From markzzzsmith@yahoo.com.au Fri Mar 1 00:18:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890EB21F8899 for ; Fri, 1 Mar 2013 00:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.655 X-Spam-Level: X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=0.444, 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 CmMUNqtJ5LJc for ; Fri, 1 Mar 2013 00:18:19 -0800 (PST) Received: from nm35-vm6.bullet.mail.bf1.yahoo.com (nm35-vm6.bullet.mail.bf1.yahoo.com [72.30.238.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9397821F8833 for ; Fri, 1 Mar 2013 00:18:19 -0800 (PST) Received: from [98.139.215.141] by nm35.bullet.mail.bf1.yahoo.com with NNFMP; 01 Mar 2013 08:18:19 -0000 Received: from [98.139.212.227] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 01 Mar 2013 08:18:19 -0000 Received: from [127.0.0.1] by omp1036.mail.bf1.yahoo.com with NNFMP; 01 Mar 2013 08:18:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 209.35752.bm@omp1036.mail.bf1.yahoo.com Received: (qmail 99613 invoked by uid 60001); 1 Mar 2013 08:18:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1362125898; bh=KZA8NcyjgpSwZOLturz/Ty3jzfiknRTfagpzj6PNMa4=; 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=DzVMObd/DTHvetD0QzSyosxpZMpmbsOPeaZ9lhP/OWyqDNS5AMfcL7q6xE+f3qDzjDtbqCGZw8hP7eJGviqeSlQCw83ESRzBEySMu6VafPAaa6uWo8JR72iC70fJsf3+hApngbfNLhXJc7OaX6D0UyNGDRnOAvB2dHjR9NGqYcA= 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=IWGFHWxpHihsnu5vo5S+Zor0WfavGomcr369lXcmO7yzBlkvHnqBL0Lbti2pCSoRunfdJ5dZ157mk1SH/a61wlXCmSpxN6t2jBJx1hfDHyo/QEA8zYPLJZTGrfht8AXD2Cmt2KmMR57suHKH0+WJhEzNhqOS5NS77g1eG3/CfBA=; X-YMail-OSG: 9cCHnH0VM1npCXTCLepgxm66Y_tVSTpZPS5X6_Psz.tOwGR ICca7yWcuSXvRhYUIllXP8_ptxxoBQwf8lZRwja1953wKPRrHpEj0DmBVSA3 GxaEhGVmHRKH.32tfqA2bCowZ0u.r5zIxgp1dprlE7x_cZEI9l.ONfV7tuMb Z2Tqh1Bc6rH6SEVEDU4NHt5sG2JCQCXSLfXUzRM51ER9MNOqu.FfuX9y2GF8 VPV2gJFSCp.N94c51wF5e1_eWXaGgzoVWtsunXPTetkoMN6166X2V1luRAHE c6QDVw8DBVsI9i5aB_9BmO2ILHKHHXjw4.7EWCYvNwtHCue6_nObNNaO9yYF LTblFaJJBaGo13hSkU7Iy28aIAkUYnZPti._ARBzYaSD0eQHaKAxjo67dVUg 9QmA62xYOsXqAkBL3FgyL2oaFVtqL6hE1Ssr5DF_T9J.jLVngz7FzIRmKY9B c8ZYuRZ6xQcba_YExXfyKn1YcxKVr01h7tkb63tKpF6n2MbWNgVFrd1eD7Pl E3tX1ckVSnF239tExNNjsKwsdnbJ0ANntr7wdFqgzFec5NEsUccS6.fAuhCS L8QAYJ4C4HOzyvyu_AQl8xXSiWxbUDzhWpge3QdirSg-- Received: from [150.101.221.237] by web142503.mail.bf1.yahoo.com via HTTP; Fri, 01 Mar 2013 00:18:18 PST X-Rocket-MIMEInfo: 001.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPgo.IFRvOiBPd2VuIERlTG9uZyA8b3dlbkBkZWxvbmcuY29tPgo.IENjOiAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz4KPiBTZW50OiBUaHVyc2RheSwgMjggRmVicnVhcnkgMjAxMyAxMDoyOSBQTQo.IFN1YmplY3Q6IFJlOiBbdjZvcHNdIFVMQSBVc2FnZSBHdWlkZSBkcmFmdCByZXF1ZXN0aW5nIGZvciByZXZpZXcKPiAKPiBPbiAyOC8wMi8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.135.514 References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <512F1A52.60806@gmail.com> <512F3FAC.7060905@gmail.com> Message-ID: <1362125898.97376.YahooMailNeo@web142503.mail.bf1.yahoo.com> Date: Fri, 1 Mar 2013 00:18:18 -0800 (PST) From: Mark Smith To: Brian E Carpenter In-Reply-To: <512F3FAC.7060905@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 08:18:20 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Brian E Carpenter =0A> To: Owen DeLong =0A> Cc: "v6op= s@ietf.org" =0A> Sent: Thursday, 28 February 2013 10:29 PM= =0A> Subject: Re: [v6ops] ULA Usage Guide draft requesting for review=0A> = =0A> On 28/02/2013 09:23, Owen DeLong wrote:=0A>> On Feb 28, 2013, at 00:5= 0 , Brian E Carpenter =0A> wrote:=0A> =0A> ..= .=0A>> What is the significant benefit to "without PI"?=0A> =0A> Saving BG= P4. Using a PI prefix is selfish as far as the=0A> Internet is concerned, s= o we need to encourage alternatives.=0A> =0A>> =0A>> PI seems to be very n= ice as near as I can tell. It is working very=0A>> well here.=0A>> =0A>>>>= Section 3.1=0A>>>> =0A>>>> The last sentence should be deleted. GUA is a= n equally viable=0A>>>> option for these networks.=0A>>> Only if you have= an ISP, which by definition you don't.=0A>> =0A>> ?? I know of a number o= f networks that are using GUA for those=0A>> purposes without involving an= ISP. Could you explain why you=0A>> think that's not possible?=0A> =0A> Y= ou need to get your prefix either from an ISP or from an LIR.=0A> You don't= need to talk to anyone, or pay anyone, to get your ULA=0A> prefix. In fact= , it can be generated automatically in a SOHO=0A> scenario, so that the use= r doesn't have to know anything.=0A>=A0=0A=0AI agree. I think requiring a G= UA prefix to build a private IPv6 network is fundamentally creating an annu= al licence fee model for the use of IPv6 technology.=0A=0AFor projects such= as the following one, annual RIR or ISP fees for a GUA would probably be= =A0exorbitant, and not good value considering the other things that the mon= ey could help provide, such as cleaner water, better education or better he= alth care.=0A=0Ahttp://villagetelco.org/about/=0A=0A=0A. From brian.e.carpenter@gmail.com Fri Mar 1 00:57:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D9B21F854E for ; Fri, 1 Mar 2013 00:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.873 X-Spam-Level: X-Spam-Status: No, score=-100.873 tagged_above=-999 required=5 tests=[AWL=0.818, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, 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 nD2MPVnTac7n for ; Fri, 1 Mar 2013 00:57:21 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id C864021F84BE for ; Fri, 1 Mar 2013 00:57:20 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hm6so3154808wib.14 for ; Fri, 01 Mar 2013 00:57:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0OiXopDuFlzHDgTsi4Thd+Ge0qsaNs37evFIPFtkfHM=; b=R5oYV2S3B0IwZqfZBBA9+P1HeOQFT16fOAyaO1eqhKGKamiMat2AUupJ5kgRVtT43B O/Nqvuz6P1V0NvcFHkbLWFFumJ97LBAEncQnH0qtNH+QrXeKcSkuEw5b1ewgRfwWVHt2 UlEJtNuFMvo0srFrm+kiQ44OvPNSUddhw6tQqmpsw/Wv9gpf6VXUDD08B20R9Ps1Hc9R kRBIXd74ICooa3N/s0Ld5cPf6dye9o6w+u7cG5pFfvyuwdKmmjcSjSHwsJz0G8OFfDap VafGt+OyqoJ71DZbox8GBY0RR6Ffj3nxdjRlnngDBmpMTgfwZSClkBHKqQlEsSKgOT5y UseA== X-Received: by 10.180.103.161 with SMTP id fx1mr37911567wib.25.1362128239953; Fri, 01 Mar 2013 00:57:19 -0800 (PST) Received: from [192.168.1.65] (host-2-101-189-92.as13285.net. [2.101.189.92]) by mx.google.com with ESMTPS id ex15sm38037608wid.5.2013.03.01.00.57.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Mar 2013 00:57:18 -0800 (PST) Message-ID: <51306D7B.7020200@gmail.com> Date: Fri, 01 Mar 2013 08:57:31 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: joel jaeggli References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <512F1A52.60806@gmail.com> <512F3FAC.7060905@gmail.com> <512FF8F6.1080204@bogus.com> In-Reply-To: <512FF8F6.1080204@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 08:57:21 -0000 On 01/03/2013 00:40, joel jaeggli wrote: > On 2/28/13 12:14 PM, Owen DeLong wrote: >> On Feb 28, 2013, at 3:29 AM, Brian E Carpenter >> wrote: >> >>> On 28/02/2013 09:23, Owen DeLong wrote: >>>> On Feb 28, 2013, at 00:50 , Brian E Carpenter >>>> wrote: >>> ... >>>> What is the significant benefit to "without PI"? >>> Saving BGP4. Using a PI prefix is selfish as far as the >>> Internet is concerned, so we need to encourage alternatives. > Strictly speaking PI holders are not the obnoxious polluters in the > routing system to today. there are ~43K AS in my internet today. > somewhat less then half of them announce only one route yet there are > 445K routes in my ipv4 table. > > Is is plausble to assert that there a potentially a lot more multihomers > out there then there are ISPs. Well yes, and the concern (which led to LISP among other things) is that the potential number of multihomers is more like ten million than 43K. At the moment there is a loose correlation between the number of active AS and the number of PI prefixes, but it's when that correlation breaks that we will have a big problem. ULA takes away one of the arguments for PI. Of course I agree with Owen that encouraging NPTv6 would be a very bad thing. Brian From brian.e.carpenter@gmail.com Fri Mar 1 01:02:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6B021F8988 for ; Fri, 1 Mar 2013 01:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.895 X-Spam-Level: X-Spam-Status: No, score=-100.895 tagged_above=-999 required=5 tests=[AWL=0.796, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, 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 Jijb6xluKcVG for ; Fri, 1 Mar 2013 01:02:41 -0800 (PST) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id 04C1721F86D5 for ; Fri, 1 Mar 2013 01:02:40 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id 8so2162968wgl.6 for ; Fri, 01 Mar 2013 01:02:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=IXMZIyrePwwIIIoZMaWS7fmwzd+U8ZtkPp+aCB4jA5Y=; b=pqyakUmXfdaCJy7m5g4sQRngbs881ZIMZj5n8mmppGKApT9mOAPMDhqFt9n0c7Jaar V0br3ILt21NBlwCA4rg3fsCEzMe58F4xfV41wOarKn0hk475PMug2UY0OYf80Sd+CmE8 FdXm7pZWGi9XGU+rEw92UbawtrnL/8t27Id7zF4IBCmebwM5sN4QEg6dAjGW9LLzZklA kjGKjGjlQRnILFkiSlDFCDuFnLc1r3n71bzlylrYltAPtIYObihePLx/D0xqBwEMO4m4 xpk6/gp0orgMsSpKJADiaR/a/+2PVCpI2Yx7Y4UDIdaIw1ZwmlSkhuz8Waj8YybO5GIL vVnA== X-Received: by 10.194.10.202 with SMTP id k10mr15948837wjb.53.1362128560099; Fri, 01 Mar 2013 01:02:40 -0800 (PST) Received: from [192.168.1.65] (host-2-101-189-92.as13285.net. [2.101.189.92]) by mx.google.com with ESMTPS id ay10sm38071208wib.3.2013.03.01.01.02.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Mar 2013 01:02:39 -0800 (PST) Message-ID: <51306EBB.3030802@gmail.com> Date: Fri, 01 Mar 2013 09:02:51 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Owen DeLong References: <4FCC0BC3-9B99-482B-AED2-F358B7A07338@delong.com> In-Reply-To: <4FCC0BC3-9B99-482B-AED2-F358B7A07338@delong.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 09:02:41 -0000 On 01/03/2013 03:27, Owen DeLong wrote: >>> Admittedly, ULA doesn't have that problem, but, neither would a /48 or >>> /32 or >>> whatever set aside from GUA for that purpose. >>> >>>> ULAs can play a similar role in this case given the devices have no >>>> global >>>> connectivity requirement and fit into existing rules which are put on >>>> the >>>> perimeter anyway. >>> They don't fit into existing rules, they need new rules. ULA does not >>> match >>> 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. You have to apply an additional >>> rule for fc00::/7. >> I think (opinion alert) most operators will put in rules for ULAs on the >> perimeter similar to RFC1918. So if those rules are in place anyway, then >> it works quite well. I suspect I have no need to accept ULA routes or >> traffic from outside the AS, so those rules will be in. Exceptions (if >> any) can be managed as exceptions. > > I think that will be true until customer A and customer B want to talk to > each other's ULAs over provider C and then those rules will get an > exception added. And then E and F will come along. Pretty soon, the > ULA rules end up looking like swiss cheese. There are no miracles. This is exactly the situation with multi-site enterprise networks today, and this is (I assume) why ISPs will tell you that their real routing table is considerably larger than the publicly visible DFZ. Whether the Swiss cheese is composed of fragmented GUA prefixes or individual ULA prefixes doesn't really matter (that's why a ULA prefix is technically scoped "global"). Brian From owen@delong.com Fri Mar 1 01:06:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F4221F8771 for ; Fri, 1 Mar 2013 01:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.466 X-Spam-Level: X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zi97cvm5NysA for ; Fri, 1 Mar 2013 01:06:13 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE4821F858E for ; Fri, 1 Mar 2013 01:06:13 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2193O7B023770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 1 Mar 2013 01:03:24 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2193O7B023770 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362128605; bh=NpsQLg94AynUUvb/jMN7YExlET4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=dKpNJr85oIegL3JdVN7Zg1VxpMTirY4hT5ZtvIPceJezIbjG3Gw+mqJveZQZpkFqn YdQQc37E2Bt6CQ8Sno6olo2NT3ci1rDEso4FxFCPzp+mcZPL/5B+JqWmniN9oSKq/7 Tt65hFH9lp9zWabObUI5kezPRBp+2/C249HiphlE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> Date: Fri, 1 Mar 2013 01:03:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> To: "Liubing (Leo)" X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 01 Mar 2013 01:03:25 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 09:06:17 -0000 >=20 >> Section 2.2.2.1 >>=20 >> IMHO, this section should be deleted in its entirety or at least come = with a >> strong cautionary note that such designs are ill-conceived and = detrimental in >> nature. Pretending that NAT or NPT improve security at all is dubious = at best. >> In fact, NPT and especially NAT provide more tall weeds for attackers = to hide >> in, if anything. >=20 > [Bing] Such designs come from special requirements such as the = abovementioned information security sensitive enterprises or = governments. If you want the endpoints disconnected as default and only = connected via central control, it is quite reasonable to pick ULA+Proxy.=20= > However, normally we won't recommend to use ULA in this model. But I = think it might not be proper to justify such scenarios as ill. My point = is: if you really have special requirements, just use it in this model; = but please don't misunderstanding ULA was just designed for this kind of = use. >=20 Then clarify that this is only intended to address ULA on = default-disconnected + Proxy networks and _NOT_ NAT or NPT which should = never be used with ULA. >> AL Proxies can be implemented equally effectively using GUA and there = is no >> significant advantage to ULA in such a case. >=20 > [Bing] If require endpoints default disconnected, egress filtering = would be easier and more stable for ULA than GUA. And can save some = operation to apply PA/PI. >=20 I disagree. I can filter 2001:db8::/32 just as easily as I can filter = fc00::7. Either way, it's just an entry in a prefix list. By definition, ULA isn't in any default prefix lists or hard coded into = being blocked by routers, so there are no special global default = semantics to it that distinguish it from GUA. Only human convention. >>=20 >> Section 3.1 >>=20 >> The last sentence should be deleted. GUA is an equally viable option = for >> these networks. >>=20 >> Section 3.3.2 >>=20 >> I'm unable to decipher Paragraph 2, so I cannot make a suggestion on >> rewording it. However, since I can't tell what you're trying to say, = I'm pretty >> sure it needs to be rewritten. >=20 > [Bing] It is only a corner case, that is, if the NAT64 prefix is = shorter than 48/, it would divide the 40bit of ULA into two parts. But = in most of the practices NAT64 just use 96/. I'll rewritten it for ease = of reading.=20 >=20 That's probably best addressed in a document that says "If you're going = to do NAT-64, then don't use a prefix shorter than /48". Certainly = there's no need to do so. Thanks, Owen From owen@delong.com Fri Mar 1 01:11:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7461921F87E0 for ; Fri, 1 Mar 2013 01:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCujsWP-WDMG for ; Fri, 1 Mar 2013 01:11:20 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D8D0421F858E for ; Fri, 1 Mar 2013 01:11:19 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r21962qM023834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 1 Mar 2013 01:06:02 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r21962qM023834 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362128762; bh=a+I3JS1lCJ+pFaQkqUWP/Gf3Yno=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XOxzp1TFjX1HaZRigjh+/X/PF1dclj6dyU3aX3XuH9FpK8PNrAWF61LsC3K0JPUha 5fV37OSs+pL7m4boLIDryGFTqU9QrZRk1RD3G3lCWvhmBjS6z34yCFNvQHLbndo4aF 48PlriE0ZfWxZ4cVUWNyq3cbi5VZalP33eK3enFQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <51306D7B.7020200@gmail.com> Date: Fri, 1 Mar 2013 01:05:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <99258677-1A6E-453C-9208-404B9E73D254@delong.com> References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <512F1A52.60806@gmail.com> <512F3FAC.7060905@gmail.com> <512FF8F6.1080204@bogus.com> <51306D7B.7020200@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 01 Mar 2013 01:06:02 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 09:11:22 -0000 On Mar 1, 2013, at 00:57 , Brian E Carpenter = wrote: > On 01/03/2013 00:40, joel jaeggli wrote: >> On 2/28/13 12:14 PM, Owen DeLong wrote: >>> On Feb 28, 2013, at 3:29 AM, Brian E Carpenter >>> wrote: >>>=20 >>>> On 28/02/2013 09:23, Owen DeLong wrote: >>>>> On Feb 28, 2013, at 00:50 , Brian E Carpenter >>>>> wrote: >>>> ... >>>>> What is the significant benefit to "without PI"? >>>> Saving BGP4. Using a PI prefix is selfish as far as the >>>> Internet is concerned, so we need to encourage alternatives. >> Strictly speaking PI holders are not the obnoxious polluters in the >> routing system to today. there are ~43K AS in my internet today. >> somewhat less then half of them announce only one route yet there are >> 445K routes in my ipv4 table. >>=20 >> Is is plausble to assert that there a potentially a lot more = multihomers >> out there then there are ISPs.=20 >=20 > Well yes, and the concern (which led to LISP among other things) is > that the potential number of multihomers is more like ten million than > 43K. At the moment there is a loose correlation between the number > of active AS and the number of PI prefixes, but it's when that > correlation breaks that we will have a big problem. >=20 Pretty much by definition, the correlation will remain. However, the = number of ASNs is now scoped to n<2^32, so that's still a really large number = of prefixes. > ULA takes away one of the arguments for PI. Of course I agree with > Owen that encouraging NPTv6 would be a very bad thing. It really doesn't. It just creates another opportunity for ISPs to treat = their customers as captive second class citizens all over again. We never should have punted on solving the routing scale problem in = IPv6. Owen From stefan.marksteiner@joanneum.at Fri Mar 1 01:36:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0EF21F86BE for ; Fri, 1 Mar 2013 01:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.23 X-Spam-Level: X-Spam-Status: No, score=-0.23 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_13=0.6, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71N-hG8HRODS for ; Fri, 1 Mar 2013 01:36:12 -0800 (PST) Received: from rzjgate1.joanneum.ac.at (rzjgate1.joanneum.ac.at [143.224.185.3]) by ietfa.amsl.com (Postfix) with ESMTP id 95BB021F85F3 for ; Fri, 1 Mar 2013 01:36:11 -0800 (PST) Received: from RZJS078.jr1.local (rzjs078.joanneum.ac.at [143.224.71.19]) by rzjgate1.joanneum.ac.at (8.14.4/8.14.4) with ESMTP id r219ZvRf002086; Fri, 1 Mar 2013 10:35:58 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joanneum.at; s=sel3; t=1362130558; bh=WsZ40oUdTxWde61GnsMzWTTFB9HOBHZdJXZs5jjz8Xw=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=NmaKAg7ks8PVGath1PR6FtOmLKBBB7qCvuvArUfAOGVhfcIE+8bh7PuMWgfo5rPNx Z8ks1vDFNwWDbdwle9PZuu5kEAm1AnbrNbOhmLTYp15HbaeJ+8KROqE0Cbll4o5lyL 0FFsmqCBKNxJdwhM5EqCyu3mIUwz1mohVlGfPn9Y= Received: from RZJC1EX.jr1.local ([169.254.2.69]) by RZJS078.jr1.local ([143.224.71.19]) with mapi; Fri, 1 Mar 2013 10:35:57 +0100 From: "Marksteiner, Stefan" To: "'Owen DeLong'" Date: Fri, 1 Mar 2013 10:35:56 +0100 Thread-Topic: [v6ops] ULA Usage Guide draft requesting for review Thread-Index: Ac4WXmzFIftZZC40T+CU3snGJbfcjw== Message-ID: <8A317FD8C00FEE448E52D4EE5B56BB3E02513FBE2301@RZJC1EX.jr1.local> Accept-Language: de-DE, de-AT Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, de-AT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'v6ops@ietf.org'" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 09:36:14 -0000 Hi, Section 2.2.2.1 follows the principle "internal addresses for internal comm= unication". As they are (per default) not advertised, they may prevent that= internal services become publically available by misconfigurations. Additi= onally, by their distinctive prefix, they are easier to recognize (for oper= ator eyes) and thus may be easier to troubleshoot in firewalling rules and = network sniffers (if, for instance, a service is mistakenly opened to the o= utside). Sincerely, Stefan P.S.: Even there is a wide consensus that ULAs (or RFC1918-addresses in v4)= , I personally would broaden the suggestion in 2.2.2.1 to internal infrastr= ucture devices and services for the reasons stated above. If the internal s= ervices don't have to be routed (or reside in an extra vlan), I'd don't nu= mber them with GUAs at all and just use their LLAs, which spares a little b= it of numbering efforts. -----Urspr=FCngliche Nachricht----- Von: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] Im Auftrag von = Owen DeLong Gesendet: Freitag, 01. M=E4rz 2013 10:03 An: Liubing (Leo) Cc: v6ops@ietf.org Betreff: Re: [v6ops] ULA Usage Guide draft requesting for review >=20 >> Section 2.2.2.1 >>=20 >> IMHO, this section should be deleted in its entirety or at least come=20 >> with a strong cautionary note that such designs are ill-conceived and=20 >> detrimental in nature. Pretending that NAT or NPT improve security at al= l is dubious at best. >> In fact, NPT and especially NAT provide more tall weeds for attackers=20 >> to hide in, if anything. >=20 > [Bing] Such designs come from special requirements such as the abovementi= oned information security sensitive enterprises or governments. If you want= the endpoints disconnected as default and only connected via central contr= ol, it is quite reasonable to pick ULA+Proxy.=20 > However, normally we won't recommend to use ULA in this model. But I thin= k it might not be proper to justify such scenarios as ill. My point is: if = you really have special requirements, just use it in this model; but please= don't misunderstanding ULA was just designed for this kind of use. >=20 Then clarify that this is only intended to address ULA on default-disconnec= ted + Proxy networks and _NOT_ NAT or NPT which should never be used with U= LA. >> AL Proxies can be implemented equally effectively using GUA and there=20 >> is no significant advantage to ULA in such a case. >=20 > [Bing] If require endpoints default disconnected, egress filtering would = be easier and more stable for ULA than GUA. And can save some operation to = apply PA/PI. >=20 I disagree. I can filter 2001:db8::/32 just as easily as I can filter fc00:= :7. Either way, it's just an entry in a prefix list. By definition, ULA isn't in any default prefix lists or hard coded into bei= ng blocked by routers, so there are no special global default semantics to = it that distinguish it from GUA. Only human convention. >>=20 >> Section 3.1 >>=20 >> The last sentence should be deleted. GUA is an equally viable option=20 >> for these networks. >>=20 >> Section 3.3.2 >>=20 >> I'm unable to decipher Paragraph 2, so I cannot make a suggestion on=20 >> rewording it. However, since I can't tell what you're trying to say,=20 >> I'm pretty sure it needs to be rewritten. >=20 > [Bing] It is only a corner case, that is, if the NAT64 prefix is shorter = than 48/, it would divide the 40bit of ULA into two parts. But in most of t= he practices NAT64 just use 96/. I'll rewritten it for ease of reading.=20 >=20 That's probably best addressed in a document that says "If you're going to = do NAT-64, then don't use a prefix shorter than /48". Certainly there's no = need to do so. Thanks, Owen _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Fri Mar 1 02:04:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059D521F84CC for ; Fri, 1 Mar 2013 02:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.53 X-Spam-Level: X-Spam-Status: No, score=-99.53 tagged_above=-999 required=5 tests=[AWL=-0.609, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 KtbRmHu2-mex for ; Fri, 1 Mar 2013 02:04:52 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBCA21F84A9 for ; Fri, 1 Mar 2013 02:04:52 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id l13so10191330wie.2 for ; Fri, 01 Mar 2013 02:04:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+314g9FdpahFQaJiHknvkCs52tD4jLwRPHdWECxRPqM=; b=qhv184hbZjjtYfm1qIJ6KzMjdYF84j8VD1nnqr9ApjDYTo3w42Y4Z3UZQEW5Js3nj1 4F0xAfMQCGjLaRyY7/tQneZjOUNFTYwYg55ZHpgJEePb+qb7JocDb/tBrceEGrNax3ld wS+Vdp2b423uRQbXOhLdgXvdYyVnVUiATg7HiurDZs4ke2agowIXPGb4gI8R7ILxXw5d 7DoHgqLqNMFaomOT4L3IlPAJHqaTugR35yGXYt3oHQNIkFra4/o07plDs03ia5GSZNZC jUBofbTJLgwPKQ0fLP7JMCmyB+Y4vJPkfCJE16mrmadG7Z9J+RaS90DVp28i/1GhDxg0 r0ug== X-Received: by 10.181.12.5 with SMTP id em5mr2762961wid.24.1362132291247; Fri, 01 Mar 2013 02:04:51 -0800 (PST) Received: from [192.168.1.65] (host-2-101-189-92.as13285.net. [2.101.189.92]) by mx.google.com with ESMTPS id m6sm20920690wic.2.2013.03.01.02.04.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Mar 2013 02:04:50 -0800 (PST) Message-ID: <51307D4F.10700@gmail.com> Date: Fri, 01 Mar 2013 10:05:03 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Owen DeLong References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <512F1A52.60806@gmail.com> <512F3FAC.7060905@gmail.com> <512FF8F6.1080204@bogus.com> <51306D7B.7020200@gmail.com> <99258677-1A6E-453C-9208-404B9E73D254@delong.com> In-Reply-To: <99258677-1A6E-453C-9208-404B9E73D254@delong.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 10:04:53 -0000 Owen, We're getting close to off-topic, but... On 01/03/2013 09:05, Owen DeLong wrote: > On Mar 1, 2013, at 00:57 , Brian E Carpenter wrote: > >> On 01/03/2013 00:40, joel jaeggli wrote: >>> On 2/28/13 12:14 PM, Owen DeLong wrote: >>>> On Feb 28, 2013, at 3:29 AM, Brian E Carpenter >>>> wrote: >>>> >>>>> On 28/02/2013 09:23, Owen DeLong wrote: >>>>>> On Feb 28, 2013, at 00:50 , Brian E Carpenter >>>>>> wrote: >>>>> ... >>>>>> What is the significant benefit to "without PI"? >>>>> Saving BGP4. Using a PI prefix is selfish as far as the >>>>> Internet is concerned, so we need to encourage alternatives. >>> Strictly speaking PI holders are not the obnoxious polluters in the >>> routing system to today. there are ~43K AS in my internet today. >>> somewhat less then half of them announce only one route yet there are >>> 445K routes in my ipv4 table. >>> >>> Is is plausble to assert that there a potentially a lot more multihomers >>> out there then there are ISPs. >> Well yes, and the concern (which led to LISP among other things) is >> that the potential number of multihomers is more like ten million than >> 43K. At the moment there is a loose correlation between the number >> of active AS and the number of PI prefixes, but it's when that >> correlation breaks that we will have a big problem. >> > > Pretty much by definition, the correlation will remain. I don't think so. As the Internet matures, more and more small business users will want redundancy, i.e. two service providers. That will break the linkage between AS and multihoming, and then the correlation might vanish. > However, the number > of ASNs is now scoped to n<2^32, so that's still a really large number of > prefixes. > >> ULA takes away one of the arguments for PI. Of course I agree with >> Owen that encouraging NPTv6 would be a very bad thing. > > It really doesn't. It just creates another opportunity for ISPs to treat their customers > as captive second class citizens all over again. > > We never should have punted on solving the routing scale problem in IPv6. We didn't punt; we tried and failed. IMHO it's still the hardest problem we have, but that discussion belongs elsewhere. Brian From leo.liubing@huawei.com Fri Mar 1 03:32:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B88521F886B for ; Fri, 1 Mar 2013 03:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.702 X-Spam-Level: X-Spam-Status: No, score=-5.702 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=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 kp5Mvs6czZlE for ; Fri, 1 Mar 2013 03:32:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9B021F8A3D for ; Fri, 1 Mar 2013 03:32:53 -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 AOY27773; Fri, 01 Mar 2013 11:32:52 +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.7; Fri, 1 Mar 2013 11:32:38 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 1 Mar 2013 11:32:51 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.101]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.01.0323.007; Fri, 1 Mar 2013 19:32:46 +0800 From: "Liubing (Leo)" To: Owen DeLong Thread-Topic: [v6ops] ULA Usage Guide draft requesting for review Thread-Index: AQHOE1oj2qUAuv5aG0SBTJo7pMCvqZiKC3OAgAPxl4CAAl7zoP//rlwAgACKUQA= Date: Fri, 1 Mar 2013 11:32:45 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.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.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 11:32:55 -0000 > > [Bing] Such designs come from special requirements such as the > abovementioned information security sensitive enterprises or governments. > If you want the endpoints disconnected as default and only connected via > central control, it is quite reasonable to pick ULA+Proxy. > > However, normally we won't recommend to use ULA in this model. But I > think it might not be proper to justify such scenarios as ill. My point i= s: if you > really have special requirements, just use it in this model; but please d= on't > misunderstanding ULA was just designed for this kind of use. > > >=20 > Then clarify that this is only intended to address ULA on > default-disconnected + Proxy networks and _NOT_ NAT or NPT which should > never be used with ULA. [Bing] Generally we consider ULA+NAT a not recommended model for connected = network. But if you for some reason chose to use NAT, then ULA is a natural= selection. The reason to use NAT, my understanding is as section 1 of RFC6296(NPTv6), = to get the address independence without acquiring PI. And also some benefit= s as described in section 4 of RFC4864. > > [Bing] If require endpoints default disconnected, egress filtering woul= d be > easier and more stable for ULA than GUA. And can save some operation to > apply PA/PI. > > >=20 >=20 > I disagree. I can filter 2001:db8::/32 just as easily as I can filter fc0= 0::7. [Bing] It is actually the discussion of distinctive range between you and V= ictor.=20 I realize there are several important topics that are not so explicit. I'll= try to summarize them according to the discussion and raise some new threa= ds. Best regards, Bing From ipepelnjak@gmail.com Fri Mar 1 07:32:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A99E21E8064 for ; Fri, 1 Mar 2013 07:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=-0.848, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, 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 qT2LlwPKd3WZ for ; Fri, 1 Mar 2013 07:32:10 -0800 (PST) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7F90D21E8053 for ; Fri, 1 Mar 2013 07:32:10 -0800 (PST) Received: by mail-ee0-f52.google.com with SMTP id b15so2312492eek.25 for ; Fri, 01 Mar 2013 07:32:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=oJsv/jRw62iqFrOaW1+UE6Ax66uvpzT7RQdI2+kkv4M=; b=rtTwQhrfW2pnm+iiEYHGWHuJ15IZBYJtoxszVvLHsyx+/p/wCz9/rUxha7HZTAWfSh O+PkQssBJyhrurVZkzTPE7TeINqRn5MpsJfXETZUTI8O2RMUuK4ZUdDBOZYkZzeIP3NN Bsv2o9dBOwepBsZDxchyTgDz/dZOI/pYT0LfcAq5oJg58+LtKB879rJsQ7DpYdzZWco+ qR2hSKskTykg0NQrI7k8wJtEqn67VpjXohA8Ek/0Pu5UOrK3VMvtmx0wnmXqQHoTHnij IA0qvaGp7qLO+J3quxA485NHbOmV58C7+w76UuR2t9atsvbqYog1pymDfFA5qGg3sFOx U8Cw== X-Received: by 10.14.215.193 with SMTP id e41mr29083481eep.32.1362151929639; Fri, 01 Mar 2013 07:32:09 -0800 (PST) Received: from [192.168.10.52] (83-215-81-109.stjo.dyn.salzburg-online.at. [83.215.81.109]) by mx.google.com with ESMTPS id 3sm17718179eej.6.2013.03.01.07.32.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Mar 2013 07:32:08 -0800 (PST) References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <512F1A52.60806@gmail.com> <512F3FAC.7060905@gmail.com> <512FF8F6.1080204@bogus.com> <51306D7B.7020200@gmail.com> In-Reply-To: <51306D7B.7020200@gmail.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Ivan Pepelnjak Date: Fri, 1 Mar 2013 16:32:07 +0100 To: Brian E Carpenter Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 15:32:11 -0000 Speaking of potential multihomers, there are large corporations that will ha= ve to make every single site (read: high thousands) PI multihomed. We've spe= nt loads of time with one of them, trying every possible design option, and i= t was either NPT66 or PI /48 per site. Welcome to the brave (or is it broken?) new world. =3D=3D=3D=3D=3D Mistyped and autocorrected on a clunky virtual keyboard On 1. mar. 2013, at 09:57, Brian E Carpenter w= rote: > On 01/03/2013 00:40, joel jaeggli wrote: >> On 2/28/13 12:14 PM, Owen DeLong wrote: >>> On Feb 28, 2013, at 3:29 AM, Brian E Carpenter >>> wrote: >>>=20 >>>> On 28/02/2013 09:23, Owen DeLong wrote: >>>>> On Feb 28, 2013, at 00:50 , Brian E Carpenter >>>>> wrote: >>>> ... >>>>> What is the significant benefit to "without PI"? >>>> Saving BGP4. Using a PI prefix is selfish as far as the >>>> Internet is concerned, so we need to encourage alternatives. >> Strictly speaking PI holders are not the obnoxious polluters in the >> routing system to today. there are ~43K AS in my internet today. >> somewhat less then half of them announce only one route yet there are >> 445K routes in my ipv4 table. >>=20 >> Is is plausble to assert that there a potentially a lot more multihomers >> out there then there are ISPs.=20 >=20 > Well yes, and the concern (which led to LISP among other things) is > that the potential number of multihomers is more like ten million than > 43K. At the moment there is a loose correlation between the number > of active AS and the number of PI prefixes, but it's when that > correlation breaks that we will have a big problem. >=20 > ULA takes away one of the arguments for PI. Of course I agree with > Owen that encouraging NPTv6 would be a very bad thing. >=20 > Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From alexandru.petrescu@gmail.com Fri Mar 1 08:46:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22BC121F94FC for ; Fri, 1 Mar 2013 08:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.292 X-Spam-Level: X-Spam-Status: No, score=-10.292 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 L+-4SdzLwaqW for ; Fri, 1 Mar 2013 08:46:13 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 45CBC21F93DF for ; Fri, 1 Mar 2013 08:46:13 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r21GgHQ1020154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Mar 2013 17:46:12 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r21E8g49016487; Fri, 1 Mar 2013 15:08:42 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r21E8fkK012945; Fri, 1 Mar 2013 15:08:42 +0100 Message-ID: <5130B665.1020907@gmail.com> Date: Fri, 01 Mar 2013 15:08:37 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: =?ISO-8859-2?Q?V=EDzdal_Ale=B9?= References: <512CF682.8030307@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6D11E055F@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6D11E055F@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 16:46:14 -0000 Le 27/02/2013 00:59, Vízdal Ale¹ a écrit : >>> Correct. NAT44 is good enough if you can number users from >>> RFC1918. If users (including M2M ...) and infrastructure exceed >>> RFC1918 space >> >> If they exceed RFC1918 space (10.0.0.0/8, 172.16.0.0/12 and >> 192.168.0.0/16) then there is this 100.64.0.0/10 new space from >> RFC6598. > > Unfortunately, 40-60 million customer base cannot be addressed by > RFC1918/10.64/10 address space. Well. I side with typical advocating of IPv6 and big numbers. But let me play devil's advocate here. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and 100.64.0.0/10 make up for a total of unique 22 million (22085632) addresses. This is indeed less than the 40-60 million customer base. But the nature of NAT is more than that. It is also about - multiple levels of NAT. - NAT technology can be used with publicly routable addresses which are not RFC1918/RFC6598. - dynamic address allocation. With 3 levels of NAT and an additional not-used class B, one can easily cover a 40-60 million customer base. Not all 40-60 million customers are connected simultaneously. DHCP takes care to revoke use of an address and deliver it to someone else needing it. If all 40-60 million customers were connected simultaneously then the core network would crash - but for other reasons than IPv4 address numbers. Cellular network crashes exist yet they're not due to too small IPv4 addressing space. There is not a problem in numbers when using NAT technology to cover that 40-60 million customer base. There are other problems, but not in numbers of IPv4 addressing. If these problems could be formulated then we could have a case for IPv6 in cellular networks. Alex > > Ales > > From fred@cisco.com Fri Mar 1 12:37:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CFC21E809E for ; Fri, 1 Mar 2013 12:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.202 X-Spam-Level: X-Spam-Status: No, score=-110.202 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 QKqIsSqsNKNh for ; Fri, 1 Mar 2013 12:37:45 -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 1FDD421E8053 for ; Fri, 1 Mar 2013 12:37:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1411; q=dns/txt; s=iport; t=1362170265; x=1363379865; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=rNTYcA8fFA3j6l2GU4VjWkQbvEwrS/fCh4zYg89o5Ng=; b=hcBMi4+yEtNYFBJWGz3DgrsSmxlPO55dF8OWRq6xiCBghZ8GGprAGxxV G8xfdjqYpQeWaEjdQLWki6TppPJU4a8KiUQm/CP07DL2HLn54yuGMj732 iWAEACsFVW380Gd9Vj3A9+/tiiL0i+GETmhWwwurBsQXq3hK5pKUpHyef M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHcQMVGtJXG8/2dsb2JhbABEwj1/FnOCIQEEOismASoUQicEG4gLDKAtoGqObIMXYQOXYY9NgwiCJw X-IronPort-AV: E=Sophos;i="4.84,762,1355097600"; d="scan'208";a="182846602" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 01 Mar 2013 20:37:44 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r21KbixE000356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 1 Mar 2013 20:37:44 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Fri, 1 Mar 2013 14:37:44 -0600 From: "Fred Baker (fred)" To: IPv6 Ops WG Thread-Topic: IPv6 Operations Agenda - IETF 86 Thread-Index: AQHOFrygx5RndLBsfkCjUpJJhvmuRw== Date: Fri, 1 Mar 2013 20:37:44 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B7B90FE@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.120] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] IPv6 Operations Agenda - IETF 86 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 20:37:45 -0000 Agenda for the coming meeting. Opinions solicited. IPv6 Operations - IETF 86 Monday 13:00 Agenda Bashing Discussing outcome and process for two drafts: NAT64 Deployment Considerations 31-Jan-13 , A Larger Loopback Prefix for IPv6 20-Feb-13 , Extending an IPv6 /64 Prefix from a 3GPP Mobile Interface to a LAN 20-Feb-13 , IPv6 for 3GPP Cellular Hosts 25-Feb-13 , Internet Protocol Version 6 (IPv6) Requirements for Cellular Hosts 30-Jan-13 , Enterprise IPv6 Deployment Guidelines 25-Feb-13 , Wednesday 15:10 Design Choices for IPv6 Networks 18-Feb-13 , Balanced Security for IPv6 CPE 25-Jan-13 , IPv6 IPID Needed 1-Feb-13 , IPv6 Operational Guidelines for Datacenters 5-Feb-13 , Guidance of Using Unique Local Addresses 25-Feb-13 , Draft Status The status of v6ops drafts, both working group drafts (draft-ietf-v6ops-*) = and individual submissions to the working group (draft--v6ops-*), m= ay be determined from http://datatracker.ietf.org/wg/v6ops/. From owen@delong.com Fri Mar 1 18:51:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267AD21F8B9F for ; Fri, 1 Mar 2013 18:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.362 X-Spam-Level: X-Spam-Status: No, score=-1.362 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_35=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZJs1UcJp2Mg for ; Fri, 1 Mar 2013 18:51:14 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 3499921F8BA1 for ; Fri, 1 Mar 2013 18:51:13 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r222kGkW006996 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 1 Mar 2013 18:46:16 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r222kGkW006996 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362192376; bh=Rz47zZ/75D1p08OEioPKS1uo4vs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=tCO4s4sT9O4NETclFWltJwoUSB3/Nt79xX8lEQIxJxC03awE7M7t/kYyD8z0l80Ex RtyqiYO9eSK4mq6g3CDF42/3+sGB1Dc8ZB+9w+DoWBJMm34sI9iCQjrQYF12BENxjK 2RtEKeg/Ng+GQD7hJx09RvX5EKbwVxau2Nje+ldo= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <8A317FD8C00FEE448E52D4EE5B56BB3E02513FBE2301@RZJC1EX.jr1.local> Date: Fri, 1 Mar 2013 18:45:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3AC1A1D6-6ED1-4A3E-BE7A-AE5306A3E6CC@delong.com> References: <8A317FD8C00FEE448E52D4EE5B56BB3E02513FBE2301@RZJC1EX.jr1.local> To: "Marksteiner, Stefan" X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 01 Mar 2013 18:46:16 -0800 (PST) Cc: "'v6ops@ietf.org'" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 02:51:15 -0000 On Mar 1, 2013, at 01:35 , "Marksteiner, Stefan" = wrote: > Hi, >=20 > Section 2.2.2.1 follows the principle "internal addresses for internal = communication". As they are (per default) not advertised, they may = prevent that internal services become publically available by = misconfigurations. Additionally, by their distinctive prefix, they are = easier to recognize (for operator eyes) and thus may be easier to = troubleshoot in firewalling rules and network sniffers (if, for = instance, a service is mistakenly opened to the outside). >=20 I'm not sure what you mean by "As they are (per default) not = advertised..." There is no special treatment of ULA in routers. No prefix is advertised = in BGP by default. ULA or GUA. In other protocols, ULA is advertised with the same defaults as GUA. If I have a local convention that says 2001:123::/32 is my publicly = reachable space and 2620:4:104::/48 shouldn't be advertised, it's every = bit as recognizable as ULA to the operators that work for me. > Sincerely, >=20 > Stefan >=20 > P.S.: Even there is a wide consensus that ULAs (or RFC1918-addresses = in v4), I personally would broaden the suggestion in 2.2.2.1 to internal = infrastructure devices and services for the reasons stated above. If the = internal services don't have to be routed (or reside in an extra vlan), = I'd don't number them with GUAs at all and just use their LLAs, which = spares a little bit of numbering efforts. >=20 Your DNS must be fun and you've rendered them unreachable to other = internal hosts that are not on the same subnet. Owen >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] Im Auftrag = von Owen DeLong > Gesendet: Freitag, 01. M=E4rz 2013 10:03 > An: Liubing (Leo) > Cc: v6ops@ietf.org > Betreff: Re: [v6ops] ULA Usage Guide draft requesting for review >=20 >>=20 >>> Section 2.2.2.1 >>>=20 >>> IMHO, this section should be deleted in its entirety or at least = come=20 >>> with a strong cautionary note that such designs are ill-conceived = and=20 >>> detrimental in nature. Pretending that NAT or NPT improve security = at all is dubious at best. >>> In fact, NPT and especially NAT provide more tall weeds for = attackers=20 >>> to hide in, if anything. >>=20 >> [Bing] Such designs come from special requirements such as the = abovementioned information security sensitive enterprises or = governments. If you want the endpoints disconnected as default and only = connected via central control, it is quite reasonable to pick ULA+Proxy.=20= >> However, normally we won't recommend to use ULA in this model. But I = think it might not be proper to justify such scenarios as ill. My point = is: if you really have special requirements, just use it in this model; = but please don't misunderstanding ULA was just designed for this kind of = use. >>=20 >=20 > Then clarify that this is only intended to address ULA on = default-disconnected + Proxy networks and _NOT_ NAT or NPT which should = never be used with ULA. >=20 >>> AL Proxies can be implemented equally effectively using GUA and = there=20 >>> is no significant advantage to ULA in such a case. >>=20 >> [Bing] If require endpoints default disconnected, egress filtering = would be easier and more stable for ULA than GUA. And can save some = operation to apply PA/PI. >>=20 >=20 >=20 > I disagree. I can filter 2001:db8::/32 just as easily as I can filter = fc00::7. >=20 > Either way, it's just an entry in a prefix list. >=20 > By definition, ULA isn't in any default prefix lists or hard coded = into being blocked by routers, so there are no special global default = semantics to it that distinguish it from GUA. Only human convention. >=20 >>>=20 >>> Section 3.1 >>>=20 >>> The last sentence should be deleted. GUA is an equally viable option=20= >>> for these networks. >>>=20 >>> Section 3.3.2 >>>=20 >>> I'm unable to decipher Paragraph 2, so I cannot make a suggestion on=20= >>> rewording it. However, since I can't tell what you're trying to say,=20= >>> I'm pretty sure it needs to be rewritten. >>=20 >> [Bing] It is only a corner case, that is, if the NAT64 prefix is = shorter than 48/, it would divide the 40bit of ULA into two parts. But = in most of the practices NAT64 just use 96/. I'll rewritten it for ease = of reading.=20 >>=20 >=20 > That's probably best addressed in a document that says "If you're = going to do NAT-64, then don't use a prefix shorter than /48". Certainly = there's no need to do so. >=20 > Thanks, >=20 > Owen >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From owen@delong.com Fri Mar 1 18:51:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58BB1F0D0E for ; Fri, 1 Mar 2013 18:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.367 X-Spam-Level: X-Spam-Status: No, score=-1.367 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdk1km6XfTCN for ; Fri, 1 Mar 2013 18:51:22 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id E5AF31F0D0F for ; Fri, 1 Mar 2013 18:51:21 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r222ntSt007026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 1 Mar 2013 18:49:56 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r222ntSt007026 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362192596; bh=Q9h4tkLPEpVy6TRCL+wAHuiVnOQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=AhhITuIXOkMOzDZNGk5Ijzg7z+TMQNQ8fQvUANiKcZDE9pLKnFmIqdbmjpHHQGA0X E27EQCYhP1T/LklqG903oa9A6TK4iwkUgB+H/88/CeA9XtBqPHPHCMgR6suVq5rMbw kEL3qFuospcIOBmnj1XwBg8rffQU4BYSyOHT9zss= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> Date: Fri, 1 Mar 2013 18:49:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> To: Liubing (Leo) X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 01 Mar 2013 18:49:56 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 02:51:22 -0000 On Mar 1, 2013, at 03:32 , Liubing (Leo) wrote: >>> [Bing] Such designs come from special requirements such as the >> abovementioned information security sensitive enterprises or = governments. >> If you want the endpoints disconnected as default and only connected = via >> central control, it is quite reasonable to pick ULA+Proxy. >>> However, normally we won't recommend to use ULA in this model. But I >> think it might not be proper to justify such scenarios as ill. My = point is: if you >> really have special requirements, just use it in this model; but = please don't >> misunderstanding ULA was just designed for this kind of use. >>>=20 >>=20 >> Then clarify that this is only intended to address ULA on >> default-disconnected + Proxy networks and _NOT_ NAT or NPT which = should >> never be used with ULA. >=20 > [Bing] Generally we consider ULA+NAT a not recommended model for = connected network. But if you for some reason chose to use NAT, then ULA = is a natural selection. > The reason to use NAT, my understanding is as section 1 of = RFC6296(NPTv6), to get the address independence without acquiring PI. = And also some benefits as described in section 4 of RFC4864. >=20 Which is why I want to see a statement in this draft that notes the = tradeoffs and that these solutions are not recommended before it = advances. Owen From owen@delong.com Fri Mar 1 19:00:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F06021E8037 for ; Fri, 1 Mar 2013 19:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrOuRIGhyy6q for ; Fri, 1 Mar 2013 19:00:55 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6951F0D14 for ; Fri, 1 Mar 2013 19:00:55 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r22306Jr007145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 1 Mar 2013 19:00:07 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r22306Jr007145 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362193207; bh=SOnr6kIvHP8z0LomKuuUNJq2Etw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Ii6WQFDFTHKGSWq3oKtUUBSrzR4LjMQauTI457APAx7bgAhjSTNYSDV3iVf2lfRvc at71lIMGeyMCNPnmcnZVCkA2Ax8AiaH7PvcQkLmFoOXEl/1OODmnfrheskQOQf8h3E Xq2bMVoAhzULC9Ax2AVnO0rktqmZW8Kh39vB785A= Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <5130B665.1020907@gmail.com> Date: Fri, 1 Mar 2013 18:59:15 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8D4B01C4-EC43-48A4-BC15-A4D2DC5CACC2@delong.com> References: <512CF682.8030307@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6D11E055F@SRVHKE02.rdm.cz> <5130B665.1020907@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 01 Mar 2013 19:00:07 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 03:00:56 -0000 On Mar 1, 2013, at 06:08 , Alexandru Petrescu = wrote: > Le 27/02/2013 00:59, V=EDzdal Ale=B9 a =E9crit : >>>> Correct. NAT44 is good enough if you can number users from >>>> RFC1918. If users (including M2M ...) and infrastructure exceed >>>> RFC1918 space >>>=20 >>> If they exceed RFC1918 space (10.0.0.0/8, 172.16.0.0/12 and >>> 192.168.0.0/16) then there is this 100.64.0.0/10 new space from >>> RFC6598. >>=20 >> Unfortunately, 40-60 million customer base cannot be addressed by >> RFC1918/10.64/10 address space. >=20 > Well. I side with typical advocating of IPv6 and big numbers. But = let > me play devil's advocate here. >=20 > 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and 100.64.0.0/10 make up = for > a total of unique 22 million (22085632) addresses. This is indeed = less > than the 40-60 million customer base. >=20 > But the nature of NAT is more than that. It is also about > - multiple levels of NAT. Breaks many NAT traversal solutions and makes NAT even = more dysfunctional. > - NAT technology can be used with publicly routable addresses which > are not RFC1918/RFC6598. Breaks NAT-oriented assumptions that have been baked = into some applications NAT traversal efforts. > - dynamic address allocation. Has nothing whatsoever to do with NAT. >=20 > With 3 levels of NAT and an additional not-used class B, one can = easily > cover a 40-60 million customer base. Not all 40-60 million customers > are connected simultaneously. DHCP takes care to revoke use of an > address and deliver it to someone else needing it. There are a lot of (not necessarily correct) assumptions about usage patterns built into those numbers. I can guarantee you that if an ISP were to inflict such an implementation on residential subscribers, they would lose customers quickly. In mobile, maybe, maybe not. People have become pretty tolerant of an impressive level of dysfunctionality in mobile IP in the US. > If all 40-60 million customers were connected simultaneously then the > core network would crash - but for other reasons than IPv4 address = numbers. I'm not actually convinced that's true. > Cellular network crashes exist yet they're not due to too small IPv4 > addressing space. Whether the lack of addresses crashes the network or not, it certainly degrades the user experience. > There is not a problem in numbers when using NAT technology to cover > that 40-60 million customer base. There are other problems, but not = in > numbers of IPv4 addressing. Yes, there is a real problem in IPv4 numbers, too. The fact that you're = more willing to add a bunch of hacks to IPv4 to try and prop it up instead of implementing IPv6 really doesn't change the fact that there is a = problem. > If these problems could be formulated then we could have a case for = IPv6 > in cellular networks. The problems have been formulated and a number of cellular networks have started deploying IPv6. I believe Slovenia is completely dual-stacked on = their cellular networks, for example. I know that Verizon and T-Mobile both have IPv6 on their wireless = networks to varying degrees. Owen >=20 From victor.kuarsingh@gmail.com Fri Mar 1 19:37:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C58321F8BA6 for ; Fri, 1 Mar 2013 19:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.584 X-Spam-Level: X-Spam-Status: No, score=-0.584 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.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 vHnrjvIQT-Ue for ; Fri, 1 Mar 2013 19:37:16 -0800 (PST) Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C918221F8B9C for ; Fri, 1 Mar 2013 19:37:16 -0800 (PST) Received: by mail-ia0-f171.google.com with SMTP id z13so3245612iaz.2 for ; Fri, 01 Mar 2013 19:37:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=y9sEKJBn+rY1b/afvgov+lNPVNzNQJCm36dlE3G2+XY=; b=IIdN2h9QU5Hb5doiGpo9t20lIJE1LnygUKDL3v/pGMyMhi7KIWIvF1OHuEw4316Mdw cTQMd/GZOhVaTW/+UMXCBgyaLy+GSa67jkrEaJN/FQfupcIBfcegJj9XH1paayEASyhS hwA2v3iDCaLC/C5jeH29L4hmy3zvJRBEXhUyFSrgKfm81dzmXxGdDNcga7epD8jw9ba/ 4/kKSLBKXgZiEANNheATPZJ3GPFgL3/Rh77sXws0zEozInWpzHS3AEl7BQ1yop4PWjoX ldGjh5bMDazqa6N8GnWg+c24c25HtHj4URkNBV9yUysKany93fk46vJBIM2tDznbKQDy VFuQ== X-Received: by 10.43.4.74 with SMTP id ob10mr10146769icb.28.1362195435727; Fri, 01 Mar 2013 19:37:15 -0800 (PST) Received: from [192.168.100.33] ([67.224.83.162]) by mx.google.com with ESMTPS id px9sm1524397igc.0.2013.03.01.19.37.12 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 01 Mar 2013 19:37:15 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Fri, 01 Mar 2013 22:37:13 -0500 From: Victor Kuarsingh To: Owen DeLong , Alexandru Petrescu Message-ID: Thread-Topic: [v6ops] State of IPv6 in Mobile Cellular Networks In-Reply-To: <8D4B01C4-EC43-48A4-BC15-A4D2DC5CACC2@delong.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 03:37:17 -0000 On 2013-03-01 9:59 PM, "Owen DeLong" wrote: > >On Mar 1, 2013, at 06:08 , Alexandru Petrescu > wrote: > >> Le 27/02/2013 00:59, V=EDzdal Ale=B9 a =E9crit : >>>>>. In mobile, maybe, maybe not. People >have become pretty tolerant of an impressive level of dysfunctionality >in mobile IP in the US. I think this is going to change. I suspect as people start to use mobile interchangeably with their traditional wired connections, they will demand more robust connectivity. I.e. Exchanging your wired connection for Wireless to realize you can't do all the stuff you did the day before is frustrating. Although tolerated to date, I suspect the tides will change. I also think IPv6 is a good way to get there and that IPv4 can't IMHO (given this list, I would guess that some may agree). My 0.02. Regards, Victor Kuarsingh > From dougb@dougbarton.us Fri Mar 1 21:36:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C37121E8114 for ; Fri, 1 Mar 2013 21:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSAmTDhAJjZj for ; Fri, 1 Mar 2013 21:36:12 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 388A021E80F4 for ; Fri, 1 Mar 2013 21:36:12 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:ad3f:99b:9fb7:3073] (unknown [IPv6:2001:470:d:5e7:ad3f:99b:9fb7:3073]) by dougbarton.us (Postfix) with ESMTPSA id 3AFD122B6D for ; Sat, 2 Mar 2013 05:36:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362202570; bh=DHdZoxBL7MmM4OEuzeubJ7kgfjLsnu0OcaLKtqpPMQs=; h=Date:From:To:Subject:References:In-Reply-To; b=CYAyNtBw041/HPUHYcbbdCr4W2dNfhKvfIlcY5nzC4NValdYTd4CeonyW0TYXlzlO zfl/OxmeaRfzPGHCoXwQ53GhvvJwhOngy7ULy76m7VEqDb5hJ1ElRLDpyiDlKsEOfT tolOjQuVX/Y0YXbjvqSmpBMgnokfpY/xYb8w3ui0= Message-ID: <51318FC8.8070600@dougbarton.us> Date: Fri, 01 Mar 2013 21:36:08 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> In-Reply-To: <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 05:36:13 -0000 On 03/01/2013 06:49 PM, Owen DeLong wrote: > > On Mar 1, 2013, at 03:32 , Liubing (Leo) wrote: > >>>> [Bing] Such designs come from special requirements such as the >>> abovementioned information security sensitive enterprises or governments. >>> If you want the endpoints disconnected as default and only connected via >>> central control, it is quite reasonable to pick ULA+Proxy. >>>> However, normally we won't recommend to use ULA in this model. But I >>> think it might not be proper to justify such scenarios as ill. My point is: if you >>> really have special requirements, just use it in this model; but please don't >>> misunderstanding ULA was just designed for this kind of use. >>>> >>> >>> Then clarify that this is only intended to address ULA on >>> default-disconnected + Proxy networks and _NOT_ NAT or NPT which should >>> never be used with ULA. >> >> [Bing] Generally we consider ULA+NAT a not recommended model for connected network. But if you for some reason chose to use NAT, then ULA is a natural selection. >> The reason to use NAT, my understanding is as section 1 of RFC6296(NPTv6), to get the address independence without acquiring PI. And also some benefits as described in section 4 of RFC4864. >> > > Which is why I want to see a statement in this draft that notes the tradeoffs and that these solutions are not recommended before it advances. Documenting the tradeoffs would be useful, yes. "Not recommended" is almost certainly going too far. Doug From owen@delong.com Fri Mar 1 21:56:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978E321F8DDC for ; Fri, 1 Mar 2013 21:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.433 X-Spam-Level: X-Spam-Status: No, score=-1.433 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIfhpG-PT2Kb for ; Fri, 1 Mar 2013 21:56:08 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D0D1A21F8DD9 for ; Fri, 1 Mar 2013 21:56:07 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r225rgM6010645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 1 Mar 2013 21:53:43 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r225rgM6010645 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362203623; bh=0t4o690TjlBgY2HbJ9lD0Xv3n6M=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=bZHYzESy764yyo7gWqNOOfoF+f5CAChj+DGBX8n0Y2JuWiWCg1quTpdm0fLBKbgfU e1p2UnSJNUXSbQ/QqEZK7G466CwIcHR4rGk0Ja1Lno3X4zF1p4W9V04YvwK+KJeFAp WOgRxUEVHfLNdgtkQaAwj67WmicO+it0XDggSqRo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <51318FC8.8070600@dougbarton.us> Date: Fri, 1 Mar 2013 21:52:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 01 Mar 2013 21:53:43 -0800 (PST) Cc: v6ops@ietf.org Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 05:56:09 -0000 On Mar 1, 2013, at 21:36 , Doug Barton wrote: > On 03/01/2013 06:49 PM, Owen DeLong wrote: >>=20 >> On Mar 1, 2013, at 03:32 , Liubing (Leo) = wrote: >>=20 >>>>> [Bing] Such designs come from special requirements such as the >>>> abovementioned information security sensitive enterprises or = governments. >>>> If you want the endpoints disconnected as default and only = connected via >>>> central control, it is quite reasonable to pick ULA+Proxy. >>>>> However, normally we won't recommend to use ULA in this model. But = I >>>> think it might not be proper to justify such scenarios as ill. My = point is: if you >>>> really have special requirements, just use it in this model; but = please don't >>>> misunderstanding ULA was just designed for this kind of use. >>>>>=20 >>>>=20 >>>> Then clarify that this is only intended to address ULA on >>>> default-disconnected + Proxy networks and _NOT_ NAT or NPT which = should >>>> never be used with ULA. >>>=20 >>> [Bing] Generally we consider ULA+NAT a not recommended model for = connected network. But if you for some reason chose to use NAT, then ULA = is a natural selection. >>> The reason to use NAT, my understanding is as section 1 of = RFC6296(NPTv6), to get the address independence without acquiring PI. = And also some benefits as described in section 4 of RFC4864. >>>=20 >>=20 >> Which is why I want to see a statement in this draft that notes the = tradeoffs and that these solutions are not recommended before it = advances. >=20 > Documenting the tradeoffs would be useful, yes. "Not recommended" is = almost certainly going too far. >=20 In the case of NPTv6, I really don't think that it is. There are = serious impacts to the intended nature of IPv6 if NPT starts getting = widely deployed. Owen From dougb@dougbarton.us Fri Mar 1 22:24:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5761221F90B2 for ; Fri, 1 Mar 2013 22:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBX1rw-32Vyz for ; Fri, 1 Mar 2013 22:24:25 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id BB09021F8CE8 for ; Fri, 1 Mar 2013 22:24:25 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:ad3f:99b:9fb7:3073] (unknown [IPv6:2001:470:d:5e7:ad3f:99b:9fb7:3073]) by dougbarton.us (Postfix) with ESMTPSA id 6087422B6D for ; Sat, 2 Mar 2013 06:24:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362205465; bh=QzaFUFDVkmuCbgG4R46zXpqMhkb0ya44Vr7OPkDj7ss=; h=Date:From:To:Subject:References:In-Reply-To; b=NJRyyAHqxeyyaF5esatlw02q/vK1hZiyJhEOMuDjV7jFz/rqTqk7L4/A56sH/ebA4 0KzNp/wd4oXvKvPhkZFYmQXySS7fZuhlxumJkLfbJPgDJ4McBIEJqLAgsFxsoSP72V jZP6i1CrHzXydOBLntHipzROTnEunRXdTPTfthm4= Message-ID: <51319B17.1070609@dougbarton.us> Date: Fri, 01 Mar 2013 22:24:23 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 06:24:26 -0000 On 03/01/2013 09:52 PM, Owen DeLong wrote: > > On Mar 1, 2013, at 21:36 , Doug Barton wrote: > >> On 03/01/2013 06:49 PM, Owen DeLong wrote: >>> >>> On Mar 1, 2013, at 03:32 , Liubing (Leo) wrote: >>> >>>>>> [Bing] Such designs come from special requirements such as the >>>>> abovementioned information security sensitive enterprises or governments. >>>>> If you want the endpoints disconnected as default and only connected via >>>>> central control, it is quite reasonable to pick ULA+Proxy. >>>>>> However, normally we won't recommend to use ULA in this model. But I >>>>> think it might not be proper to justify such scenarios as ill. My point is: if you >>>>> really have special requirements, just use it in this model; but please don't >>>>> misunderstanding ULA was just designed for this kind of use. >>>>>> >>>>> >>>>> Then clarify that this is only intended to address ULA on >>>>> default-disconnected + Proxy networks and _NOT_ NAT or NPT which should >>>>> never be used with ULA. >>>> >>>> [Bing] Generally we consider ULA+NAT a not recommended model for connected network. But if you for some reason chose to use NAT, then ULA is a natural selection. >>>> The reason to use NAT, my understanding is as section 1 of RFC6296(NPTv6), to get the address independence without acquiring PI. And also some benefits as described in section 4 of RFC4864. >>>> >>> >>> Which is why I want to see a statement in this draft that notes the tradeoffs and that these solutions are not recommended before it advances. >> >> Documenting the tradeoffs would be useful, yes. "Not recommended" is almost certainly going too far. >> > > In the case of NPTv6, I really don't think that it is. There are serious impacts to the intended nature of IPv6 if NPT starts getting widely deployed. Yes, I get that there are a lot of people in the IPv6 literati that wish for the return of the end-to-end model, and dramatically resist anything that tries to take that away. The problem, as was recently discussed (again) in nauseating detail on ipv6-ops@lists.cluenet.de is that most organizations not only don't want end-to-end back, they prioritize ease of renumbering much higher than any benefits IPv6 might bring. Because for end user networks there is no compelling reason to deploy IPv6 right now, nor is there likely to be one in the near future, we need to understand the real world needs for those organizations, and focus on ways to deliver them. ULA + NPTv6 does that, and the costs are minimal (although not non-existent, which is why documenting the tradeoffs is valuable). Even for those end-user networks where PI space makes sense (and I would argue that they are few and far between) the costs, both monetary in terms of RIR fees, and opex; are non-zero, so discussing the pros _and_ cons of all the solutions will have value for the target audience. Doug From owen@delong.com Sat Mar 2 05:16:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A6221F8868 for ; Sat, 2 Mar 2013 05:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.73 X-Spam-Level: X-Spam-Status: No, score=-1.73 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sz2Qbz-17j+e for ; Sat, 2 Mar 2013 05:16:10 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id DB44121F882E for ; Sat, 2 Mar 2013 05:16:10 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r22DE6SI017740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 2 Mar 2013 05:14:06 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r22DE6SI017740 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362230047; bh=xLd5mHEMlamjO09NpH8tZOH0qzE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=porlsyEsE/vpoH4zQuj2yzW05eOztCAy4uUeQ+fSMDCVHFATrOnqKYmRipnTy3Kkk jqAVngqFnu3sbFElcfVlrIN3EaV2QNvTVjaetM1AKsSpC81C/5KzziSrlwNQDBKH0W F8P+wdrFhvaU27cOwjpDeVx5OdbVfpeYZKJKVAjA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <51319B17.1070609@dougbarton.us> Date: Sat, 2 Mar 2013 05:12:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 02 Mar 2013 05:14:07 -0800 (PST) Cc: v6ops@ietf.org Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 13:16:11 -0000 >>>=20 >>=20 >> In the case of NPTv6, I really don't think that it is. There are = serious impacts to the intended nature of IPv6 if NPT starts getting = widely deployed. >=20 > Yes, I get that there are a lot of people in the IPv6 literati that = wish for the return of the end-to-end model, and dramatically resist = anything that tries to take that away. The problem, as was recently = discussed (again) in nauseating detail on ipv6-ops@lists.cluenet.de is = that most organizations not only don't want end-to-end back, they = prioritize ease of renumbering much higher than any benefits IPv6 might = bring. >=20 > Because for end user networks there is no compelling reason to deploy = IPv6 right now, nor is there likely to be one in the near future, we = need to understand the real world needs for those organizations, and = focus on ways to deliver them. ULA + NPTv6 does that, and the costs are = minimal (although not non-existent, which is why documenting the = tradeoffs is valuable). >=20 The cost is not minimal. The cost is borne not by those deploying NPT. = The cost is borne by every application developer, every security = professional, law enforcement, etc. NPT and NAT are the network equivalent of the toxic polluter model. = Sure, it's cheap to dump toxic chemicals into the creek upstream. The = true costs are borne by those downstream, not the person dumping the = chemicals. > Even for those end-user networks where PI space makes sense (and I = would argue that they are few and far between) the costs, both monetary = in terms of RIR fees, and opex; are non-zero, so discussing the pros = _and_ cons of all the solutions will have value for the target audience. An up front $1,250 and an annual $100 is _NOT_ a significant expense = IMHO and that is what PI /48 costs from ARIN. I don't know about the = other RIRs. In terms of Opex, PI costs no more and probably somewhat less than NPT = because if it is set up correctly, it's basically fire and forget. The = configuration complexity for changing providers is no greater than that = with NPT+ULA. You get the further advantage that you can have actually = redundant routers, not just redundant connections (the NPT solution = basically requires putting both providers into a single box or REALLY = complex workarounds such as STONITH to make sure only one router sends = RAs at a time). You also get the advantage that sessions can (and = usually do) survive a failover event. Owen From dougb@dougbarton.us Sat Mar 2 13:43:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9F621F859B for ; Sat, 2 Mar 2013 13:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.768 X-Spam-Level: X-Spam-Status: No, score=-0.768 tagged_above=-999 required=5 tests=[AWL=-1.368, BAYES_50=0.001, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrU-Qs55+jSQ for ; Sat, 2 Mar 2013 13:43:09 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8F73821F8598 for ; Sat, 2 Mar 2013 13:43:09 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:4c85:246:97cf:cabd] (unknown [IPv6:2001:470:d:5e7:4c85:246:97cf:cabd]) by dougbarton.us (Postfix) with ESMTPSA id 0872322B31 for ; Sat, 2 Mar 2013 21:43:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362260589; bh=lEOXXukUHsnhA71Bg+YFX0mIBJhkL5/plA16LeQ3MTI=; h=Date:From:To:Subject:References:In-Reply-To; b=XVraLrJD7IFDLjWZkjFyGeF2yjE+dAe1JsDU4LzMwQsb/7yjs87xwpXX+gOiQoqAD x++T2MQbexNh5UMCskbhnYNQbS7o6FQxKdA82LqZIeCQ0wA+0/9MYIM2dgF9jVEQJ0 HLlSlWK6PnOpNskMOfK5ZWJa/lew+ntccYVJaGCY= Message-ID: <5132726C.5040600@dougbarton.us> Date: Sat, 02 Mar 2013 13:43:08 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 21:43:10 -0000 On 03/02/2013 05:12 AM, Owen DeLong wrote: >>>> >>> >>> In the case of NPTv6, I really don't think that it is. There are >>> serious impacts to the intended nature of IPv6 if NPT starts >>> getting widely deployed. >> >> Yes, I get that there are a lot of people in the IPv6 literati that >> wish for the return of the end-to-end model, and dramatically >> resist anything that tries to take that away. The problem, as was >> recently discussed (again) in nauseating detail on >> ipv6-ops@lists.cluenet.de is that most organizations not only don't >> want end-to-end back, they prioritize ease of renumbering much >> higher than any benefits IPv6 might bring. >> >> Because for end user networks there is no compelling reason to >> deploy IPv6 right now, nor is there likely to be one in the near >> future, we need to understand the real world needs for those >> organizations, and focus on ways to deliver them. ULA + NPTv6 does >> that, and the costs are minimal (although not non-existent, which >> is why documenting the tradeoffs is valuable). >> > > The cost is not minimal. The cost is borne not by those deploying > NPT. The cost is borne by every application developer, every security > professional, law enforcement, etc. To some extent I agree with you, but these are already sunk costs. We already have v4 NAT, and application developers who care have already solved these problems. Most of them get better with NPTv6, some of them stay the same, none of them get worse. But railing against these costs are pointless because _they are never going away_. NAT of some form will always exist, the end-to-end model is never coming back, PLEASE adjust to this reality, since not doing so actively damages the cause of IPv6 deployment. > NPT and NAT are the network equivalent of the toxic polluter model. > Sure, it's cheap to dump toxic chemicals into the creek upstream. The > true costs are borne by those downstream, not the person dumping the > chemicals. Histrionics don't help here. And saying these kinds of things to serious people who already have/like their v4 NAT makes us all look foolish, and ensures that the people you're trying to persuade will not take v6 seriously. >> Even for those end-user networks where PI space makes sense (and I >> would argue that they are few and far between) the costs, both >> monetary in terms of RIR fees, and opex; are non-zero, so >> discussing the pros _and_ cons of all the solutions will have value >> for the target audience. > > An up front $1,250 and an annual $100 is _NOT_ a significant expense > IMHO Great! I'll send you my PayPal info and you can put that amount in my account. Heck, I'll even give you a discount, say an even grand? Seriously though, When you look at the options of zero cost, vs. some non-zero cost, it's hard for most organizations to justify, especially when the reason we think they should pay it doesn't line up with their operational needs. > and that is what PI /48 costs from ARIN. I don't know about the > other RIRs. > > In terms of Opex, PI costs no more and probably somewhat less than > NPT because if it is set up correctly, it's basically fire and > forget. I'm far from a network expert, but I would think that coordinating your ISP announcing your PI block would take more effort in both setup and ongoing updates/monitoring than it would to set up NPTv6 on the border. The latter only needs to be changed/updated when you change providers. But I'm happy to concede this point to anyone who can provide solid facts. > The configuration complexity for changing providers is no > greater than that with NPT+ULA. You get the further advantage that > you can have actually redundant routers, not just redundant > connections (the NPT solution basically requires putting both > providers into a single box or REALLY complex workarounds such as > STONITH to make sure only one router sends RAs at a time). You also > get the advantage that sessions can (and usually do) survive a > failover event. In my mind the NPTv6 + ULA solution is targeted more towards those that only have a single provider in the first place. As in, the overwhelming majority of mid-size and SOHO market that makes up the majority of the enterprise end-user networks. Those who already have multiple providers should be looking at PI and multihoming, I agree with you there. Doug From owen@delong.com Sat Mar 2 15:20:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE6A21F8554 for ; Sat, 2 Mar 2013 15:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.697 X-Spam-Level: X-Spam-Status: No, score=0.697 tagged_above=-999 required=5 tests=[AWL=-2.203, BAYES_50=0.001, J_CHICKENPOX_33=0.6, MANGLED_TOOL=2.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zj3lV1HZBpz3 for ; Sat, 2 Mar 2013 15:20:57 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 2B77F21F8506 for ; Sat, 2 Mar 2013 15:20:53 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r22NJakO001451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 2 Mar 2013 15:19:36 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r22NJakO001451 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362266376; bh=vbNxN1va/xIcUcy3p/dlAI4B+9U=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=1O/oXa45u/L2Ok+2wulCTr0nNw4Faj26XF6EhP5cX/y/VLnkCh59U6SBpiET+P9LX Qkc1QVbsuwzr0n+xstu2lxI8QhhgSonQJL/Y+s6zZgQZjnh0iKA1S5cPxrTlpK5GZX W1Lhdgqjg5rIo6iX/GKnesHZTFsC0aS3fAtNYBB0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <5132726C.5040600@dougbarton.us> Date: Sat, 2 Mar 2013 15:19:28 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3B96D0EE-B19F-4770-85D0-F7C2136F0BEA@delong.com> References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 02 Mar 2013 15:19:36 -0800 (PST) Cc: v6ops@ietf.org Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 23:20:58 -0000 On Mar 2, 2013, at 13:43 , Doug Barton wrote: > On 03/02/2013 05:12 AM, Owen DeLong wrote: >>>>>=20 >>>>=20 >>>> In the case of NPTv6, I really don't think that it is. There are >>>> serious impacts to the intended nature of IPv6 if NPT starts >>>> getting widely deployed. >>>=20 >>> Yes, I get that there are a lot of people in the IPv6 literati that >>> wish for the return of the end-to-end model, and dramatically >>> resist anything that tries to take that away. The problem, as was >>> recently discussed (again) in nauseating detail on >>> ipv6-ops@lists.cluenet.de is that most organizations not only don't >>> want end-to-end back, they prioritize ease of renumbering much >>> higher than any benefits IPv6 might bring. >>>=20 >>> Because for end user networks there is no compelling reason to >>> deploy IPv6 right now, nor is there likely to be one in the near >>> future, we need to understand the real world needs for those >>> organizations, and focus on ways to deliver them. ULA + NPTv6 does >>> that, and the costs are minimal (although not non-existent, which >>> is why documenting the tradeoffs is valuable). >>>=20 >>=20 >> The cost is not minimal. The cost is borne not by those deploying >> NPT. The cost is borne by every application developer, every security >> professional, law enforcement, etc. >=20 > To some extent I agree with you, but these are already sunk costs. We = already have v4 NAT, and application developers who care have already = solved these problems. Most of them get better with NPTv6, some of them = stay the same, none of them get worse. But railing against these costs = are pointless because _they are never going away_. NAT of some form will = always exist, the end-to-end model is never coming back, PLEASE adjust = to this reality, since not doing so actively damages the cause of IPv6 = deployment. That statement shows a profound misunderstanding of the situation. Most applications haven't yet been ported to IPv6. Adding support for = IPv6 NPT and NAT traversal is _NOT_ a sunk cost. Further, the wide = variety of NATs and other oddities surrounding network behavior related = to NAT require substantial regression testing and QA for every release. = That's _NOT_ a sunk cost. It's an ongoing tax. The question is not whether NAT will exist or not, but, whether it will = remain in use by a sufficiently large mass to drive the industry. Many = of us are still holding out hope that with IPv6, it will not. It's still = possible and it's a perfectly valid reason to state in an RFC discussing = intended uses of ULA that NPT and NAT are NOT recommended in IPv6. >=20 >> NPT and NAT are the network equivalent of the toxic polluter model. >> Sure, it's cheap to dump toxic chemicals into the creek upstream. The >> true costs are borne by those downstream, not the person dumping the >> chemicals. >=20 > Histrionics don't help here. And saying these kinds of things to = serious people who already have/like their v4 NAT makes us all look = foolish, and ensures that the people you're trying to persuade will not = take v6 seriously. >=20 This isn't histrionics. It's a simple fact... Deploying NAT/NPT does, in = fact, inflict costs on others that are not borne by those deploying NAT = and those costs are not currently considered by most NAT fanatics. >>> Even for those end-user networks where PI space makes sense (and I >>> would argue that they are few and far between) the costs, both >>> monetary in terms of RIR fees, and opex; are non-zero, so >>> discussing the pros _and_ cons of all the solutions will have value >>> for the target audience. >>=20 >> An up front $1,250 and an annual $100 is _NOT_ a significant expense >> IMHO >=20 > Great! I'll send you my PayPal info and you can put that amount in my = account. Heck, I'll even give you a discount, say an even grand? >=20 Very funny. > Seriously though, When you look at the options of zero cost, vs. some = non-zero cost, it's hard for most organizations to justify, especially = when the reason we think they should pay it doesn't line up with their = operational needs. >=20 I suppose that's because you aren't considering all of the costs. ULA = isn't free. NPT isn't free. The fact that you want to pretend it is = doesn't make it so. I would bet that the annualized cost of maintaining all the extra code = and the additional security risks involved in running a network with = translation far exceed $100/year. So much so that I bet you get your = $1,250 back in less than 4 years. For most finance people, that's what = they call a no-brainer. >> and that is what PI /48 costs from ARIN. I don't know about the >> other RIRs. >>=20 >> In terms of Opex, PI costs no more and probably somewhat less than >> NPT because if it is set up correctly, it's basically fire and >> forget. >=20 > I'm far from a network expert, but I would think that coordinating = your ISP announcing your PI block would take more effort in both setup = and ongoing updates/monitoring than it would to set up NPTv6 on the = border. The latter only needs to be changed/updated when you change = providers. But I'm happy to concede this point to anyone who can provide = solid facts. >=20 It shows. On the other hand, I've got almost 30 years of experience as a = network expert and have actually done this many times. Coordinating your = ISP accepting your announcement of your block and forwarding it on = usually takes an email or two, sometimes including a form. In terms of = ongoing updates, there actually aren't usually any unless/until you = switch providers. Those are the solid facts. I'm not sure what else you want. Here's a BGP configuration from a router actually running multihomed = dual-stack connectivity to two upstream ISPs through two different = connections. It's a little bit more complex because the sessions with AS8121 are on another router = that's in a different location and it's set up to have a second peer = router at its same location which also has connections to the other remote routers (AS6939 = and AS8121), but even this more complex scenario is, as you can see = below, pretty simple. bgp { local-as 1734; group HE { type external; import from-he; family inet6 { any; } export to-he; peer-as 6939; neighbor 2001:470:1f03:9c::1; } group internal { type internal; export ibgp-next-hop-self; peer-as 1734; neighbor 2620:0:930:7000::1 { family inet6 { unicast; } export v6-next-hop-self; } neighbor 2620:0:930:7001::1 { family inet6 { unicast; } export v6-next-hop-self; } neighbor 192.124.40.193 { local-address 192.124.40.194; import via-cable; family inet { unicast; } } neighbor 192.124.40.197 { local-address 192.124.40.198; import via-dsl; family inet { unicast; } } } } >> The configuration complexity for changing providers is no >> greater than that with NPT+ULA. You get the further advantage that >> you can have actually redundant routers, not just redundant >> connections (the NPT solution basically requires putting both >> providers into a single box or REALLY complex workarounds such as >> STONITH to make sure only one router sends RAs at a time). You also >> get the advantage that sessions can (and usually do) survive a >> failover event. >=20 > In my mind the NPTv6 + ULA solution is targeted more towards those = that only have a single provider in the first place. As in, the = overwhelming majority of mid-size and SOHO market that makes up the = majority of the enterprise end-user networks. Those who already have = multiple providers should be looking at PI and multihoming, I agree with = you there. I think that's a temporary majority, frankly. The internet is becoming = too mission critical to accept single-homing for much longer in most = cases. Many of my clients are actually paying me to move them to = multi-homed connectivity and this seems to be a growing trend. Frankly, if you're single-homed, you're better off setting up your = network for easy renumbering, running static provider-assigned prefixes, = and taking a month with both prefixes present to renumber the network. = It's really not that hard in IPv6 and can be done with almost no = disruption to the users. (Yes, I've done this a couple of times for = medium-sized networks. If you plan for it in the original network design = it really can be pretty straight forward.) Owen From dougb@dougbarton.us Sat Mar 2 16:31:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7DA821F84D1 for ; Sat, 2 Mar 2013 16:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_50=0.001, J_CHICKENPOX_33=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 wiUZvuq2GREe for ; Sat, 2 Mar 2013 16:31:11 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id EB20C21F84C8 for ; Sat, 2 Mar 2013 16:31:10 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:4c85:246:97cf:cabd] (unknown [IPv6:2001:470:d:5e7:4c85:246:97cf:cabd]) by dougbarton.us (Postfix) with ESMTPSA id C9B1722B3A for ; Sun, 3 Mar 2013 00:31:10 +0000 (UTC) Message-ID: <513299CE.20509@dougbarton.us> Date: Sat, 02 Mar 2013 16:31:10 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <3B96D0EE-B19F-4770-85D0-F7C2136F0BEA@delong.com> In-Reply-To: <3B96D0EE-B19F-4770-85D0-F7C2136F0BEA@delong.com> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 00:31:11 -0000 On 03/02/2013 03:19 PM, Owen DeLong wrote: > > On Mar 2, 2013, at 13:43 , Doug Barton wrote: > >> On 03/02/2013 05:12 AM, Owen DeLong wrote: >>>>>> >>>>> >>>>> In the case of NPTv6, I really don't think that it is. There are >>>>> serious impacts to the intended nature of IPv6 if NPT starts >>>>> getting widely deployed. >>>> >>>> Yes, I get that there are a lot of people in the IPv6 literati that >>>> wish for the return of the end-to-end model, and dramatically >>>> resist anything that tries to take that away. The problem, as was >>>> recently discussed (again) in nauseating detail on >>>> ipv6-ops@lists.cluenet.de is that most organizations not only don't >>>> want end-to-end back, they prioritize ease of renumbering much >>>> higher than any benefits IPv6 might bring. >>>> >>>> Because for end user networks there is no compelling reason to >>>> deploy IPv6 right now, nor is there likely to be one in the near >>>> future, we need to understand the real world needs for those >>>> organizations, and focus on ways to deliver them. ULA + NPTv6 does >>>> that, and the costs are minimal (although not non-existent, which >>>> is why documenting the tradeoffs is valuable). >>>> >>> >>> The cost is not minimal. The cost is borne not by those deploying >>> NPT. The cost is borne by every application developer, every security >>> professional, law enforcement, etc. >> >> To some extent I agree with you, but these are already sunk costs. We already have v4 NAT, and application developers who care have already solved these problems. Most of them get better with NPTv6, some of them stay the same, none of them get worse. But railing against these costs are pointless because _they are never going away_. NAT of some form will always exist, the end-to-end model is never coming back, PLEASE adjust to this reality, since not doing so actively damages the cause of IPv6 deployment. > > That statement shows a profound misunderstanding of the situation. > > Most applications haven't yet been ported to IPv6. Adding support for IPv6 NPT and NAT traversal is _NOT_ a sunk cost. Further, the wide variety of NATs and other oddities surrounding network behavior related to NAT require substantial regression testing and QA for every release. That's _NOT_ a sunk cost. It's an ongoing tax. Assuming you are right about all of this (which to some extent you are, but for sake of argument let's say you're 100% right) it still doesn't matter. Adding NPTv6 support is in the statistical noise from a development perspective. Well-written applications need little or no additional development work to support IPv6, poorly written ones will need to be updated, but that's going to be true regardless, and adding NPT support is still going to be a small marginal cost. The ongoing "tax" you refer to is going to be paid regardless, because v4 NAT is never, ever going away; and we're 20-30 years away from v4 support being a thing of the past. > The question is not whether NAT will exist or not, but, whether it will remain in use by a sufficiently large mass to drive the industry. Many of us are still holding out hope that with IPv6, it will not. It's still possible and it's a perfectly valid reason to state in an RFC discussing intended uses of ULA that NPT and NAT are NOT recommended in IPv6. Yes, I understand your position thoroughly. My point is that "not recommended" is at best pollyanish, and at worst counter productive. OTOH, a fair, rational discussion of the tradeoffs is beneficial to all concerned. >>> NPT and NAT are the network equivalent of the toxic polluter model. >>> Sure, it's cheap to dump toxic chemicals into the creek upstream. The >>> true costs are borne by those downstream, not the person dumping the >>> chemicals. >> >> Histrionics don't help here. And saying these kinds of things to serious people who already have/like their v4 NAT makes us all look foolish, and ensures that the people you're trying to persuade will not take v6 seriously. >> > > This isn't histrionics. It's a simple fact... Deploying NAT/NPT does, in fact, inflict costs on others that are not borne by those deploying NAT and those costs are not currently considered by most NAT fanatics. "Toxic waste" analogies are histrionic by definition. And even if I fully agreed with your arguments about how bad NAT is, telling people that use/like it that they are the network equivalent to toxic waste dumpers is not only not helping, it's hurting. >>>> Even for those end-user networks where PI space makes sense (and I >>>> would argue that they are few and far between) the costs, both >>>> monetary in terms of RIR fees, and opex; are non-zero, so >>>> discussing the pros _and_ cons of all the solutions will have value >>>> for the target audience. >>> >>> An up front $1,250 and an annual $100 is _NOT_ a significant expense >>> IMHO >> >> Great! I'll send you my PayPal info and you can put that amount in my account. Heck, I'll even give you a discount, say an even grand? >> > > Very funny. So what you're saying is that you would consider sending me $1,000 to be a not-insignificant expense? >> Seriously though, When you look at the options of zero cost, vs. some non-zero cost, it's hard for most organizations to justify, especially when the reason we think they should pay it doesn't line up with their operational needs. >> > > I suppose that's because you aren't considering all of the costs. ULA isn't free. NPT isn't free. The fact that you want to pretend it is doesn't make it so. I'm not saying it's free, I'm saying "Let's rationally discuss the tradeoffs." It is unarguably true that ULA does not require an RIR fee, but putting down the other costs in writing will help people to make up their minds about which costs they are willing to bear. > I would bet that the annualized cost of maintaining all the extra code and the additional security risks involved in running a network with translation far exceed $100/year. So much so that I bet you get your $1,250 back in less than 4 years. For most finance people, that's what they call a no-brainer. ... except for my now-oft-repeated point that those costs are never going to go away. Not to mention that most enterprise end-user networks are not in the business of code development, so your concern doesn't apply to them. >>> and that is what PI /48 costs from ARIN. I don't know about the >>> other RIRs. >>> >>> In terms of Opex, PI costs no more and probably somewhat less than >>> NPT because if it is set up correctly, it's basically fire and >>> forget. >> >> I'm far from a network expert, but I would think that coordinating your ISP announcing your PI block would take more effort in both setup and ongoing updates/monitoring than it would to set up NPTv6 on the border. The latter only needs to be changed/updated when you change providers. But I'm happy to concede this point to anyone who can provide solid facts. >> > > It shows. On the other hand, I've got almost 30 years of experience as a network expert and have actually done this many times. Coordinating your ISP accepting your announcement of your block and forwarding it on usually takes an email or two, sometimes including a form. In terms of ongoing updates, there actually aren't usually any unless/until you switch providers. > > Those are the solid facts. I'm not sure what else you want. So ISPs never reconfigure routers, BGP sessions never flap, nothing ever happens with this kind of configuration that needs ongoing monitoring and updates? >>> The configuration complexity for changing providers is no >>> greater than that with NPT+ULA. You get the further advantage that >>> you can have actually redundant routers, not just redundant >>> connections (the NPT solution basically requires putting both >>> providers into a single box or REALLY complex workarounds such as >>> STONITH to make sure only one router sends RAs at a time). You also >>> get the advantage that sessions can (and usually do) survive a >>> failover event. >> >> In my mind the NPTv6 + ULA solution is targeted more towards those that only have a single provider in the first place. As in, the overwhelming majority of mid-size and SOHO market that makes up the majority of the enterprise end-user networks. Those who already have multiple providers should be looking at PI and multihoming, I agree with you there. > > I think that's a temporary majority, frankly. The internet is becoming too mission critical to accept single-homing for much longer in most cases. Many of my clients are actually paying me to move them to multi-homed connectivity and this seems to be a growing trend. No argument there, but your sample is severely corrupted by volunteer bias. The number of small-medium enterprises who could not even spell "multihomed" is pretty vast. > Frankly, if you're single-homed, you're better off setting up your network for easy renumbering, running static provider-assigned prefixes, and taking a month with both prefixes present to renumber the network. It's really not that hard in IPv6 and can be done with almost no disruption to the users. (Yes, I've done this a couple of times for medium-sized networks. If you plan for it in the original network design it really can be pretty straight forward.) Again, for those that actually are, or will be multihomed we're in agreement. My argument is for the overwhelming majority of small-medium enterprises who will not ever be multihomed. The perceived benefits of v4 NAT, especially no need to ever renumber, are much more important than anything v6 can provide them. They don't want the end-to-end model back, no matter how much some of us think they should. Doug From owen@delong.com Sun Mar 3 01:30:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2088421F856F for ; Sun, 3 Mar 2013 01:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[AWL=-1.088, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001, SARE_SPEC_LEO_LINE03a=0.408] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYk9rxAxb68H for ; Sun, 3 Mar 2013 01:30:52 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 20E8721F84FF for ; Sun, 3 Mar 2013 01:30:52 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r239SrPp026448 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 3 Mar 2013 01:28:54 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r239SrPp026448 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362302934; bh=8Ak5Q7A8EmLZxExEabTPZ05RPqs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=LrW/OBvU33e0yQSXPWmjuoYbIajv+ip4+BEVgqP6ukQdRXc5zYo28GX5CJxK/H7pz 4PcIaRKELx1AyCCHPX3ynzRjKeBrBvEhzlonVCu/X1lRWlfDwS9s3QF0gzIuETdBME fJG2cFMZEb3HG4MPA1uUnVwhwnElOXJ75T4rwfGM= Content-Type: multipart/alternative; boundary="Apple-Mail=_5B77DE3E-6C06-4C6D-AC40-F204C17AAE56" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <513299CE.20509@dougbarton.us> Date: Sun, 3 Mar 2013 01:28:47 -0800 Message-Id: <1364B842-D3BE-48C1-A2A5-3D74DC37DB4A@delong.com> References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <3B96D0EE-B19F-4770-85D0-F7C2136F0BEA@delong.com> <513299CE.20509@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sun, 03 Mar 2013 01:28:54 -0800 (PST) Cc: v6ops@ietf.org Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 09:30:54 -0000 --Apple-Mail=_5B77DE3E-6C06-4C6D-AC40-F204C17AAE56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> That statement shows a profound misunderstanding of the situation. >>=20 >> Most applications haven't yet been ported to IPv6. Adding support for = IPv6 NPT and NAT traversal is _NOT_ a sunk cost. Further, the wide = variety of NATs and other oddities surrounding network behavior related = to NAT require substantial regression testing and QA for every release. = That's _NOT_ a sunk cost. It's an ongoing tax. >=20 > Assuming you are right about all of this (which to some extent you = are, but for sake of argument let's say you're 100% right) it still = doesn't matter. Adding NPTv6 support is in the statistical noise from a = development perspective. Well-written applications need little or no = additional development work to support IPv6, poorly written ones will = need to be updated, but that's going to be true regardless, and adding = NPT support is still going to be a small marginal cost. Again, I cannot agree with you here. Your attempt to classify any = application that wants to be talking end-to-end without having its = packets mutilated along the way as "poorly written" simply doesn't hold = water. There are lots f reasons to want to be able to communicate = (reasonably) directly and not all of them involve including layer 3 = addressing as layer 7 payload (which I believe is what you actually = intended to target). Consider, for example, the desire to host some sort of collaborative = process on a desktop machine without requiring a third-party rendezvous = server. That's not a poorly written application, it's a perfectly valid = one which requires that the host machine have an accessible global = address. Sure, some enterprises may want to block such activities and they can do = that perfectly well through policy and stateful inspection. No need for = NPT and NPT brings no benefit to that process. > The ongoing "tax" you refer to is going to be paid regardless, because = v4 NAT is never, ever going away; and we're 20-30 years away from v4 = support being a thing of the past. I disagree. I think IPv4 will drop into the noise much faster than you = expect because it will become so completely expensive to maintain that = nobody will want to touch it. >=20 >> The question is not whether NAT will exist or not, but, whether it = will remain in use by a sufficiently large mass to drive the industry. = Many of us are still holding out hope that with IPv6, it will not. It's = still possible and it's a perfectly valid reason to state in an RFC = discussing intended uses of ULA that NPT and NAT are NOT recommended in = IPv6. >=20 > Yes, I understand your position thoroughly. My point is that "not = recommended" is at best pollyanish, and at worst counter productive. = OTOH, a fair, rational discussion of the tradeoffs is beneficial to all = concerned. I'm all for a fair rational discussion of the tradeoffs. However, I = think it is reasonable and prudent at the end of that discussion to = include the conclusion that damaging the protocol in such a manner is = not recommended. >=20 >>>> NPT and NAT are the network equivalent of the toxic polluter model. >>>> Sure, it's cheap to dump toxic chemicals into the creek upstream. = The >>>> true costs are borne by those downstream, not the person dumping = the >>>> chemicals. >>>=20 >>> Histrionics don't help here. And saying these kinds of things to = serious people who already have/like their v4 NAT makes us all look = foolish, and ensures that the people you're trying to persuade will not = take v6 seriously. >>>=20 >>=20 >> This isn't histrionics. It's a simple fact... Deploying NAT/NPT does, = in fact, inflict costs on others that are not borne by those deploying = NAT and those costs are not currently considered by most NAT fanatics. >=20 > "Toxic waste" analogies are histrionic by definition. And even if I = fully agreed with your arguments about how bad NAT is, telling people = that use/like it that they are the network equivalent to toxic waste = dumpers is not only not helping, it's hurting. =46rom webseter: Definition of HISTRIONICS 1 : theatrical performances 2 : deliberate display of emotion for effect I don't think it qualifies as a theatrical performance. It wasn't a display of emotion, it was a simple analogy about who pays = the true cost. >>>>> Even for those end-user networks where PI space makes sense (and I >>>>> would argue that they are few and far between) the costs, both >>>>> monetary in terms of RIR fees, and opex; are non-zero, so >>>>> discussing the pros _and_ cons of all the solutions will have = value >>>>> for the target audience. >>>>=20 >>>> An up front $1,250 and an annual $100 is _NOT_ a significant = expense >>>> IMHO >>>=20 >>> Great! I'll send you my PayPal info and you can put that amount in = my account. Heck, I'll even give you a discount, say an even grand? >>>=20 >>=20 >> Very funny. >=20 > So what you're saying is that you would consider sending me $1,000 to = be a not-insignificant expense? >=20 No, what I'm saying is that I had no problem paying for my PI assignment = and I cannot imagine an actual business operation that wants to be = multihomed finding it difficult to cover the minimal expenses involved = in obtaining addresses to do so. Given the number of different things involved in just creating a = business that cost more than that, I don't find it a very credible = argument. >>> Seriously though, When you look at the options of zero cost, vs. = some non-zero cost, it's hard for most organizations to justify, = especially when the reason we think they should pay it doesn't line up = with their operational needs. >>>=20 >>=20 >> I suppose that's because you aren't considering all of the costs. ULA = isn't free. NPT isn't free. The fact that you want to pretend it is = doesn't make it so. >=20 > I'm not saying it's free, I'm saying "Let's rationally discuss the = tradeoffs." It is unarguably true that ULA does not require an RIR fee, = but putting down the other costs in writing will help people to make up = their minds about which costs they are willing to bear. Your quote (still present above) states "zero cost". That's the same as = 'free" by most people's definition, so yes, you did say it was free. = It's in your quote above. A rational discussion of the tradeoffs has to include the real costs, = regardless of who bears them. People who like/want NAT like/want it = because it allows them to dump the cost burden on others. Admittedly, = many of them do not realize that they are doing so, just like there was = a time when people didn't realize the impact that dumping stuff in the = oceans was having. >=20 >> I would bet that the annualized cost of maintaining all the extra = code and the additional security risks involved in running a network = with translation far exceed $100/year. So much so that I bet you get = your $1,250 back in less than 4 years. For most finance people, that's = what they call a no-brainer. >=20 > ... except for my now-oft-repeated point that those costs are never = going to go away. Not to mention that most enterprise end-user networks = are not in the business of code development, so your concern doesn't = apply to them. Yes, you keep repeating this, but it isn't true and repeating it doesn't = make it true just because you want it to be true. I already agreed with you about the last part... In fact, that's the = part that lines up with the toxic polluter as an analogy, not = histrionics. Unfortunately, you were too caught up in dismissing what I = was saying as histrionics to actually look at the metaphor. >>>> and that is what PI /48 costs from ARIN. I don't know about the >>>> other RIRs. >>>>=20 >>>> In terms of Opex, PI costs no more and probably somewhat less than >>>> NPT because if it is set up correctly, it's basically fire and >>>> forget. >>>=20 >>> I'm far from a network expert, but I would think that coordinating = your ISP announcing your PI block would take more effort in both setup = and ongoing updates/monitoring than it would to set up NPTv6 on the = border. The latter only needs to be changed/updated when you change = providers. But I'm happy to concede this point to anyone who can provide = solid facts. >>>=20 >>=20 >> It shows. On the other hand, I've got almost 30 years of experience = as a network expert and have actually done this many times. Coordinating = your ISP accepting your announcement of your block and forwarding it on = usually takes an email or two, sometimes including a form. In terms of = ongoing updates, there actually aren't usually any unless/until you = switch providers. >>=20 >> Those are the solid facts. I'm not sure what else you want. >=20 > So ISPs never reconfigure routers, BGP sessions never flap, nothing = ever happens with this kind of configuration that needs ongoing = monitoring and updates? Monitoring, yes. As to configuration changes, very very rarely. ISPs = don't like to make customer effecting changes. They take a lot of time = and coordination and they are very expensive. They also tend to make = customers unhappy. As such, we try to avoid them whenever possible. A = BGP session flap doesn't require a configuration change, it requires = fixing the problem. If the configuration on the router worked last week = and it doesn't work this week, the configuration on the router isn't the = thing that changed, so the question is what did. If the ISP changed = their configuration, then you may need to change the local = configuration, but that's going to rarely be the case. More often, you = need to do one of the following: 1. Get the circuit fixed. (most common problem) 2. Get the ISP to fix whatever they accidentally changed on = their side. 3. Investigate a more unusual problem in more detail before = taking any action. In case 3, that's not any more or less likely to happen with a BGP = session than it is with a static routed session going through NAT/NPT = and it's not any more difficult to debug/troubleshoot. In fact, since = you don't have to trace things through state tables and address = mutilations in the headers, it's usually quite a bit easier. As an example, think the last time I changed the BGP configuration I = included was about 3.5 years ago. >>>> The configuration complexity for changing providers is no >>>> greater than that with NPT+ULA. You get the further advantage that >>>> you can have actually redundant routers, not just redundant >>>> connections (the NPT solution basically requires putting both >>>> providers into a single box or REALLY complex workarounds such as >>>> STONITH to make sure only one router sends RAs at a time). You = also >>>> get the advantage that sessions can (and usually do) survive a >>>> failover event. >>>=20 >>> In my mind the NPTv6 + ULA solution is targeted more towards those = that only have a single provider in the first place. As in, the = overwhelming majority of mid-size and SOHO market that makes up the = majority of the enterprise end-user networks. Those who already have = multiple providers should be looking at PI and multihoming, I agree with = you there. >>=20 >> I think that's a temporary majority, frankly. The internet is = becoming too mission critical to accept single-homing for much longer in = most cases. Many of my clients are actually paying me to move them to = multi-homed connectivity and this seems to be a growing trend. >=20 > No argument there, but your sample is severely corrupted by volunteer = bias. The number of small-medium enterprises who could not even spell = "multihomed" is pretty vast. Today, that's true. However, the number that can say "Hey, Mr. IT = consultant, our internet isn't reliable enough and when its down, our = credit card processor doesn't work any more. Is there any way we can get = a more reliable internet connection?" is not nearly so limiting. If "Mr. = IT Consultant" has half a brain, he figures out how to get them = multi-homed. If he doesn't, then he's one of those guys that gives the = rest of us a bad name. >> Frankly, if you're single-homed, you're better off setting up your = network for easy renumbering, running static provider-assigned prefixes, = and taking a month with both prefixes present to renumber the network. = It's really not that hard in IPv6 and can be done with almost no = disruption to the users. (Yes, I've done this a couple of times for = medium-sized networks. If you plan for it in the original network design = it really can be pretty straight forward.) >=20 > Again, for those that actually are, or will be multihomed we're in = agreement. My argument is for the overwhelming majority of small-medium = enterprises who will not ever be multihomed. The perceived benefits of = v4 NAT, especially no need to ever renumber, are much more important = than anything v6 can provide them. They don't want the end-to-end model = back, no matter how much some of us think they should. That's because those people largely don't know how much easier it is to = renumber in IPv6. Seriously, renumbering (especially prefix-only = renumbering) can be done for the average SME over the course of about a = month without significant disruption and without even requiring all that = many man hours in the process. It's not like IPv4. That part did = actually get mostly fixed in IPv6. Owen --Apple-Mail=_5B77DE3E-6C06-4C6D-AC40-F204C17AAE56 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
That = statement shows a profound misunderstanding of the = situation.

Most applications haven't yet been ported to IPv6. = Adding support for IPv6 NPT and NAT traversal is _NOT_ a sunk cost. = Further, the wide variety of NATs and other oddities surrounding network = behavior related to NAT require substantial regression testing and QA = for every release. That's _NOT_ a sunk cost. It's an ongoing = tax.

Assuming you are right about all of this (which = to some extent you are, but for sake of argument let's say you're 100% = right) it still doesn't matter. Adding NPTv6 support is in the = statistical noise from a development perspective. Well-written = applications need little or no additional development work to support = IPv6, poorly written ones will need to be updated, but that's going to = be true regardless, and adding NPT support is still going to be a small = marginal cost.

Again, I cannot agree with = you here. Your attempt to classify any application that wants to be = talking end-to-end without having its packets mutilated along the way as = "poorly written" simply doesn't hold water. There are lots f reasons to = want to be able to communicate (reasonably) directly and not all of them = involve including layer 3 addressing as layer 7 payload (which I believe = is what you actually intended to = target).

Consider, for example, the desire to = host some sort of collaborative process on a desktop machine without = requiring a third-party rendezvous server. That's not a poorly written = application, it's a perfectly valid one which requires that the host = machine have an accessible global = address.

Sure, some enterprises may want to = block such activities and they can do that perfectly well through policy = and stateful inspection. No need for NPT and NPT brings no benefit to = that process.

The = ongoing "tax" you refer to is going to be paid regardless, because v4 = NAT is never, ever going away; and we're 20-30 years away from v4 = support being a thing of the past.

I = disagree. I think IPv4 will drop into the noise much faster than you = expect because it will become so completely expensive to maintain that = nobody will want to touch it.


The question is not whether = NAT will exist or not, but, whether it will remain in use by a = sufficiently large mass to drive the industry. Many of us are still = holding out hope that with IPv6, it will not. It's still possible and = it's a perfectly valid reason to state in an RFC discussing intended = uses of ULA that NPT and NAT are NOT recommended in = IPv6.

Yes, I understand your position thoroughly. My = point is that "not recommended" is at best pollyanish, and at worst = counter productive. OTOH, a fair, rational discussion of the tradeoffs = is beneficial to all concerned.

I'm all = for a fair rational discussion of the tradeoffs. However, I think it is = reasonable and prudent at the end of that discussion to include the = conclusion that damaging the protocol in such a manner is not = recommended.


NPT = and NAT are the network equivalent of the toxic polluter model.
Sure, = it's cheap to dump toxic chemicals into the creek upstream. The
true = costs are borne by those downstream, not the person dumping = the
chemicals.

Histrionics don't help here. And = saying these kinds of things to serious people who already have/like = their v4 NAT makes us all look foolish, and ensures that the people = you're trying to persuade will not take v6 = seriously.


This isn't histrionics. It's a simple = fact... Deploying NAT/NPT does, in fact, inflict costs on others that = are not borne by those deploying NAT and those costs are not currently = considered by most NAT fanatics.

"Toxic waste" = analogies are histrionic by definition. And even if I fully agreed with = your arguments about how bad NAT is, telling people that use/like it = that they are the network equivalent to toxic waste dumpers is not only = not helping, it's hurting.

=46rom = webseter:

Definition of 
1
: theatrical = performances

: deliberate display = of emotion for effect

I don't think it = qualifies as a theatrical performance.
It wasn't a display of = emotion, it was a simple analogy about who pays the true = cost.

Even for those end-user networks = where PI space makes sense (and I
would argue that they are few and = far between) the costs, both
monetary in terms of RIR fees, and opex; = are non-zero, so
discussing the pros _and_ cons of all the solutions = will have value
for the target audience.

An up = front $1,250 and an annual $100 is _NOT_ a significant = expense
IMHO

Great! I'll send you my PayPal info = and you can put that amount in my account. Heck, I'll even give you a = discount, say an even grand?


Very = funny.

So what you're saying is that you would = consider sending me $1,000 to be a not-insignificant = expense?


No, what I'm saying is that = I had no problem paying for my PI assignment and I cannot imagine an = actual business operation that wants to be multihomed finding it = difficult to cover the minimal expenses involved in obtaining addresses = to do so.

Given the number of different things = involved in just creating a business that cost more than that, I don't = find it a very credible argument.

Seriously though, When you look at the options of zero = cost, vs. some non-zero cost, it's hard for most organizations to = justify, especially when the reason we think they should pay it doesn't = line up with their operational needs.


I suppose = that's because you aren't considering all of the costs. ULA isn't free. = NPT isn't free. The fact that you want to pretend it is doesn't make it = so.

I'm not saying it's free, I'm saying "Let's = rationally discuss the tradeoffs." It is unarguably true that ULA does = not require an RIR fee, but putting down the other costs in writing will = help people to make up their minds about which costs they are willing to = bear.

Your quote (still present above) = states "zero cost". That's the same as 'free" by most people's = definition, so yes, you did say it was free. It's in your quote = above.

A rational discussion of the tradeoffs = has to include the real costs, regardless of who bears them. People who = like/want NAT like/want it because it allows them to dump the cost = burden on others. Admittedly, many of them do not realize that they are = doing so, just like there was a time when people didn't realize the = impact that dumping stuff in the oceans was = having.


I would bet that the annualized cost of maintaining all = the extra code and the additional security risks involved in running a = network with translation far exceed $100/year. So much so that I bet you = get your $1,250 back in less than 4 years.  For most finance = people, that's what they call a no-brainer.

... = except for my now-oft-repeated point that those costs are never going to = go away. Not to mention that most enterprise end-user networks are not = in the business of code development, so your concern doesn't apply to = them.

Yes, you keep repeating this, but = it isn't true and repeating it doesn't make it true just because you = want it to be true.

I already agreed with you = about the last part... In fact, that's the part that lines up with the = toxic polluter as an analogy, not histrionics. Unfortunately, you were = too caught up in dismissing what I was saying as histrionics to actually = look at the metaphor.

and = that is what PI  /48 costs from ARIN. I don't know about = the
other RIRs.

In terms of Opex, PI costs no more and = probably somewhat less than
NPT because if it is set up correctly, = it's basically fire and
forget.

I'm far from a = network expert, but I would think that coordinating your ISP announcing = your PI block would take more effort in both setup and ongoing = updates/monitoring than it would to set up NPTv6 on the border. The = latter only needs to be changed/updated when you change providers. But = I'm happy to concede this point to anyone who can provide solid = facts.


It shows. On the other hand, I've got = almost 30 years of experience as a network expert and have actually done = this many times. Coordinating your ISP accepting your announcement of = your block and forwarding it on usually takes an email or two, sometimes = including a form. In terms of ongoing updates, there actually aren't = usually any unless/until you switch providers.

Those are the = solid facts. I'm not sure what else you want.

So = ISPs never reconfigure routers, BGP sessions never flap, nothing ever = happens with this kind of configuration that needs ongoing monitoring = and updates?

Monitoring, yes. As to = configuration changes, very very rarely. ISPs don't like to make = customer effecting changes. They take a lot of time and coordination and = they are very expensive. They also tend to make customers unhappy. As = such, we try to avoid them whenever possible. A BGP session flap doesn't = require a configuration change, it requires fixing the problem. If the = configuration on the router worked last week and it doesn't work this = week, the configuration on the router isn't the thing that changed, so = the question is what did. If the ISP changed their configuration, then = you may need to change the local configuration, but that's going to = rarely be the case. More often, you need to do one of the = following:

1. Get the circuit fixed. (most = common problem)
2. Get the ISP to fix whatever they = accidentally changed on their side.
3. = Investigate a more unusual problem in more detail before taking = any action.

In case 3, that's not any more or = less likely to happen with a BGP session than it is with a static routed = session going through NAT/NPT and it's not any more difficult to = debug/troubleshoot. In fact, since you don't have to trace things = through state tables and address mutilations in the headers, it's = usually quite a bit easier.

As an example, =  think the last time I changed the BGP configuration I included was = about 3.5 years ago.

The configuration complexity for = changing providers is no
greater than that with NPT+ULA. You get the = further advantage that
you can have actually redundant routers, not = just redundant
connections (the NPT solution basically requires = putting both
providers into a single box or REALLY complex = workarounds such as
STONITH to make sure only one router sends RAs at = a time).  You also
get the advantage that sessions can (and = usually do) survive a
failover event.

In my mind = the NPTv6 + ULA solution is targeted more towards those that only have a = single provider in the first place. As in, the overwhelming majority of = mid-size and SOHO market that makes up the majority of the enterprise = end-user networks. Those who already have multiple providers should be = looking at PI and multihoming, I agree with you = there.

I think that's a temporary majority, frankly. = The internet is becoming too mission critical to accept single-homing = for much longer in most cases. Many of my clients are actually paying me = to move them to multi-homed connectivity and this seems to be a growing = trend.

No argument there, but your sample is = severely corrupted by volunteer bias. The number of small-medium = enterprises who could not even spell "multihomed" is pretty = vast.

Today, that's true. However, the = number that can say "Hey, Mr. IT consultant, our internet isn't reliable = enough and when its down, our credit card processor doesn't work any = more. Is there any way we can get a more reliable internet connection?" = is not nearly so limiting. If "Mr. IT Consultant" has half a brain, he = figures out how to get them multi-homed. If he doesn't, then he's one of = those guys that gives the rest of us a bad = name.

Frankly, if you're single-homed, you're better off setting = up your network for easy renumbering, running static provider-assigned = prefixes, and taking a month with both prefixes present to renumber the = network. It's really not that hard in IPv6 and can be done with almost = no disruption to the users. (Yes, I've done this a couple of times for = medium-sized networks. If you plan for it in the original network design = it really can be pretty straight forward.)

Again, = for those that actually are, or will be multihomed we're in agreement. = My argument is for the overwhelming majority of small-medium enterprises = who will not ever be multihomed. The perceived benefits of v4 NAT, = especially no need to ever renumber, are much more important than = anything v6 can provide them. They don't want the end-to-end model back, = no matter how much some of us think they = should.

That's because those people = largely don't know how much easier it is to renumber in IPv6. Seriously, = renumbering (especially prefix-only renumbering) can be done for the = average SME over the course of about a month without significant = disruption and without even requiring all that many man hours in the = process. It's not like IPv4. That part did actually get mostly fixed in = IPv6.

Owen

= --Apple-Mail=_5B77DE3E-6C06-4C6D-AC40-F204C17AAE56-- From gert@space.net Sun Mar 3 05:06:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FD821F84E9 for ; Sun, 3 Mar 2013 05:06:21 -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 5voGV1cX7INI for ; Sun, 3 Mar 2013 05:06:16 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 5962821F86FA for ; Sun, 3 Mar 2013 05:06:13 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 0EA646038E for ; Sun, 3 Mar 2013 14:06:12 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id EB00C6028F for ; Sun, 3 Mar 2013 14:06:11 +0100 (CET) Received: (qmail 91224 invoked by uid 1007); 3 Mar 2013 14:06:11 +0100 Date: Sun, 3 Mar 2013 14:06:11 +0100 From: Gert Doering To: Owen DeLong Message-ID: <20130303130611.GF51699@Space.Net> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <3B96D0EE-B19F-4770-85D0-F7C2136F0BEA@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B96D0EE-B19F-4770-85D0-F7C2136F0BEA@delong.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 13:06:21 -0000 Hi, On Sat, Mar 02, 2013 at 03:19:28PM -0800, Owen DeLong wrote: > It shows. On the other hand, I've got almost 30 years of experience as a network expert and have actually done this many times. Coordinating your ISP accepting your announcement of your block and forwarding it on usually takes an email or two, sometimes including a form. In terms of ongoing updates, there actually aren't usually any unless/until you switch providers. > > Those are the solid facts. I'm not sure what else you want. Please get back a bit closer to reality... Ever tried setting up a BGP session with comcast cable or verizon LTE? Most lower-budget ISP connections will not come with the option to run BGP there - over here, the difference is somewhere between "30 EUR a month for a 16 Mbit ADSL line with a PA /56 assigned to it" and "starting at 100 EUR/month for the same line, but with BGP routing". BGP isn't free on the provider side - all the mass-market (=cost-saving) provisioning tools won't really help you, as there are lots of steps that need to be done and verified for every new customer. Yes, much of this can be automated (and usually is), but it's still much more effort than "not doing BGP". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From joelja@bogus.com Sun Mar 3 07:47:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF6921F8718 for ; Sun, 3 Mar 2013 07:47:28 -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 s2WAlMEEzdmE for ; Sun, 3 Mar 2013 07:47:27 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id A95FE21F8715 for ; Sun, 3 Mar 2013 07:47:27 -0800 (PST) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r23FlCgx097483 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 3 Mar 2013 15:47:13 GMT (envelope-from joelja@bogus.com) Message-ID: <5133709E.6060806@bogus.com> Date: Sun, 03 Mar 2013 07:47:42 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Gert Doering , Owen DeLong References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <3B96D0EE-B19F-4770-85D0-F7C2136F0BEA@delong.com> <20130303130611.GF51699@Space.Net> In-Reply-To: <20130303130611.GF51699@Space.Net> 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]); Sun, 03 Mar 2013 15:47:14 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 15:47:29 -0000 On 3/3/13 5:06 AM, Gert Doering wrote: > Hi, > > On Sat, Mar 02, 2013 at 03:19:28PM -0800, Owen DeLong wrote: >> It shows. On the other hand, I've got almost 30 years of experience as a network expert and have actually done this many times. Coordinating your ISP accepting your announcement of your block and forwarding it on usually takes an email or two, sometimes including a form. In terms of ongoing updates, there actually aren't usually any unless/until you switch providers. >> >> Those are the solid facts. I'm not sure what else you want. > Please get back a bit closer to reality... > > Ever tried setting up a BGP session with comcast cable or verizon LTE? > > Most lower-budget ISP connections will not come with the option to run > BGP there - over here, the difference is somewhere between "30 EUR a > month for a 16 Mbit ADSL line with a PA /56 assigned to it" and > "starting at 100 EUR/month for the same line, but with BGP routing". > > BGP isn't free on the provider side - all the mass-market (=cost-saving) > provisioning tools won't really help you, as there are lots of steps > that need to be done and verified for every new customer. Yes, much of > this can be automated (and usually is), but it's still much more effort > than "not doing BGP". Bgp peering with your providers is a comparatively high-touch service for an ISP. The price is structured accordingly particularly at retail volumes. wholesale transit customers enjoy large encomies of scale on pricing. Customer aggregation routers in retail ISPs (or datacenters) frequently don't need to carry a full table, consequently they are much cheaper, but also they can't provide you with one. That can be done therefore with a multihop bgp session from a device which can, with all the attendant considerations that entails. > Gert Doering > -- NetMaster From cb.list6@gmail.com Sun Mar 3 09:10:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE1021F8756 for ; Sun, 3 Mar 2013 09:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.487 X-Spam-Level: X-Spam-Status: No, score=-0.487 tagged_above=-999 required=5 tests=[AWL=-1.688, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HnKF4hQHa0x for ; Sun, 3 Mar 2013 09:10:06 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 68F6A21F8715 for ; Sun, 3 Mar 2013 09:09:57 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id u54so3902203wey.30 for ; Sun, 03 Mar 2013 09:09:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lzlGya0l22mou1FQ/RBOcuRIUyUPOtlTpSpliGGZYuo=; b=gLO5t9w5cDCifrdwJqo1g/Lh1e9zp3elxY3mMBIgq04WoXidHLWYT9dU6UM0mIudIT EPXOcvaognTkKYCod3yYpFd1fd0ceo6hob2mu+q/U6YT5IhFBclrN8BdZ+SSW8qCp19B z1PbcT/3FiCSoD3xyNYoi2tSnKvIGfglehKUczkVm21E6jquJ2mwQPMSaVPX/FbEDZvK MwRErbi3OvrA8zs+S4Q/YPK19foABwaaW1wmMYRTbbAkJ6Vuj+hxchCwmQ3rmJZBerU1 Ul/DWHR9smgIwddqxSwvUhe2S7O9XQuf9psw6azIJ5kkV+HRIB7xurGdaf1IEI3TE9TR b/SA== MIME-Version: 1.0 X-Received: by 10.180.75.143 with SMTP id c15mr7250736wiw.18.1362330596698; Sun, 03 Mar 2013 09:09:56 -0800 (PST) Received: by 10.194.20.35 with HTTP; Sun, 3 Mar 2013 09:09:56 -0800 (PST) Received: by 10.194.20.35 with HTTP; Sun, 3 Mar 2013 09:09:56 -0800 (PST) In-Reply-To: <5132726C.5040600@dougbarton.us> References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> Date: Sun, 3 Mar 2013 09:09:56 -0800 Message-ID: From: Cameron Byrne To: Doug Barton Content-Type: multipart/alternative; boundary=f46d0438955548778e04d7084f69 Cc: IPv6 Ops WG Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 17:10:07 -0000 --f46d0438955548778e04d7084f69 Content-Type: text/plain; charset=ISO-8859-1 On Mar 2, 2013 1:43 PM, "Doug Barton" wrote: > > On 03/02/2013 05:12 AM, Owen DeLong wrote: >>>>> >>>>> >>>> >>>> In the case of NPTv6, I really don't think that it is. There are >>>> serious impacts to the intended nature of IPv6 if NPT starts >>>> getting widely deployed. >>> >>> >>> Yes, I get that there are a lot of people in the IPv6 literati that >>> wish for the return of the end-to-end model, and dramatically >>> resist anything that tries to take that away. The problem, as was >>> recently discussed (again) in nauseating detail on >>> ipv6-ops@lists.cluenet.de is that most organizations not only don't >>> want end-to-end back, they prioritize ease of renumbering much >>> higher than any benefits IPv6 might bring. >>> >>> Because for end user networks there is no compelling reason to >>> deploy IPv6 right now, nor is there likely to be one in the near >>> future, we need to understand the real world needs for those >>> organizations, and focus on ways to deliver them. ULA + NPTv6 does >>> that, and the costs are minimal (although not non-existent, which >>> is why documenting the tradeoffs is valuable). >>> >> >> The cost is not minimal. The cost is borne not by those deploying >> NPT. The cost is borne by every application developer, every security >> professional, law enforcement, etc. > > > To some extent I agree with you, but these are already sunk costs. We already have v4 NAT, and application developers who care have already solved these problems. Most of them get better with NPTv6, some of them stay the same, none of them get worse. But railing against these costs are pointless because _they are never going away_. NAT of some form will always exist, the end-to-end model is never coming back, PLEASE adjust to this reality, since not doing so actively damages the cause of IPv6 deployment. > Doug Afaik, the ietf is fundamentally committed to the e2e model. The ietf structure allows for revisiting this topic everyday, but I would advise not to. Especially in this working group. I, for one, only participate in the ietf for the purpose of facilitating the e2e model whenever possible. E2e fits my world view as well as my employer's bottom line. CB > >> NPT and NAT are the network equivalent of the toxic polluter model. >> Sure, it's cheap to dump toxic chemicals into the creek upstream. The >> true costs are borne by those downstream, not the person dumping the >> chemicals. > > > Histrionics don't help here. And saying these kinds of things to serious people who already have/like their v4 NAT makes us all look foolish, and ensures that the people you're trying to persuade will not take v6 seriously. > > >>> Even for those end-user networks where PI space makes sense (and I >>> would argue that they are few and far between) the costs, both >>> monetary in terms of RIR fees, and opex; are non-zero, so >>> discussing the pros _and_ cons of all the solutions will have value >>> for the target audience. >> >> >> An up front $1,250 and an annual $100 is _NOT_ a significant expense >> IMHO > > > Great! I'll send you my PayPal info and you can put that amount in my account. Heck, I'll even give you a discount, say an even grand? > > Seriously though, When you look at the options of zero cost, vs. some non-zero cost, it's hard for most organizations to justify, especially when the reason we think they should pay it doesn't line up with their operational needs. > > >> and that is what PI /48 costs from ARIN. I don't know about the >> other RIRs. >> >> In terms of Opex, PI costs no more and probably somewhat less than >> NPT because if it is set up correctly, it's basically fire and >> forget. > > > I'm far from a network expert, but I would think that coordinating your ISP announcing your PI block would take more effort in both setup and ongoing updates/monitoring than it would to set up NPTv6 on the border. The latter only needs to be changed/updated when you change providers. But I'm happy to concede this point to anyone who can provide solid facts. > > >> The configuration complexity for changing providers is no >> greater than that with NPT+ULA. You get the further advantage that >> you can have actually redundant routers, not just redundant >> connections (the NPT solution basically requires putting both >> providers into a single box or REALLY complex workarounds such as >> STONITH to make sure only one router sends RAs at a time). You also >> get the advantage that sessions can (and usually do) survive a >> failover event. > > > In my mind the NPTv6 + ULA solution is targeted more towards those that only have a single provider in the first place. As in, the overwhelming majority of mid-size and SOHO market that makes up the majority of the enterprise end-user networks. Those who already have multiple providers should be looking at PI and multihoming, I agree with you there. > > Doug > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --f46d0438955548778e04d7084f69 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mar 2, 2013 1:43 PM, "Doug Barton" <dougb@dougbarton.us> wrote:
>
> On 03/02/2013 05:12 AM, Owen DeLong wrote:
>>>>>
>>>>>
>>>>
>>>> In the case of NPTv6, I really don't think that it is.= =A0There are
>>>> serious impacts to the intended nature of IPv6 if NPT star= ts
>>>> getting widely deployed.
>>>
>>>
>>> Yes, I get that there are a lot of people in the IPv6 literati= that
>>> wish for the return of the end-to-end model, and dramatically<= br> >>> resist anything that tries to take that away. The problem, as = was
>>> recently discussed (again) in nauseating detail on
>>> ipv6-ops@lists.cl= uenet.de is that most organizations not only don't
>>> want end-to-end back, they prioritize ease of renumbering much=
>>> higher than any benefits IPv6 might bring.
>>>
>>> Because for end user networks there is no compelling reason to=
>>> deploy IPv6 right now, nor is there likely to be one in the ne= ar
>>> future, we need to understand the real world needs for those >>> organizations, and focus on ways to deliver them. ULA + NPTv6 = does
>>> that, and the costs are minimal (although not non-existent, wh= ich
>>> is why documenting the tradeoffs is valuable).
>>>
>>
>> The cost is not minimal. The cost is borne not by those deploying<= br> >> NPT. The cost is borne by every application developer, every secur= ity
>> professional, law enforcement, etc.
>
>
> To some extent I agree with you, but these are already sunk costs. We = already have v4 NAT, and application developers who care have already solve= d these problems. Most of them get better with NPTv6, some of them stay the= same, none of them get worse. But railing against these costs are pointles= s because _they are never going away_. NAT of some form will always exist, = the end-to-end model is never coming back, PLEASE adjust to this reality, s= ince not doing so actively damages the cause of IPv6 deployment.
>

Doug

Afaik, the=A0 ietf is fundamentally committed to the e2e mod= el. The ietf structure allows for revisiting this topic everyday, but I wou= ld advise not to. Especially in this working group.

I, for one, only participate in the ietf for the purpose of = facilitating the e2e model whenever possible. E2e fits my world view as wel= l as my employer's bottom line.

CB
>
>> NPT and NAT are the network equivalent of the toxic polluter model= .
>> Sure, it's cheap to dump toxic chemicals into the creek upstre= am. The
>> true costs are borne by those downstream, not the person dumping t= he
>> chemicals.
>
>
> Histrionics don't help here. And saying these kinds of things to s= erious people who already have/like their v4 NAT makes us all look foolish,= and ensures that the people you're trying to persuade will not take v6= seriously.
>
>
>>> Even for those end-user networks where PI space makes sense (a= nd I
>>> would argue that they are few and far between) the costs, both=
>>> monetary in terms of RIR fees, and opex; are non-zero, so
>>> discussing the pros _and_ cons of all the solutions will have = value
>>> for the target audience.
>>
>>
>> An up front $1,250 and an annual $100 is _NOT_ a significant expen= se
>> IMHO
>
>
> Great! I'll send you my PayPal info and you can put that amount in= my account. Heck, I'll even give you a discount, say an even grand? >
> Seriously though, When you look at the options of zero cost, vs. some = non-zero cost, it's hard for most organizations to justify, especially = when the reason we think they should pay it doesn't line up with their = operational needs.
>
>
>> and that is what PI =A0/48 costs from ARIN. I don't know about= the
>> other RIRs.
>>
>> In terms of Opex, PI costs no more and probably somewhat less than=
>> NPT because if it is set up correctly, it's basically fire and=
>> forget.
>
>
> I'm far from a network expert, but I would think that coordinating= your ISP announcing your PI block would take more effort in both setup and= ongoing updates/monitoring than it would to set up NPTv6 on the border. Th= e latter only needs to be changed/updated when you change providers. But I&= #39;m happy to concede this point to anyone who can provide solid facts. >
>
>> The configuration complexity for changing providers is no
>> greater than that with NPT+ULA. You get the further advantage that=
>> you can have actually redundant routers, not just redundant
>> connections (the NPT solution basically requires putting both
>> providers into a single box or REALLY complex workarounds such as<= br> >> STONITH to make sure only one router sends RAs at a time). =A0You = also
>> get the advantage that sessions can (and usually do) survive a
>> failover event.
>
>
> In my mind the NPTv6 + ULA solution is targeted more towards those tha= t only have a single provider in the first place. As in, the overwhelming m= ajority of mid-size and SOHO market that makes up the majority of the enter= prise end-user networks. Those who already have multiple providers should b= e looking at PI and multihoming, I agree with you there.
>
> Doug
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--f46d0438955548778e04d7084f69-- From owen@delong.com Sun Mar 3 09:31:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE77421F8648 for ; Sun, 3 Mar 2013 09:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.806 X-Spam-Level: X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=0.794, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLMKyNh4J1E8 for ; Sun, 3 Mar 2013 09:31:11 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id CB3FC21F84AD for ; Sun, 3 Mar 2013 09:31:09 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r23HRDui017768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 3 Mar 2013 09:27:13 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r23HRDui017768 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362331634; bh=TS/DnPJDCZyo2AnxjsNSoE8ejGc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=53XVbH43vM7RE2GN1UEbUQGP4nQ4uNAonvNOqTKrMHYB89gaTpBiPqIvJetT56Ij9 i1mCo9fp4eb+PyJqJZe74exFSPDFtVOusK//Qo+4VbN7Vys93HM5NkWnny1vuAq9Hu IrdmFtnvuseDvQlen1okTYV7wSb4BTiOkniOedbI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <20130303130611.GF51699@Space.Net> Date: Sun, 3 Mar 2013 09:27:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7028A682-97CA-452C-B307-DD922748BB70@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <3B96D0EE-B19F-4770-85D0-F7C2136F0BEA@delong.com> <20130303130611.GF51699@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sun, 03 Mar 2013 09:27:14 -0800 (PST) Cc: v6ops@ietf.org Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 17:31:11 -0000 On Mar 3, 2013, at 05:06 , Gert Doering wrote: > Hi, >=20 > On Sat, Mar 02, 2013 at 03:19:28PM -0800, Owen DeLong wrote: >> It shows. On the other hand, I've got almost 30 years of experience = as a network expert and have actually done this many times. Coordinating = your ISP accepting your announcement of your block and forwarding it on = usually takes an email or two, sometimes including a form. In terms of = ongoing updates, there actually aren't usually any unless/until you = switch providers. >>=20 >> Those are the solid facts. I'm not sure what else you want. >=20 > Please get back a bit closer to reality... I base this entirely on reality. I'm running it today. >=20 > Ever tried setting up a BGP session with comcast cable or verizon LTE? >=20 Services not offered, at least presently. > Most lower-budget ISP connections will not come with the option to run > BGP there - over here, the difference is somewhere between "30 EUR a=20= > month for a 16 Mbit ADSL line with a PA /56 assigned to it" and=20 > "starting at 100 EUR/month for the same line, but with BGP routing". I can point to readily available free BGP peering, so I don't buy your = premise. > BGP isn't free on the provider side - all the mass-market = (=3Dcost-saving) > provisioning tools won't really help you, as there are lots of steps > that need to be done and verified for every new customer. Yes, much = of > this can be automated (and usually is), but it's still much more = effort > than "not doing BGP". Interesting. http://tunnelbroker.net as a counterpoint. Owen From gert@space.net Sun Mar 3 12:54:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1867A21F8887 for ; Sun, 3 Mar 2013 12:54:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vd41CfqpY0n8 for ; Sun, 3 Mar 2013 12:54:33 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 5426221F8883 for ; Sun, 3 Mar 2013 12:54:32 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 3FB1F60363 for ; Sun, 3 Mar 2013 21:54:31 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 1C89B60194 for ; Sun, 3 Mar 2013 21:54:31 +0100 (CET) Received: (qmail 52809 invoked by uid 1007); 3 Mar 2013 21:54:31 +0100 Date: Sun, 3 Mar 2013 21:54:31 +0100 From: Gert Doering To: Owen DeLong Message-ID: <20130303205431.GH51699@Space.Net> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <3B96D0EE-B19F-4770-85D0-F7C2136F0BEA@delong.com> <20130303130611.GF51699@Space.Net> <7028A682-97CA-452C-B307-DD922748BB70@delong.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3Py2cJcRnGFKJily" Content-Disposition: inline In-Reply-To: <7028A682-97CA-452C-B307-DD922748BB70@delong.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 20:54:34 -0000 --3Py2cJcRnGFKJily Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sun, Mar 03, 2013 at 09:27:11AM -0800, Owen DeLong wrote: > > Most lower-budget ISP connections will not come with the option to run > > BGP there - over here, the difference is somewhere between "30 EUR a=20 > > month for a 16 Mbit ADSL line with a PA /56 assigned to it" and=20 > > "starting at 100 EUR/month for the same line, but with BGP routing". >=20 > I can point to readily available free BGP peering, so I don't buy your pr= emise. >=20 > > BGP isn't free on the provider side - all the mass-market (=3Dcost-savi= ng) > > provisioning tools won't really help you, as there are lots of steps > > that need to be done and verified for every new customer. Yes, much of > > this can be automated (and usually is), but it's still much more effort > > than "not doing BGP". >=20 > Interesting. http://tunnelbroker.net as a counterpoint. Paid from your marketing budget. It will not be free forever. Sure, you can get free tunnel-based BGP-routed IPv6 today, and=20 tunnelbroker.net is quite impressive for automating all these things -=20 do you provide it for IPv4? Do you provide it comparatively-priced if not based on tunnels, but on a normal end-customer line, with a=20 price similar to what I pay for an ADSL line at DTAG? I also wonder how it does things like "verification of customer=20 announcements, with AS data spread over (at least) 5 different IRR=20 databases"... as that is part of what makes BGP customer connections more work than mass market. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --3Py2cJcRnGFKJily Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQCVAwUBUTO4hqkuBuNlUUl1AQI8wQP/fcPr3D7lK7qkkRrQy5vVKmx+et+TprUX Vlp6/A2ntRnLHhPmLg2HIFqt2d53/usCWq72gdItkjXkcIvDlwh48cBdhJQqIZkt XKEcLlRuaWXORTaVPZwVqOrAUzMBRZpSjcSj0KgjLi/MePOZghdxohCQf62R1LOF VKka9SBMYjQ= =7Ygu -----END PGP SIGNATURE----- --3Py2cJcRnGFKJily-- From dougb@dougbarton.us Mon Mar 4 00:14:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8244B21F85ED for ; Mon, 4 Mar 2013 00:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.414 X-Spam-Level: X-Spam-Status: No, score=0.414 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-3KfdApGmmX for ; Mon, 4 Mar 2013 00:14:31 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2B421F85F3 for ; Mon, 4 Mar 2013 00:14:31 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:fd90:9c65:3ee7:82d8] (unknown [IPv6:2001:470:d:5e7:fd90:9c65:3ee7:82d8]) by dougbarton.us (Postfix) with ESMTPSA id A0E4D22B6D for ; Mon, 4 Mar 2013 08:14:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362384870; bh=qKDiMoWhdW25Kf9TRIxZuNelCfNeRB62uAQzoHqoUZE=; h=Date:From:To:Subject:References:In-Reply-To; b=dmAkg8AHj6gtLH2EZkRGsnF+KEn1V48sUHawxh/GthtagUyiNsWO6YzNhjMtglVnj BU6PbhExCSwO/ke71dg2NMGzcWG/XUjqyy+li8AnOx7xTHQiNRHYGmZoLw6SlEjNrd UdkSS6W1auQfB14Rb+aPzojxA7XSZvYDZHdhtDJo= Message-ID: <513457E6.6060201@dougbarton.us> Date: Mon, 04 Mar 2013 00:14:30 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <3B96D0EE-B19F-4770-85D0-F7C2136F0BEA@delong.com> <513299CE.20509@dougbarton.us> <1364B842-D3BE-48C1-A2A5-3D74DC37DB4A@delong.com> In-Reply-To: <1364B842-D3BE-48C1-A2A5-3D74DC37DB4A@delong.com> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 08:14:32 -0000 Given that we've entered the "misquote/misrepresent what I wrote in the past" phase of the discussion, I will restate my position one more time, then stop boring people. :) The short version for the list is that I definitely think fairly stating the pros and cons of the various alternatives would be a valuable addition to the document. I think that saying ULA + NPTv6 is "not recommended" is way too much. Regarding this most recent post ... When I said "poorly written," I was referring to those applications still using the old get*by*() functions instead of more modern ones like getaddrinfo() which bring you IPv6 compatibility basically for free. OTOH, in this day and age any application that needs to allow outside hosts to connect in which doesn't have a NAT traversal strategy is in fact poorly written. Your example of desktop collaboration software will work perfectly well inside the firewall, where NPT is irrelevant. There are precious few enterprises that allow any connections in, whether they use NAT or not. This isn't going to change, and is one of the chief reasons why the whole "we need to go back to the end-to-end model" mantra is so much foolishness. My "zero cost" comment was in the context of RIR fees, which you conveniently snipped out. I have never said that ULA + NPT comes with absolutely no cost at all, any more than NAT, PI, or PA space do. That is why a fair discussion of the tradeoffs will be valuable. Finally, enterprises HATE renumbering. The costs associated are not merely limited to giving systems new addresses, they include changing firewall rules, ACLs, applications, configurations, etc. I could tell you horror stories about how deeply embedded bad assumptions and practices are rampant in the average enterprise, but the short version is that enterprises hate renumbering, and not without good reason. Telling an enterprise "renumbering is easy, it only takes a month" would get me laughed out of the room. In short, ULA + NPTv6 meets a real need, in spite of the costs, and should be included in the analysis of any solution matrix in this space. Doug On 03/03/2013 01:28 AM, Owen DeLong wrote: >>> That statement shows a profound misunderstanding of the situation. >>> >>> Most applications haven't yet been ported to IPv6. Adding support for >>> IPv6 NPT and NAT traversal is _NOT_ a sunk cost. Further, the wide >>> variety of NATs and other oddities surrounding network behavior >>> related to NAT require substantial regression testing and QA for >>> every release. That's _NOT_ a sunk cost. It's an ongoing tax. >> >> Assuming you are right about all of this (which to some extent you >> are, but for sake of argument let's say you're 100% right) it still >> doesn't matter. Adding NPTv6 support is in the statistical noise from >> a development perspective. Well-written applications need little or no >> additional development work to support IPv6, poorly written ones will >> need to be updated, but that's going to be true regardless, and adding >> NPT support is still going to be a small marginal cost. > > Again, I cannot agree with you here. Your attempt to classify any > application that wants to be talking end-to-end without having its > packets mutilated along the way as "poorly written" simply doesn't hold > water. There are lots f reasons to want to be able to communicate > (reasonably) directly and not all of them involve including layer 3 > addressing as layer 7 payload (which I believe is what you actually > intended to target). > > Consider, for example, the desire to host some sort of collaborative > process on a desktop machine without requiring a third-party rendezvous > server. That's not a poorly written application, it's a perfectly valid > one which requires that the host machine have an accessible global address. > > Sure, some enterprises may want to block such activities and they can do > that perfectly well through policy and stateful inspection. No need for > NPT and NPT brings no benefit to that process. > >> The ongoing "tax" you refer to is going to be paid regardless, because >> v4 NAT is never, ever going away; and we're 20-30 years away from v4 >> support being a thing of the past. > > I disagree. I think IPv4 will drop into the noise much faster than you > expect because it will become so completely expensive to maintain that > nobody will want to touch it. > >> >>> The question is not whether NAT will exist or not, but, whether it >>> will remain in use by a sufficiently large mass to drive the >>> industry. Many of us are still holding out hope that with IPv6, it >>> will not. It's still possible and it's a perfectly valid reason to >>> state in an RFC discussing intended uses of ULA that NPT and NAT are >>> NOT recommended in IPv6. >> >> Yes, I understand your position thoroughly. My point is that "not >> recommended" is at best pollyanish, and at worst counter productive. >> OTOH, a fair, rational discussion of the tradeoffs is beneficial to >> all concerned. > > I'm all for a fair rational discussion of the tradeoffs. However, I > think it is reasonable and prudent at the end of that discussion to > include the conclusion that damaging the protocol in such a manner is > not recommended. > >> >>>>> NPT and NAT are the network equivalent of the toxic polluter model. >>>>> Sure, it's cheap to dump toxic chemicals into the creek upstream. The >>>>> true costs are borne by those downstream, not the person dumping the >>>>> chemicals. >>>> >>>> Histrionics don't help here. And saying these kinds of things to >>>> serious people who already have/like their v4 NAT makes us all look >>>> foolish, and ensures that the people you're trying to persuade will >>>> not take v6 seriously. >>>> >>> >>> This isn't histrionics. It's a simple fact... Deploying NAT/NPT does, >>> in fact, inflict costs on others that are not borne by those >>> deploying NAT and those costs are not currently considered by most >>> NAT fanatics. >> >> "Toxic waste" analogies are histrionic by definition. And even if I >> fully agreed with your arguments about how bad NAT is, telling people >> that use/like it that they are the network equivalent to toxic waste >> dumpers is not only not helping, it's hurting. > > From webseter: > > > Definition of /HISTRIONICS/ > > 1 > *:* theatrical performances > 2 > *:* deliberate display of emotion for effect > > I don't think it qualifies as a theatrical performance. > It wasn't a display of emotion, it was a simple analogy about who pays > the true cost. > >>>>>> Even for those end-user networks where PI space makes sense (and I >>>>>> would argue that they are few and far between) the costs, both >>>>>> monetary in terms of RIR fees, and opex; are non-zero, so >>>>>> discussing the pros _and_ cons of all the solutions will have value >>>>>> for the target audience. >>>>> >>>>> An up front $1,250 and an annual $100 is _NOT_ a significant expense >>>>> IMHO >>>> >>>> Great! I'll send you my PayPal info and you can put that amount in >>>> my account. Heck, I'll even give you a discount, say an even grand? >>>> >>> >>> Very funny. >> >> So what you're saying is that you would consider sending me $1,000 to >> be a not-insignificant expense? >> > > No, what I'm saying is that I had no problem paying for my PI assignment > and I cannot imagine an actual business operation that wants to be > multihomed finding it difficult to cover the minimal expenses involved > in obtaining addresses to do so. > > Given the number of different things involved in just creating a > business that cost more than that, I don't find it a very credible argument. > >>>> Seriously though, When you look at the options of zero cost, vs. >>>> some non-zero cost, it's hard for most organizations to justify, >>>> especially when the reason we think they should pay it doesn't line >>>> up with their operational needs. >>>> >>> >>> I suppose that's because you aren't considering all of the costs. ULA >>> isn't free. NPT isn't free. The fact that you want to pretend it is >>> doesn't make it so. >> >> I'm not saying it's free, I'm saying "Let's rationally discuss the >> tradeoffs." It is unarguably true that ULA does not require an RIR >> fee, but putting down the other costs in writing will help people to >> make up their minds about which costs they are willing to bear. > > Your quote (still present above) states "zero cost". That's the same as > 'free" by most people's definition, so yes, you did say it was free. > It's in your quote above. > > A rational discussion of the tradeoffs has to include the real costs, > regardless of who bears them. People who like/want NAT like/want it > because it allows them to dump the cost burden on others. Admittedly, > many of them do not realize that they are doing so, just like there was > a time when people didn't realize the impact that dumping stuff in the > oceans was having. > >> >>> I would bet that the annualized cost of maintaining all the extra >>> code and the additional security risks involved in running a network >>> with translation far exceed $100/year. So much so that I bet you get >>> your $1,250 back in less than 4 years. For most finance people, >>> that's what they call a no-brainer. >> >> ... except for my now-oft-repeated point that those costs are never >> going to go away. Not to mention that most enterprise end-user >> networks are not in the business of code development, so your concern >> doesn't apply to them. > > Yes, you keep repeating this, but it isn't true and repeating it doesn't > make it true just because you want it to be true. > > I already agreed with you about the last part... In fact, that's the > part that lines up with the toxic polluter as an analogy, not > histrionics. Unfortunately, you were too caught up in dismissing what I > was saying as histrionics to actually look at the metaphor. > >>>>> and that is what PI /48 costs from ARIN. I don't know about the >>>>> other RIRs. >>>>> >>>>> In terms of Opex, PI costs no more and probably somewhat less than >>>>> NPT because if it is set up correctly, it's basically fire and >>>>> forget. >>>> >>>> I'm far from a network expert, but I would think that coordinating >>>> your ISP announcing your PI block would take more effort in both >>>> setup and ongoing updates/monitoring than it would to set up NPTv6 >>>> on the border. The latter only needs to be changed/updated when you >>>> change providers. But I'm happy to concede this point to anyone who >>>> can provide solid facts. >>>> >>> >>> It shows. On the other hand, I've got almost 30 years of experience >>> as a network expert and have actually done this many times. >>> Coordinating your ISP accepting your announcement of your block and >>> forwarding it on usually takes an email or two, sometimes including a >>> form. In terms of ongoing updates, there actually aren't usually any >>> unless/until you switch providers. >>> >>> Those are the solid facts. I'm not sure what else you want. >> >> So ISPs never reconfigure routers, BGP sessions never flap, nothing >> ever happens with this kind of configuration that needs ongoing >> monitoring and updates? > > Monitoring, yes. As to configuration changes, very very rarely. ISPs > don't like to make customer effecting changes. They take a lot of time > and coordination and they are very expensive. They also tend to make > customers unhappy. As such, we try to avoid them whenever possible. A > BGP session flap doesn't require a configuration change, it requires > fixing the problem. If the configuration on the router worked last week > and it doesn't work this week, the configuration on the router isn't the > thing that changed, so the question is what did. If the ISP changed > their configuration, then you may need to change the local > configuration, but that's going to rarely be the case. More often, you > need to do one of the following: > > 1.Get the circuit fixed. (most common problem) > 2.Get the ISP to fix whatever they accidentally changed on their side. > 3.Investigate a more unusual problem in more detail before taking any > action. > > In case 3, that's not any more or less likely to happen with a BGP > session than it is with a static routed session going through NAT/NPT > and it's not any more difficult to debug/troubleshoot. In fact, since > you don't have to trace things through state tables and address > mutilations in the headers, it's usually quite a bit easier. > > As an example, think the last time I changed the BGP configuration I > included was about 3.5 years ago. > >>>>> The configuration complexity for changing providers is no >>>>> greater than that with NPT+ULA. You get the further advantage that >>>>> you can have actually redundant routers, not just redundant >>>>> connections (the NPT solution basically requires putting both >>>>> providers into a single box or REALLY complex workarounds such as >>>>> STONITH to make sure only one router sends RAs at a time). You also >>>>> get the advantage that sessions can (and usually do) survive a >>>>> failover event. >>>> >>>> In my mind the NPTv6 + ULA solution is targeted more towards those >>>> that only have a single provider in the first place. As in, the >>>> overwhelming majority of mid-size and SOHO market that makes up the >>>> majority of the enterprise end-user networks. Those who already have >>>> multiple providers should be looking at PI and multihoming, I agree >>>> with you there. >>> >>> I think that's a temporary majority, frankly. The internet is >>> becoming too mission critical to accept single-homing for much longer >>> in most cases. Many of my clients are actually paying me to move them >>> to multi-homed connectivity and this seems to be a growing trend. >> >> No argument there, but your sample is severely corrupted by volunteer >> bias. The number of small-medium enterprises who could not even spell >> "multihomed" is pretty vast. > > Today, that's true. However, the number that can say "Hey, Mr. IT > consultant, our internet isn't reliable enough and when its down, our > credit card processor doesn't work any more. Is there any way we can get > a more reliable internet connection?" is not nearly so limiting. If "Mr. > IT Consultant" has half a brain, he figures out how to get them > multi-homed. If he doesn't, then he's one of those guys that gives the > rest of us a bad name. > >>> Frankly, if you're single-homed, you're better off setting up your >>> network for easy renumbering, running static provider-assigned >>> prefixes, and taking a month with both prefixes present to renumber >>> the network. It's really not that hard in IPv6 and can be done with >>> almost no disruption to the users. (Yes, I've done this a couple of >>> times for medium-sized networks. If you plan for it in the original >>> network design it really can be pretty straight forward.) >> >> Again, for those that actually are, or will be multihomed we're in >> agreement. My argument is for the overwhelming majority of >> small-medium enterprises who will not ever be multihomed. The >> perceived benefits of v4 NAT, especially no need to ever renumber, are >> much more important than anything v6 can provide them. They don't want >> the end-to-end model back, no matter how much some of us think they >> should. > > That's because those people largely don't know how much easier it is to > renumber in IPv6. Seriously, renumbering (especially prefix-only > renumbering) can be done for the average SME over the course of about a > month without significant disruption and without even requiring all that > many man hours in the process. It's not like IPv4. That part did > actually get mostly fixed in IPv6. > > Owen > From dougb@dougbarton.us Mon Mar 4 00:35:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FA921F870E for ; Mon, 4 Mar 2013 00:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.093 X-Spam-Level: X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[AWL=1.507, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Lw4Q1xZo9Yg for ; Mon, 4 Mar 2013 00:35:35 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5294721F8910 for ; Mon, 4 Mar 2013 00:35:35 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:fd90:9c65:3ee7:82d8] (unknown [IPv6:2001:470:d:5e7:fd90:9c65:3ee7:82d8]) by dougbarton.us (Postfix) with ESMTPSA id ED94822B6D for ; Mon, 4 Mar 2013 08:35:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362386135; bh=IykHsJPV6fZWzCNgpbVXzhnKexkUZHa1iWEwNQVyfLA=; h=Date:From:To:Subject:References:In-Reply-To; b=TgVByZE5CDuPzENb071iHA9VFGfSwSesyPtMI6a+xUkT5BtpEwzYSqNVWCQ0WV/zA W8W8t2rv5rRCTDic+pQJvmAZ8pbomDl7Q9sOsNzbYIUqpi3/CTheCDG4jbWQG2RGQt oX1LGIIbsTG6OuMf58nNm5bYzbrA8z0wWXaWeZUY= Message-ID: <51345CD6.3070807@dougbarton.us> Date: Mon, 04 Mar 2013 00:35:34 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: IPv6 Ops WG References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 08:35:44 -0000 On 03/03/2013 09:09 AM, Cameron Byrne wrote: > Doug > > Afaik, the ietf is fundamentally committed to the e2e model. [citation needed] > The ietf > structure allows for revisiting this topic everyday, but I would advise > not to. Especially in this working group. > > I, for one, only participate in the ietf for the purpose of facilitating > the e2e model whenever possible. E2e fits my world view as well as my > employer's bottom line. Cameron, With all due respect to those involved, the history of the IETF, and particularly some of those who have pushed various aspects of the IPv6 protocol as it was envisioned 15 years ago, is replete with decisions that show a stunning lack of familiarity with real world needs. The fact that it took the content networks years to drag the IPv6 literati kicking and screaming into allowing for PI space is one excellent example. The continuing failure to permit a full-featured DHCPv6 protocol is similarly slowing down adoption by the end-user networks. The whole concept of "returning to the end-to-end model" is anachronistic, and does not meet the needs of the overwhelming majority of end-user networks. Completely aside from the NAT/renumbering issues, the firewalls on nearly all enterprise networks are closed. The same should be true for home users, in fact one could argue that it's more important there. Thus, any software that needs to allow connections from the outside in has to have something like UPNP/PMP, or a rendezvous server; so whether it's punching that hole in "just a SPIF," or "SPIF + NAT/NPT" doesn't matter. So, yes ... I will continue to talk about this problem, until I'm confident that all of the right people understand it. Doug From leo.liubing@huawei.com Mon Mar 4 01:17:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F9C21F88DD for ; Mon, 4 Mar 2013 01:17:21 -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_13=0.6, 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 xRKKifxJJ0DL for ; Mon, 4 Mar 2013 01:17:16 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 83EE021F8881 for ; Mon, 4 Mar 2013 01:17: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 AQH10895; Mon, 04 Mar 2013 09:17:14 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 4 Mar 2013 09:17:07 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 4 Mar 2013 09:17:11 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.42]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.01.0323.007; Mon, 4 Mar 2013 17:16:59 +0800 From: "Liubing (Leo)" To: Sheng Jiang , "v6ops@ietf.org" Thread-Topic: Review solicitation - draft-jiang-v6ops-semantic-prefix Thread-Index: Ac4UmZxJgYKThVy5TOeV8GZlgLA+sgEFtnSA Date: Mon, 4 Mar 2013 09:16:59 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6E50E0@nkgeml506-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923A00DFFB@szxeml545-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923A00DFFB@szxeml545-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: sunqiong , "ian.farrer@telekom.de" Subject: Re: [v6ops] Review solicitation - draft-jiang-v6ops-semantic-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 09:17:21 -0000 Hi, Sheng Hope it's not too late to catch up this, sorry for the delay. Generally, I think it is a good idea to encoding semantics in IPv6 address.= The 128bit seems could provide us a loose space for doing this.=20 Just two general comments: 1. Section 5 "Sharing semantic definition among Semantic Prefix Domains ena= bles more semantic based network operations." Does "sharing" means an absolute definition across domains, or some mechani= sms of semantic mapping between domains, or both available? I think the Int= er-Domain semantic operation is an important topic, maybe we need more desc= ription on it. 2. Section 9 Gaps Maybe it's better to have a brief review of operational considerations whic= h are needed to support semantic, before the gap analysis?=20 E.g. operational considerations of the addressing plan/allocation, will it = bring too much complexity for the operators or not; filtering operations to= increase the semantic trust .etc. Best regards, Bing > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Sheng Jiang > Sent: Wednesday, February 27, 2013 11:22 AM > To: v6ops@ietf.org > Cc: ian.farrer@telekom.de; sunqiong > Subject: [v6ops] Review solicitation - draft-jiang-v6ops-semantic-prefix >=20 > Hi, all v6ops, >=20 > We have submitted a new version draft-jiang-v6ops-semantic-prefix, "A > Framework for Semantic IPv6 Prefix and Gap Analysis" > (http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix). It is des= cribes > a framework that embeds semantics into IPv6 prefixes, so that network > operators can efficiently manage their network traffic based on these > explicit semantics. >=20 > This document was once presented in v6ops @ ietf84, Vancouver. There was > many discussions and interests was expressed. After that, we have rewritt= en > the document largely along with two new co-authors from China Telecom > and Deutsche Telecom. >=20 > The authors believe it is useful work and operators can benefit from such > network planning/management. >=20 > Please read the draft and comment. Your reviewing is important for us to > improve the document. >=20 > A companion draft "Use case of IPv6 prefix semantics for operators" > (http://tools.ietf.org/html/draft-sun-v6ops-semantic-usecase) has also be= en > submitted to v6ops WG. It describes more specific use case for > telecommunication operators. >=20 > Best regards, >=20 > Sheng > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jiangsheng@huawei.com Mon Mar 4 01:49:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E485521F8634 for ; Mon, 4 Mar 2013 01:49:50 -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_13=0.6, 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 Dwa-zadKrhj3 for ; Mon, 4 Mar 2013 01:49:50 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ECA1F21F85C9 for ; Mon, 4 Mar 2013 01:49:49 -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 AQH14401; Mon, 04 Mar 2013 09:49:48 +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.7; Mon, 4 Mar 2013 09:49:37 +0000 Received: from SZXEML462-HUB.china.huawei.com (10.82.67.205) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 4 Mar 2013 09:49:41 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.156]) by szxeml462-hub.china.huawei.com ([10.82.67.205]) with mapi id 14.01.0323.007; Mon, 4 Mar 2013 17:49:31 +0800 From: Sheng Jiang To: "Liubing (Leo)" , "v6ops@ietf.org" Thread-Topic: Review solicitation - draft-jiang-v6ops-semantic-prefix Thread-Index: Ac4UmZxJgYKThVy5TOeV8GZlgLA+sgEFtnSAAALad7A= Date: Mon, 4 Mar 2013 09:49:30 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923A031DFC@szxeml545-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923A00DFFB@szxeml545-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6E50E0@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6E50E0@nkgeml506-mbx.china.huawei.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.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: sunqiong , "ian.farrer@telekom.de" Subject: Re: [v6ops] Review solicitation - draft-jiang-v6ops-semantic-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 09:49:51 -0000 SGksIEJpbmcsDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXcgYW5kIGNvbW1lbnRzLiBSZXBsaWVz IGluIGxpbmVzLg0KDQo+MS4gU2VjdGlvbiA1ICJTaGFyaW5nIHNlbWFudGljIGRlZmluaXRpb24g YW1vbmcgU2VtYW50aWMgUHJlZml4IERvbWFpbnMNCj5lbmFibGVzIG1vcmUgc2VtYW50aWMgYmFz ZWQgbmV0d29yayBvcGVyYXRpb25zLiINCj5Eb2VzICJzaGFyaW5nIiBtZWFucyBhbiBhYnNvbHV0 ZSBkZWZpbml0aW9uIGFjcm9zcyBkb21haW5zLCBvciBzb21lDQo+bWVjaGFuaXNtcyBvZiBzZW1h bnRpYyBtYXBwaW5nIGJldHdlZW4gZG9tYWlucywgb3IgYm90aCBhdmFpbGFibGU/IEkNCj50aGlu ayB0aGUgSW50ZXItRG9tYWluIHNlbWFudGljIG9wZXJhdGlvbiBpcyBhbiBpbXBvcnRhbnQgdG9w aWMsIG1heWJlIHdlDQo+bmVlZCBtb3JlIGRlc2NyaXB0aW9uIG9uIGl0Lg0KDQpJdCBpcyBub3Qg cG9zc2libGUgdG8gZGVmaW5lIGdlbmVyaWMvc3RhbmRhcmQgc2VtYW50aWNzIGFjcm9zcyBkb21h aW5zLiBXZSBoYXZlIGVtcGhhc2l6ZWQgc2VtYW50aWNzIGFyZSBvbmx5IG1lYW5pbmdmdWwgbG9j YWxseSB3aXRoaW4gZG9tYWluLiBXaGF0IHdlIG1lYW4gYnkgInNoYXJpbmciIGlzIG9ubHkgYmV0 d2VlbiB0d28gdHJ1c3RlZCBkb21haW4uIFRoZXJlIHdhcyBzb21lIGRpc2N1c3Npb24gdGhhdCBt YXkgYmUgaGF2ZSBzZWN1cml0eSBjb25jZXJucyBhbmQgc2hvdWxkIGJlIGxpbWl0ZWQuIFdlIHdp bGwgcHV0IG1vcmUgZGVzY3JpcHRpb24gYW5kIGRpc2N1c3Npb24gaW4uDQoNCj4yLiBTZWN0aW9u IDkgR2Fwcw0KPk1heWJlIGl0J3MgYmV0dGVyIHRvIGhhdmUgYSBicmllZiByZXZpZXcgb2Ygb3Bl cmF0aW9uYWwgY29uc2lkZXJhdGlvbnMgd2hpY2gNCj5hcmUgbmVlZGVkIHRvIHN1cHBvcnQgc2Vt YW50aWMsIGJlZm9yZSB0aGUgZ2FwIGFuYWx5c2lzPw0KPkUuZy4gb3BlcmF0aW9uYWwgY29uc2lk ZXJhdGlvbnMgb2YgdGhlIGFkZHJlc3NpbmcgcGxhbi9hbGxvY2F0aW9uLCB3aWxsIGl0IGJyaW5n DQo+dG9vIG11Y2ggY29tcGxleGl0eSBmb3IgdGhlIG9wZXJhdG9ycyBvciBub3Q7IGZpbHRlcmlu ZyBvcGVyYXRpb25zIHRvIGluY3JlYXNlDQo+dGhlIHNlbWFudGljIHRydXN0IC5ldGMuDQoNCllv dXIgc3VnZ2VzdGlvbiBpcyB2ZXJ5IHZhbHVhYmxlLiBBY3R1YWxseSwgSSBndWVzcywgd2Ugc2hv dWxkIHNlcGFyYXRlIGdhcCBhbmFseXNpcyB0byBiZSBhbm90aGVyIGluZGVwZW5kZW50IGRvY3Vt ZW50LiBJbiB0aGF0IGRvY3VtZW50LCBvcGVyYXRpb25hbCBjb25zaWRlcmF0aW9ucyB3aXRoaW4g dmFyaW91cyBhcHBsaWNhdGlvbiBzY2VuYXJpb3Mgc2hvdWxkIGJlIHRoZSBtb3N0IGltcG9ydGFu dCBhbmFseXNpcy4gQWZ0ZXIgdGhlbiwgd2UgY2FuIGRyYXcgdGhlIGNvbmNsdXNpb24gd2hlcmUg Z2FwcyBhcmUuDQoNCk1hbnkgdGhhbmtzIGFuZCBiZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCj5C ZXN0IHJlZ2FyZHMsDQo+QmluZw0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ IEZyb206IHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYNCj4+IE9mIFNoZW5nIEppYW5nDQo+PiBTZW50OiBXZWRuZXNkYXksIEZl YnJ1YXJ5IDI3LCAyMDEzIDExOjIyIEFNDQo+PiBUbzogdjZvcHNAaWV0Zi5vcmcNCj4+IENjOiBp YW4uZmFycmVyQHRlbGVrb20uZGU7IHN1bnFpb25nDQo+PiBTdWJqZWN0OiBbdjZvcHNdIFJldmll dyBzb2xpY2l0YXRpb24gLSBkcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXgNCj4+DQo+ PiBIaSwgYWxsIHY2b3BzLA0KPj4NCj4+IFdlIGhhdmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24g ZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4LCAiQQ0KPj4gRnJhbWV3b3JrIGZvciBT ZW1hbnRpYyBJUHY2IFByZWZpeCBhbmQgR2FwIEFuYWx5c2lzIg0KPj4gKGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWppYW5nLXY2b3BzLXNlbWFudGljLXByZWZpeCkuIEl0IGlzIGRl c2NyaWJlcw0KPj4gYSBmcmFtZXdvcmsgdGhhdCBlbWJlZHMgc2VtYW50aWNzIGludG8gSVB2NiBw cmVmaXhlcywgc28gdGhhdCBuZXR3b3JrDQo+PiBvcGVyYXRvcnMgY2FuIGVmZmljaWVudGx5IG1h bmFnZSB0aGVpciBuZXR3b3JrIHRyYWZmaWMgYmFzZWQgb24gdGhlc2UNCj4+IGV4cGxpY2l0IHNl bWFudGljcy4NCj4+DQo+PiBUaGlzIGRvY3VtZW50IHdhcyBvbmNlIHByZXNlbnRlZCBpbiB2Nm9w cyBAIGlldGY4NCwgVmFuY291dmVyLiBUaGVyZSB3YXMNCj4+IG1hbnkgZGlzY3Vzc2lvbnMgYW5k IGludGVyZXN0cyB3YXMgZXhwcmVzc2VkLiBBZnRlciB0aGF0LCB3ZSBoYXZlIHJld3JpdHRlbg0K Pj4gdGhlIGRvY3VtZW50IGxhcmdlbHkgYWxvbmcgd2l0aCB0d28gbmV3IGNvLWF1dGhvcnMgZnJv bSBDaGluYSBUZWxlY29tDQo+PiBhbmQgRGV1dHNjaGUgVGVsZWNvbS4NCj4+DQo+PiBUaGUgYXV0 aG9ycyBiZWxpZXZlIGl0IGlzIHVzZWZ1bCB3b3JrIGFuZCBvcGVyYXRvcnMgY2FuIGJlbmVmaXQg ZnJvbSBzdWNoDQo+PiBuZXR3b3JrIHBsYW5uaW5nL21hbmFnZW1lbnQuDQo+Pg0KPj4gUGxlYXNl IHJlYWQgdGhlIGRyYWZ0IGFuZCBjb21tZW50LiBZb3VyIHJldmlld2luZyBpcyBpbXBvcnRhbnQg Zm9yIHVzIHRvDQo+PiBpbXByb3ZlIHRoZSBkb2N1bWVudC4NCj4+DQo+PiBBIGNvbXBhbmlvbiBk cmFmdCAiVXNlIGNhc2Ugb2YgSVB2NiBwcmVmaXggc2VtYW50aWNzIGZvciBvcGVyYXRvcnMiDQo+ PiAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc3VuLXY2b3BzLXNlbWFudGljLXVz ZWNhc2UpIGhhcyBhbHNvDQo+YmVlbg0KPj4gc3VibWl0dGVkIHRvIHY2b3BzIFdHLiBJdCBkZXNj cmliZXMgbW9yZSBzcGVjaWZpYyB1c2UgY2FzZSBmb3INCj4+IHRlbGVjb21tdW5pY2F0aW9uIG9w ZXJhdG9ycy4NCj4+DQo+PiBCZXN0IHJlZ2FyZHMsDQo+Pg0KPj4gU2hlbmcNCj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiB2Nm9wcyBtYWlsaW5n IGxpc3QNCj4+IHY2b3BzQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Y2b3BzDQo= From arturo.servin@gmail.com Mon Mar 4 02:14:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3106521F890D for ; Mon, 4 Mar 2013 02:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, 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 PulJAs5cH9XI for ; Mon, 4 Mar 2013 02:14:40 -0800 (PST) Received: from mail-ye0-f175.google.com (mail-ye0-f175.google.com [209.85.213.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD6E21F8948 for ; Mon, 4 Mar 2013 02:14:40 -0800 (PST) Received: by mail-ye0-f175.google.com with SMTP id j12so754657yeg.6 for ; Mon, 04 Mar 2013 02:14:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=E+5us5NDSe82Qtah5xtCIixTlm3S+zbblYcMZc2az8A=; b=r3pIAdLvVNx5+A3Ho4pYwzGAmc+TX2MVI5jFLMltGO81JHzMme1U5wVR5JkK8JC5Ik dhLXEfa6j09EzvuN092MuATgWYlYbt+whm+cqb+DGpbVzM9Eiof5OqmF0T2Rm44ekzf7 F2/tDK3fnLwS5r2xSGrEgRM8uhZ3JGYMcpMNtvCj5m3locXx9sMVQSOLz6QmXvWmghUQ bRxY4W48RTOvqzOZ0ZJFmEhK5hG965D77XaZYDhnI/CVNN4yNTPzAmwB23he7PIR5OXk C4JVYe/1oEyry5iORzlgcOMp8WsJ2chEodYlsXg7K0bk/I0hryBYuCTm7hROiMff9SMk u/KQ== X-Received: by 10.236.152.161 with SMTP id d21mr13296354yhk.158.1362392079974; Mon, 04 Mar 2013 02:14:39 -0800 (PST) Received: from MiniR2D2.local ([2800:af:ba30:d6a5:24e1:bb4c:aad:8a18]) by mx.google.com with ESMTPS id s74sm33960866yhh.5.2013.03.04.02.14.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Mar 2013 02:14:39 -0800 (PST) Message-ID: <5134740A.2050500@gmail.com> Date: Mon, 04 Mar 2013 08:14:34 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: m qf References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-ma-v6ops-ipv6-address-assignment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 10:14:41 -0000 Qiongfang, Still I am not convinced, also, in section 5 you talk about "flags" while in my understanding is not what we do today in making our addressing plans that are basically based on aggregation and location. Regars, as On 04/03/2013 08:02, m qf wrote: > > The mailing list seems to have some problems, I can not receive my mail > to the v6ops@ietf.org . so I try again using > another mail address. Original mail as follows£º > > > > Dear Arturo, > > thanks for your comment. Prefix length assignment to end site refer to > some RFCs in the draft. The new things and main point I would like to > express are in later sections. This draft gives the calculation methods > of address pool , and give an example of carving up addresses. Some > considerations derived from actual network operation. I hope to provide > a reference for IPv6 address planning. > > Best regards. > > Qiongfang > > 2013-03-01 > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > *·¢¼þÈË£º* Arturo Servin > *·¢ËÍʱ¼ä£º* 2013-03-01 15:02:25 > *ÊÕ¼þÈË£º* v6ops > *³­ËÍ£º* > *Ö÷Ì⣺* Re: [v6ops] new draft: draft-ma-v6ops-ipv6-address-assignment > Dear authors, > I read your draft and I think that the content is covered by the > combination of RFC6177, RFC5375, RFC6164 and > draft-ietf-v6ops-design-choices. So I am not sure what is the new thing > in this draft. > Cheers, > as > On 19/02/2013 21:45, fred@cisco.com wrote: >> >> A new draft has been posted, at http://tools.ietf.org/html/draft-ma-v6ops-ipv6-address-assignment. Please take a look at it and comment. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://w > From arturo.servin@gmail.com Mon Mar 4 03:05:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F7621F89FB for ; Mon, 4 Mar 2013 03:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.075 X-Spam-Level: X-Spam-Status: No, score=-1.075 tagged_above=-999 required=5 tests=[AWL=-1.525, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRLig+MAEX5i for ; Mon, 4 Mar 2013 03:05:48 -0800 (PST) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 25D7E21F89FD for ; Mon, 4 Mar 2013 03:05:48 -0800 (PST) Received: by mail-yh0-f50.google.com with SMTP id z20so764026yhz.37 for ; Mon, 04 Mar 2013 03:05:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=eFfOaRZYyi06HPxwxaquPf1ovU/PeayVcBF0QpMVe3s=; b=it1VlZyKrxllj63P1uFP35jRTL69zu1Rkgybv3rYFMtXJS/GQBj9njpjX3sWY1ZnTi pamoW5SbgWMqT6e9ZMbRsHRhiisrIef7EpqzOxTAzY8qFmvj0iE1Ktb5NQzOBqhoTm36 SyHxk3hwv/2kl4gs2lFW8xozcMRc822JBaHVDMVgLeworeTvys4AjALUG8ri4ARqT27e bfIbCC+Yp+M7hbYWkUqT63Ajd1eSmhFAv5cTCldg/X/uvbdCfBnlovJ4DePSFUuqILaA jXMeAiRMo27YcBViSCHfx3Is0Xw60vq1Rt/uZ/700yL+fl6BG9U4EceIL/5NhNMYqM/E ourA== X-Received: by 10.236.150.41 with SMTP id y29mr13527827yhj.75.1362395147606; Mon, 04 Mar 2013 03:05:47 -0800 (PST) Received: from MiniR2D2.local ([2800:af:ba30:d6a5:24e1:bb4c:aad:8a18]) by mx.google.com with ESMTPS id g69sm29975739yhh.17.2013.03.04.03.05.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Mar 2013 03:05:46 -0800 (PST) Message-ID: <51348007.5080509@gmail.com> Date: Mon, 04 Mar 2013 09:05:43 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: m qf References: <5134740A.2050500@gmail.com> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-ma-v6ops-ipv6-address-assignment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 11:05:49 -0000 That is not clear to me. If I were new on IPv6 I would be very confuse how to make an allocation plan after reading your draft. Regards, as On 04/03/2013 08:40, m qf wrote: > Arturo, > > in section 5, the address is curved into some fields considering the > aggregation and management. I would like to know what are your main > considerationin your addressing plan. Thanks a lot. > > Best regards. > > > 2013/3/4 Arturo Servin > > > Qiongfang, > > Still I am not convinced, also, in section 5 you talk about > "flags" > while in my understanding is not what we do today in making our > addressing plans that are basically based on aggregation and location. > > Regars, > as > > On 04/03/2013 08:02, m qf wrote: > > > > The mailing list seems to have some problems, I can not receive my > mail > > to the v6ops@ietf.org > >. so I try again using > > another mail address. Original mail as follows£º > > > > > > > > Dear Arturo, > > > > thanks for your comment. Prefix length assignment to end site > refer to > > some RFCs in the draft. The new things and main point I would like to > > express are in later sections. This draft gives the calculation > methods > > of address pool , and give an example of carving up addresses. Some > > considerations derived from actual network operation. I hope to > provide > > a reference for IPv6 address planning. > > > > Best regards. > > > > Qiongfang > > > > 2013-03-01 > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------ > > *·¢¼þÈË£º* Arturo Servin > > *·¢ËÍʱ¼ä£º* 2013-03-01 15:02:25 > > *ÊÕ¼þÈË£º* v6ops > > *³­ËÍ£º* > > *Ö÷Ì⣺* Re: [v6ops] new draft: draft-ma-v6ops-ipv6-address-assignment > > Dear authors, > > I read your draft and I think that the content is covered by the > > combination of RFC6177, RFC5375, RFC6164 and > > draft-ietf-v6ops-design-choices. So I am not sure what is the new > thing > > in this draft. > > Cheers, > > as > > On 19/02/2013 21:45, fred@cisco.com > > wrote: > >> > >> A new draft has been posted, at > http://tools.ietf.org/html/draft-ma-v6ops-ipv6-address-assignment. > Please take a look at it and comment. > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > > https://w > > > > > From leo.liubing@huawei.com Mon Mar 4 04:21:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE2021F8A0B for ; Mon, 4 Mar 2013 04:21:07 -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_33=0.6, 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 FqmyPlslkELc for ; Mon, 4 Mar 2013 04:21:02 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1126B21F89FB for ; Mon, 4 Mar 2013 04:21:01 -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 APA22655; Mon, 04 Mar 2013 12:21:01 +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.7; Mon, 4 Mar 2013 12:20:55 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 4 Mar 2013 12:21:00 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.42]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Mon, 4 Mar 2013 20:20:52 +0800 From: "Liubing (Leo)" To: "v6ops@ietf.org" Thread-Topic: ULA discussion #1 ULA+NAT Thread-Index: Ac4Y0qVmXOczhdgyTHaW1OIbGrg4zQ== Date: Mon, 4 Mar 2013 12:20:52 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6E5795@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 12:21:07 -0000 Hi, Dear all (Note: Thanks for your comments, those would help the authors a lot. I split and s= ummarize some topics from the discussion, for ease of further discussion, h= ope we can make some consensus. Any specific discussion please going to the= relevant thread, many thanks.) For ULA+NPTv6, as I understand according to the discussion, we considering = it because we want to get independence address space, then coming the compa= re of NPTv6 vs PI. (Please correct me if I mistakenly understood it) we mainly have two views: A: ULA+NPTv6 should be "Not recommended" in this document. Since we need to= promote E2E transparence in IPv6. NPTv6 broke the transparence and made mo= re overall cost by adjust the network/applications to fit the NAT environme= nt. Contrastively, acquiring a PI would not cost too much, and easy to depl= oy with BGP. B: "Not recommended" is way too much, we need fairly stating the pros and c= ons in the document. Since NPTv6 is a reasonable requirement of the real en= d-users. Configuring BGP for PI would not feet all the users, especially th= e small enterprises and home users. And needs no cost on RIR fees. Moreover= , no limited PI might potentially cause serious BGP4 scaling issue, conside= ring the multihoming requirement in IPv6 might explode. Please supplement if I missed some points, and hope more people could comme= nt on this topic.=20 Thanks a lot. Cheers, Bing From leo.liubing@huawei.com Mon Mar 4 04:45:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056E821F88A2 for ; Mon, 4 Mar 2013 04:45:00 -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_35=0.6, 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 XZyt3PhVTLsy for ; Mon, 4 Mar 2013 04:44:59 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 35D9721F85F3 for ; Mon, 4 Mar 2013 04:44:59 -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 APA24509; Mon, 04 Mar 2013 12:44:58 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 4 Mar 2013 12:44:52 +0000 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 4 Mar 2013 12:44:57 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.42]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Mon, 4 Mar 2013 20:44:52 +0800 From: "Liubing (Leo)" To: "v6ops@ietf.org" Thread-Topic: ULA discussion #2 ULA+Proxy Thread-Index: Ac4Y1gz2bOkZlj3DSNid7caKN60e0g== Date: Mon, 4 Mar 2013 12:44:52 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6E57B6@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [v6ops] ULA discussion #2 ULA+Proxy X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 12:45:00 -0000 In some environments (e.g. information security sensitive enterprise or gov= ernment), the endpoints are default disconnected to the Internet, and need = the proxies to connect. In IPv4, RFC1918+proxies is an effective practice f= or this purpose, and it is natural to pick ULA in IPv6. =20 The point in the draft is: if you really have such requirements, just use U= LA in this model; but it is not a recommended usage in normal cases. Do you agree? From victor@jvknet.com Mon Mar 4 05:04:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B73E21F853D for ; Mon, 4 Mar 2013 05:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.486 X-Spam-Level: X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, J_CHICKENPOX_42=0.6, RDNS_NONE=0.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 y8V6e-lwgJCo for ; Mon, 4 Mar 2013 05:04:10 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id A871E21F8539 for ; Mon, 4 Mar 2013 05:04:10 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id 16so5872674iea.8 for ; Mon, 04 Mar 2013 05:04:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:user-agent:date:subject:from:to:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=2xfXo2pTy7IC0XFyKlGiLX4cYBiJ2qVgT1lLGre1SeA=; b=ioxT5Dib1p6HV0Dmz0fbLhNztuU/N/Dv7DdjlXgcw0jBDvfk2FsRKkgAWaO2PuQ1Sk TrLlH5GOiL8FoRH7nENVc2IMfwrKuVobDmeox85OTyCVI2rN6sFgNzqirKYqv28CliYQ boFGxOfQQ4B3OntNf2Pvd6JQNFyptzIx9I0psuuW0w14F2eiY2xLP2ZvXE0GS8mF+lus +e3dQlYkDGGQV5t6AN3a7krlsJtzJZ3/RGlJJIobc5qWj79xqT8cwsK7uPFNSOtHu9nw rh4QnAYteKUYAEemPKr/SpK4gedgKrW3/S6q05BfT/s0XdlKxuznj8Bm4nP6ipbTc3Rz itKw== X-Received: by 10.50.207.39 with SMTP id lt7mr2335808igc.110.1362402246651; Mon, 04 Mar 2013 05:04:06 -0800 (PST) Received: from [192.168.100.33] ([67.224.83.162]) by mx.google.com with ESMTPS id xc3sm9274183igb.10.2013.03.04.05.04.04 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 04 Mar 2013 05:04:06 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Mon, 04 Mar 2013 08:04:01 -0500 From: Victor Kuarsingh To: "Liubing (Leo)" , "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6E5795@nkgeml506-mbx.china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQlDBENI9lVolGO+11D1Y6R6E7/w1Qjrl5IBTxlOjjlRXfLT+6ZDHZdGQYwnEJt9NLzYyZFV Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 13:04:12 -0000 Bing/group, Not that I am advocating for this option (which I am not), but is there not technically a third option which is present ULA+NPTv6 without providing a recommendation? I only note this for completeness of options. It's possible to not provide a specific recommendation. I am tempted, as are many, to supply a recommendation of "not recommended". But one concern I do have in the back of my mind is that if we do recommend something specific here, then the issue of consistency will come into play. I don't think this is the only draft which notes the use of NPTv6 and/or it's use along side ULA (not sure if this combo was specifically noted, but I know NPT shows up). So this recommendation, if made, would need to be sync'ed with those drafts (or not? I am not the expert here). One may also argue that much of the contention is around NPTv6 and not specifically ULA (I think there are different arguments for and against both). So the issue is, does a draft discussing ULA use cases, one of which includes NPTv6, need to be the one recommending it's use or not? Also, NPTv6 can be used without ULAs. Also, when I re-looked at RFC6296 (NPTv6) it already has discussion on use with ULAs along with some discussion. The RFC then has further references over to RFC5902 (IAB thoughts on IPv6 Network Address Translation) which then in turn has references to RFC4924 (Reflections of Internet Transparency). Perhaps those references, and extended references is sufficient in this case? Since RFC6296 is experimental, there is also an option to point to RFC5902 directly as it supplies discussion around the matter of translation for IPv6 from an architectural view. Sorry for looking like I am play both sides, but wanted to make sure we had all our cards on the table. Regards, Victor Kuarsingh On 2013-03-04 7:20 AM, "Liubing (Leo)" wrote: >Hi, Dear all > >(Note: >Thanks for your comments, those would help the authors a lot. I split and >summarize some topics from the discussion, for ease of further >discussion, hope we can make some consensus. Any specific discussion >please going to the relevant thread, many thanks.) > >For ULA+NPTv6, as I understand according to the discussion, we >considering it because we want to get independence address space, then >coming the compare of NPTv6 vs PI. (Please correct me if I mistakenly >understood it) > >we mainly have two views: >A: ULA+NPTv6 should be "Not recommended" in this document. Since we need >to promote E2E transparence in IPv6. NPTv6 broke the transparence and >made more overall cost by adjust the network/applications to fit the NAT >environment. Contrastively, acquiring a PI would not cost too much, and >easy to deploy with BGP. >B: "Not recommended" is way too much, we need fairly stating the pros and >cons in the document. Since NPTv6 is a reasonable requirement of the real >end-users. Configuring BGP for PI would not feet all the users, >especially the small enterprises and home users. And needs no cost on RIR >fees. Moreover, no limited PI might potentially cause serious BGP4 >scaling issue, considering the multihoming requirement in IPv6 might >explode. > >Please supplement if I missed some points, and hope more people could >comment on this topic. > >Thanks a lot. > >Cheers, >Bing > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From leo.liubing@huawei.com Mon Mar 4 05:08:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E595A21F8A94 for ; Mon, 4 Mar 2013 05:08:35 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAotRGMH+LU8 for ; Mon, 4 Mar 2013 05:08:35 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 11DE221F8A8E for ; Mon, 4 Mar 2013 05:08:34 -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 APA26364; Mon, 04 Mar 2013 13:08:34 +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.7; Mon, 4 Mar 2013 13:08:26 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 4 Mar 2013 13:08:31 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.42]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Mon, 4 Mar 2013 21:08:23 +0800 From: "Liubing (Leo)" To: "v6ops@ietf.org" Thread-Topic: ULA discussion #3 RFC1918 legacy Thread-Index: Ac4Y2UvQPrycUFlaRSa5QsdSjvlItQ== Date: Mon, 4 Mar 2013 13:08:23 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6E57E4@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [v6ops] ULA discussion #3 RFC1918 legacy X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 13:08:36 -0000 As Victor commented, "there are many functions which are served well by RFC= 1918 and with some loose association to ULAs (can be used for equivalent fu= nction)".=20 I think this is a good point, we can tell the readers in the draft, you can= consider migrating some successful practice/designs of RFC1918 to ULA in I= Pv6. But please keep in mind that ULA is not equal to RFC1918, when think o= f using ULA, don't misunderstand it as binding to NAT. One example is security, I think the consensus is that ULA itself doesn't c= ontain any inner security features, but it seems still controversy on wheth= er ULA could benefit security designs/policies: A: ULA could benefit for security, it's a lot easier to filter/protect agai= nst a well known contiguous range. B: There is no benefit to the range being well known outside of the filteri= ng domain. A /48 carved out of one's GUA would serve equally well to a /48 = from ULA.=20 Please correct me if I captured the comments mistakenly. And further discus= sion on this topic is welcomed. From leo.liubing@huawei.com Mon Mar 4 05:12:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A79A21F89EE for ; Mon, 4 Mar 2013 05:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.074 X-Spam-Level: X-Spam-Status: No, score=-6.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 MBdryBbOQc64 for ; Mon, 4 Mar 2013 05:12:55 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C013421F89E1 for ; Mon, 4 Mar 2013 05:12:54 -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 AQH32800; Mon, 04 Mar 2013 13:12:51 +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.7; Mon, 4 Mar 2013 13:12:45 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 4 Mar 2013 13:12:49 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.42]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Mon, 4 Mar 2013 21:12:42 +0800 From: "Liubing (Leo)" To: Victor Kuarsingh , "v6ops@ietf.org" Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT Thread-Index: Ac4Y0qVmXOczhdgyTHaW1OIbGrg4zf//hhOA//94gLA= Date: Mon, 4 Mar 2013 13:12:41 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6E57F5@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6E5795@nkgeml506-mbx.china.huawei.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.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 13:12:56 -0000 Hi, Victor > One may also argue that much of the contention is around NPTv6 and not > specifically ULA (I think there are different arguments for and against > both). So the issue is, does a draft discussing ULA use cases, one of > which includes NPTv6, need to be the one recommending it's use or not? > Also, NPTv6 can be used without ULAs. [Bing] This is also a confusing question for me.=20 > Also, when I re-looked at RFC6296 (NPTv6) it already has discussion on us= e > with ULAs along with some discussion. The RFC then has further reference= s > over to RFC5902 (IAB thoughts on IPv6 Network Address Translation) which > then in turn has references to RFC4924 (Reflections of Internet > Transparency). Perhaps those references, and extended references is > sufficient in this case? [Bing] I think it's a good point. Thanks for the information. From Ted.Lemon@nominum.com Mon Mar 4 05:17:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7F421F8A67 for ; Mon, 4 Mar 2013 05:17:52 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dd1z2ktJtOtt for ; Mon, 4 Mar 2013 05:17:51 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6E61C21F8A11 for ; Mon, 4 Mar 2013 05:17:46 -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 DSNKUTSe+h17fywcCdC2E0CQZtz7JVXSWlJT@postini.com; Mon, 04 Mar 2013 05:17:46 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 049BD1B80EA for ; Mon, 4 Mar 2013 05:17:46 -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 E8C66190043; Mon, 4 Mar 2013 05:17:45 -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, 4 Mar 2013 05:17:39 -0800 From: Ted Lemon To: Doug Barton Thread-Topic: [v6ops] ULA Usage Guide draft requesting for review Thread-Index: AQHOE1oj2qUAuv5aG0SBTJo7pMCvqZiLF6yAgAPxl4CAAfrRgIAAEn4AgAAp0oCAAQAFgIAALq0AgAAEpoCAAAjVgIAAcigAgACOigCAAUYAAIABAp4AgABO0IA= Date: Mon, 4 Mar 2013 13:17:39 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474AB9B9@mbx-01.win.nominum.com> References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> In-Reply-To: <51345CD6.3070807@dougbarton.us> 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: IPv6 Ops WG Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 13:17:52 -0000 On Mar 4, 2013, at 3:35 AM, Doug Barton wrote: > The fact that it took the content networks years to drag the IPv6 literat= i kicking and screaming into allowing for PI space is one excellent example= . The continuing failure to permit a full-featured DHCPv6 protocol is simil= arly slowing down adoption by the end-user networks. ? From gert@space.net Mon Mar 4 06:25:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626FE21F8A33 for ; Mon, 4 Mar 2013 06:25:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJxJ9Nm+78pM for ; Mon, 4 Mar 2013 06:25:34 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id C501D21F8A42 for ; Mon, 4 Mar 2013 06:25:32 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 406A5603F3 for ; Mon, 4 Mar 2013 15:25:30 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 129466038B for ; Mon, 4 Mar 2013 15:25:30 +0100 (CET) Received: (qmail 83728 invoked by uid 1007); 4 Mar 2013 15:25:30 +0100 Date: Mon, 4 Mar 2013 15:25:30 +0100 From: Gert Doering To: Ted Lemon Message-ID: <20130304142530.GP51699@Space.Net> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474AB9B9@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474AB9B9@mbx-01.win.nominum.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Ops WG Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 14:25:34 -0000 Hi, On Mon, Mar 04, 2013 at 01:17:39PM +0000, Ted Lemon wrote: > On Mar 4, 2013, at 3:35 AM, Doug Barton > wrote: > > The fact that it took the content networks years to drag the IPv6 literati kicking and screaming into allowing for PI space is one excellent example. The continuing failure to permit a full-featured DHCPv6 protocol is similarly slowing down adoption by the end-user networks. > > ? I think he's lamenting the lack of routing information in DHCPv6. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From gert@space.net Mon Mar 4 06:33:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA8321F85B4 for ; Mon, 4 Mar 2013 06:33:59 -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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=0.6] 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 QXf77FnO34pD for ; Mon, 4 Mar 2013 06:33:59 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 5022B21F85AD for ; Mon, 4 Mar 2013 06:33:58 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id B2C6A603A9 for ; Mon, 4 Mar 2013 15:33:57 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 88A0A6038B for ; Mon, 4 Mar 2013 15:33:57 +0100 (CET) Received: (qmail 86049 invoked by uid 1007); 4 Mar 2013 15:33:57 +0100 Date: Mon, 4 Mar 2013 15:33:57 +0100 From: Gert Doering To: "Liubing \(Leo\)" Message-ID: <20130304143357.GQ51699@Space.Net> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6E5795@nkgeml506-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6E5795@nkgeml506-mbx.china.huawei.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 14:33:59 -0000 Hi, On Mon, Mar 04, 2013 at 12:20:52PM +0000, Liubing (Leo) wrote: > B: "Not recommended" is way too much, we need fairly stating the pros and cons in the document. Since NPTv6 is a reasonable requirement of the real end-users. Configuring BGP for PI would not feet all the users, especially the small enterprises and home users. And needs no cost on RIR fees. Moreover, no limited PI might potentially cause serious BGP4 scaling issue, considering the multihoming requirement in IPv6 might explode. This. (Actually there's 3 options - BGP+PI, ULA+NPTv6, and PA space from the provider, potentially having multiple prefixes from multiple providers active at the same time. Which currently has more drawbacks than benefits, but has the potential to be more lightweight and at the same time more powerful than both BGP+PI and ULA+NPTv6 for "end user networks") Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From Ted.Lemon@nominum.com Mon Mar 4 07:06:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0F521F8C0B for ; Mon, 4 Mar 2013 07:06:57 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIvJwV2sqI29 for ; Mon, 4 Mar 2013 07:06:56 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 8797D21F8C09 for ; Mon, 4 Mar 2013 07:06:56 -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 DSNKUTS4kN3960lbdRZdJOEZ8g4sUxucnaiQ@postini.com; Mon, 04 Mar 2013 07:06: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 438451B80E9 for ; Mon, 4 Mar 2013 07:06:56 -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 39F0B190043; Mon, 4 Mar 2013 07:06:56 -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, 4 Mar 2013 07:06:56 -0800 From: Ted Lemon To: Gert Doering Thread-Topic: [v6ops] ULA Usage Guide draft requesting for review Thread-Index: AQHOE1oj2qUAuv5aG0SBTJo7pMCvqZiLF6yAgAPxl4CAAfrRgIAAEn4AgAAp0oCAAQAFgIAALq0AgAAEpoCAAAjVgIAAcigAgACOigCAAUYAAIABAp4AgABO0ICAABL1AIAAC5IA Date: Mon, 4 Mar 2013 15:06:55 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474ABDDC@mbx-01.win.nominum.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474AB9B9@mbx-01.win.nominum.com> <20130304142530.GP51699@Space.Net> In-Reply-To: <20130304142530.GP51699@Space.Net> 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: <90211585501EC242BC15002607BA696B@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 15:06:57 -0000 On Mar 4, 2013, at 9:25 AM, Gert Doering wrote: > I think he's lamenting the lack of routing information in DHCPv6. Huh. That's not what I would call out as DHCPv6's biggest lack... :) From gert@space.net Mon Mar 4 07:09:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99C221F8839 for ; Mon, 4 Mar 2013 07:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] 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 h9EzREMU1IpI for ; Mon, 4 Mar 2013 07:09:36 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id F2EF821F86C8 for ; Mon, 4 Mar 2013 07:09:32 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 1F29E603FB for ; Mon, 4 Mar 2013 16:09:32 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id F1CCF603A9 for ; Mon, 4 Mar 2013 16:09:31 +0100 (CET) Received: (qmail 354 invoked by uid 1007); 4 Mar 2013 16:09:31 +0100 Date: Mon, 4 Mar 2013 16:09:31 +0100 From: Gert Doering To: Ted Lemon Message-ID: <20130304150931.GW51699@Space.Net> References: <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474AB9B9@mbx-01.win.nominum.com> <20130304142530.GP51699@Space.Net> <8D23D4052ABE7A4490E77B1A012B6307474ABDDC@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="e1ChYoNPu7XngBZh" Content-Disposition: inline In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474ABDDC@mbx-01.win.nominum.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Ops WG Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 15:09:36 -0000 --e1ChYoNPu7XngBZh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Mar 04, 2013 at 03:06:55PM +0000, Ted Lemon wrote: > On Mar 4, 2013, at 9:25 AM, Gert Doering > wrote: > > I think he's lamenting the lack of routing information in DHCPv6. >=20 > Huh. That's not what I would call out as DHCPv6's biggest lack... :) So what is it that you're missing? "Sane implementations" is not really something the IETF can provide. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --e1ChYoNPu7XngBZh Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQCVAwUBUTS5K6kuBuNlUUl1AQJz/wP/UWHPXKbdllrqfMiJkZs0VLQLlkNmdOy9 T2Uv1DXULDW86CUr9/yqIw19X3XRntScvrItHQZR7cXljWvcfQIXojnLg6Wmy4ku dvHECf50uJMoSZcRt7OnjJ76j89ApIvHdifee45SB1+u5q5gIa5Je6yOJQDzOngP pJcOfMudPkg= =lAGk -----END PGP SIGNATURE----- --e1ChYoNPu7XngBZh-- From Ted.Lemon@nominum.com Mon Mar 4 07:12:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8A921F8C3F for ; Mon, 4 Mar 2013 07:12:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KM-cbaYnZk+w for ; Mon, 4 Mar 2013 07:12:23 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 77A8421F8C2D for ; Mon, 4 Mar 2013 07:12:23 -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 DSNKUTS50RGndoeTjIE5FShVy+Szs0OHQ2wY@postini.com; Mon, 04 Mar 2013 07:12:23 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 2716A1B80EA for ; Mon, 4 Mar 2013 07:12:17 -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 2065C190043; Mon, 4 Mar 2013 07:12:17 -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, 4 Mar 2013 07:12:11 -0800 From: Ted Lemon To: Gert Doering Thread-Topic: [v6ops] ULA Usage Guide draft requesting for review Thread-Index: AQHOE1oj2qUAuv5aG0SBTJo7pMCvqZiLF6yAgAPxl4CAAfrRgIAAEn4AgAAp0oCAAQAFgIAALq0AgAAEpoCAAAjVgIAAcigAgACOigCAAUYAAIABAp4AgABO0ICAABL1AIAAC5IAgAAAu4CAAAC9AA== Date: Mon, 4 Mar 2013 15:12:11 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474ABE70@mbx-01.win.nominum.com> References: <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474AB9B9@mbx-01.win.nominum.com> <20130304142530.GP51699@Space.Net> <8D23D4052ABE7A4490E77B1A012B6307474ABDDC@mbx-01.win.nominum.com> <20130304150931.GW51699@Space.Net> In-Reply-To: <20130304150931.GW51699@Space.Net> 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: <6FDA23C5AF13124A89C142CCC46B72FE@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 15:12:24 -0000 On Mar 4, 2013, at 10:09 AM, Gert Doering wrote: > So what is it that you're missing? "Sane implementations" is not really > something the IETF can provide. Support for multiple provisioning domains is high on my list. Support for= DNS zone maintenance as well. From nalini.elkins@insidethestack.com Mon Mar 4 08:35:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B88821F8A1C for ; Mon, 4 Mar 2013 08:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 ejJPtsvJ4mCn for ; Mon, 4 Mar 2013 08:35:32 -0800 (PST) Received: from nm6-vm0.access.bullet.mail.sp2.yahoo.com (nm6-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.114]) by ietfa.amsl.com (Postfix) with ESMTP id A102021F89D3 for ; Mon, 4 Mar 2013 08:35:32 -0800 (PST) Received: from [98.139.44.103] by nm6.access.bullet.mail.sp2.yahoo.com with NNFMP; 04 Mar 2013 16:35:32 -0000 Received: from [98.139.44.66] by tm8.access.bullet.mail.sp2.yahoo.com with NNFMP; 04 Mar 2013 16:35:32 -0000 Received: from [127.0.0.1] by omp1003.access.mail.sp2.yahoo.com with NNFMP; 04 Mar 2013 16:35:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 503499.23470.bm@omp1003.access.mail.sp2.yahoo.com Received: (qmail 57007 invoked by uid 60001); 4 Mar 2013 16:35:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362414932; bh=nTJt2K9drmTdLyjjU5yTqxEdw0tdIJSbYDPNh37Ruy4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=3qFmCFbLB/dOzTiHT5S2HKL4l9H9ktK2AtWBd738DNo8ZMWh42aG8APBl/2nCYBeqKWp8LmyACeAdYILn1fb2zPoHGxN+q3VxlmOzpjx4f+/G+EYhdJvircVhIPgG1KlU80CvDRm7R/fFUbs6eIq29KJQ3qCmEtqOBZCNNb6xGY= X-YMail-OSG: mPzehKwVM1mzWWeU1WwD7GGtoJigSpbbPHi6ZblyvRQNRru 94tjBR0m7X.fm5TS5UqV8t9BKJeVaFvf_OCOS5X8lIHqKbVfCDwiP5B6ZBqn 3eVFwEfIKoUvX24X9eMfL52EIN3BIY8MHJM.BSfS6kTi.GrM6pdTvYFGHy3a _vvAWxn2i6FBYosPnjAoZQDEisx.pIR5kRxCY3L9bwiTcOwkqTZHgNzvraFb kZpA17jlSzu_fGFCqrsgn1hGegM0HfViQ5On5Z_r5_Tvy85kZJFbOUv8DyxV mRDoQ_1hpaxJ66tBOoDzUF2SRaJ3eULbO27GU_yl4IxZKKJGlYOMiM8M1gbI NGSHCxPJ6eK1J5AxJd.ieNsnymeO6SyJx2D_ZUtXoeNYJd309NsDRWGczIHV Q_2WZ_FJmDea.sIVxaD84Py4L7_jOToN9DgZX.ui56ziS7hHtTUkNa83jfdr Vku2KZ9GXX6I6UYK98EQMoSFoGPjLRoCxHH1J0NgWIisSjH7OYcMBbY5z.C4 wwWn6SgbAQInqHDSS0wxQCaQHN2_Ei30bFjzMCvED103f3YXG1DSIzSAFkDC hpi9xu.B2cEeYc3oUoK_vzrfiT4ijlfQYtQqRaQ-- Received: from [24.130.37.147] by web2805.biz.mail.ne1.yahoo.com via HTTP; Mon, 04 Mar 2013 08:35:32 PST X-Rocket-MIMEInfo: 001.001, V2Ugd291bGQgbGlrZSB0byBpbnZpdGUgZXZlcnlvbmUgdG8gYSBzbmFjayBCb0YgdG8gdGFsayBhYm91dCB0aGUgc3BlY2lhbCBuZWVkcyBvZiBlbmQgdXNlciBvcmdhbml6YXRpb25zIHdobyBydW4gbGFyZ2UgZGF0YSBjZW50ZXJzLiDCoCBJdCB3aWxsIGJlIG9uIFdlZC4gTWFyY2ggMTN0aMKgMTcxMC0xNzQwwqBhdCBvbmUgZW5kIG9mIHRoZSBDYXJpYmJlYW4gRm95ZXIgd2hlcmUgdGhlIGJldmVyYWdlIGFuZCBzbmFjayBicmVhayBpcyBoZWxkLiDCoCBPdXIgZ3JvdXAgaW5jbHVkZXMgdGhyZWUgbGFyZ2UBMAEBAQE- X-Mailer: YahooMailWebService/0.8.135.514 References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474AB9B9@mbx-01.win.nominum.com> <20130304142530.GP51699@Space.Net> Message-ID: <1362414932.44346.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Mon, 4 Mar 2013 08:35:32 -0800 (PST) From: Nalini Elkins To: IPv6 Ops WG In-Reply-To: <20130304142530.GP51699@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [v6ops] Snack BoF - Large End User Organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 16:35:36 -0000 We would like to invite everyone to a snack BoF to talk about the special n= eeds of end user organizations who run large data centers. =A0 It will be o= n Wed. March 13th=A01710-1740=A0at one end of the Caribbean Foyer where the= beverage and snack break is held. =A0 Our group includes three large end u= ser organizations. =A0We hope to talk with anyone who is interested in such= issues.=0A=0AFor whoever wants to, we can continue after the IETF and Oper= ations Plenary & over dinner & drinks.=0A=0AThere has been some discussion = on this list about addressing 'real-world' problems. =A0We could not agree = more!=0A=0A=0AThanks,=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 65= 9-8360=0Awww.insidethestack.com=0A=0A=0A=0A________________________________= =A0 From michelg@upperside.fr Mon Mar 4 10:04:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA9121F8C58 for ; Mon, 4 Mar 2013 10:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UkM5scM3Ysm for ; Mon, 4 Mar 2013 10:04:27 -0800 (PST) Received: from smtp03.msg.oleane.net (smtp03.msg.oleane.net [62.161.4.3]) by ietfa.amsl.com (Postfix) with ESMTP id 6E20821F8C59 for ; Mon, 4 Mar 2013 10:04:27 -0800 (PST) Received: from MichelGosseDel ([195.6.217.229]) (authenticated) by smtp03.msg.oleane.net (MSA) with ESMTP id r24I4JKK018613 for ; Mon, 4 Mar 2013 19:04:19 +0100 X-Oleane-Rep: REPA From: "Michel Gosse" To: References: <000b01ce18fa$d06edc60$714c9520$@upperside.fr> <2125400139-1362419521-cardhu_decombobulator_blackberry.rim.net-1996175759-@b27.c2.bise7.blackberry> In-Reply-To: <2125400139-1362419521-cardhu_decombobulator_blackberry.rim.net-1996175759-@b27.c2.bise7.blackberry> Date: Mon, 4 Mar 2013 19:04:13 +0100 Message-ID: <001c01ce1902$b20a6de0$161f49a0$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01CE190B.13D11FD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIe+PEmuROSdIlK0A5RoTIUFzSkgQHlkcPWl+TkcNA= Content-Language: fr X-PMX-Spam: Probability=8% X-PFSI-Info: PMX 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.4.174815 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Subject: [v6ops] V6 World Paris 19/22 March 2013: Going Mobile X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 18:04:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001D_01CE190B.13D11FD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The third edition will be mainly dedicated to mobile implementations. Other sessions will cover BYOD, security, measurement and "IPv6 only" developments. More information: http://www.uppersideconferences.com/ ------=_NextPart_000_001D_01CE190B.13D11FD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The third edition will be mainly dedicated to mobile = implementations.


Other sessions will cover BYOD, security, = measurement and "IPv6 only" = developments.

 

More information: http://www.uppersideconfere= nces.com/

 

 

 

 

------=_NextPart_000_001D_01CE190B.13D11FD0-- From gert@space.net Mon Mar 4 11:00:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3981B21F8CCA for ; Mon, 4 Mar 2013 11:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 xD2K9DJsw0m7 for ; Mon, 4 Mar 2013 11:00:35 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 8547F21F8CB7 for ; Mon, 4 Mar 2013 11:00:34 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 0ED9C60429 for ; Mon, 4 Mar 2013 20:00:33 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id DA09E60419 for ; Mon, 4 Mar 2013 20:00:32 +0100 (CET) Received: (qmail 89772 invoked by uid 1007); 4 Mar 2013 20:00:32 +0100 Date: Mon, 4 Mar 2013 20:00:32 +0100 From: Gert Doering To: Ted Lemon Message-ID: <20130304190032.GX51699@Space.Net> References: <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474AB9B9@mbx-01.win.nominum.com> <20130304142530.GP51699@Space.Net> <8D23D4052ABE7A4490E77B1A012B6307474ABDDC@mbx-01.win.nominum.com> <20130304150931.GW51699@Space.Net> <8D23D4052ABE7A4490E77B1A012B6307474ABE70@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yqcO0GZttnvejj/u" Content-Disposition: inline In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474ABE70@mbx-01.win.nominum.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Ops WG Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 19:00:38 -0000 --yqcO0GZttnvejj/u Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Mar 04, 2013 at 03:12:11PM +0000, Ted Lemon wrote: > On Mar 4, 2013, at 10:09 AM, Gert Doering wrote: > > So what is it that you're missing? "Sane implementations" is not really > > something the IETF can provide. >=20 > Support for multiple provisioning domains is high on my list. Support f= or DNS zone maintenance as well. But that's all in the "all software sucks" domain, not that much IETF=20 standards can do about it. Or am I misunderstanding you? The general beef in the IETF IPv6 working groups seems to be that one camp wants "everything that's needed to configure a host" in RA, and the other camp thinks DHCP is good enough for everything and thinks having to run RA as well is evil, and should not be done. Or such. I think people from both camps should be drowned somewhere, for refusing=20 to acknowledge that networks in the real world out of their ivory towers=20 *differ* in nature, and some would benefit from "just RA" while others=20 might want "just DHCPv6". Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --yqcO0GZttnvejj/u Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQCVAwUBUTTvUKkuBuNlUUl1AQIEqQP9E6tDQoFfChnRQP8+C/utbF/aM8hadVEB z0KVRTYozRPbn1DBT2MmXmfN6HhY6K74sPijZhprAZVeWB6ZKNVVIEjMCZUhnyoD ZiuEo+wEJOxkZ6paq1qv28NAlDlnTOaPEE3xtR/fGTcqX97fJIxUIuzelyCjty3r fyGPGDEZ4qg= =UA5r -----END PGP SIGNATURE----- --yqcO0GZttnvejj/u-- From owen@delong.com Mon Mar 4 12:21:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F6E21F8F63 for ; Mon, 4 Mar 2013 12:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.45 X-Spam-Level: X-Spam-Status: No, score=0.45 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVyTdIzpS1xK for ; Mon, 4 Mar 2013 12:21:40 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA6B21F8BEB for ; Mon, 4 Mar 2013 12:21:39 -0800 (PST) Received: from [IPv6:2001:470::a9:1da1:6d5a:9a7e:7f8f] ([IPv6:2001:470:0:a9:1da1:6d5a:9a7e:7f8f]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r24KHhSf007128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 Mar 2013 12:17:44 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r24KHhSf007128 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362428264; bh=89g1y2AekdwC61wcOTs8jvk3DYg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=uhX+QlnuyqCowroizBHj/owKqTh6+Sw45Hm3JzNIVaULO4Xo/O/lu9uNXpw3tgXsm KVN8kmOtSGPrvVJYZJwzGOKdAJDTKqwBBhkt2dHtUDbRBMc45DtS0iGMpOEOZ14pIk 1m4IJTC6twibYWG3kuF7VWPuXfi9SN7/JoSIoU10= Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <51348007.5080509@gmail.com> Date: Mon, 4 Mar 2013 12:17:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5134740A.2050500@gmail.com> <51348007.5080509@gmail.com> To: Arturo Servin X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 04 Mar 2013 12:17:44 -0800 (PST) Cc: v6ops@ietf.org, m qf Subject: Re: [v6ops] new draft: draft-ma-v6ops-ipv6-address-assignment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 20:21:41 -0000 I have to say I agree with Arturo on this. Fields like flags and some of = the other concepts introduced here should be migrated to the semantic addressing discussion. Owen On Mar 4, 2013, at 3:05 AM, Arturo Servin = wrote: >=20 > That is not clear to me. >=20 > If I were new on IPv6 I would be very confuse how to make an = allocation > plan after reading your draft. >=20 > Regards, > as >=20 > On 04/03/2013 08:40, m qf wrote: >> Arturo, >>=20 >> in section 5, the address is curved into some fields considering the >> aggregation and management. I would like to know what are your main >> considerationin your addressing plan. Thanks a lot. >>=20 >> Best regards. >>=20 >>=20 >> 2013/3/4 Arturo Servin > > >>=20 >> Qiongfang, >>=20 >> Still I am not convinced, also, in section 5 you talk = about >> "flags" >> while in my understanding is not what we do today in making our >> addressing plans that are basically based on aggregation and = location. >>=20 >> Regars, >> as >>=20 >> On 04/03/2013 08:02, m qf wrote: >>>=20 >>> The mailing list seems to have some problems, I can not receive my >> mail >>> to the v6ops@ietf.org >> >. so I try again = using >>> another mail address. Original mail as follows=A3=BA >>>=20 >>>=20 >>>=20 >>> Dear Arturo, >>>=20 >>> thanks for your comment. Prefix length assignment to end site >> refer to >>> some RFCs in the draft. The new things and main point I would like = to >>> express are in later sections. This draft gives the calculation >> methods >>> of address pool , and give an example of carving up addresses. Some >>> considerations derived from actual network operation. I hope to >> provide >>> a reference for IPv6 address planning. >>>=20 >>> Best regards. >>>=20 >>> Qiongfang >>>=20 >>> 2013-03-01 >>>=20 >> = ------------------------------------------------------------------------ >>>=20 >>>=20 >> = ------------------------------------------------------------------------ >>> *=B7=A2=BC=FE=C8=CB=A3=BA* Arturo Servin >>> *=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA* 2013-03-01 15:02:25 >>> *=CA=D5=BC=FE=C8=CB=A3=BA* v6ops >>> *=B3=AD=CB=CD=A3=BA* >>> *=D6=F7=CC=E2=A3=BA* Re: [v6ops] new draft: = draft-ma-v6ops-ipv6-address-assignment >>> Dear authors, >>> I read your draft and I think that the content is covered by the >>> combination of RFC6177, RFC5375, RFC6164 and >>> draft-ietf-v6ops-design-choices. So I am not sure what is the new >> thing >>> in this draft. >>> Cheers, >>> as >>> On 19/02/2013 21:45, fred@cisco.com >> > wrote: >>>>=20 >>>> A new draft has been posted, at >> http://tools.ietf.org/html/draft-ma-v6ops-ipv6-address-assignment. >> Please take a look at it and comment. >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org > > >>> https://w >>>=20 >>=20 >>=20 >>=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From owen@delong.com Mon Mar 4 12:27:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC25B21F9032 for ; Mon, 4 Mar 2013 12:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.175 X-Spam-Level: X-Spam-Status: No, score=-0.175 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zC4DelTw-CJP for ; Mon, 4 Mar 2013 12:27:01 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 100AB21F8F08 for ; Mon, 4 Mar 2013 12:27:00 -0800 (PST) Received: from [IPv6:2001:470::a9:1da1:6d5a:9a7e:7f8f] ([IPv6:2001:470:0:a9:1da1:6d5a:9a7e:7f8f]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r24KPaVh007333 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 Mar 2013 12:25:36 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r24KPaVh007333 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362428737; bh=v+p6cLgxUWv40R9S5I48SE4EHdU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=EJZ4fybncwc6cZXbG7v9Chz0tZ4fHmhl529h4oSn5K6xovhiM7u7HPSRAKEq+SByo eae7hrCMSCpmXGZLIGkzeAA0OFSzN2ujbU37KUEyxB3pazRbGRuY6Iq5KRzoOkSdLd d4M5AtkOCTQgJ0LbMfJgcDuzpzLPPdbZeCAB44tU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <20130304143357.GQ51699@Space.Net> Date: Mon, 4 Mar 2013 12:25:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7A7F3288-3C21-4C27-8653-F90066F0BC38@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6E5795@nkgeml506-mbx.china.huawei.com> <20130304143357.GQ51699@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 04 Mar 2013 12:25:37 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 20:27:01 -0000 I'm fine if we don't mention NPT in the draft. If we are going to mention NPT, then I will strenuously object unless = the draft also contains language specifying that any form of address = translation is not recommended. Owen On Mar 4, 2013, at 6:33 AM, Gert Doering wrote: > Hi, >=20 > On Mon, Mar 04, 2013 at 12:20:52PM +0000, Liubing (Leo) wrote: >> B: "Not recommended" is way too much, we need fairly stating the pros = and cons in the document. Since NPTv6 is a reasonable requirement of the = real end-users. Configuring BGP for PI would not feet all the users, = especially the small enterprises and home users. And needs no cost on = RIR fees. Moreover, no limited PI might potentially cause serious BGP4 = scaling issue, considering the multihoming requirement in IPv6 might = explode. >=20 > This. >=20 > (Actually there's 3 options - BGP+PI, ULA+NPTv6, and PA space from the > provider, potentially having multiple prefixes from multiple providers > active at the same time. Which currently has more drawbacks than = benefits, > but has the potential to be more lightweight and at the same time more > powerful than both BGP+PI and ULA+NPTv6 for "end user networks") >=20 > Gert Doering > -- NetMaster > --=20 > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. = Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From owen@delong.com Mon Mar 4 12:55:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6828521F8DEF for ; Mon, 4 Mar 2013 12:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6] 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 F8LSRIv2EI2t for ; Mon, 4 Mar 2013 12:55:56 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A455E21F8E1D for ; Mon, 4 Mar 2013 12:55:55 -0800 (PST) Received: from [10.255.251.216] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r24Kot8J007905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 Mar 2013 12:50:55 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r24Kot8J007905 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362430256; bh=qznyCarGbCA6+dx/6sF9Y3i8Q5k=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=kKD12Jqj+mTwq9GV71TT2tTAA4XAH4HA21KYu0IKW4JVZuQj3tjbHhEZRfaTGjXa7 R3sR89y/plhZFEowGKqJM0iwczTaYBQor/Ctm4HRyM07B0wHXeJIRytloOGBaIjayO svuZ9jK1XMKsZaddVll1VrQMTGjYYP8oC1L7KCgo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <513457E6.6060201@dougbarton.us> Date: Mon, 4 Mar 2013 12:50:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <3B96D0EE-B19F-4770-85D0-F7C2136F0BEA@delong.com> <513299CE.20509@dougbarton.us> <1364B842-D3BE-48C1-A2A5-3D74DC37DB4A@delong.com> <513457E6.6060201@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 04 Mar 2013 12:50:56 -0800 (PST) Cc: v6ops@ietf.org Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 20:55:58 -0000 On Mar 4, 2013, at 12:14 AM, Doug Barton wrote: > Given that we've entered the "misquote/misrepresent what I wrote in = the past" phase of the discussion, I will restate my position one more = time, then stop boring people. :) >=20 > The short version for the list is that I definitely think fairly = stating the pros and cons of the various alternatives would be a = valuable addition to the document. I think that saying ULA + NPTv6 is = "not recommended" is way too much. >=20 > Regarding this most recent post ... >=20 > When I said "poorly written," I was referring to those applications = still using the old get*by*() functions instead of more modern ones like = getaddrinfo() which bring you IPv6 compatibility basically for free. = OTOH, in this day and age any application that needs to allow outside = hosts to connect in which doesn't have a NAT traversal strategy is in = fact poorly written. What on earth does that have to do with whether they survive or function = correctly in a NAT/NPT world or not? As to the latter, it is an assertion which assumes multiple "facts" not = in evidence. > Your example of desktop collaboration software will work perfectly = well inside the firewall, where NPT is irrelevant. There are precious = few enterprises that allow any connections in, whether they use NAT or = not. This isn't going to change, and is one of the chief reasons why the = whole "we need to go back to the end-to-end model" mantra is so much = foolishness. There's lots of desktop collaboration that occurs outside of the = enterprise world. Further, with the ever increasing level of BYOD, = multiple connectivities, etc. I think that our authentication and = authorization models for network traffic are going to change = significantly in the future, especially when you consider things that = are possible with MIP6. I think you'll see more end-to-end ESP/AH used = rather than straight firewalls and that you will see direct untranslated = traversal through the firewall of packets which are part of valid = existing security associations or which are intended to set up such = security associations. > My "zero cost" comment was in the context of RIR fees, which you = conveniently snipped out. I have never said that ULA + NPT comes with = absolutely no cost at all, any more than NAT, PI, or PA space do. That = is why a fair discussion of the tradeoffs will be valuable. You stated that one option had costs and the other option did not. I = pointed out (rightly so) that you were choosing to focus on one of the = costs in the overall system and ignoring the others. It's sort of like saying that driving a private car is a no-cost option = because you don't have to pay a fare every time you get into the car = while ignoring the cost of gasoline, maintenance, and vehicle = registration. I admit that this is a popular way for enterprises to look at the issue = of NAT vs. PI, but it doesn't change the facts of the matter. > Finally, enterprises HATE renumbering. The costs associated are not = merely limited to giving systems new addresses, they include changing = firewall rules, ACLs, applications, configurations, etc. I could tell = you horror stories about how deeply embedded bad assumptions and = practices are rampant in the average enterprise, but the short version = is that enterprises hate renumbering, and not without good reason. = Telling an enterprise "renumbering is easy, it only takes a month" would = get me laughed out of the room. As I said, one has to plan ahead and construct the network with the = anticipation of renumbering up front, or it does, indeed, hurt at least = once. In IPv4, it was virtually impossible to do so and such assumptions = are rampant. In IPv6, it would be easy for such assumptions to become = rampant, but we do have the option of doing it better this time and we = should try to make use of that option. > In short, ULA + NPTv6 meets a real need, in spite of the costs, and = should be included in the analysis of any solution matrix in this space. In short, ULA+NPTv6 may provide convenience for those that are too lazy = to learn to do things right, but that's far from meeting a real = legitimate need. Owen >=20 > Doug >=20 >=20 > On 03/03/2013 01:28 AM, Owen DeLong wrote: >>>> That statement shows a profound misunderstanding of the situation. >>>>=20 >>>> Most applications haven't yet been ported to IPv6. Adding support = for >>>> IPv6 NPT and NAT traversal is _NOT_ a sunk cost. Further, the wide >>>> variety of NATs and other oddities surrounding network behavior >>>> related to NAT require substantial regression testing and QA for >>>> every release. That's _NOT_ a sunk cost. It's an ongoing tax. >>>=20 >>> Assuming you are right about all of this (which to some extent you >>> are, but for sake of argument let's say you're 100% right) it still >>> doesn't matter. Adding NPTv6 support is in the statistical noise = from >>> a development perspective. Well-written applications need little or = no >>> additional development work to support IPv6, poorly written ones = will >>> need to be updated, but that's going to be true regardless, and = adding >>> NPT support is still going to be a small marginal cost. >>=20 >> Again, I cannot agree with you here. Your attempt to classify any >> application that wants to be talking end-to-end without having its >> packets mutilated along the way as "poorly written" simply doesn't = hold >> water. There are lots f reasons to want to be able to communicate >> (reasonably) directly and not all of them involve including layer 3 >> addressing as layer 7 payload (which I believe is what you actually >> intended to target). >>=20 >> Consider, for example, the desire to host some sort of collaborative >> process on a desktop machine without requiring a third-party = rendezvous >> server. That's not a poorly written application, it's a perfectly = valid >> one which requires that the host machine have an accessible global = address. >>=20 >> Sure, some enterprises may want to block such activities and they can = do >> that perfectly well through policy and stateful inspection. No need = for >> NPT and NPT brings no benefit to that process. >>=20 >>> The ongoing "tax" you refer to is going to be paid regardless, = because >>> v4 NAT is never, ever going away; and we're 20-30 years away from v4 >>> support being a thing of the past. >>=20 >> I disagree. I think IPv4 will drop into the noise much faster than = you >> expect because it will become so completely expensive to maintain = that >> nobody will want to touch it. >>=20 >>>=20 >>>> The question is not whether NAT will exist or not, but, whether it >>>> will remain in use by a sufficiently large mass to drive the >>>> industry. Many of us are still holding out hope that with IPv6, it >>>> will not. It's still possible and it's a perfectly valid reason to >>>> state in an RFC discussing intended uses of ULA that NPT and NAT = are >>>> NOT recommended in IPv6. >>>=20 >>> Yes, I understand your position thoroughly. My point is that "not >>> recommended" is at best pollyanish, and at worst counter productive. >>> OTOH, a fair, rational discussion of the tradeoffs is beneficial to >>> all concerned. >>=20 >> I'm all for a fair rational discussion of the tradeoffs. However, I >> think it is reasonable and prudent at the end of that discussion to >> include the conclusion that damaging the protocol in such a manner is >> not recommended. >>=20 >>>=20 >>>>>> NPT and NAT are the network equivalent of the toxic polluter = model. >>>>>> Sure, it's cheap to dump toxic chemicals into the creek upstream. = The >>>>>> true costs are borne by those downstream, not the person dumping = the >>>>>> chemicals. >>>>>=20 >>>>> Histrionics don't help here. And saying these kinds of things to >>>>> serious people who already have/like their v4 NAT makes us all = look >>>>> foolish, and ensures that the people you're trying to persuade = will >>>>> not take v6 seriously. >>>>>=20 >>>>=20 >>>> This isn't histrionics. It's a simple fact... Deploying NAT/NPT = does, >>>> in fact, inflict costs on others that are not borne by those >>>> deploying NAT and those costs are not currently considered by most >>>> NAT fanatics. >>>=20 >>> "Toxic waste" analogies are histrionic by definition. And even if I >>> fully agreed with your arguments about how bad NAT is, telling = people >>> that use/like it that they are the network equivalent to toxic waste >>> dumpers is not only not helping, it's hurting. >>=20 >> =46rom webseter: >>=20 >>=20 >> Definition of /HISTRIONICS/ >>=20 >> 1 >> *:* theatrical performances >> 2 >> *:* deliberate display of emotion for effect >>=20 >> I don't think it qualifies as a theatrical performance. >> It wasn't a display of emotion, it was a simple analogy about who = pays >> the true cost. >>=20 >>>>>>> Even for those end-user networks where PI space makes sense (and = I >>>>>>> would argue that they are few and far between) the costs, both >>>>>>> monetary in terms of RIR fees, and opex; are non-zero, so >>>>>>> discussing the pros _and_ cons of all the solutions will have = value >>>>>>> for the target audience. >>>>>>=20 >>>>>> An up front $1,250 and an annual $100 is _NOT_ a significant = expense >>>>>> IMHO >>>>>=20 >>>>> Great! I'll send you my PayPal info and you can put that amount in >>>>> my account. Heck, I'll even give you a discount, say an even = grand? >>>>>=20 >>>>=20 >>>> Very funny. >>>=20 >>> So what you're saying is that you would consider sending me $1,000 = to >>> be a not-insignificant expense? >>>=20 >>=20 >> No, what I'm saying is that I had no problem paying for my PI = assignment >> and I cannot imagine an actual business operation that wants to be >> multihomed finding it difficult to cover the minimal expenses = involved >> in obtaining addresses to do so. >>=20 >> Given the number of different things involved in just creating a >> business that cost more than that, I don't find it a very credible = argument. >>=20 >>>>> Seriously though, When you look at the options of zero cost, vs. >>>>> some non-zero cost, it's hard for most organizations to justify, >>>>> especially when the reason we think they should pay it doesn't = line >>>>> up with their operational needs. >>>>>=20 >>>>=20 >>>> I suppose that's because you aren't considering all of the costs. = ULA >>>> isn't free. NPT isn't free. The fact that you want to pretend it is >>>> doesn't make it so. >>>=20 >>> I'm not saying it's free, I'm saying "Let's rationally discuss the >>> tradeoffs." It is unarguably true that ULA does not require an RIR >>> fee, but putting down the other costs in writing will help people to >>> make up their minds about which costs they are willing to bear. >>=20 >> Your quote (still present above) states "zero cost". That's the same = as >> 'free" by most people's definition, so yes, you did say it was free. >> It's in your quote above. >>=20 >> A rational discussion of the tradeoffs has to include the real costs, >> regardless of who bears them. People who like/want NAT like/want it >> because it allows them to dump the cost burden on others. Admittedly, >> many of them do not realize that they are doing so, just like there = was >> a time when people didn't realize the impact that dumping stuff in = the >> oceans was having. >>=20 >>>=20 >>>> I would bet that the annualized cost of maintaining all the extra >>>> code and the additional security risks involved in running a = network >>>> with translation far exceed $100/year. So much so that I bet you = get >>>> your $1,250 back in less than 4 years. For most finance people, >>>> that's what they call a no-brainer. >>>=20 >>> ... except for my now-oft-repeated point that those costs are never >>> going to go away. Not to mention that most enterprise end-user >>> networks are not in the business of code development, so your = concern >>> doesn't apply to them. >>=20 >> Yes, you keep repeating this, but it isn't true and repeating it = doesn't >> make it true just because you want it to be true. >>=20 >> I already agreed with you about the last part... In fact, that's the >> part that lines up with the toxic polluter as an analogy, not >> histrionics. Unfortunately, you were too caught up in dismissing what = I >> was saying as histrionics to actually look at the metaphor. >>=20 >>>>>> and that is what PI /48 costs from ARIN. I don't know about the >>>>>> other RIRs. >>>>>>=20 >>>>>> In terms of Opex, PI costs no more and probably somewhat less = than >>>>>> NPT because if it is set up correctly, it's basically fire and >>>>>> forget. >>>>>=20 >>>>> I'm far from a network expert, but I would think that coordinating >>>>> your ISP announcing your PI block would take more effort in both >>>>> setup and ongoing updates/monitoring than it would to set up NPTv6 >>>>> on the border. The latter only needs to be changed/updated when = you >>>>> change providers. But I'm happy to concede this point to anyone = who >>>>> can provide solid facts. >>>>>=20 >>>>=20 >>>> It shows. On the other hand, I've got almost 30 years of experience >>>> as a network expert and have actually done this many times. >>>> Coordinating your ISP accepting your announcement of your block and >>>> forwarding it on usually takes an email or two, sometimes including = a >>>> form. In terms of ongoing updates, there actually aren't usually = any >>>> unless/until you switch providers. >>>>=20 >>>> Those are the solid facts. I'm not sure what else you want. >>>=20 >>> So ISPs never reconfigure routers, BGP sessions never flap, nothing >>> ever happens with this kind of configuration that needs ongoing >>> monitoring and updates? >>=20 >> Monitoring, yes. As to configuration changes, very very rarely. ISPs >> don't like to make customer effecting changes. They take a lot of = time >> and coordination and they are very expensive. They also tend to make >> customers unhappy. As such, we try to avoid them whenever possible. A >> BGP session flap doesn't require a configuration change, it requires >> fixing the problem. If the configuration on the router worked last = week >> and it doesn't work this week, the configuration on the router isn't = the >> thing that changed, so the question is what did. If the ISP changed >> their configuration, then you may need to change the local >> configuration, but that's going to rarely be the case. More often, = you >> need to do one of the following: >>=20 >> 1.Get the circuit fixed. (most common problem) >> 2.Get the ISP to fix whatever they accidentally changed on their = side. >> 3.Investigate a more unusual problem in more detail before taking any >> action. >>=20 >> In case 3, that's not any more or less likely to happen with a BGP >> session than it is with a static routed session going through NAT/NPT >> and it's not any more difficult to debug/troubleshoot. In fact, since >> you don't have to trace things through state tables and address >> mutilations in the headers, it's usually quite a bit easier. >>=20 >> As an example, think the last time I changed the BGP configuration I >> included was about 3.5 years ago. >>=20 >>>>>> The configuration complexity for changing providers is no >>>>>> greater than that with NPT+ULA. You get the further advantage = that >>>>>> you can have actually redundant routers, not just redundant >>>>>> connections (the NPT solution basically requires putting both >>>>>> providers into a single box or REALLY complex workarounds such as >>>>>> STONITH to make sure only one router sends RAs at a time). You = also >>>>>> get the advantage that sessions can (and usually do) survive a >>>>>> failover event. >>>>>=20 >>>>> In my mind the NPTv6 + ULA solution is targeted more towards those >>>>> that only have a single provider in the first place. As in, the >>>>> overwhelming majority of mid-size and SOHO market that makes up = the >>>>> majority of the enterprise end-user networks. Those who already = have >>>>> multiple providers should be looking at PI and multihoming, I = agree >>>>> with you there. >>>>=20 >>>> I think that's a temporary majority, frankly. The internet is >>>> becoming too mission critical to accept single-homing for much = longer >>>> in most cases. Many of my clients are actually paying me to move = them >>>> to multi-homed connectivity and this seems to be a growing trend. >>>=20 >>> No argument there, but your sample is severely corrupted by = volunteer >>> bias. The number of small-medium enterprises who could not even = spell >>> "multihomed" is pretty vast. >>=20 >> Today, that's true. However, the number that can say "Hey, Mr. IT >> consultant, our internet isn't reliable enough and when its down, our >> credit card processor doesn't work any more. Is there any way we can = get >> a more reliable internet connection?" is not nearly so limiting. If = "Mr. >> IT Consultant" has half a brain, he figures out how to get them >> multi-homed. If he doesn't, then he's one of those guys that gives = the >> rest of us a bad name. >>=20 >>>> Frankly, if you're single-homed, you're better off setting up your >>>> network for easy renumbering, running static provider-assigned >>>> prefixes, and taking a month with both prefixes present to renumber >>>> the network. It's really not that hard in IPv6 and can be done with >>>> almost no disruption to the users. (Yes, I've done this a couple of >>>> times for medium-sized networks. If you plan for it in the original >>>> network design it really can be pretty straight forward.) >>>=20 >>> Again, for those that actually are, or will be multihomed we're in >>> agreement. My argument is for the overwhelming majority of >>> small-medium enterprises who will not ever be multihomed. The >>> perceived benefits of v4 NAT, especially no need to ever renumber, = are >>> much more important than anything v6 can provide them. They don't = want >>> the end-to-end model back, no matter how much some of us think they >>> should. >>=20 >> That's because those people largely don't know how much easier it is = to >> renumber in IPv6. Seriously, renumbering (especially prefix-only >> renumbering) can be done for the average SME over the course of about = a >> month without significant disruption and without even requiring all = that >> many man hours in the process. It's not like IPv4. That part did >> actually get mostly fixed in IPv6. >>=20 >> Owen >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From owen@delong.com Mon Mar 4 13:06:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE61B21F8F2F for ; Mon, 4 Mar 2013 13:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.591 X-Spam-Level: X-Spam-Status: No, score=-1.591 tagged_above=-999 required=5 tests=[AWL=1.008, 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 kgSFodXqT8Oe for ; Mon, 4 Mar 2013 13:06:03 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 3C83421F8EF5 for ; Mon, 4 Mar 2013 13:05:59 -0800 (PST) Received: from [10.255.251.216] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r24L2Tlu008261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 Mar 2013 13:02:30 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r24L2Tlu008261 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362430950; bh=ndgG8/8X5fqqxDmYPFWCjpmm0Ls=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=NezBop8UBXU0T/uWDeBhk0a1nPLpVTidfFBZvEdrS+aos2RU6Nf6rHkIcF8w3i301 DfVBIb/e0HJKCPGhv7OQlVt1O5FN8ihCjkILJCTc9kdQgTmqfSGG8hz7RSne4+8B1o kio8YzYeHAPmlJ2X/RMaYK3ZHWtPj5HvgPdFv2CY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <51345CD6.3070807@dougbarton.us> Date: Mon, 4 Mar 2013 13:02:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <92E6AF8C-F7A6-4291-9856-D972B371BF10@delong.com> References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 04 Mar 2013 13:02:30 -0800 (PST) Cc: IPv6 Ops WG Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 21:06:04 -0000 On Mar 4, 2013, at 12:35 AM, Doug Barton wrote: > On 03/03/2013 09:09 AM, Cameron Byrne wrote: >> Doug >>=20 >> Afaik, the ietf is fundamentally committed to the e2e model. >=20 > [citation needed] >=20 >> The ietf >> structure allows for revisiting this topic everyday, but I would = advise >> not to. Especially in this working group. >>=20 >> I, for one, only participate in the ietf for the purpose of = facilitating >> the e2e model whenever possible. E2e fits my world view as well as my >> employer's bottom line. >=20 > Cameron, >=20 > With all due respect to those involved, the history of the IETF, and = particularly some of those who have pushed various aspects of the IPv6 = protocol as it was envisioned 15 years ago, is replete with decisions = that show a stunning lack of familiarity with real world needs. True. >=20 > The fact that it took the content networks years to drag the IPv6 = literati kicking and screaming into allowing for PI space is one = excellent example. The continuing failure to permit a full-featured = DHCPv6 protocol is similarly slowing down adoption by the end-user = networks. Revisionist history. As the author of the first successful policy which allowed PI space in = IPv6, I will point out the following factual errors in your statement: 1. The content networks were not really part of the = discussion. 2. The IPv6 literati (whoever they are supposed to be) were = not really part of the discussion, either. 3. This was done as an RIR policy in the ARIN region = through the ARIN Internet Resource Policy Evaluation Process (IRPEP) which was later subsumed by = the PDP and now the revised PDP. 4. The policy has now been replaced by an even more liberal = IPv6 assignment policy which was primarily written by David Farmer (University of = Michigan), but which I made significant contributions to. I was (at the time) primarily focused on making = sweeping changes to the ISP IPv6 allocation policy. I'm happy to say that both policies are now in = place and operational in the ARIN region and that it is easier than ever before to obtain IPv6 = addressing in very generous quantities. The only feature missing from DHCPv6 that is at all significant is the = ability to provide routing information. There are actually sufficient = tools within the RA framework that this feature, while desirable in = order to facilitate existing role distribution within the enterprise, is = not vital and is more of an excuse than a reason for any failure to = deploy IPv6. > The whole concept of "returning to the end-to-end model" is = anachronistic, and does not meet the needs of the overwhelming majority = of end-user networks. Completely aside from the NAT/renumbering issues, = the firewalls on nearly all enterprise networks are closed. The same = should be true for home users, in fact one could argue that it's more = important there. Thus, any software that needs to allow connections from = the outside in has to have something like UPNP/PMP, or a rendezvous = server; so whether it's punching that hole in "just a SPIF," or "SPIF + = NAT/NPT" doesn't matter. No, it isn't. Yes, enterprises (and others) want to block end-to-end = communication in many cases. Fine, that's up to them to do as they wish = through firewalls, packet filters, stageful inspection, whatever. = However, end-to-end addressing is neither anachronistic, nor = undesirable. It meets many needs for many people outside of those = enterprises and will, in fact, support future needs in those very = enterprises of which you speak when other things are more mature as I = described above. If you want to see early development work in this area, = you need look no further than things like Apple's "Back to my Mac" and = Micr0$0ft's "Direct Access". Yes, closed firewalls are a fine thing in today's environment. Assuming = that will always be the case is absurd. There is a very large difference between allowing for some protocol to = open paths through a filtration mechanism and requiring applications to = support non-transparent addressing. The former is much simpler than the = latter and can be done in a much more secure manner than existing = probl^h^h^h^h^h"solutions" like UPNP/PMP. It actually does matter whether you're punching a hole in just a SPIF (a = very simple matter with isolated consequences to a single host) or a = SPIF+NAT/NPT (a much more complicated matter that includes mapping, = packet mutilation, a series of additional state tables, and may have = side effects that hit hosts other than the intended parties). > So, yes ... I will continue to talk about this problem, until I'm = confident that all of the right people understand it. Hopefully you will eventually understand it. Owen From owen@delong.com Mon Mar 4 13:21:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9207021F867B for ; Mon, 4 Mar 2013 13:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.543 X-Spam-Level: X-Spam-Status: No, score=-1.543 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 rLDORI4T1+ce for ; Mon, 4 Mar 2013 13:21:14 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1A55021F862D for ; Mon, 4 Mar 2013 13:21:14 -0800 (PST) Received: from [10.255.251.216] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r24LGtTD008788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 Mar 2013 13:16:56 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r24LGtTD008788 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362431816; bh=Ed/pvxe8Nuv4jIIQ34EM0ExGluw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=3kpll88IkCxNz5RlPiyK++0o+QDjkgoEdwVyZuI4Q5kXqjCxM71XTEab+cq//HCh1 CpP6ty68IP2OYvAfNhD3p0fQk7C66M4mzhc01t3F0wtmzgRg1Qgn9m1E4/IY3UsSFC k8AOsz0liyAM5MGENFuEtIqaSG3/ks9EE8vvw5m8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <20130304190032.GX51699@Space.Net> Date: Mon, 4 Mar 2013 13:16:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <18941C41-7060-47B7-8F2F-1D9C0706D10E@delong.com> References: <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474AB9B9@mbx-01.win.nominum.com> <20130304142530.GP51699@Space.Net> <8D23D4052ABE7A4490E77B1A012B6307474ABDDC@mbx-01.win.nominum.com> <20130304150931.GW51699@Space.Net> <8D23D4052ABE7A4490E77B1A012B6307474ABE70@mbx-01.win.nominum.com> <20130304190032.GX51699@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 04 Mar 2013 13:16:56 -0800 (PST) Cc: IPv6 Ops WG Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 21:21:16 -0000 Gert, I'm in the "make both protocols complete and interoperable such that = operators can choose the features that best meet their needs" camp. However, the IETF has not done so. RA (until recently) lacked RDNS = support which was a glaring failure to provide everything needed to configure a = host. I'm not sure much more should be added to RA as it's intended to be a = very lightweight protocol. I think RA has arrived at a reasonably complete = state in its current form. (implementations notwithstanding, as they are not = IETF's issue). OTOH, lack of routing information in DHCPv6 is a glaring omission and = the purists that have, thus far, managed to keep it out of the IETF specs = are likely to force an alternative solution to get adopted as a de facto standard = which will eventually then be documented after the fact by IETF. My recommendation in discussing this with the DHCP product manager at ISC has been to provide a vendor option which provides the following = properties: 1. Each response to a DHCP Request can contain zero or more of = these option fields. 2. The option will contain the following information: Vendor number Vendor's option number Prefix Next hop gateway address (must be an on-link or = link-local address) Metric (a 32 bit number used to determine preference of = competing routes) Owen On Mar 4, 2013, at 11:00 AM, Gert Doering wrote: > Hi, >=20 > On Mon, Mar 04, 2013 at 03:12:11PM +0000, Ted Lemon wrote: >> On Mar 4, 2013, at 10:09 AM, Gert Doering wrote: >>> So what is it that you're missing? "Sane implementations" is not = really >>> something the IETF can provide. >>=20 >> Support for multiple provisioning domains is high on my list. = Support for DNS zone maintenance as well. >=20 > But that's all in the "all software sucks" domain, not that much IETF=20= > standards can do about it. Or am I misunderstanding you? >=20 > The general beef in the IETF IPv6 working groups seems to be that one > camp wants "everything that's needed to configure a host" in RA, and = the > other camp thinks DHCP is good enough for everything and thinks having > to run RA as well is evil, and should not be done. Or such. >=20 > I think people from both camps should be drowned somewhere, for = refusing=20 > to acknowledge that networks in the real world out of their ivory = towers=20 > *differ* in nature, and some would benefit from "just RA" while others=20= > might want "just DHCPv6". >=20 > Gert Doering > -- NetMaster > --=20 > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. = Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rajiva@cisco.com Mon Mar 4 13:37:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380EF21F8CF2 for ; Mon, 4 Mar 2013 13:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWSo1GKCxtVE for ; Mon, 4 Mar 2013 13:37:44 -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 5B4BE21F8CF0 for ; Mon, 4 Mar 2013 13:37:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3883; q=dns/txt; s=iport; t=1362433063; x=1363642663; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Z1UzfLyUyy8nYyw5rz+v/fTzAIsdXO72GO+HW9HbPNw=; b=HgSMJEspG/mlmrmWcV6IXOTv39/nWcoDrHDI3XMEtbQw+HDZ3RAM4WQJ ebZ6aVW0fvOJJkg3Gyz36L/YHPJLNp87S6QBzuQBNilBJWwSYhUvwEhcP Aq7FO4lnFI1wTjT5eOjqsXabaWEVEMyMDWyo8XI6hZbbc5yVhc4ZX5VbE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAGATNVGtJV2c/2dsb2JhbABEwlSBCRZzgh8BAQEDAQEBATcNJwsFBwQCAQgRBAEBAQoPAgMJBycLFAkIAgQBDQUIE4dyBgyzL44dBI5bJgsHBgkYgjhhA6cygwiCJw X-IronPort-AV: E=Sophos;i="4.84,783,1355097600"; d="scan'208";a="183660913" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 04 Mar 2013 21:37:41 +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 r24LbfSm008623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Mar 2013 21:37:41 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.72]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Mon, 4 Mar 2013 15:37:41 -0600 From: "Rajiv Asati (rajiva)" To: Owen DeLong , Gert Doering Thread-Topic: [v6ops] ULA Usage Guide draft requesting for review Thread-Index: AQHOE1oj2qUAuv5aG0SBTJo7pMCvqZiK9iWAgAPxl4CAAfrRgIAAEn4AgAAp0oCAAQAFgIAALqwAgAAEp4CAAAjVgIAAcigAgACOigCAAUYAAIABAp4AgABO0ICAABL1AIAAC5OAgAAAuoCAAAC+gIAAP80AgAAmHoD//6EH4A== Date: Mon, 4 Mar 2013 21:37:40 +0000 Message-ID: References: <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474AB9B9@mbx-01.win.nominum.com> <20130304142530.GP51699@Space.Net> <8D23D4052ABE7A4490E77B1A012B6307474ABDDC@mbx-01.win.nominum.com> <20130304150931.GW51699@Space.Net> <8D23D4052ABE7A4490E77B1A012B6307474ABE70@mbx-01.win.nominum.com> <20130304190032.GX51699@Space.Net> <18941C41-7060-47B7-8F2F-1D9C0706D10E@delong.com> In-Reply-To: <18941C41-7060-47B7-8F2F-1D9C0706D10E@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.240.66] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 21:37:47 -0000 Owen, > OTOH, lack of routing information in DHCPv6 is a glaring omission and the > purists that have, thus far, managed to keep it out of the IETF specs are Did you look at this one? https://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-05 Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Owen DeLong > Sent: Monday, March 04, 2013 4:17 PM > To: Gert Doering > Cc: IPv6 Ops WG > Subject: Re: [v6ops] ULA Usage Guide draft requesting for review >=20 > Gert, >=20 > I'm in the "make both protocols complete and interoperable such that > operators can choose the features that best meet their needs" camp. >=20 > However, the IETF has not done so. RA (until recently) lacked RDNS suppor= t > which was a glaring failure to provide everything needed to configure a > host. > I'm not sure much more should be added to RA as it's intended to be a ver= y > lightweight protocol. I think RA has arrived at a reasonably complete st= ate > in its current form. (implementations notwithstanding, as they are not IE= TF's > issue). >=20 > OTOH, lack of routing information in DHCPv6 is a glaring omission and the > purists that have, thus far, managed to keep it out of the IETF specs are > likely to force an alternative solution to get adopted as a de facto stan= dard > which will eventually then be documented after the fact by IETF. >=20 > My recommendation in discussing this with the DHCP product manager at > ISC has been to provide a vendor option which provides the following > properties: >=20 > 1. Each response to a DHCP Request can contain zero or more of these > option fields. > 2. The option will contain the following information: > Vendor number > Vendor's option number > Prefix > Next hop gateway address (must be an on-link or link-local > address) > Metric (a 32 bit number used to determine preference of > competing routes) >=20 > Owen >=20 > On Mar 4, 2013, at 11:00 AM, Gert Doering wrote: >=20 > > Hi, > > > > On Mon, Mar 04, 2013 at 03:12:11PM +0000, Ted Lemon wrote: > >> On Mar 4, 2013, at 10:09 AM, Gert Doering wrote: > >>> So what is it that you're missing? "Sane implementations" is not > >>> really something the IETF can provide. > >> > >> Support for multiple provisioning domains is high on my list. Suppor= t for > DNS zone maintenance as well. > > > > But that's all in the "all software sucks" domain, not that much IETF > > standards can do about it. Or am I misunderstanding you? > > > > The general beef in the IETF IPv6 working groups seems to be that one > > camp wants "everything that's needed to configure a host" in RA, and > > the other camp thinks DHCP is good enough for everything and thinks > > having to run RA as well is evil, and should not be done. Or such. > > > > I think people from both camps should be drowned somewhere, for > > refusing to acknowledge that networks in the real world out of their > > ivory towers > > *differ* in nature, and some would benefit from "just RA" while others > > might want "just DHCPv6". > > > > Gert Doering > > -- NetMaster > > -- > > have you enabled IPv6 on something today...? > > > > SpaceNet AG Vorstand: Sebastian v. Bomhard > > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Cule= mann > > D-80807 Muenchen HRB: 136055 (AG Muenchen) > > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From owen@delong.com Mon Mar 4 14:01:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6989E21F868E for ; Mon, 4 Mar 2013 14:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.634 X-Spam-Level: X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 7SohSLBFRSdG for ; Mon, 4 Mar 2013 14:01:48 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 32C0121F8689 for ; Mon, 4 Mar 2013 14:01:47 -0800 (PST) Received: from [10.255.251.216] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r24Lw5BU009762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 Mar 2013 13:58:06 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r24Lw5BU009762 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362434286; bh=+QQ2TM+ozEh8THr/t2/Jj2sGY6E=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=q/MtuDKrvcgk/h1ggm1iD0kcF7d9o/z/jZitvuGN3dC4FvjxAlLxDkIOOdthOU4KK SOXgC0mtDV4VsIBkwVa87L2ka21HXv5Xl62Ra4EP2ynZwvE3jTtZXojMFZyQyOQN2X dAtRXOSLIPBHiPERJroHo4xAAMU/mKF4g3GKTkuY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: Date: Mon, 4 Mar 2013 13:58:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1E14AA28-CF96-4DD5-A1F6-A6F9CF73E19C@delong.com> References: <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474AB9B9@mbx-01.win.nominum.com> <20130304142530.GP51699@Space.Net> <8D23D4052ABE7A4490E77B1A012B6307474ABDDC@mbx-01.win.nominum.com> <20130304150931.GW51699@Space.Net> <8D23D4052ABE7A4490E77B1A012B6307474ABE70@mbx-01.win.nominum.com> <20130304190032.GX51699@Space.Net> <18941C41-7060-47B7-8F2F-1D9C0706D10E@delong.com> To: Rajiv Asati (rajiva) X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 04 Mar 2013 13:58:06 -0800 (PST) Cc: IPv6 Ops WG Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 22:01:49 -0000 My concern is that you are requiring the host to ask for routing = information before it is supplied. I think that in many cases, the DHCP administrators = would prefer to "force feed" this information to the clients and expect the clients = to abide by it. Otherwise, it looks like pretty much exactly what I was wanting. I hope = it moves forward. Owen On Mar 4, 2013, at 1:37 PM, Rajiv Asati (rajiva) = wrote: > Owen, >=20 >> OTOH, lack of routing information in DHCPv6 is a glaring omission and = the >> purists that have, thus far, managed to keep it out of the IETF specs = are >=20 > Did you look at this one? > https://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-05 >=20 >=20 > Cheers, > Rajiv >=20 >=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf >> Of Owen DeLong >> Sent: Monday, March 04, 2013 4:17 PM >> To: Gert Doering >> Cc: IPv6 Ops WG >> Subject: Re: [v6ops] ULA Usage Guide draft requesting for review >>=20 >> Gert, >>=20 >> I'm in the "make both protocols complete and interoperable such that >> operators can choose the features that best meet their needs" camp. >>=20 >> However, the IETF has not done so. RA (until recently) lacked RDNS = support >> which was a glaring failure to provide everything needed to configure = a >> host. >> I'm not sure much more should be added to RA as it's intended to be a = very >> lightweight protocol. I think RA has arrived at a reasonably = complete state >> in its current form. (implementations notwithstanding, as they are = not IETF's >> issue). >>=20 >> OTOH, lack of routing information in DHCPv6 is a glaring omission and = the >> purists that have, thus far, managed to keep it out of the IETF specs = are >> likely to force an alternative solution to get adopted as a de facto = standard >> which will eventually then be documented after the fact by IETF. >>=20 >> My recommendation in discussing this with the DHCP product manager at >> ISC has been to provide a vendor option which provides the following >> properties: >>=20 >> 1. Each response to a DHCP Request can contain zero or more of = these >> option fields. >> 2. The option will contain the following information: >> Vendor number >> Vendor's option number >> Prefix >> Next hop gateway address (must be an on-link or = link-local >> address) >> Metric (a 32 bit number used to determine preference of >> competing routes) >>=20 >> Owen >>=20 >> On Mar 4, 2013, at 11:00 AM, Gert Doering wrote: >>=20 >>> Hi, >>>=20 >>> On Mon, Mar 04, 2013 at 03:12:11PM +0000, Ted Lemon wrote: >>>> On Mar 4, 2013, at 10:09 AM, Gert Doering wrote: >>>>> So what is it that you're missing? "Sane implementations" is not >>>>> really something the IETF can provide. >>>>=20 >>>> Support for multiple provisioning domains is high on my list. = Support for >> DNS zone maintenance as well. >>>=20 >>> But that's all in the "all software sucks" domain, not that much = IETF >>> standards can do about it. Or am I misunderstanding you? >>>=20 >>> The general beef in the IETF IPv6 working groups seems to be that = one >>> camp wants "everything that's needed to configure a host" in RA, and >>> the other camp thinks DHCP is good enough for everything and thinks >>> having to run RA as well is evil, and should not be done. Or such. >>>=20 >>> I think people from both camps should be drowned somewhere, for >>> refusing to acknowledge that networks in the real world out of their >>> ivory towers >>> *differ* in nature, and some would benefit from "just RA" while = others >>> might want "just DHCPv6". >>>=20 >>> Gert Doering >>> -- NetMaster >>> -- >>> have you enabled IPv6 on something today...? >>>=20 >>> SpaceNet AG Vorstand: Sebastian v. Bomhard >>> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. = Grundner-Culemann >>> D-80807 Muenchen HRB: 136055 (AG Muenchen) >>> Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From jhw@apple.com Mon Mar 4 14:12:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C898911E80A5 for ; Mon, 4 Mar 2013 14:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.91 X-Spam-Level: X-Spam-Status: No, score=-107.91 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8, 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 EQ8pXzKp3Gki for ; Mon, 4 Mar 2013 14:12:56 -0800 (PST) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB4611E80A3 for ; Mon, 4 Mar 2013 14:12:51 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MJ50096WPPBNEI0@mail-out.apple.com> for v6ops@ietf.org; Mon, 04 Mar 2013 14:12:50 -0800 (PST) X-AuditID: 11807136-b7efc6d0000001b3-15-51352a706c30 Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 14.B5.00435.07A25315; Mon, 04 Mar 2013 15:12:49 -0800 (PST) Received: from kallisti.apple.com ([17.193.13.64]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MJ500GGVPPE0Y50@aniseed.apple.com> for v6ops@ietf.org; Mon, 04 Mar 2013 14:12:50 -0800 (PST) From: james woodyatt In-reply-to: <20130304143357.GQ51699@Space.Net> Date: Mon, 04 Mar 2013 14:12:50 -0800 Message-id: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6E5795@nkgeml506-mbx.china.huawei.com> <20130304143357.GQ51699@Space.Net> To: "v6ops@ietf.org" X-Mailer: Apple Mail (2.1688) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUi2FAsrluoZRposGMCi8XpY3uZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8XPuNcaCiWwV+37qNTB+YOli5OSQEDCR2HX8ADuELSZx4d56 ti5GLg4hgSlMEq2NmxghnBlMEg+behlBqpgFtCTW7zzOBGLzCuhJvF28kBXEFgayp576yAxi swmoSHy7fBeshlNAX2LXzQ6gDRwcLAKqEpMmW0CM0ZZ48u4CK8QYG4k5L9rBbCGBGokNG/6A 2SJA5aefXmaGOE5W4s3ypywTGPlnIbliFpIrZiEZu4CReRWjYFFqTmKloaleYkFBTqpecn7u JkZwgBWa7WDc8VfuEKMAB6MSD2/mVZNAIdbEsuLK3EOMEhzMSiK893lNA4V4UxIrq1KL8uOL SnNSiw8xSnOwKInzrp1nGCgkkJ5YkpqdmlqQWgSTZeLglGpgVLyp7My8cPsXfv01Sec3e7sf CH28zvSb1pM0qx1Hpm/hKN/0tE3pncDjj925J81UXFY4Pwpcksm7PHjFPIMbKyapmu/7s+/6 wdeMbzUtTrztlful+5Qx3W+jhwjnnc0vueac3FEaevyUz73I6nXJrkGLyps5WFbd22Byav6J xnDbgycKyoK7GpVYijMSDbWYi4oTAaRh9qksAgAA Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 22:12:56 -0000 On Mar 4, 2013, at 06:33 , Gert Doering wrote: > > (Actually there's 3 options - BGP+PI, ULA+NPTv6, and PA space Actually, there's a fourth: ULA+NAT66 (not NPTv6). As I have said elsewhere and I will repeat here, this option is the only one that guarantees that SOHO and HOMENET sites will always have a /48 with 16 bits of subnet identifier space from which to choose random numbers that are statistically unlikely to collide in reasonably sized sites in the foreseeable future. Yes, it comes at a terrible price, but my view is that it's not that much worse than the price of NPTv6 and the guaranteed /48 prefix is more than worth the additional cost in transparency. -- james woodyatt core os networking From bs7652@att.com Mon Mar 4 15:20:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAACA11E80AE for ; Mon, 4 Mar 2013 15:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.399 X-Spam-Level: X-Spam-Status: No, score=-105.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbICXs57LyPH for ; Mon, 4 Mar 2013 15:20:56 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 0B05A11E80A5 for ; Mon, 4 Mar 2013 15:20:55 -0800 (PST) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 85c25315.2aaadd421940.331522.00-543.936211.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 04 Mar 2013 23:20:56 +0000 (UTC) X-MXL-Hash: 51352c586dee7e08-f90d3242be86600d8a48a826dafc57c7ddb47478 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 65c25315.0.331518.00-486.936196.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 04 Mar 2013 23:20:55 +0000 (UTC) X-MXL-Hash: 51352c576a9a0daf-1d2bff0e2a0c4a8d6e12bd9f8b7177cc4a08dc87 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r24NKso9009289; Mon, 4 Mar 2013 18:20:54 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r24NKlNv009243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Mar 2013 18:20:48 -0500 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (gaalpa1msghub9e.itservices.sbc.com [130.8.36.91]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Mon, 4 Mar 2013 23:20:31 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.02.0342.003; Mon, 4 Mar 2013 18:20:31 -0500 From: "STARK, BARBARA H" To: james woodyatt , "v6ops@ietf.org" Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT Thread-Index: Ac4Y0qVmXOczhdgyTHaW1OIbGrg4zQAPJEaAABAGvQAACMI58A== Date: Mon, 4 Mar 2013 23:20:29 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6E5795@nkgeml506-mbx.china.huawei.com> <20130304143357.GQ51699@Space.Net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.44.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=boj78jmi c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=w_ZQMhq8qOEA:10 a=sI9RbPglHLgA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=w5GEXZAIX2QA:10 a=eiYUr9cJ-M4CVfd5H4gA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 23:20:56 -0000 > > (Actually there's 3 options - BGP+PI, ULA+NPTv6, and PA space >=20 > Actually, there's a fourth: ULA+NAT66 (not NPTv6). >=20 > As I have said elsewhere and I will repeat here, this option is the only = one > that guarantees that SOHO and HOMENET sites will always have a /48 with 1= 6 > bits of subnet identifier space from which to choose random numbers that > are statistically unlikely to collide in reasonably sized sites in the fo= reseeable > future. >=20 > Yes, it comes at a terrible price, but my view is that it's not that much= worse > than the price of NPTv6 and the guaranteed /48 prefix is more than worth > the additional cost in transparency. I have to admit to having been curious about the lack of mention of this 4t= h option in this ULA discussion. I'd be very interested in better understan= ding the "terrible price" of ULA+NAT66 vs. the "cost" of ULA+NPTv6 vs. "RIR= +ISP+other costs" of BGP+PI or PA space. I think the information would be u= seful. If the price of getting the information is that it has to have some = sort of recommendation tacked on to it, that doesn't bother me at all. Barbara From joelja@bogus.com Mon Mar 4 15:28:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96DAE21F87B3 for ; Mon, 4 Mar 2013 15:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.099 X-Spam-Level: X-Spam-Status: No, score=-101.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_48=0.6, J_CHICKENPOX_62=0.6, 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 5QCQbjnRPblm for ; Mon, 4 Mar 2013 15:28:47 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B327221F87BA for ; Mon, 4 Mar 2013 15:28:44 -0800 (PST) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r24NSfwv019211 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 4 Mar 2013 23:28:41 GMT (envelope-from joelja@bogus.com) Message-ID: <51352E32.6000606@bogus.com> Date: Mon, 04 Mar 2013 15:28:50 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: "STARK, BARBARA H" , james woodyatt , "v6ops@ietf.org" References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6E5795@nkgeml506-mbx.china.huawei.com> <20130304143357.GQ51699@Space.Net> <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> 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]); Mon, 04 Mar 2013 23:28:42 +0000 (UTC) Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 23:28:48 -0000 On 3/4/13 3:20 PM, STARK, BARBARA H wrote: >>> (Actually there's 3 options - BGP+PI, ULA+NPTv6, and PA space >> Actually, there's a fourth: ULA+NAT66 (not NPTv6). >> >> As I have said elsewhere and I will repeat here, this option is the only one >> that guarantees that SOHO and HOMENET sites will always have a /48 with 16 >> bits of subnet identifier space from which to choose random numbers that >> are statistically unlikely to collide in reasonably sized sites in the foreseeable >> future. >> >> Yes, it comes at a terrible price, but my view is that it's not that much worse >> than the price of NPTv6 and the guaranteed /48 prefix is more than worth >> the additional cost in transparency. > I have to admit to having been curious about the lack of mention of this 4th option in this ULA discussion. I'd be very interested in better understanding the "terrible price" of ULA+NAT66 vs. the "cost" of ULA+NPTv6 vs. "RIR+ISP+other costs" of BGP+PI or PA space. I think the information would be useful. If the price of getting the information is that it has to have some sort of recommendation tacked on to it, that doesn't bother me at all. It's not like we're aren't taking a stab at it. 6renum homenet and v6ops ops all dance around what is essentially single homing to multiple providers in some drafts. individual devices (e.g. cellphones, laptops with broadbad radios(or wifi+ethernet or split vpn), some cars and so forth) do this today do this by virtue of having more than active network interface on disparate providers. > Barbara > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From farmer@umn.edu Mon Mar 4 16:07:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DE411E80A3 for ; Mon, 4 Mar 2013 16:07: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 NVzHpfmq3T6f for ; Mon, 4 Mar 2013 16:07:24 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id 3F15921F8771 for ; Mon, 4 Mar 2013 16:07:24 -0800 (PST) Received: from mail-oa0-f71.google.com (mail-oa0-f71.google.com [209.85.219.71]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 4 Mar 2013 18:07:13 -0600 (CST) X-Umn-Remote-Mta: [N] mail-oa0-f71.google.com [209.85.219.71] #+LO+TR X-Umn-Classification: local Received: by mail-oa0-f71.google.com with SMTP id o6so37560824oag.6 for ; Mon, 04 Mar 2013 16:07:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=S/l7C36J39QRep4IWjfkwo75nuctcSU4GcoWb5pqyhY=; b=LQlRK8NOWZsDvTwathFUc6S3IkFgXwbCthN7IJ7yePLni5MZTRAadIRwRin64GVQ1f +a46Dco9DHgnWHaNUPJrmYTh9uw8s8pFo7wjGtAEo64BqWyILc2heetJ6laHCbSctASX puTKrcrdyPjVzKZQ+HY5EE0EDud7Wob1Bb7q6ji51TwslD3ZTwXa3dLxhLW1XfNA2O/f 8BKTvIhnLlGSEovXc1boTD1PMLIjnaNKlldP2o6dc2KUndQlflLyKypni7sYjZfwghQQ 4OhZuuT2pIeQ473PVEyQB8twsFhIR389LcUtCOOgt5ZHljHFomsRJne/dPERPvFWA/sn tArQ== X-Received: by 10.50.12.201 with SMTP id a9mr4287860igc.10.1362442032654; Mon, 04 Mar 2013 16:07:12 -0800 (PST) X-Received: by 10.50.12.201 with SMTP id a9mr4287853igc.10.1362442032517; Mon, 04 Mar 2013 16:07:12 -0800 (PST) Received: from x-128-101-235-119.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:5dae:ae0:8c43:6bd7]) by mx.google.com with ESMTPS id wx2sm13547772igb.4.2013.03.04.16.07.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Mar 2013 16:07:11 -0800 (PST) Message-ID: <51353736.3000800@umn.edu> Date: Mon, 04 Mar 2013 18:07:18 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Owen DeLong References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> <92E6AF8C-F7A6-4291-9856-D972B371BF10@delong.com> In-Reply-To: <92E6AF8C-F7A6-4291-9856-D972B371BF10@delong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmHbHfrfihAVJVfWmeaDsWSh9uj1xO1HcPCKtD5Bnx2iuWmhPCPYdqobMIoYVDHY6f8Zw8jFeP+r9JBU3eA0w2ZZlFrztD1JJTcRcka9tjZE3nO4dKSO9nqVV/NMCtup/+OWY5p Cc: IPv6 Ops WG Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 00:07:25 -0000 On 3/4/13 15:02 , Owen DeLong wrote: > > On Mar 4, 2013, at 12:35 AM, Doug Barton wrote: > >> The fact that it took the content networks years to drag the IPv6 literati kicking and screaming into allowing for PI space is one excellent example. The continuing failure to permit a full-featured DHCPv6 protocol is similarly slowing down adoption by the end-user networks. > > Revisionist history. > > As the author of the first successful policy which allowed PI space in IPv6, I will point out the following factual errors in your statement: > > 1. The content networks were not really part of the discussion. > 2. The IPv6 literati (whoever they are supposed to be) were not really part of the discussion, either. > 3. This was done as an RIR policy in the ARIN region through the ARIN Internet Resource Policy > Evaluation Process (IRPEP) which was later subsumed by the PDP and now the revised PDP. > 4. The policy has now been replaced by an even more liberal IPv6 assignment policy which was > primarily written by David Farmer (University of Michigan), but which I made significant contributions > to. I was (at the time) primarily focused on making sweeping changes to the ISP IPv6 allocation > policy. I'm happy to say that both policies are now in place and operational in the ARIN region and > that it is easier than ever before to obtain IPv6 addressing in very generous quantities. I mostly agree with Owen on this, I don't believe the content networks were particularly advocates of PI, at least not any more than a number of other groups. That said, I believe content networks generally supported PI, but so did many others. So, primarily crediting content networks for PI is an over statement of their role. A side note; Owen, you got the wrong U of M, again, I work for the Maroon and Gold not the Blue and Maze. We generally work well with the Michigan guys, except one Saturday a year when we battle for the little brown jug. Now if we could only create the kind of collaborative and creative rivalries that exist between the institutions involved in college football, around IPv6 adoption, we'd have no problem. No Gopher asks why we have try to beat the Wolverines each year, even though we've only won the little brown jug twice in the last two decades, its just a given. :) -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From dougb@dougbarton.us Mon Mar 4 16:16:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A3821F88DB for ; Mon, 4 Mar 2013 16:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[AWL=0.753, 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 9XeBvfcOYnMY for ; Mon, 4 Mar 2013 16:16:53 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 9A18221F88C1 for ; Mon, 4 Mar 2013 16:16:53 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:fd90:9c65:3ee7:82d8] (unknown [IPv6:2001:470:d:5e7:fd90:9c65:3ee7:82d8]) by dougbarton.us (Postfix) with ESMTPSA id 4643622B6E; Tue, 5 Mar 2013 00:16:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362442613; bh=u9wNIY9/Ofn73kNLHkrU+FXn3tkLvCE08KbFfNnyfAQ=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=flrqqARpuQX4UDeIoDsF8uwYYsxh0p15qIhVo9ZwK4gR6TpMExLOvxqBg8oZeEjMk y92apLTvpPCPOTPDinId4DvmdoIR1m7CjYi7HmCEGRzfX705nWyIbawpna9TWjIHJf qF5hjC4SmHy/MxTh/8/O4GucAQ3acHUBSpKN9R0I= Message-ID: <51353974.60707@dougbarton.us> Date: Mon, 04 Mar 2013 16:16:52 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: David Farmer References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> <92E6AF8C-F7A6-4291-9856-D972B371BF10@delong.com> <51353736.3000800@umn.edu> In-Reply-To: <51353736.3000800@umn.edu> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 00:16:54 -0000 On 03/04/2013 04:07 PM, David Farmer wrote: > I don't believe the content networks were particularly advocates of PI, > at least not any more than a number of other groups. That said, I > believe content networks generally supported PI, but so did many > others. So, primarily crediting content networks for PI is an over > statement of their role. Fair enough. My point remains however. As-designed IPv6 was PA only. It took an enormous hue and cry to get that changed. And yes, the policy change happened at the RIRs, but not till AFTER the IETF signed off, which did not occur till AFTER various large network operators made it clear that they would never deploy v6 till PI space was available. Doug From dougb@dougbarton.us Mon Mar 4 16:30:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BAB1F0D0D for ; Mon, 4 Mar 2013 16:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.502, 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 ipBHZUx9idsv for ; Mon, 4 Mar 2013 16:30:06 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5631F0D09 for ; Mon, 4 Mar 2013 16:30:06 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:fd90:9c65:3ee7:82d8] (unknown [IPv6:2001:470:d:5e7:fd90:9c65:3ee7:82d8]) by dougbarton.us (Postfix) with ESMTPSA id 0897A22B93 for ; Tue, 5 Mar 2013 00:30:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362443406; bh=FBVvz0nRiwUvxBYOP3LPnpjJ7/YZh/z7PwIcCAKtrtQ=; h=Date:From:To:Subject:References:In-Reply-To; b=BjoAvJ5vOIu7/4/J4lv+vv1S2aFkMdqCnxmPmdujXtyy7g5nugNjqxD3rlvZrWrJG sFRXgtvIlReKiGwqYLgwG98UaDgP8O2lt5qwqu+W9ImKFMzZEi2FeL32IlGUOrGao/ vzkW83KGBMtRLRw7KO3O4BshzSQkyg604K1ddhd4= Message-ID: <51353C8D.8050306@dougbarton.us> Date: Mon, 04 Mar 2013 16:30:05 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: IPv6 Ops WG References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> <92E6AF8C-F7A6-4291-9856-D972B371BF10@delong.com> In-Reply-To: <92E6AF8C-F7A6-4291-9856-D972B371BF10@delong.com> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 00:30:07 -0000 Owen, Aside from our fundamental disagreements on whether or not NPTv6 is ever acceptable, your last 2 messages highlight another fundamental disagreement which I think is equally, if not more damaging to the cause of widespread IPv6 deployment. A lot of your points of argument rely on "I think $this will/may happen in the future." While I certainly agree that we need to create our designs with doing our best not to limit future opportunities in mind, we also need to take present realities into account. Most particularly, the present reality is that users don't want to be told, "You're doing it wrong, if you want to deploy IPv6 you have to make this list of changes to your network model." In fact, they don't like that so much that they have tuned out that advice for the last 15 years, and have continued to happily use IPv4 behind their NATs. It's fine to talk about the good old days, and how much better the world would be if there was no NAT. But the operational reality is that that the majority of the life of the Internet (measured in years, users, bits/year, or any other measurement you want to consider) has been in the NAT era. Those good old days were a statistical blip, that occurred a long time ago. Not only are they not coming back, the users don't want them back. That leaves it up to us to do design work for the modern era, taking BOTH present reality and the hope for a brighter future into account. Focusing exclusively on one or the other is an error. Doug From owen@delong.com Mon Mar 4 16:56:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430B621F887F for ; Mon, 4 Mar 2013 16:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lFaGRdLINfD for ; Mon, 4 Mar 2013 16:56:15 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A1A9721F887D for ; Mon, 4 Mar 2013 16:56:15 -0800 (PST) Received: from [IPv6:2001:470::a9:cd95:49e2:bab:9b0b] ([IPv6:2001:470:0:a9:cd95:49e2:bab:9b0b]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r250qukV014644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 Mar 2013 16:52:56 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r250qukV014644 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362444777; bh=sWYG1T2uneRznO/MypIvySrjUJA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=dEBz2BPXg3AYcJLF1JPP9+0J3ZYUHCglbDZ3UVE0JJWtdexAKdU5hpfobD1/e/f2q 57SsixMNfWKFj+OMEMhpY46afCeG/L/CIksp+pNPm31+z983Hc4pUtXdNh4OvTTDn1 4Mq3on9OTZUidu2Cp2SLHcSmKt/LZJV8p/a45J20= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <51353974.60707@dougbarton.us> Date: Mon, 4 Mar 2013 16:52:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> <92E6AF8C-F7A6-4291-9856-D972B371BF10@delong.com> <51353736.3000800@umn.edu> <51353974.60707@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 04 Mar 2013 16:52:57 -0800 (PST) Cc: IPv6 Ops WG Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 00:56:16 -0000 On Mar 4, 2013, at 4:16 PM, Doug Barton wrote: > On 03/04/2013 04:07 PM, David Farmer wrote: >> I don't believe the content networks were particularly advocates of = PI, >> at least not any more than a number of other groups. That said, I >> believe content networks generally supported PI, but so did many >> others. So, primarily crediting content networks for PI is an over >> statement of their role. >=20 > Fair enough. My point remains however. As-designed IPv6 was PA only. = It took an enormous hue and cry to get that changed. And yes, the policy = change happened at the RIRs, but not till AFTER the IETF signed off, = which did not occur till AFTER various large network operators made it = clear that they would never deploy v6 till PI space was available. >=20 It must be wonderful to be able to modify history to suit your argument. The IETF did NOT sign off on PI for IPv6 before the RIR policies were = already implemented and dispensing it. I don't know if the IETF ever officially signed off on it or not, but I = do know that at least the first RIR policy was decided and implemented = without any regard to IETF action on the subject. Owen From farmer@umn.edu Mon Mar 4 17:06:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9AD321F86A1 for ; Mon, 4 Mar 2013 17:06:13 -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 A9xiiEpurA5a for ; Mon, 4 Mar 2013 17:06:13 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id F068521F86A6 for ; Mon, 4 Mar 2013 17:06:12 -0800 (PST) Received: from mail-ie0-f200.google.com (mail-ie0-f200.google.com [209.85.223.200]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 4 Mar 2013 18:54:54 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f200.google.com [209.85.223.200] #+LO+TR X-Umn-Classification: local Received: by mail-ie0-f200.google.com with SMTP id c11so35029891ieb.7 for ; Mon, 04 Mar 2013 16:54:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=eKiFZU8IZ6482TBmxJyM8JEcT/LvHELgO05Ebv/glaM=; b=bUrjYw182VoIqS72kd9q01pyyFNT7eOFPRc53sIZFGapljadkk8TfIGmjQthqQcOr8 fa1c7Xkl7tPq7zkHIsM/wSjPRXmvC9fIMZtJ5tqFlkHa7aPEzCaOFTWq4nNZmombE866 l6Dg3lKgo8N4k2pXWcbiGVlA30dPNdfoQRb/o9y/L39ss2Hc57L3F/6t7pfX9mlXSqIy 1EE2XxaxYLSoJG4fIhwj/o0Ixx1793wEUfcWBMGtVVH8Fr3owddjCDlONExsYuCx0j0e 6moytmpGQ8Mpyqz6IH4Wjv0v6pQ/RUVRdnue5ryhaCagOWYqqVWDvNtlJICMpQi9reCl DsJA== X-Received: by 10.43.117.136 with SMTP id fm8mr25692721icc.33.1362444894099; Mon, 04 Mar 2013 16:54:54 -0800 (PST) X-Received: by 10.43.117.136 with SMTP id fm8mr25692716icc.33.1362444893985; Mon, 04 Mar 2013 16:54:53 -0800 (PST) Received: from x-128-101-235-119.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:5dae:ae0:8c43:6bd7]) by mx.google.com with ESMTPS id uy13sm13793523igb.7.2013.03.04.16.54.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Mar 2013 16:54:53 -0800 (PST) Message-ID: <51354262.9000604@umn.edu> Date: Mon, 04 Mar 2013 18:54:58 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Doug Barton References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> <92E6AF8C-F7A6-4291-9856-D972B371BF10@delong.com> <51353736.3000800@umn.edu> <51353974.60707@dougbarton.us> In-Reply-To: <51353974.60707@dougbarton.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk9p+OaXga4uGT2flWKoL9W4TKWtGrTkz6U8nwTfZuXwiuXPvIQPcBYLXowJ3SmzH/u/a0TzweFn2oiob14vpoE8I4JS/1cBMMTAQC8e3yjb3i7VQ4PQt4ZYj7e6PYk/tqhzJyB Cc: IPv6 Ops WG Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 01:06:13 -0000 On 3/4/13 18:16 , Doug Barton wrote: > On 03/04/2013 04:07 PM, David Farmer wrote: >> I don't believe the content networks were particularly advocates of PI, >> at least not any more than a number of other groups. That said, I >> believe content networks generally supported PI, but so did many >> others. So, primarily crediting content networks for PI is an over >> statement of their role. > > Fair enough. My point remains however. As-designed IPv6 was PA only. It > took an enormous hue and cry to get that changed. And yes, the policy > change happened at the RIRs, Agreed. > but not till AFTER the IETF signed off, I don't recall any RFC or other consensus from the IETF that called for PI, there may have been a consensus that GUA-PI was a better idea than ULA-C, that is the closest to a consensus for PI I can think of. I'd love to be wrong on that as I still have people grumble at me about the ARIN policy I authored. Being able to provide a quote that there was a IETF consensus for PI would still be helpful to me personally if there is one to point to. > which did not occur till AFTER various large network operators made it > clear that they would never deploy v6 till PI space was available. Many of the largest network operators supported the PA-only model and mostly did not support PI. Some relented as it became obvious that the lack of IPv6 PI was a huge drag on IPv6 adoption, especially as IPv4 run-out actually started to loom big on the horizon. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From farmer@umn.edu Mon Mar 4 18:23:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56BB21F8788 for ; Mon, 4 Mar 2013 18:23:18 -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_33=0.6, 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 TZvjjAZASaEH for ; Mon, 4 Mar 2013 18:23:17 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 4555521F8700 for ; Mon, 4 Mar 2013 18:23:17 -0800 (PST) Received: from mail-ie0-f199.google.com (mail-ie0-f199.google.com [209.85.223.199]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 4 Mar 2013 20:23:11 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f199.google.com [209.85.223.199] #+LO+TR X-Umn-Classification: local Received: by mail-ie0-f199.google.com with SMTP id c13so35483715ieb.10 for ; Mon, 04 Mar 2013 18:23:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=tmkqcJmht6bqFTNkenFWAVWNOtrQoTP3mB10TTAUpY4=; b=MEC91XddL0bu8UnbdD6jKe+w+fsVVV6XG4EDyTOjoxbh4oxXRukhBj5SRBR3xo5jS3 aAhdV7SxaNkMmsuOei/ej2YQh36g0IR6cULWHqhRFmdLePSYIrRqYBlDM4D5C2XCf4dS BD+rk8RR52M+Qd8JCLtHqKHJ5R+xQGjAMJO74dXZcpVCtsqFqniv+wn0UjPeJq0InitP KwWkDnW1qGwAytyv2ub32XERk6VstOZ74Rm8/FEYaDmbJ9iQ03pmFqmPhqXqtACRHrRX NMjbr+eYumBUYe4LooJuAR5CjUXUik5zRFrI73hAKiWsAzYBqhSEcYJATvOjJLWRvtv0 S+ow== X-Received: by 10.50.17.166 with SMTP id p6mr4596325igd.12.1362450191628; Mon, 04 Mar 2013 18:23:11 -0800 (PST) X-Received: by 10.50.17.166 with SMTP id p6mr4596319igd.12.1362450191482; Mon, 04 Mar 2013 18:23:11 -0800 (PST) Received: from x-128-101-235-119.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:5dae:ae0:8c43:6bd7]) by mx.google.com with ESMTPS id in10sm12001574igc.1.2013.03.04.18.23.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Mar 2013 18:23:10 -0800 (PST) Message-ID: <51355715.2080704@umn.edu> Date: Mon, 04 Mar 2013 20:23:17 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Owen DeLong References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6E5795@nkgeml506-mbx.china.huawei.com> <20130304143357.GQ51699@Space.Net> <7A7F3288-3C21-4C27-8653-F90066F0BC38@delong.com> In-Reply-To: <7A7F3288-3C21-4C27-8653-F90066F0BC38@delong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmEwWQfJy643e4+oDMqHWaH+9YRoi4fBMg55ixYag2w4uWndGB8cCts4J/Wj17JgUNAFIOhbNnqRZYo8pBf0GPQbnu0mnEtocL2c/wmQfN8nra5kqvoXn8ZqURUvt+H83J2vzrN Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 02:23:18 -0000 On 3/4/13 14:25 , Owen DeLong wrote: > I'm fine if we don't mention NPT in the draft. > > If we are going to mention NPT, then I will strenuously object unless the draft also contains language specifying that any form of address translation is not recommended. Ok, here is a couple quotes from RFC 6296, section 1, Introduction; For reasons discussed in [RFC2993] and Section 5, the IETF does not recommend the use of Network Address Translation technology for IPv6. Where translation is implemented, however, this specification provides a mechanism that has fewer architectural problems than merely implementing a traditional stateful Network Address Translator in an IPv6 environment. Later in RFC 6296, section 4.1, Prefix Configuration and Generation; NPTv6 Translators MUST support manual configuration of internal and external prefixes and MUST NOT place any restrictions on those prefixes except that they be valid IPv6 unicast prefixes as described in [RFC4291]. They MAY also support random generation of ULA addresses on command. Since the most common place anticipated for the implementation of an NPTv6 Translator is a Customer Premises Equipment (CPE) router, the reader is urged to consider the requirements of [RFC6204]. So, I interpret that as saying the IETF consensus is that the use of address translation is NOT RECOMMENDED for IPv6, but that NTPv6 is a valid use case for ULA. Unless we wish to revisit the IETF consensus that address translation is NOT RECOMMENDED for IPv6, and I don't believe this draft is the proper way to revisit that consensus. Therefore, if NPTv6 are mentioned as recommended use cases for ULA in the draft then something to the effect of the following should be included as well; While NPTv6 is a recommended use cases for ULA, for reasons discussed in [RFC2993] and Section 5, the IETF does not recommend the use of Network Address Translation technology for IPv6. I'll note, the current version of draft mentions NTPv6 only in the context of section 2, ULA Usage Analysis, and not in section 3, Recommended ULA Use Cases. Therefore, as the current draft stands we don't need to include anything about the recommendation against NAT for IPv6, as it is not currently making any recommendation regarding NPTv6, it is only discussing it in the context of analysis. I only think this is needed if NTPv6 is added to section 3. I'm not opposed to including NTPv6 in section 3 if something like the above is included. Please note: I actually support broader use of NAT in IPv6, but if NPTv6 is a recommended use case of ULA in this draft and the recommendation against the use of NAT is not also included, it will only bog down the publication of what I think is a useful and important draft. This draft is not the right way to readdress the consensus against the use of NAT with IPv6. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From victor@jvknet.com Mon Mar 4 19:12:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992BF21F88F1 for ; Mon, 4 Mar 2013 19:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.486 X-Spam-Level: X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=0.6, RDNS_NONE=0.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 iqC8VdSQ9+74 for ; Mon, 4 Mar 2013 19:12:12 -0800 (PST) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6B39421F88D8 for ; Mon, 4 Mar 2013 19:12:12 -0800 (PST) Received: by mail-ia0-f169.google.com with SMTP id j5so5674363iaf.0 for ; Mon, 04 Mar 2013 19:11:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:user-agent:date:subject:from:to:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=zkGXYuJRRn32eMiSbFXAlv/qqhSa5cVpqxX+EflkLrY=; b=FqN9T64j2YQGfDKm/uzBt+RFeGz2aYFhVvSAbdvcW22hW86T7XJqWUnCDGI23hTcg9 EOJ+L8m5xxdDOCw7N8Sbha/jOflIyfQX+6SWb5i9fjt5oek4DtThVhHIx2R0dC10wFsC Owz59/DNLzJ5HeAfrTnO7WsH8SxgsbfjanzpqgJwKM+PQkwh3VCEJl3XV0OGX+0GA41A ZhG45O7fNmINQydskVWY1Nb0YGlKrAxm0ve8J2GS1CqMVbY+pMGLLaK4FFFOt368tPuI RwLKL0Rxznpw0QcpbEb48wXu7qARJhdxgz162xI7HX0EOWTgQnLyhQHNTQy4bgLY1PgK onNQ== X-Received: by 10.50.16.138 with SMTP id g10mr4778471igd.33.1362453116590; Mon, 04 Mar 2013 19:11:56 -0800 (PST) Received: from [192.168.100.33] ([67.224.83.162]) by mx.google.com with ESMTPS id i10sm12970468igz.9.2013.03.04.19.11.54 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 04 Mar 2013 19:11:55 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Mon, 04 Mar 2013 22:11:52 -0500 From: Victor Kuarsingh To: "STARK, BARBARA H" , james woodyatt , "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQn4E02FfFLCJ3tOn1zkj2xsARg6CJI7BPMeVmg1xUuNg7PGthfTYiLALTIu029cTJSgvudM Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 03:12:14 -0000 On 2013-03-04 6:20 PM, "STARK, BARBARA H" wrote: >> > (Actually there's 3 options - BGP+PI, ULA+NPTv6, and PA space >> >> Actually, there's a fourth: ULA+NAT66 (not NPTv6). >> >> As I have said elsewhere and I will repeat here, this option is the >>only one >> that guarantees that SOHO and HOMENET sites will always have a /48 with >>16 >> bits of subnet identifier space from which to choose random numbers that >> are statistically unlikely to collide in reasonably sized sites in the >>foreseeable >> future. >> >> Yes, it comes at a terrible price, but my view is that it's not that >>much worse >> than the price of NPTv6 and the guaranteed /48 prefix is more than worth >> the additional cost in transparency. > >I have to admit to having been curious about the lack of mention of this >4th option in this ULA discussion. I'd be very interested in better >understanding the "terrible price" of ULA+NAT66 vs. the "cost" of >ULA+NPTv6 vs. "RIR+ISP+other costs" of BGP+PI or PA space. I think the >information would be useful. If the price of getting the information is >that it has to have some sort of recommendation tacked on to it, that >doesn't bother me at all. >Barbara Barbara, I have been thinking about this quite a bit recently given all the comments on the various threads related to what started as a ULA use case document. >From my vantage point, I get the sense that many have different assessments of what the costs are (in value) based on various viewpoints. I.e. Cost to network operator (routing/scale/complexity/tooling/etc), cost to customer, cost to software developers who need to code around NATs, cost to device vendors etc. What may be possible in the more immediate timeframe would be a document that expresses the cost areas of the major options ( PA+DHCP/Routing, PI+BGP/Other, ULA+NPTv6, ULA+NAT66 etc). Not sure if this is valuable to anyone. If it is, it may be worth a try to draft something (may be met with stiff opposition). Another side observation I have is that there also seems to be some positions which are related to a "one-size-fits-all" addressing approach. This may not be a reasonable position. As an example, the original addressing (PA) model was complemented by PI - which seems to imply that more then one model was needed (at least). This is in effect a divergence from the original single model. I think, as much as it pains me to admit it, that there may be more models required to address the overall requirement set for all networks. I am also not sure if an open conversation related to what are in fact the requirements for customers and businesses is needed. Of course this is a slipper slope since it may quickly diverge away from a technical conversation into one fuelled by opinion. (waiting for attack :) Regards, Victor K >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Mon Mar 4 20:23:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D7921F88DB for ; Mon, 4 Mar 2013 20:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=0.6, 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 1FN6Gxo0WXQQ for ; Mon, 4 Mar 2013 20:23:45 -0800 (PST) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id DF96121F8738 for ; Mon, 4 Mar 2013 20:23:44 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id fn15so5169060wgb.32 for ; Mon, 04 Mar 2013 20:23:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8746jHogLkVAb8npJFfMCraM3A+BSFWkkbAZXTV3yn8=; b=C0j1E9a1LKPSryxiMwS+dSMqxvxqgDskJVlHO9B2d+Ak3onCyWGadiiWTdR6q+suSS dmPNFMXGp+X5LDzle5eB67VExvyugWCyI4Nj2dOIsbPm13OoKsu2C77D7qgLzdzuBnsj IyxZs06kbbfUNsB7ymyIy3fuTldaReYtTzCJV+4YSIa5xHXeaVv8c2KEleNfBCN/zDiB MVdUnnLsEw2a+2dUmeUJgi+eU6+T9QtWiOUDZM1csyWdJHXfnHQwbU+rsFvlfPmmjnuD FwbmXAFFiSPSR9oOcE0G3OFkkk52n6pZG9T+g3eGCCfz7RWpkdg3/CdEDsY2601Qv32u QAjQ== MIME-Version: 1.0 X-Received: by 10.194.6.2 with SMTP id w2mr36240620wjw.10.1362457423875; Mon, 04 Mar 2013 20:23:43 -0800 (PST) Received: by 10.194.20.35 with HTTP; Mon, 4 Mar 2013 20:23:43 -0800 (PST) In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Mon, 4 Mar 2013 20:23:43 -0800 Message-ID: From: Cameron Byrne To: Victor Kuarsingh Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 04:23:46 -0000 On Mon, Mar 4, 2013 at 7:11 PM, Victor Kuarsingh wrote: > > > On 2013-03-04 6:20 PM, "STARK, BARBARA H" wrote: > >>> > (Actually there's 3 options - BGP+PI, ULA+NPTv6, and PA space >>> >>> Actually, there's a fourth: ULA+NAT66 (not NPTv6). >>> >>> As I have said elsewhere and I will repeat here, this option is the >>>only one >>> that guarantees that SOHO and HOMENET sites will always have a /48 with >>>16 >>> bits of subnet identifier space from which to choose random numbers that >>> are statistically unlikely to collide in reasonably sized sites in the >>>foreseeable >>> future. >>> >>> Yes, it comes at a terrible price, but my view is that it's not that >>>much worse >>> than the price of NPTv6 and the guaranteed /48 prefix is more than worth >>> the additional cost in transparency. >> >>I have to admit to having been curious about the lack of mention of this >>4th option in this ULA discussion. I'd be very interested in better >>understanding the "terrible price" of ULA+NAT66 vs. the "cost" of >>ULA+NPTv6 vs. "RIR+ISP+other costs" of BGP+PI or PA space. I think the >>information would be useful. If the price of getting the information is >>that it has to have some sort of recommendation tacked on to it, that >>doesn't bother me at all. >>Barbara > > Barbara, > > I have been thinking about this quite a bit recently given all the > comments on the various threads related to what started as a ULA use case > document. > > From my vantage point, I get the sense that many have different > assessments of what the costs are (in value) based on various viewpoints. > I.e. Cost to network operator (routing/scale/complexity/tooling/etc), cost > to customer, cost to software developers who need to code around NATs, > cost to device vendors etc. > > What may be possible in the more immediate timeframe would be a document > that expresses the cost areas of the major options ( PA+DHCP/Routing, > PI+BGP/Other, ULA+NPTv6, ULA+NAT66 etc). Not sure if this is valuable to > anyone. If it is, it may be worth a try to draft something (may be met > with stiff opposition). > > Another side observation I have is that there also seems to be some > positions which are related to a "one-size-fits-all" addressing approach. > This may not be a reasonable position. As an example, the original > addressing (PA) model was complemented by PI - which seems to imply that > more then one model was needed (at least). This is in effect a divergence > from the original single model. I think, as much as it pains me to admit > it, that there may be more models required to address the overall > requirement set for all networks. I am also not sure if an open > conversation related to what are in fact the requirements for customers > and businesses is needed. Of course this is a slipper slope since it may > quickly diverge away from a technical conversation into one fuelled by > opinion. > > (waiting for attack :) > wait no longer. NAT / NPT6 breaks stuff and should not be used in any going-forward design. For example, say i have a simple SIP or WebRTC connection. It will use SDP (or similar) to communicate to the remote peer the address and ports to send me media... if the application is unaware of it's address, it wont work (sans band-aids like ICE, STUN, TURN ...) I think my address is FD09::1, so send it here from across the internet... hmm.. does not work... Granted, the world has STUN and TURN and ICE, but somebody asked about cost. There you have it, go price out some of that. Take it from a major CGN operator, don't do NAT. What problem are we trying to solve here? If SOHO customers want to run BGP, tell them to call he.net, nobody else is interested in providing a free service like this... and at the prices they charge, i am sure they can maintain a lock on the market and nobody will mind. If customers want NPTv6 or NAT66, there are boxes that do that, they can go crazy and tech-support themselves since they are so smart and justified in choosing this solution, or they can call tech-support of the CPE vendor who sold them that. Thanks! CB ps. Oh, yeah... add to the list of things that break to include RTSP, PPTP, IPsec AH, SIP, H323 (grasping at straws...), FTP, ... not a real who's who... but WebRTC might be a real zinger soon. > Regards, > > Victor K > > > >>_______________________________________________ >>v6ops mailing list >>v6ops@ietf.org >>https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From dougb@dougbarton.us Mon Mar 4 23:04:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3936421F85AD for ; Mon, 4 Mar 2013 23:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcxTDFf4rOfT for ; Mon, 4 Mar 2013 23:04:07 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9B50221F85B6 for ; Mon, 4 Mar 2013 23:04:07 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:d8a5:7c11:1cda:1a82] (unknown [IPv6:2001:470:d:5e7:d8a5:7c11:1cda:1a82]) by dougbarton.us (Postfix) with ESMTPSA id 7110122B6D for ; Tue, 5 Mar 2013 07:04:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362467047; bh=/wSPcCGErvevmNmGiPgheXBWBccrjmal+eii51m5uLQ=; h=Date:From:To:Subject:References:In-Reply-To; b=LqJ4GWZM9aOyxbXg+Rl/czIccENc2f6jD3ZGrwog7PxBvQqEQpVIXHZMVHpwBt2uL q1qB6dTCEf3Uulz2i63PyvLk9ogAhS9cSrAG4pn18vdiqZDnBECYVw0Ri5Jq7C7Abc V92C6Apnl1o2NGNX7K7GJEvX5UhoqOBKdkKBkalI= Message-ID: <513598E5.5060700@dougbarton.us> Date: Mon, 04 Mar 2013 23:04:05 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "v6ops@ietf.org" References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6E5795@nkgeml506-mbx.china.huawei.com> <20130304143357.GQ51699@Space.Net> <7A7F3288-3C21-4C27-8653-F90066F0BC38@delong.com> <51355715.2080704@umn.edu> In-Reply-To: <51355715.2080704@umn.edu> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 07:04:08 -0000 On 03/04/2013 06:23 PM, David Farmer wrote: > On 3/4/13 14:25 , Owen DeLong wrote: >> I'm fine if we don't mention NPT in the draft. >> >> If we are going to mention NPT, then I will strenuously object unless >> the draft also contains language specifying that any form of address >> translation is not recommended. > > Ok, here is a couple quotes from RFC 6296, section 1, Introduction; > > For reasons discussed in [RFC2993] and Section 5, the IETF does not > recommend the use of Network Address Translation technology for IPv6. > Where translation is implemented, however, this specification > provides a mechanism that has fewer architectural problems than > merely implementing a traditional stateful Network Address Translator > in an IPv6 environment. > > Later in RFC 6296, section 4.1, Prefix Configuration and Generation; > > NPTv6 Translators MUST support manual configuration of internal and > external prefixes and MUST NOT place any restrictions on those > prefixes except that they be valid IPv6 unicast prefixes as described > in [RFC4291]. They MAY also support random generation of ULA > addresses on command. Since the most common place anticipated for > the implementation of an NPTv6 Translator is a Customer Premises > Equipment (CPE) router, the reader is urged to consider the > requirements of [RFC6204]. > > So, I interpret that as saying the IETF consensus is that the use of > address translation is NOT RECOMMENDED for IPv6, but that NTPv6 is a > valid use case for ULA. Unless we wish to revisit the IETF consensus > that address translation is NOT RECOMMENDED for IPv6, and I don't > believe this draft is the proper way to revisit that consensus. The quote from Section 1 talks about NAT not being recommended, and then details the differences between traditional NAT and NPTv6. It also references other documents that discuss the tradeoffs, and Section 5 mentions some of them as well. For anyone involved in this discussion who hasn't actually read 6296, I highly recommend it. Personally I think it's very fair in discussing when NPT is useful, and when it isn't. So again, I'm not saying that a new document should say, "Hey, everyone, go do ULA + NPTv6, it's awesome!" Let's just be fair about it. Doug From dougb@dougbarton.us Mon Mar 4 23:14:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C9921F86A8 for ; Mon, 4 Mar 2013 23:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id texMfYuXXQNE for ; Mon, 4 Mar 2013 23:14:45 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDD821F868B for ; Mon, 4 Mar 2013 23:14:45 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:d8a5:7c11:1cda:1a82] (unknown [IPv6:2001:470:d:5e7:d8a5:7c11:1cda:1a82]) by dougbarton.us (Postfix) with ESMTPSA id 38E3422B6D for ; Tue, 5 Mar 2013 07:14:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362467685; bh=PiM3k2PNRySrEvb8yuQwP3Q7sIbE4BDzKEZ8qQ0vUXM=; h=Date:From:To:Subject:References:In-Reply-To; b=bOXsXejU0o+1pIG8evM2xNEQsI6RwoBAcOVuzcTVpmsPrYgkGQx6QNb7ZrWJRb+uu otvPdsKqEMISKOihNcEyTeJTZeRDakVgF4jsveKWaVh2ZOvAmFIjLttgSUfjo+uyJB ab/TpqS15UMt3zx9fvXum0Xsmfg8HcyCVlwwrDoo= Message-ID: <51359B64.7090006@dougbarton.us> Date: Mon, 04 Mar 2013 23:14:44 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 07:14:46 -0000 On 03/04/2013 08:23 PM, Cameron Byrne wrote: > > NAT / NPT6 breaks stuff and should not be used in any going-forward > design. Totally naive and unrealistic. > For example, say i have a simple SIP or WebRTC connection. It will > use SDP (or similar) to communicate to the remote peer the address > and ports to send me media... if the application is unaware of it's > address, it wont work (sans band-aids like ICE, STUN, TURN ...) I > think my address is FD09::1, so send it here from across the > internet... hmm.. does not work... Granted, the world has STUN and > TURN and ICE, but somebody asked about cost. There you have it, go > price out some of that. So given that we already have those solutions, what are the marginal costs or applying them to IPv6? Your arguments seem predicated on the need to recreate these solutions from scratch. But obviously we don't need to do that. My argument is that the marginal costs are very small, so small that they are effectively statistical noise. I haven't seen any arguments to refute that, only the same "NAT means we have to solve these problems!" argument which doesn't take reality into account. So please, refute my argument. Show me where I'm wrong. > Take it from a major CGN operator, don't do NAT. "Don't do that" is not a realistic argument in today's world. It's been ignored for 15 years already, and will continue to be ignored. > ps. Oh, yeah... add to the list of things that break to include > RTSP, PPTP, IPsec AH, SIP, H323 (grasping at straws...), FTP, ... not > a real who's who... but WebRTC might be a real zinger soon. The default for FTP has been passive mode for over a decade, and very few users even know that there used to be a different way of doing it. As discussed above, those other protocols all have NAT-traversal solutions, so as you asked in the bit that I snipped, "What problem are we trying to solve here?" Doug From lorenzo@google.com Mon Mar 4 23:38:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB4321F8645 for ; Mon, 4 Mar 2013 23:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 uL00yhoUDgfo for ; Mon, 4 Mar 2013 23:38:28 -0800 (PST) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id B710C21F8640 for ; Mon, 4 Mar 2013 23:38:28 -0800 (PST) Received: by mail-oa0-f46.google.com with SMTP id k1so10402488oag.5 for ; Mon, 04 Mar 2013 23:38:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=KYWifshoj76J6JEhtyxv/vwQOU1i9ncSJrLnkPjGZ8Y=; b=e90fv3I+M8yak2dboXEYsNKJVcoHgVbYrsRpo/gf4M/el8HqCWnI301Kkghn6Skv0k 8KSp08mT9R3/JD3tuQl88IOeBS8rPDdIpkYU70cDO3xXISROuaIvCE1040D4IlhV7Udp 6pJPR9kN52yko+8dGoJRrTG+4xiFRM7HN6g0Bx2XrXXtngWUdKJIWjQZSzNk1YeAtu4A HHDgncjcJnE2ngQapYx1frqlE98nHVQMHVHRCHRZuDt+mnvcA13oLfTmh6Xr1ZbJh4Ev F7ULhsAxoIvhxPJuUOun8rbtNUUGXlgEFMbkN4aJUjZ6deBFEnZTGoEngC+2kUpHBYfS qjEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=KYWifshoj76J6JEhtyxv/vwQOU1i9ncSJrLnkPjGZ8Y=; b=Hwvj6twKPEF52VD8zBcN2acuJWhP5g+P6pIG8zZP0qYOlA+Xvw9Lq+56N/H/KCLkq1 B9YimiNJkPw/CXf8ftQXvM/4Dn7pSa0aak9WKdteudAvsHuTxaIY9d2oy3px39KabhTH IU5ktvtqOnvF9nGmKa1HnEvDEmqKFZGi9yFpw7+/hKH5X08HnLvws42EIl7DdhP6rvCA ZX0IPcWkJatQbm1QaBe+Uv0RVu8+MVZ2SgewMQI3ibZ9WechoyyzrfNJsvQe/91C8D4P nP/C4ZqIUt9xmfv3AdioDbr5wQMQg+iJbistmMqVnlmBAqnFdBK2Rs4fajCzk3iLisQQ RJdw== X-Received: by 10.60.172.18 with SMTP id ay18mr17707586oec.126.1362469108062; Mon, 04 Mar 2013 23:38:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Mon, 4 Mar 2013 23:38:07 -0800 (PST) In-Reply-To: <51359B64.7090006@dougbarton.us> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> From: Lorenzo Colitti Date: Tue, 5 Mar 2013 16:38:07 +0900 Message-ID: To: Doug Barton Content-Type: multipart/alternative; boundary=bcaec54fae4834402f04d7288fd6 X-Gm-Message-State: ALoCoQnFTJmd0wEI5n4+GhQK++zSy3BB9SJr5eCWxXag1qYMvtSRo1W6BqYbaA+h4tnaU2kQvDYjDdXBZwjBEjNulGu0clV7FFK5I8NL/hovt+IiPx5NcGzFwxUMdvjZQ8lEDuUTMvtf1qGdJ2YDwipJiVRqxd6TILrCgCfeZ9yk+hTtN2mLlSUT7oMbNQNEno7sEsLQ1IAu Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 07:38:29 -0000 --bcaec54fae4834402f04d7288fd6 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 5, 2013 at 4:14 PM, Doug Barton wrote: > So given that we already have those solutions, what are the marginal costs > or applying them to IPv6? > For starters, that would involve substantial implementation effort. NAT traversal mechanisms are among the hardest pieces of code to port to IPv6, because their code is so IPv4-specific. Trust me, I've seen it happen. For example, adding IPv6 support to libjingle was a fair amount of work. Even then, we didn't support NAT or NPT for IPv6, we only supported rendezvous. So we did a lot of work and it will still not perform well if someone puts it behind a NAT / NPT. Your arguments seem predicated on the need to recreate these solutions from > scratch. But obviously we don't need to do that. My argument is that the > marginal costs are very small, so small that they are effectively > statistical noise. I haven't seen any arguments to refute that, only the > same "NAT means we have to solve these problems!" argument which doesn't > take reality into account. > > So please, refute my argument. Show me where I'm wrong. I listed a few reasons at: http://lists.cluenet.de/pipermail/ipv6-ops/2013-February/008411.html I don't think you ever replied to that. --bcaec54fae4834402f04d7288fd6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 5, 2013 at 4:14 PM, Doug Barton <dougb@doug= barton.us> wrote:
So g= iven that we already have those solutions, what are the marginal costs or a= pplying them to IPv6?

For starters, that would involve sub= stantial implementation effort. NAT traversal mechanisms are among the hard= est pieces of code to port to IPv6, because their code is so IPv4-specific.=

Trust me, I've seen it happen. For exam= ple, adding IPv6 support to libjingle was a fair amount of work. Even then,= we didn't support NAT or NPT for IPv6, we only supported rendezvous. S= o we did a lot of work and it will still not perform well if someone puts i= t behind a NAT / NPT.

Your arguments seem predicated on the need to recreate the= se solutions from scratch. But obviously we don't need to do that. My a= rgument is that the marginal costs are very small, so small that they are e= ffectively statistical noise. I haven't seen any arguments to refute th= at, only the same "NAT means we have to solve these problems!" ar= gument which doesn't take reality into account.

So please, refute my argument. Show me where I'm wrong.

I listed a few reasons at:

--bcaec54fae4834402f04d7288fd6-- From dougb@dougbarton.us Mon Mar 4 23:55:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E6221F8653 for ; Mon, 4 Mar 2013 23:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qin3x0EU-AT6 for ; Mon, 4 Mar 2013 23:55:38 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id E6FB321F85FC for ; Mon, 4 Mar 2013 23:55:37 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:d8a5:7c11:1cda:1a82] (unknown [IPv6:2001:470:d:5e7:d8a5:7c11:1cda:1a82]) by dougbarton.us (Postfix) with ESMTPSA id 6FE2822BA0 for ; Tue, 5 Mar 2013 07:55:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362470137; bh=OFz7h+dmdhOdx+Ta+Hi2HIC8shI5uypGK8ySo9ERK4c=; h=Date:From:To:Subject:References:In-Reply-To; b=uELW1Dc/arCsZdk0rwY+wDgdFGBNcuknU1CWSuw1sXt8o932PNBfOA+km/5Iy2mc9 LM+OEp3djze2Xtg11fhaVHkc6f6csm5cbVoAYMwjNjlZFGqLB3ywu6l+BBuEX3FL4y GJMio/Gd5FLh6HmoA1lpp2f3f9G6pne7Sm40jM3w= Message-ID: <5135A4F9.6070306@dougbarton.us> Date: Mon, 04 Mar 2013 23:55:37 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "v6ops@ietf.org WG" References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 07:55:38 -0000 On 03/04/2013 11:38 PM, Lorenzo Colitti wrote: > On Tue, Mar 5, 2013 at 4:14 PM, Doug Barton > wrote: > > So given that we already have those solutions, what are the marginal > costs or applying them to IPv6? > > > For starters, that would involve substantial implementation effort. NAT > traversal mechanisms are among the hardest pieces of code to port to > IPv6, because their code is so IPv4-specific. > > Trust me, I've seen it happen. For example, adding IPv6 support to > libjingle was a fair amount of work. Even then, we didn't support NAT or > NPT for IPv6, we only supported rendezvous. So we did a lot of work and > it will still not perform well if someone puts it behind a NAT / NPT. > > Your arguments seem predicated on the need to recreate these > solutions from scratch. But obviously we don't need to do that. My > argument is that the marginal costs are very small, so small that > they are effectively statistical noise. I haven't seen any arguments > to refute that, only the same "NAT means we have to solve these > problems!" argument which doesn't take reality into account. > > So please, refute my argument. Show me where I'm wrong. > > > I listed a few reasons at: > > http://lists.cluenet.de/pipermail/ipv6-ops/2013-February/008411.html > > I don't think you ever replied to that. No, I didn't, because your conclusion wasn't rational, and didn't take into account anything I had already said as part of that lengthy thread. You're arguing about costs to developers who are going to build or update solutions that already exist for IPv4 so that they can be used for IPv6. The point I've made ad nauseum is that THOSE COSTS ARE GOING TO BE PAID NO MATTER WHAT. There is no world where there will not be NAT/NPT/etc. Your syllogism about "insufficient incentive" for app developers to support NPTv6 is completely unrealistic (not to mention your Skype example was a complete non sequitur). People will use ULA + NPTv6 (they already are), and other IPv6 options that have similar requirements. Therefore all rational app developers who want their app to work robustly with IPv6 and need to permit connections back in from the outside will use a traversal solution. Just like in IPv4, initial implementations of those solutions will be written, they will be debugged, and _just like in IPv4_ they will eventually become standardized and robust. Does life suck for people (like you) who have to do that early work? Sure it does. Is it a "cost" that has to be paid by someone other than the people deploying NPT? Absolutely. But those aren't the relevant questions to the manager trying to decide how best to deploy IPv6 on their inside network. In fact, to the extent that this theoretical manager even understands the questions, she doesn't care about the answers. She just wants a solution that works, and in the majority of cases ULA + NPTv6 is going to work just fine, and has way more benefits than costs _to the organization deploying it_. Your complaining that these costs of NPT are being borne by those other than the ones deploying it amount to saying, "That's not fair!" I'm not arguing whether you're right or not. I'm arguing that right or wrong, it's not relevant. Doug From v6ops@globis.net Mon Mar 4 23:57:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C7621F87FD for ; Mon, 4 Mar 2013 23:57:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teAH-TkQRWGZ for ; Mon, 4 Mar 2013 23:57:30 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 699CE21F87F5 for ; Mon, 4 Mar 2013 23:57:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 87FC0870087; Tue, 5 Mar 2013 08:57:13 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eb0lDA-DhB15; Tue, 5 Mar 2013 08:56:52 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 99D5987007A; Tue, 5 Mar 2013 08:56:52 +0100 (CET) Message-ID: <5135A53E.5050105@globis.net> Date: Tue, 05 Mar 2013 08:56:46 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Owen DeLong References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <3B96D0EE-B19F-4770-85D0-F7C2136F0BEA@delong.com> <513299CE.20509@dougbarton.us> <1364B842-D3BE-48C1-A2A5-3D74DC37DB4A@delong.com> <513457E6.6060201@dougbarton.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 07:57:31 -0000 Owen DeLong wrote: > > There's lots of desktop collaboration that occurs outside of the enterprise world. Further, with the ever increasing level of BYOD, multiple connectivities, etc. I think that our authentication and authorization models for network traffic are going to change significantly in the future, especially when you consider things that are possible with MIP6. I think you'll see more end-to-end ESP/AH used rather than straight firewalls and that you will see direct untranslated traversal through the firewall of packets which are part of valid existing security associations or which are intended to set up such security associations. BYOD is a game changer. As are highly mobile devices. As is cloud computing. As is cross-enterprise collaboration. It's not just one thing. The notion that an enterprise is a monolithic entity; where all the users, data, and applications are on the "inside", and all the bad stuff is on the outside, is outdated. BYOD means a loss of control of devices. How are you going to distribute a ULA source address selection policy to someone's iDevice if you use more than one /48 ULA? Highly mobile devices are challenging the split name space. How are you going to run IPv6 DNS not spilt, whilst IPv4 DNS remains split? It's not just dual-stack DNS server reachability, you're probably going to have to serve different content too, depending on location, and flush caching as nodes move. It's probably going to be much easier just to run IPv6-only for highly mobile devices (if we ever get them). Cross-enterprise collaboration is stretching applications, and cloud computing is stretching authentication. SAML can be easily proxied from ULA to GUA, but other authentication methods and apps can't. This isn't just theory or foil ware: the switch is happening very rapidly in my customers AFAICS. So I think that even if you are thinking of using NPT, you would still be wise to deploy GUA PI space in a large enterprise (and no ULA at all), just in case the border ever does need to become more transparent. PI space is readily available and cheap in enterprise terms. ULA is not a pre-req for NPT. That's RFC1918 thinking. IMHO ULA is currently limited by practical considerations to on-site communication (in the event a non PI GUA disappears, or for stand-alone networks), and a single /48. regards, RayH From dougb@dougbarton.us Tue Mar 5 00:15:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E259D21F86D6 for ; Tue, 5 Mar 2013 00:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.377, 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 wMy332N61HLJ for ; Tue, 5 Mar 2013 00:15:11 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 1695421F8673 for ; Tue, 5 Mar 2013 00:15:11 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:d8a5:7c11:1cda:1a82] (unknown [IPv6:2001:470:d:5e7:d8a5:7c11:1cda:1a82]) by dougbarton.us (Postfix) with ESMTPSA id 9E79C22B6D; Tue, 5 Mar 2013 08:15:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362471310; bh=i8KACUxXDLwZ2Zo0HsbdKgjGdpy6H8A38AbqX9Tc8bQ=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=AYKywInKWJN1WzaFt0h3AjGVgYKMx6b6QTCr2kW0mG7fk+hBeGGGcNHu4m2OfLsiD iSwWu0SbUb+aPDtZSWC1n05qyTkNCtBgSfhDxNY77iXjIF6s8PH5PgKZRSlNoqb7bZ PIXL4xj1sxLm08rWX22nw0OtZtLLHvRqQMR/3U9c= Message-ID: <5135A98E.3000705@dougbarton.us> Date: Tue, 05 Mar 2013 00:15:10 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: David Farmer References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> <92E6AF8C-F7A6-4291-9856-D972B371BF10@delong.com> <51353736.3000800@umn.edu> <51353974.60707@dougbarton.us> <51354262.9000604@umn.edu> In-Reply-To: <51354262.9000604@umn.edu> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 08:15:12 -0000 On 03/04/2013 04:54 PM, David Farmer wrote: > On 3/4/13 18:16 , Doug Barton wrote: >> On 03/04/2013 04:07 PM, David Farmer wrote: >>> I don't believe the content networks were particularly advocates of PI, >>> at least not any more than a number of other groups. That said, I >>> believe content networks generally supported PI, but so did many >>> others. So, primarily crediting content networks for PI is an over >>> statement of their role. >> >> Fair enough. My point remains however. As-designed IPv6 was PA only. It >> took an enormous hue and cry to get that changed. And yes, the policy >> change happened at the RIRs, > > Agreed. > >> but not till AFTER the IETF signed off, > > I don't recall any RFC or other consensus from the IETF that called for > PI, there may have been a consensus that GUA-PI was a better idea than > ULA-C, that is the closest to a consensus for PI I can think of. That was part of it. The other part was the conversation (repeated at all the different RIR meetings I attended) that went something like this: people: We need PI space for IPv6 RIR: We have no guidance from the IETF on allocations to individuals, only to ISPs. IETF: Yeah, and that's how it's going to stay. At the time (2003-2005 time frame) there was still a very vocal contingent that was saying that mip6 was going to be the answer to the traditional multihoming problem, and didn't want any attention diverted from that goal. Also see below on other road blocks. Eventually the pressure to permit PI space became overwhelming, cooler heads prevailed, and the right conversations were had with the right people to make it all happen. FWIW I never got the sense that the RIRs were against it necessarily, they just didn't want to cheese off the militant no-PI folks in the IETF. > I'd > love to be wrong on that as I still have people grumble at me about the > ARIN policy I authored. Being able to provide a quote that there was a > IETF consensus for PI would still be helpful to me personally if there > is one to point to. There was not a specific document that said, "Ok, PI space is fine, go for it." In fact given the climate at the time that wasn't even possible. "Grudging acknowledgement" was the only possible outcome, and yes, people like you took heat for not only acknowledging reality, but acting in the best interests of long-term IPv6 deployment. Thank you. :) >> which did not occur till AFTER various large network operators made it >> clear that they would never deploy v6 till PI space was available. > > Many of the largest network operators supported the PA-only model and > mostly did not support PI. Some relented as it became obvious that the > lack of IPv6 PI was a huge drag on IPv6 adoption, especially as IPv4 > run-out actually started to loom big on the horizon. Sorry I wasn't clear. When I say network operators I do not mean ISPs. Obviously they were all in favor of the "PA-only" model, since it amounted to a near lock-in for the customers that purchased IPv6 from them. In fact, when talking to the CTOs of a lot of the large enterprises, not getting locked in to a given ISP was their chief concern. Renumbering was a close second, but they did not want to give up the bargaining advantage that IPv4 PI gave them. A less charitable person than myself would argue that it was the big ISPs that were one of the key driving forces of the PA-only model, but I digress. :) Doug From dougb@dougbarton.us Tue Mar 5 00:19:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192B721F86D9 for ; Tue, 5 Mar 2013 00:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.301, 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 5vbWsLUyKKbL for ; Tue, 5 Mar 2013 00:19:31 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 14DBB21F85C9 for ; Tue, 5 Mar 2013 00:19:31 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:d8a5:7c11:1cda:1a82] (unknown [IPv6:2001:470:d:5e7:d8a5:7c11:1cda:1a82]) by dougbarton.us (Postfix) with ESMTPSA id C0D9922B6D for ; Tue, 5 Mar 2013 08:19:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362471570; bh=aGFD773mBqoWEXxp4Wqd+zVRSCZWSLsnAEpOmS6YFYI=; h=Date:From:To:Subject:References:In-Reply-To; b=F9BJnyTzSyrAfPSgK+7PvHE1xB7GFrHGf/IrYaqD23/G7krrNgdYgSJ9yFc63oH+L cB0sdxsrszTKi9IKIilBne7js6B2slVDz+Plq6Lw0X4civ+rfDdCD24Kvebj0U31sN Rc/v1CekklrZi6mWTI1AniqoO51xsAf9LjVTb50c= Message-ID: <5135AA92.10106@dougbarton.us> Date: Tue, 05 Mar 2013 00:19:30 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <3B96D0EE-B19F-4770-85D0-F7C2136F0BEA@delong.com> <513299CE.20509@dougbarton.us> <1364B842-D3BE-48C1-A2A5-3D74DC37DB4A@delong.com> <513457E6.6060201@dougbarton.us> <5135A53E.5050105@globis.net> In-Reply-To: <5135A53E.5050105@globis.net> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 08:19:32 -0000 On 03/04/2013 11:56 PM, Ray Hunter wrote: > > Owen DeLong wrote: >> >> There's lots of desktop collaboration that occurs outside of the enterprise world. Further, with the ever increasing level of BYOD, multiple connectivities, etc. I think that our authentication and authorization models for network traffic are going to change significantly in the future, especially when you consider things that are possible with MIP6. I think you'll see more end-to-end ESP/AH used rather than straight firewalls and that you will see direct untranslated traversal through the firewall of packets which are part of valid existing security associations or which are intended to set up such security associations. > > BYOD is a game changer. Agreed. We're seeing this as a key driving force in the DNS/DHCP/IPAM space as well. [snipping some of your other excellent points] > So I think that even if you are thinking of using NPT, you would still > be wise to deploy GUA PI space in a large enterprise (and no ULA at > all), just in case the border ever does need to become more transparent. > PI space is readily available and cheap in enterprise terms. ULA is not > a pre-req for NPT. That's RFC1918 thinking. Just to be clear, I'm not saying that ULA is a pre-req for NPT, and for large enterprises GUA + NPT may very well be a valid solution. My point is that there is nothing about ULA, NPT, or the combination thereof that is inherently evil. :) Doug From lorenzo@google.com Tue Mar 5 00:21:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C1821F88E1 for ; Tue, 5 Mar 2013 00:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 FAPHIw5Fgcy8 for ; Tue, 5 Mar 2013 00:21:18 -0800 (PST) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB1321F88A9 for ; Tue, 5 Mar 2013 00:21:18 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id o17so10351099oag.6 for ; Tue, 05 Mar 2013 00:21:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=bd1GU8GVCAoe3aqAQXL08LO87uWDwWOJAj0T5zPmUkQ=; b=AcFVnk3MYcMeRvQ0kqbKz2TXjl3XCsbUSDkAQxy1jD+ggkRVJ396Vdo2V16UAIxeoz aO9n6MCgLxATmj0cu725eZL0nCUHDP4kONgj0NYkda86rxvD5FsCbHm95oiI8GUx2xMD Wzu0dyENHBZe+WM3kx56Al5jp7P3qoS7qbfkthZdtVBfxJ7foEDjbNEQs9QRMbzqv0+4 Rp08Z33p3+UGOA0jJVJCjH0SjMS7hpxxINu/fbiWt32C5zYsE39uU1po2kWp1cMTKR7/ B68Nb7FOW3aUhjXaJeelmgkJv5zL1I3RJa/2YEMNQos8nfrm6ylG/F6wvz7HkMwvpV4F 7ngw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=bd1GU8GVCAoe3aqAQXL08LO87uWDwWOJAj0T5zPmUkQ=; b=UuyBw8QVLhOgIJlEeYmFQOIaXlUcdIUc5uXsNFNlxsHcrbqmo+02FbSHxVgkK6L0Fa 6QHXDZ3KNGmMPrQ+VZeXF8PEjX1PFEFecxiCQY9qxAoTy93+NeyV3Qmp8ON8kCITnm6E q7Opaf4lVxN+lAmQPX+5VU64+5LKgvw/zX76JZpjkdK7ndZ4SDa4XVlUvwmxGQpUa9K2 sTEfeQi3KFzx26GeaHxeIgg3i1kt0qodu/SFg59dEuyaKppFFphkw+j2RTP31SmqQL9O St4CY5uiKyyhQ7JnpbIODBxlVTrIS3YFjuudg70zhsPFit5hOfLAJLrYWq4KMXaBCrby M5EA== X-Received: by 10.60.20.193 with SMTP id p1mr18377231oee.133.1362471677586; Tue, 05 Mar 2013 00:21:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Tue, 5 Mar 2013 00:20:57 -0800 (PST) In-Reply-To: <5135A4F9.6070306@dougbarton.us> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> From: Lorenzo Colitti Date: Tue, 5 Mar 2013 17:20:57 +0900 Message-ID: To: Doug Barton Content-Type: multipart/alternative; boundary=e89a8ff1c2d85c159d04d72928ee X-Gm-Message-State: ALoCoQmMseYZCBTI3aDC2WBYcn+Oq0mSOwtUBWxVB0jRBqmYMSw8lpq+LfaWsxsMxrHhAYdmTY7wjQYby6WcXHkmqvLB3ShnahE9lcA8ME/6e7IKeBkt2M2Xq5h62V/Ku5jA3KOWIfR0jkFqX/vZ2Jb7CEqB40JDrqC349HPBpadzILEG30YkBkLaCDI4LL4JTHMgg1GPEiY Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 08:21:19 -0000 --e89a8ff1c2d85c159d04d72928ee Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 5, 2013 at 4:55 PM, Doug Barton wrote: > You're arguing about costs to developers who are going to build or update > solutions that already exist for IPv4 so that they can be used for IPv6. > The point I've made ad nauseum is that THOSE COSTS ARE GOING TO BE PAID NO > MATTER WHAT. > Wait - you asked about the costs. (Specifically, you wrote "given that we already have those solutions, what are the marginal costs or applying them to IPv6?"). I replied pointing out some of the costs that have to be borne. And those are real costs, because software engineering is expensive. Then you say those costs are going to be paid no matter what. But they won't. It depends on what gets deployed. For example, in a case where all the IPv6 users in the world except one are using global addresses, then no developer will develop NAT66/NPT66 traversal techniques, because there is no market for them. If that happens, then the organizations that deploy NPT66 will bear support costs of because their apps won't work. I think it's safe to say that since no commercial IPv6 deployments today use NPT66, the vast majority (>99%?) of IPv6 users today does not obtain their Internet connection through an NPT66 box. That doesn't seem like an attractive use case to justify developers investing time into NAT66/NTP66 traversal techniques. Also, it does seem that "the costs are going to get paid no matter what, so there are no costs, therefore we should deploy networks that require translation" is a bit of a circular argument. --e89a8ff1c2d85c159d04d72928ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 5, 2013 at 4:55 PM, Doug Barton <dougb@doug= barton.us> wrote:
You&= #39;re arguing about costs to developers who are going to build or update s= olutions that already exist for IPv4 so that they can be used for IPv6. The= point I've made ad nauseum is that THOSE COSTS ARE GOING TO BE PAID NO= MATTER WHAT.

Wait - you asked about the costs. (S= pecifically, you wrote "given that we already have those solutions, wh= at are the marginal costs or applying them to IPv6?"). I replied point= ing out some of the costs that have to be borne. And those are real costs, = because software engineering is expensive.

Then you say those costs are going to be pa= id no matter what. But they won't. It depends on what gets deployed. Fo= r example, in a case where all the IPv6 users in the world except one are u= sing global addresses, then no developer will develop NAT66/NPT66 traversal= techniques, because there is no market for them. If that happens, then the= organizations that deploy NPT66 will bear support costs of because their a= pps won't work.

I think it's safe to say that since no = commercial IPv6 deployments today use NPT66, the vast majority (>99%?) o= f IPv6 users today does not obtain their Internet connection through an NPT= 66 box. That doesn't seem like an attractive use case to justify develo= pers investing time into NAT66/NTP66 traversal techniques.

Also, it does seem that "the costs are= going to get paid no matter what, so there are no costs, therefore we shou= ld deploy networks that require translation" is a bit of a circular ar= gument.
--e89a8ff1c2d85c159d04d72928ee-- From dougb@dougbarton.us Tue Mar 5 00:25:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D467C21F870E for ; Tue, 5 Mar 2013 00:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ld1Ynt9IGk22 for ; Tue, 5 Mar 2013 00:25:07 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 484CF21F86D2 for ; Tue, 5 Mar 2013 00:25:07 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:d8a5:7c11:1cda:1a82] (unknown [IPv6:2001:470:d:5e7:d8a5:7c11:1cda:1a82]) by dougbarton.us (Postfix) with ESMTPSA id D863422B6D for ; Tue, 5 Mar 2013 08:25:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362471906; bh=iU4v2qOz5ywb/Pt99magaMIQAuKFAgy2ssCxkg86yIU=; h=Date:From:To:Subject:References:In-Reply-To; b=R3T6Pe4nz7cBShMJQvpJkFf+RqOju2QmxUPdYIaRRftIWrgPlkmSJ4sBfttExaxA6 icCxoJU52mimhMAFmW0g/C7tDj0qRwEEXlQIkO5XnSj/5ADFOB/yB/OPHeZ5/XeaDO YlgeE4PDys4/RGW++yeqMP79B/TrEJ5nYDLLz7J8= Message-ID: <5135ABE2.5030004@dougbarton.us> Date: Tue, 05 Mar 2013 00:25:06 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "v6ops@ietf.org WG" References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 08:25:07 -0000 Lorenzo, Either you don't understand what I've written several times now, or you are intentionally twisting my words to make my argument seem unreasonable. Regardless of which one of those is true, I have run out of new and different ways to repeat the same points, and I'm sure the other members of the list are tired of me trying. :) Doug On 03/05/2013 12:20 AM, Lorenzo Colitti wrote: > On Tue, Mar 5, 2013 at 4:55 PM, Doug Barton > wrote: > > You're arguing about costs to developers who are going to build or > update solutions that already exist for IPv4 so that they can be > used for IPv6. The point I've made ad nauseum is that THOSE COSTS > ARE GOING TO BE PAID NO MATTER WHAT. > > > Wait - you asked about the costs. (Specifically, you wrote "given that > we already have those solutions, what are the marginal costs or applying > them to IPv6?"). I replied pointing out some of the costs that have to > be borne. And those are real costs, because software engineering is > expensive. > > Then you say those costs are going to be paid no matter what. But they > won't. It depends on what gets deployed. For example, in a case where > all the IPv6 users in the world except one are using global addresses, > then no developer will develop NAT66/NPT66 traversal techniques, because > there is no market for them. If that happens, then the organizations > that deploy NPT66 will bear support costs of because their apps won't work. > > I think it's safe to say that since no commercial IPv6 deployments today > use NPT66, the vast majority (>99%?) of IPv6 users today does not obtain > their Internet connection through an NPT66 box. That doesn't seem like > an attractive use case to justify developers investing time into > NAT66/NTP66 traversal techniques. > > Also, it does seem that "the costs are going to get paid no matter what, > so there are no costs, therefore we should deploy networks that require > translation" is a bit of a circular argument. From brian.e.carpenter@gmail.com Tue Mar 5 00:32:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCEE21F8910 for ; Tue, 5 Mar 2013 00:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.37 X-Spam-Level: X-Spam-Status: No, score=-100.37 tagged_above=-999 required=5 tests=[AWL=-0.479, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=0.6, RCVD_ILLEGAL_IP=1.908, 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 VtaZfw9HLn1h for ; Tue, 5 Mar 2013 00:32:35 -0800 (PST) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1C621F8862 for ; Tue, 5 Mar 2013 00:32:35 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id fm10so5413580wgb.9 for ; Tue, 05 Mar 2013 00:32:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NANJILpgtM0SCzCKGK7s38HymM1++Y62BlKefkT7gV0=; b=AnZeDJggKgomoMpI/MB8Wq+iV0nI+n5jALbfv8OXjUYp8SfTFWbGfGJOyyhg1dGOww Qnsza2ulF2sVxFp+CFrrhzXvP/UP4fsPtx4941ekcu6f5yA22NLQ7cTvm0uOCENtNrRC mCWT/aZ615RwQjBWGiK8mAR+tPx2dWloKwo+3n8llhgOTO/TrYg+iK0Weh2Cn2GE/JXH kGarW/pFFm71oChArEy62ry4W1ZT/nb+dsLgykq01H9Cm1wU2IkNiHj7iJxAN4mC3ICj WSByBQFyfyaNBf7jUqjDCXqu4lkuzrJtJSqpTrk+97hUx1weuwX8/+4EXhWwm76BxyoG 7phA== X-Received: by 10.194.19.135 with SMTP id f7mr37239492wje.27.1362472354431; Tue, 05 Mar 2013 00:32:34 -0800 (PST) Received: from [192.168.1.65] (host-2-101-188-194.as13285.net. [2.101.188.194]) by mx.google.com with ESMTPS id k5sm20804668wiy.5.2013.03.05.00.32.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Mar 2013 00:32:33 -0800 (PST) Message-ID: <5135ADA5.2070403@gmail.com> Date: Tue, 05 Mar 2013 08:32:37 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "STARK, BARBARA H" References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6E5795@nkgeml506-mbx.china.huawei.com> <20130304143357.GQ51699@Space.Net> <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 08:32:35 -0000 On 04/03/2013 23:20, STARK, BARBARA H wrote: >>> (Actually there's 3 options - BGP+PI, ULA+NPTv6, and PA space >> Actually, there's a fourth: ULA+NAT66 (not NPTv6). >> >> As I have said elsewhere and I will repeat here, this option is the only one >> that guarantees that SOHO and HOMENET sites will always have a /48 with 16 >> bits of subnet identifier space from which to choose random numbers that >> are statistically unlikely to collide in reasonably sized sites in the foreseeable >> future. >> >> Yes, it comes at a terrible price, but my view is that it's not that much worse >> than the price of NPTv6 and the guaranteed /48 prefix is more than worth >> the additional cost in transparency. > > I have to admit to having been curious about the lack of mention of this 4th option in this ULA discussion. Really? We had this conversation when NPTv6 was a draft, and RFC 6296 explains the advantages over NAT66. Brian > I'd be very interested in better understanding the "terrible price" of ULA+NAT66 vs. the "cost" of ULA+NPTv6 vs. "RIR+ISP+other costs" of BGP+PI or PA space. I think the information would be useful. If the price of getting the information is that it has to have some sort of recommendation tacked on to it, that doesn't bother me at all. > Barbara > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From pkern@spike.0x539.de Tue Mar 5 00:36:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF32921F87BA for ; Tue, 5 Mar 2013 00:36:45 -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_33=0.6] 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 czK3o3DNspH0 for ; Tue, 5 Mar 2013 00:36:45 -0800 (PST) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id 1309021F875A for ; Tue, 5 Mar 2013 00:36:44 -0800 (PST) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UCnMV-00081q-0k for v6ops@ietf.org; Tue, 05 Mar 2013 09:36:39 +0100 Received: from [2001:470:720c:0:55dc:aefc:b3b4:c295] (helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1UCnMW-00043w-1l for v6ops@ietf.org; Tue, 05 Mar 2013 09:36:40 +0100 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1UCnML-0008Dk-4C for v6ops@ietf.org; Tue, 05 Mar 2013 09:36:29 +0100 Date: Tue, 5 Mar 2013 09:36:29 +0100 From: Philipp Kern To: "v6ops@ietf.org WG" Message-ID: <20130305083629.GA31370@spike.0x539.de> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5135ABE2.5030004@dougbarton.us> Organization: 0x539 dev group User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 08:36:45 -0000 On Tue, Mar 05, 2013 at 12:25:06AM -0800, Doug Barton wrote: > Either you don't understand what I've written several times now, or > you are intentionally twisting my words to make my argument seem > unreasonable. Regardless of which one of those is true, I have run > out of new and different ways to repeat the same points, and I'm > sure the other members of the list are tired of me trying. :) It seems to me that Lorenzo's point is that the vast majority of *current* deployments are not using ULA + NPTv6. You say it's already used, but a lot of features are used somewhere, even if not widely. Hence Lorenzo claims that the development cost is not paid for supporting that fringe use case, because the installed base is too tiny. After all in commercial deployments you care not about supporting each and every use case but the ones that are relevant and make money. You claim that the cost will be paid regardless, he claims that it won't be. The technical manager of the company who opts for ULA + NPTv6 needs to be aware if there are others doing it to be supported by applications and content providers (whatever content that is, might even be p2p). Or if the mass is not relevant, possibly opt for something else. Sort of like the same situation we had with IPv6. There had to be relevance, with a similar chicken and egg problem, too. Kind regards Philipp Kern From brian.e.carpenter@gmail.com Tue Mar 5 00:45:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6435821F86CA for ; Tue, 5 Mar 2013 00:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.174 X-Spam-Level: X-Spam-Status: No, score=-101.174 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, 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 31pgyIbKTWe9 for ; Tue, 5 Mar 2013 00:45:06 -0800 (PST) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id C671421F86C2 for ; Tue, 5 Mar 2013 00:45:05 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id 12so5146596wgh.31 for ; Tue, 05 Mar 2013 00:45:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fM9XEqNPdfQE63CwDtdM1UNtLI0Mt863+pZX2y7O060=; b=gKICK7CAvZdEJsAuHjHONfsC08w3tPeaZteAh21bkDaljUpFtZVA/BPErmmFUOP8r7 ozuAkSAN81CoZZMgwFZ9r1LSE90RcPpnTb6+krrnziDWhULj3Q4xUTRM2t5P11w3wJIF aE5Z/uV8v6OvmL1gEIbapB370u9ROomk/BO//xBHzCzUqWikN4iLsV3UnLfBVCEhlyAl pk/gyPhQK/BiJf6HdOUP430mu7Y+Jpp4UIszSLR/UG2wniG870ylvVOLwhNfmjOwngr/ DNSrD3cE7tDQ9g0baHAZ5SHF3NhIEjBzlphDk2/A6OvjxB2feNApZxfANmGGC/6Mv9GD uxNw== X-Received: by 10.194.103.72 with SMTP id fu8mr37197893wjb.42.1362473105010; Tue, 05 Mar 2013 00:45:05 -0800 (PST) Received: from [192.168.1.65] (host-2-101-188-194.as13285.net. [2.101.188.194]) by mx.google.com with ESMTPS id eo1sm18873332wib.8.2013.03.05.00.45.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Mar 2013 00:45:03 -0800 (PST) Message-ID: <5135B093.2030208@gmail.com> Date: Tue, 05 Mar 2013 08:45:07 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Owen DeLong References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> <92E6AF8C-F7A6-4291-9856-D972B371BF10@delong.com> <51353736.3000800@umn.edu> <51353974.60707@dougbarton.us> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 08:45:06 -0000 On a point of historical fact: On 05/03/2013 00:52, Owen DeLong wrote: ... > The IETF did NOT sign off on PI for IPv6 before the RIR policies were already implemented and dispensing it. > > I don't know if the IETF ever officially signed off on it or not, but I do know that at least the first RIR policy was decided and implemented without any regard to IETF action on the subject. The IETF gave control over address assignment policy to IANA on March 1st, 2000 [RFC2860, clause 4.3]. Brian From dougb@dougbarton.us Tue Mar 5 00:56:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D2421F8735 for ; Tue, 5 Mar 2013 00:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rn28r6AuaNGG for ; Tue, 5 Mar 2013 00:56:48 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id CD27321F8754 for ; Tue, 5 Mar 2013 00:56:47 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:d8a5:7c11:1cda:1a82] (unknown [IPv6:2001:470:d:5e7:d8a5:7c11:1cda:1a82]) by dougbarton.us (Postfix) with ESMTPSA id 6D99222B6D for ; Tue, 5 Mar 2013 08:56:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362473807; bh=iFcZZXeKm1wUcgFGxPDHmR7arp4ostvJCnK2LOEjAUI=; h=Date:From:To:Subject:References:In-Reply-To; b=MdmitdfOrq9dH+oFVX3BuFpU9DsrSwNz2eRdmviv3PuO8di5kmm6ewty+xHRuKpIJ qYTYzwz6ltV8mCtvmUCRT8G53BgtYem6kSJrfh9BolaJpByAZvAtjVtDPyAwXGI9kd zFiicaW/tpRvtgWzip0J0cUI+YnxItq+hb+Vp37s= Message-ID: <5135B34F.8030809@dougbarton.us> Date: Tue, 05 Mar 2013 00:56:47 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> In-Reply-To: <20130305083629.GA31370@spike.0x539.de> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 08:56:49 -0000 On 03/05/2013 12:36 AM, Philipp Kern wrote: > On Tue, Mar 05, 2013 at 12:25:06AM -0800, Doug Barton wrote: >> Either you don't understand what I've written several times now, or >> you are intentionally twisting my words to make my argument seem >> unreasonable. Regardless of which one of those is true, I have run >> out of new and different ways to repeat the same points, and I'm >> sure the other members of the list are tired of me trying. :) > > It seems to me that Lorenzo's point is that the vast majority of *current* > deployments are not using ULA + NPTv6. The vast majority of current deployments aren't using IPv6, period. Of the tiny percentage that are, some percentage of them are using a NAT-a-like strategy. Many won't deploy IPv6 at all unless they have similar capabilities to what they are already using in IPv4 NAT. Of the possible NAT-a-likes for IPv6, 6296 is by far the least painful. > You say it's already used, but a > lot of features are used somewhere, even if not widely. Hence Lorenzo > claims that the development cost is not paid for supporting that fringe > use case, because the installed base is too tiny. After all in commercial > deployments you care not about supporting each and every use case but > the ones that are relevant and make money. NAT-a-likes will be deployed for IPv6, of that there is no question. So yes, I'm saying that this development cost will have to be paid, no matter how much some people don't like it. > You claim that the cost will be paid regardless, he claims that it won't > be. Lorenzo's argument is that if we complain about NAT'ish options for IPv6 loud and long, not enough end-user networks will deploy them to make the development costs of traversal solutions worthwhile for applications in the special case of "needs to allow connections in from the outside world." My argument is that not only is that view hopelessly naive, it ignores the reality that most of those costs have already been paid, so the marginal cost of adding IPv6 support is minimal. > The technical manager of the company who opts for ULA + NPTv6 needs to > be aware if there are others doing it to be supported by applications > and content providers (whatever content that is, might even be p2p). > Or if the mass is not relevant, possibly opt for something else. > > Sort of like the same situation we had with IPv6. There had to be > relevance, with a similar chicken and egg problem, too. True enough, but oddly Lorenzo's counter-argument (without a hint of irony) was, "I already implemented an IPv6 traversal solution for my product, so I know how hard it is." He seems to ignore the fact that his counter-argument actually proves my point. :) Doug From phdgang@gmail.com Tue Mar 5 01:01:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB7821F8758 for ; Tue, 5 Mar 2013 01:01:53 -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 equOiQO7yWIX for ; Tue, 5 Mar 2013 01:01:52 -0800 (PST) Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by ietfa.amsl.com (Postfix) with ESMTP id BB76021F8713 for ; Tue, 5 Mar 2013 01:01:52 -0800 (PST) Received: by mail-qe0-f43.google.com with SMTP id 1so4429778qee.30 for ; Tue, 05 Mar 2013 01:01:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=lfqPWk3JIgz0F+dJvS26L5QuPDu3kPh/2TfY6SJCJL0=; b=SneOnoCn9XUuA9tYadyr0g1UHbuTrmIH0hGkX5XtIr4zUxYFufExIAHr6LFBuVtk/1 UBmRYZbkC99+QEkVJz+aZYDkCOJoJgOnsI/2bYi5L8LgqQkEfQj5yqcsKhsQki1Z3uui C/be22ZuqT6c8t2bFPcRbzr4KLzUPzCQZpmxUGSuuiizXbMFHpklMgmEZ7cfukgMAfct f2lkmMLScE9whuPUsM/sORJ5Rp54fyLdGoaqsTQoK9zdAe2eDZ5QgpdzlxC3PmhSNJ4U 6ByrUqu7cUjWzjV8I3x3wPNf8algJeDt2oRQLlN4QL2Hphxx7ZObcmKOeI8xbAuNC1VG KDig== MIME-Version: 1.0 X-Received: by 10.49.118.137 with SMTP id km9mr28954032qeb.34.1362474112273; Tue, 05 Mar 2013 01:01:52 -0800 (PST) Received: by 10.49.71.18 with HTTP; Tue, 5 Mar 2013 01:01:52 -0800 (PST) Date: Tue, 5 Mar 2013 17:01:52 +0800 Message-ID: From: GangChen To: v6ops Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] comments for draft-ietf-v6ops-nat64-experience [was draft-ietf-v6ops-nat64-experience WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 09:01:53 -0000 wg, There are offline comments from Randy Bush suggest to consolidate NAT64 statements with the principle of e2e preservation and "smart edge & stupid core". It was presented at http://archive.psg.com/120229.apops-v4-life-extension.pdf Personally, I think it's worth to add some texts of those principle as a part of NAT64 deployment considerations, since it would beneficial to advance IPv6 deployment. I would like to seek wg opinions on this point or futher comments regarding to http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience. Please take the time to review the document in order to make sure the draft doesn't lose anything at next update. Best Regards Gang From dougb@dougbarton.us Tue Mar 5 01:04:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE2921F86F7 for ; Tue, 5 Mar 2013 01:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCTNZRYJ78-u for ; Tue, 5 Mar 2013 01:04:39 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9350F21F857A for ; Tue, 5 Mar 2013 01:04:39 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:d8a5:7c11:1cda:1a82] (unknown [IPv6:2001:470:d:5e7:d8a5:7c11:1cda:1a82]) by dougbarton.us (Postfix) with ESMTPSA id 583E422B6D for ; Tue, 5 Mar 2013 09:04:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362474276; bh=YCEV6H1/W9oNjpMi7vKKM9lBv/2bc7N54Ykgckql6m8=; h=Date:From:To:Subject:References:In-Reply-To; b=i6sXVNAddjYGsqTJudtM62yqsDUtOLdNDE8Z/9A6YcFZltJ/fTsk4ffe+jNBPsLCA Rq8WELgYC5tWSxPs9T+MsZwZYU6JvDIB+ss/ht/AfJITr3p4aWq+VXhSDhZIV/o9I7 PDYFiMvyv5WCrJ+/rIU11W9gVzMMgPcuS9p9w9CQ= Message-ID: <5135B524.7070000@dougbarton.us> Date: Tue, 05 Mar 2013 01:04:36 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: IPv6 Ops WG References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> <92E6AF8C-F7A6-4291-9856-D972B371BF10@delong.com> <51353736.3000800@umn.edu> <51353974.60707@dougbarton.us> <5135B093.2030208@gmail.com> In-Reply-To: <5135B093.2030208@gmail.com> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 09:04:40 -0000 On 03/05/2013 12:45 AM, Brian E Carpenter wrote: > On a point of historical fact: > > On 05/03/2013 00:52, Owen DeLong wrote: > ... > >> The IETF did NOT sign off on PI for IPv6 before the RIR policies were already implemented and dispensing it. >> >> I don't know if the IETF ever officially signed off on it or not, but I do know that at least the first RIR policy was decided and implemented without any regard to IETF action on the subject. > > The IETF gave control over address assignment policy to IANA on March 1st, 2000 [RFC2860, clause 4.3]. Yes, and speaking as the person who was the IANA manager at the time the PI debate hit full volume, there was no set of asbestos long-johns thick enough for me to have put "Thou shalt have IPv6 PI" in writing. :) I was happy to have played a small role in brokering conversations that ultimately helped the right things to happen, and ultimately very happy that the right things _did_ happen, but IANA's official role in that space was and is largely secretarial. Doug From owen@delong.com Tue Mar 5 01:36:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2343C21F86C3 for ; Tue, 5 Mar 2013 01:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCSGYZ3MLA12 for ; Tue, 5 Mar 2013 01:36:05 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5E19A21F8691 for ; Tue, 5 Mar 2013 01:36:04 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r259X4Jn029682 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 Mar 2013 01:33:04 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r259X4Jn029682 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362475984; bh=jlL8O15dJiR90JugT3DjmQ/UU8Y=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nRr1wyuITNULSWig2wCc5bAv/kiZFFT+gzPyYT0xx55rwrjQtHtbs1ZH0AeiwJ61H i/PLo6912s851Argja64Cx7pAqldUEXZA/OYI2Beqd6Cpt+dyOPJGtvGGgtGyon4wE 3qzk7FvZ/xqL5HdFU/bualaRxg3Jk0n8KwaRfqRE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <51359B64.7090006@dougbarton.us> Date: Tue, 5 Mar 2013 01:32:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <756E31C5-90C7-4A4D-AA06-694C3D829758@delong.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 05 Mar 2013 01:33:04 -0800 (PST) Cc: v6ops@ietf.org Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 09:36:06 -0000 On Mar 4, 2013, at 23:14 , Doug Barton wrote: > On 03/04/2013 08:23 PM, Cameron Byrne wrote: >>=20 >> NAT / NPT6 breaks stuff and should not be used in any going-forward >> design. >=20 > Totally naive and unrealistic. >=20 >> For example, say i have a simple SIP or WebRTC connection. It will >> use SDP (or similar) to communicate to the remote peer the address >> and ports to send me media... if the application is unaware of it's >> address, it wont work (sans band-aids like ICE, STUN, TURN ...) I >> think my address is FD09::1, so send it here from across the >> internet... hmm.. does not work... Granted, the world has STUN and >> TURN and ICE, but somebody asked about cost. There you have it, go >> price out some of that. >=20 > So given that we already have those solutions, what are the marginal = costs or applying them to IPv6? >=20 > Your arguments seem predicated on the need to recreate these solutions = from scratch. But obviously we don't need to do that. My argument is = that the marginal costs are very small, so small that they are = effectively statistical noise. I haven't seen any arguments to refute = that, only the same "NAT means we have to solve these problems!" = argument which doesn't take reality into account. You keep ignoring this, but as I have stated, each of those has an = ONGOING cost in development even in IPv4. Each time you release a new = version you need to test for regressions and other things related to the = NAT traversal stuff. NAT traversal interacts with lots of things in very = "interesting" and only semi-predictable ways. Have you ever actually = developed an application that depended on NAT traversal technologies to = function? Have you ever tried to test it against all the different NAT = traversal implementations that are in the wild in order to have it work = from behind the plethora of home gateways that are out there? Have you = noticed that every time {Linksys,Belkin,Netgear,D-Link,etc.} launches a = new series of home gateways you get to test (and debug) all over again? > So please, refute my argument. Show me where I'm wrong. You're wrong in the following ways: 1. You assume this is a do it once fire and forget problem. It is = not. 2. You grossly underestimate just how much it costs EACH TIME. 3. You further underestimate just how much stuff is actually broken = by NAT in environments where that breakage is not intended. 4. You assume that because the enterprises with which you are = familiar want to use NAT in a particular way, everyone should want to have those exact same capabilities and that there is no = need to support a world without NAT. >=20 >> Take it from a major CGN operator, don't do NAT. >=20 > "Don't do that" is not a realistic argument in today's world. It's = been ignored for 15 years already, and will continue to be ignored. Only in IPv4. Guess what... Many things are different in IPv6. That's a = big part of what makes it better than IPv4. >> ps. Oh, yeah... add to the list of things that break to include >> RTSP, PPTP, IPsec AH, SIP, H323 (grasping at straws...), FTP, ... not >> a real who's who... but WebRTC might be a real zinger soon. >=20 > The default for FTP has been passive mode for over a decade, and very = few users even know that there used to be a different way of doing it. = As discussed above, those other protocols all have NAT-traversal = solutions, so as you asked in the bit that I snipped, "What problem are = we trying to solve here?" Actually, in most cases, those things do not have NAT-traversal = solutions. Instead, the NAT boxes have implemented ALGs or something = that functions much like an ALG to allow them to function in spite of = the fact that NAT-traversal doesn't work for them. This further = complicates the code in each of the NAT boxes and creates more = opportunities for bad interactions in software in the various home = gateways and more opportunities for serious security vulnerabilities to = go undetected in the additional complexity of the code involved. Owen From lorenzo@google.com Tue Mar 5 01:57:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7359821F8758 for ; Tue, 5 Mar 2013 01:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 8+EwlZoaOgCu for ; Tue, 5 Mar 2013 01:57:32 -0800 (PST) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id 54BDE21F8750 for ; Tue, 5 Mar 2013 01:57:32 -0800 (PST) Received: by mail-oa0-f51.google.com with SMTP id h2so10460570oag.24 for ; Tue, 05 Mar 2013 01:57:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=GIIySWqBZ2aWr/LclfaAAbZol5TMjBn6fyPIZ9L/hlI=; b=R1ZZsMoYywcS4qIY0nIo4LldyX80k2rcrrdLYN1kKP3bLjX+8cNQkGxSEOO8YsN+7q IQ0/Vdeqpx9XhagFCfwMXqKCtaQrDSLFPtAzILpaTuNoLKcwYQZCdAvGbrzZ6LWVAsP7 SO4teypRJ3dxN5MfI+WafvdtutMPKyTgZnY/DYaRn06Vfxwf+YGBvttBEAD6yztqmqWj 1Y2bd6rIi7RhAu+qDaicN0a0BMXDVIgKb5ye9RQZd6UaXpc/Vri9ws9d8K8ayUlsUb3c y50Y0w4gkOPEPMPdDyDJhAuRBizOC8lXoPykzk/Qu6ONQs7LhzPr/8/HYnHOCYrrvh/l eWSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=GIIySWqBZ2aWr/LclfaAAbZol5TMjBn6fyPIZ9L/hlI=; b=KeXpk8QlLSCVCMvubFP32vHoEFmsSSQd2SH+R2SyM0vFjaHR1PtIbkmngrC6/3do7j 1UVYMAfzpuWiMDPExtstWRhiusWo6VMfoK/6a8w5sOgrpd5llMkoM5kNu1QFgpr+lKOi /enO6a92PWgnAUnVHNSgawGKER+CvgAblaJusb21iNRHBfUCwdgaEcPme86HAzBOAKvs EYrQ9Poj/jA96MUigmwh8MvYAppwM+szohezl4Ioq2FrPTWmgrYUw8vglwL4EV1kfsrT 2MfhuzU4oVMzy6Iob7P69cQ6jA29TcxUrEKOhRCUtRhqHU+IH/NMafH+MriY3+iKc6Na 2djw== X-Received: by 10.60.172.18 with SMTP id ay18mr17951414oec.126.1362477451889; Tue, 05 Mar 2013 01:57:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Tue, 5 Mar 2013 01:57:11 -0800 (PST) In-Reply-To: <5135B34F.8030809@dougbarton.us> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> From: Lorenzo Colitti Date: Tue, 5 Mar 2013 18:57:11 +0900 Message-ID: To: Doug Barton Content-Type: multipart/alternative; boundary=bcaec54fae4888f58404d72a8094 X-Gm-Message-State: ALoCoQmUTu9jwOYOlFMq//StN8ucICfW0vBJWTBFGQQW5l88i5AqZfsENo3ZD1xW2Y3ZYD9iAobDigjpscOTVlcYAeMWR3A0VccVG9HGczlKznFMP32CGymdUc/nfL0ApvXp+wclH/tCxW+ZY3/w3lGX447tyCH/4IND3tbya6sVA083I/SCiPUQ7s+lnpMO1847mzArouc6 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 09:57:37 -0000 --bcaec54fae4888f58404d72a8094 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 5, 2013 at 5:56 PM, Doug Barton wrote: > The vast majority of current deployments aren't using IPv6, period. Of the > tiny percentage that are, some percentage of them are using a NAT-a-like > strategy. > Saying "some percentage" provides no information that can be used to make a decision. After all, some percentage of people survive jumping out of airplanes without parachutes, and some percentage of those survive without injuries. Where are these NAT-a-like deployments, and how many users do they have? How do those numbers compare with the number of users that have global IPv6 addresses (which is order of 10M)? > Many won't deploy IPv6 at all unless they have similar capabilities to > what they are already using in IPv4 NAT. > Is this statement based on actual experience? And what is the number compared to those who have deployed IPv6 with global addresses? I know several enterprise deployments that use global IPv6 addresses but NAT for IPv4, so it's not like they don't exist. > NAT-a-likes will be deployed for IPv6, of that there is no question. > But why is there no question? It's obvious that you are convinced of this outcome, but you will likely be more convincing to others if you make a more detailed argument. True enough, but oddly Lorenzo's counter-argument (without a hint of irony) > was, "I already implemented an IPv6 traversal solution for my product, so I > know how hard it is." He seems to ignore the fact that his counter-argument > actually proves my point. :) > We did not implement traversal. We spent a long time bringing IPv6 support to a library that was made very complicated by the need to implement robust NAT traversal. As I said before, the library still does not do traversal for IPv6. Implementing that would have made it an even larger effort, and we had no evidence that any substantial percentage of the userbase has NATed IPv6 connectivity. --bcaec54fae4888f58404d72a8094 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 5, 2013 at 5:56 PM, Doug Barton <dougb@doug= barton.us> wrote:
The = vast majority of current deployments aren't using IPv6, period. Of the = tiny percentage that are, some percentage of them are using a NAT-a-like st= rategy.

Saying "some percentage" p= rovides no information that can be used to make a decision. After all, some= percentage of people survive jumping out of airplanes without parachutes, = and some percentage of those survive without injuries.

Where are these NAT-a-like deployments, and= how many users do they have? How do those numbers compare with the number = of users that have global IPv6 addresses (which is order of 10M)?=A0
=A0
Many won't deploy IPv6 at all unless they have similar capab= ilities to what they are already using in IPv4 NAT.

Is this statement based on actual ex= perience? And what is the number compared to those who have deployed IPv6 w= ith global addresses? I know several enterprise deployments that use global= IPv6 addresses but NAT for IPv4, so it's not like they don't exist= .
=A0
NAT-a-likes will be deployed for IPv6, of that there is no questi= on.

But why is there no question? It'= ;s obvious that you are convinced of this outcome, but you will likely be m= ore convincing to others if you make a more detailed argument.

True enough, but oddly Lorenzo's counter-argument (without a hint= of irony) was, "I already implemented an IPv6 traversal solution for = my product, so I know how hard it is." He seems to ignore the fact tha= t his counter-argument actually proves my point. :)

We did not implement traversal= . We spent a long time bringing IPv6 support to a library that was made ver= y complicated by the need to implement robust NAT traversal. As I said befo= re, the library still does not do traversal for IPv6. Implementing that wou= ld have made it an even larger effort, and we had no evidence that any subs= tantial percentage of the userbase has NATed IPv6 connectivity.
--bcaec54fae4888f58404d72a8094-- From v6ops@globis.net Tue Mar 5 01:58:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D737C21F886D for ; Tue, 5 Mar 2013 01:58:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ej30wTqA3ovx for ; Tue, 5 Mar 2013 01:58:48 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 05A7921F8758 for ; Tue, 5 Mar 2013 01:58:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 2A64D870066; Tue, 5 Mar 2013 10:58:32 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoheWDo3SmlO; Tue, 5 Mar 2013 10:58:03 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 6BA03870064; Tue, 5 Mar 2013 10:58:03 +0100 (CET) Message-ID: <5135C1A5.5010403@globis.net> Date: Tue, 05 Mar 2013 10:57:57 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Doug Barton References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <3B96D0EE-B19F-4770-85D0-F7C2136F0BEA@delong.com> <513299CE.20509@dougbarton.us> <1364B842-D3BE-48C1-A2A5-3D74DC37DB4A@delong.com> <513457E6.6060201@dougbarton.us> <5135A53E.5050105@globis.net> <5135AA92.10106@dougbarton.us> In-Reply-To: <5135AA92.10106@dougbarton.us> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 09:58:49 -0000 Doug Barton wrote: > On 03/04/2013 11:56 PM, Ray Hunter wrote: >> >> Owen DeLong wrote: >>> >>> There's lots of desktop collaboration that occurs outside of the >>> enterprise world. Further, with the ever increasing level of BYOD, >>> multiple connectivities, etc. I think that our authentication and >>> authorization models for network traffic are going to change >>> significantly in the future, especially when you consider things >>> that are possible with MIP6. I think you'll see more end-to-end >>> ESP/AH used rather than straight firewalls and that you will see >>> direct untranslated traversal through the firewall of packets which >>> are part of valid existing security associations or which are >>> intended to set up such security associations. > > >> BYOD is a game changer. > > Agreed. We're seeing this as a key driving force in the DNS/DHCP/IPAM > space as well. > > [snipping some of your other excellent points] > >> So I think that even if you are thinking of using NPT, you would still >> be wise to deploy GUA PI space in a large enterprise (and no ULA at >> all), just in case the border ever does need to become more transparent. >> PI space is readily available and cheap in enterprise terms. ULA is not >> a pre-req for NPT. That's RFC1918 thinking. > > Just to be clear, I'm not saying that ULA is a pre-req for NPT, and > for large enterprises GUA + NPT may very well be a valid solution. My > point is that there is nothing about ULA, NPT, or the combination > thereof that is inherently evil. :) > > Doug > > I have a slightly different take. There is stuff now traversing the enterprise border in both directions that we never ever expected to when the original protocols and code were developed. Have you tried deploying an enterprise phone system hosted on the public Internet as a cloud service? The point I make is that we don't have proper solutions today in IPv4/RFC1918/NAPT/Split DNS for many of the challenges I listed, never mind IPv6/NPT. Any engineering effort required for translation traversal in these services will be completely new, not just a delta. A deployment that relies 100% on ULA and/or NPT will likely limit your IT architecture (unnecessarily). I would therefore highly recommend enterprises keeping their options open (via GUA PI), so that they can have at least one fully-transparent highly-available two-way gateway to/from the enterprise. IPv6 could then become a business enabler, rather than an additional cost with no-benefit. regards, RayH From jouni.nospam@gmail.com Tue Mar 5 02:14:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E7721F86F4 for ; Tue, 5 Mar 2013 02:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.976, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 H4kEVvoBREn3 for ; Tue, 5 Mar 2013 02:14:35 -0800 (PST) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id 04AB921F86EA for ; Tue, 5 Mar 2013 02:14:34 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id ge1so4707379lbb.1 for ; Tue, 05 Mar 2013 02:14:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=J8xj7KjId2a6PX6hPz4WRS+V0RFblmObbNpfIL/cM2o=; b=c3fmJKVnfeXl79cOu17IcOb9vtXk9QCLrN7CvIKIuioyrIb4gwt9mRCpzhbyN2GzML PNuRAGVb5QsP6fc0NgJSRw2y/EW7BWwMYeiGqruEHJ6AOw3RhSsT7BtLsXluBxI9FMTM ewKsLOzt/+3VkhIoADJq/jja/Iff7W3m3oKAczmaI7gMFJJtOdks0tvf1q+Q13feUW2X MnsCVLyUFqjS8+9mSUJfgc3mJCl8sPYejc7qIz4vDhsQAQjgsT/lySqm/MIpFZ5PotDc Gqbm1b9jz57yH3rnkrvahJIoHlowtvuDd1VJTn2SjFKaIXORCX91rWDK4AoOhhKs3mC3 ayFg== X-Received: by 10.152.147.130 with SMTP id tk2mr21009552lab.24.1362478473956; Tue, 05 Mar 2013 02:14:33 -0800 (PST) Received: from [192.168.250.74] ([194.100.71.98]) by mx.google.com with ESMTPS id fz10sm8362727lbb.12.2013.03.05.02.14.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Mar 2013 02:14:32 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jouni Korhonen In-Reply-To: Date: Tue, 5 Mar 2013 12:14:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130225140510.30575.52772.idtracker@ietfa.amsl.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc3316bis-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 10:14:35 -0000 Hi Mikael, I am slightly reluctant to add such text here in this document. However, adding a specific pointer to RFC6459 on this topic with some = introductory text could be OK think to do. - Jouni On Feb 25, 2013, at 4:24 PM, Mikael Abrahamsson = wrote: > On Mon, 25 Feb 2013, internet-drafts@ietf.org wrote: >=20 >> Requirements document. It also discusses some issues relating to = the >> use of these components when operating in these networks. This >> document obsoletes RFC 3316. >=20 > Would it make sense to discuss the bearer concept regarding IPv4, IPv6 = and IPv4v6 in this document? >=20 > Personally I'd like to see all new devices actually support IPv4, IPv6 = (two PDP contexts if one wants dual stack) and IPv4v6 (single dual stack = PDP context). >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From owen@delong.com Tue Mar 5 02:26:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4160721F8917 for ; Tue, 5 Mar 2013 02:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3O1kZW9HBavf for ; Tue, 5 Mar 2013 02:26:29 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 6707621F8824 for ; Tue, 5 Mar 2013 02:26:28 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r25AODfN030385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 Mar 2013 02:24:14 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r25AODfN030385 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362479054; bh=jyG9MTLJPQhLJQzZPfdqhU9ixq0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Q6Rod3fl3gTqhPKJf+eQ5ONCBDwjiNEA8TREe0rJed5+v0Ib37BmFShVpUJCj2NQM 7wOQBiTfpP1vMKa0RfR9936fgpFl242Y3K/dKsPEcn4Vd3bCdj63i7cK0r+6j+WnaU /S/GByNlu4ZO4KTyWiR8cotTZCfalK+7qoan9cWg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <5135B34F.8030809@dougbarton.us> Date: Tue, 5 Mar 2013 02:24:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 05 Mar 2013 02:24:14 -0800 (PST) Cc: v6ops@ietf.org Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 10:26:30 -0000 On Mar 5, 2013, at 00:56 , Doug Barton wrote: > On 03/05/2013 12:36 AM, Philipp Kern wrote: >> On Tue, Mar 05, 2013 at 12:25:06AM -0800, Doug Barton wrote: >>> Either you don't understand what I've written several times now, or >>> you are intentionally twisting my words to make my argument seem >>> unreasonable. Regardless of which one of those is true, I have run >>> out of new and different ways to repeat the same points, and I'm >>> sure the other members of the list are tired of me trying. :) >>=20 >> It seems to me that Lorenzo's point is that the vast majority of = *current* >> deployments are not using ULA + NPTv6. >=20 > The vast majority of current deployments aren't using IPv6, period. Of = the tiny percentage that are, some percentage of them are using a = NAT-a-like strategy. Many won't deploy IPv6 at all unless they have = similar capabilities to what they are already using in IPv4 NAT. >=20 Sigh... The vast majority of current IPv6 deployments aren't using NPT, = NAT66, or any other form of IPv6 address translation. So, of the (~10%) of implementations that have some form of IPv6 = deployment, maybe 0.00001% of them are using some NAT-a-like strategy. If I'm the software product manager looking at that market, guess which = feature hits the very bottom of the "we'll probably never get to that" = list of feature requests? > Of the possible NAT-a-likes for IPv6, 6296 is by far the least = painful. Yes... I think everyone agrees that in a world of blind people, the = one-eyed man is king. However, most of us respond to the question "Shall I poke one of your = eyes out or both?" with a resounding "NONE... What the heck??!" >> You say it's already used, but a >> lot of features are used somewhere, even if not widely. Hence Lorenzo >> claims that the development cost is not paid for supporting that = fringe >> use case, because the installed base is too tiny. After all in = commercial >> deployments you care not about supporting each and every use case but >> the ones that are relevant and make money. >=20 > NAT-a-likes will be deployed for IPv6, of that there is no question. = So yes, I'm saying that this development cost will have to be paid, no = matter how much some people don't like it. Yes. But will they get deployed widely enough for anyone other than = yourself and the managers foolish enough to make that choice without = considering the possible consequences to care? If not, then guess what... The development costs don't get paid and the = people who depended on NPTv6 in their networks are kind of SOL. (Unless, = of course, they find some way to fund all that development effort among = themselves.) With any luck, NPTv6 will be the internet equivalent of the "Bone Fone". = Something everyone has heard of, but few have actually even experienced = and they aren't actually made or supported any more. I know you insist = this won't be the case, but there are lots of us that still hold out = hope for a brighter future than you envision. >=20 >> You claim that the cost will be paid regardless, he claims that it = won't >> be. >=20 > Lorenzo's argument is that if we complain about NAT'ish options for = IPv6 loud and long, not enough end-user networks will deploy them to = make the development costs of traversal solutions worthwhile for = applications in the special case of "needs to allow connections in from = the outside world." My argument is that not only is that view hopelessly = naive, it ignores the reality that most of those costs have already been = paid, so the marginal cost of adding IPv6 support is minimal. No, Lorenzo's (and my) argument is that NAT technologies in IPv6 aren't = getting wide deployment today (even as a percentage of IPv6 deployments) = and that there's no reason to expect that trend will change. Further, if = that trend doesn't change, then it's unlikely that there will be enough = of an installed base to drive development. You keep referring to = "applications that need to allow connections in from the outside world" = as a "special case". However, I would argue that Apache, Sendmail, BIND, = and a host of other applications that are in widespread use today are = really not special cases. I would argue that the current = provider/subscriber model of the internet is, in fact, an artifact or = peculiarity that is largely due to the widespread deployment of NAT and = that a return to a more peer-to-peer style of machine-to-machine = communication is, in fact, very likely in the future. Networks are for connecting people at the end of the day. All of this = machine to machine communication is at its roots in the service of = serving human communication. Humans don't operate with firewalls and = outbound-only communications filters and we don't filter all of our = communications with each other through a third-party rendezvous human. I = don't know why you cling so dearly to that model or why you can't accept = that it will eventually become an anachronism, an artifact of a = temporary period in history fostered by a need for address conservation. >> The technical manager of the company who opts for ULA + NPTv6 needs = to >> be aware if there are others doing it to be supported by applications >> and content providers (whatever content that is, might even be p2p). >> Or if the mass is not relevant, possibly opt for something else. >>=20 >> Sort of like the same situation we had with IPv6. There had to be >> relevance, with a similar chicken and egg problem, too. >=20 > True enough, but oddly Lorenzo's counter-argument (without a hint of = irony) was, "I already implemented an IPv6 traversal solution for my = product, so I know how hard it is." He seems to ignore the fact that his = counter-argument actually proves my point. :) You really should try reading what he wrote before you put words in his = mouth. He said that "porting the library to IPv6 at all was hard enough, = without including NAT traversal for IPv6." He specifically stated that = they DID NOT do the work to include traversal in the library, so I think = his counter-argument works quite well. The fact that you assume they must have done so in spite of his blatant = statement to the contrary, OTOH, proves our point. Owen From owen@delong.com Tue Mar 5 02:51:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE27821F8996 for ; Tue, 5 Mar 2013 02:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1NvCrWBkHag for ; Tue, 5 Mar 2013 02:51:23 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAB621F8995 for ; Tue, 5 Mar 2013 02:51:23 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r25AnjUu030823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 Mar 2013 02:49:45 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r25AnjUu030823 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362480585; bh=j978742OBZUW8r8u7PvgP1VkEbo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=23Zcyi0u8IoeseMr1Oy8oFa7CJj12/3xKTCloL4pApZeAQJ0N5WM7pVmJlRItGjyZ 2bqLCYy0OTHLcElF7yze1kQ2M51Xy1xI3/PaqQQlZWAixLhp7O/e+QG9fylCjGIYI4 4BHdehmDKPdzmt/BodAjL/a2OOybO7X6hOR/olWQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <5135A98E.3000705@dougbarton.us> Date: Tue, 5 Mar 2013 02:49:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <24A1C2A2-B117-46E7-8BE6-EF3E63A95359@delong.com> References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> <92E6AF8C-F7A6-4291-9856-D972B371BF10@delong.com> <51353736.3000800@umn.edu> <51353974.60707@dougbarton.us> <51354262.9000604@umn.edu> <5135A98E.3000705@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 05 Mar 2013 02:49:45 -0800 (PST) Cc: IPv6 Ops WG Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 10:51:28 -0000 On Mar 5, 2013, at 00:15 , Doug Barton wrote: > On 03/04/2013 04:54 PM, David Farmer wrote: >> On 3/4/13 18:16 , Doug Barton wrote: >>> On 03/04/2013 04:07 PM, David Farmer wrote: >>>> I don't believe the content networks were particularly advocates of = PI, >>>> at least not any more than a number of other groups. That said, I >>>> believe content networks generally supported PI, but so did many >>>> others. So, primarily crediting content networks for PI is an over >>>> statement of their role. >>>=20 >>> Fair enough. My point remains however. As-designed IPv6 was PA only. = It >>> took an enormous hue and cry to get that changed. And yes, the = policy >>> change happened at the RIRs, >>=20 >> Agreed. >>=20 >>> but not till AFTER the IETF signed off, >>=20 >> I don't recall any RFC or other consensus from the IETF that called = for >> PI, there may have been a consensus that GUA-PI was a better idea = than >> ULA-C, that is the closest to a consensus for PI I can think of. >=20 > That was part of it. The other part was the conversation (repeated at = all the different RIR meetings I attended) that went something like = this: >=20 > people: We need PI space for IPv6 > RIR: We have no guidance from the IETF on allocations to individuals, = only to ISPs. > IETF: Yeah, and that's how it's going to stay. >=20 Right... And it did, indeed, stay that way. So, the RIR(s), or, more = accurately, some individuals in the RIR communities, took it upon = themselves to craft guidance from the RIR policy development processes = to cover that lack. > At the time (2003-2005 time frame) there was still a very vocal = contingent that was saying that mip6 was going to be the answer to the = traditional multihoming problem, and didn't want any attention diverted = from that goal. Also see below on other road blocks. Actually, IIRC, there was more of a push for SHA^hIM6 at the time. There = were also a contingent pushing for a (much earlier and far less = fathomable) version of LISP. According to actual historical records: https://www.arin.net/policy/proposals/2005_1.html The first RIR policy allowing for PI IPv6 was adopted by the ARIN board = on 27 July, 2006 and implemented on 30 August, 2006. The final version of this policy was a merger between three competing = policies that had been written by myself, Andrew Dul, and Kevin Loch. = The three policies were very similar and mine was the first one into the = hopper in February, 2005. > Eventually the pressure to permit PI space became overwhelming, cooler = heads prevailed, and the right conversations were had with the right = people to make it all happen. FWIW I never got the sense that the RIRs = were against it necessarily, they just didn't want to cheese off the = militant no-PI folks in the IETF. I don't remember being exactly what one would refer to as a "cooler = head" in 2005, and I think your characterization of what happened is = still glaringly inaccurate. 1. The pressure to permit PI space came from a grass roots movement = in the ARIN community, as does the pressure for ANY ARIN policy, ever. 2. I remember the discussions actually being quite passionate. Most = of the "cooler heads" were on the no-PI side from what I remember. 3. It wasn't a matter of right conversations with right people, it = was a matter of a set of policies working their way through the ARIN = policy process until they converged as a single policy acceptable to all 3 = authors and able to achieve broad support of the community. 4. There is no policy opinion from "the RIRs". They are neutral on = policy matters and ARIN staff is expressly prohibited from expressing = opinions on policy. The RIR had no policy to support PI in IPv6 and no = advice from IETF to do so without policy. There was also nothing from = IETF to prevent the RIRs from developing policy absent guidance in either = direction from IETF. There were certainly those in the RIR crowd that = were opposed to the idea. Frankly, when I proposed the policy, I never = expected it to gain consensus. I did it in order to force the mega-corp = ISPs to go on the record beating up the little guys (which they basically did). = However, in the RIR world, a bunch of Davids really do trump a few = Golliaths and the policy achieved consensus. It wasn't a back room deal or a series of secret conversations. It was = all done through a transparent public process open to anyone who chose = to participate. >=20 >> I'd >> love to be wrong on that as I still have people grumble at me about = the >> ARIN policy I authored. Being able to provide a quote that there was = a >> IETF consensus for PI would still be helpful to me personally if = there >> is one to point to. >=20 > There was not a specific document that said, "Ok, PI space is fine, go = for it." In fact given the climate at the time that wasn't even = possible. "Grudging acknowledgement" was the only possible outcome, and = yes, people like you took heat for not only acknowledging reality, but = acting in the best interests of long-term IPv6 deployment. Thank you. :) An interesting characterization of "deafening silence". Yes, lots of = individuals that were active participants in various IPv6 working groups = were quite vocal on both sides of the subject, but the IETF as a body = NEVER really said anything one way or the other. >>> which did not occur till AFTER various large network operators made = it >>> clear that they would never deploy v6 till PI space was available. >>=20 >> Many of the largest network operators supported the PA-only model and >> mostly did not support PI. Some relented as it became obvious that = the >> lack of IPv6 PI was a huge drag on IPv6 adoption, especially as IPv4 >> run-out actually started to loom big on the horizon. >=20 > Sorry I wasn't clear. When I say network operators I do not mean ISPs. = Obviously they were all in favor of the "PA-only" model, since it = amounted to a near lock-in for the customers that purchased IPv6 from = them. In fact, when talking to the CTOs of a lot of the large = enterprises, not getting locked in to a given ISP was their chief = concern. Renumbering was a close second, but they did not want to give = up the bargaining advantage that IPv4 PI gave them. Actually, neither of your statements is accurate. 1. Many ISPs supported the PI proposal. (This surprised me at the = time as much as it will apparently surprise you now). 2. When crafting the original IPv6 PI policy we made a lot of = efforts to make sure that it made PI accessible to as many organizations = as possible and was not exclusively a tool for very large enterprises. 3. Most of the overwhelming pressure for PI IPv6 actually came from = small and medium sized organizations, not the large enterprises, Not = that they were silent or didn't support it, just that they were few in = number compared to the others. In the ARIN policy process, a person = from $MEGACORP has the same weight as a person from $CORNER_STORE and 2 = people from $MEGACORP have less weight than a person from $CORNER_STORE = and a person from $GAS_STATION. > A less charitable person than myself would argue that it was the big = ISPs that were one of the key driving forces of the PA-only model, but I = digress. :) I think that the "phear the size of the bgp table" contingent (sort of = the IPv4 equivalent of the congressional deficit hawks) were actually = the largest voice driving the PA-only model. Yes, many of them = represented large ISPs (especially the ones that are now collectively = known as something starting with V), but that wasn't so much to push for = customer lock-in (which was more of a beneficial side-effect coveted by = sales and marketing), but because the engineers really were in fear of = their routers being unable to process and/or store a complete table. I = talked to a lot of the engineers at the time. I actually held the same = assumption and didn't completely believe them at the time. However, = looking back, I realize that engineers really don't care about things = like customer lock-in and they really do care about things like failing = routers. So... The axiom "Never attribute to malice what can be adequately = explained otherwise." would seem to apply in this case. Owen From gert@space.net Tue Mar 5 02:53:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4968221F8A11 for ; Tue, 5 Mar 2013 02:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYks1YsCw7-g for ; Tue, 5 Mar 2013 02:53:12 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD5721F8A09 for ; Tue, 5 Mar 2013 02:53:12 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 8BE5760750 for ; Tue, 5 Mar 2013 11:53:11 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 6DF576074C for ; Tue, 5 Mar 2013 11:53:11 +0100 (CET) Received: (qmail 66329 invoked by uid 1007); 5 Mar 2013 11:53:11 +0100 Date: Tue, 5 Mar 2013 11:53:11 +0100 From: Gert Doering To: Doug Barton Message-ID: <20130305105311.GB51699@Space.Net> References: <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> <92E6AF8C-F7A6-4291-9856-D972B371BF10@delong.com> <51353736.3000800@umn.edu> <51353974.60707@dougbarton.us> <51354262.9000604@umn.edu> <5135A98E.3000705@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5135A98E.3000705@dougbarton.us> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Ops WG Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 10:53:13 -0000 Hi, On Tue, Mar 05, 2013 at 12:15:10AM -0800, Doug Barton wrote: > Eventually the pressure to permit PI space became overwhelming, cooler > heads prevailed, and the right conversations were had with the right > people to make it all happen. FWIW I never got the sense that the RIRs > were against it necessarily, they just didn't want to cheese off the > militant no-PI folks in the IETF. "The RIRs" had no business to have *any* opinion on this. They are secretaries to provide addresses to their communities if those decide that they want them sliced in a certain way. The RIRs' *communities* - who make the policies - have indeed had long discussions between the "no PI, only over our dead bodies!" and "without PI, no IPv6 will happen, ever!" camps... Gert Doering -- still carrying scars from the IPv6 PI debate in RIPE land -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From stefan.marksteiner@joanneum.at Tue Mar 5 06:40:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42BE21F86F4 for ; Tue, 5 Mar 2013 06:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.23 X-Spam-Level: X-Spam-Status: No, score=-0.23 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_13=0.6, J_CHICKENPOX_35=0.6] 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 uC6Fgk4mHtJD for ; Tue, 5 Mar 2013 06:40:41 -0800 (PST) Received: from rzjgate1.joanneum.ac.at (rzjgate1.joanneum.ac.at [143.224.185.3]) by ietfa.amsl.com (Postfix) with ESMTP id 9530B21F86EC for ; Tue, 5 Mar 2013 06:40:41 -0800 (PST) Received: from RZJS078.jr1.local (rzjs078.joanneum.ac.at [143.224.71.19]) by rzjgate1.joanneum.ac.at (8.14.4/8.14.4) with ESMTP id r25EeUdh027286; Tue, 5 Mar 2013 15:40:31 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joanneum.at; s=sel3; t=1362494431; bh=AreJusnrwJNivNKdIFc85vfp3RvduAtrA+S58T5sdDQ=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=kutaBKnzHWbaGS+/L7Sq++oQYIRBFpxm2uKtB1V9pAEBwECCpxzjsvaBD+vbArGIj 6QlJc8NhFVszEx5avVtG/fwlHC3qYZixB8noFA/y+KC1lTlPU6AhomWkJPeYcyIS4U iH7onR/nzvtw8Kw8SdcHkdtnORQQ9xyR96qZ/Tng= Received: from RZJC1EX.jr1.local ([169.254.2.69]) by RZJS078.jr1.local ([143.224.71.19]) with mapi; Tue, 5 Mar 2013 15:40:30 +0100 From: "Marksteiner, Stefan" To: "'Owen DeLong'" Date: Tue, 5 Mar 2013 15:40:29 +0100 Thread-Topic: [v6ops] ULA Usage Guide draft requesting for review Thread-Index: Ac4W8NEa8vexhwApRLOVemqaKcZCUACiZq+Q Message-ID: <8A317FD8C00FEE448E52D4EE5B56BB3E02513FBE2324@RZJC1EX.jr1.local> References: <8A317FD8C00FEE448E52D4EE5B56BB3E02513FBE2301@RZJC1EX.jr1.local> <3AC1A1D6-6ED1-4A3E-BE7A-AE5306A3E6CC@delong.com> In-Reply-To: <3AC1A1D6-6ED1-4A3E-BE7A-AE5306A3E6CC@delong.com> Accept-Language: de-DE, de-AT Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, de-AT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'v6ops@ietf.org'" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 14:40:42 -0000 Hi, >On Mar 1, 2013, at 01:35 , "Marksteiner, Stefan" wrote: > >> Hi, >>=20 >> Section 2.2.2.1 follows the principle "internal addresses for internal c= ommunication". As they are (per default) not advertised, they may prevent t= hat internal services become publically available by misconfigurations. Add= itionally, by their distinctive prefix, they are easier to recognize (for o= perator eyes) and thus may be easier to troubleshoot in firewalling rules a= nd network sniffers (if, for instance, a service is mistakenly opened to t= he outside). >=20 > >I'm not sure what you mean by "As they are (per default) not advertised...= " > >There is no special treatment of ULA in routers. No prefix is advertised i= n BGP by default. ULA or GUA. >In other protocols, ULA is advertised with the same defaults as GUA. > >If I have a local convention that says 2001:123::/32 is my publicly reacha= ble space and 2620:4:104::/48 shouldn't be advertised, it's every bit as re= cognizable as ULA to the operators that work for me. > What I've meant was just that your provider will propagate your GUA ranges = (or, more precisely, the shorter prefixes that contain these ranges). This = is not (or should not be) the case for ULA address ranges, so they won't be= reachable from the Internet even if you screw up your security configurati= on (ULAs of course replace, to which I totally agree, by no means any secur= ity mechanism - I just think of it as an additional "insurance against mis= haps"). As for the recognition, you're probably right. The only one for whom ULAs a= re maybe easier to recognize will be a new guy in an operator team. Besides of whether ULAs are useful for this purpose or not, do you think th= ere are any negative impacts of using ULAs for addressing internal machines= (strictly internal - who are never ever to be reached from the outside, t= hat is). >> Sincerely, >>=20 >> Stefan >>=20 >> P.S.: Even there is a wide consensus that ULAs (or RFC1918-addresses in = v4), I personally would broaden the suggestion in 2.2.2.1 to internal infra= structure devices and services for the reasons stated above. If the interna= l services don't have to be routed (or reside in an extra vlan), I'd don't= number them with GUAs at all and just use their LLAs, which spares a littl= e bit of numbering efforts. >=20 > >Your DNS must be fun and you've rendered them unreachable to other interna= l hosts that are not on the same subnet. I thought about SMB companies, which are too small for sensible net segment= ation, so they can use LLAs the exact same way as ULAs (except for the fact= that they are mandatory according to RFC4291 and its predecessors) or resi= de in an extra VLAN, in which case they will be orphaned on purpose - I thi= nk of a completely isolated management VLAN for infrastructure devices such= as switches, etc. As for the DNS, we have an external and an internal zon= e, whereas the latter of which is the natural home of the (of course non-au= toconfig) LLA-IIDs. > >Owen > Cheers, Stefan >>=20 >>=20 >> -----Urspr=FCngliche Nachricht----- >> Von: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] Im Auftrag=20 >> von Owen DeLong >> Gesendet: Freitag, 01. M=E4rz 2013 10:03 >> An: Liubing (Leo) >> Cc: v6ops@ietf.org >> Betreff: Re: [v6ops] ULA Usage Guide draft requesting for review >>=20 >>>=20 >>>> Section 2.2.2.1 >>>>=20 >>>> IMHO, this section should be deleted in its entirety or at least=20 >>>> come with a strong cautionary note that such designs are=20 >>>> ill-conceived and detrimental in nature. Pretending that NAT or NPT im= prove security at all is dubious at best. >>>> In fact, NPT and especially NAT provide more tall weeds for=20 >>>> attackers to hide in, if anything. >>>=20 >>> [Bing] Such designs come from special requirements such as the abovemen= tioned information security sensitive enterprises or governments. If you wa= nt the endpoints disconnected as default and only connected via central con= trol, it is quite reasonable to pick ULA+Proxy.=20 >>> However, normally we won't recommend to use ULA in this model. But I th= ink it might not be proper to justify such scenarios as ill. My point is: i= f you really have special requirements, just use it in this model; but plea= se don't misunderstanding ULA was just designed for this kind of use. >>>=20 >>=20 >> Then clarify that this is only intended to address ULA on default-discon= nected + Proxy networks and _NOT_ NAT or NPT which should never be used wit= h ULA. >>=20 >>>> AL Proxies can be implemented equally effectively using GUA and=20 >>>> there is no significant advantage to ULA in such a case. >>>=20 >>> [Bing] If require endpoints default disconnected, egress filtering woul= d be easier and more stable for ULA than GUA. And can save some operation t= o apply PA/PI. >>>=20 >>=20 >>=20 >> I disagree. I can filter 2001:db8::/32 just as easily as I can filter fc= 00::7. >>=20 >> Either way, it's just an entry in a prefix list. >>=20 >> By definition, ULA isn't in any default prefix lists or hard coded into = being blocked by routers, so there are no special global default semantics = to it that distinguish it from GUA. Only human convention. >>=20 >>>>=20 >>>> Section 3.1 >>>>=20 >>>> The last sentence should be deleted. GUA is an equally viable option=20 >>>> for these networks. >>>>=20 >>>> Section 3.3.2 >>>>=20 >>>> I'm unable to decipher Paragraph 2, so I cannot make a suggestion on=20 >>>> rewording it. However, since I can't tell what you're trying to say,=20 >>>> I'm pretty sure it needs to be rewritten. >>>=20 >>> [Bing] It is only a corner case, that is, if the NAT64 prefix is shorte= r than 48/, it would divide the 40bit of ULA into two parts. But in most of= the practices NAT64 just use 96/. I'll rewritten it for ease of reading.=20 >>>=20 >>=20 >> That's probably best addressed in a document that says "If you're going = to do NAT-64, then don't use a prefix shorter than /48". Certainly there's = no need to do so. >>=20 >> Thanks, >>=20 >> Owen >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Tue Mar 5 07:18:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D4121F8A18 for ; Tue, 5 Mar 2013 07:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.01 X-Spam-Level: X-Spam-Status: No, score=-102.01 tagged_above=-999 required=5 tests=[AWL=-0.530, BAYES_00=-2.599, HELO_EQ_IP_ADDR=1.119, 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 GN+lW2q7g4cC for ; Tue, 5 Mar 2013 07:18:23 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id EB0D421F8A14 for ; Tue, 5 Mar 2013 07:18:22 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id d7so6376949wer.22 for ; Tue, 05 Mar 2013 07:18:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=spEarlacijIFBni5osAKx4QHhq5V/tiDw7+rr9hW6TI=; b=KzDBNG2s6QNS/f+Bg2Hh4KeEyQD9QP6JVfczMTCGgRfWgnUv/q4tsKqFrJmWkBlTFX paPQGh6Wr1owGKnXb+mrL2wz6vl55AqVpO6jhpC7Qh6+LDrQurOU2W4neYWe2RBUyfMk 2x7hqth7t4vyE4XK+B9LAGmstjAXu88sjw6S8hehWchq4Hw+5CnJzVSE38KkC/KkaqR6 shYKQQwVt6+nww7cbiiymVY27Ja1MbpD8tK9rSPoBHfOL9ZPVRm7MAKqbKz+9R5/bIUU Ni+z5hFJtj8sEiGXsqlg4No+cN3smypyBZSPpqlw6jhXaqzKQdBtMDkZgE5I0kyqsdIQ 8bCA== X-Received: by 10.194.92.65 with SMTP id ck1mr22480093wjb.54.1362496697198; Tue, 05 Mar 2013 07:18:17 -0800 (PST) Received: from [128.232.110.174] (c174.al.cl.cam.ac.uk. [128.232.110.174]) by mx.google.com with ESMTPS id eo1sm20963897wib.8.2013.03.05.07.18.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Mar 2013 07:18:15 -0800 (PST) Message-ID: <51360CBC.2070204@gmail.com> Date: Tue, 05 Mar 2013 15:18:20 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [v6ops] draft-jiang-v6ops-semantic-prefix-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 15:18:23 -0000 Hi, One thing I don't understand, and one comment. Consider the first example: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IANA assigned block | locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | locator (Cont.) | Semantic Field|Subscriber bits| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An ISP semantic prefix example What happens if a subscriber happens to operate two servers (which should be quite common in IPv6, where "subscriber" does not mean "client")? One server is, say, a video server so that the user can look at a security camera remotely (i.e. a high-speed loss-tolerant QoS is required). The other server is a building services proxy, so that the use can check the room temperature and change the thermostat (i.e. a low speed elastic QoS is sufficient). Both these servers will get the same "semantic field". So how will this help with their QoS requirements? My comment is that there needs to be a discussion of address utilisation. An ISP is given a /20 because it was justified by their customer numbers, assuming a certain rate of address utilisation. How much address space will be wasted as a result of the semantic field? Will the ISP need to go back to its registry for more space sooner than expected? Regards Brian Carpenter From cb.list6@gmail.com Tue Mar 5 08:03:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E90B1F0D05 for ; Tue, 5 Mar 2013 08:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 D+TyY3cqFeLW for ; Tue, 5 Mar 2013 08:03:37 -0800 (PST) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id 728D221F8915 for ; Tue, 5 Mar 2013 08:03:36 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id 16so5988168wgi.27 for ; Tue, 05 Mar 2013 08:03:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8jaqlpfw6Izn+dw78uOWBIo8HQ1x23E6vRZeYjCa4jA=; b=D1nlAS0OIjNNXxrz7+BZKQeTuA7U7sN9Ke7XBeDp4ApmzOjwZdZMZj8hZ6G2l0YeGd TCfSJa8hy4KYuPMvcoAHuxh5v1s0NPjea/ESBAljtk01g1oM1hfmxPueFbeBjNIkBccG 7UL9Z7a6h7QAAfzkr7vJbLwwGZF235e2wLbjYXpP8HI3PnyzPyBdJz4So+lrjfhll2dJ Rcg3NiUkmka8nWXduY3grKgrG7eT9ean/XTCNJn1BIGxgDS75xGGLtrNlEUP/tzu7L4n XU3y2DWtrG+lCN0mdWU72yjkkUP1O6bQ1Brl0cUDIPw1IhuQURxEv+pJ/KcFhJfSxu98 ifOw== MIME-Version: 1.0 X-Received: by 10.180.75.143 with SMTP id c15mr19854202wiw.18.1362499413992; Tue, 05 Mar 2013 08:03:33 -0800 (PST) Received: by 10.194.20.35 with HTTP; Tue, 5 Mar 2013 08:03:33 -0800 (PST) Received: by 10.194.20.35 with HTTP; Tue, 5 Mar 2013 08:03:33 -0800 (PST) In-Reply-To: <5135B524.7070000@dougbarton.us> References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> <92E6AF8C-F7A6-4291-9856-D972B371BF10@delong.com> <51353736.3000800@umn.edu> <51353974.60707@dougbarton.us> <5135B093.2030208@gmail.com> <5135B524.7070000@dougbarton.us> Date: Tue, 5 Mar 2013 08:03:33 -0800 Message-ID: From: Cameron Byrne To: Doug Barton Content-Type: multipart/alternative; boundary=f46d0438955593eb8e04d72f9d33 Cc: IPv6 Ops WG Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 16:03:37 -0000 --f46d0438955593eb8e04d72f9d33 Content-Type: text/plain; charset=ISO-8859-1 Doug, You seem very interested in this topic. Your interests would be well served in writing an I-D to document your position and supporting facts. I believe the list has outlived it's utility for this topic of PI space and and Nat and npt. CB On Mar 5, 2013 1:04 AM, "Doug Barton" wrote: > On 03/05/2013 12:45 AM, Brian E Carpenter wrote: > >> On a point of historical fact: >> >> On 05/03/2013 00:52, Owen DeLong wrote: >> ... >> >> The IETF did NOT sign off on PI for IPv6 before the RIR policies were >>> already implemented and dispensing it. >>> >>> I don't know if the IETF ever officially signed off on it or not, but I >>> do know that at least the first RIR policy was decided and implemented >>> without any regard to IETF action on the subject. >>> >> >> The IETF gave control over address assignment policy to IANA on March >> 1st, 2000 [RFC2860, clause 4.3]. >> > > Yes, and speaking as the person who was the IANA manager at the time the > PI debate hit full volume, there was no set of asbestos long-johns thick > enough for me to have put "Thou shalt have IPv6 PI" in writing. :) > > I was happy to have played a small role in brokering conversations that > ultimately helped the right things to happen, and ultimately very happy > that the right things _did_ happen, but IANA's official role in that space > was and is largely secretarial. > > Doug > > ______________________________**_________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/**listinfo/v6ops > --f46d0438955593eb8e04d72f9d33 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Doug,

You seem very interested in this topic. Your interests would= be well served in writing an I-D to document your position and supporting = facts. I believe the list has outlived it's utility for this topic of P= I space and and Nat and npt.

CB

On Mar 5, 2013 1:04 AM, "Doug Barton" = <dougb@dougbarton.us> wrot= e:
On 03/05/2013 12:45 AM, Brian E Carpenter wrote:
On a point of historical fact:

On 05/03/2013 00:52, Owen DeLong wrote:
...

The IETF did NOT sign off on PI for IPv6 before the RIR policies were alrea= dy implemented and dispensing it.

I don't know if the IETF ever officially signed off on it or not, but I= do know that at least the first RIR policy was decided and implemented wit= hout any regard to IETF action on the subject.

The IETF gave control over address assignment policy to IANA on March 1st, = 2000 [RFC2860, clause 4.3].

Yes, and speaking as the person who was the IANA manager at the time the PI= debate hit full volume, there was no set of asbestos long-johns thick enou= gh for me to have put "Thou shalt have IPv6 PI" in writing. :)
I was happy to have played a small role in brokering conversations that ult= imately helped the right things to happen, and ultimately very happy that t= he right things _did_ happen, but IANA's official role in that space wa= s and is largely secretarial.

Doug

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops
--f46d0438955593eb8e04d72f9d33-- From dougb@dougbarton.us Tue Mar 5 08:31:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EF521F8937 for ; Tue, 5 Mar 2013 08:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLbOUItRD8p1 for ; Tue, 5 Mar 2013 08:31:44 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 123D521F890D for ; Tue, 5 Mar 2013 08:31:44 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:d8a5:7c11:1cda:1a82] (unknown [IPv6:2001:470:d:5e7:d8a5:7c11:1cda:1a82]) by dougbarton.us (Postfix) with ESMTPSA id 9194B22B6D for ; Tue, 5 Mar 2013 16:31:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362501103; bh=u8pxAdMatmgHVWgK2AcRCGSmo2FoHUVoOV4K3b5mivQ=; h=Date:From:To:Subject:References:In-Reply-To; b=k0nnhUMoZlsOFb6J0lFzu2nFuDrYTPiiHmAQmNAjBXhI7F64Al6WBPf51QF87N/C3 Nd3EruLdGoxV0c1bjwvDkt5Jog2U+Q9xBTGCETA/piKqeoysd+x3ESvBjS2xS/RKy/ IdEqGebsFQUoq4U53GJbAER81L/UTkt+YReqK2MM= Message-ID: <51361DEF.2080805@dougbarton.us> Date: Tue, 05 Mar 2013 08:31:43 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: IPv6 Ops WG References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> <92E6AF8C-F7A6-4291-9856-D972B371BF10@delong.com> <51353736.3000800@umn.edu> <51353974.60707@dougbarton.us> <51354262.9000604@umn.edu> <5135A98E.3000705@dougbarton.us> <24A1C2A2-B117-46E7-8BE6-EF3E63A95359@delong.com> In-Reply-To: <24A1C2A2-B117-46E7-8BE6-EF3E63A95359@delong.com> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 16:31:44 -0000 On 03/05/2013 02:49 AM, Owen DeLong wrote: > Right... And it did, indeed, stay that way. So, the RIR(s), or, more accurately, some individuals in the RIR communities, took it upon themselves to craft guidance from the RIR policy development processes to cover that lack. On this topic I think we've reached the "blind men describing an elephant" phase, so I'll let what I have said already stand on its own merit. Doug From joelja@bogus.com Tue Mar 5 09:10:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CAC21F845A for ; Tue, 5 Mar 2013 09:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.174 X-Spam-Level: X-Spam-Status: No, score=-102.174 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 Tik20aLZjbmB for ; Tue, 5 Mar 2013 09:10:28 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2E421F891D for ; Tue, 5 Mar 2013 09:10:27 -0800 (PST) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r25HANB2030560 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 5 Mar 2013 17:10:23 GMT (envelope-from joelja@bogus.com) Message-ID: <513626FF.4040903@bogus.com> Date: Tue, 05 Mar 2013 09:10:23 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Owen DeLong , Doug Barton References: <871389F3-7EDE-4215-8267-E7ACE28E9E9C@delong.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD48E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6DD545@nkgeml506-mbx.china.huawei.com> <30066E33-B342-442E-9F6E-8E0E29ECB6E1@delong.com> <51318FC8.8070600@dougbarton.us> <51319B17.1070609@dougbarton.us> <5132726C.5040600@dougbarton.us> <51345CD6.3070807@dougbarton.us> <92E6AF8C-F7A6-4291-9856-D972B371BF10@delong.com> <51353736.3000800@umn.edu> <51353974.60707@dougbarton.us> In-Reply-To: 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]); Tue, 05 Mar 2013 17:10:23 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 17:10:28 -0000 On 3/4/13 4:52 PM, Owen DeLong wrote: > On Mar 4, 2013, at 4:16 PM, Doug Barton wrote: > >> On 03/04/2013 04:07 PM, David Farmer wrote: >>> I don't believe the content networks were particularly advocates of PI, >>> at least not any more than a number of other groups. That said, I >>> believe content networks generally supported PI, but so did many >>> others. So, primarily crediting content networks for PI is an over >>> statement of their role. >> Fair enough. My point remains however. As-designed IPv6 was PA only. It took an enormous hue and cry to get that changed. And yes, the policy change happened at the RIRs, but not till AFTER the IETF signed off, which did not occur till AFTER various large network operators made it clear that they would never deploy v6 till PI space was available. >> > It must be wonderful to be able to modify history to suit your argument. > > The IETF did NOT sign off on PI for IPv6 before the RIR policies were already implemented and dispensing it. > > I don't know if the IETF ever officially signed off on it or not, but I do know that at least the first RIR policy was decided and implemented without any regard to IETF action on the subject. As a historical point, some of the very first /32 prefix assignments were to organizations I would characterize as "non-ISP" . From the outset the stated model (if one were assuming pi-only meant ISP) didn't match deployment. There are some other questions one can ask about the policy in place at that time. e.g. what's an LIR, and whats a plan for making 200 /48 assignments within two years since lots of organizations make subassignments, and anyone can have a plan. What we got out of the experience is unsurprisingly the world we already lived in. That network operators (not ISPs) go out and secure the resources the need to run the networks that they have. Policy in the RIRs is accountable to the stakeholders and so forth. > Owen > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From owen@delong.com Tue Mar 5 17:15:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABAA11E80A5 for ; Tue, 5 Mar 2013 17:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.604, 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 1vLfEX3UwtZ6 for ; Tue, 5 Mar 2013 17:15:52 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 3C79C11E80A3 for ; Tue, 5 Mar 2013 17:15:52 -0800 (PST) Received: from [10.255.251.216] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r261CLfr024555 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 Mar 2013 17:12:22 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r261CLfr024555 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362532342; bh=N19b3/iRiBkqxAG4R/aMgOj0/2g=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=gLEWt+CsuXYUtznyWJwvA3J3Rmi613QP+rTtmdkl+O5DxcJRTSf88ryqKOKbCeETh R/WXg3Lpnf2PkBAULid+VwwLczTO3D1xur0OL5b+x1S7zoGSv/t7KKlFFVMf/RjjdL hJEEfLqDNIkIrc/qlXidvdCcBbGloFPlfQvGeDZY= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <8A317FD8C00FEE448E52D4EE5B56BB3E02513FBE2324@RZJC1EX.jr1.local> Date: Tue, 5 Mar 2013 17:12:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8A317FD8C00FEE448E52D4EE5B56BB3E02513FBE2301@RZJC1EX.jr1.local> <3AC1A1D6-6ED1-4A3E-BE7A-AE5306A3E6CC@delong.com> <8A317FD8C00FEE448E52D4EE5B56BB3E02513FBE2324@RZJC1EX.jr1.local> To: "Marksteiner, Stefan" X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 05 Mar 2013 17:12:22 -0800 (PST) Cc: "'v6ops@ietf.org'" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 01:15:53 -0000 On Mar 5, 2013, at 6:40 AM, "Marksteiner, Stefan" = wrote: > Hi, >=20 >> On Mar 1, 2013, at 01:35 , "Marksteiner, Stefan" = wrote: >>=20 >>> Hi, >>>=20 >>> Section 2.2.2.1 follows the principle "internal addresses for = internal communication". As they are (per default) not advertised, they = may prevent that internal services become publically available by = misconfigurations. Additionally, by their distinctive prefix, they are = easier to recognize (for operator eyes) and thus may be easier to = troubleshoot in firewalling rules and network sniffers (if, for = instance, a service is mistakenly opened to the outside). >>=20 >>=20 >> I'm not sure what you mean by "As they are (per default) not = advertised..." >>=20 >> There is no special treatment of ULA in routers. No prefix is = advertised in BGP by default. ULA or GUA. >> In other protocols, ULA is advertised with the same defaults as GUA. >>=20 >> If I have a local convention that says 2001:123::/32 is my publicly = reachable space and 2620:4:104::/48 shouldn't be advertised, it's every = bit as recognizable as ULA to the operators that work for me. >>=20 >=20 >=20 > What I've meant was just that your provider will propagate your GUA = ranges (or, more precisely, the shorter prefixes that contain these = ranges). This is not (or should not be) the case for ULA address ranges, = so they won't be reachable from the Internet even if you screw up your = security configuration (ULAs of course replace, to which I totally = agree, by no means any security mechanism - I just think of it as an = additional "insurance against mishaps"). Unless of course the attacker finds a way to send a directed packet to a = router or other device that has both our ULA and GUA through other means = (such as hiding it in a Teredo payload, delivering it to a 6to4 gateway = running on someone's laptop, passing it through your stateless NPT, = etc.) Given the myriad ways in which this particular form of phalanx looks = more like swiss cheese, I think that the illusion of default security is = usually more damaging to security than the thin veil of potential = additional protection it might provide under idealized circumstances. = Indeed, in my experience, environments that depend on "unreachable = addressing" as part of their "defense in depth" tend to be less vigilant = about their other security measures and are more likely to "screw up = their security configuration". > As for the recognition, you're probably right. The only one for whom = ULAs are maybe easier to recognize will be a new guy in an operator = team. Maybe for a week or so. > Besides of whether ULAs are useful for this purpose or not, do you = think there are any negative impacts of using ULAs for addressing = internal machines (strictly internal - who are never ever to be reached = from the outside, that is). Several. First, forever is a very long time, especially on the internet. = Thousands of things we swore just 10 years ago would never remotely = consider being attached to the internet are today (whether we realize it = or not). I know of at least one large federal agency responsible for = quite a few medical patients that wants to put implanted medical devices = in their patients on the IPv6 internet. (Yes, they do seem to be = approaching this with due regard for the security considerations, but = when they were planning to do this with a "private network with air gap" = (which wasn't), they were largely ignoring this.). As such, it will make things more difficult and likely less secure when = these things are eventually put on the internet or start talking to = systems that talk to the internet. Remember, if A trusts B and B trusts C, then A trusts C whether A knows = it or not. If your ULA host trusts a host B that has both ULA and GUA and B trusts = {whatever nightmare works for you}, then, your ULA host isn't as isolated as you assumed it was and the = distinction between ULA and GUA just became virtually meaningless. = However, in your mind and the minds of most of your administrators, it's = still an isolated system not attached to the internet with all the = assumptions that implies. OTOH, if it has a GUA prefix, then the second it starts talking to = something else that _IS_ on the internet, everyone readily recognizes = the risks for what they are. This, among other reasons, is why I say that ULA, RFC-1918, NAT not = only do not enhance security, they are actually detrimental because of = the human factors paradigm shift and shifting assumptions that come with = them. >>> Sincerely, >>>=20 >>> Stefan >>>=20 >>> P.S.: Even there is a wide consensus that ULAs (or RFC1918-addresses = in v4), I personally would broaden the suggestion in 2.2.2.1 to internal = infrastructure devices and services for the reasons stated above. If the = internal services don't have to be routed (or reside in an extra vlan), = I'd don't number them with GUAs at all and just use their LLAs, which = spares a little bit of numbering efforts. >>=20 >>=20 >> Your DNS must be fun and you've rendered them unreachable to other = internal hosts that are not on the same subnet. >=20 >=20 > I thought about SMB companies, which are too small for sensible net = segmentation, so they can use LLAs the exact same way as ULAs (except = for the fact that they are mandatory according to RFC4291 and its = predecessors) or reside in an extra VLAN, in which case they will be = orphaned on purpose - I think of a completely isolated management VLAN = for infrastructure devices such as switches, etc. As for the DNS, we = have an external and an internal zone, whereas the latter of which is = the natural home of the (of course non-autoconfig) LLA-IIDs. I don't know what too small for sensible net segmentation would be. Most = of my SMB clients have wanted to be able to have a Wifi network that = visitors can use, a wired network for employees and internal systems, = and a Wifi network for employees. That's three sensible network segments = I've implemented in organizations as small as 3 people, 1 cash register = and 1 server (plus other more transient devices, mostly in the BYOD = category). It's hard for me to imagine an SMB much smaller than that unless you go = to my one-man consulting firm, but the network there is actually quite a = bit more complex and has 5 or more segments, depending on the day. Owen From victor@jvknet.com Tue Mar 5 19:47:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E8B11E80EA for ; Tue, 5 Mar 2013 19:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.136 X-Spam-Level: X-Spam-Status: No, score=0.136 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_PAYLESS=0.5, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.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 l9KSQonhYlRL for ; Tue, 5 Mar 2013 19:47:12 -0800 (PST) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 86DD911E80A5 for ; Tue, 5 Mar 2013 19:47:12 -0800 (PST) Received: by mail-ia0-f174.google.com with SMTP id u20so6977969iag.33 for ; Tue, 05 Mar 2013 19:47:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding:x-gm-message-state; bh=fktvvgyXHYz63G+6muM88IvS80Njq3afVXwjHOXmcHY=; b=m8Iu9V+ZQhkWF8mYgyJ2xAH2LM72qRKfnL6nWQWJYMPfC75ECDjrpxJYhKnWKtUuI7 dmG4wYyWNWf4qQquOaxnCzB5zsRsjInYdLE45HW/DZIQrhKPU8r8qua0xxtkcAMJisBg uV+HN6qojzrQ0TtHcKEtFJoTnVIZxitEaJTV502jjKSCCw7B9m5MLZqPYFBA/mID68wt PGTDDpVsObOHFE2I5JvFoor8aeBNbTMXHoFmslDgz/I6aAIXnHdfzgsuxQZXZJZdcRuM wUcatKcV+9mkvyyl19GE9iXbQPlpx64I7DW7Mbp/hR/r5vMyx4NOVvgeP7FSEPqjWta4 9EEA== X-Received: by 10.50.168.4 with SMTP id zs4mr9157561igb.66.1362541632038; Tue, 05 Mar 2013 19:47:12 -0800 (PST) Received: from [192.168.100.33] ([67.224.83.162]) by mx.google.com with ESMTPS id i10sm19595063igz.9.2013.03.05.19.47.10 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 05 Mar 2013 19:47:11 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Tue, 05 Mar 2013 22:47:07 -0500 From: Victor Kuarsingh To: Owen DeLong , "Marksteiner, Stefan" Message-ID: Thread-Topic: [v6ops] ULA Usage Guide draft requesting for review In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Gm-Message-State: ALoCoQlI3WD9ZA6HRelFGQAe2MKHt/yhyfMJsU2W2qOPyXu1tkc2dxO+UwQHrbPqNf+t0DRJdaFo Cc: "'v6ops@ietf.org'" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 03:47:13 -0000 On 2013-03-05 8:12 PM, "Owen DeLong" wrote: > >Unless of course the attacker finds a way to send a directed packet to a >router or other device that has both our ULA and GUA through other means >(such as hiding it in a Teredo payload, delivering it to a 6to4 gateway >running on someone's laptop, passing it through your stateless NPT, etc.) Sure, possible. Can happen with GUAs or ULAs I guess. Not sure if using ULAs makes this more likely to happen. > >Given the myriad ways in which this particular form of phalanx looks more >like swiss cheese, I think that the illusion of default security is >usually more damaging to security than the thin veil of potential >additional protection it might provide under idealized circumstances. I am not sure I buy into this reasoning. I do agree the some may incorrectly believe that filtering and/or unreachability alone may be enough (bad), but I don't think you can assume this will be true. Also, the same can exist if using GUAs. I suspect if engineering and operations folks are apt to making such assumptions, the block type the architect picks may not change that behavior. >Indeed, in my experience, environments that depend on "unreachable >addressing" as part of their "defense in depth" tend to be less vigilant >about their other security measures and are more likely to "screw up >their security configuration". This is a far reaching statement. > >> Besides of whether ULAs are useful for this purpose or not, do you >>think there are any negative impacts of using ULAs for addressing >>internal machines (strictly internal - who are never ever to be reached >>from the outside, that is). > >Several. First, forever is a very long time, especially on the internet. >Thousands of things we swore just 10 years ago would never remotely >consider being attached to the internet are today (whether we realize it >or not). I know of at least one large federal agency responsible for >quite a few medical patients that wants to put implanted medical devices >in their patients on the IPv6 internet. (Yes, they do seem to be >approaching this with due regard for the security considerations, but >when they were planning to do this with a "private network with air gap" >(which wasn't), they were largely ignoring this.). Due diligence needs to be conducted up front to evaluate the potential or eventual need for global connectivity vs. the choices and risks of using GUA or ULA. I can also name a number of things that where not connected to the Internet years ago and still aren't. By extension, there are things I know of that were thought to need global connectivity and actually don't. I think it's an assumption that the use of IP on a given device or system inherently means it requires Internet access. As noted before on the tread, I know of very clear use cases where devices have very defined, closed circuit connectivity requirements, and will continue to be so for the system's lifecycle. > >As such, it will make things more difficult and likely less secure when >these things are eventually put on the internet or start talking to >systems that talk to the internet. I am not sure you can say this makes it less secure. Perhaps it makes it (potentially) annoying and/or expensive to re-address or hack at getting it connected later. > >Remember, if A trusts B and B trusts C, then A trusts C whether A knows >it or not. This is true for GUA and ULA. > >This, among other reasons, is why I say that ULA, RFC-1918, NAT not only >do not enhance security, they are actually detrimental because of the >human factors paradigm shift and shifting assumptions that come with them. I will need to disagree with this statement. First, ULA !=3D RFC1918. Also, using RFC1918 and/or ULA does not mean you will be using NAT (It may be true for some cases, but not all). I don't think we can postulate that the use of ULAs means that one will have less security or pay less attention then when using GUA. Good security design and operational practices is just that - good security design and operation practices. People who make errors, make assumptions during operation and are not thorough will act this way irrespective of what address type is assigned (that's not a technical problem related to address type choice). I will also say that I do agree with previous statements that standard filtering and policy rules are simpler when well known ranges can be applied (based on my experience). I also think there is validity in the notion that if both sides protect against the same ranges, we have a greater expectation of keeping things separated. Sure stuff gets configured incorrectly, and it's possible both sides mess up. But I don=B9t' see how this is more likely by using ULAs vs GUA. (I have seen as mean errors in production related to global Ips vs. RFC1918 vs. ULAs). I do however think if two sides are protecting against different ranges, there is a greater likelyhood of spillage (given that only one side needs to mess up). In the end, I am not saying everyone should use ULAs, and that ULAs are some type of swiss army knife tool; however I think there is a place for them with valid use cases. Regards, Victor K > >>>> Sincerely, >>>>=20 >>>> > >Owen > > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From jiangsheng@huawei.com Tue Mar 5 20:02:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBE211E80F3 for ; Tue, 5 Mar 2013 20:02:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aFcs3GG9Vzs for ; Tue, 5 Mar 2013 20:02:18 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E503D11E80ED for ; Tue, 5 Mar 2013 20:02:17 -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 AQI72930; Wed, 06 Mar 2013 04:02:16 +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.7; Wed, 6 Mar 2013 04:02:06 +0000 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 6 Mar 2013 04:02:00 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.156]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.007; Wed, 6 Mar 2013 12:01:55 +0800 From: Sheng Jiang To: Brian E Carpenter , IPv6 Operations Thread-Topic: [v6ops] draft-jiang-v6ops-semantic-prefix-02 Thread-Index: AQHOGbS1IKK3KaCdHUOEMhTMmDLid5iYBprg Date: Wed, 6 Mar 2013 04:01:54 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923A03C832@szxeml545-mbx.china.huawei.com> References: <51360CBC.2070204@gmail.com> In-Reply-To: <51360CBC.2070204@gmail.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.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [v6ops] draft-jiang-v6ops-semantic-prefix-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 04:02:19 -0000 SGksIEJyaWFuLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIFBsZWFzZSBzZWUgbXkgcmVw bGllcyBpbiBsaW5lcy4NCg0KPk9uZSB0aGluZyBJIGRvbid0IHVuZGVyc3RhbmQsIGFuZCBvbmUg Y29tbWVudC4NCj4NCj5Db25zaWRlciB0aGUgZmlyc3QgZXhhbXBsZToNCj4NCj4NCj4gICAgMCAg ICAgICAgICAgICAgMSAgICAgICAgICAgICAyICAgICAgICAgICAgIDMNCj4gICAgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQo+ ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCj4gICB8ICAgICAgICAgICBJQU5BIGFzc2lnbmVkIGJsb2NrICAgICAgICAg fCAgICAgIGxvY2F0b3IgICB8DQo+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICB8ICAgICAgICBsb2NhdG9yIChD b250LikgICAgICAgIHwgU2VtYW50aWMgRmllbGR8U3Vic2NyaWJlciBiaXRzfA0KPiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQo+ICAgQW4gSVNQIHNlbWFudGljIHByZWZpeCBleGFtcGxlDQo+DQo+V2hhdCBoYXBwZW5z IGlmIGEgc3Vic2NyaWJlciBoYXBwZW5zIHRvIG9wZXJhdGUgdHdvIHNlcnZlcnMgKHdoaWNoDQo+ c2hvdWxkIGJlIHF1aXRlIGNvbW1vbiBpbiBJUHY2LCB3aGVyZSAic3Vic2NyaWJlciIgZG9lcyBu b3QgbWVhbg0KPiJjbGllbnQiKT8gT25lIHNlcnZlciBpcywgc2F5LCBhIHZpZGVvIHNlcnZlciBz byB0aGF0IHRoZSB1c2VyDQo+Y2FuIGxvb2sgYXQgYSBzZWN1cml0eSBjYW1lcmEgcmVtb3RlbHkg KGkuZS4gYSBoaWdoLXNwZWVkIGxvc3MtdG9sZXJhbnQNCj5Rb1MgaXMgcmVxdWlyZWQpLiBUaGUg b3RoZXIgc2VydmVyIGlzIGEgYnVpbGRpbmcgc2VydmljZXMgcHJveHksDQo+c28gdGhhdCB0aGUg dXNlIGNhbiBjaGVjayB0aGUgcm9vbSB0ZW1wZXJhdHVyZSBhbmQgY2hhbmdlIHRoZQ0KPnRoZXJt b3N0YXQgKGkuZS4gYSBsb3cgc3BlZWQgZWxhc3RpYyBRb1MgaXMgc3VmZmljaWVudCkuIEJvdGgg dGhlc2UNCj5zZXJ2ZXJzIHdpbGwgZ2V0IHRoZSBzYW1lICJzZW1hbnRpYyBmaWVsZCIuIFNvIGhv dyB3aWxsIHRoaXMgaGVscA0KPndpdGggdGhlaXIgUW9TIHJlcXVpcmVtZW50cz8NCg0KSWYgdGhl IHNlbWFudGljIGhhcyBiZWVuIGRlc2lnbmVkIHRvIGJlIGFwcGxpY2F0aW9uLWF3YXJlLiBUaGUg c2luZ2xlIHN1YnNjcmliZXIgd291bGQgYmUgaWRlbnRpZmllZCBhcyB0d28gZGlmZmVyZW50IGNv bm5lY3Rpb24gcmVxdWVzdHMuIFR3byBkaWZmZXJlbnQgcHJlZml4IHdpbGwgYmUgZ2l2ZW4gd2l0 aCBkaWZmZXJlbnQgc2VtYW50aWMgZmllbGQuIFRoaXMga2luZCBvZiB1c2UgY2FzZSBkb2VzIG5v dCBieSB0aGUgY3VycmVudCBwcm90b2NvbHMuIFdlIGhhdmUgZGVzY3JpYmVkIHNvbWUgdGVjaG5p Y2FsIGdhcHMgaW4gb3JkZXIgdG8gZnVsZmlsbCBzdWNoIHVzZSBjYXNlLg0KDQo+TXkgY29tbWVu dCBpcyB0aGF0IHRoZXJlIG5lZWRzIHRvIGJlIGEgZGlzY3Vzc2lvbiBvZiBhZGRyZXNzDQo+dXRp bGlzYXRpb24uIEFuIElTUCBpcyBnaXZlbiBhIC8yMCBiZWNhdXNlIGl0IHdhcyBqdXN0aWZpZWQg YnkNCj50aGVpciBjdXN0b21lciBudW1iZXJzLCBhc3N1bWluZyBhIGNlcnRhaW4gcmF0ZSBvZiBh ZGRyZXNzDQo+dXRpbGlzYXRpb24uIEhvdyBtdWNoIGFkZHJlc3Mgc3BhY2Ugd2lsbCBiZSB3YXN0 ZWQgYXMgYSByZXN1bHQNCj5vZiB0aGUgc2VtYW50aWMgZmllbGQ/IFdpbGwgdGhlIElTUCBuZWVk IHRvIGdvIGJhY2sgdG8gaXRzDQo+cmVnaXN0cnkgZm9yIG1vcmUgc3BhY2Ugc29vbmVyIHRoYW4g ZXhwZWN0ZWQ/DQoNCkkgYWdyZWUgd2l0aCB5b3UgdGhhdCBzZW1hbnRpYyBlbWJlZGRlZCB3aWxs IGxvd2VyIHRoZSBhZGRyZXNzIHV0aWxpemF0aW9uIHJhdGUuIEhvd2V2ZXIsIHRoZSBhZGRyZXNz IGFsbG9jYXRpb24gaXMgbm90IG9ubHkgYWNjb3JkaW5nIHRvIHRoZSBjdXN0b21lciBudW1iZXJz LCBJIGJlbGlldmUuIFRoZXJlIGFyZSBhbHJlYWR5IG1hbnkgY2FzZXMgdGhhdCBhZGRyZXNzIHNw YWNlIGFyZSBjb25zdW1lZCBiYXNlZCBvbiBuZXR3b3JrIHRvcG9sb2dpZXMvc3RyYXRlZ2llcy9m dW5jdGlvbnMsIGV0Yy4sIHN1Y2ggYXMgbW9iaWxlIHN1cHBvcnQuIFRoZXkgYXJlIGFscmVhZHkg c2VtYW50aWMgaW4gc29tZSBzZW5zZS4gU2VtYW50aWMgcHJlZml4IGlzIGEgc2ltaWxhciBlZmZv cnRzLiBUaGUgb25seSBkaWZmZXJlbnQgaXMgd2UgYXJlIHRyeWluZyB0byBnaXZlIGEgZ2VuZXJp YyBmcmFtZXdvcmsgYW5kIGd1aWRhbmNlLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCj5S ZWdhcmRzDQo+ICAgQnJpYW4gQ2FycGVudGVyDQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj52Nm9wcyBtYWlsaW5nIGxpc3QNCj52Nm9wc0Bp ZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From dougb@dougbarton.us Tue Mar 5 20:35:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4BF21F852A for ; Tue, 5 Mar 2013 20:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 C10wms0VSk91 for ; Tue, 5 Mar 2013 20:35:13 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 8652D21F84DF for ; Tue, 5 Mar 2013 20:35:13 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:89d0:70b7:e496:6d02] (unknown [IPv6:2001:470:d:5e7:89d0:70b7:e496:6d02]) by dougbarton.us (Postfix) with ESMTPSA id 071C322B7D for ; Wed, 6 Mar 2013 04:35:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362544513; bh=RnMX27lVjY7Qqm8qor8fBhDliiRbLQxrL6+Y4Ns06cg=; h=Date:From:To:Subject:References:In-Reply-To; b=XRppU8FH5d0R6FIjoepNfZR/EaO+xL3jTlL053JFrmFYqU48qVkLTD7rKo2gmzi/8 QmOgtmWOC6PhctS13nEyr59hayBk7LZ9C14lJn6HIicfLoEEF6QMXUgRSFrKTkFgv9 gyfEBUgft+qckwb27O8D/qdk6alO57CAYSDMcfaY= Message-ID: <5136C780.3070306@dougbarton.us> Date: Tue, 05 Mar 2013 20:35:12 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "v6ops@ietf.org WG" References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 04:35:14 -0000 On 03/05/2013 01:57 AM, Lorenzo Colitti wrote: > On Tue, Mar 5, 2013 at 5:56 PM, Doug Barton > wrote: > > The vast majority of current deployments aren't using IPv6, period. > Of the tiny percentage that are, some percentage of them are using a > NAT-a-like strategy. > > > Saying "some percentage" provides no information that can be used to > make a decision. You show me your statistics first. :) Seriously though, resorting to the "You don't have numbers" tactic is expected, if not disappointing. More importantly, see below. > Many won't deploy IPv6 at all unless they have similar capabilities > to what they are already using in IPv4 NAT. > > > Is this statement based on actual experience? Yes, both my own in dealing with enterprise DNS/DHCP customers, and in the many years of people coming to the IETF and saying exactly this. There have been many people saying the same thing for well over a decade. The problem is that this message hasn't been heard by the IPv6 protocol folks, so the network operators for the most part don't bother anymore. It comes up on the various lists I'm on periodically, and the same few people are still giving out the same unrealistic advice. The people who actually run end-user networks want feature parity with IPv4. That doesn't mean that everything needs to be done exactly the same way ... NPTv6 vs traditional NAT in v4 is an obvious example of something that can and should be done better in v6. But continuing to shout at people, "You're doing it wrong!" "You shouldn't want that!" is not a message that is going to be heard, or accepted. > NAT-a-likes will be deployed for IPv6, of that there is no question. > > > But why is there no question? It's obvious that you are convinced of > this outcome, but you will likely be more convincing to others if you > make a more detailed argument. Neither I, nor the many many network operators who have brought the same message to the IETF so many times over the last decade can provide any more details than have already been provided ... it's up to y'all to hear and accept it, or not. The problem is that if you(pl.) don't get it, you'll continue making the same bad decisions, giving out the same bad advice, and most importantly, continue doing damage to IPv6 deployment. > We did not implement traversal. Sorry I misunderstood ... so many posts, so little time. :) Doug From dougb@dougbarton.us Tue Mar 5 20:56:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A41111E80ED for ; Tue, 5 Mar 2013 20:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYUuEJc5QawY for ; Tue, 5 Mar 2013 20:56:02 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 06C2B11E80A5 for ; Tue, 5 Mar 2013 20:56:02 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:89d0:70b7:e496:6d02] (unknown [IPv6:2001:470:d:5e7:89d0:70b7:e496:6d02]) by dougbarton.us (Postfix) with ESMTPSA id 84EFA22B7D for ; Wed, 6 Mar 2013 04:56:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362545761; bh=ZiBEzBhlzEg9QTnB2r7Lopx/GPqadmvARDZ2ydMcdbM=; h=Date:From:To:Subject:References:In-Reply-To; b=I2N9fiSwVmU0J4liex+VvRf0zjrOV/Hw7rJqAZNp3x/7v64M8COz4Q4hihtuGAfT0 FjUNzij0eeCPJ8E0gze6kuQ3RXm5JHsLAT0o4fNx185w58uT+p7HwMjgiSg+mCw0XW 4idw34H5CDkUoSl+mWgtFlXv37qESZNG3pjgR9Vk= Message-ID: <5136CC60.8060005@dougbarton.us> Date: Tue, 05 Mar 2013 20:56:00 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 04:56:02 -0000 On 03/05/2013 02:24 AM, Owen DeLong wrote: > No, Lorenzo's (and my) argument is that NAT technologies in IPv6 aren't getting wide deployment today (even as a percentage of IPv6 deployments) and that there's no reason to expect that trend will change. Further, if that trend doesn't change, then it's unlikely that there will be enough of an installed base to drive development. Owen, A light-bulb went on for me when I read this, which I think illustrates our difference of opinion. (The way I understand it) you and Lorenzo are looking at the small installed base of v6 now, seeing that there are very few NAT-a-like technologies already deployed in that group, and coming to the conclusion that people who deploy IPv6 are not interested in deploying NAT. You therefore conclude that there is hope for a future without NAT if you just keep shouting loud enough about how bad it is. That line of thought has several flaws. The most obvious is that at this point (leaving aside content networks) the people on the end-user networks that have IPv6 are almost all early adopters. They didn't get it by accident, and in some cases had to work pretty hard to set it up and get it working. It's not surprising that there are not a lot of NAT'ish technologies deployed among that group. More subtly (and this is the crux of our disagreement I think) my perspective is that a big part of the reason that there is so little end-user deployment now is the lack of features relative to IPv4. So not only does the current installed base not represent a statistically valid sample due to the inherent volunteer bias, the very organizations that would be representing a significant percentage, if not the majority of IPv6 end users, are self-selected out of the pool. Meanwhile, for those that don't follow NANOG and might believe that I'm the only one holding a similar opinion, please check out this excellent response: http://mailman.nanog.org/pipermail/nanog/2013-March/056619.html Doug From owen@delong.com Tue Mar 5 21:21:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326AC11E80F4 for ; Tue, 5 Mar 2013 21:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, SARE_MILLIONSOF=0.315] 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 jJQPrvRR2rMc for ; Tue, 5 Mar 2013 21:21:06 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 3B85B11E80F3 for ; Tue, 5 Mar 2013 21:21:05 -0800 (PST) Received: from [10.255.251.216] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r265ILi4031766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 Mar 2013 21:18:21 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r265ILi4031766 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362547102; bh=x3LNmKvhPgSccGNjCFLKMZ4XrY4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=LQF17VinoL0MNJlwKYNoEDM9tGXrO2WTtYZa05m+UV6PIYRF9wGmVH0SSH9dJJQUs pRhtG6SeI4PrfzEzNyke2RMfXb2xIEu3ckRCans26rXY9EiCPZLKE1QfMMDSlqh2Ds cPsH1OrkfSMjBZMrRFllodyyek0lvJ3SQ1tqJSIY= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <5136CC60.8060005@dougbarton.us> Date: Tue, 5 Mar 2013 21:18:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 05 Mar 2013 21:18:22 -0800 (PST) Cc: v6ops@ietf.org Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 05:21:07 -0000 On Mar 5, 2013, at 8:56 PM, Doug Barton wrote: > On 03/05/2013 02:24 AM, Owen DeLong wrote: >> No, Lorenzo's (and my) argument is that NAT technologies in IPv6 = aren't getting wide deployment today (even as a percentage of IPv6 = deployments) and that there's no reason to expect that trend will = change. Further, if that trend doesn't change, then it's unlikely that = there will be enough of an installed base to drive development. >=20 > Owen, >=20 > A light-bulb went on for me when I read this, which I think = illustrates our difference of opinion. (The way I understand it) you and = Lorenzo are looking at the small installed base of v6 now, seeing that = there are very few NAT-a-like technologies already deployed in that = group, and coming to the conclusion that people who deploy IPv6 are not = interested in deploying NAT. You therefore conclude that there is hope = for a future without NAT if you just keep shouting loud enough about how = bad it is. No. I wouldn't say that is a completely accurate characterization. I won't attempt to speak for Lorenzo (he and I don't always agree, = either), but for my part, I will say this. The fact that so many IPv6 deployments exist just fine in the real world = without "NAT-alikes" is proof that IPv6 can be deployed just fine = without NAT. The fact that NAT is so damaging to the internet in general means that I = have a strong preference for an undamaged internet unencumbered by NAT. Absent some truly compelling reason to add NAT to the mix (and none has = yet been presented), I see no reason to accept its overwhelming costs, = tradeoffs, and limitations. IMHO, the organizations that are holding off on deploying IPv6 until = they can have NAT will eventually be a self-resolving problem without = NAT. Each will come to their own conclusion and do one of the following: 1. Realize that NAT is, actually, unnecessary and join the = rest of the world in IPv6. 2. Deploy some form of hacked-together NAT-alike, realize = that the ISVs are not supporting their world view, that their applications are breaking, = and eventually scrap it. 3. Fade into irrelevance from an internet perspective as = they are able to reach fewer and fewer internet participants over time. Now, the other possibility, if we do enable NAT on IPv6 as you are = advocating and the ISVs do choose to (unfortunately) support it is that = we get back on the expensive and detrimental merry-go-round that is NAT, waste more millions of dollars in development money to make the IPv6 = internet just as degraded as the current IPv4 internet (or more so) and = ensure that future generations are stuck with the subscriber/provider = model built in at the basic level of the developer assumptions as they = continue to produce code for the lowest common denominator of networks = (that being the ones stuck behind NAT). > That line of thought has several flaws. The most obvious is that at = this point (leaving aside content networks) the people on the end-user = networks that have IPv6 are almost all early adopters. They didn't get = it by accident, and in some cases had to work pretty hard to set it up = and get it working. It's not surprising that there are not a lot of = NAT'ish technologies deployed among that group. Actually, a lot of the residential subscribers on the internet and many = of the mobile devices at this point did, in fact, get it quite by = accident, so to speak. Comcast, Verizon, and Verizon Wireless, and AT&T = have all deployed IPv6 on many unsuspecting subscribers mostly without = incident. Last I heard from Jon, about 3% of all of Comcast's customers = now have native IPv6. > More subtly (and this is the crux of our disagreement I think) my = perspective is that a big part of the reason that there is so little = end-user deployment now is the lack of features relative to IPv4. So not = only does the current installed base not represent a statistically valid = sample due to the inherent volunteer bias, the very organizations that = would be representing a significant percentage, if not the majority of = IPv6 end users, are self-selected out of the pool. I disagree. I talk to a lot of end-user network operators pretty = regularly as part of my job. The number one reason I hear from them has = nothing to do with NAT. In fact about 75% of them regard getting rid of = NAT as a feature, not a bug. The main reason boils down to a combination = of inertia and drag. Inertia in that IT professionals with a working = IPv4 network are loathe to make a change to implement IPv6 unless they = see a strong immediate need to do so. This is exacerbated by management = that doesn't want to spend money on anything that doesn't have a return = unless it's going to prevent the building from burning down in the next = hour. Drag in terms of the fact that the transition costs money. Even if = you already have all the hardware and software and don't need to pay for = any upgrades, there's still a lot of man-hours involved in the process = for any sizable network. > Meanwhile, for those that don't follow NANOG and might believe that = I'm the only one holding a similar opinion, please check out this = excellent response: >=20 > http://mailman.nanog.org/pipermail/nanog/2013-March/056619.html ROFLMAO=85 Do you have any idea who Matthew is? He doesn't work in an end-user network=85 If you look at my rebuttal, = you'll get a strong clue to where he's at and why he espouses such views = at the bottom. Owen From brian.e.carpenter@gmail.com Wed Mar 6 00:49:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BE521F8484 for ; Wed, 6 Mar 2013 00:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.575 X-Spam-Level: X-Spam-Status: No, score=-99.575 tagged_above=-999 required=5 tests=[AWL=-1.254, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, J_CHICKENPOX_33=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 FTsZB1rSZi4i for ; Wed, 6 Mar 2013 00:49:02 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E55CB21F848B for ; Wed, 6 Mar 2013 00:49:01 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id 12so4408771wgh.1 for ; Wed, 06 Mar 2013 00:49:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WrtcANb5vk7xlKBLykWRbprA8U1RUwEiVBXD9S3Bz+o=; b=FtYk6kr3WG8QcD5kHZA+L/fmBUoG4ycr/eEcjFoijL4ncRrg87/iKoU46e1ushdVZx huk3S+RCcqeKpEkUaELV4ZksM07kbfECcTVfdGJ88yXRH0xIWn36zktURDH0wmWk50St an6wB2V8qy2aReBjQ54pGZHOaIkho9nmMIdGoBEJh5KPccpfGypJudSiEaeEB6T47zgT uwLqdDyggqRM4UH76pFR8JjxawtL2bk0lsYoBNK4PcapY8fEIRompsxHnJ+99YhLiyc3 O2+xlhGhNXq8+gCpXPyrKLun+Rl7EIcGLnBbdQ7e2usB/Qd+qIWoaEsjMOyFMg7lT3sI QemA== X-Received: by 10.180.82.70 with SMTP id g6mr23932488wiy.21.1362559741110; Wed, 06 Mar 2013 00:49:01 -0800 (PST) Received: from [192.168.1.65] (host-2-101-188-201.as13285.net. [2.101.188.201]) by mx.google.com with ESMTPS id q13sm26489336wie.0.2013.03.06.00.48.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 00:49:00 -0800 (PST) Message-ID: <51370302.7000003@gmail.com> Date: Wed, 06 Mar 2013 08:49:06 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: v6ops@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> In-Reply-To: <5136CC60.8060005@dougbarton.us> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 08:49:02 -0000 > On 03/05/2013 02:24 AM, Owen DeLong wrote: >> No, Lorenzo's (and my) argument is that NAT technologies in IPv6 >> aren't getting wide deployment today (even as a percentage of IPv6 >> deployments) and that there's no reason to expect that trend will >> change. Further, if that trend doesn't change, then it's unlikely that >> there will be enough of an installed base to drive development. s/IPv6/IPv4/ and this is something I might have written in 1994. I'm a well known NAT hater and I dislike NPTv6 too, but I think we have to be realistic. Those who want address isolation *will* deploy NPTv6. Some will even insist on NAPT66. It's perfectly appropriate to describe the ULA+NPTv6 scenario. We can't recommend it, because NPTv6 is Experimental. Can we move on? Brian From owen@delong.com Wed Mar 6 02:00:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9068921F86F5 for ; Wed, 6 Mar 2013 02:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PTbJFClp+U0 for ; Wed, 6 Mar 2013 02:00:56 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id E1D8D21F86AF for ; Wed, 6 Mar 2013 02:00:55 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r269xQPj005160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 6 Mar 2013 01:59:26 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r269xQPj005160 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362563967; bh=hL7a4pkmbxhxzFJDVsLAxblzvN0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=p5ru5S47zBgSJb7E+QOH4RAd8K2HcjHVWSiHPgF2+2ztGEgtbWAUoE9e7LKRoaGzL tee5tSPZrPOfoiI6PZVn72l77PV1eKAw2dgYN5fVzEA09lvJ/z6L9T8SsSde+tZbmh GQY47KTL1VGThNbi2PTD7evYUdLYJani2nD6bmiU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <51370302.7000003@gmail.com> Date: Wed, 6 Mar 2013 01:59:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 06 Mar 2013 01:59:27 -0800 (PST) Cc: v6ops@ietf.org Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 10:00:56 -0000 On Mar 6, 2013, at 00:49 , Brian E Carpenter = wrote: >> On 03/05/2013 02:24 AM, Owen DeLong wrote: >>> No, Lorenzo's (and my) argument is that NAT technologies in IPv6 >>> aren't getting wide deployment today (even as a percentage of IPv6 >>> deployments) and that there's no reason to expect that trend will >>> change. Further, if that trend doesn't change, then it's unlikely = that >>> there will be enough of an installed base to drive development. >=20 > s/IPv6/IPv4/ and this is something I might have written in 1994. >=20 > I'm a well known NAT hater and I dislike NPTv6 too, but I think > we have to be realistic. Those who want address isolation *will* > deploy NPTv6. Some will even insist on NAPT66. I don't doubt this in the least. The important questions are not whether that will happen or not. The important questions are: 1. Will enough sites do this to drive ISVs to support it? 2. What can we do to reduce the number of sites that hinder themselves in this way to help ensure a negative answer = to 1? > It's perfectly appropriate to describe the ULA+NPTv6 scenario. > We can't recommend it, because NPTv6 is Experimental. Can we move on? I don't just want to not recommend it. I want to document that we = recommend against it. If we can do that, then yes, I'm willing to move on. Owen From oej@edvina.net Wed Mar 6 03:01:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721D521F87FB for ; Wed, 6 Mar 2013 03:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 UdqInXU9jr0R for ; Wed, 6 Mar 2013 03:01:32 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA5F21F87EE for ; Wed, 6 Mar 2013 03:01:30 -0800 (PST) Received: from [192.168.40.5] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id CFCD693DE3E; Wed, 6 Mar 2013 11:01:13 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> Date: Wed, 6 Mar 2013 12:00:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> To: Owen DeLong X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 11:01:32 -0000 6 mar 2013 kl. 10:59 skrev Owen DeLong : >=20 > On Mar 6, 2013, at 00:49 , Brian E Carpenter = wrote: >=20 >>> On 03/05/2013 02:24 AM, Owen DeLong wrote: >>>> No, Lorenzo's (and my) argument is that NAT technologies in IPv6 >>>> aren't getting wide deployment today (even as a percentage of IPv6 >>>> deployments) and that there's no reason to expect that trend will >>>> change. Further, if that trend doesn't change, then it's unlikely = that >>>> there will be enough of an installed base to drive development. >>=20 >> s/IPv6/IPv4/ and this is something I might have written in 1994. >>=20 >> I'm a well known NAT hater and I dislike NPTv6 too, but I think >> we have to be realistic. Those who want address isolation *will* >> deploy NPTv6. Some will even insist on NAPT66. >=20 > I don't doubt this in the least. >=20 > The important questions are not whether that will happen or not. The > important questions are: >=20 > 1. Will enough sites do this to drive ISVs to support it? > 2. What can we do to reduce the number of sites that hinder > themselves in this way to help ensure a negative answer = to 1? >=20 >> It's perfectly appropriate to describe the ULA+NPTv6 scenario. >> We can't recommend it, because NPTv6 is Experimental. Can we move on? >=20 > I don't just want to not recommend it. I want to document that we = recommend > against it. If we can do that, then yes, I'm willing to move on. >=20 I also think there's an education problem in the NAT space. Many people = I've met start with NAT requirements, then I go through that every interface has = multiple=20 addresses, that you can set aside part of the public address space for = internal use to=20 avoid future renumbering and conflicts, that you even have ULAs if = really needed. After that we go through NAT's "security" aspects and how we can = replicate those in a firewall. The "multiple addresses on every interface" is quite = often an eye- opener, something they have totally missed. And something that I keep = forgetting in my daily work sometimes... After that talk there's usually no more discussion of NAT.=20 But of course, if people have used NAT forever and that's part of their = TCP/IP toolset, it's hard to relearn. And they end up requiring NAT all over = again. But in the end, there will always be people strongly requiring NAT. We = just have=20 to live with that.=20 I agree with Owen that should not recommend it at all and spend more = time - and documentation - to explain the alternatives. /O= From farmer@umn.edu Wed Mar 6 06:44:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB7C21F8651 for ; Wed, 6 Mar 2013 06:44:03 -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_33=0.6, 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 2GeuSu8OMV3u for ; Wed, 6 Mar 2013 06:44:02 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id BE6A521F8459 for ; Wed, 6 Mar 2013 06:44:00 -0800 (PST) Received: from mail-oa0-f70.google.com (mail-oa0-f70.google.com [209.85.219.70]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Wed, 6 Mar 2013 08:43:50 -0600 (CST) X-Umn-Remote-Mta: [N] mail-oa0-f70.google.com [209.85.219.70] #+LO+TR X-Umn-Classification: local Received: by mail-oa0-f70.google.com with SMTP id h2so49921952oag.5 for ; Wed, 06 Mar 2013 06:43:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=PDMs2XNiJH4A6bqldTZGLCdKbHQxa/nWUWw8MLCUKHw=; b=Yt1UkoVGLYIgHDA9uQuzmqqY1ztL46j8/BtaP0J0okbnpu507f7ihnG01SzD+a2e+s Vnd0Anj34NyujQ09yEHanrECiq5g2BCqiSx5CPkq7IOipJnQZwA7s2HPSqN4pRsPxyGZ sICK44eICnTKtCj/sgGwMjTRIUMc43Rtwn8nwgo6qTvl8WUNbXkG0DF6+iRlwVhyoIcX OZX0SwL3dy/lPHhLQo6Nh5cXneceaV9B07y1NXQ6CGovkoZC52sMYViG4tyOskTjGSK9 FBBMIbAWiKhpCleMB4ZYFkHdixpX4nOBZ5h2tE4PxbrsAfmN0CMYlHac39tLJN2v6u47 bFog== X-Received: by 10.43.117.136 with SMTP id fm8mr31507353icc.33.1362581029550; Wed, 06 Mar 2013 06:43:49 -0800 (PST) X-Received: by 10.43.117.136 with SMTP id fm8mr31507346icc.33.1362581029405; Wed, 06 Mar 2013 06:43:49 -0800 (PST) Received: from oit201651646.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPS id a3sm24505704igq.5.2013.03.06.06.43.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 06:43:48 -0800 (PST) Message-ID: <5137561D.5070604@umn.edu> Date: Wed, 06 Mar 2013 08:43:41 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Olle E. Johansson" References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlBiJt4tUUu0e2vc8o739SvglJ5gY36MiTyZe+0BtEZhMRnwbqL/2rXgvyf7MujFBudM4iK0RIInyxlyiM8429qSzcwBM8IHpUb1CuBG804if5DMAlbeGqIcjpqYtMXyCmzg7cb Cc: v6ops@ietf.org Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 14:44:03 -0000 On 3/6/13 05:00 , Olle E. Johansson wrote: > > 6 mar 2013 kl. 10:59 skrev Owen DeLong : > >> On Mar 6, 2013, at 00:49 , Brian E Carpenter wrote: >> .... >>> It's perfectly appropriate to describe the ULA+NPTv6 scenario. >>> We can't recommend it, because NPTv6 is Experimental. Can we move on? >> >> I don't just want to not recommend it. I want to document that we recommend >> against it. If we can do that, then yes, I'm willing to move on. >> > > I also think there's an education problem in the NAT space. Many people I've met > start with NAT requirements, then I go through that every interface has multiple > addresses, that you can set aside part of the public address space for internal use to > avoid future renumbering and conflicts, that you even have ULAs if really needed. > After that we go through NAT's "security" aspects and how we can replicate those > in a firewall. The "multiple addresses on every interface" is quite often an eye- > opener, something they have totally missed. And something that I keep forgetting > in my daily work sometimes... > > After that talk there's usually no more discussion of NAT. > > But of course, if people have used NAT forever and that's part of their TCP/IP > toolset, it's hard to relearn. And they end up requiring NAT all over again. > > But in the end, there will always be people strongly requiring NAT. We just have > to live with that. > > I agree with Owen that should not recommend it at all and spend more time > - and documentation - to explain the alternatives. Brian said we can't recommend it, I'll add we (the IETF) won't recommend it, but that's not what Owen is saying. Owen is saying we can't discuss NAT without the equivalent of putting a surgeon general's waring on the top of the document that says NAT causes birth defects. Or with less hyperbole, Owen is saying not recommending it, is not sufficient, he is saying we can't discuss it without recommend against it. My question to Owen and Doug is where do you think this argument is going? I'm getting sick and tired of hearing this debate on one mailing list or another every 3 to 6 months. You guys are not going to shout the other down, so stop trying. How do we find useful and practical compromise out of this discussion? Like Brian I hate NAT as much as the next guy, but even I use it every day, and I hate myself for it, but I'm human and full of contradictions. If IPv6 fails we have no hope of NAT ever going away. And I'm afraid that if we insist on a NAT free IPv6, that IPv6 will fail to be adopted by the masses of Internet users. So, Doug stop putting lipstick on a PIG, NAT IS EVIL!! Owen get over it, NAT in IPv6 is a NECESSARY EVIL!! For IPv6 to succeed and have any hope of the end-to-end principle to triumph in the end, IPv6 needs at least NPTv6 and probably even NAT66. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From bill.jouris@insidethestack.com Wed Mar 6 06:59:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1491A21F86E3 for ; Wed, 6 Mar 2013 06:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6] 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 mjrBVbxjY6mT for ; Wed, 6 Mar 2013 06:59:42 -0800 (PST) Received: from nm27.access.bullet.mail.sp2.yahoo.com (nm27.access.bullet.mail.sp2.yahoo.com [98.139.44.154]) by ietfa.amsl.com (Postfix) with ESMTP id F1EA521F8702 for ; Wed, 6 Mar 2013 06:59:41 -0800 (PST) Received: from [98.139.44.97] by nm27.access.bullet.mail.sp2.yahoo.com with NNFMP; 06 Mar 2013 14:59:41 -0000 Received: from [98.139.44.70] by tm2.access.bullet.mail.sp2.yahoo.com with NNFMP; 06 Mar 2013 14:59:41 -0000 Received: from [127.0.0.1] by omp1007.access.mail.sp2.yahoo.com with NNFMP; 06 Mar 2013 14:59:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 764431.6097.bm@omp1007.access.mail.sp2.yahoo.com Received: (qmail 59573 invoked by uid 60001); 6 Mar 2013 14:59:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362581981; bh=i7gxkLLln91wb93Xrj1iPvhv5oD4jXgEVNZgdS3rwDQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ympiB8sQV3fyak/ZK+O7Qk32xB4XRwtK19h9g3yBWhOimZbXfJSmDyiq5pu88fiLxBSXO1jNZ+Du/OIDfUbzVbbCXMjotXjdkUGSbfQrqoZlm6vTB/22sDL7IouEh077P+oGb3rfV9vvX8AJPgrg/A7MUyYG6JezISKEgJIrArg= X-YMail-OSG: Q1I_fLwVM1lO6O9Bemm9Kz9azBVKTst063iEer_PxCxdmy3 dAA7sTxcj7aXmSgZfKCh7zYFb90rmk348fb1uvL1rUOMZ7sYnBaKsLisjzzm K7f_rmMPbTbnDTckdlPnkqLqdio5_OsVtyiBuOwisY8U8pNV7gQt.InSVRTn jORoMEs0YOEtf.pr_K9niTfEwqKitMymXVuO5HMg.w8yxsmbvQ7GzWIccp5r MuvdPXlBxKJ1Q3J.R4f6UINVVbfuiPoN8XfK8AYBTP4qsnwd7K62B3Rl.C5A yewmPZLYED7oBJKnuhH35JmuSnCE_oupE27V30Sg_m0sxKDBxBpZZYhmBg.i S4XZeJmJH56SZuOGq1JXPKBU9jlv3m3wr1RAKPPsFyAnDCH4U0WyYEnVISK8 QwG51V9Vk5OGzymSztjH4fFF9PGsQTSDI_Jw5ZBmj_RN7fnDPmMq7KbnUW3R s32_jvc0dZ786aov8gJarEVBcBweljHfM.KdQUUCD4AvSJWaq7ey0REA43ld E20Vp86gRA5Vnho7F5SrbQBDgD9F9Nr0GK0taUMIc1DzHiBWfeBNX1P5ZWiS QbBmuRVZMqDYCF6KxrDfhuXjO1S7hgF1uLGDSZ6w- Received: from [50.148.178.232] by web2805.biz.mail.ne1.yahoo.com via HTTP; Wed, 06 Mar 2013 06:59:41 PST X-Rocket-MIMEInfo: 001.001, V2hpY2ggYnJpbmdzIHRoZSBxdWVzdGlvbiBkb3duIHRvIHRoaXM6DQpUbyB3aGF0IGV4dGVudCBkbyB3ZSBkaXNjb3VyYWdlLCBidXQgYWxsb3csIE5BVCB0byBjb250aW51ZSwgdnMNCnRvIHdoYXQgZXh0ZW50IGRvIHdlIHNpbXBseSByZWZ1c2UgdG8gYWNjb21vZGF0ZSBpdCBhdCBhbGw_DQoNClRoYXQgaXMsIGRvIHdlIHdhbnQgdG8gaW5zaXN0IG9uIG91ciBpZGVhbCBvZiB3aGF0IGEgcGVyZmVjdCBJUHY2IG5ldHdvcmsgc2hvdWxkIGxvb2sgbGlrZT_CoCBPciBhcmUgd2Ugd2lsbGluZyB0byBhY2NvbW8BMAEBAQE- X-Mailer: YahooMailClassic/15.1.4 YahooMailWebService/0.8.135.514 Message-ID: <1362581981.54438.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> Date: Wed, 6 Mar 2013 06:59:41 -0800 (PST) From: Bill Jouris To: "Olle E. Johansson" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1619178251-1000797774-1362581981=:54438" Cc: v6ops@ietf.org Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 14:59:43 -0000 --1619178251-1000797774-1362581981=:54438 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Which brings the question down to this: To what extent do we discourage, but allow, NAT to continue, vs to what extent do we simply refuse to accomodate it at all? That is, do we want to insist on our ideal of what a perfect IPv6 network s= hould look like?=A0 Or are we willing to accomodate, to some extent, the re= al world that most of the people building and maintaining network work in? Bill Jouris Inside Products, Inc. www.insidethestack.com 831-659-8360 925-855-9512 (direct) --- On Wed, 3/6/13, Olle E. Johansson wrote: From: Olle E. Johansson Subject: Re: [v6ops] ULA discussion #1 ULA+NAT To: "Owen DeLong" Cc: v6ops@ietf.org Date: Wednesday, March 6, 2013, 3:00 AM 6 mar 2013 kl. 10:59 skrev Owen DeLong : >=20 > On Mar 6, 2013, at 00:49 , Brian E Carpenter wrote: >=20 >>> On 03/05/2013 02:24 AM, Owen DeLong wrote: >>>> No, Lorenzo's (and my) argument is that NAT technologies in IPv6 >>>> aren't getting wide deployment today (even as a percentage of IPv6 >>>> deployments) and that there's no reason to expect that trend will >>>> change. Further, if that trend doesn't change, then it's unlikely that >>>> there will be enough of an installed base to drive development. >>=20 >> s/IPv6/IPv4/ and this is something I might have written in 1994. >>=20 >> I'm a well known NAT hater and I dislike NPTv6 too, but I think >> we have to be realistic. Those who want address isolation *will* >> deploy NPTv6. Some will even insist on NAPT66. >=20 > I don't doubt this in the least. >=20 > The important questions are not whether that will happen or not. The > important questions are: >=20 > =A0=A0=A0 1.=A0=A0=A0 Will enough sites do this to drive ISVs to support = it? > =A0=A0=A0 2.=A0=A0=A0 What can we do to reduce the number of sites that h= inder > =A0=A0=A0 =A0=A0=A0 themselves in this way to help ensure a negative answ= er to 1? >=20 >> It's perfectly appropriate to describe the ULA+NPTv6 scenario. >> We can't recommend it, because NPTv6 is Experimental. Can we move on? >=20 > I don't just want to not recommend it. I want to document that we recomme= nd > against it. If we can do that, then yes, I'm willing to move on. >=20 I also think there's an education problem in the NAT space. Many people I'v= e met start with NAT requirements, then I go through that every interface has mul= tiple=20 addresses, that you can set aside part of the public address space for inte= rnal use to=20 avoid future renumbering and conflicts, that you even have ULAs if really n= eeded. After that we go through NAT's "security" aspects and how we can replicate = those in a firewall.=A0 The "multiple addresses on every interface" is quite ofte= n an eye- opener, something they have totally missed. And something that I keep forge= tting in my daily work sometimes... After that talk there's usually no more discussion of NAT.=20 But of course, if people have used NAT forever and that's part of their TCP= /IP toolset, it's hard to relearn. And they end up requiring NAT all over again= . But in the end, there will always be people strongly requiring NAT. We just= have=20 to live with that.=20 I agree with Owen that should not recommend it at all and spend more time - and documentation - to explain the alternatives. /O _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --1619178251-1000797774-1362581981=:54438 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Which brings the question down to this:
To= what extent do we discourage, but allow, NAT to continue, vs
to what ex= tent do we simply refuse to accomodate it at all?

That is, do we wan= t to insist on our ideal of what a perfect IPv6 network should look like?&n= bsp; Or are we willing to accomodate, to some extent, the real world that m= ost of the people building and maintaining network work in?

Bill Jouris
Inside Products, Inc.
ww= w.insidethestack.com
831-659-8360
925-855-9512 (direct)


--- On Wed, 3/6/13, Olle E. Johansson <oej@edvina.net>= wrote:

From: Olle E. Johansson <= ;oej@edvina.net>
Subject: Re: [v6ops] ULA discussion #1 ULA+NAT
To= : "Owen DeLong" <owen@delong.com>
Cc: v6ops@ietf.org
Date: Wednesday, = March 6, 2013, 3:00 AM


6 mar 2013 kl. 1= 0:59 skrev Owen DeLong <owen@delong.com>:

>
&g= t; On Mar 6, 2013, at 00:49 , Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>
>>> O= n 03/05/2013 02:24 AM, Owen DeLong wrote:
>>>> No, Lorenzo's= (and my) argument is that NAT technologies in IPv6
>>>> are= n't getting wide deployment today (even as a percentage of IPv6
>>= >> deployments) and that there's no reason to expect that trend will<= br>>>>> change. Further, if that trend doesn't change, then it'= s unlikely that
>>>> there will be enough of an installed ba= se to drive development.
>>
>> s/IPv6/IPv4/ and this is somet= hing I might have written in 1994.
>>
>> I'm a well know= n NAT hater and I dislike NPTv6 too, but I think
>> we have to be = realistic. Those who want address isolation *will*
>> deploy NPTv6= . Some will even insist on NAPT66.
>
> I don't doubt this in t= he least.
>
> The important questions are not whether that wil= l happen or not. The
> important questions are:
>
> &nbs= p;   1.    Will enough sites do this to drive ISVs= to support it?
>     2.    What can we= do to reduce the number of sites that hinder
>     &n= bsp;   themselves in this way to help ensure a negative answer to= 1?
>
>> It's perfectly appropriate to describe the ULA+NPT= v6 scenario.
>> We can't recommend it, because NPTv6 is Experimental. Can we move on?
>
> I don't just want to not re= commend it. I want to document that we recommend
> against it. If we = can do that, then yes, I'm willing to move on.
>

I also think= there's an education problem in the NAT space. Many people I've met
sta= rt with NAT requirements, then I go through that every interface has multip= le
addresses, that you can set aside part of the public address space f= or internal use to
avoid future renumbering and conflicts, that you eve= n have ULAs if really needed.
After that we go through NAT's "security" = aspects and how we can replicate those
in a firewall.  The "multipl= e addresses on every interface" is quite often an eye-
opener, something= they have totally missed. And something that I keep forgetting
in my da= ily work sometimes...

After that talk there's usually no more discus= sion of NAT.

But of course, if people have used NAT forever and that's part of their TCP/IP
toolset, it's hard to relearn. And they= end up requiring NAT all over again.

But in the end, there will alw= ays be people strongly requiring NAT. We just have
to live with that. <= br>
I agree with Owen that should not recommend it at all and spend more= time
- and documentation - to explain the alternatives.

/O
__= _____________________________________________
v6ops mailing list
v= 6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--1619178251-1000797774-1362581981=:54438-- From Ted.Lemon@nominum.com Wed Mar 6 07:28:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883A821F8C59 for ; Wed, 6 Mar 2013 07:28:19 -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, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rn7K2UZd9Tss for ; Wed, 6 Mar 2013 07:28:19 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id DF3B021F8C55 for ; Wed, 6 Mar 2013 07:28:18 -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 DSNKUTdgkjVnkLF1dHr+PYzCB6HArbzlkTQA@postini.com; Wed, 06 Mar 2013 07:28: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 8544C1B8142 for ; Wed, 6 Mar 2013 07:28: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 7CE3F190043; Wed, 6 Mar 2013 07:28: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; Wed, 6 Mar 2013 07:28:18 -0800 From: Ted Lemon To: David Farmer Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT Thread-Index: Ac4Y0qVmXOczhdgyTHaW1OIbGrg4zQAVbZqAABAGvAAAAlzXgAAIFLoAAAKCZIAABfkCAAAA0RCAAACcd4AAAOJ/gAAAJRsAAABlxoAAALV/gAADDBMAACbVwgAACCQUAAACcUAAAAIpbgAAB8eKgAABjsKA Date: Wed, 6 Mar 2013 15:28:18 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> <5137561D.5070604@umn.edu> In-Reply-To: <5137561D.5070604@umn.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307474B0CE7mbx01winnominum_" MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 15:28:19 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307474B0CE7mbx01winnominum_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 6, 2013, at 9:43 AM, David Farmer > wrote: My question to Owen and Doug is where do you think this argument is going? = I'm getting sick and tired of hearing this debate on one mailing list or a= nother every 3 to 6 months. You guys are not going to shout the other down= , so stop trying. How do we find useful and practical compromise out of th= is discussion? Compromise isn't really the goal. Rough consensus is the goal. It's per= fectly okay to declare rough consensus when there are a few people arguing = against the consensus. What I would ask you is this: why is it so important to you that there _not= _ be a recommendation against NAT/NPT? I get that you think NAT/NPT will = happen, but that's pure speculation at this point. Are you saying that yo= u _prefer_ NAT/NPT? If so, why? If not, why not write a standard that s= ays what we _want_? What's the downside? To be clear here, I don't mean to ask you to explain to me again about all = the people who don't understand IPv6 and how they will react if they can't = have NAT. I mean to ask you, what _technically_ will go wrong if we recom= mend against NAT/NPT? What is your use case where NAT/NPT is _required_ n= ot by personal preference but because there is no other way to solve the pr= oblem? --_000_8D23D4052ABE7A4490E77B1A012B6307474B0CE7mbx01winnominum_ Content-Type: text/html; charset="us-ascii" Content-ID: <8BC328A750F65B42B2152BDA6768E8AB@nominum.com> Content-Transfer-Encoding: quoted-printable
On Mar 6, 2013, at 9:43 AM, David Farmer <farmer@umn.edu> wrote:
My question to Owen and Doug is where do you think this argument is going? &n= bsp;I'm getting sick and tired of hearing this debate on one mailing list o= r another every 3 to 6 months.  You guys are not going to shout the ot= her down, so stop trying.  How do we find useful and practical compromise out of this discussion?

Compromise isn't really the goal.   Rough consensus is the goal. =   It's perfectly okay to declare rough consensus when there are a few = people arguing against the consensus.

What I would ask you is this: why is it so important to you that there= _not_ be a recommendation against NAT/NPT?   I get that you think NAT= /NPT will happen, but that's pure speculation at this point.   Are you= saying that you _prefer_ NAT/NPT?   If so, why?   If not, why not write a standard that says what we _want_? &nb= sp; What's the downside?

To be clear here, I don't mean to ask you to explain to me again about= all the people who don't understand IPv6 and how they will react if they c= an't have NAT.   I mean to ask you, what _technically_ will go wrong i= f we recommend against NAT/NPT?   What is your use case where NAT/NPT is _required_ not by personal preference bu= t because there is no other way to solve the problem?

--_000_8D23D4052ABE7A4490E77B1A012B6307474B0CE7mbx01winnominum_-- From victor@jvknet.com Wed Mar 6 07:45:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5790F21F8AD1 for ; Wed, 6 Mar 2013 07:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.068 X-Spam-Level: * X-Spam-Status: No, score=1.068 tagged_above=-999 required=5 tests=[AWL=-0.815, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.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 KCzLrFSugDJL for ; Wed, 6 Mar 2013 07:45:44 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9009A21F8AD6 for ; Wed, 6 Mar 2013 07:45:43 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id k10so9460261iea.19 for ; Wed, 06 Mar 2013 07:45:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:user-agent:date:subject:from:to:message-id:thread-topic :in-reply-to:mime-version:content-type:x-gm-message-state; bh=nNKvn3L5hZfl5345SAq7yqdlRYyW5ukPQkjePsZd+h8=; b=o1sSHAQJG3AagD9TzC6OBTLk//k+IPJ5/ge85RTzKCGcxqAHfL4iwRRXz55BCLnlMy iqgjhEQEHRO8otCrgE3x44CjnVDB98lZpBHvBsXKcnU+VsXuZ39T3CLxoshVOW4o/CK4 uYXWoIChOaEBNNHmH9mlszT4TXCHVKajwzMPQRRn6ddtFp5MKPSU39QnKRM52WH9n4GP T0HeCCR/Qhp0s09okfRBiHf093IQ2IWzbUEx4hy4Qgb9aOJou3ad0DGJxmZ4l890QNMf +aHsNllD52DSX0RbF15fMoKPdaX3GqZCUwuZ3mBQpLBUA3W7+zxptmCVVc97pGFPCudJ Ix4A== X-Received: by 10.50.1.198 with SMTP id 6mr10920151igo.0.1362584739135; Wed, 06 Mar 2013 07:45:39 -0800 (PST) Received: from [192.168.100.33] ([67.224.83.162]) by mx.google.com with ESMTPS id g6sm21387177ign.4.2013.03.06.07.45.37 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 06 Mar 2013 07:45:37 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 06 Mar 2013 10:45:35 -0500 From: Victor Kuarsingh To: Message-ID: Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT In-Reply-To: <1362581981.54438.YahooMailClassic@web2805.biz.mail.ne1.yahoo.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3445411537_99710148" X-Gm-Message-State: ALoCoQlI1bqL1PFc+TWZEqllMOoeNMBXCKLh7MvgOOzUjbPW9fBh5osrh5t0ALbUo0zK1s2akEme Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 15:45:45 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3445411537_99710148 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I don't feel very strongly if we do or do not put a recommendation in this document related to NPTv6 or NAT in general. I think it's important that the con's be explained/document or references provided to other documents which outline those cons. I think many NAT supporters (and/or users) are quick to note the benefits (feel dirty using benefits and NAT in the same sentence) without considering the serious drawbacks. I think these drawbacks were highlighted well by folks like Lorenzo and Owen (breaking E2E, cost of development to do NAT work-a-rounds, cost to business to make it work, etc). If we do put a recommendation in, we just need to be consistent as other documents which already discuss NPTv6 and ULA. After that.. I am good. My 0.02. Regards, Victor K From: Bill Jouris Date: Wed, 6 Mar 2013 06:59:41 -0800 (PST) To: "Olle E. Johansson" Cc: Subject: Re: [v6ops] ULA discussion #1 ULA+NAT Which brings the question down to this: To what extent do we discourage, but allow, NAT to continue, vs to what extent do we simply refuse to accomodate it at all? That is, do we want to insist on our ideal of what a perfect IPv6 network should look like? Or are we willing to accomodate, to some extent, the real world that most of the people building and maintaining network work in? Bill Jouris Inside Products, Inc. www.insidethestack.com 831-659-8360 925-855-9512 (direct) --- On Wed, 3/6/13, Olle E. Johansson wrote: > > From: Olle E. Johansson > Subject: Re: [v6ops] ULA discussion #1 ULA+NAT > To: "Owen DeLong" > Cc: v6ops@ietf.org > Date: Wednesday, March 6, 2013, 3:00 AM > > > 6 mar 2013 kl. 10:59 skrev Owen DeLong >: > >> > >> > On Mar 6, 2013, at 00:49 , Brian E Carpenter > > wrote: >> > >>>> >>> On 03/05/2013 02:24 AM, Owen DeLong wrote: >>>>> >>>> No, Lorenzo's (and my) argument is that NAT technologies in IPv6 >>>>> >>>> aren't getting wide deployment today (even as a percentage of IPv6 >>>>> >>>> deployments) and that there's no reason to expect that trend will >>>>> >>>> change. Further, if that trend doesn't change, then it's unlikely that >>>>> >>>> there will be enough of an installed base to drive development. >>> >> >>> >> s/IPv6/IPv4/ and this is something I might have written in 1994. >>> >> >>> >> I'm a well known NAT hater and I dislike NPTv6 too, but I think >>> >> we have to be realistic. Those who want address isolation *will* >>> >> deploy NPTv6. Some will even insist on NAPT66. >> > >> > I don't doubt this in the least. >> > >> > The important questions are not whether that will happen or not. The >> > important questions are: >> > >> > 1. Will enough sites do this to drive ISVs to support it? >> > 2. What can we do to reduce the number of sites that hinder >> > themselves in this way to help ensure a negative answer to 1? >> > >>> >> It's perfectly appropriate to describe the ULA+NPTv6 scenario. >>> >> We can't recommend it, because NPTv6 is Experimental. Can we move on? >> > >> > I don't just want to not recommend it. I want to document that we recommend >> > against it. If we can do that, then yes, I'm willing to move on. >> > > > I also think there's an education problem in the NAT space. Many people I've > met > start with NAT requirements, then I go through that every interface has > multiple > addresses, that you can set aside part of the public address space for > internal use to > avoid future renumbering and conflicts, that you even have ULAs if really > needed. > After that we go through NAT's "security" aspects and how we can replicate > those > in a firewall. The "multiple addresses on every interface" is quite often an > eye- > opener, something they have totally missed. And something that I keep > forgetting > in my daily work sometimes... > > After that talk there's usually no more discussion of NAT. > > But of course, if people have used NAT forever and that's part of their TCP/IP > toolset, it's hard to relearn. And they end up requiring NAT all over again. > > But in the end, there will always be people strongly requiring NAT. We just > have > to live with that. > > I agree with Owen that should not recommend it at all and spend more time > - and documentation - to explain the alternatives. > > /O > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --B_3445411537_99710148 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable

I don't feel very strongly if we do or do not put a recommendation in thi= s document related to NPTv6 or NAT in general.  I think it's important = that the con's be explained/document or references provided to other documen= ts which outline those cons.  I think many NAT supporters (and/or users= ) are quick to note the benefits (feel dirty using benefits and NAT in the s= ame sentence) without considering the serious drawbacks.  I think these= drawbacks were highlighted well by folks like Lorenzo and Owen (breaking E2= E, cost of development to do NAT work-a-rounds, cost to business to make it = work, etc). 

If we do put a recommendation in,= we just need to be consistent as other documents which already discuss NPTv= 6 and ULA. 

After that.. I am good.
=
My 0.02.

Regards,

Victor K


From: Bill Jouris <bill.jouris@insidethestack.com>
Date: Wed, 6 Mar 2013 06:59:41 -0800 (PST)
To: "Olle E. Johansson" <oej@edvina.net>
Cc: <v6ops@ietf.org>
Subject: Re: [v6ops] ULA discussion #1 ULA+NAT

Which brings the question dow= n to this:
To what extent do we discourage, but allow, NAT to continue, v= s
to what extent do we simply refuse to accomodate it at all?

That= is, do we want to insist on our ideal of what a perfect IPv6 network should= look like?  Or are we willing to accomodate, to some extent, the real = world that most of the people building and maintaining network work in?
<= br>Bill Jouris
Inside Products, Inc.=
www.insidethestack.com
831-659-8360
925-855-9512 (direct)


--- On Wed, 3/6/13, Olle E. Johansson <oej@edvina.net> wrote:

From: Olle E. Johansson <oej@edv= ina.net>
Subject: Re: [v6ops] ULA discussion #1 ULA+NAT
To: "Ow= en DeLong" <owen@delong.com>
Cc= : v6ops@ietf.org
Date: Wednesday, Mar= ch 6, 2013, 3:00 AM


6 mar 2013 kl. 10:59 s= krev Owen DeLong <owen@delong.com>:

>
> On Mar 6, 2= 013, at 00:49 , Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
>
>>> On 03/05/2013 02:24 AM, = Owen DeLong wrote:
>>>> No, Lorenzo's (and my) argument is th= at NAT technologies in IPv6
>>>> aren't getting wide deployme= nt today (even as a percentage of IPv6
>>>> deployments) and = that there's no reason to expect that trend will
>>>> change.= Further, if that trend doesn't change, then it's unlikely that
>>&= gt;> there will be enough of an installed base to drive development.
>>
>> s/IPv6/IPv4/ and this is somet= hing I might have written in 1994.
>>
>> I'm a well known= NAT hater and I dislike NPTv6 too, but I think
>> we have to be re= alistic. Those who want address isolation *will*
>> deploy NPTv6. S= ome will even insist on NAPT66.
>
> I don't doubt this in the l= east.
>
> The important questions are not whether that will hap= pen or not. The
> important questions are:
>
>  &nbs= p;  1.    Will enough sites do this to drive ISVs to sup= port it?
>     2.    What can we do to r= educe the number of sites that hinder
>       = ;  themselves in this way to help ensure a negative answer to 1?
>= ;
>> It's perfectly appropriate to describe the ULA+NPTv6 scenario= .
>> We can't recommend it, because NPTv6 is Experimental. Can we move on?
>
> I don't just want to not re= commend it. I want to document that we recommend
> against it. If we c= an do that, then yes, I'm willing to move on.
>

I also think t= here's an education problem in the NAT space. Many people I've met
start = with NAT requirements, then I go through that every interface has multiple <= br>addresses, that you can set aside part of the public address space for in= ternal use to
avoid future renumbering and conflicts, that you even have= ULAs if really needed.
After that we go through NAT's "security" aspects= and how we can replicate those
in a firewall.  The "multiple addres= ses on every interface" is quite often an eye-
opener, something they hav= e totally missed. And something that I keep forgetting
in my daily work s= ometimes...

After that talk there's usually no more discussion of NAT= .

But of course, if people have used NAT forever and that's part of their TCP/IP
toolset, it's hard to relearn. And they= end up requiring NAT all over again.

But in the end, there will alwa= ys be people strongly requiring NAT. We just have
to live with that.
I agree with Owen that should not recommend it at all and spend more ti= me
- and documentation - to explain the alternatives.

/O
______= _________________________________________
v6ops mailing list
v6ops@ietf.or= g
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/= mailman/listinfo/v6ops --B_3445411537_99710148-- From farmer@umn.edu Wed Mar 6 08:54:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2606E21F8494 for ; Wed, 6 Mar 2013 08:54:08 -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_33=0.6, 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 oZha0w3gr6h9 for ; Wed, 6 Mar 2013 08:54:07 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 7742421F83EF for ; Wed, 6 Mar 2013 08:54:07 -0800 (PST) Received: from mail-oa0-f72.google.com (mail-oa0-f72.google.com [209.85.219.72]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Wed, 6 Mar 2013 10:54:01 -0600 (CST) X-Umn-Remote-Mta: [N] mail-oa0-f72.google.com [209.85.219.72] #+LO+TR X-Umn-Classification: local Received: by mail-oa0-f72.google.com with SMTP id j6so50634800oag.11 for ; Wed, 06 Mar 2013 08:54:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=aZ/1OmC+/dNxK/0RcE2jNbfYg9/Phm78UUJmNTM9h6g=; b=J5MLZB162onnrvMvOe9Eo/QnRWjQdu3HmnapnDutvuaZJw7IAOYn84YxruklEY/sUV CzKMhyDVOoIsyweJ7azdjVwrl87gs3l+ZXk/PfOxOT1ISeyqB4XSBPNRmnkyI8c7sVeB XxgT+Xj5s6N9zNUblXlrsCuMunR2DCQxBd5eDfsB3qmWI1QoPEt2tU8lefzptU5E/vPo aauQpvjQEVK8Z86NdD073XOPqwbNffRY0Rrv+V9UpxJp1FQ+R1Y9VxHlIUXV3ykEv3pn wCCwOF1p0btMxyQPCAD+qbh+3jflGUOhZxngJktyMluz+w1v2TLZMEG0Kmlmm7uY7CaP VbhQ== X-Received: by 10.50.192.165 with SMTP id hh5mr11405990igc.89.1362588841431; Wed, 06 Mar 2013 08:54:01 -0800 (PST) X-Received: by 10.50.192.165 with SMTP id hh5mr11405985igc.89.1362588841330; Wed, 06 Mar 2013 08:54:01 -0800 (PST) Received: from x-134-84-88-33.nts.umn.edu ([2607:ea00:101:2001:848f:f786:d824:d801]) by mx.google.com with ESMTPS id ew5sm25121587igc.2.2013.03.06.08.53.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 08:54:00 -0800 (PST) Message-ID: <513774A6.9070508@umn.edu> Date: Wed, 06 Mar 2013 10:53:58 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ted Lemon References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> <5137561D.5070604@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlJYISTgnv9YOIFrLFBOHH05XkmpY1wuS5X3NW89WsWd/+75MzPaG1v3zgVSGLLrVLXPOrxpcapR1AAndz2QINh7rQYpVwxY4vg8qRcwakPX49pjx+DRUmnIFidf49Sk89p918w Cc: "" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 16:54:08 -0000 On 3/6/13 09:28 , Ted Lemon wrote: > On Mar 6, 2013, at 9:43 AM, David Farmer > wrote: >> My question to Owen and Doug is where do you think this argument is >> going? I'm getting sick and tired of hearing this debate on one >> mailing list or another every 3 to 6 months. You guys are not going >> to shout the other down, so stop trying. How do we find useful and >> practical compromise out of this discussion? > > Compromise isn't really the goal. Rough consensus is the goal. It's > perfectly okay to declare rough consensus when there are a few people > arguing against the consensus. Yes, rough consensus is the goal, but I believe some amount of compromise is usually necessary to reach rough consensus. And, if we really had rough consensus on this issue and there were only a few people arguing against it; I doubt we would be seeing this argument pop up on so many different mailing list so frequently. > What I would ask you is this: why is it so important to you that there > _not_ be a recommendation against NAT/NPT? I get that you think > NAT/NPT will happen, but that's pure speculation at this point. Are > you saying that you _prefer_ NAT/NPT? If so, why? If not, why not > write a standard that says what we _want_? What's the downside? > > To be clear here, I don't mean to ask you to explain to me again about > all the people who don't understand IPv6 and how they will react if they > can't have NAT. I mean to ask you, what _technically_ will go wrong if > we recommend against NAT/NPT? What is your use case where NAT/NPT is > _required_ not by personal preference but because there is no other way > to solve the problem? These are good questions. This document is not about NPT or NAT it is about ULA and how it should be used. That said, I don't think you can fully discuss ULA without at least talking about its use in NPT, its in RFC 6296 (NPTv6) after all. But, the current draft is not recommend ULA for NPT it is only recognized as valid, but not recommended, use case for ULA. RFC 6296 (NPTv6) makes it perfectly clear NAT is not recommended by the IETF, and this draft references it. As NPT is not the primary subject of the draft and only discussion of NPT in the context of analyzing the use cases of ULA, and it not even a recommended use of ULA use case by the draft. As such adding an explicit recommendation against the use of NAT seems irrelevant and a distraction to the primary discussion and the real subject of the draft. It seems only about NAT haters piling on and insisting "NAT is EVIL" be included any time NAT is even talked about. As I said before, if the draft were to recommend the use of ULA with NPTv6 then it would be necessary to make it clear that its actually not recommending NAT but only the use of ULA with NPTv6 when it is used. But this is necessary and valid, if and only if the draft were recommending the use of ULA with NPTv6, which it is not. So, you asked whats the harm here? Well a necessary discussion of the proper uses of ULA is being completely overshadowed by a relatively minor but valid part of the discussion, NPT. If we want to have another "no holds barred" discussion of NAT fine, but that's not this draft and we need to stop trying to turn it into that. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From Ted.Lemon@nominum.com Wed Mar 6 09:01:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F91721F89C0 for ; Wed, 6 Mar 2013 09:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.261 X-Spam-Level: X-Spam-Status: No, score=-106.261 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlh53BtTYWFp for ; Wed, 6 Mar 2013 09:01:28 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8A80921F8C3E for ; Wed, 6 Mar 2013 09:01:28 -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 DSNKUTd2aI3ETJFT/iYfZrd0r7V57y28HNzA@postini.com; Wed, 06 Mar 2013 09:01:28 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 4A2D11B8164 for ; Wed, 6 Mar 2013 09:01:28 -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 411BC190043; Wed, 6 Mar 2013 09:01:28 -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, 6 Mar 2013 09:01:22 -0800 From: Ted Lemon To: David Farmer Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT Thread-Index: Ac4Y0qVmXOczhdgyTHaW1OIbGrg4zQAVbZqAABAGvAAAAlzXgAAIFLoAAAKCZIAABfkCAAAA0RCAAACcd4AAAOJ/gAAAJRsAAABlxoAAALV/gAADDBMAACbVwgAACCQUAAACcUAAAAIpbgAAB8eKgAABjsKAAAL+EQAAAEIDgA== Date: Wed, 6 Mar 2013 17:01:22 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474B106A@mbx-01.win.nominum.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> <5137561D.5070604@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> <513774A6.9070508@umn.edu> In-Reply-To: <513774A6.9070508@umn.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307474B106Ambx01winnominum_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:01:29 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307474B106Ambx01winnominum_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Mar 6, 2013, at 11:53 AM, David Farmer > wrote: So, you asked whats the harm here? Well a necessary discussion of the prop= er uses of ULA is being completely overshadowed by a relatively minor but v= alid part of the discussion, NPT. No, I asked you what the use case is that _requires_ NPT/NAT. If there is= no such use case, then we can logically conclude that there is no harm in = recommending against NPT/NAT. So if you can't come up with a use case, wh= y are we arguing about this? --_000_8D23D4052ABE7A4490E77B1A012B6307474B106Ambx01winnominum_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <791ACFF0DBD9E841983CA7D3C55E8F54@nominum.com> Content-Transfer-Encoding: quoted-printable
On Mar 6, 2013, at 11:53 AM, David Farmer <farmer@umn.edu> wrote:
So, you asked whats the harm here?  Well a necessary discussion of the pr= oper uses of ULA is being completely overshadowed by a relatively minor but= valid part of the discussion, NPT.

No, I asked you what the use case is that _requires_ NPT/NAT.   I= f there is no such use case, then we can logically conclude that there is n= o harm in recommending against NPT/NAT.   So if you can't come up with= a use case, why are we arguing about this?

--_000_8D23D4052ABE7A4490E77B1A012B6307474B106Ambx01winnominum_-- From stefan.marksteiner@joanneum.at Wed Mar 6 09:02:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6684111E8145 for ; Wed, 6 Mar 2013 09:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.83 X-Spam-Level: X-Spam-Status: No, score=-0.83 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 FG6ZET+4jccT for ; Wed, 6 Mar 2013 09:02:43 -0800 (PST) Received: from rzjgate.joanneum.ac.at (rzjgate.joanneum.ac.at [143.224.185.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9AA21F8C93 for ; Wed, 6 Mar 2013 09:02:42 -0800 (PST) Received: from RZJS078.jr1.local (rzjs078.joanneum.ac.at [143.224.71.19]) by rzjgate.joanneum.ac.at (8.13.8/8.13.8) with ESMTP id r26H2XgK023330; Wed, 6 Mar 2013 18:02:33 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joanneum.at; s=sel3; t=1362589354; bh=GG2uXDbLW2TwAG8CvDeTI+h9wQaknS1zqLLMb+VriAU=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ocMprWQZr84/rBtcrZd0tvsv0Kcm7ZLkXly4U31W/Fdr7v/Vo8CHuZJl5In8qTtYN SXx3sOQ0RUaEpkHMgQmuXkCRPqruKz6nqtmr6lFVsCgnnV1DdhOvTF3wbMDLw8GZdm Sq3Y0fDE+mP5fcbQKr3P7C3+WZOEniQxd/h5LkmQ= Received: from RZJC1EX.jr1.local ([169.254.2.69]) by RZJS078.jr1.local ([143.224.71.19]) with mapi; Wed, 6 Mar 2013 18:02:32 +0100 From: "Marksteiner, Stefan" To: "'Owen DeLong'" , "'Victor Kuarsingh'" Date: Wed, 6 Mar 2013 18:02:31 +0100 Thread-Topic: [v6ops] ULA Usage Guide draft requesting for review Thread-Index: Ac4aCCeM3Qr8/nCRQa6ixU1hLrNfPgAf/sag Message-ID: <8A317FD8C00FEE448E52D4EE5B56BB3E02513FBE2356@RZJC1EX.jr1.local> References: <8A317FD8C00FEE448E52D4EE5B56BB3E02513FBE2301@RZJC1EX.jr1.local> <3AC1A1D6-6ED1-4A3E-BE7A-AE5306A3E6CC@delong.com> <8A317FD8C00FEE448E52D4EE5B56BB3E02513FBE2324@RZJC1EX.jr1.local> In-Reply-To: Accept-Language: de-DE, de-AT Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, de-AT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'v6ops@ietf.org'" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:02:47 -0000 Hi, firstly I want to recall, that I don't want to replace any security measure= whatsoever by private addressing (as the trust argument below might sugges= t), but only to use it additionally to use it as a (yes, very thin) "coatin= g on the armor", whereas a botched firewall rule might be the "rust" agains= t which it is protecting (and yes again, protecting is a strong word for th= at) . Of course it could be circumvented, it just wanted to say that if yo= u deploy security techniques at perimeter and LAN-level, it might be a good= idea to do something on an organizational or network design level as well.= IMHO, every layer of protection, as thin as it might be, helps. That being said, I must state that I'm not so afraid of giving a false sens= e of security by using ULAs. People who are tricked to thinking they are sa= fe this way are the same people who think security is done by installing a = firewall, you can't help them anyway. Generating awareness is (and always w= as) the most crucial thing when it comes to security - but this shouldn't a= ffect the fact that every tiny step towards a more secure network might act= ually help (even if it's only to back up little flaws), the more as it is a= step that doesn't cost anything (which is always the strongest enemy of se= curity).=20 I'm of course totally with you in terms of nobody should RELY on methods wh= ich were never intended to be security features. Cheers, Stefan > -----Urspr=FCngliche Nachricht----- > Von: Owen DeLong [mailto:owen@delong.com] > Gesendet: Mittwoch, 06. M=E4rz 2013 02:12 > An: Marksteiner, Stefan > Cc: 'v6ops@ietf.org' > Betreff: Re: [v6ops] ULA Usage Guide draft requesting for review >=20 >=20 > On Mar 5, 2013, at 6:40 AM, "Marksteiner, Stefan" > wrote: >=20 > > Hi, > > > >> On Mar 1, 2013, at 01:35 , "Marksteiner, Stefan" > wrote: > >> > >>> Hi, > >>> > >>> Section 2.2.2.1 follows the principle "internal addresses for interna= l > communication". As they are (per default) not advertised, they may preven= t > that internal services become publically available by misconfigurations. > Additionally, by their distinctive prefix, they are easier to recognize (= for > operator eyes) and thus may be easier to troubleshoot in firewalling rule= s > and network sniffers (if, for instance, a service is mistakenly opened t= o the > outside). > >> > >> > >> I'm not sure what you mean by "As they are (per default) not > advertised..." > >> > >> There is no special treatment of ULA in routers. No prefix is advertis= ed in > BGP by default. ULA or GUA. > >> In other protocols, ULA is advertised with the same defaults as GUA. > >> > >> If I have a local convention that says 2001:123::/32 is my publicly re= achable > space and 2620:4:104::/48 shouldn't be advertised, it's every bit as > recognizable as ULA to the operators that work for me. > >> > > > > > > What I've meant was just that your provider will propagate your GUA > ranges (or, more precisely, the shorter prefixes that contain these range= s). > This is not (or should not be) the case for ULA address ranges, so they w= on't > be reachable from the Internet even if you screw up your security > configuration (ULAs of course replace, to which I totally agree, by no me= ans > any security mechanism - I just think of it as an additional "insurance = against > mishaps"). >=20 > Unless of course the attacker finds a way to send a directed packet to a > router or other device that has both our ULA and GUA through other means > (such as hiding it in a Teredo payload, delivering it to a 6to4 gateway r= unning > on someone's laptop, passing it through your stateless NPT, etc.) >=20 > Given the myriad ways in which this particular form of phalanx looks more > like swiss cheese, I think that the illusion of default security is usual= ly more > damaging to security than the thin veil of potential additional protectio= n it > might provide under idealized circumstances. Indeed, in my experience, > environments that depend on "unreachable addressing" as part of their > "defense in depth" tend to be less vigilant about their other security > measures and are more likely to "screw up their security configuration". >=20 > > As for the recognition, you're probably right. The only one for whom UL= As > are maybe easier to recognize will be a new guy in an operator team. >=20 > Maybe for a week or so. >=20 > > Besides of whether ULAs are useful for this purpose or not, do you thin= k > there are any negative impacts of using ULAs for addressing internal > machines (strictly internal - who are never ever to be reached from the > outside, that is). >=20 > Several. First, forever is a very long time, especially on the internet. > Thousands of things we swore just 10 years ago would never remotely > consider being attached to the internet are today (whether we realize it = or > not). I know of at least one large federal agency responsible for quite = a few > medical patients that wants to put implanted medical devices in their > patients on the IPv6 internet. (Yes, they do seem to be approaching this = with > due regard for the security considerations, but when they were planning t= o > do this with a "private network with air gap" (which wasn't), they were > largely ignoring this.). >=20 > As such, it will make things more difficult and likely less secure when t= hese > things are eventually put on the internet or start talking to systems tha= t talk > to the internet. >=20 > Remember, if A trusts B and B trusts C, then A trusts C whether A knows i= t or > not. >=20 > If your ULA host trusts a host B that has both ULA and GUA and B trusts > {whatever nightmare works for you}, then, your ULA host isn't as isolated= as > you assumed it was and the distinction between ULA and GUA just became > virtually meaningless. However, in your mind and the minds of most of you= r > administrators, it's still an isolated system not attached to the interne= t with > all the assumptions that implies. >=20 > OTOH, if it has a GUA prefix, then the second it starts talking to someth= ing > else that _IS_ on the internet, everyone readily recognizes the risks for= what > they are. >=20 > This, among other reasons, is why I say that ULA, RFC-1918, NAT not only= do > not enhance security, they are actually detrimental because of the human > factors paradigm shift and shifting assumptions that come with them. >=20 > >>> Sincerely, > >>> > >>> Stefan > >>> > >>> P.S.: Even there is a wide consensus that ULAs (or RFC1918-addresses = in > v4), I personally would broaden the suggestion in 2.2.2.1 to internal > infrastructure devices and services for the reasons stated above. If the > internal services don't have to be routed (or reside in an extra vlan), = I'd don't > number them with GUAs at all and just use their LLAs, which spares a litt= le bit > of numbering efforts. > >> > >> > >> Your DNS must be fun and you've rendered them unreachable to other > internal hosts that are not on the same subnet. > > > > > > I thought about SMB companies, which are too small for sensible net > segmentation, so they can use LLAs the exact same way as ULAs (except for > the fact that they are mandatory according to RFC4291 and its predecessor= s) > or reside in an extra VLAN, in which case they will be orphaned on purpos= e - I > think of a completely isolated management VLAN for infrastructure devices > such as switches, etc. As for the DNS, we have an external and an intern= al > zone, whereas the latter of which is the natural home of the (of course n= on- > autoconfig) LLA-IIDs. >=20 > I don't know what too small for sensible net segmentation would be. Most = of > my SMB clients have wanted to be able to have a Wifi network that visitor= s > can use, a wired network for employees and internal systems, and a Wifi > network for employees. That's three sensible network segments I've > implemented in organizations as small as 3 people, 1 cash register and 1 > server (plus other more transient devices, mostly in the BYOD category). >=20 > It's hard for me to imagine an SMB much smaller than that unless you go t= o > my one-man consulting firm, but the network there is actually quite a bit > more complex and has 5 or more segments, depending on the day. >=20 >=20 > Owen >=20 From bill.jouris@insidethestack.com Wed Mar 6 09:18:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C0821F8AC3 for ; Wed, 6 Mar 2013 09:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6] 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 bDOYBy8tbEfy for ; Wed, 6 Mar 2013 09:18:04 -0800 (PST) Received: from nm19.access.bullet.mail.sp2.yahoo.com (nm19.access.bullet.mail.sp2.yahoo.com [98.139.44.146]) by ietfa.amsl.com (Postfix) with ESMTP id 92D1321F8C45 for ; Wed, 6 Mar 2013 09:18:04 -0800 (PST) Received: from [98.139.44.103] by nm19.access.bullet.mail.sp2.yahoo.com with NNFMP; 06 Mar 2013 17:18:04 -0000 Received: from [98.139.44.88] by tm8.access.bullet.mail.sp2.yahoo.com with NNFMP; 06 Mar 2013 17:18:04 -0000 Received: from [127.0.0.1] by omp1025.access.mail.sp2.yahoo.com with NNFMP; 06 Mar 2013 17:18:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 509390.46661.bm@omp1025.access.mail.sp2.yahoo.com Received: (qmail 63709 invoked by uid 60001); 6 Mar 2013 17:18:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362590284; bh=Q1q37gWBEaMYNzdwdei5HmH1TB0ZiA8yWwOC9cr9Q5w=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=SVa5ZSIG0CVmJUR6Rq6BQqFI2rTCq2ShXaom8vwuA9PLvfF1Qcujgnxh1T4SHiaJ9LMDpIs3uWylCsJmEsJCqgQmXssMryANTD87m5X0D67H+v4dQEFJgZ4V4i04kcJT2AFO+/hJuEEl8bauX/d/cGCk1v1Jse3awH/azBfNU4k= X-YMail-OSG: dX5GDlMVM1nRBCmyDD0ZCPRjlP_eCEPoePzVtDP37ujk7Rk yA02ouQZqw4VFy6KVeISRYwARiwyo0s.oOqjsJWQDon7ygjAlwNLz7nnxT0w 192qpUpe5Kr9ngY6eF2zB1LRxyEexiTxcBalIBrQny1dWYPVhUdntS9R8S3F cGV4E45WmWTE05TTFwbsfoCi2P7GMmHmbH6_h9Pea51xvDQriGEOPbJM8Mt7 0oGsEzGGgCoebRCvo.rEQTg7HeEa3eaJpuYbxj1L6JLjpGCSZUL7cTNNnrA6 eEkWl0w1Y8Eu0l.7zLnJX8zswcRl1BNEQmafITa4jJtEbNV2xb6SNN0G92lC Pl_FRhh5IrqfIS7rtoRv5KSgWBsNeG5Rcv8a8cN28UkabdNyLUebFr629AtV 7Wms_gkDKim3gCwK5AxbHukcUP8alCMEeheABAf8q7zjMFK5vMrIzgs1fVkk 9FHL2j_z3_1JBqKZWlplsyQP49sOtDNeMyHN4351ed6e2Y6u5EQRx_88wwqx WpjUb5udkX4F2Ch.XyPKlvBIkannWNl7mfGmMIJQvruLsjCes2ME1UnKY6K1 Wbp7jwbeBs0fYBIxGA62jWicNOIbd2oED5hTEENA- Received: from [50.148.178.232] by web2801.biz.mail.ne1.yahoo.com via HTTP; Wed, 06 Mar 2013 09:18:03 PST X-Rocket-MIMEInfo: 001.001, UHV0dGluZyBpbiB0aGUgY29ucyBvZiBhbnl0aGluZyB0aGF0IHdlIGFyZSBub3QgbWFuZGF0aW5nIGlzIGEgZ29vZCBpZGVhLsKgIEFuZCBpZiB3ZSBhcmUgZ29pbmcgdG8gZGVjaWRlIHRvIGRpc2NvdXJhZ2Ugc29tZXRoaW5nICh3aGljaCBsb29rcyBsaWtlIHdoZXJlIHdlIG1heSBiZSBoZWFkaW5nIG9uIHRoaXMpLCBwdXR0aW5nIGluIHRoZSByZWFzb25zIHdoeSBub3QgdG8gZG8gaXQgaXMgZXNzZW50aWFsLsKgIChOb3QgbGVhc3QgdG8gYXZvaWQgaW4gdGhlIGZ1dHVyZSBzb21lIG9mIHRoZSBraW5kcyABMAEBAQE- X-Mailer: YahooMailClassic/15.1.4 YahooMailWebService/0.8.135.514 Message-ID: <1362590283.61406.YahooMailClassic@web2801.biz.mail.ne1.yahoo.com> Date: Wed, 6 Mar 2013 09:18:03 -0800 (PST) From: Bill Jouris To: v6ops@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="36908767-2121298680-1362590283=:61406" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:18:08 -0000 --36908767-2121298680-1362590283=:61406 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Putting in the cons of anything that we are not mandating is a good idea.= =A0 And if we are going to decide to discourage something (which looks like= where we may be heading on this), putting in the reasons why not to do it = is essential.=A0 (Not least to avoid in the future some of the kinds of dis= cussion we have had here lately about why certain decisions were take in th= e past.) Bill Jouris Inside Products, Inc. www.insidethestack.com 831-659-8360 925-855-9512 (direct) --- On Wed, 3/6/13, Victor Kuarsingh wrote: From: Victor Kuarsingh Subject: Re: [v6ops] ULA discussion #1 ULA+NAT To: v6ops@ietf.org Date: Wednesday, March 6, 2013, 7:45 AM I don't feel very strongly if we do or do not put a recommendation in this = document related to NPTv6 or NAT in general. =A0I think it's important that= the con's be explained/document or references provided to other documents = which outline those cons. =A0I think many NAT supporters (and/or users) are= quick to note the benefits (feel dirty using benefits and NAT in the same = sentence) without considering the serious drawbacks. =A0I think these drawb= acks were highlighted well by folks like Lorenzo and Owen (breaking E2E, co= st of development to do NAT work-a-rounds, cost to business to make it work= , etc).=A0 If we do put a recommendation in, we just need to be consistent as other do= cuments which already discuss NPTv6 and ULA.=A0 After that.. I am good. My 0.02. Regards, Victor K From: Bill Jouris Date: Wed, 6 Mar 2013 06:59:41 -0800 (PST) To: "Olle E. Johansson" Cc: Subject: Re: [v6ops] ULA discussion #1 ULA+NAT Which brings the question down to this: To what extent do we discourage, but allow, NAT to continue, vs to what extent do we simply refuse to accomodate it at all? That is, do we want to insist on our ideal of what a perfect IPv6 network s= hould look like?=A0 Or are we willing to accomodate, to some extent, the re= al world that most of the people building and maintaining network work in? Bill Jouris Inside Products, Inc. www.insidethestack.com 831-659-8360 925-855-9512 (direct) --- On Wed, 3/6/13, Olle E. Johansson wrote: From: Olle E. Johansson Subject: Re: [v6ops] ULA discussion #1 ULA+NAT To: "Owen=0A DeLong" Cc: v6ops@ietf.org Date: Wednesday, March 6, 2013, 3:00 AM 6 mar 2013 kl. 10:59 skrev Owen DeLong : >=20 > On Mar 6, 2013, at 00:49 , Brian E Carpenter wrote: >=20 >>> On 03/05/2013 02:24 AM, Owen DeLong wrote: >>>> No, Lorenzo's (and my) argument is that NAT technologies in IPv6 >>>> aren't getting wide deployment today (even as a percentage of IPv6 >>>> deployments) and that there's no reason to expect that trend will >>>> change. Further, if that trend doesn't change, then it's unlikely that >>>> there will be enough of an installed base to=0A drive development. >>=20 >> s/IPv6/IPv4/ and this is something I might have written in 1994. >>=20 >> I'm a well known NAT hater and I dislike NPTv6 too, but I think >> we have to be realistic. Those who want address isolation *will* >> deploy NPTv6. Some will even insist on NAPT66. >=20 > I don't doubt this in the least. >=20 > The important questions are not whether that will happen or not. The > important questions are: >=20 > =A0=A0=A0 1.=A0=A0=A0 Will enough sites do this to drive ISVs to support = it? > =A0=A0=A0 2.=A0=A0=A0 What can we do to reduce the number of sites that h= inder > =A0=A0=A0 =A0=A0=A0 themselves in this way to help ensure a negative answ= er to 1? >=20 >> It's perfectly appropriate to describe the ULA+NPTv6 scenario. >> We can't recommend it, because NPTv6 is=0A Experimental. Can we move on? >=20 > I don't just want to not recommend it. I want to document that we recomme= nd > against it. If we can do that, then yes, I'm willing to move on. >=20 I also think there's an education problem in the NAT space. Many people I'v= e met start with NAT requirements, then I go through that every interface has mul= tiple=20 addresses, that you can set aside part of the public address space for inte= rnal use to=20 avoid future renumbering and conflicts, that you even have ULAs if really n= eeded. After that we go through NAT's "security" aspects and how we can replicate = those in a firewall.=A0 The "multiple addresses on every interface" is quite ofte= n an eye- opener, something they have totally missed. And something that I keep forge= tting in my daily work sometimes... After that talk there's usually no more discussion of NAT.=20 But of course, if people have used NAT forever=0A and that's part of their = TCP/IP toolset, it's hard to relearn. And they end up requiring NAT all over again= . But in the end, there will always be people strongly requiring NAT. We just= have=20 to live with that.=20 I agree with Owen that should not recommend it at all and spend more time - and documentation - to explain the alternatives. /O _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________=0Av6ops mailing list=0Av6op= s@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/v6ops=0A=0A -----Inline Attachment Follows----- _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --36908767-2121298680-1362590283=:61406 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Putting in the cons of anything that we are n= ot mandating is a good idea.  And if we are going to decide to discour= age something (which looks like where we may be heading on this), putting i= n the reasons why not to do it is essential.  (Not least to avoid in t= he future some of the kinds of discussion we have had here lately about why= certain decisions were take in the past.)

Bill Jou= ris
Inside Products, Inc.
www.insidethestack.= com
831-659-8360
925-855-9512 (direct)

--- On Wed, 3= /6/13, Victor Kuarsingh <victor@jvknet.com> wrote:

From: Victor Kuarsingh <victor@jvknet.com>Subject: Re: [v6ops] ULA discussion #1 ULA+NAT
To: v6ops@ietf.org
D= ate: Wednesday, March 6, 2013, 7:45 AM


I don't feel very strongly if we do or do = not put a recommendation in this document related to NPTv6 or NAT in genera= l.  I think it's important that the con's be explained/document or ref= erences provided to other documents which outline those cons.  I think= many NAT supporters (and/or users) are quick to note the benefits (feel di= rty using benefits and NAT in the same sentence) without considering the se= rious drawbacks.  I think these drawbacks were highlighted well by fol= ks like Lorenzo and Owen (breaking E2E, cost of development to do NAT work-= a-rounds, cost to business to make it work, etc). 

If we do put a recommendation in, we just need to be consistent as ot= her documents which already discuss NPTv6 and ULA. 

After that.. I am good.

My 0.02.

Regards,

Victor K<= /div>


F= rom: Bill Jouris <bill.jouris@insidethestack.com>
Date: Wed, 6 Mar 2013 06:59:41 -0800 (PST)=
To: "Olle E. Johansson" <<= a rel=3D"nofollow" ymailto=3D"mailto:oej@edvina.net" target=3D"_blank" href= =3D"/mc/compose?to=3Doej@edvina.net">oej@edvina.net>
Cc: <v6ops@ietf.org>=
Subject: Re: [v6ops] ULA disc= ussion #1 ULA+NAT

Which brings the question down to this:
To what extent do we discour= age, but allow, NAT to continue, vs
to what extent do we simply refuse t= o accomodate it at all?

That is, do we want to insist on our ideal o= f what a perfect IPv6 network should look like?  Or are we willing to = accomodate, to some extent, the real world that most of the people building= and maintaining network work in?

Bill Jouris
Inside Products, Inc.
www.insidethestack.com
83= 1-659-8360
925-855-9512 (direct)



--- On Wed, 3/= 6/13, Olle E. Johansson <oej@edvina.net> wrote:

From: Olle E. Johansson <oej@edvina.net>
Subject: Re: [v6ops] U= LA discussion #1 ULA+NAT
To: "Owen=0A DeLong" <owen@delong.com>
Cc: v6ops@ietf.org
Date: Wednesday, March 6, 2013, 3:00 AM=


6 mar 2013 kl. 10:59 skrev= Owen DeLong <owen@delong.com>:

> <= br>> On Mar 6, 2013, at 00:49 , Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>
>>> On 03= /05/2013 02:24 AM, Owen DeLong wrote:
>>>> No, Lorenzo's (an= d my) argument is that NAT technologies in IPv6
>>>> aren't = getting wide deployment today (even as a percentage of IPv6
>>>= > deployments) and that there's no reason to expect that trend will
&= gt;>>> change. Further, if that trend doesn't change, then it's unlikely that
>>>> there will be enough o= f an installed base to=0A drive development.
>>
>> s/IPv= 6/IPv4/ and this is something I might have written in 1994.
>> >> I'm a well known NAT hater and I dislike NPTv6 too, but I think>> we have to be realistic. Those who want address isolation *will*=
>> deploy NPTv6. Some will even insist on NAPT66.
>
>= ; I don't doubt this in the least.
>
> The important questions= are not whether that will happen or not. The
> important questions a= re:
>
>     1.    Will enough si= tes do this to drive ISVs to support it?
>     2. = ;   What can we do to reduce the number of sites that hinder
&= gt;         themselves in this way to help en= sure a negative answer to 1?
>
>> It's perfectly appropriat= e to describe the ULA+NPTv6 scenario.
>> We can't recommend it, be= cause NPTv6 is=0A Experimental. Can we move on?
>
> I don't ju= st want to not recommend it. I want to document that we recommend
> a= gainst it. If we can do that, then yes, I'm willing to move on.
>
I also think there's an education problem in the NAT space. Many peopl= e I've met
start with NAT requirements, then I go through that every int= erface has multiple
addresses, that you can set aside part of the publi= c address space for internal use to
avoid future renumbering and confli= cts, that you even have ULAs if really needed.
After that we go through = NAT's "security" aspects and how we can replicate those
in a firewall.&n= bsp; The "multiple addresses on every interface" is quite often an eye-
= opener, something they have totally missed. And something that I keep forge= tting
in my daily work sometimes...

After that talk there's usual= ly no more discussion of NAT.

But of course, if people have used NA= T forever=0A and that's part of their TCP/IP
toolset, it's hard to relea= rn. And they end up requiring NAT all over again.

But in the end, th= ere will always be people strongly requiring NAT. We just have
to live = with that.

I agree with Owen that should not recommend it at all an= d spend more time
- and documentation - to explain the alternatives.
=
/O
_______________________________________________
v6ops mailing = list
v6ops@ietf.org
https://w= ww.ietf.org/mailman/listinfo/v6ops
_______________________________________________=0Av6ops mailing= list=0Av6ops@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/v6ops=0A
= =0A

-----Inline Attachment Follows-----

_______________________________________________
v6ops mailing list=
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops=
--36908767-2121298680-1362590283=:61406-- From bill.jouris@insidethestack.com Wed Mar 6 09:33:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11EA1F041A for ; Wed, 6 Mar 2013 09:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6] 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 mXpoK3Bnh6cT for ; Wed, 6 Mar 2013 09:33:10 -0800 (PST) Received: from nm26.access.bullet.mail.mud.yahoo.com (nm26.access.bullet.mail.mud.yahoo.com [66.94.237.91]) by ietfa.amsl.com (Postfix) with ESMTP id 62A7C21F8AF0 for ; Wed, 6 Mar 2013 09:33:07 -0800 (PST) Received: from [66.94.237.127] by nm26.access.bullet.mail.mud.yahoo.com with NNFMP; 06 Mar 2013 17:33:07 -0000 Received: from [66.94.237.111] by tm2.access.bullet.mail.mud.yahoo.com with NNFMP; 06 Mar 2013 17:33:07 -0000 Received: from [127.0.0.1] by omp1016.access.mail.mud.yahoo.com with NNFMP; 06 Mar 2013 17:33:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 73221.75600.bm@omp1016.access.mail.mud.yahoo.com Received: (qmail 21495 invoked by uid 60001); 6 Mar 2013 17:33:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362591186; bh=JXLGZiGUcmx/9PW3NMC9BTtJECKjHlj+1fn71MdWZ9g=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=memc+zPcVMoYw3SeBhUco0YqziuP/1Hdj1Ir2X5ogTUHCEK0zKcv61a0Nvnn7kcpBo8v5/AjTw0wgdc7e9lf6l38vSpJjd+OQJ74Prjg5uaSE+uFUP8W7JivN9qd5Orc9UuzwAIswtYbxzGfGXj8fkrxEOl98l0GGCYpBteRAtc= X-YMail-OSG: wGNGkicVM1kErYx9k3zGKW098HHaHvSSecOK1iP.kmA4UHW in9ffebNK7mY6WOYGhhl3swxxx1vOk7dArJQ4Kf.jwhK6TwRXZYrRgtSxxvA 3iUjS5KsSif6U7D1Dx7azVGpxiVt7rFsVg1iPrTyGgQw0b9_FYrcFvTiwdiv vJ5tak7EWGRJI98.SgSYoFIMGQh4bqLh5n_8.S1tdWdV7R1pgoK1p6Z_IqDl RUeas2najj4KLF020ix5telXDGtTMITuSqFoqnouWYLx.yUIsEUvFiGGhtZI Z4HK.8cKSpblR5jVuWUe8xLI6GeBwT.0kbiC1FeGj1RSe97AVj3CnTIK3NRq akMry_IFZN_ACY51hGuDQZCZvGiLB74yPxuhCYDXy1b3oMMFTRqQBzqpCj7I 1QBQzqCSHzh.Nr5dqxQmPb7wNpLvhaewr34vnbxIwuaiYyqOQd3Z.6CLRcDo BFMH9Znc08WPYc.Hxlbq4X.UeRosiXFfFQLX5193CteJ0M2BVawl1C5t05qm yK_24M_UaXQIVoPKSccpUMPPW4hg0B6yh6NPgCUVcDgaJgMzW2kWi6nsqqPj 4iFp42awD5q5t8.f_EvXUVMBTeZVSxSU- Received: from [50.148.178.232] by web2803.biz.mail.ne1.yahoo.com via HTTP; Wed, 06 Mar 2013 09:33:06 PST X-Rocket-MIMEInfo: 001.001, QWN0dWFsbHksIG5vLsKgIFRoZSBmYWN0IHRoYXQgc28gbWFueSBJUHY2IGRlcGxveW1lbnRzIGN1cnJlbnRseSBleGlzdCBqdXN0IGZpbmUgd2l0aG91dCBOQVQgaXMgb25seSBhIGRlbW9uc3RyYXRpb24gdGhhdCB0aG9zZSB3aG8gY2FuIGRlcGxveSB3aXRob3V0IE5BVCBoYXZlIGJlZW4gZG9pbmcgc28uwqAgQWZ0ZXIgYWxsLCBpZiBzb21lb25lIGNhbm5vdCBkZXBsb3kgd2l0aG91dCBOQVQgKG9yIGV2ZW4ganVzdCBoYXMgcmVhc29uIHRvIHRoaW5rIHRoYXQgdGhleSBuZWVkIGl0KSwgdGhleSB3b3VsZCABMAEBAQE- X-Mailer: YahooMailClassic/15.1.4 YahooMailWebService/0.8.135.514 Message-ID: <1362591185.19912.YahooMailClassic@web2803.biz.mail.ne1.yahoo.com> Date: Wed, 6 Mar 2013 09:33:05 -0800 (PST) From: Bill Jouris To: v6ops@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-410334529-1362591186=:19912" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:33:14 -0000 ---1551098171-410334529-1362591186=:19912 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Actually, no.=A0 The fact that so many IPv6 deployments currently exist jus= t fine without NAT is only a demonstration that those who can deploy withou= t NAT have been doing so.=A0 After all, if someone cannot deploy without NA= T (or even just has reason to think that they need it), they would obviousl= y not be among those who have deployed so far. Not to say that NAT is really necessary every place that thinks that they n= eed it.=A0 Just that we do not yet have empirical proof that they are wrong= . Bill Jouris Inside Products, Inc. www.insidethestack.com 831-659-8360 925-855-9512 (direct) --- On Tue, 3/5/13, Owen DeLong wrote: From: Owen DeLong Subject: Re: [v6ops] ULA discussion #1 ULA+NAT To: "Doug Barton" Cc: v6ops@ietf.org Date: Tuesday, March 5, 2013, 9:18 PM ... The fact that so many IPv6 deployments exist just fine in the real world wi= thout "NAT-alikes" is proof that IPv6 can be deployed just fine without NAT= . ... Owen _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ---1551098171-410334529-1362591186=:19912 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Actually, no.  The fact that so many IPv= 6 deployments currently exist just fine without NAT is only a demonstration= that those who can deploy without NAT have been doing so.  After all,= if someone cannot deploy without NAT (or even just has reason to think tha= t they need it), they would obviously not be among those who have deployed = so far.

Not to say that NAT is really necessary every place that thi= nks that they need it.  Just that we do not yet have empirical proof t= hat they are wrong.

Bill Jouris
Inside Products, Inc.
www.insidethestack.com
831-659-8360
= 925-855-9512 (direct)


--- On Tue, 3/5/13, Owen DeLong = <owen@delong.com> wrote:

F= rom: Owen DeLong <owen@delong.com>
Subject: Re: [v6ops] ULA discussion #1 U= LA+NAT
To: "Doug Barton" <dougb@dougbarton.us>
Cc: v6ops@ietf.o= rg
Date: Tuesday, March 5, 2013, 9:18 PM


...
The fact that so many IPv6 deployments exist just fine in the r= eal world without "NAT-alikes" is proof that IPv6 can be deployed just fine= without NAT.
...

Owen

___________________________________= ____________
v6ops mailing list
v6ops@ietf.org
https://www.i= etf.org/mailman/listinfo/v6ops
---1551098171-410334529-1362591186=:19912-- From farmer@umn.edu Wed Mar 6 09:34:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D614621F8A94 for ; Wed, 6 Mar 2013 09:34:19 -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_33=0.6, 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 Q80A5J058KlZ for ; Wed, 6 Mar 2013 09:34:19 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 327B721F8988 for ; Wed, 6 Mar 2013 09:34:19 -0800 (PST) Received: from mail-oa0-f72.google.com (mail-oa0-f72.google.com [209.85.219.72]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Wed, 6 Mar 2013 11:34:08 -0600 (CST) X-Umn-Remote-Mta: [N] mail-oa0-f72.google.com [209.85.219.72] #+LO+TR X-Umn-Classification: local Received: by mail-oa0-f72.google.com with SMTP id j6so50902995oag.3 for ; Wed, 06 Mar 2013 09:34:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=neISDexnXUujt+c9sonUNUwjCFobDQL3MZBYzGymMqw=; b=o3HwXIUAE2AsxetC7iKR2hXXmrOfJQ9mP+cgToEj35Da9aXBJ5wfzZHGTswbCkVY1v uNXqDcWzlbLX1t2EQV7+PzCAnp9q6WCkC4QdTaR5j/DZfIL6vRoyrUikL6rseD4JcGc/ F/goiGe0b4Fq4AvCH+/4Wl5YiUPfkcWNSU+YzKikcea8+e3mI14eJzG4mUqMpctJ8nTm 9hc4f7VYXZeIWM3SROyw43Kze1yeNWdxDeS9WJkTFRPA9n1pJR5twm+e9M84G5sLWpvv KMFJaqTWml/LJpbWum8lXiBwymOTExNIdvl8ek0BnIITtU8VqV6FsRbdKxjVwmvrrZ1l ETfw== X-Received: by 10.50.170.36 with SMTP id aj4mr11425823igc.67.1362591248360; Wed, 06 Mar 2013 09:34:08 -0800 (PST) X-Received: by 10.50.170.36 with SMTP id aj4mr11425811igc.67.1362591248266; Wed, 06 Mar 2013 09:34:08 -0800 (PST) Received: from x-134-84-88-33.nts.umn.edu ([2607:ea00:101:2001:848f:f786:d824:d801]) by mx.google.com with ESMTPS id uy13sm25308915igb.7.2013.03.06.09.34.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 09:34:07 -0800 (PST) Message-ID: <51377E0C.3020504@umn.edu> Date: Wed, 06 Mar 2013 11:34:04 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ted Lemon References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> <5137561D.5070604@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> <513774A6.9070508@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B106A@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474B106A@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnDYtzr3XOrSfGP4rBQsp4vfhgR3GtPXGlfkWiJEccz01mJdMuiyzUWb+5+FwyqRwNr+yc58UtU3QnFNimhLTgtHfSigH1RGIqyVqZ9gAmhQpweine/J7kLDaJqcGBE0AR+pYDm Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:34:20 -0000 On 3/6/13 11:01 , Ted Lemon wrote: > On Mar 6, 2013, at 11:53 AM, David Farmer > wrote: >> So, you asked whats the harm here? Well a necessary discussion of the >> proper uses of ULA is being completely overshadowed by a relatively >> minor but valid part of the discussion, NPT. > > No, I asked you what the use case is that _requires_ NPT/NAT. If there > is no such use case, then we can logically conclude that there is no > harm in recommending against NPT/NAT. So if you can't come up with a > use case, why are we arguing about this? There is an example provided in the draft, read it. Rereading the draft, section 2.2.2.1, ULA-only Deployment, seems to imply that ULA-only Deployment is a special use case of ULA and not the generally intended deployment model. I would support making a more explicit recommendation against the use of ULA-only Deployment model, especially for general purpose connectivity. I remain opposed to an explicit recommendation against NAT or NPT as neither are truly the subject of the draft. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From lorenzo@google.com Wed Mar 6 10:52:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5858621F8A91 for ; Wed, 6 Mar 2013 10:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.294 X-Spam-Level: X-Spam-Status: No, score=-102.294 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, 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 wH4706Bl-F9m for ; Wed, 6 Mar 2013 10:52:35 -0800 (PST) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id C240321F88E6 for ; Wed, 6 Mar 2013 10:52:30 -0800 (PST) Received: by mail-oa0-f50.google.com with SMTP id l20so13214784oag.9 for ; Wed, 06 Mar 2013 10:52:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=khakat42Bli8ZLMsT1PMa0kWRqFY4IJZVQNpNihansI=; b=Rr/fTqRK8/T2063kD6NnGihO/vgeW1VvTm+MMbfRO3dRq8XsQr6JBQp/vSQCSrDfIL dClft1QWyCSteqGUPwqeAVZP6YFDe2nGSI6+FIXhMn2lyhek2pamrO3ed4GoEzzQXPu+ ahqYty2IdILIYsm7TtoWXPm5Ab95K8pBUE/7AYV1MHRTgE7cKSa3fXUkWjQ+1+exO4Jf fLVd7Qh/+nHxPFF+NbhizxW6/5IiZhBeaBEf1J0b2bzr4qVwmUMxaoz8WAD2FMSsrPb7 tWfkd3L6ZZR4KDDFt6Q7i81pAQFA8CKvz16kyvGJK5eVBENNUgOkaqMu5RkB+roDxFA/ V7RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=khakat42Bli8ZLMsT1PMa0kWRqFY4IJZVQNpNihansI=; b=LLvloW6MKZiNX9KDmPXVJv0t3fqr+jyHk7ey3DIALG9q7QKdryw5+r6gn2cAJy5joy 2VUcPWCEZhn/SJ+iNifLPn7/NyXowTGzFLRXhIraTcfhDjqzqNcd035u+Lxs7MOum2zg gAdfvkoNaykZE0bbn8gAJ+RQnuI8MXLtGEwa9CrVgUN6U/l1JX+mnu+Ga7bziu/cF+3j nyRkp3mcOjllE6e+Z6AetVuFmP7HBIwQ/HvoQ/GnlvDK45n75yJDVJJaekxFSunGLxcW J8frdFIx+Ar8gD0tJtqPJTUSO5Zz2j6Njb5WSEePKr2xtuk3HIeKRAIORULKSWTBgZ1l LldA== X-Received: by 10.60.172.18 with SMTP id ay18mr23448077oec.126.1362595950249; Wed, 06 Mar 2013 10:52:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Wed, 6 Mar 2013 10:52:10 -0800 (PST) In-Reply-To: <5136C780.3070306@dougbarton.us> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> From: Lorenzo Colitti Date: Wed, 6 Mar 2013 10:52:10 -0800 Message-ID: To: Doug Barton Content-Type: multipart/alternative; boundary=bcaec54fae48966bb204d74617dc X-Gm-Message-State: ALoCoQlBLpaTkgo2ML/nr4QyBAqBOb0U/sjFrGNVP5j1v45q4S81Y9yOqpzJEfDqhzz19eH9Bp7uriZnccENXaE8AUo8tF2agrF2Ed5WFvu6z/vjCgzdakj5yDsfIlqJdQpizef9aZMIxJ4x4JhhFlnW35orywB64OiV1OY+FzQ51QrN0/MxfG1/pMymvyRjqW7JMVQ2ZJtd Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 18:52:39 -0000 --bcaec54fae48966bb204d74617dc Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 5, 2013 at 8:35 PM, Doug Barton wrote: > >> Saying "some percentage" provides no information that can be used to >> make a decision. >> > > You show me your statistics first. :) > They're at http://www.worldipv6launch.org/measurements . You'll see a number of large and very large ISPs with significant IPv6 usage numbers. To my knowledge none of them use NAT66 or NPT66. If you add up the numbers you get to tens of millions of users - Verizon Wireless alone declares 94M customers, and if 17% of that has IPv6, then we're talking about 15M customers. > Seriously though, resorting to the "You don't have numbers" tactic is > expected, if not disappointing. More importantly, see below. I can see how it would be disappointing if we had no numbers. Fortunately we do. :-) > Is this statement based on actual experience? > > Yes, both my own in dealing with enterprise DNS/DHCP customers, and in the > many years of people coming to the IETF and saying exactly this. There have > been many people saying the same thing for well over a decade. The problem > is that this message hasn't been heard by the IPv6 protocol folks, so the > network operators for the most part don't bother anymore. It comes up on > the various lists I'm on periodically, and the same few people are still > giving out the same unrealistic advice. > One funny think I've learned about IPv6 deployment is that people love to say "we can't deploy IPv6 because of X". But in my experience, what usually happens when X is provided the same people move on to saying "we can't deploy IPv6 because of Y", where Y != X. So X is really not the real reason, it's just a red herring. What they are *actually* saying is "we see no need to deploy IPv6 at the moment". I would bet that most of the people you're talking to don't see a particular reason to deploy IPv6. > The problem is that if you(pl.) don't get it, you'll continue making the > same bad decisions, giving out the same bad advice, and most importantly, > continue doing damage to IPv6 deployment. Got it. But see, I don't think we're doing damage. IPv6 *is* growing exponentially, and at this point enterprise deployment or lack thereof won't change the numbers much. In my view, better to get real IPv6 with global addressing deployed, and then the enterprises can choose to deploy that or not. --bcaec54fae48966bb204d74617dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 5, 2013 at 8:35 PM, Doug Barton <dougb@doug= barton.us> wrote:

Saying "some percentage" provides no information that can be used= to
make a decision.

You show me your statistics first. :)

T= hey're at=A0http://www.worldipv6launch.org/measurements=A0. You'= ll see a number of large and very large ISPs with significant IPv6 usage nu= mbers. To my knowledge none of them use NAT66 or NPT66. If you add up the n= umbers you get to tens of millions of users - Verizon Wireless alone declar= es 94M customers, and if 17% of that has IPv6, then we're talking about= 15M customers.
=A0
Seriously though, resorting to= the "You don't have numbers" tactic is expected, if not disa= ppointing. More importantly, see below.

I can see how it would be disappointing if we had no nu= mbers. Fortunately we do. :-)
=A0
Is this statement based o= n actual experience?

Yes, both my own in dealing with enterprise DNS/DHCP customers, and in the = many years of people coming to the IETF and saying exactly this. There have= been many people saying the same thing for well over a decade. The problem= is that this message hasn't been heard by the IPv6 protocol folks, so = the network operators for the most part don't bother anymore. It comes = up on the various lists I'm on periodically, and the same few people ar= e still giving out the same unrealistic advice.

One funny think I've learned abo= ut IPv6 deployment is that people love to say "we can't deploy IPv= 6 because of X". But in my experience, what usually happens when X is = provided the same people move on to saying "we can't deploy IPv6 b= ecause of Y", where Y !=3D X. So X is really not the real reason, it&#= 39;s just a red herring. What they are *actually* saying is "we see no= need to deploy IPv6 at the moment". I would bet that most of the peop= le you're talking to don't see a particular reason to deploy IPv6.<= br>
=A0
The problem is that if you(pl.) don't get it, you'll continue makin= g the same bad decisions, giving out the same bad advice, and most importan= tly, continue doing damage to IPv6 deployment.

Got it. But see, I don't think we're doing damage. IPv6 = *is* growing exponentially, and at this point enterprise deployment or lack= thereof won't change the numbers much. In my view, better to get real = IPv6 with global addressing deployed, and then the enterprises can choose t= o deploy that or not.
--bcaec54fae48966bb204d74617dc-- From lorenzo@google.com Wed Mar 6 10:55:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9415B21F8920 for ; Wed, 6 Mar 2013 10:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.377 X-Spam-Level: X-Spam-Status: No, score=-101.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0J4zgaTWwx9 for ; Wed, 6 Mar 2013 10:55:53 -0800 (PST) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 214A821F88F7 for ; Wed, 6 Mar 2013 10:55:53 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id tb18so3807480obb.17 for ; Wed, 06 Mar 2013 10:55:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=3UGEGugNgi+VEH2aCpsaNIpWvry7HaLhYWMd4+zEIVk=; b=dfHwSj42d85Uq/bGwebvQi+J+c+zfMRHQmoBpDg/2qy3K5ataaYMtv6oVn70ZfaeD4 OzjwIutwmey70cdCm49wTTcOo2qmhWp82YqXD0Wm/e0IPrjTvm5DsnBc43E7MwcZ5zl2 ZFxM2eR61roZJqTu9zoTGPmfye5S9XpXrDpWHvTJrEzX+yubOoEM5F57k8XAhMaw/KLp g9uCt8+qvBgm6CUUK6sIcim+Liu+ZB+96etZMc6RpvQim2886okK8IpQirX47j/AAZSf NXXGf1KOd+s/0Tj2QQphySqQ0QtZ6cLT21W6484tKHE+sfS1Mb1Z7WLzKm0sj6GbA5uf +SXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=3UGEGugNgi+VEH2aCpsaNIpWvry7HaLhYWMd4+zEIVk=; b=dhHBaDjzquyzQsdn9vyYFwo5psdbd0rhCVLMTQaGipfrQzRvKzGY4zC2ILUGWxwUj3 lBYcTNmdwZ4Ppzrmp6tP5ZYUD4ENr/Uur3oSTIkmpZpZivwKHbAXQk23mVGod7VQOyvx OJWy6/+SBeC1uYGI8GOkamPkafMSf3ZBF0iGSpV9OaacNKt4Rf+GQG7YLQUkZLUe0iHZ eVOTYCqDvHV2SYfZhn7GAetGRlwo/ly9oTcgj6j+CW/3aaFyQQQV2usJnj4Ck8r9Mzi/ oYPi9JTUs7RVOkWsbQe9Yv9K2lBIppzjS31E8mJS6PE0HyqwE5Npi8NEtVIN7WSMpVQX 8LBQ== X-Received: by 10.60.170.140 with SMTP id am12mr23168494oec.125.1362596152679; Wed, 06 Mar 2013 10:55:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Wed, 6 Mar 2013 10:55:32 -0800 (PST) In-Reply-To: <51370302.7000003@gmail.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> From: Lorenzo Colitti Date: Wed, 6 Mar 2013 10:55:32 -0800 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=bcaec54b4812a73f6804d74623f1 X-Gm-Message-State: ALoCoQnEDvJQy4m+RxyCe1CXx2trqYh/qSOsShM8P8SGkUzPPSZSoFaY+4yaWVTX1bHKeyV/dwytAvfuO/6MlLUr/Nc/Bws1dSnRnbpkHE4VDOgATybet/rTBYKmNUHsjzpCwLCh9atfHm3dFcO3lnZMdodwE3EOk748i7KD93arDJwcxzODT+H/NpAsmM0vUvs0TJ7mxc2V Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 18:55:53 -0000 --bcaec54b4812a73f6804d74623f1 Content-Type: text/plain; charset=ISO-8859-1 Wed, Mar 6, 2013 at 12:49 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > On 03/05/2013 02:24 AM, Owen DeLong wrote: > >> No, Lorenzo's (and my) argument is that NAT technologies in IPv6 > >> aren't getting wide deployment today (even as a percentage of IPv6 > >> deployments) and that there's no reason to expect that trend will > >> change. Further, if that trend doesn't change, then it's unlikely that > >> there will be enough of an installed base to drive development. > > s/IPv6/IPv4/ and this is something I might have written in 1994. > You're forgetting the huge commercial pressures towards NAT in IPv4. In IPv4, NAT meant "my roommate/wife/child/dog and I can use the Internet at the same time without paying twice". Those commercial pressures do not exist today in IPv6, because every ISP I have ever heard of provides a /64. --bcaec54b4812a73f6804d74623f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0Wed, Mar 6, 2013 at 12:49 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> On 03/05= /2013 02:24 AM, Owen DeLong wrote:
>> No, Lorenzo's (and my) argument is that NAT technologies in IP= v6
>> aren't getting wide deployment today (even as a percentage of = IPv6
>> deployments) and that there's no reason to expect that trend w= ill
>> change. Further, if that trend doesn't change, then it's u= nlikely that
>> there will be enough of an installed base to drive development.
s/IPv6/IPv4/ and this is something I might have written in 1994.
<= /blockquote>

You're forgetting the huge commer= cial pressures towards NAT in IPv4. In IPv4, NAT meant "my roommate/wi= fe/child/dog and I can use the Internet at the same time without paying twi= ce".=A0Those commercial pressures do not exist today in IPv6, because = every ISP I have ever heard of provides a /64.
--bcaec54b4812a73f6804d74623f1-- From lorenzo@google.com Wed Mar 6 11:03:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2A721F892F for ; Wed, 6 Mar 2013 11:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.404 X-Spam-Level: X-Spam-Status: No, score=-102.404 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 QGobVR-TjonW for ; Wed, 6 Mar 2013 11:03:41 -0800 (PST) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0D621F8C10 for ; Wed, 6 Mar 2013 11:03:40 -0800 (PST) Received: by mail-oa0-f52.google.com with SMTP id k14so12801386oag.25 for ; Wed, 06 Mar 2013 11:03:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=fI9zPEbxQOwG5QFJzXK8mNw8mKvJkVvLx/7YECYuKkM=; b=k/m6Jhwp0ZPWUQbMwnMArvhbYCHAHzkHbDHjMNlH+G8kBgO3LVDxeNs7wApHBFF+E/ jBkVOEB12zON+vY/bM5WKhRsN9VNN/prnl2GOb+yrx90fbAOM9mZSDp+WKqFtrWOQ9pO XvJOOYghBgA6RpDlkhSUyg1H7FVzAMh//gloGHrjmy/qV0HmcuEqkx+S+ESw1ja7lgiF 3OvKxXmrjrtFZ+N89jwk2DU2wyLDzdAJOmW/HOOmDAGAGvLwZJ4woLCu3C1noC1rO5y3 LbheAwWA7flC5kU1qCjQJr57bPxJZByCE5IO0QzDh5x0ZwSzvbM4PlqonYv4iXFuevP4 T2mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=fI9zPEbxQOwG5QFJzXK8mNw8mKvJkVvLx/7YECYuKkM=; b=CubEBRjKT9D3mOHPRgZjF5mO9ijGP0mdTyVjVoDTE0XAHZUH0AT75n6GsxHF9fuysI gSaXwJZtTqLoPczj6eEdbP/eYBPEyJ0IyBD0EeptTlZdeiUt9YoHGduqk9VHi2gRMm5/ dZHMNoERVjG6l9QrW+tXVzPY0vLkRUhg8b0vRXfdYdUd0ZaiclpEYw705PxlLL0ZPl+8 BfXLdWd4LP+S+4JHIf/pcNcjSJEpqN6U8JDC4JDV+oAgN18O81g1mpRZIQGU/uEZe4K0 3zjNRBok67PJyub7y8mM/WbzQN9JysrIwz5ezBJmCBOO1UQYGO0KN5gMlunEigBRg62e kXFA== X-Received: by 10.60.3.200 with SMTP id e8mr14326637oee.94.1362596620089; Wed, 06 Mar 2013 11:03:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Wed, 6 Mar 2013 11:03:19 -0800 (PST) In-Reply-To: <5137561D.5070604@umn.edu> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> <5137561D.5070604@umn.edu> From: Lorenzo Colitti Date: Wed, 6 Mar 2013 11:03:19 -0800 Message-ID: To: David Farmer Content-Type: multipart/alternative; boundary=e89a8fb1f55e835dcd04d7463f04 X-Gm-Message-State: ALoCoQnQPxCcuUarT2d/hreCPcsO8Xia5MPkWv+0utrv6+STDW5n2Oz0xlKRUYDFTY3yAcdf1PYVhj0bW5geajmGDFivEhBpOHfSkDc06Rhm1VDGBIjGlusTtCJ1sFpTo4es564+/I03zFC498z0W77s85DKsdDk79PKa9hhLXDoTyFsHJNpf/8VWGVJ4eChsdBMGBFoeUfH Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 19:03:45 -0000 --e89a8fb1f55e835dcd04d7463f04 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 6, 2013 at 6:43 AM, David Farmer wrote: > If IPv6 fails we have no hope of NAT ever going away. And I'm afraid that > if we insist on a NAT free IPv6, that IPv6 will fail to be adopted by the > masses of Internet users. > But... but.. then your argument doesn't fit the data available. Because the data at http://www.worldipv6launch.org/measurements/ shows that IPv6 *IS* being adopted by the masses of Internet users. Aren't AT&T, Comcast and Verizon Wireless (to name some of the ones in your country) some of the largest mass market ISPs in the world? Yes, the enterprise is not going along as eagerly as the ISPs, but the enterprise wasn't leading the charge towards deploying IPv4 either. IPv6 deployment ain't broke. Don't fix it. --e89a8fb1f55e835dcd04d7463f04 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 6, 2013 at 6:43 AM, David Farmer <farmer@umn.edu= > wrote:
If IPv6 fails we have= no hope of NAT ever going away. And I'm afraid that if we insist on a = NAT free IPv6, that IPv6 will fail to be adopted by the masses of Internet = users.
=A0
But... but.. then your argument d= oesn't fit the data available.

Bec= ause the data at h= ttp://www.worldipv6launch.org/measurements/ shows that IPv6 *IS* being = adopted by the masses of Internet users. Aren't AT&T, Comcast and V= erizon Wireless (to name some of the ones in your country) some of the larg= est mass market ISPs in the world? Yes, the enterprise is not going along a= s eagerly as the ISPs, but the enterprise wasn't leading the charge tow= ards deploying IPv4 either.

IPv6 deployment ain't broke. Don't = fix it.
--e89a8fb1f55e835dcd04d7463f04-- From wesley.george@twcable.com Wed Mar 6 11:29:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9A721F8CDF for ; Wed, 6 Mar 2013 11:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.227 X-Spam-Level: X-Spam-Status: No, score=-0.227 tagged_above=-999 required=5 tests=[AWL=0.636, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, 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 ASV1zn+DVvxY for ; Wed, 6 Mar 2013 11:29:49 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id DF8E721F8CE7 for ; Wed, 6 Mar 2013 11:29:48 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,795,1355115600"; d="scan'208";a="38257168" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 06 Mar 2013 14:28:24 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 6 Mar 2013 14:29:46 -0500 From: "George, Wes" To: GangChen , v6ops Date: Wed, 6 Mar 2013 14:29:39 -0500 Thread-Topic: [v6ops] comments for draft-ietf-v6ops-nat64-experience [was draft-ietf-v6ops-nat64-experience WGLC] Thread-Index: Ac4ZgBi7eIn1RI5jQHGmhaO8TuDfbgA/x6LQ Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923041F47A432@PRVPEXVS15.corp.twcable.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] comments for draft-ietf-v6ops-nat64-experience [was draft-ietf-v6ops-nat64-experience WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 19:29:54 -0000 Apologies for not getting it out before the conclusion of WGLC, but it seem= s that the authors are still looking for comments before revising it, so I'= ve reviewed this document. Introduction, third paragraph. I think this sentence is out of place and sh= ould be removed: "There is also the troublesome trend of access network providers squatting on IPv4 address space that they do not own." It really doesn't tie into the rest of that paragraph, nor does it relate o= vermuch to the reasons for deploying NAT64. Carriers that need to support c= ustomers that have end devices which still require IPv4 connectivity are go= ing to do so by whatever means they feel appropriate, and NAT64 doesn't sol= ve that problem. NAT64 solves the problem of an SP that has the means to fo= rce all (or a large subset of) devices to IPv6-only but still needs a way f= or those users to reach IPv4-only content and services. 3.2 - this section is currently pretty weak. Are there any references to th= e different methods of HA in NAT64 that you could provide, either via vendo= r implementation or in the standards themseles? Is the assertion that most = traffic is short-lived and therefore cold standby is ok backed up by any pr= oduction or lab testing demonstrating the user experience for NAT64? It nee= ds to discuss what assumptions you made about how short-lived is short-live= d, how long a cold-standby failover should take before it becomes an unacce= ptable impact to customers, and whether there are certain types of traffic = more sensitive to this problem (TCP vs UDP, streaming vs surfing, etc). It = may also need to discuss true cold standby vs warm standby, because in most= cases, I think what you're referring to as cold standby is more like warm = standby (online at all times, but not actively exchanging all state informa= tion). This likely also ties into section 3.4, since the choice here will a= ffect the quality of experience. I would like to see more effort to tie the= two ideas together. IOW, if you are expecting that this will be a second-c= lass service that only covers the major traffic (http, etc) then it might b= e ok for there to be cold standby and session resets. If you're trying to m= ake this a first-class alternative (within the limits of the technology of = course), then session resets might not be acceptable. I would also move 3.5 so that it is immediately after 3.2. These are both t= alking about similar areas (scale and resiliency) and make more sense when = more closely tied together, especially when bolstered with some discussion = of how load balancers are used for resiliency and scale for normal use, and= how that might be different for NAT64/FE use. 3.3 - there have been a couple of drafts floating around trying to build a = NAT/CGN mib, whether generic or specific to NAT64. They haven't really gone= anywhere. Might be useful to discuss whether the lack of a mib is making t= his harder, or if it doesn't matter. 3.6 - I'm not following the explanation of the MTU issues here. It seems to= assert that IPv6 can't deal with packets smaller than 1280, which really i= sn't true, it just requires end host to end host fragmentation. Therefore, = IMO part of a NAT64 device's job is going to be to manage the PTB messages = and MTU discovery between the protocols and act as the IPv6 destination end= host so that it can facilitate any required IPv6 endhost-to-endhost fragme= ntation if the required MTU is below 1280 - it basically has to detect the = outgoing MTU and enforce it back to its end host. It's a lot of state to ma= intain probably, but doable. This is also a corner case, because IPv4 allow= s almost all packets (except those with the DF bit set) to be fragmented by= middleboxes if their MTU is smaller than the offered packet, making it lar= gely transparent to the end hosts. The IPv6 host can send whatever size pac= ket they want, and the IPv4 side will just fragment as necessary unless the= NAT64 box is doing something dumb like setting DF on the outgoing IPv4 pac= kets it is generating. Is this meant to discuss the situation where a NAT64 box receives IPv4 pack= ets smaller than 1280 and then has to send them to the IPv6 host? 4 - I'm not certain figure 2 is helpful in its current form. I had to look = 3 times before I figured out what was even different from figure 1, and the= addition of one word doesn't really require a new diagram. Honestly, this entire section repeats a lot of the content from the previou= s sections, and I think the draft would be much tighter and readable if you= simply integrated the little bit of additional information into the previo= us sections, either as subsections or just as part of the overall discussio= n. I don't think it adds much value as a standalone section. Generally, the= drafts that you reference here do a better job of discussing the use of a = loadbalancer as a method to provide IPv6 to a mostly IPv4-only backend and = vice versa. Regarding Randy's comments on e2e/smart edge/stupid core and the interactio= n with NAT64, I think they're mostly incompatible. While NAT64 makes runnin= g an IPv6-only network more possible while we wait for ubiquitous IPv6 depl= oyment on the content/service side, it's still fundamentally a NAT, a state= ful box in the middle that interferes with end to end communications and ma= y require ALGs for full function. It also still requires investment in thos= e boxes in the middle, which means that you're sort of stuck with them unti= l they depreciate, unless you can repurpose them for some other use. The on= ly thing you could do here is make the point that in order to keep the inte= lligence at the edge, NAT64/DNS64 implementations should be pushed as far d= own into the network as possible. But even then there are other tradeoffs o= n placement to consider, such as the scale of an individual NAT64 box or th= e number of devices that would be required by a more decentralized placemen= t, or network design and topology (as you have alluded to with the mobile e= xamples). By the ruler that Randy was proposing in his slides, this is less bad becau= se at least it sets up a network to be actually running IPv6 instead of ext= ending IPv4, and only does IPv4 to compensate for those who haven't deploye= d it yet. But it's still limited to places that are unencumbered by a need = to continue supporting legacy IPv4 devices, which limits its applicability = in the Access Provider community. Nits: 3.1 has a number of spelling errors Wes George > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of GangChen > Sent: Tuesday, March 05, 2013 4:02 AM > To: v6ops > Subject: [v6ops] comments for draft-ietf-v6ops-nat64-experience [was > draft-ietf-v6ops-nat64-experience WGLC] > > wg, > > There are offline comments from Randy Bush suggest to consolidate > NAT64 statements with the principle of e2e preservation and "smart edge > & stupid core". It was presented at http://archive.psg.com/120229.apops- > v4-life-extension.pdf > > Personally, I think it's worth to add some texts of those principle as a > part of NAT64 deployment considerations, since it would beneficial to > advance IPv6 deployment. > > I would like to seek wg opinions on this point or futher comments > regarding to http://tools.ietf.org/html/draft-ietf-v6ops-nat64- > experience. > > Please take the time to review the document in order to make sure the > draft doesn't lose anything at next update. > > Best Regards > > Gang > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops 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. From arturo.servin@gmail.com Wed Mar 6 12:39:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020C911E80BA for ; Wed, 6 Mar 2013 12:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 wREUk8vG4C3Z for ; Wed, 6 Mar 2013 12:39:30 -0800 (PST) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by ietfa.amsl.com (Postfix) with ESMTP id DB18221F88CF for ; Wed, 6 Mar 2013 12:39:23 -0800 (PST) Received: by mail-vc0-f176.google.com with SMTP id fk10so5046397vcb.21 for ; Wed, 06 Mar 2013 12:39:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=PJQozOj3CUvf8VJ3wsaoyeJg5etL2F/0BrTJVCvm3bI=; b=lF74fRzpehDJ2BxPToXrJTSi4WSVo+DRY3/cbVg5PI1v1vTJXqKQt4QBoyNIGt8wBI 0thVxkR1FuDN3Y9Nx9S4jg2UWzPd3QX7cRYsnYNLvQOmV5nxyfMPOgFtGN5MXD0szZsC AdyWIrEBtmU0ibEYAQMe9vgGqwMfm2ylqq6bLEqNvjIIHimiUmhwZKDa78VvwcoT0P53 ObYVXt3MjzhGrurj+b/xtZBm37aVUZt//SGYkP5sTvj6yp8jRGScazLiNyFNBt1tfMSu ZlUb503fg6qihlMYs6iclzf/W1CXOkqJoiI6bQuj5XJbeP8WGjFMgER/gpsYJwaINYrM PsLg== X-Received: by 10.52.88.237 with SMTP id bj13mr10382330vdb.75.1362602363315; Wed, 06 Mar 2013 12:39:23 -0800 (PST) Received: from 85-7-200.lacnic.net.uy ([2001:13c7:7001:5128:d15c:af20:1558:d4cb]) by mx.google.com with ESMTPS id l5sm6585437vdi.4.2013.03.06.12.39.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 12:39:22 -0800 (PST) Message-ID: <5137A976.9040308@gmail.com> Date: Wed, 06 Mar 2013 18:39:18 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org, lorenzo@google.com References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 20:39:31 -0000 Perhaps if you count Universities as enterprises may be we could see an increase in traffic. But I do not really know. Regards, as On 06/03/2013 16:52, Lorenzo Colitti wrote: > Got it. But see, I don't think we're doing damage. IPv6 *is* growing > exponentially, and at this point enterprise deployment or lack thereof > won't change the numbers much. In my view, better to get real IPv6 with > global addressing deployed, and then the enterprises can choose to > deploy that or not. From dougb@dougbarton.us Wed Mar 6 12:44:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E265521F88CF for ; Wed, 6 Mar 2013 12:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315] 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 sr1eJEPejyHb for ; Wed, 6 Mar 2013 12:44:49 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2873721F8BF0 for ; Wed, 6 Mar 2013 12:44:46 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:536:67b9:8210:372b] (unknown [IPv6:2001:470:d:5e7:536:67b9:8210:372b]) by dougbarton.us (Postfix) with ESMTPSA id C941422B0F for ; Wed, 6 Mar 2013 20:44:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362602685; bh=L6w8mfstZq76CA+/AD5yjh8n7ImXRIE48PS1TlAqMyY=; h=Date:From:To:Subject:References:In-Reply-To; b=ptBaDhIjssitzdp7AhfpsZ9dj6lPsIZtz5/mqDgW6I1zW5veFwjFfjj3hXow4w/Om M+pgsIQPXEUp44KzVUmIASKepgf3wmkTv0UTk/gScVlG8YM/CffJkbfEMPXZ/RulJF Br/+iovh9jJro51OZ7YYMoxczOh+XtR9Fd5Uu1rg= Message-ID: <5137AABD.1050401@dougbarton.us> Date: Wed, 06 Mar 2013 12:44:45 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "v6ops@ietf.org WG" References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 20:44:54 -0000 On 03/06/2013 10:52 AM, Lorenzo Colitti wrote: > On Tue, Mar 5, 2013 at 8:35 PM, Doug Barton > wrote: > > > Saying "some percentage" provides no information that can be used to > make a decision. > > > You show me your statistics first. :) > > > They're at http://www.worldipv6launch.org/measurements . You'll see a > number of large and very large ISPs with significant IPv6 usage numbers. > To my knowledge none of them use NAT66 or NPT66. If you add up the > numbers you get to tens of millions of users - Verizon Wireless alone > declares 94M customers, and if 17% of that has IPv6, then we're talking > about 15M customers. And what does any of that have to do with the topic at hand? Obviously ISPs don't need NAT-a-like solutions for v6, and for the most part neither do their customers since most only have a few devices behind the ISP-provided CPE. The topic we are discussing is the small - medium enterprise, in case you've forgotten. > One funny think I've learned about IPv6 deployment is that people love > to say "we can't deploy IPv6 because of X". But in my experience, what > usually happens when X is provided the same people move on to saying "we > can't deploy IPv6 because of Y", where Y != X. So X is really not the > real reason, it's just a red herring. What they are *actually* saying is > "we see no need to deploy IPv6 at the moment". I would bet that most of > the people you're talking to don't see a particular reason to deploy IPv6. First, the big enterprises and ISPs demanded PI space, and once they got it, they started deploying (per your statistics above). Second, some of those cycles were quite justified in the sense that the protocol of 10 years ago wasn't quite ready for prime time, and needed to have some things fixed. But more importantly, the same people have been saying for over a decade that they will not deploy IPv6 until they get full-featured DHCP, and a robust NAT-a-like solution. (I'll save you the time of responding with "robust NAT is an oxymoron.") The first still hasn't been delivered, and although I think 6296 is a good answer to the second, the IPv6 cognescenti are still complaining about it. And, even if those problems are solved, we hear from a non-trivial number of operators who have actually taken the time to dig into a potential IPv6 deployment that their next "can't deploy IPv6 because of X" problem is the concern about rogue RAs, and we still don't have a robust solution for that, and don't get me started on ND abuse ... Doug From lorenzo@google.com Wed Mar 6 12:54:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022D521F8A85 for ; Wed, 6 Mar 2013 12:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.242 X-Spam-Level: X-Spam-Status: No, score=-102.242 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, 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 l2Ac1pSyWNdx for ; Wed, 6 Mar 2013 12:54:02 -0800 (PST) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id 144F121F88D1 for ; Wed, 6 Mar 2013 12:53:58 -0800 (PST) Received: by mail-oa0-f53.google.com with SMTP id m1so13004312oag.40 for ; Wed, 06 Mar 2013 12:53:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=pc5JF7Vn4X3/77ZddV5Kdm8DW0eHOkEnTHizAeR9ZSQ=; b=TBbTmgCKrCQSjoVn6pFUVfW1aTmDwbl3lUWuZkpLqHfWqYf3JmFBKtuDYJd9ZivQ+R hDLP0RIBdRMqGw6D69Cfaw5liT46+H1KpZNwf/0NItGYuIdRmsdpvUWCvL7h16rgb4y5 7U1oqS4BOaWBaTbAQBEhucFoumRjQOiYrD3puQfOnKnZtaULV+S/8YXKm0DKZpsWcIpK OfWar5IHEt7MP/LHn3NxvcVSXZcJlKJ6VElcceBN5JPFylOnn75hoT5cuI+vSboyAorN RmjLGWeNRpiMvFKmrb+n30kBfyIK1vsIXri+8JY+6h1toQ1UbThiTEcYg9uReUJuhdwU 5jfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=pc5JF7Vn4X3/77ZddV5Kdm8DW0eHOkEnTHizAeR9ZSQ=; b=T6Ly+2CNGtYfF+1wUFAcCu7Qrdrd9XVxt9Icbex9JNL58tWWGL/MNmJPvYNyqtmkbK iXgmJzw8UMvld2Hz570iY4cZi8Ew/TPCg64JuHniusEXHumXXuqPeQqNRptitzzTRyK4 lf6Bmbajhr2TBWH1c4MMRNTe56kM1fn6FGRl86hUPclFtY78QSBDcfgXaTJVkDFZVbcT Jp7aTKyhMKjucT5w/uzY8aJPkfFSPZ+4EfePUDRqcXX2qQHT48bMtQ6bg29OXRfuk6Mt JphXg4HLbvwRUOP/h6h2f+seKIjbCalRQepNPQIVgg60Ofp7D4BFTR9WhWFsTKQyt1DL kRPg== X-Received: by 10.60.170.140 with SMTP id am12mr23557152oec.125.1362603237630; Wed, 06 Mar 2013 12:53:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Wed, 6 Mar 2013 12:53:37 -0800 (PST) In-Reply-To: <5137AABD.1050401@dougbarton.us> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> From: Lorenzo Colitti Date: Wed, 6 Mar 2013 12:53:37 -0800 Message-ID: To: Doug Barton Content-Type: multipart/alternative; boundary=bcaec54b4812f309c704d747c9bf X-Gm-Message-State: ALoCoQlBszMFhRSpj3bUg8BMO3aOPPeVx9ALIZhMQ67g2VMJNjSIxzT4u6s1OS1a4PthjQ6powIe/c96fwouGNVpF/Q6FmPGoJEUDfcxHR8v1XB+M7ggzNblttRLw8KiiLKgdv9eHkN9866aZfHWxYE0koOdzNTR1cNDkITNCEOG1+D2qkcE8Whi9skN7vkm9XkEGM/BDdvT Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 20:54:07 -0000 --bcaec54b4812f309c704d747c9bf Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 6, 2013 at 12:44 PM, Doug Barton wrote: > >> They're at http://www.worldipv6launch.**org/measurements. You'll see a >> number of large and very large ISPs with significant IPv6 usage numbers. >> To my knowledge none of them use NAT66 or NPT66. If you add up the >> numbers you get to tens of millions of users - Verizon Wireless alone >> declares 94M customers, and if 17% of that has IPv6, then we're talking >> about 15M customers. >> > > And what does any of that have to do with the topic at hand? Obviously > ISPs don't need NAT-a-like solutions for v6, and for the most part neither > do their customers since most only have a few devices behind the > ISP-provided CPE. > > The topic we are discussing is the small - medium enterprise, in case > you've forgotten. No it wasn't. I was replying to your statement that "The vast majority of current deployments aren't using IPv6, period. Of the tiny percentage that are, some percentage of them are using a NAT-a-like strategy." The data we have do not support that assertion. And, even if those problems are solved, we hear from a non-trivial number > of operators who have actually taken the time to dig into a potential IPv6 > deployment that their next "can't deploy IPv6 because of X" problem is the > concern about rogue RAs, and we still don't have a robust solution for > that, and don't get me started on ND abuse ... > And yet, > 90% of the users on Google's enterprise network have IPv6. We don't use NAT66 or NPT66, we have solutions for rogue RAs. I suppose that's a case of the people who say it can't be done not interrupting the ones who are doing it. And yes, we do use NAT for IPv4 (sometimes multiple layers of it). I'll grant you this is possible because the network has PI space; we still need to find a solution for multihoming using PA space. The recent homenet and routing area drafts on source-based routing can, I think, solve that problem. --bcaec54b4812f309c704d747c9bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 6, 2013 at 12:44 PM, Doug Barton <dougb@dou= gbarton.us> wrote:

They're at http://www.worldipv6launch.org/m= easurements . You'll see a
number of large and very large ISPs with significant IPv6 usage numbers. To my knowledge none of them use NAT66 or NPT66. If you add up the
numbers you get to tens of millions of users - Verizon Wireless alone
declares 94M customers, and if 17% of that has IPv6, then we're talking=
about 15M customers.

And what does any of that have to do with the topic at hand? Obviously ISPs= don't need NAT-a-like solutions for v6, and for the most part neither = do their customers since most only have a few devices behind the ISP-provid= ed CPE.

The topic we are discussing is the small - medium enterprise, in case you&#= 39;ve forgotten.

No it wasn't. I = was replying to your statement that "The vast majority of current depl= oyments aren't using IPv6, period. Of the tiny percentage that are, som= e percentage of them are using a NAT-a-like strategy." The data we hav= e do not support that assertion.

And, even if those problems are solved, we hear from a non= -trivial number of operators who have actually taken the time to dig into a= potential IPv6 deployment that their next "can't deploy IPv6 beca= use of X" problem is the concern about rogue RAs, and we still don'= ;t have a robust solution for that, and don't get me started on ND abus= e ...

And yet, > 90% of the users= on Google's=A0enterprise network have IPv6. We don't use NAT66 or = NPT66, we have solutions for rogue RAs. I suppose that's a case of the = people who say it can't be done not interrupting the ones who are doing= it. And yes, we do use NAT for IPv4 (sometimes multiple layers of it).

I'll grant you this is possible because= the network has PI space; we still need to find a solution for multihoming= using PA space. The recent homenet and routing area drafts on source-based= routing can, I think, solve that problem.
--bcaec54b4812f309c704d747c9bf-- From dougb@dougbarton.us Wed Mar 6 13:02:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB61721F8CCA for ; Wed, 6 Mar 2013 13:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwjwMTTngMNs for ; Wed, 6 Mar 2013 13:02:33 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4A67121F8CC8 for ; Wed, 6 Mar 2013 13:02:33 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:536:67b9:8210:372b] (unknown [IPv6:2001:470:d:5e7:536:67b9:8210:372b]) by dougbarton.us (Postfix) with ESMTPSA id 1531922B3F; Wed, 6 Mar 2013 21:02:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362603753; bh=8NyQYrDHJ2eO5R6AfJJc2GvvsMnn/h1k0oXIZA63gTU=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=VTOLaTGC88JBUXEucsptCDU7ETm6L5fAbeXLYhrHdk0ib0qiagzSYK8WQ0aZUztdT dYoJXJUCDlSp6JvIGKyvxUmmHWh3ZHlaKKNw+sJp1YGq9h+003pBJ6IMVndTI6I1zQ fcrPTXjQTENJMGjB+nGljEwFm5yncHeG5OWOJDy8= Message-ID: <5137AEE8.2050308@dougbarton.us> Date: Wed, 06 Mar 2013 13:02:32 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Lorenzo Colitti References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 21:02:38 -0000 On 03/06/2013 12:53 PM, Lorenzo Colitti wrote: > On Wed, Mar 6, 2013 at 12:44 PM, Doug Barton > wrote: > > The topic we are discussing is the small - medium enterprise, in > case you've forgotten. > > > No it wasn't. I've been talking about that all along, and I think I've been extremely clear about it. Small - medium enterprises are pretty much the only place where a NPTv6 + ULA solution makes sense. Home and SOHO users don't need it, and large enterprises multihome. If you were really confused about the topic I have been discussing all along then it might explain some of the disconnect. > And yet, > 90% of the users on Google's enterprise network have IPv6. We > don't use NAT66 or NPT66, Google is not a small - medium enterprise the last time I checked, and as you pointed out, you're using PI. > we have solutions for rogue RAs. Did you bring enough to share with the group? :) Doug From lorenzo@google.com Wed Mar 6 13:07:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973C811E8140 for ; Wed, 6 Mar 2013 13:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.374 X-Spam-Level: X-Spam-Status: No, score=-102.374 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 V9f0-cJ-tqbX for ; Wed, 6 Mar 2013 13:07:17 -0800 (PST) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id 9425911E813F for ; Wed, 6 Mar 2013 13:07:17 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id o17so13103289oag.20 for ; Wed, 06 Mar 2013 13:07:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=eRivntMy9aqFqCBAr3cnWcZ3PG4vcZuDNy55/5vY0ng=; b=MzYfBXFizA2i8SQDWfdVVk/YOfsEvZD2w3PEn0y1eu9SW55K3rl/gJ6hDbwOgeE/5h YicEvKrYsFC0clnsmaJGD99HlIBUGOCEmv3IbkQwWqWjcNJ33yhfeaJssNgHE48DhVDg hyYeKSijW0dmDEIJnR4Ql42uCVTZBVdJRS696zDI8DJ/dA5AHIVcOSENpoi4TVyOLbW9 qmUJMID2A3aGqrJc0SgyiqHbWDSTJmOP6j6BJI6NJcQ6Qrb79yGopTA89ZTvtjlGVYXB L8mBeU4w4uSWxeXF0CcYoyQFzjuoSTs0fzfcfhgDjUL2lxxxkpIeWsASmqTSmsM0saBd lO0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=eRivntMy9aqFqCBAr3cnWcZ3PG4vcZuDNy55/5vY0ng=; b=MBuAUZRcbdu7Akl6QlrmTN2AZ7oUANS2CI9/BbwnoW5UiMeE58fAXtmlVQf+XW2hRZ +b51KQ8FwMYdMMWnh+XssyUIyEJKXbMoBeHP/6DR4ftq5JuGOzeLxfI+LREgOFzLamgg HEyYEzfF6lRN+721vRNZCkjXrd72HcjJfGzGnrkiQRRLGe9TlOCug0+sDQNh3JNIA9b/ P02f6CbD905eoBOu0yed36qoJxjnsHf8Mwoo6wzR89dRk09NzpthCP5GdSwXfQeDNVUU O8QoU3zA1FrkkZ8W6PEyOrRRsW8xWPZEmTF5FtApZ4WpTVbI2taMqfPfnaz1y5nfXvSq ZE6g== X-Received: by 10.182.159.98 with SMTP id xb2mr23881457obb.81.1362604037181; Wed, 06 Mar 2013 13:07:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Wed, 6 Mar 2013 13:06:56 -0800 (PST) In-Reply-To: <5137AEE8.2050308@dougbarton.us> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> From: Lorenzo Colitti Date: Wed, 6 Mar 2013 13:06:56 -0800 Message-ID: To: Doug Barton Content-Type: multipart/alternative; boundary=14dae9399a4d9b35a004d747f9b3 X-Gm-Message-State: ALoCoQn0e3IDZjMAhM7ZmkxFntwkgK0ptPBcVS41vSLY0/0WuGxbJFUM7x5m7DZSE3RhTonPAl/K3nvzj9Yiva6L2541SYf2LxeuHrF3RNC+jTGV32Rc7Sxfq7fvNEd+aIKUQ6aMLLndjEzQNPzekieOmqK+BzZZsZu7edEHclRBkfy6OwbcmgogI+rhRDdrG/skb9kYZYiT Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 21:07:19 -0000 --14dae9399a4d9b35a004d747f9b3 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 6, 2013 at 1:02 PM, Doug Barton wrote: > we have solutions for rogue RAs. >> > > Did you bring enough to share with the group? :) I think we're using the ones recommended by the IETF... --14dae9399a4d9b35a004d747f9b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 6, 2013 at 1:02 PM, Doug Barton <dougb@doug= barton.us> wrote:
we have solutions for rogue RAs.

Did you bring enough to share with the group? :)

I think we're using the ones recommended by the IETF...=A0<= /div>
--14dae9399a4d9b35a004d747f9b3-- From dougb@dougbarton.us Wed Mar 6 13:11:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B55011E8128 for ; Wed, 6 Mar 2013 13:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhQC0pth9N0H for ; Wed, 6 Mar 2013 13:11:52 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E44911E8137 for ; Wed, 6 Mar 2013 13:11:52 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:536:67b9:8210:372b] (unknown [IPv6:2001:470:d:5e7:536:67b9:8210:372b]) by dougbarton.us (Postfix) with ESMTPSA id 491FF22B54; Wed, 6 Mar 2013 21:11:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362604312; bh=NqkGbBsqSLNoO02pIxuuXB6+doXwa6C09yrx9EJgKQU=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=pWgkTFz/0sJncAXW4oSuoVePD7dpgIKX/aa+tuq8Ea8grsE8TMU6CO6fdfFku8xHy 9EGfd3VMLRxjnnOG8fAYNg9TKw3KvLuZc1Cm4aUgd+xm7zhCVV6YpGCLo8czKdu6ev uW5Yntd46VrW0V/Kt73SSkWPwXW2YXzzcshq6Vqs= Message-ID: <5137B118.8040904@dougbarton.us> Date: Wed, 06 Mar 2013 13:11:52 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Lorenzo Colitti References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 21:11:55 -0000 On 03/06/2013 01:06 PM, Lorenzo Colitti wrote: > On Wed, Mar 6, 2013 at 1:02 PM, Doug Barton > wrote: > > we have solutions for rogue RAs. > > > Did you bring enough to share with the group? :) > > > I think we're using the ones recommended by the IETF... So perhaps you would consider writing up a draft to describe your deployment experience, how robust the solutions are under actual testing, etc. I keep hearing from people that this problem isn't solved yet. If you have solid evidence to the contrary it would be most welcome. Doug From Ted.Lemon@nominum.com Wed Mar 6 13:24:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7259C21F8CA7 for ; Wed, 6 Mar 2013 13:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.232 X-Spam-Level: X-Spam-Status: No, score=-106.232 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GH4pYYegaLId for ; Wed, 6 Mar 2013 13:24:04 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 36ECD21F8C9A for ; Wed, 6 Mar 2013 13:24:04 -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 DSNKUTez9Bhgf6ZCYpRSzGEE+kt/p4wE/ld/@postini.com; Wed, 06 Mar 2013 13:24: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 E75881B806B for ; Wed, 6 Mar 2013 13:24:03 -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 DC624190043; Wed, 6 Mar 2013 13:24:03 -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, 6 Mar 2013 13:24:03 -0800 From: Ted Lemon To: Doug Barton Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT Thread-Index: Ac4Y0qVmXOczhdgyTHaW1OIbGrg4zQAVbZqAABAGvAAAAlzXgAAIFLoAAAKCZIAABfkCAAAA0RCAAACcd4AAAOJ/gAAAJRsAAABlxoAAALV/gAACHAWAACcL2QAAHe3hAAAD7pKAAABPR4AAAE+4AAAAwBSA Date: Wed, 6 Mar 2013 21:24:02 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> In-Reply-To: <5137AEE8.2050308@dougbarton.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307474B1C9Bmbx01winnominum_" MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 21:24:05 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307474B1C9Bmbx01winnominum_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 6, 2013, at 4:02 PM, Doug Barton > wrote: Small - medium enterprises are pretty much the only place where a NPTv6 + U= LA solution makes sense. Why does it make sense in this case? Please don't say "because operators = of networks can't be bothered to learn IPv6," or something equivalent. --_000_8D23D4052ABE7A4490E77B1A012B6307474B1C9Bmbx01winnominum_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Mar 6, 2013, at 4:02 PM, Doug Barton <dougb@dougbarton.us> wrote:
Small - medium enterprises are pretty much the only place where a NPTv6 + UL= A solution makes sense. <= /span>

Why does it make sense in this case?   Please don't say "bec= ause operators of networks can't be bothered to learn IPv6," or someth= ing equivalent.


--_000_8D23D4052ABE7A4490E77B1A012B6307474B1C9Bmbx01winnominum_-- From lorenzo@google.com Wed Mar 6 13:27:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CF111E8156 for ; Wed, 6 Mar 2013 13:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.374 X-Spam-Level: X-Spam-Status: No, score=-102.374 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 qkmPgLDqlPXZ for ; Wed, 6 Mar 2013 13:27:48 -0800 (PST) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2F19C11E8147 for ; Wed, 6 Mar 2013 13:27:42 -0800 (PST) Received: by mail-oa0-f52.google.com with SMTP id k14so12993797oag.25 for ; Wed, 06 Mar 2013 13:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Mtu/V5D808DkYmWHBxApqUi0aH7K2ATc8ai+m/2vLgk=; b=Q/U/iGr2ahIwkvWn2+fDt3MvjG7V6UJD9gZIQk16T4DS0V78DaR6jbYMM7vPPRfXA3 0vHx4G97w6OiC14tkA0iqi/wOKkMhpbORzqBiSqokApm01mQDdjg65BQq61KQ19180Pz g2Ooze/1l1yap5zp12tLP9lnVlWQTU5EGA+FuGf6lBIfcsUlXLYZyVWCNanWxH1Lick0 I/ITI33LU/rsGYWvF31ypyBH1zacJpUpqZwSskosPlAo0tFxgftBOECw2YNQiL7nrEvr KmWewMoI0Uoxa5bked8a6AtVljuomq4HyjVf6oqjV40IvOzZWbRq7VFbGiuDfAc0V+tk LTbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=Mtu/V5D808DkYmWHBxApqUi0aH7K2ATc8ai+m/2vLgk=; b=N5pHgU4OV138ig8fl1pcJLD0AlFmniqFwa8kAl8fHP08HXeTaGKFZ0ZY7SvgEXyDOi 38ruEyKrLLswU1ziTdrxWPRS4hMB3QYxTdpAtp6w+jWEcNUuaq+9W1TEmV+jNZ8lVP80 pau+LbBzA5LXUqpyImPwhQhJh1WKYRnNr+ujD2ShbVcBSOwbm8AK8rJlZi6KBR9/LeBT IGrr6nN2UZNG38ame2WnflejspJ56PQTww5s1g4NecmMHEzyFuHcjWpSAozHJVz+qno8 6gnxB29PSpi0HUEDuL0i1RGwU6enWF5fEKa6upcHwkZ5KQRE7V/VMgLPVHaYYljvg3ip zihw== X-Received: by 10.182.159.98 with SMTP id xb2mr23934725obb.81.1362605262467; Wed, 06 Mar 2013 13:27:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Wed, 6 Mar 2013 13:27:22 -0800 (PST) In-Reply-To: <5137B118.8040904@dougbarton.us> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <5137B118.8040904@dougbarton.us> From: Lorenzo Colitti Date: Wed, 6 Mar 2013 13:27:22 -0800 Message-ID: To: Doug Barton Content-Type: multipart/alternative; boundary=14dae9399a4da3920004d7484258 X-Gm-Message-State: ALoCoQkMWHN2TEd1QTTAm6ykNnf5ccSQC7upoKzfAkrPGBdlhovlYJqc6jC+h+7Qhq8t4htRk2OAl8LpYEPprUrvRc4BDrbEPWGOn/rlV8xaM4O8thtFDEg/1QLjYt5+XT7fBsHoh2SfwgsCqkzdo/WU8gMEy0TrE9eG52R1GQnJpoIk3Rt/fKYhZfo6qh4OcKKs7dqjlM9F Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 21:27:49 -0000 --14dae9399a4da3920004d7484258 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 6, 2013 at 1:11 PM, Doug Barton wrote: > So perhaps you would consider writing up a draft to describe your > deployment experience, how robust the solutions are under actual testing, > etc. I keep hearing from people that this problem isn't solved yet. If you > have solid evidence to the contrary it would be most welcome. > Please read and comment on http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6 . KK is one of the authors and one of the people behind Google's enterprise IPv6 deployment. --14dae9399a4da3920004d7484258 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 6, 2013 at 1:11 PM, Doug Barton <dougb@doug= barton.us> wrote:
So p= erhaps you would consider writing up a draft to describe your deployment ex= perience, how robust the solutions are under actual testing, etc. I keep he= aring from people that this problem isn't solved yet. If you have solid= evidence to the contrary it would be most welcome.

--14dae9399a4da3920004d7484258-- From dougb@dougbarton.us Wed Mar 6 13:43:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D418E11E8169 for ; Wed, 6 Mar 2013 13:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 UOrGCiJsXyhf for ; Wed, 6 Mar 2013 13:43:55 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8C411E8153 for ; Wed, 6 Mar 2013 13:43:52 -0800 (PST) Received: from [192.168.0.102] (home [12.207.105.210]) by dougbarton.us (Postfix) with ESMTPSA id B8D8D22B0F for ; Wed, 6 Mar 2013 21:43:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362606231; bh=aiV6AizjzjpdpKfLnwEa/tI4sZM6Feb4hU+N/TC+BF8=; h=Date:From:To:Subject:References:In-Reply-To; b=DJtR9gT91sLy4kFnKULu0A7NrDSt0J12d+5HuZVykNDhjRpTOzTPehj64oIloMu6s 0XBG8SWISgxKajMIkosa5L25hkVLC3QnbYb1TF4LiF3HzIfpcixkcBD1Ai4FKfP97c kMu13NwvW5goQKO8qDnvsaHw16HWW0ijw/sBy170= Message-ID: <5137B897.7080601@dougbarton.us> Date: Wed, 06 Mar 2013 13:43:51 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> <5137561D.5070604@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 21:43:56 -0000 On 03/06/2013 07:28 AM, Ted Lemon wrote: > On Mar 6, 2013, at 9:43 AM, David Farmer > wrote: >> My question to Owen and Doug is where do you think this argument is >> going? Owen wants an explicit recommendation _against_ NPT, I suggested that a rational, fair discussion of the pros and cons of each possible solution would be a lot more useful to the intended audience. Then let them decide on their own. To answer Ted's question, the harm isn't technical, and it's naive to think that we're only dealing with technical issues here. To the extent that people will actually read the document what I want to avoid is a scenario like, "Wow, this combination of ULA + NPTv6 really sounds like it would meet my needs, but the IETF recommends against it. So now what do I do?" The other harm is by continuing the ivory tower "NAT causes birth defects!" line we make the IETF increasingly anachronistic every day, since we are demonstrating rather clearly that we're entirely deaf to the needs of real world network operators. >> I'm getting sick and tired of hearing this debate on one >> mailing list or another every 3 to 6 months. You guys are not going >> to shout the other down, so stop trying. I'm not trying to shout Owen or Lorenzo down, what I want to do (especially on the non-IETF lists) is demonstrate that there is another perspective, no matter how much some folks like to state that their view is the only right one. >> How do we find useful and practical compromise out of this discussion? I welcome input on finding a solution to this difficult problem. :) > Compromise isn't really the goal. Rough consensus is the goal. It's > perfectly okay to declare rough consensus when there are a few people > arguing against the consensus. Fair enough ... what's disturbing me at this point however is the number of people who have written to me privately to say that they support my viewpoint, but are afraid to speak up on the list. That makes it hard to judge consensus. My other concern is that while "consensus," rough or not, is a great goal, having what we produce align with reality and meet the needs of operators looking to deploy IPv6 is a more important one. It doesn't matter that we all agree on something if we're all wrong. > What I would ask you is this: why is it so important to you that there > _not_ be a recommendation against NAT/NPT? Answered above. > I get that you think > NAT/NPT will happen, but that's pure speculation at this point. Answered previously. :) > Are you saying that you _prefer_ NAT/NPT? Certainly not. I think it makes sense for a majority of organizations in one particular category, the small - medium enterprise. But even for many of them, as others have pointed out, PI space announced by their ISP would be _preferable_, it may just not be realistic. > If so, why? If not, why not > write a standard that says what we _want_? What's the downside? Because what we want doesn't matter a hill of beans. Also, see above. > To be clear here, I don't mean to ask you to explain to me again about > all the people who don't understand IPv6 and how they will react if they > can't have NAT. Even phrasing the issue this way seems to imply a fairly insulting bias against people who have looked at the needs of their enterprise and come to the conclusion that something like NPTv6 + ULA is the right answer. The fact that you still see the problem as, "They just don't understand IPv6" is a partial answer to David's question about why I keep repeating myself about how these people think. > I mean to ask you, what _technically_ will go wrong if > we recommend against NAT/NPT? What is your use case where NAT/NPT is > _required_ not by personal preference but because there is no other way > to solve the problem? Again, that's the wrong way to look at the question, but I think I've repeated myself enough on this by now. :) Doug From dougb@dougbarton.us Wed Mar 6 13:50:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF1511E8141 for ; Wed, 6 Mar 2013 13:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.036 X-Spam-Level: X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 yvWM8TrZNrqx for ; Wed, 6 Mar 2013 13:50:58 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 9C28A21F89A6 for ; Wed, 6 Mar 2013 13:50:54 -0800 (PST) Received: from [192.168.0.102] (home [12.207.105.210]) by dougbarton.us (Postfix) with ESMTPSA id 6507C22B3F for ; Wed, 6 Mar 2013 21:50:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362606654; bh=RHisOtli2jea6faIVsI9zA4ZW7a6EgoQn7QKGUwDm9U=; h=Date:From:To:Subject:References:In-Reply-To; b=rgwj3UJ+qOddSbGG58RgxU6tg5yoiYHFDuz0JZhQQ89AQbv2V3jRoetjuZYOQ7X0F tQ1Pjo0m7F9AfZUIyZ4mVyflNP7PJCreHC5XHuHeEdcAe/nyDiONy3enDX2UPT37ib jLFKEjeoOFAxSCYiJLhZPpHcU0NGkdP1NTESYogE= Message-ID: <5137BA3E.4020604@dougbarton.us> Date: Wed, 06 Mar 2013 13:50:54 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "v6ops@ietf.org WG" References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 21:50:59 -0000 On 03/06/2013 01:24 PM, Ted Lemon wrote: > On Mar 6, 2013, at 4:02 PM, Doug Barton > wrote: >> Small - medium enterprises are pretty much the only place where a >> NPTv6 + ULA solution makes sense. > > Why does it make sense in this case? I've already covered this ad nauseum in previous posts on this thread, feel free to review them for the details. Short answer, "enterprises hate renumbering." As in, really really hate it. A lot. Totally. NPT gives them the ability to be provider agnostic without having to worry about renumbering their inside network, or dealing with the trouble and expense of PI space. Doug From dougb@dougbarton.us Wed Mar 6 13:53:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7203611E817A for ; Wed, 6 Mar 2013 13:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.033 X-Spam-Level: X-Spam-Status: No, score=-2.033 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 sfsUnGVQW0t7 for ; Wed, 6 Mar 2013 13:53:24 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7869321F84D5 for ; Wed, 6 Mar 2013 13:52:39 -0800 (PST) Received: from [192.168.0.102] (home [12.207.105.210]) by dougbarton.us (Postfix) with ESMTPSA id A2FFF22B0F; Wed, 6 Mar 2013 21:52:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362606757; bh=f3yuxrZCzU7i+f0QJLJZcL4oLJNDEns1BmaY4DmyjOs=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=xqxBy7C4esgob15vpNbh5n0MEqI5evKqUkprybUwjoNnS6DRx0e1dPJa6M34hjFpO ezSEYd/9H36GQiMWA3I1ZReL4EXDsEErMu7ClDLf8d5PENLocQZFfVAI58oZosuGsz nZVeZLKmAkM1LM5Bd26e6bo2Luek/07UmSoW1KKo= Message-ID: <5137BAA5.9000302@dougbarton.us> Date: Wed, 06 Mar 2013 13:52:37 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Lorenzo Colitti References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <5137B118.8040904@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 21:53:25 -0000 On 03/06/2013 01:27 PM, Lorenzo Colitti wrote: > On Wed, Mar 6, 2013 at 1:11 PM, Doug Barton > wrote: > > So perhaps you would consider writing up a draft to describe your > deployment experience, how robust the solutions are under actual > testing, etc. I keep hearing from people that this problem isn't > solved yet. If you have solid evidence to the contrary it would be > most welcome. > > > Please read and comment on > http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6 > . KK is one of the authors and one of the people behind Google's > enterprise IPv6 deployment. Awesome, thanks! Doug From marka@isc.org Wed Mar 6 14:03:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EAC11E818F for ; Wed, 6 Mar 2013 14:03:05 -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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6] 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 Mnkf3sylHKkQ for ; Wed, 6 Mar 2013 14:03:01 -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 0ED6411E818D for ; Wed, 6 Mar 2013 14:03:01 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id ED7CFC9568; Wed, 6 Mar 2013 22:02:51 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1362607380; bh=Ae9Nm31Uhdy6gAvDRaOswWqYrxxwbYVXXbeZvdFcEFg=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Ash44eBQT67gU6Rtnzz0bytMbBVR0gQGpy+2MEr0jtj8ebq99DHhTG7pjJcUIrmh/ eHZkNxX1gr7W4HV/BMThJqQjgRjyLdcBil3jTUcgQ0Bh8sq9xt2xqxwV5yDRa110gp r2uSg+M6DSFmlJ/mehG2Jl9zJ9viYAJ28glxhroQ= 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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Wed, 6 Mar 2013 22:02:51 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:386e:5ec1:f8b1:1682]) (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 6B663216C40; Wed, 6 Mar 2013 22:02:51 +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 D935E3078F7F; Thu, 7 Mar 2013 09:02:41 +1100 (EST) To: Doug Barton From: Mark Andrews References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> In-reply-to: Your message of "Wed, 06 Mar 2013 13:02:32 -0800." <5137AEE8.2050308@dougbarton.us> Date: Thu, 07 Mar 2013 09:02:41 +1100 Message-Id: <20130306220241.D935E3078F7F@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 22:03:05 -0000 In message <5137AEE8.2050308@dougbarton.us>, Doug Barton writes: > On 03/06/2013 12:53 PM, Lorenzo Colitti wrote: > > On Wed, Mar 6, 2013 at 12:44 PM, Doug Barton > > wrote: > > > > The topic we are discussing is the small - medium enterprise, in > > case you've forgotten. > > > > > > No it wasn't. > > I've been talking about that all along, and I think I've been extremely > clear about it. Small - medium enterprises are pretty much the only > place where a NPTv6 + ULA solution makes sense. Home and SOHO users > don't need it, and large enterprises multihome. If you were really > confused about the topic I have been discussing all along then it might > explain some of the disconnect. As far as I can tell the main problem SMB are solving with NAT is the multi-homing with PA addresses. Yet over in homenet they are looking at how to get source + destination routing to work so that homes with multiple subnets can be multi homed without any configuration. You deprecate the PA RAs when the upstream link goes down and your restore them when it comes back. There a couple of stack that are broken when this happens but they will get fixed/replaced. Distributing this sort of information is the bread and butter of the IETF. With a little router smarts I don't even need a seperate protocol. I know what upstream I got my PD through. If the RAs on that interface deprecate a PA RA I deprecate it on my down stream interfaces. When the PA RA is restored on that interface I do the same thing on the others. Now I'm sure some SMB don't like this sort of magic so providing them with a explict protocol won't hurt. I suspect anyone that as worked with routing protocol design could deliver 5 different solutions to how to do this in a day. I've thought of a couple just writing this piece of email. So rather than saying NAT*6 + ULA is enevitable I suggest we look as the problems that are trying to be solved with NAT*6 + ULA and come up with alternatives. > > And yet, > 90% of the users on Google's enterprise network have IPv6. We > > don't use NAT66 or NPT66, > > Google is not a small - medium enterprise the last time I checked, and > as you pointed out, you're using PI. > > > we have solutions for rogue RAs. > > Did you bring enough to share with the group? :) > > Doug > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From farmer@umn.edu Wed Mar 6 14:08:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3192311E818D for ; Wed, 6 Mar 2013 14:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.119 X-Spam-Level: X-Spam-Status: No, score=-6.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 yEYO69OIFI2r for ; Wed, 6 Mar 2013 14:08:28 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id 3B62421F8C12 for ; Wed, 6 Mar 2013 14:08:28 -0800 (PST) Received: from mail-oa0-f72.google.com (mail-oa0-f72.google.com [209.85.219.72]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Wed, 6 Mar 2013 16:08:21 -0600 (CST) X-Umn-Remote-Mta: [N] mail-oa0-f72.google.com [209.85.219.72] #+LO+TR X-Umn-Classification: local Received: by mail-oa0-f72.google.com with SMTP id j6so52606246oag.3 for ; Wed, 06 Mar 2013 14:08:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=qxd7gyOu4Wosok8mTs3C0ooyqzBRbxVE+CTeVofHUuk=; b=XlZqM+Hz3EIWzJagRGCuq4NKamjvMS7olsZN5edouvYxvCOK1aoAxGVoCLdohg4eCi MqF6emHFIZKp/pJRp+xotcxdbJy1b5SsGEN47CjxXRecKmFXJDO29L8xyciXGnqMs7Ix XqxRuTgb4XQuJaJY/O/3XEfzpCB92df9f5WKJ7JbRWowb6XTmhxO9cxYunzp85w0mUk+ kShBrovs9b7jk00L8DacyEybLQEmYg9E2q57T6nwdzmj9YXtKOzqNO5zVAU0+AGhdOEz pDaTePshAaagFLG9eS9Rm7PBzwi23q+We1pGKXep07OWDVGRt6Gys9jNgYcSy4oB6nWj XixQ== X-Received: by 10.42.58.67 with SMTP id g3mr32887563ich.56.1362607701505; Wed, 06 Mar 2013 14:08:21 -0800 (PST) X-Received: by 10.42.58.67 with SMTP id g3mr32887556ich.56.1362607701389; Wed, 06 Mar 2013 14:08:21 -0800 (PST) Received: from x-128-101-232-75.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:1869:3b36:413e:4b35]) by mx.google.com with ESMTPS id l4sm13689348igw.6.2013.03.06.14.08.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 14:08:20 -0800 (PST) Message-ID: <5137BE53.40104@umn.edu> Date: Wed, 06 Mar 2013 16:08:19 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Lorenzo Colitti References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> <5137561D.5070604@umn.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmNdcPY0hDvBnNQ7FaxXBqGkxjhfm7e8EFt/0v67mD5YsdENMVXPY19grtWWZjzAuywWGW4Rg0Xgq3b2gSrjVHZKatgUFWdY++CgyuOB/gRiKAbmi+JVLq1Ez5659tVquUXqb+l Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 22:08:31 -0000 On 3/6/13 13:03 , Lorenzo Colitti wrote: > On Wed, Mar 6, 2013 at 6:43 AM, David Farmer > wrote: > > If IPv6 fails we have no hope of NAT ever going away. And I'm afraid > that if we insist on a NAT free IPv6, that IPv6 will fail to be > adopted by the masses of Internet users. > > > But... but.. then your argument doesn't fit the data available. > > Because the data at http://www.worldipv6launch.org/measurements/ shows > that IPv6 *IS* being adopted by the masses of Internet users. Aren't > AT&T, Comcast and Verizon Wireless (to name some of the ones in your > country) some of the largest mass market ISPs in the world? Yes, the > enterprise is not going along as eagerly as the ISPs, but the enterprise > wasn't leading the charge towards deploying IPv4 either. > > IPv6 deployment ain't broke. Don't fix it. I know IPv6 can be deployed NAT free, hell I'm doing it. I hope IPv6 will be deployed mostly NAT free, the available data in my opinion suggest that could be true. But, in my opinion there isn't enough available data to conclude that IPv6 will be deployed completely NAT free. In rereading what I said, I'll agree I miss-stated what I'm afraid of, "the masses of Internet users" that is residential users will probably be NAT free for IPv6. I should have said the masses of small to medium enterprise users. I think the jury is still out on how most small to medium enterprises will deploy IPv6, and if it will be NAT free. I'm worried that if we bully them and say "NO NAT for IPv6", they will say fine then "NO IPv6". I hope not. But I prefer the idea of saying "we suggest that your network will be better without NAT, but here is this thing NPTv6 that is a better way to do NAT if you really think you must do NAT for IPv6, but which every way you choose please implement IPv6." Longer range I hope LISP or ILNP become viable solutions for small to medium enterprise users. But honestly NAT is the least worst option for many small to medium enterprise users. Could many of them do PI, sure. Could many do PA and is renumber a little better in IPv6, sure. But, as I said NAT is the least worst option for many of them, with the added benefit from their perspective that IPv6 with NPTv6 is more or less the same thing they are doing for IPv4. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From dougb@dougbarton.us Wed Mar 6 14:14:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3C411E81A5 for ; Wed, 6 Mar 2013 14:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 BiDhM-NVLDUj for ; Wed, 6 Mar 2013 14:14:37 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id DCB2E11E818D for ; Wed, 6 Mar 2013 14:14:37 -0800 (PST) Received: from [192.168.0.102] (home [12.207.105.210]) by dougbarton.us (Postfix) with ESMTPSA id 7993E22B0F for ; Wed, 6 Mar 2013 22:14:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362608077; bh=GdJXGi2+uchfP5jv+SUZtFHEzZYAX4G9n9p/OvfOD5g=; h=Date:From:To:Subject:References:In-Reply-To; b=RqUlrU70OLs3bvtdjYPFTbi3zlTmwJATCK1g/Vx7ibP0kW8yNIH7XBgrnVNZwi2+L v/dpiwhpNTfov3jj3vr94PFZx+SFInnGx3DUHyJveqhQ8+nCXvHtqPXVCQv2uqcpst b1METNYe1QzPqoVatJHqEVIHJ2rLq7rvGtHzMK4o= Message-ID: <5137BFCD.3@dougbarton.us> Date: Wed, 06 Mar 2013 14:14:37 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "v6ops@ietf.org WG" References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <20130306220241.D935E3078F7F@drugs.dv.isc.org> In-Reply-To: <20130306220241.D935E3078F7F@drugs.dv.isc.org> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 22:14:38 -0000 On 03/06/2013 02:02 PM, Mark Andrews wrote: > As far as I can tell the main problem SMB are solving with NAT is > the multi-homing with PA addresses. I've already made clear that IME what you describe is a factor for some, but renumbering is a very important factor for nearly all. Doug From drc@virtualized.org Wed Mar 6 14:15:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDF211E81AD for ; Wed, 6 Mar 2013 14:15:11 -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_33=0.6] 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 pt6fGobhYHr3 for ; Wed, 6 Mar 2013 14:15:10 -0800 (PST) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3079011E818D for ; Wed, 6 Mar 2013 14:15:10 -0800 (PST) Received: from [10.232.248.250] (69-170-40-3.static-ip.telepacific.net [69.170.40.3]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id B281D171E9; Wed, 6 Mar 2013 22:15:08 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: David Conrad In-Reply-To: <5137B897.7080601@dougbarton.us> Date: Wed, 6 Mar 2013 14:15:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> <5137561D.5070604@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> <5137B897.7080601@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 22:15:11 -0000 Hi, On Mar 6, 2013, at 1:43 PM, Doug Barton wrote: > Fair enough ... what's disturbing me at this point however is the = number of people who have written to me privately to say that they = support my viewpoint, but are afraid to speak up on the list. That makes = it hard to judge consensus. Not afraid, just bored beyond all recognition of Yet Another NAT Food = Fight. FWIW, I'm in Doug's camp on this. I long ago gave up on architectural purity. The market will decide = whether ULA+NAT is useful or an abomination. The idea that putting yet = another statement that NAT IS EVIL!!1!! out there will have the same = effect as all the other NAT IS EVIL!!1!! statements in the past: nothing = positive. Documenting the pros and cons in an unbiased, non-religious, = data-backed way would be ideal, but does not appear to be possible in = the IETF. So it goes. Regards, -drc From marka@isc.org Wed Mar 6 15:04:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E0E11E80FD for ; Wed, 6 Mar 2013 15:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 ALLlMN6BgPDX for ; Wed, 6 Mar 2013 15:04:09 -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 6982E11E80E0 for ; Wed, 6 Mar 2013 15:04:09 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id C1A40C9428; Wed, 6 Mar 2013 23:04:03 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1362611049; bh=jCoRgLqlaXcXp/Lmdob5Z9jS1OncuabqX5UxIB3XIO0=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=ccks2xCR/jOHJbqNKjXgkMoEn39BrgBdFaQvhXhnkp8tdiMLLun+hy7cQc3zLj+Ih EfwVWveWngtC+j1twkxGcr5sap2ijkMoqQsORri9JlPIpnfG6RyM0x/Ar1RhHzt2/r wUOcbBLWebrQdGajGCfKMm+5hOZQYtEZEcjFQPeY= 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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Wed, 6 Mar 2013 23:04:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:386e:5ec1:f8b1:1682]) (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 82773216C3B; Wed, 6 Mar 2013 23:04:03 +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 66A693079C97; Thu, 7 Mar 2013 10:03:59 +1100 (EST) To: Doug Barton From: Mark Andrews References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <20130306220241.D935E3078F7F@drugs.dv.isc.org> <5137BFCD.3@dougbarton.us> In-reply-to: Your message of "Wed, 06 Mar 2013 14:14:37 -0800." <5137BFCD.3@dougbarton.us> Date: Thu, 07 Mar 2013 10:03:59 +1100 Message-Id: <20130306230359.66A693079C97@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 23:04:09 -0000 In message <5137BFCD.3@dougbarton.us>, Doug Barton writes: > On 03/06/2013 02:02 PM, Mark Andrews wrote: > > As far as I can tell the main problem SMB are solving with NAT is > > the multi-homing with PA addresses. > > I've already made clear that IME what you describe is a factor for some, > but renumbering is a very important factor for nearly all. > > Doug If I'm NATed and change my provider I need to reconfigure (renumber) my firewall. If I'm NATted and change my provider I need to reconfigure (renumber) in my DNS. The ONLY difference is that I don't change one of my addresses on a interface. I'm making the assumption that SMB is getting "permanent" static PA rather than slightly less permanent PA delivered to residential customers. You don't have to put PA addresses into the internal DNS. You can only put ULA addresses there. You will only use ULA addreses to communicate internally if you do that. I really believe the renumbering issue has been blown all out of proportion as people continue to apply IPv4 think to the issue. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Ted.Lemon@nominum.com Wed Mar 6 15:31:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B301111E80ED for ; Wed, 6 Mar 2013 15:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.208 X-Spam-Level: X-Spam-Status: No, score=-106.208 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3kRSmsdDW6i for ; Wed, 6 Mar 2013 15:31:04 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 2143621F8A1D for ; Wed, 6 Mar 2013 15:31:03 -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 DSNKUTfRt+gLTqJIWyvYCdhFhgMbN82cgG3Q@postini.com; Wed, 06 Mar 2013 15:31:03 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 BEF991B8157 for ; Wed, 6 Mar 2013 15:31:02 -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 B633B190043; Wed, 6 Mar 2013 15:31:02 -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, 6 Mar 2013 15:31:02 -0800 From: Ted Lemon To: Doug Barton Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT Thread-Index: Ac4Y0qVmXOczhdgyTHaW1OIbGrg4zQAVbZqAABAGvAAAAlzXgAAIFLoAAAKCZIAABfkCAAAA0RCAAACcd4AAAOJ/gAAAJRsAAABlxoAAALV/gAADDBMAACbVwgAACCQUAAACcUAAAAIpbgAAB8eKgAABjsKAAA0d1IAAA74lgA== Date: Wed, 6 Mar 2013 23:31:01 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474B213C@mbx-01.win.nominum.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> <5137561D.5070604@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> <5137B897.7080601@dougbarton.us> In-Reply-To: <5137B897.7080601@dougbarton.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307474B213Cmbx01winnominum_" MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 23:31:04 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307474B213Cmbx01winnominum_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 6, 2013, at 4:43 PM, Doug Barton > wrote: To answer Ted's question, the harm isn't technical, and it's naive to think= that we're only dealing with technical issues here. To the extent that peo= ple will actually read the document what I want to avoid is a scenario like= , "Wow, this combination of ULA + NPTv6 really sounds like it would meet my= needs, but the IETF recommends against it. So now what do I do?" No, you didn't answer my question. You just made another non-falsifiable = assertion about the PR effects of advising against a course of action that = everybody who has argued the technical merits has agreed is the right cours= e of action. I conclude that you actually do not have a use case to suppo= rt your claims, and that you just have a strong opinion. The IETF doesn't care about your opinion. We care about the technical mer= its of your argument. And we care about rough consensus and running code.= If that means we are dinosaurs, and that we are doomed, maybe that's okay= . But I really don't think this particular argument is the one that will = doom us. --_000_8D23D4052ABE7A4490E77B1A012B6307474B213Cmbx01winnominum_ Content-Type: text/html; charset="us-ascii" Content-ID: <2AEC5AF54DD788439C00F675727FC76A@nominum.com> Content-Transfer-Encoding: quoted-printable
To answer Ted's question, the harm isn't technical, and it's naive to think t= hat we're only dealing with technical issues here. To the extent that peopl= e will actually read the document what I want to avoid is a scenario like, = "Wow, this combination of ULA + NPTv6 really sounds like it would meet my needs, but the IETF recommends a= gainst it. So now what do I do?"

No, you didn't answer my question.   You just made another non-fa= lsifiable assertion about the PR effects of advising against a course of ac= tion that everybody who has argued the technical merits has agreed is the r= ight course of action.   I conclude that you actually do not have a use case to support your claims, and that you j= ust have a strong opinion.

The IETF doesn't care about your opinion.   We care about the tec= hnical merits of your argument.   And we care about rough consensus an= d running code.  If that means we are dinosaurs, and that we are doome= d, maybe that's okay.   But I really don't think this particular argument is the one that will doom us.

--_000_8D23D4052ABE7A4490E77B1A012B6307474B213Cmbx01winnominum_-- From Ted.Lemon@nominum.com Wed Mar 6 15:32:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0A611E80FF for ; Wed, 6 Mar 2013 15:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.189 X-Spam-Level: X-Spam-Status: No, score=-106.189 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6CImSV8jRFM for ; Wed, 6 Mar 2013 15:32:19 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 1592011E80FC for ; Wed, 6 Mar 2013 15:32:19 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUTfSAs1lPStCq9tHI35KDLcB/nJ8zL5U@postini.com; Wed, 06 Mar 2013 15:32: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 C54F01B8157 for ; Wed, 6 Mar 2013 15:32:18 -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 BEA75190043; Wed, 6 Mar 2013 15:32: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; Wed, 6 Mar 2013 15:32:18 -0800 From: Ted Lemon To: Doug Barton Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT Thread-Index: Ac4Y0qVmXOczhdgyTHaW1OIbGrg4zQAVbZqAABAGvAAAAlzXgAAIFLoAAAKCZIAABfkCAAAA0RCAAACcd4AAAOJ/gAAAJRsAAABlxoAAALV/gAACHAWAACcL2QAAHe3hAAAD7pKAAABPR4AAAE+4AAAAwBSAAADwWwAAA4qWAA== Date: Wed, 6 Mar 2013 23:32:18 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474B2162@mbx-01.win.nominum.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> In-Reply-To: <5137BA3E.4020604@dougbarton.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307474B2162mbx01winnominum_" MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 23:32:23 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307474B2162mbx01winnominum_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 6, 2013, at 4:50 PM, Doug Barton > wrote: or dealing with the trouble and expense of PI space. Do you have any figures on that that you can offer? --_000_8D23D4052ABE7A4490E77B1A012B6307474B2162mbx01winnominum_ Content-Type: text/html; charset="us-ascii" Content-ID: <85DF8217FE2A0243A8679F6CB34DB809@nominum.com> Content-Transfer-Encoding: quoted-printable
On Mar 6, 2013, at 4:50 PM, Doug Barton <dougb@dougbarton.us> wrote:
 or dealing with the trouble and expense of PI space.

Do you have any figures on that that you can offer?

--_000_8D23D4052ABE7A4490E77B1A012B6307474B2162mbx01winnominum_-- From drc@virtualized.org Wed Mar 6 15:42:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69DE21F8A3E for ; Wed, 6 Mar 2013 15:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] 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 5oxwmof0gvYI for ; Wed, 6 Mar 2013 15:42:30 -0800 (PST) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 68EE221F879D for ; Wed, 6 Mar 2013 15:42:30 -0800 (PST) Received: from [10.0.1.4] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id CD87E171E9; Wed, 6 Mar 2013 23:42:29 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_A08283F8-6D99-486B-BDA5-2D966A68A4DD" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: David Conrad In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474B2162@mbx-01.win.nominum.com> Date: Wed, 6 Mar 2013 15:42:21 -0800 Message-Id: <709A43C8-3D68-49D6-98DA-631E84C78075@virtualized.org> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B2162@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1499) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 23:42:31 -0000 --Apple-Mail=_A08283F8-6D99-486B-BDA5-2D966A68A4DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ted, On Mar 6, 2013, at 3:32 PM, Ted Lemon wrote: > On Mar 6, 2013, at 4:50 PM, Doug Barton wrote: >> or dealing with the trouble and expense of PI space. >=20 > Do you have any figures on that that you can offer? Trouble: Obviously a subjective evaluation. I'd recommend getting a PI block for = yourself, after all, according to some on this list, it is painless and = the cost inconsequential. Expense: http://www.afrinic.net/en/services/rs/membership-fees http://www.apnic.net/services/become-a-member/how-much-does-it-cost https://www.arin.net/fees/fee_schedule.html http://www.lacnic.net/en/web/lacnic/membresia-costo = http://www.ripe.net/lir-services/member-support/become-a-member/membership= -fees/membership-fees Regards, -drc --Apple-Mail=_A08283F8-6D99-486B-BDA5-2D966A68A4DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Ted.Lemon@nominum.com> = wrote:
On Mar 6, 2013, at 4:50 PM, Doug Barton = <dougb@dougbarton.us> = wrote:
 or dealing with the trouble and expense of PI space.
Do you have any figures on that that you can offer?
=

Trouble:

Obviou= sly a subjective evaluation.  I'd recommend getting a PI block for = yourself, after all, according to some on this list, it is painless and = the cost = inconsequential.

Expense:

http://www.= afrinic.net/en/services/rs/membership-fees

Regards,
-drc

= --Apple-Mail=_A08283F8-6D99-486B-BDA5-2D966A68A4DD-- From farmer@umn.edu Wed Mar 6 15:52:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826AA21F8B60 for ; Wed, 6 Mar 2013 15:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 Xm1YI-7v2QMS for ; Wed, 6 Mar 2013 15:52:29 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 9905521F88B6 for ; Wed, 6 Mar 2013 15:52:27 -0800 (PST) Received: from mail-oa0-f70.google.com (mail-oa0-f70.google.com [209.85.219.70]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Wed, 6 Mar 2013 17:52:18 -0600 (CST) X-Umn-Remote-Mta: [N] mail-oa0-f70.google.com [209.85.219.70] #+LO+TR X-Umn-Classification: local Received: by mail-oa0-f70.google.com with SMTP id h2so53153739oag.1 for ; Wed, 06 Mar 2013 15:52:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=1X4QrPmGUZSp8y1cP9p4TdmqAkIWqddkQkl5dgAStnk=; b=fOfdtmoK3Sg8c8li0ciydqqXdXkL3q+frTHekEYYh2NEdmJSgjS6V/pbyTjXq/8o4c yH25uTlm0rBKHzr5avzy/kKn9P5hAAf+YUv4mI6XeTJ0VK8oGs4Ew4hed1D/pr3QxSuE IJrZEzYlgzv96z+f/vzfgAI55O4EpKmD3fbNV6xVOXyusitH1azKLiO5mifkuBolyX0C 3JQq8uJb972TdVSsBHawo04yoYWhtlc3EKzSt01/oYQyITrVmkaeCdcLAIhVa4ppfRHZ Y/wwC+UpbMDYGyVZLFltwi5I13bfFGiIz7t6QqQfe6Jlv3fhjX6eb2xGjaoZ62jU6qA1 Fh7w== X-Received: by 10.50.180.197 with SMTP id dq5mr12586777igc.22.1362613937425; Wed, 06 Mar 2013 15:52:17 -0800 (PST) X-Received: by 10.50.180.197 with SMTP id dq5mr12586769igc.22.1362613937312; Wed, 06 Mar 2013 15:52:17 -0800 (PST) Received: from x-128-101-232-75.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:9c17:33e9:b428:61cc]) by mx.google.com with ESMTPS id qn10sm24722620igc.6.2013.03.06.15.52.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 15:52:15 -0800 (PST) Message-ID: <5137D6AA.1010802@umn.edu> Date: Wed, 06 Mar 2013 17:52:10 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Lorenzo Colitti References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <5137B118.8040904@dougbarton.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnSadcPPM8UMzHWSpmvosummh2DjoBVoByQyjjfYUJCS5rnaxfVb+k5VLcpJH6CsrPNiPU90SlSzswwqO6IKKuI6zpj1pWBxy4RqdpstIgRCNbRAAanwOlnmL0YY3N4TwANUZt7 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 23:52:30 -0000 On 3/6/13 15:27 , Lorenzo Colitti wrote: > On Wed, Mar 6, 2013 at 1:11 PM, Doug Barton > wrote: > > So perhaps you would consider writing up a draft to describe your > deployment experience, how robust the solutions are under actual > testing, etc. I keep hearing from people that this problem isn't > solved yet. If you have solid evidence to the contrary it would be > most welcome. > > > Please read and comment on > http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6 > . KK is one of the authors and one of the people behind Google's > enterprise IPv6 deployment. So here is what that draft has to say on the subject; 3.1. Connectivity .... The use of ULAs may provide additional flexibility when an enterprise is using PA space, by providing an independent local prefix for internal use, while using the PA prefix externally in conjunction with NPTv6 [RFC6296]. Many enterprises today are used to using IPv4 host-based NAT, and indeed may choose to use this model even when global IPv4 address space is available. NPTv6 instead performs stateless prefix-based NAT, mapping from an external global prefix to (usually) an internal ULA prefix. Such mappings can be used with multiple prefixes in multihoming scenarios, rather than using both ISP's global prefixes internally, with hosts receiving an IPv6 address from each prefix (and then needing to ensure the correct source address is used to route traffic out of the correct egress). While NPTv6 can provide for simplified renumbering in certain scenarios, as described in [I-D.ietf-6renum-enterprise], it must be noted that many of the well-known issues with NAT still apply, in particular handling IPv6 addresses embedded in payloads. .... 3.5. Network Prefix Translation for IPv6 Network Prefix Translation for IPv6, or NPTv6 as described in [RFC6296] provides a framework to utilize prefix ranges within the internal network which are separate (address-independent) from the assigned prefix from the upstream provider or registry. As mentioned above, while NPTv6 has potential use-cases in IPv6 networks, the implications of its deployment need to be fully understood, particularly where any applications might embed IPv6 addresses in their payloads. Use of NTPv6 can be chosen independently from how addresses are assigned and routed within the internal network and how prefixes are routed towards the Internet (included both PA and PI address assignment options). This seems like a very reasonable treatment of the issue, to me. But, I don't see any explicit recommendation against the use of NPT or NAT other than by reference to RFC 6296. Please explain why it is necessary for this draft about the use of ULA to include an explicit recommendation against the use of NPT or NAT? I'd be happy with the inclusion of something like above "the implications of its deployment need to be fully understood", especially given that RFC 6296 has an Experimental Status. But that is much different than an explicit recommendation against the use of NPT or NAT. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From marka@isc.org Wed Mar 6 16:34:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E367B21F8706 for ; Wed, 6 Mar 2013 16:34:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azRpCMjwoxAn for ; Wed, 6 Mar 2013 16:34:27 -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 07FDF21F86F5 for ; Wed, 6 Mar 2013 16:34:27 -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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id B4E735F995F; Thu, 7 Mar 2013 00:34:15 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1362616466; bh=0aoazMtb/ZKKXnmkocrhggcYwyQNVNVuu89HD0rBPhQ=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=jwSmsPGx4aNJh814QwBntJAWz8NN/sTm48y7KbgHmE7cFNc0dzEpVWGMQeQLwmEkM u8z0zDRalkOtMtNPg0eM2Wgjfa/Fr8u3bYzVbY1ANNta9ELCqMfLdZsBXWq1CBMBrs MkEBUxpbMbCK3DDkch5GjCMek7y45C/GKgdVAZk4= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 CF964216C3B; Thu, 7 Mar 2013 00:34:13 +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 C8A42307C508; Thu, 7 Mar 2013 11:34:08 +1100 (EST) To: "Marksteiner, Stefan" From: Mark Andrews References: <8A317FD8C00FEE448E52D4EE5B56BB3E02513FBE2301@RZJC1EX.jr1.local> <3AC1A1D6-6ED1-4A3E-BE7A-AE5306A3E6CC@delong.com> <8A317FD8C00FEE448E52D4EE5B56BB3E02513FBE2324@RZJC1EX.jr1.local> <8A317FD8C00FEE448E52D4EE5B56BB3E02513FBE2356@RZJC1EX.jr1.local> In-reply-to: Your message of "Wed, 06 Mar 2013 18:02:31 BST." <8A317FD8C00FEE448E52D4EE5B56BB3E02513FBE2356@RZJC1EX.jr1.local> Date: Thu, 07 Mar 2013 11:34:08 +1100 Message-Id: <20130307003408.C8A42307C508@drugs.dv.isc.org> Cc: "'v6ops@ietf.org'" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 00:34:28 -0000 In message <8A317FD8C00FEE448E52D4EE5B56BB3E02513FBE2356@RZJC1EX.jr1.local>, "M arksteiner, Stefan" writes: > Hi, > > firstly I want to recall, that I don't want to replace any security > measure whatsoever by private addressing (as the trust argument below > might suggest), but only to use it additionally to use it as a (yes, very > thin) "coating on the armor", whereas a botched firewall rule might be > the "rust" against which it is protecting (and yes again, protecting is a > strong word for that) . Of course it could be circumvented, it just > wanted to say that if you deploy security techniques at perimeter and > LAN-level, it might be a good idea to do something on an organizational > or network design level as well. IMHO, every layer of protection, as thin > as it might be, helps. > > That being said, I must state that I'm not so afraid of giving a false > sense of security by using ULAs. People who are tricked to thinking they > are safe this way are the same people who think security is done by > installing a firewall, you can't help them anyway. Generating awareness > is (and always was) the most crucial thing when it comes to security - > but this shouldn't affect the fact that every tiny step towards a more > secure network might actually help (even if it's only to back up little > flaws), the more as it is a step that doesn't cost anything (which is > always the strongest enemy of security). If NAT didn't have a continual on going costs on everyone in the industry you would be seeing less objections. NAT is like lead in petrol. You needed it once. You don't need it now. NAT is a toxic pollutant. > I'm of course totally with you in terms of nobody should RELY on methods > which were never intended to be security features. > > Cheers, > > Stefan > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From farmer@umn.edu Wed Mar 6 18:11:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BC211E80C5 for ; Wed, 6 Mar 2013 18:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.085 X-Spam-Level: X-Spam-Status: No, score=-6.085 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 dhV025lJnbKS for ; Wed, 6 Mar 2013 18:11:12 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 9794521F867E for ; Wed, 6 Mar 2013 18:11:03 -0800 (PST) Received: from mail-ia0-f199.google.com (mail-ia0-f199.google.com [209.85.210.199]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Wed, 6 Mar 2013 20:10:51 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ia0-f199.google.com [209.85.210.199] #+LO+TR X-Umn-Classification: local Received: by mail-ia0-f199.google.com with SMTP id w21so6240438iac.10 for ; Wed, 06 Mar 2013 18:10:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=kg35acNVlPUh1++q3S7ciptKPeeETVkIJ7J7qp8PJNo=; b=o4yo8PFz1Mecja+pWjUwT8s12eYr6EIDwkac+CCmU0T+ghTCLbBXBOD+6405UhCcDh MtuYiN7MQabfcAiR6Tk+IT3UPS807Lqx3U19yPjmwyzVjNy3IcKE8bxBNMxi7fZdvvUw 53IO+od2LUDCdN4WOY+SiOM7xO96CCeDeZxOsPIdtzgxyU6IfXOrIV5X5ip2oZa5AZVf OuGF16amdUkL7BvteMrW+VIWPDQYbpkcu7bA22vcPxFDSaXPX+s2rAXaabgvwwqzu13R 2T/0YQ2zuhCNr5AaIvBuvnkkpW4HIUrQSUEf30V0zT2FbBvRm8EDW4/5+rYLLQLK28/M W66Q== X-Received: by 10.42.247.8 with SMTP id ma8mr32908055icb.1.1362622251303; Wed, 06 Mar 2013 18:10:51 -0800 (PST) X-Received: by 10.42.247.8 with SMTP id ma8mr32908048icb.1.1362622251221; Wed, 06 Mar 2013 18:10:51 -0800 (PST) Received: from x-128-101-232-75.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:9c17:33e9:b428:61cc]) by mx.google.com with ESMTPS id i10sm25258309igz.9.2013.03.06.18.10.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 18:10:49 -0800 (PST) Message-ID: <5137F729.8080108@umn.edu> Date: Wed, 06 Mar 2013 20:10:49 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Doug Barton References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <5137B118.8040904@dougbarton.us> In-Reply-To: <5137B118.8040904@dougbarton.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQktksEZCvyWHBU09nbXah8CWyAYr4ilefWfWezaOSKtCE/6NiE+kFOZDMdEkYMazOlIKrMn5HDPT2Ey26SEDDXllVRE4HkrIZ62aw7ZJSDBmYx4WqhzsG6ARQ/caGBJB6534rEb Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Rogue RAs was: ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 02:11:12 -0000 On 3/6/13 15:11 , Doug Barton wrote: > On 03/06/2013 01:06 PM, Lorenzo Colitti wrote: >> On Wed, Mar 6, 2013 at 1:02 PM, Doug Barton > > wrote: >> >> we have solutions for rogue RAs. >> >> >> Did you bring enough to share with the group? :) >> >> >> I think we're using the ones recommended by the IETF... > > So perhaps you would consider writing up a draft to describe your > deployment experience, how robust the solutions are under actual > testing, etc. I keep hearing from people that this problem isn't solved > yet. If you have solid evidence to the contrary it would be most welcome. We have a basic IPv6 inbound ACL on every wired access port blocking RAs and DHCP server responses for IPv4 and IPv6. By the way, IPv6 ACL support was a requirement when we selected our current switches in 2004. We also announce the RA from our routers with high priority. The later is necessary because our enterprise wireless solution doesn't support IPv6 ACLs yet. These techniques are discussed in RFC 6104. IPv6 ACLs or an automated RA-Guard, RFC 6105, block most rouge RAs caused by basic malicious activity or simple misconfiguration. Setting your routers RAs to high priority can deal with rogue RAs caused by simple misconfiguration in most cases. Draft-ietf-v6ops-ra-guard-implementation addresses some ways malicious activity can evade basic Rouge RA mitigation. That said the we haven't seen malicious activity in the wild. But, until we implemented the above techniques rogue RAs from simple misconfiguration were a huge issue. The above techniques have made our IPv6 network very stable. There is one additional technique we have used, that is filtering IPv6 traffic all together with a 86DD Ether-Type filter. This is a drastic solution, but is necessary in one part of our network. We have IPv6 enabled on our 802.1x/WPA2-enterprise authenticated wireless network, but the authentication portal for our web-portal authenticated wireless network doesn't support redirection of IPv6 traffic. Therefore, we filter all IPv6 traffic on the web-portal authenticated wireless network to prevent rogue RAs and make our entire network AAAA record safe. Bad or rogue IPv6 is worse than no IPv6. We are working with our enterprise wireless vendor to support IPv6 on their authentication portal and I believe it is a committed feature for a future release. Hope that helps. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From leo.liubing@huawei.com Wed Mar 6 18:17:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFE311E80C5 for ; Wed, 6 Mar 2013 18:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.57 X-Spam-Level: X-Spam-Status: No, score=-5.57 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, 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 5ET6WUDKx+Qw for ; Wed, 6 Mar 2013 18:17:15 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6B15B11E809C for ; Wed, 6 Mar 2013 18:17:14 -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 APC40669; Thu, 07 Mar 2013 02:17:13 +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.7; Thu, 7 Mar 2013 02:17:00 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 7 Mar 2013 02:17:12 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.42]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.01.0323.007; Thu, 7 Mar 2013 10:17:06 +0800 From: "Liubing (Leo)" To: David Farmer , Ted Lemon Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT Thread-Index: Ac4Y0qVmXOczhdgyTHaW1OIbGrg4zf//nzSAgACANgCAABLmgIAAQKYAgAAUE4CAAC/IAIAABomAgAAE5ICAAAcUgIAAASgAgAADL4CAAAWsgIAAGGAAgAE2rgCAAEEhAIAAE4oAgAARSwCAAD49gIAADHcAgAAX7wCAAAIRAIAACSMA//7sZ5A= Date: Thu, 7 Mar 2013 02:17:05 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6E6DFE@nkgeml506-mbx.china.huawei.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> <5137561D.5070604@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> <513774A6.9070508@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B106A@mbx-01.win.nominum.com> <51377E0C.3020504@umn.edu> In-Reply-To: <51377E0C.3020504@umn.edu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 02:17:17 -0000 Hi, David > There is an example provided in the draft, read it. Rereading the > draft, section 2.2.2.1, ULA-only Deployment, seems to imply that > ULA-only Deployment is a special use case of ULA and not the generally > intended deployment model.=20 [Bing] ULA-only is recommended in isolated networks especially when multipl= e subnets are required, I think it might be the most solid use case of ULA = so far. Please see section 2.2.1 and 3.1, the texts are not explicit of "UL= A-only", maybe I need to revise it in the next ver. For connected networks, I agree with you ULA-only is not the generally inte= nded deployment model. > I would support making a more explicit > recommendation against the use of ULA-only Deployment model, especially > for general purpose connectivity. =20 [Bing] In my understanding, using ULA-only in a connected network, is not d= etermined from the ULA perspective, but from the perspective of whether the= y decide to use NAT things to gain address independence without acquiring P= I, or Proxy things to gain central security control of the outgoing traffic= . If they've decided to do such things, then ULA is a very proper choice. >=20 >=20 > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David Farmer Email: farmer@umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > =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=3D > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From leo.liubing@huawei.com Wed Mar 6 18:25:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCC721F84C2 for ; Wed, 6 Mar 2013 18:25:52 -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_33=0.6, 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 zAJ2eVm1dziO for ; Wed, 6 Mar 2013 18:25:51 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EEA5B21F84DC for ; Wed, 6 Mar 2013 18:25:47 -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 AQJ59205; Thu, 07 Mar 2013 02:25:47 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 7 Mar 2013 02:25:33 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 7 Mar 2013 02:25:46 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.42]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Thu, 7 Mar 2013 10:25:43 +0800 From: "Liubing (Leo)" To: David Farmer , Ted Lemon Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT Thread-Index: Ac4Y0qVmXOczhdgyTHaW1OIbGrg4zf//nzSAgACANgCAABLmgIAAQKYAgAAUE4CAAC/IAIAABomAgAAE5ICAAAcUgIAAASgAgAADL4CAAAWsgIAAGGAAgAE2rgCAAEEhAIAAE4oAgAARSwCAAD49gIAADHcAgAAX7wD//txcoA== Date: Thu, 7 Mar 2013 02:25:42 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6E6E0F@nkgeml506-mbx.china.huawei.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> <5137561D.5070604@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> <513774A6.9070508@umn.edu> In-Reply-To: <513774A6.9070508@umn.edu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 02:25:52 -0000 Hi, David > This document is not about NPT or NAT it is about ULA and how it should > be used. That said, I don't think you can fully discuss ULA without at > least talking about its use in NPT, its in RFC 6296 (NPTv6) after all. > But, the current draft is not recommend ULA for NPT it is only > recognized as valid, but not recommended, use case for ULA. [Bing] Agreed. Thank you for helping me clarify it. =20 > So, you asked whats the harm here? Well a necessary discussion of the > proper uses of ULA is being completely overshadowed by a relatively > minor but valid part of the discussion, NPT. [Bing] I think the discussion of NAT in this thread is meaningful, it helpe= d us understand more in this topic. But for the specific ULA draft, I agree with you, it seems a little bit ove= rshadowing. All the best, Bing From Ted.Lemon@nominum.com Wed Mar 6 18:51:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6152321F86A5 for ; Wed, 6 Mar 2013 18:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.173 X-Spam-Level: X-Spam-Status: No, score=-106.173 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eE-hW+dXQKTs for ; Wed, 6 Mar 2013 18:51:15 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id C15F621F868F for ; Wed, 6 Mar 2013 18:51:15 -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 DSNKUTgAoxkJuNj78fv4IuS3NeHdc3so9tKf@postini.com; Wed, 06 Mar 2013 18:51: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 6654F1B8158 for ; Wed, 6 Mar 2013 18:51: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 5DE2F190043; Wed, 6 Mar 2013 18:51: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; Wed, 6 Mar 2013 18:51:15 -0800 From: Ted Lemon To: David Conrad Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT Thread-Index: Ac4Y0qVmXOczhdgyTHaW1OIbGrg4zQAVbZqAABAGvAAAAlzXgAAIFLoAAAKCZIAABfkCAAAA0RCAAACcd4AAAOJ/gAAAJRsAAABlxoAAALV/gAACHAWAACcL2QAAHe3hAAAD7pKAAABPR4AAAE+4AAAAwBSAAADwWwAAA4qWAAAAWduAAAaYmYA= Date: Thu, 7 Mar 2013 02:51:14 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474B28A5@mbx-01.win.nominum.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B2162@mbx-01.win.nominum.com> <709A43C8-3D68-49D6-98DA-631E84C78075@virtualized.org> In-Reply-To: <709A43C8-3D68-49D6-98DA-631E84C78075@virtualized.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307474B28A5mbx01winnominum_" MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 02:51:16 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307474B28A5mbx01winnominum_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 6, 2013, at 6:42 PM, David Conrad > wrote: Obviously a subjective evaluation. I'd recommend getting a PI block for yo= urself, after all, according to some on this list, it is painless and the c= ost inconsequential. Based on the links you sent, it seems like the answer to "how expensive is = a PI" is "not very." --_000_8D23D4052ABE7A4490E77B1A012B6307474B28A5mbx01winnominum_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Mar 6, 2013, at 6:42 PM, David Conrad <drc@virtualized.org> wrote:
Obviously a subjective evaluation.  I'd recommend getting a PI block f= or yourself, after all, according to some on this list, it is painless and = the cost inconsequential.

Based on the links you sent, it seems like the answer to "how exp= ensive is a PI" is "not very."

--_000_8D23D4052ABE7A4490E77B1A012B6307474B28A5mbx01winnominum_-- From owen@delong.com Wed Mar 6 19:35:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C5A21F8522 for ; Wed, 6 Mar 2013 19:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 Sp6FCMOdTE5D for ; Wed, 6 Mar 2013 19:35:56 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 69D8421F8441 for ; Wed, 6 Mar 2013 19:35:55 -0800 (PST) Received: from [10.255.251.216] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r273ZDsi007214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 6 Mar 2013 19:35:14 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r273ZDsi007214 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362627314; bh=tQN4lEsQM1f9Vhb7wglfDFaUh2s=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=e3/BF6TnmXqaQZX82eBnwX/QRQfDtL9x5ziau5ZaROumEArnpvppHvcAfa0PXtsgi Ze8FGOrFX9npHW1jXU3oM8K0ABUMWJWSdGE8sx1au435TXmq72fOM6nLdc6WwQYBVc CP2HaS+u0x0D9gyq316W+XYv3TIcKfhjDaR/zzX0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <5137AABD.1050401@dougbarton.us> Date: Wed, 6 Mar 2013 19:35:12 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 06 Mar 2013 19:35:14 -0800 (PST) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 03:35:57 -0000 > And, even if those problems are solved, we hear from a non-trivial = number of operators who have actually taken the time to dig into a = potential IPv6 deployment that their next "can't deploy IPv6 because of = X" problem is the concern about rogue RAs, and we still don't have a = robust solution for that, and don't get me started on ND abuse If you want to claim your focused on the SME, then let's look at these = problems from an SME perspective. 1. At its worst, rogue RAs and ND abuse are no worse than ARP = attacks and rogue DHCP servers in IPv4. The available solutions today are roughly equally robust. 2. Rogue RAs come in two flavors. Accidental and Malicious. I am not aware of any case where Accidental rogue RAs are likely = to be HIGH priority. Setting your valid RAs to high priority will automatically = override the accidental ones. In the case of Malicious rogue RAs, the attacker has to be = directly attached to your local link. In that case, the RAs really are low on your list of = concerns compared to many of the other things Mr. attacker can be doing with that access. As Lorenzo said, those of you that don't want to deploy IPv6 because = "dunwanna" are very good at proposing all manner of legitimate problems = that should be solved as "show-stoppers". Yes, we've been doing a = pretty good job playing whack-a-mole on the ones that should get solved = through protocol updates and you're running out. NAT-alike, Rogue-RA, and ND abuse are pretty much all you've got left in = that arsenal. NAT-alike isn't a protocol problem, it's an educational problem. Solving = it in the protocol would be a (potentially) catastrophic mistake, IMHO. Rogue-RA is a valid concern, but not really a show-stopper.=20 ND abuse is also being worked and also not really a show-stopper in = terms of impact and in terms of attacker requirements. Owen From owen@delong.com Wed Mar 6 19:56:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268F511E80A3 for ; Wed, 6 Mar 2013 19:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.812 X-Spam-Level: X-Spam-Status: No, score=-1.812 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 V5nMULrckYjz for ; Wed, 6 Mar 2013 19:56:00 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B0E6D21F87F5 for ; Wed, 6 Mar 2013 19:55:56 -0800 (PST) Received: from [10.255.251.216] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r273ppYJ007987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 6 Mar 2013 19:51:52 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r273ppYJ007987 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362628312; bh=CPwZbHkJWWkqNZIKT/SFyOTeM3U=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=NGEo4KTGvFKjaYupHlhx4HMxpSnafnZitwqOAz8V0uNvBed+dh6au8TV/Kr8sOp6D Ckq0+SkswM88rqLwj4trvhMmD7SUacSkAI67YFbqhX7Woa7aTaQYFsHYzAmhcp63j/ T+ZfH6nAjY/orpkzSmSOc5mMrq6jt7HqKFwukSbk= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <5137B897.7080601@dougbarton.us> Date: Wed, 6 Mar 2013 19:51:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <10149973-5DA0-4B51-AEB7-1AC04B9981BB@delong.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> <5137561D.5070604@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> <5137B897.7080601@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 06 Mar 2013 19:51:52 -0800 (PST) Cc: v6ops@ietf.org Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 03:56:01 -0000 On Mar 6, 2013, at 1:43 PM, Doug Barton wrote: > On 03/06/2013 07:28 AM, Ted Lemon wrote: >> On Mar 6, 2013, at 9:43 AM, David Farmer > > wrote: >>> My question to Owen and Doug is where do you think this argument is >>> going? >=20 > Owen wants an explicit recommendation _against_ NPT, I suggested that = a rational, fair discussion of the pros and cons of each possible = solution would be a lot more useful to the intended audience. Then let = them decide on their own. >=20 > To answer Ted's question, the harm isn't technical, and it's naive to = think that we're only dealing with technical issues here. To the extent = that people will actually read the document what I want to avoid is a = scenario like, "Wow, this combination of ULA + NPTv6 really sounds like = it would meet my needs, but the IETF recommends against it. So now what = do I do?" I think that's EXACTLY the desired effect. That's not harm, that's = beneficial. That leads to the enterprise administrator doing more research into the = problems caused by NAT/NPT and perhaps realizing that with large address = space and other IPv6 features, there are, in fact, other ways to meet = his needs that he might not have discovered if he'd just gone blindly = down the "NAT worked in IPv4, let's do that in IPv6" road. Again, not harm, benefit. > The other harm is by continuing the ivory tower "NAT causes birth = defects!" line we make the IETF increasingly anachronistic every day, = since we are demonstrating rather clearly that we're entirely deaf to = the needs of real world network operators. I guess I'm confused=85 I'm pretty sure that Lorenzo and I are "real = world network operators". NAT/NPT does real harm to network operations = and not just on the networks where it is deployed. Do you actually = operate a network? If not, why aren't any of these "real world network = operators" on the list supporting your cause? >>> I'm getting sick and tired of hearing this debate on one >>> mailing list or another every 3 to 6 months. You guys are not going >>> to shout the other down, so stop trying. >=20 > I'm not trying to shout Owen or Lorenzo down, what I want to do = (especially on the non-IETF lists) is demonstrate that there is another = perspective, no matter how much some folks like to state that their view = is the only right one. There are many other perspectives. However, when it comes to developing = standards that are used to document operational practices on the = internet and make recommendations to network operators, it is my opinion = that we should do everything in our power to discourage harmful = practices. I think that David's proposed language is weaker than what I would like = to see, but I could tolerate it. > Fair enough ... what's disturbing me at this point however is the = number of people who have written to me privately to say that they = support my viewpoint, but are afraid to speak up on the list. That makes = it hard to judge consensus. Decisions are made by those who show up. If they want their voices = heard, they should speak up. I'm not sure what they are afraid of. They = don't even have to read the replies if they don't want to, but failing = to say anything means you should expect not to have your input = considered since you didn't give any. > My other concern is that while "consensus," rough or not, is a great = goal, having what we produce align with reality and meet the needs of = operators looking to deploy IPv6 is a more important one. It doesn't = matter that we all agree on something if we're all wrong. It's not like I asked for a statement that said "NPT is prohibited by = IETF standards and any deployment of NAT in a network is not in = compliance." I just want a statement along the lines of: "Deploying NAT or NPT in a connected IPv6 network is not recommended." > Certainly not. I think it makes sense for a majority of organizations = in one particular category, the small - medium enterprise. But even for = many of them, as others have pointed out, PI space announced by their = ISP would be _preferable_, it may just not be realistic. Not realistic how? It's very easy to obtain PI space. It's relatively = inexpensive (from an enterprise perspective). > Even phrasing the issue this way seems to imply a fairly insulting = bias against people who have looked at the needs of their enterprise and = come to the conclusion that something like NPTv6 + ULA is the right = answer. The fact that you still see the problem as, "They just don't = understand IPv6" is a partial answer to David's question about why I = keep repeating myself about how these people think. Yes, you've repeatedly expressed that they don't want to fully = understand IPv6 and want to do in IPv6 exactly what they've done in IPv4 = regardless of who it hurts. I think his phrasing reflects what you have = said rather accurately. If you meant to say something different, it's = not evident in your writings. Owen From leo.liubing@huawei.com Wed Mar 6 19:58:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C584521F882F for ; Wed, 6 Mar 2013 19:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.865 X-Spam-Level: X-Spam-Status: No, score=-5.865 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 aikrRwTxhH1L for ; Wed, 6 Mar 2013 19:58:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3454521F8763 for ; Wed, 6 Mar 2013 19:58:23 -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 AQJ65199; Thu, 07 Mar 2013 03:58:21 +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.7; Thu, 7 Mar 2013 03:58:02 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 7 Mar 2013 11:58:16 +0800 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.42]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.01.0323.007; Thu, 7 Mar 2013 11:58:13 +0800 From: "Liubing (Leo)" To: Ted Lemon , David Farmer Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT Thread-Index: Ac4Y0qVmXOczhdgyTHaW1OIbGrg4zf//nzSAgACANgCAABLmgIAAQKYAgAAUE4CAAC/IAIAABomAgAAE5ICAAAcUgIAAASgAgAADL4CAAAWsgIAAGGAAgAE2rgCAAEEhAIAAE4oAgAARSwCAAD49gIAADHcA//62+sA= Date: Thu, 7 Mar 2013 03:58:11 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6E6E84@nkgeml506-mbx.china.huawei.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> <5137561D.5070604@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D6E6E84nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 03:58:31 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D6E6E84nkgeml506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Ted I mean to ask you, what _technically_ will go wrong if we recommend against= NAT/NPT? What is your use case where NAT/NPT is _required_ not by person= al preference but because there is no other way to solve the problem? [Bing] In section 2.6 of RFC5902: "At present, the primary benefits one may receive from deploying NAT appear= to be avoiding renumbering, facilitating multihoming without impacting rou= ting scalability, and making edge consumer network configurations homogenou= s." In section 4, it discussed solution space for renumbering and multihoming w= ithout NAT. But they are not perfect, e.g. routing scalability issue of PI= . That is to say, we do have other way to solve the problems, but it may also= bring us other issues. In my understanding, in RFC5902, the IETF just tend= to encourage people working on the other ways by considering E2E transpare= ncy the higher priority. So I think maybe it is not an all-or-none issue of recommending against NAT= /NPT or not. It seems there is a controversial grey zone here, maybe just r= eferring the relevant discussion in RFC5902 and RFC6296 is sufficient enoug= h for this specific ULA draft. Best regards, Bing --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D6E6E84nkgeml506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Ted

 = ;

I mean to ask you, what _techni= cally_ will go wrong if we recommend against NAT/NPT?   What is your u= se case where NAT/NPT is _required_ not by personal preference but because = there is no other way to solve the problem?

 

 = ;

[Bing] In = section 2.6 of RFC5902:

“At present, the primary benefits one may =
receive from deploying NAT appear to be avoiding renumbering, facilitating =
multihoming without impacting routing scalability, and making edge consumer=
 network configurations homogenous.”=

 = ;

In section= 4, it discussed solution space for renumbering and multihoming without NAT= .  But they are not perfect, e.g. routing scalability issue of PI.

That is to= say, we do have other way to solve the problems, but it may also bring us = other issues. In my understanding, in RFC5902, the IETF just tend to encourage people working on the other ways by considering E2E tran= sparency the higher priority.

So I think= maybe it is not an all-or-none issue of recommending against NAT/NPT or no= t. It seems there is a controversial grey zone here, maybe just referring the relevant discussion in RFC5902 and RFC6296 is sufficien= t enough for this specific ULA draft.

 = ;

Best regar= ds,

Bing<= /o:p>

 = ;

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D6E6E84nkgeml506mbxchi_-- From owen@delong.com Wed Mar 6 20:01:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC4D21F8613 for ; Wed, 6 Mar 2013 20:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 plmLrq8UnMjV for ; Wed, 6 Mar 2013 20:01:08 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE8E21F8489 for ; Wed, 6 Mar 2013 20:01:07 -0800 (PST) Received: from [10.255.251.216] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2740jZ9008268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 6 Mar 2013 20:00:46 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2740jZ9008268 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362628846; bh=jWdrcVIG+7EAaG/T01skPWV61mE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=c/4XPAAKPRILt7KsWIndoXHkNxZbHpz5qXreRGWWUrC7P1jGIwj/0/PBZp5e+0r8t cI/rJm6BWnwM9aGm8Jb0DeJZ+BgrgjbbovchV5ExwG44W2YN0ZMaiXcyIJRFujGB57 w39yj6ky3aCdajhsCjU7ZwiLpavBh368iZn+XW+4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <5137D6AA.1010802@umn.edu> Date: Wed, 6 Mar 2013 20:00:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <58A8A809-CA1C-48B3-BA5C-D458DC43D25B@delong.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <5137B118.8040904@dougbarton.us> <5137D6A! A.1010802@umn.edu> To: David Farmer X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 06 Mar 2013 20:00:46 -0800 (PST) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 04:01:08 -0000 >=20 > This seems like a very reasonable treatment of the issue, to me. But, = I don't see any explicit recommendation against the use of NPT or NAT = other than by reference to RFC 6296. Please explain why it is necessary = for this draft about the use of ULA to include an explicit = recommendation against the use of NPT or NAT? >=20 > I'd be happy with the inclusion of something like above "the = implications of its deployment need to be fully understood", especially = given that RFC 6296 has an Experimental Status. But that is much = different than an explicit recommendation against the use of NPT or NAT. Along those lines, how about the following statement: "Use of NPT or NAT comes with a number of detrimental implications which = should be fully considered and understood prior to any deployment of = these technologies." Owen From Ted.Lemon@nominum.com Wed Mar 6 20:20:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0904721F884A for ; Wed, 6 Mar 2013 20:20:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.16 X-Spam-Level: X-Spam-Status: No, score=-106.16 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9N24xTthAk0k for ; Wed, 6 Mar 2013 20:20:03 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3A66021F883A for ; Wed, 6 Mar 2013 20:20:03 -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 DSNKUTgVc9CfbpagVmnUGSBCNsZt8BZ5nt8H@postini.com; Wed, 06 Mar 2013 20:20:03 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 DAA891B82CA for ; Wed, 6 Mar 2013 20:20: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 D069E190043; Wed, 6 Mar 2013 20:20: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; Wed, 6 Mar 2013 20:20:02 -0800 From: Ted Lemon To: "Liubing (Leo)" Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT Thread-Index: Ac4Y0qVmXOczhdgyTHaW1OIbGrg4zQAVbZqAABAGvAAAAlzXgAAIFLoAAAKCZIAABfkCAAAA0RCAAACcd4AAAOJ/gAAAJRsAAABlxoAAALV/gAADDBMAACbVwgAACCQUAAACcUAAAAIpbgAAB8eKgAABjsKAABowoYAAAMNaAA== Date: Thu, 7 Mar 2013 04:20:02 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474B2BC4@mbx-01.win.nominum.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> <5137561D.5070604@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6E6E84@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6E6E84@nkgeml506-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: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307474B2BC4mbx01winnominum_" MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 04:20:07 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307474B2BC4mbx01winnominum_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 6, 2013, at 10:58 PM, Liubing (Leo) > wrote: In section 4, it discussed solution space for renumbering and multihoming w= ithout NAT. But they are not perfect, e.g. routing scalability issue of PI= . Is this a practical concern, or a theoretical concern? I know the origina= l architecture called for perfect routing hierarchies so that the backbone = would have only four or five aggregated routes on it, but is that really wh= at we have now? Is it really the case that PIs could not be routed? I think that the answer to this is partly "no," and partly "we don't actual= ly have much data." So in my mind it's too soon to break a fundamental as= pect of the Internet architecture. It's certainly true that as time goes = by, we may discover that ISPs are not willing to set up routing for PIs, an= d that small enterprise customers will have to choose between NAPT and renu= mbering. But I haven't heard a single person make this case as a real pro= blem that exists now, and even if it does exist in the future, it seems to = me that it's something we'd like to _avoid_, not _enable_. --_000_8D23D4052ABE7A4490E77B1A012B6307474B2BC4mbx01winnominum_ Content-Type: text/html; charset="us-ascii" Content-ID: <081C0A5215BDA04985B320A530B6D42C@nominum.com> Content-Transfer-Encoding: quoted-printable
On Mar 6, 2013, at 10:58 PM, Liubing (Leo) <leo.liubing@huawei.com> wrote:
In section 4, it discussed solution spac= e for renumbering and multihoming without NAT.  But they are not perfe= ct, e.g. routing scalability issue of PI.

Is this a practical concern, or a theoretical concern?   I know t= he original architecture called for perfect routing hierarchies so that the= backbone would have only four or five aggregated routes on it, but is that= really what we have now?   Is it really the case that PIs could not be routed?

I think that the answer to this is partly "no," and partly &= quot;we don't actually have much data."   So in my mind it's too = soon to break a fundamental aspect of the Internet architecture.   It'= s certainly true that as time goes by, we may discover that ISPs are not willing to set up routing for PIs, and that small enterprise custo= mers will have to choose between NAPT and renumbering.   But I haven't= heard a single person make this case as a real problem that exists now, an= d even if it does exist in the future, it seems to me that it's something we'd like to _avoid_, not _enable_.

--_000_8D23D4052ABE7A4490E77B1A012B6307474B2BC4mbx01winnominum_-- From dougb@dougbarton.us Wed Mar 6 20:33:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BCB21F883E for ; Wed, 6 Mar 2013 20:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPuj+umMEGJI for ; Wed, 6 Mar 2013 20:33:52 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id BAB1721F882F for ; Wed, 6 Mar 2013 20:33:52 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:34b6:ab10:d0af:2ac6] (unknown [IPv6:2001:470:d:5e7:34b6:ab10:d0af:2ac6]) by dougbarton.us (Postfix) with ESMTPSA id 3930422B31 for ; Thu, 7 Mar 2013 04:33:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362630832; bh=UYe/Kdl69+ben4RaDGHgHVox8UrP5qDFJeuAtQtZRTo=; h=Date:From:To:Subject:References:In-Reply-To; b=Cz0UqF4B7eT3hewe3R4QX3sDC9g7hDIwn7mXf1ZyraXN0orCTInA45i9n7eVBEZVA OAyzwxiPiexPjs53dgLf0esTYsJ3C+1VsdhjqV767sLao44x6q18gWiz7hKQpC+Dwg p5YNQYzJ2Ob5QMWpl5dGjGDUO2yMD3PeRtrrVq3s= Message-ID: <513818AF.4090005@dougbarton.us> Date: Wed, 06 Mar 2013 20:33:51 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "v6ops@ietf.org WG" References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 04:33:53 -0000 On 03/06/2013 07:35 PM, Owen DeLong wrote: > 1. At its worst, rogue RAs and ND abuse are no worse than ARP attacks and rogue DHCP servers in IPv4. > The available solutions today are roughly equally robust. Intentionally malicious rouge RAs set to high priority are quite a bit worse, because they redirect all traffic immediately, instead of the trickle you get with rogue DHCP. Your point that the attacker needs to be inside the network already is valid of course, but it's not like that never happens. Doug From victor@jvknet.com Wed Mar 6 20:41:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2F61F0D05 for ; Wed, 6 Mar 2013 20:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.171 X-Spam-Level: X-Spam-Status: No, score=-0.171 tagged_above=-999 required=5 tests=[AWL=0.831, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, MIME_QP_LONG_LINE=1.396, 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 KySS9yadyHtU for ; Wed, 6 Mar 2013 20:41:42 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id A79EB21F84BE for ; Wed, 6 Mar 2013 20:41:42 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id bv4so3015016qab.3 for ; Wed, 06 Mar 2013 20:41:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :x-gm-message-state; bh=qQAkFolp28uMNE+OnZRyJiAALsZUpQD2iZ4pQF2jdic=; b=HuzHZgS48ofToU9Vzd9ppP10avoKCIvz5h69WY8nIyEsblg8/ajZKjLnRygzLe3fTQ Y0+YVRqiUpT7tVkKnTGyA0wjqg+HQBbSOPAULa9c0mpjs1Kq3wWBhrZc8htJyE8FFie+ DRqFLL64RFEadcTlohg1H6n91yiVLhIcXopPACyFkz3enMBzqtSbU7LTeC6muDw0Nyhr V6HKqaodthCuRxe42zAQ6Fvg9J5hP3UUZJkZr4xXu3P7jGYm0Si/3ZHY3r91hjNLQPx9 KTX+55croA7scgFXttrLybo6jaWyo1Xug+MDb2rFFJWIxpzRsKj3LQG75ve2ohja6YIf UE6g== X-Received: by 10.224.207.72 with SMTP id fx8mr48833810qab.66.1362631302143; Wed, 06 Mar 2013 20:41:42 -0800 (PST) Received: from [192.168.100.33] ([67.224.83.162]) by mx.google.com with ESMTPS id hr1sm277811qeb.3.2013.03.06.20.41.39 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 06 Mar 2013 20:41:41 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 06 Mar 2013 23:41:36 -0500 From: Victor Kuarsingh To: Ted Lemon , "Liubing (Leo)" Message-ID: Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474B2BC4@mbx-01.win.nominum.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3445458100_101875396" X-Gm-Message-State: ALoCoQmmW9YeYgBqQX9uhySe1IB9C8db2DJ68Kjqo5NsNz0qYo6KJTrWdrz5z1ilx4nF6/PwIc/x Cc: "" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 04:41:44 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3445458100_101875396 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable From: Ted Lemon Date: Thu, 7 Mar 2013 04:20:02 +0000 To: "Liubing (Leo)" Cc: "" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT On Mar 6, 2013, at 10:58 PM, Liubing (Leo) wrote: > In section 4, it discussed solution space for renumbering and multihoming > without NAT. But they are not perfect, e.g. routing scalability issue of= PI. [VK]. Technically ULA+NAT w/PI has the same routing impact as Native w/PI. The routing issues (which are theoretical as Ted noted below =AD for now) are potentially diminished if there is a lot more ULA+NAT w/PA or just Native w/PA. Is this a practical concern, or a theoretical concern? I know the origina= l architecture called for perfect routing hierarchies so that the backbone would have only four or five aggregated routes on it, but is that really what we have now? Is it really the case that PIs could not be routed? I think that the answer to this is partly "no," and partly "we don't actually have much data." So in my mind it's too soon to break a fundamental aspect of the Internet architecture. It's certainly true that as time goes by, we may discover that ISPs are not willing to set up routin= g for PIs, and that small enterprise customers will have to choose between NAPT and renumbering. But I haven't heard a single person make this case as a real problem that exists now, and even if it does exist in the future, it seems to me that it's something we'd like to _avoid_, not _enable_. [VK] It's hard to say what the future impact will be if PI becomes widespread or the norm. Not sure if this (mass PI usage) will be what send= s us to a seven figure global routing table. Right now I am a bit more concerned about how fragmented the IPv4 table may become. Regards, Victor K _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --B_3445458100_101875396 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable


From: Ted Lemon <Ted.Lemon@nominum.com>
Date: Thu, 7 Mar 2013 04:20:02 +0000
To: "Liubing (Leo)" <leo.liubing@huawei.com>
Cc: "<v6ops@ietf.org>" <v6ops@ietf.org>
Subject: Re: [v6ops] ULA discussion #1 ULA+NAT
<= br>
On Mar 6, 2013, at 10:58 PM, Liu= bing (Leo) <leo.liubing@huawei.co= m> wrote:
In section 4, it discussed solution space for renumbering a= nd multihoming without NAT.  But they are not perfect, e.g. routing sca= lability issue of PI.
[VK].  Technically ULA+NAT w/PI has the same routing impact as Native = w/PI.  The routing issues (which are theoretical as Ted noted below = 211; for now) are potentially diminished if there is a lot more ULA+NAT w/PA= or just Native w/PA.


Is this a practical concern, or a theo= retical concern?   I know the original architecture called for perfect = routing hierarchies so that the backbone would have only four or five aggreg= ated routes on it, but is that really what we have now?   Is it really the case that PIs could not be routed?

I think th= at the answer to this is partly "no," and partly "we don't actually have muc= h data."   So in my mind it's too soon to break a fundamental aspect of= the Internet architecture.   It's certainly true that as time goes by,= we may discover that ISPs are not willing to set up routing for PIs, and that small enterprise custo= mers will have to choose between NAPT and renumbering.   But I haven't = heard a single person make this case as a real problem that exists now, and = even if it does exist in the future, it seems to me that it's something we'd like to _avoid_, not _enable_.

[VK]  It's hard to say what th= e future impact will be if PI becomes widespread or the norm.  Not sure= if this (mass PI usage) will be what sends us to a seven figure global rout= ing table.  Right now I am a bit more concerned about how fragmented th= e IPv4 table may become.

Regards,

Victor K




=
_______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/= mailman/listinfo/v6ops --B_3445458100_101875396-- From dougb@dougbarton.us Wed Mar 6 20:43:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762751F0D08 for ; Wed, 6 Mar 2013 20:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCzStp8L8ZS9 for ; Wed, 6 Mar 2013 20:43:11 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id DECB81F0D07 for ; Wed, 6 Mar 2013 20:43:10 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:34b6:ab10:d0af:2ac6] (unknown [IPv6:2001:470:d:5e7:34b6:ab10:d0af:2ac6]) by dougbarton.us (Postfix) with ESMTPSA id 98F1122B54 for ; Thu, 7 Mar 2013 04:43:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362631390; bh=gavdG0aqSXBJf74BMHWW+JWt2BZmv+NQ9hYFfvQ7Mco=; h=Date:From:To:Subject:References:In-Reply-To; b=EPZZVhPMrifUvNlo50/ZtoUFneEnpt/UGgtODCQBReo6qfcexnB7JHFCDCBoV9lq6 EYKsE21jJkoo3QWFN0EZDSkH9NVVb19AlLqoghRnnviwBfrO1P3qVEcqt67+D0k0Cz vdp8zQSYCPzq8lSOuRjwDtbySiK9oaGvKl5IuQj8= Message-ID: <51381ADE.1000104@dougbarton.us> Date: Wed, 06 Mar 2013 20:43:10 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "" References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> <5137561D.5070604@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> <5137B897.7080601@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B213C@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474B213C@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 04:43:11 -0000 On 03/06/2013 03:31 PM, Ted Lemon wrote: > On Mar 6, 2013, at 4:43 PM, Doug Barton > wrote: >> To answer Ted's question, the harm isn't technical, and it's naive to >> think that we're only dealing with technical issues here. To the >> extent that people will actually read the document what I want to >> avoid is a scenario like, "Wow, this combination of ULA + NPTv6 really >> sounds like it would meet my needs, but the IETF recommends against >> it. So now what do I do?" > > No, you didn't answer my question. You just made another > non-falsifiable assertion about the PR effects of advising against a > course of action that everybody who has argued the technical merits has > agreed is the right course of action. I think everyone (including me) agrees that an ideal world would not include NAT, or anything like it. So if you want to claim a "win" on the technical merits, go right ahead. > I conclude that you actually do > not have a use case to support your claims, and that you just have a > strong opinion. I've actually described the use case in tremendous detail, including the technical merits (and potential drawbacks) of the solution. Thus I conclude that you're not interested in listening to any opinions that contradict yours. (See what I did there?) > The IETF doesn't care about your opinion. More's the pity. :) > We care about the technical > merits of your argument. And we care about rough consensus and running > code. But the problem is that you're choosing to limit your definition of "rough consensus" to the people who agree with you. You're shouting "You're ignorant!" "You're doing it wrong!" at the people who come to you and say that the things which you have achieved rough consensus on don't meet their needs, thus perpetuating your ability to get together and pat one another on the back while you rest comfortably in your echo chamber. If that's the life you want, go for it. I remember when the IETF was more than that. > If that means we are dinosaurs, and that we are doomed, maybe > that's okay. But I really don't think this particular argument is the > one that will doom us. You're right of course, it's the attitude behind it that will doom you. Doug (We don't live in an ideal world) From Ted.Lemon@nominum.com Wed Mar 6 20:45:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0BD11E80E9 for ; Wed, 6 Mar 2013 20:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAL6ZKtxT2LJ for ; Wed, 6 Mar 2013 20:45:05 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id E191111E80D5 for ; Wed, 6 Mar 2013 20:44:58 -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 DSNKUTgbSjtEt42E/z0Rle5eXftxp7W5SQPt@postini.com; Wed, 06 Mar 2013 20:44: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 91D6F108014 for ; Wed, 6 Mar 2013 20:44:58 -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 88A31190043; Wed, 6 Mar 2013 20:44:58 -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, 6 Mar 2013 20:44:58 -0800 From: Ted Lemon To: Doug Barton Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT Thread-Index: Ac4Y0qVmXOczhdgyTHaW1OIbGrg4zQAVbZqAABAGvAAAAlzXgAAIFLoAAAKCZIAABfkCAAAA0RCAAACcd4AAAOJ/gAAAJRsAAABlxoAAALV/gAACHAWAACcL2QAAHe3hAAAD7pKAAA5VtgAAAgxfgAAAYz6A Date: Thu, 7 Mar 2013 04:44:58 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474B2CB8@mbx-01.win.nominum.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <513818AF.4090005@dougbarton.us> In-Reply-To: <513818AF.4090005@dougbarton.us> 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: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 04:45:06 -0000 On Mar 6, 2013, at 11:33 PM, Doug Barton wrote: > Intentionally malicious rouge RAs set to high priority are quite a bit wo= rse, because they redirect all traffic immediately, instead of the trickle = you get with rogue DHCP. ARP attacks can work pretty quickly (within 120 seconds). > Your point that the attacker needs to be inside the network already is va= lid of course, but it's not like that never happens. Yes, this is why you want to filter out malicious RAs on your switch. Alt= hough there's some value in knowing that the hypothetical risk of a malefac= tor on the LAN has turned into the reality of a malefactor on the LAN. I = suspect this is why attacks of this sort are so rare. From dougb@dougbarton.us Wed Mar 6 20:45:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6ED011E80F3 for ; Wed, 6 Mar 2013 20:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQL4G3YJ1Jm2 for ; Wed, 6 Mar 2013 20:45:21 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id C638E11E80F2 for ; Wed, 6 Mar 2013 20:45:13 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:34b6:ab10:d0af:2ac6] (unknown [IPv6:2001:470:d:5e7:34b6:ab10:d0af:2ac6]) by dougbarton.us (Postfix) with ESMTPSA id 90B4E22B54 for ; Thu, 7 Mar 2013 04:45:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362631513; bh=DjttPvYxI3ZDtzkX8TBxd13oDtvcPoD6gGpyDz+3Djo=; h=Date:From:To:Subject:References:In-Reply-To; b=c54UW69wD8kEhmA/dmDv/ora5NwBvWBmy7W1jQUFeYmESSb+AzZw0o8+QdvMHLcrY hs677YfaY3igyT0tVuiApUPkd928V9dpaQmUYY3KySGEZ15OYWIoml+s1kcsEAnQtW ihCjyn2rs3tPOAQShxt29l373/DsDV7FV208UpuE= Message-ID: <51381B59.7020902@dougbarton.us> Date: Wed, 06 Mar 2013 20:45:13 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "v6ops@ietf.org WG" References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <20130306220241.D935E3078F7F@drugs.dv.isc.org> <5137BFCD.3@dougbarton.us> <20130306230359.66A693079C97@drugs.dv.isc.org> In-Reply-To: <20130306230359.66A693079C97@drugs.dv.isc.org> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 04:45:22 -0000 On 03/06/2013 03:03 PM, Mark Andrews wrote: > In message <5137BFCD.3@dougbarton.us>, Doug Barton writes: >> On 03/06/2013 02:02 PM, Mark Andrews wrote: >>> As far as I can tell the main problem SMB are solving with NAT is >>> the multi-homing with PA addresses. >> >> I've already made clear that IME what you describe is a factor for some, >> but renumbering is a very important factor for nearly all. >> >> Doug > I'm making the assumption that SMB is getting "permanent" static > PA rather than slightly less permanent PA delivered to residential > customers. > > You don't have to put PA addresses into the internal DNS. You can > only put ULA addresses there. You will only use ULA addreses to > communicate internally if you do that. Yes, that's certainly 1 valid use case, and I think the pros and cons of it should be included in the solution matrix. Doug From dougb@dougbarton.us Wed Mar 6 20:52:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD4E21F86AE for ; Wed, 6 Mar 2013 20:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6GAwUHXmdeb for ; Wed, 6 Mar 2013 20:52:44 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8285121F868F for ; Wed, 6 Mar 2013 20:52:44 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:34b6:ab10:d0af:2ac6] (unknown [IPv6:2001:470:d:5e7:34b6:ab10:d0af:2ac6]) by dougbarton.us (Postfix) with ESMTPSA id 549EA22B31 for ; Thu, 7 Mar 2013 04:52:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362631964; bh=25RXdZPTIbpiX/FO5SyQUr0imeDPSDidhxyINauiN98=; h=Date:From:To:Subject:References:In-Reply-To; b=P57WBwvRymrbmK5PX+4DmOGqdBaj6rjlAGbQu74eWzXAqy2oKQYWH20hge3/vuXVv Wi+rFJxqxRo8bJB2AyuPiPymkXPyQwCZAbtMbcHYZpl9knxFrkfbDbyrEq09taPoGb DXrlDJjMRwRReuxqrf9SosrC2h0BzTNoliNttbMs= Message-ID: <51381D1B.6050707@dougbarton.us> Date: Wed, 06 Mar 2013 20:52:43 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "v6ops@ietf.org WG" References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <513818AF.4090005@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B2CB8@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474B2CB8@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 04:52:45 -0000 On 03/06/2013 08:44 PM, Ted Lemon wrote: > On Mar 6, 2013, at 11:33 PM, Doug Barton > wrote: >> Intentionally malicious rouge RAs set to high priority are quite a bit worse, because they redirect all traffic immediately, instead of the trickle you get with rogue DHCP. > > ARP attacks can work pretty quickly (within 120 seconds). > >> Your point that the attacker needs to be inside the network already is valid of course, but it's not like that never happens. > > Yes, this is why you want to filter out malicious RAs on your switch. Assuming you have switches of sufficient quality, sure. The flip side of that is the discussion that looks like this: Tech: We need to upgrade all our switches so that we can safely deploy IPv6. Manager: But the switches we have now work just fine, right? Tech: Right, but ... Manager: Are the new switches more expensive? Tech: Yes, but ... Manager: Does anything bad happen if we don't deploy IPv6? Tech: No, but ... Manager: Ok, I'll look at this new switch thing again when the switches we have need to be replaced. > Although there's some value in knowing that the hypothetical risk of a malefactor on the LAN has turned into the reality of a malefactor on the LAN. I suspect this is why attacks of this sort are so rare. My point was not, "There are no solutions to these problems," although I'm glad to be learning more about the solutions that people have already deployed. My point is that when serious people investigated deploying IPv6 they found genuine deficits in the protocol. To then criticize those people (as Lorenzo did) by saying that they were never serious about deploying it in the first place is not accurate. Doug From dougb@dougbarton.us Wed Mar 6 21:00:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7052E11E80D5 for ; Wed, 6 Mar 2013 21:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 Fxto4DnkpvDx for ; Wed, 6 Mar 2013 21:00:04 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5FA11E80A3 for ; Wed, 6 Mar 2013 21:00:04 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:34b6:ab10:d0af:2ac6] (unknown [IPv6:2001:470:d:5e7:34b6:ab10:d0af:2ac6]) by dougbarton.us (Postfix) with ESMTPSA id D5EDF22B31 for ; Thu, 7 Mar 2013 05:00:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362632403; bh=REeuGCv5TP/GDPCy93WQ/h9wFlON9tvl120A7pQXoNE=; h=Date:From:To:Subject:References:In-Reply-To; b=DFA0xehG2nhD7/aClBYt+qeMEWnl/ZJ1uDvzXEIbPHhw9wXweiOFvrrDariQ4x+/h rZl3sdi3pb4lIi3wN16i1D9jleg1IRz81xKZ/a5Q80TIUUqauuqt//JkBLWtfZTfjv CT+B0q6CJCUNfer+LByJ61QOW0TMua+eAPJYQg2w= Message-ID: <51381ED3.4070900@dougbarton.us> Date: Wed, 06 Mar 2013 21:00:03 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <5137B118.8040904@dougbarton.us> <5137D6A! A.1010802@umn.edu> <58A8A809-CA1C-48B3-BA5C-D458DC43D25B@delong.com> In-Reply-To: <58A8A809-CA1C-48B3-BA5C-D458DC43D25B@delong.com> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 05:00:05 -0000 On 03/06/2013 08:00 PM, Owen DeLong wrote: >> >> This seems like a very reasonable treatment of the issue, to me. But, I don't see any explicit recommendation against the use of NPT or NAT other than by reference to RFC 6296. Please explain why it is necessary for this draft about the use of ULA to include an explicit recommendation against the use of NPT or NAT? >> >> I'd be happy with the inclusion of something like above "the implications of its deployment need to be fully understood", especially given that RFC 6296 has an Experimental Status. But that is much different than an explicit recommendation against the use of NPT or NAT. > > Along those lines, how about the following statement: > > "Use of NPT or NAT comes with a number of detrimental implications which should be fully considered and understood prior to any deployment of these technologies." As long as this is accompanied by a fair discussion of the pros and cons of the various solutions, I'm fine with that, FWIW. Doug From Ted.Lemon@nominum.com Wed Mar 6 21:19:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E075D21F8691 for ; Wed, 6 Mar 2013 21:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.138 X-Spam-Level: X-Spam-Status: No, score=-106.138 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8cxFfyCVXPA for ; Wed, 6 Mar 2013 21:19:45 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id F2DE721F868E for ; Wed, 6 Mar 2013 21:19:44 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUTgjcOHHmBMXmI4NHxHPFXRahToPwkhm@postini.com; Wed, 06 Mar 2013 21:19:45 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 446F71B8350 for ; Wed, 6 Mar 2013 21:19:44 -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 39355190043; Wed, 6 Mar 2013 21:19:44 -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, 6 Mar 2013 21:19:44 -0800 From: Ted Lemon To: Doug Barton Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT Thread-Index: Ac4Y0qVmXOczhdgyTHaW1OIbGrg4zQAVbZqAABAGvAAAAlzXgAAIFLoAAAKCZIAABfkCAAAA0RCAAACcd4AAAOJ/gAAAJRsAAABlxoAAALV/gAADDBMAACbVwgAACCQUAAACcUAAAAIpbgAAB8eKgAABjsKAAA0d1IAAA74lgAAK5tYAAAFGyYA= Date: Thu, 7 Mar 2013 05:19:43 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474B2F3E@mbx-01.win.nominum.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> <5137561D.5070604@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> <5137B897.7080601@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B213C@mbx-01.win.nominum.com> <51381ADE.1000104@dougbarton.us> In-Reply-To: <51381ADE.1000104@dougbarton.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307474B2F3Embx01winnominum_" MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 05:19:46 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307474B2F3Embx01winnominum_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 6, 2013, at 11:43 PM, Doug Barton > wrote: I've actually described the use case in tremendous detail, including the te= chnical merits (and potential drawbacks) of the solution. Thus I conclude t= hat you're not interested in listening to any opinions that contradict your= s. (See what I did there?) I didn't say you weren't listening. I said you hadn't made your point. = So if this was an attempt to turn that around on me, please reconsider. You're shouting "You're ignorant!" "You're doing it wrong!" at the people w= ho come to you and say that the things which you have achieved rough consen= sus on don't meet their needs, I'm not shouting at all. And I don't determine consensus. Maybe you mea= nt "you, the IETF," though. You still haven't explained why PI doesn't wo= rk for you. On Mar 6, 2013, at 11:52 PM, Doug Barton > wrote: Manager: Does anything bad happen if we don't deploy IPv6? Tech: No, but ... This would be an example of someone who doesn't yet need to deploy IPv6. My point is that when serious people investigated deploying IPv6 they found= genuine deficits in the protocol. To then criticize those people (as Loren= zo did) by saying that they were never serious about deploying it in the fi= rst place is not accurate. Yes, we have found genuine deficits in the protocol, just like we did when = IPv4 started to see widespread deployment. And just like when that happen= ed, we are working to address those deficits, and have in fact addressed so= me of them. It's a process. It would be a mistake to push people into the process who don't need to be = in it yet, and in order to get them into it, make engineering compromises t= hat wind up being expensive in the long run. For people who can have the= conversation you reported between the manager and the tech, this really is= n't the time for them to deploy; deploying will be more likely to get them = to hate IPv6 than to successfully complete their IPv6 deployment. --_000_8D23D4052ABE7A4490E77B1A012B6307474B2F3Embx01winnominum_ Content-Type: text/html; charset="us-ascii" Content-ID: <5CA46809283D424B9496DE2958D3C4D9@nominum.com> Content-Transfer-Encoding: quoted-printable
On Mar 6, 2013, at 11:43 PM, Doug Barton <dougb@dougbarton.us> wrote:
I've actually described the use case in tremendou= s detail, including the technical merits (and potential drawbacks) of the s= olution. Thus I conclude that you're not interested in listening to any opi= nions that contradict yours. (See what I did there?)

I didn't say you weren't listening.   I said you hadn't made your= point.   So if this was an attempt to turn that around on me, please = reconsider.

You're shouting "You're ignorant!" "You're doing it wrong!" a= t the people who come to you and say that the things which you have achieve= d rough consensus on don't meet their needs,

I'm not shouting at all.   And I don't determine consensus.  = ; Maybe you meant "you, the IETF," though.   You still haven= 't explained why PI doesn't work for you.

On Mar 6, 2013, at 11:52 PM, Doug Barton <dougb@dougbarton.us> wrote:
Manager: Does anything bad happen if we don't dep= loy IPv6?
Tech: No, but ...

This would be an example of someone who doesn't yet need to deploy IPv= 6.

My point is that when serious people investigated= deploying IPv6 they found genuine deficits in the protocol. To then critic= ize those people (as Lorenzo did) by saying that they were never serious ab= out deploying it in the first place is not accurate.

Yes, we have found genuine deficits in the protocol, just like we did = when IPv4 started to see widespread deployment.   And just like when t= hat happened, we are working to address those deficits, and have in fact ad= dressed some of them.   It's a process.

It would be a mistake to push people into the process who don't need t= o be in it yet, and in order to get them into it, make engineering compromi= ses that wind up being expensive in the long run.    For people w= ho can have the conversation you reported between the manager and the tech, this really isn't the time for them to d= eploy; deploying will be more likely to get them to hate IPv6 than to succe= ssfully complete their IPv6 deployment.

--_000_8D23D4052ABE7A4490E77B1A012B6307474B2F3Embx01winnominum_-- From drc@virtualized.org Wed Mar 6 21:30:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1619021F849A for ; Wed, 6 Mar 2013 21:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] 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 1o+jMjEK700p for ; Wed, 6 Mar 2013 21:30:56 -0800 (PST) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7E39421F8499 for ; Wed, 6 Mar 2013 21:30:56 -0800 (PST) Received: from [10.0.1.4] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id CF4F8171E9; Thu, 7 Mar 2013 05:30:54 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_58181C28-FAFE-497E-A3A8-74B68AF7032C" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: David Conrad In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474B28A5@mbx-01.win.nominum.com> Date: Wed, 6 Mar 2013 21:30:53 -0800 Message-Id: <830A33E1-6B1B-4572-ADF7-BC27A3C21C58@virtualized.org> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B2162@mbx-01.win.nominum.com> <709A43C8-3D68- 49D6-98D A-631E84C78075@virtualized.org> <8D23D4052ABE7A4490E77B1A012B6307474B28A5@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1499) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 05:30:57 -0000 --Apple-Mail=_58181C28-FAFE-497E-A3A8-74B68AF7032C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 6, 2013, at 6:51 PM, Ted Lemon wrote: > On Mar 6, 2013, at 6:42 PM, David Conrad wrote: >> Obviously a subjective evaluation. I'd recommend getting a PI block = for yourself, after all, according to some on this list, it is painless = and the cost inconsequential. >=20 > Based on the links you sent, it seems like the answer to "how = expensive is a PI" is "not very." Clearly, Nominum is paying you too much :). More seriously, this is another subjective evaluation. When doing that = evaluation, it is probably useful to compare those costs (and don't = forget to include the cost of legal review, getting someone to route = your PI space, and the implications of yearly renewal) to the direct = costs of using ULA+NAT to the purchaser.=20 Regards, -drc --Apple-Mail=_58181C28-FAFE-497E-A3A8-74B68AF7032C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Mar 6, 2013, at 6:51 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
On Mar 6, 2013, at 6:42 PM, David Conrad <drc@virtualized.org> wrote:
Obviously a subjective evaluation.  I'd recommend getting a PI block for yourself, after all, according to some on this list, it is painless and the cost inconsequential.
Based on the links you sent, it seems like the answer to "how expensive is a PI" is "not very."

Clearly, Nominum is paying you too much :).

More seriously, this is another subjective evaluation. When doing that evaluation, it is probably useful to compare those costs (and don't forget to include the cost of legal review, getting someone to route your PI space, and the implications of yearly renewal) to the direct costs of using ULA+NAT to the purchaser. 

Regards,
-drc

--Apple-Mail=_58181C28-FAFE-497E-A3A8-74B68AF7032C-- From Ted.Lemon@nominum.com Wed Mar 6 21:41:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D08E21F85A4 for ; Wed, 6 Mar 2013 21:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.13 X-Spam-Level: X-Spam-Status: No, score=-106.13 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fz-cHPqccHJO for ; Wed, 6 Mar 2013 21:41:21 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 49C1621F85A1 for ; Wed, 6 Mar 2013 21:41:21 -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 DSNKUTgogSeyJYkctu1mQpAGvSWVnJs7d/TI@postini.com; Wed, 06 Mar 2013 21: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 0B8DE108008 for ; Wed, 6 Mar 2013 21:41: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 03F7A190043; Wed, 6 Mar 2013 21:41: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; Wed, 6 Mar 2013 21:41:15 -0800 From: Ted Lemon To: David Conrad Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT Thread-Index: Ac4Y0qVmXOczhdgyTHaW1OIbGrg4zQAVbZqAABAGvAAAAlzXgAAIFLoAAAKCZIAABfkCAAAA0RCAAACcd4AAAOJ/gAAAJRsAAABlxoAAALV/gAACHAWAACcL2QAAHe3hAAAD7pKAAABPR4AAAE+4AAAAwBSAAADwWwAAA4qWAAAAWduAAAaYmYAABZOIgAAAXGOA Date: Thu, 7 Mar 2013 05:41:14 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474B2FFA@mbx-01.win.nominum.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B2162@mbx-01.win.nominum.com> <709A43C8-3D68- 49D6-98D A-631E84C78075@virtualized.org> <8D23D4052ABE7A4490E77B1A012B6307474B28A5@mbx-01.win.nominum.com> <830A33E1-6B1B-4572-ADF7-BC27A3C21C58@virtualized.org> In-Reply-To: <830A33E1-6B1B-4572-ADF7-BC27A3C21C58@virtualized.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307474B2FFAmbx01winnominum_" MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 05:41:22 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307474B2FFAmbx01winnominum_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Mar 7, 2013, at 12:30 AM, David Conrad > wrote: More seriously, this is another subjective evaluation. When doing that eval= uation, it is probably useful to compare those costs (and don't forget to i= nclude the cost of legal review, getting someone to route your PI space, an= d the implications of yearly renewal) to the direct costs of using ULA+NAT = to the purchaser. Are you offering to supply text? Don't forget to also cover the case wher= e the small business just renumbers=97we've heard that small businesses hat= e to do that, but it _is_ an option. --_000_8D23D4052ABE7A4490E77B1A012B6307474B2FFAmbx01winnominum_ Content-Type: text/html; charset="Windows-1252" Content-ID: <355EF91AA865FA46A3FB92E935504E58@nominum.com> Content-Transfer-Encoding: quoted-printable
On Mar 7, 2013, at 12:30 AM, David Conrad <drc@virtualized.org> wrote:
More seriously, this is another subjective evaluation. When doing that evaluati= on, it is probably useful to compare those costs (and don't forget to inclu= de the cost of legal review, getting someone to route your PI space, and th= e implications of yearly renewal) to the direct costs of using ULA+NAT to the purchaser. 

Are you offering to supply text?   Don't forget to also cover the= case where the small business just renumbers=97we've heard that small busi= nesses hate to do that, but it _is_ an option.


--_000_8D23D4052ABE7A4490E77B1A012B6307474B2FFAmbx01winnominum_-- From farmer@umn.edu Wed Mar 6 22:41:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C9621F8A14 for ; Wed, 6 Mar 2013 22:41:15 -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_33=0.6, 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 eZ6N8Ex8MKbA for ; Wed, 6 Mar 2013 22:41:15 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 88D1221F8A1C for ; Wed, 6 Mar 2013 22:41:09 -0800 (PST) Received: from mail-ie0-f198.google.com (mail-ie0-f198.google.com [209.85.223.198]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 7 Mar 2013 00:41:02 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f198.google.com [209.85.223.198] #+LO+TR X-Umn-Classification: local Received: by mail-ie0-f198.google.com with SMTP id 17so897800iea.5 for ; Wed, 06 Mar 2013 22:41:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=ZrtiofF/aRML5yZRIDNiKB86pVQL8TnrbXD/v7lM5/M=; b=miAFSNh4VEaRZEH/LVcRfUATMvqSbnPrMDycZsfXEoZLUy/9LTMbfb4yFto9GJfFg3 IhIZEmDdou62uHnWCHNZjQRhZtyCK034t7u3BwILrHuDXOtNvpzNEyDaD19W4i1q+Mvl pJKeC1O0suIRuCbTPcp6xdDEAaCFQ1zBZy9+pfBYQrQh0dHQGESbVUhdSawrWDt9P6pl U6I/bUoS2uEC7kDBFTkqyIWa5Ja1y6LeDZyoeD/dvxcj+/bMf+lAuhnFK2GxNOCWqZ9T BqwG43JlrC+WY0llyu8iwx1QilCXlHQCjv2jwrGhu0W8R5dimKYaVwyx8/iE+wpOxRk3 byjw== X-Received: by 10.42.179.73 with SMTP id bp9mr33247691icb.51.1362638461822; Wed, 06 Mar 2013 22:41:01 -0800 (PST) X-Received: by 10.42.179.73 with SMTP id bp9mr33247682icb.51.1362638461712; Wed, 06 Mar 2013 22:41:01 -0800 (PST) Received: from oit201651646.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPS id uq1sm26012679igc.5.2013.03.06.22.41.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 22:41:01 -0800 (PST) Message-ID: <51383672.6020205@umn.edu> Date: Thu, 07 Mar 2013 00:40:50 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ted Lemon References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> <5137561D.5070604@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> <5137B897.7080601@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B213C@mbx-01.win.nominum.com> <51381ADE.1000104@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B2F3E@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474B2F3E@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkhnhpijuapDxyXtRwKaQPzHySRUE7rw08NL3bqmb2Fm7YHvc5FTBZJsi8jimAXgRJJVNDa/k6b5PXAiwhssMbu4sRGidblbkD4t2WM1tBkiOYmiPkh3XOTnwkyeObwLZ2eKC/T Cc: "" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 06:41:16 -0000 On 3/6/13 23:19 , Ted Lemon wrote: > You still haven't explained why PI doesn't work for you. Lets look at the numbers, I did a little Googling; First what is an SME, best definition is an organization with less than 500 employees. And therefore, a large enterprise is an organization with 500 or more employees. Within the US there are ~6M SMEs, obviously PI for all of them isn't going to make a workable route table. While were looking, Large enterprises within the US is about ~20K even extrapolating that over the globe and that's probably a workable route table. But, about ~5.38M of the SMEs have less than 20 employees, business class or residential broadband probably covers most of these guys. That leaves ~620K, of which ~530K are 20 to 99 employees, and ~90K are 100 to 499 employees. When you extrapolate that out globally, it seems clear that PI can't even reasonably cover all the medium sized guys, no matter where you draw the line. So, it seems to me that there are probably a few million organizations globally for which PI isn't going to be practical and even IPv6's improved renumbering will be more that an annoying inconvenience. Got my number here; http://www.census.gov/econ/smallbus.html -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From v6ops@globis.net Wed Mar 6 23:17:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9A421F8B07 for ; Wed, 6 Mar 2013 23:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 S8QgmZBl1PCa for ; Wed, 6 Mar 2013 23:17:35 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 92B6821F8AB7 for ; Wed, 6 Mar 2013 23:17:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id BB66A8700D0; Thu, 7 Mar 2013 08:17:19 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sf0ZzBrkFFYI; Thu, 7 Mar 2013 08:16:58 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 9A1C987007B; Thu, 7 Mar 2013 08:16:58 +0100 (CET) Message-ID: <51383EE3.1000503@globis.net> Date: Thu, 07 Mar 2013 08:16:51 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: David Conrad References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B2162@mbx-01.win.nominum.com> <709A43C8-3D68-49D6-98DA-631E84C78075@virtualized. org> In-Reply-To: <709A43C8-3D68-49D6-98DA-631E84C78075@virtualized.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 07:17:36 -0000 David Conrad wrote: > Ted, > > On Mar 6, 2013, at 3:32 PM, Ted Lemon > wrote: >> On Mar 6, 2013, at 4:50 PM, Doug Barton > > wrote: >>> or dealing with the trouble and expense of PI space. >> Do you have any figures on that that you can offer? > > Trouble: > > Obviously a subjective evaluation. I'd recommend getting a PI block > for yourself, after all, according to some on this list, it is > painless and the cost inconsequential. > > Expense: > > http://www.afrinic.net/en/services/rs/membership-fees > http://www.apnic.net/services/become-a-member/how-much-does-it-cost > https://www.arin.net/fees/fee_schedule.html > http://www.lacnic.net/en/web/lacnic/membresia-costo > http://www.ripe.net/lir-services/member-support/become-a-member/membership-fees/membership-fees > > Regards, > -drc > Following IMHO So there's clearly a market for a neutral (non transport provider allied) organization to register some numbers on behalf of small medium enterprises (per geography). Maybe the ISP's could do this themselves per country as part of an SMB service? Or the RIR's. I mean come on. The RIR's are just covering their costs, and divide these by some formula across their membership. If a huge number of SMB's bought PI space the fees would go down per SMB. The tariffs are modifiable by the membership. This is a non-argument. And as for portability of PI space across providers, and fear of routing table explosion, I suggest the RIR's and LIR's look long and hard at what happened in the mobile Telco World, where number portability was thrust on them by the regulators / politicians. Telcos manage that situation pretty well, even though there are potentially billions of "host routes". I know no-one wants compulsory provider tiering hard-coded in the numbering scheme, but that does not exclude local (voluntary) cooperation per geography. An SMB doesn't strictly need an AS number, or to operate their own BGP, or become an LIR, for them to be able to achieve portable numbering and practical provider independence (which I 100% agree is the real issue for businesses). And that's even before we solve homenet and allow multi-homing with multiple PA prefixes running simultaneously. We should stop being so myopic on insisting on applying technical solutions to a non-technical problem. regards, RayH From owen@delong.com Thu Mar 7 00:05:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0362E21F84BE for ; Thu, 7 Mar 2013 00:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7CAFYFqFLFO for ; Thu, 7 Mar 2013 00:05:57 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7107221F850C for ; Thu, 7 Mar 2013 00:05:56 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2784Ymk013806 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Mar 2013 00:04:34 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2784Ymk013806 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362643474; bh=GJc5tYf7TVJwScxuh9bqZRBhQHc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=puGn9PrALH3io9EZxtMbQv2674H8jVndeX5qG94ASL8YvrPl+ZQXEUZ3M4l7b6hpu n9QdHqlCbTdNBFb8ep9rPbZJEeOoKl6o2GUOI5XwTuEji0ss3MWvSrWNKRyRjshTRV Y/FetHzXhdpIo6qNx0woG/kyGPDmSLdeqIqoaoqE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <513818AF.4090005@dougbarton.us> Date: Thu, 7 Mar 2013 00:04:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8EC913EB-5756-4A3F-ADBF-CB0133960168@delong.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <513818AF.4090005@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 07 Mar 2013 00:04:34 -0800 (PST) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 08:05:58 -0000 On Mar 6, 2013, at 20:33 , Doug Barton wrote: > On 03/06/2013 07:35 PM, Owen DeLong wrote: >> 1. At its worst, rogue RAs and ND abuse are no worse than ARP = attacks and rogue DHCP servers in IPv4. >> The available solutions today are roughly equally robust. >=20 > Intentionally malicious rouge RAs set to high priority are quite a bit = worse, because they redirect all traffic immediately, instead of the = trickle you get with rogue DHCP. Not really. They aren't guaranteed to win against other High Priority = legitimate RAs, so, in fact... > Your point that the attacker needs to be inside the network already is = valid of course, but it's not like that never happens. Sure, but my point is that when it does happen, having the wrong default = gateway on a few hosts really drops low on the list of serious concerns. Owen From owen@delong.com Thu Mar 7 00:21:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B0021F8B06 for ; Thu, 7 Mar 2013 00:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbbF6PuXCBdk for ; Thu, 7 Mar 2013 00:20:57 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 709C721F88FB for ; Thu, 7 Mar 2013 00:20:57 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r278GYRI014059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Mar 2013 00:16:34 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r278GYRI014059 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362644195; bh=mP0MYQnPJys/Y8eC3WPd58f+zWA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=aILHxduXd2Q0rzxXmQ4uoPMxJTipHGJzhgnapnAwEl3zRNotsIAjVHMGkk7bkugP1 wh3veDvT3lABwdcAqsVIY3G4B3lsCFw3p5ATr6WyfjFzvfClnT6Vdtxf1h1bP+fgW3 oLJK5wzLmZ5lfz4wDobiH4Pq+eHxn4r0FX67ROTU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <51381D1B.6050707@dougbarton.us> Date: Thu, 7 Mar 2013 00:16:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <513818AF.4090005@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B2CB8@mbx-01.win.nominum.com> <51381D1B.6050707@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 07 Mar 2013 00:16:35 -0800 (PST) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 08:21:02 -0000 On Mar 6, 2013, at 20:52 , Doug Barton wrote: > On 03/06/2013 08:44 PM, Ted Lemon wrote: >> On Mar 6, 2013, at 11:33 PM, Doug Barton >> wrote: >>> Intentionally malicious rouge RAs set to high priority are quite a = bit worse, because they redirect all traffic immediately, instead of the = trickle you get with rogue DHCP. >>=20 >> ARP attacks can work pretty quickly (within 120 seconds). >>=20 >>> Your point that the attacker needs to be inside the network already = is valid of course, but it's not like that never happens. >>=20 >> Yes, this is why you want to filter out malicious RAs on your switch. >=20 > Assuming you have switches of sufficient quality, sure. The flip side = of that is the discussion that looks like this: >=20 > Tech: We need to upgrade all our switches so that we can safely deploy = IPv6. > Manager: But the switches we have now work just fine, right? > Tech: Right, but ... > Manager: Are the new switches more expensive? > Tech: Yes, but ... > Manager: Does anything bad happen if we don't deploy IPv6? > Tech: No, but ... > Manager: Ok, I'll look at this new switch thing again when the = switches we have need to be replaced. Interesting... I've had that conversation a few times. It always went = more like this: Tech (me): We need to upgrade the switches or accept a certain amount of = risk in our IPv6 deployment. Manager: But the switches we have now work just fine, right? Tech (me): No, they have a vulnerability to certain attacks over IPv6 = that should be corrected. Manager: How much will this cost? Tech (me): Depends on how many of the switches can be upgraded in just = software. (most of them) The few switches that can't be done software only (free) are = switches that we have wanted to replace for some time now since they are becoming quite dated = and lack improved management features that we have on the other switches. Manager: What happens if we delay IPv6 instead? Tech (me): Immediately, nothing. However, the further we push this down = the road, the more likely it is that our eventual IPv6 deployment will be sudden, = uncoordinated, and costly. Manager: OK... Get me a budget number and I'll see what I can do. >> Although there's some value in knowing that the hypothetical risk of = a malefactor on the LAN has turned into the reality of a malefactor on = the LAN. I suspect this is why attacks of this sort are so rare. >=20 > My point was not, "There are no solutions to these problems," although = I'm glad to be learning more about the solutions that people have = already deployed. My point is that when serious people investigated = deploying IPv6 they found genuine deficits in the protocol. To then = criticize those people (as Lorenzo did) by saying that they were never = serious about deploying it in the first place is not accurate. Actually, Lorenzo's point is spot on. The problem is you're not = necessarily talking about the same people. While the defects you cited are "genuine", they are also relatively = low-risk in the real world. They present a different, but not larger = attack surface when compared to known vulnerabilities in IPv4 that we = have lived with for decades. There are, however, a LOT of people who = haven't really looked at IPv6 and just keep looking for the next reason = they don't have to. This is human nature, we resist change in a variety = of ways. Owen From owen@delong.com Thu Mar 7 00:21:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF1F21F8AEA for ; Thu, 7 Mar 2013 00:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IagFUa0iBspr for ; Thu, 7 Mar 2013 00:20:56 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 69C7921F8ADB for ; Thu, 7 Mar 2013 00:20:56 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r278GYRJ014059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Mar 2013 00:17:16 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r278GYRJ014059 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362644236; bh=pfzu/pMY6znth0iLmctgFbtjsRk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=gZZHgb8bmnO0NDpFrzNTcuz6du5FERuHlXuYsGdmTpNQXYSJM+xO91YTLKKkv7Ez3 fcbI6/qPBlH6IUReAcDqqZrFSGrv0m9RKa679iZ30QhqmyQ9TMwoj73GUJ9wJzxQJ+ zzAfRN6WR+J/5nBmtf4wDtArEilSPlc/0yTyvprc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <51381ED3.4070900@dougbarton.us> Date: Thu, 7 Mar 2013 00:17:10 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6570D530-1B46-4AC5-8006-E4DC0F5A6CBC@delong.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <5137B118.8040904@dougbarton.us> <5137D6A! A.1010802@umn.edu> <58A8A809-CA1C-48B3-BA5C-D458DC43D25B@delong.com> <51381ED3.4070900@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 07 Mar 2013 00:17:16 -0800 (PST) Cc: v6ops@ietf.org Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 08:21:02 -0000 On Mar 6, 2013, at 21:00 , Doug Barton wrote: > On 03/06/2013 08:00 PM, Owen DeLong wrote: >>>=20 >>> This seems like a very reasonable treatment of the issue, to me. = But, I don't see any explicit recommendation against the use of NPT or = NAT other than by reference to RFC 6296. Please explain why it is = necessary for this draft about the use of ULA to include an explicit = recommendation against the use of NPT or NAT? >>>=20 >>> I'd be happy with the inclusion of something like above "the = implications of its deployment need to be fully understood", especially = given that RFC 6296 has an Experimental Status. But that is much = different than an explicit recommendation against the use of NPT or NAT. >>=20 >> Along those lines, how about the following statement: >>=20 >> "Use of NPT or NAT comes with a number of detrimental implications = which should be fully considered and understood prior to any deployment = of these technologies." >=20 > As long as this is accompanied by a fair discussion of the pros and = cons of the various solutions, I'm fine with that, FWIW. >=20 Hallelujah... Sounds like rough consensus to me. Nowhere did I oppose = having a fair discussion of the pros and cons. Owen From owen@delong.com Thu Mar 7 00:25:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0F321F859B for ; Thu, 7 Mar 2013 00:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGi3klAckSxO for ; Thu, 7 Mar 2013 00:25:55 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id AF31721F84BB for ; Thu, 7 Mar 2013 00:25:54 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r278MX9C014167 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Mar 2013 00:22:33 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r278MX9C014167 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362644553; bh=8dAav0VaOS8dB1T1gUtNWki4A7E=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=MnmHz160vPCEM3280glvvRzLs4Llfcwg3IyEadmRBboNS6vteUiSYW5VFHU1ImO87 Rajz5S6/goaRJ02USE1vAoMz4CFlQEqOzP19R9mbHbG2KaWAtMSWEOkPt7V3EQiRLL ZUiMTl41F4QV7vcRbIoAqN7NwI8EUTMjQIDol94o= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <51383672.6020205@umn.edu> Date: Thu, 7 Mar 2013 00:22:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> <5137561D.5070604@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> <5137B897.7080601@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B213C@mbx-01.win.nominum.com> <51381ADE.1000104@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B2F3E@mbx-01.win.nominum.com> <51383672.6020205! @umn.edu> To: David Farmer X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 07 Mar 2013 00:22:33 -0800 (PST) Cc: "" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 08:25:56 -0000 On Mar 6, 2013, at 22:40 , David Farmer wrote: > On 3/6/13 23:19 , Ted Lemon wrote: >=20 >> You still haven't explained why PI doesn't work for you. >=20 > Lets look at the numbers, I did a little Googling; First what is an = SME, best definition is an organization with less than 500 employees. = And therefore, a large enterprise is an organization with 500 or more = employees. >=20 > Within the US there are ~6M SMEs, obviously PI for all of them isn't = going to make a workable route table. While were looking, Large = enterprises within the US is about ~20K even extrapolating that over the = globe and that's probably a workable route table. >=20 > But, about ~5.38M of the SMEs have less than 20 employees, business = class or residential broadband probably covers most of these guys. That = leaves ~620K, of which ~530K are 20 to 99 employees, and ~90K are 100 to = 499 employees. >=20 > When you extrapolate that out globally, it seems clear that PI can't = even reasonably cover all the medium sized guys, no matter where you = draw the line. So, it seems to me that there are probably a few million = organizations globally for which PI isn't going to be practical and even = IPv6's improved renumbering will be more that an annoying inconvenience. In fact a large portion of the 20-99 employee group is also pretty well = served with the business class or residential broadband you mentioned. The remaining 90K enterprises extrapolated globally works out to not = much bigger than the current IPv4 routing table. Given that there will be continued Moore's law advances in routing table = capacity over the years between now and when they ALL want to multihome, = I think we're actually OK there with PI. Owen From v6ops@globis.net Thu Mar 7 00:46:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C2F21F89EF for ; Thu, 7 Mar 2013 00:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 S9CZQj7fl8y6 for ; Thu, 7 Mar 2013 00:46:18 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4CF21F89E9 for ; Thu, 7 Mar 2013 00:46:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id AEEB48700E3; Thu, 7 Mar 2013 09:46:02 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MlIQ0P0ZuFK; Thu, 7 Mar 2013 09:45:41 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 816F187007B; Thu, 7 Mar 2013 09:45:41 +0100 (CET) Message-ID: <513853AE.5050009@globis.net> Date: Thu, 07 Mar 2013 09:45:34 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: David Farmer References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> <5137561D.5070604@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> <5137B897.7080601@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B213C@mbx-01.win.nominum.com> <51381ADE.1000104@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B2F3E@mbx-01.win.nominum.com> <51383672.6020205@umn.edu> In-Reply-To: <51383672.6020205@umn.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 08:46:19 -0000 David Farmer wrote: > On 3/6/13 23:19 , Ted Lemon wrote: > >> You still haven't explained why PI doesn't work for you. > > Lets look at the numbers, I did a little Googling; First what is an > SME, best definition is an organization with less than 500 employees. > And therefore, a large enterprise is an organization with 500 or more > employees. > How many SMEs are expected to want to significantly change geography and simultaneously expect not to renumber when they change providers? I suggest ~ 0. Because almost any such office move requires reconfiguring IT and phased moves between sites. I suggest the real requirement is that businesses want to be able to easily change providers, whilst not physically relocating, and having some simple solution to provider independence without having the business crippled for more than a few hours; like not renumbering, or flash renumbering, or dual provider operations, or something else manageable. > Within the US there are ~6M SMEs, obviously PI for all of them isn't > going to make a workable route table. Why not? These ~6M SMEs are presumably already connected to the Internet (and routed today). In the Netherlands they have the Polder Model: if the dyke breaks, everyone drowns, so no one wants that to happen. Same thing with the routing table. All ISP's are inter-dependent on making the routing table work, otherwise the Internet collapses and they have no service to sell. So even though they may compete (on last-mile fees) why wouldn't they cooperate on ensuring the (PI) routing table does not explode? We have CIDR. We have BGP. We have so many addresses we don't know what to do with them. We're already working on dual PA operation, flash renumbering, flag days, PI numbering etc. What else is needed at IETF level? > While were looking, Large enterprises within the US is about ~20K even > extrapolating that over the globe and that's probably a workable route > table. > But, about ~5.38M of the SMEs have less than 20 employees, business > class or residential broadband probably covers most of these guys. > That leaves ~620K, of which ~530K are 20 to 99 employees, and ~90K are > 100 to 499 employees. > When a business starts to need 1, 2 or 3 employees just to manage firewalls and NAT devices from a total employee base of 20-499, guess what? Those devices (and the excessive amount of people needed manage them) are removed [based on personal experience] IMHO the bases are covered. > When you extrapolate that out globally, it seems clear that PI can't > even reasonably cover all the medium sized guys, no matter where you > draw the line. So, it seems to me that there are probably a few > million organizations globally for which PI isn't going to be > practical and even IPv6's improved renumbering will be more that an > annoying inconvenience. > Got my number here; > http://www.census.gov/econ/smallbus.html > > From pkern@simplex.0x539.de Thu Mar 7 01:05:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2129421F8C99 for ; Thu, 7 Mar 2013 01:05:29 -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=[AWL=-0.500, BAYES_00=-2.599, GB_AFFORDABLE=1, J_CHICKENPOX_33=0.6] 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 aHThTMlQBNnq for ; Thu, 7 Mar 2013 01:05:28 -0800 (PST) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D1721F8C98 for ; Thu, 7 Mar 2013 01:05:28 -0800 (PST) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UDWlQ-0000sU-QW for v6ops@ietf.org; Thu, 07 Mar 2013 10:05:24 +0100 Received: from [2001:470:720c:0:2026:d67c:7df2:1d64] (helo=simplex.lan.home.philkern.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1UDWlS-0004mG-3N for v6ops@ietf.org; Thu, 07 Mar 2013 10:05:26 +0100 Received: from pkern by simplex.lan.home.philkern.de with local (Exim 4.80) (envelope-from ) id 1UDWlQ-0002in-VO for v6ops@ietf.org; Thu, 07 Mar 2013 10:05:25 +0100 Date: Thu, 7 Mar 2013 10:05:24 +0100 From: Philipp Kern To: v6ops@ietf.org Message-ID: <20130307090524.GB9667@simplex.0x539.de> References: <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline In-Reply-To: <5137AABD.1050401@dougbarton.us> Organization: The Debian Project (http://www.debian.org) X-Debbugs-No-Ack: yes User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 09:05:29 -0000 --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Doug, am Wed, Mar 06, 2013 at 12:44:45PM -0800 hast du folgendes geschrieben: > First, the big enterprises and ISPs demanded PI space, and once they > got it, they started deploying (per your statistics above). as a university we just became a LIR in RIPE land and got our /32. Granted, now we're in the weird situation of being an IPv6-only LIR, because all our other IPv4 space is unregistered legacy space. But it was still quite affordable and we'd even still get a chunk of fresh IPv4 "for free". Big enterprises and ISPs certainly could've got their own space through this process. Kind regards Philipp Kern --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJROFhUAAoJEERuJUU10FbsE6QH/1lIu8bu6XJkkh4UVN1YzB1c 7vD0cCIOuy0hTf+2Lj9CuLVL/erMbYJVPLnR4QpLDNszCwRahdfGA+78OlRt8Wsr 2Np0oYYHVBx0WHv06Itzhf6BdEXlUsdRyoSEO3tXzh7KtWsp4IqniAeleYkAr/RW QXqab9hf2VWBjjJ78vruPqX84D/i74zAfZLnhmk7MVqgoa/qd+Uua/s9f5pz3mdO rd5iYKcTIO6fP8+xyb2cNedTwDHCasgtAV9fpudiSmsw2FVyOMjay486O0jjH7kB w54nOS3QF692cxaNLNnP5PZ+GOwcH9MjP3aqcnds0ERA99jczCbEGtlh/cXjHgA= =Ebxr -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm-- From fgont@si6networks.com Thu Mar 7 01:33:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A6A21F8C7D for ; Thu, 7 Mar 2013 01:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 T4glrZCxRJdx for ; Thu, 7 Mar 2013 01:33:44 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id ABF5321F8C7A for ; Thu, 7 Mar 2013 01:33:44 -0800 (PST) Received: from [186.137.77.228] (helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UDXCZ-0004Yt-4b; Thu, 07 Mar 2013 10:33:40 +0100 Message-ID: <513856E5.2060109@si6networks.com> Date: Thu, 07 Mar 2013 05:59:17 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Lorenzo Colitti References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 09:33:45 -0000 On 03/06/2013 06:06 PM, Lorenzo Colitti wrote: > On Wed, Mar 6, 2013 at 1:02 PM, Doug Barton > wrote: > > we have solutions for rogue RAs. > > > Did you bring enough to share with the group? :) > > > I think we're using the ones recommended by the IETF... Please test them -- such implementations are likely broken (see draft-ietf-6man-ra-guard-implementation. -- fwiw, ra6 of is your friend. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From Ted.Lemon@nominum.com Thu Mar 7 05:52:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CC921F8CD7 for ; Thu, 7 Mar 2013 05:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.132 X-Spam-Level: X-Spam-Status: No, score=-106.132 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8zwuWWQJf+b for ; Thu, 7 Mar 2013 05:52:53 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 15A0A21F8CD3 for ; Thu, 7 Mar 2013 05:52:53 -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 DSNKUTibsu7/YR++f9JC+wtnN83BRMX+pRKL@postini.com; Thu, 07 Mar 2013 05:52: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 C79681B814A for ; Thu, 7 Mar 2013 05:52:50 -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 BEBDD190043; Thu, 7 Mar 2013 05:52:50 -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, 7 Mar 2013 05:52:50 -0800 From: Ted Lemon To: David Farmer Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT Thread-Index: Ac4Y0qVmXOczhdgyTHaW1OIbGrg4zQAVbZqAABAGvAAAAlzXgAAIFLoAAAKCZIAABfkCAAAA0RCAAACcd4AAAOJ/gAAAJRsAAABlxoAAALV/gAADDBMAACbVwgAACCQUAAACcUAAAAIpbgAAB8eKgAABjsKAAA0d1IAAA74lgAAK5tYAAAFGyYAAAtU9AAAPFmEA Date: Thu, 7 Mar 2013 13:52:50 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474B3B85@mbx-01.win.nominum.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> <5137561D.5070604@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> <5137B897.7080601@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B213C@mbx-01.win.nominum.com> <51381ADE.1000104@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B2F3E@mbx-01.win.nominum.com> <51383672.6020205@umn.edu> In-Reply-To: <51383672.6020205@umn.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307474B3B85mbx01winnominum_" MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 13:52:53 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307474B3B85mbx01winnominum_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Mar 7, 2013, at 1:40 AM, David Farmer > wrote: When you extrapolate that out globally, it seems clear that PI can't even r= easonably cover all the medium sized guys, no matter where you draw the lin= e. So, it seems to me that there are probably a few million organizations = globally for which PI isn't going to be practical and even IPv6's improved = renumbering will be more that an annoying inconvenience. I think the argument about the problem of getting PIs routed has some legs,= but I'm not convinced that it won't be solved. Still, if I were going to= solve this problem for an SME, here is how I would solve it: - I would deploy DHCPv6 throughout, along with RA that disables autonomous = autoconfiguration. - I would choose a PI, not a ULA, because PIs are guaranteed globally uniqu= e. But you could use a ULA and get the same effect I'm proposing=97it's j= ust a really bad idea. You only need a /48; if this practice becomes comm= on I would expect a cooperative or competitive market to form to serve the = need for /48 PIs. - I would connect to one or more ISPs, with appropriate firewalls; I'll ass= ume one for the rest of this diatribe. - I would set up the DHCP server to issue a pair of addresses that have the= same lower 80 bits; one on the PI, and one on the ISP /48. - I would publish all my internal server names on the PI, not the ISP prefi= x. Now I have a network where the address used externally is always the same a= s the address used internally in the bottom 48 bits. ISP addresses are on= ly used to communicate on the Internet. PI addresses are all that is ever= used to communicate internally. Now my ISP connection is a commodity again. If my ISP puts me over a barr= el, I just switch to a different ISP; my hosts all renumber to the new ISP,= but the PI address stays the same, so I'm not experiencing an internal ren= umbering. --_000_8D23D4052ABE7A4490E77B1A012B6307474B3B85mbx01winnominum_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Mar 7, 2013, at 1:40 AM, David Farmer <farmer@umn.edu> wrote:
When you extrapolate that out globally, it seems clear that PI can't even reaso= nably cover all the medium sized guys, no matter where you draw the line. &= nbsp;So, it seems to me that there are probably a few million organizations= globally for which PI isn't going to be practical and even IPv6's improved renumbering will be more that an ann= oying inconvenience.

I think the argument about the problem of getting PIs routed has some = legs, but I'm not convinced that it won't be solved.   Still, if I wer= e going to solve this problem for an SME, here is how I would solve it:

- I would deploy DHCPv6 throughout, along with RA that disables autono= mous autoconfiguration.
- I would choose a PI, not a ULA, because PIs are guaranteed globally = unique.   But you could use a ULA and get the same effect I'm proposin= g=97it's just a really bad idea.   You only need a /48; if this practi= ce becomes common I would expect a cooperative or competitive market to form to serve the need for /48 PIs.
- I would connect to one or more ISPs, with appropriate firewalls; I'l= l assume one for the rest of this diatribe.
- I would set up the DHCP server to issue a pair of addresses that hav= e the same lower 80 bits; one on the PI, and one on the ISP /48.
- I would publish all my internal server names on the PI, not the ISP = prefix.

Now I have a network where the address used externally is always the s= ame as the address used internally in the bottom 48 bits.   ISP addres= ses are only used to communicate on the Internet.   PI addresses are a= ll that is ever used to communicate internally.

Now my ISP connection is a commodity again.   If my ISP puts me o= ver a barrel, I just switch to a different ISP; my hosts all renumber to th= e new ISP, but the PI address stays the same, so I'm not experiencing an in= ternal renumbering.

--_000_8D23D4052ABE7A4490E77B1A012B6307474B3B85mbx01winnominum_-- From farmer@umn.edu Thu Mar 7 07:23:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D654321F8D2D for ; Thu, 7 Mar 2013 07:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.074 X-Spam-Level: X-Spam-Status: No, score=-6.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 R2Lcky30u+tD for ; Thu, 7 Mar 2013 07:23:01 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 12F4B21F8C08 for ; Thu, 7 Mar 2013 07:23:01 -0800 (PST) Received: from mail-ia0-f197.google.com (mail-ia0-f197.google.com [209.85.210.197]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 7 Mar 2013 09:22:50 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ia0-f197.google.com [209.85.210.197] #+LO+TR X-Umn-Classification: local Received: by mail-ia0-f197.google.com with SMTP id o25so2160565iad.4 for ; Thu, 07 Mar 2013 07:22:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=MsN5pHqICMFPsG1/RnOWZuArJq5/L1YEQF0QeFQMTbY=; b=c12Rhk3vNdAihNM4bu+qz6WtavjJuaBTqTdsd+jA5VsiVkAaAUmlcmbHuqoAzi1FSk TuM804t+usSAdq3w6cLdR9Fqj0F1aEzM59qcLZSg0b4mVYwA6e2rpuBs6BjAgR5aiWRn iEnd4YBQ3d/jZYX87GDmxesmx1gECn0Q0doYNNa55T1AYbJ2IKtiBQilsbPw8lf4SA6J g54RZgUWY68MdOK//sRibRqeW10fjMqyj4pQDSxAkiZ8efb1PLF5ZO3xJDd7OrrgJaKj KWehXHyIZiHMtN2LfkW7KYa/SydGvVPe+XAX2fxRzqxF7H4tp/LmW3J0b4YnMymLff5U 8AIA== X-Received: by 10.50.169.6 with SMTP id aa6mr14621189igc.1.1362669769766; Thu, 07 Mar 2013 07:22:49 -0800 (PST) X-Received: by 10.50.169.6 with SMTP id aa6mr14621182igc.1.1362669769641; Thu, 07 Mar 2013 07:22:49 -0800 (PST) Received: from oit201651646.local ([2001:470:1f11:821:d1cb:97ab:e20:3b18]) by mx.google.com with ESMTPS id l2sm27179351igb.1.2013.03.07.07.22.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Mar 2013 07:22:48 -0800 (PST) Message-ID: <5138B0C8.5050809@umn.edu> Date: Thu, 07 Mar 2013 09:22:48 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Owen DeLong References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> <5137561D.5070604@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> <5137B897.7080601@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B213C@mbx-01.win.nominum.com> <51381ADE.1000104@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B2F3E@mbx-01.win.nominum.com> <51383672.6020205! @umn.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnCJeAj1UOkn7VpK0AJ1LrIlU7WhfNi/Cl0baQ+YgfRwbioWLe/QBjMlK69Vah1Id7zJxnGLJoe9p9GY/ipmsboYIl8/ctUaBFpCD/IEx9chNOZJ7V29zFcX+OTorCPxlRS+VlY Cc: "" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 15:23:02 -0000 On 3/7/13 02:22 , Owen DeLong wrote: > > On Mar 6, 2013, at 22:40 , David Farmer wrote: > >> On 3/6/13 23:19 , Ted Lemon wrote: >> >>> You still haven't explained why PI doesn't work for you. >> >> Lets look at the numbers, I did a little Googling; First what is an SME, best definition is an organization with less than 500 employees. And therefore, a large enterprise is an organization with 500 or more employees. >> >> Within the US there are ~6M SMEs, obviously PI for all of them isn't going to make a workable route table. While were looking, Large enterprises within the US is about ~20K even extrapolating that over the globe and that's probably a workable route table. >> >> But, about ~5.38M of the SMEs have less than 20 employees, business class or residential broadband probably covers most of these guys. That leaves ~620K, of which ~530K are 20 to 99 employees, and ~90K are 100 to 499 employees. >> >> When you extrapolate that out globally, it seems clear that PI can't even reasonably cover all the medium sized guys, no matter where you draw the line. So, it seems to me that there are probably a few million organizations globally for which PI isn't going to be practical and even IPv6's improved renumbering will be more that an annoying inconvenience. > > In fact a large portion of the 20-99 employee group is also pretty well served with the business class or residential broadband you mentioned. I agree, many if not most of theses Business-Class/Residential (BC/R) Broadband could cover many if not most of these. > The remaining 90K enterprises extrapolated globally works out to not much bigger than the current IPv4 routing table. This depends on the global multiplier and how many from the above that BC/R Broadband doesn't work for them. I'm think it could be possible to push the two together. However, I think the numbers make a strong argument that there probably needs to be another solution between BC/R Broadband (Classic-PA) and Classic-PI. Personally, I like LISP or ILNP, because I believe it would serve many of the smaller guys better than BC/R Broadband. There are other options too, I'm not opposed to what Ted suggested either. However, lets be honest, must of these middle guys, and even many of the large guys, are using NAT today, and from their perspective it mostly works. Is it perfect, no. Is it good enough for many of them, yes, at least in their opinion. You, Ted, me and many on the list disagree, but we don't write the check for them, they do. Therefore, our opinion may count, but theirs counts more. > Given that there will be continued Moore's law advances in routing table capacity over the years between now and when they ALL want to multihome, I think we're actually OK there with PI. Like I said, I think there is a good argument that there is a gap. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From stefan.marksteiner@joanneum.at Thu Mar 7 08:18:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5437421F8D19 for ; Thu, 7 Mar 2013 08:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 9ixZc1ucyfyD for ; Thu, 7 Mar 2013 08:18:55 -0800 (PST) Received: from rzjgate1.joanneum.ac.at (rzjgate1.joanneum.ac.at [143.224.185.3]) by ietfa.amsl.com (Postfix) with ESMTP id 55CAC21F8D10 for ; Thu, 7 Mar 2013 08:18:55 -0800 (PST) Received: from RZJS078.jr1.local (rzjs078.joanneum.ac.at [143.224.71.19]) by rzjgate1.joanneum.ac.at (8.14.4/8.14.4) with ESMTP id r27GIjDB027951; Thu, 7 Mar 2013 17:18:45 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joanneum.at; s=sel3; t=1362673126; bh=OQZZ38maParLP8tyYNdZALHn+1P7FMb6LslIzgmV/S4=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ay+SoSNEd51A7ZCrH/5PWmKbC6CGI1LvUYixHcSOWb5huo4r06vDWIZ1hbpr3Ad9c 1SBfSjFxPnVTZEI/v+7qvPHdbfo+GK5rwpN1v5LH7cSTXK6KYNWFARmvXlbAo8bai4 XvLJhH2yFiZ5fBXMoh7SNr+tNlLXVrPLLewu/rOM= Received: from RZJC1EX.jr1.local ([169.254.2.69]) by RZJS078.jr1.local ([143.224.71.19]) with mapi; Thu, 7 Mar 2013 17:18:45 +0100 From: "Marksteiner, Stefan" To: "'Mark Andrews'" Date: Thu, 7 Mar 2013 17:18:43 +0100 Thread-Topic: [v6ops] ULA Usage Guide draft requesting for review Thread-Index: Ac4ay4qpJXBsFQxbRQO8dasJJQtUYgAgo62A Message-ID: <8A317FD8C00FEE448E52D4EE5B56BB3E02513FBE2381@RZJC1EX.jr1.local> References: <8A317FD8C00FEE448E52D4EE5B56BB3E02513FBE2301@RZJC1EX.jr1.local> <3AC1A1D6-6ED1-4A3E-BE7A-AE5306A3E6CC@delong.com> <8A317FD8C00FEE448E52D4EE5B56BB3E02513FBE2324@RZJC1EX.jr1.local> <8A317FD8C00FEE448E52D4EE5B56BB3E02513FBE2356@RZJC1EX.jr1.local> <20130307003408.C8A42307C508@drugs.dv.isc.org> In-Reply-To: <20130307003408.C8A42307C508@drugs.dv.isc.org> Accept-Language: de-DE, de-AT Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, de-AT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'v6ops@ietf.org'" Subject: Re: [v6ops] ULA Usage Guide draft requesting for review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 16:18:56 -0000 > -----Urspr=FCngliche Nachricht----- > Von: Mark Andrews [mailto:marka@isc.org] > Gesendet: Donnerstag, 07. M=E4rz 2013 01:34 > An: Marksteiner, Stefan > Cc: 'Owen DeLong'; 'Victor Kuarsingh'; 'v6ops@ietf.org' > Betreff: Re: [v6ops] ULA Usage Guide draft requesting for review >=20 >=20 > In message > <8A317FD8C00FEE448E52D4EE5B56BB3E02513FBE2356@RZJC1EX.jr1.local>, > "M arksteiner, Stefan" writes: > > Hi, > > > > firstly I want to recall, that I don't want to replace any security > > measure whatsoever by private addressing (as the trust argument below > > might suggest), but only to use it additionally to use it as a (yes, > > very > > thin) "coating on the armor", whereas a botched firewall rule might be > > the "rust" against which it is protecting (and yes again, protecting > > is a strong word for that) . Of course it could be circumvented, it > > just wanted to say that if you deploy security techniques at perimeter > > and LAN-level, it might be a good idea to do something on an > > organizational or network design level as well. IMHO, every layer of > > protection, as thin as it might be, helps. > > > > That being said, I must state that I'm not so afraid of giving a false > > sense of security by using ULAs. People who are tricked to thinking > > they are safe this way are the same people who think security is done > > by installing a firewall, you can't help them anyway. Generating > > awareness is (and always was) the most crucial thing when it comes to > > security - but this shouldn't affect the fact that every tiny step > > towards a more secure network might actually help (even if it's only > > to back up little flaws), the more as it is a step that doesn't cost > > anything (which is always the strongest enemy of security). >=20 > If NAT didn't have a continual on going costs on everyone in the industry= you > would be seeing less objections. NAT is like lead in petrol. You needed= it > once. You don't need it now. NAT is a toxic pollutant. >=20 I agree totally. But I'm not talking about NAT, instead rather about using = private addresses which should not be translated intentionally. I don't use NAT in v4 and I certainly don't intent to use NAT in v6, so IMH= O you are completely right. > > I'm of course totally with you in terms of nobody should RELY on > > methods which were never intended to be security features. > > > > Cheers, > > > > Stefan > > >=20 > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dougb@dougbarton.us Thu Mar 7 08:33:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D8521F8D09 for ; Thu, 7 Mar 2013 08:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_AFFORDABLE=1, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xL+DvoAt8e87 for ; Thu, 7 Mar 2013 08:33:17 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id C41AC21F8D05 for ; Thu, 7 Mar 2013 08:33:10 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:d35:3594:8a9f:b1ae] (unknown [IPv6:2001:470:d:5e7:d35:3594:8a9f:b1ae]) by dougbarton.us (Postfix) with ESMTPSA id 6205422B0F for ; Thu, 7 Mar 2013 16:33:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362673990; bh=7x3bnwKLVUSh3BsbEjWgj+tWx8ilvIkcQIQWhILrgpg=; h=Date:From:To:Subject:References:In-Reply-To; b=ZaB3RMFGq7yCcU9TzxmdqV+Ysf2KlzHhjsXAbI69SOB1jxVqMVczpkAE+mGmah18Z ufBH4K4bZ/akoSogIwHco+1G4/mUbiqcZ9ei0SixRYOZdIkThGt7nrL7eGRNhWzAX2 0yQDBKrslmUWUf5M5O4YV5rxOqtRk30/jfTjqxII= Message-ID: <5138C145.1090006@dougbarton.us> Date: Thu, 07 Mar 2013 08:33:09 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <20130307090524.GB9667@simplex.0x539.de> In-Reply-To: <20130307090524.GB9667@simplex.0x539.de> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 16:33:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/07/2013 01:05 AM, Philipp Kern wrote: | Doug, | | am Wed, Mar 06, 2013 at 12:44:45PM -0800 hast du folgendes geschrieben: |> First, the big enterprises and ISPs demanded PI space, and once they |> got it, they started deploying (per your statistics above). | | as a university we just became a LIR in RIPE land and got our /32. Granted, now | we're in the weird situation of being an IPv6-only LIR, because all our other | IPv4 space is unregistered legacy space. But it was still quite affordable and | we'd even still get a chunk of fresh IPv4 "for free". | | Big enterprises and ISPs certainly could've got their own space through this | process. We already covered this in great detail. 10 years ago the landscape for PI for non-ISPs was very different. Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQEcBAEBCAAGBQJROMFFAAoJEFzGhvEaGryEDdoH+QFtFItfBtjaCOIfGD9Gem/K rHGeesqlxsk6Bg43WX+ylKOeV4dU2BJH9PUm3z/asQlYBMaC/k5s0HwpPP5DtPRJ VzWiFfj0qVC6wivNgGwtqrxzsmdkVTmlW8yXCSSb+V72PbSr0Xm1vWgbaPhbOapF cUzfwQlPDQqQRtnIugkPQFfJH4bK4iJ0c/3wJVoEqCeXxo8kkox3HP2/9G21ltQy WT9S9lUwEYnGVtADNy76BLVGmD+k9fMGMrgNkAKg0Kqj24AhPtBW5jceZdG+j0O0 qEi0PwcaKHa2eAV7NkhSsKs/KYAVoBH0KwB8BQ/A009ximLX1xUFgezVjAypD6o= =CXDP -----END PGP SIGNATURE----- From pkern@simplex.0x539.de Thu Mar 7 08:37:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFDFC21F8BE4 for ; Thu, 7 Mar 2013 08:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 BCIMJSJ4F-VN for ; Thu, 7 Mar 2013 08:37:33 -0800 (PST) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA7221F8B1D for ; Thu, 7 Mar 2013 08:37:32 -0800 (PST) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UDdov-0007EI-SE for v6ops@ietf.org; Thu, 07 Mar 2013 17:37:29 +0100 Received: from [2001:470:720c:0:2026:d67c:7df2:1d64] (helo=simplex.lan.home.philkern.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1UDdow-0005cO-UK for v6ops@ietf.org; Thu, 07 Mar 2013 17:37:31 +0100 Received: from pkern by simplex.lan.home.philkern.de with local (Exim 4.80) (envelope-from ) id 1UDdou-0008PK-Tc for v6ops@ietf.org; Thu, 07 Mar 2013 17:37:28 +0100 Date: Thu, 7 Mar 2013 17:37:28 +0100 From: Philipp Kern To: v6ops@ietf.org Message-ID: <20130307163728.GA32180@simplex.0x539.de> References: <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <20130307090524.GB9667@simplex.0x539.de> <5138C145.1090006@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5138C145.1090006@dougbarton.us> Organization: 0x539 dev group User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 16:37:34 -0000 On Thu, Mar 07, 2013 at 08:33:09AM -0800, Doug Barton wrote: > We already covered this in great detail. 10 years ago the landscape for > PI for non-ISPs was very different. I'm talking about 2009, shortly before the introduction of PI in RIPE land. It was not a deterrent at all and the financial burden, while significantly more than PI, was also negligible. (Although I can understand if enterprises don't want to go into the business of managing numbers themselves.) I don't think that we were the only ones doing it that way. Kind regards Philipp Kern From dougb@dougbarton.us Thu Mar 7 10:21:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E8521F8AA1 for ; Thu, 7 Mar 2013 10:21:10 -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=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 mwPosnQ8oUVt for ; Thu, 7 Mar 2013 10:21:10 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA1621F89F9 for ; Thu, 7 Mar 2013 10:21:07 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:d35:3594:8a9f:b1ae] (unknown [IPv6:2001:470:d:5e7:d35:3594:8a9f:b1ae]) by dougbarton.us (Postfix) with ESMTPSA id E611422B0F for ; Thu, 7 Mar 2013 18:21:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362680467; bh=4szl4BzWls3kSpOULeT7S2kCRBgshtOPdgrIgSEILI0=; h=Date:From:To:Subject:References:In-Reply-To; b=n+0LkpTgzol1tBmPFJLXloa1qligvRlCX7br2SNDq01XSTFCgrdTXXYZ4uKG4oNP1 IJGOCQQ/u3JsU/jAvUjuZEpIzIUXNd4dtQR/bj28yfVubgzenK6Unk2OlnmL9Xqmyl NTkALKoauHbBSeA46BJONha+X2Sb1wuXVfyWSV2M= Message-ID: <5138DA92.8060002@dougbarton.us> Date: Thu, 07 Mar 2013 10:21:06 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <20130307090524.GB9667@simplex.0x539.de> <5138C145.1090006@dougbarton.us> <20130307163728.GA32180@simplex.0x539.de> In-Reply-To: <20130307163728.GA32180@simplex.0x539.de> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 18:21:11 -0000 On 03/07/2013 08:37 AM, Philipp Kern wrote: > I'm talking about 2009 2009 > 2003 :) From wwwrun@rfc-editor.org Thu Mar 7 16:43:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1922121F8714; Thu, 7 Mar 2013 16:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.057 X-Spam-Level: X-Spam-Status: No, score=-102.057 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zE5RBX0FfzF; Thu, 7 Mar 2013 16:42:57 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D620421F870A; Thu, 7 Mar 2013 16:42:57 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id CD674B1E00B; Thu, 7 Mar 2013 16:29:05 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130308002905.CD674B1E00B@rfc-editor.org> Date: Thu, 7 Mar 2013 16:29:05 -0800 (PST) Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 6883 on IPv6 Guidance for Internet Content Providers and Application Service Providers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 00:43:01 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6883 Title: IPv6 Guidance for Internet Content Providers and Application Service Providers Author: B. Carpenter, S. Jiang Status: Informational Stream: IETF Date: March 2013 Mailbox: brian.e.carpenter@gmail.com, jiangsheng@huawei.com Pages: 24 Characters: 60430 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-icp-guidance-05.txt URL: http://www.rfc-editor.org/rfc/rfc6883.txt This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to hosting providers or to any enterprise network preparing for IPv6 users. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From farmer@umn.edu Thu Mar 7 17:47:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D28A21F8659 for ; Thu, 7 Mar 2013 17:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.066 X-Spam-Level: X-Spam-Status: No, score=-6.066 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 ulXal0ypyjSS for ; Thu, 7 Mar 2013 17:47:31 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id A32AF21F863C for ; Thu, 7 Mar 2013 17:47:31 -0800 (PST) Received: from mail-ie0-f198.google.com (mail-ie0-f198.google.com [209.85.223.198]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 7 Mar 2013 19:47:25 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f198.google.com [209.85.223.198] #+LO+TR X-Umn-Classification: local Received: by mail-ie0-f198.google.com with SMTP id 17so6626109iea.5 for ; Thu, 07 Mar 2013 17:47:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=DJvYM51Q921RKwW51cD4furr1EVVljLSAsY9P6wCQio=; b=NXwPyKw37HRUKPpw6REA1nIM+9bkMfbmlMbCS3iD8njyTvZ/V4w3b2MGS8Cl8RLttY E9dWAZ7GgIjGp4ZHWhmxj37Ao8bISQ0mF8qUCpu4BSaHzAtmy28IWkRfrXab0gmsvI54 MGvIceDMj9DxZp8w4Erz4QfeQASSosqeuYq1vTRYZ1PBASU5UWL9DYL/LgwOwsQ/7aR0 o7lBh7B0VJJuFC29uYWy4jbVRxwCN51JQfUwGriICMm4PKrvx1aHRRGm0DwudXgGHvmT r+q6JRydd0jaq+ugLGAhjPDZUXAbyW11QmLSGsCgSGX6eeSZdJg5T7MKeY49g5ItxUhl qu1A== X-Received: by 10.50.87.161 with SMTP id az1mr358487igb.33.1362707245646; Thu, 07 Mar 2013 17:47:25 -0800 (PST) X-Received: by 10.50.87.161 with SMTP id az1mr358482igb.33.1362707245530; Thu, 07 Mar 2013 17:47:25 -0800 (PST) Received: from x-134-84-88-33.nts.umn.edu ([2607:ea00:101:2001:e09d:f4f9:ab8:75bb]) by mx.google.com with ESMTPS id vb15sm4078108igb.9.2013.03.07.17.47.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Mar 2013 17:47:24 -0800 (PST) Message-ID: <5139432A.4070505@umn.edu> Date: Thu, 07 Mar 2013 19:47:22 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ted Lemon References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> <5137561D.5070604@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> <5137B897.7080601@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B213C@mbx-01.win.nominum.com> <51381ADE.1000104@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B2F3E@mbx-01.win.nominum.com> <51383672.6020205@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B3B85@mbx-01.win.nominum .com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474B3B85@mbx-01.win.nominum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQn2lUhPlIncGrFqQYhZ87R4WwP/oI8zt2InkWriBUNLgIxljea64gjSWydyrVz00w4L4uqSrmyF9ebXSzsyKq1afpKKL8vp9caOwNgoc/ZS/1Q4kBjXAiJRYcPcYqVq377M+bRa Cc: "" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 01:47:32 -0000 On 3/7/13 07:52 , Ted Lemon wrote: > On Mar 7, 2013, at 1:40 AM, David Farmer > wrote: >> When you extrapolate that out globally, it seems clear that PI can't >> even reasonably cover all the medium sized guys, no matter where you >> draw the line. So, it seems to me that there are probably a few >> million organizations globally for which PI isn't going to be >> practical and even IPv6's improved renumbering will be more that an >> annoying inconvenience. > > I think the argument about the problem of getting PIs routed has some > legs, but I'm not convinced that it won't be solved. I'm not convince that classic-PI couldn't solve the problem either, but I think there is a strong argument that their could be a gap. While I think it might be possible for PI to cover the gap, I'm worried it might not. > Still, if I were going to solve this problem for an SME, here is how > I would solve it: > > - I would deploy DHCPv6 throughout, along with RA that disables > autonomous autoconfiguration. > - I would choose a PI, not a ULA, because PIs are guaranteed globally > unique. But you could use a ULA and get the same effect I'm > proposing—it's just a really bad idea. You only need a /48; if this > practice becomes common I would expect a cooperative or competitive > market to form to serve the need for /48 PIs. > - I would connect to one or more ISPs, with appropriate firewalls; I'll > assume one for the rest of this diatribe. > - I would set up the DHCP server to issue a pair of addresses that have > the same lower 80 bits; one on the PI, and one on the ISP /48. > - I would publish all my internal server names on the PI, not the ISP > prefix. > > Now I have a network where the address used externally is always the > same as the address used internally in the bottom 48 bits. ISP > addresses are only used to communicate on the Internet. PI addresses > are all that is ever used to communicate internally. > > Now my ISP connection is a commodity again. If my ISP puts me over a > barrel, I just switch to a different ISP; my hosts all renumber to the > new ISP, but the PI address stays the same, so I'm not experiencing an > internal renumbering. I'd encourage you to write a draft proposing that model. This is essentially non-connected PI + connected PA which is similar to the ULA + GUA scenario in this draft. This would be workable for SMEs especially the larger ones, but ULA + GUA still probably makes the most sense in the homenet scenario. Maybe there should be a section in this draft quickly discussing alternatives to using ULA all together, like PI for non-connected networks, etc... It shouldn't detail the full scenario like you just did. But, point out that there are viable alternatives to using ULA that could be considered. ARIN's end-user policy explicitly supports assignments for non-connected networks, I wrote it. And there are advantages to this like real uniqueness not only statistical uniqueness, and fully functioning reverse DNS that won't have split DNS issues, just to name a few. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From owen@delong.com Thu Mar 7 19:10:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBD721F8696 for ; Thu, 7 Mar 2013 19:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 ERqv3HKik4he for ; Thu, 7 Mar 2013 19:10:55 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 06A5E21F854E for ; Thu, 7 Mar 2013 19:10:54 -0800 (PST) Received: from [10.255.251.216] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r28395P4004460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Mar 2013 19:09:06 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r28395P4004460 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362712146; bh=uB36Ccpo4Y8v3c/35FmfFmmjpkk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=WJoDtG+fUKWQxDW2vyrG3d7j/xebAcKwFFJpKa/9U/xR4MHsir/Loq1XU4pD0vOtN Ml+xiJzrwwB5gA0TWPBKHFfLe9wAXJVxKOr4eVPjNnrabk1b1NQ0CTSdZwpuZ3nY6A xB83n8Ck59qbhqSuBlJijAjonLimggrgr+42YaEc= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <5139432A.4070505@umn.edu> Date: Thu, 7 Mar 2013 19:09:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7A8A43F5-3D4C-410F-8B8F-F08A0E8EC778@delong.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136CC60.8060005@dougbarton.us> <51370302.7000003@gmail.com> <0E735FAE-B28B-4A3E-9957-232B4E6717C0@delong.com> <5137561D.5070604@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B0CE7@mbx-01.win.nominum.com> <5137B897.7080601@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B213C@mbx-01.win.nominum.com> <51381ADE.1000104@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B2F3E@mbx-01.win.nominum.com> <51383672.6020205@umn.edu> <8D23D4052ABE7A4490E77B1A012B6307474B3B85@mbx-01.win.nominu! m .com> <5139432A.4070505@umn.edu> To: David Farmer X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 07 Mar 2013 19:09:06 -0800 (PST) Cc: "" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 03:10:55 -0000 On Mar 7, 2013, at 5:47 PM, David Farmer wrote: > On 3/7/13 07:52 , Ted Lemon wrote: >> On Mar 7, 2013, at 1:40 AM, David Farmer > > wrote: >>> When you extrapolate that out globally, it seems clear that PI can't >>> even reasonably cover all the medium sized guys, no matter where you >>> draw the line. So, it seems to me that there are probably a few >>> million organizations globally for which PI isn't going to be >>> practical and even IPv6's improved renumbering will be more that an >>> annoying inconvenience. >>=20 >> I think the argument about the problem of getting PIs routed has some >> legs, but I'm not convinced that it won't be solved. >=20 > I'm not convince that classic-PI couldn't solve the problem either, = but I think there is a strong argument that their could be a gap. While = I think it might be possible for PI to cover the gap, I'm worried it = might not. >=20 But why create a gap where one doesn't exist just because it might = happen? ULA+{NAT,NPT} comes with huge drawbacks. Worst of all, most of those = drawbacks effect people outside of the ones implementing the = ULA+{NAT,NPT} network which means the people doing the damage don't have = to face most of the consequences of their actions and are, instead, able = to inflict them on others. As such, I strongly believe that we should do everything possible to = make sure that such a solution is only implemented where absolutely = necessary and with due consideration of the tradeoffs. Hopefully, if we = do this well enough, ISVs will be able to start producing applications = without NAT traversal in the medium-term future. I think having a gap is pretty unlikely, actually. We already have = routers that can handle a million prefixes and I expect that in less = than 3 years, that will be approaching 2M or more. >> Still, if I were going to solve this problem for an SME, here is how >> I would solve it: >>=20 >> - I would deploy DHCPv6 throughout, along with RA that disables >> autonomous autoconfiguration. >> - I would choose a PI, not a ULA, because PIs are guaranteed globally >> unique. But you could use a ULA and get the same effect I'm >> proposing=97it's just a really bad idea. You only need a /48; if = this >> practice becomes common I would expect a cooperative or competitive >> market to form to serve the need for /48 PIs. >> - I would connect to one or more ISPs, with appropriate firewalls; = I'll >> assume one for the rest of this diatribe. >> - I would set up the DHCP server to issue a pair of addresses that = have >> the same lower 80 bits; one on the PI, and one on the ISP /48. >> - I would publish all my internal server names on the PI, not the ISP >> prefix. >>=20 >> Now I have a network where the address used externally is always the >> same as the address used internally in the bottom 48 bits. ISP >> addresses are only used to communicate on the Internet. PI = addresses >> are all that is ever used to communicate internally. >>=20 >> Now my ISP connection is a commodity again. If my ISP puts me over = a >> barrel, I just switch to a different ISP; my hosts all renumber to = the >> new ISP, but the PI address stays the same, so I'm not experiencing = an >> internal renumbering. >=20 > I'd encourage you to write a draft proposing that model. This is = essentially non-connected PI + connected PA which is similar to the ULA = + GUA scenario in this draft. This would be workable for SMEs = especially the larger ones, but ULA + GUA still probably makes the most = sense in the homenet scenario. Why? > Maybe there should be a section in this draft quickly discussing = alternatives to using ULA all together, like PI for non-connected = networks, etc... It shouldn't detail the full scenario like you just = did. But, point out that there are viable alternatives to using ULA = that could be considered. ARIN's end-user policy explicitly supports = assignments for non-connected networks, I wrote it. And there are = advantages to this like real uniqueness not only statistical uniqueness, = and fully functioning reverse DNS that won't have split DNS issues, just = to name a few. I like this idea. Owen From fred@cisco.com Fri Mar 8 01:36:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF79421F8648 for ; Fri, 8 Mar 2013 01:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aj5-JTD-CBUP for ; Fri, 8 Mar 2013 01:36:30 -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 BCAD621F8691 for ; Fri, 8 Mar 2013 01:36:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=194; q=dns/txt; s=iport; t=1362735390; x=1363944990; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=cMemIPyEUkqrQUKg20pm4hYwg4WPW2xOOz8LpUpyDjU=; b=NZUH1uPzUdguai7BPiSdQqq4awbNSzxJTPUjskNfgRR8yPqQd5Oc07DL T3WRG9wi6ZTDy54rpmyuNe08vxcmdNQNFvKO2yjDydk2gEyDORLZO/OHE 597fIsHDoJy4BdgWTBJdjAdnPtSyUjbmfHWFSKo/o/nHYvEc8xrpIIv1Z s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEKAFewOVGtJV2a/2dsb2JhbABDxEQBAwEDAYFYFnSCLQEEOj8SASoUQicEDg2IC7sYjlsxgmZhA6c8gwmCJw X-IronPort-AV: E=Sophos;i="4.84,806,1355097600"; d="scan'208";a="185234522" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 08 Mar 2013 09:36:30 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r289aUlt014720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Mar 2013 09:36:30 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Fri, 8 Mar 2013 03:36:30 -0600 From: "Fred Baker (fred)" To: IPv6 Ops WG Thread-Topic: Working Group Chair Hours Thread-Index: AQHOG+BpsJqmCtdoVUaHg5tmRyzMKQ== Date: Fri, 8 Mar 2013 09:36:29 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B7C465E@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.246.218] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] Working Group Chair Hours X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 09:36:35 -0000 John and I will be in the IESG Breakout Room from 16:00-17:00 Monday. We're= there to be available to draft authors or design teams that would like a f= ew moments to chat with the chairs.= From phdgang@gmail.com Fri Mar 8 15:32:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A6B21F8569 for ; Fri, 8 Mar 2013 15:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 EgQDY2utdVJQ for ; Fri, 8 Mar 2013 15:32:38 -0800 (PST) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id 49E8921F856C for ; Fri, 8 Mar 2013 15:32:38 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id g10so80826qah.4 for ; Fri, 08 Mar 2013 15:32:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=By0+2rXzL4kFdH3rBNDJYa7zFdbxtHY8L+qgWCiaa3U=; b=Q/lmwJRcyzlMgjbcg2UTht6CDVyi91YiSIk6X+GQuPgS7SH9VQ5/2P5cx7+zWKHWy0 hw5Mnqs2A5eAP568G78A7u7ueeBErdxmviPL4l8NVJHL4dv0RC6fBllozv5naZbc6sqM CrknaX/4SPQMCL6+G/gvbix8SbStPvWl2xOxx4T+XLQzKFlY3HjfqbR1tFDLxguk0qOa jairVEsdDU7LoxwVm6tMHGQik6be41JqRs96mQaCzN3N7EtJ06BU3n8a6z/IDFygoAet YiXnipNHT8F2Lv4ob1GiqKx6HljE2d2MA+4zT7bx7lHNrRBp9PRzBQtapmTa2mPIo9os Tmhg== MIME-Version: 1.0 X-Received: by 10.224.182.70 with SMTP id cb6mr6440597qab.80.1362785557812; Fri, 08 Mar 2013 15:32:37 -0800 (PST) Received: by 10.49.71.18 with HTTP; Fri, 8 Mar 2013 15:32:37 -0800 (PST) In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923041F47A432@PRVPEXVS15.corp.twcable.com> References: <2671C6CDFBB59E47B64C10B3E0BD5923041F47A432@PRVPEXVS15.corp.twcable.com> Date: Sat, 9 Mar 2013 07:32:37 +0800 Message-ID: From: GangChen To: "George, Wes" Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops Subject: Re: [v6ops] comments for draft-ietf-v6ops-nat64-experience [was draft-ietf-v6ops-nat64-experience WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 23:32:40 -0000 Hi Wes, Many thanks for the review and detailed comments. My reply is inline. 2013/3/7, George, Wes : > Apologies for not getting it out before the conclusion of WGLC, but it seems > that the authors are still looking for comments before revising it, so I've > reviewed this document. > > Introduction, third paragraph. I think this sentence is out of place and > should be removed: > "There is also the troublesome trend of access > network providers squatting on IPv4 address space that they do not > own." > It really doesn't tie into the rest of that paragraph, nor does it relate > overmuch to the reasons for deploying NAT64. Carriers that need to support > customers that have end devices which still require IPv4 connectivity are > going to do so by whatever means they feel appropriate, and NAT64 doesn't > solve that problem. NAT64 solves the problem of an SP that has the means to > force all (or a large subset of) devices to IPv6-only but still needs a way > for those users to reach IPv4-only content and services. I won't object to remove it. That seems superfluous for a clear description. PS: The original intent of the sentence is to describe the incentive of enabling access network with IPv6. Doing NAT64 will bridge those IPv6 access network with dominated IPv4 services. > 3.2 - this section is currently pretty weak. Are there any references to the > different methods of HA in NAT64 that you could provide, either via vendor > implementation or in the standards themseles? One early work was documented at http://tools.ietf.org/html/draft-xu-behave-stateful-nat-standby-06, in which three modes were described. I guess the draft could revisit those considerations to consolidate the statement. > Is the assertion that most > traffic is short-lived and therefore cold standby is ok backed up by any > production or lab testing demonstrating the user experience for NAT64? It There is statistic of service traffic in a mobile network could be the evidence. Most traffic (almost 94% of amount of traffic) is accounted by Http, WAP browsing, which contribute this assertion. > needs to discuss what assumptions you made about how short-lived is > short-lived, how long a cold-standby failover should take before it becomes > an unacceptable impact to customers, and whether there are certain types of > traffic more sensitive to this problem (TCP vs UDP, streaming vs surfing, Good suggestion. More concrete data backing up statement would be added to verify the assumptions at next version. > etc). It may also need to discuss true cold standby vs warm standby, because > in most cases, I think what you're referring to as cold standby is more like > warm standby (online at all times, but not actively exchanging all state > information). This likely also ties into section 3.4, since the choice here > will affect the quality of experience. I would like to see more effort to > tie the two ideas together. IOW, if you are expecting that this will be a > second-class service that only covers the major traffic (http, etc) then it > might be ok for there to be cold standby and session resets. If you're > trying to make this a first-class alternative (within the limits of the > technology of course), then session resets might not be acceptable. I guess it's worth to do some tests regarding those ties. Current draft didn't cover because the lack of evaluation on user experiences impacts of different modes. Let's try to start with the testing. > I would also move 3.5 so that it is immediately after 3.2. These are both > talking about similar areas (scale and resiliency) and make more sense when > more closely tied together, especially when bolstered with some discussion > of how load balancers are used for resiliency and scale for normal use, and > how that might be different for NAT64/FE use. Will a change at next version. > 3.3 - there have been a couple of drafts floating around trying to build a > NAT/CGN mib, whether generic or specific to NAT64. They haven't really gone > anywhere. Might be useful to discuss whether the lack of a mib is making > this harder, or if it doesn't matter. I would prefer to discuss the mib issues at a separated section other than section 3.3 "Traceability" because that is different topics. Current NAT64 equipment didn't offer MIB AFAIK. > 3.6 - I'm not following the explanation of the MTU issues here. It seems to > assert that IPv6 can't deal with packets smaller than 1280, which really > isn't true, it just requires end host to end host fragmentation. Therefore, > IMO part of a NAT64 device's job is going to be to manage the PTB messages > and MTU discovery between the protocols and act as the IPv6 destination end > host so that it can facilitate any required IPv6 endhost-to-endhost > fragmentation if the required MTU is below 1280 - it basically has to detect > the outgoing MTU and enforce it back to its end host. It's a lot of state to > maintain probably, but doable. This is also a corner case, because IPv4 > allows almost all packets (except those with the DF bit set) to be > fragmented by middleboxes if their MTU is smaller than the offered packet, > making it largely transparent to the end hosts. The IPv6 host can send > whatever size packet they want, and the IPv4 side will just fragment as > necessary unless the NAT64 box is doing something dumb like setting DF on > the outgoing IPv4 packets it is generating. > Is this meant to discuss the situation where a NAT64 box receives IPv4 > packets smaller than 1280 and then has to send them to the IPv6 host? The draft discuss the case where a NAT64 receives IPv6 packets with fragmentation header in which M=0 & offset=0(that is caused if IPv6 nodes receive PTB<1280 via NAT64 box). Those packets likely impact other fragments already queued with the same set of {IPv6 Source Address, IPv6 Destination Address, Fragment Identification}. If the NAT64 box is compliant with RFC5722, there is risk that all the fragments have to be dropped. The draft recommends doing I-D.ietf-6man-ipv6-atomic-fragments on NAT64-CGN to exclude the risk. > 4 - I'm not certain figure 2 is helpful in its current form. I had to look 3 > times before I figured out what was even different from figure 1, and the > addition of one word doesn't really require a new diagram. > Honestly, this entire section repeats a lot of the content from the previous > sections, and I think the draft would be much tighter and readable if you > simply integrated the little bit of additional information into the previous > sections, either as subsections or just as part of the overall discussion. I > don't think it adds much value as a standalone section. Generally, the > drafts that you reference here do a better job of discussing the use of a > loadbalancer as a method to provide IPv6 to a mostly IPv4-only backend and > vice versa. Will try to restruct the contents at next update. Hopefully, it's more clearer than current form if the draft integrated NAT-FE&CGN in one section. > Regarding Randy's comments on e2e/smart edge/stupid core and the interaction > with NAT64, I think they're mostly incompatible. While NAT64 makes running > an IPv6-only network more possible while we wait for ubiquitous IPv6 > deployment on the content/service side, it's still fundamentally a NAT, a > stateful box in the middle that interferes with end to end communications > and may require ALGs for full function. It also still requires investment in > those boxes in the middle, which means that you're sort of stuck with them > until they depreciate, unless you can repurpose them for some other use. The > only thing you could do here is make the point that in order to keep the > intelligence at the edge, NAT64/DNS64 implementations should be pushed as > far down into the network as possible. But even then there are other > tradeoffs on placement to consider, such as the scale of an individual NAT64 > box or the number of devices that would be required by a more decentralized > placement, or network design and topology (as you have alluded to with the > mobile examples). I have a different understanding because Randy's proposal is likely applied to stateless NAT64 in the core. Those principles are incompatible with stateful NAT64 consideration. That reminds me a point: should the draft cover the case of stateless NAT64? FWIW, both stateful&stateless NAT64 has customers in real world. They have different incentives. A tentative showcase is stateful NAT64-CGN: NAT64 on Core router or in a mobile network(464xlat) stateful NAT64-FE: an HTTP proxy for IPv4 backend in DC stateless NAT64-CGN: MAP/4rd/A+P kinds of solutions stateless NAT64-FE: I-D.anderson-siit-dc Is it of value to discuss both in the I-D.ietf-v6ops-nat64-experience? > By the ruler that Randy was proposing in his slides, this is less bad > because at least it sets up a network to be actually running IPv6 instead of > extending IPv4, and only does IPv4 to compensate for those who haven't > deployed it yet. But it's still limited to places that are unencumbered by a > need to continue supporting legacy IPv4 devices, which limits its > applicability in the Access Provider community. > > Nits: 3.1 has a number of spelling errors Will fix at next update Best Regards Gang > Wes George > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >> Of GangChen >> Sent: Tuesday, March 05, 2013 4:02 AM >> To: v6ops >> Subject: [v6ops] comments for draft-ietf-v6ops-nat64-experience [was >> draft-ietf-v6ops-nat64-experience WGLC] >> >> wg, >> >> There are offline comments from Randy Bush suggest to consolidate >> NAT64 statements with the principle of e2e preservation and "smart edge >> & stupid core". It was presented at http://archive.psg.com/120229.apops- >> v4-life-extension.pdf >> >> Personally, I think it's worth to add some texts of those principle as a >> part of NAT64 deployment considerations, since it would beneficial to >> advance IPv6 deployment. >> >> I would like to seek wg opinions on this point or futher comments >> regarding to http://tools.ietf.org/html/draft-ietf-v6ops-nat64- >> experience. >> >> Please take the time to review the document in order to make sure the >> draft doesn't lose anything at next update. >> >> Best Regards >> >> Gang >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > This E-mail and any of its attachments 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 are not > the intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify the > sender immediately and permanently delete the original and any copy of this > E-mail and any printout. > From markzzzsmith@yahoo.com.au Fri Mar 8 17:03:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BC021F85A1 for ; Fri, 8 Mar 2013 17:03:20 -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=[AWL=-0.600, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6] 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 CLClnPzCrptC for ; Fri, 8 Mar 2013 17:03:19 -0800 (PST) Received: from nm30-vm0.bullet.mail.bf1.yahoo.com (nm30-vm0.bullet.mail.bf1.yahoo.com [98.139.213.126]) by ietfa.amsl.com (Postfix) with ESMTP id 822C021F85E0 for ; Fri, 8 Mar 2013 17:03:19 -0800 (PST) Received: from [98.139.215.141] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 09 Mar 2013 01:03:18 -0000 Received: from [98.139.212.223] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 09 Mar 2013 01:03:18 -0000 Received: from [127.0.0.1] by omp1032.mail.bf1.yahoo.com with NNFMP; 09 Mar 2013 01:03:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 484998.97247.bm@omp1032.mail.bf1.yahoo.com Received: (qmail 69024 invoked by uid 60001); 9 Mar 2013 01:03:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1362790998; bh=4jtBwD1wIUEuWh1cxK3KN07XWCNXkzNArw1MnPgnWQ4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CQeKtkdC4WZHxC+/F9yiQQ/w819x53IO/8DqZ0oQMjI7YspEQBmo4DpDS+/orTM5yQsA0qCE06o72lH2mofqD9e9n+GP1GSJxauBH0dR1zTZIJEDEz7goP2PtT1YAGyecxkwmqXIbvR/0Q+zZRohUMhwt9Nh9eJLmiVp6p3Dw6I= 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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kqa1suEY11QQAHca6VhTBqHB0eG0Mwblakps3gR98limnOHTWvfh4LRAUD77UiMGzYJI6qJL/OJBKHD1NaC6HzTq1yakYsXkp3Q5gMV2n1pXyKHbu102Csk6lUupnFhrHxT1Iq6RXjt3ZhxIsQbGkwqu+kowEbe7D3tJSuAgJVo=; X-YMail-OSG: MOcziBgVM1li0r8p1YoL8.NtFa8an0Jqq0aYXeiuXELlqto D4trFI4VOBLHAXgEYwaKPIkRrkJNemlrm0U7a3rwTgRSuQkIVKpT.NqiwLau CkrWvGP.IXLnt.AvIy7wkNUyN9bpXF2sUiPgiMiglPWhO8ZxHrnFb0AC6cvB vpW3xt4bVIw9JG.bQ8SJZVj4M6i4BAuiob6PDIgewThlOxmw4ezcUaYAEXLC 0YhlwFCgZmrRQkwkySGZ_KXqdVj_bRTYjYXcn_jdbmEfoiKSBJR5c8rDcIIK NYzNFoxJgYDzveQVkuBt4P0KFNvDCL_LZLeqsftfutrxAaPUyELgfmiH6gID 0.o02GNaoAvE5NyAiItbpXGcqE3kXwflE0JYprJH4zylT1sROWHUZbYGQpao A0Zhb9rMSvSjOGao5go9SafIwOu.lnZay00O31PFUOF.cge.t6xC64u9KfKF R.qQKISXyuXa3i.ueMf5HGVhnIrr9NFA4rsNht7E8R8NYyjNXPZuXz6cqFSo WhUhfMis6mrXLaA8M8iiJEcY- Received: from [150.101.221.237] by web142504.mail.bf1.yahoo.com via HTTP; Fri, 08 Mar 2013 17:03:18 PST X-Rocket-MIMEInfo: 001.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBEb3VnIEJhcnRvbiA8ZG91Z2JAZG91Z2JhcnRvbi51cz4KPiBUbzogInY2b3BzQGlldGYub3JnIFdHIiA8djZvcHNAaWV0Zi5vcmc.Cj4gQ2M6IAo.IFNlbnQ6IFRodXJzZGF5LCA3IE1hcmNoIDIwMTMgODo1MCBBTQo.IFN1YmplY3Q6IFJlOiBbdjZvcHNdIFVMQSBkaXNjdXNzaW9uICMxIFVMQStOQVQKPiAKPiBPbiAwMy8wNi8yMDEzIDAxOjI0IFBNLCBUZWQgTGVtb24gd3JvdGU6Cj4.ICBPbiBNYXIgNiwgMjAxMywgYXQgNDowMiBQTSwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.135.514 References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> Message-ID: <1362790998.58259.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Fri, 8 Mar 2013 17:03:18 -0800 (PST) From: Mark Smith To: Doug Barton , "v6ops@ietf.org WG" In-Reply-To: <5137BA3E.4020604@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 01:03:21 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Doug Barton =0A> To: "v6ops@ietf.org WG" =0A> Cc: =0A> Sent: T= hursday, 7 March 2013 8:50 AM=0A> Subject: Re: [v6ops] ULA discussion #1 UL= A+NAT=0A> =0A> On 03/06/2013 01:24 PM, Ted Lemon wrote:=0A>> On Mar 6, 201= 3, at 4:02 PM, Doug Barton > > wrote:=0A>>> Small - medium enterprises are pretty much the only = place where a=0A>>> NPTv6 + ULA solution makes sense.=0A>> =0A>> Why does= it make sense in this case?=0A> =0A> I've already covered this ad nauseum = in previous posts on this thread, feel =0A> free to review them for the det= ails.=0A> =0A> Short answer, "enterprises hate renumbering."=A0=0A=0AHow mu= ch experience do they have renumbering IPv6, using the preferred and valid = lifetime mechanisms to phase in and phase out two (or more) GUA prefixes? H= ave they taken advantage of having a stable internal ULA address space so t= hat only their external connectivity would be impacted by a GUA renumbering= process?=A0Or are you making these assertions about IPv6 practices purely = based on IPv4 capabilities, experience and history?=0A=0AVery few enterpris= es have deployed IPv6, so I don't think their experience with just IPv4 sho= uld be used to limit the guidance and advice on how to deploy IPv6. This is= the trap of treating IPv6 as nothing more than IPv4 with bigger addresses.= =0A=0A=0A>As in, really really =0A> hate it. A lot. Totally. NPT gives them= the ability to be provider agnostic =0A> without having to worry about ren= umbering their inside network, or dealing with =0A> the trouble and expense= of PI space.=0A>=A0=0A> Doug=0A=0A> =0A> _________________________________= ______________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.ie= tf.org/mailman/listinfo/v6ops=0A> From dougb@dougbarton.us Fri Mar 8 17:51:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2009821F85C6 for ; Fri, 8 Mar 2013 17:51:10 -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=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 U9EUPqO6XZUC for ; Fri, 8 Mar 2013 17:51:09 -0800 (PST) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 91DBD21F8569 for ; Fri, 8 Mar 2013 17:51:08 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:d99a:8a3a:e14e:ead1] (unknown [IPv6:2001:470:d:5e7:d99a:8a3a:e14e:ead1]) by dougbarton.us (Postfix) with ESMTPSA id 1A3A822B0F for ; Sat, 9 Mar 2013 01:51:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362793868; bh=lG1kdLMFE85/zyrkTihs9SiKdiHCYZCWf2sC/T4f+Wc=; h=Date:From:To:Subject:References:In-Reply-To; b=oiwBlPPhChqUcqtxvToY9Bf/l0NReC7KE1dZLjNKQGbFOnRHQK/A/JzI9quRx+xh7 gsR80ZbJNYkCV7L/9q5UbLlK3nlvstjTUfxatZba0mY33YW0E8UFRP3aNxfR0Y3qHj YqYvdEfRLeIyUgL4uQ6xWioLRwuqYj/TCMOkkxfk= Message-ID: <513A958B.7070104@dougbarton.us> Date: Fri, 08 Mar 2013 17:51:07 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "v6ops@ietf.org WG" References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <1362790998.58259.YahooMailNeo@web142504.mail.bf1.yahoo.com> In-Reply-To: <1362790998.58259.YahooMailNeo@web142504.mail.bf1.yahoo.com> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 01:51:10 -0000 I've covered this ground already, so for those who read my previous posts, sorry for the spam, feel free to hit delete now. On 03/08/2013 05:03 PM, Mark Smith wrote: > ----- Original Message ----- >> From: Doug Barton To: "v6ops@ietf.org WG" >> Cc: Sent: Thursday, 7 March 2013 8:50 AM Subject: >> Re: [v6ops] ULA discussion #1 ULA+NAT >> >> On 03/06/2013 01:24 PM, Ted Lemon wrote: >>> On Mar 6, 2013, at 4:02 PM, Doug Barton >> > wrote: >>>> Small - medium enterprises are pretty much the only place where >>>> a NPTv6 + ULA solution makes sense. >>> >>> Why does it make sense in this case? >> >> I've already covered this ad nauseum in previous posts on this >> thread, feel free to review them for the details. >> >> Short answer, "enterprises hate renumbering." > > How much experience do they have renumbering IPv6 Totally irrelevant question, as the real pain points in renumbering are not the issues of getting new addresses on systems. Most end-user hosts, and a non-trivial number of servers, are configured dynamically nowadays. > using the > preferred and valid lifetime mechanisms to phase in and phase out two > (or more) GUA prefixes? I agree that on paper that sounds like a good plan, but I'd like to see more information from competent networking folks who have actually implemented it. Meanwhile, given the incredibly low average skill level of even large enterprise network "engineers," and the low, or nonexistent level of such expertise in the SME world, I have little to no confidence that this is a viable strategy. I would love to be proven wrong though. > Have they taken advantage of having a stable > internal ULA address space so that only their external connectivity > would be impacted by a GUA renumbering process? I think this idea has merit as well, but it hits on the real pain points in renumbering: the meta issues surrounding firewalls, ACLs, bookmarks, hardware and software configuration, etc. No matter how much you tell people, "our policy is to use this inside network to access this set of resources" when that doesn't work, but the "outside" network does, people are going to go with what works. And then those things get hard-coded somewhere, and then they have to be supported "forever." I've seen this on IPv4 only networks lots of times, there is no reason to believe it would be any different with IPv6. People who range from minimally competent to actively dangerous with IPv4 now cannot be trusted to "do it right" with complex IPv6 configurations. People in the IETF tend to poo-poo these kinds of things when I talk about them, insisting that no one could really be that stupid/careless. As I've pointed out in the past, people around here are way above average, so yeah, these kinds of problems would seem ridiculous to them. OTOH, I work with the "below average" crowd day in and day out, and I could tell you stories ... > Or are you making > these assertions about IPv6 practices purely based on IPv4 > capabilities, experience and history? First of all, to the extent that this line of thought is being applied to me, I am really getting tired of the thinly-veiled insult. I know, use, deploy, and advocate for IPv6 myself; and have helped others do so as well. I speak from experience, not theory. More to the point however, in regards to the way most SMEs are looking at this, they _are_ mired in IPv4-think to some extent, because that's what they know, and what they are familiar with. It's up to us to listen to their concerns, try and discern their real needs, and figure out ways to meet them. Shouting, "You're doing it wrong!" at them isn't really going to help the situation. > Very few enterprises have deployed IPv6, so I don't think their > experience with just IPv4 should be used to limit the guidance and > advice on how to deploy IPv6. This is the trap of treating IPv6 as > nothing more than IPv4 with bigger addresses. ... which I know that the IPv6 cognescenti really hates. :) FWIW, *I* am not doing that, but what I *am* doing is listening, and sorting the wheat from the chaff. SMEs need a solution that gives them stable addressing for their inside network while allowing them to be provider independent. Out of all the possible solutions ULA + NPTv6 seems to be the safest and best in this space. Although like I said above, I'd like to see some real operational experience with a mix of ULA and GUA on the inside. I think for the overwhelming majority of SMEs their own PI space is a non-starter, so this is likely to be a situation where the least-unattractive option is the "best." hth, Doug From markzzzsmith@yahoo.com.au Fri Mar 8 18:56:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E336B21F86CD for ; Fri, 8 Mar 2013 18:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6] 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 dPqPoZLwA-3w for ; Fri, 8 Mar 2013 18:56:17 -0800 (PST) Received: from nm6.bullet.mail.bf1.yahoo.com (nm6.bullet.mail.bf1.yahoo.com [98.139.212.165]) by ietfa.amsl.com (Postfix) with SMTP id EBEBF21F86C8 for ; Fri, 8 Mar 2013 18:56:16 -0800 (PST) Received: from [98.139.212.151] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 09 Mar 2013 02:56:16 -0000 Received: from [98.139.212.223] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 09 Mar 2013 02:56:16 -0000 Received: from [127.0.0.1] by omp1032.mail.bf1.yahoo.com with NNFMP; 09 Mar 2013 02:56:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 386232.62325.bm@omp1032.mail.bf1.yahoo.com Received: (qmail 59727 invoked by uid 60001); 9 Mar 2013 02:56:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1362797776; bh=8UdE3q0Td1/DOF4AzEmxZ96YxnbKNKqn+NkSVCWO4E8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=TIxd3VNPo5AEQUIS43n7RfmnQtzP+uZ6bwnRCzRSUHmwNoY1vJhGZV8oHepPLo3hC4oIqr/gGjBvNjtPr8fGdLn0vU1xaLIB9gUzNxoJRTholnat8vIoxPdsIKngPaLrfF/LQJVVSuYQ7jZnqbhOzelgcbzHGsuxQcD9M+htzk8= 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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bG5REKrPu69jJzAvL/oxy8/fnH+Lj12RaM3nvkCBt8ZxiJkqFzZOPWONs4D1J3z9+NouPd0nCt2gVKbVthaNXEnCH7ojPSBXiznDmN1T0MFN4tifY1hP307be0pfzLKOGY2vXGV2dEvpWONx7mTQN+NhDL8l67S8teus6ualXhQ=; X-YMail-OSG: MCGcvYQVM1kO.K11j2Q12ds5TD5ZGS9WOR_FUgEYwKMCbkC kzTNdiomXZC5K66Gn1OMKWWIzrdIPf.EQuMUkwUhA5vY.R.65ouQAwUOm5Ua LX0qstwly_25VpMJ02vB0GCrPGArLHxEx7mRYm8JR.bwDVDFjYqsTfxmgLSi 6LMjQsjS8N0kRrge9phs9Yx4r0RlF4ODdk736hXx00VhhHy.toDhx6nzDbEf Wl9nf.PDJPKDN51CIMbJ2AAZugZvhMX7bER1JbChxLp3Cqry8wxGQHZPDtiA QXrojX7rA4oGAqrEu_yK.y2cB8FrZAtdVVLG.JuTNF8fiofSq6MwcU1Dq1Ss KomW5JnnkLwzx07TWhUOI7qEFVk4HLxHnsvwupnnbONZ6uQrJA.eXHClf_dW F0_6vy3UOnWSZmpnCGs0EfBInWViRe5Zyvo2Z5ROv03HrmkoFBDziLs55TlU tlvaAi5dabE4YIThqvUTFHwAdq3.9dckGcQSW4c59Jjdq9eSsP_KdOsqqpWy v0HcpdpEsJlL9B.Q61zl6disZF9kWqbCOL7jCaD4T1Qbc6hpfyv9Oc8wdA9n dduf5smcGBfhA2sRMP1ipEA36Z.aQYKCnRLe149eLmOtqi0wWY.I0DJ2Y3X3 x3TnN Received: from [150.101.221.237] by web142505.mail.bf1.yahoo.com via HTTP; Fri, 08 Mar 2013 18:56:16 PST X-Rocket-MIMEInfo: 001.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBEb3VnIEJhcnRvbiA8ZG91Z2JAZG91Z2JhcnRvbi51cz4KPiBUbzogInY2b3BzQGlldGYub3JnIFdHIiA8djZvcHNAaWV0Zi5vcmc.Cj4gQ2M6IAo.IFNlbnQ6IFNhdHVyZGF5LCA5IE1hcmNoIDIwMTMgMTI6NTEgUE0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBVTEEgZGlzY3Vzc2lvbiAjMSBVTEErTkFUCj4gCj4gSSd2ZSBjb3ZlcmVkIHRoaXMgZ3JvdW5kIGFscmVhZHksIHNvIGZvciB0aG9zZSB3aG8gcmVhZCBteSBwcmV2aW91cyBwb3MBMAEBAQE- X-Mailer: YahooMailWebService/0.8.135.514 References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <1362790998.58259.YahooMailNeo@web142504.mail.bf1.yahoo.com> <513A958B.7070104@do ugbarton.us> Message-ID: <1362797776.59544.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Fri, 8 Mar 2013 18:56:16 -0800 (PST) From: Mark Smith To: Doug Barton , "v6ops@ietf.org WG" In-Reply-To: <513A958B.7070104@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 02:56:19 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Doug Barton =0A> To: "v6ops@ietf.org WG" =0A> Cc: =0A> Sent: S= aturday, 9 March 2013 12:51 PM=0A> Subject: Re: [v6ops] ULA discussion #1 U= LA+NAT=0A> =0A> I've covered this ground already, so for those who read my = previous posts, =0A> sorry for the spam, feel free to hit delete now.=0A> = =0A> On 03/08/2013 05:03 PM, Mark Smith wrote:=0A>> ----- Original Message= -----=0A>>> From: Doug Barton To: "v6ops@ietf.org = =0A> WG"=0A>>> Cc: Sent: Thursday, 7 March 2013 8:50 AM = =0A> Subject:=0A>>> Re: [v6ops] ULA discussion #1 ULA+NAT=0A>>> =0A>>> On= 03/06/2013 01:24 PM, Ted Lemon wrote:=0A>>>> On Mar 6, 2013, at 4:02 PM, = Doug Barton >>> > wrot= e:=0A>>>>> Small - medium enterprises are pretty much the only place where= =0A>>>>> a NPTv6 + ULA solution makes sense.=0A>>>> =0A>>>> Why does it m= ake sense in this case?=0A>>> =0A>>> I've already covered this ad nauseum = in previous posts on this=0A>>> thread, feel free to review them for the d= etails.=0A>>> =0A>>> Short answer, "enterprises hate renumbering."=0A>> = =0A>> How much experience do they have renumbering IPv6=0A> =0A> Totally i= rrelevant question, as the real pain points in renumbering are not the =0A>= issues of getting new addresses on systems. Most end-user hosts, and a =0A= > non-trivial number of servers, are configured dynamically nowadays.=0A>= =A0=0A=0AI don't consider renumbering to just be a problem of getting new a= ddresses onto systems. Renumbering a network is achieved when every IP addr= ess in every location in the network, including ACLs, DNS, hosts files etc.= , as well as on hosts interfaces, has been changed.=0A=0A>> using the=0A= =0A>> preferred and valid lifetime mechanisms to phase in and phase out tw= o=0A>> (or more) GUA prefixes?=0A> =0A> I agree that on paper that sounds = like a good plan, but I'd like to see more =0A> information from competent = networking folks who have actually implemented it.=0A>=A0=0A=0AI haven't re= ad them, but I think the following reports describe experiences using IPv6'= s renumbering capabilities:=0A=0A"Cookbook for IPv6 Renumbering in SOHO=A0a= nd Backbone Networks."=0Ahttp://www.6net.org/publications/deliverables/D3.6= .1.pdf=0A=0A=0A"Cookbook for IPv6 Renumbering in ISP and=A0Enterprise Netwo= rks."=0Ahttp://www.6net.org/publications/deliverables/D3.6.2.pdf=0A=0A=A0= =0AOne of the authors (Tim Chown) is a common participant here, so he might= be able to provide further perspective if necessary.=0A=0A=0A> Meanwhile, = given the incredibly low average skill level of even large enterprise=A0=0A= =0A> network "engineers," and the low, or nonexistent level of such =0A> ex= pertise in the SME world, I have little to no confidence that this is a via= ble =0A> strategy. I would love to be proven wrong though.=0A> =0A>> Have = they taken advantage of having a stable=0A>> internal ULA address space so= that only their external connectivity=0A>> would be impacted by a GUA ren= umbering process?=0A> =0A> I think this idea has merit as well, but it hits= on the real pain points in =0A> renumbering: the meta issues surrounding f= irewalls, ACLs, bookmarks, hardware =0A> and software configuration, etc. N= o matter how much you tell people, "our =0A> policy is to use this inside n= etwork to access this set of resources" when =0A> that doesn't work, but th= e "outside" network does, people are =0A> going to go with what works. And = then those things get hard-coded somewhere, and =0A> then they have to be s= upported "forever." I've seen this on IPv4 =0A> only networks lots of times= , there is no reason to believe it would be any =0A> different with IPv6. P= eople who range from minimally competent to actively =0A> dangerous with IP= v4 now cannot be trusted to "do it right" with =0A> complex IPv6 configurat= ions.=0A>=A0=0A=0AThe specific goal of this ID is to provide advice on what= people should do. If they don't "RTFM" and treat IPv6 as IPv4 with bigger = addresses, then they'll create the same _avoidable_ problems for themselves= with IPv6 that they haven't been able to avoid with IPv4.=0A=0AIt seems a = bit silly to me to write advice documents for an audience who will ignore t= he advice anyway (which I think is the audience you're mostly describing). = The intended audience would be people who are willing to be open minded abo= ut how best to deploy IPv6 and who are looking for advice.=0A=0AIt seems to= be a common to say it is better to avoid giving good advice that is contra= ry to what close minded people will do. The thinking seems to be, the close= minded people won't do what is best and advised, so therefore what is "bes= t" should be lowered and redefined to what close minded people will be will= ing to do. That doesn't help them, because they think what they are doing i= s fine, and it doesn't help other people who are open minded, because they = don't become aware of better methods they may benefit from.=0A=0A=0A> Peopl= e in the IETF tend to poo-poo these kinds of things when I talk about them,= =0A> insisting that no one could really be that stupid/careless. As I've p= ointed =0A> out in the past, people around here are way above average, so y= eah, these kinds =0A> of problems would seem ridiculous to them. OTOH, I wo= rk with the "below =0A> average" crowd day in and day out, and I could tell= you stories ...=0A>=A0=0A=0AI too know people who work in enterprises, and= have myself. I believe IPv6 should be at least as easy to use and deploy a= s IPX and Appletalk were in the 1990s (20 years ago!). IPv4 was harder to l= earn and deploy than those, so advice and descriptions of IPv4's practices = shouldn't be propagated into IPv6. Documents giving advice on IPv6 deployme= nt should leverage where possible all of IPv6's capabilities that IPv4 does= n't have. The bar for IPv6 usability should set at or should be higher than= the usability of IPX and Appletalk, not equal to IPv4s.=0A=0A>> Or are yo= u making=0A>> these assertions about IPv6 practices purely based on IPv4= =0A>> capabilities, experience and history?=0A> =0A> First of all, to the = extent that this line of thought is being applied to me, I =0A> am really g= etting tired of the thinly-veiled insult.=0A=0AI'm not intending to insult.= Sorry if that is how it was taken. What I am doing is questioning whether = IPv6 practices should be constrained by and to what have been common IPv4 p= ractices.=A0=0A=0A> I know, use, deploy, and =0A> advocate for IPv6 myself;= and have helped others do so as well. I speak from =0A> experience, not th= eory.=0A>=A0=0A=0AExactly. So I don't think you have answered my questions.= So what is your and/or your enterprise customers _experience_ with renumbe= ring IPv6 using the IPv6 mechanisms available?=0A=0AI don't think the evide= nce that enterprises don't like renumbering IPv4 networks is also evidence = that they won't like renumbering IPv6 networks, when they have no experienc= e doing it.=0A=0A=0A=0ARegards,=0AMark. From brian.e.carpenter@gmail.com Sat Mar 9 00:25:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAC021F85AC for ; Sat, 9 Mar 2013 00:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.302 X-Spam-Level: X-Spam-Status: No, score=-99.302 tagged_above=-999 required=5 tests=[AWL=-0.981, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, J_CHICKENPOX_33=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 XDt1xXMGOM3t for ; Sat, 9 Mar 2013 00:25:27 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id D398F21F859B for ; Sat, 9 Mar 2013 00:25:26 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id p43so1906631wea.10 for ; Sat, 09 Mar 2013 00:25:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=73rn8iRQPx06IbOYe84u0H0RGvoMZXk6NlYxxOzD+sc=; b=ZDzGzJOkv8AlrI7cWjFml9nYg+xxMtYRE54aTXAK/SEFB9hhgDAeOcZYbmxrl3fIfn 94+jtMn654ANrtTdLVmKPnESnFigp0qIZVy/xayZn5dSn6BAw3m6vXnn+LFKAIzqWsio GlBdQ9plpa4RJfp7T1vT/TqLzvd9x/ztkf823+kWGYFVn2KCAnPxrsJXN7YB6lTQqSwg tVTCptCImxlopTigB0R2f6exHYSNrJmE+fnxGAjq3EZE1L3SvHmXiabK3jbVrIKCTOBn +qclnvu5NHzv1t1LWHqWX5h7vJsq+NyR/CZvcYwlgipZPhzAFhFXMUu0GCSkop0ZWEvA JP2A== X-Received: by 10.180.108.3 with SMTP id hg3mr2524119wib.33.1362817525819; Sat, 09 Mar 2013 00:25:25 -0800 (PST) Received: from [192.168.1.65] (host-2-101-188-193.as13285.net. [2.101.188.193]) by mx.google.com with ESMTPS id c15sm3050692wiw.3.2013.03.09.00.25.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Mar 2013 00:25:24 -0800 (PST) Message-ID: <513AF203.4070605@gmail.com> Date: Sat, 09 Mar 2013 08:25:39 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Smith References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <1362790998.58259.YahooMailNeo@web142504.mail.bf1.yahoo.com> <513A958B.7070104@do ugbarton.us> <1362797776.59544.YahooMailNeo@web142505.mail.bf1.yahoo.com> In-Reply-To: <1362797776.59544.YahooMailNeo@web142505.mail.bf1.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 08:25:27 -0000 > I haven't read them, but I think the following reports describe experiences using IPv6's renumbering capabilities: > > "Cookbook for IPv6 Renumbering in SOHO and Backbone Networks." > http://www.6net.org/publications/deliverables/D3.6.1.pdf > > > "Cookbook for IPv6 Renumbering in ISP and Enterprise Networks." > http://www.6net.org/publications/deliverables/D3.6.2.pdf > > > One of the authors (Tim Chown) is a common participant here, so he might be able to provide further perspective if necessary. Erm, he's been giving that perspective quite regularly as co-chair of 6renum, whose output can be found at http://datatracker.ietf.org/wg/6renum/ Brian From owen@delong.com Sat Mar 9 03:45:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E64221F8555 for ; Sat, 9 Mar 2013 03:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_00=-2.599, GB_ABOUTYOU=0.5, J_CHICKENPOX_33=0.6] 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 462hWU8nGmgk for ; Sat, 9 Mar 2013 03:45:54 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D261A21F84A2 for ; Sat, 9 Mar 2013 03:45:54 -0800 (PST) Received: from delong-dhcp227.delong.com (delong-dhcp27 [192.159.10.227]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r29BfL7M018846 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 9 Mar 2013 03:41:21 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r29BfL7M018846 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362829281; bh=ktTXdwsUoPDF3KmdGSjKO+swGCo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ATQBXqCG/RqimcCOE7AboH4FbuWstnC+UivolFXRTvFN2yXAO/hVpSRp1XhCVlsKt xc6TlN4QrDQLUn7Bq7dpJ/7hEuJRwmTQ66B70lJU0t6ciqM/Kz4kxh19vaxTU6C+bb SHd//auSA3ewP/FYpA0Mdh9GQEqeYoC/gnnmBWYo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <513A958B.7070104@dougbarton.us> Date: Sat, 9 Mar 2013 03:41:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <93C8132C-F72E-4BF0-98DD-2D715240445C@delong.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <1362790998.58259.YahooMailNeo@web142504.mail.bf1.yahoo.com> <513A958B.7070104@d! ougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Sat, 09 Mar 2013 03:41:21 -0800 (PST) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 11:45:56 -0000 On Mar 8, 2013, at 17:51 , Doug Barton wrote: > I've covered this ground already, so for those who read my previous = posts, sorry for the spam, feel free to hit delete now. >=20 > On 03/08/2013 05:03 PM, Mark Smith wrote: >> ----- Original Message ----- >>> From: Doug Barton To: "v6ops@ietf.org WG" >>> Cc: Sent: Thursday, 7 March 2013 8:50 AM Subject: >>> Re: [v6ops] ULA discussion #1 ULA+NAT >>>=20 >>> On 03/06/2013 01:24 PM, Ted Lemon wrote: >>>> On Mar 6, 2013, at 4:02 PM, Doug Barton >>> > wrote: >>>>> Small - medium enterprises are pretty much the only place where >>>>> a NPTv6 + ULA solution makes sense. >>>>=20 >>>> Why does it make sense in this case? >>>=20 >>> I've already covered this ad nauseum in previous posts on this >>> thread, feel free to review them for the details. >>>=20 >>> Short answer, "enterprises hate renumbering." >>=20 >> How much experience do they have renumbering IPv6 >=20 > Totally irrelevant question, as the real pain points in renumbering = are not the issues of getting new addresses on systems. Most end-user = hosts, and a non-trivial number of servers, are configured dynamically = nowadays. >=20 As I see it, the real pain points are: 1. Things about your address configuration that require = customer coordination. 2. Your addresses in configuration files you don't control. = (Remote VPN boxes, etc.) 3. Firewall rulesets, etc. Of these, in the SME world, 1 is virtually non-existent. 2 is rare and = when it does exist, we're usually talking about 1 or two instances in the average SME. Hardly a = show-stoper. As to 3, this is much simpler in IPv6 because you can literally = duplicate the rules and do a global search and replace on them to produce the rules for the new = addresses. In IPv4, that was rarely so simple because you would have 192.0.2.64/26 from one = provider whereas the next provider would give you 209.67.126.192/26. Remember, in IPv6, you're just replacing the first 12 hex digits. = Everything else can stay the same. >> using the >> preferred and valid lifetime mechanisms to phase in and phase out two >> (or more) GUA prefixes? >=20 > I agree that on paper that sounds like a good plan, but I'd like to = see more information from competent networking folks who have actually = implemented it. >=20 What would you like to see? I've already told you that I've done it = multiple times. As I stated, if you plan for it in the network = deployment, it's pretty easy. If you don't, then it's hard once. > Meanwhile, given the incredibly low average skill level of even large = enterprise network "engineers," and the low, or nonexistent level of = such expertise in the SME world, I have little to no confidence that = this is a viable strategy. I would love to be proven wrong though. It really isn't that hard. The truly hardest part is getting someone = involved in the planning stage that understands the concepts well enough = to plan properly. (Or have someone come fix it during the first iteration). Beyond that, it really boils down to this: 1. Turn on the new addresses and test them. 2. Stop advertising the old addresses in the RAs. (If you want to = accelerate the process, you can immediately set the desired lifetime to 0 and wait a little = while before pulling out the RAs.) 3. Turn off the old addresses in DHCP (if applicable) 4. Wait for the valid lifetimer to expire. 5. Deprecate the old addresses from your routers. >=20 >> Have they taken advantage of having a stable >> internal ULA address space so that only their external connectivity >> would be impacted by a GUA renumbering process? >=20 > I think this idea has merit as well, but it hits on the real pain = points in renumbering: the meta issues surrounding firewalls, ACLs, = bookmarks, hardware and software configuration, etc. No matter how much = you tell people, "our policy is to use this inside network to access = this set of resources" when that doesn't work, but the "outside" network = does, people are going to go with what works. And then those things get = hard-coded somewhere, and then they have to be supported "forever." I've = seen this on IPv4 only networks lots of times, there is no reason to = believe it would be any different with IPv6. People who range from = minimally competent to actively dangerous with IPv4 now cannot be = trusted to "do it right" with complex IPv6 configurations. Not sure what you mean by bookmarks. Bookmarks in web browsers should be = using names, not numbers. Why would the inside network not work at a time when the outside does? = Makes no sense in IPv6. > People in the IETF tend to poo-poo these kinds of things when I talk = about them, insisting that no one could really be that stupid/careless. = As I've pointed out in the past, people around here are way above = average, so yeah, these kinds of problems would seem ridiculous to them. = OTOH, I work with the "below average" crowd day in and day out, and I = could tell you stories ... Yes, I'm familiar with this crowd. Bottom line, no matter what we do, = that crowd is going to suffer. You just can't sell guns to people who = are willing to shoot themselves in the foot and expect them to somehow = come out of the process without any pain. Frankly, ULA+NPT/NAT will = _NOT_ reduce their pain in these instances. It will reduce their level = of reactionary discomfort with learning something new, but it will not = reduce their opportunities to make all of the mistakes you are expecting = to cause problems with the other solutions and they will hurt just as = bad. >> Or are you making >> these assertions about IPv6 practices purely based on IPv4 >> capabilities, experience and history? >=20 > First of all, to the extent that this line of thought is being applied = to me, I am really getting tired of the thinly-veiled insult. I know, = use, deploy, and advocate for IPv6 myself; and have helped others do so = as well. I speak from experience, not theory. It's just that so much of what you say seems to reflect a real ignorance = of the many of the tools available in IPv6. Experience does not always = equate to a complete understanding of the toolset available. I have lots = of IPv6 experience too. I'm still learning new things about it pretty = regularly. > More to the point however, in regards to the way most SMEs are looking = at this, they _are_ mired in IPv4-think to some extent, because that's = what they know, and what they are familiar with. It's up to us to listen = to their concerns, try and discern their real needs, and figure out ways = to meet them. Shouting, "You're doing it wrong!" at them isn't really = going to help the situation. Right... But the solution to that is education. What you call shouting = is actually an attempt to share knowledge and provide better = alternatives that lead to less pain. If you have a better path to proper = education, I'm all ears. If you just want to keep shouting "We want to = do it the way we have been doing it and we won't accept any other = answer" on their behalf, then that isn't going to help the situation = either. >> Very few enterprises have deployed IPv6, so I don't think their >> experience with just IPv4 should be used to limit the guidance and >> advice on how to deploy IPv6. This is the trap of treating IPv6 as >> nothing more than IPv4 with bigger addresses. >=20 > ... which I know that the IPv6 cognescenti really hates. :) FWIW, *I* = am not doing that, but what I *am* doing is listening, and sorting the = wheat from the chaff. SMEs need a solution that gives them stable = addressing for their inside network while allowing them to be provider = independent. Out of all the possible solutions ULA + NPTv6 seems to be = the safest and best in this space. Although like I said above, I'd like = to see some real operational experience with a mix of ULA and GUA on the = inside. I think for the overwhelming majority of SMEs their own PI space = is a non-starter, so this is likely to be a situation where the = least-unattractive option is the "best." GUA is a fine solution in that space. I know you don't like it for = whatever reason, but it really is a vastly superior solution to NPT. ULA+PA is a better solution than ULA+NPT. NPTv6 is experimental at best = and not very likely to be widely supported by ISVs. As such, I can = hardly consider it even remotely "safe" for enterprise deployment at = this point. If you have GUA on the inside, what do you need ULA for? You keep saying that their own PI space is a non-starter, but you = haven't done anything to back that up with any rational reason. Owen From brian.e.carpenter@gmail.com Sat Mar 9 05:46:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BDF21F8610 for ; Sat, 9 Mar 2013 05:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.164 X-Spam-Level: X-Spam-Status: No, score=-99.164 tagged_above=-999 required=5 tests=[AWL=-0.843, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, J_CHICKENPOX_33=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 oC9oK1WSDIMu for ; Sat, 9 Mar 2013 05:46:56 -0800 (PST) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id D5E9921F8606 for ; Sat, 9 Mar 2013 05:46:55 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id k14so1999425wer.25 for ; Sat, 09 Mar 2013 05:46:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lamtI98QZycmfyBKh5Z8GqkYtYbf4QUjfUmZIQzvc8k=; b=Cwoa6Ee6gfJ41crMgdm+RN+pnHL/MVmEPq6USbR80WKOe8C7hckiFlj2iv3QsYY2XG 5n30A1QJB+bry4VpmekFGtlcmKqWyKlUsEq9nTAft0gqUVXwH4wipu6QjkQM6iZuUaOs j8ycoX0ajYeTbSmweZAr0hRchERZJ9+EkRSedwTjKdCfoirRohaRUwKBu/8hM1HzZuKG hTFKm+TFb2KJjBv+vIGJXFW40s0y6jUhMdiV1NdfC5IaPHRgLS2GFWg6OGbVlLqXo+G8 AbW+qO6Qg77/P15pRv1FfGMeYw8N5M1MjOSeTvc2rjDgJNpJ8++TIAkf4RooSDKZmCjq DuXA== X-Received: by 10.194.170.165 with SMTP id an5mr9971197wjc.41.1362836814989; Sat, 09 Mar 2013 05:46:54 -0800 (PST) Received: from [192.168.1.65] (host-2-101-188-193.as13285.net. [2.101.188.193]) by mx.google.com with ESMTPS id q2sm4706073wiz.8.2013.03.09.05.46.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Mar 2013 05:46:53 -0800 (PST) Message-ID: <513B3D5C.3060707@gmail.com> Date: Sat, 09 Mar 2013 13:47:08 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Owen DeLong References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <1362790998.58259.YahooMailNeo@web142504.mail.bf1.yahoo.com> <513A958B.7070104@d! ougbarton.us> <93C8132C-F72E-4BF0-98DD-2D715240445C@delong.com> In-Reply-To: <93C8132C-F72E-4BF0-98DD-2D715240445C@delong.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 13:46:56 -0000 On 09/03/2013 11:41, Owen DeLong wrote: ... > Remember, in IPv6, you're just replacing the first 12 hex digits. Everything else can stay > the same. Huh? That only applies if you have exactly one /48 prefix replaced by another. The general case is significantly more complex. Again, see the 6renum documents, although they are only scoped for enterprise networks. Brian From owen@delong.com Sat Mar 9 06:11:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E12021F8640 for ; Sat, 9 Mar 2013 06:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 XoSFnlj0I6Ga for ; Sat, 9 Mar 2013 06:11:26 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3B821F863F for ; Sat, 9 Mar 2013 06:11:25 -0800 (PST) Received: from delong-dhcp227.delong.com (delong-dhcp27 [192.159.10.227]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r29EA2H1022416 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 9 Mar 2013 06:10:02 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r29EA2H1022416 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362838202; bh=Ay78zDCy50Xcra/fBW+XLddtp6E=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Yi/g6FQAZo1so+gqkQBRrGuWRWeTTFteHAe1jSoSPQIVc/RGHnIsbr08kGNTKskgU q5dMSHMhHcz3uBeOKMaSRfD6zXhg7K+Wu2ilsx+6j8tO7485IPaz3/5GVljYuJVlD+ mtwT8G7t500h1V8OikJDJnxNeZvdvaCiJPVojihs= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <513B3D5C.3060707@gmail.com> Date: Sat, 9 Mar 2013 06:09:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6D4AB912-3884-46EA-BC12-D800FA6FBAC8@delong.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <1362790998.58259.YahooMailNeo@web142504.mail.bf1.yahoo.com> <513A958B.7070104@d! ougbarton.us> <93C8132C-F72E-4BF0-98DD-2D715240445C@delong.com> <513B3D5C.3060707@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Sat, 09 Mar 2013 06:10:02 -0800 (PST) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 14:11:27 -0000 On Mar 9, 2013, at 05:47 , Brian E Carpenter = wrote: > On 09/03/2013 11:41, Owen DeLong wrote: > ... >> Remember, in IPv6, you're just replacing the first 12 hex digits. = Everything else can stay >> the same. >=20 > Huh? That only applies if you have exactly one /48 prefix replaced > by another. The general case is significantly more complex. >=20 We're talking about renumbering the SMB to change ISPs. How would the general case for that NOT be replacing the /48 from the = previous provider with a /48 from a new provider? Owen From Ted.Lemon@nominum.com Sat Mar 9 06:14:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560F721F8600 for ; Sat, 9 Mar 2013 06:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.194 X-Spam-Level: X-Spam-Status: No, score=-106.194 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbbDdWHmHwJK for ; Sat, 9 Mar 2013 06:14:36 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id B609621F85E0 for ; Sat, 9 Mar 2013 06:14:36 -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 DSNKUTtDzGp/3U6tTbS6bLoC0PmByWb9eH9D@postini.com; Sat, 09 Mar 2013 06:14: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 6E67E1B80B9 for ; Sat, 9 Mar 2013 06:14:36 -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 62C82190043; Sat, 9 Mar 2013 06:14:36 -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; Sat, 9 Mar 2013 06:14:36 -0800 From: Ted Lemon To: Owen DeLong Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT Thread-Index: Ac4Y0qVmXOczhdgyTHaW1OIbGrg4zQAVbZqAABAGvAAAAlzXgAAIFLoAAAKCZIAABfkCAAAA0RCAAACcd4AAAOJ/gAAAJRsAAABlxoAAALV/gAACHAWAACcL2QAAHe3hAAAD7pKAAABPR4AAAE+4AAAAwBSAAADwWwAAa01lAAABq4SAABScgIAABGUwAAAAy40AAAApuQA= Date: Sat, 9 Mar 2013 14:14:35 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474B8DD6@mbx-01.win.nominum.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <51359B64.7090006@dougbarton.us> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <1362790998.58259.YahooMailNeo@web142504.mail.bf1.yahoo.com> <513A958B.7070104@d! ougbarton.us> <93C8132C-F72E-4BF0-98DD-2D715240445C@delong.com> <513B3D5C.3060707@gmail.com> <6D4AB912-3884-46EA-BC12-D800FA6FBAC8@delong.com> In-Reply-To: <6D4AB912-3884-46EA-BC12-D800FA6FBAC8@delong.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: <9FBD939784DF26448A603B0C878140D7@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 14:14:37 -0000 On Mar 9, 2013, at 9:09 AM, Owen DeLong wrote: > How would the general case for that NOT be replacing the /48 from the pre= vious > provider with a /48 from a new provider? The only case where there might be trouble is where the provider only offer= s a /56, but the previous provider offered a /48, and the SME expanded into= the high bits of the /48 but doesn't actually need that many bits. But i= n any case where NPT would work, the renumbering that we are talking about = would be a simple prefix replacement, so that concern doesn't contradict th= e original argument. From brian.e.carpenter@gmail.com Sat Mar 9 08:23:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4521021F862B for ; Sat, 9 Mar 2013 08:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.321 X-Spam-Level: X-Spam-Status: No, score=-98.321 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, J_CHICKENPOX_33=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 njMupm1TYZaZ for ; Sat, 9 Mar 2013 08:23:20 -0800 (PST) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D591821F8618 for ; Sat, 9 Mar 2013 08:23:19 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id r6so2146791wey.5 for ; Sat, 09 Mar 2013 08:23:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=MSqg4tqP3BzHTvLM+lo27iPX6ZhWy9EJsjktJXBD9cY=; b=ISUzqvbDDgzjaeK2orYhXFj1eWQh1uCHODf1gmJeX4eJUOgsh6mPNtPy4PVyqQzEsR uUH6Cvsta7qFS1JqRgf4mE5loGHPPIO+unwkfMw+Z+4Gfvbtbbg082UOJL1ME0qT/J47 j9N+6jyX0/WzujjPNJgBW2xIRxUmAfDlvbo9aZ2S+Z/4LrkVq51roNu02Cj5RT7PdIez NV0CHD43LgYDENi8Ud1yWvbJcr0KkYPqMulkprHK/EIX2H11P9lSd7Rw34zQ3mDHDIj3 NGxIiivX54A89olcT6C7+cXA1QcitWkQtvUNu9aBrJoCAhW0+AnQg/9xR8iZn2BZt6th +Dow== X-Received: by 10.194.133.98 with SMTP id pb2mr10546061wjb.20.1362846199062; Sat, 09 Mar 2013 08:23:19 -0800 (PST) Received: from [192.168.1.65] (host-2-102-216-78.as13285.net. [2.102.216.78]) by mx.google.com with ESMTPS id bs6sm5577214wib.4.2013.03.09.08.23.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Mar 2013 08:23:18 -0800 (PST) Message-ID: <513B6205.7080802@gmail.com> Date: Sat, 09 Mar 2013 16:23:33 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <1362790998.58259.YahooMailNeo@web142504.mail.bf1.yahoo.com> <513A958B.7070104@d! ougbarton.us> <93C8132C-F72E-4BF0-98DD-2D715240445C@delong.com> <513B3D5C.3060707@gmail.com> <6D4AB912-3884-46EA-BC12-D800FA6FBAC8@delong.com> <8D23D4052ABE7A4490E77B1A012B6307474B8DD6@mbx-01.win.nominum.c om> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474B8DD6@mbx-01.win.nominum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 16:23:21 -0000 On 09/03/2013 14:14, Ted Lemon wrote: > On Mar 9, 2013, at 9:09 AM, Owen DeLong wrote: >> How would the general case for that NOT be replacing the /48 from the previous >> provider with a /48 from a new provider? > > The only case where there might be trouble is where the provider only offers a /56, but the previous provider offered a /48, and the SME expanded into the high bits of the /48 but doesn't actually need that many bits. But in any case where NPT would work, the renumbering that we are talking about would be a simple prefix replacement, so that concern doesn't contradict the original argument. NPTv6 can deal with various lengths of prefix, so I don't quite see that last point. The benefits of a standard prefix length would (IMNSHO) have been considerable, but that ship has sailed. Brian From Ted.Lemon@nominum.com Sat Mar 9 08:52:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6AC21F86B1 for ; Sat, 9 Mar 2013 08:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.232 X-Spam-Level: X-Spam-Status: No, score=-106.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8lnTUs0eN8k for ; Sat, 9 Mar 2013 08:52:25 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9237521F869E for ; Sat, 9 Mar 2013 08:52:25 -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 DSNKUTtow3T+xmQ91GqfNuXC4TjVS21QygZg@postini.com; Sat, 09 Mar 2013 08:52:25 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 C246D1080DC for ; Sat, 9 Mar 2013 08:52: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 BC168190043; Sat, 9 Mar 2013 08:52: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; Sat, 9 Mar 2013 08:52:19 -0800 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT Thread-Index: Ac4Y0qVmXOczhdgyTHaW1OIbGrg4zQAVbZqAABAGvAAAAlzXgAAIFLoAAAKCZIAABfkCAAAA0RCAAACcd4AAAOJ/gAAAJRsAAABlxoAAALV/gAACHAWAACcL2QAAHe3hAAAD7pKAAABPR4AAAE+4AAAAwBSAAADwWwAAa01lAAABq4SAABScgIAABGUwAAAAy40AAAApuQAABIEzgAABAOaA Date: Sat, 9 Mar 2013 16:52:18 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474B8FAC@mbx-01.win.nominum.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <1362790998.58259.YahooMailNeo@web142504.mail.bf1.yahoo.com> <513A958B.7070104@d! ougbarton.us> <93C8132C-F72E-4BF0-98DD-2D715240445C@delong.com> <513B3D5C.3060707@gmail.com> <6D4AB912-3884-46EA-BC12-D800FA6FBAC8@delong.com> <8D23D4052ABE7A4490E77B1A012B6307474B8DD6@mbx-01.win.nominum.c om> <513B6205.7080802@gmail.com> In-Reply-To: <513B6205.7080802@gmail.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: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 16:52:27 -0000 On Mar 9, 2013, at 11:23 AM, Brian E Carpenter wrote: > NPTv6 can deal with various lengths of prefix, so I don't quite > see that last point. The benefits of a standard prefix length > would (IMNSHO) have been considerable, but that ship has sailed. I suppose so, but the config file would be a lot more complicated, and the = assertion that's been made here is that NPT is _easier_, not just that it's= _possible_. From dougb@dougbarton.us Sat Mar 9 11:44:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3821321F8702 for ; Sat, 9 Mar 2013 11:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 AgylC5xChnrR for ; Sat, 9 Mar 2013 11:44:52 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id DDE7721F8700 for ; Sat, 9 Mar 2013 11:44:52 -0800 (PST) Received: from [192.168.0.102] (home [12.207.105.210]) by dougbarton.us (Postfix) with ESMTPSA id 1FE6A22B0F for ; Sat, 9 Mar 2013 19:44:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362858290; bh=GF0ds52tnIQCnOSuHP2u6D6grB0BCCV9pMmf7FAehjg=; h=Date:From:To:Subject:References:In-Reply-To; b=e88crP33afQlJT1YsTuQbq3ZiwI3m7xMLFlORJVz23OR38uOUQZxg88WAc9rID2xb KcH+NoXi2yOlO1zdiIYcJiKSQznNyJwwcH+dnerb6BJImzMxAqCEgzRpsaV4OgYzUR SS19GWP0iWBqSMXHS7DuycUO7ajnqdOXl3nv5jys= Message-ID: <513B9131.70807@dougbarton.us> Date: Sat, 09 Mar 2013 11:44:49 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <1362790998.58259.YahooMailNeo@web142504.mail.bf1.yahoo.com> <513A958B.7070104@d! ougbarton.us> <93C8132C-F72E-4BF0-98DD-2D715240445C@delong.com> <513B3D5C.3060707@gmail.com> <6D4AB912-3884-46EA-BC12-D800FA6FBAC8@delong.com> <8D23D4052ABE7A4490E77B1A012B6307474B8DD6@mbx-01.win.nominum.c om> <513B6205.7080802@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307474B8FAC@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474B8FAC@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 19:44:54 -0000 On 03/09/2013 08:52 AM, Ted Lemon wrote: > On Mar 9, 2013, at 11:23 AM, Brian E Carpenter wrote: >> NPTv6 can deal with various lengths of prefix, so I don't quite >> see that last point. The benefits of a standard prefix length >> would (IMNSHO) have been considerable, but that ship has sailed. > > I suppose so, but the config file would be a lot more complicated, and the assertion that's been made here is that NPT is _easier_, not just that it's _possible_. The assertion I made is that ULA + NPT meets the needs of most SMEs better than the other options. I agree that if an organization fully utilized a /48 and then were only offered a larger prefix from a new ISP it would make things more difficult for them to transition to that ISP. However, the same would be true if they were using the PA space directly. This issue would be a good thing to put in the list of "cons" for both the NPT and direct PA solutions. Doug From Ted.Lemon@nominum.com Sat Mar 9 12:28:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7CB21F8749 for ; Sat, 9 Mar 2013 12:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.228 X-Spam-Level: X-Spam-Status: No, score=-106.228 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWYQRQv99jsf for ; Sat, 9 Mar 2013 12:28:09 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id EB28521F848B for ; Sat, 9 Mar 2013 12:28:08 -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 DSNKUTubWPmbbUpLM0eFf/pyNxkdsyMMtlJE@postini.com; Sat, 09 Mar 2013 12:28:08 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 8E8781B8490 for ; Sat, 9 Mar 2013 12:28:08 -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 7E9CF190043; Sat, 9 Mar 2013 12:28:08 -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; Sat, 9 Mar 2013 12:28:02 -0800 From: Ted Lemon To: Doug Barton Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT Thread-Index: Ac4Y0qVmXOczhdgyTHaW1OIbGrg4zQAVbZqAABAGvAAAAlzXgAAIFLoAAAKCZIAABfkCAAAA0RCAAACcd4AAAOJ/gAAAJRsAAABlxoAAALV/gAACHAWAACcL2QAAHe3hAAAD7pKAAABPR4AAAE+4AAAAwBSAAADwWwAAa01lAAABq4SAABScgIAABGUwAAAAy40AAAApuQAABIEzgAABAOaAAAYGkYAAAYI9gA== Date: Sat, 9 Mar 2013 20:28:02 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474B926E@mbx-01.win.nominum.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <1362790998.58259.YahooMailNeo@web142504.mail.bf1.yahoo.com> <513A958B.7070104@d! ougbarton.us> <93C8132C-F72E-4BF0-98DD-2D715240445C@delong.com> <513B3D5C.3060707@gmail.com> <6D4AB912-3884-46EA-BC12-D800FA6FBAC8@delong.com> <8D23D4052ABE7A4490E77B1A012B6307474B8DD6@mbx-01.win.nominum.c om> <513B6205.7080802@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307474B8FAC@mbx-01.win.nominum.com> <513B9131.70807@dougbarton.us> In-Reply-To: <513B9131.70807@dougbarton.us> 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: <03EC16DD0EECC541B2260DCADC2235CD@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 20:28:09 -0000 On Mar 9, 2013, at 2:44 PM, Doug Barton wrote: > The assertion I made is that ULA + NPT meets the needs of most SMEs bette= r than the other options. I agree that if an organization fully utilized a = /48 and then were only offered a larger prefix from a new ISP it would make= things more difficult for them to transition to that ISP. However, the sam= e would be true if they were using the PA space directly. Yes, but additionally, if the organization uses the /48 sparsely, even if t= hey can _fit_ into a /56, they are still going to have to do a lot of work = to make that happen, whether it's renumbering or a really hairy NPT table. = There's probably some advice worth giving about not doing this, however t= his discussion ultimately ends... From john_brzozowski@cable.comcast.com Sat Mar 9 17:16:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4314921F8771 for ; Sat, 9 Mar 2013 17:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.662 X-Spam-Level: X-Spam-Status: No, score=-101.662 tagged_above=-999 required=5 tests=[AWL=-0.765, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, 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 EHV8UbDE+83T for ; Sat, 9 Mar 2013 17:16:53 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 5531A21F8767 for ; Sat, 9 Mar 2013 17:16:53 -0800 (PST) Received: from ([24.40.56.116]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.45899588; Sat, 09 Mar 2013 20:03:50 -0500 Received: from PACDCEXHUB04.cable.comcast.com (24.40.56.121) by pacdcexhub03.cable.comcast.com (24.40.56.116) with Microsoft SMTP Server (TLS) id 14.2.318.1; Sat, 9 Mar 2013 20:16:50 -0500 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by pacdcexhub04.cable.comcast.com ([fe80::1532:d330:f9a5:c8a1%18]) with mapi id 14.02.0318.001; Sat, 9 Mar 2013 20:16:50 -0500 From: "Brzozowski, John" To: v6ops Thread-Topic: Jabber volunteer request Thread-Index: AQHOHSzwrM+btf3s/E6wCIBsUU4x7A== Date: Sun, 10 Mar 2013 01:16:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.70] Content-Type: text/plain; charset="us-ascii" Content-ID: <507ECBEA8720724EB23A5CE9F911C4A7@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops chairs Subject: [v6ops] Jabber volunteer request X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 01:16:54 -0000 We need volunteers to for jabber for both sessions, anyone interested should email Fred and I at the email address copied above. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozowski@cable.comcast.com o) 609-377-6594 w) www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From john_brzozowski@cable.comcast.com Sat Mar 9 19:37:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96EB21F874B for ; Sat, 9 Mar 2013 19:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.552 X-Spam-Level: X-Spam-Status: No, score=-101.552 tagged_above=-999 required=5 tests=[AWL=-0.655, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, 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 SyBISUyaT0rt for ; Sat, 9 Mar 2013 19:37:55 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id E7E8621F874A for ; Sat, 9 Mar 2013 19:37:54 -0800 (PST) Received: from ([24.40.56.115]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.45902931; Sat, 09 Mar 2013 22:24:51 -0500 Received: from PACDCEXHUB05.cable.comcast.com (24.40.56.122) by PACDCEXHUB02.cable.comcast.com (24.40.56.115) with Microsoft SMTP Server (TLS) id 14.2.318.1; Sat, 9 Mar 2013 22:37:52 -0500 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by pacdcexhub05.cable.comcast.com ([fe80::3d40:bdea:7266:7f5a%18]) with mapi id 14.02.0318.001; Sat, 9 Mar 2013 22:37:52 -0500 From: "Brzozowski, John" To: v6ops Thread-Topic: Meeting minute volunteer request Thread-Index: AQHOHUCkqrqyXhB0bEO2XJLh8YBrDg== Date: Sun, 10 Mar 2013 03:37:51 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.70] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops chairs Subject: [v6ops] Meeting minute volunteer request X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 03:37:56 -0000 We need volunteers to take meeting minutes for both sessions, anyone interested should email Fred and I at the email address copied above. Thanks, John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozowski@cable.comcast.com o) 609-377-6594 w) www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From owen@delong.com Sat Mar 9 23:50:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F79921F87B1 for ; Sat, 9 Mar 2013 23:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 nJJIaaGlamKY for ; Sat, 9 Mar 2013 23:50:57 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7504B21F871C for ; Sat, 9 Mar 2013 23:50:56 -0800 (PST) Received: from delong-dhcp227.delong.com (delong-dhcp27 [192.159.10.227]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2A7nLid008986 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 9 Mar 2013 23:50:19 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2A7nLid008986 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362901819; bh=Aam6OO518O9okKMIEb3ET/kLCtU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=u84RbEgQ/n2rNSsIJqaqTiEDhDROgmi8IhaHd6vRIB+Eo6/zwIrIUhKTWmtqcEYoM n8RIkKhGXux+aQF5FfBI6QSYPUtSBbYceELJL+bAbSNE37utmpzrn1rA0TqU9hGU90 0PgYtpuO+G946P0TJ8fzamekojADSKiaxdjqMVfw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <513B6205.7080802@gmail.com> Date: Sat, 9 Mar 2013 23:50:10 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8224B427-EBE2-437B-9850-5C17BD32F22C@delong.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <1362790998.58259.YahooMailNeo@web142504.mail.bf1.yahoo.com> <513A958B.7070104@d! ougbarton.us> <93C8132C-F72E-4BF0-98DD-2D715240445C@delong.com> <513B3D5C.3060707@gmail.com> <6D4AB912-3884-46EA-BC12-D800FA6FBAC8@delong.com> <8D23D4052ABE7A4490E77B1A012B6307474B8DD6@mbx-01.win.nominum.! com> <513B6205.7080802@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Sat, 09 Mar 2013 23:50:19 -0800 (PST) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 07:50:58 -0000 On Mar 9, 2013, at 08:23 , Brian E Carpenter = wrote: > On 09/03/2013 14:14, Ted Lemon wrote: >> On Mar 9, 2013, at 9:09 AM, Owen DeLong wrote: >>> How would the general case for that NOT be replacing the /48 from = the previous >>> provider with a /48 from a new provider? >>=20 >> The only case where there might be trouble is where the provider only = offers a /56, but the previous provider offered a /48, and the SME = expanded into the high bits of the /48 but doesn't actually need that = many bits. But in any case where NPT would work, the renumbering that = we are talking about would be a simple prefix replacement, so that = concern doesn't contradict the original argument. >=20 > NPTv6 can deal with various lengths of prefix, so I don't quite > see that last point. The benefits of a standard prefix length > would (IMNSHO) have been considerable, but that ship has sailed. >=20 > Brian Actually, even the providers that are brain-damaged enough to think they = don't want to give /48s to residential are all still planning on /48 for = SMB to the best of my knowledge. Owen From owen@delong.com Sat Mar 9 23:56:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CABF11E80A6 for ; Sat, 9 Mar 2013 23:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 YZBEKeAMcfmJ for ; Sat, 9 Mar 2013 23:56:07 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A907911E809C for ; Sat, 9 Mar 2013 23:56:07 -0800 (PST) Received: from delong-dhcp227.delong.com (delong-dhcp27 [192.159.10.227]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2A7qoLM009049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 9 Mar 2013 23:52:51 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2A7qoLM009049 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1362901971; bh=VYEPDZ9Eu17VphWy4PjIVW+6GM8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=dMD3TV3GN92UP+UVnfECA0p9XU0WWbopNo1+qXcNa8wADTvu/FIuHUjj4gjjH8+10 kD7BDdAkD7O7m1tVTPjxInSB5+dxPhGJaQzY5++fSljWLXlndckEbKMkyrVOYc2ncV W1FgDn+w+Y44h1wmrGlaeE1GekQFKpvMuMQJ5EcE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474B926E@mbx-01.win.nominum.com> Date: Sat, 9 Mar 2013 23:52:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <1362790998.58259.YahooMailNeo@web142504.mail.bf1.yahoo.com> <513A958B.7070104@d! ougbarton.us> <93C8132C-F72E-4BF0-98DD-2D715240445C@delong.com> <513B3D5C.3060707@gmail.com> <6D4AB912-3884-46EA-BC12-D800FA6FBAC8@delong.com> <8D23D4052ABE7A4490E77B1A012B6307474B8DD6@mbx-01.win.nominum.c om> <513B6205.7080802@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307474B8FAC@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474B926E@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Sat, 09 Mar 2013 23:52:51 -0800 (PST) Cc: "" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 07:56:08 -0000 On Mar 9, 2013, at 12:28 , Ted Lemon wrote: > On Mar 9, 2013, at 2:44 PM, Doug Barton wrote: >> The assertion I made is that ULA + NPT meets the needs of most SMEs = better than the other options. I agree that if an organization fully = utilized a /48 and then were only offered a larger prefix from a new ISP = it would make things more difficult for them to transition to that ISP. = However, the same would be true if they were using the PA space = directly. >=20 > Yes, but additionally, if the organization uses the /48 sparsely, even = if they can _fit_ into a /56, they are still going to have to do a lot = of work to make that happen, whether it's renumbering or a really hairy = NPT table. There's probably some advice worth giving about not doing = this, however this discussion ultimately ends... >=20 If they can fit into the /56, the additional renumbering effort mostly = amounts to more iterations of global search and replace because you may = need to d each /64 instead of the whole /48 in one shot. However, this = really shouldn't be an issue for an SME as I think ISPs are still = planning on /48s for business. It's just residential that they want to = shaft for unknown reasons, to the best of my knowledge. Owen From Ted.Lemon@nominum.com Sun Mar 10 05:20:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28EA221F86BB for ; Sun, 10 Mar 2013 05:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.22 X-Spam-Level: X-Spam-Status: No, score=-106.22 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XCKE8C3M8qi for ; Sun, 10 Mar 2013 05:20:16 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 890BA21F86C8 for ; Sun, 10 Mar 2013 05:20:16 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUTx6gMJjZZGfcO6CuEBJ7/cD88nDK7MX@postini.com; Sun, 10 Mar 2013 05:20:16 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 27B041B8430 for ; Sun, 10 Mar 2013 05:20: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 13B6D190043; Sun, 10 Mar 2013 05:20: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.0318.004; Sun, 10 Mar 2013 05:20:16 -0700 From: Ted Lemon To: Owen DeLong Thread-Topic: [v6ops] ULA discussion #1 ULA+NAT Thread-Index: Ac4Y0qVmXOczhdgyTHaW1OIbGrg4zQAVbZqAABAGvAAAAlzXgAAIFLoAAAKCZIAABfkCAAAA0RCAAACcd4AAAOJ/gAAAJRsAAABlxoAAALV/gAACHAWAACcL2QAAHe3hAAAD7pKAAABPR4AAAE+4AAAAwBSAAADwWwAAa01lAAABq4SAABScgIAABGUwAAAAy40AAAApuQAABIEzgAABAOaAAAYGkYAAAYI9gAAV0RsAAAlYYoA= Date: Sun, 10 Mar 2013 12:20:16 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474B99E0@mbx-01.win.nominum.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <1362790998.58259.YahooMailNeo@web142504.mail.bf1.yahoo.com> <513A958B.7070104@d! ougbarton.us> <93C8132C-F72E-4BF0-98DD-2D715240445C@delong.com> <513B3D5C.3060707@gmail.com> <6D4AB912-3884-46EA-BC12-D800FA6FBAC8@delong.com> <8D23D4052ABE7A4490E77B1A012B6307474B8DD6@mbx-01.win.nominum.c om> <513B6205.7080802@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307474B8FAC@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474B926E@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="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 12:20:17 -0000 On Mar 10, 2013, at 3:52 AM, Owen DeLong wrote: > If they can fit into the /56, the additional renumbering effort mostly am= ounts to more iterations of global search and replace because you may need = to d each /64 instead of the whole /48 in one shot. However, this really sh= ouldn't be an issue for an SME as I think ISPs are still planning on /48s f= or business. It's just residential that they want to shaft for unknown reas= ons, to the best of my knowledge. Yup. From tperrine@scea.com Sun Mar 10 12:12:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1898821F86C2 for ; Sun, 10 Mar 2013 12:12:34 -0700 (PDT) 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_33=0.6] 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 9tNwMSMEuN7w for ; Sun, 10 Mar 2013 12:12:33 -0700 (PDT) Received: from ironport01a.scea.com (ironport01a.scea.com [160.33.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9C50921F86A8 for ; Sun, 10 Mar 2013 12:12:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,819,1355126400"; d="scan'208";a="26561827" Received: from inbetweener02.scea.com ([160.33.45.196]) by ironport01a.scea.com with ESMTP; 10 Mar 2013 12:12:31 -0700 Received: from Toms-MacBook-Pro.local (unknown [192.168.45.100]) by inbetweener02.scea.com (Postfix) with ESMTP id 91087B8122 for ; Sun, 10 Mar 2013 12:12:31 -0700 (PDT) Message-ID: <513CDB1F.8040806@scea.com> Date: Sun, 10 Mar 2013 12:12:31 -0700 From: Tom Perrine User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <1362790998.58259.YahooMailNeo@web142504.mail.bf1.yahoo.com> <513A958B.7070104@d! ougbarton.us> <93C8132C-F72E-4BF0-98DD-2D715240445C@delong.com> <513B3D5C.3060707@gmail.com> <6D4AB912-3884-46EA-BC12-D800FA6FBAC8@delong.com> <8D23D4052ABE7A4490E77B1A012B6307474B8DD6@mbx-01.win.nominum.c om> <513B6205.7080802@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307474B8FAC@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474B926E@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474B99E0@mbx-01.win.nominum. com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474B99E0@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 10 Mar 2013 12:16:58 -0700 Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 19:12:34 -0000 On 3/10/13 5:20 AM, Ted Lemon wrote: > On Mar 10, 2013, at 3:52 AM, Owen DeLong wrote: >> If they can fit into the /56, the additional renumbering effort mostly amounts to more iterations of global search and replace because you may need to d each /64 instead of the whole /48 in one shot. However, this really shouldn't be an issue for an SME as I think ISPs are still planning on /48s for business. It's just residential that they want to shaft for unknown reasons, to the best of my knowledge. > Yup. I suspect that this is a way to differentiate the lowest level of service from a premium level of service, in order to push home users to move to a higher-cost option. Much like US cable providers push residential users to "business class" in order to get static IP assignments. From aenertia@aenertia.net Sun Mar 10 13:06:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F2B21F8964 for ; Sun, 10 Mar 2013 13:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvpsWqviYGog for ; Sun, 10 Mar 2013 13:06:29 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 54BAF21F884C for ; Sun, 10 Mar 2013 13:06:29 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hm14so558921wib.4 for ; Sun, 10 Mar 2013 13:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aenertia.net; s=dkimaenertianet; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=dtk1RVB5UAahYt5LwqDdc8XLqfuTXBPkf2os3wnzxMs=; b=PYiWA9+cEMmChxlndvIo499Iak44K0E68+UlhIAr5ou40fYJ+edZf2j22G9d1D4NG/ 9KtXP0XmecemQJ+9l00c046ogMqo42G+ir49GN026mYgQSiltLSWD13pygacfNhQrefz mWqHhVfSbioC8B9vkTxf29QY95ZV744MROrkA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=dtk1RVB5UAahYt5LwqDdc8XLqfuTXBPkf2os3wnzxMs=; b=G7TEoC7JMxEo7BPuPVmqeFGxm83ZHz9qXeCNAcyJMq+7OA1yqsdkcYdzMPnSHs7vu5 V+sXRRgrhts1iwQik0CqZT13nuA+iwODFo19Gd+4X67xtmm04aOhGKBUJrUDWvSZKVYD x1u54UXGsTeorJAa5fDHn/0gLqRLZ2e0kWmZYMLqcE/lJVRivY8dDXLpDpt1l6GvvnlJ ch/Rgb+Gjw0KR4m1D1ASUpum/ERooUkPfep+eH3lYzfAnqTzO5dKyrkVZ57rnziiiweW XrLwzYuAZeN02Q8Tds4oQqfcWOxzi15P+glWhA99Q0oW3sIeNQTTDKK/rsOrO659wH3v lxoQ== MIME-Version: 1.0 X-Received: by 10.180.75.110 with SMTP id b14mr8683781wiw.21.1362945988387; Sun, 10 Mar 2013 13:06:28 -0700 (PDT) Sender: aenertia@aenertia.net Received: by 10.194.22.100 with HTTP; Sun, 10 Mar 2013 13:06:28 -0700 (PDT) Received: by 10.194.22.100 with HTTP; Sun, 10 Mar 2013 13:06:28 -0700 (PDT) In-Reply-To: <513B6205.7080802@gmail.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <5135A4F9.6070306@dougbarton.us> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <1362790998.58259.YahooMailNeo@web142504.mail.bf1.yahoo.com> <93C8132C-F72E-4BF0-98DD-2D715240445C@delong.com> <513B3D5C.3060707@gmail.com> <6D4AB912-3884-46EA-BC12-D800FA6FBAC8@delong.com> <8D23D4052ABE7A4490E77B1A012B6307474B8DD6@mbx-01.win.nominum.com> <513B6205.7080802@gmail.com> Date: Mon, 11 Mar 2013 09:06:28 +1300 X-Google-Sender-Auth: eJMQ_vFjwSSeNvfSZ3OKg1XsfIs Message-ID: From: =?UTF-8?Q?Joel_Wir=C4=81mu_Pauling?= To: Brian E Carpenter Content-Type: multipart/alternative; boundary=f46d043be2287c80b404d79797e2 X-Gm-Message-State: ALoCoQndkHBJkfCVhwj/oULEcFv3+Qr617dj0E0WXyWszOa1WWy3h3MY5zQg7/hxyXqm9jXqDu8B Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 20:06:30 -0000 --f46d043be2287c80b404d79797e2 Content-Type: text/plain; charset=UTF-8 On 10/03/2013 5:23 AM, "Brian E Carpenter" wrote: > > On 09/03/2013 14:14, Ted Lemon wrote: > > On Mar 9, 2013, at 9:09 AM, Owen DeLong wrote: > >> How would the general case for that NOT be replacing the /48 from the previous > >> provider with a /48 from a new provider? > > > > The only case where there might be trouble is where the provider only offers a /56, but the previous provider offered a /48, and the SME expanded into the high bits of the /48 but doesn't actually need that many bits. But in any case where NPT would work, the renumbering that we are talking about would be a simple prefix replacement IIRC isn't there a recommendation that v6 delegations should be hooked into DNS and IPAM. Shouldn't the renumbering complexity be dealt with outside of general recommendations for numbering? --f46d043be2287c80b404d79797e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 10/03/2013 5:23 AM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
>
> On 09/03/2013 14:14, Ted Lemon wrote:
> > On Mar 9, 2013, at 9:09 AM, Owen DeLong <owen@delong.com> wrote:
> >> How would the general case for that NOT be replacing the /48 = from the previous
> >> provider with a /48 from a new provider?
> >
> > The only case where there might be trouble is where the provider = only offers a /56, but the previous provider offered a /48, and the SME exp= anded into the high bits of the /48 but doesn't actually need that many= bits. =C2=A0 But in any case where NPT would work, the renumbering that we= are talking about would be a simple prefix replacement

IIRC isn't there a recommendation that v6 delegations s= hould be hooked into DNS and IPAM.

Shouldn't the renumbering complexity be dealt with outsi= de of general recommendations for numbering?

--f46d043be2287c80b404d79797e2-- From dougb@dougbarton.us Sun Mar 10 13:28:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501F511E80FC for ; Sun, 10 Mar 2013 13:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8ow8BlyC4NM for ; Sun, 10 Mar 2013 13:28:07 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id C037311E80C5 for ; Sun, 10 Mar 2013 13:28:07 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:b0a4:2125:7057:44e6] (unknown [IPv6:2001:470:d:5e7:b0a4:2125:7057:44e6]) by dougbarton.us (Postfix) with ESMTPSA id 4BDB422B3F for ; Sun, 10 Mar 2013 20:28:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1362947287; bh=XsF+rGd0L8aUqizyud9p0upHD13RFmB1RZZVuiil/Sc=; h=Date:From:To:Subject:References:In-Reply-To; b=TExmWyMrruHxRlTNVbodndIkh0fpYGa3xEQzkcg0e/TFxm8ANBgdyOISXX7DwWy2F x30ctruCEf1Gq1aPr9SySAWEZfLasKN1Zc9GZA+WVwXC075yX7FNP9KIFgxj8Fgr88 XUSAqJSMmsFDUOhRvjzuGUd9g3ye2H6RiTIEvBX0= Message-ID: <513CECD6.3030900@dougbarton.us> Date: Sun, 10 Mar 2013 13:28:06 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <5135ABE2.5030004@dougbarton.us> <20130305083629.GA31370@spike.0x539.de> <5135B34F.8030809@dougbarton.us> <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <1362790998.58259.YahooMailNeo@web142504.mail.bf1.yahoo.com> <93C8132C-F72E-4BF0-98DD-2D715240445C@delong.com> <513B3D5C.3060707@gmail.com> <6D4AB912-3884-46EA-BC12-D800FA6FBAC8@delong.com> <8D23D4052ABE7A4490E77B1A012B6307474B8DD6@mbx-01.win.nominum.com> <513B6205.7080802@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 20:28:16 -0000 On 03/10/2013 01:06 PM, Joel WirÄmu Pauling wrote: > IIRC isn't there a recommendation that v6 delegations should be hooked > into DNS and IPAM. Ideally, sure. But not all sites, especially the small - medium businesses that we're discussing for non-PI solutions, are able to afford such a tool, or have staff with sufficient time/training to use one effectively. > Shouldn't the renumbering complexity be dealt with outside of general > recommendations for numbering? Please read the numerous posts on this thread already where it is generally agreed that simply putting numbers onto hosts is the tip of the iceberg when it comes to renumbering. Doug From pkern@spike.0x539.de Sun Mar 10 14:50:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8A021F8714 for ; Sun, 10 Mar 2013 14:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 upeq+iOYqIRe for ; Sun, 10 Mar 2013 14:50:00 -0700 (PDT) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id 048C021F862B for ; Sun, 10 Mar 2013 14:49:58 -0700 (PDT) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UEo7v-0007TL-8m for v6ops@ietf.org; Sun, 10 Mar 2013 22:49:55 +0100 Received: from [2001:470:720c:0:11d7:445c:42b4:ee1e] (helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1UEo7v-00020W-Qw for v6ops@ietf.org; Sun, 10 Mar 2013 22:49:56 +0100 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1UEo7u-0007oT-Sn for v6ops@ietf.org; Sun, 10 Mar 2013 22:49:54 +0100 Date: Sun, 10 Mar 2013 22:49:54 +0100 From: Philipp Kern To: v6ops@ietf.org Message-ID: <20130310214954.GB29677@spike.0x539.de> References: <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <1362790998.58259.YahooMailNeo@web142504.mail.bf1.yahoo.com> <93C8132C-F72E-4BF0-98DD-2D715240445C@delong.com> <513B3D5C.3060707@gmail.com> <6D4AB912-3884-46EA-BC12-D800FA6FBAC8@delong.com> <8D23D4052ABE7A4490E77B1A012B6307474B8DD6@mbx-01.win.nominum.com> <513B6205.7080802@gmail.com> <513CECD6.3030900@dougbarton.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline In-Reply-To: <513CECD6.3030900@dougbarton.us> Organization: The Debian Project (http://www.debian.org) X-Debbugs-No-Ack: yes User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 21:50:01 -0000 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Doug, am Sun, Mar 10, 2013 at 01:28:06PM -0700 hast du folgendes geschrieben: > >Shouldn't the renumbering complexity be dealt with outside of general > >recommendations for numbering? > Please read the numerous posts on this thread already where it is > generally agreed that simply putting numbers onto hosts is the tip > of the iceberg when it comes to renumbering. =66rom my experience putting numbers somewhere on hosts is the most time consuming tasks and the ones that might require a flag day. Firewall rules = and RAs are easily taken care of. But static addressing and manual ACLs (e.g. apache or postgresql) without keeping track where an address got written do= wn are really what's making renumbering hard. Kind regards Philipp Kern --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEAREIAAYFAlE9AAIACgkQ7Ro5M7LPzdilQgCglKdJrAVrv6kjgInQUrVLEQjW HzwAn3+ni2GkI/N8lBc1u+eBKG1o/h5i =YVrE -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- From ietf@meetecho.com Sun Mar 10 21:03:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA7121F88E1 for ; Sun, 10 Mar 2013 21:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_13=0.6] 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 CB19lHFDwTzK for ; Sun, 10 Mar 2013 21:03:20 -0700 (PDT) Received: from smtpdg10.aruba.it (smtpdg228.aruba.it [62.149.158.228]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8E021F88BF for ; Sun, 10 Mar 2013 21:03:19 -0700 (PDT) Received: from meetecho ([130.129.6.44]) by smtpcmd04.ad.aruba.it with bizsmtp id A43E1l00R0wzZHu0143GXH; Mon, 11 Mar 2013 05:03:17 +0100 Date: Mon, 11 Mar 2013 00:02:45 -0700 (PDT) From: Meetecho Team To: v6ops@ietf.org Message-ID: <9962628.3.1362985365026.JavaMail.root@meetecho> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2_5315182.1362985365025" Subject: [v6ops] Meetecho support for V6OPS session X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 04:03:20 -0000 ------=_Part_2_5315182.1362985365025 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, a virtual room has been reserved on the Meetecho system for the V6OPS WG meeting session. Access to the on-line session (including audio and video streams) will be available (just a couple of minutes before session start time) at: http://www.meetecho.com/ietf86/v6ops The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf86 Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_2_5315182.1362985365025-- From internet-drafts@ietf.org Mon Mar 11 01:42:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D980421F8A3D; Mon, 11 Mar 2013 01:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjwhcCxSqWsc; Mon, 11 Mar 2013 01:42:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC8C21F8A0C; Mon, 11 Mar 2013 01:42:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.42 Message-ID: <20130311084256.27118.24529.idtracker@ietfa.amsl.com> Date: Mon, 11 Mar 2013 01:42:56 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 08:42:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Internet Protocol Version 6 (IPv6) Profile for Mobile De= vices Author(s) : David Binet Mohamed Boucadair Ales Vizdal Cameron Byrne Gang Chen Filename : draft-ietf-v6ops-mobile-device-profile-00.txt Pages : 16 Date : 2013-03-11 Abstract: This document specifies an IPv6 profile for mobile devices. It lists the set of features a mobile device is to be compliant with to connect to an IPv6-only or dual-stack mobile network. The document identifies also features to ensure IPv4 service continuity over an IPv6-only transport. Both Hosts and devices with LAN capabilities are in scope. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fred@cisco.com Mon Mar 11 02:37:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFCE21F86A8 for ; Mon, 11 Mar 2013 02:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0qMQagtsOfW for ; Mon, 11 Mar 2013 02:37:36 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A9CE121F869A for ; Mon, 11 Mar 2013 02:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=745; q=dns/txt; s=iport; t=1362994656; x=1364204256; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TWYjaTa71CLBtEO9XZSFL99sEVanamHOx8FuEBJ7IkM=; b=F0cBwFlXEkJt+W6gm1dcAjORmnjmgzx7cv/qWt2Qv0wlxCd4IottsUFQ fpeWiVCoEmhFNfiksdSsT2Wk7XAq2Foc5JqK7DG4qWGtQlVbhA13PoGpK OqyPy1AI+Qipt1tpNBa0XLA1sL/DtBM4k+DWMxGasifjhGGdnHoln+n57 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0FAE+lPVGtJV2Z/2dsb2JhbABAA4davHOBUxZ0gigBAQEDAToPMAULAgEIIhQQMiUCBA4FCIgFBrsbF41NgQ4CIRAHEYJOYQOnSoMKgXM1 X-IronPort-AV: E=Sophos;i="4.84,822,1355097600"; d="scan'208";a="186035288" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 11 Mar 2013 09:37:36 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2B9ba4a024430 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Mar 2013 09:37:36 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 04:37:35 -0500 From: "Fred Baker (fred)" To: v6ops Thread-Topic: Meeting minute volunteer request Thread-Index: AQHOHjwPaSLAOk3U1km7HggGF30tEA== Date: Mon, 11 Mar 2013 09:37:35 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B7C91C1@xmb-rcd-x09.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.228.20] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops chairs Subject: Re: [v6ops] Meeting minute volunteer request X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 09:37:37 -0000 On Mar 9, 2013, at 10:37 PM, "Brzozowski, John" wrote: > We need volunteers to take meeting minutes for both sessions, anyone > interested should email Fred and I at the email address copied above. We also need a jabber scribe, please. > Thanks, >=20 >=20 > John > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > John Jason Brzozowski > Comcast Cable > m) 484-962-0060 > e) john_brzozowski@cable.comcast.com > o) 609-377-6594 > w) www.comcast6.net > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 >=20 From fred@cisco.com Mon Mar 11 04:43:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F0E21F8794 for ; Mon, 11 Mar 2013 04:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1K5IYv-0zsD for ; Mon, 11 Mar 2013 04:43:29 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1B57B21F8790 for ; Mon, 11 Mar 2013 04:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1742; q=dns/txt; s=iport; t=1363002209; x=1364211809; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Wl5ZhiWdQdkhpw9AaMDho7adbdE2DsJ2PdmWY4RNdBo=; b=M+id09h5Og4tIb1G/njj2j+VDyAatXOl5aDLvgoAIR8v6bjMUXHg7fMR H6v4Bbqx1v5nflsrRRs53+i0qhzO4PgVeLMKNg5HPMYlUClPdmp/PzuLW wjj31YB/5GT18uThcpSCkC4CAwNlwu2VQmxE++Uu7Elxjm7TtiL/knSSW o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFADzCPVGtJXHB/2dsb2JhbABDxFGBVxZtB4IoAQEBAwE6PwUNASoUQicEDg2IBQa7IBeOXTGCZmEDp0qDCoIo X-IronPort-AV: E=Sophos;i="4.84,822,1355097600"; d="scan'208";a="185824759" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 11 Mar 2013 11:43:28 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2BBhSUR001831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Mar 2013 11:43:28 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 06:43:28 -0500 From: "Fred Baker (fred)" To: "draft-ietf-v6ops-mobile-device-profile@tools.ietf.org" Thread-Topic: Internet Protocol Version 6 (IPv6) Profile for Mobile Devices Thread-Index: AQHOHk2ld4TZI6ljRkmnpHz8chBCeg== Date: Mon, 11 Mar 2013 11:43:27 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B7C9487@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.228.20] Content-Type: text/plain; charset="us-ascii" Content-ID: <6AE553C3E19E6349B3B790A4EBD92479@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops WG Subject: [v6ops] Internet Protocol Version 6 (IPv6) Profile for Mobile Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 11:43:29 -0000 I remain concerned about the cognitive dissonance between this draft and dr= aft-ietf-v6ops-rfc3316bis. > Abstract >=20 > This document specifies an IPv6 profile for mobile devices. It lists > the set of features a mobile device is to be compliant with to > connect to an IPv6-only or dual-stack mobile network. The document > identifies also features to ensure IPv4 service continuity over an > IPv6-only transport. >=20 > Both Hosts and devices with LAN capabilities are in scope. It is correct to say that this is "an IPv6 Profile", in the sense that ther= e may be other profiles. It is incorrect to say that this is the profile re= quired for connecting to "an IPv6-only or dual-stack mobile network", which= is to say "for connecting the device to any IPv6 mobile network, whether I= Pv4 or also configured or not". That profile is described in RFC 3316 and i= s being updated in draft-ietf-v6ops-rfc3316bis. I will send one document to the IESG that updates or replaces RFC 3316, and= I am willing to send one document that refers to 3316bis and adds addition= al requirements for some more specialized service. I will not send two draf= ts that claim to replace 3316's requirements but differ in their listed req= uirements, because that is guaranteed to cause confusion for both operators= and vendors. Please change the Abstract and language in the document to recognize that t= his is a *different* profile than the one for general connection to IPv6 mo= bile networks. It is by definition for IPv6 services with some kind of qual= ifier, which must be stated.=20 If you can't distinguish this document from 3316bis, its requirements need = to be merged into 3316bis.= From fred@cisco.com Mon Mar 11 05:45:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2D921F85CE for ; Mon, 11 Mar 2013 05:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlZtx2jIjbHV for ; Mon, 11 Mar 2013 05:45:02 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E35EE21F85E0 for ; Mon, 11 Mar 2013 05:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1363005902; x=1364215502; h=date:from:message-id:to:subject:cc; bh=ze2zLaaoXD/jP3VJy7+24XkNl/1DVjpNRhlxdjbTLcw=; b=DxuQB0ivrLSIusgnBLyXH8OpL6NaE7RCu7NpbnnUpg2bxuxQ6WPpeP9j b5KSwwEHJDVjfh4INVQDRsswncrmfBFxm2SpxNTfhJg2jubqDl33MuHdT KBRxLpSwrhKUonPn/XFSjEanqiVddw5swJ0lTziI52GY/1+2nHu/g5vFf k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8MAL7QPVGrRDoG/2dsb2JhbABDh2CrHQGRTQQDAYFZFnSDKDwtB4hzDbs7jw4dgyoDiHKPAY9Xgyo X-IronPort-AV: E=Sophos;i="4.84,822,1355097600"; d="scan'208";a="72467568" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 11 Mar 2013 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2BCj1mr019191; Mon, 11 Mar 2013 12:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r2BCj1Q21809; Mon, 11 Mar 2013 05:45:01 -0700 (PDT) Date: Mon, 11 Mar 2013 05:45:01 -0700 (PDT) From: Message-Id: <201303111245.r2BCj1Q21809@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-ietf-v6ops-mobile-device-profile@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-mobile-device-profile X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 12:45:02 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile. Please take a look at it and comment. From mohamed.boucadair@orange.com Mon Mar 11 05:53:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9C721F8790 for ; Mon, 11 Mar 2013 05:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.321 X-Spam-Level: X-Spam-Status: No, score=-1.321 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1w-nUjcqOqW for ; Mon, 11 Mar 2013 05:53:08 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id AC56521F85A4 for ; Mon, 11 Mar 2013 05:53:07 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 904C818C17D; Mon, 11 Mar 2013 13:53:06 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 6B4AC4C06D; Mon, 11 Mar 2013 13:53:06 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Mon, 11 Mar 2013 13:53:06 +0100 From: To: "Fred Baker (fred)" , "draft-ietf-v6ops-mobile-device-profile@tools.ietf.org" Date: Mon, 11 Mar 2013 13:53:05 +0100 Thread-Topic: Internet Protocol Version 6 (IPv6) Profile for Mobile Devices Thread-Index: AQHOHk2ld4TZI6ljRkmnpHz8chBCepigbEpA Message-ID: <94C682931C08B048B7A8645303FDC9F36EB61349CE@PUEXCB1B.nanterre.francetelecom.fr> References: <8C48B86A895913448548E6D15DA7553B7C9487@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B7C9487@xmb-rcd-x09.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: 2013.3.11.120617 Cc: v6ops WG Subject: Re: [v6ops] Internet Protocol Version 6 (IPv6) Profile for Mobile Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 12:53:08 -0000 Dear Fred, draft-ietf-v6ops-mobile-device-profile does not say it updates RFC3316. Its= scope is clearly mentioned in the abstract and the introduction.=20 The document includes a section which positions this draft vs. draft-ietf-v= 6ops-rfc3316bis (see http://tools.ietf.org/html/draft-ietf-v6ops-mobile-dev= ice-profile-00#section-1.1).=20 You have already raised the same question and I replied to your message her= e (Feb 18th) http://www.ietf.org/mail-archive/web/v6ops/current/msg15303.ht= ml but I didn't seen a follow up on that discussion. So, I can not guess wh= at you are expecting to see recorded in the document. As a matter of fact, three intermediate versions of draft-binet-* were subm= itted and discussed in this list before draft-korhonen-* came out. Even if = draft-korhonen-* was never discussed in this list nor a call for adoption i= s issued in the list, we never complained nor claimed this is not fair with= regards to the effort we made to explain why the profile document is neede= d, to integrate comments from the reviewers, to resubmit a new version with= out mentioning rfc3316update, etc. Can you please explicit what changes you want to see added to http://tools.= ietf.org/html/draft-ietf-v6ops-mobile-device-profile-00#section-1.1? Cheers, Med=20 >-----Message d'origine----- >De : Fred Baker (fred) [mailto:fred@cisco.com]=20 >Envoy=E9 : lundi 11 mars 2013 12:43 >=C0 : draft-ietf-v6ops-mobile-device-profile@tools.ietf.org >Cc : v6ops WG; John Brzozowski; joel jaeggli >Objet : Internet Protocol Version 6 (IPv6) Profile for Mobile Devices > >I remain concerned about the cognitive dissonance between this=20 >draft and draft-ietf-v6ops-rfc3316bis. > >> Abstract >>=20 >> This document specifies an IPv6 profile for mobile=20 >devices. It lists >> the set of features a mobile device is to be compliant with to >> connect to an IPv6-only or dual-stack mobile network. =20 >The document >> identifies also features to ensure IPv4 service continuity over an >> IPv6-only transport. >>=20 >> Both Hosts and devices with LAN capabilities are in scope. > >It is correct to say that this is "an IPv6 Profile", in the=20 >sense that there may be other profiles. It is incorrect to say=20 >that this is the profile required for connecting to "an=20 >IPv6-only or dual-stack mobile network", which is to say "for=20 >connecting the device to any IPv6 mobile network, whether IPv4=20 >or also configured or not". That profile is described in RFC=20 >3316 and is being updated in draft-ietf-v6ops-rfc3316bis. > >I will send one document to the IESG that updates or replaces=20 >RFC 3316, and I am willing to send one document that refers to=20 >3316bis and adds additional requirements for some more=20 >specialized service. I will not send two drafts that claim to=20 >replace 3316's requirements but differ in their listed=20 >requirements, because that is guaranteed to cause confusion=20 >for both operators and vendors. > >Please change the Abstract and language in the document to=20 >recognize that this is a *different* profile than the one for=20 >general connection to IPv6 mobile networks. It is by=20 >definition for IPv6 services with some kind of qualifier,=20 >which must be stated.=20 > >If you can't distinguish this document from 3316bis, its=20 >requirements need to be merged into 3316bis.= From gert@space.net Mon Mar 11 06:05:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4559321F87BA for ; Mon, 11 Mar 2013 06:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 ydyeCgg1-lzr for ; Mon, 11 Mar 2013 06:05:51 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id A0E6721F86FF for ; Mon, 11 Mar 2013 06:05:50 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 1602E6040F for ; Mon, 11 Mar 2013 14:05:49 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id E34F760183 for ; Mon, 11 Mar 2013 14:05:48 +0100 (CET) Received: (qmail 25297 invoked by uid 1007); 11 Mar 2013 14:05:48 +0100 Date: Mon, 11 Mar 2013 14:05:48 +0100 From: Gert Doering To: Ray Hunter Message-ID: <20130311130548.GY51699@Space.Net> References: <5136C780.3070306@dougbarton.us> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B2162@mbx-01.win.nominum.com> <709A43C8-3D68-49D6-98DA-631E84C78075@virtualized.org> <51383EE3.1000503@globis.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51383EE3.1000503@globis.net> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 13:05:52 -0000 Hi, On Thu, Mar 07, 2013 at 08:16:51AM +0100, Ray Hunter wrote: > And as for portability of PI space across providers, and fear of routing > table explosion, I suggest the RIR's and LIR's look long and hard at > what happened in the mobile Telco World, where number portability was > thrust on them by the regulators / politicians. Telcos manage that > situation pretty well, even though there are potentially billions of > "host routes". If you can life with "changing to a different provider will take a few days to move the address" and "occasionally the number will be completely lost afterwards", then yes, this model would surely "scale"... (Network roaming is more like mobile IPv6 as it doesn't change the "home network" for your number, but instead tunnel back and forth) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From alexandru.petrescu@gmail.com Mon Mar 11 09:59:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E5411E8167 for ; Mon, 11 Mar 2013 09:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.749 X-Spam-Level: X-Spam-Status: No, score=-9.749 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uc85EMt6Nwbh for ; Mon, 11 Mar 2013 09:59:47 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 4407A11E8159 for ; Mon, 11 Mar 2013 09:59:47 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2BGxfiH013533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Mar 2013 17:59:41 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2BGxfxn019782; Mon, 11 Mar 2013 17:59:41 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.1]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2BGxZXm009695; Mon, 11 Mar 2013 17:59:40 +0100 Message-ID: <513E0D5F.4010904@gmail.com> Date: Mon, 11 Mar 2013 17:59:11 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Owen DeLong References: <512CF682.8030307@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6D11E055F@SRVHKE02.rdm.cz> <5130B665.1020907@gmail.com> <8D4B01C4-EC43-48A4-BC15-A4D2DC5CACC2@delong.com> In-Reply-To: <8D4B01C4-EC43-48A4-BC15-A4D2DC5CACC2@delong.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 16:59:48 -0000 Le 02/03/2013 03:59, Owen DeLong a écrit : > > On Mar 1, 2013, at 06:08 , Alexandru Petrescu > wrote: > >> Le 27/02/2013 00:59, Vízdal Ale¹ a écrit : >>>>> Correct. NAT44 is good enough if you can number users from >>>>> RFC1918. If users (including M2M ...) and infrastructure >>>>> exceed RFC1918 space >>>> >>>> If they exceed RFC1918 space (10.0.0.0/8, 172.16.0.0/12 and >>>> 192.168.0.0/16) then there is this 100.64.0.0/10 new space >>>> from RFC6598. >>> >>> Unfortunately, 40-60 million customer base cannot be addressed >>> by RFC1918/10.64/10 address space. >> >> Well. I side with typical advocating of IPv6 and big numbers. But >> let me play devil's advocate here. >> >> 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and 100.64.0.0/10 make up >> for a total of unique 22 million (22085632) addresses. This is >> indeed less than the 40-60 million customer base. >> >> But the nature of NAT is more than that. It is also about - >> multiple levels of NAT. > Breaks many NAT traversal solutions and makes NAT even more > dysfunctional. It may, but I am not sure which ones? The NAT Traversal of Mobile IP (based on UDP) works ok with this NAT. Also, NAT Traversal is not absolutely necessary. One may use Internet without employing NAT Traversal. >> - NAT technology can be used with publicly routable addresses >> which are not RFC1918/RFC6598. > > Breaks NAT-oriented assumptions that have been baked into some > applications NAT traversal efforts. I didnt know that. I wonder which NAT traversal solution is built in with the assumption that the IP address is only RFC1918 space? (remark these implementations will fail also when the new NAT space 100./10 is employed, instead of RFC1918). >> - dynamic address allocation. > > Has nothing whatsoever to do with NAT. It has to do with the lack of addresses argument. Although an operator may need 50million addresses, these are not needed at the same time. And the dynamic nature of DHCP allows for it. >> With 3 levels of NAT and an additional not-used class B, one can >> easily cover a 40-60 million customer base. Not all 40-60 million >> customers are connected simultaneously. DHCP takes care to revoke >> use of an address and deliver it to someone else needing it. > > There are a lot of (not necessarily correct) assumptions about usage > patterns built into those numbers. I can guarantee you that if an > ISP were to inflict such an implementation on residential > subscribers, they would lose customers quickly. Residential - I tend to agree, people tend to need a more comfortable IP connection when the place is as comfortable as at home. > In mobile, maybe, maybe not. People have become pretty tolerant of an > impressive level of dysfunctionality in mobile IP in the US. Well, this is the case of how the computer is used. When people are mobile they do less things on a computer than when at a desk. IPv4 and NAT are maybe sufficient for that. >> If all 40-60 million customers were connected simultaneously then >> the core network would crash - but for other reasons than IPv4 >> address numbers. > > I'm not actually convinced that's true. > >> Cellular network crashes exist yet they're not due to too small >> IPv4 addressing space. > > Whether the lack of addresses crashes the network or not, it > certainly degrades the user experience. Operators are afraid of having to pay subscribers, rather than offering them a degraded service. Operators pay subscribers when the service fails entirely. >> There is not a problem in numbers when using NAT technology to >> cover that 40-60 million customer base. There are other problems, >> but not in numbers of IPv4 addressing. > > Yes, there is a real problem in IPv4 numbers, too. The fact that > you're more willing to add a bunch of hacks to IPv4 to try and prop > it up instead of implementing IPv6 really doesn't change the fact > that there is a problem. > >> If these problems could be formulated then we could have a case for >> IPv6 in cellular networks. > > The problems have been formulated and a number of cellular networks > have started deploying IPv6. I believe Slovenia is completely > dual-stacked on their cellular networks, for example. It is a good exemple. But I would like to learn whether Slovenia deploys LTE. I think it does not look at it. An dif it does, I would be surprised that were IPv6 (although Slovenia may look at deploying 3G and IPv6). > I know that Verizon and T-Mobile both have IPv6 on their wireless > networks to varying degrees. Yes, varying degrees. That is a detail point I am trying to understand - who deploys IPv6 and LTE/4G. Alex > > Owen >> > > From alexandru.petrescu@gmail.com Mon Mar 11 10:13:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C42D21F8BF8 for ; Mon, 11 Mar 2013 10:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.874 X-Spam-Level: X-Spam-Status: No, score=-9.874 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZmcCgnnMldw for ; Mon, 11 Mar 2013 10:13:09 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEB021F8BF6 for ; Mon, 11 Mar 2013 10:13:09 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2BHD41T018322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Mar 2013 18:13:04 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2BHD4p3023871; Mon, 11 Mar 2013 18:13:04 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.8]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2BHCv07015550; Mon, 11 Mar 2013 18:13:03 +0100 Message-ID: <513E1081.3060404@gmail.com> Date: Mon, 11 Mar 2013 18:12:33 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Victor Kuarsingh References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 17:13:11 -0000 Le 02/03/2013 04:37, Victor Kuarsingh a écrit : > > > On 2013-03-01 9:59 PM, "Owen DeLong" wrote: > >> >> On Mar 1, 2013, at 06:08 , Alexandru Petrescu >> wrote: >> >>> Le 27/02/2013 00:59, Vízdal Ale¹ a écrit : >>>>>> . In mobile, maybe, maybe not. People >> have become pretty tolerant of an impressive level of >> dysfunctionality in mobile IP in the US. > > I think this is going to change. I suspect as people start to use > mobile interchangeably with their traditional wired connections, they > will demand more robust connectivity. I dont think people use mobile interchangeably with their wired connections. For example, real Word and Excel never took off on smartphones. Moreover, there are now have a large number of smartphone-exclusive Applications. I doubt many of them do IPv6. These applications were written from scratch at a time when IPv6 existed and was mature enough already. Yet ignored. > I.e. Exchanging your wired connection for Wireless to realize you > can't do all the stuff you did the day before is frustrating. Wired to wireless - ok, but wireless WiFi, not cellular. > Although tolerated to date, I suspect the tides will change. I also > think IPv6 is a good way to get there and that IPv4 can't IMHO (given > this list, I would guess that some may agree). Yes, the profile on this list is IPv6. I will shut up :-) Alex > > My 0.02. > > Regards, > > Victor Kuarsingh > > >> > > > From swmike@swm.pp.se Mon Mar 11 10:18:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4377C11E8169 for ; Mon, 11 Mar 2013 10:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 j3OQj6QkX+A7 for ; Mon, 11 Mar 2013 10:18:51 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 879FB11E8166 for ; Mon, 11 Mar 2013 10:18:51 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8EFB29C; Mon, 11 Mar 2013 18:18:49 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8160B9A; Mon, 11 Mar 2013 18:18:49 +0100 (CET) Date: Mon, 11 Mar 2013 18:18:49 +0100 (CET) From: Mikael Abrahamsson To: fred@cisco.com In-Reply-To: <201303111245.r2BCj1Q21809@ftpeng-update.cisco.com> Message-ID: References: <201303111245.r2BCj1Q21809@ftpeng-update.cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org, draft-ietf-v6ops-mobile-device-profile@tools.ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-mobile-device-profile X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 17:18:52 -0000 On Mon, 11 Mar 2013, fred@cisco.com wrote: > > A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile. Please take a look at it and comment. I have read this. REQ#29. I have had some confusion by vendors when I request this in a similar wording. As soon as they see "release 10", they see a huge chunk of requirements and they will say "device doesn't support release 10". When I then tell them that DHCPv6-PD is a purely control plane feature, I have received more favorable responses. I recommend to re-write of this paragraph to tone down the Release 10 mention. REQ#31: What about MSS clamping? Apart from that, I like this document and it's a useful collection of requirements. -- Mikael Abrahamsson email: swmike@swm.pp.se From cb.list6@gmail.com Mon Mar 11 10:27:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3505111E8165 for ; Mon, 11 Mar 2013 10:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbK4oHb0Ifsq for ; Mon, 11 Mar 2013 10:27:23 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 58B0011E80CC for ; Mon, 11 Mar 2013 10:27:23 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id r6so3800100wey.19 for ; Mon, 11 Mar 2013 10:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=O2lNtL/C/kwmSiXIKj88U+C4mTIlUS0tgRn4fVkPdSE=; b=JM+XV8WppgKx0ogf0mNVdqwAjhIgHG4Y9Hu0PwjiSn96INOP2MptGAThi7o1Ms0Hxp v8PWln52R3a1l6ZRNnOA4t28y8F0uIsfNph/nKuCBtwm/7GtNW43CwU2zvwXKUxqRdGy ZQwTtvFsj7HmQTbMCBnheV4uy46D3CvLXrFPYLmo7NfEQFPqik/ff6BjDcF5hXdoNb6X XwGXYLeVyF1t/DOZR3b7S7WyXDiLmPV6jv2dDYIjF1WApNLFpo1RfAAs7J3n0ZjQKYAT ctQxFx7GftsmpSTeH7Frk6B1ynqfsg81jrKROZSJxIs8wi8lpqc9a5G3qNc8Af9nxrtj iHXQ== MIME-Version: 1.0 X-Received: by 10.194.123.103 with SMTP id lz7mr7973197wjb.10.1363022835955; Mon, 11 Mar 2013 10:27:15 -0700 (PDT) Received: by 10.194.20.35 with HTTP; Mon, 11 Mar 2013 10:27:15 -0700 (PDT) Date: Mon, 11 Mar 2013 10:27:15 -0700 Message-ID: From: Cameron Byrne To: IPv6 Ops WG , Dave Thaler Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 17:27:24 -0000 Dave, Here is the quote of the current draft text. Does this correctly describe the link model that the gateway does not consume an address? Would you suggest a change? "As [RFC6459] describes, the 3GPP network assigned /64 is completely dedicated to the UE and the gateway does not consume any of the /64 addresses. The gateway routes the entire /64 to the UE and does not perform ND or Network Unreachability Detection (NUD) [RFC4861]." http://tools.ietf.org/html/draft-ietf-v6ops-64share-03 Cameron From alexandru.petrescu@gmail.com Mon Mar 11 10:39:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0602C11E80DE for ; Mon, 11 Mar 2013 10:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gM+Z8JAyFYXE for ; Mon, 11 Mar 2013 10:39:55 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 28FDB11E80CC for ; Mon, 11 Mar 2013 10:39:54 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2BHdnjZ027237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 11 Mar 2013 18:39:49 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2BHdmf0029237 for ; Mon, 11 Mar 2013 18:39:49 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.8]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2BHdg9Y011131 for ; Mon, 11 Mar 2013 18:39:47 +0100 Message-ID: <513E16C5.5090508@gmail.com> Date: Mon, 11 Mar 2013 18:39:17 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 17:39:56 -0000 In addition to this, (sorry for intervening, I should have said this to the mic), there is a need to state that this works only when: - this is a cellular link of kind point-to-point; it does not work when that cellular link is of kind 'shared link', eg with a qmi client, and Qualcomm chipset. - the Gateway does _not_ send an NS for _any_ of the addresses within the /64 prefix. - the Gateway does not use a 'Connected' route towards that /64. There may exist cellular links on which this 64share does not work. (and I find it strange to talk purely implementation in this draft, but when it comes to its inconvenients to refer to some 3GPP spec - it is widely known that 3GPP specs are implemented in various incompatible ways; the draft would better talk pure implementation everywhere). Alex Le 11/03/2013 18:27, Cameron Byrne a écrit : > Dave, > > Here is the quote of the current draft text. Does this correctly > describe the link model that the gateway does not consume an > address? Would you suggest a change? > > "As [RFC6459] describes, the 3GPP network assigned /64 is completely > dedicated to the UE and the gateway does not consume any of the /64 > addresses. The gateway routes the entire /64 to the UE and does not > perform ND or Network Unreachability Detection (NUD) [RFC4861]." > > http://tools.ietf.org/html/draft-ietf-v6ops-64share-03 > > Cameron _______________________________________________ v6ops mailing > list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From alexandru.petrescu@gmail.com Mon Mar 11 10:48:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F343911E8128 for ; Mon, 11 Mar 2013 10:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCbSyxI47ENM for ; Mon, 11 Mar 2013 10:48:28 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2337111E80DE for ; Mon, 11 Mar 2013 10:48:27 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2BHmQw9003194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Mar 2013 18:48:26 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2BHmQAe030936; Mon, 11 Mar 2013 18:48:26 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.8]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2BHmOf0027885; Mon, 11 Mar 2013 18:48:25 +0100 Message-ID: <513E18CE.3080808@gmail.com> Date: Mon, 11 Mar 2013 18:47:58 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Mikael Abrahamsson References: <510F7FCC.5040705@viagenie.ca> <510FC324.7090908@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 17:48:29 -0000 Le 04/02/2013 17:43, Mikael Abrahamsson a écrit : > On Mon, 4 Feb 2013, Alexandru Petrescu wrote: > >> A parallel could be drawned between the GPRS-3G migration and >> 3G-LTE, in terms of IP family of protocols. If I remember >> correctly, the GPRS deployment was IPv4 NAT and one had to wait for >> 2nd generation 3G deployments to see publicly routable IPv4 >> addresses and IPv6 in test. Maybe now we wait the same - a second >> or 3rd generation LTE deployment to see publicly routable IPv4 and >> IPv6. > > This is really weird. > > Personally, I'm trying to get 2G/3G/4G equal service with proper > establishment and handover between the networks for a IPv4v6 PDP > context. > >> So, I personnally wait for the following, in this order: - 3G >> network to become IPv6 for everybody - LTE network to become IPv4 >> publicly routable addresses - LTE network to become IPv6 as test - >> LTE network to become IPv6 for everybody All this maybe in 3-6 >> years time. At that time we'd talk 5G already I believe. > > Doing IPv4v6 on LTE is not that much of a problem, that's doable > today (my experience). I am not sure what you mean by 'doable'. Do you know of an operator having done some LTE IPv6 test? Alex Getting the same IPv4v6 so the customer can establish a > IPv4v6 PDP context in 3G, handing over to 4G and back to 3G, that's > where it gets interesting. :P > > For me 2G/3G/4G are different access technologies that should be > transparent to the user, they should offer the same services just at > increasingly higher speeds. > > IPv6 only access on 2G/3G/4G is also doable (there are quite a few > phones and usb dongles that do this), the problem is that IPv6 only + > NAT64 gives a lousy end user experience without 464XLAT, so that's a > no-go. > From cb.list6@gmail.com Mon Mar 11 10:59:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66A611E815A for ; Mon, 11 Mar 2013 10:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=1.027, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 JAxYlJ2MjbhL for ; Mon, 11 Mar 2013 10:59:50 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id F07B211E80F2 for ; Mon, 11 Mar 2013 10:59:49 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id 16so5104737wgi.15 for ; Mon, 11 Mar 2013 10:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=vT4Dl0+Ua79KbzXBYrPOCCirLY6LwGnu+XVaHLrVwOo=; b=fQG5tygKFmDe4hGgxPNqYqoylnBlbSdPWwfR1CFeCF0mGLSWmGxt4pg7zERTGKclkQ 8LJWlqEAu565GnigiXiOn3hWuOV+DiZxSyCg+OQxg+bx7o+R/TAd9chndZa44YL8AEWg 2GLlnPxLYLUBo6gmvpiZtEkM5hk6BtNmC98xTty/mpCFSC6wpn1nZ/6zdRI4JfIqpk7e d+kW3YmaSdiEarZyXhJ9OBcXrQqDuu0sA0fXJl0wwYHWdrjowPtBdb/gX5siq5ZakhV7 rn5Vm3tAbqe/RDnvIoeaxBW3tmIg60o8r4D+oZV3d3/L+J2hD2GAh9ZN9yPW3KE9BiHM r7Wg== MIME-Version: 1.0 X-Received: by 10.180.98.232 with SMTP id el8mr14546012wib.22.1363024777140; Mon, 11 Mar 2013 10:59:37 -0700 (PDT) Received: by 10.194.20.35 with HTTP; Mon, 11 Mar 2013 10:59:37 -0700 (PDT) In-Reply-To: <513E16C5.5090508@gmail.com> References: <513E16C5.5090508@gmail.com> Date: Mon, 11 Mar 2013 10:59:37 -0700 Message-ID: From: Cameron Byrne To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 17:59:50 -0000 Alex, On Mon, Mar 11, 2013 at 10:39 AM, Alexandru Petrescu wrote: > In addition to this, (sorry for intervening, I should have said this to > the mic), there is a need to state that this works only when: > > - this is a cellular link of kind point-to-point; it does not work when > that cellular link is of kind 'shared link', eg with a qmi client, and > Qualcomm chipset. > There is no other 3GPP link model. There is only p2p. What i believe you are referencing is a link model that is a specific implementation towards tethered devices, and not within the scope of any 3GPP standard. We only consider 3GPP link model as described in the draft explicitly and via reference to rfc6459. Our hope is that publishing this draft will avoid new invention from every OEM. > - the Gateway does _not_ send an NS for _any_ of the addresses within > the /64 prefix. > This is also already covered in stating that is this standard 3GPP operatio= n > - the Gateway does not use a 'Connected' route towards that /64. > I am not sure what this one is, but i assume it is covered in the same way as above. > There may exist cellular links on which this 64share does not work. > We believe all case for standard 3GPP links are covered. > (and I find it strange to talk purely implementation in this draft, but > when it comes to its inconvenients to refer to some 3GPP spec - it is > widely known that 3GPP specs are implemented in various incompatible > ways; the draft would better talk pure implementation everywhere). > I have running code for scenario 3. CB > Alex > > Le 11/03/2013 18:27, Cameron Byrne a =E9crit : >> >> Dave, >> >> Here is the quote of the current draft text. Does this correctly >> describe the link model that the gateway does not consume an >> address? Would you suggest a change? >> >> "As [RFC6459] describes, the 3GPP network assigned /64 is completely >> dedicated to the UE and the gateway does not consume any of the /64 >> addresses. The gateway routes the entire /64 to the UE and does not >> perform ND or Network Unreachability Detection (NUD) [RFC4861]." >> >> http://tools.ietf.org/html/draft-ietf-v6ops-64share-03 >> >> Cameron _______________________________________________ v6ops mailing >> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From swmike@swm.pp.se Mon Mar 11 11:00:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFC811E8196 for ; Mon, 11 Mar 2013 11:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QW8wRKNCx5tR for ; Mon, 11 Mar 2013 11:00:18 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 63AD611E819E for ; Mon, 11 Mar 2013 11:00:18 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 346CC9C; Mon, 11 Mar 2013 19:00:13 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2A6729A; Mon, 11 Mar 2013 19:00:13 +0100 (CET) Date: Mon, 11 Mar 2013 19:00:13 +0100 (CET) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <513E18CE.3080808@gmail.com> Message-ID: References: <510F7FCC.5040705@viagenie.ca> <510FC324.7090908@gmail.com> <513E18CE.3080808@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: v6ops@ietf.org Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 18:00:19 -0000 On Mon, 11 Mar 2013, Alexandru Petrescu wrote: > I am not sure what you mean by 'doable'. Do you know of an operator > having done some LTE IPv6 test? I have IPv4v6 working in our LTE network today, network wide. Not in production to customers, but doing IPv4v6 in LTE is comparitively easy. We had it working 2-3 years ago. I don't want to IPv6 enable our users when they're connected to the LTE network and then have customers lose their IPv6 connectivity if they happen to hand over to 2G or 3G. -- Mikael Abrahamsson email: swmike@swm.pp.se From john_brzozowski@cable.comcast.com Mon Mar 11 11:03:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8AD11E81AD for ; Mon, 11 Mar 2013 11:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.711 X-Spam-Level: X-Spam-Status: No, score=-103.711 tagged_above=-999 required=5 tests=[AWL=0.920, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxXin6WH6uTg for ; Mon, 11 Mar 2013 11:03:30 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 9F98D11E81A7 for ; Mon, 11 Mar 2013 11:03:21 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.60274940; Mon, 11 Mar 2013 11:32:05 -0600 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Mon, 11 Mar 2013 14:03:17 -0400 From: "Brzozowski, John" To: v6ops Thread-Topic: IETF 86 v6ops Working Group Chair Hour Thread-Index: AQHOHoK0K5g8wQvL7EmB1fx1cHHMJQ== Date: Mon, 11 Mar 2013 18:03:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] IETF 86 v6ops Working Group Chair Hour X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 18:03:31 -0000 We will arrive early since session #1 ended ahead of schedule, Fred and I will be in BOCA III (3) starting at 230PM ET. Fred and John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozowski@cable.comcast.com o) 609-377-6594 w) www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From tore@fud.no Mon Mar 11 11:07:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C8011E81CE for ; Mon, 11 Mar 2013 11:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HEYyMVM8l0Y for ; Mon, 11 Mar 2013 11:07:30 -0700 (PDT) Received: from greed.fud.no (unknown [IPv6:2a02:c0:1001:100:216:3eff:feaf:f94f]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3A111E81C6 for ; Mon, 11 Mar 2013 11:07:30 -0700 (PDT) Received: from [2a02:fe0:cf16:70:21d:60ff:fe48:f59e] (port=46860 helo=wrath.fud.no) by greed.fud.no with esmtpa (Exim 4.76) (envelope-from ) id 1UF78D-0001xR-88; Mon, 11 Mar 2013 19:07:29 +0100 Message-ID: <513E1D61.20308@fud.no> Date: Mon, 11 Mar 2013 19:07:29 +0100 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: Mikael Abrahamsson References: <510F7FCC.5040705@viagenie.ca> <510FC324.7090908@gmail.com> <513E18CE.3080808@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 18:07:31 -0000 * Mikael Abrahamsson > On Mon, 11 Mar 2013, Alexandru Petrescu wrote: > >> I am not sure what you mean by 'doable'. Do you know of an operator >> having done some LTE IPv6 test? > > I have IPv4v6 working in our LTE network today, network wide. Not in > production to customers, but doing IPv4v6 in LTE is comparitively easy. > We had it working 2-3 years ago. > > I don't want to IPv6 enable our users when they're connected to the LTE > network and then have customers lose their IPv6 connectivity if they > happen to hand over to 2G or 3G. Is this only a challenge for IPv4v6, or does it apply to IPv6 as well? I know of several 3G networks that support IPv6 in production for their customers, but I don't know if any of those also operate LTE networks and if so whether or not the handover between the network types works. Best regards, -- Tore Anderson From swmike@swm.pp.se Mon Mar 11 11:28:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E08421F8D60 for ; Mon, 11 Mar 2013 11:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 L+pHmrU+yex4 for ; Mon, 11 Mar 2013 11:28:35 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id EFE8E21F8D45 for ; Mon, 11 Mar 2013 11:28:34 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 15B539C; Mon, 11 Mar 2013 19:28:33 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id F343B9A; Mon, 11 Mar 2013 19:28:33 +0100 (CET) Date: Mon, 11 Mar 2013 19:28:33 +0100 (CET) From: Mikael Abrahamsson To: Tore Anderson In-Reply-To: <513E1D61.20308@fud.no> Message-ID: References: <510F7FCC.5040705@viagenie.ca> <510FC324.7090908@gmail.com> <513E18CE.3080808@gmail.com> <513E1D61.20308@fud.no> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 18:28:36 -0000 On Mon, 11 Mar 2013, Tore Anderson wrote: >> I don't want to IPv6 enable our users when they're connected to the LTE >> network and then have customers lose their IPv6 connectivity if they >> happen to hand over to 2G or 3G. > > Is this only a challenge for IPv4v6, or does it apply to IPv6 as well? Well, it's a scaling issue as well. Currently supporting IPv4+IPv6 is not really a problem, but this increases the signalling load. For me it's been a problem to get IPv4v6 support in 2G+3G which I want before deploying. > I know of several 3G networks that support IPv6 in production for their > customers, but I don't know if any of those also operate LTE networks > and if so whether or not the handover between the network types works. One way is to go IPv4v6 in LTE and IPv4+IPv6 (dual bearers) in 2G/3G. I don't know how well this works in real life. This is one of the things I'm going to find out :P -- Mikael Abrahamsson email: swmike@swm.pp.se From alexandru.petrescu@gmail.com Mon Mar 11 11:40:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F72021F8E4E for ; Mon, 11 Mar 2013 11:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.692 X-Spam-Level: X-Spam-Status: No, score=-9.692 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2nQrsb3xBGF for ; Mon, 11 Mar 2013 11:40:28 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2193F21F8E4F for ; Mon, 11 Mar 2013 11:40:26 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2BIeEZi024046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Mar 2013 19:40:14 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2BIeDS5007085; Mon, 11 Mar 2013 19:40:14 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.8]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2BIe7pc011134; Mon, 11 Mar 2013 19:40:12 +0100 Message-ID: <513E24EC.9020902@gmail.com> Date: Mon, 11 Mar 2013 19:39:40 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Cameron Byrne References: <513E16C5.5090508@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 18:40:29 -0000 Le 11/03/2013 18:59, Cameron Byrne a écrit : > Alex, > > On Mon, Mar 11, 2013 at 10:39 AM, Alexandru Petrescu > wrote: >> In addition to this, (sorry for intervening, I should have said >> this to the mic), there is a need to state that this works only >> when: >> >> - this is a cellular link of kind point-to-point; it does not work >> when that cellular link is of kind 'shared link', eg with a qmi >> client, and Qualcomm chipset. >> > > There is no other 3GPP link model. There is only p2p. What i believe > you are referencing is a link model that is a specific implementation > towards tethered devices, and not within the scope of any 3GPP > standard. Well. The 3GPP links which use IEEE MAC addresses are 3GPP links or not? > We only consider 3GPP link model as described in the draft explicitly > and via reference to rfc6459. Our hope is that publishing this draft > will avoid new invention from every OEM. Well. IETF does not specify 3GPP links. It's impossible to write an RFC which does so. Cellular links exist out there, and some of them behave as some 3GPP specs expect, others dont. What would one call a cellular link of a cellular operator which does IPv6 and uses IEEE MAC addresses - are these 3GPP links? >> - the Gateway does _not_ send an NS for _any_ of the addresses >> within the /64 prefix. >> > > This is also already covered in stating that is this standard 3GPP > operation I doubt we have a common understanding of what is "3GPP operation". I doubt implementations of 3GPP links act as 3GPP specs expect them to. >> - the Gateway does not use a 'Connected' route towards that /64. >> > > I am not sure what this one is, but i assume it is covered in the > same way as above. A 'connected' route is Cisco terminology to say that there is no next-hop in the Gateway's routing table entry (linux's '*') for that prefix /64. I doubt 3GPP specs talk 'connected' route; but routers do have two different kind sof routes for a /64 - a 'connected' route, or a non-connected route (_has_ a nexthop for that /64). This is why I am surprised we refer here to 3GPP specs. > >> There may exist cellular links on which this 64share does not >> work. >> > > We believe all case for standard 3GPP links are covered. What is a standard 3GPP link? I doubt we can say so authoritatively at IETF. Besides, if one asks 3GPP specs, they'll tell that 64share is not possible. >> (and I find it strange to talk purely implementation in this draft, >> but when it comes to its inconvenients to refer to some 3GPP spec - >> it is widely known that 3GPP specs are implemented in various >> incompatible ways; the draft would better talk pure implementation >> everywhere). >> > > I have running code for scenario 3. Yes, I agree with you. I have tried the same thing on linux with an USB key. However, it seems I may have tried an additional running code which breaks at 64share - when the link is 'shared' kind. I do not care whether that link is compliant with 3GPP specs. It is a link on a cellular operator, at a cellular frequency. If one asks 3GPP specs, they'll tell that 64share is not possible. Alex > > CB >> Alex >> >> Le 11/03/2013 18:27, Cameron Byrne a écrit : >>> >>> Dave, >>> >>> Here is the quote of the current draft text. Does this >>> correctly describe the link model that the gateway does not >>> consume an address? Would you suggest a change? >>> >>> "As [RFC6459] describes, the 3GPP network assigned /64 is >>> completely dedicated to the UE and the gateway does not consume >>> any of the /64 addresses. The gateway routes the entire /64 to >>> the UE and does not perform ND or Network Unreachability >>> Detection (NUD) [RFC4861]." >>> >>> http://tools.ietf.org/html/draft-ietf-v6ops-64share-03 >>> >>> Cameron _______________________________________________ v6ops >>> mailing list v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From gert@space.net Mon Mar 11 11:42:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235D021F8E83 for ; Mon, 11 Mar 2013 11:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhsnRfkRKZU7 for ; Mon, 11 Mar 2013 11:42:23 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5BA21F8E7F for ; Mon, 11 Mar 2013 11:42:23 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 7BD9E603F8 for ; Mon, 11 Mar 2013 19:42:22 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 57B7760147 for ; Mon, 11 Mar 2013 19:42:22 +0100 (CET) Received: (qmail 69541 invoked by uid 1007); 11 Mar 2013 19:42:22 +0100 Date: Mon, 11 Mar 2013 19:42:22 +0100 From: Gert Doering To: Alexandru Petrescu Message-ID: <20130311184222.GI51699@Space.Net> References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <513E24EC.9020902@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 18:42:24 -0000 Hi, On Mon, Mar 11, 2013 at 07:39:40PM +0100, Alexandru Petrescu wrote: > The 3GPP links which use IEEE MAC addresses are 3GPP links or not? As far as I have learned, they are not 3GPP links, but 3GPP modems that pretend to be "an ethernet thingie". That's fully outside the 3GPP realm of things. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From alexandru.petrescu@gmail.com Mon Mar 11 11:52:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E74121F8EB3 for ; Mon, 11 Mar 2013 11:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.986 X-Spam-Level: X-Spam-Status: No, score=-9.986 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8duZxWd1ed6I for ; Mon, 11 Mar 2013 11:52:17 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 7E60521F8EAB for ; Mon, 11 Mar 2013 11:52:17 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2BIqFmY016798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Mar 2013 19:52:15 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2BIqFhD008780; Mon, 11 Mar 2013 19:52:15 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.8]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2BIq9nD013941; Mon, 11 Mar 2013 19:52:14 +0100 Message-ID: <513E27BD.50005@gmail.com> Date: Mon, 11 Mar 2013 19:51:41 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Gert Doering References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> In-Reply-To: <20130311184222.GI51699@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 18:52:18 -0000 Le 11/03/2013 19:42, Gert Doering a écrit : > Hi, > > On Mon, Mar 11, 2013 at 07:39:40PM +0100, Alexandru Petrescu wrote: >> The 3GPP links which use IEEE MAC addresses are 3GPP links or not? > > As far as I have learned, they are not 3GPP links, but 3GPP modems > that pretend to be "an ethernet thingie". That's fully outside the > 3GPP realm of things. But maybe in the realm of IETF? IETF already describes MAC addresses and IPv6 addresses. We are already the knees deep into thingies. The IPv6 stack (the one which uses IPv6 addresses, ND, routes, interfaces - as 64share requires) is faced to these thingies. The easiest way to clarify here would be to invent a new term 'thingie' and say when thingies are present 64share does not work. Alex > > Gert Doering -- NetMaster > From swmike@swm.pp.se Mon Mar 11 11:55:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5A921F8CA7 for ; Mon, 11 Mar 2013 11:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 S7ekmWBsylM2 for ; Mon, 11 Mar 2013 11:55:21 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id A87C421F8C99 for ; Mon, 11 Mar 2013 11:55:21 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E5C3F9C; Mon, 11 Mar 2013 19:55:20 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D8C3E9A; Mon, 11 Mar 2013 19:55:20 +0100 (CET) Date: Mon, 11 Mar 2013 19:55:20 +0100 (CET) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <513E24EC.9020902@gmail.com> Message-ID: References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 18:55:22 -0000 On Mon, 11 Mar 2013, Alexandru Petrescu wrote: > I doubt 3GPP specs talk 'connected' route; but routers do have two > different kind sof routes for a /64 - a 'connected' route, or a > non-connected route (_has_ a nexthop for that /64). The SPGW/GGSN routes the entire /64 onto the GTP tunnel. The tunnel is similar to IPIP or GRE, there is no mac header inside the tunnel. Think of it as basically a PPP interface, where it's just fine to route an entire prefix onto the p2p link. > If one asks 3GPP specs, they'll tell that 64share is not possible. Where? -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Mon Mar 11 11:58:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B09321F8CF4 for ; Mon, 11 Mar 2013 11:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xk-FR4QNK1Rt for ; Mon, 11 Mar 2013 11:58:24 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 04C6421F8CC7 for ; Mon, 11 Mar 2013 11:58:24 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4C6399C; Mon, 11 Mar 2013 19:58:23 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 418B39A; Mon, 11 Mar 2013 19:58:23 +0100 (CET) Date: Mon, 11 Mar 2013 19:58:23 +0100 (CET) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <513E27BD.50005@gmail.com> Message-ID: References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 18:58:24 -0000 On Mon, 11 Mar 2013, Alexandru Petrescu wrote: > We are already the knees deep into thingies. The IPv6 stack (the one > which uses IPv6 addresses, ND, routes, interfaces - as 64share requires) > is faced to these thingies. The USB dongle does this magic in order to emulate a MAC layer towards the OS. It doesn't need to do this, but that's one way of doing it. For Windows machines, emulating an ethernet interface with an existing driver and doing ND spoofing, injecting RA etc is just a way of interfacing with the OS. > The easiest way to clarify here would be to invent a new term 'thingie' > and say when thingies are present 64share does not work. Let's put it this way, the "thingie" you're talking about terminates the GTP tunnel and then spoofs stuff so that it looks like an ethernet segment. I can imagine that 64share doesn't work in that scenario, yes. -- Mikael Abrahamsson email: swmike@swm.pp.se From ietf@meetecho.com Mon Mar 11 12:52:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8F021F8EF5 for ; Mon, 11 Mar 2013 12:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_13=0.6] 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 kXP0wBasoVJm for ; Mon, 11 Mar 2013 12:52:47 -0700 (PDT) Received: from smtpdg3.aruba.it (smtpdg221.aruba.it [62.149.158.221]) by ietfa.amsl.com (Postfix) with ESMTP id DF76021F8EE6 for ; Mon, 11 Mar 2013 12:52:46 -0700 (PDT) Received: from meetecho ([130.129.6.44]) by smtpcmd01.ad.aruba.it with bizsmtp id AKsi1l00L0wzZHu01Kskqf; Mon, 11 Mar 2013 20:52:44 +0100 Date: Mon, 11 Mar 2013 15:52:09 -0700 (PDT) From: Meetecho Team To: v6ops@ietf.org Message-ID: <1386211.1.1363042329976.JavaMail.root@meetecho> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_19282695.1363042329950" Subject: [v6ops] V6OPS session recording available X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 19:52:49 -0000 ------=_Part_0_19282695.1363042329950 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the V6OPS WG session at IETF 86 is available at the following URL: http://ietf86.conf.meetecho.com/index.php/Recorded_Sessions#IETF86_V6OPS In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_0_19282695.1363042329950-- From alexandru.petrescu@gmail.com Mon Mar 11 13:23:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F3621F9011 for ; Mon, 11 Mar 2013 13:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.016 X-Spam-Level: X-Spam-Status: No, score=-10.016 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwqdrKiaRo5V for ; Mon, 11 Mar 2013 13:23:40 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 937B821F900F for ; Mon, 11 Mar 2013 13:23:39 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2BKNcng014629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Mar 2013 21:23:38 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2BKNbMW021349; Mon, 11 Mar 2013 21:23:38 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.8]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2BKNSPh003151; Mon, 11 Mar 2013 21:23:37 +0100 Message-ID: <513E3D21.7090905@gmail.com> Date: Mon, 11 Mar 2013 21:22:57 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Mikael Abrahamsson References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 20:23:41 -0000 Le 11/03/2013 19:55, Mikael Abrahamsson a écrit : > On Mon, 11 Mar 2013, Alexandru Petrescu wrote: > >> I doubt 3GPP specs talk 'connected' route; but routers do have two >> different kind sof routes for a /64 - a 'connected' route, or a >> non-connected route (_has_ a nexthop for that /64). > > The SPGW/GGSN routes the entire /64 onto the GTP tunnel. The tunnel > is similar to IPIP or GRE, there is no mac header inside the tunnel. > Think of it as basically a PPP interface, where it's just fine to > route an entire prefix onto the p2p link. What the CoreNetwork doess does not prevent the UE to use MAC addresses on these links. There is a distinction: CoreNetwork-IntermediateSystem-UserEquipment. The Intermediate System and the User Equipment are in the same Computer. This distinction is not agreed here. Some say this is a thingie. >> If one asks 3GPP specs, they'll tell that 64share is not possible. > > Where? I don't think there's a precise place, just a metter of interpretation. The 3GPP specs say that the /64 is for an UE. The UE is an User Equipment. 3GPP specs have no notion of a UR (User Router or so). The UE has one single interface - the 3GPP interface. But 64share needs more than one interface to work, at least one being non-3GPP (the WiFi). That's why I think 3GPP specs think that 64share is impossible. Additionnally, many operators of these 3GPP links will appreciate little the use of 64share on devices which they dont control. (i.e. use 64share on a laptop PC with linux, rather than on an operator-controlled smartphone). For these two reasons, I find strange for this document to refer to 3GPP documents to explain that 64share must work. Alex > From alexandru.petrescu@gmail.com Mon Mar 11 13:32:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82FD21F9049 for ; Mon, 11 Mar 2013 13:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOKr7b2ZeEr5 for ; Mon, 11 Mar 2013 13:32:51 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id EFAD521F9050 for ; Mon, 11 Mar 2013 13:32:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2BKWn07008897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Mar 2013 21:32:49 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2BKWnuI022340; Mon, 11 Mar 2013 21:32:49 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.8]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2BKWkn4023873; Mon, 11 Mar 2013 21:32:48 +0100 Message-ID: <513E3F4F.1010903@gmail.com> Date: Mon, 11 Mar 2013 21:32:15 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Mikael Abrahamsson References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 20:32:52 -0000 Le 11/03/2013 19:58, Mikael Abrahamsson a écrit : > On Mon, 11 Mar 2013, Alexandru Petrescu wrote: > >> We are already the knees deep into thingies. The IPv6 stack (the >> one which uses IPv6 addresses, ND, routes, interfaces - as 64share >> requires) is faced to these thingies. > > The USB dongle does this magic in order to emulate a MAC layer > towards the OS. It doesn't need to do this, but that's one way of > doing it. This is a kind effort from the USB key - it helps a lot the IPv6 stack. The stack sees the 3GPP interface just like any other Ethernet interface. The stack does not need to do wacky things like NO_ARP. This is the future of 3GPP interfaces (as opposed to old ptp addressless links). It's not only me who thinks so. Why would manufacturers of 3GPP USB keys go through the effort to ask IEEE for Organization IDs, if it were not for a belief in a technical advantage of using MAC addresses on 3GPP links. > For Windows machines, emulating an ethernet interface with an > existing driver and doing ND spoofing, injecting RA etc is just a way > of interfacing with the OS. I think that is good for Windows as well. This emulation is what the intermediate layers do to help stacks (witness other intermediate layers like in 6lowpan, header compression, 802.16/WiMax) - they are all new developments and go the way of offering an Ethernet-like interface to the IPv6 stack. >> The easiest way to clarify here would be to invent a new term >> 'thingie' and say when thingies are present 64share does not work. > > Let's put it this way, the "thingie" you're talking about terminates > the GTP tunnel and then spoofs stuff so that it looks like an > ethernet segment. I can imagine that 64share doesn't work in that > scenario, yes. Well yes, and thus the good 64share is not working with the good 64thingie. Each taken independently is a good thing, but both at the same time is not working. This should be ack'ed. Maybe one should specify the thingie to be such that it works ok with 64share... (i.e. don't send an NS for any arbitrary address within the allocated /64). (but only if one is sure that it is the thingie who sends it, not the Gateway). Alex From joelja@bogus.com Mon Mar 11 13:33:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A85C21F9068 for ; Mon, 11 Mar 2013 13:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.387 X-Spam-Level: X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 r+PRbLQOZU02 for ; Mon, 11 Mar 2013 13:33:48 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 755C021F9067 for ; Mon, 11 Mar 2013 13:33:48 -0700 (PDT) Received: from dhcp-603a.meeting.ietf.org (dhcp-603a.meeting.ietf.org [130.129.96.58]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r2BKXibv029618 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 11 Mar 2013 20:33:46 GMT (envelope-from joelja@bogus.com) Message-ID: <513E3FA8.30002@bogus.com> Date: Mon, 11 Mar 2013 16:33:44 -0400 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Alexandru Petrescu , Mikael Abrahamsson References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <513E3D21.7090905@gmail.com> In-Reply-To: <513E3D21.7090905@gmail.com> 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]); Mon, 11 Mar 2013 20:33:46 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 20:33:49 -0000 On 3/11/13 4:22 PM, Alexandru Petrescu wrote: > > > Additionnally, many operators of these 3GPP links will appreciate little > the use of 64share on devices which they dont control. (i.e. use 64share > on a laptop PC with linux, rather than on an operator-controlled > smartphone). > The policy question seems unrelated to the technical mechanism used for tethering. Doesn't really seem any different than in IPv4 except I don't need DPI to observe it. > For these two reasons, I find strange for this document to refer to 3GPP > documents to explain that 64share must work. > > Alex > > > >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From alexandru.petrescu@gmail.com Mon Mar 11 13:48:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E88D21F905C for ; Mon, 11 Mar 2013 13:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.758 X-Spam-Level: X-Spam-Status: No, score=-9.758 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAu5WGBhZyU4 for ; Mon, 11 Mar 2013 13:47:59 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 63D1C21F9044 for ; Mon, 11 Mar 2013 13:47:58 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2BKlim7004516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Mar 2013 21:47:44 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2BKlia8024126; Mon, 11 Mar 2013 21:47:44 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.8]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2BKlaff026889; Mon, 11 Mar 2013 21:47:42 +0100 Message-ID: <513E42C9.2050802@gmail.com> Date: Mon, 11 Mar 2013 21:47:05 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: joel jaeggli References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <513E3D21.7090905@gmail.com> <513E3FA8.30002@bogus.com> In-Reply-To: <513E3FA8.30002@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 20:48:00 -0000 Le 11/03/2013 21:33, joel jaeggli a écrit : > On 3/11/13 4:22 PM, Alexandru Petrescu wrote: >> >> >> Additionnally, many operators of these 3GPP links will appreciate >> little the use of 64share on devices which they dont control. >> (i.e. use 64share on a laptop PC with linux, rather than on an >> operator-controlled smartphone). >> > The policy question seems unrelated to the technical mechanism used > for tethering. If it were not, then DHCPv6-PD for Mobile Routers would be correctly specified at 3GPP, and it would be at least in test deployment phases. (AFAIK, DHCPv6-PD is specified in 3GPP but for purposes which cant make 'tethering' - to me that's on purpose, policy). > Doesn't really seem any different than in IPv4 except I don't need > DPI to observe it. In IPv4 there is a unique NAT mechanism, whereas here a number of options are on the table: NPT, 64share, DHCPv6-PD. None of these is in the 3GPP specs AFAIK. I wonder why if it were not for policy... That said, I also agree that one may leave policy aside and implement whatever one likes to - which is especially true when inter-operability may not be at stake - which is the case here: we only talk this smartphone, which does not need to be interoperable with anything, because we assume 3GPP specs forbid the impossible thingie cases... which make 64share bound to 3GPP... Alex >> For these two reasons, I find strange for this document to refer >> to 3GPP documents to explain that 64share must work. >> >> Alex >> >> >> >>> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> > > > From tsavo.stds@gmail.com Mon Mar 11 13:52:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF33421F9122 for ; Mon, 11 Mar 2013 13:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 bd9hMI3hEXJX for ; Mon, 11 Mar 2013 13:52:34 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 41DAA21F911F for ; Mon, 11 Mar 2013 13:52:34 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr12so5276786wgb.11 for ; Mon, 11 Mar 2013 13:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CCx5i+S+JndTSWwQ2uYEJgIwkmbF+F3DepSeEgMDAJs=; b=T05eXHDt4Nx6VIlo9ZB2Xw+JV8oGjfVXSCNMmjpSctOhK2Obi4JLY3+FWbS4j8TxD/ C+pAODxg/9DxTFkZydadI4VfF4eDr8xZq1Hye72WTKIhFoqKPU0UXd+pp3IXfVX3Ow0w BZQkIOtuX+Kj/uDMsUQNn0g5+wxncrBxwmNRW7IhfiJQF3bXo8FJwszm59/vupiDym7c odPRLeSwgTQ6jQr/beK4Xhyuf+OfFa34/0ZicMVIpsDk2kNW/SLrpOiNMYrY9tredL/q Vsbjmy0wnrQGTKBPefJGuvICXIukzcn6T9Fvk24vEvQOJgudipmITjRIvqUjluzUf2OX 9WYQ== MIME-Version: 1.0 X-Received: by 10.194.120.169 with SMTP id ld9mr22091941wjb.24.1363035153390; Mon, 11 Mar 2013 13:52:33 -0700 (PDT) Received: by 10.194.152.71 with HTTP; Mon, 11 Mar 2013 13:52:33 -0700 (PDT) In-Reply-To: References: <510F7FCC.5040705@viagenie.ca> <510FC324.7090908@gmail.com> <513E18CE.3080808@gmail.com> <513E1D61.20308@fud.no> Date: Mon, 11 Mar 2013 16:52:33 -0400 Message-ID: From: Teemu Savolainen To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=e89a8f642c142260b904d7ac5ab8 Cc: v6ops@ietf.org Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 20:52:36 -0000 --e89a8f642c142260b904d7ac5ab8 Content-Type: text/plain; charset=ISO-8859-1 There is no handover specified for a case where UE has first IPv4v6 in LTE and then handovers to 2G/3G where IPv4v6 is not supported. 3GPP looked at that scenario, but there was no reasonable way to specify that (for splitting a connection to two, and then merging back when handing over from 2G/3G to LTE:-). That is the main reason, afaik, why status codes for "single-stack bearers only" were created. I.e. operator can deploy LTE that would support IPv4v6, and can even provision UEs to ask for IPv4v6, but until 2G/3G is upgraded the PGW is configured to force UEs to fallback to parallel IPv4 and IPv6 until the day 2G and 3G have been upgraded to support IPv4v6. Best regards, Teemu 2013/3/11 Mikael Abrahamsson > >> I know of several 3G networks that support IPv6 in production for their >> customers, but I don't know if any of those also operate LTE networks >> and if so whether or not the handover between the network types works. >> > > One way is to go IPv4v6 in LTE and IPv4+IPv6 (dual bearers) in 2G/3G. I > don't know how well this works in real life. This is one of the things I'm > going to find out :P > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > ______________________________**_________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/**listinfo/v6ops > --e89a8f642c142260b904d7ac5ab8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There is no handover specified for a case where UE has first IPv4v6 in LTE = and then handovers to 2G/3G where IPv4v6 is not supported. 3GPP looked at t= hat scenario, but there was no reasonable way to specify that (for splittin= g a connection to two, and then merging back when handing over from 2G/3G t= o LTE:-).=A0

That is the main reason, afaik, why status codes for "s= ingle-stack bearers only" were created. I.e. operator can deploy LTE t= hat would support IPv4v6, and can even provision UEs to ask for IPv4v6, but= until 2G/3G is upgraded the PGW is configured to force UEs to fallback to = parallel IPv4 and IPv6 until the day 2G and 3G have been upgraded to suppor= t IPv4v6.

Best regards,

Teemu

2013/3/11 Mikael Abrahamsson <s= wmike@swm.pp.se>

I know of several 3G networks that support IPv6 in production for their
customers, but I don't know if any of those also operate LTE networks and if so whether or not the handover between the network types works.

One way is to go IPv4v6 in LTE and IPv4+IPv6 (dual bearers) in 2G/3G. I don= 't know how well this works in real life. This is one of the things I&#= 39;m going to find out :P


--
Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--e89a8f642c142260b904d7ac5ab8-- From cb.list6@gmail.com Mon Mar 11 13:52:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C1F21F912A for ; Mon, 11 Mar 2013 13:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hU11-WF73BHl for ; Mon, 11 Mar 2013 13:52:54 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 146A521F9129 for ; Mon, 11 Mar 2013 13:52:53 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hm14so1320827wib.3 for ; Mon, 11 Mar 2013 13:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=qHNyp61xuMIuivWGYCPy616xBKlC+RDa31iKfuUNMEs=; b=oypb9c9Wfu3vFAhc7LkmlxGWKT1kWNVrDXlFeeeq3zCREgYhygmudr+g/Xm9wk1sfA +eeUQY/cf9YxtTYL41zXXxuLxBM5kPkGtm4X84+V1avnMoDXB+NPZoKdX/JKGhT2s2zj ju147FOUPMZ1XcvBNcuit0RmiQD3yFvUP/vkza+o23qO+Yr8utBlzU90xARu6Tfojgoi M8Bq2XkO3sM2Rf2pCHtVjTJnp03ttp+geQJQnXKEz1tbBFwEqGcPs5BkCe2zYZJJpgfT XpV/aJvzCFGPcHFmyMMnRakAil6q0QGN3WlH0ZLLdj6AJq3QEdW1tjUBUJi+EADDdb5Y 9Eyg== MIME-Version: 1.0 X-Received: by 10.180.105.99 with SMTP id gl3mr15477401wib.22.1363035173242; Mon, 11 Mar 2013 13:52:53 -0700 (PDT) Received: by 10.194.20.35 with HTTP; Mon, 11 Mar 2013 13:52:53 -0700 (PDT) In-Reply-To: <513E3F4F.1010903@gmail.com> References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> Date: Mon, 11 Mar 2013 13:52:53 -0700 Message-ID: From: Cameron Byrne To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 20:52:55 -0000 On Mon, Mar 11, 2013 at 1:32 PM, Alexandru Petrescu wrote: > Le 11/03/2013 19:58, Mikael Abrahamsson a =E9crit : > >> On Mon, 11 Mar 2013, Alexandru Petrescu wrote: >> >>> We are already the knees deep into thingies. The IPv6 stack (the >>> one which uses IPv6 addresses, ND, routes, interfaces - as 64share >>> requires) is faced to these thingies. >> >> >> The USB dongle does this magic in order to emulate a MAC layer >> towards the OS. It doesn't need to do this, but that's one way of >> doing it. > > > This is a kind effort from the USB key - it helps a lot the IPv6 > stack. The stack sees the 3GPP interface just like any other Ethernet > interface. The stack does not need to do wacky things like NO_ARP. > > This is the future of 3GPP interfaces (as opposed to old ptp addressless > links). > can you cite this from a 3GPP document ? Or is this your own idea? I believe what you are seeing is (3gpp network)---standard 3gpp p2p link ---- (USB stick (proprietary trickery) )---LAN--- IMHO, your observations about the USB stick are not relevant to the 3GPP network or the related standards. > It's not only me who thinks so. Why would manufacturers of 3GPP USB > keys go through the effort to ask IEEE for Organization IDs, if it were > not for a belief in a technical advantage of using MAC addresses on 3GPP > links. > At the end of the day, i think these efforts are happening in a proprietary way because they needed to fill a space on ipv6 tethering is to work. draft-ietf-v6ops-64share-03 exists to fill this space with an open approach that is known to work. The idea being that folks can cite this approach instead of everyone building their own. All that said, the draft-ietf-v6ops-64share-03 scopes the solution with specific text about p2p links and direct pointers to the known 3GPP model. Do you have an issue with this text as written with the current scope? If so, do you have a text suggestion? I would like to avoid broadening the scope from what the current text has set, because it believe that would be an impossible problem to solve. CB > >> For Windows machines, emulating an ethernet interface with an >> existing driver and doing ND spoofing, injecting RA etc is just a way >> of interfacing with the OS. > > > I think that is good for Windows as well. > > This emulation is what the intermediate layers do to help stacks > (witness other intermediate layers like in 6lowpan, header compression, > 802.16/WiMax) - they are all new developments and go the way of offering > an Ethernet-like interface to the IPv6 stack. > > >>> The easiest way to clarify here would be to invent a new term >>> 'thingie' and say when thingies are present 64share does not work. >> >> >> Let's put it this way, the "thingie" you're talking about terminates >> the GTP tunnel and then spoofs stuff so that it looks like an >> ethernet segment. I can imagine that 64share doesn't work in that >> scenario, yes. > > > Well yes, and thus the good 64share is not working with the good > 64thingie. Each taken independently is a good thing, but both at the > same time is not working. This should be ack'ed. > > Maybe one should specify the thingie to be such that it works ok with > 64share... (i.e. don't send an NS for any arbitrary address within the > allocated /64). (but only if one is sure that it is the thingie who > sends it, not the Gateway). > > Alex > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From alexandru.petrescu@gmail.com Mon Mar 11 14:21:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867B621F8FFD for ; Mon, 11 Mar 2013 14:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.749 X-Spam-Level: X-Spam-Status: No, score=-9.749 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6twAUL9d3mg7 for ; Mon, 11 Mar 2013 14:21:29 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 06ADE21F8FF3 for ; Mon, 11 Mar 2013 14:21:28 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2BLLHRx028458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Mar 2013 22:21:17 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2BLLHsp028025; Mon, 11 Mar 2013 22:21:17 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.8]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2BLL9Ms000893; Mon, 11 Mar 2013 22:21:16 +0100 Message-ID: <513E4AA4.5030404@gmail.com> Date: Mon, 11 Mar 2013 22:20:36 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Cameron Byrne References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 21:21:30 -0000 Le 11/03/2013 21:52, Cameron Byrne a écrit : > On Mon, Mar 11, 2013 at 1:32 PM, Alexandru Petrescu > wrote: >> Le 11/03/2013 19:58, Mikael Abrahamsson a écrit : >> >>> On Mon, 11 Mar 2013, Alexandru Petrescu wrote: >>> >>>> We are already the knees deep into thingies. The IPv6 stack >>>> (the one which uses IPv6 addresses, ND, routes, interfaces - as >>>> 64share requires) is faced to these thingies. >>> >>> >>> The USB dongle does this magic in order to emulate a MAC layer >>> towards the OS. It doesn't need to do this, but that's one way >>> of doing it. >> >> >> This is a kind effort from the USB key - it helps a lot the IPv6 >> stack. The stack sees the 3GPP interface just like any other >> Ethernet interface. The stack does not need to do wacky things >> like NO_ARP. >> >> This is the future of 3GPP interfaces (as opposed to old ptp >> addressless links). >> > > can you cite this from a 3GPP document ? Or is this your own idea? It is my own speculation, after seeing the developments of IEEE 802.16 and IETF 6lowpan. These developments of intermediate layers were beneficial to IP stacks, at a time when 3GPP was the only cellular and Bluetooth was mainly ppp/ptp. > I believe what you are seeing is (3gpp network)---standard 3gpp p2p > link ---- (USB stick (proprietary trickery) )---LAN--- Yes and no. I see: (3gpp network)---standard 3gpp p2p link ---- (USB stick (proprietary trickery) )---(Computer-Running-IP-stack)----(WiFi stick)-----LAN--- > IMHO, your observations about the USB stick are not relevant to the > 3GPP network or the related standards. But they are relevant to IPv6 stack, arent they? This is what the IPv6 stack on the Computer sees - the 'thingie'. The thingie is not specified by anybody, it's Proprietary, it brings some benefits when 64share is not there, but may break 64share. >> It's not only me who thinks so. Why would manufacturers of 3GPP >> USB keys go through the effort to ask IEEE for Organization IDs, if >> it were not for a belief in a technical advantage of using MAC >> addresses on 3GPP links. >> > > At the end of the day, i think these efforts are happening in a > proprietary way because they needed to fill a space on ipv6 > tethering is to work. But IPv6 tethering works _only_ if these proprietary means dont get in the way. > draft-ietf-v6ops-64share-03 exists to fill this space with an open > approach that is known to work. The idea being that folks can cite > this approach instead of everyone building their own. 64share and proprietary IP proxies on USB keys are not competing in their goals. One cant suggest a USB key manufacturer to implement 64share rather than the ND-proxying. The ND-proxying (if that's what it does) helps other goals (e.g. allow the stack to use its ND multicast unmodified, others). The 64share is not helping at all to run ND multicast on 3GPP links. > All that said, the draft-ietf-v6ops-64share-03 scopes the solution > with specific text about p2p links and direct pointers to the known > 3GPP model. Cameron - the draft is a pure experimentation effort, which is very good. It should be as experimental about 3GPP specs as well, not just citing them. This draft and no 3GPP specs and no discussion on this email list describe what do IEEE-legitimate MAC addresses are doing on these 3GPP links. They are there, are used, but are not reported. Rather we redirect to 3GPP specs... > Do you have an issue with this text as written with the current > scope? If so, do you have a text suggestion? I would like to avoid > broadening the scope from what the current text has set, because it > believe that would be an impossible problem to solve. Right, no, not my intention to say this is an impossible problem to solve, nor to broaden the scope (I have no solution for this). As I suggested at the beginning of the discussion, the draft should ack that there are cases (like when the UE receives a NS for an IPv6 address within the allocated /64, when MAC addresses may be used on 3GPP links, and when QMI may be used, and when the route at the Gateway be "Connected") where 64share is not working. Just ack it, that's all. As for suggesting text - yes I could suggest text, here on the list - would you like me to? Alex > > CB > >> >>> For Windows machines, emulating an ethernet interface with an >>> existing driver and doing ND spoofing, injecting RA etc is just a >>> way of interfacing with the OS. >> >> >> I think that is good for Windows as well. >> >> This emulation is what the intermediate layers do to help stacks >> (witness other intermediate layers like in 6lowpan, header >> compression, 802.16/WiMax) - they are all new developments and go >> the way of offering an Ethernet-like interface to the IPv6 stack. >> >> >>>> The easiest way to clarify here would be to invent a new term >>>> 'thingie' and say when thingies are present 64share does not >>>> work. >>> >>> >>> Let's put it this way, the "thingie" you're talking about >>> terminates the GTP tunnel and then spoofs stuff so that it looks >>> like an ethernet segment. I can imagine that 64share doesn't >>> work in that scenario, yes. >> >> >> Well yes, and thus the good 64share is not working with the good >> 64thingie. Each taken independently is a good thing, but both at >> the same time is not working. This should be ack'ed. >> >> Maybe one should specify the thingie to be such that it works ok >> with 64share... (i.e. don't send an NS for any arbitrary address >> within the allocated /64). (but only if one is sure that it is the >> thingie who sends it, not the Gateway). >> >> Alex >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From philip_matthews@magma.ca Mon Mar 11 14:34:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C98021F8CAD for ; Mon, 11 Mar 2013 14:34:36 -0700 (PDT) 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_13=0.6] 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 FzD6awRej0+l for ; Mon, 11 Mar 2013 14:34:35 -0700 (PDT) Received: from mail-05.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id 359CF21F8BDD for ; Mon, 11 Mar 2013 14:34:34 -0700 (PDT) Received: from dhcp-1783.meeting.ietf.org ([130.129.23.131]) by mail-05.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1UFAMb-0004dP-2E; Mon, 11 Mar 2013 17:34:34 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923041F47A432@PRVPEXVS15.corp.twcable.com> Date: Mon, 11 Mar 2013 17:34:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <34A4EB40-BEAE-4849-A785-E59F41AEA1EC@magma.ca> References: <2671C6CDFBB59E47B64C10B3E0BD5923041F47A432@PRVPEXVS15.corp.twcable.com> To: GangChen X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - dhcp-1783.meeting.ietf.org [130.129.23.131] Cc: v6ops Subject: Re: [v6ops] comments for draft-ietf-v6ops-nat64-experience [was draft-ietf-v6ops-nat64-experience WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 21:34:36 -0000 I agree with Wes's comments (below), so I won't repeat them. I will = simply add a few additional comments of my own: 3.1 This section makes the comment "It is advantageous from the vantage-point of = troubleshooting and traffic engineering to carry the IPv6 traffic = natively for as long as possible within an access network and translate = only near the edge." The question of where to place the NAT64 (near the subscriber, near = peering routers, somewhere in the middle) is an interesting one. I = would like to see a lot more discussion on this topic. The document = makes some brief comments on why placing it near peering routers might = be useful, but I am sure more can be said. I can also see cons for = placing it there: as one example, this would make geo-location based on = IPv4 addresses rather inaccurate. Furthermore, if one has multiple NAT64 = boxes located near different peering routers, then might mean some flows = went through one NAT64 box, while others went though a different NAT64 = box -- not a good situation. =20 3.3 I don't understand what is meant by "online" vs. "offline" in this = section. It would be good to properly define these, or give a = reference to a document that defines them. Furthermore, the bullet points in this section seem somewhat random = --- if there is some cohesive picture which the authors are trying to = present, then I don't see it. - Philip =20 On 2013-03-06, at 14:29 , George, Wes wrote: > Apologies for not getting it out before the conclusion of WGLC, but it = seems that the authors are still looking for comments before revising = it, so I've reviewed this document. >=20 > Introduction, third paragraph. I think this sentence is out of place = and should be removed: > "There is also the troublesome trend of access > network providers squatting on IPv4 address space that they do not > own." > It really doesn't tie into the rest of that paragraph, nor does it = relate overmuch to the reasons for deploying NAT64. Carriers that need = to support customers that have end devices which still require IPv4 = connectivity are going to do so by whatever means they feel appropriate, = and NAT64 doesn't solve that problem. NAT64 solves the problem of an SP = that has the means to force all (or a large subset of) devices to = IPv6-only but still needs a way for those users to reach IPv4-only = content and services. >=20 > 3.2 - this section is currently pretty weak. Are there any references = to the different methods of HA in NAT64 that you could provide, either = via vendor implementation or in the standards themseles? Is the = assertion that most traffic is short-lived and therefore cold standby is = ok backed up by any production or lab testing demonstrating the user = experience for NAT64? It needs to discuss what assumptions you made = about how short-lived is short-lived, how long a cold-standby failover = should take before it becomes an unacceptable impact to customers, and = whether there are certain types of traffic more sensitive to this = problem (TCP vs UDP, streaming vs surfing, etc). It may also need to = discuss true cold standby vs warm standby, because in most cases, I = think what you're referring to as cold standby is more like warm standby = (online at all times, but not actively exchanging all state = information). This likely also ties into section 3.4, since the choice = here will affect the quali > ty of experience. I would like to see more effort to tie the two ideas = together. IOW, if you are expecting that this will be a second-class = service that only covers the major traffic (http, etc) then it might be = ok for there to be cold standby and session resets. If you're trying to = make this a first-class alternative (within the limits of the technology = of course), then session resets might not be acceptable. >=20 > I would also move 3.5 so that it is immediately after 3.2. These are = both talking about similar areas (scale and resiliency) and make more = sense when more closely tied together, especially when bolstered with = some discussion of how load balancers are used for resiliency and scale = for normal use, and how that might be different for NAT64/FE use. >=20 > 3.3 - there have been a couple of drafts floating around trying to = build a NAT/CGN mib, whether generic or specific to NAT64. They haven't = really gone anywhere. Might be useful to discuss whether the lack of a = mib is making this harder, or if it doesn't matter. >=20 > 3.6 - I'm not following the explanation of the MTU issues here. It = seems to assert that IPv6 can't deal with packets smaller than 1280, = which really isn't true, it just requires end host to end host = fragmentation. Therefore, IMO part of a NAT64 device's job is going to = be to manage the PTB messages and MTU discovery between the protocols = and act as the IPv6 destination end host so that it can facilitate any = required IPv6 endhost-to-endhost fragmentation if the required MTU is = below 1280 - it basically has to detect the outgoing MTU and enforce it = back to its end host. It's a lot of state to maintain probably, but = doable. This is also a corner case, because IPv4 allows almost all = packets (except those with the DF bit set) to be fragmented by = middleboxes if their MTU is smaller than the offered packet, making it = largely transparent to the end hosts. The IPv6 host can send whatever = size packet they want, and the IPv4 side will just fragment as necessary = unless the NAT64 box is d > oing something dumb like setting DF on the outgoing IPv4 packets it is = generating. > Is this meant to discuss the situation where a NAT64 box receives IPv4 = packets smaller than 1280 and then has to send them to the IPv6 host? >=20 > 4 - I'm not certain figure 2 is helpful in its current form. I had to = look 3 times before I figured out what was even different from figure 1, = and the addition of one word doesn't really require a new diagram. > Honestly, this entire section repeats a lot of the content from the = previous sections, and I think the draft would be much tighter and = readable if you simply integrated the little bit of additional = information into the previous sections, either as subsections or just as = part of the overall discussion. I don't think it adds much value as a = standalone section. Generally, the drafts that you reference here do a = better job of discussing the use of a loadbalancer as a method to = provide IPv6 to a mostly IPv4-only backend and vice versa. >=20 > Regarding Randy's comments on e2e/smart edge/stupid core and the = interaction with NAT64, I think they're mostly incompatible. While NAT64 = makes running an IPv6-only network more possible while we wait for = ubiquitous IPv6 deployment on the content/service side, it's still = fundamentally a NAT, a stateful box in the middle that interferes with = end to end communications and may require ALGs for full function. It = also still requires investment in those boxes in the middle, which means = that you're sort of stuck with them until they depreciate, unless you = can repurpose them for some other use. The only thing you could do here = is make the point that in order to keep the intelligence at the edge, = NAT64/DNS64 implementations should be pushed as far down into the = network as possible. But even then there are other tradeoffs on = placement to consider, such as the scale of an individual NAT64 box or = the number of devices that would be required by a more decentralized = placement, or network d > esign and topology (as you have alluded to with the mobile examples). >=20 > By the ruler that Randy was proposing in his slides, this is less bad = because at least it sets up a network to be actually running IPv6 = instead of extending IPv4, and only does IPv4 to compensate for those = who haven't deployed it yet. But it's still limited to places that are = unencumbered by a need to continue supporting legacy IPv4 devices, which = limits its applicability in the Access Provider community. >=20 > Nits: 3.1 has a number of spelling errors >=20 > Wes George >=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf >> Of GangChen >> Sent: Tuesday, March 05, 2013 4:02 AM >> To: v6ops >> Subject: [v6ops] comments for draft-ietf-v6ops-nat64-experience [was >> draft-ietf-v6ops-nat64-experience WGLC] >>=20 >> wg, >>=20 >> There are offline comments from Randy Bush suggest to consolidate >> NAT64 statements with the principle of e2e preservation and "smart = edge >> & stupid core". It was presented at = http://archive.psg.com/120229.apops- >> v4-life-extension.pdf >>=20 >> Personally, I think it's worth to add some texts of those principle = as a >> part of NAT64 deployment considerations, since it would beneficial to >> advance IPv6 deployment. >>=20 >> I would like to seek wg opinions on this point or futher comments >> regarding to http://tools.ietf.org/html/draft-ietf-v6ops-nat64- >> experience. >>=20 >> Please take the time to review the document in order to make sure the >> draft doesn't lose anything at next update. >>=20 >> Best Regards >>=20 >> Gang >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > This E-mail and any of its attachments 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 are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From owen@delong.com Mon Mar 11 14:36:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CDF21F901F for ; Mon, 11 Mar 2013 14:36:18 -0700 (PDT) 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_33=0.6] 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 EJSR4ZxBmeVw for ; Mon, 11 Mar 2013 14:36:18 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 938E521F8CAD for ; Mon, 11 Mar 2013 14:36:13 -0700 (PDT) Received: from [10.255.251.216] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2BLWQh4021132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Mar 2013 14:32:27 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2BLWQh4021132 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363037547; bh=+PtXJXG/1/QHRLiJtml+Kz9ysxY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=SRvruwsSQFKHxrcGSqCQh3ARhH5XEvop0xjczAsZTsGwC3Ti9OTGfQ16NJbrYtHWl v0g/DyYuAmLKilYyZLyVxL9rU+RjIzaoLo29J/zX/9ABvK7xhSCTwgK3s/V72hg9GU Wma2i1wjCsFnhcYZdIYman4LvTteD659tG5qIhUI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <513CDB1F.8040806@scea.com> Date: Mon, 11 Mar 2013 14:32:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <127F090C-8204-4131-8922-382AEC060720@delong.com> References: <2D09D61DDFA73D4C884805CC7865E6113025BF29@GAALPA1MSGUSR9L.ITServices.sbc.com> <5137AABD.1050401@dougbarton.us> <5137AEE8.2050308@dougbarton.us> <8D23D4052ABE7A4490E77B1A012B6307474B1C9B@mbx-01.win.nominum.com> <5137BA3E.4020604@dougbarton.us> <1362790998.58259.YahooMailNeo@web142504.mail.bf1.yahoo.com> <513A958B.7070104@d! ougbarton.us> <93C8132C-F72E-4BF0-98DD-2D715240445C@delong.com> <513B3D5C.3060707@gmail.com> <6D4AB912-3884-46EA-BC12-D800FA6FBAC8@delong.com> <8D23D4052ABE7A4490E77B1A012B6307474B8DD6@mbx-01.win.nominum.c om> <513B6205.7080802@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307474B8FAC@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474B926E@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474B99E0@mbx-01.win.nominum! . com> <513CDB1F.8040806@scea.com> To: Tom Perrine X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 11 Mar 2013 14:32:27 -0700 (PDT) Cc: v6ops@ietf.org Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 21:36:19 -0000 On Mar 10, 2013, at 12:12 PM, Tom Perrine wrote: > On 3/10/13 5:20 AM, Ted Lemon wrote: >> On Mar 10, 2013, at 3:52 AM, Owen DeLong wrote: >>> If they can fit into the /56, the additional renumbering effort = mostly amounts to more iterations of global search and replace because = you may need to d each /64 instead of the whole /48 in one shot. = However, this really shouldn't be an issue for an SME as I think ISPs = are still planning on /48s for business. It's just residential that they = want to shaft for unknown reasons, to the best of my knowledge. >> Yup. >=20 > I suspect that this is a way to differentiate the lowest level of = service from a premium level of service, in order to push home users to = move to a higher-cost option. >=20 > Much like US cable providers push residential users to "business = class" in order to get static IP assignments. >=20 Conduct which I certainly don't think should be encouraged in an IETF = document. Owen From cb.list6@gmail.com Mon Mar 11 14:36:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2311621F8CAD for ; Mon, 11 Mar 2013 14:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.771, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 dlByI-b8yzLW for ; Mon, 11 Mar 2013 14:36:18 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB6721F9005 for ; Mon, 11 Mar 2013 14:36:13 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id dr13so5316041wgb.26 for ; Mon, 11 Mar 2013 14:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=r1Px9VYTZNgg7l59JfVKb+v+PRYhfD+eKFAnIzcpy3E=; b=D2SBq43LGUXRRR3vg6DPUTuS4qUOXJF39bKW3L86ioZ+IVugs3iuZTb5OS+42b/EuV 6ffUBzODtF6+uJjMFWsJ/234dPRmZ+SHT7nx9VVZ3e71hkYiyGlRJQXEHr++SU4MLNs7 adIch1kwlhYgoamvYda/7Sz58q+dKXGBD4C3Mu6p9WiMy2/M4LQ/MjktwZ/Z3+RmMSIb V2M/TUwICV1Fq6XhmHdW1vr0i6FP9o4z4ZpJe92nOlG5NiIfgAeFI57Jp6DJP6/H35dy Mnh64oC6i9nOnzJ2PgNIYQnZ1ayPSOdgMdMNx+2KVqGjkxYkau7vOmHxY0WWWe08G2sQ ubxQ== MIME-Version: 1.0 X-Received: by 10.194.123.103 with SMTP id lz7mr9328077wjb.10.1363037773212; Mon, 11 Mar 2013 14:36:13 -0700 (PDT) Received: by 10.194.20.35 with HTTP; Mon, 11 Mar 2013 14:36:13 -0700 (PDT) In-Reply-To: <513E4AA4.5030404@gmail.com> References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <513E4AA4.5030404@gmail.com> Date: Mon, 11 Mar 2013 14:36:13 -0700 Message-ID: From: Cameron Byrne To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 21:36:19 -0000 On Mon, Mar 11, 2013 at 2:20 PM, Alexandru Petrescu wrote: > Le 11/03/2013 21:52, Cameron Byrne a =E9crit : > >> On Mon, Mar 11, 2013 at 1:32 PM, Alexandru Petrescu >> wrote: >>> >>> Le 11/03/2013 19:58, Mikael Abrahamsson a =E9crit : >>> >>>> On Mon, 11 Mar 2013, Alexandru Petrescu wrote: >>>> >>>>> We are already the knees deep into thingies. The IPv6 stack >>>>> (the one which uses IPv6 addresses, ND, routes, interfaces - as >>>>> 64share requires) is faced to these thingies. >>>> >>>> >>>> >>>> The USB dongle does this magic in order to emulate a MAC layer >>>> towards the OS. It doesn't need to do this, but that's one way >>>> of doing it. >>> >>> >>> >>> This is a kind effort from the USB key - it helps a lot the IPv6 >>> stack. The stack sees the 3GPP interface just like any other >>> Ethernet interface. The stack does not need to do wacky things >>> like NO_ARP. >>> >>> This is the future of 3GPP interfaces (as opposed to old ptp >>> addressless links). >>> >> >> can you cite this from a 3GPP document ? Or is this your own idea? > > > It is my own speculation, after seeing the developments of IEEE 802.16 > and IETF 6lowpan. These developments of intermediate layers were > beneficial to IP stacks, at a time when 3GPP was the only cellular and > Bluetooth was mainly ppp/ptp. > > >> I believe what you are seeing is (3gpp network)---standard 3gpp p2p >> link ---- (USB stick (proprietary trickery) )---LAN--- > > > Yes and no. I see: > > (3gpp network)---standard 3gpp p2p link ---- (USB stick (proprietary > trickery) )---(Computer-Running-IP-stack)----(WiFi stick)-----LAN--- > > >> IMHO, your observations about the USB stick are not relevant to the >> 3GPP network or the related standards. > > > But they are relevant to IPv6 stack, arent they? This is what the IPv6 > stack on the Computer sees - the 'thingie'. The thingie is not > specified by anybody, it's Proprietary, it brings some benefits when > 64share is not there, but may break 64share. > My idea is that 64share and "thingie" are mutually exclusive. > >>> It's not only me who thinks so. Why would manufacturers of 3GPP >>> USB keys go through the effort to ask IEEE for Organization IDs, if >>> it were not for a belief in a technical advantage of using MAC >>> addresses on 3GPP links. >>> >> >> At the end of the day, i think these efforts are happening in a >> proprietary way because they needed to fill a space on ipv6 >> tethering is to work. > > > But IPv6 tethering works _only_ if these proprietary means dont get in > the way. > > >> draft-ietf-v6ops-64share-03 exists to fill this space with an open >> approach that is known to work. The idea being that folks can cite >> this approach instead of everyone building their own. > > > 64share and proprietary IP proxies on USB keys are not competing in > their goals. > > One cant suggest a USB key manufacturer to implement 64share rather than > the ND-proxying. The ND-proxying (if that's what it does) helps other > goals (e.g. allow the stack to use its ND multicast unmodified, others). > The 64share is not helping at all to run ND multicast on 3GPP links. > > >> All that said, the draft-ietf-v6ops-64share-03 scopes the solution >> with specific text about p2p links and direct pointers to the known >> 3GPP model. > > > Cameron - the draft is a pure experimentation effort, which is very > good. It should be as experimental about 3GPP specs as well, not just > citing them. > > This draft and no 3GPP specs and no discussion on this email list > describe what do IEEE-legitimate MAC addresses are doing on these 3GPP > links. They are there, are used, but are not reported. Rather we > redirect to 3GPP specs... > > >> Do you have an issue with this text as written with the current >> scope? If so, do you have a text suggestion? I would like to avoid >> broadening the scope from what the current text has set, because it >> believe that would be an impossible problem to solve. > > > Right, no, not my intention to say this is an impossible problem to > solve, nor to broaden the scope (I have no solution for this). > > As I suggested at the beginning of the discussion, the draft should ack > that there are cases (like when the UE receives a NS for an IPv6 address > within the allocated /64, when MAC addresses may be used on 3GPP links, > and when QMI may be used, and when the route at the Gateway be > "Connected") where 64share is not working. Just ack it, that's all. > > As for suggesting text - yes I could suggest text, here on the list - > would you like me to? > Yes. I would be especially in favor or text that tunes the 64share scope to be mutually exclusive to ( QMI | Thingie | Proprietary Trickery). I think the current scope makes this clear already in that we clearly describe a p2p link with a /64 that is dedicated tot he UE only.... but i acknowledge that QMI and related thingies are out there, and if we can more clearly state that they are out of scope, that would be great. CB > Alex > > >> >> CB >> >>> >>>> For Windows machines, emulating an ethernet interface with an >>>> existing driver and doing ND spoofing, injecting RA etc is just a >>>> way of interfacing with the OS. >>> >>> >>> >>> I think that is good for Windows as well. >>> >>> This emulation is what the intermediate layers do to help stacks >>> (witness other intermediate layers like in 6lowpan, header >>> compression, 802.16/WiMax) - they are all new developments and go >>> the way of offering an Ethernet-like interface to the IPv6 stack. >>> >>> >>>>> The easiest way to clarify here would be to invent a new term >>>>> 'thingie' and say when thingies are present 64share does not >>>>> work. >>>> >>>> >>>> >>>> Let's put it this way, the "thingie" you're talking about >>>> terminates the GTP tunnel and then spoofs stuff so that it looks >>>> like an ethernet segment. I can imagine that 64share doesn't >>>> work in that scenario, yes. >>> >>> >>> >>> Well yes, and thus the good 64share is not working with the good >>> 64thingie. Each taken independently is a good thing, but both at >>> the same time is not working. This should be ack'ed. >>> >>> Maybe one should specify the thingie to be such that it works ok >>> with 64share... (i.e. don't send an NS for any arbitrary address >>> within the allocated /64). (but only if one is sure that it is the >>> thingie who sends it, not the Gateway). >>> >>> Alex >>> >>> >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> >> > > From gert@space.net Mon Mar 11 14:53:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E47421F9098 for ; Mon, 11 Mar 2013 14:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 WPySjFmpZ3FR for ; Mon, 11 Mar 2013 14:53:29 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 97ADA21F9034 for ; Mon, 11 Mar 2013 14:53:28 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id F30E560470 for ; Mon, 11 Mar 2013 22:53:27 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id D3E9F603F8 for ; Mon, 11 Mar 2013 22:53:27 +0100 (CET) Received: (qmail 54960 invoked by uid 1007); 11 Mar 2013 22:53:27 +0100 Date: Mon, 11 Mar 2013 22:53:27 +0100 From: Gert Doering To: Alexandru Petrescu Message-ID: <20130311215327.GK51699@Space.Net> References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3UuNU5B2zxNW6aAx" Content-Disposition: inline In-Reply-To: <513E3F4F.1010903@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 21:53:30 -0000 --3UuNU5B2zxNW6aAx Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Mar 11, 2013 at 09:32:15PM +0100, Alexandru Petrescu wrote: > Le 11/03/2013 19:58, Mikael Abrahamsson a =E9crit : > > On Mon, 11 Mar 2013, Alexandru Petrescu wrote: > > > >> We are already the knees deep into thingies. The IPv6 stack (the > >> one which uses IPv6 addresses, ND, routes, interfaces - as 64share > >> requires) is faced to these thingies. > > > > The USB dongle does this magic in order to emulate a MAC layer > > towards the OS. It doesn't need to do this, but that's one way of > > doing it. >=20 > This is a kind effort from the USB key - it helps a lot the IPv6 > stack. The stack sees the 3GPP interface just like any other Ethernet > interface. The stack does not need to do wacky things like NO_ARP. I'm not sure why you think that this is helpful or kind - it just=20 complicates things, while PPP interfaces have been around and well- understood for over 20 years - no need for a MAC layer, extra overhead, "smart" firmware breaking stuff (like "packets coming from the wrong link-layer address" as necessary consequence of EUI-64 not giving the computer the link-local address that the network is expecting, etc.) > This is the future of 3GPP interfaces (as opposed to old ptp addressless > links). I hope not. It's a kludge. > It's not only me who thinks so. Why would manufacturers of 3GPP USB > keys go through the effort to ask IEEE for Organization IDs, if it were > not for a belief in a technical advantage of using MAC addresses on 3GPP > links. "It makes windows drivers easier". Yay. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --3UuNU5B2zxNW6aAx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQCVAwUBUT5SV6kuBuNlUUl1AQKedQP+ITirkfS5W3L8UBNrJ1OtnXOOtNUn4l0c v9Nn/cO94C8nvDmvu+2+46fPWwPGo4OP0oOhTD3AE6dyd10iKz2ViGA6UMQFSRkA taH9qy9hhGv+kj5V3RJ0w/jrdWtl/vMWnbd+ZxvKBri8OfpfWohyWYHAc0Zl42pA byLG/68anX4= =okls -----END PGP SIGNATURE----- --3UuNU5B2zxNW6aAx-- From ales.vizdal@t-mobile.cz Mon Mar 11 14:57:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C52621F9052 for ; Mon, 11 Mar 2013 14:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXRCwWSCHFf8 for ; Mon, 11 Mar 2013 14:57:04 -0700 (PDT) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4C221F9034 for ; Mon, 11 Mar 2013 14:57:04 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 38AC3285820; Mon, 11 Mar 2013 22:57:00 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Mon, 11 Mar 2013 22:57:00 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu Date: Mon, 11 Mar 2013 22:56:58 +0100 Thread-Topic: [v6ops] State of IPv6 in Mobile Cellular Networks Thread-Index: Ac4Wps7YCB41ppPGSti8yFxk4FRVtQH++d6w Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6DA1419F4@SRVHKE02.rdm.cz> References: <512CF682.8030307@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6D11E055F@SRVHKE02.rdm.cz> <5130B665.1020907@gmail.com> In-Reply-To: <5130B665.1020907@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 21:57:05 -0000 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Friday, March 01, 2013 9:09 AM > To: V=EDzdal Ale=B9 > Cc: v6ops@ietf.org > Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks >=20 > Le 27/02/2013 00:59, V=EDzdal Ale=B9 a =E9crit : > >>> Correct. NAT44 is good enough if you can number users from > >>> RFC1918. If users (including M2M ...) and infrastructure exceed > >>> RFC1918 space > >> > >> If they exceed RFC1918 space (10.0.0.0/8, 172.16.0.0/12 and > >> 192.168.0.0/16) then there is this 100.64.0.0/10 new space from > >> RFC6598. > > > > Unfortunately, 40-60 million customer base cannot be addressed by > > RFC1918/10.64/10 address space. >=20 > Well. I side with typical advocating of IPv6 and big numbers. But let > me play devil's advocate here. >=20 > 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and 100.64.0.0/10 make up for > a total of unique 22 million (22085632) addresses. This is indeed less > than the 40-60 million customer base. >=20 > But the nature of NAT is more than that. It is also about > - multiple levels of NAT. > - NAT technology can be used with publicly routable addresses which > are not RFC1918/RFC6598. > - dynamic address allocation. >=20 > With 3 levels of NAT and an additional not-used class B, one can easily > cover a 40-60 million customer base. Not all 40-60 million customers > are connected simultaneously. DHCP takes care to revoke use of an > address and deliver it to someone else needing it. 3 levels of NAT will make the data retention much much harder than just one= level. It will hopefully be cheaper to deploy IPv6 ;-) Ales From ales.vizdal@t-mobile.cz Mon Mar 11 15:09:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64EB21F90D3 for ; Mon, 11 Mar 2013 15:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMk29tC75smj for ; Mon, 11 Mar 2013 15:09:02 -0700 (PDT) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF1921F9044 for ; Mon, 11 Mar 2013 15:09:02 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 1572A285812; Mon, 11 Mar 2013 23:09:01 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Mon, 11 Mar 2013 23:09:01 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Tore Anderson , Mikael Abrahamsson Date: Mon, 11 Mar 2013 23:08:59 +0100 Thread-Topic: [v6ops] State of IPv6 in Mobile Cellular Networks Thread-Index: Ac4eg3YLW9Vc7mrkSW6DoHl57IaX9AAIESOQ Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6DA1419F5@SRVHKE02.rdm.cz> References: <510F7FCC.5040705@viagenie.ca> <510FC324.7090908@gmail.com> <513E18CE.3080808@gmail.com> <513E1D61.20308@fud.no> In-Reply-To: <513E1D61.20308@fud.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 22:09:02 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Tore > Anderson > Sent: Monday, March 11, 2013 2:07 PM > To: Mikael Abrahamsson > Cc: v6ops@ietf.org > Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks >=20 > * Mikael Abrahamsson >=20 > > On Mon, 11 Mar 2013, Alexandru Petrescu wrote: > > > >> I am not sure what you mean by 'doable'. Do you know of an operator > >> having done some LTE IPv6 test? > > > > I have IPv4v6 working in our LTE network today, network wide. Not in > > production to customers, but doing IPv4v6 in LTE is comparitively easy. > > We had it working 2-3 years ago. > > > > I don't want to IPv6 enable our users when they're connected to the LTE > > network and then have customers lose their IPv6 connectivity if they > > happen to hand over to 2G or 3G. >=20 > Is this only a challenge for IPv4v6, or does it apply to IPv6 as well? In general if you doing a handover between two RATs (radio access technolog= ies such as 2G, 3G or LTE) you need to have the same PDP Types subscribed and s= upported,=20 so both networks must have the same capabilities and matching user subscrip= tions. IPv4v6 support for 2G/3G usually requires a network upgrade, so LTE deploym= ents are more likely to be IPv4v6 compliant than 2G/3G. In terms of IPv6, handov= ers are likely to work as IPv6 PDP support is there for some time, but it comes= down to if IPv6 is supported in 2G/3G as IPv6 only not common and operators are = trying to avoid dual-stack support by two independent PDPs (IPv4 and IPv6) as the = BSS systems might have some issues. > I know of several 3G networks that support IPv6 in production for their > customers, but I don't know if any of those also operate LTE networks > and if so whether or not the handover between the network types works. >=20 > Best regards, > -- > Tore Anderson Ales From ales.vizdal@t-mobile.cz Mon Mar 11 15:16:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABEA621F8C08 for ; Mon, 11 Mar 2013 15:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iezxiUYjCGfz for ; Mon, 11 Mar 2013 15:15:59 -0700 (PDT) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id AFBF121F8C06 for ; Mon, 11 Mar 2013 15:15:58 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id E498228581A; Mon, 11 Mar 2013 23:15:57 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Mon, 11 Mar 2013 23:15:57 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu , Cameron Byrne Date: Mon, 11 Mar 2013 23:15:54 +0100 Thread-Topic: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 Thread-Index: Ac4eh/ateyyQ8pMgRKiMCKMSO1L8QAAHRydA Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6DA1419F6@SRVHKE02.rdm.cz> References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> In-Reply-To: <513E24EC.9020902@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 22:16:00 -0000 Alex, > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Sent: Monday, March 11, 2013 2:40 PM > To: Cameron Byrne > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64sha= re-03 >=20 > Le 11/03/2013 18:59, Cameron Byrne a =E9crit : > > Alex, > > > > There is no other 3GPP link model. There is only p2p. What i believe > > you are referencing is a link model that is a specific implementation > > towards tethered devices, and not within the scope of any 3GPP > > standard. >=20 > Well. >=20 > The 3GPP links which use IEEE MAC addresses are 3GPP links or not? The 3GPP can hardly be using an IEEE MAC as there is no link-layer, you may be talking about the PC facing interface such as USB. > > We only consider 3GPP link model as described in the draft explicitly > > and via reference to rfc6459. Our hope is that publishing this draft > > will avoid new invention from every OEM. >=20 > Well. >=20 > IETF does not specify 3GPP links. It's impossible to write an RFC which > does so. >=20 > Cellular links exist out there, and some of them behave as some 3GPP > specs expect, others dont. >=20 > What would one call a cellular link of a cellular operator which does > IPv6 and uses IEEE MAC addresses - are these 3GPP links? As written above, are you talking about the 3GPP or USB (or any other) inte= rface? > >> - the Gateway does _not_ send an NS for _any_ of the addresses > >> within the /64 prefix. > >> > > > > This is also already covered in stating that is this standard 3GPP > > operation >=20 > I doubt we have a common understanding of what is "3GPP operation". I > doubt implementations of 3GPP links act as 3GPP specs expect them to. Well, if someone violates the standard he/she should not surprised if thing= s go wrong. > >> - the Gateway does not use a 'Connected' route towards that /64. > >> > > > > I am not sure what this one is, but i assume it is covered in the > > same way as above. >=20 > A 'connected' route is Cisco terminology to say that there is no > next-hop in the Gateway's routing table entry (linux's '*') for that > prefix /64. >=20 > I doubt 3GPP specs talk 'connected' route; but routers do have two > different kind sof routes for a /64 - a 'connected' route, or a > non-connected route (_has_ a nexthop for that /64). I believe that the packet core nodes have no next-hops as they're sending a= ll the matching traffic to the GTP tunnel. > This is why I am surprised we refer here to 3GPP specs. > > > >> There may exist cellular links on which this 64share does not > >> work. > >> > > > > We believe all case for standard 3GPP links are covered. >=20 > What is a standard 3GPP link? I doubt we can say so authoritatively at > IETF. The respective 2G/3G or LTE 3GPP TS. > Besides, if one asks 3GPP specs, they'll tell that 64share is not possibl= e. The 3GPP specs to me are more concerned about the architecture. The 3GPP sp= ec can be potentially referring to this draft/rfc. > >> (and I find it strange to talk purely implementation in this draft, > >> but when it comes to its inconvenients to refer to some 3GPP spec - > >> it is widely known that 3GPP specs are implemented in various > >> incompatible ways; the draft would better talk pure implementation > >> everywhere). > >> > > > > I have running code for scenario 3. >=20 > Yes, I agree with you. I have tried the same thing on linux with an USB > key. >=20 > However, it seems I may have tried an additional running code which > breaks at 64share - when the link is 'shared' kind. I do not care > whether that link is compliant with 3GPP specs. It is a link on a > cellular operator, at a cellular frequency. >=20 > If one asks 3GPP specs, they'll tell that 64share is not possible. >=20 > Alex >=20 > > > > CB > >> Alex > >> > >> Le 11/03/2013 18:27, Cameron Byrne a =E9crit : > >>> > >>> Dave, > >>> > >>> Here is the quote of the current draft text. Does this > >>> correctly describe the link model that the gateway does not > >>> consume an address? Would you suggest a change? > >>> > >>> "As [RFC6459] describes, the 3GPP network assigned /64 is > >>> completely dedicated to the UE and the gateway does not consume > >>> any of the /64 addresses. The gateway routes the entire /64 to > >>> the UE and does not perform ND or Network Unreachability > >>> Detection (NUD) [RFC4861]." > >>> > >>> http://tools.ietf.org/html/draft-ietf-v6ops-64share-03 > >>> > >>> Cameron _______________________________________________ v6ops > >>> mailing list v6ops@ietf.org > >>> https://www.ietf.org/mailman/listinfo/v6ops > >>> > >>> > >> > >> > >> _______________________________________________ v6ops mailing list > >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > > >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From owen@delong.com Mon Mar 11 15:16:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2808E21F8C08 for ; Mon, 11 Mar 2013 15:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] 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 L+hNhwSji-3c for ; Mon, 11 Mar 2013 15:16:00 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C328121F8C09 for ; Mon, 11 Mar 2013 15:15:59 -0700 (PDT) Received: from [10.255.251.216] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2BMBtVf022337 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Mar 2013 15:11:55 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2BMBtVf022337 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363039916; bh=AZ3N66/Mbsl6UIl9Noey1m4QRgI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=j8CB49aOFsotKyXlNcfvafti927aQB8FnvxDCjLC+yH921qGWd85w+A3VbTIzXi1H lIsOnvXEmb3X7p0y8UC+1wwH8IvJXsPebIFxcQJnGodHCWeAg9C2E+xTPewkcjzJem 1/NdYqJC0TffwmCr+XMkwxuTidZ4fKQBwQK0j3Gs= Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <513E0D5F.4010904@gmail.com> Date: Mon, 11 Mar 2013 15:11:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <512CF682.8030307@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6D11E055F@SRVHKE02.rdm.cz> <5130B665.1020907@gmail.com> <8D4B01C4-EC43-48A4-BC15-A4D2DC5CACC2@delong.com> <513E0D5F.4010904@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 11 Mar 2013 15:11:56 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 22:16:01 -0000 On Mar 11, 2013, at 9:59 AM, Alexandru Petrescu = wrote: > Le 02/03/2013 03:59, Owen DeLong a =E9crit : >>=20 >> On Mar 1, 2013, at 06:08 , Alexandru Petrescu >> wrote: >>=20 >>> Le 27/02/2013 00:59, V=EDzdal Ale=B9 a =E9crit : >>>>>> Correct. NAT44 is good enough if you can number users from >>>>>> RFC1918. If users (including M2M ...) and infrastructure >>>>>> exceed RFC1918 space >>>>>=20 >>>>> If they exceed RFC1918 space (10.0.0.0/8, 172.16.0.0/12 and >>>>> 192.168.0.0/16) then there is this 100.64.0.0/10 new space >>>>> from RFC6598. >>>>=20 >>>> Unfortunately, 40-60 million customer base cannot be addressed >>>> by RFC1918/10.64/10 address space. >>>=20 >>> Well. I side with typical advocating of IPv6 and big numbers. But >>> let me play devil's advocate here. >>>=20 >>> 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and 100.64.0.0/10 make up >>> for a total of unique 22 million (22085632) addresses. This is >>> indeed less than the 40-60 million customer base. >>>=20 >>> But the nature of NAT is more than that. It is also about - >>> multiple levels of NAT. >> Breaks many NAT traversal solutions and makes NAT even more >> dysfunctional. >=20 > It may, but I am not sure which ones? >=20 > The NAT Traversal of Mobile IP (based on UDP) works ok with this NAT. >=20 > Also, NAT Traversal is not absolutely necessary. One may use = Internet > without employing NAT Traversal. That depends on your application. VPNs will, in many cases suffer here. Also many peer-to-peer communications programs such as Skype, YIM, etc. VOIP will often break from multi-layer NAT in interesting ways. The internet is not the web. The web works without NAT traversal. Other applications vary. Some applications don't work particularly well with = NAT even with NAT traversal. >=20 >>> - NAT technology can be used with publicly routable addresses >>> which are not RFC1918/RFC6598. >>=20 >> Breaks NAT-oriented assumptions that have been baked into some >> applications NAT traversal efforts. >=20 > I didnt know that. I wonder which NAT traversal solution is built in > with the assumption that the IP address is only RFC1918 space? >=20 > (remark these implementations will fail also when the new NAT space > 100./10 is employed, instead of RFC1918). No, they won't. The new space is intended not as an end-user space, but for the intermediate space used by ISPs. The application should never see it (or should see it as "public address" space on the other side of the NAT. >=20 >>> - dynamic address allocation. >>=20 >> Has nothing whatsoever to do with NAT. >=20 > It has to do with the lack of addresses argument. >=20 > Although an operator may need 50million addresses, these are not = needed > at the same time. And the dynamic nature of DHCP allows for it. Only to a very limited (and ever decreasing) extent. More and more = things are becoming always-on-always-connected. >=20 >>> With 3 levels of NAT and an additional not-used class B, one can >>> easily cover a 40-60 million customer base. Not all 40-60 million >>> customers are connected simultaneously. DHCP takes care to revoke >>> use of an address and deliver it to someone else needing it. >>=20 >> There are a lot of (not necessarily correct) assumptions about usage >> patterns built into those numbers. I can guarantee you that if an >> ISP were to inflict such an implementation on residential >> subscribers, they would lose customers quickly. >=20 > Residential - I tend to agree, people tend to need a more comfortable = IP connection when the place is as comfortable as at home. >=20 I don't think that's the distinction that matters so much here. My point = is that customers have developed a certain level of expectation based on their customer experience to date. In the mobile world, that experience has = been traditionally particularly poor and as a result, expectations are = generally very low. In the residential world, the experience has been generally poor, = but not nearly as poor as in the mobile world. As a result, expectations are a = bit higher. >> In mobile, maybe, maybe not. People have become pretty tolerant of an >> impressive level of dysfunctionality in mobile IP in the US. >=20 > Well, this is the case of how the computer is used. >=20 > When people are mobile they do less things on a computer than when at = a desk. IPv4 and NAT are maybe sufficient for that. That is an assumption which may have been valid 5 or possibly even 2 = years ago. It certainly isn't valid today for many users and is becoming = increasingly invalid for more and more users as time progresses. >>> If all 40-60 million customers were connected simultaneously then >>> the core network would crash - but for other reasons than IPv4 >>> address numbers. >>=20 >> I'm not actually convinced that's true. >>=20 >>> Cellular network crashes exist yet they're not due to too small >>> IPv4 addressing space. >>=20 >> Whether the lack of addresses crashes the network or not, it >> certainly degrades the user experience. >=20 > Operators are afraid of having to pay subscribers, rather than = offering them a degraded service. >=20 > Operators pay subscribers when the service fails entirely. Operators never pay subscribers in my experience. In some cases, if the = network fails entirely (where fails entirely is viewed from the user's = perspective more than from the operator's), operators may have to refund = some of what the subscriber paid. Subscribers do not expect to pay for = services they have not received or could not use. Operators are afraid of many things: Service credits Departing customers Regulatory changes Failed service leads to the first one. Degraded service leads to the = second. Enough unhappy customers from either failed or degraded service = tends to result in the third. >=20 >>> There is not a problem in numbers when using NAT technology to >>> cover that 40-60 million customer base. There are other problems, >>> but not in numbers of IPv4 addressing. >>=20 >> Yes, there is a real problem in IPv4 numbers, too. The fact that >> you're more willing to add a bunch of hacks to IPv4 to try and prop >> it up instead of implementing IPv6 really doesn't change the fact >> that there is a problem. >>=20 >>> If these problems could be formulated then we could have a case for >>> IPv6 in cellular networks. >>=20 >> The problems have been formulated and a number of cellular networks >> have started deploying IPv6. I believe Slovenia is completely >> dual-stacked on their cellular networks, for example. >=20 > It is a good exemple. >=20 > But I would like to learn whether Slovenia deploys LTE. I think it = does not look at it. An dif it does, I would be surprised that were IPv6 = (although Slovenia may look at deploying 3G and IPv6). >=20 This makes no sense. It is actually easier to do IPv6 on LTE than on = earlier cellular technologies. I know that Verizon's IPv6 deployment is on their LTE network. >> I know that Verizon and T-Mobile both have IPv6 on their wireless >> networks to varying degrees. >=20 > Yes, varying degrees. That is a detail point I am trying to = understand - who deploys IPv6 and LTE/4G. Verizon. T-Mobile. The varying degrees part was more about the percentage of network = coverage than about which of their technologies had IPv6. Owen From ales.vizdal@t-mobile.cz Mon Mar 11 15:22:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C01321F8DF0 for ; Mon, 11 Mar 2013 15:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbOdaUJJ6Rj9 for ; Mon, 11 Mar 2013 15:22:53 -0700 (PDT) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 7451621F8DE9 for ; Mon, 11 Mar 2013 15:22:53 -0700 (PDT) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 9EA55285827; Mon, 11 Mar 2013 23:22:52 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk504.rdm.cz ([fe80::744e:351e:b5b:fd01%12]) with mapi; Mon, 11 Mar 2013 23:22:52 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu , joel jaeggli Date: Mon, 11 Mar 2013 23:22:50 +0100 Thread-Topic: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 Thread-Index: Ac4emcN7P8KNgfBrSNe+vf3b+3KvQwADJy0g Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6DA1419F7@SRVHKE02.rdm.cz> References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <513E3D21.7090905@gmail.com> <513E3FA8.30002@bogus.com> <513E42C9.2050802@gmail.com> In-Reply-To: <513E42C9.2050802@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 22:22:57 -0000 Alex, > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Sent: Monday, March 11, 2013 4:47 PM > To: joel jaeggli > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64sha= re-03 >=20 > Le 11/03/2013 21:33, joel jaeggli a =E9crit : > > On 3/11/13 4:22 PM, Alexandru Petrescu wrote: > >> > >> > >> Additionnally, many operators of these 3GPP links will appreciate > >> little the use of 64share on devices which they dont control. > >> (i.e. use 64share on a laptop PC with linux, rather than on an > >> operator-controlled smartphone). > >> > > The policy question seems unrelated to the technical mechanism used > > for tethering. >=20 > If it were not, then DHCPv6-PD for Mobile Routers would be correctly > specified at 3GPP, and it would be at least in test deployment phases. >=20 > (AFAIK, DHCPv6-PD is specified in 3GPP but for purposes which cant make > 'tethering' - to me that's on purpose, policy). The 3GPP Rel-10 has introduced DHCP-PD. What's the problem here? =20 > In IPv4 there is a unique NAT mechanism, whereas here a number of > options are on the table: NPT, 64share, DHCPv6-PD. None of these is in > the 3GPP specs AFAIK. I wonder why if it were not for policy... >=20 > That said, I also agree that one may leave policy aside and implement > whatever one likes to - which is especially true when inter-operability > may not be at stake - which is the case here: we only talk this > smartphone, which does not need to be interoperable with anything, > because we assume 3GPP specs forbid the impossible thingie cases... > which make 64share bound to 3GPP... >=20 > Alex Ales From marka@isc.org Mon Mar 11 15:42:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE7221F901E for ; Mon, 11 Mar 2013 15:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PR8vrN8HzWR2 for ; Mon, 11 Mar 2013 15:42:15 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id D03A621F900A for ; Mon, 11 Mar 2013 15:42:15 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id B96F0C958E; Mon, 11 Mar 2013 22:42:10 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363041735; bh=CgRlVlH1WSG3r/ck5XHTC4hgh2MpsNTijtVhmrwcMOE=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=TzOFfyG8DgqMdia4Gx79ozQ+HkKuvDwPyDDw+hjcZHFpP91zYupd3ZSiXcEM4nmJJ xjjiBJ68mcfsu39FJKmV21JLqHwpPr9WAQTK3LYsTGtacXWUnSJPdcKz3/PHoSOVCj URbHPnp+OSmEui7BUjC0TAkjYEF0SXPsGXKcvYIc= 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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Mon, 11 Mar 2013 22:42:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 77FE6216C3B; Mon, 11 Mar 2013 22:42:10 +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 C24B230B9425; Tue, 12 Mar 2013 09:42:01 +1100 (EST) To: Owen DeLong From: Mark Andrews References: <512CF682.8030307@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6D11E055F@SRVHKE02.rdm.cz> <5130B665.1020907@gmail.com> <8D4B01C4-EC43-48A4-BC15-A4D2DC5CACC2@delong.com> <513E0D5F.4010904@gmail.com> In-reply-to: Your message of "Mon, 11 Mar 2013 15:11:55 PDT." Date: Tue, 12 Mar 2013 09:42:01 +1100 Message-Id: <20130311224201.C24B230B9425@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 22:42:16 -0000 In message , Owen DeLong writes: > > > (remark these implementations will fail also when the new NAT space > > 100./10 is employed, instead of RFC1918). > > No, they won't. The new space is intended not as an end-user space, > but for the intermediate space used by ISPs. The application should > never see it (or should see it as "public address" space on the other > side of the NAT. Of course applications will see it. If you are directly connected applications are expected to see it. 100/10 prevents RFC 1918 either side of a CPE router. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ietf@meetecho.com Mon Mar 11 15:44:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60CC21F9050 for ; Mon, 11 Mar 2013 15:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_13=0.6] 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 3e+rFBbW5toR for ; Mon, 11 Mar 2013 15:44:02 -0700 (PDT) Received: from smtpdg12.aruba.it (smtpdg96.aruba.it [62.149.158.96]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7D521F901D for ; Mon, 11 Mar 2013 15:44:01 -0700 (PDT) Received: from meetecho ([130.129.6.44]) by smtpcmd05.ad.aruba.it with bizsmtp id ANjx1l0040wzZHu01NjyoQ; Mon, 11 Mar 2013 23:43:59 +0100 Date: Mon, 11 Mar 2013 18:43:24 -0700 (PDT) From: Meetecho Team To: v6ops@ietf.org Message-ID: <16985476.1.1363052604284.JavaMail.root@meetecho> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_13272829.1363052604256" Subject: [v6ops] V6OPS session recording available X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 22:44:03 -0000 ------=_Part_0_13272829.1363052604256 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the V6OPS WG session at IETF 86 is available at the following URL: http://ietf86.conf.meetecho.com/index.php/Recorded_Sessions#IETF86_V6OPS In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_0_13272829.1363052604256-- From alexandru.petrescu@gmail.com Mon Mar 11 15:59:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C7F21F8E5E for ; Mon, 11 Mar 2013 15:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXeWMhmsdqbw for ; Mon, 11 Mar 2013 15:59:42 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9800921F8E5F for ; Mon, 11 Mar 2013 15:59:41 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2BMxeiE006218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Mar 2013 23:59:40 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2BMxe7b006712; Mon, 11 Mar 2013 23:59:40 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.8]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2BMxYN0031776; Mon, 11 Mar 2013 23:59:39 +0100 Message-ID: <513E61B2.2000307@gmail.com> Date: Mon, 11 Mar 2013 23:58:58 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Gert Doering References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> In-Reply-To: <20130311215327.GK51699@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 22:59:42 -0000 Le 11/03/2013 22:53, Gert Doering a écrit : > Hi, > > On Mon, Mar 11, 2013 at 09:32:15PM +0100, Alexandru Petrescu wrote: >> Le 11/03/2013 19:58, Mikael Abrahamsson a écrit : >>> On Mon, 11 Mar 2013, Alexandru Petrescu wrote: >>> >>>> We are already the knees deep into thingies. The IPv6 stack >>>> (the one which uses IPv6 addresses, ND, routes, interfaces - as >>>> 64share requires) is faced to these thingies. >>> >>> The USB dongle does this magic in order to emulate a MAC layer >>> towards the OS. It doesn't need to do this, but that's one way >>> of doing it. >> >> This is a kind effort from the USB key - it helps a lot the IPv6 >> stack. The stack sees the 3GPP interface just like any other >> Ethernet interface. The stack does not need to do wacky things >> like NO_ARP. > > I'm not sure why you think that this is helpful or kind - it just > complicates things, while PPP interfaces have been around and well- > understood for over 20 years PPP on cellular 3GPP links have failed to evolve for some strange reason. (many other links have moved away from this ppp nature). When a new kind of link shows up it first gets seen by IPv6 stack as a serial, or as a ptp link. Then it slowly evolves to IEEE, MAC addressable, multicast capable links. Now 3GPP links try the same... > - no need for a MAC layer, extra overhead, "smart" firmware breaking > stuff (like "packets coming from the wrong link-layer address" as > necessary consequence of EUI-64 not giving the computer the > link-local address that the network is expecting, etc.) Strange, the absence of a proper MAC layer is what allows 64share to work... (no doubt DHCPv6 is not deployed on these MAC-less links, because DHCPv6, like IPv6 ND, rely a lot on having a good MAC layer). >> This is the future of 3GPP interfaces (as opposed to old ptp >> addressless links). > > I hope not. It's a kludge. It may be implemented as what looks like kludgy patch, but it may improve in the future. We should let space for that. It may turn in circles, but the first thing this 64share draft says is that DHCPv6-PD is the right thing to do. And DHCPv6-PD is working better on links which have MAC layers (e.g. during the mulitcast SErver discovery phase one better has a multicast feature built-in). Were the 3GPP links to have right MAC layers (non kludgy) then maybe DHCPv6-PD were used instead of 64share. >> It's not only me who thinks so. Why would manufacturers of 3GPP >> USB keys go through the effort to ask IEEE for Organization IDs, if >> it were not for a belief in a technical advantage of using MAC >> addresses on 3GPP links. > > "It makes windows drivers easier". Yay. Recent linux kernel efforst try to work in the same way as windows ndis drivers do with recent USB LTE keys. Alex > > Gert Doering -- NetMaster > From alexandru.petrescu@gmail.com Mon Mar 11 16:03:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D4721F8E12 for ; Mon, 11 Mar 2013 16:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.912 X-Spam-Level: X-Spam-Status: No, score=-9.912 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCaNDbt8TsYB for ; Mon, 11 Mar 2013 16:03:06 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7713521F8C7A for ; Mon, 11 Mar 2013 16:03:06 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2BN351g017633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Mar 2013 00:03:05 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2BN358w007400; Tue, 12 Mar 2013 00:03:05 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.8]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2BN33wP032529; Tue, 12 Mar 2013 00:03:04 +0100 Message-ID: <513E6282.6010607@gmail.com> Date: Tue, 12 Mar 2013 00:02:26 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: =?ISO-8859-2?Q?V=EDzdal_Ale=B9?= References: <512CF682.8030307@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6D11E055F@SRVHKE02.rdm.cz> <5130B665.1020907@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA1419F4@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6DA1419F4@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 23:03:07 -0000 Le 11/03/2013 22:56, Vízdal Ale¹ a écrit : >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Friday, March 01, 2013 >> 9:09 AM To: Vízdal Ale¹ Cc: v6ops@ietf.org Subject: Re: [v6ops] >> State of IPv6 in Mobile Cellular Networks >> >> Le 27/02/2013 00:59, Vízdal Ale¹ a écrit : >>>>> Correct. NAT44 is good enough if you can number users from >>>>> RFC1918. If users (including M2M ...) and infrastructure >>>>> exceed RFC1918 space >>>> >>>> If they exceed RFC1918 space (10.0.0.0/8, 172.16.0.0/12 and >>>> 192.168.0.0/16) then there is this 100.64.0.0/10 new space >>>> from RFC6598. >>> >>> Unfortunately, 40-60 million customer base cannot be addressed >>> by RFC1918/10.64/10 address space. >> >> Well. I side with typical advocating of IPv6 and big numbers. But >> let me play devil's advocate here. >> >> 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and 100.64.0.0/10 make up >> for a total of unique 22 million (22085632) addresses. This is >> indeed less than the 40-60 million customer base. >> >> But the nature of NAT is more than that. It is also about - >> multiple levels of NAT. - NAT technology can be used with publicly >> routable addresses which are not RFC1918/RFC6598. - dynamic address >> allocation. >> >> With 3 levels of NAT and an additional not-used class B, one can >> easily cover a 40-60 million customer base. Not all 40-60 million >> customers are connected simultaneously. DHCP takes care to revoke >> use of an address and deliver it to someone else needing it. > > 3 levels of NAT will make the data retention much much harder than > just one level. Well I dont know what is meant by data retention? I did this scheme: lte-wifi-wifi with two NATs and it works fine for some web browsing I tried. > It will hopefully be cheaper to deploy IPv6 ;-) Hopefully :-) Alex > > Ales > > > From alexandru.petrescu@gmail.com Mon Mar 11 16:22:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA2021F8D27 for ; Mon, 11 Mar 2013 16:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.624 X-Spam-Level: X-Spam-Status: No, score=-9.624 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcIRxXs81tGu for ; Mon, 11 Mar 2013 16:22:28 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 435DD21F8D1A for ; Mon, 11 Mar 2013 16:22:28 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2BNMQXD021296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Mar 2013 00:22:26 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2BNMQCP009776; Tue, 12 Mar 2013 00:22:26 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.8]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2BNMKnu007834; Tue, 12 Mar 2013 00:22:25 +0100 Message-ID: <513E6707.6010905@gmail.com> Date: Tue, 12 Mar 2013 00:21:43 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: =?ISO-8859-2?Q?V=EDzdal_Ale=B9?= References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA1419F6@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6DA1419F6@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 23:22:29 -0000 Le 11/03/2013 23:15, Vízdal Ale¹ a écrit : > Alex, > >> -----Original Message----- From: v6ops-bounces@ietf.org >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Monday, March 11, 2013 2:40 PM To: Cameron Byrne Cc: >> v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in >> draft-ietf-v6ops-64share-03 >> >> Le 11/03/2013 18:59, Cameron Byrne a écrit : >>> Alex, >>> >>> There is no other 3GPP link model. There is only p2p. What i >>> believe you are referencing is a link model that is a specific >>> implementation towards tethered devices, and not within the >>> scope of any 3GPP standard. >> >> Well. >> >> The 3GPP links which use IEEE MAC addresses are 3GPP links or not? > > The 3GPP can hardly be using an IEEE MAC as there is no link-layer, > you may be talking about the PC facing interface such as USB. Yes, I am talking about what the IPv6 stack on the PC sees: it sees Ethernet-encapsulated IPv6 packets. This IPv6 stack on the PC supposedly implements 64share. (64share would not be implemented on 3GPP USB keys). > >>> We only consider 3GPP link model as described in the draft >>> explicitly and via reference to rfc6459. Our hope is that >>> publishing this draft will avoid new invention from every OEM. >> >> Well. >> >> IETF does not specify 3GPP links. It's impossible to write an RFC >> which does so. >> >> Cellular links exist out there, and some of them behave as some >> 3GPP specs expect, others dont. >> >> What would one call a cellular link of a cellular operator which >> does IPv6 and uses IEEE MAC addresses - are these 3GPP links? > > As written above, are you talking about the 3GPP or USB (or any > other) interface? I am talking about what the IPv6 stack on the PC sees. I am not talking about the IPv6 'thingie' software which runs on the USB key. (I doubt it has a full IPv6 stack). Besides, I have no idea whether that NS is originated by the Gateway, or by the USB key. And nobody seems to know (other than speculating by reading the 3GPP specs). Were it to be generated by the USB key, then we could call it kludge, fake proxying, bad thing. But if it were originated by the Gateway then we'd call it the right thing to do. >>>> - the Gateway does _not_ send an NS for _any_ of the addresses >>>> within the /64 prefix. >>>> >>> >>> This is also already covered in stating that is this standard >>> 3GPP operation >> >> I doubt we have a common understanding of what is "3GPP >> operation". I doubt implementations of 3GPP links act as 3GPP specs >> expect them to. > > Well, if someone violates the standard he/she should not surprised > if things go wrong. Yes and no. Standards shouldd follow implementations as well. >>>> - the Gateway does not use a 'Connected' route towards that >>>> /64. >>>> >>> >>> I am not sure what this one is, but i assume it is covered in the >>> same way as above. >> >> A 'connected' route is Cisco terminology to say that there is no >> next-hop in the Gateway's routing table entry (linux's '*') for >> that prefix /64. >> >> I doubt 3GPP specs talk 'connected' route; but routers do have two >> different kind sof routes for a /64 - a 'connected' route, or a >> non-connected route (_has_ a nexthop for that /64). > > I believe that the packet core nodes have no next-hops as they're > sending all the matching traffic to the GTP tunnel. If it so, then it is a problem, because that link must be configured to _not_ do ARP, not do ND, etc. >> This is why I am surprised we refer here to 3GPP specs. >>> >>>> There may exist cellular links on which this 64share does not >>>> work. >>>> >>> >>> We believe all case for standard 3GPP links are covered. >> >> What is a standard 3GPP link? I doubt we can say so >> authoritatively at IETF. > > The respective 2G/3G or LTE 3GPP TS. No no... 3GPP standards cant stop people from implementing this kind of MAC-addressable links... chipset manufacturers, kernel developpers, etc. It's the other way around. Standards should document implementations - this is what 64share spec does too. >> Besides, if one asks 3GPP specs, they'll tell that 64share is not >> possible. > > The 3GPP specs to me are more concerned about the architecture. The > 3GPP spec can be potentially referring to this draft/rfc. Circular references? 3GPP refers to 64share which works _only_ if that other 3GPP spec works? Alex >>>> (and I find it strange to talk purely implementation in this >>>> draft, but when it comes to its inconvenients to refer to some >>>> 3GPP spec - it is widely known that 3GPP specs are implemented >>>> in various incompatible ways; the draft would better talk pure >>>> implementation everywhere). >>>> >>> >>> I have running code for scenario 3. >> >> Yes, I agree with you. I have tried the same thing on linux with >> an USB key. >> >> However, it seems I may have tried an additional running code which >> breaks at 64share - when the link is 'shared' kind. I do not care >> whether that link is compliant with 3GPP specs. It is a link on a >> cellular operator, at a cellular frequency. >> >> If one asks 3GPP specs, they'll tell that 64share is not possible. >> >> Alex >> >>> >>> CB >>>> Alex >>>> >>>> Le 11/03/2013 18:27, Cameron Byrne a écrit : >>>>> >>>>> Dave, >>>>> >>>>> Here is the quote of the current draft text. Does this >>>>> correctly describe the link model that the gateway does not >>>>> consume an address? Would you suggest a change? >>>>> >>>>> "As [RFC6459] describes, the 3GPP network assigned /64 is >>>>> completely dedicated to the UE and the gateway does not >>>>> consume any of the /64 addresses. The gateway routes the >>>>> entire /64 to the UE and does not perform ND or Network >>>>> Unreachability Detection (NUD) [RFC4861]." >>>>> >>>>> http://tools.ietf.org/html/draft-ietf-v6ops-64share-03 >>>>> >>>>> Cameron _______________________________________________ v6ops >>>>> mailing list v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ v6ops mailing >>>> list v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From ales.vizdal@t-mobile.cz Mon Mar 11 16:23:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D3221F8D55 for ; Mon, 11 Mar 2013 16:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RlVm2zfVqrC for ; Mon, 11 Mar 2013 16:23:40 -0700 (PDT) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id E3CA521F8D27 for ; Mon, 11 Mar 2013 16:23:39 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id ED12A2857F9; Tue, 12 Mar 2013 00:23:38 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Tue, 12 Mar 2013 00:23:38 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu Date: Tue, 12 Mar 2013 00:23:35 +0100 Thread-Topic: [v6ops] State of IPv6 in Mobile Cellular Networks Thread-Index: Ac4erjgOqyz4uW0gSeWn2uAPAswn8gAAF3pw Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6DA1419FD@SRVHKE02.rdm.cz> References: <512CF682.8030307@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6D11E055F@SRVHKE02.rdm.cz> <5130B665.1020907@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA1419F4@SRVHKE02.rdm.cz> <513E6282.6010607@gmail.com> In-Reply-To: <513E6282.6010607@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 23:23:41 -0000 > > 3 levels of NAT will make the data retention much much harder than > > just one level. >=20 > Well I dont know what is meant by data retention? http://en.wikipedia.org/wiki/Data_retention or call it logging The ISPs are asked to keep records, so once asked by the court they must re= veal=20 who was using the IP address that's a subject of a query at a given time. T= he legislation varies country by country. > I did this scheme: >=20 > lte-wifi-wifi >=20 > with two NATs and it works fine for some web browsing I tried. >=20 > > It will hopefully be cheaper to deploy IPv6 ;-) >=20 > Hopefully :-) >=20 > Alex >=20 > > > > Ales Ales From jouni.nospam@gmail.com Mon Mar 11 16:27:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5656021F8EEB for ; Mon, 11 Mar 2013 16:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.671 X-Spam-Level: X-Spam-Status: No, score=0.671 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, J_CHICKENPOX_13=0.6, RDNS_NONE=0.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 d3TlwGSgqs3A for ; Mon, 11 Mar 2013 16:27:51 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id A697A11E80A2 for ; Mon, 11 Mar 2013 16:27:49 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id 13so5584918iea.14 for ; Mon, 11 Mar 2013 16:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=oWQuOT2GR5haggfQoTNxS3CgrSOqNawc3iJ5IkwKf3Q=; b=pxNexZIKnMUcb5ZbyvtREZnnSfHbTj+8nPgbRL+gQDciW7XpFQ0wH9S/ZUtexK6+Vp DmQK734aZdTUNc1XLbwcqhekdgpiupqczmurqyuLNoGVshU53cIT7W49nq289uizYukb 8ltRA0UN/HxKlj6FLmXfr18cxGVrk7RIvlY/PB2pWM0eAG6CqBOmhQt43kYVElVVHHwW 9tp7PIp7T2EH8FQPgVi7RmaoMIzK6TbHK+UvMpBtM7NK9ntbZts2qyOsHDR+QxqkZPXp YGmc3uHCrB/NulCKeKdJi296X76oYnecDFqCI7tXfbYD1ifmlr0eP7Wx93X3w1X1VWHc 5LTQ== X-Received: by 10.50.195.134 with SMTP id ie6mr9408676igc.6.1363044466186; Mon, 11 Mar 2013 16:27:46 -0700 (PDT) Received: from [130.129.134.193] ([130.129.134.193]) by mx.google.com with ESMTPS id ew5sm17130745igc.2.2013.03.11.16.27.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Mar 2013 16:27:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jouni Korhonen In-Reply-To: Date: Tue, 12 Mar 2013 01:27:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3AA6890B-3CCD-4F2B-861F-279BB9294370@gmail.com> References: <510F7FCC.5040705@viagenie.ca> <510FC324.7090908@gmail.com> <513E18CE.3080808@gmail.com> <513E1D61.20308@fud.no> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 23:27:52 -0000 On Mar 11, 2013, at 8:28 PM, Mikael Abrahamsson = wrote: > On Mon, 11 Mar 2013, Tore Anderson wrote: >=20 >>> I don't want to IPv6 enable our users when they're connected to the = LTE >>> network and then have customers lose their IPv6 connectivity if they >>> happen to hand over to 2G or 3G. >>=20 >> Is this only a challenge for IPv4v6, or does it apply to IPv6 as = well? >=20 > Well, it's a scaling issue as well. Currently supporting IPv4+IPv6 is = not really a problem, but this increases the signalling load. For me = it's been a problem to get IPv4v6 support in 2G+3G which I want before = deploying. >=20 >> I know of several 3G networks that support IPv6 in production for = their >> customers, but I don't know if any of those also operate LTE networks >> and if so whether or not the handover between the network types = works. >=20 > One way is to go IPv4v6 in LTE and IPv4+IPv6 (dual bearers) in 2G/3G. = I don't know how well this works in real life. This is one of the things = I'm going to find out :P The context transfer messages will get rejected if the pre-rel-9 SGSN = does not understand the dual-stack required extended addressing IEs. = Some GTPv1 goodness ;) - Jouni >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Dmitry.Anipko@microsoft.com Mon Mar 11 16:30:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B57011E80A5 for ; Mon, 11 Mar 2013 16:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 Haoy9NfgpcAU for ; Mon, 11 Mar 2013 16:30:46 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE2511E80CC for ; Mon, 11 Mar 2013 16:30:46 -0700 (PDT) Received: from BN1BFFO11FD008.protection.gbl (10.58.52.204) by BN1AFFO11HUB022.protection.gbl (10.58.52.132) with Microsoft SMTP Server (TLS) id 15.0.620.12; Mon, 11 Mar 2013 23:30:39 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD008.mail.protection.outlook.com (10.58.53.68) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Mon, 11 Mar 2013 23:30:38 +0000 Received: from TK5EX14MBXC252.redmond.corp.microsoft.com ([169.254.1.2]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Mon, 11 Mar 2013 23:30:00 +0000 From: Dmitry Anipko To: Alexandru Petrescu , Gert Doering Thread-Topic: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 Thread-Index: AQHOHpenqbWbQmpwXk287QLKWMO5mZihCImAgAASTgCAAAeisA== Date: Mon, 11 Mar 2013 23:29:57 +0000 Message-ID: References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> <513E61B2.2000307@gmail.com> In-Reply-To: <513E61B2.2000307@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.23] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(479174001)(199002)(13464002)(377454001)(24454001)(51704002)(54356001)(80022001)(47736001)(54316002)(53806001)(46102001)(47776003)(79102001)(65816001)(63696002)(47976001)(20776003)(69226001)(74662001)(59766001)(23756002)(50466001)(49866001)(66066001)(47446002)(56816002)(77982001)(51856001)(76482001)(50986001)(33656001)(55846006)(74502001)(16406001)(31966008)(5343655001)(56776001)(4396001); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB022; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0782EC617F Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 23:30:48 -0000 Alexandru, >> Were the 3GPP links to have right MAC layers (non kludgy) then maybe DHC= Pv6-PD were used instead of 64share. The actual point is that wherever DHCP-PD is available, it should be used i= nstead of /64share. Not just where there is a "right" MAC layer. So there s= eems to be a violent agreement about the long term direction and that it wi= ll cover the wider scenarios. /64share is not the long term direction - it is a short/mid-term fix. The d= raft says that, and in my opinion, it doesn't need changes in this respect,= because it is intentionally scoped to be a short/mid-term fix for particul= ar types of scenarios. -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of A= lexandru Petrescu Sent: Monday, March 11, 2013 3:59 PM To: Gert Doering Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share= -03 Le 11/03/2013 22:53, Gert Doering a =E9crit : > Hi, > > On Mon, Mar 11, 2013 at 09:32:15PM +0100, Alexandru Petrescu wrote: >> Le 11/03/2013 19:58, Mikael Abrahamsson a =E9crit : >>> On Mon, 11 Mar 2013, Alexandru Petrescu wrote: >>> >>>> We are already the knees deep into thingies. The IPv6 stack (the=20 >>>> one which uses IPv6 addresses, ND, routes, interfaces - as 64share=20 >>>> requires) is faced to these thingies. >>> >>> The USB dongle does this magic in order to emulate a MAC layer=20 >>> towards the OS. It doesn't need to do this, but that's one way of=20 >>> doing it. >> >> This is a kind effort from the USB key - it helps a lot the IPv6=20 >> stack. The stack sees the 3GPP interface just like any other=20 >> Ethernet interface. The stack does not need to do wacky things like=20 >> NO_ARP. > > I'm not sure why you think that this is helpful or kind - it just=20 > complicates things, while PPP interfaces have been around and well-=20 > understood for over 20 years PPP on cellular 3GPP links have failed to evolve for some strange reason. (= many other links have moved away from this ppp nature). When a new kind of link shows up it first gets seen by IPv6 stack as a seri= al, or as a ptp link. Then it slowly evolves to IEEE, MAC addressable, mul= ticast capable links. Now 3GPP links try the same... > - no need for a MAC layer, extra overhead, "smart" firmware breaking =20 > stuff (like "packets coming from the wrong link-layer address" as=20 > necessary consequence of EUI-64 not giving the computer the link-local=20 > address that the network is expecting, etc.) Strange, the absence of a proper MAC layer is what allows 64share to work..= . (no doubt DHCPv6 is not deployed on these MAC-less links, because DHCPv6, l= ike IPv6 ND, rely a lot on having a good MAC layer). >> This is the future of 3GPP interfaces (as opposed to old ptp=20 >> addressless links). > > I hope not. It's a kludge. It may be implemented as what looks like kludgy patch, but it may improve i= n the future. We should let space for that. It may turn in circles, but the first thing this 64share draft says is that= DHCPv6-PD is the right thing to do. And DHCPv6-PD is working better on li= nks which have MAC layers (e.g. during the mulitcast SErver discovery phase= one better has a multicast feature built-in). Were the 3GPP links to have= right MAC layers (non kludgy) then maybe DHCPv6-PD were used instead of 64= share. >> It's not only me who thinks so. Why would manufacturers of 3GPP USB=20 >> keys go through the effort to ask IEEE for Organization IDs, if it=20 >> were not for a belief in a technical advantage of using MAC addresses=20 >> on 3GPP links. > > "It makes windows drivers easier". Yay. Recent linux kernel efforst try to work in the same way as windows ndis dri= vers do with recent USB LTE keys. Alex > > Gert Doering -- NetMaster > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From jouni.nospam@gmail.com Mon Mar 11 16:32:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F3211E80D5 for ; Mon, 11 Mar 2013 16:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.189 X-Spam-Level: X-Spam-Status: No, score=-0.189 tagged_above=-999 required=5 tests=[AWL=0.860, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 jZOGtuLTkCK5 for ; Mon, 11 Mar 2013 16:32:05 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0410A11E80A5 for ; Mon, 11 Mar 2013 16:32:04 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id k13so5529320iea.35 for ; Mon, 11 Mar 2013 16:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=f+OLTQV0vkk2uC/R72a8w4aLIz2pIpa7MONSAxwCzOQ=; b=Ko96HHtg9hb8Tbgk9RDQQme6tUDUDLyn9OHCxCApx7NFEXRRZyvnornRVsQDNdJMHO I1y6ikub7QTuHRZJwKGDIOfT8E0o+mNViwH4DPre4SqT1ntmjw4G3I14clOZ6kfQoEft oHt3bHIqqHMDGGATD2zwVkuvMLoLmdcOVUDZcvndTMj51EBBTeGH6wXs/UQEflSoAmmT z1ifH/QAqNpUT3jzB7VlkoZ1bj1zdTr9Kdi6V7Y2fOPwU22oElVyl2RRiHZAdhZ3jLQU aEH5tx2HoXdCVXgSmvyEE11T2pK683sDLAgHXOiQ9Hc4i63iQUcYv7ut1IHostXGLNp+ Jjng== X-Received: by 10.50.149.233 with SMTP id ud9mr9542733igb.92.1363044724698; Mon, 11 Mar 2013 16:32:04 -0700 (PDT) Received: from ?IPv6:2001:df8::128:c947:8cd5:d3fe:c25a? ([130.129.134.193]) by mx.google.com with ESMTPS id a3sm17143222igq.5.2013.03.11.16.32.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Mar 2013 16:32:04 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jouni Korhonen In-Reply-To: <513E24EC.9020902@gmail.com> Date: Tue, 12 Mar 2013 01:31:58 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 23:32:05 -0000 > > What would one call a cellular link of a cellular operator which does > IPv6 and uses IEEE MAC addresses - are these 3GPP links? It has been repeated quite many times that the 3GPP link has no link-layer addresses. When you see one on your host, someone is playing tricks. - Jouni From alexandru.petrescu@gmail.com Mon Mar 11 16:52:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E876611E8140 for ; Mon, 11 Mar 2013 16:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.91 X-Spam-Level: X-Spam-Status: No, score=-9.91 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLaqtdio7Ttp for ; Mon, 11 Mar 2013 16:52:21 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id B82F611E813F for ; Mon, 11 Mar 2013 16:52:19 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2BNq0Bd026555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Mar 2013 00:52:00 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2BNq0NV013464; Tue, 12 Mar 2013 00:52:00 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.4]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2BNproQ007067; Tue, 12 Mar 2013 00:51:59 +0100 Message-ID: <513E6E00.5000403@gmail.com> Date: Tue, 12 Mar 2013 00:51:28 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: =?ISO-8859-2?Q?V=EDzdal_Ale=B9?= References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <513E3D21.7090905@gmail.com> <513E3FA8.30002@bogus.com> <513E42C9.2050802@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA1419F7@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6DA1419F7@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 23:52:24 -0000 Le 11/03/2013 23:22, Vízdal Ale¹ a écrit : > Alex, > >> -----Original Message----- From: v6ops-bounces@ietf.org >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Monday, March 11, 2013 4:47 PM To: joel jaeggli Cc: >> v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in >> draft-ietf-v6ops-64share-03 >> >> Le 11/03/2013 21:33, joel jaeggli a écrit : >>> On 3/11/13 4:22 PM, Alexandru Petrescu wrote: >>>> >>>> >>>> Additionnally, many operators of these 3GPP links will >>>> appreciate little the use of 64share on devices which they dont >>>> control. (i.e. use 64share on a laptop PC with linux, rather >>>> than on an operator-controlled smartphone). >>>> >>> The policy question seems unrelated to the technical mechanism >>> used for tethering. >> >> If it were not, then DHCPv6-PD for Mobile Routers would be >> correctly specified at 3GPP, and it would be at least in test >> deployment phases. >> >> (AFAIK, DHCPv6-PD is specified in 3GPP but for purposes which cant >> make 'tethering' - to me that's on purpose, policy). > > The 3GPP Rel-10 has introduced DHCP-PD. What's the problem here? As far as I can remember, that is a PD for something in the core, the delegated prefix is for the UE to use on its cellular (not for the UE to use on its WLAN). Were that 3GPP use of DHCPv6-PD to be for a prefix on the UEs WLAN then... Or am I wrong about this? Alex >> In IPv4 there is a unique NAT mechanism, whereas here a number of >> options are on the table: NPT, 64share, DHCPv6-PD. None of these >> is in the 3GPP specs AFAIK. I wonder why if it were not for >> policy... >> >> That said, I also agree that one may leave policy aside and >> implement whatever one likes to - which is especially true when >> inter-operability may not be at stake - which is the case here: we >> only talk this smartphone, which does not need to be interoperable >> with anything, because we assume 3GPP specs forbid the impossible >> thingie cases... which make 64share bound to 3GPP... >> >> Alex > > Ales > > From ales.vizdal@t-mobile.cz Mon Mar 11 16:55:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C54D11E8142 for ; Mon, 11 Mar 2013 16:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXcATX+GzRY2 for ; Mon, 11 Mar 2013 16:55:49 -0700 (PDT) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id C83CE11E8140 for ; Mon, 11 Mar 2013 16:55:47 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id C1A43285820; Tue, 12 Mar 2013 00:55:46 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Tue, 12 Mar 2013 00:55:46 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu Date: Tue, 12 Mar 2013 00:55:44 +0100 Thread-Topic: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 Thread-Index: Ac4es3lmoLCq+3ycSiCJdl4xn3G8ZAAABzjQ Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6DA141A01@SRVHKE02.rdm.cz> References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <513E3D21.7090905@gmail.com> <513E3FA8.30002@bogus.com> <513E42C9.2050802@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA1419F7@SRVHKE02.rdm.cz> <513E6E00.5000403@gmail.com> In-Reply-To: <513E6E00.5000403@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 23:55:49 -0000 > > The 3GPP Rel-10 has introduced DHCP-PD. What's the problem here? >=20 > As far as I can remember, that is a PD for something in the core, the > delegated prefix is for the UE to use on its cellular (not for the UE to > use on its WLAN). >=20 > Were that 3GPP use of DHCPv6-PD to be for a prefix on the UEs WLAN then..= . >=20 > Or am I wrong about this? You seem to be wrong here as the PD is intended for an UE to delegate a pre= fix to a LAN. > Alex Ales From owen@delong.com Mon Mar 11 17:05:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D250221F9092 for ; Mon, 11 Mar 2013 17:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHQP6Sya2yBH for ; Mon, 11 Mar 2013 17:05:57 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 526B321F906B for ; Mon, 11 Mar 2013 17:05:56 -0700 (PDT) Received: from [10.255.251.216] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2C04uS6025195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Mar 2013 17:04:57 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2C04uS6025195 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363046697; bh=5w0FsfQrg4KFYGvezSiyy4UkHzU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Yop6E7Feva44nyH1NsnoXGiDhYxVhcP/xaUlZilMwN9Yqjc5GvA86A0tneajShbo0 vCEYXcqHrp2glrjrrluKmweiO4chb7iBoShplChKrS8rTzoSnzg96Z7gKsReu/GJub EibBChU0l0Y1AP/rqYJEWbr5kyOu1lIL8upKRDks= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <20130311224201.C24B230B9425@drugs.dv.isc.org> Date: Mon, 11 Mar 2013 17:04:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <12897BE3-E798-482B-8841-95D600E0FCA5@delong.com> References: <512CF682.8030307@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6D11E055F@SRVHKE02.rdm.cz> <5130B665.1020907@gmail.com> <8D4B01C4-EC43-48A4-BC15-A4D2DC5CACC2@delong.com> <513E0D5F.4010904@gmail.com> <20130311224201.C24B230B9425@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 11 Mar 2013 17:04:57 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 00:05:57 -0000 On Mar 11, 2013, at 3:42 PM, Mark Andrews wrote: >=20 > In message , Owen = DeLong writes: >>=20 >>> (remark these implementations will fail also when the new NAT space >>> 100./10 is employed, instead of RFC1918). >>=20 >> No, they won't. The new space is intended not as an end-user space, >> but for the intermediate space used by ISPs. The application should >> never see it (or should see it as "public address" space on the other >> side of the NAT. >=20 > Of course applications will see it. If you are directly connected > applications are expected to see it. 100/10 prevents RFC 1918 > either side of a CPE router. No=85 100.64/10 is intended to provide for RFC-1918 on the customer side of the CPE and 100.64/10 on the Carrier side. You really should read the relevant drafts again if you are still = confused about this. Owen From farmer@umn.edu Mon Mar 11 17:26:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D387921F8F43 for ; Mon, 11 Mar 2013 17:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 MUv0tNCq3lB5 for ; Mon, 11 Mar 2013 17:26:45 -0700 (PDT) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id 312D721F8F3C for ; Mon, 11 Mar 2013 17:26:45 -0700 (PDT) Received: from mail-oa0-f70.google.com (mail-oa0-f70.google.com [209.85.219.70]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 11 Mar 2013 19:26:34 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-oa0-f70.google.com [209.85.219.70] #+LO+TR X-Umn-Classification: local Received: by mail-oa0-f70.google.com with SMTP id h2so26368021oag.9 for ; Mon, 11 Mar 2013 17:26:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=g05/6dyE15HCxLrnP/nKPMa/pIEFB4sCacbgNiJtFuU=; b=fxPF8cBSLVa028A63CLiatUtKcmrWZlIEYnDi50l5OpNZ0y87016HdSZVUG3FGIcHm ypNMzDdeib+VjGKu61bBpptxCf9sBeb/yAaxdPM1SBYr6xsqesuw8IpTj/SJyFQc/lSp 63mNMFfi5E773GVwea79I1QQWGAl80U9nbDk0h4jpN14SCcajxHf880ENz/6LSYeBy5h N0BcknOhsV9T+ovAItZEcw5wxxvB6ArTPuikC8LMySGeOUqp2lnj2cUqA5oaTy0lqOwW JNqRfOKRZEvZH6MzjCKlCQ6V4IoHSF7/zx1s+iC4A2Mi05AQzbs2/r5FBhaxjGrEFzRv 18IQ== X-Received: by 10.50.57.166 with SMTP id j6mr9734447igq.21.1363047993927; Mon, 11 Mar 2013 17:26:33 -0700 (PDT) X-Received: by 10.50.57.166 with SMTP id j6mr9734441igq.21.1363047993802; Mon, 11 Mar 2013 17:26:33 -0700 (PDT) Received: from x-134-84-88-33.nts.umn.edu ([2607:ea00:101:2001:5977:8d58:ea34:1bf3]) by mx.google.com with ESMTPS id ip2sm15973080igc.5.2013.03.11.17.26.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Mar 2013 17:26:32 -0700 (PDT) Message-ID: <513E7637.6050900@umn.edu> Date: Mon, 11 Mar 2013 19:26:31 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Owen DeLong References: <512CF682.8030307@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6D11E055F@SRVHKE02.rdm.cz> <5130B665.1020907@gmail.com> <8D4B01C4-EC43-48A4-BC15-A4D2DC5CACC2@delong.com> <513E0D5F.4010904@gmail.com> <20130311224201.C24B230B9425@drugs.dv.isc.org> <12897BE3-E798-482B-8841-95D600E0FCA5@delong.com> In-Reply-To: <12897BE3-E798-482B-8841-95D600E0FCA5@delong.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQkrXqx1nWlbaJ5zUim/+p/OHqdviOTlFwhkUReBuk6JK53jTBqTRifEpC30zG8eroDNniL5LaEjo84AF26imtxwaNkFrPSdBt4doCZwvjwJLp37/oA7e0wHVyJnQb56/+uZyAqP Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 00:26:46 -0000 On 3/11/13 19:04 , Owen DeLong wrote: > > On Mar 11, 2013, at 3:42 PM, Mark Andrews wrote: > >> >> In message , Owen DeLong writes: >>> >>>> (remark these implementations will fail also when the new NAT space >>>> 100./10 is employed, instead of RFC1918). >>> >>> No, they won't. The new space is intended not as an end-user space, >>> but for the intermediate space used by ISPs. The application should >>> never see it (or should see it as "public address" space on the other >>> side of the NAT. >> >> Of course applications will see it. If you are directly connected >> applications are expected to see it. 100/10 prevents RFC 1918 >> either side of a CPE router. > > No… 100.64/10 is intended to provide for RFC-1918 on the customer > side of the CPE and 100.64/10 on the Carrier side. > > You really should read the relevant drafts again if you are still confused > about this. Actually, 100.64.0.0/10 is allowed to be used on both the carrier side and the customer side of a CPE, IFF the CPE is capable of having the same addresses on both sides. Sometimes referred to as bi-direction or double NAT. Otherwise, it SHOULD only be use on the carrier side. I'm not aware of most consumer grade NAT boxes meeting this requirement. Therefore generally, 100.64.0.0/10 should only be allow on the carrier side of a CPE NAT and RFC 1918 on the customer side. So, I wouldn't make any absolute assumptions about 100.64.0.0/10. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From owen@delong.com Mon Mar 11 17:51:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6CC21F8DAE for ; Mon, 11 Mar 2013 17:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 WbLAEJFoEsk3 for ; Mon, 11 Mar 2013 17:51:06 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 8343021F8DA6 for ; Mon, 11 Mar 2013 17:51:05 -0700 (PDT) Received: from [10.255.251.216] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2C0o8ug026410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Mar 2013 17:50:09 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2C0o8ug026410 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363049409; bh=44fl/JTBfTRpI4mV0OyKp/zK7U4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=VmqpMekan5TSEdKl174SBFf7IpxLUri8ypOF5fqOz0mcYC4wcNAS98fAV2NUA0EZQ cGYud4TMdS0cj4nHn0zxJsRw+cE0hMboUs3TPqpDBfrjM5hS7jg/OPLgu4glqhMsm/ Q0RdEsxIMoAXXTTy/Vdb4/gKjPb4GkNRTPOm7zvk= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <513E7637.6050900@umn.edu> Date: Mon, 11 Mar 2013 17:50:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7C1B42E8-9506-4FA5-B484-85F363AF74E9@delong.com> References: <512CF682.8030307@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6D11E055F@SRVHKE02.rdm.cz> <5130B665.1020907@gmail.com> <8D4B01C4-EC43-48A4-BC15-A4D2DC5CACC2@delong.com> <513E0D5F.4010904@gmail.com> <20130311224201.C24B230B9425@drugs.dv.isc.org> <12897BE3-E798-482B-8841-95D600E0FCA5@delong.com> <513E7637.6050900@umn.edu> To: David Farmer X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 11 Mar 2013 17:50:09 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 00:51:09 -0000 On Mar 11, 2013, at 5:26 PM, David Farmer wrote: > On 3/11/13 19:04 , Owen DeLong wrote: >>=20 >> On Mar 11, 2013, at 3:42 PM, Mark Andrews wrote: >>=20 >>>=20 >>> In message , Owen = DeLong writes: >>>>=20 >>>>> (remark these implementations will fail also when the new NAT = space >>>>> 100./10 is employed, instead of RFC1918). >>>>=20 >>>> No, they won't. The new space is intended not as an end-user space, >>>> but for the intermediate space used by ISPs. The application should >>>> never see it (or should see it as "public address" space on the = other >>>> side of the NAT. >>>=20 >>> Of course applications will see it. If you are directly connected >>> applications are expected to see it. 100/10 prevents RFC 1918 >>> either side of a CPE router. >>=20 >> No=85 100.64/10 is intended to provide for RFC-1918 on the customer >> side of the CPE and 100.64/10 on the Carrier side. >>=20 >> You really should read the relevant drafts again if you are still = confused >> about this. >=20 > Actually, 100.64.0.0/10 is allowed to be used on both the carrier side = and the customer side of a CPE, IFF the CPE is capable of having the = same addresses on both sides. Sometimes referred to as bi-direction or = double NAT. Otherwise, it SHOULD only be use on the carrier side. I'm = not aware of most consumer grade NAT boxes meeting this requirement. = Therefore generally, 100.64.0.0/10 should only be allow on the carrier = side of a CPE NAT and RFC 1918 on the customer side. >=20 Hmm=85 It seems that the prohibition against that usage was lost when we = abandoned the companion document (draft-bdgks). That's unfortunate. However, I think RFC-6598 makes it pretty clear that use of 100.64/10 = for customer-side networking is at the very least strongly discouraged = and that the primary purpose for allocating 100.64/10 as shared = transition space was to create a distinct space for CGN that would not = conflict with customer-side use of RFC-1918. > So, I wouldn't make any absolute assumptions about 100.64.0.0/10. I think you could basically say the same thing about most of IPv4 in = general at this point. Owen From marka@isc.org Mon Mar 11 18:59:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F3321F8AC1 for ; Mon, 11 Mar 2013 18:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 nFAees5tkRih for ; Mon, 11 Mar 2013 18:59:20 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id EFAEE21F8AC0 for ; Mon, 11 Mar 2013 18:59:19 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 9328FC958F; Tue, 12 Mar 2013 01:59:12 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363053559; bh=o1aTP3hN3LBr6YSyM72gLLIeLGfapKbtkLsH1N2p+ZY=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=RdPDU1qsPi8CssEk5ltTHX2g36/DTgY22WBPoJuPYaEI9gXWIyQxQ6d6ArstLVujI LNARnhAZ1/7oU/eozIrrLRHw1vKhV8Zgo16n3QIGt0We6CdAm+kbwroUwn6Lq5E/yK KK9Q4fKZNBu4J02EwsgOjrWcD9hxqSujOlNWoUIM= 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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Tue, 12 Mar 2013 01:59:12 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:fc43:5f9f:1cde:d9ad]) (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 51796216C40; Tue, 12 Mar 2013 01:59:12 +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 EAD7930BB67A; Tue, 12 Mar 2013 12:59:01 +1100 (EST) To: Owen DeLong From: Mark Andrews References: <512CF682.8030307@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6D11E055F@SRVHKE02.rdm.cz> <5130B665.1020907@gmail.com> <8D4B01C4-EC43-48A4-BC15-A4D2DC5CACC2@delong.com> <513E0D5F.4010904@gmail.com> <20130311224201.C24B230B9425@drugs.dv.isc.org> <12897BE3-E798-482B-8841-95D600E0FCA5@delong.com> In-reply-to: Your message of "Mon, 11 Mar 2013 17:04:55 PDT." <12897BE3-E798-482B-8841-95D600E0FCA5@delong.com> Date: Tue, 12 Mar 2013 12:58:57 +1100 Message-Id: <20130312015901.EAD7930BB67A@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 01:59:20 -0000 In message <12897BE3-E798-482B-8841-95D600E0FCA5@delong.com>, Owen DeLong writes: > > On Mar 11, 2013, at 3:42 PM, Mark Andrews wrote: > > >=20 > > In message , Owen = > DeLong writes: > >>=20 > >>> (remark these implementations will fail also when the new NAT space > >>> 100./10 is employed, instead of RFC1918). > >>=20 > >> No, they won't. The new space is intended not as an end-user space, > >> but for the intermediate space used by ISPs. The application should > >> never see it (or should see it as "public address" space on the other > >> side of the NAT. > >=20 > > Of course applications will see it. If you are directly connected > > applications are expected to see it. 100/10 prevents RFC 1918 > > either side of a CPE router. > > No=85 100.64/10 is intended to provide for RFC-1918 on the customer > side of the CPE and 100.64/10 on the Carrier side. > > You really should read the relevant drafts again if you are still = > confused > about this. Sorry Owen, you are the one that is confused here. The ISP assigns 100.64/10 to *all* its customers as it has no way of knowing if the device is a router or host. The home CPE router masquerade as a host. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owen@delong.com Mon Mar 11 19:16:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A0021F8BEA for ; Mon, 11 Mar 2013 19:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 oTjlsTa3IWT2 for ; Mon, 11 Mar 2013 19:16:15 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D20C721F8BE9 for ; Mon, 11 Mar 2013 19:16:14 -0700 (PDT) Received: from [10.255.251.216] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2C2Fnou027897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Mar 2013 19:15:50 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2C2Fnou027897 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363054550; bh=n/TbaYVrqEZf7GUWzKlRNszOWXI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ADSGxt9EXRsIE6K5569pV8iMGrlJejELU/b2yGJHrrqMZfgg+oE9LLoampcbB5OJi Y0AFeKxbj7q00dSKAuT2cRG8hMyeBOnfbzToEqvlkJnD6gR12u9pApacgIUF1f3BWg 9/urhgMwnrbfN43mLuudv55sH4kTMlq2clCrMIPA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <20130312015901.EAD7930BB67A@drugs.dv.isc.org> Date: Mon, 11 Mar 2013 19:15:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2182BA1D-B2A2-445F-9962-338E2F0DE351@delong.com> References: <512CF682.8030307@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6D11E055F@SRVHKE02.rdm.cz> <5130B665.1020907@gmail.com> <8D4B01C4-EC43-48A4-BC15-A4D2DC5CACC2@delong.com> <513E0D5F.4010904@gmail.com> <20130311224201.C24B230B9425@drugs.dv.isc.org> <12897BE3-E798-482B-8841-95D600E0FCA5@delong.com> <20130312015901.EAD7930BB67A@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 11 Mar 2013 19:15:50 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 02:16:16 -0000 On Mar 11, 2013, at 6:58 PM, Mark Andrews wrote: >=20 > In message <12897BE3-E798-482B-8841-95D600E0FCA5@delong.com>, Owen = DeLong writes: >>=20 >> On Mar 11, 2013, at 3:42 PM, Mark Andrews wrote: >>=20 >>> =3D20 >>> In message , Owen =3D= >> DeLong writes: >>>> =3D20 >>>>> (remark these implementations will fail also when the new NAT = space >>>>> 100./10 is employed, instead of RFC1918). >>>> =3D20 >>>> No, they won't. The new space is intended not as an end-user space, >>>> but for the intermediate space used by ISPs. The application should >>>> never see it (or should see it as "public address" space on the = other >>>> side of the NAT. >>> =3D20 >>> Of course applications will see it. If you are directly connected >>> applications are expected to see it. 100/10 prevents RFC 1918 >>> either side of a CPE router. >>=20 >> No=3D85 100.64/10 is intended to provide for RFC-1918 on the customer >> side of the CPE and 100.64/10 on the Carrier side. >>=20 >> You really should read the relevant drafts again if you are still =3D >> confused >> about this. >=20 > Sorry Owen, you are the one that is confused here. >=20 > The ISP assigns 100.64/10 to *all* its customers as it has no way > of knowing if the device is a router or host. The home CPE router > masquerade as a host.=20 >=20 Sure, but almost nobody does that these days. I'm still having trouble figuring out what you meant by "100/10 prevents = RFC 1918 either side of a CPE router." if you didn't mean that customers were = expected not to use RFC-1918 in an environment where the provider is using 100.64/10. If that is what you meant, then I stand by my original statement with = the exception that those few remaining end-users without routers will, in fact, receive = 100.64/10 addresses on their host directly from the provider. Owen From alexandru.petrescu@gmail.com Mon Mar 11 20:38:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD7521F8904 for ; Mon, 11 Mar 2013 20:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.07 X-Spam-Level: X-Spam-Status: No, score=-10.07 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q98vC0isWMP3 for ; Mon, 11 Mar 2013 20:38:18 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 805A721F88EF for ; Mon, 11 Mar 2013 20:38:18 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2C3cH3g003702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Mar 2013 04:38:17 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2C3cGRi004389; Tue, 12 Mar 2013 04:38:16 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.2]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2C3c96d024744; Tue, 12 Mar 2013 04:38:15 +0100 Message-ID: <513EA308.6050405@gmail.com> Date: Tue, 12 Mar 2013 04:37:44 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Jouni Korhonen References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 03:38:19 -0000 Le 12/03/2013 00:31, Jouni Korhonen a écrit : >> >> What would one call a cellular link of a cellular operator which does >> IPv6 and uses IEEE MAC addresses - are these 3GPP links? > > It has been repeated quite many times that the 3GPP link has no > link-layer addresses. > > When you see one on your host, someone is playing tricks. And who's that? 3GPP cant stop him/her from doing so - it's on the market, and in the kernel. Alex > > - Jouni > From alexandru.petrescu@gmail.com Mon Mar 11 20:39:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F60F21F84B8 for ; Mon, 11 Mar 2013 20:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.929 X-Spam-Level: X-Spam-Status: No, score=-9.929 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiXCoSQblm9J for ; Mon, 11 Mar 2013 20:39:45 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id B54E921F84C1 for ; Mon, 11 Mar 2013 20:39:42 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2C3dStM020687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Mar 2013 04:39:28 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2C3dSYL004501; Tue, 12 Mar 2013 04:39:28 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.2]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2C3dOd4024998; Tue, 12 Mar 2013 04:39:27 +0100 Message-ID: <513EA353.7020708@gmail.com> Date: Tue, 12 Mar 2013 04:38:59 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: =?ISO-8859-2?Q?V=EDzdal_Ale=B9?= References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <513E3D21.7090905@gmail.com> <513E3FA8.30002@bogus.com> <513E42C9.2050802@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA1419F7@SRVHKE02.rdm.cz> <513E6E00.5000403@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA141A01@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6DA141A01@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 03:39:45 -0000 Le 12/03/2013 00:55, Vízdal Ale¹ a écrit : >>> The 3GPP Rel-10 has introduced DHCP-PD. What's the problem here? >> >> As far as I can remember, that is a PD for something in the core, the >> delegated prefix is for the UE to use on its cellular (not for the UE to >> use on its WLAN). >> >> Were that 3GPP use of DHCPv6-PD to be for a prefix on the UEs WLAN then... >> >> Or am I wrong about this? > > You seem to be wrong here as the PD is intended for an UE to delegate a prefix to a LAN. Please point me to the 3GPP ref? (last time I checked it was a prefix for the UE on its 3GPP link) Alex > >> Alex > > Ales > > From ales.vizdal@t-mobile.cz Mon Mar 11 20:50:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E8D21F8960 for ; Mon, 11 Mar 2013 20:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+94qPraBaFc for ; Mon, 11 Mar 2013 20:50:25 -0700 (PDT) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1D421F8920 for ; Mon, 11 Mar 2013 20:50:25 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 835DE28581A; Tue, 12 Mar 2013 04:50:24 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Tue, 12 Mar 2013 04:50:24 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu Date: Tue, 12 Mar 2013 04:50:19 +0100 Thread-Topic: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 Thread-Index: Ac4e0z2wIxMZjx9DRzqaZyuM5qCS0wAAUK1Q Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6DA141A05@SRVHKE02.rdm.cz> References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <513E3D21.7090905@gmail.com> <513E3FA8.30002@bogus.com> <513E42C9.2050802@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA1419F7@SRVHKE02.rdm.cz> <513E6E00.5000403@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA141A01@SRVHKE02.rdm.cz> <513EA353.7020708@gmail.com> In-Reply-To: <513EA353.7020708@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 03:50:27 -0000 Hi Alex, let's start with TS 29.061 version 10.0.0, Section 11.2.1.3.5 IPv6 Prefix D= elegation via DHCPv6 that includes further references. (http://www.3gpp.org/ftp/Specs/archive/29= _series/29.061/29061-a00.zip) Cheers, Ales > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Monday, March 11, 2013 11:39 PM > To: V=EDzdal Ale=B9 > Cc: joel jaeggli; v6ops@ietf.org > Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64sha= re-03 >=20 > Le 12/03/2013 00:55, V=EDzdal Ale=B9 a =E9crit : > >>> The 3GPP Rel-10 has introduced DHCP-PD. What's the problem here? > >> > >> As far as I can remember, that is a PD for something in the core, the > >> delegated prefix is for the UE to use on its cellular (not for the UE = to > >> use on its WLAN). > >> > >> Were that 3GPP use of DHCPv6-PD to be for a prefix on the UEs WLAN the= n... > >> > >> Or am I wrong about this? > > > > You seem to be wrong here as the PD is intended for an UE to delegate a= prefix to a > LAN. >=20 > Please point me to the 3GPP ref? >=20 > (last time I checked it was a prefix for the UE on its 3GPP link) >=20 > Alex >=20 > > > >> Alex > > > > Ales > > > > >=20 From marka@isc.org Mon Mar 11 20:53:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8928421F8A5E for ; Mon, 11 Mar 2013 20:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 XsyVWbanR-EC for ; Mon, 11 Mar 2013 20:53:07 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD6A21F8960 for ; Mon, 11 Mar 2013 20:53:07 -0700 (PDT) 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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 0982A5F9861; Tue, 12 Mar 2013 03:52:58 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363060386; bh=KMlICsW3FVu4TvjucIcbOs8gqbuUBADSuLXM5qwMC6E=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=T/iV1Wn4GH2WwiT5F3A/0PoISTbI1cSYo6qwBQmjehidEMPdeyAV30+Dm2iZb8fe0 Zhp64JcyLRphXtLQoSuh4wvNAtokiLqonuYgxtwIORdrjlfg3ewNZTMOx25d9d/VE8 9VWQSs36twhQHamAMmhIpBkCdmhNuRiqrS9ot3GY= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 09019216C3B; Tue, 12 Mar 2013 03:52:57 +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 1DF2330BEFD3; Tue, 12 Mar 2013 14:52:54 +1100 (EST) To: Owen DeLong From: Mark Andrews References: <512CF682.8030307@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6D11E055F@SRVHKE02.rdm.cz> <5130B665.1020907@gmail.com> <8D4B01C4-EC43-48A4-BC15-A4D2DC5CACC2@delong.com> <513E0D5F.4010904@gmail.com> <20130311224201.C24B230B9425@drugs.dv.isc.org> <12897BE3-E798-482B-8841-95D600E0FCA5@delong.com> <20130312015901.EAD7930BB67A@drugs.dv.isc.org> <2182BA1D-B2A2-445F-9962-338E2F0DE351@delong.com> In-reply-to: Your message of "Mon, 11 Mar 2013 19:15:48 PDT." <2182BA1D-B2A2-445F-9962-338E2F0DE351@delong.com> Date: Tue, 12 Mar 2013 14:52:54 +1100 Message-Id: <20130312035254.1DF2330BEFD3@drugs.dv.isc.org> Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 03:53:08 -0000 In message <2182BA1D-B2A2-445F-9962-338E2F0DE351@delong.com>, Owen DeLong writes: > > On Mar 11, 2013, at 6:58 PM, Mark Andrews wrote: > > > > > In message <12897BE3-E798-482B-8841-95D600E0FCA5@delong.com>, Owen > DeLong writes: > >> > >> On Mar 11, 2013, at 3:42 PM, Mark Andrews wrote: > >> > >>> =20 > >>> In message , Owen = > >> DeLong writes: > >>>> =20 > >>>>> (remark these implementations will fail also when the new NAT space > >>>>> 100./10 is employed, instead of RFC1918). > >>>> =20 > >>>> No, they won't. The new space is intended not as an end-user space, > >>>> but for the intermediate space used by ISPs. The application should > >>>> never see it (or should see it as "public address" space on the other > >>>> side of the NAT. > >>> =20 > >>> Of course applications will see it. If you are directly connected > >>> applications are expected to see it. 100/10 prevents RFC 1918 > >>> either side of a CPE router. > >> > >> No=85 100.64/10 is intended to provide for RFC-1918 on the customer > >> side of the CPE and 100.64/10 on the Carrier side. > >> > >> You really should read the relevant drafts again if you are still = > >> confused > >> about this. > > > > Sorry Owen, you are the one that is confused here. > > > > The ISP assigns 100.64/10 to *all* its customers as it has no way > > of knowing if the device is a router or host. The home CPE router > > masquerade as a host. > > > > Sure, but almost nobody does that these days. > > I'm still having trouble figuring out what you meant by "100/10 prevents > RFC 1918 > either side of a CPE router." if you didn't mean that customers were > expected not > to use RFC-1918 in an environment where the provider is using 100.64/10. 100.64/10 is designed to prevent RFC 1918 on both sides of the border CPE router. > If that is what you meant, then I stand by my original statement with the > exception that > those few remaining end-users without routers will, in fact, receive > 100.64/10 > addresses on their host directly from the provider. Well you claimed "never". If a host/router sees that one of its addresses is in 100.64/10 then it can assume that the address is behind a NAT. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From swmike@swm.pp.se Mon Mar 11 21:22:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C87D21F863F for ; Mon, 11 Mar 2013 21:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuEOXCdDbZZk for ; Mon, 11 Mar 2013 21:22:03 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 37F3321F8639 for ; Mon, 11 Mar 2013 21:21:56 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 14C149C; Tue, 12 Mar 2013 05:21:54 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 082AE9A; Tue, 12 Mar 2013 05:21:54 +0100 (CET) Date: Tue, 12 Mar 2013 05:21:54 +0100 (CET) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <513E6707.6010905@gmail.com> Message-ID: References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA1419F6@SRVHKE02.rdm.cz> <513E6707.6010905@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 04:22:04 -0000 On Tue, 12 Mar 2013, Alexandru Petrescu wrote: > Yes, I am talking about what the IPv6 stack on the PC sees: it sees > Ethernet-encapsulated IPv6 packets. This IPv6 stack on the PC > supposedly implements 64share. In some cases, yes. The sticks usually have two operating modes. Put the same usb stick in a linux machine and it'll see a ppp0. > (64share would not be implemented on 3GPP USB keys). On USB keys that presents a MAC layer to the OS that is. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Mon Mar 11 21:24:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5AAC21F8507 for ; Mon, 11 Mar 2013 21:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 45abDDQCRjgz for ; Mon, 11 Mar 2013 21:24:35 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 4403C21F84D1 for ; Mon, 11 Mar 2013 21:24:35 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 925879E; Tue, 12 Mar 2013 05:24:34 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8D2439A; Tue, 12 Mar 2013 05:24:34 +0100 (CET) Date: Tue, 12 Mar 2013 05:24:34 +0100 (CET) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <513EA353.7020708@gmail.com> Message-ID: References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <513E3D21.7090905@gmail.com> <513E3FA8.30002@bogus.com> <513E42C9.2050802@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA1419F7@SRVHKE02.rdm.cz> <513E6E00.5000403@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA141A01@SRVHKE02.rdm.cz> <513EA353.7020708@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 04:24:40 -0000 On Tue, 12 Mar 2013, Alexandru Petrescu wrote: >> You seem to be wrong here as the PD is intended for an UE to delegate a >> prefix to a LAN. > > Please point me to the 3GPP ref? > > (last time I checked it was a prefix for the UE on its 3GPP link) Not for *prefix delegation*. Otoh it's said that the 3GPP /64 should be part of of the larger PD prefix (for instance a /56). -- Mikael Abrahamsson email: swmike@swm.pp.se From volz@cisco.com Tue Mar 12 04:40:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FEA21F85FC for ; Tue, 12 Mar 2013 04:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.185 X-Spam-Level: X-Spam-Status: No, score=-10.185 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiYFsp3eqFIH for ; Tue, 12 Mar 2013 04:40:45 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2F57421F85ED for ; Tue, 12 Mar 2013 04:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1071; q=dns/txt; s=iport; t=1363088445; x=1364298045; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4JPp8YjYzv3xm24ED0Kqlr5Fm4oshigvKto5c6Y/G2w=; b=R/Rh9TXr/mwuULrNS26woZFkKFvfoc/w9vugvtMzEdu4lB0axxuEWkz7 G5WoMkJxDRtJ0dLPFf7pHcmhfZ4Et2D7Se/zObyIlWIOSyu9Nd7hp+mm6 ET9UF+yzg6c6C0c0yTvYsAzABdtqMRVOLCsYuOlAgnkQIWUmZhMRq0FtN w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAI0TP1GtJXG//2dsb2JhbABDxGGBShZ0gigBAQEDATo/BQsCAQg2EDIlAgQOBRuHcgavfpALF45aMweCX2EDllWQdYMK X-IronPort-AV: E=Sophos;i="4.84,830,1355097600"; d="scan'208";a="186485902" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 12 Mar 2013 11:40:44 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2CBeiSK005257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Mar 2013 11:40:44 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 06:40:44 -0500 From: "Bernie Volz (volz)" To: v6ops WG Thread-Topic: Looking at RFC Editor Queue Thread-Index: AQHOHxH/oxdItfgnLkKU5Y/ZoZw/h5ih7rha Date: Tue, 12 Mar 2013 11:40:44 +0000 Message-ID: <192C0479-210F-48BE-BC61-F9DE0ED12532@cisco.com> References: <8C48B86A895913448548E6D15DA7553B7CB9EF@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B7CB9EF@xmb-rcd-x09.cisco.com> 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: Dhc Chairs , v6ops chairs , Ralph Droms , "v6ops-ads@tools.ietf.org" Subject: Re: [v6ops] Looking at RFC Editor Queue X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 11:40:46 -0000 This work stalled but was recently picked up again. Some issues were recent= ly raised and those need to be addressed (whether single infrequent Solicit= s might fail to ever allow the client to get a response from server if ND r= esolution causes packet to be dropped and the ND entry expires before next = retransmission - proposed solution is to do several transmissions with shor= t intervals.) - Bernie On Mar 12, 2013, at 7:09 AM, "Fred Baker (fred)" wrote: > We have some documents that are waiting for normative references, in one = case for more than a year. Could you please tell us the status of your work= ? >=20 > Thanks >=20 >=20 > 2012-11-01 draft-ietf-v6ops-6204bis-12.txt [C158] >=20 > MISSREF*R(1G) > REF draft-droms-dhc-dhcpv6-solmaxrt-update NOT-RECEIVED > H. Singh, W. Beebee, C. Donley, B. Stark > "Basic Requirements for IPv6 Customer Edge Routers" > Bytes: 50527 > Working Group: IPv6 Operations >=20 > 2012-02-21 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt [C= 156] >=20 From alexandru.petrescu@gmail.com Tue Mar 12 05:01:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D30B21F8632 for ; Tue, 12 Mar 2013 05:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.779 X-Spam-Level: X-Spam-Status: No, score=-9.779 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyMnjJ4OiHMq for ; Tue, 12 Mar 2013 05:01:36 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 979B221F8606 for ; Tue, 12 Mar 2013 05:01:36 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2CC1Zkx018183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Mar 2013 13:01:35 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2CC1Zw8031094; Tue, 12 Mar 2013 13:01:35 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.25]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2CC1Svg018829; Tue, 12 Mar 2013 13:01:34 +0100 Message-ID: <513F18FF.2060700@gmail.com> Date: Tue, 12 Mar 2013 13:01:03 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Dmitry Anipko References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> <513E61B2.2000307@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 12:01:37 -0000 Le 12/03/2013 00:29, Dmitry Anipko a écrit : > Alexandru, > >>> Were the 3GPP links to have right MAC layers (non kludgy) then >>> maybe DHCPv6-PD were used instead of 64share. > > The actual point is that wherever DHCP-PD is available, it should be > used instead of /64share. Not just where there is a "right" MAC > layer. So there seems to be a violent agreement about the long term > direction and that it will cover the wider scenarios. YEs, the long term intention is right. I agree in the long term one should use DHCPv6-PD to get a prefix for the WLAN of the UE connected on LTE. The only minor comment here is that I think (just suppose), from my recollection, that 3GPP specs need some clarification about this DHCPv6-PD use. > /64share is not the long term direction - it is a short/mid-term > fix. The draft says that, and in my opinion, it doesn't need changes > in this respect, because it is intentionally scoped to be a > short/mid-term fix for particular types of scenarios. Yes, right. It does not need to stress it is a midterm solution. It is already said. On another hand, for each one of the 3 scenarios, if 64share receives a NS from the network about the IPv6 address within the /64 - it will break. Alex > > -----Original Message----- From: v6ops-bounces@ietf.org > [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Monday, March 11, 2013 3:59 PM To: Gert Doering Cc: > v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in > draft-ietf-v6ops-64share-03 > > Le 11/03/2013 22:53, Gert Doering a écrit : >> Hi, >> >> On Mon, Mar 11, 2013 at 09:32:15PM +0100, Alexandru Petrescu >> wrote: >>> Le 11/03/2013 19:58, Mikael Abrahamsson a écrit : >>>> On Mon, 11 Mar 2013, Alexandru Petrescu wrote: >>>> >>>>> We are already the knees deep into thingies. The IPv6 stack >>>>> (the one which uses IPv6 addresses, ND, routes, interfaces - >>>>> as 64share requires) is faced to these thingies. >>>> >>>> The USB dongle does this magic in order to emulate a MAC layer >>>> towards the OS. It doesn't need to do this, but that's one >>>> way of doing it. >>> >>> This is a kind effort from the USB key - it helps a lot the IPv6 >>> stack. The stack sees the 3GPP interface just like any other >>> Ethernet interface. The stack does not need to do wacky things >>> like NO_ARP. >> >> I'm not sure why you think that this is helpful or kind - it just >> complicates things, while PPP interfaces have been around and well- >> understood for over 20 years > > PPP on cellular 3GPP links have failed to evolve for some strange > reason. (many other links have moved away from this ppp nature). > > When a new kind of link shows up it first gets seen by IPv6 stack as > a serial, or as a ptp link. Then it slowly evolves to IEEE, MAC > addressable, multicast capable links. Now 3GPP links try the > same... > >> - no need for a MAC layer, extra overhead, "smart" firmware >> breaking stuff (like "packets coming from the wrong link-layer >> address" as necessary consequence of EUI-64 not giving the >> computer the link-local address that the network is expecting, >> etc.) > > Strange, the absence of a proper MAC layer is what allows 64share to > work... > > (no doubt DHCPv6 is not deployed on these MAC-less links, because > DHCPv6, like IPv6 ND, rely a lot on having a good MAC layer). > >>> This is the future of 3GPP interfaces (as opposed to old ptp >>> addressless links). >> >> I hope not. It's a kludge. > > It may be implemented as what looks like kludgy patch, but it may > improve in the future. We should let space for that. > > It may turn in circles, but the first thing this 64share draft says > is that DHCPv6-PD is the right thing to do. And DHCPv6-PD is > working better on links which have MAC layers (e.g. during the > mulitcast SErver discovery phase one better has a multicast feature > built-in). Were the 3GPP links to have right MAC layers (non kludgy) > then maybe DHCPv6-PD were used instead of 64share. > >>> It's not only me who thinks so. Why would manufacturers of 3GPP >>> USB keys go through the effort to ask IEEE for Organization IDs, >>> if it were not for a belief in a technical advantage of using MAC >>> addresses on 3GPP links. >> >> "It makes windows drivers easier". Yay. > > Recent linux kernel efforst try to work in the same way as windows > ndis drivers do with recent USB LTE keys. > > Alex > >> >> Gert Doering -- NetMaster >> > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From alexandru.petrescu@gmail.com Tue Mar 12 05:02:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4889121F8714 for ; Tue, 12 Mar 2013 05:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.924 X-Spam-Level: X-Spam-Status: No, score=-9.924 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GS6kGGC5+iap for ; Tue, 12 Mar 2013 05:02:45 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0AD21F870E for ; Tue, 12 Mar 2013 05:02:45 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2CC2VZm030739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Mar 2013 13:02:31 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2CC2UQF031599; Tue, 12 Mar 2013 13:02:30 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.25]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2CC2RFH019517; Tue, 12 Mar 2013 13:02:29 +0100 Message-ID: <513F193B.3020205@gmail.com> Date: Tue, 12 Mar 2013 13:02:03 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: =?ISO-8859-2?Q?V=EDzdal_Ale=B9?= References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <513E3D21.7090905@gmail.com> <513E3FA8.30002@bogus.com> <513E42C9.2050802@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA1419F7@SRVHKE02.rdm.cz> <513E6E00.5000403@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA141A01@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6DA141A01@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 12:02:46 -0000 Le 12/03/2013 00:55, Vízdal Ale¹ a écrit : >>> The 3GPP Rel-10 has introduced DHCP-PD. What's the problem here? >> >> As far as I can remember, that is a PD for something in the core, >> the delegated prefix is for the UE to use on its cellular (not for >> the UE to use on its WLAN). >> >> Were that 3GPP use of DHCPv6-PD to be for a prefix on the UEs WLAN >> then... >> >> Or am I wrong about this? > > You seem to be wrong here as the PD is intended for an UE to delegate > a prefix to a LAN. Well... I may need to check that once again in the specs and I will come back to the list abou tthis. Alex > >> Alex > > Ales > > From alexandru.petrescu@gmail.com Tue Mar 12 05:05:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B16E21F87D3 for ; Tue, 12 Mar 2013 05:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.075 X-Spam-Level: X-Spam-Status: No, score=-10.075 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5sH2R33zTEk for ; Tue, 12 Mar 2013 05:05:14 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id BBA1721F8706 for ; Tue, 12 Mar 2013 05:05:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2CC5CF8020310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Mar 2013 13:05:12 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2CC5CUS032558; Tue, 12 Mar 2013 13:05:12 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.25]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2CC59pb021108; Tue, 12 Mar 2013 13:05:11 +0100 Message-ID: <513F19DC.8080105@gmail.com> Date: Tue, 12 Mar 2013 13:04:44 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Mikael Abrahamsson References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA1419F6@SRVHKE02.rdm.cz> <513E6707.6010905@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 12:05:15 -0000 Le 12/03/2013 05:21, Mikael Abrahamsson a écrit : > On Tue, 12 Mar 2013, Alexandru Petrescu wrote: > >> Yes, I am talking about what the IPv6 stack on the PC sees: it sees >> Ethernet-encapsulated IPv6 packets. This IPv6 stack on the PC >> supposedly implements 64share. > > In some cases, yes. The sticks usually have two operating modes. Put > the same usb stick in a linux machine and it'll see a ppp0. Yes, and put it on a linux machine and run QMI (qmiclient) instead of pppd and it'll see a wwan0 with MAC addresses just like a wlan0. >> (64share would not be implemented on 3GPP USB keys). > > On USB keys that presents a MAC layer to the OS that is. Yes. I think 64share is not intended to be implemented on any USB keys for that matter (be them with or w/o MAC addresses). Alex > From swmike@swm.pp.se Tue Mar 12 05:32:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D7A21F8A18 for ; Tue, 12 Mar 2013 05:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 i7AuYxsXCFYm for ; Tue, 12 Mar 2013 05:32:25 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5C221F8793 for ; Tue, 12 Mar 2013 05:32:25 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 034B29C; Tue, 12 Mar 2013 13:32:23 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id F28D59A; Tue, 12 Mar 2013 13:32:23 +0100 (CET) Date: Tue, 12 Mar 2013 13:32:23 +0100 (CET) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <513F19DC.8080105@gmail.com> Message-ID: References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA1419F6@SRVHKE02.rdm.cz> <513E6707.6010905@gmail.com> <513F19DC.8080105@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 12:32:25 -0000 On Tue, 12 Mar 2013, Alexandru Petrescu wrote: > I think 64share is not intended to be implemented on any USB keys for > that matter (be them with or w/o MAC addresses). Well, I wouldn't be so sure. There are products out there that take a USB dongle for WWAN connectivity. I would imagine they should be fine to implement 64share if they run the dongle in ppp mode. -- Mikael Abrahamsson email: swmike@swm.pp.se From alexandru.petrescu@gmail.com Tue Mar 12 06:23:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AFE21F8A84 for ; Tue, 12 Mar 2013 06:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.082 X-Spam-Level: X-Spam-Status: No, score=-10.082 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3ezrbOZ06oC for ; Tue, 12 Mar 2013 06:23:50 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id CA98421F8A7B for ; Tue, 12 Mar 2013 06:23:48 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2CDNlrV009925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Mar 2013 14:23:47 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2CDNlvL000471; Tue, 12 Mar 2013 14:23:47 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.20]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2CDNj1r029128; Tue, 12 Mar 2013 14:23:46 +0100 Message-ID: <513F2C48.5070303@gmail.com> Date: Tue, 12 Mar 2013 14:23:20 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Mikael Abrahamsson References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA1419F6@SRVHKE02.rdm.cz> <513E6707.6010905@gmail.com> <513F19DC.8080105@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 13:23:52 -0000 Le 12/03/2013 13:32, Mikael Abrahamsson a écrit : > On Tue, 12 Mar 2013, Alexandru Petrescu wrote: > >> I think 64share is not intended to be implemented on any USB keys >> for that matter (be them with or w/o MAC addresses). > > Well, I wouldn't be so sure. There are products out there that take a > USB dongle for WWAN connectivity. I would imagine they should be > fine to implement 64share if they run the dongle in ppp mode. Do you mean 64share script in the USBkey? Or 64share script in the computer on which the USB key is attached? (I think the latter only). Alex > From ales.vizdal@t-mobile.cz Tue Mar 12 06:30:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8221921F875C for ; Tue, 12 Mar 2013 06:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6EB3Sd2zeUL for ; Tue, 12 Mar 2013 06:30:31 -0700 (PDT) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id E155C21F85FC for ; Tue, 12 Mar 2013 06:30:30 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id BF3BC285812; Tue, 12 Mar 2013 14:30:29 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Tue, 12 Mar 2013 14:30:29 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Mikael Abrahamsson , Alexandru Petrescu Date: Tue, 12 Mar 2013 14:30:22 +0100 Thread-Topic: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 Thread-Index: Ac4e2tVNxeH/53EBShiTiaaOIaIKewASoppw Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6DA141BE7@SRVHKE02.rdm.cz> References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <513E3D21.7090905@gmail.com> <513E3FA8.30002@bogus.com> <513E42C9.2050802@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA1419F7@SRVHKE02.rdm.cz> <513E6E00.5000403@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA141A01@SRVHKE02.rdm.cz> <513EA353.7020708@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 13:30:31 -0000 > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Sent: Tuesday, March 12, 2013 12:25 AM > To: Alexandru Petrescu > Cc: V=EDzdal Ale=B9; v6ops@ietf.org > Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64sha= re-03 >=20 > On Tue, 12 Mar 2013, Alexandru Petrescu wrote: >=20 > >> You seem to be wrong here as the PD is intended for an UE to delegate = a > >> prefix to a LAN. > > > > Please point me to the 3GPP ref? > > > > (last time I checked it was a prefix for the UE on its 3GPP link) >=20 > Not for *prefix delegation*. >=20 > Otoh it's said that the 3GPP /64 should be part of of the larger PD > prefix (for instance a /56). It's a must as the 3GPP architecture supports just one routing entry per su= bscriber, so both the 3GPP link and delegated prefix must be aggregatable.=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Tue Mar 12 06:38:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29AAE21F8B74 for ; Tue, 12 Mar 2013 06:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 HUSLJ4GT66w2 for ; Tue, 12 Mar 2013 06:38:46 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id DC89121F8B5B for ; Tue, 12 Mar 2013 06:38:43 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0635E9C; Tue, 12 Mar 2013 14:38:42 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id ECB579A; Tue, 12 Mar 2013 14:38:42 +0100 (CET) Date: Tue, 12 Mar 2013 14:38:42 +0100 (CET) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <513F2C48.5070303@gmail.com> Message-ID: References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA1419F6@SRVHKE02.rdm.cz> <513E6707.6010905@gmail.com> <513F19DC.8080105@gmail.com> <513F2C48.5070303@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 13:38:51 -0000 On Tue, 12 Mar 2013, Alexandru Petrescu wrote: > Do you mean 64share script in the USBkey? Or 64share script in the > computer on which the USB key is attached? (I think the latter only). Latter only. -- Mikael Abrahamsson email: swmike@swm.pp.se From mohamed.boucadair@orange.com Tue Mar 12 07:13:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C7921F8B19 for ; Tue, 12 Mar 2013 07:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.805 X-Spam-Level: X-Spam-Status: No, score=-1.805 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcsYbNvVpZ5O for ; Tue, 12 Mar 2013 07:13:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id AB47821F8B16 for ; Tue, 12 Mar 2013 07:13:17 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 11BC3324CF0; Tue, 12 Mar 2013 15:13:17 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id E3E77238048; Tue, 12 Mar 2013 15:13:16 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Tue, 12 Mar 2013 15:13:16 +0100 From: To: Mikael Abrahamsson Date: Tue, 12 Mar 2013 15:13:15 +0100 Thread-Topic: [v6ops] new draft: draft-ietf-v6ops-mobile-device-profile Thread-Index: Ac4efIRyXGUhdIEdTp+dWuI/rozCawAqdeCQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EB735617A@PUEXCB1B.nanterre.francetelecom.fr> References: <201303111245.r2BCj1Q21809@ftpeng-update.cisco.com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.5.94520 Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-mobile-device-profile@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-mobile-device-profile X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 14:13:26 -0000 Dear Mikael, Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 >Envoy=E9 : lundi 11 mars 2013 18:19 >=C0 : fred@cisco.com >Cc : v6ops@ietf.org;=20 >draft-ietf-v6ops-mobile-device-profile@tools.ietf.org >Objet : Re: [v6ops] new draft: draft-ietf-v6ops-mobile-device-profile > >On Mon, 11 Mar 2013, fred@cisco.com wrote: > >> >> A new draft has been posted, at=20 >http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profi >le. Please take a look at it and comment. > >I have read this. > >REQ#29. I have had some confusion by vendors when I request this in a=20 >similar wording. As soon as they see "release 10", they see a=20 >huge chunk=20 >of requirements and they will say "device doesn't support release 10".=20 >When I then tell them that DHCPv6-PD is a purely control plane=20 >feature, I=20 >have received more favorable responses. I recommend to=20 >re-write of this=20 >paragraph to tone down the Release 10 mention. Med: Is this wording better? (note prefix delegation is discussed in REQ#27= without any reference to release 10) OLD: REQ#29: Prefix delegation which allows to allocate a shorter prefix to a cellular host is only available since 3GPP Release 10. For deployments requiring to share the same /64 prefix, the cellular device SHOULD support [I-D.ietf-v6ops-64share] to enable sharing a /64 prefix between the 3GPP interface towards the GGSN (WAN interface) and the LAN interfaces. NEW: REQ#29: For deployments requiring to share the same /64 prefix, the cellular device SHOULD support [I-D.ietf-v6ops-64share] to enable sharing a /64 prefix between the 3GPP interface towards the GGSN (WAN interface) and the LAN interfaces. > >REQ#31: > >What about MSS clamping? Med: As you know this is a controversial feature. I checked this thread (ht= tp://www.ietf.org/mail-archive/web/v6ops/current/msg14406.html) to see if t= hat discussion can help in drafting some text to propose to you...but my re= ading of that discussion is there is no clear conclusion to make.=20 > >Apart from that, I like this document and it's a useful collection of=20 >requirements. Med: Thanks.=20 From ietf@rozanak.com Tue Mar 12 07:27:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955CA21F8A08; Tue, 12 Mar 2013 07:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxWSc3fTYPzF; Tue, 12 Mar 2013 07:27:17 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id D2C2E21F87CE; Tue, 12 Mar 2013 07:27:15 -0700 (PDT) Received: from kopoli (dhcp-51ef.meeting.ietf.org [130.129.81.239]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MO8WC-1U9uOi2ZN6-005y1e; Tue, 12 Mar 2013 10:27:14 -0400 From: "Hosnieh Rafiee" To: , Date: Tue, 12 Mar 2013 15:27:09 +0100 Message-ID: <002501ce1f2d$b05198d0$10f4ca70$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01CE1F36.1216C420" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4fLSR+E6qr435gQc6fpREey/S8aA== Content-Language: en-us X-Provags-ID: V02:K0:YUAIBVFmcEUA5T8T/gfPFfqKFxghUmM1hqv/5eoABAB PkcByEiUytgp36NxJsJIgUmIB9lCtC5OdoaM4xxqdz62ukYQpV BlDFRA50UkF8YwqJy3uWiWeiwV8nXfUymwPlaLqEAHs6vwtHU/ CM12mgNmoNaaQVM1SjJQtXw9liibeJjxDYgryTKJzYXtiCS2ZB nl7jhf82f42q9zi4LCzgMkJCnJlxq961/2F0tba0YHTBqe8TMf V9G+4neLX7jx9R224KIEPts5pVx1oBz3MsJe8WDVSYtumm1Ijn mkCyfFfiuPaAsh8Vu6g+ZAds63N/9WsM/9VnsnSXR70FnII4oA LkqcV1hbJhLpYGYdjjYg= Subject: [v6ops] ND security, meeting at 12:15 in front of Grand Sierra D X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 14:27:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0026_01CE1F36.1216C420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I will give a short, informal presentation for anyone interested in learning about ND security while observing privacy (draft so called SSAS http://tools.ietf.org/html/draft-rafiee-6man-ssas-04 ) . It will not take more than 7- 10 minutes unless there are questions. This will take place front of the Grand Sierra D (IETF lounge) at 12:15. Thanks Hosnieh ------=_NextPart_000_0026_01CE1F36.1216C420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I will = give a short, informal presentation for anyone interested in learning = about ND security while observing privacy (draft so called SSAS http://tool= s.ietf.org/html/draft-rafiee-6man-ssas-04  ) . It will not take = more than 7- 10 minutes unless there are questions. This will take place = front of the G= rand Sierra D (IETF lounge) at 12:15.  

T= hanks

H= osnieh

------=_NextPart_000_0026_01CE1F36.1216C420-- From gert@space.net Tue Mar 12 07:41:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47E521F8C49 for ; Tue, 12 Mar 2013 07:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, 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 wxEqNObjqn6t for ; Tue, 12 Mar 2013 07:41:59 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 37C8621F8C1F for ; Tue, 12 Mar 2013 07:41:54 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 7687F6076E for ; Tue, 12 Mar 2013 15:41:53 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 53F3060762 for ; Tue, 12 Mar 2013 15:41:53 +0100 (CET) Received: (qmail 37953 invoked by uid 1007); 12 Mar 2013 15:41:53 +0100 Date: Tue, 12 Mar 2013 15:41:53 +0100 From: Gert Doering To: Alexandru Petrescu Message-ID: <20130312144153.GS51699@Space.Net> References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> <513E61B2.2000307@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X/bwPxfmJlMJebmk" Content-Disposition: inline In-Reply-To: <513E61B2.2000307@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 14:42:00 -0000 --X/bwPxfmJlMJebmk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Mar 11, 2013 at 11:58:58PM +0100, Alexandru Petrescu wrote: > (no doubt DHCPv6 is not deployed on these MAC-less links, because > DHCPv6, like IPv6 ND, rely a lot on having a good MAC layer). Nothing wrong with DHCPv6 on PPP (or generic p2p) links. > It may turn in circles, but the first thing this 64share draft says is > that DHCPv6-PD is the right thing to do. And DHCPv6-PD is working > better on links which have MAC layers (e.g. during the mulitcast SErver > discovery phase one better has a multicast feature built-in). Were the > 3GPP links to have right MAC layers (non kludgy) then maybe DHCPv6-PD > were used instead of 64share. There is no need for any sort of "multicast" support on a ptp link, as there is only one other party, which will see your packets when you stuff it into the link. Your ramblings have no substance - DHCPv6-PD is not supported because the 3GPP network vendors have not implemented it, not because the link=20 is of a "p2p-ish nature". Non-3GPP BRAS vendors have offered DHCPv6 and DHCPv6-PD on "p2p" links (SDH/SONET, PPP, PPPoE, ...) for ages. > >> It's not only me who thinks so. Why would manufacturers of 3GPP > >> USB keys go through the effort to ask IEEE for Organization IDs, if > >> it were not for a belief in a technical advantage of using MAC > >> addresses on 3GPP links. > > > > "It makes windows drivers easier". Yay. >=20 > Recent linux kernel efforst try to work in the same way as windows ndis > drivers do with recent USB LTE keys. But that's not because it's useful, it's because these dongles work that way and Linux has to find a way to make it work there, too. Don't mix cause and symptom. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --X/bwPxfmJlMJebmk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQCVAwUBUT8+sakuBuNlUUl1AQJXOgP/UPvMTWj+mR0Cc2x60jfKG0x6OAg68f8b oerAZFigaCGmtHqI8O3oWs1CnP8Ag+mLRwKh68qm3lNA9mkA/15rfiFLQ+j9Aqaw AbC6l6sCzui91NhWc+VXnydlSZm4jIAv5PjXKBMmwNCowNEppNTR0/V8ScEEy9yc pOtDY6uPysQ= =QDQn -----END PGP SIGNATURE----- --X/bwPxfmJlMJebmk-- From swmike@swm.pp.se Tue Mar 12 07:54:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F33421F8552 for ; Tue, 12 Mar 2013 07:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 3H5+aog1c1LV for ; Tue, 12 Mar 2013 07:54:28 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 6492521F8675 for ; Tue, 12 Mar 2013 07:54:28 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 28DC89C; Tue, 12 Mar 2013 15:54:27 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1EA8A9A; Tue, 12 Mar 2013 15:54:27 +0100 (CET) Date: Tue, 12 Mar 2013 15:54:27 +0100 (CET) From: Mikael Abrahamsson To: mohamed.boucadair@orange.com In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB735617A@PUEXCB1B.nanterre.francetelecom.fr> Message-ID: References: <201303111245.r2BCj1Q21809@ftpeng-update.cisco.com> <94C682931C08B048B7A8645303FDC9F36EB735617A@PUEXCB1B.nanterre.francetelecom.fr> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-mobile-device-profile@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-mobile-device-profile X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 14:54:29 -0000 On Tue, 12 Mar 2013, mohamed.boucadair@orange.com wrote: > Med: Is this wording better? (note prefix delegation is discussed in REQ#27 without any reference to release 10) > > OLD: > REQ#29: Prefix delegation which allows to allocate a shorter prefix > to a cellular host is only available since 3GPP Release 10. > For deployments requiring to share the same /64 prefix, the > cellular device SHOULD support [I-D.ietf-v6ops-64share] to > enable sharing a /64 prefix between the 3GPP interface towards > the GGSN (WAN interface) and the LAN interfaces. > > NEW: > REQ#29: For deployments requiring to share the same /64 prefix, the > cellular device SHOULD support [I-D.ietf-v6ops-64share] to > enable sharing a /64 prefix between the 3GPP interface towards > the GGSN (WAN interface) and the LAN interfaces. Sounds good to me. >> >> REQ#31: >> >> What about MSS clamping? > > Med: As you know this is a controversial feature. I checked this thread > (http://www.ietf.org/mail-archive/web/v6ops/current/msg14406.html) to > see if that discussion can help in drafting some text to propose to > you...but my reading of that discussion is there is no clear conclusion > to make. Personally I like the IPv6 MTU setting you're already suggesting, this is how I do things at home currently (tunnel with lower MTU so I set my home to "ip mtu 1400" and everything is fine). MSS clamping is as you say controversial. Perhaps it could be a MAY feature? Otoh that doesn't give strong guidance so it might be redundant and should be avoided. I just wanted to bring the topic up. -- Mikael Abrahamsson email: swmike@swm.pp.se From ietf@rozanak.com Tue Mar 12 09:06:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA5B11E80E8; Tue, 12 Mar 2013 09:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0MncTd-zs63; Tue, 12 Mar 2013 09:06:29 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 4F73D11E80DF; Tue, 12 Mar 2013 09:06:29 -0700 (PDT) Received: from kopoli (dhcp-51ef.meeting.ietf.org [130.129.81.239]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MPlHO-1UATdw05b8-005MtR; Tue, 12 Mar 2013 12:06:28 -0400 From: "Hosnieh Rafiee" To: , Date: Tue, 12 Mar 2013 17:06:22 +0100 Message-ID: <008101ce1f3b$8c7fcb80$a57f6280$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0082_01CE1F43.EE460840" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4fO0v7RSHTtBPJSCa0XAfa9YeGhw== Content-Language: en-us X-Provags-ID: V02:K0:hwRP6OhTHuuy31U8RvspvhyVArX5JYR3Pr+JNiVRxhv y2+6vp0jnRD/gMLsG+QYM24W9a8e5UhS64hyBRqSSA+lk3fOFn otr7PRrvtNOMbmue4SMUxo0RRwQ0PPCZDseJFft646JE4T71YO nGLs8YI+ffhgzwKB+4I5Qiye7Zayc1e1ToMNV62sb3kJozntRr 1dQrctntBOgn2MDLKTc0G7lanpJ+5s4XyhnvVdD/0B1o6XD46a LPFcf5meXVFkiTKyvWk6z9dVQfs1rnIBuwSlZ4fyf3My6GTG2b OCMEcM8JphtNW93oYXAylOhhisaxuFyliJOfOYvJyUgOV+nA/Q +9/uzQ6jSEjmxcS5FCaA= Subject: [v6ops] ND security, meeting place changed to Grand Sierra B X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 16:06:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0082_01CE1F43.EE460840 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We are at the last table in the corner. If anybody interested join us :-) From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Tuesday, March 12, 2013 3:27 PM To: ipv6@ietf.org; v6ops@ietf.org Subject: ND security, meeting at 12:15 in front of Grand Sierra D I will give a short, informal presentation for anyone interested in learning about ND security while observing privacy (draft so called SSAS http://tools.ietf.org/html/draft-rafiee-6man-ssas-04 ) . It will not take more than 7- 10 minutes unless there are questions. This will take place front of the Grand Sierra D (IETF lounge) at 12:15. Thanks Hosnieh ------=_NextPart_000_0082_01CE1F43.EE460840 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We are at the last table in the corner. If = anybody interested join us :-)

 

From:= = Hosnieh Rafiee [mailto:ietf@rozanak.com]
Sent: Tuesday, March = 12, 2013 3:27 PM
To: ipv6@ietf.org; = v6ops@ietf.org
Subject: ND security, meeting at 12:15 in front = of Grand Sierra D

 

I will give = a short, informal presentation for anyone interested in learning about = ND security while observing privacy (draft so called SSAS http://tool= s.ietf.org/html/draft-rafiee-6man-ssas-04  ) . It will not take = more than 7- 10 minutes unless there are questions. This will take place = front of the G= rand Sierra D (IETF lounge) at 12:15.  

T= hanks

H= osnieh

------=_NextPart_000_0082_01CE1F43.EE460840-- From dan-v6ops@drown.org Tue Mar 12 09:11:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F87B21F8AB2 for ; Tue, 12 Mar 2013 09:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7I5wAbBnY8nC for ; Tue, 12 Mar 2013 09:11:53 -0700 (PDT) Received: from vps3.drown.org (vps3.drown.org [IPv6:2600:3c00::f03c:91ff:fedf:5654]) by ietfa.amsl.com (Postfix) with ESMTP id 38CF021F8A93 for ; Tue, 12 Mar 2013 09:11:53 -0700 (PDT) Received: by vps3.drown.org (Postfix, from userid 48) id EDA00C12B; Tue, 12 Mar 2013 12:11:52 -0400 (EDT) Received: from 2001:470:b9fd:2:7aac:c0ff:fe97:ce69 ([2001:470:b9fd:2:7aac:c0ff:fe97:ce69]) by mail.drown.org (Horde Framework) with HTTP; Tue, 12 Mar 2013 11:11:52 -0500 Message-ID: <20130312111152.18266yihh9ofes08@mail.drown.org> Date: Tue, 12 Mar 2013 11:11:52 -0500 From: Dan Drown To: v6ops@ietf.org References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA1419F6@SRVHKE02.rdm.cz> <513E6707.6010905@gmail.com> <513F19DC.8080105@gmail.com> In-Reply-To: <513F19DC.8080105@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 16:11:53 -0000 Quoting Alexandru Petrescu : > I think 64share is not intended to be implemented on any USB keys for > that matter (be them with or w/o MAC addresses). The USB keys you are talking about (the ones that translate between ethernet and 3GPP) are doing some form of 64share on the USB key itself. It has a point to point upstream and an ethernet downstream. The USB key firmware takes the /64 and assigns it to its end of the virtual ethernet interface. It may have a global address and it may not. It might properly do neighbor discovery and handle being (layer 2) bridged to other ethernet networks and it might ignore standards and only expect one device downstream. That's all up to the USB key vendor's implementation. So if by "implemented on" USB keys you mean in the USB key's firmware, that sounds like it's already covered. If you mean sharing your USB key connection to other devices, that's all up to the USB key vendor following the standards for IPv6 over ethernet. From alexandru.petrescu@gmail.com Tue Mar 12 09:16:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC2E21F8C06 for ; Tue, 12 Mar 2013 09:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.094 X-Spam-Level: X-Spam-Status: No, score=-10.094 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7uyfK88MREg for ; Tue, 12 Mar 2013 09:16:50 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3A321F8BF4 for ; Tue, 12 Mar 2013 09:16:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2CGGnPf017704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Mar 2013 17:16:49 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2CGGmg0006831; Tue, 12 Mar 2013 17:16:48 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.20]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2CGGgcQ002095; Tue, 12 Mar 2013 17:16:48 +0100 Message-ID: <513F54D1.7030001@gmail.com> Date: Tue, 12 Mar 2013 17:16:17 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Gert Doering References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> <513E61B2.2000307@gmail.com> <20130312144153.GS51699@Space.Net> In-Reply-To: <20130312144153.GS51699@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 16:16:51 -0000 Le 12/03/2013 15:41, Gert Doering a écrit : > Hi, > > On Mon, Mar 11, 2013 at 11:58:58PM +0100, Alexandru Petrescu wrote: >> (no doubt DHCPv6 is not deployed on these MAC-less links, because >> DHCPv6, like IPv6 ND, rely a lot on having a good MAC layer). > > Nothing wrong with DHCPv6 on PPP (or generic p2p) links. Well yes, still... I have not seen DHCPv6 running on the 3GPP link (3G+) that I use. There is no answer to DHCPv6 Solicits. If MAC-less ptp links is not a reason for lack of DHCPv6 on 3GPP links, then what's the technical reasons? >> It may turn in circles, but the first thing this 64share draft says >> is that DHCPv6-PD is the right thing to do. And DHCPv6-PD is >> working better on links which have MAC layers (e.g. during the >> mulitcast SErver discovery phase one better has a multicast feature >> built-in). Were the 3GPP links to have right MAC layers (non >> kludgy) then maybe DHCPv6-PD were used instead of 64share. > > There is no need for any sort of "multicast" support on a ptp link, > as there is only one other party, which will see your packets when > you stuff it into the link. Yes it works on ptp link. > Your ramblings have no substance - DHCPv6-PD is not supported > because the 3GPP network vendors have not implemented it, There must be a technical reason for why vendors didnt implement it. > not because the link is of a "p2p-ish nature". Non-3GPP BRAS vendors > have offered DHCPv6 and DHCPv6-PD on "p2p" links (SDH/SONET, PPP, > PPPoE, ...) for ages. > >>>> It's not only me who thinks so. Why would manufacturers of >>>> 3GPP USB keys go through the effort to ask IEEE for >>>> Organization IDs, if it were not for a belief in a technical >>>> advantage of using MAC addresses on 3GPP links. >>> >>> "It makes windows drivers easier". Yay. >> >> Recent linux kernel efforst try to work in the same way as windows >> ndis drivers do with recent USB LTE keys. > > But that's not because it's useful, it's because these dongles work > that way and Linux has to find a way to make it work there, too. No no, the dongles that I talk about work equally well as ppp or as MAC-addressable device. It's not that that dongle does not work with ppp, it can as well (depends how one initialiwes it). If presented with an option to choose between two interfaces, which one would one prefer - a ptp no-ARP ppp interfaces? Or a MAC-addressable WiFi-like ND interface? I prefer the latter - its features can be advantageously used by ND, DHCPv6, MLD and other protocols. Alex > > Don't mix cause and symptom. > > Gert Doering -- NetMaster > From gert@space.net Tue Mar 12 09:34:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88CAA21F8C87 for ; Tue, 12 Mar 2013 09:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 ZoWVUNoXWN6n for ; Tue, 12 Mar 2013 09:34:15 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 73B5321F8C84 for ; Tue, 12 Mar 2013 09:34:14 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id F3B4D6076E for ; Tue, 12 Mar 2013 17:34:13 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id D622260764 for ; Tue, 12 Mar 2013 17:34:13 +0100 (CET) Received: (qmail 82379 invoked by uid 1007); 12 Mar 2013 17:34:13 +0100 Date: Tue, 12 Mar 2013 17:34:13 +0100 From: Gert Doering To: Alexandru Petrescu Message-ID: <20130312163413.GY51699@Space.Net> References: <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> <513E61B2.2000307@gmail.com> <20130312144153.GS51699@Space.Net> <513F54D1.7030001@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hNzZqZIeaZHndbxI" Content-Disposition: inline In-Reply-To: <513F54D1.7030001@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 16:34:16 -0000 --hNzZqZIeaZHndbxI Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Mar 12, 2013 at 05:16:17PM +0100, Alexandru Petrescu wrote: > Le 12/03/2013 15:41, Gert Doering a =E9crit : > > On Mon, Mar 11, 2013 at 11:58:58PM +0100, Alexandru Petrescu wrote: > >> (no doubt DHCPv6 is not deployed on these MAC-less links, because > >> DHCPv6, like IPv6 ND, rely a lot on having a good MAC layer). > > > > Nothing wrong with DHCPv6 on PPP (or generic p2p) links. >=20 > Well yes, still... >=20 > I have not seen DHCPv6 running on the 3GPP link (3G+) that I use. There > is no answer to DHCPv6 Solicits. >=20 > If MAC-less ptp links is not a reason for lack of DHCPv6 on 3GPP links, > then what's the technical reasons? "Vendors not having it implemented on the other side" (or "operators not having switched it on", but as far as I hear from Telco folks, the=20 problem is more around "Vendors not implementing it"). If I turn off the DHCPv6 server off on my nifty MAC based ethernet link, you won't get anything back for your solicits either. Even if it has all the ethernet framing you want. [..] > > Your ramblings have no substance - DHCPv6-PD is not supported > > because the 3GPP network vendors have not implemented it, > There must be a technical reason for why vendors didnt implement it. "Priorization of scarce development manpower"? "The customer that waves with the biggest wad of money gets their feature first", and nobody complaining loudly enough about lack of DHCPv6-PD? [..] > If presented with an option to choose between two interfaces, which one > would one prefer - a ptp no-ARP ppp interfaces? Or a MAC-addressable > WiFi-like ND interface? I prefer the latter - its features can be > advantageously used by ND, DHCPv6, MLD and other protocols. I'd prefer a ptp interface any day, because that's much closer to=20 the real link characteristics - the "I pretend to be an ethernet=20 thingie" interface is actually *breaking* communication in certain=20 cases. There are 3G networks where the UE is assigned a fixed link-local address (in the PDP setup), and if you do not send your NS/RS using=20 *that* source address, the other end will just not answer. With=20 a PPP based link, telling the client it's link-local address is=20 part of the protocol and works nicely, with an ethernet based link,=20 it *can not be done*, so your thingie won't work properly in those=20 networks. (Communication using "any global address out of the /64" actually worked fine, just link-local stuff using a different-than- assigned address didn't) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --hNzZqZIeaZHndbxI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQCVAwUBUT9ZBakuBuNlUUl1AQLeoAQAtDn7+rfkvCbAo7HJUf77c+ztRspprtbA PHb54nAJNQnwuoNTqCwNcFa7Fcnx+vTC1pVjOEm4HmreRnaAdkmGoHNbFECkNtqk kLW2GpxNvM1fRsQgD3y5hMX5S2gw/3wdg4sHB1aDhhxBZ9SRge6tcHmTswRFwvV9 3CMbJMQKfcI= =6XEM -----END PGP SIGNATURE----- --hNzZqZIeaZHndbxI-- From mohamed.boucadair@orange.com Tue Mar 12 09:48:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E790111E80E3 for ; Tue, 12 Mar 2013 09:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzqQuoERkOyS for ; Tue, 12 Mar 2013 09:48:59 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 337AC11E80D7 for ; Tue, 12 Mar 2013 09:48:59 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 0CFF9324CB2; Tue, 12 Mar 2013 17:48:56 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id E2E4935C068; Tue, 12 Mar 2013 17:48:55 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Tue, 12 Mar 2013 17:48:55 +0100 From: To: Mikael Abrahamsson Date: Tue, 12 Mar 2013 17:48:55 +0100 Thread-Topic: [v6ops] new draft: draft-ietf-v6ops-mobile-device-profile Thread-Index: Ac4fMX+UtKXBAZ5vQMe+ctgxGL09AAAD3CdQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EB735623A@PUEXCB1B.nanterre.francetelecom.fr> References: <201303111245.r2BCj1Q21809@ftpeng-update.cisco.com> <94C682931C08B048B7A8645303FDC9F36EB735617A@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: 2013.3.12.161519 Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-mobile-device-profile@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-mobile-device-profile X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 16:49:00 -0000 Re-, Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 >Envoy=E9 : mardi 12 mars 2013 15:54 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : v6ops@ietf.org;=20 >draft-ietf-v6ops-mobile-device-profile@tools.ietf.org >Objet : RE: [v6ops] new draft: draft-ietf-v6ops-mobile-device-profile > >On Tue, 12 Mar 2013, mohamed.boucadair@orange.com wrote: > >> Med: Is this wording better? (note prefix delegation is=20 >discussed in REQ#27 without any reference to release 10) >> >> OLD: >> REQ#29: Prefix delegation which allows to allocate a=20 >shorter prefix >> to a cellular host is only available since 3GPP Release 10. >> For deployments requiring to share the same /64 prefix, the >> cellular device SHOULD support [I-D.ietf-v6ops-64share] to >> enable sharing a /64 prefix between the 3GPP=20 >interface towards >> the GGSN (WAN interface) and the LAN interfaces. >> >> NEW: >> REQ#29: For deployments requiring to share the same /64=20 >prefix, the >> cellular device SHOULD support [I-D.ietf-v6ops-64share] to >> enable sharing a /64 prefix between the 3GPP=20 >interface towards >> the GGSN (WAN interface) and the LAN interfaces. > >Sounds good to me. Med: Ok, the change is implemented in my local copy. > >>> >>> REQ#31: >>> >>> What about MSS clamping? >> >> Med: As you know this is a controversial feature. I checked=20 >this thread=20 >>=20 >(http://www.ietf.org/mail-archive/web/v6ops/current/msg14406.html) to=20 >> see if that discussion can help in drafting some text to propose to=20 >> you...but my reading of that discussion is there is no clear=20 >conclusion=20 >> to make. > >Personally I like the IPv6 MTU setting you're already=20 >suggesting, this is=20 >how I do things at home currently (tunnel with lower MTU so I=20 >set my home=20 >to "ip mtu 1400" and everything is fine). MSS clamping is as you say=20 >controversial. Perhaps it could be a MAY feature? Otoh that=20 >doesn't give=20 >strong guidance so it might be redundant and should be avoided. > >I just wanted to bring the topic up. Med: Thanks for raising the point. I prefer to not mention MSS rewrite in t= he next revision of the text. From swmike@swm.pp.se Tue Mar 12 09:55:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39CA11E80FA for ; Tue, 12 Mar 2013 09:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 mVGO0BkV-RgR for ; Tue, 12 Mar 2013 09:54:54 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 78ED011E80BA for ; Tue, 12 Mar 2013 09:54:40 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7F6D29C; Tue, 12 Mar 2013 17:54:36 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 748FC9A; Tue, 12 Mar 2013 17:54:36 +0100 (CET) Date: Tue, 12 Mar 2013 17:54:36 +0100 (CET) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <513F54D1.7030001@gmail.com> Message-ID: References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> <513E61B2.2000307@gmail.com> <20130312144153.GS51699@Space.Net> <513F54D1.7030001@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 16:55:12 -0000 X-List-Received-Date: Tue, 12 Mar 2013 16:55:12 -0000 On Tue, 12 Mar 2013, Alexandru Petrescu wrote: > If MAC-less ptp links is not a reason for lack of DHCPv6 on 3GPP links, > then what's the technical reasons? The technical reason is that 3GPP didn't standardize DHCPv6 on that link. DHCPv6-PD is in Release 10, which isn't implemented by any vendors yet afaik. > If presented with an option to choose between two interfaces, which one > would one prefer - a ptp no-ARP ppp interfaces? Or a MAC-addressable > WiFi-like ND interface? I prefer the latter - its features can be > advantageously used by ND, DHCPv6, MLD and other protocols. That's your personal preference. I don't understand why this is of any advantage. -- Mikael Abrahamsson email: swmike@swm.pp.se From ales.vizdal@t-mobile.cz Tue Mar 12 10:25:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52AC21F0C6D for ; Tue, 12 Mar 2013 10:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FGm-gRW1FsO for ; Tue, 12 Mar 2013 10:25:26 -0700 (PDT) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7821F0C36 for ; Tue, 12 Mar 2013 10:25:24 -0700 (PDT) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id ADFB72857DC; Tue, 12 Mar 2013 18:25:23 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk504.rdm.cz ([fe80::744e:351e:b5b:fd01%12]) with mapi; Tue, 12 Mar 2013 18:25:23 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Mikael Abrahamsson , Alexandru Petrescu Date: Tue, 12 Mar 2013 18:25:21 +0100 Thread-Topic: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 Thread-Index: Ac4fQqBsUdRUFnZPQuqTIS7tXZH5cgAA28CA Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6DA141C8D@SRVHKE02.rdm.cz> References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> <513E61B2.2000307@gmail.com> <20130312144153.GS51699@Space.Net> <513F54D1.7030001@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 17:25:27 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Mikael > Abrahamsson > Sent: Tuesday, March 12, 2013 12:55 PM > To: Alexandru Petrescu > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64sha= re-03 >=20 > On Tue, 12 Mar 2013, Alexandru Petrescu wrote: >=20 > > If MAC-less ptp links is not a reason for lack of DHCPv6 on 3GPP links, > > then what's the technical reasons? >=20 > The technical reason is that 3GPP didn't standardize DHCPv6 on that link. > DHCPv6-PD is in Release 10, which isn't implemented by any vendors yet > afaik. Just a note: As specified in Rel-10 the UE shall use SLAAC to get it's 3GPP= link address,=20 the DHCP-PD feature is there only for a LAN prefix delegation. So there is = no full DHCPv6=20 support in the 3GPP specs. =20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se Ales From ales.vizdal@t-mobile.cz Tue Mar 12 10:31:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A0921F88F7 for ; Tue, 12 Mar 2013 10:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1DuHOM5nPcN for ; Tue, 12 Mar 2013 10:31:32 -0700 (PDT) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 69F8221F8930 for ; Tue, 12 Mar 2013 10:31:32 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 9C9972857DC; Tue, 12 Mar 2013 18:31:31 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Tue, 12 Mar 2013 18:31:31 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Gert Doering , Alexandru Petrescu Date: Tue, 12 Mar 2013 18:31:29 +0100 Thread-Topic: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 Thread-Index: Ac4fP4Ny/8oNLZAWSrKZJZYRKmQoLQAB0zqQ Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6DA141C91@SRVHKE02.rdm.cz> References: <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> <513E61B2.2000307@gmail.com> <20130312144153.GS51699@Space.Net> <513F54D1.7030001@gmail.com> <20130312163413.GY51699@Space.Net> In-Reply-To: <20130312163413.GY51699@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 17:31:33 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Gert > Doering > Sent: Tuesday, March 12, 2013 12:34 PM > To: Alexandru Petrescu > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64sha= re-03 =20 > There are 3G networks where the UE is assigned a fixed link-local > address (in the PDP setup),=20 Those networks and UEs are following the spec that requires the gateway (GG= SN/PGW) to hint the UE the host part of the LLA. Given that the gateway must not us= e any address from the /64 GUA available to the UE it removes the need for DAD. > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 Ales From Dmitry.Anipko@microsoft.com Tue Mar 12 11:30:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E56C11E815C for ; Tue, 12 Mar 2013 11:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 Z3KRq9LJ0fmc for ; Tue, 12 Mar 2013 11:30:49 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id 4964911E8138 for ; Tue, 12 Mar 2013 11:30:40 -0700 (PDT) Received: from BL2FFO11FD016.protection.gbl (10.173.161.204) by BL2FFO11HUB021.protection.gbl (10.173.161.45) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Mar 2013 18:30:32 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD016.mail.protection.outlook.com (10.173.160.224) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Mar 2013 18:30:31 +0000 Received: from TK5EX14MBXC252.redmond.corp.microsoft.com ([169.254.1.2]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Tue, 12 Mar 2013 18:29:40 +0000 From: Dmitry Anipko To: Alexandru Petrescu Thread-Topic: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 Thread-Index: AQHOHxlkM7V0Oc4OBEWtZYiGN2xO0ZiiX+NQ Date: Tue, 12 Mar 2013 18:29:38 +0000 Message-ID: References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> <513E61B2.2000307@gmail.com> <513F18FF.2060700@gmail.com> In-Reply-To: <513F18FF.2060700@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.23] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(479174001)(199002)(189002)(13464002)(377454001)(24454001)(51704002)(77982001)(74502001)(53806001)(76482001)(44976002)(5343655001)(20776003)(54316002)(63696002)(50466001)(79102001)(50986001)(80022001)(46102001)(23756002)(16406001)(31966008)(59766001)(47976001)(69226001)(4396001)(49866001)(65816001)(47776003)(56776001)(33656001)(47446002)(66066001)(55846006)(54356001)(51856001)(56816002)(74662001)(47736001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB021; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078310077C Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 18:30:50 -0000 Thanks Alexandru. >> The only minor comment here is that I think (just suppose), from my reco= llection, that 3GPP specs need some clarification about this DHCPv6-PD use. If 3gpp specs need such clarification, it doesn't seem to be in scope for d= raft-ietf-v6ops-64share? >> On another hand, for each one of the 3 scenarios, if 64share receives a = NS from the network about the IPv6 address within the /64 - it will break. The draft currently says " The gateway routes the entire /64 to the UE and = does not perform ND or Network Unreachability Detection (NUD) [RFC4861].". = If you think this is not sufficient, do you want to suggest the particular = text you'd like to see? Thank you. -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: Tuesday, March 12, 2013 5:01 AM To: Dmitry Anipko Cc: Gert Doering; v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share= -03 Le 12/03/2013 00:29, Dmitry Anipko a =E9crit : > Alexandru, > >>> Were the 3GPP links to have right MAC layers (non kludgy) then maybe=20 >>> DHCPv6-PD were used instead of 64share. > > The actual point is that wherever DHCP-PD is available, it should be=20 > used instead of /64share. Not just where there is a "right" MAC layer.=20 > So there seems to be a violent agreement about the long term direction=20 > and that it will cover the wider scenarios. YEs, the long term intention is right. I agree in the long term one should= use DHCPv6-PD to get a prefix for the WLAN of the UE connected on LTE. The only minor comment here is that I think (just suppose), from my recolle= ction, that 3GPP specs need some clarification about this DHCPv6-PD use. > /64share is not the long term direction - it is a short/mid-term fix.=20 > The draft says that, and in my opinion, it doesn't need changes in=20 > this respect, because it is intentionally scoped to be a=20 > short/mid-term fix for particular types of scenarios. Yes, right. It does not need to stress it is a midterm solution. It is al= ready said. On another hand, for each one of the 3 scenarios, if 64share receives a NS = from the network about the IPv6 address within the /64 - it will break. Alex > > -----Original Message----- From: v6ops-bounces@ietf.org=20 > [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Monday, March 11, 2013 3:59 PM To: Gert Doering Cc: > v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in > draft-ietf-v6ops-64share-03 > > Le 11/03/2013 22:53, Gert Doering a =E9crit : >> Hi, >> >> On Mon, Mar 11, 2013 at 09:32:15PM +0100, Alexandru Petrescu >> wrote: >>> Le 11/03/2013 19:58, Mikael Abrahamsson a =E9crit : >>>> On Mon, 11 Mar 2013, Alexandru Petrescu wrote: >>>> >>>>> We are already the knees deep into thingies. The IPv6 stack (the=20 >>>>> one which uses IPv6 addresses, ND, routes, interfaces - as 64share=20 >>>>> requires) is faced to these thingies. >>>> >>>> The USB dongle does this magic in order to emulate a MAC layer =20 >>>> towards the OS. It doesn't need to do this, but that's one way of=20 >>>> doing it. >>> >>> This is a kind effort from the USB key - it helps a lot the IPv6=20 >>> stack. The stack sees the 3GPP interface just like any other=20 >>> Ethernet interface. The stack does not need to do wacky things like=20 >>> NO_ARP. >> >> I'm not sure why you think that this is helpful or kind - it just=20 >> complicates things, while PPP interfaces have been around and well-=20 >> understood for over 20 years > > PPP on cellular 3GPP links have failed to evolve for some strange=20 > reason. (many other links have moved away from this ppp nature). > > When a new kind of link shows up it first gets seen by IPv6 stack as a=20 > serial, or as a ptp link. Then it slowly evolves to IEEE, MAC=20 > addressable, multicast capable links. Now 3GPP links try the same... > >> - no need for a MAC layer, extra overhead, "smart" firmware breaking=20 >> stuff (like "packets coming from the wrong link-layer address" as=20 >> necessary consequence of EUI-64 not giving the computer the=20 >> link-local address that the network is expecting, >> etc.) > > Strange, the absence of a proper MAC layer is what allows 64share to=20 > work... > > (no doubt DHCPv6 is not deployed on these MAC-less links, because=20 > DHCPv6, like IPv6 ND, rely a lot on having a good MAC layer). > >>> This is the future of 3GPP interfaces (as opposed to old ptp=20 >>> addressless links). >> >> I hope not. It's a kludge. > > It may be implemented as what looks like kludgy patch, but it may=20 > improve in the future. We should let space for that. > > It may turn in circles, but the first thing this 64share draft says is=20 > that DHCPv6-PD is the right thing to do. And DHCPv6-PD is working=20 > better on links which have MAC layers (e.g. during the mulitcast=20 > SErver discovery phase one better has a multicast feature built-in).=20 > Were the 3GPP links to have right MAC layers (non kludgy) then maybe=20 > DHCPv6-PD were used instead of 64share. > >>> It's not only me who thinks so. Why would manufacturers of 3GPP USB=20 >>> keys go through the effort to ask IEEE for Organization IDs, if it=20 >>> were not for a belief in a technical advantage of using MAC=20 >>> addresses on 3GPP links. >> >> "It makes windows drivers easier". Yay. > > Recent linux kernel efforst try to work in the same way as windows=20 > ndis drivers do with recent USB LTE keys. > > Alex > >> >> Gert Doering -- NetMaster >> > > > _______________________________________________ v6ops mailing list=20 > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From bob.hinden@gmail.com Tue Mar 12 12:10:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F6E11E81E8 for ; Tue, 12 Mar 2013 12:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.254 X-Spam-Level: X-Spam-Status: No, score=-103.254 tagged_above=-999 required=5 tests=[AWL=0.345, 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 FpyUxMi9vqLQ for ; Tue, 12 Mar 2013 12:10:34 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id 964B011E81E4 for ; Tue, 12 Mar 2013 12:10:34 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id 15so202125wgd.16 for ; Tue, 12 Mar 2013 12:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=bPzYFNxHNbI7XkK/E41cbGRIjPwae8mW59cy6IaGqog=; b=VVP9eGYylaCFDYznf2zlQWK77bR4E9xu2AeL3RRmVjtAgvRAnaI2odc8iiiPovZT+q iIrWXUjdZMN6DfXOgjX6hfvc6c6zMB/PG9pZ5g5Oh7GQTpg3LWZceBhwjf+MfQa7O8q2 xDRpZuuHSDlJYhhrDJRZQEXMCHVrP5vuGa2uWmYBeGXzRuB4YmVFsT0f9Q6OWY3w/Aph 0CzylzQ/K2mjavDNCZ1cKxa4MsoPA6mflLm0As/vxfHEHpTnux/C4KSFgL4VlhH+hYfu lrv5Ueb/996Ye3QoUykQLPj7IPvGoZwxtE6Uu2u1Q7kmOXUPfIV2KrGCxvZsax0YlHdH WERA== X-Received: by 10.180.75.177 with SMTP id d17mr22384691wiw.16.1363115432648; Tue, 12 Mar 2013 12:10:32 -0700 (PDT) Received: from dhcp-6422.meeting.ietf.org (dhcp-6422.meeting.ietf.org. [130.129.100.34]) by mx.google.com with ESMTPS id t7sm23803434wij.2.2013.03.12.12.10.27 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 12 Mar 2013 12:10:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <8C48B86A895913448548E6D15DA7553B7CB9DF@xmb-rcd-x09.cisco.com> Date: Tue, 12 Mar 2013 15:10:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <55C837DB-3B3B-48EB-A435-E1D5FDB66810@gmail.com> References: <8C48B86A895913448548E6D15DA7553B7CB9DF@xmb-rcd-x09.cisco.com> To: v6ops WG X-Mailer: Apple Mail (2.1283) Cc: 6man Chairs <6man-chairs@tools.ietf.org>, v6ops chairs , "v6ops-ads@tools.ietf.org" Subject: Re: [v6ops] Looking at RFC Editor Queue X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 19:10:35 -0000 Fred,=20 Comments below. Bob On Mar 12, 2013, at 7:08 AM, Fred Baker (fred) wrote: > We have some documents that are waiting for normative references, in = one case for more than a year. Could you please tell us the status of = your work? >=20 > Thanks >=20 >=20 > 2012-11-19 draft-ietf-v6ops-ra-guard-implementation-07.txt [C175] >=20 > MISSREF*R(1G) > REF draft-ietf-6man-oversized-header-chain NOT-RECEIVED Completed w.g. last call in late February. > draft-ietf-6man-nd-extension-headers NOT-RECEIVED In the IESG, three discusses. > F. Gont > "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)" > Bytes: 30802 > Working Group: IPv6 Operations >=20 >=20 > 2012-02-21 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt = [C156] >=20 > MISSREF*R(1G) > REF draft-ietf-6man-addr-select-considerations NOT-RECEIVED The authors are going to do a new draft and the chairs plan to start a = w.g. last call after it is available. > draft-ietf-6man-addr-select-opt NOT-RECEIVED Submitted to the IESG in January. > O. Troan, Ed., D. Miles, S. Matsushima, T. Okimoto, D. Wing > "IPv6 Multihoming without Network Address Translation" > Bytes: 50586 > Working Group: IPv6 Operations From alexandru.petrescu@gmail.com Tue Mar 12 13:04:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2717F11E811E for ; Tue, 12 Mar 2013 13:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.799 X-Spam-Level: X-Spam-Status: No, score=-10.799 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuuRe+rZv8Uu for ; Tue, 12 Mar 2013 13:04:11 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4174511E8110 for ; Tue, 12 Mar 2013 13:04:11 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2CK4AfO019887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 12 Mar 2013 21:04:10 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2CK4A4i014109 for ; Tue, 12 Mar 2013 21:04:10 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.14]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2CK44wn009379 for ; Tue, 12 Mar 2013 21:04:09 +0100 Message-ID: <513F8A1B.1040905@gmail.com> Date: Tue, 12 Mar 2013 21:03:39 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA1419F6@SRVHKE02.rdm.cz> <513E6707.6010905@gmail.com> <513F19DC.8080105@gmail.com> <20130312111152.18266yihh9ofes08@mail.drown.org> In-Reply-To: <20130312111152.18266yihh9ofes08@mail.drown.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 20:04:12 -0000 Le 12/03/2013 17:11, Dan Drown a écrit : > Quoting Alexandru Petrescu : >> I think 64share is not intended to be implemented on any USB keys >> for that matter (be them with or w/o MAC addresses). > > > The USB keys you are talking about (the ones that translate between > ethernet and 3GPP) are doing some form of 64share on the USB key > itself. Hum? This is a surprise to me. This would mean that MAC-enabled USB LTE keys are already implementing a method similar to 64share. > It has a point to point upstream and an ethernet downstream. The USB > key firmware takes the /64 and assigns it to its end of the virtual > ethernet interface. It may have a global address and it may not. It > might properly do neighbor discovery and handle being (layer 2) > bridged to other ethernet networks I may agree with this description. At some point I speculated that it is not the dongle which sends these ND messages, but the Gateway. I am told that's not possible because 3GPP specification; but I would need to see it in practice. Until then I am still on a fence about this. > and it might ignore standards and only expect one device downstream. > That's all up to the USB key vendor's implementation. Remark, from the standpoint of these vendors, the 64share document is an IETF ongoing developping document which does not respect their way of doing '64share'. And it means that we here contribute a 64share IETF document which ignores the other running code. This argument of who is compliant to what standard is misleading. It can be used both ways, it may fire back. It's too easy! I will try to restrain myself from further posting on this. I will go back to the invitation from Cameron to contribute text. Alex > So if by "implemented on" USB keys you mean in the USB key's > firmware, that sounds like it's already covered. If you mean sharing > your USB key connection to other devices, that's all up to the USB > key vendor following the standards for IPv6 over ethernet. > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From alexandru.petrescu@gmail.com Tue Mar 12 13:16:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15EFE21F8C83 for ; Tue, 12 Mar 2013 13:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.127 X-Spam-Level: X-Spam-Status: No, score=-10.127 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W52p9YKFwEko for ; Tue, 12 Mar 2013 13:16:37 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 227A821F8C6F for ; Tue, 12 Mar 2013 13:16:36 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2CKGZ3m029433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Mar 2013 21:16:36 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2CKGZji015613; Tue, 12 Mar 2013 21:16:35 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.14]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2CKGSnI009460; Tue, 12 Mar 2013 21:16:34 +0100 Message-ID: <513F8D02.7030704@gmail.com> Date: Tue, 12 Mar 2013 21:16:02 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Gert Doering References: <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> <513E61B2.2000307@gmail.com> <20130312144153.GS51699@Space.Net> <513F54D1.7030001@gmail.com> <20130312163413.GY51699@Space.Net> In-Reply-To: <20130312163413.GY51699@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 20:16:38 -0000 Le 12/03/2013 17:34, Gert Doering a écrit : > Hi, > > On Tue, Mar 12, 2013 at 05:16:17PM +0100, Alexandru Petrescu wrote: >> Le 12/03/2013 15:41, Gert Doering a écrit : >>> On Mon, Mar 11, 2013 at 11:58:58PM +0100, Alexandru Petrescu >>> wrote: >>>> (no doubt DHCPv6 is not deployed on these MAC-less links, >>>> because DHCPv6, like IPv6 ND, rely a lot on having a good MAC >>>> layer). >>> >>> Nothing wrong with DHCPv6 on PPP (or generic p2p) links. >> >> Well yes, still... >> >> I have not seen DHCPv6 running on the 3GPP link (3G+) that I use. >> There is no answer to DHCPv6 Solicits. >> >> If MAC-less ptp links is not a reason for lack of DHCPv6 on 3GPP >> links, then what's the technical reasons? > > "Vendors not having it implemented on the other side" (or "operators > not having switched it on", but as far as I hear from Telco folks, > the problem is more around "Vendors not implementing it"). Vendors must have a reason of not doing so. > If I turn off the DHCPv6 server off on my nifty MAC based ethernet > link, you won't get anything back for your solicits either. Even if > it has all the ethernet framing you want. Right... but MLD would work ok, faster than if there were no MAC addresses, which allows to start using ND reliably... which in turn allows for this DNS discovery by MAC and so on. DHCPv6 discovery phase is but one. On ptp ppp links we have none of these link-scoped protocols. We dont have ND, no MLD no DNS discovery on link, etc. For all these features we rely on non-IETF protocols, like for example the non-IETF way of forming Interface Identifiers. All these ptp ppp aspects are peculiarities which are specific only to the cellular link of the Computer. For all the other non-cellular links, the stack on the Computer uses a homogeneous way to deal with LAN, PAN, MAN whatsoever. > [..] >>> Your ramblings have no substance - DHCPv6-PD is not supported >>> because the 3GPP network vendors have not implemented it, >> There must be a technical reason for why vendors didnt implement >> it. > > "Priorization of scarce development manpower"? Right... > "The customer that waves with the biggest wad of money gets their > feature first", and nobody complaining loudly enough about lack of > DHCPv6-PD? Right... > [..] >> If presented with an option to choose between two interfaces, >> which one would one prefer - a ptp no-ARP ppp interfaces? Or a >> MAC-addressable WiFi-like ND interface? I prefer the latter - its >> features can be advantageously used by ND, DHCPv6, MLD and other >> protocols. > > I'd prefer a ptp interface any day, because that's much closer to > the real link characteristics - the "I pretend to be an ethernet > thingie" interface is actually *breaking* communication in certain > cases. Aha... sounds reasonable. But pretend to be Ethernet thingie may one day become a real one, with cellular shared links, where neighbors may talk directly to each other without going through a fixed base station. > There are 3G networks where the UE is assigned a fixed link-local > address (in the PDP setup), and if you do not send your NS/RS using > *that* source address, the other end will just not answer. With a > PPP based link, telling the client it's link-local address is part > of the protocol and works nicely, with an ethernet based link, it > *can not be done*, so your thingie won't work properly in those > networks. (Communication using "any global address out of the /64" > actually worked fine, just link-local stuff using a different-than- > assigned address didn't) I read. Alex > > Gert Doering -- NetMaster > From alexandru.petrescu@gmail.com Tue Mar 12 13:19:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF36F11E8118 for ; Tue, 12 Mar 2013 13:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.131 X-Spam-Level: X-Spam-Status: No, score=-10.131 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0nYHbM8JvBQ for ; Tue, 12 Mar 2013 13:19:46 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 374C211E810A for ; Tue, 12 Mar 2013 13:19:44 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2CKJhUK026115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Mar 2013 21:19:43 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2CKJgEB015963; Tue, 12 Mar 2013 21:19:43 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.14]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2CKJdbX010058; Tue, 12 Mar 2013 21:19:42 +0100 Message-ID: <513F8DC2.70804@gmail.com> Date: Tue, 12 Mar 2013 21:19:14 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Mikael Abrahamsson References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> <513E61B2.2000307@gmail.com> <20130312144153.GS51699@Space.Net> <513F54D1.7030001@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 20:19:46 -0000 Le 12/03/2013 17:54, Mikael Abrahamsson a écrit : > On Tue, 12 Mar 2013, Alexandru Petrescu wrote: > >> If MAC-less ptp links is not a reason for lack of DHCPv6 on 3GPP >> links, then what's the technical reasons? > > The technical reason is that 3GPP didn't standardize DHCPv6 on that > link. DHCPv6-PD is in Release 10, which isn't implemented by any > vendors yet afaik. > >> If presented with an option to choose between two interfaces, which >> one would one prefer - a ptp no-ARP ppp interfaces? Or a >> MAC-addressable WiFi-like ND interface? I prefer the latter - its >> features can be advantageously used by ND, DHCPv6, MLD and other >> protocols. > > That's your personal preference. I don't understand why this is of > any advantage. MAC-addressed links allows to use a single software implementation for many IEEE links and these are very many, cellular is not IEEE and is but one kind of link. There are many protocols at IETF which could be used unmodified on cellular links if they were MAC-addressable, and wouldt be used if they're not MAC addressable - MLD, DNS discovery, SeND, you name it. Alex > From ietf@meetecho.com Tue Mar 12 13:23:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD6511E8186 for ; Tue, 12 Mar 2013 13:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.366 X-Spam-Level: X-Spam-Status: No, score=-0.366 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_13=0.6] 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 O5uLI6xzViRU for ; Tue, 12 Mar 2013 13:23:49 -0700 (PDT) Received: from smtpdg9.aruba.it (smtpdg8.aruba.it [62.149.158.238]) by ietfa.amsl.com (Postfix) with ESMTP id A643E11E8199 for ; Tue, 12 Mar 2013 13:23:48 -0700 (PDT) Received: from dell-tcastaldi ([130.129.16.136]) by smtpcmd03.ad.aruba.it with bizsmtp id AkPk1l00W2w8SR601kPmbk; Tue, 12 Mar 2013 21:23:47 +0100 Date: Tue, 12 Mar 2013 16:23:42 -0400 (EDT) From: Meetecho Team To: v6ops@ietf.org Message-ID: <26235040.17.1363119822622.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_16_8622256.1363119822613" Subject: [v6ops] Meetecho support for V6OPS_II session X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 20:23:50 -0000 ------=_Part_16_8622256.1363119822613 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, a virtual room has been reserved on the Meetecho system for the V6OPS WG meeting session. Access to the on-line session (including audio and video streams) will be made available (just a couple of minutes before session start time) at: http://www.meetecho.com/ietf86/v6ops The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf86 Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_16_8622256.1363119822613-- From alexandru.petrescu@gmail.com Tue Mar 12 13:26:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C185B11E81A8 for ; Tue, 12 Mar 2013 13:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.835 X-Spam-Level: X-Spam-Status: No, score=-9.835 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUIdLHwIOBbH for ; Tue, 12 Mar 2013 13:26:48 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7E19111E8179 for ; Tue, 12 Mar 2013 13:26:47 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2CKQkhF031917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Mar 2013 21:26:46 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2CKQkBw016868; Tue, 12 Mar 2013 21:26:46 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.14]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2CKQhns014434; Tue, 12 Mar 2013 21:26:45 +0100 Message-ID: <513F8F69.2050204@gmail.com> Date: Tue, 12 Mar 2013 21:26:17 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Dmitry Anipko References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> <513E61B2.2000307@gmail.com> <513F18FF.2060700@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 20:26:48 -0000 Le 12/03/2013 19:29, Dmitry Anipko a écrit : > Thanks Alexandru. > >>> The only minor comment here is that I think (just suppose), from >>> my recollection, that 3GPP specs need some clarification about >>> this DHCPv6-PD use. > > If 3gpp specs need such clarification, it doesn't seem to be in > scope for draft-ietf-v6ops-64share? Right, no, it's not in the scope of 64share document to explain why DHCPv6-PD is not correctly specified at 3GPP. >>> On another hand, for each one of the 3 scenarios, if 64share >>> receives a NS from the network about the IPv6 address within the >>> /64 - it will break. > > The draft currently says " The gateway routes the entire /64 to the > UE and does not perform ND or Network Unreachability Detection (NUD) > [RFC4861].". If you think this is not sufficient, do you want to > suggest the particular text you'd like to see? Yes, I will, soon, thanks for asking. I will send something soon. Basically that text is incomplete. It says it 'routes' but it doesnt say how. Or here we have a fundamental distinctions for the how; these boil down to what does the routing table entry at the Gateway towards the UE looks like: is there a nexthop, is there a device name, is the dev a ptp or a MAC-adressed link, etc. It's because of the particular mixture of these parameters that 64share mechanism works. Were it for the Gateway to have a different mixture, 64share wouldnt work. Also, the part which says that "the Gateway does not perform ND on that link" is very strange, because RFCs require ND on all interfaces IIRC. Also, this is a router and should not accept RAs. Alex > > Thank you. > > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, March 12, 2013 > 5:01 AM To: Dmitry Anipko Cc: Gert Doering; v6ops@ietf.org Subject: > Re: [v6ops] Mic comments on link model in > draft-ietf-v6ops-64share-03 > > Le 12/03/2013 00:29, Dmitry Anipko a écrit : >> Alexandru, >> >>>> Were the 3GPP links to have right MAC layers (non kludgy) then >>>> maybe DHCPv6-PD were used instead of 64share. >> >> The actual point is that wherever DHCP-PD is available, it should >> be used instead of /64share. Not just where there is a "right" MAC >> layer. So there seems to be a violent agreement about the long >> term direction and that it will cover the wider scenarios. > > YEs, the long term intention is right. I agree in the long term one > should use DHCPv6-PD to get a prefix for the WLAN of the UE > connected on LTE. > > The only minor comment here is that I think (just suppose), from my > recollection, that 3GPP specs need some clarification about this > DHCPv6-PD use. > >> /64share is not the long term direction - it is a short/mid-term >> fix. The draft says that, and in my opinion, it doesn't need >> changes in this respect, because it is intentionally scoped to be a >> short/mid-term fix for particular types of scenarios. > > Yes, right. It does not need to stress it is a midterm solution. > It is already said. > > On another hand, for each one of the 3 scenarios, if 64share > receives a NS from the network about the IPv6 address within the /64 > - it will break. > > Alex > >> >> -----Original Message----- From: v6ops-bounces@ietf.org >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Monday, March 11, 2013 3:59 PM To: Gert Doering Cc: >> v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in >> draft-ietf-v6ops-64share-03 >> >> Le 11/03/2013 22:53, Gert Doering a écrit : >>> Hi, >>> >>> On Mon, Mar 11, 2013 at 09:32:15PM +0100, Alexandru Petrescu >>> wrote: >>>> Le 11/03/2013 19:58, Mikael Abrahamsson a écrit : >>>>> On Mon, 11 Mar 2013, Alexandru Petrescu wrote: >>>>> >>>>>> We are already the knees deep into thingies. The IPv6 >>>>>> stack (the one which uses IPv6 addresses, ND, routes, >>>>>> interfaces - as 64share requires) is faced to these >>>>>> thingies. >>>>> >>>>> The USB dongle does this magic in order to emulate a MAC >>>>> layer towards the OS. It doesn't need to do this, but that's >>>>> one way of doing it. >>>> >>>> This is a kind effort from the USB key - it helps a lot the >>>> IPv6 stack. The stack sees the 3GPP interface just like any >>>> other Ethernet interface. The stack does not need to do wacky >>>> things like NO_ARP. >>> >>> I'm not sure why you think that this is helpful or kind - it just >>> complicates things, while PPP interfaces have been around and >>> well- understood for over 20 years >> >> PPP on cellular 3GPP links have failed to evolve for some strange >> reason. (many other links have moved away from this ppp nature). >> >> When a new kind of link shows up it first gets seen by IPv6 stack >> as a serial, or as a ptp link. Then it slowly evolves to IEEE, MAC >> addressable, multicast capable links. Now 3GPP links try the >> same... >> >>> - no need for a MAC layer, extra overhead, "smart" firmware >>> breaking stuff (like "packets coming from the wrong link-layer >>> address" as necessary consequence of EUI-64 not giving the >>> computer the link-local address that the network is expecting, >>> etc.) >> >> Strange, the absence of a proper MAC layer is what allows 64share >> to work... >> >> (no doubt DHCPv6 is not deployed on these MAC-less links, because >> DHCPv6, like IPv6 ND, rely a lot on having a good MAC layer). >> >>>> This is the future of 3GPP interfaces (as opposed to old ptp >>>> addressless links). >>> >>> I hope not. It's a kludge. >> >> It may be implemented as what looks like kludgy patch, but it may >> improve in the future. We should let space for that. >> >> It may turn in circles, but the first thing this 64share draft >> says is that DHCPv6-PD is the right thing to do. And DHCPv6-PD is >> working better on links which have MAC layers (e.g. during the >> mulitcast SErver discovery phase one better has a multicast >> feature built-in). Were the 3GPP links to have right MAC layers >> (non kludgy) then maybe DHCPv6-PD were used instead of 64share. >> >>>> It's not only me who thinks so. Why would manufacturers of >>>> 3GPP USB keys go through the effort to ask IEEE for >>>> Organization IDs, if it were not for a belief in a technical >>>> advantage of using MAC addresses on 3GPP links. >>> >>> "It makes windows drivers easier". Yay. >> >> Recent linux kernel efforst try to work in the same way as windows >> ndis drivers do with recent USB LTE keys. >> >> Alex >> >>> >>> Gert Doering -- NetMaster >>> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> > > > From owen@delong.com Tue Mar 12 14:22:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8AD11E80D3 for ; Tue, 12 Mar 2013 14:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBV8bEMF+iiz for ; Tue, 12 Mar 2013 14:22:15 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 97E1311E80D2 for ; Tue, 12 Mar 2013 14:22:14 -0700 (PDT) Received: from [IPv6:2001:470::a9:3850:144d:3ab5:e5b6] ([IPv6:2001:470:0:a9:3850:144d:3ab5:e5b6]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2CLKORd028352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 12 Mar 2013 14:20:24 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2CLKORd028352 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363123224; bh=Z+5YPKHNBm8rzwZG+k1CuRz1Fi4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=zf6wQ1ZfiGn6fFVWnrEtvZtqqJln6RK4WcQ1kiDKoQRSjzMR3dTDa2e170n+Yh1fL jG2ykjDzaBXwd9X+9MXZpWd+8baUTZEyAJ1z/bzbZU1GyBUGa4KtfRopMZD4fBn3If PsQtwzj1Rr2XYFyXQsw1659WBtIjvanqH6sZKOtY= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <513F8DC2.70804@gmail.com> Date: Tue, 12 Mar 2013 14:20:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1C080602-1C6A-49F2-8444-AC86EC90A8F8@delong.com> References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> <513E61B2.2000307@gmail.com> <20130312144153.GS51699@Space.Net> <513F54D1.7030001@gmail.com> <513F8DC2.70804@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 12 Mar 2013 14:20:24 -0700 (PDT) Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 21:22:16 -0000 On Mar 12, 2013, at 1:19 PM, Alexandru Petrescu = wrote: > Le 12/03/2013 17:54, Mikael Abrahamsson a =E9crit : >> On Tue, 12 Mar 2013, Alexandru Petrescu wrote: >>=20 >>> If MAC-less ptp links is not a reason for lack of DHCPv6 on 3GPP >>> links, then what's the technical reasons? >>=20 >> The technical reason is that 3GPP didn't standardize DHCPv6 on that >> link. DHCPv6-PD is in Release 10, which isn't implemented by any >> vendors yet afaik. >>=20 >>> If presented with an option to choose between two interfaces, which >>> one would one prefer - a ptp no-ARP ppp interfaces? Or a >>> MAC-addressable WiFi-like ND interface? I prefer the latter - its >>> features can be advantageously used by ND, DHCPv6, MLD and other >>> protocols. >>=20 >> That's your personal preference. I don't understand why this is of >> any advantage. >=20 > MAC-addressed links allows to use a single software implementation for > many IEEE links and these are very many, cellular is not IEEE and is = but > one kind of link. >=20 Meh=85 There are lots of non-IEEE (or more accurately, = non-Ethernet-like) links in the world. Serial point to point (such as POS, DS-3, DS-1, = etc.), will persist and have existed for a very long time. PPP is well known = and well understood by virtually every operating system and is simple, = clean, and efficient. I see no reason to treat a point-to-point cellular link = as other than point-to-point and no advantage to coercing it to behaving as if it was an ethernet just so you can use ethernet drivers and then need a = bunch of odd-ball software to cope with the aspects of the connection that are = not ethernet-like. > There are many protocols at IETF which could be used unmodified on > cellular links if they were MAC-addressable, and wouldt be used if > they're not MAC addressable - MLD, DNS discovery, SeND, you name it. There is no need whatsoever for MLD on a point to point link since = multicast makes no sense in such an environment. There are two hosts on the link. If you are the sender, then the other one will receive whatever you send = and vice versa. What is the point of putting in a bunch of overhead to = enable multicast on such a link? Not sure how you see DNS discovery playing out on such a link. I would expect that to play out on the /64 and across the point to point link to=20= a more distant DNS server where the actual context of the PPP link should be relatively irrelevant as to whether it is ethernet-like or = not. SeND is a secure form of Neighbor Discovery. Again, I fail to see the relevance of Neighbor Discovery on a point to point link. As such, it seems that all of the technologies you are describing as = being usable on Point to Point links only if the point to point link pretends = to be an ethernet-like BMA or NBMA network are actually intended to overcome the complexities imposed by BMA/NBMA networks. Since those complexities don't exist in a point to point link, I fail to see any advantage to = implementing those complexities just so you can take advantage of the existing = solutions designed to overcome those complexities. Perhaps I am missing or misunderstanding something in what you are advocating, but unless that is the case, I think that it makes far more = sense to treat cellular connections as point to point connections between = routers (one router at the cellular provider and one in the {handset,usb fob, = midi, etc.} device. Owen From owen@delong.com Tue Mar 12 14:26:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9426211E80CC for ; Tue, 12 Mar 2013 14:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9uYtVLvYDK5 for ; Tue, 12 Mar 2013 14:26:39 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id E600E11E80BA for ; Tue, 12 Mar 2013 14:26:38 -0700 (PDT) Received: from [IPv6:2001:470::a9:3850:144d:3ab5:e5b6] ([IPv6:2001:470:0:a9:3850:144d:3ab5:e5b6]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2CLOYUJ028465 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 12 Mar 2013 14:24:35 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2CLOYUJ028465 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363123477; bh=+1/ETLHiEFx84KaLgG3X0tS/Ymc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=NW7cbVu6qP3rx4KOsowwK238cc6KoORhmqJ54rUjKzmM2c7M86yTLd3X6oGos2+Le VT3b5lRBSIpwvEXd02Hih8wxW25E1Y0he7ndqgDbWE4z2xhQnA9gLz/IL0fRl8wL9S VgZzgdHUGpgIlywWKPAVLS9GuWHtUSznG92nrY58= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <513F8D02.7030704@gmail.com> Date: Tue, 12 Mar 2013 14:24:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3C69A2DF-509E-46EF-9EE4-54C2A7CE9686@delong.com> References: <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> <513E61B2.2000307@gmail.com> <20130312144153.GS51699@Space.Net> <513F54D1.7030001@gmail.com> <20130312163413.GY51699@Space.Net> <513F8D02.7030704@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 12 Mar 2013 14:24:37 -0700 (PDT) Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 21:26:39 -0000 > Aha... sounds reasonable. >=20 > But pretend to be Ethernet thingie may one day become a real one, with > cellular shared links, where neighbors may talk directly to each other > without going through a fixed base station. Unlikely unless you expect the physics of radio to radically change in = the near future. A low power transmitter (as you find in the average cellular device) is = unlikely to be able to reliably reach all of the neighbors within the same cell = without being retransmitted by the cell itself. As such, treating cellular as point to = point links makes much MUCH more sense from a bandwidth conservation and protocol = simplicity perspective. Owen From ales.vizdal@t-mobile.cz Wed Mar 13 06:24:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C790021F8622 for ; Wed, 13 Mar 2013 06:24:37 -0700 (PDT) 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.027, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yr8DfAJDcWVh for ; Wed, 13 Mar 2013 06:24:37 -0700 (PDT) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE7021F860A for ; Wed, 13 Mar 2013 06:24:34 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 88116285841; Wed, 13 Mar 2013 14:24:33 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Wed, 13 Mar 2013 14:24:33 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu , Dmitry Anipko Date: Wed, 13 Mar 2013 14:24:33 +0100 Thread-Topic: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 Thread-Index: Ac4fX/5N6/LqwJqWSKyhyoMPnAz34wAjUpYQ Message-ID: <1808340F7EC362469DDFFB112B37E2FCC6DA141E89@SRVHKE02.rdm.cz> References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> <513E61B2.2000307@gmail.com> <513F18FF.2060700@gmail.com> <513F8F69.2050204@gmail.com> In-Reply-To: <513F8F69.2050204@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 13:24:38 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Sent: Tuesday, March 12, 2013 4:26 PM > To: Dmitry Anipko > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64sha= re-03 > > The draft currently says " The gateway routes the entire /64 to the > > UE and does not perform ND or Network Unreachability Detection (NUD) > > [RFC4861].". If you think this is not sufficient, do you want to > > suggest the particular text you'd like to see? >=20 > Yes, I will, soon, thanks for asking. I will send something soon. >=20 > Basically that text is incomplete. It says it 'routes' but it doesnt > say how. Or here we have a fundamental distinctions for the how; these > boil down to what does the routing table entry at the Gateway towards > the UE looks like: is there a nexthop, is there a device name, is the > dev a ptp or a MAC-adressed link, etc. It's because of the particular > mixture of these parameters that 64share mechanism works. Were it for > the Gateway to have a different mixture, 64share wouldnt work. It routes ... the packet core gateway (ggsn/p-gw) is the default router for= the UE and the TTL is being decremented by the gateway. On the gateway you would probably see the /64 prefix linked to a PDP Context / PDN connection = or a GTP tunnel. =20 > Also, the part which says that "the Gateway does not perform ND on that > link" is very strange, because RFCs require ND on all interfaces IIRC. > Also, this is a router and should not accept RAs. As there is no link-layer there is no need for ND to my understanding. > Alex Ales From swmike@swm.pp.se Wed Mar 13 06:29:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33AB721F858C for ; Wed, 13 Mar 2013 06:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, J_BACKHAIR_24=1, J_BACKHAIR_42=1, MIME_8BIT_HEADER=0.3] 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 Llt6K3Tt6UZo for ; Wed, 13 Mar 2013 06:29:41 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 9C04C21F8462 for ; Wed, 13 Mar 2013 06:29:41 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5EB6B9C; Wed, 13 Mar 2013 14:29:40 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4D85B9A; Wed, 13 Mar 2013 14:29:40 +0100 (CET) Date: Wed, 13 Mar 2013 14:29:40 +0100 (CET) From: Mikael Abrahamsson To: =?ISO-8859-15?Q?V=EDzdal_Ale=A8?= In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC6DA141E89@SRVHKE02.rdm.cz> Message-ID: References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> <513E61B2.2000307@gmail.com> <513F18FF.2060700@gmail.com> <513F8F69.2050204@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA141E89@SRVHKE02.rdm.cz> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-846245094-1363181380=:378" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 13:29:42 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-846245094-1363181380=:378 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 13 Mar 2013, Vízdal Ale¨ wrote: > It routes ... the packet core gateway (ggsn/p-gw) is the default router > for the UE and the TTL is being decremented by the gateway. On the > gateway you would probably see the /64 prefix linked to a PDP Context / > PDN connection or a GTP tunnel. Not all GGSN/PGW decrement TTL. When I traceroute from my UE to the Internet, my first hop seen in traceroute is the GUA address of the first router hop after the PGW: UE<-GTP->SPGW<-IPv6->PE So my traceroute hop 1 is the GUA address of the PE. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-846245094-1363181380=:378-- From brian@innovationslab.net Wed Mar 13 07:36:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6297321F8D6E for ; Wed, 13 Mar 2013 07:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8r6wMhBT6eOw for ; Wed, 13 Mar 2013 07:36:27 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id DD7E821F8D90 for ; Wed, 13 Mar 2013 07:36:24 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id A2B9C88135 for ; Wed, 13 Mar 2013 07:36:21 -0700 (PDT) Received: from dhcp-51ca.meeting.ietf.org (unknown [IPv6:2001:df8:0:80:1c1f:e468:eb13:12f7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 6FDE3136823D for ; Wed, 13 Mar 2013 07:36:21 -0700 (PDT) Message-ID: <51408ED8.4070102@innovationslab.net> Date: Wed, 13 Mar 2013 10:36:08 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops WG References: <8C48B86A895913448548E6D15DA7553B7CB9E7@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B7CB9E7@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Looking at RFC Editor Queue X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 14:36:28 -0000 Fred, Have you gotten any response on this? Brian On 3/12/13 7:08 AM, Fred Baker (fred) wrote: > We have some documents that are waiting for normative references, in one case for more than a year. Could you please tell us the status of your work? > > Thanks > > > 2012-02-21 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt [C156] > > MISSREF*R(1G) > REF draft-ietf-mif-dhcpv6-route-option NOT-RECEIVED > O. Troan, Ed., D. Miles, S. Matsushima, T. Okimoto, D. Wing > "IPv6 Multihoming without Network Address Translation" > Bytes: 50586 > Working Group: IPv6 Operations > From jouni.nospam@gmail.com Wed Mar 13 09:28:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C515821F8CD8 for ; Wed, 13 Mar 2013 09:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_24=1, J_BACKHAIR_42=1, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yV7I56QAqFr4 for ; Wed, 13 Mar 2013 09:28:10 -0700 (PDT) Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com [IPv6:2607:f8b0:4001:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 410AA21F8CD1 for ; Wed, 13 Mar 2013 09:28:10 -0700 (PDT) Received: by mail-ia0-f180.google.com with SMTP id f27so1121267iae.39 for ; Wed, 13 Mar 2013 09:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=V248Lz357Jcs2oouWIoe8+A94F9rjzMe5AS8qyEgfcQ=; b=Exn0ayu8XseTs5swZZTczRNJbfHDNvlxwh8htlSgtLM/JZ/QoGf+UqmwZVscTo0Awp IvDorihOwZbuJf7QtMrIMH9pQSoPT+ONzNK4usVx5Nxycjc1YQ+Y4nAF7ofPSYc8ZlVl u3+NNzNSV4VRMS7gu2Zd5pfiBgV5QZQrR9E0j621gQVqPtlnsr1H++YWCMXEBZbLMVCv ELUTSoZ60Xb/9walh7OWgGvxprHgRO2wY+9PSMUg94r/H4v/wlqdQYbH2RuDOFvEnzoi vczc2Opb0vm2jC5MXcmX6qo8/XYLlucZ/+lpbowcb6ihk4ESPX4z7TCW3Ly8u5/e1AOE Lftg== MIME-Version: 1.0 X-Received: by 10.50.17.131 with SMTP id o3mr16512769igd.63.1363192089879; Wed, 13 Mar 2013 09:28:09 -0700 (PDT) Received: by 10.231.228.133 with HTTP; Wed, 13 Mar 2013 09:28:09 -0700 (PDT) Received: by 10.231.228.133 with HTTP; Wed, 13 Mar 2013 09:28:09 -0700 (PDT) In-Reply-To: References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> <513E61B2.2000307@gmail.com> <513F18FF.2060700@gmail.com> <513F8F69.2050204@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA141E89@SRVHKE02.rdm.cz> Date: Wed, 13 Mar 2013 18:28:09 +0200 Message-ID: From: jouni korhonen To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=14dae934049f47339704d7d0e4dd Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 16:28:10 -0000 --14dae934049f47339704d7d0e4dd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 13.3.2013 9.29 "Mikael Abrahamsson" kirjoitti: > > On Wed, 13 Mar 2013, V=C3=ADzdal Ale=C5=A1 wrote: > >> It routes ... the packet core gateway (ggsn/p-gw) is the default router for the UE and the TTL is being decremented by the gateway. On the gateway you would probably see the /64 prefix linked to a PDP Context / PDN connection or a GTP tunnel. > > > Not all GGSN/PGW decrement TTL. When I traceroute from my UE to the Internet, my first hop seen in traceroute is the GUA address of the first router hop after the PGW: > > UE<-GTP->SPGW<-IPv6->PE > > So my traceroute hop 1 is the GUA address of the PE. This is vendor implementation specific. Very popular but not really defined in 3gpp specs except for some deprecated stuff. - jouni > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --14dae934049f47339704d7d0e4dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


13.3.2013 9.29 "Mikael Abrahamsson" <swmike@swm.pp.se> kirjoitti:
>
> On Wed, 13 Mar 2013, V=C3=ADzdal Ale=C5=A1 wrote:
>
>> It routes ... the packet core gateway (ggsn/p-gw) is the default r= outer for the UE and the TTL is being decremented by the gateway. On the ga= teway you would probably see the /64 prefix linked to a PDP Context / PDN c= onnection or a GTP tunnel.
>
>
> Not all GGSN/PGW decrement TTL. When I traceroute from my UE to the In= ternet, my first hop seen in traceroute is the GUA address of the first rou= ter hop after the PGW:
>
> UE<-GTP->SPGW<-IPv6->PE
>
> So my traceroute hop 1 is the GUA address of the PE.

This is vendor implementation specific. Very popular but not= really=C2=A0 defined in 3gpp specs except for some deprecated stuff.

- jouni

>
> --
> Mikael Abrahamsson =C2=A0 =C2=A0email: swmike@swm.pp.se
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--14dae934049f47339704d7d0e4dd-- From phdgang@gmail.com Wed Mar 13 16:13:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89F411E8106 for ; Wed, 13 Mar 2013 16:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DGgNvZXrsCh for ; Wed, 13 Mar 2013 16:13:18 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id EA32B11E80D5 for ; Wed, 13 Mar 2013 16:13:17 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id b12so741274qca.4 for ; Wed, 13 Mar 2013 16:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lrBVKe5lzFjoINVLoQ3xt5/HqPbGVZhUmY7SS+L84d8=; b=MjRw3WOWWMdrPAmFLfuLrOKK11oiM207vumbwt0Lbv2tmWOATt34OhKyBzK7slnYb4 zk1VtiAKnd3CSKvIeLuZmma6Nl/FM8sOYadpSaUD0uPu7j21T0tlVk0PeQr12b8ChhjI KXo9c8cIvjfIhlgKLzdLZVJ5x5M/XztMkf0szo5HoUtm7JNEIQLKoVxeBo7yvtiy4GoO BU+WE6hg0D2Q3r/C3vqtZjbPhRKBqTC8dc0oBG8Z+lV4hG3zSRH9aUWuNS+x7yuvoKDt nt5eKLF6p+aP8D/gt1PLuJg0DRM/YU0OM30Od7az8LOkvp/vtBcbLMKtL5K9T28KnTex QbNg== MIME-Version: 1.0 X-Received: by 10.229.131.133 with SMTP id x5mr84028qcs.6.1363216397394; Wed, 13 Mar 2013 16:13:17 -0700 (PDT) Received: by 10.49.71.18 with HTTP; Wed, 13 Mar 2013 16:13:17 -0700 (PDT) In-Reply-To: <34A4EB40-BEAE-4849-A785-E59F41AEA1EC@magma.ca> References: <2671C6CDFBB59E47B64C10B3E0BD5923041F47A432@PRVPEXVS15.corp.twcable.com> <34A4EB40-BEAE-4849-A785-E59F41AEA1EC@magma.ca> Date: Thu, 14 Mar 2013 07:13:17 +0800 Message-ID: From: GangChen To: Philip Matthews Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops Subject: Re: [v6ops] comments for draft-ietf-v6ops-nat64-experience [was draft-ietf-v6ops-nat64-experience WGLC] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 23:13:18 -0000 Hi Philip, 2013/3/12, Philip Matthews : > I agree with Wes's comments (below), so I won't repeat them. I will simply > add a few additional comments of my own: > > 3.1 This section makes the comment > "It is advantageous from the vantage-point of troubleshooting > and traffic engineering to carry the IPv6 traffic natively for as long as > possible within an access network and translate only near the edge." > The question of where to place the NAT64 (near the subscriber, near peering > routers, somewhere in the middle) is an interesting one. I would like to > see a lot more discussion on this topic. The document makes some brief > comments on why placing it near peering routers might be useful, but I am > sure more can be said. I can also see cons for placing it there: as one > example, this would make geo-location based on IPv4 addresses rather > inaccurate. Will add more discussions on the point. Regarding the geo-location, I guess IPv6 address is more preferable than converted IPv4 address. IPv4 will loss geographical semantic in any case if NAT is on the path. > Furthermore, if one has multiple NAT64 boxes located near > different peering routers, then might mean some flows went through one NAT64 > box, while others went though a different NAT64 box -- not a good situation. Not sure if your concern is on asymmetric routing? Otherwise, those you described seem a usual practice of load balance. > > 3.3 I don't understand what is meant by "online" vs. "offline" in this > section. It would be good to properly define these, or give a reference to > a document that defines them. > Furthermore, the bullet points in this section seem somewhat random --- if > there is some cohesive picture which the authors are trying to present, then > I don't see it. "online" vs. "offline" is differentiated by various applications needs. We will fix that by adding proper definitions and logic in next version. Best Regards Gang From ietf@meetecho.com Wed Mar 13 16:26:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5719611E8159 for ; Wed, 13 Mar 2013 16:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.367 X-Spam-Level: X-Spam-Status: No, score=-0.367 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_13=0.6] 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 Hy56uziEG8pn for ; Wed, 13 Mar 2013 16:26:50 -0700 (PDT) Received: from smtpdg9.aruba.it (smtpdg8.aruba.it [62.149.158.238]) by ietfa.amsl.com (Postfix) with ESMTP id BC60011E811D for ; Wed, 13 Mar 2013 16:26:43 -0700 (PDT) Received: from dell-tcastaldi ([130.129.16.136]) by smtpcmd03.ad.aruba.it with bizsmtp id BBSe1l00b2w8SR601BSg6S; Thu, 14 Mar 2013 00:26:41 +0100 Date: Wed, 13 Mar 2013 19:26:36 -0400 (EDT) From: Meetecho Team To: v6ops@ietf.org Message-ID: <15842168.1.1363217196434.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_5143025.1363217196361" Subject: [v6ops] V6OPS session recording available X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 23:26:51 -0000 ------=_Part_0_5143025.1363217196361 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the V6OPS WG session at IETF 86 is available at the following URL: http://ietf86.conf.meetecho.com/index.php/Recorded_Sessions#V6OPS In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_0_5143025.1363217196361-- From alexandru.petrescu@gmail.com Wed Mar 13 20:28:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD1411E80A4 for ; Wed, 13 Mar 2013 20:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.866 X-Spam-Level: X-Spam-Status: No, score=-8.866 tagged_above=-999 required=5 tests=[AWL=-1.217, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_BACKHAIR_24=1, J_BACKHAIR_42=1, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLS2jrVOTsLd for ; Wed, 13 Mar 2013 20:28:32 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id CBA1411E809C for ; Wed, 13 Mar 2013 20:28:31 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2E3STrL014501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 14 Mar 2013 04:28:29 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2E3STDX019129 for ; Thu, 14 Mar 2013 04:28:29 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.4]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2E3SKOP004880 for ; Thu, 14 Mar 2013 04:28:29 +0100 Message-ID: <514143B7.20002@gmail.com> Date: Thu, 14 Mar 2013 04:27:51 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> <513E61B2.2000307@gmail.com> <513F18FF.2060700@gmail.com> <513F8F69.2050204@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA141E89@SRVHKE02.rdm.cz> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 03:28:33 -0000 Le 13/03/2013 17:28, jouni korhonen a écrit : > > 13.3.2013 9.29 "Mikael Abrahamsson" > kirjoitti: >> >> On Wed, 13 Mar 2013, Vízdal Aleš wrote: >> >>> It routes ... the packet core gateway (ggsn/p-gw) is the default >>> router for the UE and the TTL is being decremented by the >>> gateway. > > On the gateway you would probably see the /64 prefix linked to a PDP > Context / PDN connection or a GTP tunnel. Something like: Prefix Next-hop Device 2001:db8:1:1::/64 :: GTPtunnel0 or something like: Prefix Next-hop Device 2001:db8:1:1::/64 fe80::5 GTPtunnel0 If the former, and that PDPContext/PDNconnectio-or-GTPtunnel is MAC-addressable, then 64share wont work. >> Not all GGSN/PGW decrement TTL. When I traceroute from my UE to >> the >> > Internet, my first hop seen in traceroute is the GUA address of the > first router hop after the PGW: >> >> UE<-GTP->SPGW<-IPv6->PE >> >> So my traceroute hop 1 is the GUA address of the PE. > > This is vendor implementation specific. Very popular but not really > defined in 3gpp specs except for some deprecated stuff. Jouni - this is way too generic to be understandable. (if we want to do any reverse engineering :-) Alex > > - jouni > >> >> -- Mikael Abrahamsson email: swmike@swm.pp.se >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From swmike@swm.pp.se Wed Mar 13 20:33:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD7221F8E15 for ; Wed, 13 Mar 2013 20:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 yYLoXrSVzWyB for ; Wed, 13 Mar 2013 20:33:00 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id CDA8021F8E10 for ; Wed, 13 Mar 2013 20:32:59 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 268399C; Thu, 14 Mar 2013 04:32:59 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 196479A; Thu, 14 Mar 2013 04:32:59 +0100 (CET) Date: Thu, 14 Mar 2013 04:32:59 +0100 (CET) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <514143B7.20002@gmail.com> Message-ID: References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> <513E61B2.2000307@gmail.com> <513F18FF.2060700@gmail.com> <513F8F69.2050204@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA141E89@SRVHKE02.rdm.cz> <514143B7.20002@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 03:33:00 -0000 On Thu, 14 Mar 2013, Alexandru Petrescu wrote: > Something like: > > Prefix Next-hop Device > 2001:db8:1:1::/64 :: GTPtunnel0 > > or something like: > > Prefix Next-hop Device > 2001:db8:1:1::/64 fe80::5 GTPtunnel0 > > If the former, and that PDPContext/PDNconnectio-or-GTPtunnel is > MAC-addressable, then 64share wont work. There is no MAC header in the GTP tunnel. It's "ip-in-ip" kind of encapsulation, similar to IP proto 41. So anything causing there to be mac addressing is doing magic and perhaps the draft should mention this, but I don't see what else can be done. -- Mikael Abrahamsson email: swmike@swm.pp.se From cb.list6@gmail.com Wed Mar 13 21:02:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84F521F8CD9 for ; Wed, 13 Mar 2013 21:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.716 X-Spam-Level: X-Spam-Status: No, score=-1.716 tagged_above=-999 required=5 tests=[AWL=-0.717, BAYES_00=-2.599, J_BACKHAIR_24=1, J_BACKHAIR_42=1, J_CHICKENPOX_13=0.6, 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 ZBSRhygMvIhy for ; Wed, 13 Mar 2013 21:02:26 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0085111E809C for ; Wed, 13 Mar 2013 21:02:25 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id dq12so1686950wgb.24 for ; Wed, 13 Mar 2013 21:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=lJUDOomSpGt0U+grmIKqc7K2pgfOeVbpgu5M6YZgKT8=; b=EYyDxmFEfvxnXu03aUoW9SETKUEniB90G2vIE+E2K0iO2th9yYKqj0FEexc0si72EK NiKDjQdiPbgHR76/VGk5ywIjPqf/xAu573LEl8OmrfwfaGx3xYGvXjzQ43Qz8zvb3k65 DgO/oqGOW5Q1Lt8L1NRi6beSCbcdjzINvz57sifeluZlTo+B0jqTUWg/MhAME5KW70Q3 IcAwr0sohUN/MuRU6Qs0SZysrOiV2/xyWadOq8IJLRJZQrbEXJypWlk2CekgEm38QI8S 6bcwLXTN2TzIhRD/xUDK3PpgbvA22ls49Fo8rOoE5RLi9Zrona3JnaP2eDRKPAXZ3uoE QKog== MIME-Version: 1.0 X-Received: by 10.180.75.110 with SMTP id b14mr31343442wiw.21.1363233745124; Wed, 13 Mar 2013 21:02:25 -0700 (PDT) Received: by 10.194.20.35 with HTTP; Wed, 13 Mar 2013 21:02:24 -0700 (PDT) In-Reply-To: <514143B7.20002@gmail.com> References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> <513E61B2.2000307@gmail.com> <513F18FF.2060700@gmail.com> <513F8F69.2050204@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA141E89@SRVHKE02.rdm.cz> <514143B7.20002@gmail.com> Date: Wed, 13 Mar 2013 21:02:24 -0700 Message-ID: From: Cameron Byrne To: Alexandru Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 04:02:27 -0000 On Wed, Mar 13, 2013 at 8:27 PM, Alexandru Petrescu wrote: > Le 13/03/2013 17:28, jouni korhonen a =C3=A9crit : >> >> >> 13.3.2013 9.29 "Mikael Abrahamsson" > > kirjoitti: >> >>> >>> On Wed, 13 Mar 2013, V=C3=ADzdal Ale=C5=A1 wrote: >>> >>>> It routes ... the packet core gateway (ggsn/p-gw) is the default >>>> router for the UE and the TTL is being decremented by the >>>> gateway. >> >> >> On the gateway you would probably see the /64 prefix linked to a PDP >> Context / PDN connection or a GTP tunnel. > > > Something like: > > Prefix Next-hop Device > 2001:db8:1:1::/64 :: GTPtunnel0 > > or something like: > > Prefix Next-hop Device > 2001:db8:1:1::/64 fe80::5 GTPtunnel0 > > If the former, and that PDPContext/PDNconnectio-or-GTPtunnel is > MAC-addressable, then 64share wont work. > Mikael already answered this, but if i may, it does work. There is running code. Feel free to test it / review it http://dan.drown.org/android/clat/ CB > >>> Not all GGSN/PGW decrement TTL. When I traceroute from my UE to >>> the >>> >> Internet, my first hop seen in traceroute is the GUA address of the >> first router hop after the PGW: >>> >>> >>> UE<-GTP->SPGW<-IPv6->PE >>> >>> So my traceroute hop 1 is the GUA address of the PE. >> >> >> This is vendor implementation specific. Very popular but not really >> defined in 3gpp specs except for some deprecated stuff. > > > Jouni - this is way too generic to be understandable. > > (if we want to do any reverse engineering :-) > > Alex > >> >> - jouni >> >>> >>> -- Mikael Abrahamsson email: swmike@swm.pp.se >>> >>> >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Thu Mar 14 07:46:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DFA11E81C5 for ; Thu, 14 Mar 2013 07:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.186 X-Spam-Level: X-Spam-Status: No, score=-109.186 tagged_above=-999 required=5 tests=[AWL=1.413, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 VCXNj4OV4Eti for ; Thu, 14 Mar 2013 07:46:24 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0820711E81BF for ; Thu, 14 Mar 2013 07:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=456; q=dns/txt; s=iport; t=1363272384; x=1364481984; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=J7aCXGCWyAVirCjcW9Mv+HwZIQBVw+S/5ikYAQzXt6A=; b=f37wTSrIsDzVCfy/X1r9cLN5NfJcZSKkTs9FX6Hu3qz1dPsbjGCve1N+ ekyDddMVg+9SDTqQEf4EDhlQPbLDgLGyphHnn5tgsTDzw7qCHNFb8qvMe nISWFSu5GiUMizTmD/zJ1JTskfR0wcifF0x8gqCSMUtbAvkFOx1D1hfB8 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAJfhQVGtJV2Y/2dsb2JhbABEh2O9FYFiFnSCLAEEOlEBKhRCJwQbiAwMoAehI45fgxdhA5d3j2ODCoIo X-IronPort-AV: E=Sophos;i="4.84,845,1355097600"; d="scan'208";a="187246812" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 14 Mar 2013 14:46:23 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2EEkNnP018576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 14 Mar 2013 14:46:23 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 09:46:23 -0500 From: "Fred Baker (fred)" To: v6ops WG Thread-Topic: draft-liu-v6ops-ula-usage-analysis Thread-Index: AQHOIMKyuRqJmEDhbkSplQyJnXr4Tg== Date: Thu, 14 Mar 2013 14:46:23 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.243.94] Content-Type: text/plain; charset="us-ascii" Content-ID: <3F1CD98A2EC76F4E97AB65D6E12B5737@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 14:46:24 -0000 In the meeting at IETF 86, we discussed http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang, Cameron Byrne, 25-Feb-13 and the hum supported making that a working group draft. In this note, I'm = asking for ratification on the list - whether you agree or disagree, I'd ap= preciate your thoughts.= From victor@jvknet.com Thu Mar 14 08:00:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315A911E822E for ; Thu, 14 Mar 2013 08:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 Zvg-8jFu3KZe for ; Thu, 14 Mar 2013 08:00:45 -0700 (PDT) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9F77311E8224 for ; Thu, 14 Mar 2013 08:00:40 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id xa12so2322338pbc.22 for ; Thu, 14 Mar 2013 08:00:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:user-agent:date:subject:from:to:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=77slQbnOFlm7FjfI7xKoa4k6Qb5LP4Uuu7kI2WZqKPs=; b=W2U2VqmCbd79lX6iHYAGlOvnxTjHbe4l1FVIydSsuBWus2y/WIV46EgHJnNrkxjzL2 ZRcDRCQHtq9pSonFGkAGEvjJk1Qhp8VK2oyqw1LfQAhDiFvvGuwqihZIkr7xqtq8V1qY cFXTS6VLahN5JB4iuKvp5q5iMDKMyW2oyUwQZ7qcWoaehas8iRfgwxmV4PUgIDFqf5JE krY62W+70S5eKvC9J3ZizWm8bmp+9jlyD+q5CTEOfUJX6g/6DbJOU0rkNh6qm239XWs6 h6dGHDB/f5+OPab8RPa2ShH34ZBcHHXg+xfwgoZ+kWCrFe77ZSu+A3xrYUHkJj0Hcvyf ZvAQ== X-Received: by 10.68.56.232 with SMTP id d8mr6339706pbq.162.1363273239478; Thu, 14 Mar 2013 08:00:39 -0700 (PDT) Received: from [130.129.16.166] (dhcp-10a6.meeting.ietf.org. [130.129.16.166]) by mx.google.com with ESMTPS id y1sm3663380pbg.10.2013.03.14.08.00.34 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 14 Mar 2013 08:00:38 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 14 Mar 2013 11:00:30 -0400 From: Victor Kuarsingh To: "Fred Baker (fred)" , v6ops WG Message-ID: Thread-Topic: [v6ops] draft-liu-v6ops-ula-usage-analysis In-Reply-To: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQnVDIoTjIiMIGDiiAwgnqHzNr9YdLmkdcuD/JP7cgbyt1eTGnYwlw8apGDciqaBdac/TMy0 Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 15:00:57 -0000 I support a draft that describes ULAs with the following principles. - Early document text separating RFC1918 from ULAs (that RFC1819 != ULA) - I am ok with describing general use cases (I think we cannot enumerate all possible specific cases yet - IPv6 has not found it's way in enough places to understand the full extent of what and where ULAs can be used) - text needs to cover the drawbacks of using ULAs in those general cases (I.e. Host using ULA, then requires future Internet connectivity etc). - I also think that we should not specifically "recommend" or "not recommend" specific options. The key is to provide the right description of the drawbacks, issues and challenges that can arise If the draft takes on that form, I think it can provide valuable guidance (better then having people guess and use an incomplete set of data/experience to figure out how/when to use ULAs). Regards, Victor K On 2013-03-14 10:46 AM, "Fred Baker (fred)" wrote: >In the meeting at IETF 86, we discussed > >http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis >http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis > "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang, > Cameron Byrne, 25-Feb-13 > >and the hum supported making that a working group draft. In this note, >I'm asking for ratification on the list - whether you agree or disagree, >I'd appreciate your thoughts. >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Thu Mar 14 08:04:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6583911E8125 for ; Thu, 14 Mar 2013 08:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.621 X-Spam-Level: X-Spam-Status: No, score=-98.621 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 iDkn0bmkgcan for ; Thu, 14 Mar 2013 08:04:31 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4F211E822C for ; Thu, 14 Mar 2013 08:03:43 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id d46so2204665wer.31 for ; Thu, 14 Mar 2013 08:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=p08Fk+cMZ4AobDR+sLIbN4K9ZDK04+S8TE/qOdDr/IQ=; b=Gqd3zRGCxj2pwtiG6KTI8HaHdJdt+gH9SYxi2DMnkHpyVndM0w3KUMDFluVRzGWeqT CJPHFiQpRsSVT8TEit5fLBppq17B0Rw0p9nrGhvN8NVlNC9sMPvdg1TNNSg1r2i9YMlh zxp2Yv6fSgw8Jzc1E37y/+kSAjHOEhy1dNh5wTuDhiRC/h1vdxGbhGdQroQPVLPADbh2 YBXEHGnz+bpA1/M/AJxKHO2wVWRy1z4uDlvIaDc10HGODZO2cdCZ3S9w6tOr9aQ13LVY uBCbK/CwdZJ413D8hfF0zeaow+Dyg4hiQMhA9Gg5OnNZHjPvUZ2Qe498Q3NRecdZRVRk YcTg== X-Received: by 10.180.185.43 with SMTP id ez11mr4675589wic.28.1363273423052; Thu, 14 Mar 2013 08:03:43 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-189-141.as13285.net. [2.101.189.141]) by mx.google.com with ESMTPS id q13sm11184087wie.0.2013.03.14.08.03.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 08:03:41 -0700 (PDT) Message-ID: <5141E6D8.8080504@gmail.com> Date: Thu, 14 Mar 2013 15:03:52 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops WG Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 15:04:35 -0000 Since I wasn't there, let me hummmmm for adoption. The fact that how to use ULAs is a bit contentious is a very good reason for publishing this document. Regards Brian On 14/03/2013 14:46, Fred Baker (fred) wrote: > In the meeting at IETF 86, we discussed > > http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis > http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis > "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang, > Cameron Byrne, 25-Feb-13 > > and the hum supported making that a working group draft. In this note, I'm asking for ratification on the list - whether you agree or disagree, I'd appreciate your thoughts. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From jonghyouk@gmail.com Thu Mar 14 08:09:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000E611E8268 for ; Thu, 14 Mar 2013 08:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 yRvKHIZyhHaM for ; Thu, 14 Mar 2013 08:09:28 -0700 (PDT) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) by ietfa.amsl.com (Postfix) with ESMTP id A796D11E823E for ; Thu, 14 Mar 2013 08:09:14 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id cy12so1787784veb.34 for ; Thu, 14 Mar 2013 08:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=w+g2CepioEdAS/0Fow+iraqPlVmJPl72yZNrBSdiiHA=; b=xip+HTRoC+TdFzL7aJa4K+8CEgO6RZ08soVABDjauFDjJJT6IyPSoyL8KsdaFIGUlm xtjQ5waD2gjtwqWbu0kRpv4J8ODtLvSFprkq22rwEp1wlcG+jmIL3qnpO5nqIVHUt9rb dVHqW9PrJaDJDXYrnGwF94acMOVqAuvJ32/OVyaDc8gEBl1CAmCjmsxL2jx7fUqkEvAV QVeL5LjnuTHoKAMoRFfcSU1o3cMhqgs7hwuZZ0IMeobM0a2ABWOgiOrvNLiXkqDGbPzG JNI/uw9F7kRgXomN/pYe4PLErxXuzk5Z4zY4oObdy+3DOSGKAQ/GN37MSgTp+MUhpmsE kfsw== MIME-Version: 1.0 X-Received: by 10.220.109.210 with SMTP id k18mr2038924vcp.72.1363273747710; Thu, 14 Mar 2013 08:09:07 -0700 (PDT) Received: by 10.59.4.1 with HTTP; Thu, 14 Mar 2013 08:09:07 -0700 (PDT) In-Reply-To: <5141E6D8.8080504@gmail.com> References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <5141E6D8.8080504@gmail.com> Date: Thu, 14 Mar 2013 11:09:07 -0400 Message-ID: From: Jong-Hyouk Lee To: Brian E Carpenter Content-Type: multipart/alternative; boundary=047d7b3a98e676c9ef04d7e3e715 Cc: v6ops WG Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 15:09:29 -0000 --047d7b3a98e676c9ef04d7e3e715 Content-Type: text/plain; charset=UTF-8 I support this draft. Regarding some descriptions of general use cases and specific use cases, I'd like to encourage the authors to keep both: first give the general use cases and then give some specific use cases. In this way, this draft would provide better understanding of the ULA use to people. Cheers. On Thu, Mar 14, 2013 at 11:03 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Since I wasn't there, let me hummmmm for adoption. The fact that how to > use ULAs is a bit contentious is a very good reason for publishing > this document. > > Regards > Brian > > On 14/03/2013 14:46, Fred Baker (fred) wrote: > > In the meeting at IETF 86, we discussed > > > > http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis > > http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis > > "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang, > > Cameron Byrne, 25-Feb-13 > > > > and the hum supported making that a working group draft. In this note, > I'm asking for ratification on the list - whether you agree or disagree, > I'd appreciate your thoughts. > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random #email: jonghyouk (at) gmail (dot) com #webpage: http://sites.google.com/site/hurryon/ --047d7b3a98e676c9ef04d7e3e715 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I support this draft.

Regarding some descriptions of gen= eral use cases and specific use cases, I'd like to encourage the author= s to keep both: first give the general use cases and then give some specifi= c use cases. In this way, this draft would provide better understanding of = the ULA use to people.

Cheers.

On Thu, Mar= 14, 2013 at 11:03 AM, Brian E Carpenter <brian.e.carpenter@gmai= l.com> wrote:
Since I wasn't there, let me hummmmm for= adoption. The fact that how to
use ULAs is a bit contentious is a very good reason for publishing
this document.

Regards
=C2=A0 =C2=A0Brian

On 14/03/2013 14:46, Fred Baker (fred) wrote:
> In the meeting at IETF 86, we discussed
>
> http://datatracker.ietf.org/doc/draft-liu-v6ops-= ula-usage-analysis
> http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-= analysis
> =C2=A0 "Guidance of Using Unique Local Addresses", Bing Liu,= Sheng Jiang,
> =C2=A0 Cameron Byrne, 25-Feb-13
>
> and the hum supported making that a working group draft. In this note,= I'm asking for ratification on the list - whether you agree or disagre= e, I'd appreciate your thoughts.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops



--
=
RSM Department, TELECOM Bretagne, France
Jong-Hyouk Lee, liv= ing somewhere between /dev/null and /dev/random

#email:=C2=A0jonghyouk (at) gmail (dot) com
--047d7b3a98e676c9ef04d7e3e715-- From sean.stuart@gmail.com Thu Mar 14 08:10:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC9B11E823E for ; Thu, 14 Mar 2013 08:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, 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 UhkEUkaFXPQl for ; Thu, 14 Mar 2013 08:09:59 -0700 (PDT) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id 97AE711E827D for ; Thu, 14 Mar 2013 08:09:55 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id md12so2349290pbc.2 for ; Thu, 14 Mar 2013 08:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=E5o5v8h4aqGP1wQT0eXIyeK3isn22G4RM2JV3Unhi/w=; b=bklgOAHTbapqeiS85BtEgtkfVyTZLwbRupFGtsJW6f11kya28c4tIQ+P584qgjzM1C R/iPvpVP+eFzJKmLimyU0gkDKEuVexvhtBjLuDpMRJskN5N4SYe1laB4/YiQsPtHcDKe tmrvuRdJPvaNPJKsxU9u5k/fN2NCdj8nR2MFpIzSLREn7rSD4eOFAIwoX/HjNvQfRaPi UpkcgA9ojbKmZVipizrG6YntCDIelLNvZekZCXAOtXGqyERlzJw9sH7fx/4HbHdEbUEc sLmNxVDuQgAYAfMUK1FAjFO2t8CsQABUL9Jg7t9DloTZMguh6ShCCcMVFnEmCeHElpRd 64+A== X-Received: by 10.68.125.169 with SMTP id mr9mr6589072pbb.74.1363273791510; Thu, 14 Mar 2013 08:09:51 -0700 (PDT) Received: from ?IPv6:2001:df8::16:88a8:6fd5:4601:12ac? ([2001:df8:0:16:88a8:6fd5:4601:12ac]) by mx.google.com with ESMTPS id xc4sm3677991pbc.41.2013.03.14.08.09.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 08:09:50 -0700 (PDT) References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <022A4B0D-2352-4DB3-A06B-178CE1836D0D@gmail.com> X-Mailer: iPhone Mail (10B146) From: Sean Stuart Date: Thu, 14 Mar 2013 11:09:46 -0400 To: "Fred Baker (fred)" Cc: v6ops WG Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 15:10:00 -0000 I support this as a working group item.=20 On Mar 14, 2013, at 10:46 AM, "Fred Baker (fred)" wrote: > In the meeting at IETF 86, we discussed >=20 > http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis > http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis > "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang, > Cameron Byrne, 25-Feb-13 >=20 > and the hum supported making that a working group draft. In this note, I'm= asking for ratification on the list - whether you agree or disagree, I'd ap= preciate your thoughts. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Thu Mar 14 08:14:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FE911E8220 for ; Thu, 14 Mar 2013 08:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUpcTLVy7ZRo for ; Thu, 14 Mar 2013 08:14:01 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id D92A311E8171 for ; Thu, 14 Mar 2013 08:14:01 -0700 (PDT) Received: from dhcp-603a.meeting.ietf.org (dhcp-603a.meeting.ietf.org [130.129.96.58]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r2EFDxOr078296 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Thu, 14 Mar 2013 15:14:00 GMT (envelope-from joelja@bogus.com) Message-ID: <5141E936.7090006@bogus.com> Date: Thu, 14 Mar 2013 11:13:58 -0400 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: IPv6 Ops WG 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]); Thu, 14 Mar 2013 15:14:00 +0000 (UTC) Subject: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 15:14:02 -0000 some more thoughts since the presentation. Noted that I consulted the earlier draft, discussion in 6-man and appendix a in the slides. http://tools.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header-00 was the previous one. The request is not really for the ipv4 IPID/frag header in v6. it's for a unique per packet value over a given sample interval. The utility of ipid in ipv4 for this context has eroded over time, (this is not knock againt the draft I'm just trying to describe my understanding of the utility). IPID's in the context of mobile phones/mobile networks are typically unvarrying (due to header compresssion). rfc 6864 exists because modern implmentations cannot (and therefore don't) honor requirements for uniqueness in rfc791,rfc1122 e.g. the duration over which 16 bit IPID is valid for uniqueness is bounded by the size of the flow because if it were limited by the MDL it would limit that speed of a flow. a 10Gb/s flow with 1500 byte packets overflows a 16 bit value every 78 or so ms. if your capture is longer than that you can reasonably expect duplicate IPIDS to show up which are readily identifiable as not being duplicate packets. desirable properties of a unique per packet value to my mind... * That it doesn't cost us anything - it strikes me as undesirable that packets should in general have larger headers then they do today that adds cost all over the place. extension header processing or indeed fragmentation header use has conquences. see http://tools.ietf.org/html/draft-wkumari-long-headers-00 for dicussion that has come up about header processing in modern routers. and http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00 for a similar discussion about fragmentation headers. neither of these represent any form of consensus document, so take that with a grain of salt. * That it is applied to every packet - part of the stated utility of the ipv4 ipid is that it's present (with my noted caveats) you don't have to turn it on. likewise this implies that the application of the value does not impact the observation, having the packet size change because you're doing debugging means imho that you're not doing the From fred@cisco.com Thu Mar 14 08:27:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF5711E8290 for ; Thu, 14 Mar 2013 08:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.486 X-Spam-Level: X-Spam-Status: No, score=-110.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 2Qy2w3Wia9aT for ; Thu, 14 Mar 2013 08:27:09 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 89ABB11E82B0 for ; Thu, 14 Mar 2013 08:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1701; q=dns/txt; s=iport; t=1363274829; x=1364484429; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jixLpMgjwwsQuNaTE9WY1J+zXFOFzpJBmxdETMeQZwg=; b=SZ3d2WgY6jb25R4NiYip+h2h+rEn2L1bCW2Rk3w27Trx5arAha8L1UYI O3uDWS6jIXu0zrrHieA7xjMxng189pKESPkK8Ed9u3918aR6Ro8NevS+Y I0IJ8D8eGDRyawJaaWHIfKlb/U+X29fhQQNTFHWdNomuOYskYIn9ypiuZ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAB3rQVGtJV2c/2dsb2JhbAA6CcR4gWIWdIIqAQEBAwE6OAcQAgEIIhQQMiUCBA4FCAyHegbBRY1WA4EEAjEHgl9hA6dagwqBaj4 X-IronPort-AV: E=Sophos;i="4.84,845,1355097600"; d="scan'208";a="187479253" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 14 Mar 2013 15:27:08 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2EFR7kG022505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 15:27:07 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 10:27:07 -0500 From: "Fred Baker (fred)" To: Victor Kuarsingh Thread-Topic: [v6ops] draft-liu-v6ops-ula-usage-analysis Thread-Index: AQHOIMhj3X5Ay9I0E0eu68nw2IEjmw== Date: Thu, 14 Mar 2013 15:27:07 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B7D2428@xmb-rcd-x09.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.217.99] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops WG Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 15:27:13 -0000 On Mar 14, 2013, at 11:00 AM, Victor Kuarsingh wrote: >=20 > I support a draft that describes ULAs with the following principles. >=20 > - Early document text separating RFC1918 from ULAs (that RFC1819 !=3D ULA= ) I suspect that's code for something it doesn't well express. RFC 1918 provides several prefixes that can be used within a routing domain= and are not advertised outside it. ULAs are a more scalable way to impleme= nt that concept in IPv6. From that perspective, one could argue that a ULA = has an obvious relationship to an RFC 1918 prefix. RFC 1918 prefixes are often used behind a translator, which enables traffic= to cross the boundary and have a global address on the far side. I think t= his is the usage that you (and many) object to. I'm fine with the recommendation, but I think that it needs to be stated in= a manner that someone not from our community would be able to understand. Examples that I consider good uses of ULAs depend on the premise that the U= LA is only advertised within a limited domain. The reference to draft-bake= r-v6ops-b2b-private-routing-00.txt, for example, is a condition of controll= ed trust: two business entities want to exchange private routing among a se= t of systems used by both business entities but whose identity is not share= d. The ULA is used as a means of controlling routing without disclosing ide= ntity. Any company has some systems that are only used internally, and acce= ss to which is filtered at the firewall. A ULA eliminates the need for the = firewall rule; since it is not advertised outside, the system(s) is unreach= able from the outside. And so on.= From victor@jvknet.com Thu Mar 14 10:22:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1A911E81CB for ; Thu, 14 Mar 2013 10:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8m1c+zVb2fV for ; Thu, 14 Mar 2013 10:22:20 -0700 (PDT) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by ietfa.amsl.com (Postfix) with ESMTP id BBD3211E81CA for ; Thu, 14 Mar 2013 10:22:19 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id un1so2505414pbc.40 for ; Thu, 14 Mar 2013 10:22:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding:x-gm-message-state; bh=fSyGBcq4LPaeXmkigKNxXI2dOLrlEAEZYuLvg83mBqI=; b=M8eHghMdGRy/B55VFoDIDw2MhNuKmVnABU6bc4XH5wxmzqfEWAaM7zghrBiQ7F4hGv +ANQ0GbKX7tLljpw37mNQ5ngjBeX0+vtdc6MsteCumzIu2MH9zwh/nEFUEx3saZlaWlP OUrxQLxyAC0oIUduot1alSAinX1D0GdpqHKG2Bs9lkxqHIdykWuAVb04vYguWIPlJ+Ad /glKkJxVlUaaxj1pUsmB+nIjflbbjZHM3uE2ntPxsvokQidRmG+3EwKlAZH8/c3ApUgr fs3VSGXy0nKtt1THDhvCFqRI0zoSOMiSaEjYHv9k6H00pDfjFFdO0dXpevAXOTOgy9dG 6+WQ== X-Received: by 10.68.59.199 with SMTP id b7mr7718094pbr.167.1363281739173; Thu, 14 Mar 2013 10:22:19 -0700 (PDT) Received: from [130.129.16.166] (dhcp-10a6.meeting.ietf.org. [130.129.16.166]) by mx.google.com with ESMTPS id gf6sm4193714pbc.24.2013.03.14.10.22.15 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 14 Mar 2013 10:22:18 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 14 Mar 2013 13:22:10 -0400 From: Victor Kuarsingh To: "Fred Baker (fred)" Message-ID: Thread-Topic: [v6ops] draft-liu-v6ops-ula-usage-analysis In-Reply-To: <8C48B86A895913448548E6D15DA7553B7D2428@xmb-rcd-x09.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQkMiidvBBfWwj5t9lbp6hYdm5jQtsx9yieMF7bdbd1bLVAuw4oc7ZyLzxNGBWKX++y8DAY4 Cc: v6ops WG Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 17:22:21 -0000 On 2013-03-14 11:27 AM, "Fred Baker (fred)" wrote: > >On Mar 14, 2013, at 11:00 AM, Victor Kuarsingh wrote: > >> >> I support a draft that describes ULAs with the following principles. >> >> - Early document text separating RFC1918 from ULAs (that RFC1819 != ULA) > >I suspect that's code for something it doesn't well express. > >RFC 1918 provides several prefixes that can be used within a routing >domain and are not advertised outside it. ULAs are a more scalable way to >implement that concept in IPv6. From that perspective, one could argue >that a ULA has an obvious relationship to an RFC 1918 prefix. Agreed, there are some definite relationships, and there are some differences. One such difference, which if used correctly, you can connect two domains using ULAs and not need a NAT box in the middle given prefixes which are not expected to overlap (the pain we have with converging networks using RFC1918 with typical overlap). I think my point (perhaps not made well), was that ULAs and RFC1918 are not interchangeable (there are some differences). > >RFC 1918 prefixes are often used behind a translator, which enables >traffic to cross the boundary and have a global address on the far side. >I think this is the usage that you (and many) object to. I am not as opposed to this as others are. But I agree, the use case of ULA+NPTv6 and ULA+NAT66 are a bit more contentious. My point was I (personally) don't need to see a "don't do it", but think the drawbacks need to be well described (or points to references which describe this). I suspect others a bit more polarized on this particular topic. I would also think we should not recommend ULA-NPTv6 either. > >I'm fine with the recommendation, but I think that it needs to be stated >in a manner that someone not from our community would be able to >understand. Agreed. This document is most useful for people who are not typical RFC document consumers. Therefore extra attention needs to be applied to put it into a tone which makes sense for non-IETF frequent flyers. Regards, Victor K > From dougb@dougbarton.us Thu Mar 14 11:10:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDADF11E811B for ; Thu, 14 Mar 2013 11:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHCSj4SHQiki for ; Thu, 14 Mar 2013 11:10:38 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF3911E8106 for ; Thu, 14 Mar 2013 11:10:38 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:cb0:e254:8f57:3fc9] (unknown [IPv6:2001:470:d:5e7:cb0:e254:8f57:3fc9]) by dougbarton.us (Postfix) with ESMTPSA id 85FE422B6D for ; Thu, 14 Mar 2013 18:10:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1363284637; bh=NmB8vm3nxSyfpAReRq+8hYFIBPqUrsYz3lj3xhgIYx8=; h=Date:From:To:Subject:References:In-Reply-To; b=ebiRd0ugAjHiHTPracJmsq7HA9DyHoTwqGzuT4ZWadQ2dHJvFJRoIiMTIxX8M0LUk A0/4uomD7JHz4cm/LZ2HrkD33s8TpjgO9Nk8AG2IONSCZN5I6aPQhy2j5nzuEK8B4w WDJYW7ExNFr6mKv3uK80aWW9+zr3ufMjzGt9PaDU= Message-ID: <5142129D.5000503@dougbarton.us> Date: Thu, 14 Mar 2013 11:10:37 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 18:10:39 -0000 On 03/14/2013 10:22 AM, Victor Kuarsingh wrote: > > > On 2013-03-14 11:27 AM, "Fred Baker (fred)" wrote: > >> >> On Mar 14, 2013, at 11:00 AM, Victor Kuarsingh wrote: >> >>> >>> I support a draft that describes ULAs with the following principles. >>> >>> - Early document text separating RFC1918 from ULAs (that RFC1819 != ULA) >> >> I suspect that's code for something it doesn't well express. A very well-turned phrase, Fred. :) >> RFC 1918 provides several prefixes that can be used within a routing >> domain and are not advertised outside it. ULAs are a more scalable way to >> implement that concept in IPv6. From that perspective, one could argue >> that a ULA has an obvious relationship to an RFC 1918 prefix. > > Agreed, there are some definite relationships, and there are some > differences. One such difference, which if used correctly, you can > connect two domains using ULAs and not need a NAT box in the middle given > prefixes which are not expected to overlap (the pain we have with > converging networks using RFC1918 with typical overlap). You can do that with 1918 addresses too. In fact I'm at a loss to see how you could do that with ULA in a way that you could not do it with 1918 space. > I think my point > (perhaps not made well), was that ULAs and RFC1918 are not interchangeable > (there are some differences). Can you describe in detail what those differences are, and why they are important to you? I'm not saying you're wrong, just that I'd like to understand exactly what you're trying to convey. Doug From bill.jouris@insidethestack.com Thu Mar 14 11:14:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EFA11E8133 for ; Thu, 14 Mar 2013 11:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] 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 29J3V6ZKkqRz for ; Thu, 14 Mar 2013 11:14:29 -0700 (PDT) Received: from nm21.access.bullet.mail.mud.yahoo.com (nm21.access.bullet.mail.mud.yahoo.com [66.94.237.222]) by ietfa.amsl.com (Postfix) with ESMTP id 9223211E812B for ; Thu, 14 Mar 2013 11:14:29 -0700 (PDT) Received: from [66.94.237.198] by nm21.access.bullet.mail.mud.yahoo.com with NNFMP; 14 Mar 2013 18:14:28 -0000 Received: from [66.94.237.120] by tm9.access.bullet.mail.mud.yahoo.com with NNFMP; 14 Mar 2013 18:14:28 -0000 Received: from [127.0.0.1] by omp1025.access.mail.mud.yahoo.com with NNFMP; 14 Mar 2013 18:14:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 695223.99190.bm@omp1025.access.mail.mud.yahoo.com Received: (qmail 72959 invoked by uid 60001); 14 Mar 2013 18:14:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1363284868; bh=Ak7YXM4gWdQwk79w4WAogevmBW2bVlOf16dLoe+LPI8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=fhOAQApHe4dQufptIiJiuXr2HLZ1c0r+SjrIXPTQm0nWICUzTwPJcHtnZheoIaZNM6MKC/pat+VHoYyS3Lb8K20P57/lm7M7HIRqTomkB4A8xms2kGSZrqxs/Ajn+F4qP3WcWnfgbQ+VMzSq9oWD6ohXNLYeBLn4a2670mr9EIE= X-YMail-OSG: qs6.d8IVM1mXaAW3uUPX9MEWbN7LR.zBR5x5702RPtkj0ZF HW5js5jQArrXaMH6cssnx7LHrrcHveQiLGEgUSh4LbtSqdlxIMsIIb15AhCO 5ObPhiW3a2biAiuBkAg_bzq8RY4fE2Tb0TIxN6.HXe5uliSCmPoL.YKIr.VY EiGTrCoOQoRF8NeaQ55MIuqtCMJ2NvrckgGRZDMTeJCYZZAMlengnv7kFylg Q.2Ycv4gZHB23kaHWHOd64f4.dmR9ZSkQC8U3rOqtZfCKXumzqYGIAfYkz8X 1yQoXBTslBTEsejTcB.Oa.Nl5Oa1z7ZLEsNC0dMz6LJJ4fI2tnYhcGf.w17B E9wi6nKvWTsaAjxD1kuHNGdUtq5dZ2L6gPhnguKYZO60KNpGFs.sQaxPsorG lb0n8wB0Fd_F_zvxR3pHria6Y_J9ZptmQZUn2XcrmjqRM8i4GbGLAv7zJJ47 HTfVo_vGY_43f78an5xqBwokVERCCK3pLeJoO7du6PJu2EcMutxoBzpELQTM 6NTzD4yDRFnxRranBV5G9GOFYAfcbQY7tp5Yt4vZHsUvDqOH_ysmoYEfs3Df 626CjOshw6A9SLHI.3KVFrUQ77a9QCrnUUVH34Q-- Received: from [50.148.178.232] by web2801.biz.mail.ne1.yahoo.com via HTTP; Thu, 14 Mar 2013 11:14:27 PDT X-Rocket-MIMEInfo: 002.001, QWdyZWUuwqAgDQoNCldlIG5lZWQgdG8gZ2V0IG1vcmUgaW5mb3JtYXRpb24gb3V0IHRoZXJlIG9uICpob3cqIHZhcmlvdXMgZmVhdHVyZXMgb2YgSVB2NiBjYW4gYmUgdXNlZnVsbHkgaW1wbGVtZW50ZWQuDQoNCkJpbGwgSm91cmlzDQpJbnNpZGUgUHJvZHVjdHMsIEluYy4NCnd3dy5pbnNpZGV0aGVzdGFjay5jb20NCjgzMS02NTktODM2MA0KOTI1LTg1NS05NTEyIChkaXJlY3QpDQoNCg0KDQotLS0gT24gVGh1LCAzLzE0LzEzLCBGcmVkIEJha2VyIChmcmVkKSA8ZnJlZEBjaXNjby5jb20.IHdyb3RlOg0KDQoBMAEBAQE- X-Mailer: YahooMailClassic/15.1.5 YahooMailWebService/0.8.137.519 Message-ID: <1363284867.70766.YahooMailClassic@web2801.biz.mail.ne1.yahoo.com> Date: Thu, 14 Mar 2013 11:14:27 -0700 (PDT) From: Bill Jouris To: v6ops WG , "Fred Baker \(fred\)" In-Reply-To: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="36908767-1617508611-1363284867=:70766" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 18:14:30 -0000 --36908767-1617508611-1363284867=:70766 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Agree.=A0=20 We need to get more information out there on *how* various features of IPv6= can be usefully implemented. Bill Jouris Inside Products, Inc. www.insidethestack.com 831-659-8360 925-855-9512 (direct) --- On Thu, 3/14/13, Fred Baker (fred) wrote: From: Fred Baker (fred) Subject: [v6ops] draft-liu-v6ops-ula-usage-analysis To: "v6ops WG" Date: Thursday, March 14, 2013, 7:46 AM In the meeting at IETF 86, we discussed http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis =A0 "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang, =A0 Cameron Byrne, 25-Feb-13 and the hum supported making that a working group draft. In this note, I'm = asking for ratification on the list - whether you agree or disagree, I'd ap= preciate your thoughts. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --36908767-1617508611-1363284867=:70766 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Agree. 

We need to get more info= rmation out there on *how* various features of IPv6 can be usefully impleme= nted.

Bill Jouris
Inside= Products, Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (= direct)



--- On Thu, 3/14/13, Fred Baker (fred) = <fred@cisco.com> wrote:

From:= Fred Baker (fred) <fred@cisco.com>
Subject: [v6ops] draft-liu-v6o= ps-ula-usage-analysis
To: "v6ops WG" <v6ops@ietf.org>
Date: Thu= rsday, March 14, 2013, 7:46 AM

In the meeti= ng at IETF 86, we discussed

http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usag= e-analysis
http://tools.ietf.org/html/draft-liu-v6o= ps-ula-usage-analysis
  "Guidance of Using Unique Local Address= es", Bing Liu, Sheng Jiang,
  Cameron Byrne, 25-Feb-13

and t= he hum supported making that a working group draft. In this note, I'm askin= g for ratification on the list - whether you agree or disagree, I'd appreci= ate your thoughts.
_______________________________________________
v6= ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/li= stinfo/v6ops
--36908767-1617508611-1363284867=:70766-- From victor@jvknet.com Thu Mar 14 11:53:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0AE21F8E99 for ; Thu, 14 Mar 2013 11:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 hH1VsHmi6bO6 for ; Thu, 14 Mar 2013 11:53:39 -0700 (PDT) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id C610E11E80F2 for ; Thu, 14 Mar 2013 11:53:38 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id ro8so2642513pbb.32 for ; Thu, 14 Mar 2013 11:53:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:user-agent:date:subject:from:to:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=YAaGSj+qNGRpDR93HUI/44bHNwL1fAjUrFWVIFgpCBM=; b=Ibk+CrNQx7SArUW3sYXeUYGsJREIfWClOmw1/6ETQldu3Ay4jLqBS0tDcl6oMg5Kit Mhg+pv9hlvRYq+ooUGRQhC69gaQadTIuIaiybyI0YiL/mWqgpAGwPxC3Wr525B/6DQ7G TRDuczfW+xTXXkzDArfYA4+FeacjzvT1JSYeJyTX5AW6bRTHycm9GsIiCtcx6B//o2W6 Yb8mYsv8OGiEtq6FyfbrMpuKfU7rETXQyfdn0qTQuuroeJTpZf+yLs84NVpSO9j9oDOq VulYnVN2bPkciG4iyNaKBaeYJ+V1cZknsDMB3EE0A47Y/9kdNIJkiQthyR6UwRTeZfbi QHug== X-Received: by 10.68.233.229 with SMTP id tz5mr8119187pbc.172.1363287218300; Thu, 14 Mar 2013 11:53:38 -0700 (PDT) Received: from [130.129.16.166] (dhcp-10a6.meeting.ietf.org. [130.129.16.166]) by mx.google.com with ESMTPS id eh5sm4486919pbc.44.2013.03.14.11.53.33 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 14 Mar 2013 11:53:37 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 14 Mar 2013 14:53:30 -0400 From: Victor Kuarsingh To: Doug Barton , Message-ID: Thread-Topic: [v6ops] draft-liu-v6ops-ula-usage-analysis In-Reply-To: <5142129D.5000503@dougbarton.us> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Gm-Message-State: ALoCoQkiCvTbq4bOXeUA8W5R6myL4cgFHwnQ0jkBkoz41tEW7eMYC+dxapziUDVgbIqM9FI8DNYE Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 18:53:40 -0000 Doug, On 2013-03-14 2:10 PM, "Doug Barton" wrote: >On 03/14/2013 10:22 AM, Victor Kuarsingh wrote: >> >> >> On 2013-03-14 11:27 AM, "Fred Baker (fred)" wrote: >> >>> >>> On Mar 14, 2013, at 11:00 AM, Victor Kuarsingh >>>wrote: >>> >>>> >>>> I support a draft that describes ULAs with the following principles. >>>> >>>> - Early document text separating RFC1918 from ULAs (that RFC1819 !=3D >>>>ULA) >>> >>> I suspect that's code for something it doesn't well express. > >A very well-turned phrase, Fred. :) > >>> RFC 1918 provides several prefixes that can be used within a routing >>> domain and are not advertised outside it. ULAs are a more scalable way >>>to >>> implement that concept in IPv6. From that perspective, one could argue >>> that a ULA has an obvious relationship to an RFC 1918 prefix. >> >> Agreed, there are some definite relationships, and there are some >> differences. One such difference, which if used correctly, you can >> connect two domains using ULAs and not need a NAT box in the middle >>given >> prefixes which are not expected to overlap (the pain we have with >> converging networks using RFC1918 with typical overlap). > >You can do that with 1918 addresses too. In fact I'm at a loss to see >how you could do that with ULA in a way that you could not do it with >1918 space. Well the statement is somewhat dependant on how the two domains were addressed (I.e. Did they use the whole RFC1918 space, was it optimal [I.e. Spare usage with poor summarization etc]). So, an example (just one example) would be Network-A and Network-B. Network-A is using 10/8 with usage across the entire block. Network-B is using 10/8 with usage across the block as well. Assuming no renumbering (which can be extremely difficult in some places) to connect these two network domains, you may need a NAT box in the middle or some other way to get stuff to communication across the overlapping domains (in fact I have personally had to do this more then once converging networks together). In the ULA/IPv6 example, we take the same Network-A and Network-B. Network-A uses FD00:/48 and assigns it to the infrastructure. Network-B uses FD00:/48 and assigns it to the infrastructure. I now attempt to connect these two domains. From an addressing perspective I do not need a NAT function between networks, I can just route traffic. Of course I may need to change some routing policy, filtering rules and other items depending on how each network built up their independent (pre-converged) policies. Using ULAs, one has [arguably] more flexibility in some cases vs. what we are typically used to in RFC1918 land. This is due to the amount of overall space available to generate ULA prefixes. So my position is that although I may not expect to need to have global connectivity with ULAs, I have different expectations as to what I can do with this environment in the future. (Section 4.3 RFC4193) Also, with RFC1918, some SPs (and enterprises) may have run out of space. This is much less likely in ULA/IPv6 given that a run out of my /48 block (likely prefix run out, not IPv6 address run out), I can spawn a second, third, fourth=8A block and keep going. A nice side point supporting ULA is that my network policy can remain largely the same (filtering, routing, etc) if it's build around FC00::/7 > >> I think my point >> (perhaps not made well), was that ULAs and RFC1918 are not >>interchangeable >> (there are some differences). > >Can you describe in detail what those differences are, and why they are >important to you? There are places in IPv4 land where I may not have been able to use global IPv4 addresses (I.e. If I needed a /8, /9, /10 as a non-large company) so I would have been stuck with RFC1918. In IPv6, you can feasibly get addresses that you need up front. You may want to do this if you may expect to have global connectivity in the future (of course you can use ULA+NAT, but there are options which were not necessary available in IPv4). This means that when evaluating addressing iPv6, as part of the ULA considerations, you can choose to use GUA for future use options. So, one may artificially put themselves at a disadvantage with ULAs which may be avoidable (but was less of an option with IPv4 due to space constraints). If people believe that ULAs are just a new form of RFC1918, they may default to ULAs needlessly. >From a usage perspective, in IPv4, one typically gave a host a single IPv4 address. In IPv6, you can assign multiple addresses. So you can assign a ULA and a GUA (I know there are questions about source address selection here). This option is easy to do and you can then provide connectivity for both intra-zone flows using ULAs and external zone flows using GUAs. One may ask why would someone do this? (I.e. Why not use multiple GUA blocks and treat them differently etc). Well this is an internal choice to be made by the operator/enterprise. Back to the ULA case, if a business had a GUA/PA space (which may change over time), the ULA space can be somewhat stable with internal DNS names attached to that (perhaps you need to renumber later on for the PA space). I am not saying this is a good idea, but you can do it. I personally do this in my home/test but I don=B9t represent a big enough network and endpoints to say it works in the general case. Another point, as RFC4193 was written, applications are permitted to use ULAs in an identical manner as global addresses. This may cause problems depending on things are deployed. (Section 6.1 / RFC4193) "Applications can treat these addresses in an identical manner as any other type of global IPv6 unicast addresses." Just a few things.. I guess there is room for more discussion. Regards, Victor K > >I'm not saying you're wrong, just that I'd like to understand exactly >what you're trying to convey. > >Doug > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From dougb@dougbarton.us Thu Mar 14 12:26:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FB511E8150 for ; Thu, 14 Mar 2013 12:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 bqPJFRCbehhz for ; Thu, 14 Mar 2013 12:26:26 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 9043A11E812C for ; Thu, 14 Mar 2013 12:26:26 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:b912:86f0:43a6:c70c] (unknown [IPv6:2001:470:d:5e7:b912:86f0:43a6:c70c]) by dougbarton.us (Postfix) with ESMTPSA id 3B74022B6D for ; Thu, 14 Mar 2013 19:26:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1363289186; bh=UFnJH8uMNVJPzflTfmSSfZUH/DoTl2NgwS5jMum045Y=; h=Date:From:To:Subject:References:In-Reply-To; b=jPiXvgP03U88DX2m/OxXahvVe+wrcuNumjd1l3tYK+vgmXbzUzfrfWno2cLdaVS9B hBc0BHM3RAWd4EfYQX/nvOTZ42HkvdmIRGUev5ULeswmsBkXIC5NaLQlXwGo/eunvH 3Onopq/uDajTDzyo9SIAGotXOLwSobhhL4Wd9PKc= Message-ID: <51422462.2010904@dougbarton.us> Date: Thu, 14 Mar 2013 12:26:26 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:26:27 -0000 On 03/14/2013 11:53 AM, Victor Kuarsingh wrote: > Well the statement is somewhat dependant on how the two domains were > addressed (I.e. Did they use the whole RFC1918 space, was it optimal [I.e. > Spare usage with poor summarization etc]). So we can summarize by saying that the distinction is that operators are less likely to run into overlapping networks with ULA. That is an important thing to note, but it's not a functional difference. > From a usage perspective, in IPv4, one typically gave a host a single IPv4 > address. In IPv6, you can assign multiple addresses. You can assign multiple addresses in IPv4 too. That's not actually a difference. > Another point, as RFC4193 was written, applications are permitted to use > ULAs in an identical manner as global addresses. This may cause problems > depending on things are deployed. > > (Section 6.1 / RFC4193) "Applications can treat these addresses in an > identical manner as > any other type of global IPv6 unicast addresses." I don't see how this is different from 1918 space. Doug From nalini.elkins@insidethestack.com Thu Mar 14 14:52:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDBA1F0D0F for ; Thu, 14 Mar 2013 14:52:39 -0700 (PDT) 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_13=0.6] 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 ZKoSbpZzbZDo for ; Thu, 14 Mar 2013 14:52:38 -0700 (PDT) Received: from nm2-vm0.access.bullet.mail.sp2.yahoo.com (nm2-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.158]) by ietfa.amsl.com (Postfix) with ESMTP id 6D60F1F0D09 for ; Thu, 14 Mar 2013 14:52:38 -0700 (PDT) Received: from [98.139.44.103] by nm2.access.bullet.mail.sp2.yahoo.com with NNFMP; 14 Mar 2013 21:52:36 -0000 Received: from [98.139.44.78] by tm8.access.bullet.mail.sp2.yahoo.com with NNFMP; 14 Mar 2013 21:52:36 -0000 Received: from [127.0.0.1] by omp1015.access.mail.sp2.yahoo.com with NNFMP; 14 Mar 2013 21:52:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 723506.68274.bm@omp1015.access.mail.sp2.yahoo.com Received: (qmail 34189 invoked by uid 60001); 14 Mar 2013 21:52:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1363297956; bh=pJcBxCZgJAeUqgdp/q1mj8eNSQhDD8e8FpFPt/dUviE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kXLUUvkCD/ImT38nJJzJM9O3xpOCnvizcCAF1bwcizl58Q6/DEMU92+nnQ9fjNgE1uAn8DMs8TP5ALBgFnFfs6BIeo2NW+eUydiNiPdZMpa/gGG7CJ67uBX3gpjiREqdSUq/XVFTlrjzklpv+J/3CYYJl21R2BA/M2yPmg5rv+M= X-YMail-OSG: miay8WIVM1mg_XXEQcbFgs3BYW_rNP6szZQa7gK0vLQa3QW Qr6s_ZEU3rM3xLbtfHHGDDIfner2IqvK.hEIg5nn1QpUKstHCANZqlrqMc7i Mp.nhznbQ0UfdIkq7d8ppmV1Jxnr1oLptnNkvp3lqd8BZcTzoCVfT8Ik6_XD ukrhSue.sdCbJsI4UteD6RG7QS.7MqchpbgOEyqEp5YT2dUxI.n6u2KJw5Uy MYtoSoexJ63nWi0ODIXecARnZwIkXWgJCajtFaSdFtueB7faoREVW8trPz99 CjQfdgh5hAH3Y.Cv6Ir2HZCxqe8k3D.8mzB7aY5qBzfYCfhQQKtMXcil0f3D cAG6TBiCIcgsZ.FaDlNS_3DWKhl6KInUS9ocLBbuvScS5P3BC.XikuFW4z4x nJLlKLHeEl2fGvmNXmAvqGvD_i_Dy6Q9O0g3hRYFF6_jdoRcYu1evk.bTbSW F.ZH8qTt51RTD4CnQrQl65B04nKX6GF5Uj3Ijy9yg0PxSEe68_LMN3Dvx2G7 wfYyYf3Nn5Wa8LLfeorBBOIE3JbZ4OFA.LBYsd07w3mGiQ61TCFx5klffuQU HzkiNCggRSGq5isO90WELdn5oIUTSPezVrqmGXrZ4V84h Received: from [130.129.21.38] by web2806.biz.mail.ne1.yahoo.com via HTTP; Thu, 14 Mar 2013 14:52:36 PDT X-Rocket-MIMEInfo: 002.001, Sm9lbCwKClRoYW5rcyBzbyBtdWNoIGZvciB5b3VyIGZlZWRiYWNrLiDCoCBPbmUgb2YgdGhlIGFsdGVybmF0aXZlcyB0aGF0IHdlIGFyZSBsb29raW5nIGF0IHRvIHByb3ZpZGUgYSBQYWNrZXQgU2VxdWVuY2UgTnVtYmVyIGlzIGEgJ1NISU0nIHN1Y2ggYXMgdGhhdCBwcm92aWRlZCBieSBTRUFMLgoKaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvL3JmYzUzMjAKClRoaXMgaGVhZGVyIChpZiBJIGFtIHJlYWRpbmcgdGhpcyBjb3JyZWN0bHkhKSB3b3VsZCBiZSBiZXR3ZWVuIHRoZSBUQ1Agb3IgVURQIGhlYWQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.137.519 References: <5141E936.7090006@bogus.com> Message-ID: <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Date: Thu, 14 Mar 2013 14:52:36 -0700 (PDT) From: Nalini Elkins To: joel jaeggli , IPv6 Ops WG In-Reply-To: <5141E936.7090006@bogus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 21:52:39 -0000 Joel,=0A=0AThanks so much for your feedback. =A0 One of the alternatives th= at we are looking at to provide a Packet Sequence Number is a 'SHIM' such a= s that provided by SEAL.=0A=0Ahttp://tools.ietf.org/html//rfc5320=0A=0AThis= header (if I am reading this correctly!) would be between the TCP or UDP h= eader and the application payload.=0A=0AOne of the things that SEAL provide= s is:=0A=0ASEAL_ID - a 32-bit Identification value, randomly initialized an= d monotonically incremented for each SEAL protocol packet=0A=0ASo, this mig= ht provide exactly what we are looking for! =A0=A0=0A=0AWe do understand th= at there are a number of issues with IPv6 extension headers. =A0=A0We are n= ot wedded to a particular implementation and whatever will provide the info= rmation we need is perfect! =A0 But, we have just found out about this RFC = and need to study it more to see if there are any drawbacks.=0A=0AThanks,= =0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insideth= estack.com=0A=0A=0A=0A________________________________=0AFrom: joel jaeggli= =0ATo: IPv6 Ops WG =0ASent: Thursday, M= arch 14, 2013 8:13 AM=0ASubject: [v6ops] draft-elkins-v6ops-ipv6-ipid-neede= d-00=0A=0Asome more thoughts since the presentation.=0A=0ANoted that I cons= ulted the earlier draft, discussion in 6-man and appendix a in the slides.= =0A=0Ahttp://tools.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header-0= 0=0A=0Awas the previous one.=0A=0AThe request is not really for the ipv4 IP= ID/frag header in v6. it's for a unique per packet value over a given sampl= e interval.=0A=0AThe utility of ipid in ipv4 for this context has eroded ov= er time, (this is not knock againt the draft I'm just trying to describe my= understanding of the utility). IPID's in the context of mobile phones/mobi= le networks are typically unvarrying (due to header compresssion). rfc 6864= exists because modern implmentations cannot (and therefore don't) honor re= quirements for uniqueness in rfc791,rfc1122 e.g. the duration over which 16= bit IPID is valid for uniqueness is bounded by the size of the flow becaus= e if it were limited by the MDL it would limit that speed of a flow. a 10Gb= /s flow with 1500 byte packets overflows a 16 bit value every 78 or so ms. = if your capture is longer than that you can reasonably expect duplicate IPI= DS to show up which are readily identifiable as not being duplicate packets= .=0A=0Adesirable properties of a unique per packet value to my mind...=0A= =0A* That it doesn't cost us anything - it strikes me as undesirable that p= ackets should in general have larger headers then they do today that adds c= ost all over the place. extension header processing or indeed fragmentation= header use has conquences.=0A=0Asee http://tools.ietf.org/html/draft-wkuma= ri-long-headers-00=0A=0Afor dicussion that has come up about header process= ing in modern routers.=0A=0Aand=0A=0Ahttp://tools.ietf.org/html/draft-taylo= r-v6ops-fragdrop-00=0A=0Afor a similar discussion about fragmentation heade= rs.=0A=0Aneither of these represent any form of consensus document, so take= that with a grain of salt.=0A=0A* That it is applied to every packet - par= t of the stated utility of the ipv4 ipid is that it's present (with my note= d caveats) you don't have to turn it on. likewise this implies that the app= lication of the value does not impact the observation, having the packet si= ze change because you're doing debugging means imho that you're not doing t= he=0A_______________________________________________=0Av6ops mailing list= =0Av6ops@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/v6ops=A0 From tom.taylor.stds@gmail.com Thu Mar 14 15:18:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D96421F86F0 for ; Thu, 14 Mar 2013 15:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.810, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 TEZS+iBzOnjf for ; Thu, 14 Mar 2013 15:18:34 -0700 (PDT) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id 85E3F21F841C for ; Thu, 14 Mar 2013 15:18:34 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id um15so2876426pbc.14 for ; Thu, 14 Mar 2013 15:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lB0r+AwGuv2vncO47gGnnFLPC+CmEFUCjDpw6xr1SXw=; b=N4RWBREIBaiUDTNDns5060RuQaLa3+2zvPNBFnc6deinq/0oJA8Hy7+uV+Sjhl4lb8 lkiM2F7z2nn8SjLZqetZKH2QFjDw+6Kyz7oUQ/g5RglufZCTrAVRcRyQqdff1opVowgL Cs8rfqlj0CphntsxGi/h9+4Pr9APvqdgjSqJOgptPt8otYlhLwipHZAetCe2XyKbeJah jalre+ICTazKP9brXtN7//TMUn1Y5/v5rfKJPdMWMY0iq58M4sDls/DJrY0Sk79FSon7 OEm07inbLiuv3gTpsMZEGpyNJNwPaxIKzuklGuHmI9wEOSw6Gs5m4ENyPtPHPkJYwqjk RHyg== X-Received: by 10.68.224.65 with SMTP id ra1mr9888649pbc.55.1363299514113; Thu, 14 Mar 2013 15:18:34 -0700 (PDT) Received: from ?IPv6:2001:df8:0:16:8094:982e:a909:b7ad? ([2001:df8:0:16:8094:982e:a909:b7ad]) by mx.google.com with ESMTPS id cy4sm3630927pbc.13.2013.03.14.15.18.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 15:18:33 -0700 (PDT) Message-ID: <51424CAB.9060305@gmail.com> Date: Thu, 14 Mar 2013 18:18:19 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 22:18:35 -0000 Agree. On 14/03/2013 10:46 AM, Fred Baker (fred) wrote: > In the meeting at IETF 86, we discussed > > http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis > http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis > "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang, > Cameron Byrne, 25-Feb-13 > > and the hum supported making that a working group draft. In this note, I'm asking for ratification on the list - whether you agree or disagree, I'd appreciate your thoughts. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > . > From Fred.L.Templin@boeing.com Thu Mar 14 15:27:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956E111E81AF for ; Thu, 14 Mar 2013 15:27:44 -0700 (PDT) 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_13=0.6] 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 9dLVsxRgWvym for ; Thu, 14 Mar 2013 15:27:43 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id E554211E812B for ; Thu, 14 Mar 2013 15:27:43 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r2EMRhLb006165 for ; Thu, 14 Mar 2013 15:27:43 -0700 Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r2EMRROL006066 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 14 Mar 2013 15:27:42 -0700 Received: from XCH-BLV-506.nw.nos.boeing.com (130.247.25.196) by XCH-NWHT-06.nw.nos.boeing.com (130.247.25.110) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 14 Mar 2013 15:27:38 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.214]) by XCH-BLV-506.nw.nos.boeing.com ([169.254.6.56]) with mapi id 14.02.0328.011; Thu, 14 Mar 2013 15:27:37 -0700 From: "Templin, Fred L" To: Nalini Elkins , joel jaeggli , IPv6 Ops WG Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Thread-Index: AQHOIP5NpovTMHVwr0KJKw2dWHfftZilw1Sg Date: Thu, 14 Mar 2013 22:27:36 +0000 Message-ID: <2134F8430051B64F815C691A62D9831802F8BE@XCH-BLV-504.nw.nos.boeing.com> References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> In-Reply-To: <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 22:27:44 -0000 Hi Nalini, Just to clarify, RFC5320 will soon be obsoleted by 'draft-templin-intarea-s= eal'. But, also note that the source and destination would both need to be SEAL-a= ware, so the complexity would be worse than just asking the source to uncondition= ally include an IPv6 fragment header with a well-behave ID. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Nalini Elkins > Sent: Thursday, March 14, 2013 2:53 PM > To: joel jaeggli; IPv6 Ops WG > Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 >=20 > Joel, >=20 > Thanks so much for your feedback. =A0 One of the alternatives that we are > looking at to provide a Packet Sequence Number is a 'SHIM' such as that > provided by SEAL. >=20 > http://tools.ietf.org/html//rfc5320 >=20 > This header (if I am reading this correctly!) would be between the TCP or > UDP header and the application payload. >=20 > One of the things that SEAL provides is: >=20 > SEAL_ID - a 32-bit Identification value, randomly initialized and > monotonically incremented for each SEAL protocol packet >=20 > So, this might provide exactly what we are looking for! >=20 > We do understand that there are a number of issues with IPv6 extension > headers. =A0=A0We are not wedded to a particular implementation and whate= ver > will provide the information we need is perfect! =A0 But, we have just fo= und > out about this RFC and need to study it more to see if there are any > drawbacks. >=20 > Thanks, >=20 > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com >=20 >=20 >=20 > ________________________________ > From: joel jaeggli > To: IPv6 Ops WG > Sent: Thursday, March 14, 2013 8:13 AM > Subject: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 >=20 > some more thoughts since the presentation. >=20 > Noted that I consulted the earlier draft, discussion in 6-man and appendi= x > a in the slides. >=20 > http://tools.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header-00 >=20 > was the previous one. >=20 > The request is not really for the ipv4 IPID/frag header in v6. it's for a > unique per packet value over a given sample interval. >=20 > The utility of ipid in ipv4 for this context has eroded over time, (this > is not knock againt the draft I'm just trying to describe my understandin= g > of the utility). IPID's in the context of mobile phones/mobile networks > are typically unvarrying (due to header compresssion). rfc 6864 exists > because modern implmentations cannot (and therefore don't) honor > requirements for uniqueness in rfc791,rfc1122 e.g. the duration over whic= h > 16 bit IPID is valid for uniqueness is bounded by the size of the flow > because if it were limited by the MDL it would limit that speed of a flow= . > a 10Gb/s flow with 1500 byte packets overflows a 16 bit value every 78 or > so ms. if your capture is longer than that you can reasonably expect > duplicate IPIDS to show up which are readily identifiable as not being > duplicate packets. >=20 > desirable properties of a unique per packet value to my mind... >=20 > * That it doesn't cost us anything - it strikes me as undesirable that > packets should in general have larger headers then they do today that add= s > cost all over the place. extension header processing or indeed > fragmentation header use has conquences. >=20 > see http://tools.ietf.org/html/draft-wkumari-long-headers-00 >=20 > for dicussion that has come up about header processing in modern routers. >=20 > and >=20 > http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00 >=20 > for a similar discussion about fragmentation headers. >=20 > neither of these represent any form of consensus document, so take that > with a grain of salt. >=20 > * That it is applied to every packet - part of the stated utility of the > ipv4 ipid is that it's present (with my noted caveats) you don't have to > turn it on. likewise this implies that the application of the value does > not impact the observation, having the packet size change because you're > doing debugging means imho that you're not doing the > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nalini.elkins@insidethestack.com Thu Mar 14 15:37:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D22811E8133 for ; Thu, 14 Mar 2013 15:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] 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 RC7dELAsCkvg for ; Thu, 14 Mar 2013 15:37:31 -0700 (PDT) Received: from nm23-vm0.access.bullet.mail.mud.yahoo.com (nm23-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.141]) by ietfa.amsl.com (Postfix) with ESMTP id BB10B11E81AB for ; Thu, 14 Mar 2013 15:37:31 -0700 (PDT) Received: from [66.94.237.192] by nm23.access.bullet.mail.mud.yahoo.com with NNFMP; 14 Mar 2013 22:37:31 -0000 Received: from [66.94.237.100] by tm3.access.bullet.mail.mud.yahoo.com with NNFMP; 14 Mar 2013 22:37:31 -0000 Received: from [127.0.0.1] by omp1005.access.mail.mud.yahoo.com with NNFMP; 14 Mar 2013 22:37:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 417357.84426.bm@omp1005.access.mail.mud.yahoo.com Received: (qmail 64985 invoked by uid 60001); 14 Mar 2013 22:37:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1363300650; bh=6WLmLczYPvbT3PiPHye+2yNK51Sj4ULPP2G8Vg8CFNw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=0ObN9rBgwLqWCRcTRi5FT6bt/QJu/olu0KgqBC0X8Hinaue1I7dapW/4eLSVviiuXpTDsD33Z/RneaUD93nr3qZZ5S4T2n0IF5rV8dJtjMFYiWgID8aOO1wuP1/FJhXgXERappPwC4ZzLQQLWfpDUQfeKe3rqpr0daYGf5yIw6M= X-YMail-OSG: 5wMAE8sVM1k20yYmzsvBGL3UjwGecLsR7nZf3pUybM0tdcw .NlwoVlWSAYs_tX_3l68u9_Ng8pHISDFwgPmCASUbI9vwMZ19uiK31WRJphX NfMFRqUVZZ2nUXI2XDXWXTz_nAESBGZzTy78k7QEsNayRGvhvsYCw_RthIEj USJ6U0qadBfeYdjzUllodNL9pQqJun7X5yVZFlP.aFR.vmiXkXcyEhe3u0oN sGfjfvdrOQiVh5SyeBPsBBhRTJQf.qVGq78dHXe5a4S.nsDk6SV74gLjWPGS S0Ji48_gqYF3wD3Va297P4S.MhcSK20lTh1tOyaS3.6.W7hi5.L6yqCQeSJd PPxgJdbXwqyPxQ5L57FByRYpTviHA.ihKcGdJNCW4TxO4D_b8o5EsuD2Xobg .bbXekvxH.y_ndt4..CbqLlFnkIt0Xok43DK058ca.ZHZhxYYErchSsg3EAW IEAjeIpfgSSan1FeZGcGMSy.jjZr.KbTfKZfEJupl7gY3sK70InwrqrJU37G 5sMLKk6nHoTaCb.idBQ_23hx1lilnpOsDzTAtJGwPUK9K0IZrOndJ65ArLB7 cJz4FZTO54EBWOxBUn8UzNFafEv0fA_M5Kvqlkv3E0OE3 Received: from [130.129.21.38] by web2806.biz.mail.ne1.yahoo.com via HTTP; Thu, 14 Mar 2013 15:37:30 PDT X-Rocket-MIMEInfo: 002.001, RnJlZCwKClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4KCldlIGFyZSBnZXR0aW5nIGEgbG90IG9mIGNvbW1lbnRzIGZyb20gcGVvcGxlIHRoYXQgdGhlIHJlYWxpdHkgb2YgdGhlIHNpdHVhdGlvbiBpcyB0aGF0IG1hbnkgZmlyZXdhbGxzIGRyb3AgcGFja2V0cyB3aXRoIElQdjYgZXh0ZW5zaW9uIGhlYWRlcnMuIMKgIEluY2x1ZGluZyBmcmFnbWVudCBoZWFkZXIuIMKgIFBlb3BsZSBzZWVtIHRvIGZlZWwgdGhlcmUgYXJlIGEgbG90IG9mIHNlY3VyaXR5IGlzc3VlcyB3aXRoIElQdjYgZXh0ZW5zaW9uIGhlYWQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.137.519 References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D9831802F8BE@XCH-BLV-504.nw.nos.boeing.com> Message-ID: <1363300650.51430.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Date: Thu, 14 Mar 2013 15:37:30 -0700 (PDT) From: Nalini Elkins To: "Templin, Fred L" , joel jaeggli , IPv6 Ops WG In-Reply-To: <2134F8430051B64F815C691A62D9831802F8BE@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1510626085-911830779-1363300650=:51430" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 22:37:33 -0000 --1510626085-911830779-1363300650=:51430 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Fred,=0A=0AThanks for your comments.=0A=0AWe are getting a lot of comments = from people that the reality of the situation is that many firewalls drop p= ackets with IPv6 extension headers. =A0 Including fragment header. =A0 Peop= le seem to feel there are a lot of security issues with IPv6 extension head= ers. =A0I do feel that adding an atomic fragment header with each packet wo= uld have been a great solution but does not seem to have much support. =A0 = We have not ruled anything out but I am just telling you what we are hearin= g.=0A=0ABTW, any chance of getting a timestamp in the SEAL header?=0A=A0=0A= Thanks,=0A=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Aww= w.insidethestack.com=0A=0A=0A=0A________________________________=0A From: "= Templin, Fred L" =0ATo: Nalini Elkins ; joel jaeggli ; IPv6 Ops WG =0ASent: Thursday, March 14, 2013 3:27 PM=0ASubject: RE: [v6op= s] draft-elkins-v6ops-ipv6-ipid-needed-00=0A =0AHi Nalini,=0A=0AJust to cla= rify, RFC5320 will soon be obsoleted by 'draft-templin-intarea-seal'.=0ABut= , also note that the source and destination would both need to be SEAL-awar= e,=0Aso the complexity would be worse than just asking the source to uncond= itionally=0Ainclude an IPv6 fragment header with a well-behave ID.=0A=0ATha= nks - Fred=0Afred.l.templin@boeing.com=0A=0A> -----Original Message-----=0A= > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= =0A> Nalini Elkins=0A> Sent: Thursday, March 14, 2013 2:53 PM=0A> To: joel = jaeggli; IPv6 Ops WG=0A> Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-= needed-00=0A> =0A> Joel,=0A> =0A> Thanks so much for your feedback. =A0 One= of the alternatives that we are=0A> looking at to provide a Packet Sequenc= e Number is a 'SHIM' such as that=0A> provided by SEAL.=0A> =0A> http://too= ls.ietf.org/html//rfc5320=0A> =0A> This header (if I am reading this correc= tly!) would be between the TCP or=0A> UDP header and the application payloa= d.=0A> =0A> One of the things that SEAL provides is:=0A> =0A> SEAL_ID - a 3= 2-bit Identification value, randomly initialized and=0A> monotonically incr= emented for each SEAL protocol packet=0A> =0A> So, this might provide exact= ly what we are looking for!=0A> =0A> We do understand that there are a numb= er of issues with IPv6 extension=0A> headers. =A0=A0We are not wedded to a = particular implementation and whatever=0A> will provide the information we = need is perfect! =A0 But, we have just found=0A> out about this RFC and nee= d to study it more to see if there are any=0A> drawbacks.=0A> =0A> Thanks,= =0A> =0A> Nalini Elkins=0A> Inside Products, Inc.=0A> (831) 659-8360=0A> ww= w.insidethestack.com=0A> =0A> =0A> =0A> ________________________________=0A= > From: joel jaeggli =0A> To: IPv6 Ops WG =0A> Sent: Thursday, March 14, 2013 8:13 AM=0A> Subject: [v6ops] draft-elk= ins-v6ops-ipv6-ipid-needed-00=0A> =0A> some more thoughts since the present= ation.=0A> =0A> Noted that I consulted the earlier draft, discussion in 6-m= an and appendix=0A> a in the slides.=0A> =0A> http://tools.ietf.org/html/dr= aft-elkins-6man-ipv6-diagnostic-header-00=0A> =0A> was the previous one.=0A= > =0A> The request is not really for the ipv4 IPID/frag header in v6. it's = for a=0A> unique per packet value over a given sample interval.=0A> =0A> Th= e utility of ipid in ipv4 for this context has eroded over time, (this=0A> = is not knock againt the draft I'm just trying to describe my understanding= =0A> of the utility). IPID's in the context of mobile phones/mobile network= s=0A> are typically unvarrying (due to header compresssion). rfc 6864 exist= s=0A> because modern implmentations cannot (and therefore don't) honor=0A> = requirements for uniqueness in rfc791,rfc1122 e.g. the duration over which= =0A> 16 bit IPID is valid for uniqueness is bounded by the size of the flow= =0A> because if it were limited by the MDL it would limit that speed of a f= low.=0A> a 10Gb/s flow with 1500 byte packets overflows a 16 bit value ever= y 78 or=0A> so ms. if your capture is longer than that you can reasonably e= xpect=0A> duplicate IPIDS to show up which are readily identifiable as not = being=0A> duplicate packets.=0A> =0A> desirable properties of a unique per = packet value to my mind...=0A> =0A> * That it doesn't cost us anything - it= strikes me as undesirable that=0A> packets should in general have larger h= eaders then they do today that adds=0A> cost all over the place. extension = header processing or indeed=0A> fragmentation header use has conquences.=0A= > =0A> see http://tools.ietf.org/html/draft-wkumari-long-headers-00=0A> =0A= > for dicussion that has come up about header processing in modern routers.= =0A> =0A> and=0A> =0A> http://tools.ietf.org/html/draft-taylor-v6ops-fragdr= op-00=0A> =0A> for a similar discussion about fragmentation headers.=0A> = =0A> neither of these represent any form of consensus document, so take tha= t=0A> with a grain of salt.=0A> =0A> * That it is applied to every packet -= part of the stated utility of the=0A> ipv4 ipid is that it's present (with= my noted caveats) you don't have to=0A> turn it on. likewise this implies = that the application of the value does=0A> not impact the observation, havi= ng the packet size change because you're=0A> doing debugging means imho tha= t you're not doing the=0A> _______________________________________________= =0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman= /listinfo/v6ops=0A> _______________________________________________=0A> v6o= ps mailing list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman/listinf= o/v6ops --1510626085-911830779-1363300650=:51430 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Fred,

<= div style=3D"color: rgb(0, 0, 0); font-size: 13.600000381469727px; font-fam= ily: arial, helvetica, sans-serif; background-color: transparent; font-styl= e: normal;">Thanks for your comments.

We are getting a lot of comments from people that the reality of the si= tuation is that many firewalls drop packets with IPv6 extension headers. &n= bsp; Including fragment header.   People seem to feel there are a lot = of security issues with IPv6 extension headers.  I do feel that adding an atomic fragment header with each packet would have been a great solutio= n but does not seem to have much support.   We have not ruled anything= out but I am just telling you what we are hearing.

<= /div>
BTW, any chance of getting a timestamp in the SEAL header= ?
 
Thanks,

Nalini El= kins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com
=
From: "Templi= n, Fred L" <Fred.L.Templin@boeing.com>
To: Nalini Elkins <nalini.elkins@insidethestack.c= om>; joel jaeggli <joelja@bogus.com>; IPv6 Ops WG <v6ops@ietf.o= rg>
Sent: Thursday= , March 14, 2013 3:27 PM
Subject:= RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
 =

=0AHi Nalini,

Just to clarify, RFC5320 will soon be obsol= eted by 'draft-templin-intarea-seal'.
But, also note that the source and= destination would both need to be SEAL-aware,
so the complexity would b= e worse than just asking the source to unconditionally
include an IPv6 f= ragment header with a well-behave ID.

Thanks - Fred
fred.l.templin@boeing.com

> -----Original Message-----
&= gt; From: v6ops-bounces@ietf.org [mailto:v6ops-bounce= s@ietf.org] On Behalf Of
> Nalini Elkins
> Sent: Thursday, = March 14, 2013 2:53 PM
> To: joel jaeggli; IPv6 Ops WG
> Subjec= t: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
>
> Joel= ,
>
> Thanks so much for your feedback.   One of the alternatives that we a= re
> looking at to provide a Packet Sequence Number is a 'SHIM' such = as that
> provided by SEAL.
>
> http://tools.ietf.org/ht= ml//rfc5320
>
> This header (if I am reading this correctly!) = would be between the TCP or
> UDP header and the application payload.=
>
> One of the things that SEAL provides is:
>
>= SEAL_ID - a 32-bit Identification value, randomly initialized and
> = monotonically incremented for each SEAL protocol packet
>
> So= , this might provide exactly what we are looking for!
>
> We d= o understand that there are a number of issues with IPv6 extension
> = headers.   We are not wedded to a particular implementation and w= hatever
> will provide the information we need is perfect!   But= , we have just found
> out about this RFC and need to study it more to see if there are any
> drawbacks.
>
> Thanks,>
> Nalini Elkins
> Inside Products, Inc.
> (831) 6= 59-8360
> www.insidethestack.com
>
>
>
> ___________= _____________________
> From: joel jaeggli <joelja@bogus.com><= br>> To: IPv6 Ops WG <v6ops@ietf.org>
> Sent: Thursday, March 1= 4, 2013 8:13 AM
> Subject: [v6ops] draft-elkins-v6ops-ipv6-ipid-neede= d-00
>
> some more thoughts since the presentation.
> > Noted that I consulted the earlier draft, discussion in 6-man and ap= pendix
> a in the slides.
>
> http://tools.ietf.org/html= /draft-elkins-6man-ipv6-diagnostic-header-00
>
> was the previ= ous one.
>
> The request is not really for the ipv4 IPID/frag hea= der in v6. it's for a
> unique per packet value over a given sample i= nterval.
>
> The utility of ipid in ipv4 for this context has = eroded over time, (this
> is not knock againt the draft I'm just tryi= ng to describe my understanding
> of the utility). IPID's in the cont= ext of mobile phones/mobile networks
> are typically unvarrying (due = to header compresssion). rfc 6864 exists
> because modern implmentati= ons cannot (and therefore don't) honor
> requirements for uniqueness = in rfc791,rfc1122 e.g. the duration over which
> 16 bit IPID is valid= for uniqueness is bounded by the size of the flow
> because if it we= re limited by the MDL it would limit that speed of a flow.
> a 10Gb/s= flow with 1500 byte packets overflows a 16 bit value every 78 or
> s= o ms. if your capture is longer than that you can reasonably expect
> duplicate IPIDS to show up which are readily identifiable a= s not being
> duplicate packets.
>
> desirable propertie= s of a unique per packet value to my mind...
>
> * That it doe= sn't cost us anything - it strikes me as undesirable that
> packets s= hould in general have larger headers then they do today that adds
> c= ost all over the place. extension header processing or indeed
> fragm= entation header use has conquences.
>
> see http://tools.ietf.= org/html/draft-wkumari-long-headers-00
>
> for dicussion that = has come up about header processing in modern routers.
>
> and=
>
> http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00=
>
> for a similar discussion about fragmentation headers.
= >
> neither of these represent any form of consensus document, so= take that
> with a grain of salt.
>
> * That it is applied to every packet - part of the stated utility of the
> ipv= 4 ipid is that it's present (with my noted caveats) you don't have to
&g= t; turn it on. likewise this implies that the application of the value does=
> not impact the observation, having the packet size change because = you're
> doing debugging means imho that you're not doing the
>= _______________________________________________
> v6ops mailing list=
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops=
> _______________________________________________
> v6ops mail= ing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

<= br>
--1510626085-911830779-1363300650=:51430-- From touch@isi.edu Thu Mar 14 15:39:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C813711E8158 for ; Thu, 14 Mar 2013 15:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.966 X-Spam-Level: X-Spam-Status: No, score=-102.966 tagged_above=-999 required=5 tests=[AWL=-0.967, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 aUdRI4fPIjzg for ; Thu, 14 Mar 2013 15:39:18 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABC611E8133 for ; Thu, 14 Mar 2013 15:39:18 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r2EMcWZM025316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Mar 2013 15:38:32 -0700 (PDT) Message-ID: <51425168.1080106@isi.edu> Date: Thu, 14 Mar 2013 15:38:32 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Nalini Elkins References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> In-Reply-To: <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 22:39:18 -0000 Hi, all, SEAL wraps IP packets. If you put a shim above the transport layer (between TCP/UDP and the app payload), then you might not get the semantics you want. Wrapping UDP messages is fine - presuming you look at the wrapper only at the endpoints; IP fragmentation may mean the wrapper isn't available for some datagrams. Wrapping TCP segments is a bad idea IMO, and doesn't make sense. TCP segments exist only at the TCP layer, and those boundaries are invisible to the application layer. The boundaries of what is written, transmitted, received, and, read may differ (the middle two due to rewriting proxies, which are evil but real). If you want/need a network identifier for diagnostics, it has to exist at the network layer. NB - as we noted during the discussion of RFC6864, the IPv6 ID can exist *either* when the source fragments *or* when a 6-to-4 translation is required even for datagrams that otherwise fit in an IPv6 MTU. You might update your intro accordingly: ...The IPv6 fragment header is present only when a datagram has been fragmented, or when the source has received a "packet too big" ICMPv6 error message indicating that the path cannot support the required minimum 1280-byte IPv6 MTU and is thus subject to translation [RFC2460] [RFC4443]. The latter case is relevant only for IPv6 datagrams sent to IPv4 destinations to support subsequent fragmentation after translation to IPv4. Regarding this draft, it would be useful to explain why using the entire packet (or a hash thereof) isn't nearly as useful in most cases (and that would not require a new ID). Again, note that most IPv4 implementations do not implement the ID uniqueness requirements in RFC791, and some use repeated IDs (even that don't compress headers). Joe On 3/14/2013 2:52 PM, Nalini Elkins wrote: > Joel, > > Thanks so much for your feedback. One of the alternatives that we are looking at to provide a Packet Sequence Number is a 'SHIM' such as that provided by SEAL. > > http://tools.ietf.org/html//rfc5320 > > This header (if I am reading this correctly!) would be between the TCP or UDP header and the application payload. > > One of the things that SEAL provides is: > > SEAL_ID - a 32-bit Identification value, randomly initialized and monotonically incremented for each SEAL protocol packet > > So, this might provide exactly what we are looking for! > > We do understand that there are a number of issues with IPv6 extension headers. We are not wedded to a particular implementation and whatever will provide the information we need is perfect! But, we have just found out about this RFC and need to study it more to see if there are any drawbacks. > > Thanks, > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > > > ________________________________ > From: joel jaeggli > To: IPv6 Ops WG > Sent: Thursday, March 14, 2013 8:13 AM > Subject: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 > > some more thoughts since the presentation. > > Noted that I consulted the earlier draft, discussion in 6-man and appendix a in the slides. > > http://tools.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header-00 > > was the previous one. > > The request is not really for the ipv4 IPID/frag header in v6. it's for a unique per packet value over a given sample interval. > > The utility of ipid in ipv4 for this context has eroded over time, (this is not knock againt the draft I'm just trying to describe my understanding of the utility). IPID's in the context of mobile phones/mobile networks are typically unvarrying (due to header compresssion). rfc 6864 exists because modern implmentations cannot (and therefore don't) honor requirements for uniqueness in rfc791,rfc1122 e.g. the duration over which 16 bit IPID is valid for uniqueness is bounded by the size of the flow because if it were limited by the MDL it would limit that speed of a flow. a 10Gb/s flow with 1500 byte packets overflows a 16 bit value every 78 or so ms. if your capture is longer than that you can reasonably expect duplicate IPIDS to show up which are readily identifiable as not being duplicate packets. > > desirable properties of a unique per packet value to my mind... > > * That it doesn't cost us anything - it strikes me as undesirable that packets should in general have larger headers then they do today that adds cost all over the place. extension header processing or indeed fragmentation header use has conquences. > > see http://tools.ietf.org/html/draft-wkumari-long-headers-00 > > for dicussion that has come up about header processing in modern routers. > > and > > http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00 > > for a similar discussion about fragmentation headers. > > neither of these represent any form of consensus document, so take that with a grain of salt. > > * That it is applied to every packet - part of the stated utility of the ipv4 ipid is that it's present (with my noted caveats) you don't have to turn it on. likewise this implies that the application of the value does not impact the observation, having the packet size change because you're doing debugging means imho that you're not doing the > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From owen@delong.com Thu Mar 14 16:26:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC89121F8D64 for ; Thu, 14 Mar 2013 16:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJt9glzP2xxV for ; Thu, 14 Mar 2013 16:26:14 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id F119B21F8D37 for ; Thu, 14 Mar 2013 16:26:13 -0700 (PDT) Received: from [10.10.2.150] ([216.190.116.21]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2ENPcFG025934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Mar 2013 16:25:39 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2ENPcFG025934 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363303539; bh=vKn2Ckw/pR6WVZrsESMS31KH3Zc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hYgof95l3O6E4puojMT7DI+7amBQCdvlyt8mglSt4zpP7QHKqyxinYEN/ZNxM7SOV TTTtjHLqIxyMDPSNCmEpNkptp6hJyD79GEsUBXb/vYNcJ27ZZXK7K6h/pzcVmQuG26 gGnxgK5trFnsyBIlCBWv7SaFNiNR3bVAhIkGHrpA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <5142129D.5000503@dougbarton.us> Date: Thu, 14 Mar 2013 16:25:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> References: <5142129D.5000503@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 14 Mar 2013 16:25:39 -0700 (PDT) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 23:26:14 -0000 On Mar 14, 2013, at 11:10 AM, Doug Barton wrote: > On 03/14/2013 10:22 AM, Victor Kuarsingh wrote: >>=20 >>=20 >> On 2013-03-14 11:27 AM, "Fred Baker (fred)" wrote: >>=20 >>>=20 >>> On Mar 14, 2013, at 11:00 AM, Victor Kuarsingh = wrote: >>>=20 >>>>=20 >>>> I support a draft that describes ULAs with the following = principles. >>>>=20 >>>> - Early document text separating RFC1918 from ULAs (that RFC1819 !=3D= ULA) >>>=20 >>> I suspect that's code for something it doesn't well express. >=20 > A very well-turned phrase, Fred. :) >=20 >>> RFC 1918 provides several prefixes that can be used within a routing >>> domain and are not advertised outside it. ULAs are a more scalable = way to >>> implement that concept in IPv6. =46rom that perspective, one could = argue >>> that a ULA has an obvious relationship to an RFC 1918 prefix. >>=20 >> Agreed, there are some definite relationships, and there are some >> differences. One such difference, which if used correctly, you can >> connect two domains using ULAs and not need a NAT box in the middle = given >> prefixes which are not expected to overlap (the pain we have with >> converging networks using RFC1918 with typical overlap). >=20 > You can do that with 1918 addresses too. In fact I'm at a loss to see = how you could do that with ULA in a way that you could not do it with = 1918 space. If both sites are using 10.0.0.0/8 in an overlapping manner, then = connecting them via routers does not yield goodness. OTOH, if both sites = are using appropriately random ULA prefixes, the odds of an overlap are = very low. Thus it is far more likely with ULA that connecting two sites via = routers and achieving the desired result is possible than it is with = RFC-1918. OTOH, it's even more likely with GUA. Owen From owen@delong.com Thu Mar 14 16:26:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C72321F8E99 for ; Thu, 14 Mar 2013 16:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 lT3w-ItDhj+N for ; Thu, 14 Mar 2013 16:26:17 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C8F3221F8E95 for ; Thu, 14 Mar 2013 16:26:17 -0700 (PDT) Received: from [10.10.2.150] ([216.190.116.21]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2ENLjlJ025880 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Mar 2013 16:21:46 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2ENLjlJ025880 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363303307; bh=byIFbCmLYhI4gKlO+pJFLMWx2NI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QTNVj7Es9EqyXwBb8wTFpqpSfeFkKQh9+WYxvN1uxrhCCbvcxLAgJaZ3F43pyShCN jRsi0oSgJeYy8uj/mSFXQx4xin46NfIzdZRjxPl7/4kzs900CXlJZDvl+MMotUABU7 KGaPd9m/RVW41HTvpYPuXeDH18efXWHevXDI9b8k= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: Date: Thu, 14 Mar 2013 16:21:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1B2052F2-7917-40DB-8409-F1C6864742E6@delong.com> References: To: Victor Kuarsingh X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 14 Mar 2013 16:21:47 -0700 (PDT) Cc: v6ops WG Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 23:26:18 -0000 On Mar 14, 2013, at 8:00 AM, Victor Kuarsingh wrote: >=20 > I support a draft that describes ULAs with the following principles. >=20 > - Early document text separating RFC1918 from ULAs (that RFC1819 !=3D = ULA) I would like to see this part include as part of the differentiation = that the use of ULA with NAT or NPT is not recommended as in the traditional use of = RFC-1918. > - I am ok with describing general use cases (I think we cannot = enumerate > all possible specific cases yet - IPv6 has not found it's way in = enough > places to understand the full extent of what and where ULAs can be = used) > - text needs to cover the drawbacks of using ULAs in those general = cases > (I.e. Host using ULA, then requires future Internet connectivity etc). > - I also think that we should not specifically "recommend" or "not > recommend" specific options. The key is to provide the right = description > of the drawbacks, issues and challenges that can arise >=20 > If the draft takes on that form, I think it can provide valuable = guidance > (better then having people guess and use an incomplete set of > data/experience to figure out how/when to use ULAs). >=20 > Regards, >=20 > Victor K >=20 >=20 > On 2013-03-14 10:46 AM, "Fred Baker (fred)" wrote: >=20 >> In the meeting at IETF 86, we discussed >>=20 >> http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis >> http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis >> "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang, >> Cameron Byrne, 25-Feb-13 >>=20 >> and the hum supported making that a working group draft. In this = note, >> I'm asking for ratification on the list - whether you agree or = disagree, >> I'd appreciate your thoughts. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From dougb@dougbarton.us Thu Mar 14 16:35:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD7D11E80E7 for ; Thu, 14 Mar 2013 16:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 PTcVHs8frf40 for ; Thu, 14 Mar 2013 16:35:18 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 65DEE11E80D9 for ; Thu, 14 Mar 2013 16:35:18 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:b912:86f0:43a6:c70c] (unknown [IPv6:2001:470:d:5e7:b912:86f0:43a6:c70c]) by dougbarton.us (Postfix) with ESMTPSA id DBCA722B3F for ; Thu, 14 Mar 2013 23:35:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1363304118; bh=zED3DlUjQVOjochAjJvF/VC4lucQv3e6CjJET/UDCRo=; h=Date:From:To:Subject:References:In-Reply-To; b=RN08gax+anNtB6kYN/lTLSqpGdRFFylShHejLdSrTQxvt6pkD/eMZ9Hz5znthk16N 8COSBv8DyPr8z/IJGYJ9k65DW9YHM4236G7ASChD2HKq8kGLimXk7DtlQWbWwdHPQf W4c23yGVs0QbdTCWfxRNvVllkL6YVRpE3Hbgd3pM= Message-ID: <51425EB5.6040703@dougbarton.us> Date: Thu, 14 Mar 2013 16:35:17 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: v6ops@ietf.org References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> In-Reply-To: <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 23:35:20 -0000 On 03/14/2013 04:25 PM, Owen DeLong wrote: > If both sites are using 10.0.0.0/8 in an overlapping manner, then connecting them via routers does not yield goodness. Of course, but that's not a technical difference between ULA and 1918. As I pointed out in my reply to Victor, the distinction is that it's less likely to happen with ULA, which is worth noting of course. Doug From Fred.L.Templin@boeing.com Thu Mar 14 17:50:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C4711E8151 for ; Thu, 14 Mar 2013 17:50:57 -0700 (PDT) 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_13=0.6] 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 GKeNyx2Vcdjg for ; Thu, 14 Mar 2013 17:50:56 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 1186611E8162 for ; Thu, 14 Mar 2013 17:50:56 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r2F0otLZ024959 for ; Thu, 14 Mar 2013 17:50:55 -0700 Received: from XCH-PHX-211.sw.nos.boeing.com (xch-phx-211.sw.nos.boeing.com [130.247.25.140]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r2F0osl7024956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 14 Mar 2013 17:50:55 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.214]) by XCH-PHX-211.sw.nos.boeing.com ([169.254.11.106]) with mapi id 14.02.0328.011; Thu, 14 Mar 2013 17:50:51 -0700 From: "Templin, Fred L" To: Joe Touch , Nalini Elkins Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Thread-Index: AQHOIQSnpovTMHVwr0KJKw2dWHfftZil6eVQ Date: Fri, 15 Mar 2013 00:50:50 +0000 Message-ID: <2134F8430051B64F815C691A62D9831802FB9D@XCH-BLV-504.nw.nos.boeing.com> References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> In-Reply-To: <51425168.1080106@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 00:50:57 -0000 Hi Joe, > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Joe Touch > Sent: Thursday, March 14, 2013 3:39 PM > To: Nalini Elkins > Cc: IPv6 Ops WG > Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 >=20 > Hi, all, >=20 > SEAL wraps IP packets. If you put a shim above the transport layer > (between TCP/UDP and the app payload), then you might not get the > semantics you want. >=20 > Wrapping UDP messages is fine - presuming you look at the wrapper only > at the endpoints; IP fragmentation may mean the wrapper isn't available > for some datagrams. >=20 > Wrapping TCP segments is a bad idea IMO, and doesn't make sense. >=20 > TCP segments exist only at the TCP layer, and those boundaries are > invisible to the application layer. The boundaries of what is written, > transmitted, received, and, read may differ (the middle two due to > rewriting proxies, which are evil but real). >=20 > If you want/need a network identifier for diagnostics, it has to exist > at the network layer. >=20 > NB - as we noted during the discussion of RFC6864, the IPv6 ID can exist > *either* when the source fragments *or* when a 6-to-4 translation is > required even for datagrams that otherwise fit in an IPv6 MTU. You might > update your intro accordingly: >=20 > ...The IPv6 fragment > header is present only when a datagram has been fragmented, or when > the source has received a "packet too big" ICMPv6 error message > indicating that the path cannot support the required minimum > 1280-byte IPv6 MTU and is thus subject to translation [RFC2460] > [RFC4443]. The latter case is relevant only for IPv6 datagrams sent > to IPv4 destinations to support subsequent fragmentation after > translation to IPv4. >=20 > Regarding this draft, it would be useful to explain why using the entire > packet (or a hash thereof) isn't nearly as useful in most cases (and > that would not require a new ID). >=20 > Again, note that most IPv4 implementations do not implement the ID > uniqueness requirements in RFC791, and some use repeated IDs (even that > don't compress headers). Isn't it true that network middleboxes like NATs might even take it upon themselves to rewrite the IP_ID field for packets in flight? For example, if there are many hosts inside the NAT that might want to talk to the same server outside of the NAT then the packets from multiple hosts would use a shared source address of the NAT and the same destination address and so could experience significant collisions in IP_ID if the NAT did not rewrite. I have seen it suggested somewhere that NATs should rewrite the IP_ID to a random value, but I'm not sure if many implementations do that. What has been your experience? Thanks - Fred=20 > Joe >=20 >=20 >=20 >=20 > On 3/14/2013 2:52 PM, Nalini Elkins wrote: > > Joel, > > > > Thanks so much for your feedback. One of the alternatives that we are > looking at to provide a Packet Sequence Number is a 'SHIM' such as that > provided by SEAL. > > > > http://tools.ietf.org/html//rfc5320 > > > > This header (if I am reading this correctly!) would be between the TCP > or UDP header and the application payload. > > > > One of the things that SEAL provides is: > > > > SEAL_ID - a 32-bit Identification value, randomly initialized and > monotonically incremented for each SEAL protocol packet > > > > So, this might provide exactly what we are looking for! > > > > We do understand that there are a number of issues with IPv6 extension > headers. We are not wedded to a particular implementation and whatever > will provide the information we need is perfect! But, we have just foun= d > out about this RFC and need to study it more to see if there are any > drawbacks. > > > > Thanks, > > > > Nalini Elkins > > Inside Products, Inc. > > (831) 659-8360 > > www.insidethestack.com > > > > > > > > ________________________________ > > From: joel jaeggli > > To: IPv6 Ops WG > > Sent: Thursday, March 14, 2013 8:13 AM > > Subject: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 > > > > some more thoughts since the presentation. > > > > Noted that I consulted the earlier draft, discussion in 6-man and > appendix a in the slides. > > > > http://tools.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header-00 > > > > was the previous one. > > > > The request is not really for the ipv4 IPID/frag header in v6. it's for > a unique per packet value over a given sample interval. > > > > The utility of ipid in ipv4 for this context has eroded over time, (thi= s > is not knock againt the draft I'm just trying to describe my understandin= g > of the utility). IPID's in the context of mobile phones/mobile networks > are typically unvarrying (due to header compresssion). rfc 6864 exists > because modern implmentations cannot (and therefore don't) honor > requirements for uniqueness in rfc791,rfc1122 e.g. the duration over whic= h > 16 bit IPID is valid for uniqueness is bounded by the size of the flow > because if it were limited by the MDL it would limit that speed of a flow= . > a 10Gb/s flow with 1500 byte packets overflows a 16 bit value every 78 or > so ms. if your capture is longer than that you can reasonably expect > duplicate IPIDS to show up which are readily identifiable as not being > duplicate packets. > > > > desirable properties of a unique per packet value to my mind... > > > > * That it doesn't cost us anything - it strikes me as undesirable that > packets should in general have larger headers then they do today that add= s > cost all over the place. extension header processing or indeed > fragmentation header use has conquences. > > > > see http://tools.ietf.org/html/draft-wkumari-long-headers-00 > > > > for dicussion that has come up about header processing in modern > routers. > > > > and > > > > http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00 > > > > for a similar discussion about fragmentation headers. > > > > neither of these represent any form of consensus document, so take that > with a grain of salt. > > > > * That it is applied to every packet - part of the stated utility of th= e > ipv4 ipid is that it's present (with my noted caveats) you don't have to > turn it on. likewise this implies that the application of the value does > not impact the observation, having the packet size change because you're > doing debugging means imho that you're not doing the > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From swmike@swm.pp.se Thu Mar 14 20:35:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7505311E8158 for ; Thu, 14 Mar 2013 20:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4D9aDRctKJ2N for ; Thu, 14 Mar 2013 20:35:15 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id DDF0511E80DC for ; Thu, 14 Mar 2013 20:35:14 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C38129C; Fri, 15 Mar 2013 04:35:12 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B98749A for ; Fri, 15 Mar 2013 04:35:12 +0100 (CET) Date: Fri, 15 Mar 2013 04:35:12 +0100 (CET) From: Mikael Abrahamsson To: v6ops WG In-Reply-To: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> Message-ID: References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 03:35:15 -0000 On Thu, 14 Mar 2013, Fred Baker (fred) wrote: > and the hum supported making that a working group draft. In this note, > I'm asking for ratification on the list - whether you agree or disagree, I like to see it as a WG draft. However, I would like to discourage usage of ULAs for deployment with a default route in hosts. Unless there is a way to make the hosts only use its ULA address to talk to only other ULA addresses, I don't like to see them being used at all. The whole kludge with NPT when traversing onto the public Internet is in my opinion not good and the fact that the whole IPv6 model wasn't designed with routing in mind from the beginning is something I consider very unfortunate. When RAs are sent and an on-link prefix is being announced, there should be routing information included so that hosts could be configured with ULA but only use this address for communication with other ULA, and even perhaps only with a netmask that matches the ULA prefix used in the specific home. I asked in the jabber room the other day and the answer I got was that the gateway could send ICMP messages saying an ULA packet sent via the default route didn't reach its destination, but this is a very chatty way of achieving the same goal. -- Mikael Abrahamsson email: swmike@swm.pp.se From marka@isc.org Thu Mar 14 21:00:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1BE11E819B for ; Thu, 14 Mar 2013 21:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 K9MNjntdbik9 for ; Thu, 14 Mar 2013 21:00:44 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 2C24411E8188 for ; Thu, 14 Mar 2013 21:00:44 -0700 (PDT) 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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id CA89B5F9865; Fri, 15 Mar 2013 04:00:34 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363320043; bh=6WW59+4vQEzg3AQVU1jcs7vvN9SqYhKjTPbcV3WCLE4=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=bAA4zAhKwkL8wZ6L8+gKuD6xBaUEKFwz9N2sj/WdFH5Mo6roB6y86EBzsnUU1Cd78 UZCEbsmEP2o2eNSiB5/AR0zRc72wGk20hFxZGeQQ0AkbJh01lV4+BTIMccZfVw9Prz LEXPv0CL5kRmkpg8w/CwOtYl1o44XfDE+XMpkaR0= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:58e0:8bff:a476:a845]) (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 2B59F216C3B; Fri, 15 Mar 2013 04:00:33 +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 9324430E3615; Fri, 15 Mar 2013 15:00:24 +1100 (EST) To: Mikael Abrahamsson From: Mark Andrews References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> In-reply-to: Your message of "Fri, 15 Mar 2013 04:35:12 BST." Date: Fri, 15 Mar 2013 15:00:24 +1100 Message-Id: <20130315040024.9324430E3615@drugs.dv.isc.org> Cc: v6ops WG Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 04:00:45 -0000 In message , Mikael Abrahamsson writes: > On Thu, 14 Mar 2013, Fred Baker (fred) wrote: > > > and the hum supported making that a working group draft. In this note, > > I'm asking for ratification on the list - whether you agree or disagree, > > I like to see it as a WG draft. > > However, I would like to discourage usage of ULAs for deployment with a > default route in hosts. Unless there is a way to make the hosts only use > its ULA address to talk to only other ULA addresses, I don't like to see > them being used at all. Well one can certainly configure nodes to preference ula when talking to ula and depreference ula when talking to anything else. > The whole kludge with NPT when traversing onto the public Internet is in > my opinion not good and the fact that the whole IPv6 model wasn't designed > with routing in mind from the beginning is something I consider very > unfortunate. When RAs are sent and an on-link prefix is being announced, > there should be routing information included so that hosts could be > configured with ULA but only use this address for communication with other > ULA, and even perhaps only with a netmask that matches the ULA prefix used > in the specific home. > > I asked in the jabber room the other day and the answer I got was that the > gateway could send ICMP messages saying an ULA packet sent via the default > route didn't reach its destination, but this is a very chatty way of > achieving the same goal. Yes, it is chatty. One needs to be able to null route fc00::/7 yet still have f[cd]xx:xxxx::/48 route installed for each f[cd]xx:xxxx::/48 in use on the link. If one only installed ::/0 if there is a non fc00::/7 prefix and installed a null route for fc00::/7 along with a next hop for f[cd]xx:xxxx::/48 if there is a f[cd]xx:xxxx::/48 or longer prefix advertised in the RA. This would address most of these issues. It would only require a bit in the f[cd]xx:xxxx::/48 prefix announcement to say to do this. Mark > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From swmike@swm.pp.se Thu Mar 14 23:07:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E15221F918A for ; Thu, 14 Mar 2013 23:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0e7LZ4MQOB9i for ; Thu, 14 Mar 2013 23:07:16 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id CBA5721F9188 for ; Thu, 14 Mar 2013 23:07:14 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E733E9C; Fri, 15 Mar 2013 07:07:08 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E19429A; Fri, 15 Mar 2013 07:07:08 +0100 (CET) Date: Fri, 15 Mar 2013 07:07:08 +0100 (CET) From: Mikael Abrahamsson To: Mark Andrews In-Reply-To: <20130315040024.9324430E3615@drugs.dv.isc.org> Message-ID: References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <20130315040024.9324430E3615@drugs.dv.isc.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops WG Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 06:07:16 -0000 On Fri, 15 Mar 2013, Mark Andrews wrote: > Well one can certainly configure nodes to preference ula when talking to > ula and depreference ula when talking to anything else. Remotely? In that case, how? I don't want the nodes seeing the RAs to believe that there is IPv6 GUA Internet connectivity just because they happen to get a ULA address using SLAAC. > One needs to be able to null route fc00::/7 yet still have > f[cd]xx:xxxx::/48 route installed for each f[cd]xx:xxxx::/48 in use on > the link. That's fine. > If one only installed ::/0 if there is a non fc00::/7 prefix and > installed a null route for fc00::/7 along with a next hop for > f[cd]xx:xxxx::/48 if there is a f[cd]xx:xxxx::/48 or longer prefix > advertised in the RA. This would address most of these issues. It > would only require a bit in the f[cd]xx:xxxx::/48 prefix announcement to > say to do this. What bit in the announcement are you referring to? -- Mikael Abrahamsson email: swmike@swm.pp.se From brian.e.carpenter@gmail.com Fri Mar 15 01:17:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1C921F91D6 for ; Fri, 15 Mar 2013 01:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.871 X-Spam-Level: X-Spam-Status: No, score=-98.871 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 BM0eoK2KTyRx for ; Fri, 15 Mar 2013 01:17:08 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9E03821F90CB for ; Fri, 15 Mar 2013 01:17:07 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id p43so2847777wea.38 for ; Fri, 15 Mar 2013 01:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QXpWY5HPp61ndFbgOmrxGfguifelnEK8+3NXo7E1M5s=; b=bq0woQ81Nh83lTJ8u5TKekv4PwDVz8ivycs4tbMo920YVTE7LWSC9A+6bioGAeo4hd zmv5OZcZo38bjALjPWrFa0rv/COngr4z0FH/OGXDJ3Ps6Z8OrbRJ8f1NvmMzl3xT7QSc zePn/UT1/jN/CIOn/UYc6B2w12LUMsyHHVoiwGdMenEN4TpFLVkbC1VQK4ZkzFu0BLk3 r2L78RXmSXCzoD908EcXLIecvUNRtKrfb7iGUyMzw5P7DCfwJiPv01Kn1xz6/jqyuzJ3 vmuK0Hv0jbnYF55kWVza9E8WUf1ZxzVidcz2KlDP+J983Q5NAewv2N+dn3sS9G646xAC VaCg== X-Received: by 10.180.79.6 with SMTP id f6mr1189709wix.26.1363335426681; Fri, 15 Mar 2013 01:17:06 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-188-133.as13285.net. [2.101.188.133]) by mx.google.com with ESMTPS id n2sm1294551wiy.6.2013.03.15.01.17.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 01:17:05 -0700 (PDT) Message-ID: <5142D90F.2020404@gmail.com> Date: Fri, 15 Mar 2013 08:17:19 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Victor Kuarsingh References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 08:17:09 -0000 On 14/03/2013 18:53, Victor Kuarsingh wrote: ... > So, an example (just one example) would be Network-A and Network-B. > Network-A is using 10/8 with usage across the entire block. Network-B is > using 10/8 with usage across the block as well. Assuming no renumbering > (which can be extremely difficult in some places) to connect these two > network domains, you may need a NAT box in the middle And there are plenty of cheap NATs that simply will not work if 10.0.0.1 exists on both sides of the NAT. Brian From simon.perreault@viagenie.ca Fri Mar 15 06:17:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABDE21F9001 for ; Fri, 15 Mar 2013 06:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bil8JG1goN1z for ; Fri, 15 Mar 2013 06:17:51 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D723321F8FA4 for ; Fri, 15 Mar 2013 06:17:51 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2001:df8:0:16:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 32C2E40439 for ; Fri, 15 Mar 2013 09:17:51 -0400 (EDT) Message-ID: <51431F7E.3090502@viagenie.ca> Date: Fri, 15 Mar 2013 09:17:50 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <2134F8430051B64F815C691A62D9831802FB9D@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831802FB9D@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 13:17:52 -0000 Le 2013-03-14 20:50, Templin, Fred L a écrit : > I have seen it suggested somewhere that NATs should > rewrite the IP_ID to a random value, but I'm not sure if many > implementations do that. What has been your experience? Here's one implementation that does that: http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf > random-id > Replaces the IPv4 identification field with random values to > compensate for predictable values generated by many hosts. This > option only applies to packets that are not fragmented after the > optional fragment reassembly. Off by default. 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 lorenzo@google.com Fri Mar 15 07:06:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5738221F8651 for ; Fri, 15 Mar 2013 07:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 shgNhCmG1bCu for ; Fri, 15 Mar 2013 07:06:16 -0700 (PDT) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id CA27221F8650 for ; Fri, 15 Mar 2013 07:06:16 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id o6so3455263oag.18 for ; Fri, 15 Mar 2013 07:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=RPexqGK6FxDiHzDSIXRuakl4dgbpa12lNrLT2i0mIXs=; b=Boo/ighv2/p1Y3JoaDB8tOR0iZW05HbMxs0jtPJkoSHgc38pxQ76gF1qw6vonSnrEX lnsZdvAsniN1H5rmHM5kxvNzHnQZhtdWh9gtptDX/WY39lztsaO//mG22d4ddN+fIWcr u5qrLZe1q7dZHRZIIpK3u3M39HYryBcsimpDD7PCA1912Wy0Vd8T17u/YKI40oyUSYqD FCsDsVgoVIMzo01XO0/LC2NaEneEUqhCjiU7kDDzYSXapYdN/4TOlN9Hhr4OwSYkVk22 uDERZDBSOKWFjir/Jc1TL4c/ZKqwST9w0PfP8Wsc3OQe2Tdxzlvl9jKm3Wcsfj4RwO1t L4aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=RPexqGK6FxDiHzDSIXRuakl4dgbpa12lNrLT2i0mIXs=; b=Rzh3L0SN9PDKlfkAl/ERGKpTkCWqjSEnoRCqdlxmB2HRB6fUTb0LvsgmZrdfeEnBU3 F/Yisqf1dM9GB5grydYKh9Hw0PkBV0dOzv7ZdrumtLeLcVWsnYBjKevwG3NMs0yClxwx fOVV5DOzyv5RXS7nzQanDtMiXtJBEW3Tb15xhNewdbjb/2PcazthWsA28ao9eJ75MHP3 w+Lk42e9UfWC0eru/orSGw5qLaCuSmS5ynGj+b86vRkylQ9hRNum08juEzx2lxy77JcL UVflDztcoqIVknZFVI3QcYyEb3M62akPyAyprzffhkjHZQR9dM6AqSfxO/bNaNU21pqy G6wg== X-Received: by 10.182.108.104 with SMTP id hj8mr2986230obb.44.1363356376364; Fri, 15 Mar 2013 07:06:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Fri, 15 Mar 2013 07:05:56 -0700 (PDT) In-Reply-To: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> From: Lorenzo Colitti Date: Fri, 15 Mar 2013 07:05:56 -0700 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=f46d0447a1e98422a504d7f724bb X-Gm-Message-State: ALoCoQkyxnBdGKtQW87a0e2V+2jVKpCOfNKMqpHb1Qn5CVXfkagVbzKvwugV6q/aQdtDZQ/CEx/94bxvt1rIk+YKypwcixZt3Vl1hEKM0Izh6tQrFUZJQZ8l6/BD0mbJ+GhNvaWuPp2nXcDo4KJ/rsuyr3xUdsDAFYdnLhtfj2dCGyL3cLVgcwsW03ZbPEh94az5CCnUR5U4 Cc: v6ops WG Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 14:06:17 -0000 --f46d0447a1e98422a504d7f724bb Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 14, 2013 at 7:46 AM, Fred Baker (fred) wrote: > http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis > http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis > "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang, > Cameron Byrne, 25-Feb-13 > > and the hum supported making that a working group draft. In this note, I'm > asking for ratification on the list - whether you agree or disagree, I'd > appreciate your thoughts. > I do not support adoption of this document, because I'd argue that we as a community do not yet have enough experience with using ULAs compared to global addresses. I would support a draft that discussed and reported on operational experience obtained from actually using ULAs, but there does not seem to be much of that in this draft. --f46d0447a1e98422a504d7f724bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 14, 2013 at 7:46 AM, Fred Baker (fred) <fred@cis= co.com> wrote:
http://datatracker.iet= f.org/doc/draft-liu-v6ops-ula-usage-analysis
http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analy= sis
=A0 "Guidance of Using Unique Local Addresses", Bing Liu, Sheng J= iang,
=A0 Cameron Byrne, 25-Feb-13

and the hum supported making that a working group draft. In this note, I= 9;m asking for ratification on the list - whether you agree or disagree, I&= #39;d appreciate your thoughts.

I do not support adoption of this document, because I'd argue that we a= s a community do not yet have enough experience with using ULAs compared to= global addresses.

I would support a d= raft that discussed and reported on operational experience obtained from ac= tually using ULAs, but there does not seem to be much of that in this draft= .
--f46d0447a1e98422a504d7f724bb-- From jiangsheng@huawei.com Fri Mar 15 07:28:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4ABA21F8867 for ; Fri, 15 Mar 2013 07:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 bEYSGO8fIJPZ for ; Fri, 15 Mar 2013 07:28:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0431121F8862 for ; Fri, 15 Mar 2013 07:28:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APK05144; Fri, 15 Mar 2013 14:28:18 +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.7; Fri, 15 Mar 2013 14:27:40 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 15 Mar 2013 14:28:18 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.40]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Fri, 15 Mar 2013 22:28:12 +0800 From: Sheng Jiang To: Lorenzo Colitti , "Fred Baker (fred)" Thread-Topic: [v6ops] draft-liu-v6ops-ula-usage-analysis Thread-Index: AQHOIMKyuRqJmEDhbkSplQyJnXr4TpimRMoAgACJqvc= Date: Fri, 15 Mar 2013 14:28:11 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923A9FACAF@nkgeml512-mbx.china.huawei.com> References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com>, In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.141.58] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B923A9FACAFnkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: v6ops WG Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 14:28:22 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B923A9FACAFnkgeml512mbxchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Lorenzo, For my understanding, your ask too much for adoption call according to the = IETF process. The adoption only means the WG agree it is an important work,= the WG should works on. It is not necessary we already have the best conte= nt. It is for WGLC. I think you agree that ULA is an important topic that v6ops should do somet= hing on it, but think the current need much more concrete content from real= experience to be published. If your agree my above observation, the right thing to do is v6ops WG adopt= this draft first, then, have the authors (maybe call more contributions fr= om WG too) to continue work on it. We will come to decide whether the conte= nt is mature enough for publication during WGLC or whether to launch WGLC a= t all. Best regards, Sheng ________________________________ From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] on behalf of Lorenzo = Colitti [lorenzo@google.com] Sent: 15 March 2013 22:05 To: Fred Baker (fred) Cc: v6ops WG Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis On Thu, Mar 14, 2013 at 7:46 AM, Fred Baker (fred) > wrote: http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang, Cameron Byrne, 25-Feb-13 and the hum supported making that a working group draft. In this note, I'm = asking for ratification on the list - whether you agree or disagree, I'd ap= preciate your thoughts. I do not support adoption of this document, because I'd argue that we as a = community do not yet have enough experience with using ULAs compared to glo= bal addresses. I would support a draft that discussed and reported on operational experien= ce obtained from actually using ULAs, but there does not seem to be much of= that in this draft. --_000_5D36713D8A4E7348A7E10DF7437A4B923A9FACAFnkgeml512mbxchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi, Lorenzo,

 

For my understanding, your ask too much for adoption call according to t= he IETF process. The adoption only means the WG agree it is an important wo= rk, the WG should works on. It is not necessary we already have the best co= ntent. It is for WGLC.

 

I think you agree that ULA is an important topic that v6ops should do so= mething on it, but think the current need much more concrete content from r= eal experience to be published.

 

If your agree my above observation, the right thing to do is v6ops WG ad= opt this draft first, then, have the authors (maybe call more contributions= from WG too) to continue work on it. We will come to decide whether the co= ntent is mature enough for publication during WGLC or whether to launch WGLC at all.

 

Best regards,

 

Sheng

From: v6ops-bounces@ietf.org [v6ops-bounce= s@ietf.org] on behalf of Lorenzo Colitti [lorenzo@google.com]
Sent: 15 March 2013 22:05
To: Fred Baker (fred)
Cc: v6ops WG
Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis

On Thu, Mar 14, 2013 at 7:46 AM, Fred Baker (fred) <fred@cisco.com&= gt; wrote:
http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-u= sage-analysis
http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analy= sis
  "Guidance of Using Unique Local Addresses", Bing Liu, Shen= g Jiang,
  Cameron Byrne, 25-Feb-13

and the hum supported making that a working group draft. In this note, I'm = asking for ratification on the list - whether you agree or disagree, I'd ap= preciate your thoughts.

I do not support adoption of this document, because I'd argue that we = as a community do not yet have enough experience with using ULAs compared t= o global addresses.

I would support a draft that discussed and reported on operational exp= erience obtained from actually using ULAs, but there does not seem to be mu= ch of that in this draft.
--_000_5D36713D8A4E7348A7E10DF7437A4B923A9FACAFnkgeml512mbxchi_-- From dwing@cisco.com Fri Mar 15 07:36:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777F321F872E for ; Fri, 15 Mar 2013 07:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.066 X-Spam-Level: X-Spam-Status: No, score=-110.066 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, 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 Utu9MkA4b4Zo for ; Fri, 15 Mar 2013 07:36:28 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id C8E2C21F8630 for ; Fri, 15 Mar 2013 07:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1262; q=dns/txt; s=iport; t=1363358188; x=1364567788; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=2Evt/6SFpKpBfHqlZvhEQBm89SFoZsKq1E8xAGpaQM8=; b=C0tjXeFhFwEezi22rpBw9AFOSc7T90p251pxEL4uE0WXtoyBqZ3sMtjB owf0PGeozSMX2eN7XQcZBxTxtvAEmNO6REdlMjvfskNv0zK5wBOjADHhC UzqNDoJQltbCli9R72cbRkWIx1aAPk70rrh6u+z1jqia8skf7DlccWpXL o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAFcwQ1GrRDoG/2dsb2JhbABDFsUAgWUWdIIqAQEBAgEBAQEBJEcLBQsLRicwBhMJiAUFDcMLjmIzB4JfYQOWW4Efj2ODJiA X-IronPort-AV: E=Sophos;i="4.84,850,1355097600"; d="scan'208";a="75536816" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 15 Mar 2013 14:36:28 +0000 Received: from sjc-vpn7-905.cisco.com (sjc-vpn7-905.cisco.com [10.21.147.137]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2FEaReA029956; Fri, 15 Mar 2013 14:36:28 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dan Wing In-Reply-To: <51431F7E.3090502@viagenie.ca> Date: Fri, 15 Mar 2013 10:36:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <27DBEA9E-49B7-4744-8BBB-E804AE1B0A19@cisco.com> References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <2134F8430051B64F815C691A62D9831802FB9D@XCH-BLV-504.nw.nos.boeing.com> <51431F7E.3090502@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 14:36:29 -0000 On Mar 15, 2013, at 9:17 AM, Simon Perreault = wrote: > Le 2013-03-14 20:50, Templin, Fred L a =E9crit : >> I have seen it suggested somewhere that NATs should >> rewrite the IP_ID to a random value, but I'm not sure if many >> implementations do that. What has been your experience? >=20 > Here's one implementation that does that: > http://www.openbsd.org/cgi-bin/man.cgi?query=3Dpf.conf Perhaps a reaction to Bellovin's "A Technique for Counting NATted = Hosts", https://www.cs.columbia.edu/~smb/papers/fnat.pdf -d >=20 >> random-id >> Replaces the IPv4 identification field with random values = to >> compensate for predictable values generated by many hosts. = This >> option only applies to packets that are not fragmented = after the >> optional fragment reassembly. >=20 > Off by default. >=20 > Simon > --=20 > 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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Fri Mar 15 07:49:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1030921F87E7 for ; Fri, 15 Mar 2013 07:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] 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 N5JJmIvc9M2w for ; Fri, 15 Mar 2013 07:49:13 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 6B60621F87BB for ; Fri, 15 Mar 2013 07:49:13 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r2FEnCvi012787 for ; Fri, 15 Mar 2013 09:49:12 -0500 Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r2FEnBsD012782 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 15 Mar 2013 09:49:12 -0500 Received: from XCH-BLV-301.nw.nos.boeing.com (130.247.25.213) by XCH-NWHT-08.nw.nos.boeing.com (130.247.25.112) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 15 Mar 2013 07:49:11 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.214]) by XCH-BLV-301.nw.nos.boeing.com ([169.254.1.18]) with mapi id 14.02.0328.011; Fri, 15 Mar 2013 07:49:11 -0700 From: "Templin, Fred L" To: Dan Wing Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Thread-Index: AQHOIYp5povTMHVwr0KJKw2dWHfftZim1ODw Date: Fri, 15 Mar 2013 14:49:10 +0000 Message-ID: <2134F8430051B64F815C691A62D9831803024A@XCH-BLV-504.nw.nos.boeing.com> References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <2134F8430051B64F815C691A62D9831802FB9D@XCH-BLV-504.nw.nos.boeing.com> <51431F7E.3090502@viagenie.ca> <27DBEA9E-49B7-4744-8BBB-E804AE1B0A19@cisco.com> In-Reply-To: <27DBEA9E-49B7-4744-8BBB-E804AE1B0A19@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 14:49:14 -0000 Hi Dan, > Perhaps a reaction to Bellovin's "A Technique for Counting NATted Hosts", > https://www.cs.columbia.edu/~smb/papers/fnat.pdf Thanks for that reference. I read that document years ago but lost the URL, and that was where my comment originated from. Fred From joelja@bogus.com Fri Mar 15 07:51:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7781B21F883A for ; Fri, 15 Mar 2013 07:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 8yKUTYvCQW7N for ; Fri, 15 Mar 2013 07:51:18 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id E4DC221F8836 for ; Fri, 15 Mar 2013 07:51:17 -0700 (PDT) Received: from dhcp-603a.meeting.ietf.org (dhcp-603a.meeting.ietf.org [130.129.96.58]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r2FEpE8u093828 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 15 Mar 2013 14:51:15 GMT (envelope-from joelja@bogus.com) Message-ID: <51433562.9050304@bogus.com> Date: Fri, 15 Mar 2013 10:51:14 -0400 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Brian E Carpenter , Victor Kuarsingh References: <5142D90F.2020404@gmail.com> In-Reply-To: <5142D90F.2020404@gmail.com> 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]); Fri, 15 Mar 2013 14:51:15 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 14:51:19 -0000 On 3/15/13 4:17 AM, Brian E Carpenter wrote: > On 14/03/2013 18:53, Victor Kuarsingh wrote: > ... >> So, an example (just one example) would be Network-A and Network-B. >> Network-A is using 10/8 with usage across the entire block. Network-B is >> using 10/8 with usage across the block as well. Assuming no renumbering >> (which can be extremely difficult in some places) to connect these two >> network domains, you may need a NAT box in the middle > And there are plenty of cheap NATs that simply will not work > if 10.0.0.1 exists on both sides of the NAT. you generally have to have an actual collision of subnets for that to happen. it's not enough to break things to simply have non-overlapping rfc-1918 ranges on both sides. > Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fred@cisco.com Fri Mar 15 07:54:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F4B21F870F for ; Fri, 15 Mar 2013 07:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.542 X-Spam-Level: X-Spam-Status: No, score=-110.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 g-1aEYrbUu59 for ; Fri, 15 Mar 2013 07:54:13 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6646921F8706 for ; Fri, 15 Mar 2013 07:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=872; q=dns/txt; s=iport; t=1363359253; x=1364568853; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=aTzSUKa1DgPCXXKn8kyV+HXHYAj5yA0u6Lb2DRIrFAM=; b=fBrn4NJjfZlqmBBNfRgRiP2iZ5q/qKLQZ4qTJ3ijzWoLLZ23u7Ksh6OM rL2f4DPX597ZIBwuFDSjYMSPecGoUOHtXdNq9kR/vOfDeO7Z79D13IgtA ChrG3rq1/UGknRp6hj8mmQBerLS3lf1ML4be95YKB7SjouVs0Axy/N7Lk k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAHY1Q1GtJXG//2dsb2JhbABDh2q9LIFlFnSCKgEBAQMBOkQLAgEIIhQQMiUCBBMIiAYGDMMQjmICOIJfYQOXeo9jgwqCKA X-IronPort-AV: E=Sophos;i="4.84,850,1355097600"; d="scan'208";a="187688873" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 15 Mar 2013 14:54:13 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2FEsC7F020147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 15 Mar 2013 14:54:12 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Fri, 15 Mar 2013 09:54:12 -0500 From: "Fred Baker (fred)" To: v6ops WG Thread-Topic: [v6ops] draft-liu-v6ops-ula-usage-analysis Thread-Index: AQHOIYz0oHMOhhuE/UmTVANl+KaqIg== Date: Fri, 15 Mar 2013 14:54:11 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B7D3ABB@xmb-rcd-x09.cisco.com> References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.212.98] Content-Type: text/plain; charset="us-ascii" Content-ID: <867C9BB72656B6478D7F92286D8A50AE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 14:54:14 -0000 On Mar 14, 2013, at 10:46 AM, Fred Baker (fred) wrote: > In the meeting at IETF 86, we discussed >=20 > http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis > http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis > "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang, > Cameron Byrne, 25-Feb-13 >=20 > and the hum supported making that a working group draft. In this note, I'= m asking for ratification on the list - whether you agree or disagree, I'd = appreciate your thoughts. We're having a good discussion of the draft, which is to be encouraged. The initial purpose of this thread was to determine whether it should be ad= opted by the working group. I have heard a number of voices in favor and no= ne opposed. So what I need to hear now, if there are any, is those that are= opposed. From arturo.servin@gmail.com Fri Mar 15 07:55:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B2621F8837 for ; Fri, 15 Mar 2013 07:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 VACzi9iEvghc for ; Fri, 15 Mar 2013 07:55:47 -0700 (PDT) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by ietfa.amsl.com (Postfix) with ESMTP id BF9DA21F870F for ; Fri, 15 Mar 2013 07:55:47 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id un1so3893474pbc.40 for ; Fri, 15 Mar 2013 07:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=U0mu56C+glWCs1vFgGwShEoLL0gvFBJSCtE6rWsJL6A=; b=PMRYrbIMJE7EiujvqCAP2SzcsXhvIOK9dDRF3P93R7BGpWnZ8+2D0gMqxkRh+17hZR +F/+bM3ERGVMBiih4mvxPyaBtkYCrBtoV4xjxcjQ1JNH7gb4M//kNrPnuurKloC66Ymv LV2bXzwj7dx1YdlNDHmHBvpg2lm7TCaxUEnbJkUcDmtHOYu8X3Vdzk4XStQzRQtNYypD NpkVyp8JlNESCV/fXoTwJFIsI6JAEW2KpemquYyOyPS+AxaGCny8JWcM0lS254pX3oGR ibWMoP66y4UvGZKvvVDMkyxWs4t5lc54mnZ/u2uM0tVo6UpFw9lDGVnE842EB8xcZt68 oAvQ== X-Received: by 10.68.135.136 with SMTP id ps8mr16548073pbb.2.1363359339217; Fri, 15 Mar 2013 07:55:39 -0700 (PDT) Received: from dhcp-12b8.meeting.ietf.org (dhcp-12b8.meeting.ietf.org. [130.129.18.184]) by mx.google.com with ESMTPS id f4sm7528971pbc.6.2013.03.15.07.55.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 07:55:38 -0700 (PDT) Message-ID: <51433668.3050905@gmail.com> Date: Fri, 15 Mar 2013 10:55:36 -0400 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com>, <5D36713D8A4E7348A7E10DF7437A4B923A9FACAF@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923A9FACAF@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 14:55:48 -0000 I have mixed feelings about this draft. In one hand I think it is valuable to have a document to inform about ULAs usage. On the other hand I am not very comfortable in the way the document recommends ULAs and I agree with Lorenzo that we need more deployment experience to have a good outcome. Perhaps reading a new version with the comments that has been addressed in the list I would move to neutral/no-support to support. /as On 15/03/2013 10:28, Sheng Jiang wrote: > Hi, Lorenzo, > > > > For my understanding, your ask too much for adoption call according to > the IETF process. The adoption only means the WG agree it is an > important work, the WG should works on. It is not necessary we already > have the best content. It is for WGLC. > > > > I think you agree that ULA is an important topic that v6ops should do > something on it, but think the current need much more concrete content > from real experience to be published. > > > > If your agree my above observation, the right thing to do is v6ops WG > adopt this draft first, then, have the authors (maybe call more > contributions from WG too) to continue work on it. We will come to > decide whether the content is mature enough for publication during WGLC > or whether to launch WGLC at all. > > > > Best regards, > > > > Sheng > > ------------------------------------------------------------------------ > *From:* v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] on behalf of > Lorenzo Colitti [lorenzo@google.com] > *Sent:* 15 March 2013 22:05 > *To:* Fred Baker (fred) > *Cc:* v6ops WG > *Subject:* Re: [v6ops] draft-liu-v6ops-ula-usage-analysis > > On Thu, Mar 14, 2013 at 7:46 AM, Fred Baker (fred) > wrote: > > http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis > http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis > "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang, > Cameron Byrne, 25-Feb-13 > > and the hum supported making that a working group draft. In this > note, I'm asking for ratification on the list - whether you agree or > disagree, I'd appreciate your thoughts. > > > I do not support adoption of this document, because I'd argue that we as > a community do not yet have enough experience with using ULAs compared > to global addresses. > > I would support a draft that discussed and reported on operational > experience obtained from actually using ULAs, but there does not seem to > be much of that in this draft. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From victor@jvknet.com Fri Mar 15 08:42:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A718921F8848 for ; Fri, 15 Mar 2013 08:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[AWL=-0.598, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 A6ngW87+iqOm for ; Fri, 15 Mar 2013 08:42:41 -0700 (PDT) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id 47C8621F8840 for ; Fri, 15 Mar 2013 08:42:38 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id um15so4002166pbc.0 for ; Fri, 15 Mar 2013 08:42:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :x-gm-message-state; bh=qbHGaUYty4iqJjbxVQMb9BHz3elIzl3CxJSP2d2o0DQ=; b=TPySwpVZ9da7jsLPNcclBv1CS4frjlDtfLFztrY11+KY9YavY6++V8Lhk2XB2a+Cs5 an57aa31XhFAOlPRvY2XWlyEZHm5QTT3q+3DYvu0jqFb6gxVqHfdj+VdRjbGTRiUWwuB KTApsmxHANM6FTg68hF1oUnNlZ1FUbTHn5cdYtOmlKnPR32KCPySRgTkd66mpKkgxnMi js/xeVmUTMsZ7WrlLjh4wsmsIS8dYosCGUr3e/YNG13ZMX1pctSnxcjMJxJRf6SIqQMi XM+KlwApJl9IvaKdhX1wMDgTimS26Vm//IvsgIybnX/r9nS9z+fzPZZlNYxjspM3w9ix cMMg== X-Received: by 10.68.129.9 with SMTP id ns9mr17364798pbb.16.1363362148518; Fri, 15 Mar 2013 08:42:28 -0700 (PDT) Received: from [130.129.16.166] (dhcp-10a6.meeting.ietf.org. [130.129.16.166]) by mx.google.com with ESMTPS id pg7sm9340828pbc.5.2013.03.15.08.42.25 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 15 Mar 2013 08:42:27 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Fri, 15 Mar 2013 11:42:21 -0400 From: Victor Kuarsingh To: Lorenzo Colitti , "Fred Baker (fred)" Message-ID: Thread-Topic: [v6ops] draft-liu-v6ops-ula-usage-analysis In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3446192546_663190" X-Gm-Message-State: ALoCoQn+XwO8gMi+eTnLfC+aB9bIM4koOSwi1MbWBz2Emy5k/EPX9cWsKZ2CDxT+ia8flR1OQNgj Cc: v6ops WG Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 15:42:41 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3446192546_663190 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit From: Lorenzo Colitti >I would support a draft that discussed and reported on operational experience obtained from actually using ULAs, but there does not seem to be much of that in >this draft. [VICTORK] Although I differ with the position on adoption (I support to adopt), I also agree with this last statement from Lorenzo. We do not have enough experience and testing with ULAs - hence why any recommendations are premature (in either direction) IMHO. I still support an option where we list deployment options and along with benefits/drawbacks (as understood as of today). Regards, Victor K --B_3446192546_663190 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable


From: Lorenzo Colitti <lorenzo@google.com>


>I would support a draft that discussed and reported on operati= onal experience obtained from actually using ULAs, but there does not seem t= o be much of that in >this draft.

=
[VICTORK]

Although I differ with the pos= ition on adoption (I support to adopt), I also agree with this last statemen= t from Lorenzo.  We do not have enough experience and testing with ULAs= -  hence why any recommendations are premature (in either direction) I= MHO.  I still support an option where we list deployment options and al= ong with benefits/drawbacks (as understood as of today).

Regards,

Victor K
--B_3446192546_663190-- From touch@isi.edu Fri Mar 15 09:43:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1668E21F84E8 for ; Fri, 15 Mar 2013 09:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.024 X-Spam-Level: X-Spam-Status: No, score=-103.024 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eufIiX4hY2sn for ; Fri, 15 Mar 2013 09:43:35 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1E54821F84D8 for ; Fri, 15 Mar 2013 09:43:34 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r2FGh4d1005582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Mar 2013 09:43:04 -0700 (PDT) Message-ID: <51434F97.7080505@isi.edu> Date: Fri, 15 Mar 2013 09:43:03 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Simon Perreault References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <2134F8430051B64F815C691A62D9831802FB9D@XCH-BLV-504.nw.nos.boeing.com> <51431F7E.3090502@viagenie.ca> In-Reply-To: <51431F7E.3090502@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 16:43:36 -0000 On 3/15/2013 6:17 AM, Simon Perreault wrote: > Le 2013-03-14 20:50, Templin, Fred L a écrit : >> I have seen it suggested somewhere that NATs should >> rewrite the IP_ID to a random value, but I'm not sure if many >> implementations do that. What has been your experience? > > Here's one implementation that does that: > http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf > >> random-id >> Replaces the IPv4 identification field with random values to >> compensate for predictable values generated by many hosts. >> This >> option only applies to packets that are not fragmented >> after the >> optional fragment reassembly. > > Off by default. FWIW, that's a violation of RFC 791. NATs, as the source of IP packets with their address, need to reassemble incoming datagram fragments and send packets with unique IDs. Picking "random" values can/will potentially interfere with fragmentation and reassembly, especially when those values don't consider how they might step on values used by fragments OR when 'random' isn't unique as expected if the DF bit isn't set. Joe From simon.perreault@viagenie.ca Fri Mar 15 09:51:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF2E21F8525 for ; Fri, 15 Mar 2013 09:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Kt-fAjMQgU1R for ; Fri, 15 Mar 2013 09:51:07 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6710421F853A for ; Fri, 15 Mar 2013 09:51:05 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2001:df8:0:16:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3C018425ED; Fri, 15 Mar 2013 12:50:33 -0400 (EDT) Message-ID: <51435158.1010006@viagenie.ca> Date: Fri, 15 Mar 2013 12:50:32 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Joe Touch References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <2134F8430051B64F815C691A62D9831802FB9D@XCH-BLV-504.nw.nos.boeing.com> <51431F7E.3090502@viagenie.ca> <51434F97.7080505@isi.edu> In-Reply-To: <51434F97.7080505@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 16:51:09 -0000 Le 2013-03-15 12:43, Joe Touch a écrit : > > > On 3/15/2013 6:17 AM, Simon Perreault wrote: >> Le 2013-03-14 20:50, Templin, Fred L a écrit : >>> I have seen it suggested somewhere that NATs should >>> rewrite the IP_ID to a random value, but I'm not sure if many >>> implementations do that. What has been your experience? >> >> Here's one implementation that does that: >> http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf >> >>> random-id >>> Replaces the IPv4 identification field with random values to >>> compensate for predictable values generated by many hosts. >>> This >>> option only applies to packets that are not fragmented >>> after the >>> optional fragment reassembly. >> >> Off by default. > > FWIW, that's a violation of RFC 791. Only if the default reassembly behaviour is turned off. See: > set reassemble > The reassemble option is used to enable or disable the reassembly > of fragmented packets, and can be set to yes (the default) or no. > If no-df is also specified, fragments with the dont-fragment bit > set are reassembled too, instead of being dropped; the > reassembled packet will have the dont-fragment bit cleared. > Picking "random" values can/will potentially interfere with > fragmentation and reassembly, especially when those values don't > consider how they might step on values used by fragments OR when > 'random' isn't unique as expected if the DF bit isn't set. It might be a documentation bug. Here's the description of the function used for generating a "random ID". It's not really random... > /* > * Return a random IP id. Shuffle the new value we get into the previous half > * of the ip_shuffle ring (-32767 or swap with ourself), to avoid duplicates > * occuring too quickly but also still be random. > * > * 0 is a special IP ID -- don't return it. > */ > u_int16_t > ip_randomid(void) > { >... Does pf get the IETF seal of approval now? ;) 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 touch@isi.edu Fri Mar 15 10:56:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203D821F8910 for ; Fri, 15 Mar 2013 10:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.939 X-Spam-Level: X-Spam-Status: No, score=-104.939 tagged_above=-999 required=5 tests=[AWL=1.660, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIRWNzQJU-CC for ; Fri, 15 Mar 2013 10:56:28 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8096F21F85F5 for ; Fri, 15 Mar 2013 10:56:28 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r2FHtlME027076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Mar 2013 10:55:47 -0700 (PDT) Message-ID: <514360A2.2040800@isi.edu> Date: Fri, 15 Mar 2013 10:55:46 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Simon Perreault References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <2134F8430051B64F815C691A62D9831802FB9D@XCH-BLV-504.nw.nos.boeing.com> <51431F7E.3090502@viagenie.ca> <51434F97.7080505@isi.edu> <51435158.1010006@viagenie.ca> In-Reply-To: <51435158.1010006@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 17:56:29 -0000 Hi, Simon, On 3/15/2013 9:50 AM, Simon Perreault wrote: > Le 2013-03-15 12:43, Joe Touch a écrit : >> >> >> On 3/15/2013 6:17 AM, Simon Perreault wrote: >>> Le 2013-03-14 20:50, Templin, Fred L a écrit : >>>> I have seen it suggested somewhere that NATs should >>>> rewrite the IP_ID to a random value, but I'm not sure if many >>>> implementations do that. What has been your experience? >>> >>> Here's one implementation that does that: >>> http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf >>> >>>> random-id >>>> Replaces the IPv4 identification field with random values to >>>> compensate for predictable values generated by many hosts. >>>> This >>>> option only applies to packets that are not fragmented >>>> after the >>>> optional fragment reassembly. >>> >>> Off by default. >> >> FWIW, that's a violation of RFC 791. > > Only if the default reassembly behaviour is turned off. Reassembly should be required at NATs; otherwise, they can't ensure that fragments can be reassembled (because they might give them different IDs, or might go through different NATs). > See: > >> set reassemble >> The reassemble option is used to enable or disable the >> reassembly >> of fragmented packets, and can be set to yes (the >> default) or no. >> If no-df is also specified, fragments with the >> dont-fragment bit >> set are reassembled too, instead of being dropped; the >> reassembled packet will have the dont-fragment bit cleared. > >> Picking "random" values can/will potentially interfere with >> fragmentation and reassembly, especially when those values don't >> consider how they might step on values used by fragments OR when >> 'random' isn't unique as expected if the DF bit isn't set. > > It might be a documentation bug. Here's the description of the function > used for generating a "random ID". It's not really random... > >> /* >> * Return a random IP id. Shuffle the new value we get into the >> previous half >> * of the ip_shuffle ring (-32767 or swap with ourself), to avoid >> duplicates >> * occuring too quickly but also still be random. >> * >> * 0 is a special IP ID -- don't return it. >> */ >> u_int16_t >> ip_randomid(void) >> { >> ... "avoiding duplicates too quickly" is not compliant. The rule is to **ensure** that IDs are not duplicated during the maximum datagram lifetime (typically considered 2 minutes; related to the max reassembly lifetime). That includes throttling the generation of new IDs when necessary. > Does pf get the IETF seal of approval now? ;) Nope, as per above. The rules aren't stated as "SHOULD NOT" repeat; they are "MUST NOT" -- when DF=0. The rules for handling NATs and IDs, as well as ID uniqueness, were stated in such terms in RFC 6864, and the ink is barely dry on that. Joe From markzzzsmith@yahoo.com.au Fri Mar 15 14:05:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC59E11E809C for ; Fri, 15 Mar 2013 14:05:14 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XDg8rIXtQMy for ; Fri, 15 Mar 2013 14:05:14 -0700 (PDT) Received: from nm10.bullet.mail.bf1.yahoo.com (nm10.bullet.mail.bf1.yahoo.com [98.139.212.169]) by ietfa.amsl.com (Postfix) with SMTP id F0D1421F863C for ; Fri, 15 Mar 2013 14:05:13 -0700 (PDT) Received: from [98.139.212.152] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 15 Mar 2013 21:05:13 -0000 Received: from [98.139.212.222] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 15 Mar 2013 21:05:13 -0000 Received: from [127.0.0.1] by omp1031.mail.bf1.yahoo.com with NNFMP; 15 Mar 2013 21:05:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 456480.91072.bm@omp1031.mail.bf1.yahoo.com Received: (qmail 32439 invoked by uid 60001); 15 Mar 2013 21:05:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1363381513; bh=qgNSosHJUT6lTkpDRTA0iPxIjjHyWufcRMu4Ja+SxNo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KGU1DgOmcIqVDCtTdK3vjL1KiAlBz7JyNjYdlfcNrfFS3yg0rXVhpkfRDiZRKvot98Z4yxo1nLNS+tjn1DyaMlVbwsjv1QHXFtGPD5WMMpWzZVOVrGhlFFD+po3i3hVIXggn73q3GZu8DuwihajjOMDuJI4UAXeZ6IyTjLfUa0U= 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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=sKybRHvML+2LamhuDCJNAdhWTG2IUMEdyEIu99blf0cEulmS3qi15t0gFiwgSAI2E5pTT9VIYR/hQyIhpyBGhEOystvxHM4mauNCph9R82UIHK+rRik1rvubvrGZX+MxLlIOJHzqclL4pjFKbwkED0PkEGPIDILDmIpH8oC+jWo=; X-YMail-OSG: jCdo2o0VM1nCFUFtIUUF3uVjpvGVmsa2O5hU6exZAFjyUtU Z29ZMBFG9cmaKGzMLBsAHJl6QYevsG_VfE0J4l0Ot617m6Dr5zQbfEyrwBKK zs5VcXxgHGFE801onoqPq5QTKq4PPB4GpAWEqePwMZZsZkRaveVrZgVK1fbu 4nFBTVr4QkEOy1C8PneeasNK5EdhWb8B.e8PxMgG9NLnc1_Dj.2Lb7tSyEMg XTPixSjNNNCg2_3xdug03Wh.Qbxlgurgxf3DfH8_eLwXE9xehpwV8g0RSVT2 1_gpXLj0FrgOTfrHulFckYtnI47dt8._qbYOW58yWkDXBR8osEpICymWUQth 1wUrpqqir07YW5vGI_8d2cvFIq6jEHa9DHhaDDM1yGsb_wn4f.GA6hQRanBj cldGbafNWkCikJbwrFfGVF9CFPAZwG0IT9bNnlPLXk1NIa7zKkxU62VtLHlp p2g5dQrCe0OjULUIyeztEdxJAK..HOzQbSy3gfHgDRmlZrCBgPWaFV3pkaAu 7ngPM4iwt0XJPiCBr4m3n5XM- Received: from [150.101.221.237] by web142502.mail.bf1.yahoo.com via HTTP; Fri, 15 Mar 2013 14:05:13 PDT X-Rocket-MIMEInfo: 002.001, SGksCgpJIHN1cHBvcnQgdGhpcyBiZWNvbWluZyBhIHdvcmtpbmcgZ3JvdXAgZHJhZnQuCgpSZWdhcmRzLApNYXJrLgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBGcmVkIEJha2VyIChmcmVkKSA8ZnJlZEBjaXNjby5jb20.Cj4gVG86IHY2b3BzIFdHIDx2Nm9wc0BpZXRmLm9yZz4KPiBDYzogCj4gU2VudDogRnJpZGF5LCAxNSBNYXJjaCAyMDEzIDE6NDYgQU0KPiBTdWJqZWN0OiBbdjZvcHNdIGRyYWZ0LWxpdS12Nm9wcy11bGEtdXNhZ2UtYW5hbHlzaXMKPiAKPiBJbiB0aGUgbWVldGkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.137.519 References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> Message-ID: <1363381513.32042.YahooMailNeo@web142502.mail.bf1.yahoo.com> Date: Fri, 15 Mar 2013 14:05:13 -0700 (PDT) From: Mark Smith To: "Fred Baker \(fred\)" , v6ops WG In-Reply-To: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 21:05:15 -0000 Hi,=0A=0AI support this becoming a working group draft.=0A=0ARegards,=0AMar= k.=0A=0A=0A----- Original Message -----=0A> From: Fred Baker (fred) =0A> To: v6ops WG =0A> Cc: =0A> Sent: Friday, 15 M= arch 2013 1:46 AM=0A> Subject: [v6ops] draft-liu-v6ops-ula-usage-analysis= =0A> =0A> In the meeting at IETF 86, we discussed=0A> =0A> http://datatrack= er.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis=0A> http://tools.ietf.or= g/html/draft-liu-v6ops-ula-usage-analysis=0A> =A0 "Guidance of Using Unique= Local Addresses", Bing Liu, Sheng Jiang,=0A> =A0 Cameron Byrne, 25-Feb-13= =0A> =0A> and the hum supported making that a working group draft. In this = note, I'm =0A> asking for ratification on the list - whether you agree or d= isagree, I'd =0A> appreciate your thoughts.=0A> ___________________________= ____________________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://= www.ietf.org/mailman/listinfo/v6ops=0A> From evyncke@cisco.com Fri Mar 15 14:32:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1C21F0C52 for ; Fri, 15 Mar 2013 14:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfDI9QnLG7jE for ; Fri, 15 Mar 2013 14:32:47 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8990B21F8A09 for ; Fri, 15 Mar 2013 14:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21009; q=dns/txt; s=iport; t=1363383166; x=1364592766; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=YmAegHq2afTRopSS/Qzy6uNZhmep2FtHMWCBCLQV6+s=; b=UFfRd3/zBJLxFUMr2+wEZcB9fJaTQOTIPjHCKy9iB7DXv3sQ0RwsAGlJ sXycMBH4tiVGriYYjF1Jo3JD5s+ka8BkUELiAyorMnEQWZQHpZmcsH6io doU9qheEmI1gaOzYrJM17jAPGVaQzZP7RrZHUIvj1Mzm/jdPry8J423C0 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUFACmTQ1GtJV2c/2dsb2JhbABAA4QhuFYBiDGBZhZ0gioBAQEEAQEBKhwlFwQCAQgHCgQBAQsdBycLFAkIAgQBEggTh3kMw1mJCYM8gQ8LAYEEAQUHAhIFBwECBwECBAuCTmEDiD+PO49jgTGBWYFqAR8e X-IronPort-AV: E=Sophos;i="4.84,854,1355097600"; d="scan'208,217";a="188052291" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 15 Mar 2013 21:32:45 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2FLWjC8025417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Mar 2013 21:32:45 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Fri, 15 Mar 2013 16:32:45 -0500 From: "Eric Vyncke (evyncke)" To: Nalini Elkins , "Templin, Fred L" , joel jaeggli , IPv6 Ops WG Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Thread-Index: AQHOIMai4WUkV09eAUSYu4y7h5/o95imDr4AgAAJyACAAALEAIABDbTg Date: Fri, 15 Mar 2013 21:32:45 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E112EE7C4C@xmb-aln-x02.cisco.com> References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D9831802F8BE@XCH-BLV-504.nw.nos.boeing.com> <1363300650.51430.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> In-Reply-To: <1363300650.51430.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.84.223] Content-Type: multipart/alternative; boundary="_000_97EB7536A2B2C549846804BBF3FD47E112EE7C4Cxmbalnx02ciscoc_" MIME-Version: 1.0 Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 21:32:48 -0000 --_000_97EB7536A2B2C549846804BBF3FD47E112EE7C4Cxmbalnx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable And at the risk of being flamed, I am fully supportive for firewalls (if yo= u need one) to drop anything that they are unable to understand. This does not mean that I am not supportive of solving the problem raised b= y Nalini of course -=E9ric From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of N= alini Elkins Sent: jeudi 14 mars 2013 23:38 To: Templin, Fred L; joel jaeggli; IPv6 Ops WG Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Fred, Thanks for your comments. We are getting a lot of comments from people that the reality of the situat= ion is that many firewalls drop packets with IPv6 extension headers. Incl= uding fragment header. People seem to feel there are a lot of security is= sues with IPv6 extension headers. I do feel that adding an atomic fragment= header with each packet would have been a great solution but does not seem= to have much support. We have not ruled anything out but I am just telli= ng you what we are hearing. BTW, any chance of getting a timestamp in the SEAL header? Thanks, Nalini Elkins Inside Products, Inc. (831) 659-8360 www.insidethestack.com ________________________________ From: "Templin, Fred L" > To: Nalini Elkins >; joel jaeggli = >; IPv6 Ops WG > Sent: Thursday, March 14, 2013 3:27 PM Subject: RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Hi Nalini, Just to clarify, RFC5320 will soon be obsoleted by 'draft-templin-intarea-s= eal'. But, also note that the source and destination would both need to be SEAL-a= ware, so the complexity would be worse than just asking the source to uncondition= ally include an IPv6 fragment header with a well-behave ID. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops= -bounces@ietf.org] On Behalf Of > Nalini Elkins > Sent: Thursday, March 14, 2013 2:53 PM > To: joel jaeggli; IPv6 Ops WG > Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 > > Joel, > > Thanks so much for your feedback. One of the alternatives that we are > looking at to provide a Packet Sequence Number is a 'SHIM' such as that > provided by SEAL. > > http://tools.ietf.org/html//rfc5320 > > This header (if I am reading this correctly!) would be between the TCP or > UDP header and the application payload. > > One of the things that SEAL provides is: > > SEAL_ID - a 32-bit Identification value, randomly initialized and > monotonically incremented for each SEAL protocol packet > > So, this might provide exactly what we are looking for! > > We do understand that there are a number of issues with IPv6 extension > headers. We are not wedded to a particular implementation and whatever > will provide the information we need is perfect! But, we have just foun= d > out about this RFC and need to study it more to see if there are any > drawbacks. > > Thanks, > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > > > ________________________________ > From: joel jaeggli > > To: IPv6 Ops WG > > Sent: Thursday, March 14, 2013 8:13 AM > Subject: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 > > some more thoughts since the presentation. > > Noted that I consulted the earlier draft, discussion in 6-man and appendi= x > a in the slides. > > http://tools.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header-00 > > was the previous one. > > The request is not really for the ipv4 IPID/frag header in v6. it's for a > unique per packet value over a given sample interval. > > The utility of ipid in ipv4 for this context has eroded over time, (this > is not knock againt the draft I'm just trying to describe my understandin= g > of the utility). IPID's in the context of mobile phones/mobile networks > are typically unvarrying (due to header compresssion). rfc 6864 exists > because modern implmentations cannot (and therefore don't) honor > requirements for uniqueness in rfc791,rfc1122 e.g. the duration over whic= h > 16 bit IPID is valid for uniqueness is bounded by the size of the flow > because if it were limited by the MDL it would limit that speed of a flow= . > a 10Gb/s flow with 1500 byte packets overflows a 16 bit value every 78 or > so ms. if your capture is longer than that you can reasonably expect > duplicate IPIDS to show up which are readily identifiable as not being > duplicate packets. > > desirable properties of a unique per packet value to my mind... > > * That it doesn't cost us anything - it strikes me as undesirable that > packets should in general have larger headers then they do today that add= s > cost all over the place. extension header processing or indeed > fragmentation header use has conquences. > > see http://tools.ietf.org/html/draft-wkumari-long-headers-00 > > for dicussion that has come up about header processing in modern routers. > > and > > http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00 > > for a similar discussion about fragmentation headers. > > neither of these represent any form of consensus document, so take that > with a grain of salt. > > * That it is applied to every packet - part of the stated utility of the > ipv4 ipid is that it's present (with my noted caveats) you don't have to > turn it on. likewise this implies that the application of the value does > not impact the observation, having the packet size change because you're > doing debugging means imho that you're not doing the > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --_000_97EB7536A2B2C549846804BBF3FD47E112EE7C4Cxmbalnx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

And at the r= isk of being flamed, I am fully supportive for firewalls (if you need one) = to drop anything that they are unable to understand.

 <= /o:p>

This does no= t mean that I am not supportive of solving the problem raised by Nalini of = course

 <= /o:p>

-=E9ric=

 <= /o:p>

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org= ] On Behalf Of Nalini Elkins
Sent: jeudi 14 mars 2013 23:38
To: Templin, Fred L; joel jaeggli; IPv6 Ops WG
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

 

Fr= ed,

 

Thanks for your comments.

 

We are getting a lot of comme= nts from people that the reality of the situation is that many firewalls dr= op packets with IPv6 extension headers.   Including fragment header.   People seem to feel there are a lot of security issues with= IPv6 extension headers.  I do feel that adding an atomic fragment hea= der with each packet would have been a great solution but does not seem to = have much support.   We have not ruled anything out but I am just telling you what we are hearing.

 

BTW, any chance of getting a = timestamp in the SEAL header?

&n= bsp;

Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

From: "Templin, Fred L" <Fred.L.Templin@boeing.com>= ;
To: Nalini Elkins <nalini.elkins@insidethestack.com>; joel jaeggli <joelja@bogus.com>; IPv6 Ops WG <v6ops@ietf.org>
Sent: Thursday, March 14, 2013 3:27 PM
Subject: RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00


Hi Nalini,

Just to clarify, RFC5320 will soon be obsoleted by 'draft-templin-intarea-s= eal'.
But, also note that the source and destination would both need to be SEAL-a= ware,
so the complexity would be worse than just asking the source to uncondition= ally
include an IPv6 fragment header with a well-behave ID.

Thanks - Fred
fred.l.templin@boeing.com<= br>
> -----Original Message-----
> From: v6ops-bounces@ietf.org= [mailto:v6ops-bounces@ietf.o= rg] On Behalf Of
> Nalini Elkins
> Sent: Thursday, March 14, 2013 2:53 PM
> To: joel jaeggli; IPv6 Ops WG
> Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
>
> Joel,
>
> Thanks so much for your feedback.   One of the alternatives that = we are
> looking at to provide a Packet Sequence Number is a 'SHIM' such as tha= t
> provided by SEAL.
>
> http://tools.ietf.org/h= tml//rfc5320
>
> This header (if I am reading this correctly!) would be between the TCP= or
> UDP header and the application payload.
>
> One of the things that SEAL provides is:
>
> SEAL_ID - a 32-bit Identification value, randomly initialized and
> monotonically incremented for each SEAL protocol packet
>
> So, this might provide exactly what we are looking for!
>
> We do understand that there are a number of issues with IPv6 extension=
> headers.   We are not wedded to a particular implementation = and whatever
> will provide the information we need is perfect!   But, we have j= ust found
> out about this RFC and need to study it more to see if there are any > drawbacks.
>
> Thanks,
>
> Nalini Elkins
> Inside Products, Inc.
> (831) 659-8360
> www.insid= ethestack.com
>
>
>
> ________________________________
> From: joel jaeggli <joelja@bogu= s.com>
> To: IPv6 Ops WG <v6ops@ietf.org>
> Sent: Thursday, March 14, 2013 8:13 AM
> Subject: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
>
> some more thoughts since the presentation.
>
> Noted that I consulted the earlier draft, discussion in 6-man and appe= ndix
> a in the slides.
>
> http://tools.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header-00<= br> >
> was the previous one.
>
> The request is not really for the ipv4 IPID/frag header in v6. it's fo= r a
> unique per packet value over a given sample interval.
>
> The utility of ipid in ipv4 for this context has eroded over time, (th= is
> is not knock againt the draft I'm just trying to describe my understan= ding
> of the utility). IPID's in the context of mobile phones/mobile network= s
> are typically unvarrying (due to header compresssion). rfc 6864 exists=
> because modern implmentations cannot (and therefore don't) honor
> requirements for uniqueness in rfc791,rfc1122 e.g. the duration over w= hich
> 16 bit IPID is valid for uniqueness is bounded by the size of the flow=
> because if it were limited by the MDL it would limit that speed of a f= low.
> a 10Gb/s flow with 1500 byte packets overflows a 16 bit value every 78= or
> so ms. if your capture is longer than that you can reasonably expect > duplicate IPIDS to show up which are readily identifiable as not being=
> duplicate packets.
>
> desirable properties of a unique per packet value to my mind...
>
> * That it doesn't cost us anything - it strikes me as undesirable that=
> packets should in general have larger headers then they do today that = adds
> cost all over the place. extension header processing or indeed
> fragmentation header use has conquences.
>
> see http://tools.ietf.org/html/draft-wkumari-long-headers-00
>
> for dicussion that has come up about header processing in modern route= rs.
>
> and
>
> = http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00
>
> for a similar discussion about fragmentation headers.
>
> neither of these represent any form of consensus document, so take tha= t
> with a grain of salt.
>
> * That it is applied to every packet - part of the stated utility of t= he
> ipv4 ipid is that it's present (with my noted caveats) you don't have = to
> turn it on. likewise this implies that the application of the value do= es
> not impact the observation, having the packet size change because you'= re
> doing debugging means imho that you're not doing the
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

--_000_97EB7536A2B2C549846804BBF3FD47E112EE7C4Cxmbalnx02ciscoc_-- From evyncke@cisco.com Fri Mar 15 14:33:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101F221F8AE2 for ; Fri, 15 Mar 2013 14:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GjC7ePHA6Fj for ; Fri, 15 Mar 2013 14:33:09 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 236EA21F8A80 for ; Fri, 15 Mar 2013 14:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2327; q=dns/txt; s=iport; t=1363383189; x=1364592789; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=2TeheIzEABdhnTthc28Ml5Q7+Z5JqDofw9N2KVTU77M=; b=QT6ub6GAetbtAc++UbiHtyiRXdYC6e331Dc5uJ7laWxLXJ6HxQJzVmjJ 64zPfD0wWoP+2cN/+Yjh+wNW2ll1rNW9dZsvvNYxn/2CTr5ep+yaEryj2 pxy2UCNzhL+E5Xo+azsrpXfDjm0jM0ik66+8AoFrKT5sMI4rE8IUk8nT9 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAFmSQ1GtJV2c/2dsb2JhbABDxSmBZhZ0gioBAQEEAQEBaxcEAgEIEQQBAQEKHQcnCxQJCAIEARIIiAwMw1iNVIEQJhIGgllhA4g/jzuPY4MKgig X-IronPort-AV: E=Sophos;i="4.84,854,1355097600"; d="scan'208";a="188027049" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 15 Mar 2013 21:33:08 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2FLX8ba025771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Mar 2013 21:33:08 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Fri, 15 Mar 2013 16:32:47 -0500 From: "Eric Vyncke (evyncke)" To: Victor Kuarsingh , "Fred Baker (fred)" , v6ops WG Thread-Topic: [v6ops] draft-liu-v6ops-ula-usage-analysis Thread-Index: AQHOIMKyuRqJmEDhbkSplQyJnXr4Tpilm6IAgAGOknA= Date: Fri, 15 Mar 2013 21:32:47 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E112EE7C53@xmb-aln-x02.cisco.com> References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.84.223] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 21:33:10 -0000 Fred, While I support the idea that we need a draft on ULA as a WG item, I must w= rite that I share Victor, Arturo and Lorenzo's concerns about the current I= -D, it is not ready for WGLC -=E9ric > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Victor Kuarsingh > Sent: jeudi 14 mars 2013 16:01 > To: Fred Baker (fred); v6ops WG > Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis >=20 >=20 > I support a draft that describes ULAs with the following principles. >=20 > - Early document text separating RFC1918 from ULAs (that RFC1819 !=3D ULA= ) > - I am ok with describing general use cases (I think we cannot enumerate = all > possible specific cases yet - IPv6 has not found it's way in enough place= s > to understand the full extent of what and where ULAs can be used) > - text needs to cover the drawbacks of using ULAs in those general cases > (I.e. Host using ULA, then requires future Internet connectivity etc). > - I also think that we should not specifically "recommend" or "not > recommend" specific options. The key is to provide the right description= of > the drawbacks, issues and challenges that can arise >=20 > If the draft takes on that form, I think it can provide valuable guidance > (better then having people guess and use an incomplete set of > data/experience to figure out how/when to use ULAs). >=20 > Regards, >=20 > Victor K >=20 >=20 > On 2013-03-14 10:46 AM, "Fred Baker (fred)" wrote: >=20 > >In the meeting at IETF 86, we discussed > > > >http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis > >http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis > > "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang, > > Cameron Byrne, 25-Feb-13 > > > >and the hum supported making that a working group draft. In this note, > >I'm asking for ratification on the list - whether you agree or > >disagree, I'd appreciate your thoughts. > >_______________________________________________ > >v6ops mailing list > >v6ops@ietf.org > >https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From shtsuchi@cisco.com Fri Mar 15 15:33:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522EA21F84CA for ; Fri, 15 Mar 2013 15:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.799 X-Spam-Level: X-Spam-Status: No, score=-8.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8sxCC3eKPgm for ; Fri, 15 Mar 2013 15:33:58 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id DEBDC21F84B7 for ; Fri, 15 Mar 2013 15:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1270; q=dns/txt; s=iport; t=1363386838; x=1364596438; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=sjy3usUKwcMLX3xqomGJIzUxAyZLxQmqmVwSwzhD3G4=; b=P8F3YNCSVhMLDz94hVkwu7q6S/GrI5yaS+32wd7g2Lo64YY1k/vJ5nlV QcudAj85z71/qYiUFz8Pb3047g7EbVfDgRSP3+uqgyFaO2iHyzJ/kA/qc A09VoS1bvpzpcCfZHGFHdv3pQcuambQNjvOeJmPzWYiOoarRT5tQUOMJU Y=; X-IronPort-AV: E=Sophos;i="4.84,854,1355097600"; d="scan'208";a="188063001" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 15 Mar 2013 22:33:57 +0000 Received: from rtp-vpn6-363.cisco.com (rtp-vpn6-363.cisco.com [10.82.249.108]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2FMXv0N020433; Fri, 15 Mar 2013 22:33:57 GMT Message-ID: <5143A1D5.9030702@cisco.com> Date: Fri, 15 Mar 2013 18:33:57 -0400 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 22:33:59 -0000 I think the draft is well-written about feature of ULA. I know a lot of service provider and enterprise who are deployed IPv6 in their network, but I don't know ULA widely deployed network. IMHO,in this case,we may need experience document before the draft support as WG. like a RFC6586 https://tools.ietf.org/html/rfc6586 http://tools.ietf.org/html/draft-hazeyama-widecamp-ipv6-only-experience http://tools.ietf.org/html/draft-janog-softwire-report I'm not support the draft in this point. But if the experience document will be published,I will completely support this draft. Regards, -Shishio (2013/03/14 10:46), Fred Baker (fred) wrote: > In the meeting at IETF 86, we discussed > > http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis > http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis > "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang, > Cameron Byrne, 25-Feb-13 > > and the hum supported making that a working group draft. In this note, I'm asking for ratification on the list - whether you agree or disagree, I'd appreciate your thoughts. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From owen@delong.com Fri Mar 15 17:21:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282DF1F0D14 for ; Fri, 15 Mar 2013 17:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RpRB9dAimwj for ; Fri, 15 Mar 2013 17:21:18 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 959341F0D05 for ; Fri, 15 Mar 2013 17:21:18 -0700 (PDT) Received: from [10.10.2.150] ([216.190.116.21]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2G0K4Pj023245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 15 Mar 2013 17:20:11 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2G0K4Pj023245 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363393213; bh=eD6WKpTaDkX2tn6YgFZ48B92n9o=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=dagY7plmDrC62mbZvRAv7T4RMnAirROx2udOYUwcqvvcq0/ncqsNwaFOUPimr16de v29B+2YBD61JTRWk/yp9XpbgeJX3GFyFhwBhld3R57Ky4DgvMMJpMpPDCfzpzBCU/9 liF8PcwaC7fwnEYE0ItFFyUjRwTwI3+fYZ3e02dU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <5143A1D5.9030702@cisco.com> Date: Fri, 15 Mar 2013 17:20:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9466C244-E38C-4983-AEEA-33379954F80C@delong.com> References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <5143A1D5.9030702@cisco.com> To: Shishio Tsuchiya X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 15 Mar 2013 17:20:13 -0700 (PDT) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 00:21:19 -0000 On Mar 15, 2013, at 3:33 PM, Shishio Tsuchiya = wrote: > I think the draft is well-written about feature of ULA. > I know a lot of service provider and enterprise who are deployed IPv6 = in their network, but I don't know ULA widely deployed network. This is a good thing IMHO=85 ULA deployment really should be the = exception, not the rule. Owen From fred@cisco.com Fri Mar 15 19:02:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2AD1F0D10 for ; Fri, 15 Mar 2013 19:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.542 X-Spam-Level: X-Spam-Status: No, score=-110.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 NofjxyGmfdoD for ; Fri, 15 Mar 2013 19:02:46 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6353D1F0D0E for ; Fri, 15 Mar 2013 19:02:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=427; q=dns/txt; s=iport; t=1363399366; x=1364608966; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8CTAwTGyv7g80DX5JN80UGPf/75p2fgON9KqRFOHHoM=; b=e3U1EPAOLQD5UAtnYUFDCoRtNZT9P5fWMKKC+JUihM87pHeR1PusivcS 1nVZqR8rOc+6N3ozdnt+OvetizeXMKe554FIZFHIDXzUdrW8OYlWMdREH u01KdIxJsCu0fObb8y035Zp0g8VsCSiiUTiRaMW1BMCSUL+vM5JdZSuSl Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUFAITRQ1GtJXG//2dsb2JhbABDh2q9QYFnFnSCKgEBAQMBeQULAgEIIiQyJQIEDgUIiAYGw1KOYgIxB4JfYQOIP58egwqCKA X-IronPort-AV: E=Sophos;i="4.84,855,1355097600"; d="scan'208";a="188127417" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 16 Mar 2013 02:02:46 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2G22jHK025074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 16 Mar 2013 02:02:46 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Fri, 15 Mar 2013 21:02:45 -0500 From: "Fred Baker (fred)" To: "Eric Vyncke (evyncke)" Thread-Topic: [v6ops] draft-liu-v6ops-ula-usage-analysis Thread-Index: AQHOIepZoHMOhhuE/UmTVANl+KaqIg== Date: Sat, 16 Mar 2013 02:02:45 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B7D48FE@xmb-rcd-x09.cisco.com> References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <97EB7536A2B2C549846804BBF3FD47E112EE7C53@xmb-aln-x02.cisco.com> In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E112EE7C53@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.117.39] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops WG Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 02:02:47 -0000 On Mar 15, 2013, at 5:32 PM, Eric Vyncke (evyncke) wrot= e: > it is not ready for WGLC We rarely adopt a draft and leave it unchanged. The real question in adopti= on is whether the working group is willing to take control of it and turn i= t into a consensus document as opposed to the dreams of the original author= . I expect the draft we publish to be quite a bit different than this one.= From nalini.elkins@insidethestack.com Sat Mar 16 06:36:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183DA21F8B7E for ; Sat, 16 Mar 2013 06:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] 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 qlLj11pOVSBv for ; Sat, 16 Mar 2013 06:36:41 -0700 (PDT) Received: from nm1.access.bullet.mail.mud.yahoo.com (nm1.access.bullet.mail.mud.yahoo.com [66.94.237.202]) by ietfa.amsl.com (Postfix) with ESMTP id B1A2721F8BCC for ; Sat, 16 Mar 2013 06:36:41 -0700 (PDT) Received: from [66.94.237.192] by nm1.access.bullet.mail.mud.yahoo.com with NNFMP; 16 Mar 2013 13:36:41 -0000 Received: from [66.94.237.120] by tm3.access.bullet.mail.mud.yahoo.com with NNFMP; 16 Mar 2013 13:36:41 -0000 Received: from [127.0.0.1] by omp1025.access.mail.mud.yahoo.com with NNFMP; 16 Mar 2013 13:36:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 245626.98962.bm@omp1025.access.mail.mud.yahoo.com Received: (qmail 36733 invoked by uid 60001); 16 Mar 2013 13:36:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1363441000; bh=h+Vosc7No6yONl+/Ib7lf6P29Ky+FAHtssPpGTD4Nl8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=JPkbe3zlc2/TaO0B09YLk+zeHFEOB58TeylPT+d5XGoMmZLxUT3lf070QN6fLfHOZxP+kK5U5zNhqLl2CjIxJqMWrb+pPno5XZUmHW3nvfrRA3OJUQA7FrnFV7Mm+VPjkVgLp2OLrNBWHm4jMO9mRIL8ehFRDvFJOTJ7wGfvDUM= X-YMail-OSG: AE5pcR4VM1nrgXxhYWTWCLif.IMhS6IBUmMzmD2Wml62lcT tzlfk9UPQdrO__tv7QISFrY9BTaoG4RB9KanAcmOTfbt34UOwznxV4Ljd6dw 8hbqJ04u5A.BxfjDu9ZlwveelAVAVqMxsEGvwRAr_Bh_iHVbJj6PpA0zncXy KIwUvyVuL9cDB4gTu2bZIzPy12ofI27sytmoHy_Ig7x5SuqZiMAXR5lhPJZ_ RpQMpo18uoipbmacDQ1vMGshJSyQq0C8tcDYGNNw_mngbbWVUOr3VJYDQd_r bMmIM6tPQhjYQIiVuExPZMewu2meDICssZJuCd9DGzDDJb7qB7WSYhNexuy5 WI5t51Jgf27w_0J4wPUelxZ.NDMttGR6MPbCPPDwXdUoyLWbwbxzP1PFvjIC MM9msaEvDnD6uw4Grx.t8530.zXeKUd2DUnkunzt._UDqmzjdJiMoyZHV1nJ 2iL9wIoLr1k.dRCUaxT_X69Tg5Ddan7S0Pc7hRgYJzWGPpDGohtZ5UhkQnpP .99OLBjTXpEEnXsCmNbfBtBCNbmxFxW6tq3Dvcr7RZOx3UDmA7L52o2u33u. PVHoDK25JuNVEPr1.Gsj2ZVZh6cwkJVa9LUkm0bacVjo- Received: from [38.98.231.61] by web2803.biz.mail.ne1.yahoo.com via HTTP; Sat, 16 Mar 2013 06:36:40 PDT X-Rocket-MIMEInfo: 002.001, Q29ycmVjdCBtZSBpZiBJIGFtIHdyb25nLCBidXQgSSBoYXZlIHRvIHRoaW5rIHRoYXQgbW9zdCBmaXJld2FsbHMgYXJlIG9ubHkgZHJvcHBpbmcgcGFja2V0cyB0aGF0IHRoZXkgYXJlIFRPTEQgdG8gZHJvcC4gwqBUaGF0IGlzLCBhbiBvcHRpb24gaGFzIGJlZW4gc2V0IGJ5IHRoZSBuZXR3b3JrIG9wZXJhdG9yIHRvIGRyb3AgY2VydGFpbiBwYWNrZXRzLiDCoE1heWJlIHRoZXNlIHBhY2tldHMgaW5jbHVkZSBJUHY2IGV4dGVuc2lvbiBoZWFkZXJzIChmcmFnbWVudCBvciBvdGhlcndpc2UpLiDCoCBJdCBpcywBMAEBAQE- X-Mailer: YahooMailWebService/0.8.137.519 References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D9831802F8BE@XCH-BLV-504.nw.nos.boeing.com> <1363300650.51430.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <97EB7536A2B2C549846804BBF3FD47E112EE7C4C@xmb-aln-x02.cisco.com> Message-ID: <1363441000.29041.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Sat, 16 Mar 2013 06:36:40 -0700 (PDT) From: Nalini Elkins To: "Eric Vyncke \(evyncke\)" , "Templin, Fred L" , joel jaeggli , IPv6 Ops WG In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E112EE7C4C@xmb-aln-x02.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-44754328-1363441000=:29041" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 13:36:44 -0000 ---1551098171-44754328-1363441000=:29041 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Correct me if I am wrong, but I have to think that most firewalls are only = dropping packets that they are TOLD to drop. =A0That is, an option has been= set by the network operator to drop certain packets. =A0Maybe these packet= s include IPv6 extension headers (fragment or otherwise). =A0 It is, of cou= rse, possible that some firewalls (or other middle boxes) do not understand= certain packets and drop them or feel that ANY packets containing IPv6 ext= ension headers are suspect. =A0This, I find to be an over-reaction. =A0 How= is this OK?=A0=0A=0AI understand that this is likely indeed the case, and = primary allegiance must be to reality or what is ACTUALLY happening on real= networks, but wouldn't some level of nuance or discrimination be better be= havior? =A0 Yes, I know that many security attacks can be launched using IP= v6 extension headers and I can give you a detailed list of many of them. = =A0 =A0=0A=0AHaving said that, I was just at a site yesterday where they ha= ve been using IPv6 for quite a few years. =A0They tell me that they see qui= te a few IPv6 Fragment Headers on DNSSEC responses on their internal networ= k. =A0 BUT, they do not have tons of firewalls internally. =A0 When they co= nnect to a partner, they can indeed see that packets containing fragment he= aders are being dropped. =A0=A0=0A=0ASo, whatever behavior one may choose o= n one's own internal network, one cannot dictate to a business partner. =A0= This is what is bringing up thoughts of alternative solutions to our probl= ems. =A0 I will detail those in the response to Joe Touch's list entry.=0A= =0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-= 8360=0Awww.insidethestack.com=0A=0A=0A=0A________________________________= =0A From: Eric Vyncke (evyncke) =0ATo: Nalini Elkins ; "Templin, Fred L" ; joel jaeggli ; IPv6 Ops WG =0ASent:= Friday, March 15, 2013 5:32 PM=0ASubject: RE: [v6ops] draft-elkins-v6ops-i= pv6-ipid-needed-00=0A =0A=0A =0AAnd at the risk of being flamed, I am fully= supportive for firewalls (if you need one) to drop anything that they are = unable to understand.=0A=A0=0AThis does not mean that I am not supportive o= f solving the problem raised by Nalini of course=0A=A0=0A-=E9ric=0A=A0=0AFr= om:v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Nali= ni Elkins=0ASent: jeudi 14 mars 2013 23:38=0ATo: Templin, Fred L; joel jaeg= gli; IPv6 Ops WG=0ASubject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed= -00=0A=A0=0AFred,=0A=A0=0AThanks for your comments.=0A=A0=0AWe are getting = a lot of comments from people that the reality of the situation is that man= y firewalls drop packets with IPv6 extension headers. =A0 Including fragmen= t header. =A0 People seem to feel there are a lot of security issues with I= Pv6 extension headers. =A0I do feel that adding an atomic fragment header w= ith each packet would have been a great solution but does not seem to have = much support. =A0 We have not ruled anything out but I am just telling you = what we are hearing.=0A=A0=0ABTW, any chance of getting a timestamp in the = SEAL header?=0A=A0=0AThanks,=0ANalini Elkins=0AInside Products, Inc.=0A(831= ) 659-8360=0Awww.insidethestack.com=0A=0A________________________________= =0A =0AFrom:"Templin, Fred L" =0ATo: Nalini Elki= ns ; joel jaeggli ; IPv= 6 Ops WG =0ASent: Thursday, March 14, 2013 3:27 PM=0ASubje= ct: RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00=0A=0AHi Nalini,=0A= =0AJust to clarify, RFC5320 will soon be obsoleted by 'draft-templin-intare= a-seal'.=0ABut, also note that the source and destination would both need t= o be SEAL-aware,=0Aso the complexity would be worse than just asking the so= urce to unconditionally=0Ainclude an IPv6 fragment header with a well-behav= e ID.=0A=0AThanks - Fred=0Afred.l.templin@boeing.com=0A=0A> -----Original M= essage-----=0A> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org= ] On Behalf Of=0A> Nalini Elkins=0A> Sent: Thursday, March 14, 2013 2:53 PM= =0A> To: joel jaeggli; IPv6 Ops WG=0A> Subject: Re: [v6ops] draft-elkins-v6= ops-ipv6-ipid-needed-00=0A> =0A> Joel,=0A> =0A> Thanks so much for your fee= dback. =A0 One of the alternatives that we are=0A> looking at to provide a = Packet Sequence Number is a 'SHIM' such as that=0A> provided by SEAL.=0A> = =0A> http://tools.ietf.org/html/rfc5320=0A> =0A> This header (if I am readi= ng this correctly!) would be between the TCP or=0A> UDP header and the appl= ication payload.=0A> =0A> One of the things that SEAL provides is:=0A> =0A>= SEAL_ID - a 32-bit Identification value, randomly initialized and=0A> mono= tonically incremented for each SEAL protocol packet=0A> =0A> So, this might= provide exactly what we are looking for!=0A> =0A> We do understand that th= ere are a number of issues with IPv6 extension=0A> headers. =A0=A0We are no= t wedded to a particular implementation and whatever=0A> will provide the i= nformation we need is perfect! =A0 But, we have just found=0A> out about th= is RFC and need to study it more to see if there are any=0A> drawbacks.=0A>= =0A> Thanks,=0A> =0A> Nalini Elkins=0A> Inside Products, Inc.=0A> (831) 65= 9-8360=0A> www.insidethestack.com=0A> =0A> =0A> =0A> ______________________= __________=0A> From: joel jaeggli =0A> To: IPv6 Ops WG =0A> Sent: Thursday, March 14, 2013 8:13 AM=0A> Subject: [v6o= ps] draft-elkins-v6ops-ipv6-ipid-needed-00=0A> =0A> some more thoughts sinc= e the presentation.=0A> =0A> Noted that I consulted the earlier draft, disc= ussion in 6-man and appendix=0A> a in the slides.=0A> =0A> http://tools.iet= f.org/html/draft-elkins-6man-ipv6-diagnostic-header-00=0A> =0A> was the pre= vious one.=0A> =0A> The request is not really for the ipv4 IPID/frag header= in v6. it's for a=0A> unique per packet value over a given sample interval= .=0A> =0A> The utility of ipid in ipv4 for this context has eroded over tim= e, (this=0A> is not knock againt the draft I'm just trying to describe my u= nderstanding=0A> of the utility). IPID's in the context of mobile phones/mo= bile networks=0A> are typically unvarrying (due to header compresssion). rf= c 6864 exists=0A> because modern implmentations cannot (and therefore don't= ) honor=0A> requirements for uniqueness in rfc791,rfc1122 e.g. the duration= over which=0A> 16 bit IPID is valid for uniqueness is bounded by the size = of the flow=0A> because if it were limited by the MDL it would limit that s= peed of a flow.=0A> a 10Gb/s flow with 1500 byte packets overflows a 16 bit= value every 78 or=0A> so ms. if your capture is longer than that you can r= easonably expect=0A> duplicate IPIDS to show up which are readily identifia= ble as not being=0A> duplicate packets.=0A> =0A> desirable properties of a = unique per packet value to my mind...=0A> =0A> * That it doesn't cost us an= ything - it strikes me as undesirable that=0A> packets should in general ha= ve larger headers then they do today that adds=0A> cost all over the place.= extension header processing or indeed=0A> fragmentation header use has con= quences.=0A> =0A> see http://tools.ietf.org/html/draft-wkumari-long-headers= -00=0A> =0A> for dicussion that has come up about header processing in mode= rn routers.=0A> =0A> and=0A> =0A> http://tools.ietf.org/html/draft-taylor-v= 6ops-fragdrop-00=0A> =0A> for a similar discussion about fragmentation head= ers.=0A> =0A> neither of these represent any form of consensus document, so= take that=0A> with a grain of salt.=0A> =0A> * That it is applied to every= packet - part of the stated utility of the=0A> ipv4 ipid is that it's pres= ent (with my noted caveats) you don't have to=0A> turn it on. likewise this= implies that the application of the value does=0A> not impact the observat= ion, having the packet size change because you're=0A> doing debugging means= imho that you're not doing the=0A> _______________________________________= ________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.ietf.org= /mailman/listinfo/v6ops=0A> _______________________________________________= =0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman= /listinfo/v6ops ---1551098171-44754328-1363441000=:29041 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Correct me if I am wr= ong, but I have to think that most firewalls are only dropping packets that= they are TOLD to drop.  That is, an option has been set by the networ= k operator to drop certain packets.  Maybe these packets include IPv6 = extension headers (fragment or otherwise).   It is, of course, possibl= e that some firewalls (or other middle boxes) do not understand certain pac= kets and drop them or feel that ANY packets containing IPv6 extension heade= rs are suspect.  This, I find to be an over-reaction.   How is th= is OK? 

I understand that this is likely indeed the case, and primary allegi= ance must be to reality or what is ACTUALLY happening on real networks, but= wouldn't some level of nuance or discrimination be better behavior?  = Yes, I know that many security attacks can be launched using IPv6 extensio= n headers and I can give you a detailed list of many of them.    =

Having = said that, I was just at a site yesterday where they have been using IPv6 f= or quite a few years.  They tell me that they see quite a few IPv6 Fragment Headers on DNSSEC responses on their internal network.   BUT= , they do not have tons of firewalls internally.   When they connect t= o a partner, they can indeed see that packets containing fragment headers a= re being dropped.   

So, whatever behavior one may choose on one's own in= ternal network, one cannot dictate to a business partner.   This is wh= at is bringing up thoughts of alternative solutions to our problems.  = I will detail those in the response to Joe Touch's list entry.

 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831)= 659-8360
www.insidethestack.com

From: Eric Vyncke (evyncke) <evyncke@cisco.c= om>
To: Nalini Elki= ns <nalini.elkins@insidethestack.com>; "Templin, Fred L" <Fred.L.T= emplin@boeing.com>; joel jaeggli <joelja@bogus.com>; IPv6 Ops WG &= lt;v6ops@ietf.org>
Sent: Friday, March 15, 2013 5:32 PM
Subject: RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed= -00

=0A
=0A=0A =0A =0A=0A=0A
=0A
=0A
And at the risk of being f= lamed, I am fully supportive for firewalls (if you need one) to drop anythi= ng that they are unable to understand.
=0A
 
=0A
This does not mean = that I am not supportive of solving the problem raised by Nalini of course<= /span>
=0A
 
=0A
-=E9ric
=0A
 <= /span>
=0A
=0A
=0A
=0A
From:= v6ops-bounces@ietf.or= g [mailto:v6ops-bounces@ietf.org]=0AOn Behalf Of Nalini Elkins
= =0ASent: jeudi 14 mars 2013 23:38
=0ATo: Templin, Fred L; = joel jaeggli; IPv6 Ops WG
=0ASubject: Re: [v6ops] draft-elkins-v6= ops-ipv6-ipid-needed-00
=0A
=0A
=0A
 
=0A
=0A
=0A
Fred,
=0A
=0A
=0A
 
=0A
=0A
=0A
Thanks f= or your comments.
=0A
=0A
=0A
 <= /div> =0A
=0A
=0A
We are getting a lot of comments from pe= ople that the reality of the situation is that many firewalls drop packets = with IPv6 extension headers.   Including fragment=0A header.   Pe= ople seem to feel there are a lot of security issues with IPv6 extension he= aders.  I do feel that adding an atomic fragment header with each pack= et would have been a great solution but does not seem to have much support.=   We have not ruled anything=0A out but I am just telling you what we= are hearing.
=0A
=0A
=0A
  =0A
=0A
=0A
BTW, any chance of getting a timestamp in th= e SEAL header?
=0A
=0A
=0A
 
=0A
=0A
=0A
Thanks,
=0A
=0A
= =0A
Nalini Elkins<= br>=0AInside Products, Inc.
=0A(831) 659-8360
=0Awww.insidethestac= k.com
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
From: "= Templin, Fred L" <Fred= .L.Templin@boeing.com>
=0ATo: Nalini Elkins <nalini.elkins@insidet= hestack.com>; joel jaeggli <joelj= a@bogus.com>; IPv6 Ops WG <v6ops@ietf= .org>=0A
=0ASent: Thursday, March 14, 2013 3:27 PM
=0A<= b>Subject: RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
=0A
=0A

=0AHi Nalini,
=0A
=0AJust to clarify, RFC5320 w= ill soon be obsoleted by 'draft-templin-intarea-seal'.
=0ABut, also note= that the source and destination would both need to be SEAL-aware,
=0Aso= the complexity would be worse than just asking the source to unconditional= ly
=0Ainclude an IPv6 fragment header with a well-behave ID.
=0A
= =0AThanks - Fred
=0Afr= ed.l.templin@boeing.com
=0A
=0A> -----Original Message-----=0A> From: v6ops-bounces@ie= tf.org [mailto:v6ops-bounce= s@ietf.org] On Behalf Of
=0A> Nalini Elkins
=0A> Sent: Thur= sday, March 14, 2013 2:53 PM
=0A> To: joel jaeggli; IPv6 Ops WG
= =0A> Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
=0A&= gt;
=0A> Joel,
=0A>
=0A> Thanks so much for your feedba= ck.   One of the alternatives that we are
=0A> looking at to pro= vide a Packet Sequence Number is a 'SHIM' such as that
=0A> provided = by SEAL.
=0A>
=0A> http://tools.ietf.org/html/rfc5320
=0A&g= t;
=0A> This header (if I am reading this correctly!) would be betwe= en the TCP or
=0A> UDP header and the application payload.
=0A>=
=0A> One of the things that SEAL provides is:
=0A>
=0A>= ; SEAL_ID - a 32-bit Identification value, randomly initialized and
=0A&= gt; monotonically incremented for each SEAL protocol packet
=0A>
= =0A> So, this might provide exactly what we are looking for!
=0A> =
=0A> We do understand that there are a number of issues with IPv6 ex= tension
=0A> headers.   We are not wedded to a particular i= mplementation and whatever
=0A> will provide the information we need = is perfect!   But, we have just found
=0A> out about this RFC an= d need to study it more to see if there are any
=0A> drawbacks.
= =0A>
=0A> Thanks,
=0A>
=0A> Nalini Elkins
=0A>= Inside Products, Inc.
=0A> (831) 659-8360
=0A> www.insideth= estack.com
=0A>
=0A>
=0A>
=0A> _____________= ___________________
=0A> From: joel jaeggli <joelja@bogus.com>
=0A> To: IPv6 Ops WG <v6ops@ietf.org>
=0A> Sent: Thursday, Mar= ch 14, 2013 8:13 AM
=0A> Subject: [v6ops] draft-elkins-v6ops-ipv6-ipi= d-needed-00
=0A>
=0A> some more thoughts since the presentatio= n.
=0A>
=0A> Noted that I consulted the earlier draft, discuss= ion in 6-man and appendix
=0A> a in the slides.
=0A>
=0A>= ; http://tools.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header-00=0A>
=0A> was the previous one.
=0A>
=0A> The reque= st is not really for the ipv4 IPID/frag header in v6. it's for a
=0A>= unique per packet value over a given sample interval.
=0A>
=0A&g= t; The utility of ipid in ipv4 for this context has eroded over time, (this=
=0A> is not knock againt the draft I'm just trying to describe my un= derstanding
=0A> of the utility). IPID's in the context of mobile pho= nes/mobile networks
=0A> are typically unvarrying (due to header comp= resssion). rfc 6864 exists
=0A> because modern implmentations cannot = (and therefore don't) honor
=0A> requirements for uniqueness in rfc79= 1,rfc1122 e.g. the duration over which
=0A> 16 bit IPID is valid for = uniqueness is bounded by the size of the flow
=0A> because if it were= limited by the MDL it would limit that speed of a flow.
=0A> a 10Gb/= s flow with 1500 byte packets overflows a 16 bit value every 78 or
=0A&g= t; so ms. if your capture is longer than that you can reasonably expect
= =0A> duplicate IPIDS to show up which are readily identifiable as not be= ing
=0A> duplicate packets.
=0A>
=0A> desirable properti= es of a unique per packet value to my mind...
=0A>
=0A> * That= it doesn't cost us anything - it strikes me as undesirable that
=0A>= packets should in general have larger headers then they do today that adds=
=0A> cost all over the place. extension header processing or indeed<= br>=0A> fragmentation header use has conquences.
=0A>
=0A> = see http://tools.ietf.org/html/draft-wkumari-l= ong-headers-00
=0A>
=0A> for dicussion that has come up ab= out header processing in modern routers.
=0A>
=0A> and
=0A&= gt;
=0A> http://tools.ietf.org/html/dr= aft-taylor-v6ops-fragdrop-00
=0A>
=0A> for a similar discu= ssion about fragmentation headers.
=0A>
=0A> neither of these = represent any form of consensus document, so take that
=0A> with a gr= ain of salt.
=0A>
=0A> * That it is applied to every packet - = part of the stated utility of the
=0A> ipv4 ipid is that it's present= (with my noted caveats) you don't have to
=0A> turn it on. likewise = this implies that the application of the value does
=0A> not impact t= he observation, having the packet size change because you're
=0A> doi= ng debugging means imho that you're not doing the
=0A> ______________= _________________________________
=0A> v6ops mailing list
=0A> = v6ops@ietf.org
=0A> h= ttps://www.ietf.org/mailman/listinfo/v6ops
=0A> _________________= ______________________________
=0A> v6ops mailing list
=0A> v6ops@ietf.org
=0A> ht= tps://www.ietf.org/mailman/listinfo/v6ops
=0A
=0A
= =0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A=0A
=

---1551098171-44754328-1363441000=:29041-- From owen@delong.com Sun Mar 17 03:16:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14AC121F871E for ; Sun, 17 Mar 2013 03:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eUWD0L-ki9B for ; Sun, 17 Mar 2013 03:16:19 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5688021F86F7 for ; Sun, 17 Mar 2013 03:16:19 -0700 (PDT) Received: from [10.10.1.89] ([216.190.116.21]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2HADGZl019887 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 17 Mar 2013 03:13:17 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2HADGZl019887 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363515198; bh=pSUWwfQPWkbZDeh/r9heR1lGnW8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=oug4liIzKqlDW03SZIKR5ve8Sm2X5hweO61n9s4emkEEPyIxkzrRtfPBaacliW7ry BH0bcro68LYlJQOprZKyVCVCLWLJj1WxNBnKHvP9iCnBZ7fm3I42utKzrLpsJvmvVp 8QwZYTfgUT3lmE9UQm9oHCNB2n1ekMW7eYAk9Qww= Content-Type: multipart/alternative; boundary="Apple-Mail=_E9D7A875-A856-46E9-9AFA-152CCDD0A6CA" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <1363441000.29041.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Sun, 17 Mar 2013 03:13:16 -0700 Message-Id: References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D9831802F8BE@XCH-BLV-504.nw.nos.boeing.com> <1363300650.51430.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <97EB7536A2B2C549846804BBF3FD47E112EE7C4C@xmb-aln-x02.cisco.com> <1363441000.29041.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> To: Nalini Elkins X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Sun, 17 Mar 2013 03:13:18 -0700 (PDT) Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 10:16:20 -0000 --Apple-Mail=_E9D7A875-A856-46E9-9AFA-152CCDD0A6CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Mar 16, 2013, at 6:36 AM, Nalini Elkins = wrote: > Correct me if I am wrong, but I have to think that most firewalls are = only dropping packets that they are TOLD to drop. That is, an option = has been set by the network operator to drop certain packets. Maybe = these packets include IPv6 extension headers (fragment or otherwise). = It is, of course, possible that some firewalls (or other middle boxes) = do not understand certain packets and drop them or feel that ANY packets = containing IPv6 extension headers are suspect. This, I find to be an = over-reaction. How is this OK?=20 >=20 Hopefully quite the reverse=85 A firewall should drop any packet it has = not been told to pass. The operator should set options to pass certain packets. If the firewall doesn't provide sufficient interface knobs to accept = certain packets (e.g. IPv6, Fragments, extension headers, etc.), then it = may not be possible to cause the firewall not to drop them. If your default is to drop all packets that you are not configured to = accept and you lack the UI to be configured to accept some forms of = packets, there is no way you can pass those packets. This is quite = acceptable and expected. What is neither acceptable nor expected at this = point is the abysmal state of firewall development WRT IPv6. Owen --Apple-Mail=_E9D7A875-A856-46E9-9AFA-152CCDD0A6CA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 nalini.elkins@insidethest= ack.com> wrote:

Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 11:24:14 -0000 ---1551098171-1887888483-1363519449=:86288 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Owen - well said!=0A=C2=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Product= s, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A______________= __________________=0A From: Owen DeLong =0ATo: Nalini Elki= ns =0ACc: Eric Vyncke (evyncke) ; "Templin, Fred L" ; joel jaeggli ; IPv6 Ops WG =0ASent: Sunday, March 17, 2= 013 6:13 AM=0ASubject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00= =0A =0A=0A=0A=0AOn Mar 16, 2013, at 6:36 AM, Nalini Elkins wrote:=0A=0ACorrect me if I am wrong, but I have to thin= k that most firewalls are only dropping packets that they are TOLD to drop.= =C2=A0That is, an option has been set by the network operator to drop cert= ain packets. =C2=A0Maybe these packets include IPv6 extension headers (frag= ment or otherwise). =C2=A0 It is, of course, possible that some firewalls (= or other middle boxes) do not understand certain packets and drop them or f= eel that ANY packets containing IPv6 extension headers are suspect. =C2=A0T= his, I find to be an over-reaction. =C2=A0 How is this OK?=C2=A0=0A>=0A>=0A= Hopefully quite the reverse=E2=80=A6 A firewall should drop any packet it h= as not been told to pass.=0A=0AThe operator should set options to pass cert= ain packets.=0A=0AIf the firewall doesn't provide sufficient interface knob= s to accept certain packets (e.g. IPv6, Fragments, extension headers, etc.)= , then it may not be possible to cause the firewall not to drop them.=0A=0A= If your default is to drop all packets that you are not configured to accep= t and you lack the UI to be configured to accept some forms of packets, the= re is no way you can pass those packets. This is quite acceptable and expec= ted. What is neither acceptable nor expected at this point is the abysmal s= tate of firewall development WRT IPv6.=0A=0AOwen ---1551098171-1887888483-1363519449=:86288 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Owen - well said!
 
Thanks,

Nalini = Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com=

From: O= wen DeLong <owen@delong.com>
Cc: Eric Vyncke (evyncke)= <evyncke@cisco.com>; "Templin, Fred L" <Fred.L.Templin@boeing.com= >; joel jaeggli <joelja@bogus.com>; IPv6 Ops WG <v6ops@ietf.org= >
Sent: Sunday, March 17, 2= 013 6:13 AM
Subject: R= e: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

= =0A

On Mar 16, 2013, at 6:36 AM= , Nalini Elkins <nalini.elkins@insidethestack.com> wrote:

Correct me if I am wrong, but = I have to think that most firewalls are only dropping packets that they are= TOLD to drop.  That is, an option has been set by the network operato= r to drop certain packets.  Maybe these packets include IPv6 extension= headers (fragment or otherwise).   It is, of course, possible that so= me firewalls (or other middle boxes) do not understand certain packets and = drop them or feel that ANY packets containing IPv6 extension headers are su= spect.  This, I find to be an over-reaction.   How is this OK? 
To: Nalini Elkins , Owen DeLong Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Thread-Index: AQHOIMaVqC5M9XVYp0uFMLNLdFX3pZil/fsAgAAJxwCAAALEAIABgD6AgAENUQCAAVmAAIAAE86AgAAFexA= Date: Sun, 17 Mar 2013 15:45:25 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A64E131@PWN401EA160.ent.corp.bcbsm.com> References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D9831802F8BE@XCH-BLV-504.nw.nos.boeing.com> <1363300650.51430.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <97EB7536A2B2C549846804BBF3FD47E112EE7C4C@xmb-aln-x02.cisco.com> <1363441000.29041.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1363519449.86288.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> In-Reply-To: <1363519449.86288.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: multipart/alternative; boundary="_000_4FC37E442D05A748896589E468752CAA0A64E131PWN401EA160entc_" MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 15:45:39 -0000 --_000_4FC37E442D05A748896589E468752CAA0A64E131PWN401EA160entc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RUNITyEhISEhISEhISENCg0KQW5kIHVuZm9ydHVuYXRlbHkgdW50aWwgRmlyZXdhbGxzIGFu ZCBvdGhlciBzZWN1cml0eSBkZXZpY2VzIOKAnENhdGNoIHVw4oCdLCAgIGRlcGxveW1lbnRz IGF0IGluc3RhbGxhdGlvbnMgc3VjaCBhcyBtaW5lIHdpbGwgYmUgc2xvd2VkIChvciB3b3Jz ZSkuICAgIOKYuQ0KDQoNCg0KRnJvbTogTmFsaW5pIEVsa2lucyBbbWFpbHRvOm5hbGluaS5l bGtpbnNAaW5zaWRldGhlc3RhY2suY29tXQ0KU2VudDogU3VuZGF5LCBNYXJjaCAxNywgMjAx MyA3OjI0IEFNDQpUbzogT3dlbiBEZUxvbmcNCkNjOiBFcmljIFZ5bmNrZSAoZXZ5bmNrZSk7 IFRlbXBsaW4sIEZyZWQgTDsgam9lbCBqYWVnZ2xpOyBJUHY2IE9wcyBXRw0KU3ViamVjdDog UmU6IFt2Nm9wc10gZHJhZnQtZWxraW5zLXY2b3BzLWlwdjYtaXBpZC1uZWVkZWQtMDANCg0K T3dlbiAtIHdlbGwgc2FpZCENCg0KVGhhbmtzLA0KTmFsaW5pIEVsa2lucw0KSW5zaWRlIFBy b2R1Y3RzLCBJbmMuDQooODMxKSA2NTktODM2MA0Kd3d3Lmluc2lkZXRoZXN0YWNrLmNvbTxo dHRwOi8vd3d3Lmluc2lkZXRoZXN0YWNrLmNvbT4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpGcm9tOiBPd2VuIERlTG9uZyA8b3dlbkBkZWxvbmcuY29tPG1haWx0bzpv d2VuQGRlbG9uZy5jb20+Pg0KVG86IE5hbGluaSBFbGtpbnMgPG5hbGluaS5lbGtpbnNAaW5z aWRldGhlc3RhY2suY29tPG1haWx0bzpuYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNv bT4+DQpDYzogRXJpYyBWeW5ja2UgKGV2eW5ja2UpIDxldnluY2tlQGNpc2NvLmNvbTxtYWls dG86ZXZ5bmNrZUBjaXNjby5jb20+PjsgIlRlbXBsaW4sIEZyZWQgTCIgPEZyZWQuTC5UZW1w bGluQGJvZWluZy5jb208bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+Pjsgam9l bCBqYWVnZ2xpIDxqb2VsamFAYm9ndXMuY29tPG1haWx0bzpqb2VsamFAYm9ndXMuY29tPj47 IElQdjYgT3BzIFdHIDx2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+Pg0K U2VudDogU3VuZGF5LCBNYXJjaCAxNywgMjAxMyA2OjEzIEFNDQpTdWJqZWN0OiBSZTogW3Y2 b3BzXSBkcmFmdC1lbGtpbnMtdjZvcHMtaXB2Ni1pcGlkLW5lZWRlZC0wMA0KDQoNCk9uIE1h ciAxNiwgMjAxMywgYXQgNjozNiBBTSwgTmFsaW5pIEVsa2lucyA8bmFsaW5pLmVsa2luc0Bp bnNpZGV0aGVzdGFjay5jb208bWFpbHRvOm5hbGluaS5lbGtpbnNAaW5zaWRldGhlc3RhY2su Y29tPj4gd3JvdGU6DQoNCg0KQ29ycmVjdCBtZSBpZiBJIGFtIHdyb25nLCBidXQgSSBoYXZl IHRvIHRoaW5rIHRoYXQgbW9zdCBmaXJld2FsbHMgYXJlIG9ubHkgZHJvcHBpbmcgcGFja2V0 cyB0aGF0IHRoZXkgYXJlIFRPTEQgdG8gZHJvcC4gIFRoYXQgaXMsIGFuIG9wdGlvbiBoYXMg YmVlbiBzZXQgYnkgdGhlIG5ldHdvcmsgb3BlcmF0b3IgdG8gZHJvcCBjZXJ0YWluIHBhY2tl dHMuICBNYXliZSB0aGVzZSBwYWNrZXRzIGluY2x1ZGUgSVB2NiBleHRlbnNpb24gaGVhZGVy cyAoZnJhZ21lbnQgb3Igb3RoZXJ3aXNlKS4gICBJdCBpcywgb2YgY291cnNlLCBwb3NzaWJs ZSB0aGF0IHNvbWUgZmlyZXdhbGxzIChvciBvdGhlciBtaWRkbGUgYm94ZXMpIGRvIG5vdCB1 bmRlcnN0YW5kIGNlcnRhaW4gcGFja2V0cyBhbmQgZHJvcCB0aGVtIG9yIGZlZWwgdGhhdCBB TlkgcGFja2V0cyBjb250YWluaW5nIElQdjYgZXh0ZW5zaW9uIGhlYWRlcnMgYXJlIHN1c3Bl Y3QuICBUaGlzLCBJIGZpbmQgdG8gYmUgYW4gb3Zlci1yZWFjdGlvbi4gICBIb3cgaXMgdGhp cyBPSz8NCg0KDQpIb3BlZnVsbHkgcXVpdGUgdGhlIHJldmVyc2XigKYgQSBmaXJld2FsbCBz aG91bGQgZHJvcCBhbnkgcGFja2V0IGl0IGhhcyBub3QgYmVlbiB0b2xkIHRvIHBhc3MuDQoN ClRoZSBvcGVyYXRvciBzaG91bGQgc2V0IG9wdGlvbnMgdG8gcGFzcyBjZXJ0YWluIHBhY2tl dHMuDQoNCklmIHRoZSBmaXJld2FsbCBkb2Vzbid0IHByb3ZpZGUgc3VmZmljaWVudCBpbnRl cmZhY2Uga25vYnMgdG8gYWNjZXB0IGNlcnRhaW4gcGFja2V0cyAoZS5nLiBJUHY2LCBGcmFn bWVudHMsIGV4dGVuc2lvbiBoZWFkZXJzLCBldGMuKSwgdGhlbiBpdCBtYXkgbm90IGJlIHBv c3NpYmxlIHRvIGNhdXNlIHRoZSBmaXJld2FsbCBub3QgdG8gZHJvcCB0aGVtLg0KDQpJZiB5 b3VyIGRlZmF1bHQgaXMgdG8gZHJvcCBhbGwgcGFja2V0cyB0aGF0IHlvdSBhcmUgbm90IGNv bmZpZ3VyZWQgdG8gYWNjZXB0IGFuZCB5b3UgbGFjayB0aGUgVUkgdG8gYmUgY29uZmlndXJl ZCB0byBhY2NlcHQgc29tZSBmb3JtcyBvZiBwYWNrZXRzLCB0aGVyZSBpcyBubyB3YXkgeW91 IGNhbiBwYXNzIHRob3NlIHBhY2tldHMuIFRoaXMgaXMgcXVpdGUgYWNjZXB0YWJsZSBhbmQg ZXhwZWN0ZWQuIFdoYXQgaXMgbmVpdGhlciBhY2NlcHRhYmxlIG5vciBleHBlY3RlZCBhdCB0 aGlzIHBvaW50IGlzIHRoZSBhYnlzbWFsIHN0YXRlIG9mIGZpcmV3YWxsIGRldmVsb3BtZW50 IFdSVCBJUHY2Lg0KDQpPd2VuDQoNCg0KCgpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgY29tbXVuaWNhdGlvbiBpcyBoaWdobHkgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRl bmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgdG8gd2hvbSB0 aGlzIGNvbW11bmljYXRpb24gaXMgZGlyZWN0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHZpZXdp bmcsIGNvcHlpbmcsIGRpc2Nsb3N1cmUgb3IgZGlzdHJpYnV0aW9uIG9mIHRoaXMgaW5mb3Jt YXRpb24gaXMgcHJvaGliaXRlZC4gUGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyLCBieSBlbGVj dHJvbmljIG1haWwgb3IgdGVsZXBob25lLCBvZiBhbnkgdW5pbnRlbmRlZCByZWNlaXB0IGFu ZCBkZWxldGUgdGhlIG9yaWdpbmFsIG1lc3NhZ2Ugd2l0aG91dCBtYWtpbmcgYW55IGNvcGll cy4KIAogQmx1ZSBDcm9zcyBCbHVlIFNoaWVsZCBvZiBNaWNoaWdhbiBhbmQgQmx1ZSBDYXJl IE5ldHdvcmsgb2YgTWljaGlnYW4gYXJlIG5vbnByb2ZpdCBjb3Jwb3JhdGlvbnMgYW5kIGlu ZGVwZW5kZW50IGxpY2Vuc2VlcyBvZiB0aGUgQmx1ZSBDcm9zcyBhbmQgQmx1ZSBTaGllbGQg QXNzb2NpYXRpb24uCg== --_000_4FC37E442D05A748896589E468752CAA0A64E131PWN401EA160entc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRl cmVkIG1lZGl1bSkiPg0KPCEtLVtpZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0K d1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1 cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oldpbmdk aW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6 MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhv bWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGku TXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RUNI TyEhISEhISEhISE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZCB1bmZvcnR1bmF0ZWx5 IHVudGlsIEZpcmV3YWxscyBhbmQgb3RoZXIgc2VjdXJpdHkgZGV2aWNlcyDigJxDYXRjaCB1 cOKAnSwmbmJzcDsmbmJzcDsgZGVwbG95bWVudHMgYXQgaW5zdGFsbGF0aW9ucyBzdWNoIGFz IG1pbmUgd2lsbCBiZSBzbG93ZWQgKG9yIHdvcnNlKS4mbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGlu Z3M7Y29sb3I6IzFGNDk3RCI+TDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBOYWxpbmkgRWxraW5z IFttYWlsdG86bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gU3VuZGF5LCBNYXJjaCAxNywgMjAxMyA3OjI0IEFNPGJyPg0KPGI+VG86PC9i PiBPd2VuIERlTG9uZzxicj4NCjxiPkNjOjwvYj4gRXJpYyBWeW5ja2UgKGV2eW5ja2UpOyBU ZW1wbGluLCBGcmVkIEw7IGpvZWwgamFlZ2dsaTsgSVB2NiBPcHMgV0c8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQtZWxraW5zLXY2b3BzLWlwdjYtaXBpZC1uZWVk ZWQtMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Pd2VuIC0gd2VsbCBzYWlkITxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5OYWxp bmkgRWxraW5zPGJyPg0KSW5zaWRlIFByb2R1Y3RzLCBJbmMuPGJyPg0KKDgzMSkgNjU5LTgz NjA8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3Lmluc2lkZXRoZXN0YWNrLmNvbSI+d3d3Lmlu c2lkZXRoZXN0YWNrLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxl PSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIxMDAl IiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+IE93ZW4gRGVMb25nICZsdDs8YSBocmVmPSJtYWlsdG86 b3dlbkBkZWxvbmcuY29tIj5vd2VuQGRlbG9uZy5jb208L2E+Jmd0Ozxicj4NCjxiPlRvOjwv Yj4gTmFsaW5pIEVsa2lucyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5hbGluaS5lbGtpbnNAaW5z aWRldGhlc3RhY2suY29tIj5uYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbTwvYT4m Z3Q7DQo8YnI+DQo8Yj5DYzo8L2I+IEVyaWMgVnluY2tlIChldnluY2tlKSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmV2eW5ja2VAY2lzY28uY29tIj5ldnluY2tlQGNpc2NvLmNvbTwvYT4mZ3Q7 OyAmcXVvdDtUZW1wbGluLCBGcmVkIEwmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpGcmVk LkwuVGVtcGxpbkBib2VpbmcuY29tIj5GcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9hPiZn dDs7IGpvZWwgamFlZ2dsaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvZWxqYUBib2d1cy5jb20i PmpvZWxqYUBib2d1cy5jb208L2E+Jmd0OzsNCiBJUHY2IE9wcyBXRyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4mZ3Q7IDxicj4NCjxi PlNlbnQ6PC9iPiBTdW5kYXksIE1hcmNoIDE3LCAyMDEzIDY6MTMgQU08YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQtZWxraW5zLXY2b3BzLWlwdjYtaXBpZC1uZWVk ZWQtMDA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgaWQ9InlpdjExNDY0MTM4NzUiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+T24gTWFyIDE2LCAyMDEzLCBhdCA2OjM2IEFNLCBOYWxpbmkgRWxr aW5zICZsdDs8YSBocmVmPSJtYWlsdG86bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5j b20iIHRhcmdldD0iX2JsYW5rIj5uYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkNvcnJlY3Qg bWUgaWYgSSBhbSB3cm9uZywgYnV0IEkgaGF2ZSB0byB0aGluayB0aGF0IG1vc3QgZmlyZXdh bGxzIGFyZSBvbmx5IGRyb3BwaW5nIHBhY2tldHMgdGhhdCB0aGV5IGFyZSBUT0xEIHRvIGRy b3AuICZuYnNwO1RoYXQgaXMsIGFuIG9wdGlvbg0KIGhhcyBiZWVuIHNldCBieSB0aGUgbmV0 d29yayBvcGVyYXRvciB0byBkcm9wIGNlcnRhaW4gcGFja2V0cy4gJm5ic3A7TWF5YmUgdGhl c2UgcGFja2V0cyBpbmNsdWRlIElQdjYgZXh0ZW5zaW9uIGhlYWRlcnMgKGZyYWdtZW50IG9y IG90aGVyd2lzZSkuICZuYnNwOyBJdCBpcywgb2YgY291cnNlLCBwb3NzaWJsZSB0aGF0IHNv bWUgZmlyZXdhbGxzIChvciBvdGhlciBtaWRkbGUgYm94ZXMpIGRvIG5vdCB1bmRlcnN0YW5k IGNlcnRhaW4gcGFja2V0cyBhbmQgZHJvcCB0aGVtDQogb3IgZmVlbCB0aGF0IEFOWSBwYWNr ZXRzIGNvbnRhaW5pbmcgSVB2NiBleHRlbnNpb24gaGVhZGVycyBhcmUgc3VzcGVjdC4gJm5i c3A7VGhpcywgSSBmaW5kIHRvIGJlIGFuIG92ZXItcmVhY3Rpb24uICZuYnNwOyBIb3cgaXMg dGhpcyBPSz8mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Ib3BlZnVsbHkgcXVpdGUgdGhl IHJldmVyc2XigKYgQSBmaXJld2FsbCBzaG91bGQgZHJvcCBhbnkgcGFja2V0IGl0IGhhcyBu b3QgYmVlbiB0b2xkIHRvIHBhc3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIG9wZXJhdG9yIHNob3VsZCBz ZXQgb3B0aW9ucyB0byBwYXNzIGNlcnRhaW4gcGFja2V0cy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JZiB0aGUg ZmlyZXdhbGwgZG9lc24ndCBwcm92aWRlIHN1ZmZpY2llbnQgaW50ZXJmYWNlIGtub2JzIHRv IGFjY2VwdCBjZXJ0YWluIHBhY2tldHMgKGUuZy4gSVB2NiwgRnJhZ21lbnRzLCBleHRlbnNp b24gaGVhZGVycywgZXRjLiksIHRoZW4gaXQgbWF5IG5vdCBiZSBwb3NzaWJsZSB0byBjYXVz ZSB0aGUgZmlyZXdhbGwgbm90DQogdG8gZHJvcCB0aGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPklmIHlvdXIg ZGVmYXVsdCBpcyB0byBkcm9wIGFsbCBwYWNrZXRzIHRoYXQgeW91IGFyZSBub3QgY29uZmln dXJlZCB0byBhY2NlcHQgYW5kIHlvdSBsYWNrIHRoZSBVSSB0byBiZSBjb25maWd1cmVkIHRv IGFjY2VwdCBzb21lIGZvcm1zIG9mIHBhY2tldHMsIHRoZXJlIGlzIG5vIHdheSB5b3UgY2Fu IHBhc3MgdGhvc2UgcGFja2V0cy4NCiBUaGlzIGlzIHF1aXRlIGFjY2VwdGFibGUgYW5kIGV4 cGVjdGVkLiBXaGF0IGlzIG5laXRoZXIgYWNjZXB0YWJsZSBub3IgZXhwZWN0ZWQgYXQgdGhp cyBwb2ludCBpcyB0aGUgYWJ5c21hbCBzdGF0ZSBvZiBmaXJld2FsbCBkZXZlbG9wbWVudCBX UlQgSVB2Ni48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5Pd2VuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCgoKPEJSPgo8 aHRtbD4KIDxwPlRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBjb21tdW5pY2F0 aW9uIGlzIGhpZ2hseSBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbChzKSB0byB3aG9tIHRoaXMgY29tbXVuaWNhdGlv biBpcyBkaXJlY3RlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg eW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdmlld2luZywgY29weWluZywgZGlz Y2xvc3VyZSBvciBkaXN0cmlidXRpb24gb2YgdGhpcyBpbmZvcm1hdGlvbiBpcyBwcm9oaWJp dGVkLiBQbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIsIGJ5IGVsZWN0cm9uaWMgbWFpbCBvciB0 ZWxlcGhvbmUsIG9mIGFueSB1bmludGVuZGVkIHJlY2VpcHQgYW5kIGRlbGV0ZSB0aGUgb3Jp Z2luYWwgbWVzc2FnZSB3aXRob3V0IG1ha2luZyBhbnkgY29waWVzLjwvcD4KIDxwPkJsdWUg Q3Jvc3MgQmx1ZSBTaGllbGQgb2YgTWljaGlnYW4gYW5kIEJsdWUgQ2FyZSBOZXR3b3JrIG9m IE1pY2hpZ2FuIGFyZSBub25wcm9maXQgY29ycG9yYXRpb25zIGFuZCBpbmRlcGVuZGVudCBs aWNlbnNlZXMgb2YgdGhlIEJsdWUgQ3Jvc3MgYW5kIEJsdWUgU2hpZWxkIEFzc29jaWF0aW9u LjwvcD4KICA8L2h0bWw+Cgo= --_000_4FC37E442D05A748896589E468752CAA0A64E131PWN401EA160entc_-- From internet-drafts@ietf.org Mon Mar 18 05:58:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFF821F8AD5; Mon, 18 Mar 2013 05:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5f8XlNXQLvi; Mon, 18 Mar 2013 05:58:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA2521F8783; Mon, 18 Mar 2013 05:58:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130318125842.26412.33561.idtracker@ietfa.amsl.com> Date: Mon, 18 Mar 2013 05:58:42 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 12:58:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Multihoming without Network Address Translation Author(s) : Ole Troan David Miles Satoru Matsushima Tadahisa Okimoto Dan Wing Filename : draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05.txt Pages : 23 Date : 2013-03-18 Abstract: Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements, because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution and optionally DNS resolution. For IPv6 hosts one approach could be the use of NPTv6. However, NAT should be avoided, if at all possible, to permit transparent end-to- end connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements and possible solutions for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6 allocation criteria. We conclude that DHCPv6 based solutions are suitable to solve the multihoming issues, described in this document, while NPTv6 may be required as an intermediate solution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-multihoming-without-= ipv6nat There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-multihoming-without-ipv6na= t-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ipv6-multihoming-withou= t-ipv6nat-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Fred.L.Templin@boeing.com Mon Mar 18 08:45:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBBD321F8A3D for ; Mon, 18 Mar 2013 08:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 3O-FNjiMEvaE for ; Mon, 18 Mar 2013 08:45:23 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 62CB721F899E for ; Mon, 18 Mar 2013 08:45:21 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r2IFjD5u011329 for ; Mon, 18 Mar 2013 08:45:13 -0700 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r2IFjBHg011237 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 18 Mar 2013 08:45:13 -0700 Received: from XCH-PHX-509.sw.nos.boeing.com (10.57.37.31) by XCH-NWHT-05.nw.nos.boeing.com (130.247.25.109) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 18 Mar 2013 08:45:12 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.214]) by XCH-PHX-509.sw.nos.boeing.com ([169.254.9.149]) with mapi id 14.02.0328.011; Mon, 18 Mar 2013 08:45:12 -0700 From: "Templin, Fred L" To: Joe Touch , Simon Perreault Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Thread-Index: AQHOIaZRpovTMHVwr0KJKw2dWHfftZirlELA Date: Mon, 18 Mar 2013 15:45:11 +0000 Message-ID: <2134F8430051B64F815C691A62D983180319A7@XCH-BLV-504.nw.nos.boeing.com> References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <2134F8430051B64F815C691A62D9831802FB9D@XCH-BLV-504.nw.nos.boeing.com> <51431F7E.3090502@viagenie.ca> <51434F97.7080505@isi.edu> <51435158.1010006@viagenie.ca> <514360A2.2040800@isi.edu> In-Reply-To: <514360A2.2040800@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 15:45:24 -0000 Hi Joe, > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Joe Touch > Sent: Friday, March 15, 2013 10:56 AM > To: Simon Perreault > Cc: v6ops@ietf.org > Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 >=20 > Hi, Simon, >=20 > On 3/15/2013 9:50 AM, Simon Perreault wrote: > > Le 2013-03-15 12:43, Joe Touch a =E9crit : > >> > >> > >> On 3/15/2013 6:17 AM, Simon Perreault wrote: > >>> Le 2013-03-14 20:50, Templin, Fred L a =E9crit : > >>>> I have seen it suggested somewhere that NATs should > >>>> rewrite the IP_ID to a random value, but I'm not sure if many > >>>> implementations do that. What has been your experience? > >>> > >>> Here's one implementation that does that: > >>> http://www.openbsd.org/cgi-bin/man.cgi?query=3Dpf.conf > >>> > >>>> random-id > >>>> Replaces the IPv4 identification field with random values > to > >>>> compensate for predictable values generated by many hosts= . > >>>> This > >>>> option only applies to packets that are not fragmented > >>>> after the > >>>> optional fragment reassembly. > >>> > >>> Off by default. > >> > >> FWIW, that's a violation of RFC 791. > > > > Only if the default reassembly behaviour is turned off. >=20 > Reassembly should be required at NATs; otherwise, they can't ensure that > fragments can be reassembled (because they might give them different > IDs, or might go through different NATs). True, the NAT should collect up all of the fragments of a fragmented datagram before forwarding them. However, RFC1812 says: "A router MUST NOT reassemble any datagram before forwarding it." For that reason, NATs should do virtual fragment reassembly, i.e., collect up the fragments but then forward them on without reassembly once all fragments arrive. This is important, because the source and destination may have some sort of mutual understanding that packets will be sent and received as multiple IP fragments. If the NAT steps into the middle and does reassembly, then this understanding is violated. This is starting to veer off into an IPv4 topic, but I think the same considerations would apply also for IPv6. Thanks - Fred fred.l.templin@boeing.com =20 > > See: > > > >> set reassemble > >> The reassemble option is used to enable or disable the > >> reassembly > >> of fragmented packets, and can be set to yes (the > >> default) or no. > >> If no-df is also specified, fragments with the > >> dont-fragment bit > >> set are reassembled too, instead of being dropped; the > >> reassembled packet will have the dont-fragment bit > cleared. > > > >> Picking "random" values can/will potentially interfere with > >> fragmentation and reassembly, especially when those values don't > >> consider how they might step on values used by fragments OR when > >> 'random' isn't unique as expected if the DF bit isn't set. > > > > It might be a documentation bug. Here's the description of the function > > used for generating a "random ID". It's not really random... > > > >> /* > >> * Return a random IP id. Shuffle the new value we get into the > >> previous half > >> * of the ip_shuffle ring (-32767 or swap with ourself), to avoid > >> duplicates > >> * occuring too quickly but also still be random. > >> * > >> * 0 is a special IP ID -- don't return it. > >> */ > >> u_int16_t > >> ip_randomid(void) > >> { > >> ... >=20 > "avoiding duplicates too quickly" is not compliant. The rule is to > **ensure** that IDs are not duplicated during the maximum datagram > lifetime (typically considered 2 minutes; related to the max reassembly > lifetime). That includes throttling the generation of new IDs when > necessary. >=20 > > Does pf get the IETF seal of approval now? ;) >=20 > Nope, as per above. The rules aren't stated as "SHOULD NOT" repeat; they > are "MUST NOT" -- when DF=3D0. The rules for handling NATs and IDs, as > well as ID uniqueness, were stated in such terms in RFC 6864, and the > ink is barely dry on that. >=20 > Joe > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From touch@isi.edu Mon Mar 18 09:08:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E928D21F8BD0 for ; Mon, 18 Mar 2013 09:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVdn5Zezp3mp for ; Mon, 18 Mar 2013 09:08:36 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4C38321F8B9C for ; Mon, 18 Mar 2013 09:08:36 -0700 (PDT) Received: from [75.209.29.119] (119.sub-75-209-29.myvzw.com [75.209.29.119]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r2IG7T2H006001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Mar 2013 09:07:40 -0700 (PDT) Message-ID: <51473BC5.4020905@isi.edu> Date: Mon, 18 Mar 2013 09:07:33 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Templin, Fred L" References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <2134F8430051B64F815C691A62D9831802FB9D@XCH-BLV-504.nw.nos.boeing.com> <51431F7E.3090502@viagenie.ca> <51434F97.7080505@isi.edu> <51435158.1010006@viagenie.ca> <514360A2.2040800@isi.edu> <2134F8430051B64F815C691A62D983180319A7@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180319A7@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 16:08:37 -0000 Hi, Fred, On 3/18/2013 8:45 AM, Templin, Fred L wrote: > Hi Joe, > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of >> Joe Touch >> Sent: Friday, March 15, 2013 10:56 AM >> To: Simon Perreault >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 >> >> Hi, Simon, >> >> On 3/15/2013 9:50 AM, Simon Perreault wrote: >>> Le 2013-03-15 12:43, Joe Touch a écrit : >>>> >>>> >>>> On 3/15/2013 6:17 AM, Simon Perreault wrote: >>>>> Le 2013-03-14 20:50, Templin, Fred L a écrit : >>>>>> I have seen it suggested somewhere that NATs should >>>>>> rewrite the IP_ID to a random value, but I'm not sure if many >>>>>> implementations do that. What has been your experience? >>>>> >>>>> Here's one implementation that does that: >>>>> http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf >>>>> >>>>>> random-id >>>>>> Replaces the IPv4 identification field with random values >> to >>>>>> compensate for predictable values generated by many hosts. >>>>>> This >>>>>> option only applies to packets that are not fragmented >>>>>> after the >>>>>> optional fragment reassembly. >>>>> >>>>> Off by default. >>>> >>>> FWIW, that's a violation of RFC 791. >>> >>> Only if the default reassembly behaviour is turned off. >> >> Reassembly should be required at NATs; otherwise, they can't ensure that >> fragments can be reassembled (because they might give them different >> IDs, or might go through different NATs). > > True, the NAT should collect up all of the fragments of a fragmented > datagram before forwarding them. However, RFC1812 says: > > "A router MUST NOT reassemble any datagram before forwarding it." A NAT isn't a router. It acts like a host for the purposes of RFC1812, because it sources packets with its own IP address (to the public side), and acts as the sink of public addresses (to the private side). > For that reason, NATs should do virtual fragment reassembly, i.e., > collect up the fragments but then forward them on without reassembly > once all fragments arrive. That may be a useful optimization, but its the same net effect. The only difference is whether the fragment boundaries are the same before/after the NAT, and that doesn't matter for the purposes of PMTUD, etc. > This is important, because the source and destination may have some > sort of mutual understanding that packets will be sent and received > as multiple IP fragments. If the NAT steps into the middle and does > reassembly, then this understanding is violated. Source and dest exchange IP packets, not fragments. Any other understanding between the endpoints is already violated by the NAT process itself. > This is starting to veer off into an IPv4 topic, but I think the > same considerations would apply also for IPv6. Agreed; most of the considerations I'm discussing are applicable to both v4 and v6. Joe From Fred.L.Templin@boeing.com Mon Mar 18 09:23:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C058E21F8D14 for ; Mon, 18 Mar 2013 09:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 K1WupwS+wORZ for ; Mon, 18 Mar 2013 09:23:03 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 1D19B21F8C7D for ; Mon, 18 Mar 2013 09:22:21 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r2IGMoCK015931 for ; Mon, 18 Mar 2013 09:22:50 -0700 Received: from XCH-PHX-211.sw.nos.boeing.com (xch-phx-211.sw.nos.boeing.com [130.247.25.140]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r2IGMnau015928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 18 Mar 2013 09:22:49 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.214]) by XCH-PHX-211.sw.nos.boeing.com ([169.254.11.106]) with mapi id 14.02.0328.011; Mon, 18 Mar 2013 09:22:19 -0700 From: "Templin, Fred L" To: Joe Touch Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Thread-Index: AQHOI/KypovTMHVwr0KJKw2dWHfftZirn1xg Date: Mon, 18 Mar 2013 16:22:19 +0000 Message-ID: <2134F8430051B64F815C691A62D98318031A47@XCH-BLV-504.nw.nos.boeing.com> References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <2134F8430051B64F815C691A62D9831802FB9D@XCH-BLV-504.nw.nos.boeing.com> <51431F7E.3090502@viagenie.ca> <51434F97.7080505@isi.edu> <51435158.1010006@viagenie.ca> <514360A2.2040800@isi.edu> <2134F8430051B64F815C691A62D983180319A7@XCH-BLV-504.nw.nos.boeing.com> <51473BC5.4020905@isi.edu> In-Reply-To: <51473BC5.4020905@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 16:23:12 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Monday, March 18, 2013 9:08 AM > To: Templin, Fred L > Cc: Simon Perreault; v6ops@ietf.org > Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 >=20 > Hi, Fred, >=20 > On 3/18/2013 8:45 AM, Templin, Fred L wrote: > > Hi Joe, > > > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of > >> Joe Touch > >> Sent: Friday, March 15, 2013 10:56 AM > >> To: Simon Perreault > >> Cc: v6ops@ietf.org > >> Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 > >> > >> Hi, Simon, > >> > >> On 3/15/2013 9:50 AM, Simon Perreault wrote: > >>> Le 2013-03-15 12:43, Joe Touch a =E9crit : > >>>> > >>>> > >>>> On 3/15/2013 6:17 AM, Simon Perreault wrote: > >>>>> Le 2013-03-14 20:50, Templin, Fred L a =E9crit : > >>>>>> I have seen it suggested somewhere that NATs should > >>>>>> rewrite the IP_ID to a random value, but I'm not sure if many > >>>>>> implementations do that. What has been your experience? > >>>>> > >>>>> Here's one implementation that does that: > >>>>> http://www.openbsd.org/cgi-bin/man.cgi?query=3Dpf.conf > >>>>> > >>>>>> random-id > >>>>>> Replaces the IPv4 identification field with random > values > >> to > >>>>>> compensate for predictable values generated by many > hosts. > >>>>>> This > >>>>>> option only applies to packets that are not fragmented > >>>>>> after the > >>>>>> optional fragment reassembly. > >>>>> > >>>>> Off by default. > >>>> > >>>> FWIW, that's a violation of RFC 791. > >>> > >>> Only if the default reassembly behaviour is turned off. > >> > >> Reassembly should be required at NATs; otherwise, they can't ensure > that > >> fragments can be reassembled (because they might give them different > >> IDs, or might go through different NATs). > > > > True, the NAT should collect up all of the fragments of a fragmented > > datagram before forwarding them. However, RFC1812 says: > > > > "A router MUST NOT reassemble any datagram before forwarding it." >=20 > A NAT isn't a router. It acts like a host for the purposes of RFC1812, > because it sources packets with its own IP address (to the public side), > and acts as the sink of public addresses (to the private side). I had a feeling you would say that, but a NAT is really a hybrid of sorts that exhibits some host functions and some router functions. For the purpose of handling fragments, it needs to behave as a router. > > For that reason, NATs should do virtual fragment reassembly, i.e., > > collect up the fragments but then forward them on without reassembly > > once all fragments arrive. >=20 > That may be a useful optimization, but its the same net effect. The only > difference is whether the fragment boundaries are the same before/after > the NAT, and that doesn't matter for the purposes of PMTUD, etc. It isn't an optimization; the NAT still has to dedicate reassembly resources for all of the fragments even though it won't be reassembling. Instead, it is the only correct behavior permissible by RFC1812. It also does not have the same net effect. With *real* reassembly, the destination sees only whole IP packets and has no notion that the packets may have been fragmented at some earlier hop(s) of the path from the source. With *virtual* reassembly, the destination gets to see that the packets were fragmented. > > This is important, because the source and destination may have some > > sort of mutual understanding that packets will be sent and received > > as multiple IP fragments. If the NAT steps into the middle and does > > reassembly, then this understanding is violated. >=20 > Source and dest exchange IP packets, not fragments. Any other > understanding between the endpoints is already violated by the NAT > process itself. I disagree. If the source has some reason to send the destination fragmented packets, it should reasonably expect that they will arrive at the destination as fragments and not as whole packets. That is what virtual fragment reassembly is all about. > > This is starting to veer off into an IPv4 topic, but I think the > > same considerations would apply also for IPv6. >=20 > Agreed; most of the considerations I'm discussing are applicable to both > v4 and v6. OK. Thanks - Fred fred.l.templin@boeing.com > Joe From nalini.elkins@insidethestack.com Mon Mar 18 10:31:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE0D21F902D for ; Mon, 18 Mar 2013 10:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] 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 xisLAXkofIZv for ; Mon, 18 Mar 2013 10:31:40 -0700 (PDT) Received: from nm13-vm0.access.bullet.mail.sp2.yahoo.com (nm13-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.160]) by ietfa.amsl.com (Postfix) with ESMTP id 99B7721F9021 for ; Mon, 18 Mar 2013 10:31:38 -0700 (PDT) Received: from [98.139.44.103] by nm13.access.bullet.mail.sp2.yahoo.com with NNFMP; 18 Mar 2013 17:31:36 -0000 Received: from [98.139.44.78] by tm8.access.bullet.mail.sp2.yahoo.com with NNFMP; 18 Mar 2013 17:31:36 -0000 Received: from [127.0.0.1] by omp1015.access.mail.sp2.yahoo.com with NNFMP; 18 Mar 2013 17:31:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 440199.8048.bm@omp1015.access.mail.sp2.yahoo.com Received: (qmail 17032 invoked by uid 60001); 18 Mar 2013 17:31:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1363627896; bh=6bqQpP9Azs/1w0IZY5wDFnNhq7JMoV5+89lBy8vChbY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=h4rtnwkPOBNuVq3L/DNGFmcizY7jyWqNSQEnwzfIzbom2JA86NF3RiSHz7DbVOGChf8KSIM1xAAQhGg3z41eFhpU3rLX65fFYOrYZ+O4Jfds2b2pliQFXp8oA1JlZCItwkceugntJHaibEfuXqjaqhZM6ll6oBF/n57G3R+Yh10= X-YMail-OSG: 7J6_viwVM1lk36jr_Tx82enc_pY8OkcRMwsZp66cvti72aL rNsAtIIxQyjT0b9tkZh86Di4kk1uet1FZZoaiCaX6nbEJHK6siuL_BkTMpSC wyilRmf_T861Oox_Fur4dEYDAtZhRSqwA6AC_pCXrlB5J9V2jQZ0ocqUQfnT wH24ei.nO049Qw87t512CtwHSBdB_Rla8jVwuW5s8uj_cx_ukZqhPioPxGel ehyl.xYKmEPo1b7CE15nrIaKQz2PLnQfBBU3oIc67qumjXkYl6E7yY9M6qds R1UAHK53Q7_t00epWuknslGfQiMt87XzTiAOW0BcsHyFAvT8.Gs7dI4wD9cQ fq0aVZ_QxArYqhfjPRjYbKhMe2xP4Am7svImXo.EpIS_dTL71gc5x9nmeUQR O_23VylvuVgU5zFAjTd85fRl9bMdwiX96Jng.IvCnzyGIWaTNaaKncMoLB5S 0pAml9KlyRHaPrM86yzUWClv_qxQfnvbgTcc8wAUHFLFP3GcCKb0QcD.dEHR 4LL0RanYeAWMcNuocIAxV01Sb1MBF2NMY9mqsE_sZatxm.1YJF5B1T31PRYO MoKykHeITdDiK0gaQPQaR Received: from [24.130.37.147] by web2805.biz.mail.ne1.yahoo.com via HTTP; Mon, 18 Mar 2013 10:31:35 PDT X-Rocket-MIMEInfo: 002.001, R3V5cywKCk1heWJlIGl0IHdvdWxkIGJlIGJlc3QgdG8gYmFjayB1cCBhIGJpdCwgYW5kIHN0YXJ0IHdpdGggd2hhdCB3ZSB3YW50LCB3aHkgd2Ugd2FudCBpdCBhbmQgd2hhdCB3ZSBrbm93IHRvIGJlIHNvbWUgb2YgdGhlIHByb2JsZW1zLgoKMS4gwqAgVGhlcmUgaXMgYSBjbGFzcyBvZiBhcHBsaWNhdGlvbnMgZm9yIHdoaWNoIHRoZSB0aW1lIGZvciBkaWFnbm9zdGljcywgwqBwZXJmb3JtYW5jZSBhbmQgYWJpbGl0eSB0byBtYW5hZ2UgaXMgY3JpdGljYWwuIMKgVGhlc2UgbWF5IGJlIGZpbmFuY2lhbCAoYXMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.138.524 References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> Message-ID: <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Mon, 18 Mar 2013 10:31:35 -0700 (PDT) From: Nalini Elkins To: Joe Touch , Fred L MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1619178251-1598130816-1363627895=:16683" Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 17:31:52 -0000 --1619178251-1598130816-1363627895=:16683 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Guys,=0A=0AMaybe it would be best to back up a bit, and start with what we = want, why we want it and what we know to be some of the problems.=0A=0A1. = =A0 There is a class of applications for which the time for diagnostics, = =A0performance and ability to manage is critical. =A0These may be financial= (as ours are) but they may also be 911 in a city government, law enforceme= nt, and others. =A0=A0=0A=0A2. =A0 The platform may be IBM-mainframe based,= Windows, Unix or cell phone.=0A=0A3. =A0 Often problems are reported after= the fact. =A0As in, the Wire Transfer from xxx organization was too slow o= r did not complete properly.=0A=0A4. =A0 Again, often, packet traces are ei= ther available or are the easiest way to diagnose such problems. =A0Packet = traces may be available because all packets are sometimes stored for regula= tory reasons (ex. =A0all stock trades must be saved, etc). =A0 Packet trace= s are often easiest because the organization does not necessarily own all t= he equipment and middle boxes or because a business partner is involved. = =A0 An organization which owns all the hardware can do diagnostics differen= tly. =A0I used to work for such an organization and we would likely have st= uck a hardware probe on immediately. =A0This is quite often not an option i= n many organizations.=0A=0A5. =A0In IPv4, one of the fields we used was the= IP ID. =A0Even though, this field was meant for fragmentation, one of the = properties it had (on many platforms) was sequentiality. =A0 We used it as = a de-facto packet sequence number and also an eye catcher to know when the = packet trace that we are looking at is corrupted or has potential inaccurac= ies. =A0 What can happen is that middle boxes can sometimes duplicate packe= ts ONLY FOR SOME nodes or when we extract packets from one of the devices w= hich are continuously capturing packets, the extract itself is wrong.=A0 = =A0This is actually why hash of the packets will not work and why we need i= t for TCP.=0A=0A6. =A0Packet sequence number turns out to be quite an inter= esting and useful number - with all the drawbacks it has of potential wrapp= ing, etc. =A0 Taken in conjunction with TTL and other fields, it can often = reduce problem diagnostic time considerably. =A0 Our motto is: do not let t= he perfect be the enemy of the good. =A0=0A=0ANow, because IP ID is not in = the main IP header in IPv6 and may not be available in IPv4, we are looking= for a potential solution. =A0We are not going to deal with IPv4 - we will = only move forward to IPv6. =A0Let me detail some of the known problems with= solutions we have looked at:=0A=0A1. =A0 Use IPv6 Fragment extension heade= r with # of fragments set to 0 (atomic fragments). =A0 The problem with thi= s is that many firewalls (and possibly other devices) drop these. =A0 You m= ay be able to control this in your network but cannot in other peoples. =A0= That is, business partners.=0A=0A2. =A0Use IPv6 Dest Options extension head= er: similar issues as above but possibly even more as this may be even more= unrecognized by middle boxes. =A0Also, I have been told that adding IPv6 e= xtension headers will make the routing of the packets through routers and m= iddle boxes route at a software rather than hardware layer, thus slowing th= e performance. =A0Guys, am I right?=0A=0A3. =A0So, now, we are trying to go= back up the layers and consider the SHIM possibility. =A0That is, introduc= e a header that is between TCP and UDP and the application.=A0The idea of a= SHIM was brought to us by Ron Bonica (Ron, we owe you a beer in Berlin!). = =A0 This seems attractive in that only those applications which wish to emp= loy this can do it. =A0It also I believe gets us away from the IP layer. = =A0 It seems that changes at the IP layer are quite problematic.=0A=0A4. = =A0Then, we thought, if we are adding fields, something we would REALLY lik= e is a timestamp in every packet. =A0 So, we are considering designing a PD= -SHIM (Performance and Diagnostics SHIM) which will have a number of these = quite interesting fields. =A0This is when we started looking at Fred Templi= n's SEAL implementation. =A0But, it we may need different fields. =A0=0A=0A= BTW, =A0we are physically located in the Monterey and San Francisco Bay are= as. =A0So, Joe, if you have time, we can certainly drive down to Southern C= alifornia and maybe we can chat for an hour or two. =A0I will contact you o= ffline about that.=0A=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Produc= ts, Inc.=0A(831)=0A 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A__________= ______________________=0A From: Joe Touch =0ATo: Nalini Elki= ns =0ACc: joel jaeggli ; IPv6 Ops WG =0ASent: Thursday, March 14, 2013 3:38 PM= =0ASubject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00=0A =0AHi, al= l,=0A=0ASEAL wraps IP packets. If you put a shim above the transport layer = =0A(between TCP/UDP and the app payload), then you might not get the =0Asem= antics you want.=0A=0AWrapping UDP messages is fine - presuming you look at= the wrapper only =0Aat the endpoints; IP fragmentation may mean the wrappe= r isn't available =0Afor some datagrams.=0A=0AWrapping TCP segments is a ba= d idea IMO, and doesn't make sense.=0A=0ATCP segments exist only at the TCP= layer, and those boundaries are =0Ainvisible to the application layer. The= boundaries of what is written, =0Atransmitted, received, and, read may dif= fer (the middle two due to =0Arewriting proxies, which are evil but real).= =0A=0AIf you want/need a network identifier for diagnostics, it has to exis= t =0Aat the network layer.=0A=0ANB - as we noted during the discussion of R= FC6864, the IPv6 ID can exist =0A*either* when the source fragments *or* wh= en a 6-to-4 translation is =0Arequired=0A even for datagrams that otherwise= fit in an IPv6 MTU. You might =0Aupdate your intro accordingly:=0A=0A=A0 = =A0 ...The IPv6 fragment=0A=A0 =A0 header is present only when a datagram h= as been fragmented, or when=0A=A0 =A0 the source has received a "packet too= big" ICMPv6 error message=0A=A0 =A0 indicating that the path cannot suppor= t the required minimum=0A=A0 =A0 1280-byte IPv6 MTU and is thus subject to = translation [RFC2460]=0A=A0 =A0 [RFC4443].=A0 The latter case is relevant o= nly for IPv6 datagrams sent=0A=A0 =A0 to IPv4 destinations to support subse= quent fragmentation after=0A=A0 =A0 translation to IPv4.=0A=0ARegarding thi= s draft, it would be useful to explain why using the entire =0Apacket (or a= hash thereof) isn't nearly as useful in most cases (and =0Athat would not = require a new ID).=0A=0AAgain, note that most IPv4 implementations do not i= mplement the ID =0Auniqueness requirements=0A in RFC791, and some use repea= ted IDs (even that =0Adon't compress headers).=0A=0AJoe=0A=0A=0A=0A=0AOn 3/= 14/2013 2:52 PM, Nalini Elkins wrote:=0A> Joel,=0A>=0A> Thanks so much for = your feedback.=A0 One of the alternatives that we are looking at to provid= e a Packet Sequence Number is a 'SHIM' such as that provided by SEAL.=0A>= =0A> http://tools.ietf.org/html//rfc5320=0A>=0A> This header (if I am readi= ng this correctly!) would be between the TCP or UDP header and the applicat= ion payload.=0A>=0A> One of the things that SEAL provides is:=0A>=0A> SEAL_= ID - a 32-bit Identification value, randomly initialized and monotonically = incremented for each SEAL protocol packet=0A>=0A> So, this might provide ex= actly what we are looking for!=0A>=0A> We do understand that there are a nu= mber of issues with IPv6 extension headers.=A0 We are not wedded to a part= icular implementation and whatever will=0A provide the information we need = is perfect!=A0 But, we have just found out about this RFC and need to stud= y it more to see if there are any drawbacks.=0A>=0A> Thanks,=0A>=0A> Nalini= Elkins=0A> Inside Products, Inc.=0A> (831) 659-8360=0A> www.insidethestack= .com=0A>=0A>=0A>=0A> ________________________________=0A> From: joel jaeggl= i =0A> To: IPv6 Ops WG =0A> Sent: Thursda= y, March 14, 2013 8:13 AM=0A> Subject: [v6ops] draft-elkins-v6ops-ipv6-ipid= -needed-00=0A>=0A> some more thoughts since the presentation.=0A>=0A> Noted= that I consulted the earlier draft, discussion in 6-man and appendix a in = the slides.=0A>=0A>=0A http://tools.ietf.org/html/draft-elkins-6man-ipv6-di= agnostic-header-00=0A>=0A> was the previous one.=0A>=0A> The request is not= really for the ipv4 IPID/frag header in v6. it's for a unique per packet v= alue over a given sample interval.=0A>=0A> The utility of ipid in ipv4 for = this context has eroded over time, (this is not knock againt the draft I'm = just trying to describe my understanding of the utility). IPID's in the con= text of mobile phones/mobile networks are typically unvarrying (due to head= er compresssion). rfc 6864 exists because modern implmentations cannot (and= therefore don't) honor requirements for uniqueness in rfc791,rfc1122 e.g. = the duration over which 16 bit IPID is valid for uniqueness is bounded by t= he size of the flow because if it were limited by the MDL it would limit th= at speed of a flow. a 10Gb/s flow with 1500 byte packets overflows a 16 bit= value every 78 or so ms. if your capture is longer than that you=0A can re= asonably expect duplicate IPIDS to show up which are readily identifiable a= s not being duplicate packets.=0A>=0A> desirable properties of a unique per= packet value to my mind...=0A>=0A> * That it doesn't cost us anything - it= strikes me as undesirable that packets should in general have larger heade= rs then they do today that adds cost all over the place. extension header p= rocessing or indeed fragmentation header use has conquences.=0A>=0A> see ht= tp://tools.ietf.org/html/draft-wkumari-long-headers-00=0A>=0A> for dicussio= n that has come up about header processing in modern routers.=0A>=0A> and= =0A>=0A> http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00=0A>=0A> = for a similar discussion about fragmentation=0A headers.=0A>=0A> neither of= these represent any form of consensus document, so take that with a grain = of salt.=0A>=0A> * That it is applied to every packet - part of the stated = utility of the ipv4 ipid is that it's present (with my noted caveats) you d= on't have to turn it on. likewise this implies that the application of the = value does not impact the observation, having the packet size change becaus= e you're doing debugging means imho that you're not doing the=0A> _________= ______________________________________=0A> v6ops mailing list=0A> v6ops@iet= f.org=0A> https://www.ietf.org/mailman/listinfo/v6ops=0A> _________________= ______________________________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/v6ops=0A> --1619178251-1598130816-1363627895=:16683 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Guys,<= /span>

Maybe it would be best to back up a bit, and start with what we want, why we want i= t and what we know to be some of the problems.

1.   There is a class of applications for = which the time for diagnostics,  performance and ability to manage is = critical.  These may be financial (as ours are) but they may also be 9= 11 in a city government, law enforcement, and others.   

2.   The platform may be IBM-mainframe based, Windows, Unix or cell = phone.

3.   Often p= roblems are reported after the fact.  As in, the Wire Transfer from xx= x organization was too slow or did not complete properly.
<= br>
4.   Again, often, packet traces are either availa= ble or are the easiest way to diagnose such problems.  Packet traces m= ay be available because all packets are sometimes stored for regulatory rea= sons (ex.  all stock trades must be saved, etc).   Packet traces are = often easiest because the organization does not necessarily own all the equ= ipment and middle boxes or because a business partner is involved.   A= n organization which owns all the hardware can do diagnostics differently. =  I used to work for such an organization and we would likely have stuc= k a hardware probe on immediately.  This is quite often not an option = in many organizations.

5.  In IPv4, one o= f the fields we used was the IP ID.  Even though, this field was meant= for fragmentation, one of the properties it had (on many platforms) was sequen= tiality.   We used it as a de-facto packet sequence number and also an= eye catcher to know when the packet trace that we are looking at is corrup= ted or has potential inaccuracies.   What can happen is that middle bo= xes can sometimes duplicate packets ONLY FOR SOME nodes or when we extract = packets from one of the devices which are continuously capturing packets, t= he extract itself is wrong.   This is actually why hash of the pa= ckets will not work and why we need it for TCP.

6.  Packet sequence number turns out to be quite an interesting= and useful number - with all the drawbacks it has of potential wrapping, etc. =   Taken in conjunction with TTL and other fields, it can often reduce = problem diagnostic time considerably.   Our motto is: do not let the p= erfect be the enemy of the good.  

No= w, because IP ID is not in the main IP header in IPv6 and may not be availa= ble in IPv4, we are looking for a potential solution.  We are not goin= g to deal with IPv4 - we will only move forward to IPv6.  Let me detail so= me of the known problems with solutions we have looked at:
1.   Use IPv6 Fragment extension header with # of fr= agments set to 0 (atomic fragments).   The problem with this is that m= any firewalls (and possibly other devices) drop these.   You may be ab= le to control this in your network but cannot in other peoples.  That = is, business partners.

2.  Use IPv6 D= est Options extension header: similar issues as above but possibly even more as this may be even= more unrecognized by middle boxes.  Also, I have been told that addin= g IPv6 extension headers will make the routing of the packets through route= rs and middle boxes route at a software rather than hardware layer, thus sl= owing the performance.  Guys, am I right?

3.  So, now, we are trying to go back up the layers and conside= r the SHIM possibility.  That is, introduce a header that is between T= CP and UDP and the application. 
4.  Then, we thought, if we a= re adding fields, something we would REALLY like is a timestamp in every pa= cket.   So, we are considering designing a PD-SHIM (Performance and Di= agnostics SHIM) which will have a number of these quite interesting fields.=  This is when we started looking at Fred Templin's SEAL implementatio= n.  But, it we may need different fields.  
BTW,  we are physically located in the Monterey and = San Francisco Bay areas.  So, Joe, if you have time, we can certainly = drive down to Southern California and maybe we can chat for an hour or two.=  I will contact you offline about that.

 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831)=0A 659-8360
www.insidethestack= .com

From: Joe Touch <touch@isi.edu>
= To: Nalini Elkins <nalini.e= lkins@insidethestack.com>
Cc: joel jaeggli <joelja@bogus.com>; IPv6 Ops WG <v6ops@ietf= .org>
Sent: Thursda= y, March 14, 2013 3:38 PM
Subject:= Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
 =

=0AHi, all,

SEAL wraps IP packets. If you put a shim above the = transport layer
(between TCP/UDP and the app payload), then you might n= ot get the
semantics you want.

Wrapping UDP messages is fine - p= resuming you look at the wrapper only
at the endpoints; IP fragmentatio= n may mean the wrapper isn't available
for some datagrams.

Wrapp= ing TCP segments is a bad idea IMO, and doesn't make sense.

TCP segm= ents exist only at the TCP layer, and those boundaries are
invisible to= the application layer. The boundaries of what is written,
transmitted,= received, and, read may differ (the middle two due to
rewriting proxie= s, which are evil but real).

If you want/need a network identifier f= or diagnostics, it has to exist
at the network layer.

NB - as we= noted during the discussion of RFC6864, the IPv6 ID can exist
*either*= when the source fragments *or* when a 6-to-4 translation is
required= =0A even for datagrams that otherwise fit in an IPv6 MTU. You might
upd= ate your intro accordingly:

    ...The IPv6 fragment
&n= bsp;   header is present only when a datagram has been fragmented, or = when
    the source has received a "packet too big" ICMPv6 err= or message
    indicating that the path cannot support the req= uired minimum
    1280-byte IPv6 MTU and is thus subject to tr= anslation [RFC2460]
    [RFC4443].  The latter case is re= levant only for IPv6 datagrams sent
    to IPv4 destinations t= o support subsequent fragmentation after
    translation to IP= v4.

Regarding this draft, it would be useful to explain why using th= e entire
packet (or a hash thereof) isn't nearly as useful in most case= s (and
that would not require a new ID).

Again, note that most I= Pv4 implementations do not implement the ID
uniqueness requirements=0A = in RFC791, and some use repeated IDs (even that
don't compress headers)= .

Joe




On 3/14/2013 2:52 PM, Nalini Elkins wrote:<= br>> Joel,
>
> Thanks so much for your feedback.  One = of the alternatives that we are looking at to provide a Packet Sequence Num= ber is a 'SHIM' such as that provided by SEAL.
>
> http://tools= .ietf.org/html//rfc5320
>
> This header (if I am reading this c= orrectly!) would be between the TCP or UDP header and the application paylo= ad.
>
> One of the things that SEAL provides is:
>
>= ; SEAL_ID - a 32-bit Identification value, randomly initialized and monoton= ically incremented for each SEAL protocol packet
>
> So, this m= ight provide exactly what we are looking for!
>
> We do underst= and that there are a number of issues with IPv6 extension headers.  W= e are not wedded to a particular implementation and whatever will=0A provid= e the information we need is perfect!  But, we have just found out ab= out this RFC and need to study it more to see if there are any drawbacks.>
> Thanks,
>
> Nalini Elkins
> Inside Product= s, Inc.
> (831) 659-8360
> www.insidethestack.com
>= ;
>
>
> ________________________________
> From: jo= el jaeggli <joelja@bogus.com>
= > To: IPv6 Ops WG <v6ops@ietf.org>=
> Sent: Thursday, March 14, 2013 8:13 AM
> Subject: [v6ops] dr= aft-elkins-v6ops-ipv6-ipid-needed-00
>
> some more thoughts sin= ce the presentation.
>
> Noted that I consulted the earlier dra= ft, discussion in 6-man and appendix a in the slides.
>
>=0A http:= //tools.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header-00
>> was the previous one.
>
> The request is not really for = the ipv4 IPID/frag header in v6. it's for a unique per packet value over a = given sample interval.
>
> The utility of ipid in ipv4 for this= context has eroded over time, (this is not knock againt the draft I'm just= trying to describe my understanding of the utility). IPID's in the context= of mobile phones/mobile networks are typically unvarrying (due to header c= ompresssion). rfc 6864 exists because modern implmentations cannot (and the= refore don't) honor requirements for uniqueness in rfc791,rfc1122 e.g. the = duration over which 16 bit IPID is valid for uniqueness is bounded by the s= ize of the flow because if it were limited by the MDL it would limit that s= peed of a flow. a 10Gb/s flow with 1500 byte packets overflows a 16 bit val= ue every 78 or so ms. if your capture is longer than that you=0A can reason= ably expect duplicate IPIDS to show up which are readily identifiable as no= t being duplicate packets.
>
> desirable properties of a unique= per packet value to my mind...
>
> * That it doesn't cost us a= nything - it strikes me as undesirable that packets should in general have = larger headers then they do today that adds cost all over the place. extens= ion header processing or indeed fragmentation header use has conquences.>
> see http://tools.ietf.org/html/d= raft-wkumari-long-headers-00
>
> for dicussion that has com= e up about header processing in modern routers.
>
> and
>=
> http://tools.ietf.org/html/draft-tay= lor-v6ops-fragdrop-00
>
> for a similar discussion about fragmentation=0A headers.
>
> neither of these represent= any form of consensus document, so take that with a grain of salt.
>=
> * That it is applied to every packet - part of the stated utility = of the ipv4 ipid is that it's present (with my noted caveats) you don't hav= e to turn it on. likewise this implies that the application of the value do= es not impact the observation, having the packet size change because you're= doing debugging means imho that you're not doing the
> _____________= __________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://w= ww.ietf.org/mailman/listinfo/v6ops
> ____________________________= ___________________
> v6ops mailing list
> v6ops@ietf.org
>= ; https://www.ietf.org/mailman/listinfo/v6ops
>

--1619178251-1598130816-1363627895=:16683-- From joelja@bogus.com Mon Mar 18 10:51:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B142D21F8FDA for ; Mon, 18 Mar 2013 10:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 Ay4a6qgk-c5P for ; Mon, 18 Mar 2013 10:51:18 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id A836021F8FD7 for ; Mon, 18 Mar 2013 10:51:18 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r2IHpA5k037107 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 18 Mar 2013 17:51:11 GMT (envelope-from joelja@bogus.com) Message-ID: <51475409.1010201@bogus.com> Date: Mon, 18 Mar 2013 10:51:05 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Nalini Elkins , Joe Touch , Fred L References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> In-Reply-To: <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> 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]); Mon, 18 Mar 2013 17:51:11 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 17:51:26 -0000 On 3/18/13 10:31 AM, Nalini Elkins wrote > > 2. Use IPv6 Dest Options extension header: similar issues as above > but possibly even more as this may be even more unrecognized by middle > boxes. Also, I have been told that adding IPv6 extension headers will > make the routing of the packets through routers and middle boxes route > at a software rather than hardware layer, thus slowing the > performance. Guys, am I right? This characterization extends back in time to when there was a software forwarding path, and while there may still be devices that have one,the class of high performance routers and L3 switches doing the heavy lifting effectively have a choice between asic-based-forwarding and no forwarding. If headers can safely beignored, great. if the addition of extensionheaders perturbs the the forwarding decision in some fashion (can't find the L4 header for example) the forwarding decision may be different, (or result in the packet being dropped) than the forwarding decision made without that header. > > From jhw@apple.com Mon Mar 18 11:21:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389CA21F8F15 for ; Mon, 18 Mar 2013 11:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-Sx0fJe3dGw for ; Mon, 18 Mar 2013 11:21:50 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id EC28F21F8DD1 for ; Mon, 18 Mar 2013 11:21:49 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MJV005E1CC03BG0@mail-out.apple.com> for v6ops@ietf.org; Mon, 18 Mar 2013 11:21:43 -0700 (PDT) X-AuditID: 11807153-b7f8a6d0000064e7-fd-51475b36f163 Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 07.21.25831.63B57415; Mon, 18 Mar 2013 11:21:43 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MJV00CFWCC6DN10@aniseed.apple.com> for v6ops@ietf.org; Mon, 18 Mar 2013 11:21:42 -0700 (PDT) From: james woodyatt In-reply-to: <51475409.1010201@bogus.com> Date: Mon, 18 Mar 2013 11:21:42 -0700 Message-id: <084D95C1-07ED-4C54-859D-9E974B12D715@apple.com> References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51475409.1010201@bogus.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1503) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUi2FAsrmse7R5o8Okyi8XpY3uZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsX7eUqaCPywVR5sWMjYw/mPuYuTkkBAwkWj6dxjKFpO4cG89 WxcjF4eQQD+TxM8jFxghnBlMEgsb17CAVDELaEms33mcCcTmFdCT2DZ3GxuILSxgLXH260mw GjYBFYlvl++C1XAKaErc3fESbAOLgKrE1Gl72CHmaEs8eXeBFWKOjcT5XReZIZY9Y5RYsO4h WEJEQEFix/+dTBDnyUq8fv6GZQIj/ywkd8xCcscsJHMXMDKvYhQoSs1JrDTWSywoyEnVS87P 3cQIDrLC4B2Mf5ZZHWIU4GBU4uFVDHMPFGJNLCuuzD3EKMHBrCTCG+wPFOJNSaysSi3Kjy8q zUktPsQozcGiJM5rHeQUKCSQnliSmp2aWpBaBJNl4uCUamDcNCerdtnuaTtyry/fNqvZ50VF xp9Npqey599feiX2yJKVL74sk6+wdA3RqUtjr5v1jvGJZkl14m2D+DOuSY4SGpdPPK3ey5Zw OvdL1QVtweVremamdwTtO/F10rsvqWWJXkbxzJdyjY1mvJ50qCza+UjAy6w95c+fnPl4Qaph TYvmx7dCJtxzlFiKMxINtZiLihMBM4+mkC4CAAA= Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 18:21:59 -0000 On Mar 18, 2013, at 10:51 , joel jaeggli wrote: > On 3/18/13 10:31 AM, Nalini Elkins wrote >> 2. Use IPv6 Dest Options extension header [...] > > ...if the addition of extension headers perturbs the the forwarding decision in some fashion (can't find the L4 header for example)... So... if adding a destination option header makes it impossible for interior routers to find the upper layer transport header in their hardware forwarding path... then what exactly is it we think we are doing here? I'm not being entirely facetious. -- james woodyatt core os networking From warren@kumari.net Mon Mar 18 11:54:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92C611E80A2 for ; Mon, 18 Mar 2013 11:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 t4IFzKMxt8ew for ; Mon, 18 Mar 2013 11:54:39 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id E632821F8D76 for ; Mon, 18 Mar 2013 11:54:38 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.106]) by vimes.kumari.net (Postfix) with ESMTPSA id 00F751B400F0; Mon, 18 Mar 2013 14:54:37 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <084D95C1-07ED-4C54-859D-9E974B12D715@apple.com> Date: Mon, 18 Mar 2013 14:54:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51475409.1010201@bogus.com> <084D95C1-07ED-4C54-859D-9E974B12D715@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1499) Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 18:54:49 -0000 On Mar 18, 2013, at 2:21 PM, james woodyatt wrote: > On Mar 18, 2013, at 10:51 , joel jaeggli wrote: >> On 3/18/13 10:31 AM, Nalini Elkins wrote >>> 2. Use IPv6 Dest Options extension header [...] >>=20 >> ...if the addition of extension headers perturbs the the forwarding = decision in some fashion (can't find the L4 header for example)... >=20 > So... if adding a destination option header makes it impossible for = interior routers to find the upper layer transport header in their = hardware forwarding path... then what exactly is it we think we are = doing here? Dunno what you are doing, but a number of folk are dropping the packet=85.= ;-) > I'm not being entirely facetious. Me neither - http://tools.ietf.org/html/draft-wkumari-long-headers-00 If a router cannot see the L4 header (because it is a fragment or = because the header is simply past the cell size), and you want to only = allow known traffic into your network, you have no real choice but to = assume it is bad and toss it... W >=20 >=20 > -- > james woodyatt > core os networking >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 -- I don't think the execution is relevant when it was obviously a bad idea = in the first place. This is like putting rabid weasels in your pants, and later expressing = regret at having chosen those particular rabid weasels and that pair of = pants.=20 ---maf Warren Kumari warren@kumari.net From touch@isi.edu Mon Mar 18 13:43:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA6D21F89A6 for ; Mon, 18 Mar 2013 13:43:51 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0KY8yGWjo41 for ; Mon, 18 Mar 2013 13:43:50 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6F92921F8901 for ; Mon, 18 Mar 2013 13:43:50 -0700 (PDT) Received: from [10.3.10.49] (206.111.226.201.ptr.us.xo.net [206.111.226.201]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r2IKgwnE027852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Mar 2013 13:43:07 -0700 (PDT) Message-ID: <51477C55.7030900@isi.edu> Date: Mon, 18 Mar 2013 13:43:01 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Templin, Fred L" References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <2134F8430051B64F815C691A62D9831802FB9D@XCH-BLV-504.nw.nos.boeing.com> <51431F7E.3090502@viagenie.ca> <51434F97.7080505@isi.edu> <51435158.1010006@viagenie.ca> <514360A2.2040800@isi.edu> <2134F8430051B64F815C691A62D983180319A7@XCH-BLV-504.nw.nos.boeing.com> <51473BC5.4020905@isi.edu> <2134F8430051B64F815C691A62D98318031A47@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D98318031A47@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 20:43:51 -0000 Hi, Fred, On 3/18/2013 9:22 AM, Templin, Fred L wrote: > Hi Joe, ... >>> True, the NAT should collect up all of the fragments of a fragmented >>> datagram before forwarding them. However, RFC1812 says: >>> >>> "A router MUST NOT reassemble any datagram before forwarding it." >> >> A NAT isn't a router. It acts like a host for the purposes of RFC1812, >> because it sources packets with its own IP address (to the public side), >> and acts as the sink of public addresses (to the private side). > > I had a feeling you would say that, but a NAT is really a > hybrid of sorts that exhibits some host functions and some > router functions. For the purpose of handling fragments, it > needs to behave as a router. Routers should NEVER aggregate the fragments before forwarding, nor should it expect to see the whole set of fragments. I agree that a NAT is a hybrid in some ways - e.g., it should decrement the hopcount - but regarding IDs, fragments, etc - it MUST behave as a host exactly because it either sources packets or acts as if it were the sink. >>> For that reason, NATs should do virtual fragment reassembly, i.e., >>> collect up the fragments but then forward them on without reassembly >>> once all fragments arrive. >> >> That may be a useful optimization, but its the same net effect. The only >> difference is whether the fragment boundaries are the same before/after >> the NAT, and that doesn't matter for the purposes of PMTUD, etc. > > It isn't an optimization; the NAT still has to dedicate reassembly > resources for all of the fragments even though it won't be reassembling. > Instead, it is the only correct behavior permissible by RFC1812. NATs should do reassembly, period. There's no reason to do anything else, and it is the only permissible behavior by RFC1122. This is governed by that RFC because the NAT is a source or (false) sink of the addresses. > It also does not have the same net effect. With *real* reassembly, > the destination sees only whole IP packets and has no notion that > the packets may have been fragmented at some earlier hop(s) of the > path from the source. With *virtual* reassembly, the destination > gets to see that the packets were fragmented. It cannot possibly matter. If you have the time to see all the fragments, you have time to reassemble - and refragment - them. Fragment boundaries are semantically meaningful - and should only be visible - to IP anyway. >>> This is important, because the source and destination may have some >>> sort of mutual understanding that packets will be sent and received >>> as multiple IP fragments. If the NAT steps into the middle and does >>> reassembly, then this understanding is violated. >> >> Source and dest exchange IP packets, not fragments. Any other >> understanding between the endpoints is already violated by the NAT >> process itself. > > I disagree. If the source has some reason to send the destination > fragmented packets, it should reasonably expect that they will > arrive at the destination as fragments and not as whole packets. > That is what virtual fragment reassembly is all about. They arrive at the destination IP layer as fragments, but at the next layer up as whole packets anyway. I don't see a good reason why fragment boundaries are sacrosanct but IP addresses and ports can be rewritten. Once you rewwrite, you act as a the source anyway, and all bets of what the orignal source intended are off. Joe From touch@isi.edu Mon Mar 18 13:52:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8035321F9138 for ; Mon, 18 Mar 2013 13:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ukcme50FlSpq for ; Mon, 18 Mar 2013 13:52:55 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 12DD521F90BB for ; Mon, 18 Mar 2013 13:52:55 -0700 (PDT) Received: from [75.209.55.18] (18.sub-75-209-55.myvzw.com [75.209.55.18]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r2IKnsgP028919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Mar 2013 13:50:03 -0700 (PDT) Message-ID: <51477DF4.9070304@isi.edu> Date: Mon, 18 Mar 2013 13:49:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Nalini Elkins References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> In-Reply-To: <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 20:52:56 -0000 I'm lost on one key point - why not use the packets themselves? Why focus on a single field? Regardless, it seems like your business model is based on assumptions that were never sound (assuming sequential IDs), have become even less sound (no ID in most IPv6 and even some IPv4), and are now approved as not sound (RFC 6864). Maybe it's time to change your assumptions ;-) Joe On 3/18/2013 10:31 AM, Nalini Elkins wrote: > Guys, > > Maybe it would be best to back up a bit, and start with what we want, > why we want it and what we know to be some of the problems. > > 1. There is a class of applications for which the time for > diagnostics, performance and ability to manage is critical. These may > be financial (as ours are) but they may also be 911 in a city > government, law enforcement, and others. > > 2. The platform may be IBM-mainframe based, Windows, Unix or cell phone. > > 3. Often problems are reported after the fact. As in, the Wire > Transfer from xxx organization was too slow or did not complete properly. > > 4. Again, often, packet traces are either available or are the easiest > way to diagnose such problems. Packet traces may be available because > all packets are sometimes stored for regulatory reasons (ex. all stock > trades must be saved, etc). Packet traces are often easiest because > the organization does not necessarily own all the equipment and middle > boxes or because a business partner is involved. An organization which > owns all the hardware can do diagnostics differently. I used to work > for such an organization and we would likely have stuck a hardware probe > on immediately. This is quite often not an option in many organizations. > > 5. In IPv4, one of the fields we used was the IP ID. Even though, this > field was meant for fragmentation, one of the properties it had (on many > platforms) was sequentiality. We used it as a de-facto packet sequence > number and also an eye catcher to know when the packet trace that we are > looking at is corrupted or has potential inaccuracies. What can happen > is that middle boxes can sometimes duplicate packets ONLY FOR SOME nodes > or when we extract packets from one of the devices which are > continuously capturing packets, the extract itself is wrong. This is > actually why hash of the packets will not work and why we need it for TCP. > > 6. Packet sequence number turns out to be quite an interesting and > useful number - with all the drawbacks it has of potential wrapping, > etc. Taken in conjunction with TTL and other fields, it can often > reduce problem diagnostic time considerably. Our motto is: do not let > the perfect be the enemy of the good. > > Now, because IP ID is not in the main IP header in IPv6 and may not be > available in IPv4, we are looking for a potential solution. We are not > going to deal with IPv4 - we will only move forward to IPv6. Let me > detail some of the known problems with solutions we have looked at: > > 1. Use IPv6 Fragment extension header with # of fragments set to 0 > (atomic fragments). The problem with this is that many firewalls (and > possibly other devices) drop these. You may be able to control this in > your network but cannot in other peoples. That is, business partners. > > 2. Use IPv6 Dest Options extension header: similar issues as above but > possibly even more as this may be even more unrecognized by middle > boxes. Also, I have been told that adding IPv6 extension headers will > make the routing of the packets through routers and middle boxes route > at a software rather than hardware layer, thus slowing the performance. > Guys, am I right? > > 3. So, now, we are trying to go back up the layers and consider the > SHIM possibility. That is, introduce a header that is between TCP and > UDP and the application. The idea of a SHIM was brought to us by Ron > Bonica (Ron, we owe you a beer in Berlin!). This seems attractive in > that only those applications which wish to employ this can do it. It > also I believe gets us away from the IP layer. It seems that changes > at the IP layer are quite problematic. > > 4. Then, we thought, if we are adding fields, something we would REALLY > like is a timestamp in every packet. So, we are considering designing > a PD-SHIM (Performance and Diagnostics SHIM) which will have a number of > these quite interesting fields. This is when we started looking at Fred > Templin's SEAL implementation. But, it we may need different fields. > > BTW, we are physically located in the Monterey and San Francisco Bay > areas. So, Joe, if you have time, we can certainly drive down to > Southern California and maybe we can chat for an hour or two. I will > contact you offline about that. > > Thanks, > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > ------------------------------------------------------------------------ > *From:* Joe Touch > *To:* Nalini Elkins > *Cc:* joel jaeggli ; IPv6 Ops WG > *Sent:* Thursday, March 14, 2013 3:38 PM > *Subject:* Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 > > Hi, all, > > SEAL wraps IP packets. If you put a shim above the transport layer > (between TCP/UDP and the app payload), then you might not get the > semantics you want. > > Wrapping UDP messages is fine - presuming you look at the wrapper only > at the endpoints; IP fragmentation may mean the wrapper isn't available > for some datagrams. > > Wrapping TCP segments is a bad idea IMO, and doesn't make sense. > > TCP segments exist only at the TCP layer, and those boundaries are > invisible to the application layer. The boundaries of what is written, > transmitted, received, and, read may differ (the middle two due to > rewriting proxies, which are evil but real). > > If you want/need a network identifier for diagnostics, it has to exist > at the network layer. > > NB - as we noted during the discussion of RFC6864, the IPv6 ID can exist > *either* when the source fragments *or* when a 6-to-4 translation is > required even for datagrams that otherwise fit in an IPv6 MTU. You might > update your intro accordingly: > > ...The IPv6 fragment > header is present only when a datagram has been fragmented, or when > the source has received a "packet too big" ICMPv6 error message > indicating that the path cannot support the required minimum > 1280-byte IPv6 MTU and is thus subject to translation [RFC2460] > [RFC4443]. The latter case is relevant only for IPv6 datagrams sent > to IPv4 destinations to support subsequent fragmentation after > translation to IPv4. > > Regarding this draft, it would be useful to explain why using the entire > packet (or a hash thereof) isn't nearly as useful in most cases (and > that would not require a new ID). > > Again, note that most IPv4 implementations do not implement the ID > uniqueness requirements in RFC791, and some use repeated IDs (even that > don't compress headers). > > Joe > > > > > On 3/14/2013 2:52 PM, Nalini Elkins wrote: > > Joel, > > > > Thanks so much for your feedback. One of the alternatives that we > are looking at to provide a Packet Sequence Number is a 'SHIM' such as > that provided by SEAL. > > > > http://tools.ietf.org/html//rfc5320 > > > > This header (if I am reading this correctly!) would be between the > TCP or UDP header and the application payload. > > > > One of the things that SEAL provides is: > > > > SEAL_ID - a 32-bit Identification value, randomly initialized and > monotonically incremented for each SEAL protocol packet > > > > So, this might provide exactly what we are looking for! > > > > We do understand that there are a number of issues with IPv6 > extension headers. We are not wedded to a particular implementation and > whatever will provide the information we need is perfect! But, we have > just found out about this RFC and need to study it more to see if there > are any drawbacks. > > > > Thanks, > > > > Nalini Elkins > > Inside Products, Inc. > > (831) 659-8360 > > www.insidethestack.com > > > > > > > > ________________________________ > > From: joel jaeggli > > > To: IPv6 Ops WG > > > Sent: Thursday, March 14, 2013 8:13 AM > > Subject: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 > > > > some more thoughts since the presentation. > > > > Noted that I consulted the earlier draft, discussion in 6-man and > appendix a in the slides. > > > > http://tools.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header-00 > > > > was the previous one. > > > > The request is not really for the ipv4 IPID/frag header in v6. it's > for a unique per packet value over a given sample interval. > > > > The utility of ipid in ipv4 for this context has eroded over time, > (this is not knock againt the draft I'm just trying to describe my > understanding of the utility). IPID's in the context of mobile > phones/mobile networks are typically unvarrying (due to header > compresssion). rfc 6864 exists because modern implmentations cannot (and > therefore don't) honor requirements for uniqueness in rfc791,rfc1122 > e.g. the duration over which 16 bit IPID is valid for uniqueness is > bounded by the size of the flow because if it were limited by the MDL it > would limit that speed of a flow. a 10Gb/s flow with 1500 byte packets > overflows a 16 bit value every 78 or so ms. if your capture is longer > than that you can reasonably expect duplicate IPIDS to show up which are > readily identifiable as not being duplicate packets. > > > > desirable properties of a unique per packet value to my mind... > > > > * That it doesn't cost us anything - it strikes me as undesirable > that packets should in general have larger headers then they do today > that adds cost all over the place. extension header processing or indeed > fragmentation header use has conquences. > > > > see http://tools.ietf.org/html/draft-wkumari-long-headers-00 > > > > for dicussion that has come up about header processing in modern routers. > > > > and > > > > http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00 > > > > for a similar discussion about fragmentation headers. > > > > neither of these represent any form of consensus document, so take > that with a grain of salt. > > > > * That it is applied to every packet - part of the stated utility of > the ipv4 ipid is that it's present (with my noted caveats) you don't > have to turn it on. likewise this implies that the application of the > value does not impact the observation, having the packet size change > because you're doing debugging means imho that you're not doing the > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > From Fred.L.Templin@boeing.com Mon Mar 18 14:04:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B4021F8F8A for ; Mon, 18 Mar 2013 14:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 efepC9aMSR-I for ; Mon, 18 Mar 2013 14:04:55 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id C274D21F8F69 for ; Mon, 18 Mar 2013 14:04:55 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r2IL4tcn002206 for ; Mon, 18 Mar 2013 16:04:55 -0500 Received: from XCH-PHX-312.sw.nos.boeing.com (xch-phx-312.sw.nos.boeing.com [130.247.25.173]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r2IL4rKV002183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 18 Mar 2013 16:04:54 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.214]) by XCH-PHX-312.sw.nos.boeing.com ([169.254.12.243]) with mapi id 14.02.0328.011; Mon, 18 Mar 2013 14:04:53 -0700 From: "Templin, Fred L" To: Joe Touch Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Thread-Index: AQHOJBkupovTMHVwr0KJKw2dWHfftZir6zAg Date: Mon, 18 Mar 2013 21:04:52 +0000 Message-ID: <2134F8430051B64F815C691A62D98318031F85@XCH-BLV-504.nw.nos.boeing.com> References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <2134F8430051B64F815C691A62D9831802FB9D@XCH-BLV-504.nw.nos.boeing.com> <51431F7E.3090502@viagenie.ca> <51434F97.7080505@isi.edu> <51435158.1010006@viagenie.ca> <514360A2.2040800@isi.edu> <2134F8430051B64F815C691A62D983180319A7@XCH-BLV-504.nw.nos.boeing.com> <51473BC5.4020905@isi.edu> <2134F8430051B64F815C691A62D98318031A47@XCH-BLV-504.nw.nos.boeing.com> <51477C55.7030900@isi.edu> In-Reply-To: <51477C55.7030900@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 21:04:56 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Monday, March 18, 2013 1:43 PM > To: Templin, Fred L > Cc: Simon Perreault; v6ops@ietf.org > Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 >=20 > Hi, Fred, >=20 > On 3/18/2013 9:22 AM, Templin, Fred L wrote: > > Hi Joe, > ... > >>> True, the NAT should collect up all of the fragments of a fragmented > >>> datagram before forwarding them. However, RFC1812 says: > >>> > >>> "A router MUST NOT reassemble any datagram before forwarding it.= " > >> > >> A NAT isn't a router. It acts like a host for the purposes of RFC1812, > >> because it sources packets with its own IP address (to the public > side), > >> and acts as the sink of public addresses (to the private side). > > > > I had a feeling you would say that, but a NAT is really a > > hybrid of sorts that exhibits some host functions and some > > router functions. For the purpose of handling fragments, it > > needs to behave as a router. >=20 > Routers should NEVER aggregate the fragments before forwarding, nor > should it expect to see the whole set of fragments. >=20 > I agree that a NAT is a hybrid in some ways - e.g., it should decrement > the hopcount - but regarding IDs, fragments, etc - it MUST behave as a > host exactly because it either sources packets or acts as if it were the > sink. I think host vs router wrt to reassembly may be a matter of opinion and it sounds like our opinions differ. Be that as it may, there are certainly implementations of virtual fragment reassembly out there but I don't know how widely deployed they are nor whether they are on-by-default. Do you know what is the state of affairs for widely deployed NATs? The three options seem to be 1) real reassembly, 2) virtual reassembly, 3) no reassembly. =20 > >>> For that reason, NATs should do virtual fragment reassembly, i.e., > >>> collect up the fragments but then forward them on without reassembly > >>> once all fragments arrive. > >> > >> That may be a useful optimization, but its the same net effect. The > only > >> difference is whether the fragment boundaries are the same before/afte= r > >> the NAT, and that doesn't matter for the purposes of PMTUD, etc. > > > > It isn't an optimization; the NAT still has to dedicate reassembly > > resources for all of the fragments even though it won't be reassembling= . > > Instead, it is the only correct behavior permissible by RFC1812. >=20 > NATs should do reassembly, period. There's no reason to do anything > else, and it is the only permissible behavior by RFC1122. This is > governed by that RFC because the NAT is a source or (false) sink of the > addresses. The NAT is also forwarding packets that weren't explicitly addressed to itself, which would say that the normative reference is RFC1812. And, RFC1812 says that a router is not permitted to reassemble packets not addressed to itself. =20 > > It also does not have the same net effect. With *real* reassembly, > > the destination sees only whole IP packets and has no notion that > > the packets may have been fragmented at some earlier hop(s) of the > > path from the source. With *virtual* reassembly, the destination > > gets to see that the packets were fragmented. >=20 > It cannot possibly matter. If you have the time to see all the > fragments, you have time to reassemble - and refragment - them. Yes, it can matter. If the final destination is monitoring its reassembly cache to see if any packets are arriving fragmented then it matters. > Fragment boundaries are semantically meaningful - and should only be > visible - to IP anyway. >=20 > >>> This is important, because the source and destination may have some > >>> sort of mutual understanding that packets will be sent and received > >>> as multiple IP fragments. If the NAT steps into the middle and does > >>> reassembly, then this understanding is violated. > >> > >> Source and dest exchange IP packets, not fragments. Any other > >> understanding between the endpoints is already violated by the NAT > >> process itself. > > > > I disagree. If the source has some reason to send the destination > > fragmented packets, it should reasonably expect that they will > > arrive at the destination as fragments and not as whole packets. > > That is what virtual fragment reassembly is all about. >=20 > They arrive at the destination IP layer as fragments, but at the next > layer up as whole packets anyway. I don't see a good reason why fragment > boundaries are sacrosanct but IP addresses and ports can be rewritten. > Once you rewwrite, you act as a the source anyway, and all bets of what > the orignal source intended are off. The destination may need to know that fragmentation is occurring in the network so that it can inform the source to start sending smaller packets. You know - as in SEAL. Thanks - Fred fred.l.templin@boeing.com > Joe From mackermann@bcbsm.com Mon Mar 18 14:37:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C5B21F8D63 for ; Mon, 18 Mar 2013 14:37:48 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xHywNvmVceC for ; Mon, 18 Mar 2013 14:37:47 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.zixworks.com [63.71.11.123]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD8321F8C97 for ; Mon, 18 Mar 2013 14:37:45 -0700 (PDT) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id ACDDE17E4B5 for ; Mon, 18 Mar 2013 16:37:44 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 7979617E495; Mon, 18 Mar 2013 16:37:43 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 2FD652F0045; Mon, 18 Mar 2013 17:36:29 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva2.bcbsm.com (Postfix) with ESMTP id 207B72F0043; Mon, 18 Mar 2013 17:36:29 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA100.ent.corp.bcbsm.com ([fe80::8db:9ce7:e2cf:8565%14]) with mapi id 14.01.0355.002; Mon, 18 Mar 2013 17:37:43 -0400 From: "Ackermann, Michael" To: Joe Touch , Nalini Elkins Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Thread-Index: AQHOIMaVqC5M9XVYp0uFMLNLdFX3pZil/fsAgAW9XMeAAHp1AP//xeIw Date: Mon, 18 Mar 2013 21:37:41 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> In-Reply-To: <51477DF4.9070304@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 21:37:48 -0000 Since beginning to explore this issue of IPID, it has become clear how = valuable IPID has been to our organization and many like us. I have = personally not talked with everyone about this, but to those I have, the = preponderance would not like to see this beneficial diagnostic feature = lost. =20 As a result, most of us do not view this as an assumption, but as a = reality experienced for many years now and one we would like to continue = to benefit from, I recognize that this reality is in conflict with the = original intent of this field, but at a certain point isn't proven field = value of equal or greater significance that original intent? =20 Having said that I know how challenging this will be, but I continue to = hope we can find the optimal solution that provides and works for all. =20 As far as using the packet itself, it would still need a way to uniquely = identify it and make it's relative or absolute order in a sequence clear, = to facilitate related diagnostics. This could be done with add on = software or techniques, which may be great for vendors or software = developers, but as a lowly (and poor) end user, I would very much like to = see this capability inherent in the protocol as it is today in IPV4. =20 Thanks, Mike -----Original Message----- From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Joe Touch Sent: Monday, March 18, 2013 4:50 PM To: Nalini Elkins Cc: IPv6 Ops WG Subject: Re: =5Bv6ops=5D draft-elkins-v6ops-ipv6-ipid-needed-00 I'm lost on one key point - why not use the packets themselves? Why focus = on a single field? Regardless, it seems like your business model is based on assumptions that = were never sound (assuming sequential IDs), have become even less sound = (no ID in most IPv6 and even some IPv4), and are now approved as not sound = (RFC 6864). Maybe it's time to change your assumptions ;-) Joe On 3/18/2013 10:31 AM, Nalini Elkins wrote: > Guys, > > Maybe it would be best to back up a bit, and start with what we want,=20 > why we want it and what we know to be some of the problems. > > 1. There is a class of applications for which the time for > diagnostics, performance and ability to manage is critical. These=20 > may be financial (as ours are) but they may also be 911 in a city=20 > government, law enforcement, and others. > > 2. The platform may be IBM-mainframe based, Windows, Unix or cell phone. > > 3. Often problems are reported after the fact. As in, the Wire > Transfer from xxx organization was too slow or did not complete properly. > > 4. Again, often, packet traces are either available or are the easiest > way to diagnose such problems. Packet traces may be available because=20 > all packets are sometimes stored for regulatory reasons (ex. all stock > trades must be saved, etc). Packet traces are often easiest because > the organization does not necessarily own all the equipment and middle > boxes or because a business partner is involved. An organization which > owns all the hardware can do diagnostics differently. I used to work=20 > for such an organization and we would likely have stuck a hardware=20 > probe on immediately. This is quite often not an option in many = organizations. > > 5. In IPv4, one of the fields we used was the IP ID. Even though,=20 > this field was meant for fragmentation, one of the properties it had (on = many > platforms) was sequentiality. We used it as a de-facto packet sequence > number and also an eye catcher to know when the packet trace that we are > looking at is corrupted or has potential inaccuracies. What can happen > is that middle boxes can sometimes duplicate packets ONLY FOR SOME=20 > nodes or when we extract packets from one of the devices which are > continuously capturing packets, the extract itself is wrong. This is > actually why hash of the packets will not work and why we need it for TCP. > > 6. Packet sequence number turns out to be quite an interesting and=20 > useful number - with all the drawbacks it has of potential wrapping, > etc. Taken in conjunction with TTL and other fields, it can often > reduce problem diagnostic time considerably. Our motto is: do not let > the perfect be the enemy of the good. > > Now, because IP ID is not in the main IP header in IPv6 and may not be=20 > available in IPv4, we are looking for a potential solution. We are=20 > not going to deal with IPv4 - we will only move forward to IPv6. Let=20 > me detail some of the known problems with solutions we have looked at: > > 1. Use IPv6 Fragment extension header with =23 of fragments set to 0 > (atomic fragments). The problem with this is that many firewalls (and > possibly other devices) drop these. You may be able to control this in > your network but cannot in other peoples. That is, business partners. > > 2. Use IPv6 Dest Options extension header: similar issues as above=20 > but possibly even more as this may be even more unrecognized by middle=20 > boxes. Also, I have been told that adding IPv6 extension headers will=20 > make the routing of the packets through routers and middle boxes route=20 > at a software rather than hardware layer, thus slowing the performance. > Guys, am I right? > > 3. So, now, we are trying to go back up the layers and consider the=20 > SHIM possibility. That is, introduce a header that is between TCP and=20 > UDP and the application. The idea of a SHIM was brought to us by Ron > Bonica (Ron, we owe you a beer in Berlin=21). This seems attractive in > that only those applications which wish to employ this can do it. It > also I believe gets us away from the IP layer. It seems that changes > at the IP layer are quite problematic. > > 4. Then, we thought, if we are adding fields, something we would REALLY > like is a timestamp in every packet. So, we are considering designing > a PD-SHIM (Performance and Diagnostics SHIM) which will have a number=20 > of these quite interesting fields. This is when we started looking at=20 > Fred Templin's SEAL implementation. But, it we may need different fields. > > BTW, we are physically located in the Monterey and San Francisco Bay=20 > areas. So, Joe, if you have time, we can certainly drive down to=20 > Southern California and maybe we can chat for an hour or two. I will=20 > contact you offline about that. > > Thanks, > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > ---------------------------------------------------------------------- > -- > *From:* Joe Touch > *To:* Nalini Elkins > *Cc:* joel jaeggli ; IPv6 Ops WG > *Sent:* Thursday, March 14, 2013 3:38 PM > *Subject:* Re: =5Bv6ops=5D draft-elkins-v6ops-ipv6-ipid-needed-00 > > Hi, all, > > SEAL wraps IP packets. If you put a shim above the transport layer=20 > (between TCP/UDP and the app payload), then you might not get the=20 > semantics you want. > > Wrapping UDP messages is fine - presuming you look at the wrapper only=20 > at the endpoints; IP fragmentation may mean the wrapper isn't=20 > available for some datagrams. > > Wrapping TCP segments is a bad idea IMO, and doesn't make sense. > > TCP segments exist only at the TCP layer, and those boundaries are=20 > invisible to the application layer. The boundaries of what is written,=20 > transmitted, received, and, read may differ (the middle two due to=20 > rewriting proxies, which are evil but real). > > If you want/need a network identifier for diagnostics, it has to exist=20 > at the network layer. > > NB - as we noted during the discussion of RFC6864, the IPv6 ID can=20 > exist > *either* when the source fragments *or* when a 6-to-4 translation is=20 > required even for datagrams that otherwise fit in an IPv6 MTU. You=20 > might update your intro accordingly: > > ...The IPv6 fragment > header is present only when a datagram has been fragmented, or when > the source has received a =22packet too big=22 ICMPv6 error message > indicating that the path cannot support the required minimum > 1280-byte IPv6 MTU and is thus subject to translation =5BRFC2460=5D > =5BRFC4443=5D. The latter case is relevant only for IPv6 datagrams = sent > to IPv4 destinations to support subsequent fragmentation after > translation to IPv4. > > Regarding this draft, it would be useful to explain why using the=20 > entire packet (or a hash thereof) isn't nearly as useful in most cases=20 > (and that would not require a new ID). > > Again, note that most IPv4 implementations do not implement the ID=20 > uniqueness requirements in RFC791, and some use repeated IDs (even=20 > that don't compress headers). > > Joe > > > > > On 3/14/2013 2:52 PM, Nalini Elkins wrote: > > Joel, > > > > Thanks so much for your feedback. One of the alternatives that we=20 > are looking at to provide a Packet Sequence Number is a 'SHIM' such as=20 > that provided by SEAL. > > > > http://tools.ietf.org/html//rfc5320 > > > > This header (if I am reading this correctly=21) would be between the=20 > TCP or UDP header and the application payload. > > > > One of the things that SEAL provides is: > > > > SEAL_ID - a 32-bit Identification value, randomly initialized and=20 > monotonically incremented for each SEAL protocol packet > > So, this=20 > might provide exactly what we are looking for=21 > > > > We do understand that there are a number of issues with IPv6=20 > extension headers. We are not wedded to a particular implementation=20 > and whatever will provide the information we need is perfect=21 But, = we=20 > have just found out about this RFC and need to study it more to see if=20 > there are any drawbacks. > > > > Thanks, > > > > Nalini Elkins > > Inside Products, Inc. > > (831) 659-8360 > > www.insidethestack.com > > > >=20 > ________________________________ > From: joel jaeggli=20 > > > To: IPv6 Ops WG=20 > > > Sent: Thursday, March = 14,=20 > 2013 8:13 AM > Subject: =5Bv6ops=5D=20 > draft-elkins-v6ops-ipv6-ipid-needed-00 > > > > some more thoughts since the presentation. > > > > Noted that I consulted the earlier draft, discussion in 6-man and=20 > appendix a in the slides. > > > >=20 > http://tools.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header-00 > > > > was the previous one. > > > > The request is not really for the ipv4 IPID/frag header in v6. it's=20 > for a unique per packet value over a given sample interval. > > > > The utility of ipid in ipv4 for this context has eroded over time,=20 > (this is not knock againt the draft I'm just trying to describe my=20 > understanding of the utility). IPID's in the context of mobile=20 > phones/mobile networks are typically unvarrying (due to header=20 > compresssion). rfc 6864 exists because modern implmentations cannot=20 > (and therefore don't) honor requirements for uniqueness in=20 > rfc791,rfc1122 e.g. the duration over which 16 bit IPID is valid for=20 > uniqueness is bounded by the size of the flow because if it were=20 > limited by the MDL it would limit that speed of a flow. a 10Gb/s flow=20 > with 1500 byte packets overflows a 16 bit value every 78 or so ms. if=20 > your capture is longer than that you can reasonably expect duplicate=20 > IPIDS to show up which are readily identifiable as not being duplicate = packets. > > > > desirable properties of a unique per packet value to my mind... > > > > * That it doesn't cost us anything - it strikes me as undesirable=20 > that packets should in general have larger headers then they do today=20 > that adds cost all over the place. extension header processing or=20 > indeed fragmentation header use has conquences. > > > > see http://tools.ietf.org/html/draft-wkumari-long-headers-00 > > > > for dicussion that has come up about header processing in modern = routers. > > > > and > > > > http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00 > > > > for a similar discussion about fragmentation headers. > > > > neither of these represent any form of consensus document, so take=20 > that with a grain of salt. > > > > * That it is applied to every packet - part of the stated utility=20 > of the ipv4 ipid is that it's present (with my noted caveats) you=20 > don't have to turn it on. likewise this implies that the application=20 > of the value does not impact the observation, having the packet size=20 > change because you're doing debugging means imho that you're not doing=20 > the > _______________________________________________ > > v6ops mailing list > > v6ops=40ietf.org >=20 > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > > v6ops mailing list > > v6ops=40ietf.org >=20 > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From nick@inex.ie Mon Mar 18 14:56:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83C321F8A54 for ; Mon, 18 Mar 2013 14:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcOMe+wCZalI for ; Mon, 18 Mar 2013 14:56:27 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 04DD021F8A53 for ; Mon, 18 Mar 2013 14:56:26 -0700 (PDT) X-Envelope-To: Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.4/8.14.5) with ESMTP id r2ILrEkm059491 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 18 Mar 2013 21:53:14 GMT (envelope-from nick@inex.ie) Message-ID: <51478D86.2090008@inex.ie> Date: Mon, 18 Mar 2013 21:56:22 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> X-Enigmail-Version: 1.5.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 21:56:27 -0000 On 18/03/2013 21:37, Ackermann, Michael wrote: > Since beginning to explore this issue of IPID, it has become clear how > valuable IPID has been to our organization and many like us. I have > personally not talked with everyone about this, but to those I have, the > preponderance would not like to see this beneficial diagnostic feature > lost. Mike, Nalini, I understand that using IPID works for you when diagnosing connectivity problems in ipv4. Do you understand that ipv6 extension headers cause massive operational headaches which we cannot get around using today's technology? And that as a working group, the operational people here are baulking at the idea of creating more extension headers because it makes our lives massively more difficult? If everyone doesn't understand each others' points of view, this conversation is going to continue running around in circles, causing nothing but frustration. Nick From nalini.elkins@insidethestack.com Mon Mar 18 15:39:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C33E21F8A52 for ; Mon, 18 Mar 2013 15:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] 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 ejU8BNSoqsLj for ; Mon, 18 Mar 2013 15:39:37 -0700 (PDT) Received: from nm27-vm0.access.bullet.mail.mud.yahoo.com (nm27-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.227]) by ietfa.amsl.com (Postfix) with ESMTP id 1067D21F8A3F for ; Mon, 18 Mar 2013 15:39:36 -0700 (PDT) Received: from [66.94.237.201] by nm27.access.bullet.mail.mud.yahoo.com with NNFMP; 18 Mar 2013 22:39:36 -0000 Received: from [66.94.237.117] by tm12.access.bullet.mail.mud.yahoo.com with NNFMP; 18 Mar 2013 22:39:36 -0000 Received: from [127.0.0.1] by omp1022.access.mail.mud.yahoo.com with NNFMP; 18 Mar 2013 22:39:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 636436.91235.bm@omp1022.access.mail.mud.yahoo.com Received: (qmail 64962 invoked by uid 60001); 18 Mar 2013 22:39:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1363646376; bh=YwFVEqJRgJoLYEs//vCdD8AkLFI73Bd4mqX+8dS74Eo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=upsUOUO656KERqdjZ3K9AinOjNbvuTyOAkxtw5znXeQHkIvLZfqjLXX0BXNuA/0whgWQBYboKLsMvAhxTQxVr85I3+lnMUuLDiR4CQ/how3b6XNCd+LMRwghlv5rtVbK5CYk5Sul4t35Me3kk5wdUiJfXs4cLGnXMD9x1fvQSY0= X-YMail-OSG: dAe8hZAVM1l0XpA.PqXHDjAbUVOmeuaIEYjyAcWm4r2kHte .F97FHTgn3s3e0azyAREp1XNg9PMiK_0tYpS_6ugN0XRS7szilIF0hHneQJ0 Ehugl20rpLgr1MX8Rn_lIReguVVu.RSfkSafb_yncmk5ImFHHPRStb3_aZvD Y.v06oWNGFEBWy1kptmqXzMQVaK.yX.p_w9prykP0j4wH.NaYT45.GeQ5NYh 4gH1CtZrN9JGgt0I9xGbxWb1rprucyum8cgM2gAJemoxl8dzXhMFCqGFtsVe E8CWrKE04rIP2uCESBkCRPHlrHwAHWbqOvNVvLrY6LtrElnmSLbcJ4u49B0a MrQPrKWde6l0HiB75zYHdco5_GKizjVfDn3vxFwYK6AKpwQ6dkk5mR3npmNg SK1UcArnTPpRdvPAuPC7mFkraZV3tDXrrzowc3f.nZCWEMFPUysG7aACz9kD qxcRSahiRE9FJ6JgO._UpIT_3i9zDSmBej1ATHRBLdHyolLo8ioDSakRJ1PR nEc.LC8u8X1DSL82JAQpMt_riCPxUWwDSavn9hT4BNYxA8Tzmsvdj00goCIY rmWv4oC25_2QQB_VPfAEsknqKl7FgaKRe7daRQnjOWZ52 Received: from [24.130.37.147] by web2805.biz.mail.ne1.yahoo.com via HTTP; Mon, 18 Mar 2013 15:39:36 PDT X-Rocket-MIMEInfo: 002.001, TmljaywKClRvdGFsbHkgYWdyZWUgd2l0aCB5b3UgYWJvdXQgdHJ5aW5nIHRvIHVuZGVyc3RhbmQgZWFjaCBvdGhlcidzIHBvaW50IG9mIHZpZXcuIMKgIFdlIGFic29sdXRlbHkgd2FudCB0byBkbyB0aGF0LiDCoCBJIHRoaW5rIE1pa2Ugd2FzIHJlc3BvbmRpbmcgdG8gdGhlIGNvbW1lbnQgb24gdGhlIG5lZWQgZm9yIElQSUQgaXRzZWxmLgoKQXMgZmFyIGFzIGEgc29sdXRpb24swqB3ZSBhcmUgdGhpbmtpbmcgdGhhdCBJUHY2IGV4dGVuc2lvbiBoZWFkZXJzIGFyZSBhIG5vbi1zdGFydGVyLiDCoEZvciBhbGwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.138.524 References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> Message-ID: <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Mon, 18 Mar 2013 15:39:36 -0700 (PDT) From: Nalini Elkins To: Nick Hilliard , "v6ops@ietf.org" In-Reply-To: <51478D86.2090008@inex.ie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1619178251-1123217515-1363646376=:64760" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 22:39:38 -0000 --1619178251-1123217515-1363646376=:64760 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Nick,=0A=0ATotally agree with you about trying to understand each other's p= oint of view. =A0 We absolutely want to do that. =A0 I think Mike was respo= nding to the comment on the need for IPID itself.=0A=0AAs far as a solution= ,=A0we are thinking that IPv6 extension headers are a non-starter. =A0For a= ll the reasons that have been brought up.=0A=0ASo,=A0we are thinking of a h= eader higher up the layers. =A0 For example, between the Transport Layer (T= CP / UDP) and the application payload.=0A=0AWhat are opinions from people o= n that?=0A=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Products, Inc.=0A= (831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A________________________= ________=0A From: Nick Hilliard =0ATo: v6ops@ietf.org =0ASent= : Monday, March 18, 2013 2:56 PM=0ASubject: Re: [v6ops] draft-elkins-v6ops-= ipv6-ipid-needed-00=0A =0AOn 18/03/2013 21:37, Ackermann, Michael wrote:=0A= > Since beginning to explore this issue of IPID, it has become clear how=0A= > valuable IPID has been to our organization and many like us.=A0 =A0 I hav= e=0A> personally not talked with everyone about this, but to those I have, = the=0A> preponderance would not like to see this beneficial diagnostic feat= ure=0A> lost.=0A=0AMike, Nalini,=0A=0AI understand that using IPID works fo= r you when diagnosing connectivity=0Aproblems in ipv4.=A0 Do you understand= that ipv6 extension headers cause=0Amassive operational headaches which we= cannot get around using today's=0Atechnology?=A0 And that as a working gro= up, the operational people here are=0Abaulking at the idea of creating more= extension headers because it makes=0Aour lives massively more difficult?= =0A=0AIf everyone doesn't understand each others' points of view, this=0Aco= nversation is going to continue running around in circles, causing=0Anothin= g but frustration.=0A=0ANick=0A=0A_________________________________________= ______=0Av6ops mailing list=0Av6ops@ietf.org=0Ahttps://www.ietf.org/mailman= /listinfo/v6ops --1619178251-1123217515-1363646376=:64760 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Nick,
=
Totally agree with you about trying to understand each = other's point of view.   We absolutely want to do that.   I think= Mike was responding to the comment on the need for IPID itself.
<= span>
As far as a solution, we are thinking that IPv6 extension hea= ders are a non-starter.  For all the reasons that have been brought up= .

So, we are thinking of a header higher up the layers. =   For example, between the Transport Layer (TCP / UDP) and the applica= tion payload.

What are opinions from people on that?

=  
Thanks,

Nalini Elkins
Inside Products= , Inc.
(831) 659-8360
www.insidethestack.com

From: Nick Hilliard <nick@ine= x.ie>
To: v6ops@iet= f.org
Sent: Monday, March 18, 2= 013 2:56 PM
Subject: R= e: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

= =0AOn 18/03/2013 21:37, Ackermann, Michael wrote:
> Since beginning t= o explore this issue of IPID, it has become clear how
> valuable IPID= has been to our organization and many like us.    I have
>= personally not talked with everyone about this, but to those I have, the> preponderance would not like to see this beneficial diagnostic featu= re
> lost.

Mike, Nalini,

I understand that using IPID w= orks for you when diagnosing connectivity
problems in ipv4.  Do you= understand that ipv6 extension headers cause
massive operational headac= hes which we cannot get around using today's
technology?  And that = as a working group, the operational people here are
baulking at the idea= of creating more extension headers because it makes
our lives massively= more difficult?

If everyone doesn't understand each others' points = of view, this
conversation is going to continue running around in circles, causing
nothing but frustration.

Nick

__________= _____________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


--1619178251-1123217515-1363646376=:64760-- From Fred.L.Templin@boeing.com Mon Mar 18 15:53:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF01021F8BED for ; Mon, 18 Mar 2013 15:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] 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 TXf5Oq9PSSiu for ; Mon, 18 Mar 2013 15:53:11 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id AC22921F8B64 for ; Mon, 18 Mar 2013 15:53:08 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r2IMr8Pl008575 for ; Mon, 18 Mar 2013 15:53:08 -0700 Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r2IMr7eK008569 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 18 Mar 2013 15:53:07 -0700 Received: from XCH-PHX-412.sw.nos.boeing.com (10.57.37.44) by XCH-NWHT-09.nw.nos.boeing.com (130.247.25.115) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 18 Mar 2013 15:53:06 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.214]) by XCH-PHX-412.sw.nos.boeing.com ([169.254.12.141]) with mapi id 14.02.0328.011; Mon, 18 Mar 2013 15:53:06 -0700 From: "Templin, Fred L" To: Nalini Elkins , Nick Hilliard , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Thread-Index: AQHOJCl3povTMHVwr0KJKw2dWHfftZisDIdA Date: Mon, 18 Mar 2013 22:53:05 +0000 Message-ID: <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> In-Reply-To: <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D983180320FFXCHBLV504nwnosboe_" MIME-Version: 1.0 X-TM-AS-MML: No Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 22:53:14 -0000 --_000_2134F8430051B64F815C691A62D983180320FFXCHBLV504nwnosboe_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nalini, For a shim header between the transport and the application data, TCP provi= des TCP options so you could consider a new TCP option. But, TCP already includ= es sequence numbers that can be used for diagnostic purposes - in fact, Wiresh= ark (and I'm sure other network diagnostic tools) already use that. So, I don't= see a shim as a big win for TCP. For UDP, there would need to be a new UDP port number assignment, and a new piece of code at both the source and destination. The source would have to insert the shim about the UDP header, and the destination would have to remove it. That is the same model that SEAL is addressing, but SEAL is expe= cting both ends to implement the protocol. So, unfortunately, there is no way to have a source-only patch that does not also require a patch at the destinat= ion. Thanks - Fred From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of N= alini Elkins Sent: Monday, March 18, 2013 3:40 PM To: Nick Hilliard; v6ops@ietf.org Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Nick, Totally agree with you about trying to understand each other's point of vie= w. We absolutely want to do that. I think Mike was responding to the co= mment on the need for IPID itself. As far as a solution, we are thinking that IPv6 extension headers are a non= -starter. For all the reasons that have been brought up. So, we are thinking of a header higher up the layers. For example, betwee= n the Transport Layer (TCP / UDP) and the application payload. What are opinions from people on that? Thanks, Nalini Elkins Inside Products, Inc. (831) 659-8360 www.insidethestack.com ________________________________ From: Nick Hilliard > To: v6ops@ietf.org Sent: Monday, March 18, 2013 2:56 PM Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 On 18/03/2013 21:37, Ackermann, Michael wrote: > Since beginning to explore this issue of IPID, it has become clear how > valuable IPID has been to our organization and many like us. I have > personally not talked with everyone about this, but to those I have, the > preponderance would not like to see this beneficial diagnostic feature > lost. Mike, Nalini, I understand that using IPID works for you when diagnosing connectivity problems in ipv4. Do you understand that ipv6 extension headers cause massive operational headaches which we cannot get around using today's technology? And that as a working group, the operational people here are baulking at the idea of creating more extension headers because it makes our lives massively more difficult? If everyone doesn't understand each others' points of view, this conversation is going to continue running around in circles, causing nothing but frustration. Nick _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_2134F8430051B64F815C691A62D983180320FFXCHBLV504nwnosboe_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Nalini,

 <= /p>

For a shim header between= the transport and the application data, TCP provides

TCP options so you could = consider a new TCP option. But, TCP already includes

sequence numbers that can= be used for diagnostic purposes – in fact, Wireshark

(and I’m sure other= network diagnostic tools) already use that. So, I don’t see

a shim as a big win for T= CP.

 <= /p>

For UDP, there would need= to be a new UDP port number assignment, and a

new piece of code at both= the source and destination. The source would have

to insert the shim about = the UDP header, and the destination would have to

remove it. That is the sa= me model that SEAL is addressing, but SEAL is expecting

both ends to implement th= e protocol. So, unfortunately, there is no way to

have a source-only patch = that does not also require a patch at the destination.

 <= /p>

Thanks - Fred<= /span>

 <= /p>

 <= /p>

From: v6ops-bo= unces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Nalini Elkins
Sent: Monday, March 18, 2013 3:40 PM
To: Nick Hilliard; v6ops@ietf.org
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

 

Ni= ck,

 

Totally agree with you about = trying to understand each other's point of view.   We absolutely want = to do that.   I think Mike was responding to the comment on the need for IPID itself.

 

As far as a solution, we= are thinking that IPv6 extension headers are a non-starter.  For all = the reasons that have been brought up.

 

So, we are thinking of a= header higher up the layers.   For example, between the Transport Lay= er (TCP / UDP) and the application payload.

 

What are opinions from people= on that?

 

&n= bsp;

Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

From: Nick Hilliard <nick@inex.ie>
To: v6ops@ietf.org
Sent: Monday, March 18, 2013 2:56 PM
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00


On 18/03/2013 21:37, Ackermann, Michael wrote:
> Since beginning to explore this issue of IPID, it has become clear how=
> valuable IPID has been to our organization and many like us.  &nb= sp; I have
> personally not talked with everyone about this, but to those I have, t= he
> preponderance would not like to see this beneficial diagnostic feature=
> lost.

Mike, Nalini,

I understand that using IPID works for you when diagnosing connectivity
problems in ipv4.  Do you understand that ipv6 extension headers cause=
massive operational headaches which we cannot get around using today's
technology?  And that as a working group, the operational people here = are
baulking at the idea of creating more extension headers because it makes our lives massively more difficult?

If everyone doesn't understand each others' points of view, this
conversation is going to continue running around in circles, causing
nothing but frustration.

Nick

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

--_000_2134F8430051B64F815C691A62D983180320FFXCHBLV504nwnosboe_-- From mackermann@bcbsm.com Mon Mar 18 15:54:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E4121F89A5 for ; Mon, 18 Mar 2013 15:54:22 -0700 (PDT) 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_13=0.6, 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 shmrSnlxb4dk for ; Mon, 18 Mar 2013 15:54:22 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.zixworks.com [63.71.11.123]) by ietfa.amsl.com (Postfix) with ESMTP id DE6AC21F88A1 for ; Mon, 18 Mar 2013 15:54:21 -0700 (PDT) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 7E179136E73 for ; Mon, 18 Mar 2013 17:54:21 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id A1C1D136D1C; Mon, 18 Mar 2013 17:54:20 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 0F6174F804D; Mon, 18 Mar 2013 18:53:07 -0400 (EDT) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) by imsva1.bcbsm.com (Postfix) with ESMTP id 03D694F8049; Mon, 18 Mar 2013 18:53:07 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([fe80::716f:e3f0:b97f:8900%14]) with mapi id 14.01.0355.002; Mon, 18 Mar 2013 18:54:20 -0400 From: "Ackermann, Michael" To: Nick Hilliard , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Thread-Index: AQHOIMaVqC5M9XVYp0uFMLNLdFX3pZil/fsAgAW9XMeAAHp1AP//xeIwgABMrQD//8pbMA== Date: Mon, 18 Mar 2013 22:54:18 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A64E973@PWN401EA160.ent.corp.bcbsm.com> References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> In-Reply-To: <51478D86.2090008@inex.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 22:54:22 -0000 Well stated Nick=21 The various viewpoints here are incredibly diverse. =20 I do get that we are arriving at what for IETF is the 11th hour and asking = for what would likely mean significant change. On the other hand this is = zero hour to a lot of us. I also agree that we don't want any more bits floating around (extension = headers), than absolutely necessary. So the trade off is a most = challenging one. =20 It's tough and confusing, and at times I feel like it may never come = together in an optimal, effective way. Not too certain about many of = the associated solutions, but I do know how important this feels and I do = want to be part of a best possible effort. =20 -----Original Message----- From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Nick Hilliard Sent: Monday, March 18, 2013 5:56 PM To: v6ops=40ietf.org Subject: Re: =5Bv6ops=5D draft-elkins-v6ops-ipv6-ipid-needed-00 On 18/03/2013 21:37, Ackermann, Michael wrote: > Since beginning to explore this issue of IPID, it has become clear how > valuable IPID has been to our organization and many like us. I have > personally not talked with everyone about this, but to those I have,=20 > the preponderance would not like to see this beneficial diagnostic=20 > feature lost. Mike, Nalini, I understand that using IPID works for you when diagnosing connectivity = problems in ipv4. Do you understand that ipv6 extension headers cause = massive operational headaches which we cannot get around using today's = technology? And that as a working group, the operational people here are = baulking at the idea of creating more extension headers because it makes = our lives massively more difficult? If everyone doesn't understand each others' points of view, this = conversation is going to continue running around in circles, causing = nothing but frustration. Nick _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From touch@isi.edu Mon Mar 18 16:18:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E1821F8B74 for ; Mon, 18 Mar 2013 16:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.299 X-Spam-Level: X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 PuiJ84tT4fMf for ; Mon, 18 Mar 2013 16:18:32 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8BD21F8B65 for ; Mon, 18 Mar 2013 16:18:32 -0700 (PDT) Received: from [66.104.71.46] (206.111.226.201.ptr.us.xo.net [206.111.226.201]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r2INI8m6028407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Mar 2013 16:18:11 -0700 (PDT) Message-ID: <5147A0B3.9050202@isi.edu> Date: Mon, 18 Mar 2013 16:18:11 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Ackermann, Michael" References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 23:18:33 -0000 The IPv4 ID requirements were recently updated to reflect widespread operational reality. That cat has been out of the bag for a long time. The ID never existed to support your business model, and the spec shouldn't be reverted for that reason. There are plenty of alternative ways to trace packets and packet sequences. Joe On 3/18/2013 2:37 PM, Ackermann, Michael wrote: > Since beginning to explore this issue of IPID, it has become clear > how valuable IPID has been to our organization and many like us. I > have personally not talked with everyone about this, but to those I > have, the preponderance would not like to see this beneficial > diagnostic feature lost. > > As a result, most of us do not view this as an assumption, but as a > reality experienced for many years now and one we would like to > continue to benefit from, I recognize that this reality is in > conflict with the original intent of this field, but at a certain > point isn't proven field value of equal or greater significance that > original intent? > > Having said that I know how challenging this will be, but I continue > to hope we can find the optimal solution that provides and works for > all. > > As far as using the packet itself, it would still need a way to > uniquely identify it and make it's relative or absolute order in a > sequence clear, to facilitate related diagnostics. This could be > done with add on software or techniques, which may be great for > vendors or software developers, but as a lowly (and poor) end user, I > would very much like to see this capability inherent in the protocol > as it is today in IPV4. > Thanks, > > Mike > > > > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Joe Touch > Sent: Monday, March 18, 2013 4:50 PM > To: Nalini Elkins > Cc: IPv6 Ops WG > Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 > > I'm lost on one key point - why not use the packets themselves? Why focus on a single field? > > Regardless, it seems like your business model is based on assumptions that were never sound (assuming sequential IDs), have become even less sound (no ID in most IPv6 and even some IPv4), and are now approved as not sound (RFC 6864). Maybe it's time to change your assumptions ;-) > > Joe > > On 3/18/2013 10:31 AM, Nalini Elkins wrote: >> Guys, >> >> Maybe it would be best to back up a bit, and start with what we want, >> why we want it and what we know to be some of the problems. >> >> 1. There is a class of applications for which the time for >> diagnostics, performance and ability to manage is critical. These >> may be financial (as ours are) but they may also be 911 in a city >> government, law enforcement, and others. >> >> 2. The platform may be IBM-mainframe based, Windows, Unix or cell phone. >> >> 3. Often problems are reported after the fact. As in, the Wire >> Transfer from xxx organization was too slow or did not complete properly. >> >> 4. Again, often, packet traces are either available or are the easiest >> way to diagnose such problems. Packet traces may be available because >> all packets are sometimes stored for regulatory reasons (ex. all stock >> trades must be saved, etc). Packet traces are often easiest because >> the organization does not necessarily own all the equipment and middle >> boxes or because a business partner is involved. An organization which >> owns all the hardware can do diagnostics differently. I used to work >> for such an organization and we would likely have stuck a hardware >> probe on immediately. This is quite often not an option in many organizations. >> >> 5. In IPv4, one of the fields we used was the IP ID. Even though, >> this field was meant for fragmentation, one of the properties it had (on many >> platforms) was sequentiality. We used it as a de-facto packet sequence >> number and also an eye catcher to know when the packet trace that we are >> looking at is corrupted or has potential inaccuracies. What can happen >> is that middle boxes can sometimes duplicate packets ONLY FOR SOME >> nodes or when we extract packets from one of the devices which are >> continuously capturing packets, the extract itself is wrong. This is >> actually why hash of the packets will not work and why we need it for TCP. >> >> 6. Packet sequence number turns out to be quite an interesting and >> useful number - with all the drawbacks it has of potential wrapping, >> etc. Taken in conjunction with TTL and other fields, it can often >> reduce problem diagnostic time considerably. Our motto is: do not let >> the perfect be the enemy of the good. >> >> Now, because IP ID is not in the main IP header in IPv6 and may not be >> available in IPv4, we are looking for a potential solution. We are >> not going to deal with IPv4 - we will only move forward to IPv6. Let >> me detail some of the known problems with solutions we have looked at: >> >> 1. Use IPv6 Fragment extension header with # of fragments set to 0 >> (atomic fragments). The problem with this is that many firewalls (and >> possibly other devices) drop these. You may be able to control this in >> your network but cannot in other peoples. That is, business partners. >> >> 2. Use IPv6 Dest Options extension header: similar issues as above >> but possibly even more as this may be even more unrecognized by middle >> boxes. Also, I have been told that adding IPv6 extension headers will >> make the routing of the packets through routers and middle boxes route >> at a software rather than hardware layer, thus slowing the performance. >> Guys, am I right? >> >> 3. So, now, we are trying to go back up the layers and consider the >> SHIM possibility. That is, introduce a header that is between TCP and >> UDP and the application. The idea of a SHIM was brought to us by Ron >> Bonica (Ron, we owe you a beer in Berlin!). This seems attractive in >> that only those applications which wish to employ this can do it. It >> also I believe gets us away from the IP layer. It seems that changes >> at the IP layer are quite problematic. >> >> 4. Then, we thought, if we are adding fields, something we would REALLY >> like is a timestamp in every packet. So, we are considering designing >> a PD-SHIM (Performance and Diagnostics SHIM) which will have a number >> of these quite interesting fields. This is when we started looking at >> Fred Templin's SEAL implementation. But, it we may need different fields. >> >> BTW, we are physically located in the Monterey and San Francisco Bay >> areas. So, Joe, if you have time, we can certainly drive down to >> Southern California and maybe we can chat for an hour or two. I will >> contact you offline about that. >> >> Thanks, >> >> Nalini Elkins >> Inside Products, Inc. >> (831) 659-8360 >> www.insidethestack.com >> >> ---------------------------------------------------------------------- >> -- >> *From:* Joe Touch >> *To:* Nalini Elkins >> *Cc:* joel jaeggli ; IPv6 Ops WG >> *Sent:* Thursday, March 14, 2013 3:38 PM >> *Subject:* Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 >> >> Hi, all, >> >> SEAL wraps IP packets. If you put a shim above the transport layer >> (between TCP/UDP and the app payload), then you might not get the >> semantics you want. >> >> Wrapping UDP messages is fine - presuming you look at the wrapper only >> at the endpoints; IP fragmentation may mean the wrapper isn't >> available for some datagrams. >> >> Wrapping TCP segments is a bad idea IMO, and doesn't make sense. >> >> TCP segments exist only at the TCP layer, and those boundaries are >> invisible to the application layer. The boundaries of what is written, >> transmitted, received, and, read may differ (the middle two due to >> rewriting proxies, which are evil but real). >> >> If you want/need a network identifier for diagnostics, it has to exist >> at the network layer. >> >> NB - as we noted during the discussion of RFC6864, the IPv6 ID can >> exist >> *either* when the source fragments *or* when a 6-to-4 translation is >> required even for datagrams that otherwise fit in an IPv6 MTU. You >> might update your intro accordingly: >> >> ...The IPv6 fragment >> header is present only when a datagram has been fragmented, or when >> the source has received a "packet too big" ICMPv6 error message >> indicating that the path cannot support the required minimum >> 1280-byte IPv6 MTU and is thus subject to translation [RFC2460] >> [RFC4443]. The latter case is relevant only for IPv6 datagrams sent >> to IPv4 destinations to support subsequent fragmentation after >> translation to IPv4. >> >> Regarding this draft, it would be useful to explain why using the >> entire packet (or a hash thereof) isn't nearly as useful in most cases >> (and that would not require a new ID). >> >> Again, note that most IPv4 implementations do not implement the ID >> uniqueness requirements in RFC791, and some use repeated IDs (even >> that don't compress headers). >> >> Joe >> >> >> >> >> On 3/14/2013 2:52 PM, Nalini Elkins wrote: >> > Joel, >> > >> > Thanks so much for your feedback. One of the alternatives that we >> are looking at to provide a Packet Sequence Number is a 'SHIM' such as >> that provided by SEAL. >> > >> > http://tools.ietf.org/html//rfc5320 >> > >> > This header (if I am reading this correctly!) would be between the >> TCP or UDP header and the application payload. >> > >> > One of the things that SEAL provides is: >> > >> > SEAL_ID - a 32-bit Identification value, randomly initialized and >> monotonically incremented for each SEAL protocol packet > > So, this >> might provide exactly what we are looking for! >> > >> > We do understand that there are a number of issues with IPv6 >> extension headers. We are not wedded to a particular implementation >> and whatever will provide the information we need is perfect! But, we >> have just found out about this RFC and need to study it more to see if >> there are any drawbacks. >> > >> > Thanks, >> > >> > Nalini Elkins >> > Inside Products, Inc. >> > (831) 659-8360 >> > www.insidethestack.com > > > > >> ________________________________ > From: joel jaeggli >> > > To: IPv6 Ops WG >> > > Sent: Thursday, March 14, >> 2013 8:13 AM > Subject: [v6ops] >> draft-elkins-v6ops-ipv6-ipid-needed-00 >> > >> > some more thoughts since the presentation. >> > >> > Noted that I consulted the earlier draft, discussion in 6-man and >> appendix a in the slides. >> > >> > >> http://tools.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header-00 >> > >> > was the previous one. >> > >> > The request is not really for the ipv4 IPID/frag header in v6. it's >> for a unique per packet value over a given sample interval. >> > >> > The utility of ipid in ipv4 for this context has eroded over time, >> (this is not knock againt the draft I'm just trying to describe my >> understanding of the utility). IPID's in the context of mobile >> phones/mobile networks are typically unvarrying (due to header >> compresssion). rfc 6864 exists because modern implmentations cannot >> (and therefore don't) honor requirements for uniqueness in >> rfc791,rfc1122 e.g. the duration over which 16 bit IPID is valid for >> uniqueness is bounded by the size of the flow because if it were >> limited by the MDL it would limit that speed of a flow. a 10Gb/s flow >> with 1500 byte packets overflows a 16 bit value every 78 or so ms. if >> your capture is longer than that you can reasonably expect duplicate >> IPIDS to show up which are readily identifiable as not being duplicate packets. >> > >> > desirable properties of a unique per packet value to my mind... >> > >> > * That it doesn't cost us anything - it strikes me as undesirable >> that packets should in general have larger headers then they do today >> that adds cost all over the place. extension header processing or >> indeed fragmentation header use has conquences. >> > >> > see http://tools.ietf.org/html/draft-wkumari-long-headers-00 >> > >> > for dicussion that has come up about header processing in modern routers. >> > >> > and >> > >> > http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00 >> > >> > for a similar discussion about fragmentation headers. >> > >> > neither of these represent any form of consensus document, so take >> that with a grain of salt. >> > >> > * That it is applied to every packet - part of the stated utility >> of the ipv4 ipid is that it's present (with my noted caveats) you >> don't have to turn it on. likewise this implies that the application >> of the value does not impact the observation, having the packet size >> change because you're doing debugging means imho that you're not doing >> the > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops >> > >> >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. > > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. > From marka@isc.org Mon Mar 18 16:39:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68E721F86D3 for ; Mon, 18 Mar 2013 16:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 ke+bywonqxVB for ; Mon, 18 Mar 2013 16:39:54 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 1839321F8652 for ; Mon, 18 Mar 2013 16:39:54 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id BE3B6C942B; Mon, 18 Mar 2013 23:39:45 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363649993; bh=N108AMPm1SgiRNIpjOsmx/Pb7ckKWneSL2dvoH1+Io4=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=JmKn27Ndp07HatuT5UhW46yOuzIjzYIWIKbK9ktDTQQk+u+HcSb/nQVXgGERN7YSA cDmiM4tQvvUeptG7aR4xC/MewCNiLre883Y2iMCWhIjwQBQgF99fzd3fY0dbvkTcJO l9ZYkgHODIOlPCFU+CK0XLpOoku5jw8Wn1G9/vlQ= 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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Mon, 18 Mar 2013 23:39:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:c151:953f:1813:8b87]) (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 4DD6D216C3B; Mon, 18 Mar 2013 23:39:45 +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 E8657312E1B9; Tue, 19 Mar 2013 10:39:42 +1100 (EST) To: Joe Touch From: Mark Andrews References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <2134F8430051B64F815C691A62D9831802FB9D@XCH-BLV-504.nw.nos.boeing.com> <51431F7E.3090502@viagenie.ca> <51434F97.7080505@isi.edu> <51435158.1010006@viagenie.ca> <514360A2.2040800@isi.edu> <2134F8430051B64F815C691A62D983180319A7@XCH-BLV-504.nw.nos.boeing.com> <51473BC5.4020905@isi.edu> <2134F8430051B64F815C691A62D98318031A47@XCH-BLV-504.nw.nos.boeing.com> <51477C55.7030900@isi.edu> In-reply-to: Your message of "Mon, 18 Mar 2013 13:43:01 PDT." <51477C55.7030900@isi.edu> Date: Tue, 19 Mar 2013 10:39:42 +1100 Message-Id: <20130318233942.E8657312E1B9@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 23:39:54 -0000 In message <51477C55.7030900@isi.edu>, Joe Touch writes: > Hi, Fred, > > On 3/18/2013 9:22 AM, Templin, Fred L wrote: > > Hi Joe, > ... > >>> True, the NAT should collect up all of the fragments of a fragmented > >>> datagram before forwarding them. However, RFC1812 says: > >>> > >>> "A router MUST NOT reassemble any datagram before forwarding it." > >> > >> A NAT isn't a router. It acts like a host for the purposes of RFC1812, > >> because it sources packets with its own IP address (to the public side), > >> and acts as the sink of public addresses (to the private side). > > > > I had a feeling you would say that, but a NAT is really a > > hybrid of sorts that exhibits some host functions and some > > router functions. For the purpose of handling fragments, it > > needs to behave as a router. > > Routers should NEVER aggregate the fragments before forwarding, nor > should it expect to see the whole set of fragments. > > I agree that a NAT is a hybrid in some ways - e.g., it should decrement > the hopcount - but regarding IDs, fragments, etc - it MUST behave as a > host exactly because it either sources packets or acts as if it were the > sink. > > >>> For that reason, NATs should do virtual fragment reassembly, i.e., > >>> collect up the fragments but then forward them on without reassembly > >>> once all fragments arrive. > >> > >> That may be a useful optimization, but its the same net effect. The only > >> difference is whether the fragment boundaries are the same before/after > >> the NAT, and that doesn't matter for the purposes of PMTUD, etc. > > > > It isn't an optimization; the NAT still has to dedicate reassembly > > resources for all of the fragments even though it won't be reassembling. > > Instead, it is the only correct behavior permissible by RFC1812. > > NATs should do reassembly, period. There's no reason to do anything > else, and it is the only permissible behavior by RFC1122. This is > governed by that RFC because the NAT is a source or (false) sink of the > addresses. > > > It also does not have the same net effect. With *real* reassembly, > > the destination sees only whole IP packets and has no notion that > > the packets may have been fragmented at some earlier hop(s) of the > > path from the source. With *virtual* reassembly, the destination > > gets to see that the packets were fragmented. > > It cannot possibly matter. If you have the time to see all the > fragments, you have time to reassemble - and refragment - them. > > Fragment boundaries are semantically meaningful - and should only be > visible - to IP anyway. Not true. In both IPv4 and IPv6 you can avoid PMTU issues by setting appropriate fragment sizes. For IPv6 we have a socket option for this IPV6_USE_MIN_MTU. Nameservers use this socket option on both UDP and TCP connections. When you only have 2-3 seconds to do a name resolution involving multiple lookups you don't have time for PMTUD to work (TCP) or there is no recovery from PTB (UDP). > >>> This is important, because the source and destination may have some > >>> sort of mutual understanding that packets will be sent and received > >>> as multiple IP fragments. If the NAT steps into the middle and does > >>> reassembly, then this understanding is violated. > >> > >> Source and dest exchange IP packets, not fragments. Any other > >> understanding between the endpoints is already violated by the NAT > >> process itself. > > > > I disagree. If the source has some reason to send the destination > > fragmented packets, it should reasonably expect that they will > > arrive at the destination as fragments and not as whole packets. > > That is what virtual fragment reassembly is all about. > > They arrive at the destination IP layer as fragments, but at the next > layer up as whole packets anyway. I don't see a good reason why fragment > boundaries are sacrosanct but IP addresses and ports can be rewritten. > Once you rewwrite, you act as a the source anyway, and all bets of what > the orignal source intended are off. > > Joe > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From touch@isi.edu Mon Mar 18 16:45:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7114721F8AF0 for ; Mon, 18 Mar 2013 16:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eiNyyreFFeH for ; Mon, 18 Mar 2013 16:45:56 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id CC9A721F8AE3 for ; Mon, 18 Mar 2013 16:45:55 -0700 (PDT) Received: from [66.104.71.46] (206.111.226.201.ptr.us.xo.net [206.111.226.201]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r2INimiX005921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Mar 2013 16:44:51 -0700 (PDT) Message-ID: <5147A6F3.4040301@isi.edu> Date: Mon, 18 Mar 2013 16:44:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Mark Andrews References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <2134F8430051B64F815C691A62D9831802FB9D@XCH-BLV-504.nw.nos.boeing.com> <51431F7E.3090502@viagenie.ca> <51434F97.7080505@isi.edu> <51435158.1010006@viagenie.ca> <514360A2.2040800@isi.edu> <2134F8430051B64F815C691A62D983180319A7@XCH-BLV-504.nw.nos.boeing.com> <51473BC5.4020905@isi.edu> <2134F8430051B64F815C691A62D98318031A47@XCH-BLV-504.nw.nos.boeing.com> <51477C55.7030900@isi.edu> <20130318233942.E8657312E1B9@drugs.dv.isc.org> In-Reply-To: <20130318233942.E8657312E1B9@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 23:45:56 -0000 On 3/18/2013 4:39 PM, Mark Andrews wrote: > In message <51477C55.7030900@isi.edu>, Joe Touch writes: ... >> Fragment boundaries are semantically meaningful - and should only be >> visible - to IP anyway. > > Not true. In both IPv4 and IPv6 you can avoid PMTU issues by setting > appropriate fragment sizes. You can try... > For IPv6 we have a socket option for > this IPV6_USE_MIN_MTU. Nameservers use this socket option on both > UDP and TCP connections. When you only have 2-3 seconds to do a > name resolution involving multiple lookups you don't have time for > PMTUD to work (TCP) or there is no recovery from PTB (UDP). This all presumes a) the NAT relays PTB b) the NAT doesn't rewrite the packets Neither is universally true. PMTUD is a path issue, and if the NAT presents an endpoint that is capable of dealing with a larger packet size, then it's up to the NAT to fragment later anyway. Again, it's the host and/or spoofs a host, so either way it needs to be participating as an endpoint in these protocols. Joe From marka@isc.org Mon Mar 18 16:58:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E371D21F8A71 for ; Mon, 18 Mar 2013 16:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 b4qXVfQX0Oge for ; Mon, 18 Mar 2013 16:58:39 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id EC79321F8A6F for ; Mon, 18 Mar 2013 16:58:38 -0700 (PDT) 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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id BF0B25F98B7; Mon, 18 Mar 2013 23:58:30 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363651118; bh=4uzlrN5a5sTbF8yZ5rfc2aqSheCGymlG9KJHchT5YTo=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=ionkjSZYjh6HapRS3AmSe+ru23Bbup3F1HBrisMkycYO2g5kRpx6BEmQm4mcQhKPK Z5yL4qwa2EyvfhBKGMVLqQ54WVj+a7TqnZJL9ttDi3exnAP8txx7XjW+NSmmkEFApT FpMTwtq00dYqtT0HDG+lmXxTIbc6c5SVXbVsXCxg= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 BB0BB216C43; Mon, 18 Mar 2013 23:58:28 +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 7BE8C312E98D; Tue, 19 Mar 2013 10:58:26 +1100 (EST) To: Joe Touch From: Mark Andrews References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <2134F8430051B64F815C691A62D9831802FB9D@XCH-BLV-504.nw.nos.boeing.com> <51431F7E.3090502@viagenie.ca> <51434F97.7080505@isi.edu> <51435158.1010006@viagenie.ca> <514360A2.2040800@isi.edu> <2134F8430051B64F815C691A62D983180319A7@XCH-BLV-504.nw.nos.boeing.com> <51473BC5.4020905@isi.edu> <2134F8430051B64F815C691A62D98318031A47@XCH-BLV-504.nw.nos.boeing.com> <51477C55.7030900@isi.edu> <20130318233942.E8657312E1B9@drugs.dv.isc.org> <5147A6F3.4040301@isi.edu> In-reply-to: Your message of "Mon, 18 Mar 2013 16:44:51 PDT." <5147A6F3.4040301@isi.edu> Date: Tue, 19 Mar 2013 10:58:26 +1100 Message-Id: <20130318235826.7BE8C312E98D@drugs.dv.isc.org> Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 23:58:40 -0000 In message <5147A6F3.4040301@isi.edu>, Joe Touch writes: > > > On 3/18/2013 4:39 PM, Mark Andrews wrote: > > In message <51477C55.7030900@isi.edu>, Joe Touch writes: > ... > >> Fragment boundaries are semantically meaningful - and should only be > >> visible - to IP anyway. > > > > Not true. In both IPv4 and IPv6 you can avoid PMTU issues by setting > > appropriate fragment sizes. > > You can try... > > > For IPv6 we have a socket option for > > this IPV6_USE_MIN_MTU. Nameservers use this socket option on both > > UDP and TCP connections. When you only have 2-3 seconds to do a > > name resolution involving multiple lookups you don't have time for > > PMTUD to work (TCP) or there is no recovery from PTB (UDP). > > This all presumes > > a) the NAT relays PTB > > b) the NAT doesn't rewrite the packets > > Neither is universally true. PMTUD is a path issue, and if the NAT > presents an endpoint that is capable of dealing with a larger packet > size, then it's up to the NAT to fragment later anyway. Again, it's the > host and/or spoofs a host, so either way it needs to be participating as > an endpoint in these protocols. > > Joe You claimed that only the IP layer cares about fragmentation. Your claim is wrong. As for NAT relaying PTB the point of using IPV6_USE_MIN_MTU is to never have a PTB be generated in the first place. A NAT needs to be aware that to one side it is a router and to the other side it is a host. It needs to behave like both. It can fragment a fragmement but needs to preserve incoming fragmentation points even if it has to reassemble a packet for something else. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From touch@isi.edu Mon Mar 18 17:04:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0CC21F88ED for ; Mon, 18 Mar 2013 17:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.024 X-Spam-Level: X-Spam-Status: No, score=-103.024 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZ0Ld7g6oEbz for ; Mon, 18 Mar 2013 17:04:47 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9C77021F88C7 for ; Mon, 18 Mar 2013 17:04:47 -0700 (PDT) Received: from [66.104.71.46] (206.111.226.201.ptr.us.xo.net [206.111.226.201]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r2J04Lx8012030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Mar 2013 17:04:24 -0700 (PDT) Message-ID: <5147AB88.6060105@isi.edu> Date: Mon, 18 Mar 2013 17:04:24 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Mark Andrews References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <2134F8430051B64F815C691A62D9831802FB9D@XCH-BLV-504.nw.nos.boeing.com> <51431F7E.3090502@viagenie.ca> <51434F97.7080505@isi.edu> <51435158.1010006@viagenie.ca> <514360A2.2040800@isi.edu> <2134F8430051B64F815C691A62D983180319A7@XCH-BLV-504.nw.nos.boeing.com> <51473BC5.4020905@isi.edu> <2134F8430051B64F815C691A62D98318031A47@XCH-BLV-504.nw.nos.boeing.com> <51477C55.7030900@isi.edu> <20130318233942.E8657312E1B9@drugs.dv.isc.org> <5147A6F3.4040301@isi.edu> <20130318235826.7BE8C312E98D@drugs.dv.isc.org> In-Reply-To: <20130318235826.7BE8C312E98D@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 00:04:48 -0000 On 3/18/2013 4:58 PM, Mark Andrews wrote: > In message <5147A6F3.4040301@isi.edu>, Joe Touch writes: >> >> >> On 3/18/2013 4:39 PM, Mark Andrews wrote: >>> In message <51477C55.7030900@isi.edu>, Joe Touch writes: >> ... >>>> Fragment boundaries are semantically meaningful - and should only be >>>> visible - to IP anyway. >>> >>> Not true. In both IPv4 and IPv6 you can avoid PMTU issues by setting >>> appropriate fragment sizes. >> >> You can try... >> >>> For IPv6 we have a socket option for >>> this IPV6_USE_MIN_MTU. Nameservers use this socket option on both >>> UDP and TCP connections. When you only have 2-3 seconds to do a >>> name resolution involving multiple lookups you don't have time for >>> PMTUD to work (TCP) or there is no recovery from PTB (UDP). >> >> This all presumes >> >> a) the NAT relays PTB >> >> b) the NAT doesn't rewrite the packets >> >> Neither is universally true. PMTUD is a path issue, and if the NAT >> presents an endpoint that is capable of dealing with a larger packet >> size, then it's up to the NAT to fragment later anyway. Again, it's the >> host and/or spoofs a host, so either way it needs to be participating as >> an endpoint in these protocols. >> >> Joe > > You claimed that only the IP layer cares about fragmentation. > Your claim is wrong. Yes, I'll concede that transport cares about this too. Apps shouldn't. > As for NAT relaying PTB the point of using IPV6_USE_MIN_MTU is to > never have a PTB be generated in the first place. Sure. > A NAT needs to be aware that to one side it is a router and to the > other side it is a host. It needs to behave like both. It can > fragment a fragmement but needs to preserve incoming fragmentation > points even if it has to reassemble a packet for something else. I disagree that it needs to preserve the fragmentation; it needs to preserve the fragment signalling and behavior together. Sometimes that means preserving fragmentation, but other times not. Joe From mackermann@bcbsm.com Mon Mar 18 17:46:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8497421F8ABA for ; Mon, 18 Mar 2013 17:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 0E5ABLk8MtCL for ; Mon, 18 Mar 2013 17:46:48 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.zixworks.com [63.71.11.123]) by ietfa.amsl.com (Postfix) with ESMTP id E8D3E21F8AB8 for ; Mon, 18 Mar 2013 17:46:46 -0700 (PDT) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 9D03F136D27 for ; Mon, 18 Mar 2013 19:46:45 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 6D376136D15; Mon, 18 Mar 2013 19:46:44 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id BD7222F0043; Mon, 18 Mar 2013 20:45:29 -0400 (EDT) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) by imsva2.bcbsm.com (Postfix) with ESMTP id AFF4A2F0040; Mon, 18 Mar 2013 20:45:29 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([fe80::716f:e3f0:b97f:8900%14]) with mapi id 14.01.0355.002; Mon, 18 Mar 2013 20:46:43 -0400 From: "Ackermann, Michael" To: Joe Touch Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Thread-Index: AQHOIMaVqC5M9XVYp0uFMLNLdFX3pZil/fsAgAW9XMeAAHp1AP//xeIwgABjiYD//9KAIA== Date: Tue, 19 Mar 2013 00:46:43 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A64E9D8@PWN401EA160.ent.corp.bcbsm.com> References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <5147A0B3.9050202@isi.edu> In-Reply-To: <5147A0B3.9050202@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 00:46:49 -0000 Good comments Joe=21 I suppose this exchange serves to again illustrate = the different perspectives that some of us have, or a different view of = what is important. As you say different operational realities. =20 Our operational reality is keeping outages to an absolute minimum. So = while I agree with you that there are other methods of tracing packets and = solving problems, if one has proven to be better and faster, I certainly = would like to preserve it if at all possible. =20 I do understand how unpopular such new ideas must be for those of you who = have been running IPV6 for some time now. So I greatly appreciate the = openness, consideration and help, for the perspective of those of us just = starting on the IPV6 journey. =20 -----Original Message----- From: Joe Touch =5Bmailto:touch=40isi.edu=5D=20 Sent: Monday, March 18, 2013 7:18 PM To: Ackermann, Michael Cc: Nalini Elkins; IPv6 Ops WG Subject: Re: =5Bv6ops=5D draft-elkins-v6ops-ipv6-ipid-needed-00 The IPv4 ID requirements were recently updated to reflect widespread = operational reality. That cat has been out of the bag for a long time. The ID never existed to support your business model, and the spec = shouldn't be reverted for that reason. There are plenty of alternative = ways to trace packets and packet sequences. Joe On 3/18/2013 2:37 PM, Ackermann, Michael wrote: > Since beginning to explore this issue of IPID, it has become clear how=20 > valuable IPID has been to our organization and many like us. I have=20 > personally not talked with everyone about this, but to those I have,=20 > the preponderance would not like to see this beneficial diagnostic=20 > feature lost. > > As a result, most of us do not view this as an assumption, but as a=20 > reality experienced for many years now and one we would like to=20 > continue to benefit from, I recognize that this reality is in conflict=20 > with the original intent of this field, but at a certain point isn't=20 > proven field value of equal or greater significance that original=20 > intent? > > Having said that I know how challenging this will be, but I continue=20 > to hope we can find the optimal solution that provides and works for=20 > all. > > As far as using the packet itself, it would still need a way to=20 > uniquely identify it and make it's relative or absolute order in a=20 > sequence clear, to facilitate related diagnostics. This could be done=20 > with add on software or techniques, which may be great for vendors or=20 > software developers, but as a lowly (and poor) end user, I would very=20 > much like to see this capability inherent in the protocol as it is=20 > today in IPV4. > Thanks, > > Mike > > > > > -----Original Message----- > From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf=20 > Of Joe Touch > Sent: Monday, March 18, 2013 4:50 PM > To: Nalini Elkins > Cc: IPv6 Ops WG > Subject: Re: =5Bv6ops=5D draft-elkins-v6ops-ipv6-ipid-needed-00 > > I'm lost on one key point - why not use the packets themselves? Why = focus on a single field? > > Regardless, it seems like your business model is based on assumptions=20 > that were never sound (assuming sequential IDs), have become even less=20 > sound (no ID in most IPv6 and even some IPv4), and are now approved as=20 > not sound (RFC 6864). Maybe it's time to change your assumptions ;-) > > Joe > > On 3/18/2013 10:31 AM, Nalini Elkins wrote: >> Guys, >> >> Maybe it would be best to back up a bit, and start with what we want,=20 >> why we want it and what we know to be some of the problems. >> >> 1. There is a class of applications for which the time for >> diagnostics, performance and ability to manage is critical. These=20 >> may be financial (as ours are) but they may also be 911 in a city=20 >> government, law enforcement, and others. >> >> 2. The platform may be IBM-mainframe based, Windows, Unix or cell = phone. >> >> 3. Often problems are reported after the fact. As in, the Wire >> Transfer from xxx organization was too slow or did not complete properly. >> >> 4. Again, often, packet traces are either available or are the easiest >> way to diagnose such problems. Packet traces may be available=20 >> because all packets are sometimes stored for regulatory reasons (ex. = all stock >> trades must be saved, etc). Packet traces are often easiest because >> the organization does not necessarily own all the equipment and middle >> boxes or because a business partner is involved. An organization which >> owns all the hardware can do diagnostics differently. I used to work=20 >> for such an organization and we would likely have stuck a hardware=20 >> probe on immediately. This is quite often not an option in many = organizations. >> >> 5. In IPv4, one of the fields we used was the IP ID. Even though,=20 >> this field was meant for fragmentation, one of the properties it had = (on many >> platforms) was sequentiality. We used it as a de-facto packet sequence >> number and also an eye catcher to know when the packet trace that we are >> looking at is corrupted or has potential inaccuracies. What can happen >> is that middle boxes can sometimes duplicate packets ONLY FOR SOME=20 >> nodes or when we extract packets from one of the devices which are >> continuously capturing packets, the extract itself is wrong. This is >> actually why hash of the packets will not work and why we need it for = TCP. >> >> 6. Packet sequence number turns out to be quite an interesting and=20 >> useful number - with all the drawbacks it has of potential wrapping, >> etc. Taken in conjunction with TTL and other fields, it can often >> reduce problem diagnostic time considerably. Our motto is: do not let >> the perfect be the enemy of the good. >> >> Now, because IP ID is not in the main IP header in IPv6 and may not=20 >> be available in IPv4, we are looking for a potential solution. We=20 >> are not going to deal with IPv4 - we will only move forward to IPv6.=20 >> Let me detail some of the known problems with solutions we have looked = at: >> >> 1. Use IPv6 Fragment extension header with =23 of fragments set to 0 >> (atomic fragments). The problem with this is that many firewalls (and >> possibly other devices) drop these. You may be able to control this in >> your network but cannot in other peoples. That is, business partners. >> >> 2. Use IPv6 Dest Options extension header: similar issues as above=20 >> but possibly even more as this may be even more unrecognized by=20 >> middle boxes. Also, I have been told that adding IPv6 extension=20 >> headers will make the routing of the packets through routers and=20 >> middle boxes route at a software rather than hardware layer, thus = slowing the performance. >> Guys, am I right? >> >> 3. So, now, we are trying to go back up the layers and consider the=20 >> SHIM possibility. That is, introduce a header that is between TCP=20 >> and UDP and the application. The idea of a SHIM was brought to us by Ron >> Bonica (Ron, we owe you a beer in Berlin=21). This seems attractive in >> that only those applications which wish to employ this can do it. It >> also I believe gets us away from the IP layer. It seems that changes >> at the IP layer are quite problematic. >> >> 4. Then, we thought, if we are adding fields, something we would REALLY >> like is a timestamp in every packet. So, we are considering designing >> a PD-SHIM (Performance and Diagnostics SHIM) which will have a number=20 >> of these quite interesting fields. This is when we started looking=20 >> at Fred Templin's SEAL implementation. But, it we may need different = fields. >> >> BTW, we are physically located in the Monterey and San Francisco Bay=20 >> areas. So, Joe, if you have time, we can certainly drive down to=20 >> Southern California and maybe we can chat for an hour or two. I will=20 >> contact you offline about that. >> >> Thanks, >> >> Nalini Elkins >> Inside Products, Inc. >> (831) 659-8360 >> www.insidethestack.com >> >> --------------------------------------------------------------------- >> - >> -- >> *From:* Joe Touch >> *To:* Nalini Elkins >> *Cc:* joel jaeggli ; IPv6 Ops WG >> *Sent:* Thursday, March 14, 2013 3:38 PM >> *Subject:* Re: =5Bv6ops=5D draft-elkins-v6ops-ipv6-ipid-needed-00 >> >> Hi, all, >> >> SEAL wraps IP packets. If you put a shim above the transport layer=20 >> (between TCP/UDP and the app payload), then you might not get the=20 >> semantics you want. >> >> Wrapping UDP messages is fine - presuming you look at the wrapper=20 >> only at the endpoints; IP fragmentation may mean the wrapper isn't=20 >> available for some datagrams. >> >> Wrapping TCP segments is a bad idea IMO, and doesn't make sense. >> >> TCP segments exist only at the TCP layer, and those boundaries are=20 >> invisible to the application layer. The boundaries of what is=20 >> written, transmitted, received, and, read may differ (the middle two=20 >> due to rewriting proxies, which are evil but real). >> >> If you want/need a network identifier for diagnostics, it has to=20 >> exist at the network layer. >> >> NB - as we noted during the discussion of RFC6864, the IPv6 ID can=20 >> exist >> *either* when the source fragments *or* when a 6-to-4 translation is=20 >> required even for datagrams that otherwise fit in an IPv6 MTU. You=20 >> might update your intro accordingly: >> >> ...The IPv6 fragment >> header is present only when a datagram has been fragmented, or when >> the source has received a =22packet too big=22 ICMPv6 error message >> indicating that the path cannot support the required minimum >> 1280-byte IPv6 MTU and is thus subject to translation =5BRFC2460=5D >> =5BRFC4443=5D. The latter case is relevant only for IPv6 = datagrams sent >> to IPv4 destinations to support subsequent fragmentation after >> translation to IPv4. >> >> Regarding this draft, it would be useful to explain why using the=20 >> entire packet (or a hash thereof) isn't nearly as useful in most=20 >> cases (and that would not require a new ID). >> >> Again, note that most IPv4 implementations do not implement the ID=20 >> uniqueness requirements in RFC791, and some use repeated IDs (even=20 >> that don't compress headers). >> >> Joe >> >> >> >> >> On 3/14/2013 2:52 PM, Nalini Elkins wrote: >> > Joel, >> > >> > Thanks so much for your feedback. One of the alternatives that=20 >> we are looking at to provide a Packet Sequence Number is a 'SHIM'=20 >> such as that provided by SEAL. >> > >> > http://tools.ietf.org/html//rfc5320 >> > >> > This header (if I am reading this correctly=21) would be between=20 >> the TCP or UDP header and the application payload. >> > >> > One of the things that SEAL provides is: >> > >> > SEAL_ID - a 32-bit Identification value, randomly initialized and=20 >> monotonically incremented for each SEAL protocol packet > > So,=20 >> this might provide exactly what we are looking for=21 >> > >> > We do understand that there are a number of issues with IPv6=20 >> extension headers. We are not wedded to a particular implementation=20 >> and whatever will provide the information we need is perfect=21 But,=20 >> we have just found out about this RFC and need to study it more to=20 >> see if there are any drawbacks. >> > >> > Thanks, >> > >> > Nalini Elkins >> > Inside Products, Inc. >> > (831) 659-8360 >> > www.insidethestack.com > > > =20 >> > ________________________________ > From: joel jaeggli=20 >> > > To: IPv6 Ops WG=20 >> > > Sent: Thursday, March 14, >> 2013 8:13 AM > Subject: =5Bv6ops=5D >> draft-elkins-v6ops-ipv6-ipid-needed-00 >> > >> > some more thoughts since the presentation. >> > >> > Noted that I consulted the earlier draft, discussion in 6-man and=20 >> appendix a in the slides. >> > >> > >> http://tools.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header-00 >> > >> > was the previous one. >> > >> > The request is not really for the ipv4 IPID/frag header in v6.=20 >> it's for a unique per packet value over a given sample interval. >> > >> > The utility of ipid in ipv4 for this context has eroded over=20 >> time, (this is not knock againt the draft I'm just trying to describe=20 >> my understanding of the utility). IPID's in the context of mobile=20 >> phones/mobile networks are typically unvarrying (due to header=20 >> compresssion). rfc 6864 exists because modern implmentations cannot=20 >> (and therefore don't) honor requirements for uniqueness in >> rfc791,rfc1122 e.g. the duration over which 16 bit IPID is valid for=20 >> uniqueness is bounded by the size of the flow because if it were=20 >> limited by the MDL it would limit that speed of a flow. a 10Gb/s flow=20 >> with 1500 byte packets overflows a 16 bit value every 78 or so ms. if=20 >> your capture is longer than that you can reasonably expect duplicate=20 >> IPIDS to show up which are readily identifiable as not being duplicate = packets. >> > >> > desirable properties of a unique per packet value to my mind... >> > >> > * That it doesn't cost us anything - it strikes me as undesirable=20 >> that packets should in general have larger headers then they do today=20 >> that adds cost all over the place. extension header processing or=20 >> indeed fragmentation header use has conquences. >> > >> > see http://tools.ietf.org/html/draft-wkumari-long-headers-00 >> > >> > for dicussion that has come up about header processing in modern = routers. >> > >> > and >> > >> > http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00 >> > >> > for a similar discussion about fragmentation headers. >> > >> > neither of these represent any form of consensus document, so=20 >> take that with a grain of salt. >> > >> > * That it is applied to every packet - part of the stated utility=20 >> of the ipv4 ipid is that it's present (with my noted caveats) you=20 >> don't have to turn it on. likewise this implies that the application=20 >> of the value does not impact the observation, having the packet size=20 >> change because you're doing debugging means imho that you're not=20 >> doing the > _______________________________________________ >> > v6ops mailing list >> > v6ops=40ietf.org >=20 >> https://www.ietf.org/mailman/listinfo/v6ops >> > _______________________________________________ >> > v6ops mailing list >> > v6ops=40ietf.org >=20 >> https://www.ietf.org/mailman/listinfo/v6ops >> > >> >> > _______________________________________________ > v6ops mailing list > v6ops=40ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. > > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. > The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From nalini.elkins@insidethestack.com Mon Mar 18 17:49:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6070721F853E for ; Mon, 18 Mar 2013 17:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] 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 S7sod77+yMJK for ; Mon, 18 Mar 2013 17:49:17 -0700 (PDT) Received: from nm14.access.bullet.mail.mud.yahoo.com (nm14.access.bullet.mail.mud.yahoo.com [66.94.237.215]) by ietfa.amsl.com (Postfix) with ESMTP id 17F2721F8539 for ; Mon, 18 Mar 2013 17:49:17 -0700 (PDT) Received: from [66.94.237.198] by nm14.access.bullet.mail.mud.yahoo.com with NNFMP; 19 Mar 2013 00:49:16 -0000 Received: from [66.94.237.113] by tm9.access.bullet.mail.mud.yahoo.com with NNFMP; 19 Mar 2013 00:49:16 -0000 Received: from [127.0.0.1] by omp1018.access.mail.mud.yahoo.com with NNFMP; 19 Mar 2013 00:49:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 724824.17278.bm@omp1018.access.mail.mud.yahoo.com Received: (qmail 18155 invoked by uid 60001); 19 Mar 2013 00:49:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1363654156; bh=qZJKSrihh/Odt3oljDTA7XPh5RGBOJwUR/2N+fFoJeI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=dZnfK4vBMcBHdesFuSxm2IqJbE2BSG6HTANSXdVP4xopRlGzFhbkGyHh4zOBEDpd19bIJUM8CBSoMaMPYu7/JNn3msAqGHRtADH3TLu4k9k40ynTI9NB60IKRD2fzyOEuvqbxZYjFWRtHwii4S9KLgRQ6rw5AV8gxodbSSszOtY= X-YMail-OSG: 4NiAJjwVM1kNxvVzdPNZ5pCcZR5S7o_tYCJx1xyqQztZZb6 lq8M8qpW6DHd8kw2R6kBoQ.BS8A1QbLUifmis4fmrkdMahNLDg12fob03xsX 5YUgfou5_XDlNA3WRjO6evZfTvjpAoGRC6v0PduUO_5aw0_jpCNX4iVddvy7 hGdFw3vbcbwe.m_gnuNWpChBFPsv8X2WUnrCM.BQp4XIVrYKdGD4YLsfMyPk QiB2hzWdFFrRCVwPdkKCt0wZMCulHJI5k95eioZpim587M07QDq5qlLUtxZW U90MWm3oKpM3ujR9ihPxLLMgYkXiDlZl1tHjbOCp0YXc6IoyLPwCUo3iUEF1 cao4ZlbmtITxZpoj.VYfb3LjItv7NTIF5SHxrtci6.injd9xnG0UNI2AT0Ws WgONicErlLzspM.ldUyrXEvzXMFgQ9AjFuCqfICfU8uoVztzw_MXzkxj9tcA cmLC6Hy_Ul7q2H5XvVb4diW9Pt50lLOKZnh4VTi501H6gnPfh.IZ73Iv.D87 FKnpH_m787YAx1gzxDDo2EBfjYUf0RCkwCfm9.Rf6BXT5XYGE9gzv2gzUNtd 0.WgrrGtXH2Hcjw9pyYvrLbh0Tx_EFXqNzKCg4Vz_JI_6 Received: from [24.130.37.147] by web2804.biz.mail.ne1.yahoo.com via HTTP; Mon, 18 Mar 2013 17:49:16 PDT X-Rocket-MIMEInfo: 002.001, RnJlZCwKClRDUCBzZXF1ZW5jZSBudW1iZXIgaXMgbm90IGVub3VnaCBiZWNhdXNlIHRoZXJlIGNhbiBiZSBkdXBsaWNhdGUgc2VnbWVudHMgYW5kIHJldHJhbnNtaXNzaW9ucy4gwqAgV2UgbmVlZCBhIHdheSB0byBzZWUgaWYgdGhlc2UgYXJlIHJlYWxseSBzZW50IGJ5IHRoZSBkZXZpY2Ugb3IgaWYgdGhleSBhcmUganVzdCBhIHByb2JsZW0gaW4gcGFja2V0IHRyYWNpbmcuCgpBbHNvLCBpbiB0aGUgY2FzZSBvZiByZXNldHMsIHRoZSBTRVEgYW5kIEFDSyBtYXkgYWxzbyBiZSBkdXBsaWNhdGVkLiDCoExldCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.138.524 References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> Message-ID: <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> Date: Mon, 18 Mar 2013 17:49:16 -0700 (PDT) From: Nalini Elkins To: "Templin, Fred L" , Nick Hilliard , "v6ops@ietf.org" In-Reply-To: <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1051860855-187537301-1363654156=:16516" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 00:49:18 -0000 ---1051860855-187537301-1363654156=:16516 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Fred,=0A=0ATCP sequence number is not enough because there can be duplicate= segments and retransmissions. =C2=A0 We need a way to see if these are rea= lly sent by the device or if they are just a problem in packet tracing.=0A= =0AAlso, in the case of resets, the SEQ and ACK may also be duplicated. =C2= =A0Let me give you real example:=0A=0Apkt 1: seq no: 123 =C2=A0 =C2=A0ack: = 345 =C2=A0 =C2=A0 ttl: 60 =C2=A0 =C2=A0 IPID: 123 =C2=A0 =C2=A0 =C2=A0 =C2= =A0src addr: 1.2.3.4 =C2=A0 =C2=A0dest addr : 4.5.6.7 =C2=A0=0Apkt 2: seq n= o: 123 =C2=A0 =C2=A0ack: 345 =C2=A0 =C2=A0 ttl: 254 =C2=A0 IPID: =C2=A0FF2A= =C2=A0 =C2=A0 src addr: 1.2.3.4 =C2=A0 dest addr: =C2=A04.5.6.7 =C2=A0 TCP= RESET flag set=0A=0AThe time between these two packets is quite small. =C2= =A0They have also been having problems with connections failing.=0A=0AMy co= nclusion would be that the second packet was NOT sent by the same device th= at sent the first. =C2=A0Why? =C2=A0Because BOTH IPID and TTL are quite dif= ferent. =C2=A0Very unlikely that the originating device is going to change = BOTH that quickly. =C2=A0I would conclude that there is a box in the middle= sending a RESET for that session. =C2=A0And, actually, when we replaced th= e device that we felt was the problem, sessions stayed up!=0A=0AThis is jus= t one case. =C2=A0In our draft, we had quite a few others, as you remember = from the presentation.=0A=0ADefinitely, we need a sequence number field tha= t is more than 16 bits. =C2=A0Wrapping is a problem.=0A=0ABut, the point is= well taken that=C2=A0the down side of a SHIM is that both sides have to im= plement. =C2=A0Noted.=0A=0A=C2=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside = Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A_______= _________________________=0A From: "Templin, Fred L" =0ATo: Nalini Elkins ; Nick Hilliard= ; "v6ops@ietf.org" =0ASent: Monday, March 1= 8, 2013 3:53 PM=0ASubject: RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-= 00=0A =0A=0A =0AHi Nalini,=0A=C2=A0=0AFor a shim header between the transpo= rt and the application data, TCP provides=0ATCP options so you could consid= er a new TCP option. But, TCP already includes=0Asequence numbers that can = be used for diagnostic purposes =E2=80=93 in fact, Wireshark=0A(and I=E2=80= =99m sure other network diagnostic tools) already use that. So, I don=E2=80= =99t see=0Aa shim as a big win for TCP.=0A=C2=A0=0AFor UDP, there would nee= d to be a new UDP port number assignment, and a=0Anew piece of code at both= the source and destination. The source would have=0Ato insert the shim abo= ut the UDP header, and the destination would have to=0Aremove it. That is t= he same model that SEAL is addressing, but SEAL is expecting=0Aboth ends to= implement the protocol. So, unfortunately, there is no way to=0Ahave a sou= rce-only patch that does not also require a patch at the destination.=0A=C2= =A0=0AThanks - Fred=0A=C2=A0=0A=C2=A0=0AFrom:v6ops-bounces@ietf.org [mailto= :v6ops-bounces@ietf.org] On Behalf Of Nalini Elkins=0ASent: Monday, March 1= 8, 2013 3:40 PM=0ATo: Nick Hilliard; v6ops@ietf.org=0ASubject: Re: [v6ops] = draft-elkins-v6ops-ipv6-ipid-needed-00=0A=C2=A0=0ANick,=0A=C2=A0=0ATotally = agree with you about trying to understand each other's point of view. =C2= =A0 We absolutely want to do that. =C2=A0 I think Mike was responding to th= e comment on the need for IPID itself.=0A=C2=A0=0AAs far as a solution,=C2= =A0we are thinking that IPv6 extension headers are a non-starter. =C2=A0For= all the reasons that have been brought up.=0A=C2=A0=0ASo,=C2=A0we are thin= king of a header higher up the layers. =C2=A0 For example, between the Tran= sport Layer (TCP / UDP) and the application payload.=0A=C2=A0=0AWhat are op= inions from people on that?=0A=C2=A0=0A=C2=A0=0AThanks,=0ANalini Elkins=0AI= nside Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A_______= _________________________=0A =0AFrom:Nick Hilliard =0ATo: v6o= ps@ietf.org =0ASent: Monday, March 18, 2013 2:56 PM=0ASubject: Re: [v6ops] = draft-elkins-v6ops-ipv6-ipid-needed-00=0A=0AOn 18/03/2013 21:37, Ackermann,= Michael wrote:=0A> Since beginning to explore this issue of IPID, it has b= ecome clear how=0A> valuable IPID has been to our organization and many lik= e us.=C2=A0 =C2=A0 I have=0A> personally not talked with everyone about thi= s, but to those I have, the=0A> preponderance would not like to see this be= neficial diagnostic feature=0A> lost.=0A=0AMike, Nalini,=0A=0AI understand = that using IPID works for you when diagnosing connectivity=0Aproblems in ip= v4.=C2=A0 Do you understand that ipv6 extension headers cause=0Amassive ope= rational headaches which we cannot get around using today's=0Atechnology?= =C2=A0 And that as a working group, the operational people here are=0Abaulk= ing at the idea of creating more extension headers because it makes=0Aour l= ives massively more difficult?=0A=0AIf everyone doesn't understand each oth= ers' points of view, this=0Aconversation is going to continue running aroun= d in circles, causing=0Anothing but frustration.=0A=0ANick=0A=0A___________= ____________________________________=0Av6ops mailing list=0Av6ops@ietf.org= =0Ahttps://www.ietf.org/mailman/listinfo/v6ops ---1051860855-187537301-1363654156=:16516 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Fred,
=
TCP sequence number is not enough because there can be = duplicate segments and retransmissions.   We need a way to see if thes= e are really sent by the device or if they are just a problem in packet tra= cing.

Also, in the case of resets, the S= EQ and ACK may also be duplicated.  Let me give you real example:

pkt 1: seq no: 123    ack: 345 &nb= sp;   ttl: 60     IPID: 123        src a= ddr: 1.2.3.4    dest addr : 4.5.6.7  
pkt 2: seq no= : 123    ack: 345     ttl: 254   IPID:  FF2A =     src addr: 1.2.3.4   dest addr:  4.5.6.7   TCP RESET flag set

The time between these two packets is quite small.=  They have also been having problems with connections failing.
<= div style=3D"color: rgb(0, 0, 0); font-size: 13px; font-family: arial, helv= etica, sans-serif; background-color: transparent; font-style: normal;">
=
My conclusion would be that the second packet was NOT sent by the same device that sent the first. &= nbsp;Why?  Because BOTH IPID and TTL are quite different.  Very unlikely that the originating device is going to change BOTH that quickly.=  I would conclude that there is a box in the middle sending a RESET f= or that session.  And, actually, when we replaced the device that we f= elt was the problem, sessions stayed up!

This is just one case.  In our draft, we had quite a few other= s, as you remember from the presentation.

Definitely, we need a sequence number field tha= t is more than 16 bits.  Wrapping is a problem.

But, the point is well taken that the down side of a SHIM is that bot= h sides have to implement.  Noted.

 
Thanks,

Nalini Elkins
Inside Products, Inc.
(= 831) 659-8360
www.insidethestack.com

From: "Templin, Fred L" <Fred.L.Templi= n@boeing.com>
To: N= alini Elkins <nalini.elkins@insidethestack.com>; Nick Hilliard <ni= ck@inex.ie>; "v6ops@ietf.org" <v6ops@ietf.org>
Sent: Monday, March 18, 2013 3:53 PM
= Subject: RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

=0A
=0A=0A =0A =0A=0A=0A
=0A
=0A
Hi Nalini,
=0A
=  
=0A
For a shim header between the transport a= nd the application data, TCP provides
=0A
TCP options= so you could consider a new TCP option. But, TCP already includes =0A
sequence numbers that can be used for diagnostic purposes= =E2=80=93 in fact, Wireshark
=0A
(and I=E2=80=99m su= re other network diagnostic tools) already use that. So, I don=E2=80=99t se= e
=0A
a shim as a big win for TCP.
=0A  
=0A
For UDP, there would need to be a= new UDP port number assignment, and a
=0A
new piece = of code at both the source and destination. The source would have =0A
to insert the shim about the UDP header, and the destinati= on would have to
=0A
remove it. That is the same mode= l that SEAL is addressing, but SEAL is expecting
=0A
= both ends to implement the protocol. So, unfortunately, there is no way to<= /span>
=0A
have a source-only patch that does not also requi= re a patch at the destination.
=0A
  =0A
Thanks - Fred
=0A
  =0A
 
=0A
=0A
=0A
=0AFrom:= v6ops-bounces@ietf.org [mailt= o:v6ops-bounces@ietf.org]=0AOn Behalf Of Nalini Elkins
=0ASent= : Monday, March 18, 2013 3:40 PM
=0ATo: Nick Hilliard; v6ops@= ietf.org
=0ASubject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-nee= ded-00
=0A
=0A
=0A
 
=0A
=0A
=0A
Nic= k,
=0A
=0A
=0A
 
=0A
= =0A
=0A
Totally agree with you about trying to understand each o= ther's point of view.   We absolutely want to do that.   I think = Mike was responding to the comment on the=0A need for IPID itself. =0A
=0A
=0A
 
=0A
=0A
= =0A
As far as a solution, we are thinking that IPv6 extension h= eaders are a non-starter.  For all the reasons that have been brought = up.
=0A
=0A
=0A
<= span style=3D"font-size:10.0pt;color:black;">  
=0A
= =0A
=0A
So, we are thinking of a header higher up the layer= s.   For example, between the Transport Layer (TCP / UDP) and the appl= ication payload.
=0A
=0A
=0A
  =0A
=0A
=0A
What are opinions from people on that?
=0A
=0A
=0A
 
=0A
=0A
= =0A
 
=0A
=0A=0A
Thanks,=
=0A
=0A
=0A
Nalini Elkins
=0AInside Products, Inc.
=0A(831) 659-8360
= =0Awww.insidethestack.com
=0A
=0A
=0A
=0A=0A=0A=
=0A
=0A
From: Nick Hilliard <nick@inex.ie>
=0ATo: v6ops@ietf.org
= =0ASent: Monday, March 18, 2013 2:56 PM
=0ASubject: Re: [v= 6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
=0A
=0A
=0AOn 18/03/2013 21:37, Ackermann, Michael wrote:
=0A> Since beginn= ing to explore this issue of IPID, it has become clear how
=0A> valua= ble IPID has been to our organization and many like us.    I have=
=0A> personally not talked with everyone about this, but to those I = have, the
=0A> preponderance would not like to see this beneficial di= agnostic feature
=0A> lost.
=0A
=0AMike, Nalini,
=0A
=0AI= understand that using IPID works for you when diagnosing connectivity
= =0Aproblems in ipv4.  Do you understand that ipv6 extension headers ca= use
=0Amassive operational headaches which we cannot get around using to= day's
=0Atechnology?  And that as a working group, the operational = people here are
=0Abaulking at the idea of creating more extension heade= rs because it makes
=0Aour lives massively more difficult?
=0A
=0A= If everyone doesn't understand each others' points of view, this
=0Aconv= ersation is going to continue running around in circles, causing
=0Anoth= ing but frustration.
=0A
=0ANick
=0A
=0A_______________________= ________________________
=0Av6ops mailing list
=0Av6ops@ietf.org
=0Ahttps://www.ietf.org/mail= man/listinfo/v6ops
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
=0A
=0A=0A


<= /div>
---1051860855-187537301-1363654156=:16516-- From marka@isc.org Mon Mar 18 17:50:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A1A21F858A for ; Mon, 18 Mar 2013 17:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 eo17cqy8X97w for ; Mon, 18 Mar 2013 17:50:20 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5E221F8549 for ; Mon, 18 Mar 2013 17:50:20 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 5A439C9478; Tue, 19 Mar 2013 00:50:10 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363654217; bh=JofsszxvUG9E68TtdhCLIHWwPXOU3UkVp3FZZ+Gl/Mo=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=q6xz+njpjT0YbK9n3YqkWe06VIGdt5Rc7L9oMWf4yam0J2fC1UeuEUaW+mAZ2L902 +tqJpx81I2oQatmiVKFTX+uvVI5JEEWn9JkKlxhUqaB1Tr2fNFnWSIGAUWI+jFld1h d2wR641gYX3WXZGsrcFj18Ql0Cu4rDVXiIVVoobA= 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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Tue, 19 Mar 2013 00:50:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 16357216C40; Tue, 19 Mar 2013 00:50:10 +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 664D7312EF70; Tue, 19 Mar 2013 11:50:07 +1100 (EST) To: Joe Touch From: Mark Andrews References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <2134F8430051B64F815C691A62D9831802FB9D@XCH-BLV-504.nw.nos.boeing.com> <51431F7E.3090502@viagenie.ca> <51434F97.7080505@isi.edu> <51435158.1010006@viagenie.ca> <514360A2.2040800@isi.edu> <2134F8430051B64F815C691A62D983180319A7@XCH-BLV-504.nw.nos.boeing.com> <51473BC5.4020905@isi.edu> <2134F8430051B64F815C691A62D98318031A47@XCH-BLV-504.nw.nos.boeing.com> <51477C55.7030900@isi.edu> <20130318233942.E8657312E1B9@drugs.dv.isc.org> <5147A6F3.4040301@isi.edu> <20130318235826.7BE8C312E98D@drugs.dv.isc.org> <5147AB88.6060105@isi.edu> In-reply-to: Your message of "Mon, 18 Mar 2013 17:04:24 PDT." <5147AB88.6060105@isi.edu> Date: Tue, 19 Mar 2013 11:50:07 +1100 Message-Id: <20130319005007.664D7312EF70@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 00:50:21 -0000 In message <5147AB88.6060105@isi.edu>, Joe Touch writes: > > > On 3/18/2013 4:58 PM, Mark Andrews wrote: > > In message <5147A6F3.4040301@isi.edu>, Joe Touch writes: > >> > >> > >> On 3/18/2013 4:39 PM, Mark Andrews wrote: > >>> In message <51477C55.7030900@isi.edu>, Joe Touch writes: > >> ... > >>>> Fragment boundaries are semantically meaningful - and should only be > >>>> visible - to IP anyway. > >>> > >>> Not true. In both IPv4 and IPv6 you can avoid PMTU issues by setting > >>> appropriate fragment sizes. > >> > >> You can try... > >> > >>> For IPv6 we have a socket option for > >>> this IPV6_USE_MIN_MTU. Nameservers use this socket option on both > >>> UDP and TCP connections. When you only have 2-3 seconds to do a > >>> name resolution involving multiple lookups you don't have time for > >>> PMTUD to work (TCP) or there is no recovery from PTB (UDP). > >> > >> This all presumes > >> > >> a) the NAT relays PTB > >> > >> b) the NAT doesn't rewrite the packets > >> > >> Neither is universally true. PMTUD is a path issue, and if the NAT > >> presents an endpoint that is capable of dealing with a larger packet > >> size, then it's up to the NAT to fragment later anyway. Again, it's the > >> host and/or spoofs a host, so either way it needs to be participating as > >> an endpoint in these protocols. > >> > >> Joe > > > > You claimed that only the IP layer cares about fragmentation. > > Your claim is wrong. > > Yes, I'll concede that transport cares about this too. Apps shouldn't. Apart from TCP which handles retransmission, apps need to care about about fragmentation when it is not being done by itermediate nodes in the network. For IPv6 this is any app that is using a protocol other then TCP. > > As for NAT relaying PTB the point of using IPV6_USE_MIN_MTU is to > > never have a PTB be generated in the first place. > > Sure. > > > A NAT needs to be aware that to one side it is a router and to the > > other side it is a host. It needs to behave like both. It can > > fragment a fragmement but needs to preserve incoming fragmentation > > points even if it has to reassemble a packet for something else. > > I disagree that it needs to preserve the fragmentation; it needs to > preserve the fragment signalling and behavior together. Sometimes that > means preserving fragmentation, but other times not. And how can a NAT know if it can *safely* reassemble and do its own fragmentation? It can't. Since it can't it needs to preserve fragmentation. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nalini.elkins@insidethestack.com Mon Mar 18 17:54:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE6421F8BE2 for ; Mon, 18 Mar 2013 17:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 jONPjzPKn9TQ for ; Mon, 18 Mar 2013 17:54:39 -0700 (PDT) Received: from nm29.access.bullet.mail.mud.yahoo.com (nm29.access.bullet.mail.mud.yahoo.com [66.94.237.94]) by ietfa.amsl.com (Postfix) with ESMTP id 914F021F896E for ; Mon, 18 Mar 2013 17:54:39 -0700 (PDT) Received: from [66.94.237.196] by nm29.access.bullet.mail.mud.yahoo.com with NNFMP; 19 Mar 2013 00:54:36 -0000 Received: from [66.94.237.99] by tm7.access.bullet.mail.mud.yahoo.com with NNFMP; 19 Mar 2013 00:54:36 -0000 Received: from [127.0.0.1] by omp1004.access.mail.mud.yahoo.com with NNFMP; 19 Mar 2013 00:54:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 541403.46912.bm@omp1004.access.mail.mud.yahoo.com Received: (qmail 53699 invoked by uid 60001); 19 Mar 2013 00:54:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1363654476; bh=0dvdk/aMhv95zIUKwqMB433wea5kNv2JBF44SBJYR30=; 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=CE7VgfuRXXwY3U6bWVc8v9mP+VR0TlJ5qxZzI610JqXTzym5ukViSj7iUat+mg3qHu7vyHtCsRGc4KGB2xn3eb37+ALj7KQodKDnoRpUmrRla71DCO1pEpDm6Jel8LoEg+5cNU7J6K3omtqPiYUceapmqj5h6WIqwntc/107QvE= X-YMail-OSG: eVn65HoVM1myQj9MYLMoNxca8SCSVKcmgGSPcL1f3bUOqn9 YQTofglFviPj_MlzzaOSMtiaNBhHnNkv7dI6oasfz5RW7Hc9o6rI8e0nXmt4 2O8YKYiA2tmHkcpPmSdDvXF2OGwtlxIasjqDcitaRvpPMxKK114ZRRxy7Vj9 IUq4pCM.HgQ9YY49DiKgug4la4wg9Z84gpbpQKORf00E8Pl4Qxg5iXNWWNZ7 pCVeSqSK2cNWqVh7Nhupk5EqNdAg58Z__mrwXoBBBakCt983.TaP0uP4NPU8 GZLLixfwFg_F7bKk.X_4tTHksXwX2hP6G10WGzovyD3kfFXAoITgCFBIDL.u QrkQCJByOS_K4Xl0CTeG1v5SbFsrp5o.2a44cHzKY9yTFaPkZeD9RJtc80k4 D1WLGJxVQNkW7quVQW6N.MYHc3RBKQ42dewes8uHPUv58q2BRWdDVH0AhG.8 ZgYlIzfmKgw5ieYgvH8orsXsphzkfgY9AEKhIDKmOgJu2XoJ6_mkPx9qv29f yWKWtbhUsc_N0.VnSFIhHdtbWICs7bvdyqDmE7HrA.Z13XKLelXUnDSosemQ E3m20646Mkvv7WGwh0BcZ4ipCJ23y8sZshqoHRbbOHqQ- Received: from [24.130.37.147] by web2805.biz.mail.ne1.yahoo.com via HTTP; Mon, 18 Mar 2013 17:54:35 PDT X-Rocket-MIMEInfo: 002.001, T3BlcmF0aW9uYWwgcmVhbGl0aWVzIGRlcGVuZCBvbiB3aGVyZSB5b3UgYXJlIHNpdHRpbmcuIMKgV2UgaGFkIDYgdXNhZ2UgY2FzZXMgZnJvbSA1IGRpZmZlcmVudCBvcmdhbml6YXRpb25zIHdoZXJlIHdlIHVzZWQgSVBJRCB0byBzYXZlIHVzIHRpbWUgaW4gcHJvYmxlbSBkaWFnbm9zdGljcy4gwqAgVGhpcyBpcyBzdGFydGluZyB0byBzZWVtIGxpa2UgdGhlIGJsaW5kIG1lbiBkZXNjcmliaW5nIHRoZSBlbGVwaGFudC4KCkkgYW0gYWZyYWlkIEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGXCoCJUaGUgSUQgbmV2ZXIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.138.524 References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <5147A0B3.9050202@isi.edu> Message-ID: <1363654475.52161.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Mon, 18 Mar 2013 17:54:35 -0700 (PDT) From: Nalini Elkins To: Joe Touch , "Ackermann, Michael" In-Reply-To: <5147A0B3.9050202@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 00:54:41 -0000 Operational realities depend on where you are sitting. =A0We had 6 usage ca= ses from 5 different organizations where we used IPID to save us time in pr= oblem diagnostics. =A0 This is starting to seem like the blind men describi= ng the elephant.=0A=0AI am afraid I don't understand the=A0"The ID never ex= isted to support your business model" statement. =A0 What business model? = =A0I thought we were talking about diagnostics.=0A=0A=0AThanks,=0A=0ANalini= Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com= =0A=0A=0A=0A________________________________=0AFrom: Joe Touch =0ATo: "Ackermann, Michael" =0ACc: Nalini Elkins = ; IPv6 Ops WG =0ASent: M= onday, March 18, 2013 4:18 PM=0ASubject: Re: [v6ops] draft-elkins-v6ops-ipv= 6-ipid-needed-00=0A=0AThe IPv4 ID requirements were recently updated to ref= lect widespread =0Aoperational reality. That cat has been out of the bag fo= r a long time.=0A=0AThe ID never existed to support your business model, an= d the spec =0Ashouldn't be reverted for that reason. There are plenty of al= ternative =0Aways to trace packets and packet sequences.=0A=0AJoe=0A=0AOn 3= /18/2013 2:37 PM, Ackermann, Michael wrote:=0A> Since beginning to explore = this issue of IPID, it has become clear=0A> how valuable IPID has been to o= ur organization and many like us. I=0A> have personally not talked with eve= ryone about this, but to those I=0A> have, the preponderance would not like= to see this beneficial=0A> diagnostic feature lost.=0A>=0A> As a result, m= ost of us do not view this as an assumption, but as a=0A> reality experienc= ed for many years now and one we would like to=0A> continue to benefit from= , I recognize that this reality is in=0A> conflict with the original intent= of this field, but at a certain=0A> point isn't proven field value of equa= l or greater significance that=0A> original intent?=0A>=0A> Having said tha= t I know how challenging this will be, but I continue=0A> to hope we can fi= nd the optimal solution that provides and works for=0A> all.=0A>=0A> As far= as using the packet itself, it would still need a way to=0A> uniquely iden= tify it and make it's relative or absolute order in a=0A> sequence clear, t= o facilitate related diagnostics. This could be=0A> done with add on softwa= re or techniques, which may be great for=0A> vendors or software developers= , but as a lowly (and poor) end user, I=0A> would very much like to see thi= s capability inherent in the protocol=0A> as it is today in IPV4.=0A=0A> Th= anks,=0A>=0A> Mike=0A>=0A>=0A>=0A>=0A> -----Original Message-----=0A> From:= v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Joe To= uch=0A> Sent: Monday, March 18, 2013 4:50 PM=0A> To: Nalini Elkins=0A> Cc: = IPv6 Ops WG=0A> Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00= =0A>=0A> I'm lost on one key point - why not use the packets themselves? Wh= y focus on a single field?=0A>=0A> Regardless, it seems like your business = model is based on assumptions that were never sound (assuming sequential ID= s), have become even less sound (no ID in most IPv6 and even some IPv4), an= d are now approved as not sound (RFC 6864). Maybe it's time to change your = assumptions ;-)=0A>=0A> Joe=0A>=0A> On 3/18/2013 10:31 AM, Nalini Elkins wr= ote:=0A>> Guys,=0A>>=0A>> Maybe it would be best to back up a bit, and star= t with what we want,=0A>> why we want it and what we know to be some of the= problems.=0A>>=0A>> 1.=A0=A0=A0There is a class of applications for which = the time for=0A>> diagnostics,=A0 performance and ability to manage is crit= ical.=A0 These=0A>> may be financial (as ours are) but they may also be 911= in a city=0A>> government, law enforcement, and others.=0A>>=0A>> 2.=A0=A0= =A0The platform may be IBM-mainframe based, Windows, Unix or cell phone.=0A= >>=0A>> 3.=A0=A0=A0Often problems are reported after the fact.=A0 As in, th= e Wire=0A>> Transfer from xxx organization was too slow or did not complete= properly.=0A>>=0A>> 4.=A0=A0=A0Again, often, packet traces are either avai= lable or are the easiest=0A>> way to diagnose such problems.=A0 Packet trac= es may be available because=0A>> all packets are sometimes stored for regul= atory reasons (ex.=A0 all stock=0A>> trades must be saved, etc).=A0=A0=A0Pa= cket traces are often easiest because=0A>> the organization does not necess= arily own all the equipment and middle=0A>> boxes or because a business par= tner is involved.=A0=A0=A0An organization which=0A>> owns all the hardware = can do diagnostics differently.=A0 I used to work=0A>> for such an organiza= tion and we would likely have stuck a hardware=0A>> probe on immediately.= =A0 This is quite often not an option in many organizations.=0A>>=0A>> 5.= =A0 In IPv4, one of the fields we used was the IP ID.=A0 Even though,=0A>> = this field was meant for fragmentation, one of the properties it had (on ma= ny=0A>> platforms) was sequentiality.=A0=A0=A0We used it as a de-facto pack= et sequence=0A>> number and also an eye catcher to know when the packet tra= ce that we are=0A>> looking at is corrupted or has potential inaccuracies.= =A0=A0=A0What can happen=0A>> is that middle boxes can sometimes duplicate = packets ONLY FOR SOME=0A>> nodes or when we extract packets from one of the= devices which are=0A>> continuously capturing packets, the extract itself = is wrong.=A0=A0=A0This is=0A>> actually why hash of the packets will not wo= rk and why we need it for TCP.=0A>>=0A>> 6.=A0 Packet sequence number turns= out to be quite an interesting and=0A>> useful number - with all the drawb= acks it has of potential wrapping,=0A>> etc.=A0=A0=A0Taken in conjunction w= ith TTL and other fields, it can often=0A>> reduce problem diagnostic time = considerably.=A0=A0=A0Our motto is: do not let=0A>> the perfect be the enem= y of the good.=0A>>=0A>> Now, because IP ID is not in the main IP header in= IPv6 and may not be=0A>> available in IPv4, we are looking for a potential= solution.=A0 We are=0A>> not going to deal with IPv4 - we will only move f= orward to IPv6. Let=0A>> me detail some of the known problems with solution= s we have looked at:=0A>>=0A>> 1.=A0=A0=A0Use IPv6 Fragment extension heade= r with # of fragments set to 0=0A>> (atomic fragments).=A0=A0=A0The problem= with this is that many firewalls (and=0A>> possibly other devices) drop th= ese.=A0=A0=A0You may be able to control this in=0A>> your network but canno= t in other peoples.=A0 That is, business partners.=0A>>=0A>> 2.=A0 Use IPv6= Dest Options extension header: similar issues as above=0A>> but possibly e= ven more as this may be even more unrecognized by middle=0A>> boxes.=A0 Als= o, I have been told that adding IPv6 extension headers will=0A>> make the r= outing of the packets through routers and middle boxes route=0A>> at a soft= ware rather than hardware layer, thus slowing the performance.=0A>>=A0 =A0 = Guys, am I right?=0A>>=0A>> 3.=A0 So, now, we are trying to go back up the = layers and consider the=0A>> SHIM possibility.=A0 That is, introduce a head= er that is between TCP and=0A>> UDP and the application. The idea of a SHIM= was brought to us by Ron=0A>> Bonica (Ron, we owe you a beer in Berlin!).= =A0=A0=A0This seems attractive in=0A>> that only those applications which w= ish to employ this can do it.=A0 It=0A>> also I believe gets us away from t= he IP layer.=A0=A0=A0It seems that changes=0A>> at the IP layer are quite p= roblematic.=0A>>=0A>> 4.=A0 Then, we thought, if we are adding fields, some= thing we would REALLY=0A>> like is a timestamp in every packet.=A0=A0=A0So,= we are considering designing=0A>> a PD-SHIM (Performance and Diagnostics S= HIM) which will have a number=0A>> of these quite interesting fields.=A0 Th= is is when we started looking at=0A>> Fred Templin's SEAL implementation.= =A0 But, it we may need different fields.=0A>>=0A>> BTW,=A0 we are physical= ly located in the Monterey and San Francisco Bay=0A>> areas.=A0 So, Joe, if= you have time, we can certainly drive down to=0A>> Southern California and= maybe we can chat for an hour or two.=A0 I will=0A>> contact you offline a= bout that.=0A>>=0A>> Thanks,=0A>>=0A>> Nalini Elkins=0A>> Inside Products, = Inc.=0A>> (831) 659-8360=0A>> www.insidethestack.com =0A>>=0A>> ------------------------------------------------------= ----------------=0A>> --=0A>> *From:* Joe Touch =0A>> *To:* = Nalini Elkins =0A>> *Cc:* joel jaeggli ; IPv6 Ops WG =0A>> *Sent:* Thursday, March= 14, 2013 3:38 PM=0A>> *Subject:* Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-= needed-00=0A>>=0A>> Hi, all,=0A>>=0A>> SEAL wraps IP packets. If you put a = shim above the transport layer=0A>> (between TCP/UDP and the app payload), = then you might not get the=0A>> semantics you want.=0A>>=0A>> Wrapping UDP = messages is fine - presuming you look at the wrapper only=0A>> at the endpo= ints; IP fragmentation may mean the wrapper isn't=0A>> available for some d= atagrams.=0A>>=0A>> Wrapping TCP segments is a bad idea IMO, and doesn't ma= ke sense.=0A>>=0A>> TCP segments exist only at the TCP layer, and those bou= ndaries are=0A>> invisible to the application layer. The boundaries of what= is written,=0A>> transmitted, received, and, read may differ (the middle t= wo due to=0A>> rewriting proxies, which are evil but real).=0A>>=0A>> If yo= u want/need a network identifier for diagnostics, it has to exist=0A>> at t= he network layer.=0A>>=0A>> NB - as we noted during the discussion of RFC68= 64, the IPv6 ID can=0A>> exist=0A>> *either* when the source fragments *or*= when a 6-to-4 translation is=0A>> required even for datagrams that otherwi= se fit in an IPv6 MTU. You=0A>> might update your intro accordingly:=0A>>= =0A>>=A0 =A0 =A0=A0=A0...The IPv6 fragment=0A>>=A0 =A0 =A0=A0=A0header is p= resent only when a datagram has been fragmented, or when=0A>>=A0 =A0 =A0=A0= =A0the source has received a "packet too big" ICMPv6 error message=0A>>=A0 = =A0 =A0=A0=A0indicating that the path cannot support the required minimum= =0A>>=A0 =A0 =A0=A0=A01280-byte IPv6 MTU and is thus subject to translation= [RFC2460]=0A>>=A0 =A0 =A0=A0=A0[RFC4443].=A0 The latter case is relevant o= nly for IPv6 datagrams sent=0A>>=A0 =A0 =A0=A0=A0to IPv4 destinations to su= pport subsequent fragmentation after=0A>>=A0 =A0 =A0=A0=A0translation to IP= v4.=0A>>=0A>> Regarding this draft, it would be useful to explain why using= the=0A>> entire packet (or a hash thereof) isn't nearly as useful in most = cases=0A>> (and that would not require a new ID).=0A>>=0A>> Again, note tha= t most IPv4 implementations do not implement the ID=0A>> uniqueness require= ments in RFC791, and some use repeated IDs (even=0A>> that don't compress h= eaders).=0A>>=0A>> Joe=0A>>=0A>>=0A>>=0A>>=0A>> On 3/14/2013 2:52 PM, Nalin= i Elkins wrote:=0A>>=A0=A0=A0> Joel,=0A>>=A0=A0=A0>=0A>>=A0=A0=A0> Thanks s= o much for your feedback.=A0 One of the alternatives that we=0A>> are looki= ng at to provide a Packet Sequence Number is a 'SHIM' such as=0A>> that pro= vided by SEAL.=0A>>=A0=A0=A0>=0A>>=A0=A0=A0> http://tools.ietf.org/html//rf= c5320=0A>>=A0=A0=A0>=0A>>=A0=A0=A0> This header (if I am reading this corre= ctly!) would be between the=0A>> TCP or UDP header and the application payl= oad.=0A>>=A0=A0=A0>=0A>>=A0=A0=A0> One of the things that SEAL provides is:= =0A>>=A0=A0=A0>=0A>>=A0=A0=A0> SEAL_ID - a 32-bit Identification value, ran= domly initialized and=0A>> monotonically incremented for each SEAL protocol= packet=A0 >=A0 > So, this=0A>> might provide exactly what we are looking f= or!=0A>>=A0=A0=A0>=0A>>=A0=A0=A0> We do understand that there are a number = of issues with IPv6=0A>> extension headers.=A0 We are not wedded to a parti= cular implementation=0A>> and whatever will provide the information we need= is perfect!=A0 But, we=0A>> have just found out about this RFC and need to= study it more to see if=0A>> there are any drawbacks.=0A>>=A0=A0=A0>=0A>>= =A0=A0=A0> Thanks,=0A>>=A0=A0=A0>=0A>>=A0=A0=A0> Nalini Elkins=0A>>=A0=A0= =A0> Inside Products, Inc.=0A>>=A0=A0=A0> (831) 659-8360=0A>>=A0=A0=A0> www= .insidethestack.com =A0 >=A0 >=A0 >=A0 >=0A= >> ________________________________=A0 > From: joel jaeggli=0A>> >=A0 > To: IPv6 Ops WG=0A>> >=A0 > Sent: Thursday, March 14,=0A>> 2013 8:13 AM= =A0 > Subject: [v6ops]=0A>> draft-elkins-v6ops-ipv6-ipid-needed-00=0A>>=A0= =A0=A0>=0A>>=A0=A0=A0> some more thoughts since the presentation.=0A>>=A0= =A0=A0>=0A>>=A0=A0=A0> Noted that I consulted the earlier draft, discussion= in 6-man and=0A>> appendix a in the slides.=0A>>=A0=A0=A0>=0A>>=A0=A0=A0>= =0A>> http://tools.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header-0= 0=0A>>=A0=A0=A0>=0A>>=A0=A0=A0> was the previous one.=0A>>=A0=A0=A0>=0A>>= =A0=A0=A0> The request is not really for the ipv4 IPID/frag header in v6. i= t's=0A>> for a unique per packet value over a given sample interval.=0A>>= =A0=A0=A0>=0A>>=A0=A0=A0> The utility of ipid in ipv4 for this context has = eroded over time,=0A>> (this is not knock againt the draft I'm just trying = to describe my=0A>> understanding of the utility). IPID's in the context of= mobile=0A>> phones/mobile networks are typically unvarrying (due to header= =0A>> compresssion). rfc 6864 exists because modern implmentations cannot= =0A>> (and therefore don't) honor requirements for uniqueness in=0A>> rfc79= 1,rfc1122 e.g. the duration over which 16 bit IPID is valid for=0A>> unique= ness is bounded by the size of the flow because if it were=0A>> limited by = the MDL it would limit that speed of a flow. a 10Gb/s flow=0A>> with 1500 b= yte packets overflows a 16 bit value every 78 or so ms. if=0A>> your captur= e is longer than that you can reasonably expect duplicate=0A>> IPIDS to sho= w up which are readily identifiable as not being duplicate packets.=0A>>=A0= =A0=A0>=0A>>=A0=A0=A0> desirable properties of a unique per packet value to= my mind...=0A>>=A0=A0=A0>=0A>>=A0=A0=A0> * That it doesn't cost us anythin= g - it strikes me as undesirable=0A>> that packets should in general have l= arger headers then they do today=0A>> that adds cost all over the place. ex= tension header processing or=0A>> indeed fragmentation header use has conqu= ences.=0A>>=A0=A0=A0>=0A>>=A0=A0=A0> see http://tools.ietf.org/html/draft-w= kumari-long-headers-00=0A>>=A0=A0=A0>=0A>>=A0=A0=A0> for dicussion that has= come up about header processing in modern routers.=0A>>=A0=A0=A0>=0A>>=A0= =A0=A0> and=0A>>=A0=A0=A0>=0A>>=A0=A0=A0> http://tools.ietf.org/html/draft-= taylor-v6ops-fragdrop-00=0A>>=A0=A0=A0>=0A>>=A0=A0=A0> for a similar discus= sion about fragmentation headers.=0A>>=A0=A0=A0>=0A>>=A0=A0=A0> neither of = these represent any form of consensus document, so take=0A>> that with a gr= ain of salt.=0A>>=A0=A0=A0>=0A>>=A0=A0=A0> * That it is applied to every pa= cket - part of the stated utility=0A>> of the ipv4 ipid is that it's presen= t (with my noted caveats) you=0A>> don't have to turn it on. likewise this = implies that the application=0A>> of the value does not impact the observat= ion, having the packet size=0A>> change because you're doing debugging mean= s imho that you're not doing=0A>> the=A0 > ________________________________= _______________=0A>>=A0=A0=A0> v6ops mailing list=0A>>=A0=A0=A0> v6ops@ietf= .org =A0 >=0A>> https://www.ietf.org/mailman/listinf= o/v6ops=0A>>=A0=A0=A0> _______________________________________________=0A>>= =A0=A0=A0> v6ops mailing list=0A>>=A0=A0=A0> v6ops@ietf.org =A0 >=0A>> https://www.ietf.org/mailman/listinfo/v6ops=0A>>=A0=A0= =A0>=0A>>=0A>>=0A> _______________________________________________=0A> v6op= s mailing list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman/listinfo= /v6ops=0A>=0A>=0A> The information contained in this communication is highl= y confidential and is intended solely for the use of the individual(s) to w= hom this communication is directed. If you are not the intended recipient, = you are hereby notified that any viewing, copying, disclosure or distributi= on of this information is prohibited. Please notify the sender, by electron= ic mail or telephone, of any unintended receipt and delete the original mes= sage without making any copies.=0A>=0A>=A0=A0=A0Blue Cross Blue Shield of M= ichigan and Blue Care Network of Michigan are nonprofit corporations and in= dependent licensees of the Blue Cross and Blue Shield Association.=0A> From v6ops@globis.net Tue Mar 19 06:11:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D3521F8714 for ; Tue, 19 Mar 2013 06:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+ellMua7JGb for ; Tue, 19 Mar 2013 06:11:44 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7C51D21F87B6 for ; Tue, 19 Mar 2013 06:11:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 246528700EA; Tue, 19 Mar 2013 14:11:27 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+ltHHE9OxGF; Tue, 19 Mar 2013 14:10:57 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 3DECF8700CA; Tue, 19 Mar 2013 14:10:57 +0100 (CET) Message-ID: <514863DB.4000507@globis.net> Date: Tue, 19 Mar 2013 14:10:51 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops WG Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 13:11:45 -0000 Fred Baker (fred) wrote: > In the meeting at IETF 86, we discussed > > http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis > http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis > "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang, > Cameron Byrne, 25-Feb-13 > > and the hum supported making that a working group draft. In this note, I'm asking for ratification on the list - whether you agree or disagree, I'd appreciate your thoughts. I have a problem with "BCP" status for any draft recommending use of ULA on Internet connected networks without some health warning, because I'm not yet convinced that this may not end up being harmful [highly mobile devices, split horizon, caching]. But let's see where the draft goes from here. regards, RayH From touch@isi.edu Tue Mar 19 07:41:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA9B21F89D7 for ; Tue, 19 Mar 2013 07:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QHV1CPei5xB for ; Tue, 19 Mar 2013 07:41:21 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 98C3621F8574 for ; Tue, 19 Mar 2013 07:41:21 -0700 (PDT) Received: from [192.168.1.96] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r2JEephi007061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Mar 2013 07:40:54 -0700 (PDT) Message-ID: <514878F6.9090903@isi.edu> Date: Tue, 19 Mar 2013 07:40:54 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Mark Andrews References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <2134F8430051B64F815C691A62D9831802FB9D@XCH-BLV-504.nw.nos.boeing.com> <51431F7E.3090502@viagenie.ca> <51434F97.7080505@isi.edu> <51435158.1010006@viagenie.ca> <514360A2.2040800@isi.edu> <2134F8430051B64F815C691A62D983180319A7@XCH-BLV-504.nw.nos.boeing.com> <51473BC5.4020905@isi.edu> <2134F8430051B64F815C691A62D98318031A47@XCH-BLV-504.nw.nos.boeing.com> <51477C55.7030900@isi.edu> <20130318233942.E8657312E1B9@drugs.dv.isc.org> <5147A6F3.4040301@isi.edu> <20130318235826.7BE8C312E98D@drugs.dv.isc.org> <5147AB88.6060105@isi.edu> <20130319005007.664D7312EF70@drugs.dv.isc.org> In-Reply-To: <20130319005007.664D7312EF70@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 14:41:22 -0000 On 3/18/2013 5:50 PM, Mark Andrews wrote: ... >> I disagree that it needs to preserve the fragmentation; it needs to >> preserve the fragment signalling and behavior together. Sometimes that >> means preserving fragmentation, but other times not. > > And how can a NAT know if it can *safely* reassemble and do its own > fragmentation? It can't. Since it can't it needs to preserve > fragmentation. A NAT creates packets with its own IP address. A NAT creates packets spoofed from external addresses. A NAT sinks (consumes) packets to its IP address. A NAT sinks packets by spoofing external addresses. Once a fragment goes through a NAT, the information needed to reassemble has been destroyed (in either direction). The NAT is the only device that can address that issue, and only by reassembling (or virtually reassemblying) the packet. Fred spoke of the utility of keeping the original fragment boundaries; we can debate whether this is meaningful when PTBs aren't relayed across a NAT. However, virtual reassembly is just reassembly and refragmentation that retains those boundaries - if all the fragments aren't seen, the packet is dropped just as if real reassembly were used. So the difference is only in the boundaries. Either way, a NAT that doesn't reassemble (one way or the other) creates fragments that are useless anyway. Joe From Fred.L.Templin@boeing.com Tue Mar 19 07:56:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967E321F8C77 for ; Tue, 19 Mar 2013 07:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] 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 V-j-nINjfn7t for ; Tue, 19 Mar 2013 07:56:19 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2E68C21F8C45 for ; Tue, 19 Mar 2013 07:56:18 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r2JEuIt3014412 for ; Tue, 19 Mar 2013 09:56:18 -0500 Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r2JEuGcL014380 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 19 Mar 2013 09:56:17 -0500 Received: from XCH-BLV-305.nw.nos.boeing.com (130.247.25.217) by XCH-NWHT-02.nw.nos.boeing.com (130.247.70.248) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 19 Mar 2013 07:56:16 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.214]) by XCH-BLV-305.nw.nos.boeing.com ([169.254.5.221]) with mapi id 14.02.0328.011; Tue, 19 Mar 2013 07:56:15 -0700 From: "Templin, Fred L" To: Nalini Elkins , Nick Hilliard , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Thread-Index: AQHOJDuUpovTMHVwr0KJKw2dWHfftZitGHDQ Date: Tue, 19 Mar 2013 14:56:14 +0000 Message-ID: <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> In-Reply-To: <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D98318032BD5XCHBLV504nwnosboe_" MIME-Version: 1.0 X-TM-AS-MML: No Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 14:56:20 -0000 --_000_2134F8430051B64F815C691A62D98318032BD5XCHBLV504nwnosboe_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmFsaW5pDQoNCknigJlsbCBhZ3JlZSB0aGF0IHlvdSBjYW4gY29uc3RydWN0IGFuIGV4YW1w bGUgc2hvd2luZyBhIHBhaXIgb2YgcGFja2V0cyB3aXRoIHRoZQ0Kc2FtZSAoc3JjLCBkc3QsIHNl cSwgYWNrKS10dXBsZSB5ZXQgdGhlIHBhY2tldHMgYXJlIG5vdCBkdXBsaWNhdGVzLiBCdXQsIGRp YWdub3N0aWNzDQpjYW7igJl0IGJlIGxpbWl0ZWQgdG8gYW4gaXNvbGF0ZWQgcGFpciBvZiBwYWNr ZXRzIGFuZCBuZWVkIHRvIG9ic2VydmUgYSB0cmVuZCBvdmVyDQptYW55IHBhY2tldHMuIEFnYWlu LCBkaWFnbm9zdGljIHRvb2xzIGxpa2UgV2lyZXNoYXJrIHNlZW0gdG8gYmUgYWxyZWFkeSBwcm9k dWNpbmcNCmVmZmVjdGl2ZSBkaWFnbm9zdGljcyBiYXNlZCBqdXN0IG9uIHRoZSBpbmZvcm1hdGlv biBhdCBoYW5kIOKAkyBJIHJlY2VudGx5IHVzZWQgdGhlDQp0b29sIHRvIGlkZW50aWZ5IGEgY2Fz ZSBvZiBpbi10aGUtbmV0d29yayBwYWNrZXQgZHVwbGljYXRpb24gd2l0aGluIG91ciBuZXR3b3Jr Lg0KRG9lcyBhbnlvbmUga25vdyB3aGF0IHRoZSBXaXJlc2hhcmsgdGVhbSB0aGlua3MgYWJvdXQg dGhpcz8NCg0KVGhhbmtzIC0gRnJlZA0KDQpGcm9tOiBOYWxpbmkgRWxraW5zIFttYWlsdG86bmFs aW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb21dDQpTZW50OiBNb25kYXksIE1hcmNoIDE4LCAy MDEzIDU6NDkgUE0NClRvOiBUZW1wbGluLCBGcmVkIEw7IE5pY2sgSGlsbGlhcmQ7IHY2b3BzQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1lbGtpbnMtdjZvcHMtaXB2Ni1pcGlk LW5lZWRlZC0wMA0KDQpGcmVkLA0KDQpUQ1Agc2VxdWVuY2UgbnVtYmVyIGlzIG5vdCBlbm91Z2gg YmVjYXVzZSB0aGVyZSBjYW4gYmUgZHVwbGljYXRlIHNlZ21lbnRzIGFuZCByZXRyYW5zbWlzc2lv bnMuICAgV2UgbmVlZCBhIHdheSB0byBzZWUgaWYgdGhlc2UgYXJlIHJlYWxseSBzZW50IGJ5IHRo ZSBkZXZpY2Ugb3IgaWYgdGhleSBhcmUganVzdCBhIHByb2JsZW0gaW4gcGFja2V0IHRyYWNpbmcu DQoNCkFsc28sIGluIHRoZSBjYXNlIG9mIHJlc2V0cywgdGhlIFNFUSBhbmQgQUNLIG1heSBhbHNv IGJlIGR1cGxpY2F0ZWQuICBMZXQgbWUgZ2l2ZSB5b3UgcmVhbCBleGFtcGxlOg0KDQpwa3QgMTog c2VxIG5vOiAxMjMgICAgYWNrOiAzNDUgICAgIHR0bDogNjAgICAgIElQSUQ6IDEyMyAgICAgICAg c3JjIGFkZHI6IDEuMi4zLjQgICAgZGVzdCBhZGRyIDogNC41LjYuNw0KcGt0IDI6IHNlcSBubzog MTIzICAgIGFjazogMzQ1ICAgICB0dGw6IDI1NCAgIElQSUQ6ICBGRjJBICAgICBzcmMgYWRkcjog MS4yLjMuNCAgIGRlc3QgYWRkcjogIDQuNS42LjcgICBUQ1AgUkVTRVQgZmxhZyBzZXQNCg0KVGhl IHRpbWUgYmV0d2VlbiB0aGVzZSB0d28gcGFja2V0cyBpcyBxdWl0ZSBzbWFsbC4gIFRoZXkgaGF2 ZSBhbHNvIGJlZW4gaGF2aW5nIHByb2JsZW1zIHdpdGggY29ubmVjdGlvbnMgZmFpbGluZy4NCg0K TXkgY29uY2x1c2lvbiB3b3VsZCBiZSB0aGF0IHRoZSBzZWNvbmQgcGFja2V0IHdhcyBOT1Qgc2Vu dCBieSB0aGUgc2FtZSBkZXZpY2UgdGhhdCBzZW50IHRoZSBmaXJzdC4gIFdoeT8gIEJlY2F1c2Ug Qk9USCBJUElEIGFuZCBUVEwgYXJlIHF1aXRlIGRpZmZlcmVudC4gIFZlcnkgdW5saWtlbHkgdGhh dCB0aGUgb3JpZ2luYXRpbmcgZGV2aWNlIGlzIGdvaW5nIHRvIGNoYW5nZSBCT1RIIHRoYXQgcXVp Y2tseS4gIEkgd291bGQgY29uY2x1ZGUgdGhhdCB0aGVyZSBpcyBhIGJveCBpbiB0aGUgbWlkZGxl IHNlbmRpbmcgYSBSRVNFVCBmb3IgdGhhdCBzZXNzaW9uLiAgQW5kLCBhY3R1YWxseSwgd2hlbiB3 ZSByZXBsYWNlZCB0aGUgZGV2aWNlIHRoYXQgd2UgZmVsdCB3YXMgdGhlIHByb2JsZW0sIHNlc3Np b25zIHN0YXllZCB1cCENCg0KVGhpcyBpcyBqdXN0IG9uZSBjYXNlLiAgSW4gb3VyIGRyYWZ0LCB3 ZSBoYWQgcXVpdGUgYSBmZXcgb3RoZXJzLCBhcyB5b3UgcmVtZW1iZXIgZnJvbSB0aGUgcHJlc2Vu dGF0aW9uLg0KDQpEZWZpbml0ZWx5LCB3ZSBuZWVkIGEgc2VxdWVuY2UgbnVtYmVyIGZpZWxkIHRo YXQgaXMgbW9yZSB0aGFuIDE2IGJpdHMuICBXcmFwcGluZyBpcyBhIHByb2JsZW0uDQoNCkJ1dCwg dGhlIHBvaW50IGlzIHdlbGwgdGFrZW4gdGhhdCB0aGUgZG93biBzaWRlIG9mIGEgU0hJTSBpcyB0 aGF0IGJvdGggc2lkZXMgaGF2ZSB0byBpbXBsZW1lbnQuICBOb3RlZC4NCg0KDQpUaGFua3MsDQpO YWxpbmkgRWxraW5zDQpJbnNpZGUgUHJvZHVjdHMsIEluYy4NCig4MzEpIDY1OS04MzYwDQp3d3cu aW5zaWRldGhlc3RhY2suY29tPGh0dHA6Ly93d3cuaW5zaWRldGhlc3RhY2suY29tPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206ICJUZW1wbGluLCBGcmVkIEwiIDxGcmVk LkwuVGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPj4N ClRvOiBOYWxpbmkgRWxraW5zIDxuYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbTxtYWls dG86bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb20+PjsgTmljayBIaWxsaWFyZCA8bmlj a0BpbmV4LmllPG1haWx0bzpuaWNrQGluZXguaWU+PjsgInY2b3BzQGlldGYub3JnPG1haWx0bzp2 Nm9wc0BpZXRmLm9yZz4iIDx2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+Pg0K U2VudDogTW9uZGF5LCBNYXJjaCAxOCwgMjAxMyAzOjUzIFBNDQpTdWJqZWN0OiBSRTogW3Y2b3Bz XSBkcmFmdC1lbGtpbnMtdjZvcHMtaXB2Ni1pcGlkLW5lZWRlZC0wMA0KDQpIaSBOYWxpbmksDQoN CkZvciBhIHNoaW0gaGVhZGVyIGJldHdlZW4gdGhlIHRyYW5zcG9ydCBhbmQgdGhlIGFwcGxpY2F0 aW9uIGRhdGEsIFRDUCBwcm92aWRlcw0KVENQIG9wdGlvbnMgc28geW91IGNvdWxkIGNvbnNpZGVy IGEgbmV3IFRDUCBvcHRpb24uIEJ1dCwgVENQIGFscmVhZHkgaW5jbHVkZXMNCnNlcXVlbmNlIG51 bWJlcnMgdGhhdCBjYW4gYmUgdXNlZCBmb3IgZGlhZ25vc3RpYyBwdXJwb3NlcyDigJMgaW4gZmFj dCwgV2lyZXNoYXJrDQooYW5kIEnigJltIHN1cmUgb3RoZXIgbmV0d29yayBkaWFnbm9zdGljIHRv b2xzKSBhbHJlYWR5IHVzZSB0aGF0LiBTbywgSSBkb27igJl0IHNlZQ0KYSBzaGltIGFzIGEgYmln IHdpbiBmb3IgVENQLg0KDQpGb3IgVURQLCB0aGVyZSB3b3VsZCBuZWVkIHRvIGJlIGEgbmV3IFVE UCBwb3J0IG51bWJlciBhc3NpZ25tZW50LCBhbmQgYQ0KbmV3IHBpZWNlIG9mIGNvZGUgYXQgYm90 aCB0aGUgc291cmNlIGFuZCBkZXN0aW5hdGlvbi4gVGhlIHNvdXJjZSB3b3VsZCBoYXZlDQp0byBp bnNlcnQgdGhlIHNoaW0gYWJvdXQgdGhlIFVEUCBoZWFkZXIsIGFuZCB0aGUgZGVzdGluYXRpb24g d291bGQgaGF2ZSB0bw0KcmVtb3ZlIGl0LiBUaGF0IGlzIHRoZSBzYW1lIG1vZGVsIHRoYXQgU0VB TCBpcyBhZGRyZXNzaW5nLCBidXQgU0VBTCBpcyBleHBlY3RpbmcNCmJvdGggZW5kcyB0byBpbXBs ZW1lbnQgdGhlIHByb3RvY29sLiBTbywgdW5mb3J0dW5hdGVseSwgdGhlcmUgaXMgbm8gd2F5IHRv DQpoYXZlIGEgc291cmNlLW9ubHkgcGF0Y2ggdGhhdCBkb2VzIG5vdCBhbHNvIHJlcXVpcmUgYSBw YXRjaCBhdCB0aGUgZGVzdGluYXRpb24uDQoNClRoYW5rcyAtIEZyZWQNCg0KDQpGcm9tOiB2Nm9w cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRv OnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOYWxpbmkgRWxraW5zDQpTZW50 OiBNb25kYXksIE1hcmNoIDE4LCAyMDEzIDM6NDAgUE0NClRvOiBOaWNrIEhpbGxpYXJkOyB2Nm9w c0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBk cmFmdC1lbGtpbnMtdjZvcHMtaXB2Ni1pcGlkLW5lZWRlZC0wMA0KDQpOaWNrLA0KDQpUb3RhbGx5 IGFncmVlIHdpdGggeW91IGFib3V0IHRyeWluZyB0byB1bmRlcnN0YW5kIGVhY2ggb3RoZXIncyBw b2ludCBvZiB2aWV3LiAgIFdlIGFic29sdXRlbHkgd2FudCB0byBkbyB0aGF0LiAgIEkgdGhpbmsg TWlrZSB3YXMgcmVzcG9uZGluZyB0byB0aGUgY29tbWVudCBvbiB0aGUgbmVlZCBmb3IgSVBJRCBp dHNlbGYuDQoNCkFzIGZhciBhcyBhIHNvbHV0aW9uLCB3ZSBhcmUgdGhpbmtpbmcgdGhhdCBJUHY2 IGV4dGVuc2lvbiBoZWFkZXJzIGFyZSBhIG5vbi1zdGFydGVyLiAgRm9yIGFsbCB0aGUgcmVhc29u cyB0aGF0IGhhdmUgYmVlbiBicm91Z2h0IHVwLg0KDQpTbywgd2UgYXJlIHRoaW5raW5nIG9mIGEg aGVhZGVyIGhpZ2hlciB1cCB0aGUgbGF5ZXJzLiAgIEZvciBleGFtcGxlLCBiZXR3ZWVuIHRoZSBU cmFuc3BvcnQgTGF5ZXIgKFRDUCAvIFVEUCkgYW5kIHRoZSBhcHBsaWNhdGlvbiBwYXlsb2FkLg0K DQpXaGF0IGFyZSBvcGluaW9ucyBmcm9tIHBlb3BsZSBvbiB0aGF0Pw0KDQoNClRoYW5rcywNCk5h bGluaSBFbGtpbnMNCkluc2lkZSBQcm9kdWN0cywgSW5jLg0KKDgzMSkgNjU5LTgzNjANCnd3dy5p bnNpZGV0aGVzdGFjay5jb208aHR0cDovL3d3dy5pbnNpZGV0aGVzdGFjay5jb20vPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IE5pY2sgSGlsbGlhcmQgPG5pY2tAaW5l eC5pZTxtYWlsdG86bmlja0BpbmV4LmllPj4NClRvOiB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZv cHNAaWV0Zi5vcmc+DQpTZW50OiBNb25kYXksIE1hcmNoIDE4LCAyMDEzIDI6NTYgUE0NClN1Ympl Y3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWVsa2lucy12Nm9wcy1pcHY2LWlwaWQtbmVlZGVkLTAwDQoN Ck9uIDE4LzAzLzIwMTMgMjE6MzcsIEFja2VybWFubiwgTWljaGFlbCB3cm90ZToNCj4gU2luY2Ug YmVnaW5uaW5nIHRvIGV4cGxvcmUgdGhpcyBpc3N1ZSBvZiBJUElELCBpdCBoYXMgYmVjb21lIGNs ZWFyIGhvdw0KPiB2YWx1YWJsZSBJUElEIGhhcyBiZWVuIHRvIG91ciBvcmdhbml6YXRpb24gYW5k IG1hbnkgbGlrZSB1cy4gICAgSSBoYXZlDQo+IHBlcnNvbmFsbHkgbm90IHRhbGtlZCB3aXRoIGV2 ZXJ5b25lIGFib3V0IHRoaXMsIGJ1dCB0byB0aG9zZSBJIGhhdmUsIHRoZQ0KPiBwcmVwb25kZXJh bmNlIHdvdWxkIG5vdCBsaWtlIHRvIHNlZSB0aGlzIGJlbmVmaWNpYWwgZGlhZ25vc3RpYyBmZWF0 dXJlDQo+IGxvc3QuDQoNCk1pa2UsIE5hbGluaSwNCg0KSSB1bmRlcnN0YW5kIHRoYXQgdXNpbmcg SVBJRCB3b3JrcyBmb3IgeW91IHdoZW4gZGlhZ25vc2luZyBjb25uZWN0aXZpdHkNCnByb2JsZW1z IGluIGlwdjQuICBEbyB5b3UgdW5kZXJzdGFuZCB0aGF0IGlwdjYgZXh0ZW5zaW9uIGhlYWRlcnMg Y2F1c2UNCm1hc3NpdmUgb3BlcmF0aW9uYWwgaGVhZGFjaGVzIHdoaWNoIHdlIGNhbm5vdCBnZXQg YXJvdW5kIHVzaW5nIHRvZGF5J3MNCnRlY2hub2xvZ3k/ICBBbmQgdGhhdCBhcyBhIHdvcmtpbmcg Z3JvdXAsIHRoZSBvcGVyYXRpb25hbCBwZW9wbGUgaGVyZSBhcmUNCmJhdWxraW5nIGF0IHRoZSBp ZGVhIG9mIGNyZWF0aW5nIG1vcmUgZXh0ZW5zaW9uIGhlYWRlcnMgYmVjYXVzZSBpdCBtYWtlcw0K b3VyIGxpdmVzIG1hc3NpdmVseSBtb3JlIGRpZmZpY3VsdD8NCg0KSWYgZXZlcnlvbmUgZG9lc24n dCB1bmRlcnN0YW5kIGVhY2ggb3RoZXJzJyBwb2ludHMgb2YgdmlldywgdGhpcw0KY29udmVyc2F0 aW9uIGlzIGdvaW5nIHRvIGNvbnRpbnVlIHJ1bm5pbmcgYXJvdW5kIGluIGNpcmNsZXMsIGNhdXNp bmcNCm5vdGhpbmcgYnV0IGZydXN0cmF0aW9uLg0KDQpOaWNrDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3Bz QGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdjZvcHMNCg0K --_000_2134F8430051B64F815C691A62D98318032BD5XCHBLV504nwnosboe_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC55aXY4MTMwNTA1 NjZtc29hY2V0YXRlLCBsaS55aXY4MTMwNTA1NjZtc29hY2V0YXRlLCBkaXYueWl2ODEzMDUwNTY2 bXNvYWNldGF0ZQ0KCXttc28tc3R5bGUtbmFtZTp5aXY4MTMwNTA1NjZtc29hY2V0YXRlOw0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLnlpdjgxMzA1MDU2Nm1z b25vcm1hbCwgbGkueWl2ODEzMDUwNTY2bXNvbm9ybWFsLCBkaXYueWl2ODEzMDUwNTY2bXNvbm9y bWFsDQoJe21zby1zdHlsZS1uYW1lOnlpdjgxMzA1MDU2Nm1zb25vcm1hbDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC55aXY4MTMwNTA1NjZtc29jaHBkZWZh dWx0LCBsaS55aXY4MTMwNTA1NjZtc29jaHBkZWZhdWx0LCBkaXYueWl2ODEzMDUwNTY2bXNvY2hw ZGVmYXVsdA0KCXttc28tc3R5bGUtbmFtZTp5aXY4MTMwNTA1NjZtc29jaHBkZWZhdWx0Ow0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLnlpdjgxMzA1MDU2 Nm1zb2h5cGVybGluaw0KCXttc28tc3R5bGUtbmFtZTp5aXY4MTMwNTA1NjZtc29oeXBlcmxpbms7 fQ0Kc3Bhbi55aXY4MTMwNTA1NjZtc29oeXBlcmxpbmtmb2xsb3dlZA0KCXttc28tc3R5bGUtbmFt ZTp5aXY4MTMwNTA1NjZtc29oeXBlcmxpbmtmb2xsb3dlZDt9DQpzcGFuLnlpdjgxMzA1MDU2NmVt YWlsc3R5bGUxNw0KCXttc28tc3R5bGUtbmFtZTp5aXY4MTMwNTA1NjZlbWFpbHN0eWxlMTc7fQ0K c3Bhbi55aXY4MTMwNTA1NjZiYWxsb29udGV4dGNoYXINCgl7bXNvLXN0eWxlLW5hbWU6eWl2ODEz MDUwNTY2YmFsbG9vbnRleHRjaGFyO30NCnAueWl2ODEzMDUwNTY2bXNvbm9ybWFsMSwgbGkueWl2 ODEzMDUwNTY2bXNvbm9ybWFsMSwgZGl2LnlpdjgxMzA1MDU2Nm1zb25vcm1hbDENCgl7bXNvLXN0 eWxlLW5hbWU6eWl2ODEzMDUwNTY2bXNvbm9ybWFsMTsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi55aXY4MTMwNTA1NjZtc29oeXBlcmxpbmsxDQoJe21z by1zdHlsZS1uYW1lOnlpdjgxMzA1MDU2Nm1zb2h5cGVybGluazE7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4ueWl2ODEzMDUwNTY2bXNvaHlwZXJsaW5r Zm9sbG93ZWQxDQoJe21zby1zdHlsZS1uYW1lOnlpdjgxMzA1MDU2Nm1zb2h5cGVybGlua2ZvbGxv d2VkMTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLnlp djgxMzA1MDU2Nm1zb2FjZXRhdGUxLCBsaS55aXY4MTMwNTA1NjZtc29hY2V0YXRlMSwgZGl2Lnlp djgxMzA1MDU2Nm1zb2FjZXRhdGUxDQoJe21zby1zdHlsZS1uYW1lOnlpdjgxMzA1MDU2Nm1zb2Fj ZXRhdGUxOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi55aXY4 MTMwNTA1NjZlbWFpbHN0eWxlMTcxDQoJe21zby1zdHlsZS1uYW1lOnlpdjgxMzA1MDU2NmVtYWls c3R5bGUxNzE7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4ueWl2ODEzMDUwNTY2YmFsbG9vbnRleHRjaGFyMQ0KCXttc28tc3R5bGUt bmFtZTp5aXY4MTMwNTA1NjZiYWxsb29udGV4dGNoYXIxOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQpwLnlpdjgxMzA1MDU2Nm1zb2NocGRlZmF1bHQxLCBsaS55aXY4MTMw NTA1NjZtc29jaHBkZWZhdWx0MSwgZGl2LnlpdjgxMzA1MDU2Nm1zb2NocGRlZmF1bHQxDQoJe21z by1zdHlsZS1uYW1lOnlpdjgxMzA1MDU2Nm1zb2NocGRlZmF1bHQxOw0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUzMQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SGkgTmFsaW5pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J4oCZbGwgYWdyZWUgdGhhdCB5b3UgY2FuIGNvbnN0 cnVjdCBhbiBleGFtcGxlIHNob3dpbmcgYSBwYWlyIG9mIHBhY2tldHMgd2l0aCB0aGU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+c2FtZSAoc3JjLCBkc3QsIHNlcSwgYWNrKS10dXBsZSB5 ZXQgdGhlIHBhY2tldHMgYXJlIG5vdCBkdXBsaWNhdGVzLiBCdXQsIGRpYWdub3N0aWNzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmNhbuKAmXQgYmUgbGltaXRlZCB0byBhbiBpc29sYXRl ZCBwYWlyIG9mIHBhY2tldHMgYW5kIG5lZWQgdG8gb2JzZXJ2ZSBhIHRyZW5kIG92ZXI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+bWFueSBwYWNrZXRzLiBBZ2FpbiwgZGlhZ25vc3RpYyB0 b29scyBsaWtlIFdpcmVzaGFyayBzZWVtIHRvIGJlIGFscmVhZHkgcHJvZHVjaW5nPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmVmZmVjdGl2ZSBkaWFnbm9zdGljcyBiYXNlZCBqdXN0IG9u IHRoZSBpbmZvcm1hdGlvbiBhdCBoYW5kIOKAkyBJIHJlY2VudGx5IHVzZWQgdGhlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnRvb2wgdG8gaWRlbnRpZnkgYSBjYXNlIG9mIGluLXRoZS1u ZXR3b3JrIHBhY2tldCBkdXBsaWNhdGlvbiB3aXRoaW4gb3VyIG5ldHdvcmsuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkRvZXMgYW55b25lIGtub3cgd2hhdCB0aGUgV2lyZXNoYXJrIHRl YW0gdGhpbmtzIGFib3V0IHRoaXM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgLSBGcmVkPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE5hbGluaSBFbGtpbnMgW21haWx0bzpu YWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25k YXksIE1hcmNoIDE4LCAyMDEzIDU6NDkgUE08YnI+DQo8Yj5Ubzo8L2I+IFRlbXBsaW4sIEZyZWQg TDsgTmljayBIaWxsaWFyZDsgdjZvcHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFt2Nm9wc10gZHJhZnQtZWxraW5zLXY2b3BzLWlwdjYtaXBpZC1uZWVkZWQtMDA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5GcmVkLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRDUCBzZXF1ZW5jZSBudW1i ZXIgaXMgbm90IGVub3VnaCBiZWNhdXNlIHRoZXJlIGNhbiBiZSBkdXBsaWNhdGUgc2VnbWVudHMg YW5kIHJldHJhbnNtaXNzaW9ucy4gJm5ic3A7IFdlIG5lZWQgYSB3YXkgdG8gc2VlIGlmIHRoZXNl IGFyZSByZWFsbHkgc2VudCBieSB0aGUgZGV2aWNlIG9yDQogaWYgdGhleSBhcmUganVzdCBhIHBy b2JsZW0gaW4gcGFja2V0IHRyYWNpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ QWxzbywgaW4gdGhlIGNhc2Ugb2YgcmVzZXRzLCB0aGUgU0VRIGFuZCBBQ0sgbWF5IGFsc28gYmUg ZHVwbGljYXRlZC4gJm5ic3A7TGV0IG1lIGdpdmUgeW91IHJlYWwgZXhhbXBsZTo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5wa3QgMTogc2VxIG5vOiAxMjMgJm5ic3A7ICZuYnNwO2Fj azogMzQ1ICZuYnNwOyAmbmJzcDsgdHRsOiA2MCAmbmJzcDsgJm5ic3A7IElQSUQ6IDEyMyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzcmMgYWRkcjogMS4yLjMuNCAmbmJzcDsgJm5ic3A7ZGVz dCBhZGRyIDogNC41LjYuNyAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5wa3QgMjogc2VxIG5vOiAxMjMgJm5ic3A7ICZuYnNwO2FjazogMzQ1ICZuYnNwOyAm bmJzcDsgdHRsOiAyNTQgJm5ic3A7IElQSUQ6ICZuYnNwO0ZGMkEgJm5ic3A7ICZuYnNwOyBzcmMg YWRkcjogMS4yLjMuNCAmbmJzcDsgZGVzdCBhZGRyOiAmbmJzcDs0LjUuNi43ICZuYnNwOyBUQ1Ag UkVTRVQgZmxhZyBzZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGUgdGltZSBi ZXR3ZWVuIHRoZXNlIHR3byBwYWNrZXRzIGlzIHF1aXRlIHNtYWxsLiAmbmJzcDtUaGV5IGhhdmUg YWxzbyBiZWVuIGhhdmluZyBwcm9ibGVtcyB3aXRoIGNvbm5lY3Rpb25zIGZhaWxpbmcuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+TXkgY29uY2x1c2lvbiB3b3VsZCBiZSB0aGF0IHRo ZSBzZWNvbmQgcGFja2V0IHdhcyBOT1Qgc2VudCBieSB0aGUgc2FtZSBkZXZpY2UgdGhhdCBzZW50 IHRoZSBmaXJzdC4gJm5ic3A7V2h5PyAmbmJzcDtCZWNhdXNlIEJPVEggSVBJRCBhbmQgVFRMIGFy ZSBxdWl0ZSBkaWZmZXJlbnQuICZuYnNwO1ZlcnkgdW5saWtlbHkNCiB0aGF0IHRoZSBvcmlnaW5h dGluZyBkZXZpY2UgaXMgZ29pbmcgdG8gY2hhbmdlIEJPVEggdGhhdCBxdWlja2x5LiAmbmJzcDtJ IHdvdWxkIGNvbmNsdWRlIHRoYXQgdGhlcmUgaXMgYSBib3ggaW4gdGhlIG1pZGRsZSBzZW5kaW5n IGEgUkVTRVQgZm9yIHRoYXQgc2Vzc2lvbi4gJm5ic3A7QW5kLCBhY3R1YWxseSwgd2hlbiB3ZSBy ZXBsYWNlZCB0aGUgZGV2aWNlIHRoYXQgd2UgZmVsdCB3YXMgdGhlIHByb2JsZW0sIHNlc3Npb25z IHN0YXllZCB1cCE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGlzIGlzIGp1c3Qg b25lIGNhc2UuICZuYnNwO0luIG91ciBkcmFmdCwgd2UgaGFkIHF1aXRlIGEgZmV3IG90aGVycywg YXMgeW91IHJlbWVtYmVyIGZyb20gdGhlIHByZXNlbnRhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5EZWZpbml0ZWx5LCB3ZSBuZWVkIGEgc2VxdWVuY2UgbnVtYmVyIGZpZWxk IHRoYXQgaXMgbW9yZSB0aGFuIDE2IGJpdHMuICZuYnNwO1dyYXBwaW5nIGlzIGEgcHJvYmxlbS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5CdXQsIHRoZSBwb2ludCBpcyB3ZWxsIHRh a2VuIHRoYXQmbmJzcDt0aGUgZG93biBzaWRlIG9mIGEgU0hJTSBpcyB0aGF0IGJvdGggc2lkZXMg aGF2ZSB0byBpbXBsZW1lbnQuICZuYnNwO05vdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5OYWxpbmkg RWxraW5zPGJyPg0KSW5zaWRlIFByb2R1Y3RzLCBJbmMuPGJyPg0KKDgzMSkgNjU5LTgzNjA8YnI+ DQo8YSBocmVmPSJodHRwOi8vd3d3Lmluc2lkZXRoZXN0YWNrLmNvbSI+d3d3Lmluc2lkZXRoZXN0 YWNrLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNl bnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bh bj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ICZxdW90O1RlbXBsaW4sIEZy ZWQgTCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20i PkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208L2E+Jmd0Ozxicj4NCjxiPlRvOjwvYj4gTmFsaW5p IEVsa2lucyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5hbGluaS5lbGtpbnNAaW5zaWRldGhlc3RhY2su Y29tIj5uYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbTwvYT4mZ3Q7OyBOaWNrIEhpbGxp YXJkICZsdDs8YSBocmVmPSJtYWlsdG86bmlja0BpbmV4LmllIj5uaWNrQGluZXguaWU8L2E+Jmd0 OzsgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwv YT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5v cmc8L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTWFyY2ggMTgsIDIwMTMgMzo1 MyBQTTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3Y2b3BzXSBkcmFmdC1lbGtpbnMtdjZvcHMt aXB2Ni1pcGlkLW5lZWRlZC0wMDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBpZD0ieWl2ODEzMDUwNTY2Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5IaSBOYWxpbmksPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5Gb3IgYSBzaGltIGhlYWRlciBi ZXR3ZWVuIHRoZSB0cmFuc3BvcnQgYW5kIHRoZSBhcHBsaWNhdGlvbiBkYXRhLCBUQ1AgcHJvdmlk ZXM8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+VENQIG9w dGlvbnMgc28geW91IGNvdWxkIGNvbnNpZGVyIGEgbmV3IFRDUCBvcHRpb24uIEJ1dCwgVENQIGFs cmVhZHkgaW5jbHVkZXM8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFG NDk3RCI+c2VxdWVuY2UgbnVtYmVycyB0aGF0IGNhbiBiZSB1c2VkIGZvciBkaWFnbm9zdGljIHB1 cnBvc2VzIOKAkyBpbiBmYWN0LCBXaXJlc2hhcms8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6IzFGNDk3RCI+KGFuZCBJ4oCZbSBzdXJlIG90aGVyIG5ldHdvcmsgZGlhZ25v c3RpYyB0b29scykgYWxyZWFkeSB1c2UgdGhhdC4gU28sIEkgZG9u4oCZdCBzZWU8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+YSBzaGltIGFzIGEgYmlnIHdp biBmb3IgVENQLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+ Rm9yIFVEUCwgdGhlcmUgd291bGQgbmVlZCB0byBiZSBhIG5ldyBVRFAgcG9ydCBudW1iZXIgYXNz aWdubWVudCwgYW5kIGE8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFG NDk3RCI+bmV3IHBpZWNlIG9mIGNvZGUgYXQgYm90aCB0aGUgc291cmNlIGFuZCBkZXN0aW5hdGlv bi4gVGhlIHNvdXJjZSB3b3VsZCBoYXZlPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOiMxRjQ5N0QiPnRvIGluc2VydCB0aGUgc2hpbSBhYm91dCB0aGUgVURQIGhlYWRlciwg YW5kIHRoZSBkZXN0aW5hdGlvbiB3b3VsZCBoYXZlIHRvPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPnJlbW92ZSBpdC4gVGhhdCBpcyB0aGUgc2FtZSBtb2Rl bCB0aGF0IFNFQUwgaXMgYWRkcmVzc2luZywgYnV0IFNFQUwgaXMgZXhwZWN0aW5nPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPmJvdGggZW5kcyB0byBpbXBs ZW1lbnQgdGhlIHByb3RvY29sLiBTbywgdW5mb3J0dW5hdGVseSwgdGhlcmUgaXMgbm8gd2F5IHRv PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPmhhdmUgYSBz b3VyY2Utb25seSBwYXRjaCB0aGF0IGRvZXMgbm90IGFsc28gcmVxdWlyZSBhIHBhdGNoIGF0IHRo ZSBkZXN0aW5hdGlvbi48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5 N0QiPlRoYW5rcyAtIEZyZWQ8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9y OmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29s b3I6YmxhY2siPg0KPGEgaHJlZj0ibWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmciPnY2b3Bz LWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86djZvcHMtYm91bmNlc0BpZXRm Lm9yZyI+bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5OYWxpbmkgRWxraW5zPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTWFyY2ggMTgsIDIw MTMgMzo0MCBQTTxicj4NCjxiPlRvOjwvYj4gTmljayBIaWxsaWFyZDsgPGEgaHJlZj0ibWFpbHRv OnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFt2Nm9wc10gZHJhZnQtZWxraW5zLXY2b3BzLWlwdjYtaXBpZC1uZWVkZWQtMDA8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Y29sb3I6YmxhY2siPk5pY2ssPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPlRvdGFsbHkgYWdyZWUgd2l0aCB5 b3UgYWJvdXQgdHJ5aW5nIHRvIHVuZGVyc3RhbmQgZWFjaCBvdGhlcidzIHBvaW50IG9mIHZpZXcu ICZuYnNwOyBXZSBhYnNvbHV0ZWx5IHdhbnQgdG8gZG8gdGhhdC4gJm5ic3A7IEkgdGhpbmsgTWlr ZSB3YXMgcmVzcG9uZGluZyB0byB0aGUgY29tbWVudCBvbiB0aGUgbmVlZA0KIGZvciBJUElEIGl0 c2VsZi48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtjb2xvcjpibGFjayI+QXMgZmFyIGFzIGEgc29sdXRpb24sJm5ic3A7d2UgYXJlIHRo aW5raW5nIHRoYXQgSVB2NiBleHRlbnNpb24gaGVhZGVycyBhcmUgYSBub24tc3RhcnRlci4gJm5i c3A7Rm9yIGFsbCB0aGUgcmVhc29ucyB0aGF0IGhhdmUgYmVlbiBicm91Z2h0IHVwLjwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9y OmJsYWNrIj5TbywmbmJzcDt3ZSBhcmUgdGhpbmtpbmcgb2YgYSBoZWFkZXIgaGlnaGVyIHVwIHRo ZSBsYXllcnMuICZuYnNwOyBGb3IgZXhhbXBsZSwgYmV0d2VlbiB0aGUgVHJhbnNwb3J0IExheWVy IChUQ1AgLyBVRFApIGFuZCB0aGUgYXBwbGljYXRpb24gcGF5bG9hZC48L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+ V2hhdCBhcmUgb3BpbmlvbnMgZnJvbSBwZW9wbGUgb24gdGhhdD88L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPlRoYW5rcyw8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtjb2xvcjpibGFjayI+TmFsaW5pIEVsa2luczxicj4NCkluc2lkZSBQcm9kdWN0cywg SW5jLjxicj4NCig4MzEpIDY1OS04MzYwPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5pbnNpZGV0 aGVzdGFjay5jb20vIiB0YXJnZXQ9Il9ibGFuayI+d3d3Lmluc2lkZXRoZXN0YWNrLmNvbTwvYT48 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPg0KPGhyIHNpemU9IjEiIHdp ZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+IE5pY2sgSGlsbGlhcmQgJmx0OzxhIGhyZWY9 Im1haWx0bzpuaWNrQGluZXguaWUiIHRhcmdldD0iX2JsYW5rIj5uaWNrQGluZXguaWU8L2E+Jmd0 Ozxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+IDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1h cmNoIDE4LCAyMDEzIDI6NTYgUE08YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gZHJh ZnQtZWxraW5zLXY2b3BzLWlwdjYtaXBpZC1uZWVkZWQtMDA8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PGJyPg0KT24gMTgvMDMvMjAxMyAyMTozNywgQWNrZXJtYW5uLCBNaWNoYWVsIHdy b3RlOjxicj4NCiZndDsgU2luY2UgYmVnaW5uaW5nIHRvIGV4cGxvcmUgdGhpcyBpc3N1ZSBvZiBJ UElELCBpdCBoYXMgYmVjb21lIGNsZWFyIGhvdzxicj4NCiZndDsgdmFsdWFibGUgSVBJRCBoYXMg YmVlbiB0byBvdXIgb3JnYW5pemF0aW9uIGFuZCBtYW55IGxpa2UgdXMuJm5ic3A7ICZuYnNwOyBJ IGhhdmU8YnI+DQomZ3Q7IHBlcnNvbmFsbHkgbm90IHRhbGtlZCB3aXRoIGV2ZXJ5b25lIGFib3V0 IHRoaXMsIGJ1dCB0byB0aG9zZSBJIGhhdmUsIHRoZTxicj4NCiZndDsgcHJlcG9uZGVyYW5jZSB3 b3VsZCBub3QgbGlrZSB0byBzZWUgdGhpcyBiZW5lZmljaWFsIGRpYWdub3N0aWMgZmVhdHVyZTxi cj4NCiZndDsgbG9zdC48YnI+DQo8YnI+DQpNaWtlLCBOYWxpbmksPGJyPg0KPGJyPg0KSSB1bmRl cnN0YW5kIHRoYXQgdXNpbmcgSVBJRCB3b3JrcyBmb3IgeW91IHdoZW4gZGlhZ25vc2luZyBjb25u ZWN0aXZpdHk8YnI+DQpwcm9ibGVtcyBpbiBpcHY0LiZuYnNwOyBEbyB5b3UgdW5kZXJzdGFuZCB0 aGF0IGlwdjYgZXh0ZW5zaW9uIGhlYWRlcnMgY2F1c2U8YnI+DQptYXNzaXZlIG9wZXJhdGlvbmFs IGhlYWRhY2hlcyB3aGljaCB3ZSBjYW5ub3QgZ2V0IGFyb3VuZCB1c2luZyB0b2RheSdzPGJyPg0K dGVjaG5vbG9neT8mbmJzcDsgQW5kIHRoYXQgYXMgYSB3b3JraW5nIGdyb3VwLCB0aGUgb3BlcmF0 aW9uYWwgcGVvcGxlIGhlcmUgYXJlPGJyPg0KYmF1bGtpbmcgYXQgdGhlIGlkZWEgb2YgY3JlYXRp bmcgbW9yZSBleHRlbnNpb24gaGVhZGVycyBiZWNhdXNlIGl0IG1ha2VzPGJyPg0Kb3VyIGxpdmVz IG1hc3NpdmVseSBtb3JlIGRpZmZpY3VsdD88YnI+DQo8YnI+DQpJZiBldmVyeW9uZSBkb2Vzbid0 IHVuZGVyc3RhbmQgZWFjaCBvdGhlcnMnIHBvaW50cyBvZiB2aWV3LCB0aGlzPGJyPg0KY29udmVy c2F0aW9uIGlzIGdvaW5nIHRvIGNvbnRpbnVlIHJ1bm5pbmcgYXJvdW5kIGluIGNpcmNsZXMsIGNh dXNpbmc8YnI+DQpub3RoaW5nIGJ1dCBmcnVzdHJhdGlvbi48YnI+DQo8YnI+DQpOaWNrPGJyPg0K PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQp2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2134F8430051B64F815C691A62D98318032BD5XCHBLV504nwnosboe_-- From nalini.elkins@insidethestack.com Tue Mar 19 08:14:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2DD21F856E for ; Tue, 19 Mar 2013 08:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] 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 CF-kTSqxLXf0 for ; Tue, 19 Mar 2013 08:14:00 -0700 (PDT) Received: from nm6.access.bullet.mail.sp2.yahoo.com (nm6.access.bullet.mail.sp2.yahoo.com [98.139.44.133]) by ietfa.amsl.com (Postfix) with ESMTP id 576FA21F851F for ; Tue, 19 Mar 2013 08:13:59 -0700 (PDT) Received: from [98.139.44.102] by nm6.access.bullet.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 15:13:57 -0000 Received: from [98.139.44.84] by tm7.access.bullet.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 15:13:57 -0000 Received: from [127.0.0.1] by omp1021.access.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 15:13:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 355557.33780.bm@omp1021.access.mail.sp2.yahoo.com Received: (qmail 36559 invoked by uid 60001); 19 Mar 2013 15:13:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1363706036; bh=fp7rlu38OPxp2X5gnu7MCxqyHnIYVmEks/bixeNpcs0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=DKx0oD6zizDaA/P+441QitwGDM+2qGzuxqZEjTLqGUXoV4Rnb3mJ4S0tApjyqn6fy9zi66xKe8Tqjh22LdcHcvk3yxc2rg2xXpJ5ZOQJzawqqNyKdzYTDH42gU0c/FbAYP/KNTE33ksmELIqwL9nxvOBydyZZ+rVrgJ4kgqGlsU= X-YMail-OSG: JzZ6tfQVM1mL_ZIL4AdDcQLz17Ammh6PoTZphpOzF2_rfQw O9IpIKl9Dw0qZeMtyysY.ClanXLqId1yLHuo2H.ot9PXwr8Vm7jgJCsjSnm9 hLpZPBRf9krOzZM4fJDv0bG7LKKmIMp2fwVR6iHGRBtbDKQxgsOVJWplpE6P jERSk8NlsdUtCoO5PxbGk67sHwp9w4__c4l6TOZfjBXilpdlXvpfgkyP7JWD OtdRD_JEUX.X0san.1VRGhrJ7EOAaP3Mpwg042FpVJjFkb7r68bdVA9hqP_v rZN4gODz.hyj_l3f6NFNPfvfZBtJdyoIheIMOz4m81aKNLAi1G7Jn4qvSTlC wtgrlQ1aQfqI41cIgz.egqV6R9s5eGNrNC4W0VRe_IltxGdLQN9WFMJm0o33 htY2pGZWbpJhd_N5XhLBAIpvLDeqML4MTfDJu9zYRUahpAHyiRwaOCNiVwkB 7EjbzmbFgyTPh8XnvTI09jo2hzRs598mpbVoXjSYZ33ZZ1btea2wVvInWDfi TSq1lQxYWWpWkEqYC3BXFGOw7bSuliGs9miRuDZmQJrakPDFSjo3UZPiJm9E 0yEJT1s2la8kblKrmE0VAjdD_cbJRhcd7zlPDKUd3mVGd Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Tue, 19 Mar 2013 08:13:56 PDT X-Rocket-MIMEInfo: 002.001, RnJlZCwKCkkgdXNlIFdpcmVzaGFyayBpbmNlc3NhbnRseS4gwqAgQmVsaWV2ZSBtZSwgSVAgSUQgaXMgdmVyeSBuZWVkZWQgaW4gV2lyZXNoYXJrLgoKQXMgYSBtYXR0ZXIgb2YgZmFjdCwgd2Uga25vdyB0aGUgZm9sa3MgYXQgV2lyZXNoYXJrIHZlcnkgd2VsbC4gwqBXZSBoZWxwIHNwb25zb3IgdGhlaXIgU2hhcmtGZXN0IGV2ZW50LiDCoEkgc3Bva2UgdGhlcmUgbGFzdCB5ZWFyICYgd2lsbCBiZSBhZ2FpbiB0aGlzIHllYXIuIMKgSSBhbSB0cnlpbmcgdG8gdHdpc3QgcGVvcGxlJ3MgYXJtcyBhdCBXaXJlc2gBMAEBAQE- X-Mailer: YahooMailWebService/0.8.138.524 References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> Message-ID: <1363706036.36543.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Tue, 19 Mar 2013 08:13:56 -0700 (PDT) From: Nalini Elkins To: "Templin, Fred L" , Nick Hilliard , "v6ops@ietf.org" In-Reply-To: <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-635592315-1363706036=:36543" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 15:14:01 -0000 ---1551098171-635592315-1363706036=:36543 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Fred,=0A=0AI use Wireshark incessantly. =C2=A0 Believe me, IP ID is very ne= eded in Wireshark.=0A=0AAs a matter of fact, we know the folks at Wireshark= very well. =C2=A0We help sponsor their SharkFest event. =C2=A0I spoke ther= e last year & will be again this year. =C2=A0I am trying to twist people's = arms at Wireshark to come to IETF and speak for themselves. =C2=A0Well, may= be Berlin.=0A=0ABTW, quite a while back, we asked Gerald Combs, the origina= l developer of Wireshark, to comment on our RFC and work with us. =C2=A0He = supports our efforts. =C2=A0I am copying his response to me here. =C2=A0Jan= ice is our contact at Riverbed who "own" Wireshark. =C2=A0 He is speaking o= f the IP ID field in the note below.=0A=0AHi Janice and Nalini,=0A=0AI thin= k this is a great idea! An explicit (and separate) diagnostic field for=C2= =A0IPv6=C2=A0would definitely be helpful for Wireshark, Pilot (particularly= for its MSA feature) and many other tools.=C2=A0=0A=0ATwo quick notes:=C2= =A0=0A=0AYou might want to add a SHOULD NOT or MUST NOT explicitly stating = that gateways must not modify or remove the IPID from packets that they for= ward.=C2=A0=0A=0AMany OSes support random IP IDs (e.g. my laptop has a "net= .inet.ip.random_id" sysctl which is currently enabled), primarily to improv= e security. Is that needed here?=C2=A0=0A=0A=0A=C2=A0=0AThanks,=0A=0A=0ANal= ini Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.co= m=0A=0A=0A=0A________________________________=0A From: "Templin, Fred L" =0ATo: Nalini Elkins ; Nick Hilliard ; "v6ops@ietf.org" =0AS= ent: Tuesday, March 19, 2013 7:56 AM=0ASubject: RE: [v6ops] draft-elkins-v6= ops-ipv6-ipid-needed-00=0A =0A=0A =0AHi Nalini=0A=C2=A0=0AI=E2=80=99ll agre= e that you can construct an example showing a pair of packets with the=0Asa= me (src, dst, seq, ack)-tuple yet the packets are not duplicates. But, diag= nostics=0Acan=E2=80=99t be limited to an isolated pair of packets and need = to observe a trend over=0Amany packets. Again, diagnostic tools like Wiresh= ark seem to be already producing=0Aeffective diagnostics based just on the = information at hand =E2=80=93 I recently used the=0Atool to identify a case= of in-the-network packet duplication within our network.=0ADoes anyone kno= w what the Wireshark team thinks about this?=0A=C2=A0=0AThanks - Fred=0A=C2= =A0=0AFrom:Nalini Elkins [mailto:nalini.elkins@insidethestack.com] =0ASent:= Monday, March 18, 2013 5:49 PM=0ATo: Templin, Fred L; Nick Hilliard; v6ops= @ietf.org=0ASubject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00=0A= =C2=A0=0AFred,=0A=C2=A0=0ATCP sequence number is not enough because there c= an be duplicate segments and retransmissions. =C2=A0 We need a way to see i= f these are really sent by the device or if they are just a problem in pack= et tracing.=0A=C2=A0=0AAlso, in the case of resets, the SEQ and ACK may als= o be duplicated. =C2=A0Let me give you real example:=0A=C2=A0=0Apkt 1: seq = no: 123 =C2=A0 =C2=A0ack: 345 =C2=A0 =C2=A0 ttl: 60 =C2=A0 =C2=A0 IPID: 123= =C2=A0 =C2=A0 =C2=A0 =C2=A0src addr: 1.2.3.4 =C2=A0 =C2=A0dest addr : 4.5.= 6.7 =C2=A0=0Apkt 2: seq no: 123 =C2=A0 =C2=A0ack: 345 =C2=A0 =C2=A0 ttl: 25= 4 =C2=A0 IPID: =C2=A0FF2A =C2=A0 =C2=A0 src addr: 1.2.3.4 =C2=A0 dest addr:= =C2=A04.5.6.7 =C2=A0 TCP RESET flag set=0A=C2=A0=0AThe time between these = two packets is quite small. =C2=A0They have also been having problems with = connections failing.=0A=C2=A0=0AMy conclusion would be that the second pack= et was NOT sent by the same device that sent the first. =C2=A0Why? =C2=A0Be= cause BOTH IPID and TTL are quite different. =C2=A0Very unlikely that the o= riginating device is going to change BOTH that quickly. =C2=A0I would concl= ude that there is a box in the middle sending a RESET for that session. =C2= =A0And, actually, when we replaced the device that we felt was the problem,= sessions stayed up!=0A=C2=A0=0AThis is just one case. =C2=A0In our draft, = we had quite a few others, as you remember from the presentation.=0A=C2=A0= =0ADefinitely, we need a sequence number field that is more than 16 bits. = =C2=A0Wrapping is a problem.=0A=C2=A0=0ABut, the point is well taken that= =C2=A0the down side of a SHIM is that both sides have to implement. =C2=A0N= oted.=0A=C2=A0=0A=C2=A0=0AThanks,=0ANalini Elkins=0AInside Products, Inc.= =0A(831) 659-8360=0Awww.insidethestack.com=0A=0A___________________________= _____=0A =0AFrom:"Templin, Fred L" =0ATo: Nalini= Elkins ; Nick Hilliard ; "= v6ops@ietf.org" =0ASent: Monday, March 18, 2013 3:53 PM=0A= Subject: RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00=0A=C2=A0=0AHi N= alini,=0A=C2=A0=0AFor a shim header between the transport and the applicati= on data, TCP provides=0ATCP options so you could consider a new TCP option.= But, TCP already includes=0Asequence numbers that can be used for diagnost= ic purposes =E2=80=93 in fact, Wireshark=0A(and I=E2=80=99m sure other netw= ork diagnostic tools) already use that. So, I don=E2=80=99t see=0Aa shim as= a big win for TCP.=0A=C2=A0=0AFor UDP, there would need to be a new UDP po= rt number assignment, and a=0Anew piece of code at both the source and dest= ination. The source would have=0Ato insert the shim about the UDP header, a= nd the destination would have to=0Aremove it. That is the same model that S= EAL is addressing, but SEAL is expecting=0Aboth ends to implement the proto= col. So, unfortunately, there is no way to=0Ahave a source-only patch that = does not also require a patch at the destination.=0A=C2=A0=0AThanks - Fred= =0A=C2=A0=0A=C2=A0=0AFrom:v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf= .org] On Behalf Of Nalini Elkins=0ASent: Monday, March 18, 2013 3:40 PM=0AT= o: Nick Hilliard; v6ops@ietf.org=0ASubject: Re: [v6ops] draft-elkins-v6ops-= ipv6-ipid-needed-00=0A=C2=A0=0ANick,=0A=C2=A0=0ATotally agree with you abou= t trying to understand each other's point of view. =C2=A0 We absolutely wan= t to do that. =C2=A0 I think Mike was responding to the comment on the need= for IPID itself.=0A=C2=A0=0AAs far as a solution,=C2=A0we are thinking tha= t IPv6 extension headers are a non-starter. =C2=A0For all the reasons that = have been brought up.=0A=C2=A0=0ASo,=C2=A0we are thinking of a header highe= r up the layers. =C2=A0 For example, between the Transport Layer (TCP / UDP= ) and the application payload.=0A=C2=A0=0AWhat are opinions from people on = that?=0A=C2=A0=0A=C2=A0=0AThanks,=0ANalini Elkins=0AInside Products, Inc.= =0A(831) 659-8360=0Awww.insidethestack.com=0A=0A___________________________= _____=0A =0AFrom:Nick Hilliard =0ATo: v6ops@ietf.org =0ASent:= Monday, March 18, 2013 2:56 PM=0ASubject: Re: [v6ops] draft-elkins-v6ops-i= pv6-ipid-needed-00=0A=0AOn 18/03/2013 21:37, Ackermann, Michael wrote:=0A> = Since beginning to explore this issue of IPID, it has become clear how=0A> = valuable IPID has been to our organization and many like us.=C2=A0 =C2=A0 I= have=0A> personally not talked with everyone about this, but to those I ha= ve, the=0A> preponderance would not like to see this beneficial diagnostic = feature=0A> lost.=0A=0AMike, Nalini,=0A=0AI understand that using IPID work= s for you when diagnosing connectivity=0Aproblems in ipv4.=C2=A0 Do you und= erstand that ipv6 extension headers cause=0Amassive operational headaches w= hich we cannot get around using today's=0Atechnology?=C2=A0 And that as a w= orking group, the operational people here are=0Abaulking at the idea of cre= ating more extension headers because it makes=0Aour lives massively more di= fficult?=0A=0AIf everyone doesn't understand each others' points of view, t= his=0Aconversation is going to continue running around in circles, causing= =0Anothing but frustration.=0A=0ANick=0A=0A________________________________= _______________=0Av6ops mailing list=0Av6ops@ietf.org=0Ahttps://www.ietf.or= g/mailman/listinfo/v6ops ---1551098171-635592315-1363706036=:36543 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Fred,

<= div style=3D"color: rgb(0, 0, 0); font-size: 13px; font-family: arial, helv= etica, sans-serif; background-color: transparent; font-style: normal;">I us= e Wireshark incessantly.   Believe me, IP ID is very needed in Wiresha= rk.

As a matter of fact, we know the folks at Wireshark very well.  We help spons= or their SharkFest event.  I spoke there last year & will be again= this year.  I am trying to twist people's arms at Wireshark to come t= o IETF and speak for themselves.  Well, maybe Berlin.

=
BTW= , quite a while back, we ask= ed Gerald Combs, the original developer of Wireshark, to comment on our RFC= and work with us.  He supports our efforts.  I am copying his re= sponse to me here.  Janice is our contact at Riverbed who "own" Wiresh= ark.   He is speaking of the IP ID field in the note below.
<= br>
Hi Janice and Nalini,

I think this is a gr= eat idea! An explicit (and separate) diagnostic field for IPv6=  would definitely be helpful for Wireshark, P= ilot (particularly for its MSA feature) and many other tools. <= br style=3D"color: rgb(69, 69, 69); font-family: Helvetica, Arial, sans-ser= if; font-size: 12px;">
Two quick no= tes: 

You might want to add a SHOULD NOT or MUST NOT explicitly sta= ting that gateways must not modify or remove the IPID from packets that the= y forward. 

Many OSes support random IP IDs (e.g. my laptop has a "net.inet.ip.random_id" sysctl which is currently enabled), primarily to i= mprove security. Is that needed here? 

 
Thanks,

Nalin= i Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.c= om

From:= "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Nalini Elkins <nalini.elkins@insidethestack.com>; Nick Hilliard <nick@inex.ie&g= t;; "v6ops@ietf.org" <v6ops@ietf.org>
Sent: Tuesday, March 19, 2013 7:56 AM
Subject: RE: [v6ops] draft-elkins-v6= ops-ipv6-ipid-needed-00

=0A
=0A=0A =0A =0A=0A=0A
=0A=0A
Hi Nalini, =0A
 
=0A
> I use Wireshark inces= santly.   Believe me, IP ID is very needed in Wireshark.
= =0A
 
=0A
In the case I examined, a = sequence of TCP segments that were conveyed in 8-10
=0A
packets was being repeated. The sequence and ack numbers in each segmen= t were
=0A
repeated exactly. I can=E2=80=99t be sure= , but I don=E2=80=99t think Wireshark even looked at the IPID
= =0A
because the extra packets were flagged as =E2=80=9Cout of ord= er=E2=80=9D instead of duplicates. But,
=0A
examinin= g the trend rather than an isolated packet pair left little doubt that they=
=0A
were duplicates.
=0A
&n= bsp;
=0A
Thanks - Fred
=0A
&= nbsp;
=0A
 
=0A
=0A
= =0A
=0A
From: Nalini E= lkins [mailto:nalini.elkins@insidethestack.com]=0A
=0ASent: Tuesd= ay, March 19, 2013 8:14 AM
=0ATo: Templin, Fred L; Nick Hilliard;= v6ops@ietf.org
=0ASubject: Re: [v6ops] draft-elkins-v6ops-ipv6-i= pid-needed-00
=0A
=0A
=0A
 
=0A
=0A
=0A
Fred,
=0A
=0A
=0A
 
=0A
=0A
=0A
I use Wireshark in= cessantly.   Believe me, IP ID is very needed in Wireshark. =0A
=0A
=0A
 <= /div> =0A
=0A
=0A
As a matter of fact, we know the folks a= t Wireshark very well.  We help sponsor their SharkFest event.  I= spoke there last year & will be again this year.  I am=0A trying = to twist people's arms at Wireshark to come to IETF and speak for themselve= s.  Well, maybe Berlin.
=0A
=0A
=0A
&nb= sp;
=0A
=0A
=0A
= BTW, quite a while back, we a= sked Gerald Combs, the original developer of Wireshark, to comment on our R= FC and work with us.  He supports our efforts.  I am copying=0A h= is response to me here.  Janice is our contact at Riverbed who "own" W= ireshark.   He is speaking of the IP ID field in the note below.
=0A
=0A
=0A
 
=0A
=0A
= =0A
Hi Janice and Nalini,
=0A
=0AI think this is a great ide= a! An explicit (and separate) diagnostic field for IPv6 would definitely be helpful for Wires= hark, Pilot (particularly for its MSA feature) and many other tools. <= br>=0A
=0ATwo quick notes: 
=0A
=0AYou might want to add a SH= OULD NOT or MUST NOT explicitly stating that gateways must not modify or re= move the IPID from packets that they forward. 
=0A
=0AMany OSes = support random IP IDs (e.g. my laptop has a "net.inet.ip.random_id" sysctl = which is currently enabled), primarily to improve security. Is that needed = here?  =0A
=0A
=0A
 
=0A
=0A
=0A 
=0A
=0A
=0A=
Thanks, =0A
=0A
=0A
Nalini Elkins
=0AInside Products, Inc.
=0A(831) 659-8360
= =0Awww.insidethestack.com
=0A
=0A
=0A
=0A=0A= =0A
=0A
=0A
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
=0ATo: Nali= ni Elkins <nalini.elkins@insidethestack.com>; Nick Hilliard <nick@inex.ie>; "v6ops@ietf.o= rg" <v6ops@ietf.org>=0A
=0A= Sent: Tuesday, March 19, 2013 7:56 AM
=0ASubject: RE: [v6ops]= draft-elkins-v6ops-ipv6-ipid-needed-00=
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
Hi Nalini
=0A<= /div>=0A
=0A
 
=0A
=0A
=0A
I=E2=80=99ll agree that you can construct an example sh= owing a pair of packets with the=
=0A
=0A
=0A
same (src= , dst, seq, ack)-tuple yet the packets are not duplicates. But, diagnostics=
=0A
=0A
=0A
can=E2=80=99t be limited to an isolated p= air of packets and need to observe a trend over
=0A
=0A
=0A
many packets. Again, diagnostic tools like Wireshark seem to be alrea= dy producing
=0A
=0A<= div>=0A
effective diagnostics based j= ust on the information at hand =E2=80=93 I recently used the
=0A
=0A
=0A
tool to identify a case of in-the-network packet duplica= tion within our network.
= =0A
=0A
=0A
Does anyone know= what the Wireshark team thinks about this?
=0A
=0A
=0A
 
=0A
=0A
= =0A
Thanks - Fred
=0A
=0A
=0A
 
=0A=
=0A
=0A
=0A
=0A
=0A
From: Nalini Elkins [mailto:nalini.elkins@insidethestack.com]=0A
=0ASent: Mo= nday, March 18, 2013 5:49 PM
=0ATo: Templin, Fred L; Nick Hilliar= d; v6ops@ietf.org
=0ASubject: Re:= [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
Fred, =0A
=0A
=0A
=0A
=0A
 
=0A
=0A=0A
=0A
=0A
TCP sequence numbe= r is not enough because there can be duplicate segments and retransmissions= .   We need a way to see if these are really sent by the device or if = they=0A are just a problem in packet tracing.
=0A
=0A
=0A
=0A
=0A
 
= =0A
=0A
=0A
=0A
=0A
A= lso, in the case of resets, the SEQ and ACK may also be duplicated.  L= et me give you real example: =0A
=0A
=0A
=0A
=0A
 
=0A
=0A=0A
=0A
=0A
pkt 1: seq no: 123=    ack: 345     ttl: 60     IPID: 123  =      src addr: 1.2.3.4    dest addr : 4.5.6.7 &nb= sp;
=0A
=0A
=0A<= div>=0A
=0A
pkt 2: seq no: 123 &nbs= p;  ack: 345     ttl: 254   IPID:  FF2A   &nb= sp; src addr: 1.2.3.4   dest addr:  4.5.6.7   TCP RESET flag= set
=0A
=0A
=0A=
=0A
=0A
 
=0A
=0A
=0A
=0A
=0AThe time between these two packets is qu= ite small.  They have also been having problems with connections faili= ng.
=0A
=0A
=0A<= div>=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
My conclusion would be that the second pack= et was NOT sent by the same device that sent the first.  Why?  Be= cause BOTH IPID and TTL are quite different.  Very unlikely=0A that th= e originating device is going to change BOTH that quickly.  I would co= nclude that there is a box in the middle sending a RESET for that session. =  And, actually, when we replaced the device that we felt was the probl= em, sessions stayed up!
= =0A
=0A
=0A
=0A
=0A
&= nbsp;
=0A
=0A
= =0A
=0A
=0A
This is just one ca= se.  In our draft, we had quite a few others, as you remember from the= presentation.
=0A
= =0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A=
=0A
<= span style=3D"font-size:10.0pt;color:black;">Definitely, we need a sequence= number field that is more than 16 bits.  Wrapping is a problem.
=0A
=0A
=0A
=0A=0A
 
=0A
=0A
=0A
=0A
=0A
But, the point is well taken that the down side= of a SHIM is that both sides have to implement.  Noted.
=0A
=0A
=0A
=0A
=0A 
=0A
=0A
=0A
=0A
=0A
 
=0A<= /div>=0A
=0A
=0A
=0A
Thanks,
=0A
=0A
=0A
=0A
= =0A
Nalini Elkins
=0AInside Products= , Inc.
=0A(831) 659-8360
=0Awww.insidethestack.com
=0A
=0A
=0A
=0A
=0A<= div class=3D"yiv1438261774MsoNormal" align=3D"center" style=3D"text-align:c= enter;background:white;">=0A= =0A
=0A
=0A
= =0A
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
=0ATo:<= /b> Nalini Elkins <nalini.elkins@insidethestack.com>; Nick Hilliard <nick@inex.ie>; "v6op= s@ietf.org"=0A <v6ops@ietf.org> <= br>=0ASent: Monday, March 18, 2013 3:53 PM
=0ASubject: RE:= [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
=0A
=0A
=0A
=0A
&nbs= p;
=0A
=0A
=0A
=0A
=0A=0A
=0A
Hi Nalini,
=0A
=0A
=0A
=0A
=0A=
 
=0A
=0A
=0A
=0A
=0A
For a shim header between the transport and the applic= ation data, TCP provides
= =0A
=0A
=0A
=0A
=0A
TCP options so you could consider a new TCP option. But, TCP already inclu= des
=0A
=0A
=0A<= div>=0A
=0A
sequence numbers that= can be used for diagnostic purposes =E2=80=93 in fact, Wireshark
=0A
=0A
=0A
=0A
= =0A
(and I=E2=80=99m sure other netwo= rk diagnostic tools) already use that. So, I don=E2=80=99t see
=0A
=0A
=0A
=0A
=0A<= div class=3D"yiv1438261774MsoNormal" style=3D"background:white;">a shim as a big win for TCP.
=0A
=0A
=0A
=0A
= =0A
 
=0A
=0A
=0A
=0A
=0A
For UDP, there would need to be a new UDP port numb= er assignment, and a
=0A=0A
=0A
=0A
=0A
new = piece of code at both the source and destination. The source would have
=0A
=0A
=0A
=0A=
=0A
<= span style=3D"font-size:11.0pt;color:#1F497D;">to insert the shim about the= UDP header, and the destination would have to
=0A
=0A
=0A
=0A
=0A
remove it. That is the same model that SEAL is addres= sing, but SEAL is expecting =0A
=0A
=0A
=0A
=0A
both ends to implement the protocol. So, unfortunately, there is no way = to
=0A
=0A
=0A=0A
=0A
have a source-only pat= ch that does not also require a patch at the destination.
=0A
=0A
=0A
=0A
=0A
 =
=0A
=0A
=0A
=0A
=0A
Thanks - Fred =0A
=0A
=0A
=0A
=0A
 
=0A
=0A=0A
=0A
=0A
 <= span style=3D"color:black;">
=0A
=0A
=0A
= =0A
=0A
=0A
=0A
=0A
From:=0Av6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=0A= On Behalf Of Nalini Elkins
=0ASent: Monday, March 18, 2013= 3:40 PM
=0ATo: Nick Hilliard; v6ops@= ietf.org
=0ASubject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid= -needed-00
=0A
=0A=0A
=0A
=0A
=0A
=0A
  =0A
=0A
=0A
=0A
=0A
=0A
=0A
Nick,
= =0A
=0A
=0A
=0A
=0A
=0A
=0A
 
=0A=
=0A
=0A
=0A
=0A
=0A
=0A
Totally agree with you about trying to understand each other's= point of view.   We absolutely want to do that.   I think Mike w= as responding to the comment on the need=0A for IPID itself.
=0A
=0A
=0A
=0A
=0A=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
= =0A
=0A
As far as a solution, = we are thinking that IPv6 extension headers are a non-starter.  For al= l the reasons that have been brought up.
=0A
=0A
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
=0A
=0A
So, we are thinking of a header higher up = the layers.   For example, between the Transport Layer (TCP / UDP) and= the application payload.
= =0A
=0A
=0A
=0A
=0A
=0A
=0A
 
=0A=
=0A
=0A
=0A
=0A
=0A
=0A
What are opinions from people on that?
=0A
=0A
=0A
=0A
=0A
=0A=0A
 
=0A
=0A
=0A
=0A
=0A
=0A
= =0A
 
=0A
=0A
=0A
=0A
=0A
=0A
=0A
Thanks= ,
=0A
=0A
=0A=0A
=0A
=0A
=0A
Nalini Elkins
=0AInside Products, Inc.
=0A(83= 1) 659-8360
=0Awww.insidethestack.com
=0A
=0A
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
=0A
= =0A
From: Nick Hilliard <ni= ck@inex.ie>
=0ATo: v6ops@ietf.= org
=0ASent: Monday, March 18, 2013 2:56 PM
=0ASubject= : Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
=0A
=0A
=0A
=0A
=0A
=0A

=0AOn 18/03/2013 21:37, Ackermann, Michael wrote:
=0A>= ; Since beginning to explore this issue of IPID, it has become clear how=0A> valuable IPID has been to our organization and many like us. =   I have
=0A> personally not talked with everyone about this, b= ut to those I have, the
=0A> preponderance would not like to see this= beneficial diagnostic feature
=0A> lost.
=0A
=0AMike, Nalini,<= br>=0A
=0AI understand that using IPID works for you when diagnosing con= nectivity
=0Aproblems in ipv4.  Do you understand that ipv6 extensi= on headers cause
=0Amassive operational headaches which we cannot get ar= ound using today's
=0Atechnology?  And that as a working group, the= operational people here are
=0Abaulking at the idea of creating more ex= tension headers because it makes
=0Aour lives massively more difficult?<= br>=0A
=0AIf everyone doesn't understand each others' points of view, th= is
=0Aconversation is going to continue running around in circles, causi= ng
=0Anothing but frustration.
=0A
=0ANick
=0A
=0A__________= _____________________________________
=0Av6ops mailing list
=0Av6ops@ietf.org
=0Ahttps://ww= w.ietf.org/mailman/listinfo/v6ops
=0A
=0A
=0A=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
 
= =0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A=
=0A
 
=0A<= /div>=0A
=0A
=0A
=0A
=0A
=0A
=0A=0A

=
--1510626085-1197803358-1363708947=:97060-- From nalini.elkins@insidethestack.com Tue Mar 19 09:09:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDF921F88FC for ; Tue, 19 Mar 2013 09:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] 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 nziNecU5nsRd for ; Tue, 19 Mar 2013 09:09:26 -0700 (PDT) Received: from nm20-vm0.access.bullet.mail.sp2.yahoo.com (nm20-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1D67021F85BF for ; Tue, 19 Mar 2013 09:09:26 -0700 (PDT) Received: from [98.139.44.99] by nm20.access.bullet.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 16:09:26 -0000 Received: from [98.139.44.67] by tm4.access.bullet.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 16:09:26 -0000 Received: from [127.0.0.1] by omp1004.access.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 16:09:26 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 36511.34557.bm@omp1004.access.mail.sp2.yahoo.com Received: (qmail 33527 invoked by uid 60001); 19 Mar 2013 16:09:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1363709365; bh=wmUr3rFohUCW07tLjF7dvQ5XuaxgEuaz0N0L5rBhs7s=; 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; b=POuLt6UemXwcD57bQVW/AyfJ89ihhklQzCe3y18GdFg0Tww7f9qJ9X6WZgoql5lFQwVuZ/xY6YcIpnRQG5OVtQqnCdz4tXk7xl4RsOtEcl1JI+5XlbkpM+Hae2V7ni5gtH51MHYxyvJ4bKmiPArESIB215lFnSdLOlrvBJNAgjE= X-YMail-OSG: r7tmVEIVM1kzNWxoWxWChC4h0poijD9qXYUt.gHoXF44bRj 5Anm0bg9mq6bIC2VeWBOxiZOUsVXHrLNuZdNn4vjmO3oZLiRmhqn0AD.F6dq iZpFZwE.AT3_Obwntq1FBdJgT1NpbuKnAl_R0dAe_k9esh60O.cyWn5drAWP Gm6gSFHpf3ye6WLvwF0Eagarsm3W.QFh7jy3LfI.guprQ0uU.wdNZkpwjMA1 U1m5GW5qiZdpN_VuE.afzy8gB7tbxxgM4gfy2CtoEFsn9MI7x05skcLTz3di E.JmRwIlXyvLV5QE20HM.qOjXOUQWzx84XnAGcIOIlIvsSqg3X6z.EH_VM0a 3.G2AN4wXmEqTXpX_ZbdcEV_.my10UIksnUBGPciynaZ6Wfjm8niByLc_cHa 14JIfaNaW8syfrCqIAo2UVOQi8U8l0DXiIPSj7rGAZYKPiAiC3q.SPf3u18i 7d8vj0w9M_RYaWNRd.izeIVr6Dly2oItnzzhCKlP9wM7veEw1IC2AlIrpILP .K0R_DkTAWmej.2jD83OjiDpIh8HjU2GUJCIQxhgQr61sXNG0pf5vsDopZW_ qua9B1o.4geWtGdkHVnqlgc5pmGWYqTTMmea86UwUXDg. Received: from [24.130.37.147] by web2804.biz.mail.ne1.yahoo.com via HTTP; Tue, 19 Mar 2013 09:09:25 PDT X-Rocket-MIMEInfo: 002.001, R2VydCwKCkFjdHVhbGx5LCBpbiBteSBleHBlcmllbmNlLCBtYW55IGNvbXBhbmllcyBhcmUgcmVzaXN0aW5nIHRoZSBtb3ZlIHRvIElQdjYgYmVjYXVzZSB0aGV5IHNlZSBubyBidXNpbmVzcyByZWFzb24uIMKgIElmIHdlIGNhbiBoYXZlIGltcHJvdmVkIHBlcmZvcm1hbmNlIGFuZCBkaWFnbm9zdGljcyBmb3IgSVB2NiBieSB0aGUgbWV0aG9kIHRoYXQgd2UgZW52aXNpb24sIHRoaXMgbWF5IGFjdHVhbGx5IFNQRUVEIHRoZSBtb3ZlIHRvIElQdjYuIMKgQXQgbGVhc3QgaW4gY29ycG9yYXRlIEFtZXJpY2EsIHcBMAEBAQE- X-Mailer: YahooMailWebService/0.8.138.524 References: <51488615.8030805@isi.edu> <1363708250.41275.YahooMailClassic@web2802.biz.mail.ne1.yahoo.com> <20130319155955.GI51699@Space.Net> Message-ID: <1363709365.33312.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> Date: Tue, 19 Mar 2013 09:09:25 -0700 (PDT) From: Nalini Elkins To: Gert Doering , Bill Jouris In-Reply-To: <20130319155955.GI51699@Space.Net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1051860855-751322805-1363709365=:33312" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:09:26 -0000 ---1051860855-751322805-1363709365=:33312 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Gert,=0A=0AActually, in my experience, many companies are resisting the mov= e to IPv6 because they see no business reason. =A0 If we can have improved = performance and diagnostics for IPv6 by the method that we envision, this m= ay actually SPEED the move to IPv6. =A0At least in corporate America, which= has been our world for many years.=0A=A0=0AThanks,=0A=0A=0ANalini Elkins= =0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A= =0A________________________________=0A From: Gert Doering = =0ATo: Bill Jouris =0ACc: "v6ops@ietf.org"= =0ASent: Tuesday, March 19, 2013 8:59 AM=0ASubject: Re: [= v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00=0A =0AHi,=0A=0AOn Tue, Mar 19= , 2013 at 08:50:50AM -0700, Bill Jouris wrote:=0A> It's not just "packet di= agnostics designers" that care.=A0 It's also the folks who are merely tryin= g to diagnose problems by reading traces manually.=A0 In fact, they probabl= y care more.=0A=0AJFTR, I recularily diagnose problems by reading tcpdump o= utput, and have=0Anever used IP-ID, and have never missed it either.=0A=0AG= iven what we have today, and that we need to roll out IPv6 "now!", not=0A"w= hen all stacks have been upgraded to handle some sort of IPID change",=0AI = see this as a fairly futile excercise.=0A=0AGert Doering=0A=A0 =A0 =A0 =A0 = -- NetMaster=0A-- =0Ahave you enabled IPv6 on something today...?=0A=0ASpac= eNet AG=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Vorstand: Sebastian = v. Bomhard=0AJoseph-Dollinger-Bogen 14=A0 =A0 =A0 =A0 =A0 Aufsichtsratsvors= .: A. Grundner-Culemann=0AD-80807 Muenchen=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 HRB: 136055 (AG Muenchen)=0ATel: +49 (89) 32356-444=A0 =A0 =A0 =A0 =A0= =A0 USt-IdNr.: DE813185279=0A_____________________________________________= __=0Av6ops mailing list=0Av6ops@ietf.org=0Ahttps://www.ietf.org/mailman/lis= tinfo/v6ops ---1051860855-751322805-1363709365=:33312 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Gert,
=
Actually, in my experience, many companies are resistin= g the move to IPv6 because they see no business reason.   If we can ha= ve improved performance and diagnostics for IPv6 by the method that we envi= sion, this may actually SPEED the move to IPv6.  At least in corporate= America, which has been our world for many years.
<= div> 
Thanks,

Nalini Elkins
Inside Prod= ucts, Inc.
(831) 659-8360
www.insidethestack.com

From: Gert Doering &l= t;gert@space.net>
To: Bill Jouris <bill.jouris@insidethestack.com>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>=
Sent: Tuesday, March= 19, 2013 8:59 AM
Subject:= Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
=
=0AHi,

On Tue, Mar 19, 2013 at 08:50:50AM -0700, Bill Jouris wro= te:
> It's not just "packet diagnostics designers" that care.  I= t's also the folks who are merely trying to diagnose problems by reading tr= aces manually.  In fact, they probably care more.

JFTR, I recul= arily diagnose problems by reading tcpdump output, and have
never used I= P-ID, and have never missed it either.

Given what we have today, and= that we need to roll out IPv6 "now!", not
"when all stacks have been up= graded to handle some sort of IPID change",
I see this as a fairly futil= e excercise.

Gert Doering
        -- NetMaste= r
--
have you enabled IPv6 on something today...?

SpaceNet AG=                      = ;   Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  =         Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen          &n= bsp;       HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356= -444            USt-IdNr.: DE813185279
___= ____________________________________________
v6ops mailing list
v6ops@ietf.o= rg
https://www.ietf.org/mailman/listinfo/v6ops


=
---1051860855-751322805-1363709365=:33312-- From mackermann@bcbsm.com Tue Mar 19 09:09:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02B421F85CE for ; Tue, 19 Mar 2013 09:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 kaw-5PB-mIuF for ; Tue, 19 Mar 2013 09:09:32 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.zixworks.com [63.71.11.123]) by ietfa.amsl.com (Postfix) with ESMTP id 020CC21F85BF for ; Tue, 19 Mar 2013 09:09:31 -0700 (PDT) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 9F8F7136EBD for ; Tue, 19 Mar 2013 11:09:30 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id E8BD0136E04; Tue, 19 Mar 2013 11:09:28 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 9C4532F004F; Tue, 19 Mar 2013 12:08:12 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva2.bcbsm.com (Postfix) with ESMTP id 983DE2F004D; Tue, 19 Mar 2013 12:08:12 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA100.ent.corp.bcbsm.com ([fe80::8db:9ce7:e2cf:8565%14]) with mapi id 14.01.0355.002; Tue, 19 Mar 2013 12:09:28 -0400 From: "Ackermann, Michael" To: Joe Touch Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Thread-Index: AQHOIMaVqC5M9XVYp0uFMLNLdFX3pZil/fsAgAW9XMeAAHp1AP//xeIwgABMrQCAAAwVAIAAA8SAgAAgdgCAAOykAP//wa/wgABJrYD//8OvAA== Date: Tue, 19 Mar 2013 16:09:28 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A64ED7F@PWN401EA160.ent.corp.bcbsm.com> References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <51488615.8030805@isi.edu> In-Reply-To: <51488615.8030805@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:09:33 -0000 Joe, I am certainly sensitive to not wanting to put extra bits on the Internet = (or my own network for that matter). I think this is something we all = seek to optimize however/whenever we can. However, I know these = particular bits have saved many, many hours of downtime for us and that is = worth many millions of dollars as we sought to demonstrate at the meeting = last week. So while I believe optimizing the number of bits sent is = very important, it is not always the only consideration. As a techie, I = may even lean in that direction. However, working for a enterprise and = knowing where my paycheck comes from, I begrudgingly have to believe that = the bits are worth the hours and the =24 Million=24 we have seen saved. = As frequently is the case in my world, business value wins out over = technical optimization. =20 Regards to the injecting of trace traffic. I could maybe do this in a = test environment, but NEVER in production=21 =20 I am afraid I do not know what you mean be =22tracing the entire = packet=22? =20 THanks Mike -----Original Message----- From: Joe Touch =5Bmailto:touch=40isi.edu=5D=20 Sent: Tuesday, March 19, 2013 11:37 AM To: Ackermann, Michael Cc: Templin, Fred L; Nalini Elkins; Nick Hilliard; v6ops=40ietf.org Subject: Re: =5Bv6ops=5D draft-elkins-v6ops-ipv6-ipid-needed-00 Hi, all, Regarding my comment about the =22business model=22, I appreciate that = packet diagnostics are very important, but not at the expense of the = operation of the Internet. I.e., it's not appropriate to complicate = everyone's stack to reduce the effort of packet diagnostics designers. IPIDs are already repeated on very short timescales, and some devices = haven't generated unique IDs for many years. Alternatives have been available, but require more work; they include: =09- injecting your own trace traffic (where the data is =09generated as unique over the timescales sought) =09- tracing the entire packet =09which might show some duplicates, but only rarely =09and typically as a transient The other alternative - to require every source to support diagnostics, = effectively - is neither efficient nor appropriate. Joe The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From nalini.elkins@insidethestack.com Tue Mar 19 09:10:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C87921F8CA3 for ; Tue, 19 Mar 2013 09:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzwGMgAtQ8zy for ; Tue, 19 Mar 2013 09:10:13 -0700 (PDT) Received: from nm3-vm0.access.bullet.mail.mud.yahoo.com (nm3-vm0.access.bullet.mail.mud.yahoo.com [66.94.237.136]) by ietfa.amsl.com (Postfix) with ESMTP id F06BC21F8AD8 for ; Tue, 19 Mar 2013 09:10:12 -0700 (PDT) Received: from [66.94.237.199] by nm3.access.bullet.mail.mud.yahoo.com with NNFMP; 19 Mar 2013 16:10:12 -0000 Received: from [66.94.237.99] by tm10.access.bullet.mail.mud.yahoo.com with NNFMP; 19 Mar 2013 16:10:12 -0000 Received: from [127.0.0.1] by omp1004.access.mail.mud.yahoo.com with NNFMP; 19 Mar 2013 16:10:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 608252.49666.bm@omp1004.access.mail.mud.yahoo.com Received: (qmail 82986 invoked by uid 60001); 19 Mar 2013 16:10:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1363709412; bh=o/U7VxEghVPh51EySz6IZDIWtcX+rs95AuhFr6qPUDw=; 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; b=HM/nlwzqAENAIWNzBEf4INIvPmOKs1NGw0Fe3yXiBnudFU02/A68z4Kd9wqIHw+A5hvVXMKWYMie0JsuXlDJaVKnl7VqoxB00QuodD6VqlBjKuR2xX3TFhHW3YRFlO+T+TyuFQoYpz32Qsb7p5XImOaa/yh5M66zq2sKA9viRO4= X-YMail-OSG: ROCEt3oVM1lsmzjotNm.iXxeh75W6cTwsN6zAIThTGLoVfI krujugJo48rU6k6tDixTzhazS2FM1H02yuSvN9VKxZx8jCzoE0Lg1qdAT22C lHBukxO3OZfmlRQ7QAzor3C84Ck9Y_HR1zmi1f7GNB45I_n5ndr57oAPQz4P 9pbPA7epy9TYmTkQllb6vlYjip.4zzGWN1_NGVQEpw6jfitru2RYYaDzmDnu Zd3wioBGcAPOMrCDnjyJYbMTIfd12WbhpAJNmtlIpW12n9AO.gz_s51xEOa9 6O4xfM5BnU4iVjBexxMLJzGo.T7XHVlXiBrH.b1QWP.q9CxrjHIDurzdypc. 8e5wb5x4cRxi6lCe3YdiHyioBv2FYZJiCQfa08s6hH3qCT1K353_1QfUQLPN 4xwKqMEq5nIIpRpHAi_bzDRrszZ6dy9WVlIZB7H6_5Dvj7Fn_.yNcSJnNMCN 4rwYr5.j3_3WmMV0EJ3cJ72Q2ylC3E15GAdub7107NOjx1MBoObv4WOQ0Cl2 LJ7W3HZ9C1Ji65gWeNjIhLMwoGbYg4NDxFu_rSfTzEdK4PiXU5Zl3rZ.IdK6 lByjWtTXGWn4iU3rssGYamiiydwbf5Q9nkYReU3YXCh4- Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Tue, 19 Mar 2013 09:10:12 PDT X-Rocket-MIMEInfo: 002.001, V2UgcHJvcG9zZSBoYXZpbmcgYSBTSElNIHByZXNlbnQgYXQgYWxsIHRpbWVzLgrCoApUaGFua3MsCgoKTmFsaW5pIEVsa2lucwpJbnNpZGUgUHJvZHVjdHMsIEluYy4KKDgzMSkgNjU5LTgzNjAKd3d3Lmluc2lkZXRoZXN0YWNrLmNvbQoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogSm9lIFRvdWNoIDx0b3VjaEBpc2kuZWR1PgpUbzogTmFsaW5pIEVsa2lucyA8bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb20.IApDYzogIkFja2VybWFubiwgTWljaGFlbCIgPE1BY2tlcm0BMAEBAQE- X-Mailer: YahooMailWebService/0.8.138.524 References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <51488615.8030805@isi.edu> <1363708229.48352.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <51488B6F.9050801@isi.edu> Message-ID: <1363709412.76925.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Tue, 19 Mar 2013 09:10:12 -0700 (PDT) From: Nalini Elkins To: Joe Touch In-Reply-To: <51488B6F.9050801@isi.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-1503957160-1363709412=:76925" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:10:16 -0000 ---1551098171-1503957160-1363709412=:76925 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable We propose having a SHIM present at all times.=0A=A0=0AThanks,=0A=0A=0ANali= ni Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com= =0A=0A=0A=0A________________________________=0A From: Joe Touch =0ATo: Nalini Elkins =0ACc: "Ackerma= nn, Michael" ; "Templin, Fred L" ; Nick Hilliard ; "v6ops@ietf.org" = =0ASent: Tuesday, March 19, 2013 8:59 AM=0ASubject: Re: [v6ops] draft-elkin= s-v6ops-ipv6-ipid-needed-00=0A =0A=0A=0AOn 3/19/2013 8:50 AM, Nalini Elkins= wrote:=0A> Joe,=0A>=0A> To respond:=0A>=0A> "Regarding my comment about th= e "business model", I appreciate that=0A> packet diagnostics are very impor= tant, but not at the expense of the=0A> operation of the Internet. I.e., it= 's not appropriate to complicate=0A> everyone's stack to reduce the effort = of packet diagnostics designers."=0A>=0A> Our effort is to reduce the time = for diagnostics for network operators=0A> or companies who actually run net= works.=A0 NOT packet diagnostics=0A> designers.=A0 Such packet diagnostics = designers have in their own interest=0A> to make diagnostics harder for eve= ryone so that people will be forced to=0A> buy their products.=A0 NOT the o= ther way around.=0A>=0A> "injecting your own trace traffic (where the data = is generated as unique=0A> over the timescales sought)"=0A>=0A> 1. You are = now just changing the environment that you are trying to=0A> diagnose.=0A= =0AWhat do you call inserting a shim?=0A=0A> 2.=A0 In the production networ= ks that I have worked on, this is impossible=0A> to do.=A0 For example,=A0 = do you think that the NY Stock Exchange network in=0A> daytime trading hour= s would ACTUALLY allow this to happen?=A0 You must be=0A> joking.=A0 You c= an't touch their networks in production.=A0 We work with=0A> companies whos= e job it is to settle the stock markets and use IPID to=0A> HELP them with = problems.=0A>=0A> "tracing the entire packet which might show some duplicat= es, but only=0A> rarely and typically as a transient"=0A>=0A> 1. Completely= not true, in my experience.=0A=0ASorry for the mis-implication; I meant "f= alse duplicates". If there is =0Atrue entire duplication, and it happens du= ring what appear to be TCP =0Aretransmissions, don't you already then know = what's going on? Or UDP?=0A=0AIPv6 has the same problem that IPv4 now has -= the ID exists only when =0Athere are fragments. If the endpoint tries to a= void fragments, there is =0ANO way to insert a diagnostic tag short of modi= fying the end systems or =0Ainjecting traffic.=0A=0AAgain, unless you want = to entire Internet to turn on such tags to make =0Ayour life easier. Not an= option, AFAICT.=0A=0AJoe ---1551098171-1503957160-1363709412=:76925 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
We propose having a S= HIM present at all times.
 
Than= ks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8= 360
www.insidethestack.com

<= font size=3D"2" face=3D"Arial">
From: Joe Touch <touch@isi.edu>
To: Nalini Elkins <nalini.elkins@i= nsidethestack.com>
Cc:<= /b> "Ackermann, Michael" <MAckermann@bcbsm.com>; "Templin, Fred L" &l= t;Fred.L.Templin@boeing.com>; Nick Hilliard <nick@inex.ie>; "v6ops= @ietf.org" <v6ops@ietf.org>
Sent: Tuesday, March 19, 2013 8:59 AM
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed= -00

=0A

On 3/19/2013 8:50 AM, Nalini Elkins w= rote:
> Joe,
>
> To respond:
>
> "Regarding m= y comment about the "business model", I appreciate that
> packet diag= nostics are very important, but not at the expense of the
> operation= of the Internet. I.e., it's not appropriate to complicate
> everyone= 's stack to reduce the effort of packet diagnostics designers."
>
= > Our effort is to reduce the time for diagnostics for network operators=
> or companies who actually run networks.  NOT packet diagnosti= cs
> designers.  Such packet diagnostics designers have in their= own interest
> to make diagnostics harder for everyone so that peopl= e will be forced to
> buy their products.  NOT the other way aro= und.
>
> "injecting your own trace traffic (where the data is g= enerated as unique
> over the timescales sought)"
>
> 1. = You are now just changing the environment that you are trying to
> diagnose.

W= hat do you call inserting a shim?

> 2.  In the production ne= tworks that I have worked on, this is impossible
> to do.  For e= xample,  do you think that the NY Stock Exchange network in
> da= ytime trading hours would ACTUALLY allow this to happen?  You must be=
> joking.  You can't touch their networks in production.  = We work with
> companies whose job it is to settle the stock markets = and use IPID to
> HELP them with problems.
>
> "tracing t= he entire packet which might show some duplicates, but only
> rarely = and typically as a transient"
>
> 1. Completely not true, in my= experience.

Sorry for the mis-implication; I meant "false duplicate= s". If there is
true entire duplication, and it happens during what app= ear to be TCP
retransmissions, don't you already then know what's going on? Or UDP?

IPv6 has the same problem that IPv4 now ha= s - the ID exists only when
there are fragments. If the endpoint tries = to avoid fragments, there is
NO way to insert a diagnostic tag short of= modifying the end systems or
injecting traffic.

Again, unless y= ou want to entire Internet to turn on such tags to make
your life easie= r. Not an option, AFAICT.

Joe


---1551098171-1503957160-1363709412=:76925-- From gert@space.net Tue Mar 19 09:14:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9BA321F8A43 for ; Tue, 19 Mar 2013 09:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYPcLFZBSMPF for ; Tue, 19 Mar 2013 09:14:37 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 534D221F85D8 for ; Tue, 19 Mar 2013 09:14:37 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id A24D6607DC for ; Tue, 19 Mar 2013 17:14:36 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 822AC60785 for ; Tue, 19 Mar 2013 17:14:36 +0100 (CET) Received: (qmail 8240 invoked by uid 1007); 19 Mar 2013 17:14:36 +0100 Date: Tue, 19 Mar 2013 17:14:36 +0100 From: Gert Doering To: Nalini Elkins Message-ID: <20130319161436.GJ51699@Space.Net> References: <51488615.8030805@isi.edu> <1363708250.41275.YahooMailClassic@web2802.biz.mail.ne1.yahoo.com> <20130319155955.GI51699@Space.Net> <1363709365.33312.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mKLrDUux5j//0XXz" Content-Disposition: inline In-Reply-To: <1363709365.33312.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:14:38 -0000 --mKLrDUux5j//0XXz Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Mar 19, 2013 at 09:09:25AM -0700, Nalini Elkins wrote: > Actually, in my experience, many companies are resisting the move to IPv6= because they see no business reason. =A0 If we can have improved performan= ce and diagnostics for IPv6 by the method that we envision, this may actual= ly SPEED the move to IPv6. =A0At least in corporate America, which has been= our world for many years. If it's "bring back an ipid similar to what IPv4 has" it's not "better than IPv4". Not compelling enough, if all the other arguments for IPv6 are not heeded. But companies are moot anyway, they do what they want, and in which time frame they want that - the Internet at large is already moving to IPv6, and it's too late for fundamental changes to the packet format or the stacks. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --mKLrDUux5j//0XXz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQCVAwUBUUiO7KkuBuNlUUl1AQLY/AQAnGYSpWLTk/vcBCzEA5+1eqBjaN/bwhsX KrWTSywn/0P7VbEUy1kcuJeFZ/c+C8j11Mx64SfcndS0kjITnteszqwxoD2hD4yq PInMAkNII9bE+XX+TQBVJ7KZo/Fo+LnTCsaApsJoYpfZqFbZNVFddlHA6bY9Kz2C t8YrIdq5u4E= =NnQ1 -----END PGP SIGNATURE----- --mKLrDUux5j//0XXz-- From gert@space.net Tue Mar 19 09:16:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921DF21F8A67 for ; Tue, 19 Mar 2013 09:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 LVjvLKWkTM3e for ; Tue, 19 Mar 2013 09:16:29 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 0900F21F8B0B for ; Tue, 19 Mar 2013 09:16:28 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 132D2607D5 for ; Tue, 19 Mar 2013 17:16:28 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id E6C68607AA for ; Tue, 19 Mar 2013 17:16:27 +0100 (CET) Received: (qmail 9942 invoked by uid 1007); 19 Mar 2013 17:16:27 +0100 Date: Tue, 19 Mar 2013 17:16:27 +0100 From: Gert Doering To: Nalini Elkins Message-ID: <20130319161627.GK51699@Space.Net> References: <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <51488615.8030805@isi.edu> <1363708229.48352.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <51488B6F.9050801@isi.edu> <1363709412.76925.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1363709412.76925.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:16:29 -0000 Hi, On Tue, Mar 19, 2013 at 09:10:12AM -0700, Nalini Elkins wrote: > We propose having a SHIM present at all times. Please describe how this can be done without breaking compatibility to existing and deployed IPv6 end hosts, load balancers, firewalls, and such. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From touch@isi.edu Tue Mar 19 09:21:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9328B21F8D60 for ; Tue, 19 Mar 2013 09:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.013 X-Spam-Level: X-Spam-Status: No, score=-103.013 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, 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 amgJp373PCdT for ; Tue, 19 Mar 2013 09:21:03 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 21F2D21F8D00 for ; Tue, 19 Mar 2013 09:21:03 -0700 (PDT) Received: from [192.168.1.96] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r2JGJkvv008135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Mar 2013 09:19:49 -0700 (PDT) Message-ID: <51489021.9060709@isi.edu> Date: Tue, 19 Mar 2013 09:19:45 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Ackermann, Michael" References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <51488615.8030805@isi.edu> <4FC37E442D05A748896589E468752CAA0A64ED7F@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0A64ED7F@PWN401EA160.ent.corp.bcbsm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:21:03 -0000 On 3/19/2013 9:09 AM, Ackermann, Michael wrote: > Joe, > > I am certainly sensitive to not wanting to put extra bits on the > Internet (or my own network for that matter). I think this is something > we all seek to optimize however/whenever we can. However, I know these > particular bits have saved many, many hours of downtime for us and that > is worth many millions of dollars as we sought to demonstrate at the > meeting last week. So while I believe optimizing the number of bits sent > is very important, it is not always the only consideration. As a techie, > I may even lean in that direction. However, working for a enterprise and > knowing where my paycheck comes from, I begrudgingly have to believe > that the bits are worth the hours and the $ Million$ we have seen saved. > As frequently is the case in my world, business value wins out over > technical optimization. Well, this is why I said that the Internet isn't here to support your business model. Many others will gladly shave a few bits off every packet because they pay for capacity and complexity. Asking everyone to enable features used for diagnostics would be like asking everyone to walk around with a thermometer in their mouth, just in case a medical doctor needs to know. > Regards to the injecting of trace traffic. I could maybe do this in a test environment, but NEVER in production! > > I am afraid I do not know what you mean be "tracing the entire packet"? You're looking for an ID. Consider the whole packet an ID, and look for duplicates. If you see duplicates on one side of a device and not the other, that device is duplicating them. This is more complicated, but there are known ways to do this at very high speed with reasonable amounts of storage. Joe From touch@isi.edu Tue Mar 19 09:22:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C8021F8E0C for ; Tue, 19 Mar 2013 09:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.079 X-Spam-Level: X-Spam-Status: No, score=-103.079 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3BSZ+dI6hAq for ; Tue, 19 Mar 2013 09:22:06 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id CD4ED21F8E0D for ; Tue, 19 Mar 2013 09:22:04 -0700 (PDT) Received: from [192.168.1.96] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r2JGLeNA008977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Mar 2013 09:21:43 -0700 (PDT) Message-ID: <51489094.8040907@isi.edu> Date: Tue, 19 Mar 2013 09:21:40 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Nalini Elkins References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <51488615.8030805@isi.edu> <1363708229.48352.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <51488B6F.9050801@isi.edu> <1363709412.76925.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> In-Reply-To: <1363709412.76925.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:22:07 -0000 That's a non-starter, as is assuming that there is an ID in either IPv4 or IPv4. Joe On 3/19/2013 9:10 AM, Nalini Elkins wrote: > We propose having a SHIM present at all times. > Thanks, > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > ------------------------------------------------------------------------ > *From:* Joe Touch > *To:* Nalini Elkins > *Cc:* "Ackermann, Michael" ; "Templin, Fred L" > ; Nick Hilliard ; > "v6ops@ietf.org" > *Sent:* Tuesday, March 19, 2013 8:59 AM > *Subject:* Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 > > > > On 3/19/2013 8:50 AM, Nalini Elkins wrote: > > Joe, > > > > To respond: > > > > "Regarding my comment about the "business model", I appreciate that > > packet diagnostics are very important, but not at the expense of the > > operation of the Internet. I.e., it's not appropriate to complicate > > everyone's stack to reduce the effort of packet diagnostics designers." > > > > Our effort is to reduce the time for diagnostics for network operators > > or companies who actually run networks. NOT packet diagnostics > > designers. Such packet diagnostics designers have in their own interest > > to make diagnostics harder for everyone so that people will be forced to > > buy their products. NOT the other way around. > > > > "injecting your own trace traffic (where the data is generated as unique > > over the timescales sought)" > > > > 1. You are now just changing the environment that you are trying to > > diagnose. > > What do you call inserting a shim? > > > 2. In the production networks that I have worked on, this is impossible > > to do. For example, do you think that the NY Stock Exchange network in > > daytime trading hours would ACTUALLY allow this to happen? You must be > > joking. You can't touch their networks in production. We work with > > companies whose job it is to settle the stock markets and use IPID to > > HELP them with problems. > > > > "tracing the entire packet which might show some duplicates, but only > > rarely and typically as a transient" > > > > 1. Completely not true, in my experience. > > Sorry for the mis-implication; I meant "false duplicates". If there is > true entire duplication, and it happens during what appear to be TCP > retransmissions, don't you already then know what's going on? Or UDP? > > IPv6 has the same problem that IPv4 now has - the ID exists only when > there are fragments. If the endpoint tries to avoid fragments, there is > NO way to insert a diagnostic tag short of modifying the end systems or > injecting traffic. > > Again, unless you want to entire Internet to turn on such tags to make > your life easier. Not an option, AFAICT. > > Joe > > From nick@inex.ie Tue Mar 19 09:25:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DF021F8AD6 for ; Tue, 19 Mar 2013 09:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315] 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 0a8YidUcySgV for ; Tue, 19 Mar 2013 09:25:46 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD5821F8CEB for ; Tue, 19 Mar 2013 09:25:43 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.4/8.14.5) with ESMTP id r2JGMO3l066377 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 19 Mar 2013 16:22:25 GMT (envelope-from nick@inex.ie) Message-ID: <5148917D.8030000@inex.ie> Date: Tue, 19 Mar 2013 16:25:33 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Ackermann, Michael" References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> X-Enigmail-Version: 1.5.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:25:47 -0000 On 19/03/2013 15:18, Ackermann, Michael wrote: > His comments (please see the slide for details), were very supportive of > IPID being retained in V6. "retained" is an argument which should have happened in 1996. We're now at the "retrofit a protocol change to hundreds of millions of machines" stage. Nick From Fred.L.Templin@boeing.com Tue Mar 19 09:27:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8795521F87C5 for ; Tue, 19 Mar 2013 09:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 9KWdJKw1vg5b for ; Tue, 19 Mar 2013 09:27:28 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 104BF21F86E3 for ; Tue, 19 Mar 2013 09:27:28 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r2JGRR50011504 for ; Tue, 19 Mar 2013 09:27:27 -0700 Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r2JGROk2011443 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 19 Mar 2013 09:27:26 -0700 Received: from XCH-BLV-407.nw.nos.boeing.com (130.247.25.165) by XCH-NWHT-01.nw.nos.boeing.com (130.247.70.222) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 19 Mar 2013 09:27:24 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.214]) by XCH-BLV-407.nw.nos.boeing.com ([169.254.7.22]) with mapi id 14.02.0328.011; Tue, 19 Mar 2013 09:27:24 -0700 From: "Templin, Fred L" To: Gert Doering , Nalini Elkins Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Thread-Index: AQHOJL0bpovTMHVwr0KJKw2dWHfftZitMVKA Date: Tue, 19 Mar 2013 16:27:23 +0000 Message-ID: <2134F8430051B64F815C691A62D98318032F6A@XCH-BLV-504.nw.nos.boeing.com> References: <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <51488615.8030805@isi.edu> <1363708229.48352.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <51488B6F.9050801@isi.edu> <1363709412.76925.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <20130319161627.GK51699@Space.Net> In-Reply-To: <20130319161627.GK51699@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:27:28 -0000 As a TCP option, the shim could be inserted by the source and ignored by the destination. For UDP, there is a way to include a shim as long as both the source and destination are aware that the shim is present. On the wire, it would look like: +------------------+ | IP header | +------------------+ | UDP shim header | | port=3D"shim" | |Next header=3D"real"| +------------------+ | Shim header with | | identification | +------------------+ | UDP real header | | port=3D"real" | +------------------+ | | ~ Application Data ~ | | +------------------+ Not pretty, but it gets the job done. And network middleboxes that expect to see either UDP or TCP should be happy. But, is it worth the 12 or more bytes of extra encapsulation? Fred > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Gert Doering > Sent: Tuesday, March 19, 2013 9:16 AM > To: Nalini Elkins > Cc: v6ops@ietf.org > Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 >=20 > Hi, >=20 > On Tue, Mar 19, 2013 at 09:10:12AM -0700, Nalini Elkins wrote: > > We propose having a SHIM present at all times. >=20 > Please describe how this can be done without breaking compatibility to > existing and deployed IPv6 end hosts, load balancers, firewalls, and such= . >=20 > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner- > Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Tue Mar 19 09:31:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5D921F8F71 for ; Tue, 19 Mar 2013 09:31:35 -0700 (PDT) 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.239, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_MILLIONSOF=0.315] 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 V7ochtyzotiv for ; Tue, 19 Mar 2013 09:31:34 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 84F9921F8F6C for ; Tue, 19 Mar 2013 09:31:34 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r2JGVXPW020838 for ; Tue, 19 Mar 2013 11:31:34 -0500 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r2JGVWMf020834 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 19 Mar 2013 11:31:32 -0500 Received: from XCH-BLV-303.nw.nos.boeing.com (130.247.25.215) by XCH-NWHT-04.nw.nos.boeing.com (130.247.64.250) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 19 Mar 2013 09:31:32 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.214]) by XCH-BLV-303.nw.nos.boeing.com ([169.254.3.246]) with mapi id 14.02.0328.011; Tue, 19 Mar 2013 09:31:31 -0700 From: "Templin, Fred L" To: Nick Hilliard , "Ackermann, Michael" Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Thread-Index: AQHOJL5gpovTMHVwr0KJKw2dWHfftZitM9pA Date: Tue, 19 Mar 2013 16:31:30 +0000 Message-ID: <2134F8430051B64F815C691A62D98318032F8F@XCH-BLV-504.nw.nos.boeing.com> References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <5148917D.8030000@inex.ie> In-Reply-To: <5148917D.8030000@inex.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:31:35 -0000 Nick is right. People cringe when I say this, but IPv6 is in fact a very old protocol - almost an antique. Maybe someday there will be another IPng iteration where this could be revisited. Thanks - Fred > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Nick Hilliard > Sent: Tuesday, March 19, 2013 9:26 AM > To: Ackermann, Michael > Cc: v6ops@ietf.org > Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 >=20 > On 19/03/2013 15:18, Ackermann, Michael wrote: > > His comments (please see the slide for details), were very supportive > of > > IPID being retained in V6. >=20 > "retained" is an argument which should have happened in 1996. We're now > at > the "retrofit a protocol change to hundreds of millions of machines" > stage. >=20 > Nick >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From gert@space.net Tue Mar 19 09:33:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFC321F8FAB for ; Tue, 19 Mar 2013 09:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] 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 xeiUIEV+igBD for ; Tue, 19 Mar 2013 09:33:34 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id BB1B921F8FA3 for ; Tue, 19 Mar 2013 09:33:34 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id DB169607EC for ; Tue, 19 Mar 2013 17:33:33 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id B8D3F607AD for ; Tue, 19 Mar 2013 17:33:33 +0100 (CET) Received: (qmail 16062 invoked by uid 1007); 19 Mar 2013 17:33:33 +0100 Date: Tue, 19 Mar 2013 17:33:33 +0100 From: Gert Doering To: "Templin, Fred L" Message-ID: <20130319163333.GM51699@Space.Net> References: <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <51488615.8030805@isi.edu> <1363708229.48352.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <51488B6F.9050801@isi.edu> <1363709412.76925.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <20130319161627.GK51699@Space.Net> <2134F8430051B64F815C691A62D98318032F6A@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TfU2w8wOOe/PeqFy" Content-Disposition: inline In-Reply-To: <2134F8430051B64F815C691A62D98318032F6A@XCH-BLV-504.nw.nos.boeing.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:33:35 -0000 --TfU2w8wOOe/PeqFy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Mar 19, 2013 at 04:27:23PM +0000, Templin, Fred L wrote: > As a TCP option, the shim could be inserted by the source and > ignored by the destination. For UDP, there is a way to include > a shim as long as both the source and destination are aware that > the shim is present. On the wire, it would look like: That's the point: changing all endpoints. And your UDP communication will mysteriously fail if you happen to send a shim'ed packet to a remote host that doesn't implement it, so you need extra logic to=20 notice the "ICMP port unreachable" coming back for the shim-pseudo-port and then fall back to "no shim", which will only work if that ICMP actually comes, etc. And firewalls will see the wrong UDP port, so throw away your packet. "No go" Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --TfU2w8wOOe/PeqFy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQCVAwUBUUiTXakuBuNlUUl1AQKSDQP+PqhUce+97XfY/dGFRadWaB/AMNQF3cpY t5KzuKajOZwFS/HE0vwFppsvSKc9DipO9G+HiSDordcMTSohNhbMOGqQTClpQUol cHImm07vAUL2AABbF1y/17/6KwWHaJbNDk/AQ3cHwjraW6dmCOkdWAvFtiQrlQLO pPkMKYBu578= =CPzn -----END PGP SIGNATURE----- --TfU2w8wOOe/PeqFy-- From mackermann@bcbsm.com Tue Mar 19 09:36:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758E121F8D92 for ; Tue, 19 Mar 2013 09:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.205 X-Spam-Level: X-Spam-Status: No, score=-6.205 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 HhM3A-Z7-AOM for ; Tue, 19 Mar 2013 09:36:26 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.zixworks.com [63.71.11.123]) by ietfa.amsl.com (Postfix) with ESMTP id 3567C21F8D6E for ; Tue, 19 Mar 2013 09:36:26 -0700 (PDT) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id C3446136EA0 for ; Tue, 19 Mar 2013 11:36:25 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 7AB89136D80; Tue, 19 Mar 2013 11:36:24 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 2AEE22F0045; Tue, 19 Mar 2013 12:35:08 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva2.bcbsm.com (Postfix) with ESMTP id 1C7562F0043; Tue, 19 Mar 2013 12:35:08 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA100.ent.corp.bcbsm.com ([fe80::8db:9ce7:e2cf:8565%14]) with mapi id 14.01.0355.002; Tue, 19 Mar 2013 12:36:24 -0400 From: "Ackermann, Michael" To: Joe Touch Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Thread-Index: AQHOIMaVqC5M9XVYp0uFMLNLdFX3pZil/fsAgAW9XMeAAHp1AP//xeIwgABMrQCAAAwVAIAAA8SAgAAgdgCAAOykAP//wa/wgABJrYD//8OvAAAJCWOAAAgyIAA= Date: Tue, 19 Mar 2013 16:36:22 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A64EE31@PWN401EA160.ent.corp.bcbsm.com> References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <51488615.8030805@isi.edu> <4FC37E442D05A748896589E468752CAA0A64ED7F@PWN401EA160.ent.corp.bcbsm.com> <51489021.9060709@isi.edu> In-Reply-To: <51489021.9060709@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:36:27 -0000 Joe, As I think others have said, I do not see this as a business model. But = only as simple math. =20 If I can add some number of bits to every (or many) packets, there is a = technical cost there, that I fully understand. However, if these bits = save me even 10 hours per year (and it is much more in my cases), this = translates into hundreds of millions of dollars or more to my company and = others. No matter what your cost per bit is, it will never come close to = that. Not to mention the direct or indirect costs to the application or = business. So no matter what I might think as a pure technician or = architect, guess what my boss or my CEO will say. Simple math is the = only math that executives understand and frequently they do not understand = math at all that is not prefixed with a =24. =20 Regards to the whole packet technique. My personal view is that if I = have to program or buy a product, to do what the protocol inherently does = today, that is a big step back and a deterrent to IPV6 deployment. I am = one of the very few pro IPV6 people in my organization and those I work = with. This would be something those fighting IPV6 would use against me. = I am out numbered enough as it is. :) -----Original Message----- From: Joe Touch =5Bmailto:touch=40isi.edu=5D=20 Sent: Tuesday, March 19, 2013 12:20 PM To: Ackermann, Michael Cc: Templin, Fred L; Nalini Elkins; Nick Hilliard; v6ops=40ietf.org Subject: Re: =5Bv6ops=5D draft-elkins-v6ops-ipv6-ipid-needed-00 On 3/19/2013 9:09 AM, Ackermann, Michael wrote: > Joe, > > I am certainly sensitive to not wanting to put extra bits on the=20 > Internet (or my own network for that matter). I think this is=20 > something we all seek to optimize however/whenever we can. However, I=20 > know these particular bits have saved many, many hours of downtime for=20 > us and that is worth many millions of dollars as we sought to=20 > demonstrate at the meeting last week. So while I believe optimizing=20 > the number of bits sent is very important, it is not always the only=20 > consideration. As a techie, I may even lean in that direction.=20 > However, working for a enterprise and knowing where my paycheck comes=20 > from, I begrudgingly have to believe that the bits are worth the hours = and the =24 Million=24 we have seen saved. > As frequently is the case in my world, business value wins out over=20 > technical optimization. Well, this is why I said that the Internet isn't here to support your = business model. Many others will gladly shave a few bits off every packet = because they pay for capacity and complexity. Asking everyone to enable = features used for diagnostics would be like asking everyone to walk around = with a thermometer in their mouth, just in case a medical doctor needs to = know. > Regards to the injecting of trace traffic. I could maybe do this in a = test environment, but NEVER in production=21 > > I am afraid I do not know what you mean be =22tracing the entire = packet=22? You're looking for an ID. Consider the whole packet an ID, and look for = duplicates. If you see duplicates on one side of a device and not the other, that = device is duplicating them. This is more complicated, but there are known ways to do this at very high = speed with reasonable amounts of storage. Joe The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From iljitsch@muada.com Tue Mar 19 09:36:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A88021F8E3A for ; Tue, 19 Mar 2013 09:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRxyU+7qIJ8L for ; Tue, 19 Mar 2013 09:36:52 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 4C55321F8EDE for ; Tue, 19 Mar 2013 09:36:52 -0700 (PDT) Received: from [IPv6:2001:470:1f0b:1289:49f3:ca7e:eec5:e06c] ([IPv6:2001:470:1f0b:1289:49f3:ca7e:eec5:e06c]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2JGVjLw043865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Mar 2013 17:31:46 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> Date: Tue, 19 Mar 2013 17:36:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1499) Cc: "draft-steffann-tunnels@tools.ietf.org" Subject: Re: [v6ops] draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:36:53 -0000 On 15 feb 2013, at 9:44, Iljitsch van Beijnum = wrote: > Three of us were asked by the Dutch academic network Surfnet to write = an overview of IPv6-in-IPv4 tunneling mechanisms. To benefit the wider = community, we did so in the form of a draft, that we intend to submit to = the RFC Editor as an independent submission. > However, we would very much appreciate reviews and comments from = within the IETF. We have submitted version -01 which addresses remarks from reviewers. = The new version can be found here: https://datatracker.ietf.org/doc/draft-steffann-tunnels/ We plan on submitting the draft to the RFC Editor at the end of the = week. Iljitsch= From joelja@bogus.com Tue Mar 19 09:41:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3B821F8FB3 for ; Tue, 19 Mar 2013 09:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 ETr8x0XoEona for ; Tue, 19 Mar 2013 09:41:04 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1F28D21F8733 for ; Tue, 19 Mar 2013 09:41:04 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r2JGf0Dp051293 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 19 Mar 2013 16:41:00 GMT (envelope-from joelja@bogus.com) Message-ID: <51489516.6000403@bogus.com> Date: Tue, 19 Mar 2013 09:40:54 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Nalini Elkins , "Templin, Fred L" , Nick Hilliard , "v6ops@ietf.org" References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <1363706036.36543.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032CD8@XCH-BLV-504.nw.nos.boeing.com> <1363708947.97060.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> In-Reply-To: <1363708947.97060.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 19 Mar 2013 16:41:01 +0000 (UTC) Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:41:05 -0000 On 3/19/13 9:02 AM, Nalini Elkins wrote: > Fred, > > Definitely, we can use TCP seq and ack to find out-of-sequence packets > on some occasions but as we said in our draft there are quite a few > other instances where this is not true. And, it is definitely not true > for UDP. > > More and more uses are being made of UDP to embed other protocols. > Tunneling is often used for UDP. Also one protocol we work with quite > a bit is HPR over UDP. > A UDP encapsulation of SNA is sensitive to duplicates? I think that's a little more subtle than find the source of duplicates with different flags in a TCP stream, TCP implementations should fundamentally not be sensitive to duplicate packets. From my own foggy memory HPR has it's own duplicate detection reordering and retransmission mechanism (RTP), which is why it runs on top of UDP rather than TCP iirc. If that has limitations that send one to look to the ip header I guess that's a problem, but it seems like a relatively constrained and well understood environment would exist around such flows. It also seems that in that particular case the shim already exists (unless it's totally inadequate) but you probably are in a better position to describe the limitations of RTP than I. > I think maybe we will now start to work on our draft of the solution > we envisage and then maybe we can have a new discussion. We definitely > will take all the suggestions into account. > > Thank you all so much for spending time thinking about this issue. > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > ------------------------------------------------------------------------ > *From:* "Templin, Fred L" > *To:* Nalini Elkins ; Nick Hilliard > ; "v6ops@ietf.org" > *Sent:* Tuesday, March 19, 2013 8:30 AM > *Subject:* RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 > > Hi Nalini, > > I use Wireshark incessantly. Believe me, IP ID is very needed in Wireshark. > In the case I examined, a sequence of TCP segments that were conveyed > in 8-10 > packets was being repeated. The sequence and ack numbers in each > segment were > repeated exactly. I can’t be sure, but I don’t think Wireshark even > looked at the IPID > because the extra packets were flagged as “out of order” instead of > duplicates. But, > examining the trend rather than an isolated packet pair left little > doubt that they > were duplicates. > Thanks - Fred > *From:*Nalini Elkins [mailto:nalini.elkins@insidethestack.com] > *Sent:* Tuesday, March 19, 2013 8:14 AM > *To:* Templin, Fred L; Nick Hilliard; v6ops@ietf.org > *Subject:* Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 > Fred, > I use Wireshark incessantly. Believe me, IP ID is very needed in > Wireshark. > As a matter of fact, we know the folks at Wireshark very well. We help > sponsor their SharkFest event. I spoke there last year & will be again > this year. I am trying to twist people's arms at Wireshark to come to > IETF and speak for themselves. Well, maybe Berlin. > BTW, quite a while back, we asked Gerald Combs, the original developer > of Wireshark, to comment on our RFC and work with us. He supports our > efforts. I am copying his response to me here. Janice is our contact > at Riverbed who "own" Wireshark. He is speaking of the IP ID field in > the note below. > Hi Janice and Nalini, > > I think this is a great idea! An explicit (and separate) diagnostic > field for IPv6 would definitely be helpful for Wireshark, Pilot > (particularly for its MSA feature) and many other tools. > > Two quick notes: > > You might want to add a SHOULD NOT or MUST NOT explicitly stating that > gateways must not modify or remove the IPID from packets that they > forward. > > Many OSes support random IP IDs (e.g. my laptop has a > "net.inet.ip.random_id" sysctl which is currently enabled), primarily > to improve security. Is that needed here? > Thanks, > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > ------------------------------------------------------------------------ > *From:*"Templin, Fred L" > > *To:* Nalini Elkins >; Nick Hilliard > >; "v6ops@ietf.org > " > > *Sent:* Tuesday, March 19, 2013 7:56 AM > *Subject:* RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 > Hi Nalini > I’ll agree that you can construct an example showing a pair of packets > with the > same (src, dst, seq, ack)-tuple yet the packets are not duplicates. > But, diagnostics > can’t be limited to an isolated pair of packets and need to observe a > trend over > many packets. Again, diagnostic tools like Wireshark seem to be > already producing > effective diagnostics based just on the information at hand – I > recently used the > tool to identify a case of in-the-network packet duplication within > our network. > Does anyone know what the Wireshark team thinks about this? > Thanks - Fred > *From:*Nalini Elkins [mailto:nalini.elkins@insidethestack.com] > *Sent:* Monday, March 18, 2013 5:49 PM > *To:* Templin, Fred L; Nick Hilliard; v6ops@ietf.org > > *Subject:* Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 > Fred, > TCP sequence number is not enough because there can be duplicate > segments and retransmissions. We need a way to see if these are really > sent by the device or if they are just a problem in packet tracing. > Also, in the case of resets, the SEQ and ACK may also be duplicated. > Let me give you real example: > pkt 1: seq no: 123 ack: 345 ttl: 60 IPID: 123 src addr: 1.2.3.4 dest > addr : 4.5.6.7 > pkt 2: seq no: 123 ack: 345 ttl: 254 IPID: FF2A src addr: 1.2.3.4 dest > addr: 4.5.6.7 TCP RESET flag set > The time between these two packets is quite small. They have also been > having problems with connections failing. > My conclusion would be that the second packet was NOT sent by the same > device that sent the first. Why? Because BOTH IPID and TTL are quite > different. Very unlikely that the originating device is going to > change BOTH that quickly. I would conclude that there is a box in the > middle sending a RESET for that session. And, actually, when we > replaced the device that we felt was the problem, sessions stayed up! > This is just one case. In our draft, we had quite a few others, as you > remember from the presentation. > Definitely, we need a sequence number field that is more than 16 bits. > Wrapping is a problem. > But, the point is well taken that the down side of a SHIM is that both > sides have to implement. Noted. > Thanks, > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > ------------------------------------------------------------------------ > *From:*"Templin, Fred L" > > *To:* Nalini Elkins >; Nick Hilliard > >; "v6ops@ietf.org > " > > *Sent:* Monday, March 18, 2013 3:53 PM > *Subject:* RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 > Hi Nalini, > For a shim header between the transport and the application data, TCP > provides > TCP options so you could consider a new TCP option. But, TCP already > includes > sequence numbers that can be used for diagnostic purposes – in fact, > Wireshark > (and I’m sure other network diagnostic tools) already use that. So, I > don’t see > a shim as a big win for TCP. > For UDP, there would need to be a new UDP port number assignment, and a > new piece of code at both the source and destination. The source would > have > to insert the shim about the UDP header, and the destination would have to > remove it. That is the same model that SEAL is addressing, but SEAL is > expecting > both ends to implement the protocol. So, unfortunately, there is no way to > have a source-only patch that does not also require a patch at the > destination. > Thanks - Fred > *From:*v6ops-bounces@ietf.org > [mailto:v6ops-bounces@ietf.org] *On Behalf Of *Nalini Elkins > *Sent:* Monday, March 18, 2013 3:40 PM > *To:* Nick Hilliard; v6ops@ietf.org > *Subject:* Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 > Nick, > Totally agree with you about trying to understand each other's point > of view. We absolutely want to do that. I think Mike was responding to > the comment on the need for IPID itself. > As far as a solution, we are thinking that IPv6 extension headers are > a non-starter. For all the reasons that have been brought up. > So, we are thinking of a header higher up the layers. For example, > between the Transport Layer (TCP / UDP) and the application payload. > What are opinions from people on that? > Thanks, > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > ------------------------------------------------------------------------ > *From:*Nick Hilliard > > *To:* v6ops@ietf.org > *Sent:* Monday, March 18, 2013 2:56 PM > *Subject:* Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 > > On 18/03/2013 21:37, Ackermann, Michael wrote: > > Since beginning to explore this issue of IPID, it has become clear how > > valuable IPID has been to our organization and many like us. I have > > personally not talked with everyone about this, but to those I have, the > > preponderance would not like to see this beneficial diagnostic feature > > lost. > > Mike, Nalini, > > I understand that using IPID works for you when diagnosing connectivity > problems in ipv4. Do you understand that ipv6 extension headers cause > massive operational headaches which we cannot get around using today's > technology? And that as a working group, the operational people here are > baulking at the idea of creating more extension headers because it makes > our lives massively more difficult? > > If everyone doesn't understand each others' points of view, this > conversation is going to continue running around in circles, causing > nothing but frustration. > > Nick > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From mackermann@bcbsm.com Tue Mar 19 09:41:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6B921F8718 for ; Tue, 19 Mar 2013 09:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.214 X-Spam-Level: X-Spam-Status: No, score=-6.214 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 YN1Wds5r0AIm for ; Tue, 19 Mar 2013 09:41:46 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.zixworks.com [63.71.11.123]) by ietfa.amsl.com (Postfix) with ESMTP id 4656621F86F0 for ; Tue, 19 Mar 2013 09:41:46 -0700 (PDT) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id CFF5F17E496 for ; Tue, 19 Mar 2013 11:41:45 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 0BB0317E416; Tue, 19 Mar 2013 11:41:45 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id B61762F0045; Tue, 19 Mar 2013 12:40:28 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva2.bcbsm.com (Postfix) with ESMTP id A438A2F0040; Tue, 19 Mar 2013 12:40:28 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA100.ent.corp.bcbsm.com ([fe80::8db:9ce7:e2cf:8565%14]) with mapi id 14.01.0355.002; Tue, 19 Mar 2013 12:41:44 -0400 From: "Ackermann, Michael" To: Nick Hilliard Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Thread-Index: AQHOIMaVqC5M9XVYp0uFMLNLdFX3pZil/fsAgAW9XMeAAHp1AP//xeIwgABMrQCAAAwVAIAAA8SAgAAgdgCAAOykAP//wa/wgABXRYD//8ApAA== Date: Tue, 19 Mar 2013 16:41:43 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A64EE4E@PWN401EA160.ent.corp.bcbsm.com> References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <5148917D.8030000@inex.ie> In-Reply-To: <5148917D.8030000@inex.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:41:46 -0000 VGhlIEhVR0UgZnVuZGFtZW50YWwgZGl2aWRlIEkgc2VlIChhcyBhIG5ldyBjb21lciB0byBJ RVRGKSwgIGlzIHRoYXQgbW9zdCBvZiB0aGUgSUVURiBwb3B1bGFjZSBoYXMgYmVlbiBydW5u aW5nIElQVjYgZm9yIHllYXJzLiAgIE1vc3Qgb2YgY29ycG9yYXRlIEFtZXJpY2EgaXMganVz dCBsZWFybmluZyB0byBzcGVsbCBpdC4gICBBbmQgbW9zdCBhcmUgdmVyeSByZXNpc3RhbnQg b2YgaXQgdG9kYXkuICAgDQoNClRoaXMgY2F1c2VzIHVzIHRvIGhhdmUgVkVSWSBkaWZmZXJl bnQgcGVyc3BlY3RpdmVzIG9uIG1hbnkgSVBWNiBpc3N1ZXMuICAgDQoNCkkgY2FuIG9ubHkg aG9wZSB3ZSBjYW4gYXR0ZW1wdCB0byBzZWUgZWFjaCBvdGhlcnMgcGVyc3BlY3RpdmVzIGFu ZCBicmlkZ2UgbWFueSBvZiB0aGlzIGdhcHMgdG8gam9pbnRseSBjcmVhdGUgb3ZlcmFsbCBl ZmZlY3RpdmUgc29sdXRpb25zLiAgIA0KDQpQZXJoYXBzIEkgc291bmQgbmHDr3ZlIG9yIFBv bGx5YW5uYWlzaCwgIGJ1dCBJIHJlYWxseSBkbyBob3BlIGZvciB0aGlzISAgDQoNCg0KDQpT b3JyeSBmb3IgY29taW5nIHNvIGxhdGUgdG8gdGhpcyBwYXJ0eSEgOikNCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTmljayBIaWxsaWFyZCBbbWFpbHRvOm5pY2tA aW5leC5pZV0gDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAxOSwgMjAxMyAxMjoyNiBQTQ0KVG86 IEFja2VybWFubiwgTWljaGFlbA0KQ2M6IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W3Y2b3BzXSBkcmFmdC1lbGtpbnMtdjZvcHMtaXB2Ni1pcGlkLW5lZWRlZC0wMA0KDQpPbiAx OS8wMy8yMDEzIDE1OjE4LCBBY2tlcm1hbm4sIE1pY2hhZWwgd3JvdGU6DQo+IEhpcyBjb21t ZW50cyAocGxlYXNlIHNlZSB0aGUgc2xpZGUgZm9yIGRldGFpbHMpLCAgd2VyZSB2ZXJ5IHN1 cHBvcnRpdmUgDQo+IG9mIElQSUQgYmVpbmcgcmV0YWluZWQgaW4gVjYuDQoNCiJyZXRhaW5l ZCIgaXMgYW4gYXJndW1lbnQgd2hpY2ggc2hvdWxkIGhhdmUgaGFwcGVuZWQgaW4gMTk5Ni4g IFdlJ3JlIG5vdyBhdCB0aGUgInJldHJvZml0IGEgcHJvdG9jb2wgY2hhbmdlIHRvIGh1bmRy ZWRzIG9mIG1pbGxpb25zIG9mIG1hY2hpbmVzIiBzdGFnZS4NCg0KTmljaw0KDQoKClRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBjb21tdW5pY2F0aW9uIGlzIGhpZ2hseSBj b25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUg aW5kaXZpZHVhbChzKSB0byB3aG9tIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBkaXJlY3RlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkg bm90aWZpZWQgdGhhdCBhbnkgdmlld2luZywgY29weWluZywgZGlzY2xvc3VyZSBvciBkaXN0 cmlidXRpb24gb2YgdGhpcyBpbmZvcm1hdGlvbiBpcyBwcm9oaWJpdGVkLiBQbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIsIGJ5IGVsZWN0cm9uaWMgbWFpbCBvciB0ZWxlcGhvbmUsIG9mIGFu eSB1bmludGVuZGVkIHJlY2VpcHQgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwgbWVzc2FnZSB3 aXRob3V0IG1ha2luZyBhbnkgY29waWVzLgogCiBCbHVlIENyb3NzIEJsdWUgU2hpZWxkIG9m IE1pY2hpZ2FuIGFuZCBCbHVlIENhcmUgTmV0d29yayBvZiBNaWNoaWdhbiBhcmUgbm9ucHJv Zml0IGNvcnBvcmF0aW9ucyBhbmQgaW5kZXBlbmRlbnQgbGljZW5zZWVzIG9mIHRoZSBCbHVl IENyb3NzIGFuZCBCbHVlIFNoaWVsZCBBc3NvY2lhdGlvbi4K From Fred.L.Templin@boeing.com Tue Mar 19 09:50:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F6F21F8D77 for ; Tue, 19 Mar 2013 09:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.061 X-Spam-Level: X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] 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 OKSVB5u00Kvj for ; Tue, 19 Mar 2013 09:50:57 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id E22ED21F8D6A for ; Tue, 19 Mar 2013 09:50:50 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r2JGooKT027816 for ; Tue, 19 Mar 2013 11:50:50 -0500 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r2JGolRL027755 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 19 Mar 2013 11:50:48 -0500 Received: from XCH-PHX-409.sw.nos.boeing.com (10.57.37.40) by XCH-NWHT-04.nw.nos.boeing.com (130.247.64.250) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 19 Mar 2013 09:50:48 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.214]) by XCH-PHX-409.sw.nos.boeing.com ([169.254.9.77]) with mapi id 14.02.0328.011; Tue, 19 Mar 2013 09:50:47 -0700 From: "Templin, Fred L" To: Gert Doering Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Thread-Index: AQHOJL9/povTMHVwr0KJKw2dWHfftZitOTRg Date: Tue, 19 Mar 2013 16:50:46 +0000 Message-ID: <2134F8430051B64F815C691A62D98318033048@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <51488615.8030805@isi.edu> <1363708229.48352.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <51488B6F.9050801@isi.edu> <1363709412.76925.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <20130319161627.GK51699@Space.Net> <2134F8430051B64F815C691A62D98318032F6A@XCH-BLV-504.nw.nos.boeing.com> <20130319163333.GM51699@Space.Net> In-Reply-To: <20130319163333.GM51699@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:50:58 -0000 Hi Gert, > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: Tuesday, March 19, 2013 9:34 AM > To: Templin, Fred L > Cc: Gert Doering; Nalini Elkins; v6ops@ietf.org > Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 >=20 > Hi, >=20 > On Tue, Mar 19, 2013 at 04:27:23PM +0000, Templin, Fred L wrote: > > As a TCP option, the shim could be inserted by the source and > > ignored by the destination. For UDP, there is a way to include > > a shim as long as both the source and destination are aware that > > the shim is present. On the wire, it would look like: >=20 > That's the point: changing all endpoints. And your UDP communication > will mysteriously fail if you happen to send a shim'ed packet to a > remote host that doesn't implement it, so you need extra logic to > notice the "ICMP port unreachable" coming back for the shim-pseudo-port > and then fall back to "no shim", which will only work if that ICMP > actually comes, etc. >=20 > And firewalls will see the wrong UDP port, so throw away your packet. >=20 > "No go" Yes, you are right - trying to include a UDP-encapsulated shim all the way from the source to the destination is going to break due to firewalls, packet filters and the like. However, if the shim header was included by an ingress tunnel endpoint somewhere in the network beyond the original source and then removed by an egress tunnel endpoint somewhere else in the network before the final destination then it should be OK. But, you lose the ability to control the ID from either the source or destination. Thanks - Fred fred.l.templin@boeing.com > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner- > Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From touch@isi.edu Tue Mar 19 09:52:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DCB21F8EF7 for ; Tue, 19 Mar 2013 09:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.868 X-Spam-Level: X-Spam-Status: No, score=-102.868 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, 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 57aHFfaXYbaj for ; Tue, 19 Mar 2013 09:52:23 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9249F21F8DDB for ; Tue, 19 Mar 2013 09:52:23 -0700 (PDT) Received: from [192.168.1.96] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r2JGobhr013094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Mar 2013 09:50:47 -0700 (PDT) Message-ID: <5148975D.2030102@isi.edu> Date: Tue, 19 Mar 2013 09:50:37 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Ackermann, Michael" References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <51488615.8030805@isi.edu> <4FC37E442D05A748896589E468752CAA0A64ED7F@PWN401EA160.ent.corp.bcbsm.com> <51489021.9060709@isi.edu> <4FC37E442D05A748896589E468752CAA0A64EE31@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0A64EE31@PWN401EA160.ent.corp.bcbsm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:52:24 -0000 I think Fred and I have made our position clear. A few bits may be millions to you or even to a few of your clients, but it's hundreds of billions to everyone else. That's not a business model that the IETF should support. Joe On 3/19/2013 9:36 AM, Ackermann, Michael wrote: > Joe, > > As I think others have said, I do not see this as a business model. But only as simple math. > > If I can add some number of bits to every (or many) packets, there is a technical cost there, that I fully understand. However, if these bits save me even 10 hours per year (and it is much more in my cases), this translates into hundreds of millions of dollars or more to my company and others. No matter what your cost per bit is, it will never come close to that. Not to mention the direct or indirect costs to the application or business. So no matter what I might think as a pure technician or architect, guess what my boss or my CEO will say. Simple math is the only math that executives understand and frequently they do not understand math at all that is not prefixed with a $. > > Regards to the whole packet technique. My personal view is that if I have to program or buy a product, to do what the protocol inherently does today, that is a big step back and a deterrent to IPV6 deployment. I am one of the very few pro IPV6 people in my organization and those I work with. This would be something those fighting IPV6 would use against me. I am out numbered enough as it is. :) > > > > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Tuesday, March 19, 2013 12:20 PM > To: Ackermann, Michael > Cc: Templin, Fred L; Nalini Elkins; Nick Hilliard; v6ops@ietf.org > Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 > > > > On 3/19/2013 9:09 AM, Ackermann, Michael wrote: >> Joe, >> >> I am certainly sensitive to not wanting to put extra bits on the >> Internet (or my own network for that matter). I think this is >> something we all seek to optimize however/whenever we can. However, I >> know these particular bits have saved many, many hours of downtime for >> us and that is worth many millions of dollars as we sought to >> demonstrate at the meeting last week. So while I believe optimizing >> the number of bits sent is very important, it is not always the only >> consideration. As a techie, I may even lean in that direction. >> However, working for a enterprise and knowing where my paycheck comes >> from, I begrudgingly have to believe that the bits are worth the hours and the $ Million$ we have seen saved. >> As frequently is the case in my world, business value wins out over >> technical optimization. > > Well, this is why I said that the Internet isn't here to support your business model. Many others will gladly shave a few bits off every packet because they pay for capacity and complexity. Asking everyone to enable features used for diagnostics would be like asking everyone to walk around with a thermometer in their mouth, just in case a medical doctor needs to know. > >> Regards to the injecting of trace traffic. I could maybe do this in a test environment, but NEVER in production! >> >> I am afraid I do not know what you mean be "tracing the entire packet"? > > You're looking for an ID. Consider the whole packet an ID, and look for duplicates. > > If you see duplicates on one side of a device and not the other, that device is duplicating them. > > This is more complicated, but there are known ways to do this at very high speed with reasonable amounts of storage. > > Joe > > > The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. > > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. > From touch@isi.edu Tue Mar 19 09:53:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A1A21F8443 for ; Tue, 19 Mar 2013 09:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.968 X-Spam-Level: X-Spam-Status: No, score=-102.968 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLlMWz7ApP2K for ; Tue, 19 Mar 2013 09:53:55 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id B1F5121F8DB4 for ; Tue, 19 Mar 2013 09:53:55 -0700 (PDT) Received: from [192.168.1.96] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r2JGr3fp013495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Mar 2013 09:53:13 -0700 (PDT) Message-ID: <514897EF.3000900@isi.edu> Date: Tue, 19 Mar 2013 09:53:03 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Ackermann, Michael" References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <5148917D.8030000@inex.ie> <4FC37E442D05A748896589E468752CAA0A64EE4E@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0A64EE4E@PWN401EA160.ent.corp.bcbsm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 16:53:59 -0000 Your view of IPv6 deployment seems a bit dated. It might be useful to take a look here: http://eggert.org/meter/ipv6 Joe On 3/19/2013 9:41 AM, Ackermann, Michael wrote: > mental divide I see (as a new comer to IETF), is that most of the IETF populace has been running IPV6 for years. Most of corporate America is just learning to spell it. And most are very resistant of it today. > > This causes us to have VERY different perspectives on many IPV6 issues. > > I can only hope we can attempt to see each others perspectives and bridge many of this gaps to jointly create overall effective solutions. > > Perhaps I sound From nalini.elkins@insidethestack.com Tue Mar 19 10:01:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639F621F8536 for ; Tue, 19 Mar 2013 10:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6] 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 WLP435fqdb-f for ; Tue, 19 Mar 2013 10:01:43 -0700 (PDT) Received: from nm21-vm0.access.bullet.mail.sp2.yahoo.com (nm21-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.176]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBE221F8C7D for ; Tue, 19 Mar 2013 10:01:43 -0700 (PDT) Received: from [98.139.44.104] by nm21.access.bullet.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 17:01:40 -0000 Received: from [98.139.44.75] by tm9.access.bullet.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 17:01:40 -0000 Received: from [127.0.0.1] by omp1012.access.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 17:01:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 598557.77535.bm@omp1012.access.mail.sp2.yahoo.com Received: (qmail 7615 invoked by uid 60001); 19 Mar 2013 17:01:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1363712499; bh=TkirtRzR1Ud1rXFwqVpDvC04C0JMqNlPqIhf8kIJAS8=; 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; b=UP2aPCqsom3/3fPMH/8D7iTxCyB87bk77gJqg3XPwp9EcMFdSxFk0BClfwf3EcM+tf4KPPSDpVWni30FouT52xq1DYQFAvmL54RCZUl8OjPvK+QZlkTlQc8ZoKrXIplnmQ9jDNgi7Ba5munj1DKQ9RQaWOSsKlITFTDZhHh7+UU= X-YMail-OSG: .rSIvNMVM1nuwPSXuv1HqkvcWmE_Ss4o7MGZp6B3ZjcZSSf oZ1P8AQt3VenEgt8e_VpRs6D8MkAgXjI4qVoxRV8qEiR6r9R50A.hb19VZXR 8wQAdBE5n3vFMxNsbL1gk40xc9FS.rMF6XKi9m.wdz7InvW_.WD_1DJzYoIM fNA3Ju8VwDi1VM4LTG08MBcfuDbu8NzMwaxsLNgDrQcJiuXWu1u4ZKlC5xpn ZcaE2QOJfi16ugItORcFMUCF0vFSrT2Q4YqeNOBvOqzRUJAchrdy0KTpHJEd vAPe9x.WKZ9_KmVIkXWaxslmRsYiOBbRdVUmwuVo_R4Sc54yPghQnSmp0wO6 cBbBT3HkauhAHZfzj0.990EukIi82Izdbh.jD3WyuFQwYvZJ1.a2dbyO50L9 O_hxn0Pe89JUW5g.LPs8aXt5mva8vycfeWWCuaTTFBiEeA3IbkY808Q4JaEP IrBRBO0K1lQ4wDzYeoadVN3lWXAH_TTG2pbiwMabqB1XkBoDc31WgcMxQzdT DNbVJPYDCy1W6ZRNqch.BwB8coS9n0S55GSvo1ZimgF6m.zzKWPzipdk.1Ty KEiUT2UnHJuVYTJetocYbAyitgQ8BPA.q8gw7q_iSicXx Received: from [24.130.37.147] by web2805.biz.mail.ne1.yahoo.com via HTTP; Tue, 19 Mar 2013 10:01:39 PDT X-Rocket-MIMEInfo: 002.001, R3V5cywKCiJIb3dldmVyLCBpZiB0aGXCoHNoaW0gaGVhZGVyIHdhcyBpbmNsdWRlZCBieSBhbiBpbmdyZXNzIHR1bm5lbCBlbmRwb2ludCBzb21ld2hlcmXCoGluIHRoZSBuZXR3b3JrIGJleW9uZCB0aGUgb3JpZ2luYWwgc291cmNlIGFuZCB0aGVuIHJlbW92ZWQgYnkgYW7CoGVncmVzcyB0dW5uZWwgZW5kcG9pbnQgc29tZXdoZXJlIGVsc2UgaW4gdGhlIG5ldHdvcmsgYmVmb3JlIHRoZQpmaW5hbCBkZXN0aW5hdGlvbiB0aGVuIGl0IHNob3VsZCBiZSBPSy4gQnV0LCB5b3UgbG9zZSB0aGXCoGFiaWxpdHkgdG8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.138.524 References: <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <51488615.8030805@isi.edu> <1363708229.48352.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <51488B6F.9050801@isi.edu> <1363709412.76925.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <20130319161627.GK51699@Space.Net> <2134F8430051B64F815C691A62D98318032F6A@XCH-BLV-504.nw.nos.boeing.com> <20130319163333.GM51699@Space.Net> <2134F8430051B64F815C691A62D98318033048@XCH-BLV-504.nw.nos.boeing.com> Message-ID: <1363712499.5395.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Tue, 19 Mar 2013 10:01:39 -0700 (PDT) From: Nalini Elkins To: "Templin, Fred L" , Gert Doering In-Reply-To: <2134F8430051B64F815C691A62D98318033048@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1619178251-1576618239-1363712499=:5395" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:01:44 -0000 --1619178251-1576618239-1363712499=:5395 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Guys,=0A=0A"However, if the=A0shim header was included by an ingress tunnel= endpoint somewhere=A0in the network beyond the original source and then re= moved by an=A0egress tunnel endpoint somewhere else in the network before t= he=0Afinal destination then it should be OK. But, you lose the=A0ability to= control the ID from either the source or destination."=0A=0A=0AVERY intere= sting point. =A0And, BTW, we would like to include more "value-added" infor= mation such as timestamp, etc. =A0 Our hope is that the value provided will= overcome all the work involved.=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AIn= side Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A__= ______________________________=0A From: "Templin, Fred L" =0ATo: Gert Doering =0ACc: Nalini Elkins ; "v6ops@ietf.org" =0ASent: Tue= sday, March 19, 2013 9:50 AM=0ASubject: RE: [v6ops] draft-elkins-v6ops-ipv6= -ipid-needed-00=0A =0AHi Gert,=0A=0A> -----Original Message-----=0A> From: = Gert Doering [mailto:gert@space.net]=0A> Sent: Tuesday, March 19, 2013 9:34= AM=0A> To: Templin, Fred L=0A> Cc: Gert Doering; Nalini Elkins; v6ops@ietf= .org=0A> Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00=0A> = =0A> Hi,=0A> =0A> On Tue, Mar 19, 2013 at 04:27:23PM +0000, Templin, Fred L= wrote:=0A> > As a TCP option, the shim could be inserted by the source and= =0A> > ignored by the destination. For UDP, there is a way to include=0A> >= a shim as long as both the source and destination are aware that=0A> > the= shim is present. On the wire, it would look like:=0A> =0A> That's the poin= t: changing all endpoints.=A0 And your UDP communication=0A> will mysteriou= sly fail if you happen to send a shim'ed packet to a=0A> remote host that d= oesn't implement it, so you need extra logic to=0A> notice the "ICMP port u= nreachable" coming back for the shim-pseudo-port=0A> and then fall back to = "no shim", which will only work if that ICMP=0A> actually comes, etc.=0A> = =0A> And firewalls will see the wrong UDP port, so throw away your packet.= =0A> =0A> "No go"=0A=0AYes, you are right - trying to include a UDP-encapsu= lated shim=0Aall the way from the source to the destination is going to bre= ak=0Adue to firewalls, packet filters and the like. However, if the=0Ashim = header was included by an ingress tunnel endpoint somewhere=0Ain the networ= k beyond the original source and then removed by an=0Aegress tunnel endpoin= t somewhere else in the network before the=0Afinal destination then it shou= ld be OK. But, you lose the=0Aability to control the ID from either the sou= rce or destination.=0A=0AThanks - Fred=0Afred.l.templin@boeing.com=0A=0A> G= ert Doering=0A>=A0 =A0 =A0 =A0 -- NetMaster=0A> --=0A> have you enabled IP= v6 on something today...?=0A> =0A> SpaceNet AG=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 Vorstand: Sebastian v. Bomhard=0A> Joseph-Dollinger-Bog= en 14=A0 =A0 =A0 =A0 =A0 Aufsichtsratsvors.: A. Grundner-=0A> Culemann=0A> = D-80807 Muenchen=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 HRB: 136055 (AG Muench= en)=0A> Tel: +49 (89) 32356-444=A0 =A0 =A0 =A0 =A0 =A0 USt-IdNr.: DE8131852= 79 --1619178251-1576618239-1363712499=:5395 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Guys,=

"However, if the shim header was included by an ingress tunnel endpo= int somewhere in th= e network beyond the original source and then removed by an egress tunnel endpoint somewher= e else in the network before the
final destination then it should be OK. But, you lose the = ability to control the ID from either the source or destina= tion."

VERY interesting point.  And, BTW,= we would like to include more "value-added" information such as timestamp,= etc.   Our hope is that the value provided will overcome all the work= involved.
 
Thanks,
<= br>
Nalini Elkins
Inside Products, Inc.
(831) 659-8360
w= ww.insidethestack.com

From: "Templin, Fred L" <Fred.L.= Templin@boeing.com>
To:= Gert Doering <gert@space.net>
Cc: Nalini Elkins <nalini.elkins@insidethestack.com&g= t;; "v6ops@ietf.org" <v6ops@ietf.org>
Sent: Tuesday, March 19, 2013 9:50 AM
Subject: RE: [v6ops] draft-elkins-v6= ops-ipv6-ipid-needed-00

=0AHi Gert,

> ----= -Original Message-----
> From: Gert Doering [mailto:gert@space.net]
&= gt; Sent: Tuesday, March 19, 2013 9:34 AM
> To: Templin, Fred L
&g= t; Cc: Gert Doering; Nalini Elkins; v6ops@ietf.org
> Subject: Re: [v6ops= ] draft-elkins-v6ops-ipv6-ipid-needed-00
>
> Hi,
>
&= gt; On Tue, Mar 19, 2013 at 04:27:23PM +0000, Templin, Fred L wrote:
>= ; > As a TCP option, the shim could be inserted by the source and
>= ; > ignored by the destination. For UDP, there is a way to include
&g= t; > a shim as long as both the source and destination are aware that> > the shim is present. On the wire, it would look like:
> > That's the point: changing all endpoints.  And your UDP communi= cation
> will mysteriously fail if you happen to send a shim'ed packet to a
> remote host that doesn't implement i= t, so you need extra logic to
> notice the "ICMP port unreachable" co= ming back for the shim-pseudo-port
> and then fall back to "no shim",= which will only work if that ICMP
> actually comes, etc.
> > And firewalls will see the wrong UDP port, so throw away your packet.=
>
> "No go"

Yes, you are right - trying to include a U= DP-encapsulated shim
all the way from the source to the destination is g= oing to break
due to firewalls, packet filters and the like. However, if= the
shim header was included by an ingress tunnel endpoint somewherein the network beyond the original source and then removed by an
egress= tunnel endpoint somewhere else in the network before the
final destinat= ion then it should be OK. But, you lose the
ability to control the ID fr= om either the source or destination.

Thanks - Fred
fred.l.templin@boeing.com

> Gert Doering
>=         -- NetMaster
> --
> have you enabl= ed IPv6 on something today...?
>
> SpaceNet AG    &n= bsp;                   Vorstan= d: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14    &nbs= p;     Aufsichtsratsvors.: A. Grundner-
> Culemann
> = D-80807 Muenchen                &nb= sp; HRB: 136055 (AG Muenchen)
> Tel: +49 (89) 32356-444   =         USt-IdNr.: DE813185279


--1619178251-1576618239-1363712499=:5395-- From nalini.elkins@insidethestack.com Tue Mar 19 10:04:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1227221F8CFA for ; Tue, 19 Mar 2013 10:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] 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 YDS--z1mzGtT for ; Tue, 19 Mar 2013 10:04:16 -0700 (PDT) Received: from nm12-vm0.access.bullet.mail.sp2.yahoo.com (nm12-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.126]) by ietfa.amsl.com (Postfix) with ESMTP id 694BD21F8CB5 for ; Tue, 19 Mar 2013 10:04:16 -0700 (PDT) Received: from [98.139.44.104] by nm12.access.bullet.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 17:04:15 -0000 Received: from [98.139.44.65] by tm9.access.bullet.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 17:04:15 -0000 Received: from [127.0.0.1] by omp1002.access.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 17:04:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 727571.8773.bm@omp1002.access.mail.sp2.yahoo.com Received: (qmail 18299 invoked by uid 60001); 19 Mar 2013 17:04:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1363712655; bh=MDf1CN8zXOFtT9dQHPvDY200ndOM7xWgvlkh79fmkb0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=S26SyIKSpti+DCva0PeCIyAAF4amjsdMkpXBPBWKsHgG+jcADHUqtaPDGQMq8KUco05PDowc6gmxvwjjd6ynWxxrXjB6E5Mc1s82Do5Kiyo+Hn9DfzJmNwtpNQC0jIBOYJqDHchHUSlRlqALLGCogpisOdxChCFXezDbrsPewNI= X-YMail-OSG: l4O4iXgVM1nezW5.zlgMfM_sOd7lHiNPeMz8_sIW3SsH3jP cOb1ECu_uUyjmBXDtOj2CLv7A3XKRRaIGg4NJ9ViQ5iYW98PyfXmkIagV.Cq _sSccfOtpkmGSuWYhpmtAxsvhrGLM_KcrBJhx17Vmm82BCse525WrwJKzdUU o.HVwM3rGtONtQ3rYI0XHg.Z5Em86ttzd9OaeFZxUb3MHRMThncBB4.Foyv8 2bSBSoHCnDwiNmSytaSU85c_pJRoRaivU4.Ri860OLfeWoSpn_kQZ6bUq5X. nERazHJxBbJ6oiHilzEJxytldu9IR4Kcnd2tTOChR_ff3RTec0pq.X2q9oMs XvlTAbCecnS_MfVqpHwz3opKCfVvZmcdZTWR6C2fF7QU3nluiFEgO3EcQJ1n eI8kLO.iWcPjWfl2mEQau8IvJfPd4SI_hhBGGIV1_qUnKcA.2o60o2zw.3f8 HuMpeIAOQaUZuR8BMovR8evnin.LFklllnYPmWR1sOwVwGOEIK14cW5AHIza lXDyaOwnIyHxPzF2xiLWbI508LKqoCbUip3q3TCZf23Km5TTOG6alsSRANSD ymBhTKz6uYlXnhKA5Ag0vKnYgdm1lsgiT_66ZaJhDU2.XshuFZTBdJEPdOp_ HDu0xfBcLfnTaAZTkhOHQa.ZqJnIEJa0sR1_5gZLSmNQbAVZVGTPvGuxOjPr C2YkQ_fRUEdw- Received: from [24.130.37.147] by web2802.biz.mail.ne1.yahoo.com via HTTP; Tue, 19 Mar 2013 10:04:14 PDT X-Rocket-MIMEInfo: 002.001, Sm9lbCwKClJUUCBpcyBxdWl0ZSBjb21wbGV4IGFuZCBpbnRlbGxpZ2VudC4gwqBZb3UgYWN0dWFsbHkgZW5kIHVwIHdpdGggOCBvciBzbyBwb3NzaWJsZSBoZWFkZXJzIChzb21ldGltZXMgbW9yZSB3aXRoIG9wdGlvbmFsIHNlZ21lbnRzKSBzdGFydGluZyB3aXRoIHRoZSBJUCBoZWFkZXIgdW50aWwgeW91IGdldCB0byB0aGUgZmluYWwgZGF0YSBwb3J0aW9uLiDCoChMZXQncyBob3BlIHRoYXQgcGFja2V0IHdhcyB3b3J0aCBzZW5kaW5nISDCoCkKCgpCdXQsIEkgdXNlZCBSVFAgYXMganVzdCBhbiBleGFtcGwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.138.524 References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <1363706036.36543.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032CD8@XCH-BLV-504.nw.nos.boeing.com> <1363708947.97060.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51489516.6000403@bogus.com> Message-ID: <1363712654.9739.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> Date: Tue, 19 Mar 2013 10:04:14 -0700 (PDT) From: Nalini Elkins To: joel jaeggli , "Templin, Fred L" , Nick Hilliard , "v6ops@ietf.org" In-Reply-To: <51489516.6000403@bogus.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-153701192-937103380-1363712654=:9739" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:04:18 -0000 ---153701192-937103380-1363712654=:9739 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Joel,=0A=0ARTP is quite complex and intelligent. =C2=A0You actually end up = with 8 or so possible headers (sometimes more with optional segments) start= ing with the IP header until you get to the final data portion. =C2=A0(Let'= s hope that packet was worth sending! =C2=A0)=0A=0A=0ABut, I used RTP as ju= st an example of a protocol embedded within UDP.=0A=C2=A0=0AThanks,=0A=0A= =0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethest= ack.com=0A=0A=0A=0A________________________________=0A From: joel jaeggli <= joelja@bogus.com>=0ATo: Nalini Elkins ; "= Templin, Fred L" ; Nick Hilliard ;= "v6ops@ietf.org" =0ASent: Tuesday, March 19, 2013 9:40 AM= =0ASubject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00=0A =0AOn 3/1= 9/13 9:02 AM, Nalini Elkins wrote:=0A> Fred,=0A> =0A> Definitely, we can us= e TCP seq and ack to find out-of-sequence packets on some occasions but as = we said in our draft there are quite a few other instances where this is no= t true. And, it is definitely not true for UDP.=0A> =0A> More and more uses= are being made of UDP to embed other protocols. Tunneling is often used fo= r UDP. Also one protocol we work with quite a bit is HPR over UDP.=0A> =0AA= UDP encapsulation of SNA is sensitive to duplicates?=0A=0AI think that's a= little more subtle than find the source of duplicates with different flags= in a TCP stream, TCP implementations should fundamentally not be sensitive= to duplicate packets.=0A=0AFrom my own foggy memory HPR has it's own dupli= cate detection reordering and retransmission mechanism (RTP), which is why = it runs on top of UDP rather than TCP iirc. If that has limitations that se= nd one to look to the ip header I guess that's a problem, but it seems like= a relatively constrained and well understood environment would exist aroun= d such flows. It also seems that in that particular case the shim already e= xists (unless it's totally inadequate) but you probably are in a better pos= ition to describe the limitations of RTP than I.=0A=0A> I think maybe we wi= ll now start to work on our draft of the solution we envisage and then mayb= e we can have a new discussion. We definitely will take all the suggestions= into account.=0A> =0A> Thank you all so much for spending time thinking ab= out this issue.=0A> =0A> Nalini Elkins=0A> Inside Products, Inc.=0A> (831) = 659-8360=0A> www.insidethestack.com=0A> =0A> ------------------------------= ------------------------------------------=0A> *From:* "Templin, Fred L" =0A> *To:* Nalini Elkins ; Nick Hilliard ; "v6ops@ietf.org" = =0A> *Sent:* Tuesday, March 19, 2013 8:30 AM=0A> *Subject:* RE: [v6ops] dra= ft-elkins-v6ops-ipv6-ipid-needed-00=0A> =0A> Hi Nalini,=0A> > I use Wiresha= rk incessantly. Believe me, IP ID is very needed in Wireshark.=0A> In the c= ase I examined, a sequence of TCP segments that were conveyed in 8-10=0A> p= ackets was being repeated. The sequence and ack numbers in each segment wer= e=0A> repeated exactly. I can=E2=80=99t be sure, but I don=E2=80=99t think = Wireshark even looked at the IPID=0A> because the extra packets were flagge= d as =E2=80=9Cout of order=E2=80=9D instead of duplicates. But,=0A> examini= ng the trend rather than an isolated packet pair left little doubt that the= y=0A> were duplicates.=0A> Thanks - Fred=0A> *From:*Nalini Elkins [mailto:n= alini.elkins@insidethestack.com]=0A> *Sent:* Tuesday, March 19, 2013 8:14 A= M=0A> *To:* Templin, Fred L; Nick Hilliard; v6ops@ietf.org=0A> *Subject:* R= e: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00=0A> Fred,=0A> I use Wires= hark incessantly. Believe me, IP ID is very needed in Wireshark.=0A> As a m= atter of fact, we know the folks at Wireshark very well. We help sponsor th= eir SharkFest event. I spoke there last year & will be again this year. I a= m trying to twist people's arms at Wireshark to come to IETF and speak for = themselves. Well, maybe Berlin.=0A> BTW, quite a while back, we asked Geral= d Combs, the original developer of Wireshark, to comment on our RFC and wor= k with us. He supports our efforts. I am copying his response to me here. J= anice is our contact at Riverbed who "own" Wireshark. He is speaking of the= IP ID field in the note below.=0A> Hi Janice and Nalini,=0A> =0A> I think = this is a great idea! An explicit (and separate) diagnostic field for IPv6 = would definitely be helpful for Wireshark, Pilot (particularly for its MSA = feature) and many other tools.=0A> =0A> Two quick notes:=0A> =0A> You might= want to add a SHOULD NOT or MUST NOT explicitly stating that gateways must= not modify or remove the IPID from packets that they forward.=0A> =0A> Man= y OSes support random IP IDs (e.g. my laptop has a "net.inet.ip.random_id" = sysctl which is currently enabled), primarily to improve security. Is that = needed here?=0A> Thanks,=0A> Nalini Elkins=0A> Inside Products, Inc.=0A> (8= 31) 659-8360=0A> www.insidethestack.com =0A= > ------------------------------------------------------------------------= =0A> *From:*"Templin, Fred L" >=0A> *To:* Nalini Elkins >; Nick Hilliard >; "v6ops@ietf.org " >=0A> *Sent:* Tuesday, March 19, 2013 7:56 AM=0A= > *Subject:* RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00=0A> Hi Nali= ni=0A> I=E2=80=99ll agree that you can construct an example showing a pair = of packets with the=0A> same (src, dst, seq, ack)-tuple yet the packets are= not duplicates. But, diagnostics=0A> can=E2=80=99t be limited to an isolat= ed pair of packets and need to observe a trend over=0A> many packets. Again= , diagnostic tools like Wireshark seem to be already producing=0A> effectiv= e diagnostics based just on the information at hand =E2=80=93 I recently us= ed the=0A> tool to identify a case of in-the-network packet duplication wit= hin our network.=0A> Does anyone know what the Wireshark team thinks about = this?=0A> Thanks - Fred=0A> *From:*Nalini Elkins [mailto:nalini.elkins@insi= dethestack.com]=0A> *Sent:* Monday, March 18, 2013 5:49 PM=0A> *To:* Templi= n, Fred L; Nick Hilliard; v6ops@ietf.org =0A> *Subje= ct:* Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00=0A> Fred,=0A> TCP s= equence number is not enough because there can be duplicate segments and re= transmissions. We need a way to see if these are really sent by the device = or if they are just a problem in packet tracing.=0A> Also, in the case of r= esets, the SEQ and ACK may also be duplicated. Let me give you real example= :=0A> pkt 1: seq no: 123 ack: 345 ttl: 60 IPID: 123 src addr: 1.2.3.4 dest = addr : 4.5.6.7=0A> pkt 2: seq no: 123 ack: 345 ttl: 254 IPID: FF2A src addr= : 1.2.3.4 dest addr: 4.5.6.7 TCP RESET flag set=0A> The time between these = two packets is quite small. They have also been having problems with connec= tions failing.=0A> My conclusion would be that the second packet was NOT se= nt by the same device that sent the first. Why? Because BOTH IPID and TTL a= re quite different. Very unlikely that the originating device is going to c= hange BOTH that quickly. I would conclude that there is a box in the middle= sending a RESET for that session. And, actually, when we replaced the devi= ce that we felt was the problem, sessions stayed up!=0A> This is just one c= ase. In our draft, we had quite a few others, as you remember from the pres= entation.=0A> Definitely, we need a sequence number field that is more than= 16 bits. Wrapping is a problem.=0A> But, the point is well taken that the = down side of a SHIM is that both sides have to implement. Noted.=0A> Thanks= ,=0A> Nalini Elkins=0A> Inside Products, Inc.=0A> (831) 659-8360=0A> www.in= sidethestack.com =0A> ---------------------= ---------------------------------------------------=0A> *From:*"Templin, Fr= ed L" >=0A> *T= o:* Nalini Elkins >; Nick Hilliard >; "v= 6ops@ietf.org " >=0A> *Sent:* Monday, March 18, 2013 3:53 PM=0A> *Subject:* RE: [v6ops] = draft-elkins-v6ops-ipv6-ipid-needed-00=0A> Hi Nalini,=0A> For a shim header= between the transport and the application data, TCP provides=0A> TCP optio= ns so you could consider a new TCP option. But, TCP already includes=0A> se= quence numbers that can be used for diagnostic purposes =E2=80=93 in fact, = Wireshark=0A> (and I=E2=80=99m sure other network diagnostic tools) already= use that. So, I don=E2=80=99t see=0A> a shim as a big win for TCP.=0A> For= UDP, there would need to be a new UDP port number assignment, and a=0A> ne= w piece of code at both the source and destination. The source would have= =0A> to insert the shim about the UDP header, and the destination would hav= e to=0A> remove it. That is the same model that SEAL is addressing, but SEA= L is expecting=0A> both ends to implement the protocol. So, unfortunately, = there is no way to=0A> have a source-only patch that does not also require = a patch at the destination.=0A> Thanks - Fred=0A> *From:*v6ops-bounces@ietf= .org [mailto:v6ops-bounces@ietf.org] *On Be= half Of *Nalini Elkins=0A> *Sent:* Monday, March 18, 2013 3:40 PM=0A> *To:*= Nick Hilliard; v6ops@ietf.org =0A> *Subject:* Re: [= v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00=0A> Nick,=0A> Totally agree w= ith you about trying to understand each other's point of view. We absolutel= y want to do that. I think Mike was responding to the comment on the need f= or IPID itself.=0A> As far as a solution, we are thinking that IPv6 extensi= on headers are a non-starter. For all the reasons that have been brought up= .=0A> So, we are thinking of a header higher up the layers. For example, be= tween the Transport Layer (TCP / UDP) and the application payload.=0A> What= are opinions from people on that?=0A> Thanks,=0A> Nalini Elkins=0A> Inside= Products, Inc.=0A> (831) 659-8360=0A> www.insidethestack.com =0A> ---------------------------------------------------= ---------------------=0A> *From:*Nick Hilliard >=0A> *To:* v6ops@ietf.org =0A> *Sent:* Monda= y, March 18, 2013 2:56 PM=0A> *Subject:* Re: [v6ops] draft-elkins-v6ops-ipv= 6-ipid-needed-00=0A> =0A> On 18/03/2013 21:37, Ackermann, Michael wrote:=0A= > > Since beginning to explore this issue of IPID, it has become clear how= =0A> > valuable IPID has been to our organization and many like us. I have= =0A> > personally not talked with everyone about this, but to those I have,= the=0A> > preponderance would not like to see this beneficial diagnostic f= eature=0A> > lost.=0A> =0A> Mike, Nalini,=0A> =0A> I understand that using = IPID works for you when diagnosing connectivity=0A> problems in ipv4. Do yo= u understand that ipv6 extension headers cause=0A> massive operational head= aches which we cannot get around using today's=0A> technology? And that as = a working group, the operational people here are=0A> baulking at the idea o= f creating more extension headers because it makes=0A> our lives massively = more difficult?=0A> =0A> If everyone doesn't understand each others' points= of view, this=0A> conversation is going to continue running around in circ= les, causing=0A> nothing but frustration.=0A> =0A> Nick=0A> =0A> __________= _____________________________________=0A> v6ops mailing list=0A> v6ops@ietf= .org =0A> https://www.ietf.org/mailman/listinfo/v6op= s=0A> =0A> =0A> =0A> =0A> _______________________________________________= =0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman= /listinfo/v6ops ---153701192-937103380-1363712654=:9739 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Joel,
=
RTP is quite c= omplex and intelligent.  You actually end up with 8 or so possible hea= ders (sometimes more with optional segments) starting with the IP header un= til you get to the final data portion.  (Let's hope that packet was wo= rth sending!  3D"*:))

=
But= , I used RTP as just an example of a protocol embedded within UDP.
 
Thanks,

Nalini Elkins
In= side Products, Inc.
(831) 659-8360
www.insidethestack.com

<= div style=3D"font-family: 'times new roman', 'new york', times, serif; font= -size: 12pt;">
From: joel jaeggli= <joelja@bogus.com>
To: Nalini Elkins <nalini.elkins@insidethestack.com>; "Templin, F= red L" <Fred.L.Templin@boeing.com>; Nick Hilliard <nick@inex.ie>= ;; "v6ops@ietf.org" <v6ops@ietf.org>
Sent: Tuesday, March 19, 2013 9:40 AM
Subject: Re: [v6ops] draft-elkins-v6ops= -ipv6-ipid-needed-00

On 3/19/13 9:02 AM, Nalini Elki= ns wrote:
> Fred,
>
> Definitely, we can use TCP seq and= ack to find out-of-sequence packets on some occasions but as we said in ou= r draft there are quite a few other instances where this is not true. And, = it is definitely not true for UDP.
>
> More and more uses are = being made of UDP to embed other protocols. Tunneling is often used for UDP= . Also one protocol we work with quite a bit is HPR over UDP.
>
A= UDP encapsulation of SNA is sensitive to duplicates?

I think that's= a little more subtle than find the source of duplicates with different fla= gs in a TCP stream, TCP implementations should fundamentally not be sensitive to duplicate packets.

From my own foggy memory HPR has it= 's own duplicate detection reordering and retransmission mechanism (RTP), w= hich is why it runs on top of UDP rather than TCP iirc. If that has limitat= ions that send one to look to the ip header I guess that's a problem, but i= t seems like a relatively constrained and well understood environment would= exist around such flows. It also seems that in that particular case the sh= im already exists (unless it's totally inadequate) but you probably are in = a better position to describe the limitations of RTP than I.

> I = think maybe we will now start to work on our draft of the solution we envis= age and then maybe we can have a new discussion. We definitely will take al= l the suggestions into account.
>
> Thank you all so much for = spending time thinking about this issue.
>
> Nalini Elkins
= > Inside Products, Inc.
> (831) 659-8360
> www.insidethestack.com
>
> ----------------------------------= --------------------------------------
> *From:* "Templin, Fred L" &l= t;Fred.L.Templin@boeing.com>
> *To:* Nalini Elk= ins <nalini.elkins@insidethestack.com&g= t;; Nick Hilliard <nick@inex.ie>; "v6ops@ietf.org" <v6ops@ietf.org>
> = *Sent:* Tuesday, March 19, 2013 8:30 AM
> *Subject:* RE: [v6ops] draf= t-elkins-v6ops-ipv6-ipid-needed-00
>
> Hi Nalini,
> >= I use Wireshark incessantly. Believe me, IP ID is very needed in Wireshark= .
> In the case I examined, a sequence of TCP segments that were conveyed in 8-10=
> packets was being repeated. The sequence and ack numbers in each s= egment were
> repeated exactly. I can=E2=80=99t be sure, but I don=E2= =80=99t think Wireshark even looked at the IPID
> because the extra p= ackets were flagged as =E2=80=9Cout of order=E2=80=9D instead of duplicates= . But,
> examining the trend rather than an isolated packet pair left= little doubt that they
> were duplicates.
> Thanks - Fred
&= gt; *From:*Nalini Elkins [mailto:nalini.elkins= @insidethestack.com]
> *Sent:* Tuesday, March 19, 2013 8:14 AM> *To:* Templin, Fred L; Nick Hilliard; v6ops@ietf.org
> *Subject:* = Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
> Fred,
> I = use Wireshark incessantly. Believe me, IP ID is very needed in Wireshark.
> As a m= atter of fact, we know the folks at Wireshark very well. We help sponsor th= eir SharkFest event. I spoke there last year & will be again this year.= I am trying to twist people's arms at Wireshark to come to IETF and speak = for themselves. Well, maybe Berlin.
> BTW, quite a while back, we ask= ed Gerald Combs, the original developer of Wireshark, to comment on our RFC= and work with us. He supports our efforts. I am copying his response to me= here. Janice is our contact at Riverbed who "own" Wireshark. He is speakin= g of the IP ID field in the note below.
> Hi Janice and Nalini,
&g= t;
> I think this is a great idea! An explicit (and separate) diagno= stic field for IPv6 would definitely be helpful for Wireshark, Pilot (parti= cularly for its MSA feature) and many other tools.
>
> Two qui= ck notes:
>
> You might want to add a SHOULD NOT or MUST NOT explicitly stating that gateways must not modify or remove the IP= ID from packets that they forward.
>
> Many OSes support rando= m IP IDs (e.g. my laptop has a "net.inet.ip.random_id" sysctl which is curr= ently enabled), primarily to improve security. Is that needed here?
>= Thanks,
> Nalini Elkins
> Inside Products, Inc.
> (831) = 659-8360
> www.insidethestack.com <http://www.insidethestack.com/>
>= ; ------------------------------------------------------------------------<= br>> *From:*"Templin, Fred L" <Fred.L.Templin@boeing.c= om <mailto:Fred.L.Templin@boeing.com>>
&= gt; *To:* Nalini Elkins <nalini.elkins@insidethest= ack.com <mailto:nalini.elkins@insidethe= stack.com>>; Nick Hilliard <nick@inex.ie <mailto:nick@inex.ie>>; "<= a ymailto=3D"mailto:v6ops@ietf.org" href=3D"mailto:v6ops@ietf.org">v6ops@ie= tf.org <mailto:v6ops@ietf.org>" <v6ops@ietf.org <mailto:v6ops@ietf.org>>
> *Sent:* Tuesday, March 19, 2013 7:56 AM
> *Subject= :* RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
> Hi Nalini
= > I=E2=80=99ll agree that you can construct an example showing a pair of packets with the
> sa= me (src, dst, seq, ack)-tuple yet the packets are not duplicates. But, diag= nostics
> can=E2=80=99t be limited to an isolated pair of packets and= need to observe a trend over
> many packets. Again, diagnostic tools= like Wireshark seem to be already producing
> effective diagnostics = based just on the information at hand =E2=80=93 I recently used the
>= tool to identify a case of in-the-network packet duplication within our ne= twork.
> Does anyone know what the Wireshark team thinks about this?<= br>> Thanks - Fred
> *From:*Nalini Elkins [mailto:nalini.elkins@insidethestack.com]
> *Sent:* Monday, = March 18, 2013 5:49 PM
> *To:* Templin, Fred L; Nick Hilliard; v6ops@ietf.or= g <mailto:v6ops@ietf.org>
> *Subject:* Re: [v6ops] draft-elkins-v6o= ps-ipv6-ipid-needed-00
> Fred,
> TCP sequence number is not eno= ugh because there can be duplicate segments and retransmissions. We need a = way to see if these are really sent by the device or if they are just a pro= blem in packet tracing.
> Also, in the case of resets, the SEQ and AC= K may also be duplicated. Let me give you real example:
> pkt 1: seq = no: 123 ack: 345 ttl: 60 IPID: 123 src addr: 1.2.3.4 dest addr : 4.5.6.7> pkt 2: seq no: 123 ack: 345 ttl: 254 IPID: FF2A src addr: 1.2.3.4 des= t addr: 4.5.6.7 TCP RESET flag set
> The time between these two packe= ts is quite small. They have also been having problems with connections fai= ling.
> My conclusion would be that the second packet was NOT sent by= the same device that sent the first. Why? Because BOTH IPID and TTL are quite different. Very unlikely that the originating device is going to cha= nge BOTH that quickly. I would conclude that there is a box in the middle s= ending a RESET for that session. And, actually, when we replaced the device= that we felt was the problem, sessions stayed up!
> This is just one= case. In our draft, we had quite a few others, as you remember from the pr= esentation.
> Definitely, we need a sequence number field that is mor= e than 16 bits. Wrapping is a problem.
> But, the point is well taken= that the down side of a SHIM is that both sides have to implement. Noted.<= br>> Thanks,
> Nalini Elkins
> Inside Products, Inc.
>= (831) 659-8360
> www.insidethestack.com <http://www.insidethestack.com/>=
> ------------------------------------------------------------------= ------
> *From:*"Templin, Fred L" <Fred.L.Templin@boeing.com <mailto:Fred.L= .Templin@boeing.com>>
> *To:* Nalini Elkins <nalini.elkins@insidethestack.com <mailto:nalini.elkins@insidethestack.com>>; Nick Hil= liard <n= ick@inex.ie <mailto:nick@inex.ie>>; "v6ops@ietf.org <mailto:v6ops@ietf.org>" <v6ops@iet= f.org <mailto:v6ops@ietf.org>>
> *Sent:* Monday, March 18, = 2013 3:53 PM
> *Subject:* RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-ne= eded-00
> Hi Nalini,
> For a shim header between the transport = and the application data, TCP provides
> TCP options so you could con= sider a new TCP option. But, TCP already includes
> sequence numbers = that can be used for diagnostic purposes =E2=80=93 in fact, Wireshark
&g= t; (and I=E2=80=99m sure other network diagnostic tools) already use that. = So, I don=E2=80=99t see
> a shim as a big win for TCP.
> For UD= P, there would need to be a new UDP port number assignment, and a
> n= ew piece of code at both the source and destination. The source would have<= br>> to insert the shim about the UDP header, and the destination would = have to
> remove it. That is the same model that SEAL is addressing, but SEAL is exp= ecting
> both ends to implement the protocol. So, unfortunately, ther= e is no way to
> have a source-only patch that does not also require = a patch at the destination.
> Thanks - Fred
> *From:*v= 6ops-bounces@ietf.org <mailto:v6ops-bounces@ietf.org>= ; [mailto:v6ops-bounces@ietf.org] *On Behalf Of *Nalini Elkins=
> *Sent:* Monday, March 18, 2013 3:40 PM
> *To:* Nick Hilliard= ; v6ops= @ietf.org <mailto:v6ops@ietf.org>
> *Subject:* Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
> Nick,
> Totally agree= with you about trying to understand each other's point of view. We absolut= ely want to do that. I think Mike was responding to the comment on the need= for IPID itself.
> As far as a solution, we are thinking that IPv6 e= xtension headers are a non-starter. For all the reasons that have been brou= ght up.
> So, we are thinking of a header higher up the layers. For e= xample, between the Transport Layer (TCP / UDP) and the application payload= .
> What are opinions from people on that?
> Thanks,
> Na= lini Elkins
> Inside Products, Inc.
> (831) 659-8360
> ww= w.insidethestack.com <http://www.insidethestack.com/>
> ----------------= --------------------------------------------------------
> *From:*Nic= k Hilliard <nick@inex.ie <mailto:nick@inex.ie>>
= > *To:* v6ops@ietf.org <mailto:v6ops@ietf.org>
> *Sent:* Monday, M= arch 18, 2013 2:56 PM
> *Subject:* Re: [v6ops] draft-elkins-v6ops-ipv= 6-ipid-needed-00
>
> On 18/03/2013 21:37, Ackermann, Michael w= rote:
> > Since beginning to explore this issue of IPID, it has be= come clear how
> > valuable IPID has been to our organization and = many like us. I have
> > personally not talked with everyone about= this, but to those I have, the
> > preponderance would not like t= o see this beneficial diagnostic feature
> > lost.
>
>= ; Mike, Nalini,
>
> I understand that using IPID works for you= when diagnosing connectivity
> problems in ipv4. Do you understand that i= pv6 extension headers cause
> massive operational headaches which we = cannot get around using today's
> technology? And that as a working g= roup, the operational people here are
> baulking at the idea of creat= ing more extension headers because it makes
> our lives massively mor= e difficult?
>
> If everyone doesn't understand each others' p= oints of view, this
> conversation is going to continue running aroun= d in circles, causing
> nothing but frustration.
>
> Nic= k
>
> _______________________________________________
> = v6ops mailing list
> v6ops@ietf.org <mailto:v6ops@ietf.org>
> <= a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" target=3D"_blank">https://www.ietf.org/mailman/listinfo/v6ops
> =
>
>
>
> _______________________________________= ________
> v6ops mailing list
> v6ops@ietf.org
> https://www.= ietf.org/mailman/listinfo/v6ops



---153701192-937103380-1363712654=:9739-- From nalini.elkins@insidethestack.com Tue Mar 19 10:05:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD6421F8DDF for ; Tue, 19 Mar 2013 10:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cx53e8nQRgTw for ; Tue, 19 Mar 2013 10:05:40 -0700 (PDT) Received: from nm22-vm0.access.bullet.mail.sp2.yahoo.com (nm22-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.178]) by ietfa.amsl.com (Postfix) with ESMTP id 72A6A21F84F9 for ; Tue, 19 Mar 2013 10:05:40 -0700 (PDT) Received: from [98.139.44.106] by nm22.access.bullet.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 17:05:37 -0000 Received: from [98.139.44.72] by tm11.access.bullet.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 17:05:37 -0000 Received: from [127.0.0.1] by omp1009.access.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 17:05:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 701282.76406.bm@omp1009.access.mail.sp2.yahoo.com Received: (qmail 54356 invoked by uid 60001); 19 Mar 2013 17:05:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1363712737; bh=57A/nsIC91bzbgLh5QDdiN/osVtJ29SvvS3A3YuRWD0=; 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; b=2ITUK/dnl+hXm0kgW10U4YGwp3MrZUz4RvLHSfvEUPt+GYi9EX/e0XYa0IUzNp6KhOCNKmSuctDaOTxMjS0L4xRo5hDlhH2qe9ffbKMDokiLLd8eUo6sQ9egRDw3pt4aPL9+oUz5p9LAmCDp5NYBSBV9Dbm50N00Qu+n6QEJbC8= X-YMail-OSG: jeMPQNsVM1lb1wpmPLkY8.r0QPavvYjY0QiV93VcmNdCVJT WuWpMzeLOdyLq9vR2UR.tK922u8vLg0fYRE_Dw8TuUti4b6SkTd8KOpA0uvl Qe31pfK9uq3gRIWP3GLWoxITLAXbRY8qFTV1Ab5Ih1oAmrQmz0.R9vYSgne8 L1n_.8Mcy_6CJAUtkrHo.7vkGDhjTYjf.WfRTQefPDU5SHDpQ_8_FH4z9Vry UIsjRM36T0iYR2ED4eHiGPWzC6w9Uhx47ZdwlfFuw3XT5sMfO5vaOzywgHR7 HQSvktzz0hgSkjrZDoUsM2r.T7xpjEVD.nmFZiaX3oTwjXC0xugCo0.HuWZJ OhKNn0TzMK0q9wCMmHyUbyDotS9P5F.NmgYZhMJiBjvWQxsZFjNu9tYCxp9_ ._IG9sFUM2hQBpcRW4ODo28GWh_kptPHQZzaBUt9Qn1j6Q10hkKyv7WG4Sp7 IRZDPI3OSeHpr_n6Za0zu4DreguRFv89QhDL4Cb2Gk8MidWVKKKaCOoJcVX3 EGTx57BQo2n1V9_CFVCe1rEU4sd2tT5.UMikcmP.R4K24sg_Q2oXcmkQZSmP qCFxEJte.U.hLlliilnTKZctSbbWXfBi6BxD.1e9iPnyH Received: from [24.130.37.147] by web2806.biz.mail.ne1.yahoo.com via HTTP; Tue, 19 Mar 2013 10:05:37 PDT X-Rocket-MIMEInfo: 002.001, IkJ1dCBjb21wYW5pZXMgYXJlIG1vb3QgYW55d2F5LCB0aGV5IGRvIHdoYXQgdGhleSB3YW50LCBhbmQgaW4gd2hpY2ggdGltZcKgZnJhbWUgdGhleSB3YW50IHRoYXQgLSB0aGUgSW50ZXJuZXQgYXQgbGFyZ2UgaXMgYWxyZWFkeSBtb3ZpbmcgdG8gSVB2NizCoGFuZCBpdCdzIHRvbyBsYXRlIGZvciBmdW5kYW1lbnRhbCBjaGFuZ2VzIHRvIHRoZSBwYWNrZXQgZm9ybWF0IG9yIHRoZQpzdGFja3MuIgoKCk1heWJlLgrCoApUaGFua3MsCgoKTmFsaW5pIEVsa2lucwpJbnNpZGUgUHJvZHVjdHMsIEluYy4KKDgzMSkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.138.524 References: <51488615.8030805@isi.edu> <1363708250.41275.YahooMailClassic@web2802.biz.mail.ne1.yahoo.com> <20130319155955.GI51699@Space.Net> <1363709365.33312.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <20130319161436.GJ51699@Space.Net> Message-ID: <1363712737.54194.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Date: Tue, 19 Mar 2013 10:05:37 -0700 (PDT) From: Nalini Elkins To: Gert Doering In-Reply-To: <20130319161436.GJ51699@Space.Net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1510626085-1636030742-1363712737=:54194" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:05:41 -0000 --1510626085-1636030742-1363712737=:54194 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable "But companies are moot anyway, they do what they want, and in which time= =A0frame they want that - the Internet at large is already moving to IPv6,= =A0and it's too late for fundamental changes to the packet format or the=0A= stacks."=0A=0A=0AMaybe.=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Prod= ucts, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A___________= _____________________=0A From: Gert Doering =0ATo: Nalini E= lkins =0ACc: Gert Doering ; Bill Jouris ; "v6ops@ietf.org" =0ASent: Tuesday, March 19, 2013 9:14 AM=0ASubject: Re: [v6ops] dr= aft-elkins-v6ops-ipv6-ipid-needed-00=0A =0AHi,=0A=0AOn Tue, Mar 19, 2013 at= 09:09:25AM -0700, Nalini Elkins wrote:=0A> Actually, in my experience, man= y companies are resisting the move to IPv6 because they see no business rea= son. =A0 If we can have improved performance and diagnostics for IPv6 by th= e method that we envision, this may actually SPEED the move to IPv6. =A0At = least in corporate America, which has been our world for many years.=0A=0AI= f it's "bring back an ipid similar to what IPv4 has" it's not "better than= =0AIPv4".=A0 Not compelling enough, if all the other arguments for IPv6 are= =0Anot heeded.=0A=0ABut companies are moot anyway, they do what they want, = and in which time=0Aframe they want that - the Internet at large is already= moving to IPv6,=0Aand it's too late for fundamental changes to the packet = format or the=0Astacks.=0A=0AGert Doering=0A=A0 =A0 =A0 =A0 -- NetMaster=0A= -- =0Ahave you enabled IPv6 on something today...?=0A=0ASpaceNet AG=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Vorstand: Sebastian v. Bomhard=0AJo= seph-Dollinger-Bogen 14=A0 =A0 =A0 =A0 =A0 Aufsichtsratsvors.: A. Grundner-= Culemann=0AD-80807 Muenchen=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 HRB: 136055= (AG Muenchen)=0ATel: +49 (89) 32356-444=A0 =A0 =A0 =A0 =A0 =A0 USt-IdNr.: = DE813185279 --1510626085-1636030742-1363712737=:54194 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
"But = companies are moot anyway, they do what they want, and in which time <= /span>frame they want that - the Internet at large is alrea= dy moving to IPv6, and it's too late for fundam= ental changes to the packet format or the
stacks."

Maybe.
 =
Thanks,

Nalini Elkins
Inside Products, Inc.=
(831) 659-8360
www.insidethestack.com

From: Gert Doering <gert@space.net&= gt;
To: Nalini Elkins <nalini.elkins@insidethestack.com>
Cc: Gert Doering <gert@space.net>; Bill Jouris &l= t;bill.jouris@insidethestack.com>; "v6ops@ietf.org" <v6ops@ietf.org&g= t;
Sent: Tuesday, Mar= ch 19, 2013 9:14 AM
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
=0AHi,

On Tue, Mar 19, 2013 at 09:09:25AM -0700, Nalini Elkins= wrote:
> Actually, in my experience, many companies are resisting th= e move to IPv6 because they see no business reason.   If we can have i= mproved performance and diagnostics for IPv6 by the method that we envision= , this may actually SPEED the move to IPv6.  At least in corporate Ame= rica, which has been our world for many years.

If it's "bring back a= n ipid similar to what IPv4 has" it's not "better than
IPv4".  Not = compelling enough, if all the other arguments for IPv6 are
not heeded.
But companies are moot anyway, they do what they want, and in which t= ime
frame they want that - the Internet at large is already moving to IP= v6,
and it's too late for fundamental changes to the packet format or th= e
stacks.

Gert Doering
        -- NetMaste= r
--
have you enabled IPv6 on something today...?

SpaceNet AG                    &n= bsp;   Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14&nbs= p;         Aufsichtsratsvors.: A. Grundner-Culemann
= D-80807 Muenchen                &nb= sp; HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444    &nbs= p;       USt-IdNr.: DE813185279


<= /div>
--1510626085-1636030742-1363712737=:54194-- From nalini.elkins@insidethestack.com Tue Mar 19 10:10:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E42C21F8D8F for ; Tue, 19 Mar 2013 10:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] 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 JQjQG8xuFOH2 for ; Tue, 19 Mar 2013 10:10:49 -0700 (PDT) Received: from nm8.access.bullet.mail.sp2.yahoo.com (nm8.access.bullet.mail.sp2.yahoo.com [98.139.44.135]) by ietfa.amsl.com (Postfix) with ESMTP id 739D821F8D8D for ; Tue, 19 Mar 2013 10:10:49 -0700 (PDT) Received: from [98.139.44.107] by nm8.access.bullet.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 17:10:44 -0000 Received: from [98.139.44.88] by tm12.access.bullet.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 17:10:44 -0000 Received: from [127.0.0.1] by omp1025.access.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 17:10:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 566867.82924.bm@omp1025.access.mail.sp2.yahoo.com Received: (qmail 32749 invoked by uid 60001); 19 Mar 2013 17:10:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1363713043; bh=M9n+XVd/XzYGEvJtlN5Bfnij+/6+VxkvSYNOS7zDkuA=; 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; b=V82nuIBlaWsUycr9tNxuP38GIdcAmOgPodRwScU3CYOWHj7hKbZBbfcemEMsU7UQ8UksSaWLIdTM9PpDP6tBHOzjAAXN18FMf0rVH+1grdz/eIyDPnCpHhQjzxafLF3fKKsHwADKEZOIq3VjsjEV26ax1q8/+jczzC/Wpibasrg= X-YMail-OSG: tAHOaBUVM1l1sHQSETywTms46qPkxdu.OUcN6bwWZKiNS0h cwv2wocHRWdHtLMcqu_Kh9TZ6vhkOv5cEVC_HapFwqfgts6.c13.7sBqCOqp YiKJf_eTq3d.Kycw0Q8wccaO4lRzmbCaTpi3LIBPr50wNL_L_OlUzU8ZpOqy n18MfeLP7fjkoJiFfemCP86LLHuZIQ9KGFeoQ8QQb40T_hvLzsSgad4sx8b6 jpuhI2qZsIeYQgpp8SS46lUOryDqpiWQzzSyFqUw6cjEdnZfiPWgBSYL2_Ut S5rP77CJfcOyaD.R5Hdfz4ucK7qGaQjF1r4iR6ay.mVx1iEKTPNM08bhsfsu .89cGtG4Vsmr8NUQHcRHQktIsfCbSIDXGRL1vNjGy3W0jJV8rtR1Zd7EMLnn MG8udoNQ.3zIWKX0NWwp4smWDwMlmTUzRxOOrkbi_Pebk1fiyUdE5YMmE5KG eZUzvnCunaKLvRcCVM5wKCEm8JJGxo1_kkMqKlYKzosmgUdvXal3Bnr0Nqob 8mxpnshYJJ6okXuMae83rgTSxGwIS7Ua.Hb5pO6_HD_qtuTVBrlBhcRSr3le fTPv1t7GRdJjc89LxMdwqPx_UgrXV.w4na3N2ocGrh4g- Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Tue, 19 Mar 2013 10:10:43 PDT X-Rocket-MIMEInfo: 002.001, V2hhdCB3ZSB3YW50IGlzIGEgd2F5IHRvIG1ha2UgdGhlIFNISU0gc29tZWhvdyBvcHRpb25hbC4KCkRlZmluaXRlbHksIEkgY2FuIHNlZSBwZW9wbGUgb3RoZXIgdGhhbiB1cyB3YW50aW5nIHRvIHVzZSBpdC4gwqDCoAoKSSBrbm93IGtpZHMgYXQgdGhlIGxvY2FsIHVuaXZlcnNpdHkgYXJlIHByb2dyYW1taW5nIGFwcHMgZm9yIEFuZHJvaWQgdGhhdCBhcmUgZm9yIHRoZSB1c2VycyBvZiBFbWVyZ2VuY3kgTWVkaWNhbCBhbmQgRmlyZS4gwqAgVGhpcyBpcyBhIGNyaXRpY2FsIGFwcC4gwqBUaGV5IG1pZ2h0IHcBMAEBAQE- X-Mailer: YahooMailWebService/0.8.138.524 References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <51488615.8030805@isi.edu> <4FC37E442D05A748896589E468752CAA0A64ED7F@PWN401EA160.ent.corp.bcbsm.com> <51489021.9060709@isi.edu> <4FC37E442D05A748896589E468752CAA0A64EE31@PWN401EA160.ent.corp.bcbsm.com> <5148975D.2030102@isi.edu> Message-ID: <1363713043.32504.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Tue, 19 Mar 2013 10:10:43 -0700 (PDT) From: Nalini Elkins To: Joe Touch , "Ackermann, Michael" In-Reply-To: <5148975D.2030102@isi.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-1837633256-1363713043=:32504" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:10:54 -0000 ---1551098171-1837633256-1363713043=:32504 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable What we want is a way to make the SHIM somehow optional.=0A=0ADefinitely, I= can see people other than us wanting to use it. =A0=A0=0A=0AI know kids at= the local university are programming apps for Android that are for the use= rs of Emergency Medical and Fire. =A0 This is a critical app. =A0They might= want reliable access and performance diagnostics.=0A=0AI can imagine that = if cell phone companies started offering different classes of service to th= e Internet (I know people will get all up in arms about this!). =A0But, if = it is a way for them to charge more, they may want to do it. =A0Any time yo= u charge more, people will want to monitor if they are getting what they pa= id for. =A0 Hey, use our SHIM!=0A=0AHaving said all this, in my humble expe= rience, the corporate world is not exactly powerless in getting what they w= ant implemented.=0A=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Products= , Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A_______________= _________________=0A From: Joe Touch =0ATo: "Ackermann, Mich= ael" =0ACc: "Templin, Fred L" ; Nalini Elkins ; Nick Hilliard ; "v6ops@ietf.org" =0ASent: Tuesday, March 19, 2= 013 9:50 AM=0ASubject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00= =0A =0AI think Fred and I have made our position clear.=0A=0AA few bits may= be millions to you or even to a few of your clients, but =0Ait's hundreds = of billions to everyone else. That's not a business model =0Athat the IETF = should support.=0A=0AJoe=0A=0AOn 3/19/2013 9:36 AM, Ackermann, Michael wrot= e:=0A> Joe,=0A>=0A> As I think others have said, I do not see this as a bus= iness model.=A0 But only as simple math.=0A>=0A> If I can add some number = of bits to every (or many) packets,=A0 there is a technical cost there, tha= t I fully understand.=A0 =A0 However, if these bits save me even 10 hours = per year (and it is much more in my cases), this translates into hundreds o= f millions of dollars or more to my company and others.=A0 No matter what = your cost per bit is, it will never come close to that.=A0 Not to mention = the direct or indirect costs to the application or business.=A0 =A0 So no m= atter what I might think as a pure technician or architect, guess what my b= oss or my CEO will say.=A0 Simple math is the only math that executives un= derstand and frequently they do not understand math at all that is not pref= ixed with a $.=0A>=0A> Regards to the whole packet technique.=A0 My person= al view is that if I have to program or buy a product, to do what the proto= col inherently does today, that is a big step back and a deterrent to IPV6 = deployment.=A0 =A0 I am one of the very few pro IPV6 people in my organizat= ion and those I work with.=A0 This would be something those fighting IPV6 = would use against me.=A0 =A0 I am out numbered enough as it is.=A0 :)=0A>= =0A>=0A>=0A> -----Original Message-----=0A> From: Joe Touch [mailto:touch@i= si.edu]=0A> Sent: Tuesday, March 19, 2013 12:20 PM=0A> To: Ackermann, Micha= el=0A> Cc: Templin, Fred L; Nalini Elkins; Nick Hilliard; v6ops@ietf.org=0A= > Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00=0A>=0A>=0A>= =0A> On 3/19/2013 9:09 AM, Ackermann, Michael wrote:=0A>> Joe,=0A>>=0A>> I = am certainly sensitive to not wanting to put extra bits on the=0A>> Interne= t (or my own network for that matter). I think this is=0A>> something we al= l seek to optimize however/whenever we can. However, I=0A>> know these part= icular bits have saved many, many hours of downtime for=0A>> us and that is= worth many millions of dollars as we sought to=0A>> demonstrate at the mee= ting last week. So while I believe optimizing=0A>> the number of bits sent = is very important, it is not always the only=0A>> consideration. As a techi= e, I may even lean in that direction.=0A>> However, working for a enterpris= e and knowing where my paycheck comes=0A>> from, I begrudgingly have to bel= ieve that the bits are worth the hours and the $ Million$ we have seen save= d.=0A>> As frequently is the case in my world, business value wins out over= =0A>> technical optimization.=0A>=0A> Well, this is why I said that the Int= ernet isn't here to support your business model. Many others will gladly sh= ave a few bits off every packet because they pay for capacity and complexit= y. Asking everyone to enable features used for diagnostics would be like as= king everyone to walk around with a thermometer in their mouth, just in cas= e a medical doctor needs to know.=0A>=0A>> Regards to the injecting of trac= e traffic.=A0 I could maybe do this in a test environment, but NEVER in pr= oduction!=0A>>=0A>> I am afraid I do not know what you mean be "tracing the= entire packet"?=0A>=0A> You're looking for an ID. Consider the whole packe= t an ID, and look for duplicates.=0A>=0A> If you see duplicates on one side= of a device and not the other, that device is duplicating them.=0A>=0A> Th= is is more complicated, but there are known ways to do this at very high sp= eed with reasonable amounts of storage.=0A>=0A> Joe=0A>=0A>=0A> The informa= tion contained in this communication is highly confidential and is intended= solely for the use of the individual(s) to whom this communication is dire= cted. If you are not the intended recipient, you are hereby notified that a= ny viewing, copying, disclosure or distribution of this information is proh= ibited. Please notify the sender, by electronic mail or telephone, of any u= nintended receipt and delete the original message without making any copies= .=0A>=0A>=A0 Blue Cross Blue Shield of Michigan and Blue Care Network of M= ichigan are nonprofit corporations and independent licensees of the Blue Cr= oss and Blue Shield Association.=0A> ---1551098171-1837633256-1363713043=:32504 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
What we want is a way to ma= ke the SHIM somehow optional.

Definitely, I can see people= other than us wanting to use it.   

I know kids at the = local university are programming apps for Android that are for the users of= Emergency Medical and Fire.   This is a critical app.  They migh= t want reliable access and performance diagnostics.

I can imagine th= at if cell phone companies started offering different classes of service to= the Internet (I know people will get all up in arms about this!).  Bu= t, if it is a way for them to charge more, they may want to do it.  An= y time you charge more, people will want to monitor if they are getting wha= t they paid for.   Hey, use our SHIM!

Having said all this, in my humble experience, the corporate world is not exactly powerless in g= etting what they want implemented.

 
=
Thanks,

Nalini Elkins
Inside Products, Inc.
(8= 31) 659-8360
www.insidethestack.com

From: Joe Touch <touch@isi.edu>
= To: "Ackermann, Michael" = <MAckermann@bcbsm.com>
Cc:<= /span> "Templin, Fred L" <Fred.L.Templin@boeing.com>; Nalini Elki= ns <nalini.elkins@insidethestack.com>; Nick Hilliard <nick@inex.ie&g= t;; "v6ops@ietf.org" <v6ops@ietf.org>
Sent: Tuesday, March 19, 2013 9:50 AM
Subject: Re: [v6ops] draft-elkins-v6= ops-ipv6-ipid-needed-00

=0AI think Fred and I have m= ade our position clear.

A few bits may be millions to you or even to= a few of your clients, but
it's hundreds of billions to everyone else.= That's not a business model
that the IETF should support.

Joe
On 3/19/2013 9:36 AM, Ackermann, Michael wrote:
> Joe,
><= br>> As I think others have said, I do not see this as a business model.=   But only as simple math.
>
> If I can add some number o= f bits to every (or many) packets,  there is a technical cost there, t= hat I fully understand.    However, if these bits save me even 1= 0 hours per year (and it is much more in my cases), this translates into hu= ndreds of millions of dollars or more to my company and others.  No m= atter what your cost per bit is, it will never come close to that.  N= ot to mention the direct or indirect costs to the application or business.&= nbsp;   So no matter what I might think as a pure technician or architect, guess what my boss or my CEO will= say.  Simple math is the only math that executives understand and fr= equently they do not understand math at all that is not prefixed with a $.<= br>>
> Regards to the whole packet technique.  My personal v= iew is that if I have to program or buy a product, to do what the protocol = inherently does today, that is a big step back and a deterrent to IPV6 depl= oyment.    I am one of the very few pro IPV6 people in my organiz= ation and those I work with.  This would be something those fighting = IPV6 would use against me.    I am out numbered enough as it is.&= nbsp; :)
>
>
>
> -----Original Message-----
>= ; From: Joe Touch [mailto:touch@isi.edu]
> Sent: Tuesday, March 19, 2013 1= 2:20 PM
> To: Ackermann, Michael
> Cc: Templin, Fred L; Nalini Elkins; Nick Hilliard; v6ops@ietf.org
> Subject: Re: [v6ops] dra= ft-elkins-v6ops-ipv6-ipid-needed-00
>
>
>
> On 3/19= /2013 9:09 AM, Ackermann, Michael wrote:
>> Joe,
>>
&g= t;> I am certainly sensitive to not wanting to put extra bits on the
= >> Internet (or my own network for that matter). I think this is
&= gt;> something we all seek to optimize however/whenever we can. However,= I
>> know these particular bits have saved many, many hours of do= wntime for
>> us and that is worth many millions of dollars as we = sought to
>> demonstrate at the meeting last week. So while I beli= eve optimizing
>> the number of bits sent is very important, it is= not always the only
>> consideration. As a techie, I may even lea= n in that direction.
>> However, working for a enterprise and knowing where my paycheck comes
>> from, I begrudgingly have to b= elieve that the bits are worth the hours and the $ Million$ we have seen sa= ved.
>> As frequently is the case in my world, business value wins= out over
>> technical optimization.
>
> Well, this is= why I said that the Internet isn't here to support your business model. Ma= ny others will gladly shave a few bits off every packet because they pay fo= r capacity and complexity. Asking everyone to enable features used for diag= nostics would be like asking everyone to walk around with a thermometer in = their mouth, just in case a medical doctor needs to know.
>
>&g= t; Regards to the injecting of trace traffic.  I could maybe do this = in a test environment, but NEVER in production!
>>
>> I a= m afraid I do not know what you mean be "tracing the entire packet"?
>= ;
> You're looking for an ID. Consider the whole packet an ID, and look for duplicates.
>
> If you see duplicates on one side= of a device and not the other, that device is duplicating them.
>> This is more complicated, but there are known ways to do this at very= high speed with reasonable amounts of storage.
>
> Joe
>=
>
> The information contained in this communication is highly = confidential and is intended solely for the use of the individual(s) to who= m this communication is directed. If you are not the intended recipient, yo= u are hereby notified that any viewing, copying, disclosure or distribution= of this information is prohibited. Please notify the sender, by electronic= mail or telephone, of any unintended receipt and delete the original messa= ge without making any copies.
>
>  Blue Cross Blue Shield= of Michigan and Blue Care Network of Michigan are nonprofit corporations a= nd independent licensees of the Blue Cross and Blue Shield Association.
>


---1551098171-1837633256-1363713043=:32504-- From nalini.elkins@insidethestack.com Tue Mar 19 10:16:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2913021F8FCD for ; Tue, 19 Mar 2013 10:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] 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 3WnArXg4xauf for ; Tue, 19 Mar 2013 10:16:49 -0700 (PDT) Received: from nm8.access.bullet.mail.mud.yahoo.com (nm8.access.bullet.mail.mud.yahoo.com [66.94.237.209]) by ietfa.amsl.com (Postfix) with ESMTP id C949521F8FD1 for ; Tue, 19 Mar 2013 10:16:48 -0700 (PDT) Received: from [66.94.237.195] by nm8.access.bullet.mail.mud.yahoo.com with NNFMP; 19 Mar 2013 17:16:48 -0000 Received: from [66.94.237.101] by tm6.access.bullet.mail.mud.yahoo.com with NNFMP; 19 Mar 2013 17:16:48 -0000 Received: from [127.0.0.1] by omp1006.access.mail.mud.yahoo.com with NNFMP; 19 Mar 2013 17:16:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 469900.89205.bm@omp1006.access.mail.mud.yahoo.com Received: (qmail 87484 invoked by uid 60001); 19 Mar 2013 17:16:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1363713408; bh=0Uex7QVTmqKNzac6EK2Xh4T1HAMtubwWyXHIUi10jyg=; 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; b=hIVTk6fFEPLtbDTRlCTkJE94tT4mQ3h8KvYoBnw9SqeWY92gmO0tw/h/LD4QHkUtUGKdTGA/iq4n+DCZ/XP1YBaddtCRkYt4L1tC56sCnqxr12Enq4jaL/5WnKptWoy3agWARefScqAxm9lEUD46W/09YPV093MD0t1UzIzgsfA= X-YMail-OSG: KNxPthEVM1k489Mb5qxE_vO30mfkHxNPC23Tot7MpsglMZ8 b9QmH8WXYg_B5xpLM1Rhr7jIEX0PyuRlxL3aMOg7zwBY.OkXa3_TNO7n8Mwp 2AvsWLqMRixIFRH6fJCSYQAGoI_xsM8slgfL5qOho_eI.LS6Hv17r4rpt2un qH0zR.6_qcqEjn.w66jG0j_5aiKS1NWpKbyP_7vtPeU50mNV7nKOoeL1syP3 bfa94FP0Xde4S1HYJkCXlL5Bd8KbvVo4Z.H5P8KplYEvmYnMpq1j_pLTQXBQ t7hJtYIcx2lLjrpqYRBBi.e7kWjoowQSxjiAkE.L9rYxAINRHRXVXTgyEanI Fn4tkxi6yWSVRbABp668gmsZAhTYNGqcuCUhEV4A9OBGwnAA6WfIUqVvbP76 yDFMpXNdjCkJbpRbUlNxtSFLRNEzcfnyBjGikpgwKShaAIpoRY42dwpW5cs5 Ggu2laNKSkGMcuwHpm.gGiN415arwEVIvh9Wv3LD.knw0a2TJXFP.HiJqLUm zi3n53T.snlsTbyxJ1t2ZZ0W8iJlLMdwwl8dmxd36OFOha7qlK7eHfmehSzP yqv5PnkCStE7x4v8FtXG7yMIHQ6_BLzfw2DcxasGCAYzvaNdKv2e38RYJl4l r.Wxf5W1RYp1m.HaCCwkbFGQIuQu1F1E1_bxQ Received: from [24.130.37.147] by web2804.biz.mail.ne1.yahoo.com via HTTP; Tue, 19 Mar 2013 10:16:47 PDT X-Rocket-MIMEInfo: 002.001, SSB3b3VsZCB3b25kZXIgd2hhdCB0aGUgZGVwdGggb2YgdGhlIElQdjYgaW1wbGVtZW50YXRpb24gaXMuIMKgQW5kLCB3aGF0ICJzaXRlcyIgd2VyZSB0YWxrZWQgdG8uCgpJLCBteXNlbGYsIGhhdmUgYmVlbiB3b3JrZWQgaW4gdGhlIGNvcnBvcmF0ZSB3b3JsZCBmb3Igb3ZlciAzMCB5ZWFycyBhbmQgdGFsayB0byBtdWx0aXBsZSBGb3J0dW5lIDEsMDAwIGNvbXBhbmllcyBkYWlseS4gwqBJIGNhbiB0ZWxsIHlvdSB0aGF0IGEgbnVtYmVyIGFyZSBsb29raW5nIGF0IHRoZWlyIHdlYiBzaXRlcyAmIGV4dGVybmEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.138.524 References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <5148917D.8030000@inex.ie> <4FC37E442D05A748896589E468752CAA0A64EE4E@PWN401EA160.ent.corp.bcbsm.com> <514897EF.3000900@isi.edu> Message-ID: <1363713407.61156.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> Date: Tue, 19 Mar 2013 10:16:47 -0700 (PDT) From: Nalini Elkins To: Joe Touch , "Ackermann, Michael" In-Reply-To: <514897EF.3000900@isi.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1051860855-982470818-1363713407=:61156" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:16:50 -0000 ---1051860855-982470818-1363713407=:61156 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I would wonder what the depth of the IPv6 implementation is. =A0And, what "= sites" were talked to.=0A=0AI, myself, have been worked in the corporate wo= rld for over 30 years and talk to multiple Fortune 1,000 companies daily. = =A0I can tell you that a number are looking at their web sites & external a= ccess (but NOT their internal network).=A0 =A0A few are looking at internal= implementation, and quite a few are saying "We have no plans to look at th= is". =A0=0A=0AThis whole discussion points out the reasons that corporation= s need to be involved in IETF - it will be good for both parties. =A0We are= working on this!=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Products, = Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A_________________= _______________=0A From: Joe Touch =0ATo: "Ackermann, Michae= l" =0ACc: "v6ops@ietf.org" =0ASent:= Tuesday, March 19, 2013 9:53 AM=0ASubject: Re: [v6ops] draft-elkins-v6ops-= ipv6-ipid-needed-00=0A =0AYour view of IPv6 deployment seems a bit dated.= =0A=0AIt might be useful to take a look here:=0A=0Ahttp://eggert.org/meter/= ipv6=0A=0AJoe=0A=0AOn 3/19/2013 9:41 AM, Ackermann, Michael wrote:=0A> ment= al divide I see (as a new comer to IETF),=A0 is that most of the IETF popul= ace has been running IPV6 for years.=A0 Most of corporate America is just = learning to spell it.=A0 And most are very resistant of it today.=0A>=0A> = This causes us to have VERY different perspectives on many IPV6 issues.=0A>= =0A> I can only hope we can attempt to see each others perspectives and bri= dge many of this gaps to jointly create overall effective solutions.=0A>=0A= > Perhaps I sound=0A_______________________________________________=0Av6ops= mailing list=0Av6ops@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/v6op= s ---1051860855-982470818-1363713407=:61156 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I would wonder what t= he depth of the IPv6 implementation is.  And, what "sites" were talked= to.

I, myself, have been worked in the = corporate world for over 30 years and talk to multiple Fortune 1,000 compan= ies daily.  I can tell you that a number are looking at their web site= s & external access (but NOT their internal network).   A few are looking at inter= nal implementation, and quite a few are saying "We have no plans to look at this".  

=
This whole discussion points out the reasons that corporations ne= ed to be involved in IETF - it will be good for both parties.  We are = working on this!
 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insid= ethestack.com

From:= Joe Touch <touch@isi.edu>
= To: "Ackermann, Michael" <MAckermann@bcbsm.com>
Cc: "v6ops@ietf.org" <v6ops@i= etf.org>
Sent: Tue= sday, March 19, 2013 9:53 AM
Subj= ect: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00

=0AYour view of IPv6 deployment seems a bit dated.

It= might be useful to take a look here:

http://eggert.org/meter/ipv6
Joe

On 3/19/2013 9:41 AM, Ackermann, Michael wrote:
> me= ntal divide I see (as a new comer to IETF),  is that most of the IETF = populace has been running IPV6 for years.  Most of corporate America = is just learning to spell it.  And most are very resistant of it toda= y.
>
> This causes us to have VERY different perspectives on ma= ny IPV6 issues.
>
> I can only hope we can attempt to see each = others perspectives and bridge many of this gaps to jointly create overall = effective solutions.
>
> Perhaps I sound
___________________= ____________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

<= br>
---1051860855-982470818-1363713407=:61156-- From gert@space.net Tue Mar 19 10:19:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8FC21F8481 for ; Tue, 19 Mar 2013 10:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 rxe1E7v4phAV for ; Tue, 19 Mar 2013 10:19:13 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 9597121F84CA for ; Tue, 19 Mar 2013 10:19:02 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id E4A57607DD for ; Tue, 19 Mar 2013 18:19:01 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id B5354607A1 for ; Tue, 19 Mar 2013 18:19:01 +0100 (CET) Received: (qmail 32836 invoked by uid 1007); 19 Mar 2013 18:19:01 +0100 Date: Tue, 19 Mar 2013 18:19:01 +0100 From: Gert Doering To: Nalini Elkins Message-ID: <20130319171901.GN51699@Space.Net> References: <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <5148917D.8030000@inex.ie> <4FC37E442D05A748896589E468752CAA0A64EE4E@PWN401EA160.ent.corp.bcbsm.com> <514897EF.3000900@isi.edu> <1363713407.61156.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1363713407.61156.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:19:13 -0000 Hi, On Tue, Mar 19, 2013 at 10:16:47AM -0700, Nalini Elkins wrote: > I would wonder what the depth of the IPv6 implementation is.  And, what "sites" were talked to. "Google and Facebook". Anything else of relevance? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From touch@isi.edu Tue Mar 19 10:24:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E053A21F877B for ; Tue, 19 Mar 2013 10:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.634 X-Spam-Level: X-Spam-Status: No, score=-102.634 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 nBBos3V7tdXK for ; Tue, 19 Mar 2013 10:24:18 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 59D0321F85D2 for ; Tue, 19 Mar 2013 10:24:18 -0700 (PDT) Received: from [192.168.1.96] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r2JHNaPN020999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Mar 2013 10:23:46 -0700 (PDT) Message-ID: <51489F18.5000804@isi.edu> Date: Tue, 19 Mar 2013 10:23:36 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Nalini Elkins References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <5148917D.8030000@inex.ie> <4FC37E442D05A748896589E468752CAA0A64EE4E@PWN401EA160.ent.corp.bcbsm.com> <514897EF.3000900@isi.edu> <1363713407.61156.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> In-Reply-To: <1363713407.61156.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:24:19 -0000 On 3/19/2013 10:16 AM, Nalini Elkins wrote: > I would wonder what the depth of the IPv6 implementation is. And, what > "sites" were talked to. The website I gave should have info on the sites; the idea of the website was to check something a lot like "Fortune 500" companies, at least for the US ones. > I, myself, have been worked in the corporate world for over 30 years and > talk to multiple Fortune 1,000 companies daily. I can tell you that a > number are looking at their web sites & external access (but NOT their > internal network). A few are looking at internal implementation, and > quite a few are saying "We have no plans to look at this". Sure, but why bother making this available publicly if nobody uses it? Also, internal IPv6 deployment is known to be very widescale - notably in cellphone networks. Joe > > This whole discussion points out the reasons that corporations need to > be involved in IETF - it will be good for both parties. We are working > on this! > Thanks, > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > ------------------------------------------------------------------------ > *From:* Joe Touch > *To:* "Ackermann, Michael" > *Cc:* "v6ops@ietf.org" > *Sent:* Tuesday, March 19, 2013 9:53 AM > *Subject:* Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 > > Your view of IPv6 deployment seems a bit dated. > > It might be useful to take a look here: > > http://eggert.org/meter/ipv6 > > Joe > > On 3/19/2013 9:41 AM, Ackermann, Michael wrote: > > mental divide I see (as a new comer to IETF), is that most of the > IETF populace has been running IPV6 for years. Most of corporate > America is just learning to spell it. And most are very resistant of it > today. > > > > This causes us to have VERY different perspectives on many IPV6 issues. > > > > I can only hope we can attempt to see each others perspectives and > bridge many of this gaps to jointly create overall effective solutions. > > > > Perhaps I sound > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From Fred.L.Templin@boeing.com Tue Mar 19 10:26:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225EE21F8DE9 for ; Tue, 19 Mar 2013 10:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, 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 MPuPG4PpM3FY for ; Tue, 19 Mar 2013 10:26:53 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 83CDA21F8D68 for ; Tue, 19 Mar 2013 10:26:53 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r2JHQrsZ019888 for ; Tue, 19 Mar 2013 10:26:53 -0700 Received: from XCH-PHX-311.sw.nos.boeing.com (xch-phx-311.sw.nos.boeing.com [130.247.25.171]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r2JHQqG7019883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 19 Mar 2013 10:26:52 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.214]) by XCH-PHX-311.sw.nos.boeing.com ([169.254.11.13]) with mapi id 14.02.0328.011; Tue, 19 Mar 2013 10:26:52 -0700 From: "Templin, Fred L" To: Nalini Elkins Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Thread-Index: AQHOJMXZpovTMHVwr0KJKw2dWHfftZitQnkg Date: Tue, 19 Mar 2013 17:26:51 +0000 Message-ID: <2134F8430051B64F815C691A62D9831803313C@XCH-BLV-504.nw.nos.boeing.com> References: <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <5148917D.8030000@inex.ie> <4FC37E442D05A748896589E468752CAA0A64EE4E@PWN401EA160.ent.corp.bcbsm.com> <514897EF.3000900@isi.edu> <1363713407.61156.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <20130319171901.GN51699@Space.Net> In-Reply-To: <20130319171901.GN51699@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:26:54 -0000 Here's another thought - just to have it out on the table. Both SCTP and DCCP have sequence numbers, so that is something that might be worth considering. But, the network is still very much entrenched in TCP and UDP as the only "legitimate" protocols so I think it would take a monumental push to get them promoted to be on equal footing with TCP and UDP. Just the same, you might want to see if there is a community of interest behind SCTP/DCCP and join forces with them. Thanks - Fred From mackermann@bcbsm.com Tue Mar 19 10:31:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214DA21F8DD6 for ; Tue, 19 Mar 2013 10:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.38 X-Spam-Level: X-Spam-Status: No, score=-6.38 tagged_above=-999 required=5 tests=[AWL=0.219, 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 q-BIBK4fIO9T for ; Tue, 19 Mar 2013 10:31:40 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.zixworks.com [63.71.11.123]) by ietfa.amsl.com (Postfix) with ESMTP id 6475921F8DB2 for ; Tue, 19 Mar 2013 10:31:39 -0700 (PDT) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 4549E17E515 for ; Tue, 19 Mar 2013 12:31:39 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id C256E17E483; Tue, 19 Mar 2013 12:31:37 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 4515C4F804F; Tue, 19 Mar 2013 13:30:22 -0400 (EDT) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) by imsva1.bcbsm.com (Postfix) with ESMTP id 331FB4F804D; Tue, 19 Mar 2013 13:30:22 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([fe80::716f:e3f0:b97f:8900%14]) with mapi id 14.01.0355.002; Tue, 19 Mar 2013 13:31:37 -0400 From: "Ackermann, Michael" To: Joe Touch Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Thread-Index: AQHOIMaVqC5M9XVYp0uFMLNLdFX3pZil/fsAgAW9XMeAAHp1AP//xeIwgABMrQCAAAwVAIAAA8SAgAAgdgCAAOykAP//wa/wgABXRYD//8ApAAAI8N2AAAc3QhA= Date: Tue, 19 Mar 2013 17:31:36 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A64EF2A@PWN401EA160.ent.corp.bcbsm.com> References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <5148917D.8030000@inex.ie> <4FC37E442D05A748896589E468752CAA0A64EE4E@PWN401EA160.ent.corp.bcbsm.com> <514897EF.3000900@isi.edu> In-Reply-To: <514897EF.3000900@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:31:41 -0000 SW50ZXJlc3RpbmcuICANCg0KU29tZXRoaW5nIEkgY2FuIHVzZSB0byB0cnkgcHJvbW90ZSBJ UFY2LiAgICBUaGUgOSUgbG9va3MgaW1wcmVzc2l2ZS4gICBFdmVuIHRob3VnaCB0aGUgRE5T IHN0YXRzIHB1Ymxpc2hlZCB3aWxsIHJlZmxlY3QgcHJvYmFibHkgMCUgb2Ygd2hhdCB3ZSBh Y2Nlc3MsIG5vIG9uZSB3aWxsIHJlYWxpemUgdGhhdC4gIA0KDQpUaGFua3MhICAgDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2UgVG91Y2ggW21haWx0bzp0b3Vj aEBpc2kuZWR1XSANClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDE5LCAyMDEzIDEyOjUzIFBNDQpU bzogQWNrZXJtYW5uLCBNaWNoYWVsDQpDYzogTmljayBIaWxsaWFyZDsgdjZvcHNAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWVsa2lucy12Nm9wcy1pcHY2LWlwaWQt bmVlZGVkLTAwDQoNCllvdXIgdmlldyBvZiBJUHY2IGRlcGxveW1lbnQgc2VlbXMgYSBiaXQg ZGF0ZWQuDQoNCkl0IG1pZ2h0IGJlIHVzZWZ1bCB0byB0YWtlIGEgbG9vayBoZXJlOg0KDQpo dHRwOi8vZWdnZXJ0Lm9yZy9tZXRlci9pcHY2DQoNCkpvZQ0KDQpPbiAzLzE5LzIwMTMgOTo0 MSBBTSwgQWNrZXJtYW5uLCBNaWNoYWVsIHdyb3RlOg0KPiBtZW50YWwgZGl2aWRlIEkgc2Vl IChhcyBhIG5ldyBjb21lciB0byBJRVRGKSwgIGlzIHRoYXQgbW9zdCBvZiB0aGUgSUVURiBw b3B1bGFjZSBoYXMgYmVlbiBydW5uaW5nIElQVjYgZm9yIHllYXJzLiAgIE1vc3Qgb2YgY29y cG9yYXRlIEFtZXJpY2EgaXMganVzdCBsZWFybmluZyB0byBzcGVsbCBpdC4gICBBbmQgbW9z dCBhcmUgdmVyeSByZXNpc3RhbnQgb2YgaXQgdG9kYXkuDQo+DQo+IFRoaXMgY2F1c2VzIHVz IHRvIGhhdmUgVkVSWSBkaWZmZXJlbnQgcGVyc3BlY3RpdmVzIG9uIG1hbnkgSVBWNiBpc3N1 ZXMuDQo+DQo+IEkgY2FuIG9ubHkgaG9wZSB3ZSBjYW4gYXR0ZW1wdCB0byBzZWUgZWFjaCBv dGhlcnMgcGVyc3BlY3RpdmVzIGFuZCBicmlkZ2UgbWFueSBvZiB0aGlzIGdhcHMgdG8gam9p bnRseSBjcmVhdGUgb3ZlcmFsbCBlZmZlY3RpdmUgc29sdXRpb25zLg0KPg0KPiBQZXJoYXBz IEkgc291bmQNCgoKVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGNvbW11bmlj YXRpb24gaXMgaGlnaGx5IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZv ciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIHRvIHdob20gdGhpcyBjb21tdW5pY2F0 aW9uIGlzIGRpcmVjdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB2aWV3aW5nLCBjb3B5aW5nLCBk aXNjbG9zdXJlIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHByb2hp Yml0ZWQuIFBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciwgYnkgZWxlY3Ryb25pYyBtYWlsIG9y IHRlbGVwaG9uZSwgb2YgYW55IHVuaW50ZW5kZWQgcmVjZWlwdCBhbmQgZGVsZXRlIHRoZSBv cmlnaW5hbCBtZXNzYWdlIHdpdGhvdXQgbWFraW5nIGFueSBjb3BpZXMuCiAKIEJsdWUgQ3Jv c3MgQmx1ZSBTaGllbGQgb2YgTWljaGlnYW4gYW5kIEJsdWUgQ2FyZSBOZXR3b3JrIG9mIE1p Y2hpZ2FuIGFyZSBub25wcm9maXQgY29ycG9yYXRpb25zIGFuZCBpbmRlcGVuZGVudCBsaWNl bnNlZXMgb2YgdGhlIEJsdWUgQ3Jvc3MgYW5kIEJsdWUgU2hpZWxkIEFzc29jaWF0aW9uLgo= From nalini.elkins@insidethestack.com Tue Mar 19 10:35:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031F721F8BE7 for ; Tue, 19 Mar 2013 10:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.324 X-Spam-Level: X-Spam-Status: No, score=-1.324 tagged_above=-999 required=5 tests=[AWL=-0.854, BAYES_00=-2.599, FB_YOUR_MORTGAGE=2.128, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxPYz3ctvgG3 for ; Tue, 19 Mar 2013 10:35:51 -0700 (PDT) Received: from nm24-vm0.access.bullet.mail.sp2.yahoo.com (nm24-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4673F21F8B96 for ; Tue, 19 Mar 2013 10:35:51 -0700 (PDT) Received: from [98.139.44.98] by nm24.access.bullet.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 17:35:51 -0000 Received: from [98.139.44.83] by tm3.access.bullet.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 17:35:51 -0000 Received: from [127.0.0.1] by omp1020.access.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 17:35:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 168140.66668.bm@omp1020.access.mail.sp2.yahoo.com Received: (qmail 45413 invoked by uid 60001); 19 Mar 2013 17:35:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1363714550; bh=joiniwp6Z8RViC8Rn6FvjjzCzvJsPA8uQOqeP5XhMSE=; 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; b=q2wzsxWvRVUXrW17nYGHqIfwZu3KLgUxr1HB0FZt6xV05fKRBXJXgB+LDn1tNRwv+gkjU19cdrt5BNqBe4uoU3DO6dMo052kkjUPFvjFavgfy5CzZe1YSU5Plvmh2lqjxuFpBUhUj9beOezApr+C+Zy9EdrR9OjOdRwf/M6PSso= X-YMail-OSG: Kr_n49cVM1mGhvlmE8m30LdvoGiXIOwtogLGfbDanw2ooG. D6mgDLmOUBu1Z29Tt2cegBzTrDZC3smmU1iEy_TIpmmZx6qjdZpsHRHSQCKL Zgl7xCX68rImVWRBn7CNWVvvx5AYlk20CDpTBmsdp2ZrmyA50g6y7qFdZrzJ dC4oOGcy_wGY2daiM5.a3GZsM2.9HpGwilTq0JGTYvu.psLBMV1qAe6IkYyj gqSVc7hPFpjsr9xwvchBVCpFu_iFZATRqtl459Fpl08BeD8vROpZDtv0G_3t my_DVxTspMDXDX_zCqAMTo0iy3hkItSc6CCqmhhAilI_tDq94T5VDWv2b4Q3 JlCG.bdegPqoGVbbu8luIMxYmwvIUqY2SmC2BKYQZo_TA2OmmxlI5HJWYQma rQCXJ.y9slp85ohs_Bekl1YXbGl1Zwnz49xAK66zKOKU5AUmVWFpn8arC3L3 58oaju1qPUUxDB8_1p0T.pDEliHGnppo770iPPEOFPsRTHeIK_4aG2H6e3tc 7nM8BFcaWWmKjQqEOTrddq1zrIiEqKRgY9f6t_snLemUXI0c853OAOVkRyCi cdhqOgUIrQvulTlRgzmsV5GkHBtT7uRVl10Tqa7TKKuY- Received: from [24.130.37.147] by web2802.biz.mail.ne1.yahoo.com via HTTP; Tue, 19 Mar 2013 10:35:50 PDT X-Rocket-MIMEInfo: 002.001, SW4gbXkgb3BpbmlvbiwgR29vZ2xlIGFuZCBGYWNlYm9vayBkbyBub3QgZXhhY3RseSByZXByZXNlbnQgY29ycG9yYXRlIEFtZXJpY2EuIMKgQ29ycG9yYXRlIEFtZXJpY2EgZG9lcyByZWFsbHkgYm9yaW5nIHRoaW5ncyBsaWtlIG1ha2luZyBzdXJlIHlvdXIgbW9ydGdhZ2UgZ2V0cyBwYWlkIGFuZCB0aGF0IHlvdSBoYXZlIGhlYWx0aCBpbnN1cmFuY2UuIMKgSXQgZG9lc24ndCBtYXR0ZXIgaWYgeW91ciBHb29nbGUgc2VhcmNoIGhhcyB0byBiZSBlbnRlcmVkIHR3aWNlLiDCoEF0IGxlYXN0IHRvIG1lLCBpdCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.138.524 References: <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <5148917D.8030000@inex.ie> <4FC37E442D05A748896589E468752CAA0A64EE4E@PWN401EA160.ent.corp.bcbsm.com> <514897EF.3000900@isi.edu> <1363713407.61156.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <20130319171901.GN51699@Space.Net> Message-ID: <1363714550.45210.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> Date: Tue, 19 Mar 2013 10:35:50 -0700 (PDT) From: Nalini Elkins To: Gert Doering In-Reply-To: <20130319171901.GN51699@Space.Net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-153701192-1089320263-1363714550=:45210" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:35:53 -0000 ---153701192-1089320263-1363714550=:45210 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable In my opinion, Google and Facebook do not exactly represent corporate Ameri= ca. =A0Corporate America does really boring things like making sure your mo= rtgage gets paid and that you have health insurance. =A0It doesn't matter i= f your Google search has to be entered twice. =A0At least to me, it matters= if my mortgage payment is taken out twice.=0A=0AHaving said that, in quite= a few ways, Google and Facebook have been smarter than us in recognizing w= here the party has been going on. =A0=A0=0A=0ABelieve me, we are working on= getting more of us informed and to the party. =A0=A0Whatever happens, I wa= nt to make sure that starting now, we know what is going on and that we hav= e a voice.=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Products, Inc.=0A= (831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A________________________= ________=0A From: Gert Doering =0ATo: Nalini Elkins =0ACc: Joe Touch ; "Ackermann, M= ichael" ; "v6ops@ietf.org" =0ASent: = Tuesday, March 19, 2013 10:19 AM=0ASubject: Re: [v6ops] draft-elkins-v6ops-= ipv6-ipid-needed-00=0A =0AHi,=0A=0AOn Tue, Mar 19, 2013 at 10:16:47AM -0700= , Nalini Elkins wrote:=0A> I would wonder what the depth of the IPv6 implem= entation is. =A0And, what "sites" were talked to.=0A=0A"Google and Facebook= ".=0A=0AAnything else of relevance?=0A=0AGert Doering=0A=A0 =A0 =A0 =A0 -- = NetMaster=0A-- =0Ahave you enabled IPv6 on something today...?=0A=0ASpaceNe= t AG=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Vorstand: Sebastian v. = Bomhard=0AJoseph-Dollinger-Bogen 14=A0 =A0 =A0 =A0 =A0 Aufsichtsratsvors.: = A. Grundner-Culemann=0AD-80807 Muenchen=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = HRB: 136055 (AG Muenchen)=0ATel: +49 (89) 32356-444=A0 =A0 =A0 =A0 =A0 =A0= USt-IdNr.: DE813185279 ---153701192-1089320263-1363714550=:45210 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
In my opinion, Google and F= acebook do not exactly represent corporate America.  Corporate America= does really boring things like making sure your mortgage gets paid and tha= t you have health insurance.  It doesn't matter if your Google search = has to be entered twice.  At least to me, it matters if my mortgage pa= yment is taken out twice.

Having said that, in quite a few ways, Google and Facebook= have been smarter than us in recognizing where the party has been going on= .   

Believe me, we are working on getting more of = us informed and to the party.   Whatever happens, I want to make sure that starting now, we k= now what is going on and that we have a voice.
=  
Thanks,

Nalini Elkins
Inside Products= , Inc.
(831) 659-8360
www.insidethestack.com

From: Gert Doering <gert@spac= e.net>
To: Nalini E= lkins <nalini.elkins@insidethestack.com>
Cc: Joe Touch <touch@isi.edu>; "Ackermann, Michae= l" <MAckermann@bcbsm.com>; "v6ops@ietf.org" <v6ops@ietf.org> Sent: Tuesday, March 19= , 2013 10:19 AM
Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
=0AHi,

On Tue, Mar 19, 2013 at 10:16:47AM -0700, Nalini Elkins wro= te:
> I would wonder what the depth of the IPv6 implementation is. &n= bsp;And, what "sites" were talked to.

"Google and Facebook".

= Anything else of relevance?

Gert Doering
      &nb= sp; -- NetMaster
--
have you enabled IPv6 on something today...?
=
SpaceNet AG                &nbs= p;       Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-= Bogen 14          Aufsichtsratsvors.: A. Grundner-= Culemann
D-80807 Muenchen             = ;     HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 =           USt-IdNr.: DE813185279


---153701192-1089320263-1363714550=:45210-- From nick@inex.ie Tue Mar 19 10:41:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D46B21F8CD9 for ; Tue, 19 Mar 2013 10:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uhTBaWA2lzv for ; Tue, 19 Mar 2013 10:41:50 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8874B21F8E12 for ; Tue, 19 Mar 2013 10:41:48 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.4/8.14.5) with ESMTP id r2JHcZsI066859 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 19 Mar 2013 17:38:36 GMT (envelope-from nick@inex.ie) Message-ID: <5148A358.50406@inex.ie> Date: Tue, 19 Mar 2013 17:41:44 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Ackermann, Michael" References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <5148917D.8030000@inex.ie> <4FC37E442D05A748896589E468752CAA0A64EE4E@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0A64EE4E@PWN401EA160.ent.corp.bcbsm.com> X-Enigmail-Version: 1.5.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:41:51 -0000 On 19/03/2013 16:41, Ackermann, Michael wrote: > The HUGE fundamental divide I see (as a new comer to IETF), is that > most of the IETF populace has been running IPV6 for years. If only they did, we wouldn't have half the amount of b/s we have with ipv6 today (e.g. the grand dhcpv6 vs SLAAC debacle, sigh) :-( > Most of > corporate America is just learning to spell it. And most are very > resistant of it today. yep. > This causes us to have VERY different perspectives on many IPV6 issues. > > I can only hope we can attempt to see each others perspectives and > bridge many of this gaps to jointly create overall effective solutions. The issue is very simple: you're proposing something which will sit near the bottom of the ipv6 protocol stack. We can only move forward with a proposal change if it's backwards compatible and it doesn't break stuff. If you propose a shim, that will probably break backwards compatibility with existing ipv6 installations. Extension headers are incompatible with shifting packets at the speeds we need to shift them at - i.e. they break ipv6 from a practical point of view. So any proposal you make which involves creating new extension headers will also be shot down. Unfortunately, this leaves your proposal as unworkable in its current incarnation. If you can find a way of getting a shim layer to work, then go for it, but I suspect this is also a dead end. The encapsulation suggestion may actually work - many problems can be solved by adding another layer of indirection. Would also suggest you check out rfc1925, particularly section 2.1 and 2.6a. Wise words there. Nick From mackermann@bcbsm.com Tue Mar 19 10:46:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3805821F8D1E for ; Tue, 19 Mar 2013 10:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.337 X-Spam-Level: X-Spam-Status: No, score=-5.337 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_00=-2.599, FB_YOUR_MORTGAGE=2.128, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDJzUvqELzyH for ; Tue, 19 Mar 2013 10:46:28 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.zixworks.com [63.71.11.123]) by ietfa.amsl.com (Postfix) with ESMTP id 59A8921F8CD9 for ; Tue, 19 Mar 2013 10:46:26 -0700 (PDT) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id CDACE17E405 for ; Tue, 19 Mar 2013 12:46:25 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 8BEC417E404; Tue, 19 Mar 2013 12:46:24 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id EFFB04F804D; Tue, 19 Mar 2013 13:45:08 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva1.bcbsm.com (Postfix) with ESMTP id E03374F8049; Tue, 19 Mar 2013 13:45:08 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA100.ent.corp.bcbsm.com ([fe80::8db:9ce7:e2cf:8565%14]) with mapi id 14.01.0355.002; Tue, 19 Mar 2013 13:46:23 -0400 From: "Ackermann, Michael" To: Nalini Elkins , Gert Doering Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Thread-Index: AQHOIMaVqC5M9XVYp0uFMLNLdFX3pZil/fsAgAW9XMeAAHp1AP//xeIwgABMrQCAAAwVAIAAA8SAgAAgdgCAAOykAP//wa/wgABXRYD//8ApAAAI8N2AAADUMYAAABP4gAAAlloAAAgH3ZA= Date: Tue, 19 Mar 2013 17:46:23 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A64EFC9@PWN401EA160.ent.corp.bcbsm.com> References: <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <5148917D.8030000@inex.ie> <4FC37E442D05A748896589E468752CAA0A64EE4E@PWN401EA160.ent.corp.bcbsm.com> <514897EF.3000900@isi.edu> <1363713407.61156.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <20130319171901.GN51699@Space.Net> <1363714550.45210.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> In-Reply-To: <1363714550.45210.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: multipart/alternative; boundary="_000_4FC37E442D05A748896589E468752CAA0A64EFC9PWN401EA160entc_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:46:29 -0000 --_000_4FC37E442D05A748896589E468752CAA0A64EFC9PWN401EA160entc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Most enterprises block facebook. From: Nalini Elkins =5Bmailto:nalini.elkins=40insidethestack.com=5D Sent: Tuesday, March 19, 2013 1:36 PM To: Gert Doering Cc: Joe Touch; Ackermann, Michael; v6ops=40ietf.org Subject: Re: =5Bv6ops=5D draft-elkins-v6ops-ipv6-ipid-needed-00 In my opinion, Google and Facebook do not exactly represent corporate = America. Corporate America does really boring things like making sure = your mortgage gets paid and that you have health insurance. It doesn't = matter if your Google search has to be entered twice. At least to me, it = matters if my mortgage payment is taken out twice. Having said that, in quite a few ways, Google and Facebook have been = smarter than us in recognizing where the party has been going on. Believe me, we are working on getting more of us informed and to the = party. Whatever happens, I want to make sure that starting now, we know = what is going on and that we have a voice. Thanks, Nalini Elkins Inside Products, Inc. (831) 659-8360 www.insidethestack.com ________________________________ From: Gert Doering > To: Nalini Elkins = > Cc: Joe Touch >; =22Ackermann, = Michael=22 >; = =22v6ops=40ietf.org=22 = > Sent: Tuesday, March 19, 2013 10:19 AM Subject: Re: =5Bv6ops=5D draft-elkins-v6ops-ipv6-ipid-needed-00 Hi, On Tue, Mar 19, 2013 at 10:16:47AM -0700, Nalini Elkins wrote: > I would wonder what the depth of the IPv6 implementation is. And, what = =22sites=22 were talked to. =22Google and Facebook=22. Anything else of relevance? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_4FC37E442D05A748896589E468752CAA0A64EFC9PWN401EA160entc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <=21--=5Bif =21mso=5D><=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

Most enterprises block facebook. 

 

 

From: Nalini Elkins =5Bmailto:nalini.elkins=40insidethestack.com=5D
Sent: Tuesday, March 19, 2013 1:36 PM
To: Gert Doering
Cc: Joe Touch; Ackermann, Michael; v6ops=40ietf.org
Subject: Re: =5Bv6ops=5D = draft-elkins-v6ops-ipv6-ipid-needed-00

 

In my opinion, Google and Facebook do not exactly = represent corporate America.  Corporate America does really boring = things like making sure your mortgage gets paid and that you have health insurance.  It = doesn't matter if your Google search has to be entered twice.  At = least to me, it matters if my mortgage payment is taken out = twice.

 

Having said that, in quite a few ways, Google and = Facebook have been smarter than us in recognizing where the party has been = going on.   

 

Believe me, we are working on getting more of us = informed and to the party.   Whatever happens, I want to make = sure that starting now, we know what is going on and that we have a voice.

 

Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com<= /o:p>

From: Gert Doering <gert=40space.net>
To: Nalini Elkins <nalini.elkins=40insi= dethestack.com>
Cc: Joe Touch <touch=40isi.edu>; = "Ackermann, Michael" <MAckermann=40bcbsm.com>; = "v6ops=40ietf.org" = <v6ops=40ietf.org>
Sent: Tuesday, March 19, 2013 10:19 AM
Subject: Re: =5Bv6ops=5D = draft-elkins-v6ops-ipv6-ipid-needed-00


Hi,

On Tue, Mar 19, 2013 at 10:16:47AM -0700, Nalini Elkins wrote:
> I would wonder what the depth of the IPv6 implementation is. =  And, what "sites" were talked to.

"Google and Facebook".

Anything else of relevance?

Gert Doering
        -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG                  =       Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          = Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                =   HRB: 136055 (AG Muenchen)
Tel: &=2343;49 (89) 32356-444            = USt-IdNr.: DE813185279


The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association.

--_000_4FC37E442D05A748896589E468752CAA0A64EFC9PWN401EA160entc_-- From joelja@bogus.com Tue Mar 19 10:54:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9A221F86BB for ; Tue, 19 Mar 2013 10:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.085 X-Spam-Level: X-Spam-Status: No, score=-101.085 tagged_above=-999 required=5 tests=[AWL=-1.214, BAYES_00=-2.599, FB_YOUR_MORTGAGE=2.128, J_CHICKENPOX_13=0.6, 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 QvEQpUBolfg0 for ; Tue, 19 Mar 2013 10:54:42 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC1A21F86A6 for ; Tue, 19 Mar 2013 10:54:42 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r2JHseXl052397 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 19 Mar 2013 17:54:41 GMT (envelope-from joelja@bogus.com) Message-ID: <5148A65B.10208@bogus.com> Date: Tue, 19 Mar 2013 10:54:35 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: "Ackermann, Michael" , Nalini Elkins , Gert Doering References: <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <5148917D.8030000@inex.ie> <4FC37E442D05A748896589E468752CAA0A64EE4E@PWN401EA160.ent.corp.bcbsm.com> <514897EF.3000900@isi.edu> <1363713407.61156.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <20130319171901.GN51699@Space.Net> <1363714550.45210.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <4FC37E442D05A748896589E468752CAA0A64EFC9@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0A64EFC9@PWN401EA160.ent.corp.bcbsm.com> 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]); Tue, 19 Mar 2013 17:54:41 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:54:43 -0000 I don't think this is a productive or useful direction for this discussion to go. I would appreciate it if the participants would adhere to the problem domain, rather than perhaps engendering a descent into list anarchy. Thanks your AD Joel On 3/19/13 10:46 AM, Ackermann, Michael wrote: > > Most enterprises block facebook. > > *From:*Nalini Elkins [mailto:nalini.elkins@insidethestack.com] > *Sent:* Tuesday, March 19, 2013 1:36 PM > *To:* Gert Doering > *Cc:* Joe Touch; Ackermann, Michael; v6ops@ietf.org > *Subject:* Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 > > In my opinion, Google and Facebook do not exactly represent corporate > America. Corporate America does really boring things like making sure > your mortgage gets paid and that you have health insurance. It > doesn't matter if your Google search has to be entered twice. At > least to me, it matters if my mortgage payment is taken out twice. > > Having said that, in quite a few ways, Google and Facebook have been > smarter than us in recognizing where the party has been going on. > > Believe me, we are working on getting more of us informed and to the > party. Whatever happens, I want to make sure that starting now, we > know what is going on and that we have a voice. > > Thanks, > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > ------------------------------------------------------------------------ > > *From:*Gert Doering > > *To:* Nalini Elkins > > *Cc:* Joe Touch >; "Ackermann, > Michael" >; > "v6ops@ietf.org " > > *Sent:* Tuesday, March 19, 2013 10:19 AM > *Subject:* Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 > > > Hi, > > On Tue, Mar 19, 2013 at 10:16:47AM -0700, Nalini Elkins wrote: > > I would wonder what the depth of the IPv6 implementation is. And, > what "sites" were talked to. > > "Google and Facebook". > > Anything else of relevance? > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > > > The information contained in this communication is highly confidential > and is intended solely for the use of the individual(s) to whom this > communication is directed. If you are not the intended recipient, you > are hereby notified that any viewing, copying, disclosure or > distribution of this information is prohibited. Please notify the > sender, by electronic mail or telephone, of any unintended receipt and > delete the original message without making any copies. > > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan > are nonprofit corporations and independent licensees of the Blue Cross > and Blue Shield Association. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From bill.jouris@insidethestack.com Tue Mar 19 11:16:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D5021F8D8C for ; Tue, 19 Mar 2013 11:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] 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 crCZKb3AFfBJ for ; Tue, 19 Mar 2013 11:16:38 -0700 (PDT) Received: from nm4-vm0.access.bullet.mail.sp2.yahoo.com (nm4-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.110]) by ietfa.amsl.com (Postfix) with ESMTP id 9A04321F8D67 for ; Tue, 19 Mar 2013 11:16:38 -0700 (PDT) Received: from [98.139.44.96] by nm4.access.bullet.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 18:16:35 -0000 Received: from [98.139.44.81] by tm1.access.bullet.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 18:16:35 -0000 Received: from [127.0.0.1] by omp1018.access.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 18:16:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 925276.20976.bm@omp1018.access.mail.sp2.yahoo.com Received: (qmail 36732 invoked by uid 60001); 19 Mar 2013 18:16:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1363716995; bh=dQuRcXJsV22I15kxDKqdxeC0qlFASkco5QJnpqS+dNA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=VmM7gMYvK1XxFx5BXkwQntpH6XAAqkati4GTr+pJQiDiRkfycyb+wvyo2ZTRabp2g1O433VpKVPdNMwxjzdNfZT6z4oBXh/pJwNmBZGLlIePR/hGMyAsr8Oxa7QBthCsvnHKMVLXgaOZpkqjcYsmxSdZKfl6mPcFLAo+YjWDVfs= X-YMail-OSG: rv74skYVM1nEwTiHhge0eaUy8C.UnIWmb8AQHsekfZOPjyG FIyMZfzqyMn5irStvuOOXmh2coYI11AdTDCYy0m1qZQeJXw6muxxoSu2fcGq kKhAMX_GOjD3fdjKXmcT6KxyuCix36d1MnpiZlu832xpO2wl7_SDsATvhfLu PC7.kRJvGfiuVpitS._baZvDengIOH.NaQDh7DCAdHlD9SE0h7F9RoZmABah _7DF0hTVVcgKF.WJlxfIYvCNiA2K3TQB1NDpN1zIIurhARnF4oIt6yMEwrrV fgOuB2nsbl0YhNLKduhqra17nYuhizGZXSrMJ_BaNhmivdeq6AQhytQPusnf 6BdnDm5767730aCKwODtr8JaQPcV261xGD20XZ29vUSbMTO_AOvMucu77W07 _0W4tg4S3UBFlXA2qhECP8IV6SWNEQw4pM.iL_Q4ZXsdghUPnxJoTrngiFvO 4ry3WGFMvPEiY1OjOLs6F4kCmCq0XD3ezPTYoLmp4NU19zm9v5Z7UFwP_w1F znlXq9punIrS0tNdB3rS9uei7z4mGlsU_PJk.mjTTt7fw_tromua2PqOK_8E KgzLEM5mkIj2WkFyplba22kegIYGJDh_OdeVx Received: from [50.148.178.232] by web2804.biz.mail.ne1.yahoo.com via HTTP; Tue, 19 Mar 2013 11:16:34 PDT X-Rocket-MIMEInfo: 002.001, VGhlcmUgbWF5IGJlIHdheXMgdG8gZG8gdGhpcyB0aGF0IGFyZSB3ZWxsIGtub3cgVE8gWU9VLsKgIE9yIGdlbmVyYWxseSB0byB0aG9zZSB3aG8gYXJlIGFjdGl2ZSBpbiB0aGUgSUVURi4NCg0KQnV0IGl0IHdvdWxkIHNlZW0gdGhhdCB3ZSBtYXkgaGF2ZSBhbiBlZHVjYXRpb24vcHVibGljaXR5IGlzc3VlIGhlcmUsIHNpbmNlIHRoZXkgZG8gbm90IChhdCBsZWFzdCBpbiBteSBleHBlcmllbmNlKSBzZWVtIHRvIGJlIHBhcnRpY3VsYXJseSB3aWRlbHkga25vd24gdG8gdGhvc2UgcmVzcG9uc2libGUgZm9yIHMBMAEBAQE- X-Mailer: YahooMailClassic/15.1.5 YahooMailWebService/0.8.138.524 Message-ID: <1363716994.36617.YahooMailClassic@web2804.biz.mail.ne1.yahoo.com> Date: Tue, 19 Mar 2013 11:16:34 -0700 (PDT) From: Bill Jouris To: Joe Touch MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1051860855-296311464-1363716994=:36617" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 18:16:47 -0000 ---1051860855-296311464-1363716994=:36617 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable There may be ways to do this that are well know TO YOU.=A0 Or generally to = those who are active in the IETF. But it would seem that we may have an education/publicity issue here, since= they do not (at least in my experience) seem to be particularly widely kno= wn to those responsible for supporting networks in the corporate world.=20 Do you have some thoughts on how we might get the word out more generally?= =A0 Because it hasn't gotten there so far. Bill Jouris Inside Products, Inc. www.insidethestack.com 831-659-8360 925-855-9512 (direct) --- On Tue, 3/19/13, Joe Touch wrote: From: Joe Touch Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 To: "Ackermann, Michael" Cc: "v6ops@ietf.org" Date: Tuesday, March 19, 2013, 9:19 AM ... This is more complicated, but there are known ways to do this at very high = speed with reasonable amounts of storage. Joe _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ---1051860855-296311464-1363716994=:36617 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <= /tr>
There may be ways to do this that are well kn= ow TO YOU.  Or generally to those who are active in the IETF.

B= ut it would seem that we may have an education/publicity issue here, since = they do not (at least in my experience) seem to be particularly widely know= n to those responsible for supporting networks in the corporate world.
=
Do you have some thoughts on how we might get the word out more general= ly?  Because it hasn't gotten there so far.

Bi= ll Jouris
Inside Products, Inc.
www.insidethe= stack.com
831-659-8360
925-855-9512 (direct)

--- On = Tue, 3/19/13, Joe Touch <touch@isi.edu> wrote:

From: Joe Touch <touch@isi.edu>
Subject: Re: = [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
To: "Ackermann, Michael" <MAc= kermann@bcbsm.com>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Dat= e: Tuesday, March 19, 2013, 9:19 AM
...
This= is more complicated, but there are known ways to do this at very high spee= d with reasonable amounts of storage.

Joe
_______________________= ________________________
v6ops mailing list
v6ops@ietf.org
= h= ttps://www.ietf.org/mailman/listinfo/v6ops
---1051860855-296311464-1363716994=:36617-- From touch@isi.edu Tue Mar 19 11:22:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E8921F8DE3 for ; Tue, 19 Mar 2013 11:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.581 X-Spam-Level: X-Spam-Status: No, score=-104.581 tagged_above=-999 required=5 tests=[AWL=1.418, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaHPdglz0KR2 for ; Tue, 19 Mar 2013 11:22:45 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id C29A821F8DDB for ; Tue, 19 Mar 2013 11:22:45 -0700 (PDT) Received: from [192.168.1.96] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r2JILroF000330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Mar 2013 11:22:03 -0700 (PDT) Message-ID: <5148ACC1.3020208@isi.edu> Date: Tue, 19 Mar 2013 11:21:53 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Bill Jouris References: <1363716994.36617.YahooMailClassic@web2804.biz.mail.ne1.yahoo.com> In-Reply-To: <1363716994.36617.YahooMailClassic@web2804.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 18:22:46 -0000 There is a fine line between the IETF being a place where a group of people work together to solve problems, and free consulting/tutorial/courses. IMO (and I do not speak for others), you are highlighting that boundary. Joe On 3/19/2013 11:16 AM, Bill Jouris wrote: > There may be ways to do this that are well know TO YOU. Or generally to > those who are active in the IETF. > > But it would seem that we may have an education/publicity issue here, > since they do not (at least in my experience) seem to be particularly > widely known to those responsible for supporting networks in the > corporate world. > > Do you have some thoughts on how we might get the word out more > generally? Because it hasn't gotten there so far. > > Bill Jouris > Inside Products, Inc. > www.insidethestack.com > 831-659-8360 > 925-855-9512 (direct) > > --- On *Tue, 3/19/13, Joe Touch //* wrote: > > > From: Joe Touch > Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 > To: "Ackermann, Michael" > Cc: "v6ops@ietf.org" > Date: Tuesday, March 19, 2013, 9:19 AM > ... > This is more complicated, but there are known ways to do this at > very high speed with reasonable amounts of storage. > > Joe > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nalini.elkins@insidethestack.com Tue Mar 19 11:37:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD2C21F8B20 for ; Tue, 19 Mar 2013 11:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.334 X-Spam-Level: X-Spam-Status: No, score=-2.334 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hln92XH4Hc3S for ; Tue, 19 Mar 2013 11:37:46 -0700 (PDT) Received: from nm7-vm0.access.bullet.mail.sp2.yahoo.com (nm7-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.116]) by ietfa.amsl.com (Postfix) with ESMTP id B9F0021F86D5 for ; Tue, 19 Mar 2013 11:37:46 -0700 (PDT) Received: from [98.139.44.105] by nm7.access.bullet.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 18:37:43 -0000 Received: from [98.139.44.91] by tm10.access.bullet.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 18:37:43 -0000 Received: from [127.0.0.1] by omp1028.access.mail.sp2.yahoo.com with NNFMP; 19 Mar 2013 18:37:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 361055.82171.bm@omp1028.access.mail.sp2.yahoo.com Received: (qmail 3853 invoked by uid 60001); 19 Mar 2013 18:37:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1363718262; bh=yZ/ttB+QsGJXjy53VM/LutxfaSyY36SgFsnJ/CZRLDg=; 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; b=IcOA1Wpqyhn1ox6Qdh0Obz5rnxF6DUMwdLhD3bJYwwdNBaLUj+sQTjXHVaQFHfv8tvlFRUu/zY8kLgIjkVAi1chTKaFsLUUR//wt+2hmnRH11mmOFi/HKGQKYB+NEfwH/MuVSDwltGaboqaA2rNVd5zVN/PBbPJ+BNZhRayXegg= X-YMail-OSG: ZM9JIwoVM1n5nX_e6wZaKPGmwy.yMudgnqT98s2DziOZdez Hf2a7iUZ03CiheT_VqsBJQBNBHuiYTC.yDhi5IlpYhyoIQmWh8njOLXJf0lC Xj7vRtPAp4c6RZeq61YTJ99x4OEXBnvROwSGx.aL6ykbpVllpnhNybCzcq0c 2eXX2a8RbxPdlQMrT4dz_iHSV1lNVak48rfGJ0k76Z_5JD6o.q9xwHxyPfad OHruI5YLhIpxEzxdk45XbzxFmVPMbJcdeX0GcP36QTyG16j8b7xCNIxv1rUK fvWV4bbqbpAGe5Dm9ClUZiApBzG_ovuK9GaVU8y5cDrM0FtDGio3wEuClavw io73agLRUwUo6v8r.DoTG4qq5.ZS8LvUya0PbMmzH6XRO_z0RdIp_hjdJs1R Pn4C5znLUPOutePS7O7zAhKWsLxhNLIV6edKuWCRvw80_cjykRnsiMdq4g8n gxBMq5t58YNMIyQb0_Sep0TBGjcqWWViTkqD9xsFWYU2ZaibPe8siJUEtUej OPxRbDvsoFU1pB2YDHdoYfV4UGQLd7hznWoKFt8gddnmQXU6_shd_NTCvDSS 6DXZcEZjBtgGK5WJ0tluiGIpehXivPP1v2J_MEIyOhwle Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Tue, 19 Mar 2013 11:37:42 PDT X-Rocket-MIMEInfo: 002.001, VGhhbmtzLCBGcmVkLiDCoEdvb2QgdGhvdWdodC4KwqAKCk5hbGluaSBFbGtpbnMKSW5zaWRlIFByb2R1Y3RzLCBJbmMuCig4MzEpIDY1OS04MzYwCnd3dy5pbnNpZGV0aGVzdGFjay5jb20KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206ICJUZW1wbGluLCBGcmVkIEwiIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPgpUbzogTmFsaW5pIEVsa2lucyA8bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb20.IApDYzogInY2b3BzQGlldGYub3JnIiA8djZvcHNAaWV0Zi5vcmc.IAoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.138.524 References: <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <5148917D.8030000@inex.ie> <4FC37E442D05A748896589E468752CAA0A64EE4E@PWN401EA160.ent.corp.bcbsm.com> <514897EF.3000900@isi.edu> <1363713407.61156.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <20130319171901.GN51699@Space.Net> <2134F8430051B64F815C691A62D9831803313C@XCH-BLV-504.nw.nos.boeing.com> Message-ID: <1363718262.3761.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Tue, 19 Mar 2013 11:37:42 -0700 (PDT) From: Nalini Elkins To: "Templin, Fred L" In-Reply-To: <2134F8430051B64F815C691A62D9831803313C@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-1352992013-1363718262=:3761" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 18:37:47 -0000 ---1551098171-1352992013-1363718262=:3761 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, Fred. =A0Good thought.=0A=A0=0A=0ANalini Elkins=0AInside Products, = Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A_________________= _______________=0A From: "Templin, Fred L" =0ATo= : Nalini Elkins =0ACc: "v6ops@ietf.org" = =0ASent: Tuesday, March 19, 2013 10:26 AM=0ASubject: RE: [= v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00=0A =0AHere's another thought = - just to have it out on the table. Both=0ASCTP and DCCP have sequence numb= ers, so that is something that=0Amight be worth considering. But, the netwo= rk is still very much=0Aentrenched in TCP and UDP as the only "legitimate" = protocols so I=0Athink it would take a monumental push to get them promoted= to be=0Aon equal footing with TCP and UDP. Just the same, you might want= =0Ato see if there is a community of interest behind SCTP/DCCP and=0Ajoin f= orces with them.=0A=0AThanks - Fred ---1551098171-1352992013-1363718262=:3761 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks, Fred.  G= ood thought.
 

Na= lini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestac= k.com

From:<= /b> "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Nalini Elkins <nalini.elkins@insi= dethestack.com>
Cc:= "v6ops@ietf.org" <v6ops@ietf.org>
Sent: Tuesday, March 19, 2013 10:26 AM
Subject: RE: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed= -00

=0AHere's another thought - just to have it out = on the table. Both
SCTP and DCCP have sequence numbers, so that is somet= hing that
might be worth considering. But, the network is still very muc= h
entrenched in TCP and UDP as the only "legitimate" protocols so I
t= hink it would take a monumental push to get them promoted to be
on equal= footing with TCP and UDP. Just the same, you might want
to see if there= is a community of interest behind SCTP/DCCP and
join forces with them.<= br>
Thanks - Fred


---1551098171-1352992013-1363718262=:3761-- From Tina.Tsou.Zouting@huawei.com Tue Mar 19 12:14:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C062121F8F64 for ; Tue, 19 Mar 2013 12:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, FRT_FOLLOW2=0.422, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 AnoS2UX9-0RG for ; Tue, 19 Mar 2013 12:14:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 226D121F8F0D for ; Tue, 19 Mar 2013 12:14:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APO43100; Tue, 19 Mar 2013 19:14:03 +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.7; Tue, 19 Mar 2013 19:13:01 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 19 Mar 2013 19:13:45 +0000 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.86]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Tue, 19 Mar 2013 12:13:38 -0700 From: Tina TSOU To: Iljitsch van Beijnum , IPv6 Ops WG Thread-Topic: [v6ops] draft-steffann-tunnels-00.txt Thread-Index: AQHOJMAFdvUzw9GRGke4nfSwPHg855itWgWQ Date: Tue, 19 Mar 2013 19:13:38 +0000 Message-ID: References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.94] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-steffann-tunnels@tools.ietf.org" Subject: Re: [v6ops] draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 19:14:07 -0000 RGVhciBJbGppdHNjaCwNClRoYW5rcyBmb3IgbGV0dGluZyB1cyBrbm93Lg0KDQpTZWN0aW9uIDMs DQpXaGVuIGl0IG1lbnRpb25zIERTLUxpdGUgYW5kIE1BUCwgSSB0aGluayBhIG1vcmUgY29tcGxl dGUgcGljdHVyZSBjb3VsZCBiZSBtZW50aW9uZWQgaW4gdGhlIGZvbGxvaXduZyB3YXkuDQoNCiAg RHVhbC1TdGFjayBMaXRlIFtSRkM2MzMzXSAoRnVsbCBzdGF0ZWZ1bCksIExXNG82IFtJLUQuY3Vp LXNvZnR3aXJlLWI0LXRyYW5zbGF0ZWQtZHMtbGl0ZV0gKEJpbmRpbmcpLCBNQVAgW0ktRC5pZXRm LXNvZnR3aXJlLW1hcF0gKEZ1bGwgU3RhdGVsZXNzKSwgcmVmZXJlZCBpbiBzZWN0aW9uIDQgb2Yg VW5pZmllZCBDUEUgW0ktRC5pZXRmLXNvZnR3aXJlLXVuaWZpZWQtY3BlXSwgYWxsIGRldmVsb3Bl ZCBieSB0aGUgSUVURiBTb2Z0d2lyZSB3b3JraW5nIGdyb3VwLCBvZnRlbiBjb21lIHVwIGluDQog ICBkaXNjdXNzaW9ucyBhYm91dCBJUHY2IHR1bm5lbGluZy4gIEhvd2V2ZXIsIHRoZXkgYXJlIF9u b3RfIElQdjYtaW4tDQogICBJUHY0IHR1bm5lbCBtZWNoYW5pc21zLiAgVGhleSBhcmUgSVB2NC1p bi1JUHY2IG1lY2hhbmlzbXMgZm9yDQogICBwcm92aWRpbmcgSVB2NCBjb25uZWN0aXZpdHkgb3Zl ciBhbiBJUHY2IGluZnJhc3RydWN0dXJlLg0KDQpQLnMuIExXNG82IFtJLUQuY3VpLXNvZnR3aXJl LWI0LXRyYW5zbGF0ZWQtZHMtbGl0ZV0gbWF5IGJlY29tZSBXRyBkcmFmdCBieSBBcHJpbCAyLCBh ZnRlciB0aGUgY29uZmlybWluZyB0aGUgYWRvcHRpb24gaW4gdGhlIGxpc3QgYmVzaWRlcyB0aGUg c3Ryb25nIHN1cHBvcnQgZm9yIGFkb3B0aW9uIGluIHRoZSByb29tLiBUaGVuIHlvdSBtYXkgbmVl ZCB0byB1cGRhdGUgdGhlIHJlZmVyZW5jZSBuYW1lIGxhdGVyLg0KDQpUaGFuayB5b3UsDQpUaW5h DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB2Nm9wcy1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9m IElsaml0c2NoIHZhbiBCZWlqbnVtDQo+IFNlbnQ6IDIwMTPE6jPUwjE5yNUgOTozNw0KPiBUbzog SVB2NiBPcHMgV0cNCj4gQ2M6IGRyYWZ0LXN0ZWZmYW5uLXR1bm5lbHNAdG9vbHMuaWV0Zi5vcmcN Cj4gU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtc3RlZmZhbm4tdHVubmVscy0wMC50eHQNCj4g DQo+IE9uIDE1IGZlYiAyMDEzLCBhdCA5OjQ0LCBJbGppdHNjaCB2YW4gQmVpam51bSA8aWxqaXRz Y2hAbXVhZGEuY29tPiB3cm90ZToNCj4gDQo+ID4gVGhyZWUgb2YgdXMgd2VyZSBhc2tlZCBieSB0 aGUgRHV0Y2ggYWNhZGVtaWMgbmV0d29yayBTdXJmbmV0IHRvIHdyaXRlDQo+IGFuIG92ZXJ2aWV3 IG9mIElQdjYtaW4tSVB2NCB0dW5uZWxpbmcgbWVjaGFuaXNtcy4gVG8gYmVuZWZpdCB0aGUgd2lk ZXINCj4gY29tbXVuaXR5LCB3ZSBkaWQgc28gaW4gdGhlIGZvcm0gb2YgYSBkcmFmdCwgdGhhdCB3 ZSBpbnRlbmQgdG8gc3VibWl0IHRvDQo+IHRoZSBSRkMgRWRpdG9yIGFzIGFuIGluZGVwZW5kZW50 IHN1Ym1pc3Npb24uDQo+IA0KPiA+IEhvd2V2ZXIsIHdlIHdvdWxkIHZlcnkgbXVjaCBhcHByZWNp YXRlIHJldmlld3MgYW5kIGNvbW1lbnRzIGZyb20NCj4gd2l0aGluIHRoZSBJRVRGLg0KPiANCj4g V2UgaGF2ZSBzdWJtaXR0ZWQgdmVyc2lvbiAtMDEgd2hpY2ggYWRkcmVzc2VzIHJlbWFya3MgZnJv bSByZXZpZXdlcnMuDQo+IFRoZSBuZXcgdmVyc2lvbiBjYW4gYmUgZm91bmQgaGVyZToNCj4gDQo+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXN0ZWZmYW5uLXR1bm5lbHMv DQo+IA0KPiBXZSBwbGFuIG9uIHN1Ym1pdHRpbmcgdGhlIGRyYWZ0IHRvIHRoZSBSRkMgRWRpdG9y IGF0IHRoZSBlbmQgb2YgdGhlIHdlZWsuDQo+IA0KPiBJbGppdHNjaA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QN Cj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by92Nm9wcw0K From dougb@dougbarton.us Tue Mar 19 13:35:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D61721F87D1 for ; Tue, 19 Mar 2013 13:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtgRVDY-1xLj for ; Tue, 19 Mar 2013 13:35:21 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id B7DB721F86D9 for ; Tue, 19 Mar 2013 13:35:21 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:7455:df60:c4e2:6cc5] (unknown [IPv6:2001:470:d:5e7:7455:df60:c4e2:6cc5]) by dougbarton.us (Postfix) with ESMTPSA id 65E4D22B12 for ; Tue, 19 Mar 2013 20:35:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1363725321; bh=/L2+kjQz3PsXmg2puXveTwTehPfiCm39bHi5DEObqWo=; h=Date:From:To:Subject:References:In-Reply-To; b=xT10AVdg3IM4APRgpLYuImQsRn99LApZhOCyFbT30reYhzVFb7L39NoKV/0r4tgA7 tzUToDZsJyVAgSD/qgR7e2Muon18egYqFLc5AfUA4FK2fCwG8GwGd/YjzlVNdrRMut bYV0ukPyVjNTEN5WD51zODQsAY2UJAMJ0U/FBM0w= Message-ID: <5148CC09.8030405@dougbarton.us> Date: Tue, 19 Mar 2013 13:35:21 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <5148917D.8030000@inex.ie> <4FC37E442D05A748896589E468752CAA0A64EE4E@PWN401EA160.ent.corp.bcbsm.com> <514897EF.3000900@isi.edu> <1363713407.61156.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> In-Reply-To: <1363713407.61156.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 20:35:23 -0000 One of the chief complaints from people who have considered implementing IPv6, but have not done so yet, is that the IETF keeps tinkering with the protocol. Others much more knowledgeable than I have already pointed out the technical reasons why it would not be possible to implement the IPID field in the manner you describe in a way that is backwards compatible with existing installations, and not doing it in a backwards compatible way is a non-starter. I have no small amount of sympathy for your concern, but it seems that we're in the "that ship has already sailed" territory unless you can provide a robust solution that won't require changes to the installed base. Doug On 03/19/2013 10:16 AM, Nalini Elkins wrote: > I would wonder what the depth of the IPv6 implementation is. And, what > "sites" were talked to. > > I, myself, have been worked in the corporate world for over 30 years and > talk to multiple Fortune 1,000 companies daily. I can tell you that a > number are looking at their web sites & external access (but NOT their > internal network). A few are looking at internal implementation, and > quite a few are saying "We have no plans to look at this". > > This whole discussion points out the reasons that corporations need to > be involved in IETF - it will be good for both parties. We are working > on this! > Thanks, > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > ------------------------------------------------------------------------ > *From:* Joe Touch > *To:* "Ackermann, Michael" > *Cc:* "v6ops@ietf.org" > *Sent:* Tuesday, March 19, 2013 9:53 AM > *Subject:* Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 > > Your view of IPv6 deployment seems a bit dated. > > It might be useful to take a look here: > > http://eggert.org/meter/ipv6 > > Joe From touch@isi.edu Tue Mar 19 13:48:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2560B21F8C9E for ; Tue, 19 Mar 2013 13:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.262 X-Spam-Level: X-Spam-Status: No, score=-105.262 tagged_above=-999 required=5 tests=[AWL=0.737, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oht8733u28dJ for ; Tue, 19 Mar 2013 13:48:41 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 51E0B21F8CCF for ; Tue, 19 Mar 2013 13:48:41 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r2JKkVu2000163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Mar 2013 13:46:31 -0700 (PDT) Message-ID: <5148CEA3.3020902@isi.edu> Date: Tue, 19 Mar 2013 13:46:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Doug Barton References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <5148917D.8030000@inex.ie> <4FC37E442D05A748896589E468752CAA0A64EE4E@PWN401EA160.ent.corp.bcbsm.com> <514897EF.3000900@isi.edu> <1363713407.61156.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <5148CC09.8030405@dougbarton.us> In-Reply-To: <5148CC09.8030405@dougbarton.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 20:48:42 -0000 Besides "that ship has sailed", I think it's useful to consider *why* it sailed in the direction it has, in terms of both cost and complexity. JOe On 3/19/2013 1:35 PM, Doug Barton wrote: > One of the chief complaints from people who have considered implementing > IPv6, but have not done so yet, is that the IETF keeps tinkering with > the protocol. Others much more knowledgeable than I have already pointed > out the technical reasons why it would not be possible to implement the > IPID field in the manner you describe in a way that is backwards > compatible with existing installations, and not doing it in a backwards > compatible way is a non-starter. > > I have no small amount of sympathy for your concern, but it seems that > we're in the "that ship has already sailed" territory unless you can > provide a robust solution that won't require changes to the installed base. > > Doug > > > On 03/19/2013 10:16 AM, Nalini Elkins wrote: >> I would wonder what the depth of the IPv6 implementation is. And, what >> "sites" were talked to. >> >> I, myself, have been worked in the corporate world for over 30 years and >> talk to multiple Fortune 1,000 companies daily. I can tell you that a >> number are looking at their web sites & external access (but NOT their >> internal network). A few are looking at internal implementation, and >> quite a few are saying "We have no plans to look at this". >> >> This whole discussion points out the reasons that corporations need to >> be involved in IETF - it will be good for both parties. We are working >> on this! >> Thanks, >> >> Nalini Elkins >> Inside Products, Inc. >> (831) 659-8360 >> www.insidethestack.com >> >> ------------------------------------------------------------------------ >> *From:* Joe Touch >> *To:* "Ackermann, Michael" >> *Cc:* "v6ops@ietf.org" >> *Sent:* Tuesday, March 19, 2013 9:53 AM >> *Subject:* Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 >> >> Your view of IPv6 deployment seems a bit dated. >> >> It might be useful to take a look here: >> >> http://eggert.org/meter/ipv6 >> >> Joe > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nalini.elkins@insidethestack.com Tue Mar 19 14:12:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E635D21F9030 for ; Tue, 19 Mar 2013 14:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] 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 ov4bAi-igHNf for ; Tue, 19 Mar 2013 14:12:03 -0700 (PDT) Received: from nm5.access.bullet.mail.mud.yahoo.com (nm5.access.bullet.mail.mud.yahoo.com [66.94.237.206]) by ietfa.amsl.com (Postfix) with ESMTP id 0476821F9020 for ; Tue, 19 Mar 2013 14:12:02 -0700 (PDT) Received: from [66.94.237.199] by nm5.access.bullet.mail.mud.yahoo.com with NNFMP; 19 Mar 2013 21:12:02 -0000 Received: from [66.94.237.112] by tm10.access.bullet.mail.mud.yahoo.com with NNFMP; 19 Mar 2013 21:12:02 -0000 Received: from [127.0.0.1] by omp1017.access.mail.mud.yahoo.com with NNFMP; 19 Mar 2013 21:12:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 503674.28855.bm@omp1017.access.mail.mud.yahoo.com Received: (qmail 26929 invoked by uid 60001); 19 Mar 2013 21:12:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1363727522; bh=Pi0784d6iaVR7C1o4mBs7UwHp4AcsvCu2Wyg+nFdoZ8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=6lJz9YYL9SGWzMROSI+DM2vx2TrS8eQXeePSzYxljU8FKG6gq1JdkTg1aIXgzygjynOgP8OtiG+mwRTFWfHgAPH1XCHC4aPwtnvbwzaJSUBVmJfQbgbt03OrKPI+Ywjkza4trpxzeWpXp2AGTs6z9P3gCExaye/g591rDpDenVY= X-YMail-OSG: UUQHr54VM1nDNNbDmxOuepcmne04h.t0pWE2OVs9DTsuWJd GK8e_AA4adLFQ0Q7NHuWULbkFocclTIVH_M3EB79GWXzDxhhms3byZX2JJ5E hGbycxvPzbjqp4k9iMJscjVmgz7qHuZaifZKzNBxgOhPEmVey.GCEAE4QrDk 8_SPNJbgcm5bfIFNqb4MqddOGFi3yP9yfTmWu4czkTs7FjcCycjG_mOt7EYP g5URNxHgSJj_nBwgEGselKYkWr0jpEvfmeni5ethtgHxgBn4_5.2.XCZMhjX 74HE8zx1ZhJT3MuT8zDy3Av65UHwxlL2XagVfssr5mt8Md6GlE5p9ryoVBIT FwNlMRjkorWtodtuNXRbeVD1TFo3MtRA.05wqaEAC.Gv.XoWDkOeLtNS55a5 CJIJiYxmnMvn7FkNmTv.jYkCFp9mRZdvtnc75NurJ8sM0cMDnkY9k.2aeL_Y t6u10kNAPhliLcYRW3NHH8Bt8s8NTjwK.IXAG6EO6_z2WogcSxAF3tON7.s9 zFOSHgyaxkKwqvbtxHnCe2yCMyapu.bKr6HpL7Jr6gxEKq0JJ.RvIO4dQu.F DlUFC.ZPTjkENhHlxhiyhSGeV63zWv7.C6dlJx5mUPZa29CN6m83oQLTk8_Z EDTS91qxeBf.8JPQGfO6tM7mRXls8gpILABje Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Tue, 19 Mar 2013 14:12:01 PDT X-Rocket-MIMEInfo: 002.001, VGhhbmtzIERvdWcuIMKgQXBwcmVjaWF0ZSB0aGUgY29tbWVudHMuCgpMZXQncyBzZWUgd2hhdCB3ZSBjYW4gZG8gdG8gYXMgeW91IHNheSwgInByb3ZpZGUgYSByb2J1c3Qgc29sdXRpb24gdGhhdCB3b24ndCByZXF1aXJlIGNoYW5nZXMgdG8gdGhlIGluc3RhbGxlZCBiYXNlLiIKwqAKVGhhbmtzLAoKCk5hbGluaSBFbGtpbnMKSW5zaWRlIFByb2R1Y3RzLCBJbmMuCig4MzEpIDY1OS04MzYwCnd3dy5pbnNpZGV0aGVzdGFjay5jb20KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206IEQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.138.524 References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <5148917D.8030000@inex.ie> <4FC37E442D05A748896589E468752CAA0A64EE4E@PWN401EA160.ent.corp.bcbsm.com> <514897EF.3000900@isi.edu> <1363713407.61156.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <5148CC09.8030405@dougbarton.us> Message-ID: <1363727521.26101.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Tue, 19 Mar 2013 14:12:01 -0700 (PDT) From: Nalini Elkins To: Doug Barton , "v6ops@ietf.org" In-Reply-To: <5148CC09.8030405@dougbarton.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-287201966-1363727521=:26101" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 21:12:04 -0000 ---1551098171-287201966-1363727521=:26101 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Doug. =A0Appreciate the comments.=0A=0ALet's see what we can do to a= s you say, "provide a robust solution that won't require changes to the ins= talled base."=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Products, Inc.= =0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A_____________________= ___________=0A From: Doug Barton =0ATo: v6ops@ietf.org= =0ASent: Tuesday, March 19, 2013 1:35 PM=0ASubject: Re: [v6ops] draft-elki= ns-v6ops-ipv6-ipid-needed-00=0A =0AOne of the chief complaints from people = who have considered implementing =0AIPv6, but have not done so yet, is that= the IETF keeps tinkering with =0Athe protocol. Others much more knowledgea= ble than I have already pointed =0Aout the technical reasons why it would n= ot be possible to implement the =0AIPID field in the manner you describe in= a way that is backwards =0Acompatible with existing installations, and not= doing it in a backwards =0Acompatible way is a non-starter.=0A=0AI have no= small amount of sympathy for your concern, but it seems that =0Awe're in t= he "that ship has already sailed" territory unless you can =0Aprovide a rob= ust solution that won't require changes to the installed base.=0A=0ADoug=0A= =0A=0AOn 03/19/2013 10:16 AM, Nalini Elkins wrote:=0A> I would wonder what = the depth of the IPv6 implementation is.=A0 And, what=0A> "sites" were talk= ed to.=0A>=0A> I, myself, have been worked in the corporate world for over = 30 years and=0A> talk to multiple Fortune 1,000 companies daily.=A0 I can t= ell you that a=0A> number are looking at their web sites & external access = (but NOT their=0A> internal network).=A0 A few are looking at internal imp= lementation, and=0A> quite a few are saying "We have no plans to look at th= is".=0A>=0A> This whole discussion points out the reasons that corporations= need to=0A> be involved in IETF - it will be good for both parties.=A0 We = are working=0A> on this!=0A> Thanks,=0A>=0A> Nalini Elkins=0A> Inside Produ= cts, Inc.=0A> (831) 659-8360=0A> www.insidethestack.com=0A>=0A> -----------= -------------------------------------------------------------=0A> *From:* J= oe Touch =0A> *To:* "Ackermann, Michael" =0A> *Cc:* "v6ops@ietf.org" =0A> *Sent:* Tuesday, March = 19, 2013 9:53 AM=0A> *Subject:* Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-ne= eded-00=0A>=0A> Your view of IPv6 deployment seems a bit dated.=0A>=0A> It = might be useful to take a look here:=0A>=0A> http://eggert.org/meter/ipv6= =0A>=0A> Joe=0A=0A_______________________________________________=0Av6ops m= ailing list=0Av6ops@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/v6ops ---1551098171-287201966-1363727521=:26101 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable ---1551098171-287201966-1363727521=:26101-- From mackermann@bcbsm.com Tue Mar 19 16:15:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4565F21F8DBB for ; Tue, 19 Mar 2013 16:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.023 X-Spam-Level: X-Spam-Status: No, score=-6.023 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 YzRfvNugilh3 for ; Tue, 19 Mar 2013 16:15:01 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.zixworks.com [63.71.11.123]) by ietfa.amsl.com (Postfix) with ESMTP id 604FE21F8DB4 for ; Tue, 19 Mar 2013 16:14:59 -0700 (PDT) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 12FAE17E50B for ; Tue, 19 Mar 2013 18:14:59 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id EA91617E429; Tue, 19 Mar 2013 18:14:57 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id C8EB14F8051; Tue, 19 Mar 2013 19:13:41 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva1.bcbsm.com (Postfix) with ESMTP id BB73C4F804F; Tue, 19 Mar 2013 19:13:41 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA100.ent.corp.bcbsm.com ([fe80::8db:9ce7:e2cf:8565%14]) with mapi id 14.01.0355.002; Tue, 19 Mar 2013 19:14:57 -0400 From: "Ackermann, Michael" To: Joe Touch , Doug Barton Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 Thread-Index: AQHOIMaVqC5M9XVYp0uFMLNLdFX3pZil/fsAgAW9XMeAAHp1AP//xeIwgABMrQCAAAwVAIAAA8SAgAAgdgCAAOykAP//wa/wgABXRYD//8ApAAAI8N2AAADUMYAABu9TgAAAYz6AAAW/YcA= Date: Tue, 19 Mar 2013 23:14:55 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A64F236@PWN401EA160.ent.corp.bcbsm.com> References: <5141E936.7090006@bogus.com> <1363297956.27744.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51425168.1080106@isi.edu> <1363627895.16683.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51477DF4.9070304@isi.edu> <4FC37E442D05A748896589E468752CAA0A64E91C@PWN401EA160.ent.corp.bcbsm.com> <51478D86.2090008@inex.ie> <1363646376.64760.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D983180320FF@XCH-BLV-504.nw.nos.boeing.com> <1363654156.16516.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <2134F8430051B64F815C691A62D98318032BD5@XCH-BLV-504.nw.nos.boeing.com> <4FC37E442D05A748896589E468752CAA0A64ECB5@PWN401EA160.ent.corp.bcbsm.com> <5148917D.8030000@inex.ie> <4FC37E442D05A748896589E468752CAA0A64EE4E@PWN401EA160.ent.corp.bcbsm.com> <514897EF.3000900@isi.edu> <1363713407.61156.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <5148CC09.8030405@dougbarton.us> <5148CEA3.3020902@isi.edu> In-Reply-To: <5148CEA3.3020902@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 23:15:02 -0000 In sticking with the maritime metaphors, are you concerned at all that = your ship may have a lighter load (e.g. less bits), but may be lacking the = tools or supplies (e.g. IPID) to repair itself QUICKLY in the event of a = disaster? It's a decision of where the real cost and complexity and = risk exist in the implied scenario. =20 I get that the perspective of my organization and those like us is very = different than many at IETF, but our ships do not usually leave port until = it is completely ready, safe and as prepared as possible for the unknown. = =20 That is my concern for IPV6 in corporate America. That it may leave port = before it is ready and ....................... Do I wish we made our case years ago? Heck yes. And I again apologize = for being late. Is it better late than never???????? =20 I am going to go eat some spinach now=21 :) =20 -----Original Message----- From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Joe Touch Sent: Tuesday, March 19, 2013 4:46 PM To: Doug Barton Cc: v6ops=40ietf.org Subject: Re: =5Bv6ops=5D draft-elkins-v6ops-ipv6-ipid-needed-00 Besides =22that ship has sailed=22, I think it's useful to consider *why* = it sailed in the direction it has, in terms of both cost and complexity. JOe On 3/19/2013 1:35 PM, Doug Barton wrote: > One of the chief complaints from people who have considered=20 > implementing IPv6, but have not done so yet, is that the IETF keeps=20 > tinkering with the protocol. Others much more knowledgeable than I=20 > have already pointed out the technical reasons why it would not be=20 > possible to implement the IPID field in the manner you describe in a=20 > way that is backwards compatible with existing installations, and not=20 > doing it in a backwards compatible way is a non-starter. > > I have no small amount of sympathy for your concern, but it seems that=20 > we're in the =22that ship has already sailed=22 territory unless you = can=20 > provide a robust solution that won't require changes to the installed = base. > > Doug > > > On 03/19/2013 10:16 AM, Nalini Elkins wrote: >> I would wonder what the depth of the IPv6 implementation is. And,=20 >> what =22sites=22 were talked to. >> >> I, myself, have been worked in the corporate world for over 30 years=20 >> and talk to multiple Fortune 1,000 companies daily. I can tell you=20 >> that a number are looking at their web sites & external access (but NOT = their >> internal network). A few are looking at internal implementation, and >> quite a few are saying =22We have no plans to look at this=22. >> >> This whole discussion points out the reasons that corporations need=20 >> to be involved in IETF - it will be good for both parties. We are=20 >> working on this=21 >> Thanks, >> >> Nalini Elkins >> Inside Products, Inc. >> (831) 659-8360 >> www.insidethestack.com >> >> --------------------------------------------------------------------- >> --- >> *From:* Joe Touch >> *To:* =22Ackermann, Michael=22 >> *Cc:* =22v6ops=40ietf.org=22 >> *Sent:* Tuesday, March 19, 2013 9:53 AM >> *Subject:* Re: =5Bv6ops=5D draft-elkins-v6ops-ipv6-ipid-needed-00 >> >> Your view of IPv6 deployment seems a bit dated. >> >> It might be useful to take a look here: >> >> http://eggert.org/meter/ipv6 >> >> Joe > > _______________________________________________ > v6ops mailing list > v6ops=40ietf.org > https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From randy@psg.com Tue Mar 19 23:56:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4AF21F8F41 for ; Tue, 19 Mar 2013 23:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32FmZxyA2kC0 for ; Tue, 19 Mar 2013 23:56:35 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C0BD721F8D76 for ; Tue, 19 Mar 2013 23:56:35 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UICws-000JFE-5O; Wed, 20 Mar 2013 06:56:34 +0000 Date: Wed, 20 Mar 2013 08:56:32 +0200 Message-ID: From: Randy Bush To: Ray Hunter In-Reply-To: <514863DB.4000507@globis.net> References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 06:56:36 -0000 > I have a problem with "BCP" status for any draft recommending use of > ULA +1 randy From tjc@ecs.soton.ac.uk Wed Mar 20 00:43:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D0421F8D76 for ; Wed, 20 Mar 2013 00:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 r8MKrsxQa1+Y for ; Wed, 20 Mar 2013 00:43:09 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id DED4221F8D46 for ; Wed, 20 Mar 2013 00:43:08 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r2K7gmi2014681; Wed, 20 Mar 2013 07:42:48 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r2K7gmi2014681 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1363765368; bh=HQs17I7iIdObsHUEJitJaGaS+ns=; h=References:Mime-Version:In-Reply-To:Cc:From:Subject:Date:To; b=rnknJ1qfANlVNDmFv1mgfoHU1K3gHR63L3RxuFZVOEEe+OEfbvXEJ37DVCIAwJPTx mfikOjhpzMKlzmNafYh260yvJro4qHU8QAU6w0ZSdMcZ1f1fkoN6ypMIxJvvTahw0X wJjvm4ef3C3R6P4Dph5tLwXoWyeHjc10bKePi2Js= 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 p2J7gm0430630946nb ret-id none; Wed, 20 Mar 2013 07:42:48 +0000 Received: from [192.168.1.101] (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 r2K7giep011826 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Mar 2013 07:42:44 GMT References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> Mime-Version: 1.0 (1.0) In-Reply-To: <514863DB.4000507@globis.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: X-Mailer: iPad Mail (10B146) From: Tim Chown Date: Wed, 20 Mar 2013 07:42:44 +0000 To: Ray Hunter X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p2J7gm043063094600; tid=p2J7gm0430630946nb; 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: r2K7gmi2014681 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: v6ops WG Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 07:43:10 -0000 On 19 Mar 2013, at 13:10, Ray Hunter wrote: > Fred Baker (fred) wrote: >> In the meeting at IETF 86, we discussed >>=20 >> http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis >> http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis >> "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang, >> Cameron Byrne, 25-Feb-13 >>=20 >> and the hum supported making that a working group draft. In this note, I'= m asking for ratification on the list - whether you agree or disagree, I'd a= ppreciate your thoughts. > I have a problem with "BCP" status for any draft recommending use of ULA > on Internet connected networks without some health warning, because I'm > not yet convinced that this may not end up being harmful [highly mobile > devices, split horizon, caching]. Informational seems appropriate. While some of us have been using them in various contexts, unless we hear of= widescale, significant deployments, it's difficult to argue for BCP. Tim= From brian.e.carpenter@gmail.com Wed Mar 20 01:48:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3885821F8A99 for ; Wed, 20 Mar 2013 01:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.383 X-Spam-Level: X-Spam-Status: No, score=-99.383 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 8EUQYVWAQaa5 for ; Wed, 20 Mar 2013 01:48:09 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8624C21F8A8E for ; Wed, 20 Mar 2013 01:48:09 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id r3so725676wey.16 for ; Wed, 20 Mar 2013 01:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BJSQg1yRuFt+p5Kqems+X68Hokhyqvky4NkfwpoavE8=; b=JiPDXf7G7TpDPWyZ7F5bdUCFdw97WHCZJ6xRKFJgjA01m90xMWSc7nyhCPwMhNkPGF arIo+geFLvqECUWUO/cRi64TphJdaUf67LByP7fONNcNolkbWc32F4IllwSaVIUVY0Rb 8W4hGyzBzB6/psTX6D3TU6ZKdzd5RNfBDHjKZxyR+C8RU7qN/TGfAf0JKCC5nLTltpHJ qy+9veP187gG+LCcXJCJr3Tf0eDuZ2aJhopzcaWRwiYTHwJZgl1HWjzZZM+H01VF8PBK Fp/sj1OSLaptxW7J9oztI7ZR+xn0fuzrYppv85+GEpVAd8q+sq7OtR+5qReN8LYtDhOm sHYQ== X-Received: by 10.194.90.168 with SMTP id bx8mr8681100wjb.59.1363769288769; Wed, 20 Mar 2013 01:48:08 -0700 (PDT) Received: from [192.168.1.64] (host-2-102-218-109.as13285.net. [2.102.218.109]) by mx.google.com with ESMTPS id ex15sm5493558wid.5.2013.03.20.01.48.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Mar 2013 01:48:07 -0700 (PDT) Message-ID: <514977CF.9030806@gmail.com> Date: Wed, 20 Mar 2013 08:48:15 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tim Chown References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ray Hunter , v6ops WG Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 08:48:10 -0000 On 20/03/2013 07:42, Tim Chown wrote: > On 19 Mar 2013, at 13:10, Ray Hunter wrote: > >> Fred Baker (fred) wrote: >>> In the meeting at IETF 86, we discussed >>> >>> http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis >>> http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis >>> "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang, >>> Cameron Byrne, 25-Feb-13 >>> >>> and the hum supported making that a working group draft. In this note, I'm asking for ratification on the list - whether you agree or disagree, I'd appreciate your thoughts. >> I have a problem with "BCP" status for any draft recommending use of ULA >> on Internet connected networks without some health warning, because I'm >> not yet convinced that this may not end up being harmful [highly mobile >> devices, split horizon, caching]. > > Informational seems appropriate. > > While some of us have been using them in various contexts, unless we hear of widescale, significant deployments, it's difficult to argue for BCP. It depends. If the draft says "If you choose to use a ULA prefix, here are some guidelines on how to do it properly", BCP might be appropriate. However, an informational description of appropriate deployment scenarios would be quite OK. If it says "Use a ULA prefix!", I would certainly object to BCP. Brian From tjc@ecs.soton.ac.uk Wed Mar 20 02:03:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D99221F8A71 for ; Wed, 20 Mar 2013 02:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=0.424, 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 LmSwetgtgSC2 for ; Wed, 20 Mar 2013 02:03:33 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 42C0C21F89FB for ; Wed, 20 Mar 2013 02:03:33 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r2K93Qu8001616 for ; Wed, 20 Mar 2013 09:03:26 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r2K93Qu8001616 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1363770206; bh=2OiZ9QMc4fs+akN9zyiUdUnyMA4=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=auvmr3HjHFv0XieQBweMrmpCYTFWKZSSKSXdrHZnLKSIBV6Ebp0gipw3ln0qWUs17 fRCtUXGiKilihns4zemOOt05EkaiKkMlTqhMHjoUItTgAreJNmLumct+6wrrC3Q91a fsY7vttffFoTa6QhPfGS/MQHbfeht3qYYW7/3/CU= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id p2J93Q0430631707hX ret-id none; Wed, 20 Mar 2013 09:03:26 +0000 Received: from [192.168.1.103] (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 r2K932bK028083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 20 Mar 2013 09:03:02 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <514977CF.9030806@gmail.com> Date: Wed, 20 Mar 2013 09:03:01 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> To: "v6ops@ietf.org Operations" X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p2J93Q043063170700; tid=p2J93Q0430631707hX; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r2K93Qu8001616 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 09:03:34 -0000 On 20 Mar 2013, at 08:48, Brian E Carpenter = wrote: > On 20/03/2013 07:42, Tim Chown wrote: >> On 19 Mar 2013, at 13:10, Ray Hunter wrote: >>=20 >>> Fred Baker (fred) wrote: >>>> In the meeting at IETF 86, we discussed >>>>=20 >>>> http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis >>>> http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis >>>> "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang, >>>> Cameron Byrne, 25-Feb-13 >>>>=20 >>>> and the hum supported making that a working group draft. In this = note, I'm asking for ratification on the list - whether you agree or = disagree, I'd appreciate your thoughts. >>> I have a problem with "BCP" status for any draft recommending use of = ULA >>> on Internet connected networks without some health warning, because = I'm >>> not yet convinced that this may not end up being harmful [highly = mobile >>> devices, split horizon, caching]. >>=20 >> Informational seems appropriate. >>=20 >> While some of us have been using them in various contexts, unless we = hear of widescale, significant deployments, it's difficult to argue for = BCP. >=20 > It depends. If the draft says "If you choose to use a ULA prefix, here > are some guidelines on how to do it properly", BCP might be = appropriate. > However, an informational description of appropriate deployment = scenarios > would be quite OK. >=20 > If it says "Use a ULA prefix!", I would certainly object to BCP. The homenet arch (which is Informational) is recommending use of ULAs. = There are real use cases already identified there, particularly with = constrained devices; one of the arch text authors is I believe already = producing such things.=20 The other arguments made include disconnected operation, and internal = connection persistence through ISP-traiggered renumbering events. A challenge is dealing with multiple internal routers that may generate = a /48 ULA, including cases where such devices are initially not = connected and are then joined/merged. In such cases devices in the = homenet need to be aware of which ULA prefixes are internal to the home, = and thus that should be preferred over GUAs for address selection. Tim= From alexandru.petrescu@gmail.com Wed Mar 20 02:16:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E182A21F88C6 for ; Wed, 20 Mar 2013 02:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.872 X-Spam-Level: X-Spam-Status: No, score=-9.872 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKWOad8xiYFY for ; Wed, 20 Mar 2013 02:16:40 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id F267B21F887F for ; Wed, 20 Mar 2013 02:16:39 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2K9GcuP005461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 20 Mar 2013 10:16:39 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2K9GcQD000655 for ; Wed, 20 Mar 2013 10:16:38 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2K9GYt9000588 for ; Wed, 20 Mar 2013 10:16:38 +0100 Message-ID: <51497E49.5080101@gmail.com> Date: Wed, 20 Mar 2013 10:15:53 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> In-Reply-To: <514977CF.9030806@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 09:16:41 -0000 Le 20/03/2013 09:48, Brian E Carpenter a écrit : > On 20/03/2013 07:42, Tim Chown wrote: >> On 19 Mar 2013, at 13:10, Ray Hunter wrote: >> >>> Fred Baker (fred) wrote: >>>> In the meeting at IETF 86, we discussed >>>> >>>> http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis >>>> >>>> http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis >>>> "Guidance of Using Unique Local Addresses", Bing Liu, Sheng >>>> Jiang, Cameron Byrne, 25-Feb-13 >>>> >>>> and the hum supported making that a working group draft. In >>>> this note, I'm asking for ratification on the list - whether >>>> you agree or disagree, I'd appreciate your thoughts. >>> I have a problem with "BCP" status for any draft recommending use >>> of ULA on Internet connected networks without some health >>> warning, because I'm not yet convinced that this may not end up >>> being harmful [highly mobile devices, split horizon, caching]. >> >> Informational seems appropriate. >> >> While some of us have been using them in various contexts, unless >> we hear of widescale, significant deployments, it's difficult to >> argue for BCP. > > It depends. If the draft says "If you choose to use a ULA prefix, > here are some guidelines on how to do it properly", BCP might be > appropriate. However, an informational description of appropriate > deployment scenarios would be quite OK. > > If it says "Use a ULA prefix!", I would certainly object to BCP. I agree with both points. We consider the ULAs for vehicular networks, although not sure yet whether the current convenience we have on using them means we should go that way any further. Typically one vehicle would be a 'site', yet vehicle-to-vehicle communications would form another one. just a little larger such site. This begs for the advice: is the Mobile Router (a router, or 'modem', or 'ECU', or Gateway) deployed in the vehicle making a strict separation between the vehicle and the outside of the vehicle for these ULAs? (i.e. dont forward ULA-addresses packets in-out of vehicle). Or is that separation done only when connecting to the fixed infrastructure (i.e. to Internet, with a default route)? Should we set the L bit (local/global). Are alternative methods possible for seeting the Global ID possible? (other than RFC4193, which suggests to rely on the time, EUI-64 and SHA-1 - each having various constraints: where to get time in a reliable manner, which EUI-64 of those many in a vehicle, export control.) Alex > > Brian _______________________________________________ v6ops mailing > list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From iljitsch@muada.com Wed Mar 20 03:36:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347DE21F848D for ; Wed, 20 Mar 2013 03:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.389 X-Spam-Level: X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, FRT_FOLLOW2=0.422, 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 vNCS2bvKgfwR for ; Wed, 20 Mar 2013 03:36:17 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 039E921F848A for ; Wed, 20 Mar 2013 03:36:16 -0700 (PDT) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2KAVBE5060094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Mar 2013 11:31:12 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: Date: Wed, 20 Mar 2013 11:36:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <58E5D429-5037-48C9-91CB-07011EBB90C8@muada.com> References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> To: Tina TSOU X-Mailer: Apple Mail (2.1499) Cc: IPv6 Ops WG , "draft-steffann-tunnels@tools.ietf.org" Subject: Re: [v6ops] draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 10:36:18 -0000 Hi Tina, On 19 mrt 2013, at 20:13, Tina TSOU = wrote: > Section 3, > When it mentions DS-Lite and MAP, I think a more complete picture = could be mentioned in the folloiwng way. Yes, this has the advantage of being more complete. However, because we discuss so many mechanisms in the document, we ended = up with more than 5 pages of references, which we feel would overwhelm = readers, especially ones less familiar with the IETF. So we've tried to limit references to only the most relevant ones. = Considering that, we believe that just the RFC 6333 reference for the = Softwire work, which is explicitly out of scope, is sufficient. Thanks, Iljitsch= From tjc@ecs.soton.ac.uk Wed Mar 20 03:44:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD2B21F84E7 for ; Wed, 20 Mar 2013 03:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_FOLLOW2=0.422] 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 JOCSmDR3RPzi for ; Wed, 20 Mar 2013 03:44:06 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 73CF521F856C for ; Wed, 20 Mar 2013 03:44:06 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r2KAhHAM032692; Wed, 20 Mar 2013 10:43:17 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r2KAhHAM032692 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1363776198; bh=TM/nQ/jtAdNfRzsWFmvJEVWTaE4=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=LImYWKpbGTQyoogyrXeZ7BJvRFg8n9Uy9OepAPhXAWgVn04/zGUB1sptgasQbOtAO +ndRFR+7aFHXwmigWID7pqTvXFVtl9wv9pOLZKXzAe2rEPkHgNvsoqySIu5wHbbid1 0e5BaAQLl3xCp3NYeFKzW7K4LZQx/hLlUypxJ5NI= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id p2JAhH0430633246n8 ret-id none; Wed, 20 Mar 2013 10:43:18 +0000 Received: from ip-204-252.eduroam.soton.ac.uk (ip-204-252.eduroam.soton.ac.uk [152.78.204.252]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r2KAhFdO027828 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Mar 2013 10:43:15 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Tim Chown In-Reply-To: <58E5D429-5037-48C9-91CB-07011EBB90C8@muada.com> Date: Wed, 20 Mar 2013 10:43:15 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> <58E5D429-5037-48C9-91CB-07011EBB90C8@muada.com> <3105197C-DFBF-4316-BC8A-1241E2483E41@ecs.soton.ac.uk> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1503) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p2JAhH043063324600; tid=p2JAhH0430633246n8; client=relay,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r2KAhHAM032692 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: IPv6 Ops WG , "draft-steffann-tunnels@tools.ietf.org" Subject: Re: [v6ops] draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 10:44:07 -0000 On 20 Mar 2013, at 10:36, Iljitsch van Beijnum = wrote: > Hi Tina, >=20 > On 19 mrt 2013, at 20:13, Tina TSOU = wrote: >=20 >> Section 3, >> When it mentions DS-Lite and MAP, I think a more complete picture = could be mentioned in the folloiwng way. >=20 > Yes, this has the advantage of being more complete. >=20 > However, because we discuss so many mechanisms in the document, we = ended up with more than 5 pages of references, which we feel would = overwhelm readers, especially ones less familiar with the IETF. >=20 > So we've tried to limit references to only the most relevant ones. = Considering that, we believe that just the RFC 6333 reference for the = Softwire work, which is explicitly out of scope, is sufficient. Hi, I think this is a great document - well done to the authors. =20 I agree the level of references is fine as is. Tim= From v6ops@globis.net Wed Mar 20 04:28:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E941321F85F3 for ; Wed, 20 Mar 2013 04:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncQ3EA5ip0Dn for ; Wed, 20 Mar 2013 04:28:00 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id CF41721F85CE for ; Wed, 20 Mar 2013 04:27:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E2B1A87010A; Wed, 20 Mar 2013 12:27:43 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUJhfyWZKjbL; Wed, 20 Mar 2013 12:27:26 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id B2718870106; Wed, 20 Mar 2013 12:27:26 +0100 (CET) Message-ID: <51499D18.8030005@globis.net> Date: Wed, 20 Mar 2013 12:27:20 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Tim Chown References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org Operations" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 11:28:01 -0000 Tim Chown wrote: > On 20 Mar 2013, at 08:48, Brian E Carpenter wrote: > >> On 20/03/2013 07:42, Tim Chown wrote: >>> On 19 Mar 2013, at 13:10, Ray Hunter wrote: >>> >>>> Fred Baker (fred) wrote: >>>>> In the meeting at IETF 86, we discussed >>>>> >>>>> http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis >>>>> http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis >>>>> "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang, >>>>> Cameron Byrne, 25-Feb-13 >>>>> >>>>> and the hum supported making that a working group draft. In this note, I'm asking for ratification on the list - whether you agree or disagree, I'd appreciate your thoughts. >>>> I have a problem with "BCP" status for any draft recommending use of ULA >>>> on Internet connected networks without some health warning, because I'm >>>> not yet convinced that this may not end up being harmful [highly mobile >>>> devices, split horizon, caching]. >>> Informational seems appropriate. >>> >>> While some of us have been using them in various contexts, unless we hear of widescale, significant deployments, it's difficult to argue for BCP. >> It depends. If the draft says "If you choose to use a ULA prefix, here >> are some guidelines on how to do it properly", BCP might be appropriate. >> However, an informational description of appropriate deployment scenarios >> would be quite OK. >> >> If it says "Use a ULA prefix!", I would certainly object to BCP. Agreed. Let's see how the draft evolves. > The homenet arch (which is Informational) is recommending use of ULAs. There are real use cases already identified there, particularly with constrained devices; one of the arch text authors is I believe already producing such things. Yes, and I commented on homenet that I thought this recommendation was still controversial. We should have a proper discussion, and not just use the fact it's currently included in one draft to justify including it in another. > The other arguments made include disconnected operation, I have no problem with this. But that is using ULA more like self-assigned addresses, which don't communicate with the Public Internet. > and internal connection persistence through ISP-traiggered renumbering events. Has this been operationally proven? Also, having witnessed problems/issues with highly mobile nodes crossing between "inside" and "outside" on corporate networks (admittedly mainly with IPv4), I'd like to know of real world IPv6 experience with split horizon operation and highly mobile devices using ULA. I know the theory, but do we know how all of these items are cached and used in practise? I know various bits of Windows and certain applications do an awful lot of work under the hood to implement "Network Location Awareness" e.g. whether they are "on net" or "off net", so that they know what NAT traversal/proxies/ firewall rules/ spilt DNS etc. to use: including detecting whether the node is a member of a AD domain, whether it is using RFC1918 addresses, whether certain FQDN's can be resolved, whether certain web sites can be reached, if it is connected to specific SSID name, downloading proxy pac files, printer reachability, address of DHCP server, gateway address...... (Incorrect) use of ULA might just make all of that gubbins necessary for IPv6 in every OS or application, which would be a shame. If you only ever use GUA, you don't need to make any choice. > A challenge is dealing with multiple internal routers that may generate a /48 ULA, including cases where such devices are initially not connected and are then joined/merged. In such cases devices in the homenet need to be aware of which ULA prefixes are internal to the home, and thus that should be preferred over GUAs for address selection. > > Tim One of the use cases Fred gave was two cooperating corporations with a "backdoor link" using disjoint /48 ULAs, which would also require policy changes from the default on both sets of hosts to prefer the other corporations' /48 ULA over their GUA. We don't yet have a fully standardised mechanism to distribute address selection policy, never mind one that has been widely implemented with extensive operational experience. [I know draft-ietf-6man-addr-select-opt-08] regards RayH From arturo.servin@gmail.com Wed Mar 20 04:49:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00C921F841C for ; Wed, 20 Mar 2013 04:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 j9yR3ji7Nv-B for ; Wed, 20 Mar 2013 04:49:04 -0700 (PDT) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBC621F8414 for ; Wed, 20 Mar 2013 04:49:04 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id q19so960902qeb.20 for ; Wed, 20 Mar 2013 04:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=u4AMz6iXKOv2LyT2kwh0eaRtxlkSw7cNW2/vmXTyiIs=; b=Dh+qHnUPiP297rmbXmDJqkp4RPMMlTwlxBM7fZE91iY+YVNud/rOI83YPweirRhvUB jeSY+h+PMZAaRu6woOQySbFS6qjuztAUaUmylDMG66sMvtdj8eZyJf+MEXU4uDYfpBL7 nCd0mNcPQkBfZ/Hr0y3UkpGsZzoLNvwrx7l+mENQpKFeVx9qglQhIy4q5oQYORBpGLwK ZKyUWjQDzAf/jLTR8UYY6yiwEvdns+WumqYGtHUlOpBEU1hjHq/+9/6QhFfo7tu1WOmc OlMcWAXfNjfxqE4NFpGfrYv9UficRinfPF/5Mm5/Ea7Q/tnlIHYg5Zm06c5GWBupQpSL VLrw== X-Received: by 10.224.17.193 with SMTP id t1mr5478259qaa.89.1363780143865; Wed, 20 Mar 2013 04:49:03 -0700 (PDT) Received: from [192.168.1.133] (r186-48-242-76.dialup.adsl.anteldata.net.uy. [186.48.242.76]) by mx.google.com with ESMTPS id he6sm49880007qab.1.2013.03.20.04.49.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Mar 2013 04:49:03 -0700 (PDT) Message-ID: <5149A22C.7080705@gmail.com> Date: Wed, 20 Mar 2013 08:49:00 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> In-Reply-To: <514977CF.9030806@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 11:49:06 -0000 On 20/03/2013 05:48, Brian E Carpenter wrote: > On 20/03/2013 07:42, Tim Chown wrote: >> On 19 Mar 2013, at 13:10, Ray Hunter wrote: >> >>> Fred Baker (fred) wrote: >>>> In the meeting at IETF 86, we discussed >>>> >>>> http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis >>>> http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis >>>> "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang, >>>> Cameron Byrne, 25-Feb-13 >>>> >>>> and the hum supported making that a working group draft. In this note, I'm asking for ratification on the list - whether you agree or disagree, I'd appreciate your thoughts. >>> I have a problem with "BCP" status for any draft recommending use of ULA >>> on Internet connected networks without some health warning, because I'm >>> not yet convinced that this may not end up being harmful [highly mobile >>> devices, split horizon, caching]. >> >> Informational seems appropriate. >> >> While some of us have been using them in various contexts, unless we hear of widescale, significant deployments, it's difficult to argue for BCP. > > It depends. If the draft says "If you choose to use a ULA prefix, here > are some guidelines on how to do it properly", BCP might be appropriate. > However, an informational description of appropriate deployment scenarios > would be quite OK. I agree, but we have so little experience with ULA deployment that these recommendations are far for being a BCP. In reality they are like "we think that this is the best way to use ULAs, but we don't really know because we haven't use it a lot." > > If it says "Use a ULA prefix!", I would certainly object to BCP. > > Brian /as From arturo.servin@gmail.com Wed Mar 20 05:01:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CDA21F8735 for ; Wed, 20 Mar 2013 05:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[AWL=-2.221, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_DIALUP=0.862, J_CHICKENPOX_13=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.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 wb+c682rgIc1 for ; Wed, 20 Mar 2013 05:01:23 -0700 (PDT) Received: from mail-vb0-x22b.google.com (mail-vb0-x22b.google.com [IPv6:2607:f8b0:400c:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7D77E21F8733 for ; Wed, 20 Mar 2013 05:01:23 -0700 (PDT) Received: by mail-vb0-f43.google.com with SMTP id fs19so1020105vbb.2 for ; Wed, 20 Mar 2013 05:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8xIgy/6f1ZscpKfdas6dCjVa0URCMLPNbSeYF2NF9v8=; b=09p3hoqEdxYNAyWOmMW16CPhxvCDSxiBuQyQ8NMdOXqpj57Ok6TqpPLTnduqNzz48Q 40UvvWHD+WcyHzMwzkEFBUzdz7UZi30gZaSplJB5d9EdLQZIg10tdFPRS+MWEcHKJeBF 3jcFiYVXrM2lcm8vnQUWxKItbSrCCAtgFXQsdprlKC9YTEqT42mqC8BL2gcPj8V0cMib HnXiKRpSq+cpbZeHYQzlCrvn5L5zG5QwBD0gYFfabMRO9wF8gOga84QaE7XMQrcieBxo 2mdaB6Ekp9Dq/33R0WBmSRC4yyUKCDNr8C0yVMa7zPhpv44OuIyLMy7dpdaAA5y99efI C+yg== X-Received: by 10.220.153.143 with SMTP id k15mr7332709vcw.33.1363780882915; Wed, 20 Mar 2013 05:01:22 -0700 (PDT) Received: from [192.168.1.133] (r186-48-242-76.dialup.adsl.anteldata.net.uy. [186.48.242.76]) by mx.google.com with ESMTPS id b9sm34527487vee.3.2013.03.20.05.01.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Mar 2013 05:01:21 -0700 (PDT) Message-ID: <5149A50E.50300@gmail.com> Date: Wed, 20 Mar 2013 09:01:18 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> In-Reply-To: <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 12:01:24 -0000 I haven't read it all but it looks like a great document. You mentioned that you are planning to do an independent submission (for the dates perhaps you have done it), however I would see a lot of value for v6ops if you change your mind. Regards, /as On 15/02/2013 06:44, Iljitsch van Beijnum wrote: > Hi all, > > Three of us were asked by the Dutch academic network Surfnet to write an overview of IPv6-in-IPv4 tunneling mechanisms. To benefit the wider community, we did so in the form of a draft, that we intend to submit to the RFC Editor as an independent submission. > > However, we would very much appreciate reviews and comments from within the IETF. These are the mechanisms we discuss: > > 3. Tunnel Mechanisms . . . . . . . . . . . . . . . . . . . . . . 5 > 3.1. Configured Tunnels (Manual Tunnels / 6in4) . . . . . . . . 6 > 3.2. Automatic Tunneling . . . . . . . . . . . . . . . . . . . 7 > 3.3. IPv6 over IPv4 without Explicit Tunnels (6over4) . . . . . 8 > 3.4. Generic Routing Encapsulation (GRE) . . . . . . . . . . . 9 > 3.5. Connection of IPv6 Domains via IPv4 Clouds (6to4) . . . . 9 > 3.6. Anything In Anything (AYIYA) . . . . . . . . . . . . . . . 10 > 3.7. Intra-site Automatic Tunnel Addressing (ISATAP) . . . . . 11 > 3.8. Tunneling IPv6 over UDP through NATs (Teredo) . . . . . . 12 > 3.9. IPv6 Rapid Deployment (6rd) . . . . . . . . . . . . . . . 13 > 3.10. Native IPv6 behind NAT44 CPEs (6a44) . . . . . . . . . . . 14 > 3.11. Peer-to-Peer IPv6 on Any Internetwork (6bed4) . . . . . . 15 > 3.12. The Locator/ID Separation Protocol (LISP) . . . . . . . . 16 > 4. Related Protocols . . . . . . . . . . . . . . . . . . . . . . 17 > 4.1. Tunnel Information and Control protocol (TIC) . . . . . . 17 > 4.2. Tunnel Setup Protocol (TSP) . . . . . . . . . . . . . . . 18 > 4.3. Dual-Stack Lite (Softwire) . . . . . . . . . . . . . . . . 19 > > Thanks! > > Iljitsch > > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Subject: I-D Action: draft-steffann-tunnels-00.txt >> Date: 15 februari 2013 9:34:07 CET >> To: i-d-announce@ietf.org >> Reply-To: internet-drafts@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : A comparison of IPv6 tunneling mechanisms >> Author(s) : S.J.M. Steffann >> Iljitsch van Beijnum >> Rick van Rein >> Filename : draft-steffann-tunnels-00.txt >> Pages : 37 >> Date : 2013-02-15 >> >> Abstract: >> This document provides an overview of various ways to to tunnel IPv6 >> packets over IPv4 networks. It covers mechanisms in contemporary >> use, touches on several mechanisms that are now only of historic >> interest, and discusses some newer tunneling mechanisms that are not >> (yet) widely used at the time of publication. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-steffann-tunnels >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-steffann-tunnels-00 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From tjc@ecs.soton.ac.uk Wed Mar 20 05:08:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D541221F8C0C for ; Wed, 20 Mar 2013 05:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, 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 3lXBjzgoxzvM for ; Wed, 20 Mar 2013 05:08:57 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 7B36821F8C09 for ; Wed, 20 Mar 2013 05:08:56 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r2KC8pxh028724 for ; Wed, 20 Mar 2013 12:08:51 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r2KC8pxh028724 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1363781332; bh=c36XfeYcT3y1BHPIS8qw1ztRl70=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=jXSMH+QF/4rmjlSVQT4MwhPnyl/Wd3eDtqnddZGbZBlm88isk8hR5gahP7AyorEHA +fezonKWmn3Wjz0ctBc5PJrgfQepH5YtnabI2Cv7KsoTYav8UOCbIerKZCQ+znb715 3GpZJac5SwYfezi88TRq8GZkydvNYuqqO7flAO+s= 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 p2JC8p0430634655KH ret-id none; Wed, 20 Mar 2013 12:08:51 +0000 Received: from ip-204-252.eduroam.soton.ac.uk (ip-204-252.eduroam.soton.ac.uk [152.78.204.252]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r2KC8nqw003128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 20 Mar 2013 12:08:50 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Tim Chown In-Reply-To: <51425EB5.6040703@dougbarton.us> Date: Wed, 20 Mar 2013 12:08:49 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <51425EB5.6040703@dougbarton.us> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> To: v6ops@ietf.org X-Mailer: Apple Mail (2.1503) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p2JC8p043063465500; tid=p2JC8p0430634655KH; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r2KC8pxh028724 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 12:08:58 -0000 On 14 Mar 2013, at 23:35, Doug Barton wrote: > On 03/14/2013 04:25 PM, Owen DeLong wrote: >> If both sites are using 10.0.0.0/8 in an overlapping manner, then = connecting them via routers does not yield goodness. >=20 > Of course, but that's not a technical difference between ULA and 1918. = As I pointed out in my reply to Victor, the distinction is that it's = less likely to happen with ULA, which is worth noting of course. Well, with ULAs you have *significantly* less chance of overlap. But = without ULA-C, which died a death, there is a possibility, however = small. What worries me is that in non-zeroconf environments, or those where = manual override is possible, administrators will use fc00::/48, as it's = easier to type/remember. Then you're back on a par with using = 10.0.0.0/8. Tim= From tjc@ecs.soton.ac.uk Wed Mar 20 05:22:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672C521F877B for ; Wed, 20 Mar 2013 05:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.106, 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 yuOGEyO15xTW for ; Wed, 20 Mar 2013 05:22:29 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 4C89E21F8767 for ; Wed, 20 Mar 2013 05:22:29 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r2KCMSCE032742 for ; Wed, 20 Mar 2013 12:22:28 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r2KCMSCE032742 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1363782148; bh=Hx6VGB9NzfLG2F7QiI45CnVm52c=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=laa6o5EeemWWDrOxs6XrbrB3huUlmi7+LBYq+JtIzDFIJQlEpxSZSYxUcYiQrxI0X qlTw9/nyn/mWZ2Pt6MSIKaxj6i/ZdxWUJV2VgLfieEidRGnvkToNuGCSW+HFNdtfsG TN2tYjI5srDDkfzNrMFToMh9UCEWAnfdTg0H/ks8= 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 p2JCMS0430634849j5 ret-id none; Wed, 20 Mar 2013 12:22:28 +0000 Received: from ip-204-252.eduroam.soton.ac.uk (ip-204-252.eduroam.soton.ac.uk [152.78.204.252]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r2KCMQJP009888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 20 Mar 2013 12:22:26 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Tim Chown In-Reply-To: <51499D18.8030005@globis.net> Date: Wed, 20 Mar 2013 12:22:26 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> To: "v6ops@ietf.org Operations" X-Mailer: Apple Mail (2.1503) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p2JCMS043063484900; tid=p2JCMS0430634849j5; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r2KCMSCE032742 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 12:22:30 -0000 On 20 Mar 2013, at 11:27, Ray Hunter wrote: > Tim Chown wrote: >>=20 >> The homenet arch (which is Informational) is recommending use of = ULAs. There are real use cases already identified there, particularly = with constrained devices; one of the arch text authors is I believe = already producing such things.=20 > Yes, and I commented on homenet that I thought this recommendation was > still controversial. >=20 > We should have a proper discussion, and not just use the fact it's > currently included in one draft to justify including it in another. The 'rough consensus' at the moment, as described at Orlando, is to = leave it in. If you feel it is contentious, perhaps start a new thread = on the homenet list explaining why. =20 >> The other arguments made include disconnected operation, > I have no problem with this. But that is using ULA more like > self-assigned addresses, which don't communicate with the Public = Internet. Well, that's what they are? There's no other address space available for = such contexts, is there? >> and internal connection persistence through ISP-traiggered = renumbering events. > Has this been operationally proven? It's worked here when we've tried it, but it would be interesting to = hear of any issues arising for anyone who has used it in real anger. > Also, having witnessed problems/issues with highly mobile nodes = crossing > between "inside" and "outside" on corporate networks (admittedly = mainly > with IPv4), I'd like to know of real world IPv6 experience with split > horizon operation and highly mobile devices using ULA. >=20 > I know the theory, but do we know how all of these items are cached = and > used in practise? I think this is why it is important that nodes both understand what site = they're in (which as someone else pointed out may be linked to the = 'provisioning domain' discussion of Orlando) and also which prefixes = (ULA or otherwise) are associated to those domains. Otherwise yes, you = could be selecting a ULA source for a remote, non-routable ULA = destination. > I know various bits of Windows and certain applications do an awful = lot > of work under the hood to implement "Network Location Awareness" e.g. > whether they are "on net" or "off net", so that they know what NAT > traversal/proxies/ firewall rules/ spilt DNS etc. to use: including > detecting whether the node is a member of a AD domain, whether it is > using RFC1918 addresses, whether certain FQDN's can be resolved, = whether > certain web sites can be reached, if it is connected to specific SSID > name, downloading proxy pac files, printer reachability, address of = DHCP > server, gateway address...=85 IPv6 should remove the 'behind NAT' to 'behind NAT' home to home issues = by using GUAs for such home to come connectivity. > (Incorrect) use of ULA might just make all of that gubbins necessary = for > IPv6 in every OS or application, which would be a shame. I think you have valid concerns, but the best way to discuss these is = via a draft/text where they are enumerated, be that = draft-liu-v6ops-ula-usage-analysis, or a homenet-specific new draft. = The existing draft doesn't really tackle these concerns. > If you only ever use GUA, you don't need to make any choice. Well, then you have different concerns about disconnected operation. >> A challenge is dealing with multiple internal routers that may = generate a /48 ULA, including cases where such devices are initially not = connected and are then joined/merged. In such cases devices in the = homenet need to be aware of which ULA prefixes are internal to the home, = and thus that should be preferred over GUAs for address selection. >>=20 >> Tim > One of the use cases Fred gave was two cooperating corporations with a > "backdoor link" using disjoint /48 ULAs, which would also require = policy > changes from the default on both sets of hosts to prefer the other > corporations' /48 ULA over their GUA. That may well be a broader issue. My particular interest is in trying = to edit and identify consensus for homenet. > We don't yet have a fully standardised mechanism to distribute address > selection policy, never mind one that has been widely implemented with > extensive operational experience. [I know > draft-ietf-6man-addr-select-opt-08] True, and that method is designed for managed enterprises, not homenets. = =20 Tim= From owen@delong.com Wed Mar 20 06:06:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A53221F8E30 for ; Wed, 20 Mar 2013 06:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpIvG9hQuos1 for ; Wed, 20 Mar 2013 06:06:02 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5020E21F84E3 for ; Wed, 20 Mar 2013 06:06:01 -0700 (PDT) Received: from [10.7.13.159] (97-64-168-70.client.mchsi.com [97.64.168.70]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2KD5iuf014786 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Mar 2013 06:05:45 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2KD5iuf014786 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363784745; bh=aF+DfslP+zb7aHBWrNLM9SkAdrs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=OmuiHVa0+7jkPI/yriEz/+E9OEhRDg0KMy5ycLbuIuZPPfxsWZODW4KmutvK7EXiu 7SkCA7Yg9fMP2R4fRcYS7kJLdb6Q4hc5CPr2KFipPE6o+9w8IsRMAsOp8sbDQr89Zi lBocyrEMuQ6/GykiGqx1RkaKAzLDKKOypCMLCl0c= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <5149A22C.7080705@gmail.com> Date: Wed, 20 Mar 2013 08:05:43 -0500 Content-Transfer-Encoding: 7bit Message-Id: <9C8C9502-725A-44AF-8AD9-A1CBB793AA7E@delong.com> References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <5149A22C.7080705@gmail.com> To: Arturo Servin X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 20 Mar 2013 06:05:45 -0700 (PDT) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 13:06:03 -0000 >> >> It depends. If the draft says "If you choose to use a ULA prefix, here >> are some guidelines on how to do it properly", BCP might be appropriate. >> However, an informational description of appropriate deployment scenarios >> would be quite OK. > > I agree, but we have so little experience with ULA deployment that > these recommendations are far for being a BCP. In reality they are like > "we think that this is the best way to use ULAs, but we don't really > know because we haven't use it a lot." > +1 Well said, Arturo. Personally, the more this discussion evolves, the more convinced I become that ULA is an ugly can of worms that is best when left unopened. Unfortunately, that ship has sailed. Owen From owen@delong.com Wed Mar 20 06:06:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC06E21F8F5D for ; Wed, 20 Mar 2013 06:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 vBs1OhDmPcmc for ; Wed, 20 Mar 2013 06:06:03 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A646221F8F31 for ; Wed, 20 Mar 2013 06:06:03 -0700 (PDT) Received: from [10.7.13.159] (97-64-168-70.client.mchsi.com [97.64.168.70]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2KD3MCQ014756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Mar 2013 06:03:24 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2KD3MCQ014756 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363784604; bh=g8fr7ytOj2n22OaJmyhtpB3sjys=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=fCIuKGFkO6O2z/IMEKEp6X6aTySzaqfPqy0SJpgxUeGRgDZaD25oHHS3qkGuM+eLm oP7CMQXx5T61AFtaDDZHARamjW50JETXWMFP6pM/VKtTEwsJ3H8y2r5NiY2OvwzFW4 1/3LhvosqW/rOLFh4dQTEahubuVV97xnYgG/Xsbg= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <51497E49.5080101@gmail.com> Date: Wed, 20 Mar 2013 08:03:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8F2B4F24-B759-4B81-A26D-3FF3D27700C3@delong.com> References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <51497E49.5080101@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 20 Mar 2013 06:03:24 -0700 (PDT) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 13:06:04 -0000 Currently, there is no defined use of L-bit =3D 0 to the best of my = knowledge. I believe that fc00::/8 sits "idle" as the IETF failed to designate a = registry structure and the ULA-registered draft expired without consensus. Owen On Mar 20, 2013, at 4:15 AM, Alexandru Petrescu = wrote: > Le 20/03/2013 09:48, Brian E Carpenter a =E9crit : >> On 20/03/2013 07:42, Tim Chown wrote: >>> On 19 Mar 2013, at 13:10, Ray Hunter wrote: >>>=20 >>>> Fred Baker (fred) wrote: >>>>> In the meeting at IETF 86, we discussed >>>>>=20 >>>>> http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis >>>>>=20 >>>>>=20 > http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis >>>>> "Guidance of Using Unique Local Addresses", Bing Liu, Sheng >>>>> Jiang, Cameron Byrne, 25-Feb-13 >>>>>=20 >>>>> and the hum supported making that a working group draft. In >>>>> this note, I'm asking for ratification on the list - whether >>>>> you agree or disagree, I'd appreciate your thoughts. >>>> I have a problem with "BCP" status for any draft recommending use >>>> of ULA on Internet connected networks without some health >>>> warning, because I'm not yet convinced that this may not end up >>>> being harmful [highly mobile devices, split horizon, caching]. >>>=20 >>> Informational seems appropriate. >>>=20 >>> While some of us have been using them in various contexts, unless >>> we hear of widescale, significant deployments, it's difficult to >>> argue for BCP. >>=20 >> It depends. If the draft says "If you choose to use a ULA prefix, >> here are some guidelines on how to do it properly", BCP might be >> appropriate. However, an informational description of appropriate >> deployment scenarios would be quite OK. >>=20 >> If it says "Use a ULA prefix!", I would certainly object to BCP. >=20 > I agree with both points. >=20 > We consider the ULAs for vehicular networks, although not sure yet > whether the current convenience we have on using them means we should = go > that way any further. >=20 > Typically one vehicle would be a 'site', yet vehicle-to-vehicle > communications would form another one. just a little larger such site. >=20 > This begs for the advice: is the Mobile Router (a router, or 'modem', = or > 'ECU', or Gateway) deployed in the vehicle making a strict separation > between the vehicle and the outside of the vehicle for these ULAs? > (i.e. dont forward ULA-addresses packets in-out of vehicle). Or is = that > separation done only when connecting to the fixed infrastructure (i.e. > to Internet, with a default route)? >=20 > Should we set the L bit (local/global). >=20 > Are alternative methods possible for seeting the Global ID possible? > (other than RFC4193, which suggests to rely on the time, EUI-64 and > SHA-1 - each having various constraints: where to get time in a = reliable > manner, which EUI-64 of those many in a vehicle, export control.) >=20 > Alex >=20 >>=20 >> Brian _______________________________________________ v6ops mailing >> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From owen@delong.com Wed Mar 20 06:22:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8250D21F8F13 for ; Wed, 20 Mar 2013 06:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Akeikyk7EcaL for ; Wed, 20 Mar 2013 06:22:22 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 55D6F21F8E2C for ; Wed, 20 Mar 2013 06:22:21 -0700 (PDT) Received: from [10.7.13.159] (97-64-168-70.client.mchsi.com [97.64.168.70]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2KDIDOw015190 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Mar 2013 06:18:15 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2KDIDOw015190 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363785495; bh=BL6gQ++nDKoNj2CyGAx81i+pqwk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=iSAsRDs8EMKoxH198IWZnfgc1bCAsaAkpHnqf7VdOCGityGYYoWmq+mYqBRCbPrlq dSeglS00YKwEOljdJJONlRWUSI4G2c8TdmG87Esvdjn/qcw6l+/hbOb2gsTQwx0Xdm tYHvvDtDB4m+wIgm/J4HZ5PC3noaSWX4BVCAx7Fw= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: Date: Wed, 20 Mar 2013 08:18:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 20 Mar 2013 06:18:15 -0700 (PDT) Cc: "v6ops@ietf.org Operations" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 13:22:23 -0000 On Mar 20, 2013, at 7:22 AM, Tim Chown wrote: > On 20 Mar 2013, at 11:27, Ray Hunter wrote: >=20 >> Tim Chown wrote: >>>=20 >>> The homenet arch (which is Informational) is recommending use of = ULAs. There are real use cases already identified there, particularly = with constrained devices; one of the arch text authors is I believe = already producing such things.=20 >> Yes, and I commented on homenet that I thought this recommendation = was >> still controversial. >>=20 >> We should have a proper discussion, and not just use the fact it's >> currently included in one draft to justify including it in another. >=20 > The 'rough consensus' at the moment, as described at Orlando, is to = leave it in. If you feel it is contentious, perhaps start a new thread = on the homenet list explaining why. =20 >=20 I'm not on home net, but I think it's a profoundly bad idea as well. >>> The other arguments made include disconnected operation, >> I have no problem with this. But that is using ULA more like >> self-assigned addresses, which don't communicate with the Public = Internet. >=20 > Well, that's what they are? There's no other address space available = for such contexts, is there? >=20 Yes, GUA is a perfectly fine choice of addressing for such contexts and = ULA offers no advantage over GUA other than avoiding RIR = interactions/fees. >>> and internal connection persistence through ISP-traiggered = renumbering events. >> Has this been operationally proven? >=20 > It's worked here when we've tried it, but it would be interesting to = hear of any issues arising for anyone who has used it in real anger. Please do not carry forward the problems of NAT traversal into IPv6. Some of us would like to see actual application innovation occur. Some of us are tired of paying the "NAT Tax" for everyone else that = isn't using globally unique numbering. >=20 >> Also, having witnessed problems/issues with highly mobile nodes = crossing >> between "inside" and "outside" on corporate networks (admittedly = mainly >> with IPv4), I'd like to know of real world IPv6 experience with split >> horizon operation and highly mobile devices using ULA. >>=20 >> I know the theory, but do we know how all of these items are cached = and >> used in practise? >=20 > I think this is why it is important that nodes both understand what = site they're in (which as someone else pointed out may be linked to the = 'provisioning domain' discussion of Orlando) and also which prefixes = (ULA or otherwise) are associated to those domains. Otherwise yes, you = could be selecting a ULA source for a remote, non-routable ULA = destination. This is asking an awful lot of nodes compared to what they are capable = of in this realm today. Doing so in a manner that does not break = existing implementations seems to be a rather daunting challenge at = best. >> I know various bits of Windows and certain applications do an awful = lot >> of work under the hood to implement "Network Location Awareness" e.g. >> whether they are "on net" or "off net", so that they know what NAT >> traversal/proxies/ firewall rules/ spilt DNS etc. to use: including >> detecting whether the node is a member of a AD domain, whether it is >> using RFC1918 addresses, whether certain FQDN's can be resolved, = whether >> certain web sites can be reached, if it is connected to specific SSID >> name, downloading proxy pac files, printer reachability, address of = DHCP >> server, gateway address...=85 >=20 > IPv6 should remove the 'behind NAT' to 'behind NAT' home to home = issues by using GUAs for such home to come connectivity. Agreed, but when you throw ULAs into the mix, especially if you throw = them in as a "BCP" or recommended way to do things, you either create a = bunch of new node requirements for addressing awareness and = source/destination address selection, or, you severely complicate other = areas and create the need for header rewriting by routers. Both of these = possibilities are somewhere between a small step and a giant leap into = the "down that path lies madness" zone IMHO. >> (Incorrect) use of ULA might just make all of that gubbins necessary = for >> IPv6 in every OS or application, which would be a shame. >=20 > I think you have valid concerns, but the best way to discuss these is = via a draft/text where they are enumerated, be that = draft-liu-v6ops-ula-usage-analysis, or a homenet-specific new draft. = The existing draft doesn't really tackle these concerns. Yes, but these concerns are a valid reason to delay, modify, or abandon = the existing draft. It is not valid to say "This draft doesn't address those concerns, go = write another draft" and then expect this draft to be adopted in spite = of the concerns. >> If you only ever use GUA, you don't need to make any choice. >=20 > Well, then you have different concerns about disconnected operation. >=20 How so? GUA is a perfectly fine alternative for disconnected operation. >>> A challenge is dealing with multiple internal routers that may = generate a /48 ULA, including cases where such devices are initially not = connected and are then joined/merged. In such cases devices in the = homenet need to be aware of which ULA prefixes are internal to the home, = and thus that should be preferred over GUAs for address selection. >>>=20 >>> Tim >> One of the use cases Fred gave was two cooperating corporations with = a >> "backdoor link" using disjoint /48 ULAs, which would also require = policy >> changes from the default on both sets of hosts to prefer the other >> corporations' /48 ULA over their GUA. >=20 > That may well be a broader issue. My particular interest is in trying = to edit and identify consensus for home net. My concern is making sure we don't break the internet by making NAT a = common feature in IPv6. I don't care whether it's homenet, enterprisenet, or backbonenet=85 If = we do stupid address tricks that naturally lead to NAT being a = convenient solution, we will recreate a number of problems that IPv6 was = intended to solve and regress the internet in a very bad way. Owen From arturo.servin@gmail.com Wed Mar 20 06:30:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523C921F84BE for ; Wed, 20 Mar 2013 06:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7YQTxzN46LG for ; Wed, 20 Mar 2013 06:30:04 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 69F5021F848D for ; Wed, 20 Mar 2013 06:30:04 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id va7so1604250obc.13 for ; Wed, 20 Mar 2013 06:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RfxmXN2Dq6asK9vOeoXIMgNXfE/yZlg7ou8zBh0RVQc=; b=WjhbYyGjobkyeteR6JlDvD/0euePQxu7RXos5k7Ihi8t6qlh54JyQRPXzP3MHW3Go9 rKbvx9IsQoXv01cHC7eAjvvzUcjdOy9G1Zt563qhQUSm35VzQgSK1nv/+KTuS8t3t7f+ zHa3q/9SDAZC6jvDkkHg2TwXBa80Lujx4/jpVA+OfOgDe2sVaZv48rOGBJk2fGs6LHbQ 9bWdEcccUpfs++suBlAcg/zywo7uanRCdK/6YvuwGa8FlprgAZLy4BZQO2eHKW2+vH7k ElN1ROQ6gOR3TFDYIT1ZcTvLMWuikQ8UAX7JquYqWh8Na6Qk6TJfE6H3Eaiao7wTJ2yN z74w== X-Received: by 10.182.190.19 with SMTP id gm19mr4013538obc.34.1363786203943; Wed, 20 Mar 2013 06:30:03 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy ([2001:13c7:7001:5128:ed04:56f9:69f7:9174]) by mx.google.com with ESMTPS id v8sm1839395oea.4.2013.03.20.06.30.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Mar 2013 06:30:03 -0700 (PDT) Message-ID: <5149B9DD.5030108@gmail.com> Date: Wed, 20 Mar 2013 10:30:05 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Owen DeLong References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <5149A22C.7080705@gmail.com> <9C8C9502-725A-44AF-8AD9-A1CBB793AA7E@delong.com> In-Reply-To: <9C8C9502-725A-44AF-8AD9-A1CBB793AA7E@delong.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 13:30:06 -0000 They have some real uses but in very specific scenarios with specif constrains like in homenet and DC with IPv6: http://tools.ietf.org/html/draft-ietf-homenet-arch-07#section-2.4 http://tools.ietf.org/html/draft-lopez-v6ops-dc-ipv6-04#section-3.1 And even there, it may be questionable. /as On 3/20/13 10:05 AM, Owen DeLong wrote: >>> >>> It depends. If the draft says "If you choose to use a ULA prefix, here >>> are some guidelines on how to do it properly", BCP might be appropriate. >>> However, an informational description of appropriate deployment scenarios >>> would be quite OK. >> >> I agree, but we have so little experience with ULA deployment that >> these recommendations are far for being a BCP. In reality they are like >> "we think that this is the best way to use ULAs, but we don't really >> know because we haven't use it a lot." >> > > +1 > > Well said, Arturo. Personally, the more this discussion evolves, the more > convinced I become that ULA is an ugly can of worms that is best when left > unopened. > > Unfortunately, that ship has sailed. > > Owen > From alexandru.petrescu@gmail.com Wed Mar 20 07:23:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6A721F84E2 for ; Wed, 20 Mar 2013 07:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.869 X-Spam-Level: X-Spam-Status: No, score=-10.869 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TY0SY6W5u+FD for ; Wed, 20 Mar 2013 07:23:45 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id E567D21F84B9 for ; Wed, 20 Mar 2013 07:23:44 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2KENi59017167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 20 Mar 2013 15:23:44 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2KENhZD006796 for ; Wed, 20 Mar 2013 15:23:43 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2KENdbr017808 for ; Wed, 20 Mar 2013 15:23:43 +0100 Message-ID: <5149C642.6060806@gmail.com> Date: Wed, 20 Mar 2013 15:22:58 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 14:23:45 -0000 Le 20/03/2013 14:18, Owen DeLong a écrit : [...] >> Well, then you have different concerns about disconnected >> operation. >> > > How so? GUA is a perfectly fine alternative for disconnected > operation. YEs and no. GUA (Global Unicast Addresses) is a good temptation to be used in all cases, even in disconnected operation. But, one should consider the cases of re-connection of moving networks at different places in the Internet, successively. In these cases there may be a risk, because a GUA is valid only at one topological place. Moving elsewhere one should use a different GUA. Should we allow two vehicles which have GUAs and meet each other to talk to each other directly? At that point would topological correctness still be respected with respect to ingress filtering? (what if one of the vehicles _is_ connected to the Internet). (I am not saying that ULA completely solves this, but that the use of GUA in disconnected operation may be a less tempting invitation). Alex > >>>> A challenge is dealing with multiple internal routers that may >>>> generate a /48 ULA, including cases where such devices are >>>> initially not connected and are then joined/merged. In such >>>> cases devices in the homenet need to be aware of which ULA >>>> prefixes are internal to the home, and thus that should be >>>> preferred over GUAs for address selection. >>>> >>>> Tim >>> One of the use cases Fred gave was two cooperating corporations >>> with a "backdoor link" using disjoint /48 ULAs, which would also >>> require policy changes from the default on both sets of hosts to >>> prefer the other corporations' /48 ULA over their GUA. >> >> That may well be a broader issue. My particular interest is in >> trying to edit and identify consensus for home net. > > My concern is making sure we don't break the internet by making NAT > a common feature in IPv6. > > I don't care whether it's homenet, enterprisenet, or backbonenet… If > we do stupid address tricks that naturally lead to NAT being a > convenient solution, we will recreate a number of problems that IPv6 > was intended to solve and regress the internet in a very bad way. > > Owen > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From tjc@ecs.soton.ac.uk Wed Mar 20 07:25:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AEF21F8FD8 for ; Wed, 20 Mar 2013 07:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 f1BNcXrHkkCE for ; Wed, 20 Mar 2013 07:25:34 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECE821F8FD0 for ; Wed, 20 Mar 2013 07:25:29 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r2KEPRMQ005168 for ; Wed, 20 Mar 2013 14:25:27 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r2KEPRMQ005168 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1363789527; bh=hav97uoBoxiXqItGVqswNIZD/5c=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=ZHSkOXInJmDBlclrPWJOuk9ItfqUTEwSYK5covsyjMC4i/7R+Oq1P2z08k4Fb6PxV 2NAVuh4TSldj2FRZXEdJmP5pgGTLYqTbNKDeb5wAIrt7t7hEX4A/2/BHZFM08t4EMA U7yY9RaGDFfQzbMUbZZY6mDjd1BCMV+ZIBZXqHzU= 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 p2JEPR0430636591mR ret-id none; Wed, 20 Mar 2013 14:25:27 +0000 Received: from dhcp-152-78-95-196.ecs.soton.ac.uk (dhcp-152-78-95-196.ecs.soton.ac.uk [152.78.95.196]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r2KEPO3T032475 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 20 Mar 2013 14:25:24 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Tim Chown In-Reply-To: Date: Wed, 20 Mar 2013 14:25:24 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <679BD726-685D-4D5E-8098-0E8F5DFDDB3A@ecs.soton.ac.uk> To: "v6ops@ietf.org Operations" X-Mailer: Apple Mail (2.1503) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p2JEPR043063659100; tid=p2JEPR0430636591mR; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r2KEPRMQ005168 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 14:25:35 -0000 On 20 Mar 2013, at 13:18, Owen DeLong wrote: >=20 > On Mar 20, 2013, at 7:22 AM, Tim Chown wrote: >=20 >> On 20 Mar 2013, at 11:27, Ray Hunter wrote: >>=20 >>> Tim Chown wrote: >>>>=20 >>>> The homenet arch (which is Informational) is recommending use of = ULAs. There are real use cases already identified there, particularly = with constrained devices; one of the arch text authors is I believe = already producing such things.=20 >>> Yes, and I commented on homenet that I thought this recommendation = was >>> still controversial. >>>=20 >>> We should have a proper discussion, and not just use the fact it's >>> currently included in one draft to justify including it in another. >>=20 >> The 'rough consensus' at the moment, as described at Orlando, is to = leave it in. If you feel it is contentious, perhaps start a new thread = on the homenet list explaining why. =20 >>=20 >=20 > I'm not on home net, but I think it's a profoundly bad idea as well. I suggest you contribute specific reasons to either this analysis draft = (which seems a bit short on that aspect at the moment, given it is an = analysis text), or write a new focused draft on the issues. That would = be very helpful. >>>> The other arguments made include disconnected operation, >>> I have no problem with this. But that is using ULA more like >>> self-assigned addresses, which don't communicate with the Public = Internet. >>=20 >> Well, that's what they are? There's no other address space available = for such contexts, is there? >>=20 >=20 > Yes, GUA is a perfectly fine choice of addressing for such contexts = and ULA offers no advantage over GUA other than avoiding RIR = interactions/fees. So how do I get a GUA if I have no relationship with an ISP? What should those installing constrained networks do, when devices may = only have an address configured on installation? >>>> and internal connection persistence through ISP-traiggered = renumbering events. >>> Has this been operationally proven? >>=20 >> It's worked here when we've tried it, but it would be interesting to = hear of any issues arising for anyone who has used it in real anger. >=20 > Please do not carry forward the problems of NAT traversal into IPv6. >=20 > Some of us would like to see actual application innovation occur. >=20 > Some of us are tired of paying the "NAT Tax" for everyone else that = isn't using globally unique numbering. ULAs in homenet have nothing to do with NAT. >>> Also, having witnessed problems/issues with highly mobile nodes = crossing >>> between "inside" and "outside" on corporate networks (admittedly = mainly >>> with IPv4), I'd like to know of real world IPv6 experience with = split >>> horizon operation and highly mobile devices using ULA. >>>=20 >>> I know the theory, but do we know how all of these items are cached = and >>> used in practise? >>=20 >> I think this is why it is important that nodes both understand what = site they're in (which as someone else pointed out may be linked to the = 'provisioning domain' discussion of Orlando) and also which prefixes = (ULA or otherwise) are associated to those domains. Otherwise yes, you = could be selecting a ULA source for a remote, non-routable ULA = destination. >=20 > This is asking an awful lot of nodes compared to what they are capable = of in this realm today. Doing so in a manner that does not break = existing implementations seems to be a rather daunting challenge at = best. True, but I think we'll see ULAs in use in homenets regardless, due to = the LLN type scenarios (see above). >>> I know various bits of Windows and certain applications do an awful = lot >>> of work under the hood to implement "Network Location Awareness" = e.g. >>> whether they are "on net" or "off net", so that they know what NAT >>> traversal/proxies/ firewall rules/ spilt DNS etc. to use: including >>> detecting whether the node is a member of a AD domain, whether it is >>> using RFC1918 addresses, whether certain FQDN's can be resolved, = whether >>> certain web sites can be reached, if it is connected to specific = SSID >>> name, downloading proxy pac files, printer reachability, address of = DHCP >>> server, gateway address...=85 >>=20 >> IPv6 should remove the 'behind NAT' to 'behind NAT' home to home = issues by using GUAs for such home to come connectivity. >=20 > Agreed, but when you throw ULAs into the mix, especially if you throw = them in as a "BCP" or recommended way to do things, you either create a = bunch of new node requirements for addressing awareness and = source/destination address selection, or, you severely complicate other = areas and create the need for header rewriting by routers. Both of these = possibilities are somewhere between a small step and a giant leap into = the "down that path lies madness" zone IMHO. So there needs to be a text that describes very clearly how use of ULAs = can be avoided, given the types of issues mentioned above. Now would be = a very timely point to write that up. >>> (Incorrect) use of ULA might just make all of that gubbins necessary = for >>> IPv6 in every OS or application, which would be a shame. >>=20 >> I think you have valid concerns, but the best way to discuss these is = via a draft/text where they are enumerated, be that = draft-liu-v6ops-ula-usage-analysis, or a homenet-specific new draft. = The existing draft doesn't really tackle these concerns. >=20 > Yes, but these concerns are a valid reason to delay, modify, or = abandon the existing draft. >=20 > It is not valid to say "This draft doesn't address those concerns, go = write another draft" and then expect this draft to be adopted in spite = of the concerns. Well, let me say that I would like to see your, and Ray's concerned = properly documented, where they can be discussion points rather than = comments buried in a very long email thread. Where that happens, I = personally don't mind. Given the current ula-usage-analysis text is = there, adding counterpoints in what is, after all, called an analysis = draft, would imo be welcome. >>> If you only ever use GUA, you don't need to make any choice. >>=20 >> Well, then you have different concerns about disconnected operation. >=20 > How so? GUA is a perfectly fine alternative for disconnected = operation. How is (non) expiry of the prefix handled, etc? >>>> A challenge is dealing with multiple internal routers that may = generate a /48 ULA, including cases where such devices are initially not = connected and are then joined/merged. In such cases devices in the = homenet need to be aware of which ULA prefixes are internal to the home, = and thus that should be preferred over GUAs for address selection. >>>>=20 >>>> Tim >>> One of the use cases Fred gave was two cooperating corporations with = a >>> "backdoor link" using disjoint /48 ULAs, which would also require = policy >>> changes from the default on both sets of hosts to prefer the other >>> corporations' /48 ULA over their GUA. >>=20 >> That may well be a broader issue. My particular interest is in = trying to edit and identify consensus for home net. >=20 > My concern is making sure we don't break the internet by making NAT a = common feature in IPv6. >=20 > I don't care whether it's homenet, enterprisenet, or backbonenet=85 If = we do stupid address tricks that naturally lead to NAT being a = convenient solution, we will recreate a number of problems that IPv6 was = intended to solve and regress the internet in a very bad way. Again, homenet use of ULAs has nothing to do with NAT. The complexity, I = think, is ensuring devices understand which ULA prefix(es) are local to = the homenet. GUAs are used for external communications. Tim= From brian.e.carpenter@gmail.com Wed Mar 20 08:22:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FA621F8FE9 for ; Wed, 20 Mar 2013 08:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.317 X-Spam-Level: X-Spam-Status: No, score=-99.317 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 9c6LSO3AHDMA for ; Wed, 20 Mar 2013 08:22:58 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id BC49021F8FE6 for ; Wed, 20 Mar 2013 08:22:57 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id t57so1520377wey.27 for ; Wed, 20 Mar 2013 08:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HSt9Jxdeu+jqIhhKWVtxSqipntziryjcOWXebCHlXBI=; b=GYLJVpQJUX9fMALdba+ZRxdSKm1JMATDFrvrzfpBNe840+8S0W9YK6kReDci533iu2 vpgOihD9Y7ROLLcll7icEg47DvdelHZpv+gclVON82Hfpfrhgs98mS52aZIuTJ3jA+hg b9M7GRSuEJIyLSRhj28WiV+56X2lSTDq/UfzRmOBpKbZ5S0WVgwcv7UQ57l5Xsn96OeC 3Xzk3fwEHkMKfKcT9lRSb4DmfueU2o3n1tReLHs1DkW4ScsKeh6UKfNDkn49stajalKj +LfsJLPs5AQ/v2LD/Zr4IDXIECLfYPCi5xrnPvkYMGAxgsvbp7W3lXoxvxSt8yUEVcgC SAlw== X-Received: by 10.194.122.131 with SMTP id ls3mr11298115wjb.55.1363792971599; Wed, 20 Mar 2013 08:22:51 -0700 (PDT) Received: from [192.168.1.64] (host-2-102-218-109.as13285.net. [2.102.218.109]) by mx.google.com with ESMTPS id gl11sm2341316wic.8.2013.03.20.08.22.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Mar 2013 08:22:50 -0700 (PDT) Message-ID: <5149D452.8020209@gmail.com> Date: Wed, 20 Mar 2013 15:22:58 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Owen DeLong References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org Operations" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 15:22:58 -0000 On 20/03/2013 13:18, Owen DeLong wrote: ... > > Yes, GUA is a perfectly fine choice of addressing for such contexts and ULA offers no advantage over GUA other than avoiding RIR interactions/fees. I think that may prove to be a significant advantage when applied, say, to 5 billion home networks that don't want to be beholden to an incumbent telco. But that is better argued in homenet. Brian From tjc@ecs.soton.ac.uk Wed Mar 20 08:27:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF1721F8FE3 for ; Wed, 20 Mar 2013 08:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 hghTjHfJ463q for ; Wed, 20 Mar 2013 08:27:11 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 501C121F8FDC for ; Wed, 20 Mar 2013 08:26:59 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r2KFQtFU025256 for ; Wed, 20 Mar 2013 15:26:55 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r2KFQtFU025256 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1363793215; bh=0lkfY6kW0e2oxshMRcs92y85Rsw=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=XmWzJe7xDP7DfU9EFpXDUEn4AgXkECRnRGVhjnBcsuiK+7AYbb6a4BmDYVSutCtA0 d3mQotn7K7mUxeAA5IXoSJE63xcqdsTX/vmVGXEkwxVbqmNgnxs5N/sz2kTWHtI9wb hPL+WRp0W65hYSIyYS/903Q6TiK+svm/KWkHmMgg= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id p2JFQy043063763125 ret-id none; Wed, 20 Mar 2013 15:26:55 +0000 Received: from dhcp-152-78-95-196.ecs.soton.ac.uk (dhcp-152-78-95-196.ecs.soton.ac.uk [152.78.95.196]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r2KFQqg8029549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 20 Mar 2013 15:26:52 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Tim Chown In-Reply-To: <5149D452.8020209@gmail.com> Date: Wed, 20 Mar 2013 15:26:52 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149D452.8020209@gmail.com> To: "v6ops@ietf.org Operations" X-Mailer: Apple Mail (2.1503) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p2JFQy043063763100; tid=p2JFQy043063763125; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r2KFQtFU025256 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 15:27:15 -0000 On 20 Mar 2013, at 15:22, Brian E Carpenter = wrote > On 20/03/2013 13:18, Owen DeLong wrote: > ... >>=20 >> Yes, GUA is a perfectly fine choice of addressing for such contexts = and ULA offers no advantage over GUA other than avoiding RIR = interactions/fees. >=20 > I think that may prove to be a significant advantage when applied, = say, to 5 billion > home networks that don't want to be beholden to an incumbent telco. = But that is better > argued in homenet. The homenet arch text states that it assumes homenets would never = receive PI, so the RIR interactions/fees are purely to the homenet = provider/ISP, as part of its own allocation. ULA-C would be a different thing. But is currently in cryo-freeze and = the key thrown away. Tim= From lorenzo@google.com Wed Mar 20 08:55:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6579121F8FE8 for ; Wed, 20 Mar 2013 08:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.975 X-Spam-Level: X-Spam-Status: No, score=-102.975 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, 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 hGaEoSexXWHX for ; Wed, 20 Mar 2013 08:55:15 -0700 (PDT) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id D967321F8FD8 for ; Wed, 20 Mar 2013 08:55:14 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id k14so1913251oag.39 for ; Wed, 20 Mar 2013 08:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=beddFMDk0E7+V3BrFAdjcHdsywcbYMg4zCrP2RMYRxI=; b=OwMVCgKiKn4PRokui2bcpfE2JcWtzduI2KZ9WX1xmZglQuJlRnwRpgNk5OSVKuZrLq DWYBmgmZWRZmohLHuSXpBF+wa2Ryj783IneaoUEDzlaovPW+jxeJ1nk93gc1rAAMlAKU qdcDmJICbTPxVyuT9FmR0766/2d+O7/Mk7L6Gq3LBSAiNmbR+tJk0fzkV3ec0XpUG6qN Q5xNntETYusFlS2ExLqyImMvC82EFKkM2Qo0HT/VW+oI7j10+e0zK65MZ1gFVNcx+cfJ ts44j+EdluAIXKzmCieXin/6OE4HT9tkGKdUJxVeaN22wJh9DSGGGyghwwUsot2cIjkN dO9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=beddFMDk0E7+V3BrFAdjcHdsywcbYMg4zCrP2RMYRxI=; b=kvnqzjy2dgROJuWr58b36TF6iI8Bxc2FcD9aPGLeBGcLVjk+0LGbbeQkbyUa+khsed uYRjck/6akalmOpktCZWIlLQKPQ01e89T3WHHxXDUAk8OBbPU7AByZXF9/IeGHRIHaGU hLPbn8DSaDWpJyH/yFiLa4GTCpI406+jEBMrWdFS2fJW6Qrro3ef4cNLC/SWALw9YVpq UcYdHnAfwrd5l7m7fny741qXSfSkO3kfHRVwz41FiyvjCaX2Se/sR5zySEoXvxGO0PYi TK9bhy3x4PrEjNHiCLrpMXrOhYIJyvV5ILJqZYZAkjmpewiHnjiGZso9CWKl7bE+bi2T LSMg== X-Received: by 10.182.132.43 with SMTP id or11mr4394891obb.67.1363794914324; Wed, 20 Mar 2013 08:55:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Wed, 20 Mar 2013 08:54:54 -0700 (PDT) In-Reply-To: References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> From: Lorenzo Colitti Date: Wed, 20 Mar 2013 08:54:54 -0700 Message-ID: To: Tim Chown Content-Type: multipart/alternative; boundary=14dae93a0c176aa7f904d85d3fdc X-Gm-Message-State: ALoCoQk1vJLC+Md+afkugZcM5K3kFusBIX42gA3loql2DltLvCDPn81wxX75w+OTei6oeVXgxZJ/paHVMop9Cr2SJnXf5JYN3C1xN8BZuv3NNAc4naHotQmI47BAcwgaAaZrpb3aQ7AxsYQpVDnqB79YtJhEj89zHunz4f2c5MFIALnv5QV3YYN3OIpwCsDXmncKpSfGzx4/ Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 15:55:15 -0000 --14dae93a0c176aa7f904d85d3fdc Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 20, 2013 at 5:08 AM, Tim Chown wrote: > What worries me is that in non-zeroconf environments, or those where > manual override is possible, administrators will use fc00::/48, as it's > easier to type/remember. Then you're back on a par with using 10.0.0.0/8. > But the unfortunate truth is that, really, ULA is no different from 10/8. I see only one difference between ULA and 10/8. That difference is *not* that ULAs are unique, because as you correctly note above, there is no hope of them actually being unique in the real world. The difference is that in IPv6 you are expected to use multiple addresses at the same time, and that you can use ULA *and* something else. --14dae93a0c176aa7f904d85d3fdc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 20, 2013 at 5:08 AM, Tim Chown <tjc@ecs.sot= on.ac.uk> wrote:
What worries me is that in non-zeroconf environments, or those wh= ere manual override is possible, administrators will use fc00::/48, as it&#= 39;s easier to type/remember. =A0Then you're back on a par with using <= /span>10.0.0.0/8.

But the unfortunate truth is that, r= eally, ULA is no different from 10/8.

= I see only one difference between ULA and 10/8. That difference is *not* th= at ULAs are unique, because as you correctly note above, there is no hope o= f them actually being unique in the real world. The difference is that in I= Pv6 you are expected to use multiple addresses at the same time, and that y= ou can use ULA *and* something else.
--14dae93a0c176aa7f904d85d3fdc-- From swmike@swm.pp.se Wed Mar 20 09:28:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F8821F8C7D for ; Wed, 20 Mar 2013 09:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 Ixv-PKC9ESI7 for ; Wed, 20 Mar 2013 09:28:09 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE5521F8CFA for ; Wed, 20 Mar 2013 09:28:07 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5BA11A0; Wed, 20 Mar 2013 17:28:06 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 556079E for ; Wed, 20 Mar 2013 17:28:06 +0100 (CET) Date: Wed, 20 Mar 2013 17:28:06 +0100 (CET) From: Mikael Abrahamsson To: "v6ops@ietf.org WG" In-Reply-To: Message-ID: References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 16:28:11 -0000 On Wed, 20 Mar 2013, Lorenzo Colitti wrote: > IPv6 you are expected to use multiple addresses at the same time, and > that you can use ULA *and* something else. It is my understanding that if a host sees RAs with A bit set, and the on-link prefix is ULA, it will install a default route towards the RA-announcing router. This for me makes ULA a no-go. I never want to use ULA to access GUA address space. Since the address and routing tables weren't logically separated from initial IPv6 design (I would like a separate routing table per IPv6 address), I don't see how the deployment case of having LL+ULA for IPv6 and whatever for IPv4 doesn't negatively impact the users Internet experience? What am I missing? RFC5220 2.2.2 talks about this and changing the policy table, but I don't see how this is done in hosts today without manual user intervention? Shouldn't draft-liu-v6ops-ula-usage-analysis analyse LL+ULA+IPv4 usage for Internet connectivity? -- Mikael Abrahamsson email: swmike@swm.pp.se From iljitsch@muada.com Wed Mar 20 09:28:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0C921F8C7D for ; Wed, 20 Mar 2013 09:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsGMJEj-u8G5 for ; Wed, 20 Mar 2013 09:28:35 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id D1B0E21F902E for ; Wed, 20 Mar 2013 09:28:32 -0700 (PDT) Received: from [IPv6:2001:470:1f0b:1289:78f4:dc83:7ac2:f79c] ([IPv6:2001:470:1f0b:1289:78f4:dc83:7ac2:f79c]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2KGNVSb062676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Mar 2013 17:23:32 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <5149A50E.50300@gmail.com> Date: Wed, 20 Mar 2013 17:28:26 +0100 Content-Transfer-Encoding: 7bit Message-Id: <07CC1B32-89A4-4627-B9BF-6DD934B46C9D@muada.com> References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> <5149A50E.50300@gmail.com> To: Arturo Servin X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 16:28:36 -0000 On 20 mrt 2013, at 13:01, Arturo Servin wrote: > I haven't read it all but it looks like a great document. Thanks. (And Tim, too.) > You mentioned that you are planning to do an independent submission > (for the dates perhaps you have done it), however I would see a lot of > value for v6ops if you change your mind. What would be the benefit of publication as an IETF document? Iljitsch From brian.e.carpenter@gmail.com Wed Mar 20 09:46:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D755321F8C7D for ; Wed, 20 Mar 2013 09:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.967 X-Spam-Level: X-Spam-Status: No, score=-98.967 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, J_CHICKENPOX_23=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 dAKhHcK7hjZN for ; Wed, 20 Mar 2013 09:46:08 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 753B021F8C0C for ; Wed, 20 Mar 2013 09:46:08 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id c10so197137wiw.14 for ; Wed, 20 Mar 2013 09:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TbtO2v6pBQcUyTrjQpvcDoS6vg11Ma4giHnQblI11QY=; b=UYn1cQg4OWnjtsbotONy2hE1UZAyrMiHQiPj5ikNwWJjDxh40oLC0NENDnz92exVOI Ezn9Nlp0TYmhDrzVsU0bsHJN0UYrOkhm1J6XAJBpKl/9PEnbZpbZRBe+p+d+kq0FNIY2 K/ZSAT3WN7fAaJAX41ORePfUscGQXGZ0PSpSP62n9CCpIYsrk3hbEq7mwNXjkJPjfTHD 6K8Yc4Xq+b9vUo5KcibgnDqYxjiT+BMa+rcknt1Fc3InnMGAh9fgy8mNfvZWMvcmMpfW eqgI7gTOj0Q3XRR39ODcKo+4QaxAwWJNHuL3camaHS+8yVKMOnsCKZZ0lOT63F4oGD5A x7rw== X-Received: by 10.194.7.131 with SMTP id j3mr11855625wja.23.1363797967580; Wed, 20 Mar 2013 09:46:07 -0700 (PDT) Received: from [192.168.1.64] (host-2-102-218-109.as13285.net. [2.102.218.109]) by mx.google.com with ESMTPS id c15sm4288060wiw.3.2013.03.20.09.46.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Mar 2013 09:46:06 -0700 (PDT) Message-ID: <5149E7D7.8010508@gmail.com> Date: Wed, 20 Mar 2013 16:46:15 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mikael Abrahamsson References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 16:46:09 -0000 On 20/03/2013 16:28, Mikael Abrahamsson wrote: > On Wed, 20 Mar 2013, Lorenzo Colitti wrote: > >> IPv6 you are expected to use multiple addresses at the same time, and >> that you can use ULA *and* something else. > > It is my understanding that if a host sees RAs with A bit set, and the > on-link prefix is ULA, it will install a default route towards the > RA-announcing router. If there's only one prefix on a LAN and that is a ULA prefix, you can't reach the outside world anyway (unless there's an NPTv6 box), so what's the problem? If there *is* an NPTv6 box, you want a default route towards it, so what's the problem? If there is also a GUA prefix, that's the one you want the default route for, and source address selection should take care of the rest, so what's the problem? Brian > This for me makes ULA a no-go. I never want to use ULA to access GUA > address space. Since the address and routing tables weren't logically > separated from initial IPv6 design (I would like a separate routing > table per IPv6 address), I don't see how the deployment case of having > LL+ULA for IPv6 and whatever for IPv4 doesn't negatively impact the > users Internet experience? > > What am I missing? RFC5220 2.2.2 talks about this and changing the > policy table, but I don't see how this is done in hosts today without > manual user intervention? Shouldn't draft-liu-v6ops-ula-usage-analysis > analyse LL+ULA+IPv4 usage for Internet connectivity? > From lorenzo@google.com Wed Mar 20 09:50:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7846121F88CF for ; Wed, 20 Mar 2013 09:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 VTPEQEZlZo4Z for ; Wed, 20 Mar 2013 09:50:03 -0700 (PDT) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id CA87121F8873 for ; Wed, 20 Mar 2013 09:50:03 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id i10so2057314oag.0 for ; Wed, 20 Mar 2013 09:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=92/R8yx+Dr0ZidkonM+vmIDMLu7GB9kxaX+7okMbD7Y=; b=g1ncDCOe7DsffWsKNxvKvDqaXOFr6lLHIXuiGg8UPnxfrBsl05TniqMVNhRSONP1w6 AjcLnxJX/YgTl/HvnpNA3hf/9k/uBTpXOhitOcS0yVT7SNiuMOc86514Hh0pLVHMUHkk O9kc9TO43mc+DMH8OPUaxmOu8FryzacXNWL4bEhpm2Bbdcfg1GhIh3WQdI2qNwOSlKPP 2nbYgrKVSuAS7hvmtstuyVL60/ZjiLXaIvO6NqstiA8GtbXtjxVhIaI7rRS4QxQikdIL oIR+0Sz4hO1TXgmOLbTWEOTK+AO/w0hhnt9PxIU5UmZqHr0v3uYmSv8NFtwsvmg1Yish Ms2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=92/R8yx+Dr0ZidkonM+vmIDMLu7GB9kxaX+7okMbD7Y=; b=a4c0lNnta1bKmV5ABB1l3P9lDifv/BRHiLc0CZVVDILteHGZIKG3whVO/1k1yohYT+ GsF2o/Zr8m8jwCo5JzkOqqBIz6AFypXE0lT9iHms29k9IgaTgEbouWVHnWSlDcxxKVcb 3HbhhV4SOa+g61WrQ3OjT9hB5izs65Eg5insBR/s52sv+dshOWdId+YozCddjoYNK9su bCK8ug7IJhVdDP4GnrH2Qaz1iqD9zoxRfQ5pmZR9tSl+13NWBVlnLkmvaG9XGPvY+fLi O3YCb3EqCVbsN92aqd+IlXiwTY5Z0QHUHTwHwoegNmJgv02mU5OElFrkA05vfGd0lv3I E83g== X-Received: by 10.60.3.200 with SMTP id e8mr4615912oee.94.1363798203220; Wed, 20 Mar 2013 09:50:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Wed, 20 Mar 2013 09:49:43 -0700 (PDT) In-Reply-To: <5149E7D7.8010508@gmail.com> References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> From: Lorenzo Colitti Date: Wed, 20 Mar 2013 09:49:43 -0700 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=e89a8fb1f55e73426804d85e03ed X-Gm-Message-State: ALoCoQmQ/ar6rMnM67LPT5gtAvunKe5FO3w6BOl7n/nT5eqKcuv47uoSmzKw0Bg2xWIpTpQoOzlY3VsAIdQRV+/hMIywWgb9DOy7IIsTM6AwYM7/u9xEdgO+RZ/CpgKbmm0DBz5jRl5XlZ3fUXB22I7XYXFGH65SZdwnoThkEAmVpYWckSQ6zlRnNyGa45iCb3XVxzjwgKMN Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 16:50:08 -0000 --e89a8fb1f55e73426804d85e03ed Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 20, 2013 at 9:46 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > It is my understanding that if a host sees RAs with A bit set, and the > > on-link prefix is ULA, it will install a default route towards the > > RA-announcing router. > > If there's only one prefix on a LAN and that is a ULA prefix, you > can't reach the outside world anyway (unless there's an NPTv6 box), > so what's the problem? > OIne problem is that hosts will prefer non-working ULA over working IPv4. --e89a8fb1f55e73426804d85e03ed Content-Type: text/html; charset=ISO-8859-1
On Wed, Mar 20, 2013 at 9:46 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> It is my understanding that if a host sees RAs with A bit set, and the
> on-link prefix is ULA, it will install a default route towards the
> RA-announcing router.

If there's only one prefix on a LAN and that is a ULA prefix, you
can't reach the outside world anyway (unless there's an NPTv6 box),
so what's the problem?

OIne problem is that hosts will prefer non-working ULA over working IPv4.
--e89a8fb1f55e73426804d85e03ed-- From swmike@swm.pp.se Wed Mar 20 10:00:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861C221F8839 for ; Wed, 20 Mar 2013 10:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.390, 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 3udNaFwjK2vW for ; Wed, 20 Mar 2013 10:00:34 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id A020B21F877B for ; Wed, 20 Mar 2013 10:00:30 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B6A819C; Wed, 20 Mar 2013 18:00:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id AFE0B9A; Wed, 20 Mar 2013 18:00:29 +0100 (CET) Date: Wed, 20 Mar 2013 18:00:29 +0100 (CET) From: Mikael Abrahamsson To: Brian E Carpenter In-Reply-To: <5149E7D7.8010508@gmail.com> Message-ID: References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 17:00:34 -0000 On Wed, 20 Mar 2013, Brian E Carpenter wrote: > If there's only one prefix on a LAN and that is a ULA prefix, you > can't reach the outside world anyway (unless there's an NPTv6 box), > so what's the problem? I can reach the outside world with my IPv4 address just fine. I can't reach it with my IPv6 ULA address. So now the gateway device needs to send ICMP unreachables for every IPv6 connection towards the Internet I try. I find this problematic. -- Mikael Abrahamsson email: swmike@swm.pp.se From alexandru.petrescu@gmail.com Wed Mar 20 10:04:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C33821F8F12 for ; Wed, 20 Mar 2013 10:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.883 X-Spam-Level: X-Spam-Status: No, score=-9.883 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKnZRU-69QvJ for ; Wed, 20 Mar 2013 10:04:17 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 2839C21F8F10 for ; Wed, 20 Mar 2013 10:04:16 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2KH4GUb001635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 20 Mar 2013 18:04:16 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2KH4FuR007536 for ; Wed, 20 Mar 2013 18:04:16 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2KH4B0K025317 for ; Wed, 20 Mar 2013 18:04:15 +0100 Message-ID: <5149EBE2.5000908@gmail.com> Date: Wed, 20 Mar 2013 18:03:30 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 17:04:19 -0000 Le 20/03/2013 16:54, Lorenzo Colitti a écrit : > On Wed, Mar 20, 2013 at 5:08 AM, Tim Chown > wrote: > > What worries me is that in non-zeroconf environments, or those where > manual override is possible, administrators will use fc00::/48, as > it's easier to type/remember. But not what the RFC says - it's wrong sysadmin. > Then you're back on a par with using 10.0.0.0/8 . > > > But the unfortunate truth is that, really, ULA is no different from > 10/8. > > I see only one difference between ULA and 10/8. That difference is > *not* that ULAs are unique, because as you correctly note above, > there is no hope of them actually being unique in the real world. So, Lorenzo, I wouldnt qualify it as strongly. There _is_ much hope. Anyone who tried to configure ULAs according to that RFC knows that there is some level of uniqueness guaranteed. (if one just tries to just try quickly ifconfig add fd::1/64 then it's probably not according to the RFC, which would want more digits there.) > The difference is that in IPv6 you are expected to use multiple > addresses at the same time, and that you can use ULA *and* something > else. I agree. Alex > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Wed Mar 20 10:21:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5501521F8DE9 for ; Wed, 20 Mar 2013 10:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.195 X-Spam-Level: X-Spam-Status: No, score=-99.195 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 Og6veOqYepZu for ; Wed, 20 Mar 2013 10:21:55 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 55EB921F8FB3 for ; Wed, 20 Mar 2013 10:21:55 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id z2so66357wey.15 for ; Wed, 20 Mar 2013 10:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OijZnP8G+vLJv6mz4D+H4TxD71pC9SdWiJrs0MjnotU=; b=ARRaUctIFgmTLmGc8AXDnV2fdMYsxBDdcPvOuSFJN/C9qtTCo4Cmh7byQRT0DRuked MBgjBprwHchxbN64N24DcubBAJdG3t47HZBESJLGgyMlke3o6uxZnhQVbe1n+stal0Gd hyLkhuV0/iBeX2PmQqFNaMhLGJ40vcs8YJevUtyrWqeuv1xe2xGae50M1Dm4YL5lKIWs lNwW4IvIw1hhET0fAngXZoPffvKqLFEm/biVLKKZgamBV4gKztasT4DJrDkvawgR5AUN 98ibHm1tWxMRGWWcFKzk7Jv2+VAepwAt5JzY6llzqN9hDm2iQfNkFdxAjiSyFz6WIXpR DGNg== X-Received: by 10.180.86.1 with SMTP id l1mr11609153wiz.32.1363800114388; Wed, 20 Mar 2013 10:21:54 -0700 (PDT) Received: from [192.168.1.64] (host-2-102-218-109.as13285.net. [2.102.218.109]) by mx.google.com with ESMTPS id ex15sm8121824wid.5.2013.03.20.10.21.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Mar 2013 10:21:53 -0700 (PDT) Message-ID: <5149F03A.6070406@gmail.com> Date: Wed, 20 Mar 2013 17:22:02 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mikael Abrahamsson References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 17:21:56 -0000 On 20/03/2013 17:00, Mikael Abrahamsson wrote: > On Wed, 20 Mar 2013, Brian E Carpenter wrote: > >> If there's only one prefix on a LAN and that is a ULA prefix, you >> can't reach the outside world anyway (unless there's an NPTv6 box), >> so what's the problem? > > I can reach the outside world with my IPv4 address just fine. I can't > reach it with my IPv6 ULA address. Right, so you want (ULA source and non-ULA destination) to be lower pref than (IPv4 source and IPv4 destination). That sounds algorithmic. Brian > So now the gateway device needs to send ICMP unreachables for every IPv6 > connection towards the Internet I try. I find this problematic. > From markzzzsmith@yahoo.com.au Wed Mar 20 11:46:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19F111E80ED for ; Wed, 20 Mar 2013 11:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] 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 RSweo7IhHPjY for ; Wed, 20 Mar 2013 11:46:36 -0700 (PDT) Received: from nm21.bullet.mail.bf1.yahoo.com (nm21.bullet.mail.bf1.yahoo.com [98.139.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 64C4B11E80EF for ; Wed, 20 Mar 2013 11:46:35 -0700 (PDT) Received: from [98.139.212.146] by nm21.bullet.mail.bf1.yahoo.com with NNFMP; 20 Mar 2013 18:46:34 -0000 Received: from [98.139.212.210] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 20 Mar 2013 18:46:34 -0000 Received: from [127.0.0.1] by omp1019.mail.bf1.yahoo.com with NNFMP; 20 Mar 2013 18:46:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 761530.94372.bm@omp1019.mail.bf1.yahoo.com Received: (qmail 87350 invoked by uid 60001); 20 Mar 2013 18:46:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1363805194; bh=attcsmBYuJw5MKTRo6ir4ptNtWAbjYJy9qT5+rkzVjU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=UINqWAdN0Huu5V5vuS9JS5dKo9PiP9/SUBE1/NNDBL5Y03pt1MkvNmM16PareYQ7t6dYsJ5IywTnTl+ym/PA/fNfP9btoxXpAB6lLkw8JhNDnfpSqpG4syqxtKtNL526pYJ1ZV/F9f6uwq4VeJtnME+HM1IiaSmAonmZ0fgncdg= 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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rEh5PTRaWfiqIwZncjG0JK8t1xhLDkZ5jJHRYkT4a7+RirAR7MCuzEUf4u37QaMv6+BGWFLltXLZLYGt5ITU0OZv4bOhYexa0SWbfG/yCBp6Pcd9qlpDYEi6Mt2IgJ0GiKGtlt7OOFnLHtwJbe1YLdIW21h0oJttFX2MruGAkxs=; X-YMail-OSG: sDhzW3sVM1msppItXojUS8Sm27pEkqlOsQB6CzMslJ8saFK U9lN30i4SF3zhtdE.ct6QBShPYK9w0u9Cd0eYhsLGbqGBEwgfeaT9mJgPXeB F8UzfK3tgDKtMnc5fV6FW60GolFUgCOd4LN6XXXBEJLfscZuMjWjS43LZ14U wM7pXzIYwHK7Vd2ITR.75Mv5fDcQYgCES8xrMQ0a7bAnYEtnFhxqqR4Xcrmb Nh7.HvCYS45Jzx9alpm5CaW2oIkWX4xO.PwkinlpS8xeRz8fMrzNDCNXnP5i Qw.9fznWbHerxwKaIeDNUHAl9w03st86QyPjKKJRw616Vx4vduB9PRgLDjTU g.QueW4iI3W_Hp5KgghfyZCamfJLbJk3o1xE2ug_BklLPSlmQKdr5b3aXqGT SuuMAv89mdgmbRLc594ff..h28Xk5BBjxZkC_hFNvZ9TqqFgoWfDku6AayQz cVFH0jm0HssYuNgRiruJRLc6j2_hUflLQEOL9fn4HjMmqPLMiDLoyP4P0eAe eH1wZa_Dbf82zEwluu.mS_RQ5ZNtI.8OkUYfhUm3Krkh65W4HYAknOPft5UH hPsp83HBiqMY3StDyUw-- Received: from [150.101.221.237] by web142505.mail.bf1.yahoo.com via HTTP; Wed, 20 Mar 2013 11:46:34 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBUaW0gQ2hvd24gPHRqY0BlY3Muc290b24uYWMudWs.Cj4gVG86IHY2b3BzQGlldGYub3JnCj4gQ2M6IAo.IFNlbnQ6IFdlZG5lc2RheSwgMjAgTWFyY2ggMjAxMyAxMTowOCBQTQo.IFN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWxpdS12Nm9wcy11bGEtdXNhZ2UtYW5hbHlzaXMKPiAKPiAKPiBPbiAxNCBNYXIgMjAxMywgYXQgMjM6MzUsIERvdWcgQmFydG9uIDxkb3VnYkBkb3VnYmFydG9uLnVzPiB3cm90ZToKPiAKPj4gIE9uIDAzLzEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.138.524 References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <51425EB5.6040703@dougbarton.us> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> Message-ID: <1363805194.86628.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Wed, 20 Mar 2013 11:46:34 -0700 (PDT) From: Mark Smith To: Tim Chown , "v6ops@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 18:46:36 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Tim Chown =0A> To: v6ops@ietf.org=0A> Cc: =0A> Sent: Wednesday, 20 March 2013 = 11:08 PM=0A> Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis=0A> = =0A> =0A> On 14 Mar 2013, at 23:35, Doug Barton wrote= :=0A> =0A>> On 03/14/2013 04:25 PM, Owen DeLong wrote:=0A>>> If both site= s are using 10.0.0.0/8 in an overlapping manner, then =0A> connecting them = via routers does not yield goodness.=0A>> =0A>> Of course, but that's not = a technical difference between ULA and 1918. =0A> As I pointed out in my re= ply to Victor, the distinction is that it's less =0A> likely to happen with= ULA, which is worth noting of course.=0A> =0A> Well, with ULAs you have *s= ignificantly* less chance of overlap. But without =0A> ULA-C, which died a = death, there is a possibility, however small.=0A> =0A> What worries me is t= hat in non-zeroconf environments, or those where manual =0A> override is po= ssible, administrators will use fc00::/48, as it's easier to =0A> type/reme= mber.=A0 Then you're back on a par with using 10.0.0.0/8.=0A>=A0=0A=0AThe F= ritzbox CPE a few years back made a failed attempt at using ULAs. They did = exactly that i.e. no random ID, and attempted to *swap* the ULA for the GUA= when the GUA disappeared due to the WAN link going down and vice versa.=A0= The thing I couldn't work out was how they product developers had read enou= gh to know of ULAs, but didn't read enough to implement them properly. Prob= ably just another example of IPv6 being thought of as nothing more than IPv= 4 with bigger addresses.=A0Unfortunately they were ignoring my bug reports,= unlike a number of other CPE vendors I was dealing with at the time.=0A=0A= It seems to me that one of the ways to make things more robust is to reduce= external dependencies. Using ULAs for internal addressing and for internal= access, and only using GUAs for external global Internet access, is making= your internal access robust against external GUA related events (e.g. your= ISP going away, or your GUA prefix expiring, or you haven't got an ISP yet= ).=0A=0AOver the last few years, CPEs have gained features beyond just prov= iding global Internet connectivity. The Fritzbox example above can also act= as a NAS if you plug a USB disk into it, a network print server for a USB = printer, and a SIP DECT gateway. Given the expense of these higher end CPEs= , end users would be quite reasonably frustrated if they can't use some of = these other non-global Internet features while they don't have an active GU= A from an ISP. For example, I wouldn't be happy if I was watching a movie b= eing streamed from the NAS in this CPE and it then stopped because my Inter= net connection had gone down and my GUA had expired.=0A=0ARFC6204 specifies= ULAs for internal addressing for these reasons.=0A=0A=0ARegards,=0AMark. From pkern@spike.0x539.de Wed Mar 20 11:51:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7146111E80ED for ; Wed, 20 Mar 2013 11:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id km+IzYELvURG for ; Wed, 20 Mar 2013 11:51:55 -0700 (PDT) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id AE56011E80E8 for ; Wed, 20 Mar 2013 11:51:55 -0700 (PDT) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UIO72-0004eN-Fq; Wed, 20 Mar 2013 19:51:48 +0100 Received: from [2001:470:720c:0:549e:7ff4:7168:b57e] (helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1UIO73-0004zn-O6; Wed, 20 Mar 2013 19:51:49 +0100 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1UIO72-0006vz-Kd; Wed, 20 Mar 2013 19:51:48 +0100 Date: Wed, 20 Mar 2013 19:51:48 +0100 From: Philipp Kern To: Mark Smith Message-ID: <20130320185148.GA26639@spike.0x539.de> References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <51425EB5.6040703@dougbarton.us> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <1363805194.86628.YahooMailNeo@web142505.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1363805194.86628.YahooMailNeo@web142505.mail.bf1.yahoo.com> Organization: 0x539 dev group User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 18:51:56 -0000 On Wed, Mar 20, 2013 at 11:46:34AM -0700, Mark Smith wrote: > The Fritzbox CPE a few years back made a failed attempt at using ULAs. They > did exactly that i.e. no random ID, and attempted to *swap* the ULA for the > GUA when the GUA disappeared due to the WAN link going down and vice > versa. I need to check it again but that's exactly what a DTAG CPE (Speedport) in Germany does. You can turn on ULAs through the web interface and don't even get to pick the bits. My personal guess is that DTAG fixed it on all but I don't have multiple devices to test. Kind regards Philipp Kern From markzzzsmith@yahoo.com.au Wed Mar 20 12:22:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1216D11E80F3 for ; Wed, 20 Mar 2013 12:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] 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 j-nHYaVmO54v for ; Wed, 20 Mar 2013 12:22:31 -0700 (PDT) Received: from nm16.bullet.mail.bf1.yahoo.com (nm16.bullet.mail.bf1.yahoo.com [98.139.212.175]) by ietfa.amsl.com (Postfix) with SMTP id 80BBD11E80F7 for ; Wed, 20 Mar 2013 12:22:19 -0700 (PDT) Received: from [98.139.212.147] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 20 Mar 2013 19:22:18 -0000 Received: from [98.139.212.207] by tm4.bullet.mail.bf1.yahoo.com with NNFMP; 20 Mar 2013 19:22:18 -0000 Received: from [127.0.0.1] by omp1016.mail.bf1.yahoo.com with NNFMP; 20 Mar 2013 19:22:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 962499.15794.bm@omp1016.mail.bf1.yahoo.com Received: (qmail 52867 invoked by uid 60001); 20 Mar 2013 19:22:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1363807338; bh=vjUaBrpVEuYuOJWBtgW1bU6DvKSRannhyvG2aQZi26U=; 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=i3HDeSPJSjrb7i6vS5rVM1CRZ3mDk3+T89MqavqTf0kYPRjSWnOjGNNdsZcHxmSOUd4mZY+i6XHxKTFbgrxAURfjvOzLcLOjWZrjw4AjzD8G3y5zX13MK48rGMbWsbLs10a3OQtKdXTO5Ed3Db2s10jw5qp3CmTUGLTbhysx+Uc= 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=JI01MBjwH1gWJr+DOe++4Aew3ReH3gpzRYnf5aHUUgOugIeG4Hd3Hug+QuuO8SIZdq8WSYGCMAYihxUfiiaqPuYzI/rKKw16lQzNC3nkFHL8aA4D04WBPSK6DdzV3axn6EGYmarMoUU2g+ipUV0YPQ1QQQAD/GhGfXa1/DW1mdo=; X-YMail-OSG: Fs94OQ4VM1l8YzUIj5BaSEaDYO6COipLtITg5pcCNFJB.NV p0DEaVHY7FJSENoqAR5Wo5sraH3jneWr5F9iLD8RW6I3b.Hf2I1xxGRFHIMe WGg0Gf9u6PGBmGea1KYhCWKVkeUnTZZKlw7VMLU7DQZzGi1XKyz4of7J58nm Qgm.UgUnufIOSQCxr5IAyCI2iHQoACZBjIKdXXRyRd2cupW9IKOnRlO7pGPA mZfLB_Dnz_gkBZF1CLOFJzkSW0LG7IcZLO61dSjo6DosKUxNCNpHTYmX_Gmy Paw7HPfJjCU.KcqW.jxrX3GLDN1NLk4EScRW7ZRItpOnvMs0VcPSC9l1Kezd HN9RpojSXxZby7dgNn3t6awaI2iIceI6vGxwa_eJUlG.skfKtHvBFHge7ShZ jQmM2PePKqwetc0Df3SU8tsQkXFu1Uv1Q0vyJ3da.THKEr8XwlEyarFnFuLv 9f2G5mB5khAW.tMgEiSC050z8t3mDwWGitxXdLxgPE1LNAoE1rM1gc.wsAUJ DrzwBd56wRFwEYvSazl_ziVt8Qu3IePz.C191p5Wc7L5fwPYNO9K34a0FG0V ybjZXN9q_rwrGTcL9zQ-- Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Wed, 20 Mar 2013 12:22:18 PDT X-Rocket-MIMEInfo: 002.001, CgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4KPlRvOiBUaW0gQ2hvd24gPHRqY0BlY3Muc290b24uYWMudWs.IAo.Q2M6ICJ2Nm9wc0BpZXRmLm9yZyBXRyIgPHY2b3BzQGlldGYub3JnPiAKPlNlbnQ6IFRodXJzZGF5LCAyMSBNYXJjaCAyMDEzIDI6NTQgQU0KPlN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWxpdS12Nm9wcy11bGEtdXNhZ2UtYW5hbHlzaXMKPiAKPgo.T24gV2VkLCBNYXIgMjAsIDIwMTMgYXQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.138.524 References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> Message-ID: <1363807338.52728.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Wed, 20 Mar 2013 12:22:18 -0700 (PDT) From: Mark Smith To: Lorenzo Colitti , Tim Chown In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 19:22:32 -0000 =0A=0A=0A=0A=0A>________________________________=0A> From: Lorenzo Colitti = =0A>To: Tim Chown =0A>Cc: "v6ops@= ietf.org WG" =0A>Sent: Thursday, 21 March 2013 2:54 AM=0A>= Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis=0A> =0A>=0A>On Wed,= Mar 20, 2013 at 5:08 AM, Tim Chown wrote:=0A>=0A>Wha= t worries me is that in non-zeroconf environments, or those where manual ov= erride is possible, administrators will use fc00::/48, as it's easier to ty= pe/remember. =A0Then you're back on a par with using 10.0.0.0/8.=0A>=0A>=0A= >But the unfortunate truth is that, really, ULA is no different from 10/8.= =0A>=0A>=0A>=0A=0AI disagree. site-locals were no different from 10/8. ULAs= don't suffer from the problems that site-locals (and RFC1918) do that are = detailed in RFC3879.=A0=0A=0AYou could argue that people will be lazy and n= ot use a globally unique ID. Unfortunately we can't legislate against not f= ollowing the specifications (a.k.a., being lazy). In this case, if they joi= n their Non-Unique Unique Local Addressed network with another one that has= also not followed the specifications, then the renumbering or NAT/NPT pain= will be theirs and their partner's alone.=A0=0A=0A>=0A=0A>=0A>=0A>=0A>=0A>= I see only one difference between ULA and 10/8. That difference is *not* th= at ULAs are unique, because as you correctly note above, there is no hope o= f them actually being unique in the real world. The difference is that in I= Pv6 you are expected to use multiple addresses at the same time, and that y= ou can use ULA *and* something else.=0A>_______________=0A=0AWhy is there n= o hope? You're effectively saying that the ULA specifications won't ever be= followed correctly, rather than far more often than not. Couldn't the same= be said about any and all specifications? Why would people follow nearly a= ll specifications correctly, with the ULA specification being the special c= ase where they won't?=0A=0A________________________________=0A>v6ops mailin= g list=0A>v6ops@ietf.org=0A>https://www.ietf.org/mailman/listinfo/v6ops=0A>= =0A>=0A> From markzzzsmith@yahoo.com.au Wed Mar 20 12:46:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B147311E80F1 for ; Wed, 20 Mar 2013 12:46:18 -0700 (PDT) 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=[AWL=0.100, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] 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 Hiaa3-CXTXTc for ; Wed, 20 Mar 2013 12:46:18 -0700 (PDT) Received: from nm39-vm5.bullet.mail.bf1.yahoo.com (nm39-vm5.bullet.mail.bf1.yahoo.com [72.30.239.149]) by ietfa.amsl.com (Postfix) with ESMTP id AF69111E80EF for ; Wed, 20 Mar 2013 12:46:17 -0700 (PDT) Received: from [98.139.212.144] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 20 Mar 2013 19:46:17 -0000 Received: from [98.139.215.250] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 20 Mar 2013 19:46:17 -0000 Received: from [127.0.0.1] by omp1063.mail.bf1.yahoo.com with NNFMP; 20 Mar 2013 19:46:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 93753.28715.bm@omp1063.mail.bf1.yahoo.com Received: (qmail 76543 invoked by uid 60001); 20 Mar 2013 19:39:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1363808377; bh=uvagxQbob1q7NFUbu9KEGH0GPpwPnaXhddoUFkFYkzI=; 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=jwSFieYITEtQDNGb3Mn7CWGfLsYul2JT/Fchlq/kk9k8hxiCofjBq7xRG9fXB5sW7ltnMlMOBTLTBwAUiOgQIaRJ3iNAyjNNikfeSnppHaqzARfPMnQDxAhj405nz+zXaaiPhn8+6NFP3A1PR8I46najG5ramx09fZppI2lsvzw= 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=w+Pg8d2HjojEvFwMlC8Ufo5HQem23ejfnInNxvOqfW4k+NjlKuCTcgm46mdXeVWM8WibdlDhs9wVdoIbgeOxw8R30o8ZK0NjP5Zye7F5CRGDwPb0iU0sjdNLL8fg1LBVTwOsp8KEGVGFA6A1fmy8RMWorT9UfmNsOug0rQQYJLg=; X-YMail-OSG: hwwEOtIVM1l8BETJvhKipEzirA15eH4Vfh773lOoERRU6VB a5aAS2mbfndz7kPckrQRQq6PqFyTS5q5rQcFwcGyQdk542VUP9j6kSsSe9gz nkL9zz6l6PrHnHE4VxyTtuaFSRGBk.6H5z._UITKJSVs4V8hXsRrbkHMIPTe dXf3_uPj8ElyNrq.W6yL6NAr6Plk_Chsh880W0LFf.P1rVlhUvRYkGvRF8nl HDR3nLK96.Siw8nxdAU5hGkGgbuMKNIJ3Re_66WQWMxiaFu8tZyUueM5.oHs xUVb_vV.PIi9YQkps1aHJ4p2tazS0u.FXQYUMTweOhjmoMzChmy1wGqEnP3T 39_TJg0pvTnXy4jv1KN0uaMo.6Oqj9iDFTacxPtlUxVvFkQj81Fx.XVQGc8t Vk.GPy1t3i.Az9_IGdfI6.ss6KlhvWnfAVP9DoI9fEx5gTkpq2e41Y0q6w7Z bD.4Vo8RhTHNcU223g3VcSju0r2tW3uYFJto5yXCe5bgfltGb4gn7KZJjKva J4.e71PhLUNGEon76AR.xbs9I Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Wed, 20 Mar 2013 12:39:37 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPgo.IFRvOiBNaWthZWwgQWJyYWhhbXNzb24gPHN3bWlrZUBzd20ucHAuc2U.Cj4gQ2M6ICJ2Nm9wc0BpZXRmLm9yZyBXRyIgPHY2b3BzQGlldGYub3JnPgo.IFNlbnQ6IFRodXJzZGF5LCAyMSBNYXJjaCAyMDEzIDQ6MjIgQU0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1saXUtdjZvcHMtdWxhLXVzYWdlLWFuYWx5c2lzCj4gCj4gT24gMjAvMDMvMjABMAEBAQE- X-Mailer: YahooMailWebService/0.8.138.524 References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <5149F03A.6070406@gmail.com> Message-ID: <1363808377.63857.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Wed, 20 Mar 2013 12:39:37 -0700 (PDT) From: Mark Smith To: Brian E Carpenter , Mikael Abrahamsson In-Reply-To: <5149F03A.6070406@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 19:46:19 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Brian E Carpenter =0A> To: Mikael Abrahamsson =0A> C= c: "v6ops@ietf.org WG" =0A> Sent: Thursday, 21 March 2013 4= :22 AM=0A> Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis=0A> =0A>= On 20/03/2013 17:00, Mikael Abrahamsson wrote:=0A>> On Wed, 20 Mar 2013, = Brian E Carpenter wrote:=0A>> =0A>>> If there's only one prefix on a LAN a= nd that is a ULA prefix, you=0A>>> can't reach the outside world anyway (u= nless there's an NPTv6 =0A> box),=0A>>> so what's the problem?=0A>> =0A>> = I can reach the outside world with my IPv4 address just fine. I can't=0A>>= reach it with my IPv6 ULA address.=0A> =0A> Right, so you want (ULA sourc= e and non-ULA destination) to be lower=0A> pref than (IPv4 source and IPv4 = destination). That sounds algorithmic.=0A> =0A> =A0 =A0 Brian=0A> =0A>> So= now the gateway device needs to send ICMP unreachables for every IPv6=0A>>= connection towards the Internet I try. I find this problematic.=0A>>=A0= =0A=0AAnd these are the sorts of scenarios which eventuated in Happy Eyebal= ls (RFC6555).=0A=0AFred has written up a draft which clarifies that the Hap= py Eyeballs wasn't really meant to be just restricted to HTTP applications,= and was intended to be a more general approach for multihomed hosts (with = multihoming also including a single interface but dual stacked host).=0A=0A= "Happier Eyeballs"=0Ahttps://www.ietf.org/id/draft-baker-happier-eyeballs-0= 0.txt=0A=0A=0ARegards,=0AMark. From owen@delong.com Wed Mar 20 12:46:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDA011E80EF for ; Wed, 20 Mar 2013 12:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 8dg-RSuYNaBW for ; Wed, 20 Mar 2013 12:46:18 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 0703211E80F0 for ; Wed, 20 Mar 2013 12:46:17 -0700 (PDT) Received: from [10.211.26.149] (mobile-198-228-235-110.mycingular.net [198.228.235.110]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2KJivpl032621 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Mar 2013 12:45:02 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2KJivpl032621 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363808708; bh=b7+W5I55lLloFlck3KE78ycbUZ0=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=aS/3HQyJaHPEOap6E8lnMMfFK1fWllbBSn0M+pofUDc1kzofTnPC4zUBpyX2Ncj1b mznAz9SD7dn4T5WwiMgAmWUYQu52jw2CzkzmqZ0B3DsImXuEJJtYGLaDgZHMyE9oSP /CPdKYXfpjHgm12cIMgSMWC/U+qGU6XWh49cWBts= References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5149E7D7.8010508@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B146) From: Owen DeLong Date: Wed, 20 Mar 2013 14:44:57 -0500 To: Brian E Carpenter X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 20 Mar 2013 12:45:08 -0700 (PDT) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 19:46:19 -0000 Sent from my iPad On Mar 20, 2013, at 11:46 AM, Brian E Carpenter wrote: > On 20/03/2013 16:28, Mikael Abrahamsson wrote: >> On Wed, 20 Mar 2013, Lorenzo Colitti wrote: >>=20 >>> IPv6 you are expected to use multiple addresses at the same time, and >>> that you can use ULA *and* something else. >>=20 >> It is my understanding that if a host sees RAs with A bit set, and the >> on-link prefix is ULA, it will install a default route towards the >> RA-announcing router. >=20 > If there's only one prefix on a LAN and that is a ULA prefix, you > can't reach the outside world anyway (unless there's an NPTv6 box), > so what's the problem? >=20 The problem is that you can reach the outside world via IPv4. While I think this is an inherently stupid way to deploy IPv6 within an orga= nization (IPv6 only good within the organization and IPv4 for outside (wheth= er or not IPv4 is usable inside)), the reality is that it is a technically v= alid scenario and ULA6+IPv4 without GUA6 =3D=3D broken user experiences. > If there *is* an NPTv6 box, you want a default route towards it, > so what's the problem? If there is NOT an NPTv6 box and you have valid IPv4 connectivity... > If there is also a GUA prefix, that's the one you want the default route > for, and source address selection should take care of the rest, so > what's the problem? The IF pretty much covers it. IF there is no GUA prefix and there is a GUA4 address or NAT44 based connectivity... The internet is a complex place. Owen From swmike@swm.pp.se Wed Mar 20 12:47:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E698F11E8100 for ; Wed, 20 Mar 2013 12:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.367, 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 a5EXYLPZbSDM for ; Wed, 20 Mar 2013 12:47:03 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 862C611E80F8 for ; Wed, 20 Mar 2013 12:47:03 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A3CB49C; Wed, 20 Mar 2013 20:47:02 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9ECA09A for ; Wed, 20 Mar 2013 20:47:02 +0100 (CET) Date: Wed, 20 Mar 2013 20:47:02 +0100 (CET) From: Mikael Abrahamsson To: "v6ops@ietf.org WG" In-Reply-To: <1363808377.63857.YahooMailNeo@web142501.mail.bf1.yahoo.com> Message-ID: References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <5149F03A.6070406@gmail.com> <1363808377.63857.YahooMailNeo@web142501.mail.bf1.yahoo.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 19:47:05 -0000 On Wed, 20 Mar 2013, Mark Smith wrote: > And these are the sorts of scenarios which eventuated in Happy Eyeballs (RFC6555). > > Fred has written up a draft which clarifies that the Happy Eyeballs wasn't really meant to be just restricted to HTTP applications, and was intended to be a more general approach for multihomed hosts (with multihoming also including a single interface but dual stacked host). > > "Happier Eyeballs" > https://www.ietf.org/id/draft-baker-happier-eyeballs-00.txt I'd be happy if my customers are using Windows 7 and IE9. If ULAs cause a problem for this setup, I'm hesitant to deploy ULAs. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Wed Mar 20 12:49:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8717B21F8B45 for ; Wed, 20 Mar 2013 12:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=0.346, 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 J-tgUYjScqTP for ; Wed, 20 Mar 2013 12:49:14 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id E677D21F8AD5 for ; Wed, 20 Mar 2013 12:49:13 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CBA069C; Wed, 20 Mar 2013 20:49:12 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B7E199A; Wed, 20 Mar 2013 20:49:12 +0100 (CET) Date: Wed, 20 Mar 2013 20:49:12 +0100 (CET) From: Mikael Abrahamsson To: Owen DeLong In-Reply-To: Message-ID: References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 19:49:14 -0000 On Wed, 20 Mar 2013, Owen DeLong wrote: > The IF pretty much covers it. IF there is no GUA prefix and there is a > GUA4 address or NAT44 based connectivity... > > The internet is a complex place. It's not even complex. I see recommendations for CPEs to start announcing ULAs even if they have no GUA, or that ULAs should be announced even if the GUA prefix goes away. This will lead to broken connectivty as you say, bad user experience, and I don't like this recommendation. -- Mikael Abrahamsson email: swmike@swm.pp.se From owen@delong.com Wed Mar 20 13:07:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE88411E8119 for ; Wed, 20 Mar 2013 13:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jrWj5IkL2lC for ; Wed, 20 Mar 2013 13:07:02 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D42FD11E8118 for ; Wed, 20 Mar 2013 13:07:01 -0700 (PDT) Received: from [172.20.10.3] (27.sub-70-198-12.myvzw.com [70.198.12.27]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2KK3InC000787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Mar 2013 13:03:22 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2KK3InC000787 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363809802; bh=4SX2Wb+R5BudNFckSAoSk9WMdWA=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=C7uf7Qcu7c+ZPLXPays01v1svsJO0ybXMkfsM51xZHC5LD5XJhwcjmXHONIlLn/p6 ZrqwZ4Bsf/J9VGpfbJhQikrHc32LWhipbtCqOCR3fRTr9tU2ilShOoEK9HiMlNpUVB tWTEazawtOVnEMqP1MbhFBDqRTimm8tZNdP9svMQ= References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149EBE2.5000908@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5149EBE2.5000908@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <0A02847A-F67C-4285-A540-8A7A6497ACF3@delong.com> X-Mailer: iPad Mail (10B146) From: Owen DeLong Date: Wed, 20 Mar 2013 15:03:17 -0500 To: Alexandru Petrescu X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 20 Mar 2013 13:03:22 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 20:07:07 -0000 Sent from my iPad On Mar 20, 2013, at 12:03 PM, Alexandru Petrescu wrote: > Le 20/03/2013 16:54, Lorenzo Colitti a =C3=A9crit : >> On Wed, Mar 20, 2013 at 5:08 AM, Tim Chown > > wrote: >>=20 >> What worries me is that in non-zeroconf environments, or those where >> manual override is possible, administrators will use fc00::/48, as >> it's easier to type/remember. >=20 > But not what the RFC says - it's wrong sysadmin. Which matters here in the ivory tower, but makes no difference in the real w= orld. >> Then you're back on a par with using 10.0.0.0/8 . >>=20 >>=20 >> But the unfortunate truth is that, really, ULA is no different from >> 10/8. >>=20 >> I see only one difference between ULA and 10/8. That difference is >> *not* that ULAs are unique, because as you correctly note above, >> there is no hope of them actually being unique in the real world. >=20 > So, Lorenzo, I wouldnt qualify it as strongly. There _is_ much hope. Only among overly optimistic idealists. > Anyone who tried to configure ULAs according to that RFC knows that > there is some level of uniqueness guaranteed. No, there is no level of uniqueness guaranteed. There is a statistically hig= h probability of uniqueness for those who deploy ULA according to the RFC. E= ven there, there is no guarantee of any level of uniqueness, just a strong p= robability. However, the probability that the majority of administrators wil= l even read the ULA RFC (how many people do you think have actually read RFC= -1918 vs. the number that have deployed 10/8 or any other RFC-1918 address? I= 'll give you a hint... Ask a bunch of administrators which of the following a= re RFC-1918 addresses. If it's not an open book test, I bet the results surp= rise you. 172.16.5.3 Everyone will probably get this rig= ht. 172.30.19.6 About half will get this wrong. 172.32.99.7 The other half will get this wrong.= 172.80.15.7 About half of the ones that got the= previous question wrong will also get this one wrong. > (if one just tries to just try quickly ifconfig add fd::1/64 then > it's probably not according to the RFC, which would want more digits there= .) fd::1/64 isn't even ULA, but I wouldn't put it past administrators to think i= t is. fd00::1/64, OTOH, will probably be the most common ULA gateway address. Owen From owen@delong.com Wed Mar 20 13:07:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C7111E8118 for ; Wed, 20 Mar 2013 13:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 faHHxSeBbQiw for ; Wed, 20 Mar 2013 13:07:03 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1E06211E80EF for ; Wed, 20 Mar 2013 13:07:03 -0700 (PDT) Received: from [172.20.10.3] (27.sub-70-198-12.myvzw.com [70.198.12.27]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2KK3InD000787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Mar 2013 13:04:08 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2KK3InD000787 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363809849; bh=GM7pY4eRaisAZpI/gO86RWDs1mA=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=BGQfc/amXpc9QwcLAmgxBB4tWVKHfhXTWoCT3dkzGQ3aMA27wbA8PfjtGdqd/fCTR Pvwul5Jskn4yXWTh8TXVQCpn35q6s4blUPaVI6RfdNu5gwtspV5vdzUE4e1uJmcO4K 6OltbX/AkF63F44zJDFTbcsdxAGpQ5miAPCq7I2w= References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <5149F03A.6070406@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5149F03A.6070406@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <41086580-163B-423D-8009-89869B8AD30C@delong.com> X-Mailer: iPad Mail (10B146) From: Owen DeLong Date: Wed, 20 Mar 2013 15:04:08 -0500 To: Brian E Carpenter X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 20 Mar 2013 13:04:09 -0700 (PDT) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 20:07:08 -0000 > Right, so you want (ULA source and non-ULA destination) to be lower > pref than (IPv4 source and IPv4 destination). That sounds algorithmic. >=20 > Brian Sure, but it contradicts the algorithm currently deployed in a very large ba= se of installed systems. Owen From markzzzsmith@yahoo.com.au Wed Mar 20 13:07:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCFE11E8128 for ; Wed, 20 Mar 2013 13:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] 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 8i+PaAgYWs+r for ; Wed, 20 Mar 2013 13:07:40 -0700 (PDT) Received: from nm40-vm3.bullet.mail.bf1.yahoo.com (nm40-vm3.bullet.mail.bf1.yahoo.com [72.30.239.211]) by ietfa.amsl.com (Postfix) with ESMTP id CBFFA11E8121 for ; Wed, 20 Mar 2013 13:07:27 -0700 (PDT) Received: from [98.139.212.144] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 20 Mar 2013 20:07:22 -0000 Received: from [98.139.212.204] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 20 Mar 2013 20:07:22 -0000 Received: from [127.0.0.1] by omp1013.mail.bf1.yahoo.com with NNFMP; 20 Mar 2013 20:07:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 464419.22609.bm@omp1013.mail.bf1.yahoo.com Received: (qmail 83065 invoked by uid 60001); 20 Mar 2013 20:07:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1363810042; bh=gVUiokBDLGx8kzwJXDhHQCcYTuVteWtpA8gER/6Fmlc=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZkWPTNuL6GuPS5wgtpa2VqyKK+EHzuYMTTJceGQ2YNkNWJRwNLi/2Bf9VDzQ+hiXIaevTGSXKGcf1mFbZWX6MpgI5p/hMlThPLTDoo1ZFuQsHDwO99A5YH590OP8Ppm230G41zLdL8R8OH3X2jegfvqp4l006gROv9Yd8yoxWd0= 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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qJ7H7XgyD22xxtb79a0Y6YLMPWUuyV38aelHJbJx2mH1ujC6x+cYvWDpie/WjMgnBtqv7+4i6pyFoyOeVO7uDqeAc3ORQFP5xUVV16cMtTVMemYDOxjjTS4uU1mi1I/XMIDtPGUtxs5okE2ToH3uiYJb+IzuT+Ti258dY0uIYUM=; X-YMail-OSG: Xpd.fzQVM1mSr.fqsGOKBDarxo0eAxasJfZEDHDGoeYHf7s JeSfm5D8SK5maLaO6VQf_O5G7JOmCZiWBOX52hR9.d9jKip_McAzNCmteKSm KPzaNrP3KWlZVUNwMb_GYe.8acVwGEZZVVjp2mrlXLvafUp1.bAmWRTezOcn G5i8t14pKoQ82.yNaqkjFfHAkqrlPAt0GWvbpqAAFc.1TsQWVK_xDuqqkHNy gcHG_PPj1lN4i71ZdW5PEiDo.Wt3n59MJGDRm0fY4GV972WPwrmWF5mA7IR6 Hw2ILVU.6UuRTNPQ5S6F6h8gE351MIz2gfZFaRUH5hznq1WB4xQR_.f4Axu_ .fDu2rTz.YYbKNLxgkCexXxNDv3iYKX2InvjEZsfvKwo7dXtMgQd408e4pd7 puwTrBw2blEiA6wEXLRFPH45SjEk32Nm.GbsRPzq_x3D9TX95NBQicT3GYRy HDQna7bgePcdfca6Oz2cyMZKtjo6RGIX7.y_agEG4roNjwpRZSPu_h7NJLGY UfliHbGfIV3RCWFcLfgVC0h1O Received: from [150.101.221.237] by web142506.mail.bf1.yahoo.com via HTTP; Wed, 20 Mar 2013 13:07:22 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBNaWthZWwgQWJyYWhhbXNzb24gPHN3bWlrZUBzd20ucHAuc2U.Cj4gVG86ICJ2Nm9wc0BpZXRmLm9yZyBXRyIgPHY2b3BzQGlldGYub3JnPgo.IENjOiAKPiBTZW50OiBUaHVyc2RheSwgMjEgTWFyY2ggMjAxMyA2OjQ3IEFNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtbGl1LXY2b3BzLXVsYS11c2FnZS1hbmFseXNpcwo.IAo.IE9uIFdlZCwgMjAgTWFyIDIwMTMsIE1hcmsgU21pdGggd3JvdGU6Cj4gCj4.ICBBbmQgdGhlc2UgYXIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.138.524 References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <5149F03A.6070406@gmail.com> <1363808377.63857.YahooMailNeo@web142501.mail.bf1.yahoo.com> Message-ID: <1363810042.80318.YahooMailNeo@web142506.mail.bf1.yahoo.com> Date: Wed, 20 Mar 2013 13:07:22 -0700 (PDT) From: Mark Smith To: Mikael Abrahamsson , "v6ops@ietf.org WG" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 20:07:43 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Mikael Abrahamsson =0A> To: "v6ops@ietf.org WG" =0A> Cc: =0A> Sen= t: Thursday, 21 March 2013 6:47 AM=0A> Subject: Re: [v6ops] draft-liu-v6ops= -ula-usage-analysis=0A> =0A> On Wed, 20 Mar 2013, Mark Smith wrote:=0A> =0A= >> And these are the sorts of scenarios which eventuated in Happy Eyeballs= =0A> (RFC6555).=0A>> =0A>> Fred has written up a draft which clarifies th= at the Happy Eyeballs =0A> wasn't really meant to be just restricted to HTT= P applications, and was =0A> intended to be a more general approach for mul= tihomed hosts (with multihoming =0A> also including a single interface but = dual stacked host).=0A>> =0A>> "Happier Eyeballs"=0A>> https://www.ietf.o= rg/id/draft-baker-happier-eyeballs-00.txt=0A> =0A> I'd be happy if my custo= mers are using Windows 7 and IE9. If ULAs cause a =0A> problem for this set= up, I'm hesitant to deploy ULAs.=0A>=A0=0A=0ASo you're a service provider, = your ULA addressing domain would have it's boundary between your network an= d your customers networks, and your transit and peers i.e. on your BNG/BRAS= /CMTSs, border routers etc. Your customers' ULA addressing domain boundary = would occur on their CPE, at the boundary of their network. In other words,= your customers' internal networks are not part of your ULA addressing doma= in - they have their own ULA addressing domain. If the customer operates th= e CPE, you wouldn't know and shouldn't care about whether they use ULA addr= essing internally or not. If you operate the CPE, you might care, but only = just because it is a configuration parameter of the CPE.=0A=0AThere would b= e no ULA addresses on the link between you and your customer. You would dro= p traffic with ULA sources and/or destinations received from your customers= as per standard BCP38/martian/bogon filtering practices.=0A=0ASo you don't= have to deploy ULAs inside your service provider network if you don't want= to, although I think there are operational advantages to having internal i= nfrastructure/OAM etc. addressing that is independent of external RIRs GUA = addressing. Your customers would have benefits of ULA addressing internally= because their internal IPv6 network will still work if their Internet conn= ection goes down.=0A=0ARegards,=0AMark. From arturo.servin@gmail.com Wed Mar 20 13:10:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1756821F87FB for ; Wed, 20 Mar 2013 13:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[AWL=-1.242, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_13=0.6, RDNS_NONE=0.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 ZqaZzUIg7vT9 for ; Wed, 20 Mar 2013 13:10:12 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 90C5221F8574 for ; Wed, 20 Mar 2013 13:10:00 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id c11so2632084ieb.15 for ; Wed, 20 Mar 2013 13:10:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=u0riuJ+Pyc2JhB+Pf6gjXXvm3HcPR8MjtGXjo2zuL5g=; b=sTb2Zh+MPykz26WiJQNHXlkTo9OioUPw5Wy3g5hWR1OqZj1gLCojQb29inMwoZDdtw Cu1PsZgv+Rr0CYkJWQOjiiGl+HRpXx+3U7CyKsQHfjkaAMQ3uXcluP4G19oLtOHhaTKP ag08w/4Xk9fe4U9j6qane7Fd3ywP9vRMbMu6bEc7VLgl7t2572/lgwDCQo4vBSc0zGrh GSDU4XL9+J4A74UgNXxe+XCjw3qwSNS6fKBhAT7manUqfoLMVgS60HPtOFvHdr5XnACg SNPoN4Ib9qkAYZtwuUpDMhUEQVWakYU8UmDo2V3d7pI7r2ROYfKRZBq5TNOUuYlb3Nsi 9d9w== X-Received: by 10.42.179.73 with SMTP id bp9mr14252863icb.51.1363810200411; Wed, 20 Mar 2013 13:10:00 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy ([200.7.85.141]) by mx.google.com with ESMTPS id a3sm3458576igq.5.2013.03.20.13.09.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Mar 2013 13:09:59 -0700 (PDT) Message-ID: <514A1792.7060305@gmail.com> Date: Wed, 20 Mar 2013 17:09:54 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Iljitsch van Beijnum References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> <5149A50E.50300@gmail.com> <07CC1B32-89A4-4627-B9BF-6DD934B46C9D@muada.com> In-Reply-To: <07CC1B32-89A4-4627-B9BF-6DD934B46C9D@muada.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 20:10:13 -0000 Peer review and a nice and shiny RFC number. Regards as On 3/20/13 1:28 PM, Iljitsch van Beijnum wrote: > On 20 mrt 2013, at 13:01, Arturo Servin wrote: > >> I haven't read it all but it looks like a great document. > > Thanks. (And Tim, too.) > >> You mentioned that you are planning to do an independent submission >> (for the dates perhaps you have done it), however I would see a lot of >> value for v6ops if you change your mind. > > What would be the benefit of publication as an IETF document? > > Iljitsch > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From v6ops@globis.net Wed Mar 20 13:11:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A67411E80EF for ; Wed, 20 Mar 2013 13:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Pq-O3Py3p544 for ; Wed, 20 Mar 2013 13:11:01 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id E7C9F11E80DE for ; Wed, 20 Mar 2013 13:11:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 3B01187005C; Wed, 20 Mar 2013 21:10:45 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e62amm9ovIp5; Wed, 20 Mar 2013 21:10:16 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 73BCD87005B; Wed, 20 Mar 2013 21:10:16 +0100 (CET) Message-ID: <514A17A2.70700@globis.net> Date: Wed, 20 Mar 2013 21:10:10 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Brian E Carpenter References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <5149F03A.6070406@gmail.com> In-Reply-To: <5149F03A.6070406@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 20:11:02 -0000 Brian E Carpenter wrote: > On 20/03/2013 17:00, Mikael Abrahamsson wrote: >> On Wed, 20 Mar 2013, Brian E Carpenter wrote: >> >>> If there's only one prefix on a LAN and that is a ULA prefix, you >>> can't reach the outside world anyway (unless there's an NPTv6 box), >>> so what's the problem? >> I can reach the outside world with my IPv4 address just fine. I can't >> reach it with my IPv6 ULA address. > > Right, so you want (ULA source and non-ULA destination) to be lower > pref than (IPv4 source and IPv4 destination). That sounds algorithmic. > > Brian Correct. But it's a no win situation on the default source address selection rules, as I pointed out when we were discussing RFC6724. As IPv6 is introduced we might have stand alone islands of IPv6, discontiguous from the global Internet. As IPv4 dies out, we might eventually have islands of legacy IPv4 devices disconnected from the global Internet. There's no reliable way to signal to an end node whether i) IPv4 RFC1918 is a stand alone pool disconnected from the Internet = local /8 /16 or /24 route only, or RFC 1918 + NAPT = default route to the Internet ii) IPv6 ULA is a stand alone pool disconnected from the Internet = local /48 route only, or multiple ULA's on one site = multiple /48 routes, or ULA + NPTv6 = default route to the Internet. AFAIK We have the following options 1) all end nodes must support draft-ietf-6man-addr-select-opt-08 (which is not yet an RFC, never mind widely supported) 2) Mikael's idea for a PIO to be associated with a specific route, rather than just a global default route (not even an ID yet, although definitely interesting) 3) every app having to support RFC6555 Happy Eyeballs [and yet many current apps can't even properly handle multiple A records in a reply] 4) weak linkage of default route next hop selection with PIO, from rule 5.5 of RFC6724 [fixes selection between 2 IPv6 GUA, although that does not address isolated IPv6 ULA v IPv4 NAPT] 5) OS specific kludges, like Windows "Network Location Awareness" 6) manual admin config I don't find that very satisfactory. Unless of course someone else has a better option I've missed. I think this will be a problem for draft-ietf-homenet-arch-07 Section 3.2.2.2 B: Two ISPs, Two CERs, Shared subnet Figure 2 I think homenet is making an implicit assumption that ULA implies a stand alone /48 network, that is disconnected from everything else, so ULA should only be used for local communication as per rfc4193 section 4.6. Although that apparently isn't the only deployment scenario for ULA; such as the suggestion to use them for private communication between 2 enterprises (but not via public Internet), or ULA + NPTv6, or even ULA + NAPT. I think homenet is probably also making an implicit assumption that IPv4 RFC 1918 => IPv4 + NAPT >> So now the gateway device needs to send ICMP unreachables for every IPv6 >> connection towards the Internet I try. I find this problematic. >> > Expect in the scenario where multiple ULA's are used for backdoor connections between two (or more) private ULA networks, which also distribute GUA PA addresses per site to access the global Internet [I've seen that suggested as a deployment model for geographically spread enterprises who wish to have multiple local Internet breakouts, but do not want to use PI space] So that's also problematic to just always send an ICMP unreachable for non local /48 ULA. You have to make that decision on sending ICMP unreachable in combination with knowledge of the site topology, and what interfaces are "borders" to the Public Internet. regards, RayH From owen@delong.com Wed Mar 20 13:12:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EF711E8130 for ; Wed, 20 Mar 2013 13:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 WxZUTeLgN4aC for ; Wed, 20 Mar 2013 13:12:46 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id AE55C11E8127 for ; Wed, 20 Mar 2013 13:12:35 -0700 (PDT) Received: from [172.20.10.3] (27.sub-70-198-12.myvzw.com [70.198.12.27]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2KKAQMW001021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Mar 2013 13:10:30 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2KKAQMW001021 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363810231; bh=ZftEysZbv2JITmAbXy4/GI602ZI=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=1Clbt1cCinKRUUTwIGPmI4Mdyj8pJB0tu6jt+xfINarzDRh5MHoH9CG41Ytj30GHb CL1I2O4AszNVKaWeULXxrOb62tsO94m6ukgryjnkuZ/xxQdpyw8Xd70R3n3yLOW4M5 4JZEXlsO2xgSbqEARhWXy/7GSVIktYLevvkImIeo= References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <1363807338.52728.YahooMailNeo@web142501.mail.bf1.yahoo.com> Mime-Version: 1.0 (1.0) In-Reply-To: <1363807338.52728.YahooMailNeo@web142501.mail.bf1.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <62EC99DE-8F55-4E75-91C4-81F1241ED408@delong.com> X-Mailer: iPad Mail (10B146) From: Owen DeLong Date: Wed, 20 Mar 2013 15:10:24 -0500 To: Mark Smith X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 20 Mar 2013 13:10:31 -0700 (PDT) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 20:12:47 -0000 > Why is there no hope? You're effectively saying that the ULA specification= s won't ever be followed correctly, rather than far more often than not. Cou= ldn't the same be said about any and all specifications? Why would people fo= llow nearly all specifications correctly, with the ULA specification being t= he special case where they won't? ULA is not the lone specification. There are lots of specifications that get= ignored. However, there is an important distinction to consider here. Most specificat= ions are to be understood and implemented by protocol developers putting tho= se implementations into products. In the case of ULA, you're now talking abo= ut the need for a site administrator to follow the specification, In my expe= rience, there is a very wide range in terms of experience, capability, and m= otivation within this group, but it is overwhelmingly weighted towards the l= ow end (unmotivated, not very experienced, and unlikely to even read an RFC v= s. take their buddy's advice that "fd00::/8 for IPv6 works just like 10/8 fo= r IPv4". Owen From markzzzsmith@yahoo.com.au Wed Mar 20 13:23:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5254621F8573 for ; Wed, 20 Mar 2013 13:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] 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 vijRwF9XxIkx for ; Wed, 20 Mar 2013 13:23:50 -0700 (PDT) Received: from nm21.bullet.mail.bf1.yahoo.com (nm21.bullet.mail.bf1.yahoo.com [98.139.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 4C39121F8540 for ; Wed, 20 Mar 2013 13:23:50 -0700 (PDT) Received: from [98.139.212.150] by nm21.bullet.mail.bf1.yahoo.com with NNFMP; 20 Mar 2013 20:23:49 -0000 Received: from [98.139.212.224] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 20 Mar 2013 20:23:49 -0000 Received: from [127.0.0.1] by omp1033.mail.bf1.yahoo.com with NNFMP; 20 Mar 2013 20:23:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 687964.34099.bm@omp1033.mail.bf1.yahoo.com Received: (qmail 63339 invoked by uid 60001); 20 Mar 2013 20:23:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1363811029; bh=S2vZSHR66MFpRJd2Lj0ikBnAhGNZGy3nujkUu/+aLbk=; 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=HQfxNWUWvJJ5VeAXiYzzuMj4uxc8K+xEPUTpMHPOr3jo6DnzcdQrBt8MgsRXZBy6mtc2Rwso66Lo1k/9CcOifHMwUlNqoO+VXPvGcnTCrzIYbcsuclsYJHWlnlo4X6f+RB8ymyc9qlDov0sO0a8TtRAX+6FxlSLOu5yuDyDbbVU= 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=TtOQ177Rs3ce0VDYUs7PZod/6TdToQVmQWoCEHGzsRf0n37uf8Zgm1qjOqyrPSbU54p6n2GcvkUjv4Ybh921Ti8b4gIJGktEyJ/mi+M5d2CldoMKauvRlh00m7uYXnbkv23DCj5ODskFVJ9f8AMa8GK3HA+9DMS02f08kcJnSz0=; X-YMail-OSG: QNuAs0cVM1mzDFSs8nzUA7zYGNcLS5liOIvaBwFNV0mD2ed 8s1oDtOdSf0IYnnOt0Uds0SUzFB5rt1pZDKHw87IDuzO8KOXTmCAbzbNw6gC GgGlRqOBj4MUROKiHVfYgo2uW60MnYW2cSFlPPdDwnHFzAIyA4e2k9CZUXdh cQGm5obhZKOYUXYWeFfIzbjx.iQpAREAOPJkPbHCWSr59bEdab87Jp43_VQV h0QVluICBHc4vuDSgD3Urv5J5u9QOQmtjY6JKquyP92CE9Tqacj3zBJ0ndeq dqtJPxZBJg_.SOm96FA9x5jOhytvvH1exlOddLx22mwyn6m.LabTYgndEQcI ROgIUyWqPNuxu4VAQJUBR0pyqqFAM8H2aUVl8BkXnv6g.KCRwTiuPyG9AnR_ DLdThFqS_HYCTpbdEEMbkOAorDTsLeBcNEO5DtjAa9IdTXFI8Xi8JwFtulSz B_7wyAPDRVvnxV72U1sH_P_nKcf9_tZB4QpuLQDPO7WSc5o_iCr0J_56SiGr rv16fl2c94pSKiKsR Received: from [150.101.221.237] by web142502.mail.bf1.yahoo.com via HTTP; Wed, 20 Mar 2013 13:23:48 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBNaWthZWwgQWJyYWhhbXNzb24gPHN3bWlrZUBzd20ucHAuc2U.Cj4gVG86IE93ZW4gRGVMb25nIDxvd2VuQGRlbG9uZy5jb20.Cj4gQ2M6ICJ2Nm9wc0BpZXRmLm9yZyBXRyIgPHY2b3BzQGlldGYub3JnPgo.IFNlbnQ6IFRodXJzZGF5LCAyMSBNYXJjaCAyMDEzIDY6NDkgQU0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1saXUtdjZvcHMtdWxhLXVzYWdlLWFuYWx5c2lzCj4gCj4gT24gV2VkLCAyMCBNYXIgMjAxMywgT3dlbiBEZUwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.138.524 References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> Message-ID: <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> Date: Wed, 20 Mar 2013 13:23:48 -0700 (PDT) From: Mark Smith To: Mikael Abrahamsson In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 20:23:51 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Mikael Abrahamsson =0A> To: Owen DeLong =0A> Cc: "v6ops@ietf.org= WG" =0A> Sent: Thursday, 21 March 2013 6:49 AM=0A> Subject= : Re: [v6ops] draft-liu-v6ops-ula-usage-analysis=0A> =0A> On Wed, 20 Mar 20= 13, Owen DeLong wrote:=0A> =0A>> The IF pretty much covers it. IF there is= no GUA prefix and there is a GUA4 =0A> address or NAT44 based connectivity= ...=0A>> =0A>> The internet is a complex place.=0A> =0A> It's not even com= plex. I see recommendations for CPEs to start announcing =0A> ULAs even if = they have no GUA, or that ULAs should be announced even if the GUA =0A> pre= fix goes away. This will lead to broken connectivty as you say, bad user = =0A> experience, and I don't like this recommendation.=0A>=A0=0A=0AIt won't= lead to broken connectivity. ULAs are now preferred over GUAs in RFC6724, = and that only really matters is when you are given a choice of both a GUA a= nd a ULA. The only devices for which ULA and GUA AAAA records may be receiv= ed will be internal devices, and that could even be made selective by havin= g the DNS resolvers only hand ULA AAAA records to internal clients if neces= sary.=A0Internet devices should only have GUA AAAAs.=0A=0AThe local network= s will usually be more stable and reliable than the global network, mainly = because a local single party controls and operates the local network, where= as the global network (i.e. the Internet) is both much, much larger, and o= perated by many different parties. Having both a local and global address s= pace, and preferring the local addresses over the global ones when both are= available, further makes the local network more reliable and independent o= f the state of the global network.=0A=0A=0A> -- Mikael Abrahamsson=A0 =A0 e= mail: swmike@swm.pp.se=0A=0A> _____________________________________________= __=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailm= an/listinfo/v6ops=0A> From fred@cisco.com Wed Mar 20 13:41:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4224311E80F2 for ; Wed, 20 Mar 2013 13:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.463 X-Spam-Level: X-Spam-Status: No, score=-110.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 MwS5dpywjQYt for ; Wed, 20 Mar 2013 13:41:14 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 770591F0C36 for ; Wed, 20 Mar 2013 13:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2425; q=dns/txt; s=iport; t=1363812074; x=1365021674; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rgTX/7y6keTw0UiZWFNouY3ycMxcLJk4AEcSysChDTg=; b=UjmHfIp3WcWt2fEzJ/h0E7zMt1GHxVZTePaFR4qUXNMOKBUbEzhDzYoZ aR9lNmgpgoEvTyW0DNZfCKc3yGkcZ0WRe2yERvbveI4mAn/lm3pnOjxPS utxrKKw8yghRICyxmSd8uiVcFl1HaC0NroWMOsyNrnkZWQIGaPgeEPUJK Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJodSlGtJXG//2dsb2JhbABEDsUYgVIWdIIkAQEBAwE6PwULAgEIDhQUEDIlAgQOBQiIBgbCWI5cAjEHgl9hA6digks/gig X-IronPort-AV: E=Sophos;i="4.84,880,1355097600"; d="scan'208";a="189735621" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 20 Mar 2013 20:41:14 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2KKfDVj006829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Mar 2013 20:41:13 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Wed, 20 Mar 2013 15:41:13 -0500 From: "Fred Baker (fred)" To: Tim Chown Thread-Topic: [v6ops] draft-liu-v6ops-ula-usage-analysis Thread-Index: AQHOJatCxJx74lD4lEaSCUCJIGmeyg== Date: Wed, 20 Mar 2013 20:41:12 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B7DDA6D@xmb-rcd-x09.cisco.com> References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.146.87] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ray Hunter , v6ops WG Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 20:41:15 -0000 On Mar 20, 2013, at 12:42 AM, Tim Chown wrote: > While some of us have been using them in various contexts, unless we hear= of widescale, significant deployments, it's difficult to argue for BCP. I agree, and yet I scratch my head. How wide-scale can one possibly deploy = a prefix that is only usable within a domain? How likely are you to hear ab= out it outside of that domain? If there were a single statement that I might expect a BCP to make about UL= As, it would be along the lines of a comment I made a week or so ago: a ULA= is by definition a prefix that is never advertised outside a given domain,= and is used within that domain by agreement of those networked by the doma= in. The purpose for which they do so is more or less irrelevant, although e= xamples of such use (usually with RFC 1918 space) in existing networks migh= t point in reasonable directions.=20 The value of a prefix that is not advertised outside a domain tends to be i= n hiding something, and making it unreachable, from networks outside the do= main. The b2b example in the draft has them hiding the actual identities of= equipment in companies that are different but have operating agreements fo= r specific purposes, for example, and using them to address equipment that = would otherwise need to be filtered at a firewall eliminates the firewall r= ule. I hear a lot of "we don't need no stinking firewalls"; OK, if you want= to get rid of them, provide an alternative that meets people's stated conc= erns. If we can't make a statement along those lines, it seems like the other sta= tement a BCP could make is "please don't deploy ULAs, ever, for any reason"= . I think we might have an equally hard time coming to consensus on that; t= hey were created for a reason, and the reason wasn't NATs. I think the primary issue that people are really raising here is "please do= n't NAT". IMHO, there are already NAT66 products out there, and I have cust= omers chomping at the bit to deploy them. I agree that stateful NAT was at = best an evil we chose to live with. I'm not sure that complaining about the= m will make them go away. But in a world without NATs, there are still vali= d uses for a prefix that is advertised only within a bounded domain. I do w= onder why we are so bent on tossing the baby while we complain about the ba= thwater. = From owen@delong.com Wed Mar 20 13:51:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E10611E80F1 for ; Wed, 20 Mar 2013 13:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, MIME_QP_LONG_LINE=1.396] 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 CqliqVdLUSQf for ; Wed, 20 Mar 2013 13:51:11 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7C61111E80E7 for ; Wed, 20 Mar 2013 13:51:11 -0700 (PDT) Received: from [10.211.26.149] (mobile-198-228-235-110.mycingular.net [198.228.235.110]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2KKnETA002251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Mar 2013 13:49:16 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2KKnETA002251 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363812557; bh=9jj1SCLAuIbWDqrV03AVzRkAJSI=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=kgt+H8WjANMLcH57Aja633w3Q497Twb5Ir7RXn7B7cykz/KFN/FNCsQzOqjpuYS5f JuBAViI0TPiKQoiFh/FxqVj0/TFADXkbjoSLHpyZbeytGjPAQSKbpgJ80NdYm9/mEA GfxT0zcS+6ed6lWeTz8xzHb5x+kUpvjTV+i43mGg= References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149C642.6060806@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5149C642.6060806@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <481173D1-2F02-4B80-8E2C-BE33009EF2C9@delong.com> X-Mailer: iPad Mail (10B146) From: Owen DeLong Date: Wed, 20 Mar 2013 15:49:12 -0500 To: Alexandru Petrescu X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 20 Mar 2013 13:49:17 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 20:51:12 -0000 Sent from my iPad On Mar 20, 2013, at 9:22 AM, Alexandru Petrescu wrote: > Le 20/03/2013 14:18, Owen DeLong a =C3=A9crit : > [...] >>> Well, then you have different concerns about disconnected >>> operation. >>>=20 >>=20 >> How so? GUA is a perfectly fine alternative for disconnected >> operation. >=20 > YEs and no. >=20 > GUA (Global Unicast Addresses) is a good temptation to be used in all > cases, even in disconnected operation. >=20 > But, one should consider the cases of re-connection of moving networks > at different places in the Internet, successively. >=20 How is GUA not an ideal candidate for this? Seems to me that is the poster c= hild for PI GUA. > In these cases there may be a risk, because a GUA is valid only at one > topological place. Moving elsewhere one should use a different GUA. >=20 No, a GUA can be portable or non-portable. > Should we allow two vehicles which have GUAs and meet each other to talk > to each other directly? At that point would topological correctness > still be respected with respect to ingress filtering? (what if one of > the vehicles _is_ connected to the Internet). Seems to me that this is an ideal application for either BGP or MIP, dependi= ng on the various factors involved in the nature of the communication betwee= n those vehicles and/or their other topological relationships. Perhaps even a= combination of BGP and MIP. > (I am not saying that ULA completely solves this, but that the use of > GUA in disconnected operation may be a less tempting invitation). ULA does not provide any benefits over GUA in this context. Owen From owen@delong.com Wed Mar 20 14:02:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D5E21F8AAC for ; Wed, 20 Mar 2013 14:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.703 X-Spam-Level: X-Spam-Status: No, score=-1.703 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 oJxDDMOd5h0n for ; Wed, 20 Mar 2013 14:02:13 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 8036D21F8AA6 for ; Wed, 20 Mar 2013 14:02:13 -0700 (PDT) Received: from [10.211.26.149] (mobile-198-228-235-110.mycingular.net [198.228.235.110]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2KKwpoP002499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Mar 2013 13:59:57 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2KKwpoP002499 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363813198; bh=0i0hzm8lBoOa72dw3ejULEKb1B4=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=x8bKQdpk1U6n/1Fos1DNr1GbqeGs/f4jkGZZsEyAZsb6UBsAVfW4n6jkSrgMpzWfS hpfbcBGXBuiFv5QzYka2jK1hq+991E4Ah8CBGkzuqBS169jiG83Eeif7CDw/xhzS14 59SPmvwRBjn1jST9FUkAiOWlkAprhGb4r1lGTyKU= References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149D452.8020209@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1BC0FF42-A6A8-4962-981A-90792FC306FA@delong.com> X-Mailer: iPad Mail (10B146) From: Owen DeLong Date: Wed, 20 Mar 2013 15:59:50 -0500 To: Tim Chown X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 20 Mar 2013 13:59:58 -0700 (PDT) Cc: "v6ops@ietf.org Operations" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 21:02:14 -0000 Sent from my iPad On Mar 20, 2013, at 10:26 AM, Tim Chown wrote: > On 20 Mar 2013, at 15:22, Brian E Carpenter w= rote >> On 20/03/2013 13:18, Owen DeLong wrote: >> ... >>>=20 >>> Yes, GUA is a perfectly fine choice of addressing for such contexts and U= LA offers no advantage over GUA other than avoiding RIR interactions/fees. >>=20 >> I think that may prove to be a significant advantage when applied, say, t= o 5 billion >> home networks that don't want to be beholden to an incumbent telco. But t= hat is better >> argued in homenet. >=20 > The homenet arch text states that it assumes homenets would never receive P= I, so the RIR interactions/fees are purely to the homenet provider/ISP, as p= art of its own allocation. >=20 Too late... I already know of at least a few homenets that are running with I= Pv6 PI. > ULA-C would be a different thing. But is currently in cryo-freeze and the k= ey thrown away. That is NOT a bad thing IMHO. Owen From owen@delong.com Wed Mar 20 14:03:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4254C11E80F9 for ; Wed, 20 Mar 2013 14:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, SARE_MILLIONSOF=0.315] 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 VqDsJB5hqN11 for ; Wed, 20 Mar 2013 14:03:00 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C49F911E80F4 for ; Wed, 20 Mar 2013 14:03:00 -0700 (PDT) Received: from [10.211.26.149] (mobile-198-228-235-110.mycingular.net [198.228.235.110]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2KKwpoO002499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Mar 2013 13:58:55 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2KKwpoO002499 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363813136; bh=ABm7cz1fRMP+Nu7rnXTfiSyJfJg=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=2BqhHC/ZuN3/HO/zcU+1Sl+Jh8ioIwfyABRWGHkcXsvMC+qM5oCKUeLZMdFlIwsWP d4YChq39EafUeIphf9hTWn1RZyBMdvYQqCQMAvU5BInp1cqrP7b5JezkhxldilsjeA TfL7KUliLa4uofc3cRqIM7UI7f6rSmuvsdo6mnFk= References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149D452.8020209@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5149D452.8020209@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B146) From: Owen DeLong Date: Wed, 20 Mar 2013 15:58:51 -0500 To: Brian E Carpenter X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 20 Mar 2013 13:58:56 -0700 (PDT) Cc: "v6ops@ietf.org Operations" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 21:03:01 -0000 Sent from my iPad On Mar 20, 2013, at 10:22 AM, Brian E Carpenter wrote: > On 20/03/2013 13:18, Owen DeLong wrote: > ... >>=20 >> Yes, GUA is a perfectly fine choice of addressing for such contexts and U= LA offers no advantage over GUA other than avoiding RIR interactions/fees. >=20 > I think that may prove to be a significant advantage when applied, say, to= 5 billion > home networks that don't want to be beholden to an incumbent telco. But th= at is better > argued in homenet. >=20 > Brian I'm not sure about that. I think, actually, if those 5 billion homes (an int= eresting number for a planet with 7 billion people where the average househo= ld is 3.8 people, btw) were to go to the RIRs, the RIRs would be able to eng= age in a sufficient fee reduction as to make that relatively unimportant. Currently, for example, ARIN would cost $100/year for the user to get an IPv= 6 /48 block. This is based on having a few thousand end-user resources regis= tered. If that were to become millions of end-user resources, the cost would= probably drop to something closer to $20/year. Remember, the RIRs are not for profit entities. Larger quantities of end-use= r registrations should directly equate to lower fees. Owen From joelja@bogus.com Wed Mar 20 16:36:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D20921F8DE3 for ; Wed, 20 Mar 2013 16:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4ANpojqfwrV for ; Wed, 20 Mar 2013 16:36:35 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B82DB21F8DDF for ; Wed, 20 Mar 2013 16:36:35 -0700 (PDT) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r2KNaUp1072885 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 20 Mar 2013 23:36:31 GMT (envelope-from joelja@bogus.com) Message-ID: <514A47F9.4000806@bogus.com> Date: Wed, 20 Mar 2013 16:36:25 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Owen DeLong , Alexandru Petrescu References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <51497E49.5080101@gmail.com> <8F2B4F24-B759-4B81-A26D-3FF3D27700C3@delong.com> In-Reply-To: <8F2B4F24-B759-4B81-A26D-3FF3D27700C3@delong.com> 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, 20 Mar 2013 23:36:31 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 23:36:36 -0000 On 3/20/13 6:03 AM, Owen DeLong wrote: > Currently, there is no defined use of L-bit = 0 to the best of my knowledge. > > I believe that fc00::/8 sits "idle" as the IETF failed to designate a registry > structure and the ULA-registered draft expired without consensus. > Did not choose to, and failed to are somewhat different implications event if the effective result is the same. From owen@delong.com Wed Mar 20 17:22:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B435721F8CAA for ; Wed, 20 Mar 2013 17:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 IP8dZKCuM3lP for ; Wed, 20 Mar 2013 17:22:27 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 0123621F8B9C for ; Wed, 20 Mar 2013 17:22:26 -0700 (PDT) Received: from [10.7.13.159] (97-64-168-70.client.mchsi.com [97.64.168.70]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2L0HcNl008205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Mar 2013 17:17:41 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2L0HcNl008205 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363825063; bh=mwHWgNZWa4u6++ONj44h+WY8Siw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=t49Yr6K9xddQKjzx9zFODvIPVoX1SEFmFNS2n6ZqRjQzoaVd96Y4mDnOyREXABgWv MwGri3pmkikyb/Ii0pQmzIBq9sXusUDDHymcCyGKr2Drx1f/zeE73YSgu9i4o9CC8a QVo6oYjo9k7IXRusfwm6xnDxpsI2cVaph1tlVSEU= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: <514A47F9.4000806@bogus.com> Date: Wed, 20 Mar 2013 19:17:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <76818985-EB63-4A91-BF27-287AB025CC51@delong.com> References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <51497E49.5080101@gmail.com> <8F2B4F24-B759-4B81-A26D-3FF3D27700C3@delong.com> <514A47F9.4000806@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 20 Mar 2013 17:17:43 -0700 (PDT) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 00:22:27 -0000 On Mar 20, 2013, at 6:36 PM, joel jaeggli wrote: > On 3/20/13 6:03 AM, Owen DeLong wrote: >> Currently, there is no defined use of L-bit =3D 0 to the best of my = knowledge. >>=20 >> I believe that fc00::/8 sits "idle" as the IETF failed to designate a = registry >> structure and the ULA-registered draft expired without consensus. >>=20 > Did not choose to, and failed to are somewhat different implications = event if the effective result is the same. In what way? Owen From swmike@swm.pp.se Wed Mar 20 19:21:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C1321F88F7 for ; Wed, 20 Mar 2013 19:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.671 X-Spam-Level: X-Spam-Status: No, score=-1.671 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_41=0.6] 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 GgHu0nKsJ5Wj for ; Wed, 20 Mar 2013 19:21:54 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 4C21C1F0D21 for ; Wed, 20 Mar 2013 19:21:54 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id EA6B09C; Thu, 21 Mar 2013 03:21:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E1CAA9A; Thu, 21 Mar 2013 03:21:47 +0100 (CET) Date: Thu, 21 Mar 2013 03:21:47 +0100 (CET) From: Mikael Abrahamsson To: Mark Smith In-Reply-To: <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> Message-ID: References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-71882887-1363832507=:2309" Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 02:21:55 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-71882887-1363832507=:2309 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 20 Mar 2013, Mark Smith wrote: > It won't lead to broken connectivity. ULAs are now preferred over GUAs > in RFC6724, and that only really matters is when you are given a choice > of both a GUA and a ULA. The only devices for which ULA and GUA AAAA > records may be received will be internal devices, and that could even be > made selective by having the DNS resolvers only hand ULA AAAA records to > internal clients if necessary. Internet devices should only have GUA > AAAAs. You're missing the point. Host has ULA+RFC 1918 IPv4. User enters www.google.com into their non-HE browser. Gets AAAA+A DNS reply. Will this user be a happy user? I'm not worried about hosts that have ULA+GUA IPv6, I'm worried about the ones with only ULA IPv6 address and them trying to use this address to access IPv6 Internet instead of using their fully functional IPv4 address. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-71882887-1363832507=:2309-- From marka@isc.org Wed Mar 20 19:47:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CACBF1F0D1C for ; Wed, 20 Mar 2013 19:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.787 X-Spam-Level: X-Spam-Status: No, score=0.787 tagged_above=-999 required=5 tests=[AWL=-3.214, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_61=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] 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 61stDCMvWj-I for ; Wed, 20 Mar 2013 19:47:40 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id DE08211E80E8 for ; Wed, 20 Mar 2013 19:47:39 -0700 (PDT) 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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id AF0035F9891; Thu, 21 Mar 2013 02:47:28 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363834059; bh=TCkzxYx+D3Z+s5P+3XRPwLTll1Yg9u47jMyH5PEujhk=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Q2KZfCthPKhtmxa3uGa75SB5ZgOnD2MGv2xxzzir++3fXIPxwkZR5HZ+UvfrMzMXR aJyxsjjMXFNTRgpBBTFaXo4vuMVzx0CIm9JQHL3/hZuGl7yTnc7tYdbLJQtobYO5fI QUdp09MlgTsQduxDxS1qMHLlDx6k1AY3/CNXVkXg= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 8389E216C3B; Thu, 21 Mar 2013 02:47:26 +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 4C2A83145C43; Thu, 21 Mar 2013 13:47:24 +1100 (EST) To: Mikael Abrahamsson From: Mark Andrews References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> In-reply-to: Your message of "Thu, 21 Mar 2013 03:21:47 BST." Date: Thu, 21 Mar 2013 13:47:24 +1100 Message-Id: <20130321024724.4C2A83145C43@drugs.dv.isc.org> Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 02:47:42 -0000 In message , Mikael Abrahamsson writes: > On Wed, 20 Mar 2013, Mark Smith wrote: > > > It won't lead to broken connectivity. ULAs are now preferred over GUAs > > in RFC6724, and that only really matters is when you are given a choice > > of both a GUA and a ULA. The only devices for which ULA and GUA AAAA > > records may be received will be internal devices, and that could even be > > made selective by having the DNS resolvers only hand ULA AAAA records to > > internal clients if necessary. Internet devices should only have GUA > > AAAAs. > > You're missing the point. > > Host has ULA+RFC 1918 IPv4. User enters www.google.com into their non-HE > browser. Gets AAAA+A DNS reply. Will this user be a happy user? If they are not using a ossified browsers yes. It about time clients bit the bullet and fixed broken multi-homed support. This is a RFC 1123 requirement and in most cases not hard to do. Millions if not billions of dollars have been spent to work around these broken applications in the last 20 years. If browers, which are much more complicated than the normal client, can add good support for talking to multi-homed servers then just about any client can. Example C code is attached. Just pick if you want select/poll/thread based fast connections. Working through the *BSD/Linux base distribution to add fast failover would make a good Google Summer of Code project. Mark > I'm not worried about hosts that have ULA+GUA IPv6, I'm worried about the > ones with only ULA IPv6 address and them trying to use this address to > access IPv6 Internet instead of using their fully functional IPv4 address. > -- > Mikael Abrahamsson email: swmike@swm.pp.se -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org /* * Copyright (C) 2011 Internet Systems Consortium, Inc. ("ISC") * * Permission to use, copy, modify, and/or distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR * PERFORMANCE OF THIS SOFTWARE. */ /* * Initial timeout between connection attempts. The smaller this is the * more embryonic connection attempts that will be made. On each subsequent * connection attempt the timeout will be halved leading to all connection * attempts being initiated within 2 * TIMEOUT ms. * * 100 ms will let most intra continent connections succeed without a * embryonic connection. * 400 ms well let most intercontinental connections succeed without a * embryonic connection. */ #define TIMEOUT 100 /* 100 ms */ #define USE_THREADS 1 #define HAVE_POLL 1 #define TESTING 1 #if HAVE_POLL == 0 && TIMEOUT > 999 #define TIMEOUT 999 /* select() doesn't like tv_usec > 999999. */ #endif #include #include #if ! USE_THREADS #if HAVE_POLL #include #else #include #endif #endif #include #include #include #include #if ! USE_THREADS #include #endif #include #if USE_THREADS #include #endif #include #include #include #include #include #include static void print_trying(struct addrinfo *res, const char *trying) { char buf[sizeof("xxxx:xxxx:xxxx:xxxx:xxxx:125.123.123.123")] = "unknown family"; switch (res->ai_family) { case AF_INET: inet_ntop(AF_INET, &((struct sockaddr_in *)res->ai_addr)->sin_addr, buf, sizeof(buf)); break; case AF_INET6: inet_ntop(AF_INET6, &((struct sockaddr_in6 *)res->ai_addr)->sin6_addr, buf, sizeof(buf)); break; } printf("%s %s\n", trying, buf); } #if USE_THREADS struct common { pthread_mutex_t *mutex; pthread_cond_t *cond; int *count; int *fd; }; struct state { struct addrinfo *addrinfo; struct common *common; }; static void fatal(char *format, ...) { va_list ap; va_start(ap, format); vfprintf(stderr, format, ap); va_end(ap); abort(); } static void connect_to_address_cleanup(void *arg) { int *fd = arg; if (*fd != -1) close(*fd); } static void * connect_to_address(void *arg) { struct state *state = arg; struct addrinfo *addrinfo = state->addrinfo; struct common *common = state->common; int fd = -1, n; /* Ensure that fd is closed if we are canceled. */ pthread_cleanup_push(connect_to_address_cleanup, &fd); fd = socket(addrinfo->ai_family, addrinfo->ai_socktype, addrinfo->ai_protocol); if (fd < 0) { /* * If AI_ADDRCONFIG is not supported we will get EAFNOSUPPORT * returned. Silently ignore it. */ if (errno != EAFNOSUPPORT) perror("socket"); } else if (connect(fd, addrinfo->ai_addr, addrinfo->ai_addrlen) == -1) { perror("connect"); close(fd); fd = -1; } print_trying(state->addrinfo, "connected"); /* If we get here we want the rest of the thread to complete. */ n = pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL); if (n != 0) fatal("pthread_setcancelstate: %s", strerror(n)); n = pthread_mutex_lock(common->mutex); if (n != 0) fatal("pthread_mutex_lock: %s", strerror(n)); if (fd != -1 && *common->fd == -1) { /* Record success. */ *common->fd = fd; fd = -1; } *common->count -= 1; n = pthread_mutex_unlock(common->mutex); if (n != 0) fatal("pthread_mutex_unlock: %s", strerror(n)); pthread_cleanup_pop(1); /* Signal that we are done. */ n = pthread_cond_signal(common->cond); if (n != 0) fatal("pthread_cond_signal: %s", strerror(n)); pthread_exit(NULL); } int connect_to_host(struct addrinfo *res0) { struct addrinfo *res; int fd = -1, n, i, j, count; pthread_t *threads; struct state *state; int timeout = TIMEOUT * 1000; struct timespec timespec; pthread_cond_t cond; pthread_mutex_t mutex; struct common common; /* * Work out how many possible descriptors we could use. */ for (res = res0, count = 0; res; res = res->ai_next) count++; threads = calloc(count, sizeof(*threads)); state = calloc(count, sizeof(*state)); if (threads == NULL || state == NULL) { perror("calloc"); goto cleanup; } n = pthread_mutex_init(&mutex, NULL); if (n != 0) { fprintf(stderr, "pthread_mutex_init: %s", strerror(n)); goto cleanup; } n = pthread_cond_init(&cond, NULL); if (n != 0) { fprintf(stderr, "pthread_cond_init: %s", strerror(n)); goto cleanup_mutex; } common.fd = &fd; common.cond = &cond; common.count = &count; common.mutex = &mutex; /* * fd and count are protected by mutex. */ for (res = res0, i = 0, count = 0; res; res = res->ai_next) { bool done; state[i].common = &common; state[i].addrinfo = res; n = pthread_create(&threads[i], NULL, connect_to_address, &state[i]); if (n != 0) fprintf(stderr, "pthread_create: %s", strerror(n)); else { i++; n = pthread_mutex_lock(&mutex); if (n != 0) fatal("pthread_mutex_lock: %s", strerror(n)); count++; n = pthread_mutex_unlock(&mutex); if (n != 0) fatal("pthread_mutex_unlock: %s", strerror(n)); } print_trying(res, "trying"); done = false; do { n = pthread_mutex_lock(&mutex); if (n != 0) fatal("pthread_mutex_lock: %s", strerror(n)); /* No outstanding threads? */ if (count == 0) { /* Are we done? */ if (fd != -1 || res->ai_next == NULL) done = true; n = pthread_mutex_unlock(&mutex); if (n != 0) fatal("pthread_mutex_unlock: %s", strerror(n)); break; } if (res->ai_next != NULL) { struct timeval tv; n = gettimeofday(&tv, NULL); if (n != 0) fatal("gettimeofday: %s\n", strerror(errno)); timespec.tv_sec = tv.tv_sec; timespec.tv_nsec = (tv.tv_usec + timeout) * 1000; while (timespec.tv_nsec >= 1000000000) { timespec.tv_nsec -= 1000000000; timespec.tv_sec += 1; } n = pthread_cond_timedwait(&cond, &mutex, ×pec); } else n = pthread_cond_wait(&cond, &mutex); if (n == ETIMEDOUT) timeout >>= 1; else if (n != 0) fatal("pthread_cond_%swait: %s\n", res->ai_next != NULL ? "timed" : "", strerror(n)); if (fd != -1 || (count == 0 && res->ai_next == NULL)) done = true; n = pthread_mutex_unlock(&mutex); if (n != 0) fatal("pthread_mutex_unlock: %s", strerror(n)); } while (!done && res->ai_next == NULL); if (done) break; } /* Shutdown and tidy up all the threads we started. */ for (j = 0; j < i; j++) { n = pthread_cancel(threads[j]); if (n != 0 && n != ESRCH) fatal("pthread_cancel: %s\n", strerror(n)); n = pthread_join(threads[j], NULL); if (n != 0) fatal("pthread_join: %s\n", strerror(n)); } /* Cleanup the resources we used. */ n = pthread_cond_destroy(&cond); if (n != 0) fatal("pthread_cond_destroy: %s", strerror(n)); cleanup_mutex: n = pthread_mutex_destroy(&mutex); if (n != 0) fatal("pthread_mutex_destroy: %s", strerror(n)); cleanup: /* Free everything. */ if (threads) free(threads); if (state) free(state); return (fd); } #elif HAVE_POLL int connect_to_host(struct addrinfo *res0) { struct addrinfo *res, **info; int fd = -1, n, i, j, flags, count; struct pollfd *fds; int timeout = TIMEOUT; /* * Work out how many possible descriptors we could use. */ for (res = res0, count = 0; res; res = res->ai_next) count++; fds = calloc(count, sizeof(*fds)); info = calloc(count, sizeof(*info)); if (fds == NULL || info == NULL) { perror("calloc"); goto cleanup; } for (res = res0, i = 0, count = 0; res; res = res->ai_next) { print_trying(res); fd = socket(res->ai_family, res->ai_socktype, res->ai_protocol); if (fd == -1) { /* * If AI_ADDRCONFIG is not supported we will get * EAFNOSUPPORT returned. Behave as if the address * was not there. */ if (errno != EAFNOSUPPORT) perror("socket"); else if (res->ai_next != NULL) continue; } else if ((flags = fcntl(fd, F_GETFL)) == -1) { perror("fcntl"); close(fd); } else if (fcntl(fd, F_SETFL, flags | O_NONBLOCK) == -1) { perror("fcntl"); close(fd); } else if (connect(fd, res->ai_addr, res->ai_addrlen) == -1) { if (errno != EINPROGRESS) { perror("connect"); close(fd); } else { /* * Record the information for this descriptor. */ info[i] = res; fds[i].fd = fd; fds[i].events = POLLERR | POLLHUP | POLLIN | POLLOUT; count++; i++; } } else { /* * We connected without blocking. */ goto done; } if (count == 0) continue; do { if (res->ai_next == NULL) timeout = -1; n = poll(fds, i, timeout); if (n == 0) { timeout >>= 1; break; } if (n < 0) { if (errno == EAGAIN || errno == EINTR) continue; perror("poll"); fd = -1; goto done; } for (j = 0; j < i; j++) { if (fds[j].fd == -1 || fds[j].events == 0 || fds[j].revents == 0) continue; fd = fds[j].fd; if (fds[j].revents & POLLHUP || read(fd, NULL, 0) == -1) { close(fd); fds[j].fd = -1; fds[j].events = 0; info[j] = NULL; count--; continue; } /* Connect succeeded. */ goto done; } } while (timeout == -1 && count != 0); } /* We failed to connect. */ fd = -1; done: /* Close all other descriptors we have created. */ for (j = 0; j < i; j++) if (fds[j].fd != fd && fds[j].fd != -1) { close(fds[j].fd); } if (fd != -1) { /* Restore default blocking behaviour. */ if ((flags = fcntl(fd, F_GETFL)) != -1) { flags &= ~O_NONBLOCK; if (fcntl(fd, F_SETFL, flags) == -1) perror("fcntl"); } else perror("fcntl"); } cleanup: /* Free everything. */ if (fds != NULL) free(fds); if (info != NULL) free(info); return (fd); } #else int connect_to_host(struct addrinfo *res0) { struct addrinfo *res, **info; int fd = -1, n, i, j, flags, count, max = -1, *fds; struct timeval *timeout, timeout0 = { 0, TIMEOUT * 1000}; fd_set fdset, wrset; /* * Work out how many possible descriptors we could use. */ for (res = res0, count = 0; res; res = res->ai_next) count++; fds = calloc(count, sizeof(*fds)); info = calloc(count, sizeof(*info)); if (fds == NULL || info == NULL) { perror("calloc"); goto cleanup; } FD_ZERO(&fdset); for (res = res0, i = 0, count = 0; res; res = res->ai_next) { print_trying(res); fd = socket(res->ai_family, res->ai_socktype, res->ai_protocol); if (fd == -1) { /* * If AI_ADDRCONFIG is not supported we will get * EAFNOSUPPORT returned. Behave as if the address * was not there. */ if (errno != EAFNOSUPPORT) perror("socket"); else if (res->ai_next != NULL) continue; } else if (fd >= FD_SETSIZE) { close(fd); } else if ((flags = fcntl(fd, F_GETFL)) == -1) { perror("fcntl"); close(fd); } else if (fcntl(fd, F_SETFL, flags | O_NONBLOCK) == -1) { perror("fcntl"); close(fd); } else if (connect(fd, res->ai_addr, res->ai_addrlen) == -1) { if (errno != EINPROGRESS) { perror("connect"); close(fd); } else { /* * Record the information for this descriptor. */ info[i] = res; fds[i] = fd; FD_SET(fd, &fdset); if (max == -1 || fd > max) max = fd; count++; i++; } } else { /* * We connected without blocking. */ goto done; } if (count == 0) continue; assert(max != -1); do { if (res->ai_next != NULL) timeout = &timeout0; else timeout = NULL; /* The write bit is set on both success and failure. */ wrset = fdset; n = select(max + 1, NULL, &wrset, NULL, timeout); if (n == 0) { timeout0.tv_usec >>= 1; break; } if (n < 0) { if (errno == EAGAIN || errno == EINTR) continue; perror("select"); fd = -1; goto done; } for (fd = 0; fd <= max; fd++) { if (FD_ISSET(fd, &wrset)) { for (j = 0; j < i; j++) if (fds[j] == fd) break; assert(j < i); /* * Test to see if the connect * succeeded. */ n = read(fd, NULL, 0); if (n == -1) { close(fd); FD_CLR(fd, &fdset); fds[j] = -1; info[j] = NULL; count--; continue; } /* Connect succeeded. */ goto done; } } } while (timeout == NULL && count != 0); } /* We failed to connect. */ fd = -1; done: /* Close all other descriptors we have created. */ for (j = 0; j < i; j++) if (fds[j] != fd && fds[j] != -1) { close(fds[j]); } if (fd != -1) { /* Restore default blocking behaviour. */ if ((flags = fcntl(fd, F_GETFL)) != -1) { flags &= ~O_NONBLOCK; if (fcntl(fd, F_SETFL, flags) == -1) perror("fcntl"); } else perror("fcntl"); } cleanup: /* Free everything. */ if (fds) free(fds); if (info) free(info); return (fd); } #endif #if TESTING int main(int argc, char **argv) { int fd, n; struct timeval then, now; struct addrinfo hints, *res0; const char *hostname, *servname; hostname = "localhost"; if (argv[1]) hostname = argv[1]; servname = "http"; /* * Not all getaddrinfo() implementations support AI_ADDRCONFIG * even if it is defined. Retry without it on EAI_BADFLAGS. */ memset(&hints, 0, sizeof(hints)); hints.ai_family = PF_UNSPEC; hints.ai_socktype = SOCK_STREAM; hints.ai_protocol = IPPROTO_TCP; #ifdef AI_ADDRCONFIG hints.ai_flags = AI_ADDRCONFIG; #endif #ifdef AI_ADDRCONFIG again: #endif n = getaddrinfo(hostname, servname, &hints, &res0); if (n != 0) { #ifdef AI_ADDRCONFIG if (n == EAI_BADFLAGS && hints.ai_flags & AI_ADDRCONFIG) { hints.ai_flags &= ~AI_ADDRCONFIG; goto again; } #endif fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(n)); exit(1); } gettimeofday(&then, NULL); fd = connect_to_host(res0); gettimeofday(&now, NULL); freeaddrinfo(res0); now.tv_sec -= then.tv_sec; now.tv_usec -= then.tv_usec; while (now.tv_sec > 0) { now.tv_usec += 1000000; now.tv_sec -= 1; } fprintf(stderr, "connect_to_host(%s) -> %d in %d ms\n", hostname, fd, now.tv_usec/1000); close(fd); } #endif From markzzzsmith@yahoo.com.au Wed Mar 20 20:01:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E993011E80EE for ; Wed, 20 Mar 2013 20:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.96 X-Spam-Level: X-Spam-Status: No, score=0.96 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_33=0.6, J_CHICKENPOX_41=0.6] 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 knrWWiCO4IFs for ; Wed, 20 Mar 2013 20:01:08 -0700 (PDT) Received: from nm33-vm7.bullet.mail.bf1.yahoo.com (nm33-vm7.bullet.mail.bf1.yahoo.com [72.30.239.207]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB1211E80BA for ; Wed, 20 Mar 2013 20:01:08 -0700 (PDT) Received: from [98.139.212.152] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 21 Mar 2013 03:01:07 -0000 Received: from [98.139.212.205] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 21 Mar 2013 03:01:07 -0000 Received: from [127.0.0.1] by omp1014.mail.bf1.yahoo.com with NNFMP; 21 Mar 2013 03:01:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 947608.42477.bm@omp1014.mail.bf1.yahoo.com Received: (qmail 99372 invoked by uid 60001); 21 Mar 2013 03:01:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1363834867; bh=tXsOtB7vdBfYW9pK9qABrDWzppg6maLvSUO6dHHW2NM=; 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=SeDd0XvP4p7JA5w7wxzMlrU5U9hct0fBxOEkbnz/zDhqwMEyI9JfqhF/4jia9LbCRjYlUwf6QrWeM6YWUA1fP3EryMKMFfOvhANprTqUZPk8kFsPefc6XeQ3u6zY0Yt4jQTrYE0GmM0/KGaIL36vODB5yf2/AqBPzpQwDPpJ1qg= 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=umq8TUscpCXa2XEi9lBNjAWpAxBroe0kyMTIkaIB0/Abt8J79qwfjJSyP2k/3PT6IJgK6CL0UDlFOVTpP13s5W9qpNkVIYS6dTbOeOhF6lbKuiRlBS5DurXSslCrnUPuyCDAr1BP916ZJphc10DdlQmH/ERYy+D+3EEXH0b5yDs=; X-YMail-OSG: Fpb0v1MVM1l_jVZiuViUVUA2LpcaKot5trqgbdqNmIDaxhH MnKakPO7Eh0R2mwo0P5_wxioor08rD0sHR6XMLpOc1_lg4Gu490nHG9KCmxl U8sdoDxxRENB47GCc4_d_.VF.mTI5GOfurtakgLRBf5rA00jwAAvoVadXa4B VHaM4q9.rms7Q_E3QK4rD3560uoinEYE2.CSjqFprhKbfJt91W5x9BiJFD59 Nql8pk4AZXfzDFPGvtaoX0FQg7x6MSFK1h9yyUCxvcNYRKx6uQ1.Y.FB4pSL aC3J7M.NhLq0hPSdWGjKeK4558S__yOBS6C0Idu1x_oE6Ni6YBkAsU1Rqzek 1k2TOQAAHU6vh6kgqdrSd07FiLCF3PFtyPZaRuf3rE_Ucz9Ooc4geg2o.Vw3 axyax4YUMApMxYRf7S4vWgZ2vI9bAdETvdVB44nCWJkkjuHJroN_kHLi3wSQ 0ByvqVUKxiDbeYxDUwXdAh6JS413fo8q.dIi_TwsaIu4Im5mDpeUDNrYTSs_ mMfgKPAk1MCXIfKWax0A6xLe0kBsgydQWfkLIlpz0TiLLDwDo0kSNn1KCeIv Y6dvFEcAXtng4Uul5Rnoyre_z8w-- Received: from [121.200.231.211] by web142506.mail.bf1.yahoo.com via HTTP; Wed, 20 Mar 2013 20:01:07 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBNaWthZWwgQWJyYWhhbXNzb24gPHN3bWlrZUBzd20ucHAuc2U.Cj4gVG86IE1hcmsgU21pdGggPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU.Cj4gQ2M6ICJ2Nm9wc0BpZXRmLm9yZyBXRyIgPHY2b3BzQGlldGYub3JnPgo.IFNlbnQ6IFRodXJzZGF5LCAyMSBNYXJjaCAyMDEzIDE6MjEgUE0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1saXUtdjZvcHMtdWxhLXVzYWdlLWFuYWx5c2lzCj4gCj4gT24gV2VkLCAyMCBNYXIgMjAxMywBMAEBAQE- X-Mailer: YahooMailWebService/0.8.138.524 References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> Message-ID: <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> Date: Wed, 20 Mar 2013 20:01:07 -0700 (PDT) From: Mark Smith To: Mikael Abrahamsson In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 03:01:10 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Mikael Abrahamsson =0A> To: Mark Smith =0A> Cc: "v6ops= @ietf.org WG" =0A> Sent: Thursday, 21 March 2013 1:21 PM=0A= > Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis=0A> =0A> On Wed, = 20 Mar 2013, Mark Smith wrote:=0A> =0A>> It won't lead to broken connectiv= ity. ULAs are now preferred over GUAs =0A> in RFC6724, and that only really= matters is when you are given a choice of both =0A> a GUA and a ULA. The o= nly devices for which ULA and GUA AAAA records may be =0A> received will be= internal devices, and that could even be made selective by =0A> having the= DNS resolvers only hand ULA AAAA records to internal clients if =0A> neces= sary.=A0Internet devices should only have GUA AAAAs.=0A> =0A> You're missin= g the point.=0A> =0A> Host has ULA+RFC 1918 IPv4. User enters www.google.co= m into their non-HE =0A> browser. Gets AAAA+A DNS reply. Will this user be = a happy user?=0A>=A0=0A=0AYes. Their IPv6 router will generate an ICMPv6 de= stination unreachable as it doesn't have a route matching the AAAA (i.e. a = default route). That will cause the browser to fall back to IPv4. When I te= sted this scenario in around 2010/2011 (before HE), I couldn't perceive the= failure of IPv6 and fall back to IPv4.=0A=0A> I'm not worried about hosts = that have ULA+GUA IPv6, I'm worried about=A0=0A=0A> the ones with only ULA = IPv6 address and them trying to use this address to =0A> access IPv6 Intern= et instead of using their fully functional IPv4 address.=0A> =0A> -- Mikael= Abrahamsson=A0 =A0 email: swmike@swm.pp.se=0A> From marka@isc.org Wed Mar 20 20:49:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFB511E80F1 for ; Wed, 20 Mar 2013 20:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.383 X-Spam-Level: X-Spam-Status: No, score=-0.383 tagged_above=-999 required=5 tests=[AWL=-1.443, BAYES_20=-0.74, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_41=0.6] 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 rZ8-znu8j+SF for ; Wed, 20 Mar 2013 20:49:33 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 21FF211E80EE for ; Wed, 20 Mar 2013 20:49:33 -0700 (PDT) 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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 2EAEB5F98E4; Thu, 21 Mar 2013 03:49:21 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363837772; bh=sA7shtyAffxSiG7Ar96cWYRJcKflOy7AtoANKhiQ+vE=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=rpZjeCS2+14R0Grg4OwD/NMTy/56qtGIc69RBTF3UqsQ7j0+Z3QdRx0X7oT8POr97 0P5sX1zymOCP7cdKSdxkf0aC62Stlfg6k4rvmPcpP2s2H3F0BzihcrahBZXwbfvNO3 jbuvO5piG51YP92pTLidCn1+TjjJBIYYpEwKBG/c= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:7dc1:7bde:ed0f:15aa]) (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 256DD216C40; Thu, 21 Mar 2013 03:49:20 +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 71CCD3147294; Thu, 21 Mar 2013 14:49:17 +1100 (EST) To: Mikael Abrahamsson From: Mark Andrews References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> In-reply-to: Your message of "Thu, 21 Mar 2013 03:21:47 BST." Date: Thu, 21 Mar 2013 14:49:17 +1100 Message-Id: <20130321034917.71CCD3147294@drugs.dv.isc.org> Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 03:49:34 -0000 In message , Mikael Abraha msson writes: > This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware tools. > > ---137064504-71882887-1363832507=:2309 > Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed > Content-Transfer-Encoding: 8BIT > > On Wed, 20 Mar 2013, Mark Smith wrote: > > > It won't lead to broken connectivity. ULAs are now preferred over GUAs > > in RFC6724, and that only really matters is when you are given a choice > > of both a GUA and a ULA. The only devices for which ULA and GUA AAAA > > records may be received will be internal devices, and that could even be > > made selective by having the DNS resolvers only hand ULA AAAA records to > > internal clients if necessary. Internet devices should only have GUA > > AAAAs. > > You're missing the point. > > Host has ULA+RFC 1918 IPv4. User enters www.google.com into their non-HE > browser. Gets AAAA+A DNS reply. Will this user be a happy user? To simulate: "telnet -6 -s fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba www.isc.org 80" which terminates in 4 and a bit seconds. By comparison trying to reach a dead host take 80 odd seconds before connect fails. Yes, my border router is configured to send back destination unreachable if a packet with a ULA source address tries to leave the site. 14:30:18.560162 IP6 fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba.63723 > 2001:4f8:0:2::d.80: Flags [S], seq 3326326525, win 65535, options [mss 1440,nop,wscale 4,nop,nop,TS val 741847151 ecr 0,sackOK,eol], length 0 14:30:18.564477 IP6 fd92:7065:b8e::2e0:29ff:fe19:c02d > fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba: ICMP6, destination unreachable, unreachable prohibited 2001:4f8:0:2::d, length 92 14:30:19.568588 IP6 fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba.63723 > 2001:4f8:0:2::d.80: Flags [S], seq 3326326525, win 65535, options [mss 1440,nop,wscale 4,nop,nop,TS val 741848154 ecr 0,sackOK,eol], length 0 14:30:19.574571 IP6 fd92:7065:b8e::2e0:29ff:fe19:c02d > fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba: ICMP6, destination unreachable, unreachable prohibited 2001:4f8:0:2::d, length 92 14:30:20.672196 IP6 fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba.63723 > 2001:4f8:0:2::d.80: Flags [S], seq 3326326525, win 65535, options [mss 1440,nop,wscale 4,nop,nop,TS val 741849247 ecr 0,sackOK,eol], length 0 14:30:20.673569 IP6 fd92:7065:b8e::2e0:29ff:fe19:c02d > fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba: ICMP6, destination unreachable, unreachable prohibited 2001:4f8:0:2::d, length 92 14:30:21.781097 IP6 fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba.63723 > 2001:4f8:0:2::d.80: Flags [S], seq 3326326525, win 65535, options [mss 1440,nop,wscale 4,nop,nop,TS val 741850328 ecr 0,sackOK,eol], length 0 14:30:21.782564 IP6 fd92:7065:b8e::2e0:29ff:fe19:c02d > fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba: ICMP6, destination unreachable, unreachable prohibited 2001:4f8:0:2::d, length 92 14:30:22.886610 IP6 fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba.63723 > 2001:4f8:0:2::d.80: Flags [S], seq 3326326525, win 65535, options [mss 1440,nop,wscale 4,nop,nop,TS val 741851408 ecr 0,sackOK,eol], length 0 14:30:22.887977 IP6 fd92:7065:b8e::2e0:29ff:fe19:c02d > fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba: ICMP6, destination unreachable, unreachable prohibited 2001:4f8:0:2::d, length 92 Now we all have networks. We can all test out our assumptions. > I'm not worried about hosts that have ULA+GUA IPv6, I'm worried about the > ones with only ULA IPv6 address and them trying to use this address to > access IPv6 Internet instead of using their fully functional IPv4 address. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > ---137064504-71882887-1363832507=:2309 > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > ---137064504-71882887-1363832507=:2309-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From swmike@swm.pp.se Wed Mar 20 21:30:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEAB1F0D1C for ; Wed, 20 Mar 2013 21:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=0.342, 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 bepN7NcfIF2u for ; Wed, 20 Mar 2013 21:30:50 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 20BC021F8901 for ; Wed, 20 Mar 2013 21:30:49 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 43A929C; Thu, 21 Mar 2013 05:30:49 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3C15E9A; Thu, 21 Mar 2013 05:30:49 +0100 (CET) Date: Thu, 21 Mar 2013 05:30:49 +0100 (CET) From: Mikael Abrahamsson To: Mark Andrews In-Reply-To: <20130321034917.71CCD3147294@drugs.dv.isc.org> Message-ID: References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <20130321034917.71CCD3147294@drugs.dv.isc.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 04:30:51 -0000 On Thu, 21 Mar 2013, Mark Andrews wrote: > To simulate: "telnet -6 -s fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba > www.isc.org 80" which terminates in 4 and a bit seconds. By 4 seconds??? So any application without HE will need 4 seconds before timeouting and falling back to IPv4. Not to mention how chatty this is, imagine almost every connection the user makes towards the Internet (5 years into the future when "all" content providers have A+AAAA) will create 3-5 ICMP unreachables before falling back to IPv4. So the answer we in the IETF have is "fix your applications, they should use HE" and that's that? Personally I would like to hold off using ULA until we have a better solution. I imagine users will have a better Internet browsing experience disabling IPv6 on their hosts (which is what I would imagine would happen at an alarming rate). -- Mikael Abrahamsson email: swmike@swm.pp.se From owen@delong.com Wed Mar 20 22:20:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BA221F8F5D for ; Wed, 20 Mar 2013 22:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 8Kdh84uiwp5Z for ; Wed, 20 Mar 2013 22:20:59 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 405D121F8F6F for ; Wed, 20 Mar 2013 22:20:58 -0700 (PDT) Received: from [10.7.13.159] (97-64-168-70.client.mchsi.com [97.64.168.70]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2L5Hh6j014155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Mar 2013 22:17:47 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2L5Hh6j014155 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363843068; bh=HPZRqG//VvgFns29J7oopRsPkhQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=kIDy+otEj8ddj23vLt91vDsdAzaPwAYurrmo5cNk9zTa2BJHEZ9XFBwV6gZ9kxa+l e+pJA+rrp2lHs3KvOwuGz7xJh0GwQ8V7Cg4jaw2VXkSs0HZH+tzFmgP0TjaV14YhfK Wi74CWdyTdRaj1wzAu2Gcehc8KWrqUvyfQJyRIVM= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: Date: Thu, 21 Mar 2013 00:17:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7F0F3F2D-2705-413B-A548-A5C820044BC7@delong.com> References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <20130321034917.71CCD3147294@drugs.dv.isc.org> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 20 Mar 2013 22:17:48 -0700 (PDT) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 05:21:00 -0000 I will point out that this isn't a valid test. By using telnet -6 and/or -s fd=85 you force telnet to try only IPv6 = with no ability to fall back to IPv4. Without those flags, it is unlikely that it would have made multiple = IPv6 attempts before falling back to IPv4, but, rather would have made = one IPv6 attempt, then upon getting the unreachable, immediately try = IPv4. Owen On Mar 20, 2013, at 11:30 PM, Mikael Abrahamsson = wrote: > On Thu, 21 Mar 2013, Mark Andrews wrote: >=20 >> To simulate: "telnet -6 -s fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba >> www.isc.org 80" which terminates in 4 and a bit seconds. By >=20 > 4 seconds??? So any application without HE will need 4 seconds before = timeouting and falling back to IPv4. >=20 > Not to mention how chatty this is, imagine almost every connection the = user makes towards the Internet (5 years into the future when "all" = content providers have A+AAAA) will create 3-5 ICMP unreachables before = falling back to IPv4. >=20 > So the answer we in the IETF have is "fix your applications, they = should use HE" and that's that? >=20 > Personally I would like to hold off using ULA until we have a better = solution. I imagine users will have a better Internet browsing = experience disabling IPv6 on their hosts (which is what I would imagine = would happen at an alarming rate). >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From marka@isc.org Wed Mar 20 22:57:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9F521F8FC4 for ; Wed, 20 Mar 2013 22:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=0.488, 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 utdTmai8OTpb for ; Wed, 20 Mar 2013 22:57:33 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id ED5A621F8FAF for ; Wed, 20 Mar 2013 22:57:32 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 056CCC9428; Thu, 21 Mar 2013 05:57:26 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363845452; bh=0l2UltBCjWronTYodSk/f80ceYqpEH+KvZqVJAkJZ4A=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=UY1oLrMzaCspnSfQwW95r2CeN3ftOelW0TVkxTmkrEPS40qx8tQ7gMyzITB/MoJcz zV/caV8apQ+ut0AajXu6sa9+MlQXtLxbSf7NDqjuw/oqTc+vkzqTLebMaesqKBTF2D 7QnEJssoZJxFCLK+C4rX2L33Y2YLoGbI+zFurFC8= 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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Thu, 21 Mar 2013 05:57:26 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 7B9F8216C3B; Thu, 21 Mar 2013 05:57:25 +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 D14A13147E73; Thu, 21 Mar 2013 16:57:16 +1100 (EST) To: Mikael Abrahamsson From: Mark Andrews References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <20130321034917.71CCD3147294@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 21 Mar 2013 05:30:49 BST." Date: Thu, 21 Mar 2013 16:57:16 +1100 Message-Id: <20130321055716.D14A13147E73@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 05:57:33 -0000 In message , Mikael Abrahamsson writes: > On Thu, 21 Mar 2013, Mark Andrews wrote: > > > To simulate: "telnet -6 -s fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba > > www.isc.org 80" which terminates in 4 and a bit seconds. By > > 4 seconds??? So any application without HE will need 4 seconds before > timeouting and falling back to IPv4. Well if people didn't spoof icmp unreachables one would do. > Not to mention how chatty this is, imagine almost every connection the > user makes towards the Internet (5 years into the future when "all" > content providers have A+AAAA) will create 3-5 ICMP unreachables before > falling back to IPv4. FUD. Modern stacks can be configured to try IPv4 except when the target address in on the same ULA. Been there, done that. > So the answer we in the IETF have is "fix your applications, they should > use HE" and that's that? You need to fix the applications because they are broken. The stack already support what is needed. > Personally I would like to hold off using ULA until we have a better > solution. I imagine users will have a better Internet browsing experience > disabling IPv6 on their hosts (which is what I would imagine would happen > at an alarming rate). > > -- > Mikael Abrahamsson email: swmike@swm.pp.se -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Wed Mar 20 23:07:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E5A21F9023 for ; Wed, 20 Mar 2013 23:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 aBHi2for84YQ for ; Wed, 20 Mar 2013 23:07:54 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id EF11021F9025 for ; Wed, 20 Mar 2013 23:07:53 -0700 (PDT) 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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id E11555F98B6; Thu, 21 Mar 2013 06:07:43 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363846073; bh=rWGDpTDVhuZc2hCR/8CU+0tFUBVy7cMchhCtN0In9GQ=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=MrH+RqSKL6ZRP5yXo33mc6l4SGyNpg72a58sWF/eSWfdfCrSWK8BPeTZ0bSBUzHq3 NcYU+w9ZAwwIAROEimD4VyuQVUa3PIh8GtX43YYjNhGNVNlotajLgH70N0hirQATVz Q4Xs375LNmd685OeUWyDHwC6OmPfWqkpRQW7nZ0U= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:7dc1:7bde:ed0f:15aa]) (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 013E1216C3B; Thu, 21 Mar 2013 06:07:42 +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 52FD93148050; Thu, 21 Mar 2013 17:07:39 +1100 (EST) To: Owen DeLong From: Mark Andrews References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <20130321034917.71CCD3147294@drugs.dv.isc.org> <7F0F3F2D-2705-413B-A548-A5C820044BC7@delong.com> In-reply-to: Your message of "Thu, 21 Mar 2013 00:17:42 CDT." <7F0F3F2D-2705-413B-A548-A5C820044BC7@delong.com> Date: Thu, 21 Mar 2013 17:07:39 +1100 Message-Id: <20130321060739.52FD93148050@drugs.dv.isc.org> Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 06:07:55 -0000 In message <7F0F3F2D-2705-413B-A548-A5C820044BC7@delong.com>, Owen DeLong writes: > I will point out that this isn't a valid test. > > By using telnet -6 and/or -s fd=85 you force telnet to try only IPv6 = > with no ability to fall back to IPv4. I was showing the IPv6 timeout. > Without those flags, it is unlikely that it would have made multiple = > IPv6 attempts before falling back to IPv4, but, rather would have made = > one IPv6 attempt, then upon getting the unreachable, immediately try = > IPv4. > > Owen With modern stacks you just tell them to prefer the /48 ULA you are using and depreference all other ULA use. If I was to disable all other prefixes then IPv4 would be used for external connections. % cat /etc/ip6addrctl.conf #Prefix Prec Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff:0.0.0.0/96 35 4 fd92:7065:b8e::/48 45 5 fc00::/7 5 6 % Mark > On Mar 20, 2013, at 11:30 PM, Mikael Abrahamsson = > wrote: > > > On Thu, 21 Mar 2013, Mark Andrews wrote: > >=20 > >> To simulate: "telnet -6 -s fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba > >> www.isc.org 80" which terminates in 4 and a bit seconds. By > >=20 > > 4 seconds??? So any application without HE will need 4 seconds before = > timeouting and falling back to IPv4. > >=20 > > Not to mention how chatty this is, imagine almost every connection the = > user makes towards the Internet (5 years into the future when "all" = > content providers have A+AAAA) will create 3-5 ICMP unreachables before = > falling back to IPv4. > >=20 > > So the answer we in the IETF have is "fix your applications, they = > should use HE" and that's that? > >=20 > > Personally I would like to hold off using ULA until we have a better = > solution. I imagine users will have a better Internet browsing = > experience disabling IPv6 on their hosts (which is what I would imagine = > would happen at an alarming rate). > >=20 > > --=20 > > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From swmike@swm.pp.se Wed Mar 20 23:54:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4169A21F8CDD for ; Wed, 20 Mar 2013 23:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.326, 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 xpmxuxksKPIa for ; Wed, 20 Mar 2013 23:54:45 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id A30A721F8CD6 for ; Wed, 20 Mar 2013 23:54:45 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9AA689C; Thu, 21 Mar 2013 07:54:44 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8EF1B9A; Thu, 21 Mar 2013 07:54:44 +0100 (CET) Date: Thu, 21 Mar 2013 07:54:44 +0100 (CET) From: Mikael Abrahamsson To: Mark Andrews In-Reply-To: <20130321055716.D14A13147E73@drugs.dv.isc.org> Message-ID: References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <20130321034917.71CCD3147294@drugs.dv.isc.org> <20130321055716.D14A13147E73@drugs.dv.isc.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 06:54:46 -0000 On Thu, 21 Mar 2013, Mark Andrews wrote: >> Not to mention how chatty this is, imagine almost every connection the >> user makes towards the Internet (5 years into the future when "all" >> content providers have A+AAAA) will create 3-5 ICMP unreachables before >> falling back to IPv4. > > FUD. Modern stacks can be configured to try IPv4 except when the > target address in on the same ULA. Been there, done that. FUD? We're still talking about usage in a CPE in a residential setting, right? So, I deliver this CPE to grandma and she brings home her brand new Windows 8 laptop and connects it. How is what you describe configured automatically? > You need to fix the applications because they are broken. The stack > already support what is needed. I don't agree at all. IPv6 design has fundamental problems from the get-go and now we need to make this work. -- Mikael Abrahamsson email: swmike@swm.pp.se From markzzzsmith@yahoo.com.au Thu Mar 21 00:16:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1944C21F85A2 for ; Thu, 21 Mar 2013 00:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.27 X-Spam-Level: X-Spam-Status: No, score=-0.27 tagged_above=-999 required=5 tests=[AWL=1.230, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] 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 fuQfDMn5ZBGo for ; Thu, 21 Mar 2013 00:15:58 -0700 (PDT) Received: from nm6.bullet.mail.bf1.yahoo.com (nm6.bullet.mail.bf1.yahoo.com [98.139.212.165]) by ietfa.amsl.com (Postfix) with SMTP id 8556821F8589 for ; Thu, 21 Mar 2013 00:15:58 -0700 (PDT) Received: from [98.139.215.142] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 21 Mar 2013 07:15:58 -0000 Received: from [98.139.212.199] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 21 Mar 2013 07:15:57 -0000 Received: from [127.0.0.1] by omp1008.mail.bf1.yahoo.com with NNFMP; 21 Mar 2013 07:15:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 941324.2586.bm@omp1008.mail.bf1.yahoo.com Received: (qmail 52961 invoked by uid 60001); 21 Mar 2013 07:15:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1363850157; bh=rN2NIz34FV7tB0Fc6vZG5n41+5iDq/rw8cfLSaJeCqc=; 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=V0BQuFBTXMb9gdYtw2az1iYgm3Dw1zqi4nUDrK30cM73750H92DoLbtJEMsABapdEiGpmtRgZdpfjVy8NzkNfC7BGpfKYnxVmBXW7QbT12OGIa43Z+OMZ35z1DPcQPTNQFG1RseRVfqYNa+68vX16pZzhwLOouz/Kj9rsaJKBu4= 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=jAgt0NeeBQT3TxBNMLoFhs9Q9QUva8W5gqIYWge83oDIPBQZgTso8IrHpqchRJ1d9yj28grYLcDabfhMAbNIXfSOaJYPa9Xo+6dNQ+nDJPJogUsPetODD+/IS7KlJXoZ/anWDPpsrQNZJP7Tn/9+JLWM/GK40KJEmTf0O4ogsAE=; X-YMail-OSG: wbWIgzMVM1k9uBbNcQ2W537AEdbHZhaph9.KpUp8QUYov1B cf9K_CChnp_r6JDcDKw8sO9V189bTBJdpvuqtalQmYQpgrXLJZ.xCD_oZKG. 13J.evnrH8_3uCd_wUR661SiFDgvLiU_vAIs5uihOkpH5SAvj5ml0kGXEE_9 NYvrPCfhrMrVCK59ilZ6dlEjY50Yj_5xc9WXiSqSl02Ri48j4KB7BTjTQjeX cnFDXvvKP_qIxOiKtFpctULOp8tKN4XmmZRNm7qiqf0tg7apm0HOyCz2Tb8u ArBLJCC8vY3Ij2z15vYw7fR.d5HG584jRnmMIKSIUibpJqRl.XndyIeMRPEH iu.1.G9BZfPjfFBz1QUhwZiGS634jcmVYJYGjuDndSJxn1HJoEi.oHrLKMI9 gqGQnYTvRkFo_5jKeyO3FAuk9zE30KVc.u6_Mz0S852GyqErKEzX7BvWaM9Y 0HKRoZ3kybbe_sMte5cpwaEJSsIsJNjNwt2FC1qxRgKwtmTNBTWXHsI5DCRH nJPLJreMSlCTFCwp50OFMi3XjNAoZk4Ebg8c3IsAOevgQXIKlV9oLituVQie 2ziLkk5oib_8qbnmK6wqjDs7j1ytt_cKDbrGnjIIEA0WgHP6NSU.o7sjZhYE uPzeKPCkmezEvBkWY4rfmEj4- Received: from [121.200.231.211] by web142504.mail.bf1.yahoo.com via HTTP; Thu, 21 Mar 2013 00:15:57 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBNaWthZWwgQWJyYWhhbXNzb24gPHN3bWlrZUBzd20ucHAuc2U.Cj4gVG86IE1hcmsgQW5kcmV3cyA8bWFya2FAaXNjLm9yZz4KPiBDYzogInY2b3BzQGlldGYub3JnIFdHIiA8djZvcHNAaWV0Zi5vcmc.Cj4gU2VudDogVGh1cnNkYXksIDIxIE1hcmNoIDIwMTMgNTo1NCBQTQo.IFN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWxpdS12Nm9wcy11bGEtdXNhZ2UtYW5hbHlzaXMKPiAKPiBPbiBUaHUsIDIxIE1hciAyMDEzLCBNYXJrIEFuZHIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.138.524 References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <20130321034917.71CCD3147294@drugs.dv.isc.org> <20130321055716.D14A13147E73@drugs.dv.isc.org> Message-ID: <1363850157.44965.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Thu, 21 Mar 2013 00:15:57 -0700 (PDT) From: Mark Smith To: Mikael Abrahamsson , Mark Andrews In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 07:16:03 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Mikael Abrahamsson =0A> To: Mark Andrews =0A> Cc: "v6ops@ietf.org = WG" =0A> Sent: Thursday, 21 March 2013 5:54 PM=0A> Subject:= Re: [v6ops] draft-liu-v6ops-ula-usage-analysis=0A> =0A> On Thu, 21 Mar 201= 3, Mark Andrews wrote:=0A> =0A>>> Not to mention how chatty this is, imagi= ne almost every connection the=0A>>> user makes towards the Internet (5 ye= ars into the future when =0A> "all"=0A>>> content providers have A+AAAA) w= ill create 3-5 ICMP unreachables before=0A>>> falling back to IPv4.=0A>> = =0A>> FUD.=A0 Modern stacks can be configured to try IPv4 except when the= =0A>> target address in on the same ULA.=A0 Been there, done that.=0A> =0A= > FUD? We're still talking about usage in a CPE in a residential setting, = =0A> right?=0A> =0A> So, I deliver this CPE to grandma and she brings home = her brand new Windows 8 =0A> laptop and connects it. How is what you descri= be configured automatically?=0A>=A0=0A=0AICMPv6 Destination Unreachables do= not have be enabled, they are standard IPv6 router functionality.=0A=0A>> = You need to fix the applications because they are broken.=A0 The stack =0A= > already support what is needed.=0A> =0A> I don't agree at all. IPv6 desig= n has fundamental problems from the get-go =0A> and now we need to make thi= s work.=0A>=A0=0A=0AIPv6 has been enabled by default on all new Internode c= ustomer's broadband connections for the last 18 months, and all CPE they've= sold have had it enabled by default. If IPv6 didn't work, the following fo= rum would be full of complaints:=0A=0Ahttp://forums.whirlpool.net.au/forum/= 68=0A=0A=0A=A0I understand the same thing has occurred with the Free.fr net= work in France.=0A=0A> -- Mikael Abrahamsson=A0 =A0 email: swmike@swm.pp.se= =0A> _______________________________________________=0A> v6ops mailing list= =0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman/listinfo/v6ops=0A> From swmike@swm.pp.se Thu Mar 21 00:20:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1EC21F901B for ; Thu, 21 Mar 2013 00:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.311, 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 hJDp9J7BqwHn for ; Thu, 21 Mar 2013 00:20:43 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id F0B9821F9013 for ; Thu, 21 Mar 2013 00:20:42 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3F10B9C; Thu, 21 Mar 2013 08:20:40 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 42E4E9A; Thu, 21 Mar 2013 08:20:40 +0100 (CET) Date: Thu, 21 Mar 2013 08:20:40 +0100 (CET) From: Mikael Abrahamsson To: Mark Smith In-Reply-To: <1363850157.44965.YahooMailNeo@web142504.mail.bf1.yahoo.com> Message-ID: References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <20130321034917.71CCD3147294@drugs.dv.isc.org> <20130321055716.D14A13147E73@drugs.dv.isc.org> <1363850157.44965.YahooMailNeo@web142504.mail.bf1.yahoo.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1404675244-1363850440=:2309" Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 07:20:43 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1404675244-1363850440=:2309 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 21 Mar 2013, Mark Smith wrote: >>> FUD.  Modern stacks can be configured to try IPv4 except when the >>> target address in on the same ULA.  Been there, done that. >> >> FUD? We're still talking about usage in a CPE in a residential setting, >> right? >> >> So, I deliver this CPE to grandma and she brings home her brand new Windows 8 >> laptop and connects it. How is what you describe configured automatically? >>   > > ICMPv6 Destination Unreachables do not have be enabled, they are standard IPv6 router functionality. That is not what I asked about. > IPv6 has been enabled by default on all new Internode customer's > broadband connections for the last 18 months, and all CPE they've sold > have had it enabled by default. If IPv6 didn't work, the following forum > would be full of complaints: I am not talking about generic IPv6 GUA. I am talking about the case where there is IPv6 ULA but not GUA, and IPv4 GUA or RFC1918 address. I have had IPv6 GUA with DHCPv6-PD at home since 2008-2009, I know it works just fine, thank you. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1404675244-1363850440=:2309-- From v6ops@globis.net Thu Mar 21 00:37:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278E921F8FFA for ; Thu, 21 Mar 2013 00:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyTY6hoKUiOd for ; Thu, 21 Mar 2013 00:37:16 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB5721F8D92 for ; Thu, 21 Mar 2013 00:37:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id C91208700B9; Thu, 21 Mar 2013 08:37:00 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMi40WZBraaZ; Thu, 21 Mar 2013 08:36:41 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id EE6F087007A; Thu, 21 Mar 2013 08:36:40 +0100 (CET) Message-ID: <514AB882.4020009@globis.net> Date: Thu, 21 Mar 2013 08:36:34 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <8C48B86A895913448548E6D15DA7553B7DDA6D@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B7DDA6D@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops WG Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 07:37:17 -0000 > Fred Baker (fred) > 20 March 2013 21:41 > > > > > I think the primary issue that people are really raising here is > "please don't NAT". IMHO, there are already NAT66 products out there, > and I have customers chomping at the bit to deploy them. I agree that > stateful NAT was at best an evil we chose to live with. I'm not sure > that complaining about them will make them go away. But in a world > without NATs, there are still valid uses for a prefix that is > advertised only within a bounded domain. I do wonder why we are so > bent on tossing the baby while we complain about the bathwater. > In my mind, the fundamental problem is the implied default route associated with NPTv6, NAPT and other NAT-like technologies. If you don't install an implied default route on end hosts, anyone using NAT-like technologies will suffer complete disconnection. If you do install an implied default route, everyone (including people who don't want to support NAT at all) are forced to bloat their code to deal with it for situations where a default route would be inappropriate (e.g. walled gardens advertising an RFC1918 or ULA only, but not offering global connectivity), or they'll suffer long connection times or timeouts. regards, RayH From alexandru.petrescu@gmail.com Thu Mar 21 00:54:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372FD21F9020 for ; Thu, 21 Mar 2013 00:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.186 X-Spam-Level: X-Spam-Status: No, score=-10.186 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_FR=0.35, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tP-A9sA+qeAR for ; Thu, 21 Mar 2013 00:54:51 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id A2B6421F8FB0 for ; Thu, 21 Mar 2013 00:54:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2L7sg4K014749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 08:54:42 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2L7sgrv000625; Thu, 21 Mar 2013 08:54:42 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2L7sctS031931; Thu, 21 Mar 2013 08:54:42 +0100 Message-ID: <514ABC93.3000608@gmail.com> Date: Thu, 21 Mar 2013 08:53:55 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Owen DeLong References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149EBE2.5000908@gmail.com> <0A02847A-F67C-4285-A540-8A7A6497ACF3@delong.com> In-Reply-To: <0A02847A-F67C-4285-A540-8A7A6497ACF3@delong.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 07:54:55 -0000 Le 20/03/2013 21:03, Owen DeLong a écrit : > > > Sent from my iPad > > On Mar 20, 2013, at 12:03 PM, Alexandru Petrescu > wrote: > >> Le 20/03/2013 16:54, Lorenzo Colitti a écrit : >>> On Wed, Mar 20, 2013 at 5:08 AM, Tim Chown >> > wrote: >>> >>> What worries me is that in non-zeroconf environments, or those >>> where manual override is possible, administrators will use >>> fc00::/48, as it's easier to type/remember. >> >> But not what the RFC says - it's wrong sysadmin. > > Which matters here in the ivory tower, but makes no difference in the > real world. In a sense yes, but what better could one do? DEsign a better way to generate this uniqueness? There are ways for that, like starting from truly unique application-specific immutable IDs which hardly ever experienced collisions (like MAC-based did). >>> Then you're back on a par with using 10.0.0.0/8 >>> . >>> >>> >>> But the unfortunate truth is that, really, ULA is no different >>> from 10/8. >>> >>> I see only one difference between ULA and 10/8. That difference >>> is *not* that ULAs are unique, because as you correctly note >>> above, there is no hope of them actually being unique in the real >>> world. >> >> So, Lorenzo, I wouldnt qualify it as strongly. There _is_ much >> hope. > > Only among overly optimistic idealists. There could be ways to be less idealistic and yet come up with unique ULAs in certain contexts. >> Anyone who tried to configure ULAs according to that RFC knows >> that there is some level of uniqueness guaranteed. > > > No, there is no level of uniqueness guaranteed. There is a > statistically high probability of uniqueness for those who deploy > ULA according to the RFC. Even there, there is no guarantee of any > level of uniqueness, just a strong probability. I think this statement assumes exclusively the suggested ULA generation algorithm in the RFC. But better algorithms could be made which remove that probability factor, in certain contexts. > However, the probability that the majority of administrators will > even read the ULA RFC (how many people do you think have actually > read RFC-1918 vs. the number that have deployed 10/8 or any other > RFC-1918 address? I'll give you a hint... Ask a bunch of > administrators which of the following are RFC-1918 addresses. If > it's not an open book test, I bet the results surprise you. I agree in a sense, I let myself surprised by that. But things could be done about it. > 172.16.5.3 Everyone will probably get this right. > 172.30.19.6 About half will get this wrong. > 172.32.99.7 The other half will get this wrong. > 172.80.15.7 About half of the ones that got the previous question wrong will > also get this one wrong. I got them all wrong at a quick view. I'd have to read the RFC1918 and find the prefix length of the 172. private addresses to do it right. Fortunately there's that RFC. >> (if one just tries to just try quickly ifconfig add fd::1/64 then >> it's probably not according to the RFC, which would want more digits there.) > > fd::1/64 isn't even ULA, but I wouldn't put it past administrators to think it is. Corrected. It's not fd::1/64 but fd00::1/64. > fd00::1/64, OTOH, will probably be the most common ULA gateway address. Let's put that in a document! State upfront that sysadmins should not assign fd00::1/64 on any interface (be that default or not) because it doesnt have enough intermediary bits such that to be unique - not an ULA by RFC. Alex > > Owen > > > From lorenzo@google.com Thu Mar 21 01:42:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD35A21F8F06 for ; Thu, 21 Mar 2013 01:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.975 X-Spam-Level: X-Spam-Status: No, score=-102.975 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, 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 zlxUbwryKyMa for ; Thu, 21 Mar 2013 01:42:17 -0700 (PDT) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id 2766F21F8783 for ; Thu, 21 Mar 2013 01:42:16 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id l10so2816081oag.16 for ; Thu, 21 Mar 2013 01:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=rsO0yDGWbOke10jdk26oVUL8ElfCOMwEjQNMIIe3FVM=; b=ajr9ftOocgEe3jd0V2ZJ6FFCaCqpUci4dEWjjpy+VwBsO9JG7ldWLjnuI3JA2r+n+0 XW6gCx6jxa/podwRx0Kmw6rFVm0RtoojJ4gFOtHFI5FUfiu3exXq+W6hg6HPmkBfAAVD hTeF+NIMwHoxvTHFbauzgDoOzukWyZeH3HINSfvdLm4h5rHmdwR45Ckjd693gQAtc8cL bLmukh24WeeVAoA4L6q2j3PxwYbx77wLE+xByNXZ19NJ9oHW1g8GcpSRcZbI+glWczHd 2HWJ162564QJwJoA/vVzQOeS6AHa5R8pvt++Lw85/tWBtA2Vhu3LRpzzmAv3U3HifONl DTJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=rsO0yDGWbOke10jdk26oVUL8ElfCOMwEjQNMIIe3FVM=; b=PRasOkKx4tedG0/PmOVmXbXsHQRwsKpiGO6sHIi9Y6hJg4Kz6fWpvZuwZn0TMZ0oQb XI8R+fuFmb+zy4BKmXpBrqY5uajEF6PccmM+k9HyzWF68vDz/zboNSoqW4KC6Nbs0kFB efKljhdaZGC8M+FsJuVjQPmCF+JPey1y1xtRA7nscF+5z6RnQXXEdYO6D8bj1aJKN/IZ 02tggAAKebKyh5hB9YOtouJHX7rwNxJxvK7bQThq106mHgnK4A10iIQghhwPXspfTV60 le9qDCdQ7BEiTGFYFK3BjNFK0dr1NxBuyzv2PLv1oKMaOa08Q3jFivabBNC9Horvp14T 5pGA== X-Received: by 10.182.79.194 with SMTP id l2mr1383415obx.76.1363855336425; Thu, 21 Mar 2013 01:42:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Thu, 21 Mar 2013 01:41:56 -0700 (PDT) In-Reply-To: <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> From: Lorenzo Colitti Date: Thu, 21 Mar 2013 01:41:56 -0700 Message-ID: To: Mark Smith Content-Type: multipart/alternative; boundary=089e0122ac4adb1f0304d86b509b X-Gm-Message-State: ALoCoQkmliuLb0CYkASuO8/yd6TryWsuUFfHYYZ+7o9yTGZHow99vEB0zMdaUmCA4AWF0mLL5CcfQcdSprV2TP12nOJ8hKTTT27iZ2JrYJx9wW/4UFpEdSUWlwVa00y9jbfB+67AKwVU1PNXGC+P785eFBoNEeiwUvuoapx0qftRkwfY21Hk2Yfz2yHWFXT0e6UuW4jjVckM Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 08:42:22 -0000 --089e0122ac4adb1f0304d86b509b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 20, 2013 at 8:01 PM, Mark Smith wrote: > Yes. Their IPv6 router will generate an ICMPv6 destination unreachable as > it doesn't have a route matching the AAAA (i.e. a default route). That will > cause the browser to fall back to IPv4. > Incorrect. RFC 1122, section 4.2.3.9: "Since these Unreachable messages indicate soft error conditions, TCP MUST NOT abort the connection". --089e0122ac4adb1f0304d86b509b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 20, 2013 at 8:01 PM, Mark Smith <mark= zzzsmith@yahoo.com.au> wrote:
<= div class=3D"gmail_quote">
Yes.= Their IPv6 router will generate an ICMPv6 destination unreachable as it do= esn't have a route matching the AAAA (i.e. a default route). That will = cause the browser to fall back to IPv4.

Incorrect. RFC 1122, section 4.2.3.9: "Since these Unreachable messages ind= icate soft error conditions, TCP MUST NOT abort the connection".
Thanks Doug.  Appreciate the comments.

Let's see what we can do to as you say, "provide a robust solution that won't require = changes to the installed base."
 
Thank= s,

Nalini Elkins
Inside Products, Inc.
(831) 659-83= 60
www.insidethestack.com

From: Doug Barton <dougb@dougbarton.us>
<= span style=3D"font-weight: bold;">To: v6ops@ietf.org
Sent: Tuesday, March 19, 2013 1:= 35 PM
Subject: Re: [v6= ops] draft-elkins-v6ops-ipv6-ipid-needed-00

=0AOne o= f the chief complaints from people who have considered implementing
IPv= 6, but have not done so yet, is that the IETF keeps tinkering with
the = protocol. Others much more knowledgeable than I have already pointed
ou= t the technical reasons why it would not be possible to implement the
I= PID field in the manner you describe in a way that is backwards
compati= ble with existing installations, and not doing it in a backwards
compat= ible way is a non-starter.

I have no small amount of sympathy for yo= ur concern, but it seems that
we're in the "that ship has already saile= d" territory unless you can
provide a robust solution that won't requir= e changes to the installed base.

Doug


On 03/19/2013 10:16= AM, Nalini Elkins wrote:
> I would wonder what the depth of the IPv6= implementation is.  And, what
> "sites" were talked to.
>=
> I, myself, have been worked in the corporate world for over 30 years and
> talk to multiple Fortune 1,000 companies daily.&= nbsp; I can tell you that a
> number are looking at their web sites &= amp; external access (but NOT their
> internal network).  A few= are looking at internal implementation, and
> quite a few are saying= "We have no plans to look at this".
>
> This whole discussion = points out the reasons that corporations need to
> be involved in IET= F - it will be good for both parties.  We are working
> on this!=
> Thanks,
>
> Nalini Elkins
> Inside Products, Inc= .
> (831) 659-8360
> www.insidethestack.com
>
> -------------= -----------------------------------------------------------
> *From:*= Joe Touch <touch@isi.edu>
> *To:* "Ackermann, Michael" <MAckermann@bcbsm.com>
> *Cc:* "v6ops@ietf.org" <v6ops@ietf.org>
> *Sent:* Tuesday, March 19, 2013 9:53 AM
> *Subject:* Re= : [v6ops] draft-elkins-v6ops-ipv6-ipid-needed-00
>
> Your view = of IPv6 deployment seems a bit dated.
>
> It might be useful to= take a look here:
>
> http://eggert.org/meter/ipv6
>
= > Joe

_______________________________________________
v6ops ma= iling list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops=


--089e0122ac4adb1f0304d86b509b-- From lorenzo@google.com Thu Mar 21 01:45:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E167421F8E2E for ; Thu, 21 Mar 2013 01:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIWLrjqUUKEK for ; Thu, 21 Mar 2013 01:45:03 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 78A7B21F8E1C for ; Thu, 21 Mar 2013 01:45:03 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id dn14so2613363obc.18 for ; Thu, 21 Mar 2013 01:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=zkSOM7VhA3/RtNvcO1R9ktHnabKDInV4uEw5Xfi0/4I=; b=kQOcWvbvEJDTQOGO8FtNxbxAd1roWOUSzkVILYTkjbpqzPkkHPRwTaQBR8PBzz3Dsy m9NNGmdCjFUIz3BfJkP+Z7CUUXISJwAb3qYz2A+ia+Ky5U57kxobnMpzjlD15jhUS3zs ibzvaWIgdlO2tOv8tQPOYDEkPCZqQypZTM+PP2wuatJietRRrcV976R7zlqh/rL4VPir o5vFRdvYy+CeIEJVCXEwscHmi+YQk8VLXAtH1q94150VXIMxpqZKLzChVyO9IbAjwb4B pjm+ts6sz/YNcdnJeHXjy5kFbXnH5Flgfb6C8zyoMChFbRZYpPdizz/1eTjbKLkIdnnJ naJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=zkSOM7VhA3/RtNvcO1R9ktHnabKDInV4uEw5Xfi0/4I=; b=Bd7Ln1k1/MI9u8ofqcyanSomzK656DBw+AeiS/7HH/eLWW9HR8I95tF684Zqc0ODA6 HykL6Q1XbZDE8AceEzKKSLSLX8l3BxUofVIiFq0FXsXcF3EM1gDvKgTb5NR+il4pLkrN VwCwkVX9uvB/4EY4BiY09Q3xys/n1IwjSqqiLzihgEobSAwOCF5Bx/5O2MO6EYwMgRwy bNwrrRCdl2qd18O0tFh/zH4KuXXCl5MHlocaD2sfsOUzsDUfIH8npr7tTXx0dGNa9JGO 2ernjdO6yNyYMfq7PVsVpjth4kOZ/VofJySxww5wwgLq/NSeT1aFhJgrKmMOKxQxtykK VTyA== X-Received: by 10.182.108.104 with SMTP id hj8mr6300961obb.44.1363855502952; Thu, 21 Mar 2013 01:45:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Thu, 21 Mar 2013 01:44:42 -0700 (PDT) In-Reply-To: <20130321024724.4C2A83145C43@drugs.dv.isc.org> References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <20130321024724.4C2A83145C43@drugs.dv.isc.org> From: Lorenzo Colitti Date: Thu, 21 Mar 2013 01:44:42 -0700 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=f46d0447a1e9c7c18704d86b5abf X-Gm-Message-State: ALoCoQnd1xnKXbGJzffBE+Lj5j6JlrBf9+R6mTBPjL+1fde6HqOVzo1ZAvyHEFKxk2PHp/6pZ+2mYSNpJOEOcHoFdmnENDx+QC/EYwwEa2RzeF710OehjnnbjbrGEyarwKYHhyD6F1kv0CSfQB5/wle4Bkd4ReQAv+Ovw5NkL8E8PAqv4wGbIYm8KZIhLNIRUcDW9QGrGIpJ Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 08:45:04 -0000 --f46d0447a1e9c7c18704d86b5abf Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 20, 2013 at 7:47 PM, Mark Andrews wrote: > Example C code is attached. Just pick if you want select/poll/thread > based fast connections. > Your example is 600 lines of code. looping through getaddrinfo() results is an order of magniture shorter. > #define TIMEOUT 100 /* 100 ms */ > Users don't want to wait 100ms on every connection. --f46d0447a1e9c7c18704d86b5abf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --f46d0447a1e9c7c18704d86b5abf-- From marka@isc.org Thu Mar 21 01:53:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291F421F8510 for ; Thu, 21 Mar 2013 01:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 9QAUinjG3EGP for ; Thu, 21 Mar 2013 01:53:42 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDF421F8FD1 for ; Thu, 21 Mar 2013 01:53:39 -0700 (PDT) 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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 802765F98E3; Thu, 21 Mar 2013 08:53:29 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363856018; bh=tPL1Z+DKpnmMmUqh9X5aldRo9x/kddiUX7TZlX16kPg=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=HVnNorytHkBQLADMtX7HAiwJ7W8/66wDmuI6q0OU8SCWrltGu/1+z+/iyovEYsyD+ kIJUQFCKJMVj9w92iAGT746k7sArlKonnT/DfL/jKtI7gDysXSQfR41ACcBZmms4t+ 3KS6Ef2vi+ZQIuMipZpFyjOdS5yyS2KTF44baWRg= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 A2E6C216C3B; Thu, 21 Mar 2013 08:53:27 +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 B1583314AC35; Thu, 21 Mar 2013 19:53:17 +1100 (EST) To: Lorenzo Colitti From: Mark Andrews References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> In-reply-to: Your message of "Thu, 21 Mar 2013 01:41:56 PDT." Date: Thu, 21 Mar 2013 19:53:17 +1100 Message-Id: <20130321085317.B1583314AC35@drugs.dv.isc.org> Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 08:53:47 -0000 In message , Lorenzo Colitti writes: > > On Wed, Mar 20, 2013 at 8:01 PM, Mark Smith wrote: > > > Yes. Their IPv6 router will generate an ICMPv6 destination unreachable as > > it doesn't have a route matching the AAAA (i.e. a default route). That will > > cause the browser to fall back to IPv4. > > > > Incorrect. RFC 1122, section 4.2.3.9: "Since these Unreachable messages > indicate soft error conditions, TCP MUST NOT abort the connection". No connection yet exists. A embrionic connection exists and has been shown port unreachables do reduce the connection timeout. Note this is moot when a the address selection table takes into account ULA properties. Configurable address selection tables have been part of the IPv6 spec since 2003 and have existed in implementations since then. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From lorenzo@google.com Thu Mar 21 01:58:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0278621F856E for ; Thu, 21 Mar 2013 01:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vW17pXNTWqNt for ; Thu, 21 Mar 2013 01:58:41 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7148B21F8514 for ; Thu, 21 Mar 2013 01:58:41 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id eh20so2548085obb.8 for ; Thu, 21 Mar 2013 01:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=2mlLxTNcxdbRdkbIzOeinlDWpolsTgryn7HOFEC/LG8=; b=OqYPEcp7byDYduYjAKF4DDfYNE2sImcDpE30liCQm9+sTUAV0+QtPvyI5418ZiHgnV OTWufzQi3CcBYnftmWsjqTYClQfEZjsR6Bfg1HrlYEzzq5fJwYrx2YJEKbWaL+Xo6mB3 EIrwPDLz4nUn0Z+WbQ13HSzWPLPbvOiCA/XIkeVCNtQqKBYmoL09iYz+K7+5xguXVCu4 Y2BNFUXyNSNklRAnF88eNIrzZjIxzJBWDgxOWllrXMhif8nAAPohteKvIp2rf1w4bPdd +WGmokzcHJUEpqTj4a/H9KGLyUMv1ERL5IcLZG5KgCs/IqUGly1iN7jD2WP6gh7SEyzb AxUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=2mlLxTNcxdbRdkbIzOeinlDWpolsTgryn7HOFEC/LG8=; b=kMmoyiKVkghEuFh5kz2uPFSF3YUnRHg1+yvnQvXAbl3ZoE/1ZZiPxw+YCSU4U+yBeD v1rAWOtXMjMfkpVJmAchKVJ//jCKOhRyKEyPWvrRGHc4o5IGzJOxdUMnnpph9GnEWSpv JoYG19wozCBGWLVCGTHV29tjr9E8pVC7fVP2fu7QGaWp5L3QSK7lleGWdSbWVaQIjubJ iT4kdXxGd+0zchKr9y+6f+tDwkdcKJHq3lddism14Pq4hhMAley3c0P27au5CcNyL6Yz fF/R8t4g+s0csofyBGruANBH2IAP13DB3qrjLW5Ep8eU53MbxpogtmkZpwFmLIPKTSvY ybaw== X-Received: by 10.60.3.200 with SMTP id e8mr6306517oee.94.1363856320976; Thu, 21 Mar 2013 01:58:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Thu, 21 Mar 2013 01:58:20 -0700 (PDT) In-Reply-To: <20130321085317.B1583314AC35@drugs.dv.isc.org> References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> From: Lorenzo Colitti Date: Thu, 21 Mar 2013 01:58:20 -0700 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=e89a8fb1f55e89828004d86b8b4e X-Gm-Message-State: ALoCoQmXN3BrWwYoAcQQA4I2T/FHnd5xPKk/hofxTTfE3L8GvPEdtRmPejF1GJxjnNHFFDvSGzTNxLiSj+G+R0eZl+jc1sbsUqexcm+sIlh28CUqljh48ZPgZyQW/ZKKZCywN+hyCoqe6voe7M9EQsLc29B5sPLGWLVm4vC2dopsl00lGJgfSin8jpRRFa2XXzqoY5FtMXct Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 08:58:42 -0000 --e89a8fb1f55e89828004d86b8b4e Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 21, 2013 at 1:53 AM, Mark Andrews wrote: > No connection yet exists. I disagree, but that doesn't matter. What does matter is that major implementations disagree. - Windows entirely ignores the unreachables - OS X (and iOS?) times out after four seconds The only major implementation that does what you say is Linux. > A embrionic connection exists and has been shown port unreachables do > reduce the connection timeout. Not really; see above. > Note this is moot when a the address selection table takes into > account ULA properties. > No implementation does this in its default configuration. > Configurable address selection tables have been part of the IPv6 > spec since 2003 and have existed in implementations since then. > If you configure them yourself (except on OS X/iOS where they're not supported at all), sure. --e89a8fb1f55e89828004d86b8b4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 21, 2013 at 1:53 AM, Mark Andrews <marka@isc.org<= /a>> wrote:
No connection yet exists.

I disagree,= but that doesn't matter. What does matter is that major implementation= s disagree.

- Windows entirely ignores the unreacha= bles
- OS X (and iOS?) times out after four seconds
<= br>
The only major implementation that does what you say is= Linux.
=A0
A embrionic connection exists and has=A0been shown port unreachables do red= uce the connection timeout.

Not reall= y; see above.
=A0
Note=A0this is moot when a the address selection table takes into account= =A0ULA properties.

No implementat= ion does this in its default configuration.
=A0
Configurable address selection tables have been part of the IPv6
spec since 2003 and have existed in implementations since then.

If you configure them yourself (except on OS= X/iOS where they're not supported at all), sure.
--e89a8fb1f55e89828004d86b8b4e-- From swmike@swm.pp.se Thu Mar 21 02:18:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A3921F8783 for ; Thu, 21 Mar 2013 02:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.297, 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 U51CdEc97F5h for ; Thu, 21 Mar 2013 02:18:48 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 552B021F8739 for ; Thu, 21 Mar 2013 02:18:48 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E6079A1; Thu, 21 Mar 2013 10:18:45 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D93E79C; Thu, 21 Mar 2013 10:18:45 +0100 (CET) Date: Thu, 21 Mar 2013 10:18:45 +0100 (CET) From: Mikael Abrahamsson To: Mark Andrews In-Reply-To: <20130321085317.B1583314AC35@drugs.dv.isc.org> Message-ID: References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 09:18:49 -0000 On Thu, 21 Mar 2013, Mark Andrews wrote: > Configurable address selection tables have been part of the IPv6 spec > since 2003 and have existed in implementations since then. What's the opposite of FUD? Wishful thinking? As stated before, this doesn't work for grandma. She needs the address selection table be remotely automatically provisioned. As far as I know, this is not the case in current implementations. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Thu Mar 21 02:29:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E3D21F8765 for ; Thu, 21 Mar 2013 02:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=0.285, 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 y-lj-v-HPJFD for ; Thu, 21 Mar 2013 02:29:51 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBBF21F8FAF for ; Thu, 21 Mar 2013 02:29:42 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3D5D49C; Thu, 21 Mar 2013 10:29:41 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 332739A; Thu, 21 Mar 2013 10:29:41 +0100 (CET) Date: Thu, 21 Mar 2013 10:29:41 +0100 (CET) From: Mikael Abrahamsson To: Mark Andrews In-Reply-To: Message-ID: References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 09:29:52 -0000 On Thu, 21 Mar 2013, Mikael Abrahamsson wrote: >From rfc6204bis: ULA-5: An IPv6 CE router MUST NOT advertise itself as a default router with a Router Lifetime greater than zero whenever all of its configured and delegated prefixes are ULA prefixes. Doesn't this make routed home useless as soon as the IPv6 Internet connectivity goes away? The ULAs won't get routed anymore (solving my problem), but it also makes the desired functionality (printer still works when ISP connection is down) go away as well. Right? -- Mikael Abrahamsson email: swmike@swm.pp.se From marka@isc.org Thu Mar 21 02:31:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEAB921F8FC4 for ; Thu, 21 Mar 2013 02:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.390, 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 wreW3zwWl01k for ; Thu, 21 Mar 2013 02:31:53 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id D5D8E21F8FB3 for ; Thu, 21 Mar 2013 02:31:52 -0700 (PDT) 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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 837775F988D; Thu, 21 Mar 2013 09:31:43 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363858312; bh=S8STvkKWmWad90/qT8jijYWpR9CyEtyMjoDIRsyGPIk=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Iq3SYtHWaClfxGOvQbuMc6gZHtQXb9TW4TvUZ9WcbD6P0+dyw/G1Dm6h7zRT7BdlM ZY8X9rzgjed+1OTTyWOmGyS1QwumoFNjX59kXGpKJ46v5N+yZqSgig2VlEwsNMBbgD hrsIL9w9++WBFPWhNzOmGHEIpBaryhv78G2azHEg= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 A8B16216C3B; Thu, 21 Mar 2013 09:31:41 +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 EF249314AE72; Thu, 21 Mar 2013 20:31:37 +1100 (EST) To: Lorenzo Colitti From: Mark Andrews References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <20130321024724.4C2A83145C43@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 21 Mar 2013 01:44:42 PDT." Date: Thu, 21 Mar 2013 20:31:37 +1100 Message-Id: <20130321093137.EF249314AE72@drugs.dv.isc.org> Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 09:31:57 -0000 In message , Lorenzo Colitti writes: > > On Wed, Mar 20, 2013 at 7:47 PM, Mark Andrews wrote: > > > Example C code is attached. Just pick if you want select/poll/thread > > based fast connections. > > > > Your example is 600 lines of code. looping through getaddrinfo() results is > an order of magniture shorter. My example had 3 different methods of connecting in it. Splitting the code out into the seperate methods. 226 poll-connect.c 248 select-connect.c 324 thread-connect.c http://users.isc.org/~marka/index.html As for the naive loop across getaddrinfo() results, that is how we are in this place to start with. One needs something smarter. You put the code in a library an call it. > > #define TIMEOUT 100 /* 100 ms */ > > Users don't want to wait 100ms on every connection. And users want us to repeal the laws of physics. 100 ms is reasonable amount of time to wait given the size of the planet and the speed of light. Remember this delay does not happen if the address selection table is properly configured. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From otroan@employees.org Thu Mar 21 02:37:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA00421F8E57 for ; Thu, 21 Mar 2013 02:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8Kb-T8J+Q6I for ; Thu, 21 Mar 2013 02:37:07 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD8C21F8E1C for ; Thu, 21 Mar 2013 02:37:07 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 5EB315EFD; Thu, 21 Mar 2013 02:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=+uGaBTs+XLikQeEgFu4NVtdbA0g=; b=oEktGtfOqMkOXPqC6x iBVSroIkbFzToYUXW4uS4dfbKlVy/A4BIVF0oFjhfGYhDTVUPP4RuCLnlZ8F0Rw/ IuGEkTpjg282ZBWKDFPEXgM5eK/HrCP6k+s34Mq0pRp+ps1FOPFrRoTztv/4cVw6 RFZLbxA5ssjU41NU8Rmega5CM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=lp7XMiaKK2RJ2a914wrEr/ekBkNpvN2W6XkeYjOfJCbFbXlYh9x 5DBe+aqdCxGCcqUbSIbAfveN2dmfgDzZcXDm2fDqaoEPoDmRqjmWdsHPdeqolGp0 SGIfqFAb8S8kjcZIPxuyzQFp0pcKeJpDdZ5NbEEsLYqrVQAxnZVxNQI4= Received: from dhcp-10-61-105-103.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id A6F2B5EF8; Thu, 21 Mar 2013 02:37:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: Date: Thu, 21 Mar 2013 10:37:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1499) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 09:37:12 -0000 Mikael, >> =46rom rfc6204bis: >=20 > ULA-5: An IPv6 CE router MUST NOT advertise itself as a default > router with a Router Lifetime greater than zero whenever all > of its configured and delegated prefixes are ULA prefixes. >=20 > Doesn't this make routed home useless as soon as the IPv6 Internet = connectivity goes away? The ULAs won't get routed anymore (solving my = problem), but it also makes the desired functionality (printer still = works when ISP connection is down) go away as well. Right? no, routing internally will still work. cheers, Ole= From marka@isc.org Thu Mar 21 02:42:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5793721F8EF2 for ; Thu, 21 Mar 2013 02:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.355, 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 z+nxTBce37fz for ; Thu, 21 Mar 2013 02:42:21 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 5122D21F8EE6 for ; Thu, 21 Mar 2013 02:42:21 -0700 (PDT) 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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 013D35F988D; Thu, 21 Mar 2013 09:42:10 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363858940; bh=Gk2dQHB8NzgefLxaW2di2ppaoT57Pzk3RCyaYSZZPPw=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=MWMXftGVqrwmwkrEkEdfaYYIrhIEL/NViHz72/67Go5lsq6cKw3e20dllklEmX7h/ FPQz93RUo0fEBJiX9KP8ENZaiTWsP74/+2PlqCE5jnxbil9xjAhJ8qQ+wScDK3vLZq OUNxumk8Ghwdfd4H83fxLnQ8JivB9EAKtfD7N3wM= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 133D1216C3B; Thu, 21 Mar 2013 09:42:09 +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 80104314AF45; Thu, 21 Mar 2013 20:42:05 +1100 (EST) To: Lorenzo Colitti From: Mark Andrews References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 21 Mar 2013 01:58:20 PDT." Date: Thu, 21 Mar 2013 20:42:05 +1100 Message-Id: <20130321094205.80104314AF45@drugs.dv.isc.org> Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 09:42:26 -0000 In message , Lorenzo Colitti writes: > > On Thu, Mar 21, 2013 at 1:53 AM, Mark Andrews wrote: > > > No connection yet exists. > > > I disagree, but that doesn't matter. What does matter is that major > implementations disagree. > > - Windows entirely ignores the unreachables > - OS X (and iOS?) times out after four seconds OS X takes 80 seconds to timeout the connection it there are no port unreachables. I measured it. > The only major implementation that does what you say is Linux. Yet the test was done on a OS X box. % time telnet -s 2001:470:1f00:820:7dc1:7bde:ed0f:15aa 2001:ffff::1 80 Trying 2001:ffff::1... telnet: connect to address 2001:ffff::1: Operation timed out telnet: Unable to connect to remote host 0.027u 0.013s 1:15.77 0.0% 0+0k 0+0io 0pf+0w % time telnet -s fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba 2001:4f8:0:2::d 80 Trying 2001:4f8:0:2::d... telnet: connect to address 2001:4f8:0:2::d: Connection refused telnet: Unable to connect to remote host 0.026u 0.012s 0:04.47 0.6% 0+0k 0+0io 0pf+0w % uname -a Darwin drugs.dv.isc.org 12.3.0 Darwin Kernel Version 12.3.0: Sun Jan 6 22:37:10 PST 2013; root:xnu-2050.22.13~1/RELEASE_X86_64 x86_64 % > > A embrionic connection exists and has been shown port unreachables do > > reduce the connection timeout. > > > Not really; see above. > > > > Note this is moot when a the address selection table takes into > > account ULA properties. > > > > No implementation does this in its default configuration. Defaults can change. > > Configurable address selection tables have been part of the IPv6 > > spec since 2003 and have existed in implementations since then. > > If you configure them yourself (except on OS X/iOS where they're not > supported at all), sure. Well we should complain to Apple. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From alexandru.petrescu@gmail.com Thu Mar 21 02:43:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5258721F8F1C for ; Thu, 21 Mar 2013 02:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.188 X-Spam-Level: X-Spam-Status: No, score=-10.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3Y6pdpplJ2K for ; Thu, 21 Mar 2013 02:43:21 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB3A21F8F02 for ; Thu, 21 Mar 2013 02:43:21 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2L9hKwe028038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 21 Mar 2013 10:43:20 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2L9hKCe028666 for ; Thu, 21 Mar 2013 10:43:20 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2L9h5EX018042 for ; Thu, 21 Mar 2013 10:43:19 +0100 Message-ID: <514AD5FE.2020705@gmail.com> Date: Thu, 21 Mar 2013 10:42:22 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 09:43:22 -0000 Le 21/03/2013 10:29, Mikael Abrahamsson a écrit : > On Thu, 21 Mar 2013, Mikael Abrahamsson wrote: > >> From rfc6204bis: > > ULA-5: An IPv6 CE router MUST NOT advertise itself as a default > router with a Router Lifetime greater than zero whenever all > of its configured and delegated prefixes are ULA prefixes. > > Doesn't this make routed home useless as soon as the IPv6 Internet > connectivity goes away? The ULAs won't get routed anymore (solving my > problem), but it also makes the desired functionality (printer still > works when ISP connection is down) go away as well. Right? In a sense I agree. This ULA-5 requirement forbids growth of large home-to-home networks. This ULA-5 requirement is wrong and shouldnt be there - neither for CPEs nor for anything else. A Router - any Router for that matter - should be able to be a default router, or not a default router, whenever it wants to, even though it has no connection to Internet. If this is not done (i.e. do not allow default routers when only ULA addresses are used) then the networks using exclusively ULA addressing can not scale to large size, because there may be too many routes at too many Routers. An advantage of using a default route is that it concentrates the many routes only in a few-places - the DFZ. Alex > From swmike@swm.pp.se Thu Mar 21 02:50:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D3221F8E1D for ; Thu, 21 Mar 2013 02:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=0.273, 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 WWuoqAiaI9Lj for ; Thu, 21 Mar 2013 02:50:00 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 32AB521F8574 for ; Thu, 21 Mar 2013 02:50:00 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E81E99C; Thu, 21 Mar 2013 10:49:58 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DF0699A; Thu, 21 Mar 2013 10:49:58 +0100 (CET) Date: Thu, 21 Mar 2013 10:49:58 +0100 (CET) From: Mikael Abrahamsson To: Ole Troan In-Reply-To: Message-ID: References: <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 09:50:00 -0000 On Thu, 21 Mar 2013, Ole Troan wrote: > Mikael, > >>> From rfc6204bis: >> >> ULA-5: An IPv6 CE router MUST NOT advertise itself as a default >> router with a Router Lifetime greater than zero whenever all >> of its configured and delegated prefixes are ULA prefixes. >> >> Doesn't this make routed home useless as soon as the IPv6 Internet connectivity goes away? The ULAs won't get routed anymore (solving my problem), but it also makes the desired functionality (printer still works when ISP connection is down) go away as well. Right? > > no, routing internally will still work. If Router Lifetime is zero (which it should be as soon as Internet connectivity goes down and now it's only ULA left), won't that invalidate the default route the clients have installed? -- Mikael Abrahamsson email: swmike@swm.pp.se From otroan@employees.org Thu Mar 21 02:53:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8CE421F902C for ; Thu, 21 Mar 2013 02:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsdCVZqaaBHS for ; Thu, 21 Mar 2013 02:53:42 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 37DFB21F9033 for ; Thu, 21 Mar 2013 02:53:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicNAIbXSlGQ/khM/2dsb2JhbABEgkMIwnCBWhZ0giQBAQQBOj8QCw44VwaIIQbCYo5eMweCX2EDp2aDCzs X-IronPort-AV: E=Sophos;i="4.84,884,1355097600"; d="scan'208";a="152031528" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2013 09:53:12 +0000 Received: from dhcp-10-61-105-103.cisco.com (dhcp-10-61-105-103.cisco.com [10.61.105.103]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2L9rCwq020696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Mar 2013 09:53:12 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: Date: Thu, 21 Mar 2013 10:53:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <892E03C7-623A-4AC3-9C9C-88F3489A06DD@employees.org> References: <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1499) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 09:53:43 -0000 Mikael, >>> ULA-5: An IPv6 CE router MUST NOT advertise itself as a default >>> router with a Router Lifetime greater than zero whenever = all >>> of its configured and delegated prefixes are ULA prefixes. >>>=20 >>> Doesn't this make routed home useless as soon as the IPv6 Internet = connectivity goes away? The ULAs won't get routed anymore (solving my = problem), but it also makes the desired functionality (printer still = works when ISP connection is down) go away as well. Right? >>=20 >> no, routing internally will still work. >=20 > If Router Lifetime is zero (which it should be as soon as Internet = connectivity goes down and now it's only ULA left), won't that = invalidate the default route the clients have installed? correct. that's why there is L-3. there will be more specific routes = advertised for the internal ULA prefix(es). cheers, Ole= From alexandru.petrescu@gmail.com Thu Mar 21 02:56:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240C021F8D51 for ; Thu, 21 Mar 2013 02:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.889 X-Spam-Level: X-Spam-Status: No, score=-9.889 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7kwzZBrZ6CQ for ; Thu, 21 Mar 2013 02:56:30 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 7E50921F8B51 for ; Thu, 21 Mar 2013 02:56:25 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2L9uO5J011448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 21 Mar 2013 10:56:24 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2L9uNg6002787 for ; Thu, 21 Mar 2013 10:56:24 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2L9uJTD031414 for ; Thu, 21 Mar 2013 10:56:23 +0100 Message-ID: <514AD918.3070208@gmail.com> Date: Thu, 21 Mar 2013 10:55:36 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <892E03C7-623A-4AC3-9C9C-88F3489A06DD@employees.org> In-Reply-To: <892E03C7-623A-4AC3-9C9C-88F3489A06DD@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 09:56:31 -0000 Le 21/03/2013 10:53, Ole Troan a écrit : > Mikael, > >>>> ULA-5: An IPv6 CE router MUST NOT advertise itself as a >>>> default router with a Router Lifetime greater than zero >>>> whenever all of its configured and delegated prefixes are ULA >>>> prefixes. >>>> >>>> Doesn't this make routed home useless as soon as the IPv6 >>>> Internet connectivity goes away? The ULAs won't get routed >>>> anymore (solving my problem), but it also makes the desired >>>> functionality (printer still works when ISP connection is down) >>>> go away as well. Right? >>> >>> no, routing internally will still work. >> >> If Router Lifetime is zero (which it should be as soon as Internet >> connectivity goes down and now it's only ULA left), won't that >> invalidate the default route the clients have installed? > > correct. that's why there is L-3. there will be more specific routes > advertised for the internal ULA prefix(es). Whenever there are specific routes it means it won't scale to large sizes. This is not good - it doesnt scale. Alex > > cheers, Ole _______________________________________________ v6ops > mailing list v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From otroan@employees.org Thu Mar 21 02:56:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D661221F9037 for ; Thu, 21 Mar 2013 02:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 RbAqNXT5eEY4 for ; Thu, 21 Mar 2013 02:56:42 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 8A74021F8AB7 for ; Thu, 21 Mar 2013 02:56:42 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 3E3065E61; Thu, 21 Mar 2013 02:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=pmCJk+f45jn6cZQIDEfjMJopvuM=; b=HbNyJv8OXl7ZVgvxzg yvCJJO0lkvSPGIZ278W7Co116Q3bOcdhHmnl69skyE5MXWKf+nD6SFu11/qn2XZb +5CCnqbK1yYa26z0ONpajGjOOuyyCpUbD3BkGHGYXcmjyfA95ZX1AQ+I6Co0QU5o fDrrFTpc2NdprjsRCQX95OXw0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=Ux8J4vj1z/+5rHAUpHfsLtcOmt6EIAnrwGE0iMn5HLw5PECJb6n UCy6qV2N2mCeMu8AKMEwUav7hetsf/aprKw9XIdinx7wl276SMPTSOP0tPDkt+nx 9tx/vm2A5Bb7T1cm5WtSXyTRfxQIeDFBzU1INBJOb9h+p+0cfitApypI= Received: from dhcp-10-61-105-103.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id A5DA65E5C; Thu, 21 Mar 2013 02:56:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <514AD5FE.2020705@gmail.com> Date: Thu, 21 Mar 2013 10:56:39 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> < 514AD5FE.2020705@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 09:56:59 -0000 >> ULA-5: An IPv6 CE router MUST NOT advertise itself as a default >> router with a Router Lifetime greater than zero whenever all >> of its configured and delegated prefixes are ULA prefixes. >> >> Doesn't this make routed home useless as soon as the IPv6 Internet >> connectivity goes away? The ULAs won't get routed anymore (solving my >> problem), but it also makes the desired functionality (printer still >> works when ISP connection is down) go away as well. Right? > > In a sense I agree. This ULA-5 requirement forbids growth of large > home-to-home networks. > > This ULA-5 requirement is wrong and shouldnt be there - neither for CPEs > nor for anything else. > > A Router - any Router for that matter - should be able to be a default > router, or not a default router, whenever it wants to, even though it > has no connection to Internet. > > If this is not done (i.e. do not allow default routers when only ULA > addresses are used) then the networks using exclusively ULA addressing > can not scale to large size, because there may be too many routes at too > many Routers. An advantage of using a default route is that it > concentrates the many routes only in a few-places - the DFZ. that's incorrect. see my reply to Mikael. check the earlier RFC6204 threads if you want history. cheers, Ole From marka@isc.org Thu Mar 21 02:58:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C69721F8D51 for ; Thu, 21 Mar 2013 02:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.34 X-Spam-Level: X-Spam-Status: No, score=-1.34 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 FOA8icahVFu7 for ; Thu, 21 Mar 2013 02:58:09 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id B810621F8AB7 for ; Thu, 21 Mar 2013 02:58:09 -0700 (PDT) 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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 1AF8C5F988D; Thu, 21 Mar 2013 09:57:59 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363859889; bh=KJsldtzpw7FySElpVAH7m3xoL3p9Xbr+5BuVVJ23VQk=; h=Cc:From:References:Subject:In-reply-to:Date; b=FySAUNjb9+gY2/9aql53e9xlyY+d5z559JL2MWENN0Bt8R0y+CIIkeXRvYudX+FZf Adj6mT/C97WWfqgprmRvB/8JU9eXuTO1KMfD8YWVjStcYfknNoivZMlcCjUOiM0Igx xv1Ef3PnLKQ/EQcanjXkQo3jQSyneu3djlQ5ZMcs= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:4c8b:a499:c999:2310]) (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 041CC216C3B; Thu, 21 Mar 2013 09:57:58 +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 1FD86314B0C7; Thu, 21 Mar 2013 20:57:53 +1100 (EST) From: Mark Andrews References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <20130321094205.80104314AF45@drug s.dv.isc .org> In-reply-to: Your message of "Thu, 21 Mar 2013 20:42:05 +1100." <20130321094205.80104314AF45@drugs.dv.isc.org> Date: Thu, 21 Mar 2013 20:57:52 +1100 Message-Id: <20130321095753.1FD86314B0C7@drugs.dv.isc.org> Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 09:58:14 -0000 In message <20130321094205.80104314AF45@drugs.dv.isc.org>, Mark Andrews writes: > Well we should complain to Apple. And OS X has good defaults. So can we please stop saying this does not work when it does with current commercial OSs. If your favorite OS does the wrong thing complain to your OS vendor. % time telnet www.isc.org 80 < /dev/null Trying 149.20.64.42... Connected to www.isc.org. Escape character is '^]'. Connection closed by foreign host. 0.027u 0.013s 0:00.82 3.6% 0+0k 0+0io 0pf+0w % ifconfig en1 en1: flags=8963 mtu 1500 ether 60:33:4b:01:75:85 inet6 fe80::6233:4bff:fe01:7585%en1 prefixlen 64 scopeid 0x5 inet 192.168.191.223 netmask 0xffffff00 broadcast 192.168.191.255 inet6 fd92:7065:b8e::6233:4bff:fe01:7585 prefixlen 64 autoconf inet6 fd92:7065:b8e::f9bc:650f:95f3:5de6 prefixlen 64 autoconf temporary media: autoselect status: active % Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From swmike@swm.pp.se Thu Mar 21 02:58:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E4021F867D for ; Thu, 21 Mar 2013 02:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 6gqPw87rx7GQ for ; Thu, 21 Mar 2013 02:58:46 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 6B59121F85DB for ; Thu, 21 Mar 2013 02:58:46 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B8C189E; Thu, 21 Mar 2013 10:58:45 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id AC4429C; Thu, 21 Mar 2013 10:58:45 +0100 (CET) Date: Thu, 21 Mar 2013 10:58:45 +0100 (CET) From: Mikael Abrahamsson To: Ole Troan In-Reply-To: <892E03C7-623A-4AC3-9C9C-88F3489A06DD@employees.org> Message-ID: References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <892E03C7-623A-4AC3-9C9C-88F3489A06DD@employees.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 09:58:47 -0000 On Thu, 21 Mar 2013, Ole Troan wrote: > correct. that's why there is L-3. there will be more specific routes > advertised for the internal ULA prefix(es). How widely is RFC4191 section 2.3 (Route information option) supported in currently deployed end systems? -- Mikael Abrahamsson email: swmike@swm.pp.se From Carl.Wuyts@technicolor.com Thu Mar 21 03:01:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132C221F8B51 for ; Thu, 21 Mar 2013 03:01:10 -0700 (PDT) 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_13=0.6, 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 4Fig3VYGuYek for ; Thu, 21 Mar 2013 03:01:09 -0700 (PDT) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id CC60321F8FC6 for ; Thu, 21 Mar 2013 03:01:05 -0700 (PDT) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKUUraX/Re7G+VUch4zj4wyG51CxCpngUw@postini.com; Thu, 21 Mar 2013 03:01:07 PDT Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 21 Mar 2013 10:56:23 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.135]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Thu, 21 Mar 2013 10:56:29 +0100 From: Wuyts Carl To: Alexandru Petrescu , "v6ops@ietf.org" Date: Thu, 21 Mar 2013 10:56:26 +0100 Thread-Topic: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) Thread-Index: Ac4mGJSGHRy+6ccKTd6cpTPqXcFXsgAAXQYQ Message-ID: <3135C2851EB6764BACEF35D8B495596806E5125D84@MOPESMBX01.eu.thmulti.com> References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> In-Reply-To: <514AD5FE.2020705@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 10:01:10 -0000 But Alexandru, isn't this going 1 step too far ? You want to step back the "no def route allowed for ULA" principle ? It's about CPE devices, so I don't see why there would be all of a sudden t= oo many routes in some of these use cases ?? Please elaborate. Regs Carl Le 21/03/2013 10:29, Mikael Abrahamsson a =E9crit : > On Thu, 21 Mar 2013, Mikael Abrahamsson wrote: > >> From rfc6204bis: > > ULA-5: An IPv6 CE router MUST NOT advertise itself as a default > router with a Router Lifetime greater than zero whenever all > of its configured and delegated prefixes are ULA prefixes. > > Doesn't this make routed home useless as soon as the IPv6 Internet=20 > connectivity goes away? The ULAs won't get routed anymore (solving my=20 > problem), but it also makes the desired functionality (printer still=20 > works when ISP connection is down) go away as well. Right? In a sense I agree. This ULA-5 requirement forbids growth of large home-to-= home networks. This ULA-5 requirement is wrong and shouldnt be there - neither for CPEs no= r for anything else. A Router - any Router for that matter - should be able to be a default rout= er, or not a default router, whenever it wants to, even though it has no co= nnection to Internet. If this is not done (i.e. do not allow default routers when only ULA addres= ses are used) then the networks using exclusively ULA addressing can not sc= ale to large size, because there may be too many routes at too many Routers= . An advantage of using a default route is that it concentrates the many ro= utes only in a few-places - the DFZ. Alex > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Thu Mar 21 03:05:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB9721F8AE6 for ; Thu, 21 Mar 2013 03:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vt5zcaPUS25a for ; Thu, 21 Mar 2013 03:05:01 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id E0C6421F883E for ; Thu, 21 Mar 2013 03:05:00 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id eh20so2601766obb.22 for ; Thu, 21 Mar 2013 03:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=vCaevAHKQoE3YiUTjv0N24eUnlnmvbHEEYkdRqkL3EE=; b=h82YChMiAPKMWMa83DtFY0HiQRO84b4BkqAYYpkbUxGQlM/DTZd8Tz8Vpm9W6mFaZO eSehtumSn31f0Zv0CoUiGcHDCjJY02j+Y7eWJ1lmn8vSRpgWpFJtf664fF5xGeYyx5+2 iPOK08TlX3UHPf+5a/mclTWNxhVrFB1fMo7KQZjeKyjFGCHF1QiJetFPEwdqsueQBA56 GSXq0L16eGjSJtxk3yUPJKn/YU5tpFODY3bf2liiVXRB5TTPkXHAEuAukRo/h3qp1rhd ceCfLKYtLu/ZoI1eVigtLnuTuxxdtz8tY+YZvk4sWsH0rB+DWfCwGKS9UYDyoxP3BS4X OkXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=vCaevAHKQoE3YiUTjv0N24eUnlnmvbHEEYkdRqkL3EE=; b=ho2551vZyAo0psp10DfdDWeK87/2/hZVJV5DgHvGv9v6FhqTKgpjKdN/jDw7Q1WTc+ be5seiL4z+uXhfTccTboRyuGOLlO1Lg07KgM8o6CZO0ZCWj6CITTS6JyLQq07MEYenPV ytkQMIdM6nXPngQzHTUVKY4Kpd95n4uS6I8tOcGeSAcKl/vjkz8Rz4DKWxZck8q5dPDl kTz3wM9hqnYXqUz4tI6ffVJWy69+xQHJunvEZseg8kLVCLwR3Xsu4uc+hkS+GeVBTg7k gFiPBDNIr1KFvcWLygMdioAgKgBWU8ktNivUR7Pc0aRmbmaG8yGHicHUTCrFnkb5zEoU tYQA== X-Received: by 10.60.20.193 with SMTP id p1mr6484473oee.133.1363860300416; Thu, 21 Mar 2013 03:05:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Thu, 21 Mar 2013 03:04:39 -0700 (PDT) In-Reply-To: <20130321094205.80104314AF45@drugs.dv.isc.org> References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <20130321094205.80104314AF45@drugs.dv.isc.org> From: Lorenzo Colitti Date: Thu, 21 Mar 2013 03:04:39 -0700 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=e89a8ff1c2d8baf5ac04d86c7888 X-Gm-Message-State: ALoCoQkO3u4xMER3/uQ8L6bscQ+J+iCFRP1tGvXJOKk7ysNvjhYMH+3O1BzfR7OfQ14SiMBVvKjNyLM+KMRF6XzhSM/9tbJI5OCLGXKfD/pvmOeQ0AXyTkb1WuKYNp6l5LO/H6IwEp8pX38+GGf6+0kIfva0nw1BOso1KuddzjVClGoPQnsdqgIztRH6+f1IOmnxPCJNcP8j Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 10:05:02 -0000 --e89a8ff1c2d8baf5ac04d86c7888 Content-Type: text/plain; charset=ISO-8859-1 Ok, so you're saying that we should specify behaviour that won't work well on any current hosts, that we should use mechanisms to get around this that don't work at all on a substantial number of hosts (OS X/iOS), that that we need to complicate all apps to deal with this, and that 4 seconds is acceptable. And you're saying this because then we can use ULAs. But... why? On Thu, Mar 21, 2013 at 2:42 AM, Mark Andrews wrote: > > In message zB5Kqw@mail.gmail.com>, Lorenzo Colitti writes: > > > > On Thu, Mar 21, 2013 at 1:53 AM, Mark Andrews wrote: > > > > > No connection yet exists. > > > > > > I disagree, but that doesn't matter. What does matter is that major > > implementations disagree. > > > > - Windows entirely ignores the unreachables > > - OS X (and iOS?) times out after four seconds > > OS X takes 80 seconds to timeout the connection it there are no > port unreachables. I measured it. > > > The only major implementation that does what you say is Linux. > > Yet the test was done on a OS X box. > > % time telnet -s 2001:470:1f00:820:7dc1:7bde:ed0f:15aa 2001:ffff::1 80 > Trying 2001:ffff::1... > telnet: connect to address 2001:ffff::1: Operation timed out > telnet: Unable to connect to remote host > 0.027u 0.013s 1:15.77 0.0% 0+0k 0+0io 0pf+0w > % time telnet -s fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba 2001:4f8:0:2::d 80 > Trying 2001:4f8:0:2::d... > telnet: connect to address 2001:4f8:0:2::d: Connection refused > telnet: Unable to connect to remote host > 0.026u 0.012s 0:04.47 0.6% 0+0k 0+0io 0pf+0w > % uname -a > Darwin drugs.dv.isc.org 12.3.0 Darwin Kernel Version 12.3.0: Sun Jan 6 > 22:37:10 PST 2013; root:xnu-2050.22.13~1/RELEASE_X86_64 x86_64 > % > > > > A embrionic connection exists and has been shown port unreachables do > > > reduce the connection timeout. > > > > > > Not really; see above. > > > > > > > Note this is moot when a the address selection table takes into > > > account ULA properties. > > > > > > > No implementation does this in its default configuration. > > Defaults can change. > > > > Configurable address selection tables have been part of the IPv6 > > > spec since 2003 and have existed in implementations since then. > > > > If you configure them yourself (except on OS X/iOS where they're not > > supported at all), sure. > > Well we should complain to Apple. > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > --e89a8ff1c2d8baf5ac04d86c7888 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ok, so you're saying that we should specify behaviour = that won't work well on any current hosts, that we should use mechanism= s to get around this that don't work at all on a substantial number of = hosts (OS X/iOS), that that we need to complicate all apps to deal with thi= s, and that 4 seconds is acceptable.

And you're saying this because then we can use ULAs. But= ... why?

On Thu, Mar 21, 2013 at 2:42 AM, Mark Andre= ws <marka@isc.org> wrote:

In message <CAKD1Yr0pbq7L0T55ZLpk1UnoMB981NZE=3D94nBUeh+Rv=3DzB5Kqw@mail.gmail.com>, Lorenzo Colitt= i writes:
>
> On Thu, Mar 21, 2013 at 1:53 AM, Mark Andrews <marka@isc.org> wrote:
>
> > No connection yet exists.
>
>
> I disagree, but that doesn't matter. What does matter is that majo= r
> implementations disagree.
>
> - Windows entirely ignores the unreachables
> - OS X (and iOS?) times out after four seconds

OS X takes 80 seconds to timeout the connection it there are no
port unreachables. =A0I measured it.

> The only major implementation that does what you say is Linux.

Yet the test was done on a OS X box.

% time telnet -s 2001:470:1f00:820:7dc1:7bde:ed0f:15aa 2001:ffff::1 80
Trying 2001:ffff::1...
telnet: connect to address 2001:ffff::1: Operation timed out
telnet: Unable to connect to remote host
0.027u 0.013s 1:15.77 0.0% =A0 =A0 =A00+0k 0+0io 0pf+0w
% time telnet -s fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba 2001:4f8:0:2::d 80
Trying 2001:4f8:0:2::d...
telnet: connect to address 2001:4f8:0:2::d: Connection refused
telnet: Unable to connect to remote host
0.026u 0.012s 0:04.47 0.6% =A0 =A0 =A00+0k 0+0io 0pf+0w
% uname -a
Darwin drugs.dv.isc.o= rg 12.3.0 Darwin Kernel Version 12.3.0: Sun Jan =A06 22:37:10 PST 2013;= root:xnu-2050.22.13~1/RELEASE_X86_64 x86_64
%

> > A embrionic connection exists and has been shown port unreachable= s do
> > reduce the connection timeout.
>
>
> Not really; see above.
>
>
> > Note this is moot when a the address selection table takes into > > account ULA properties.
> >
>
> No implementation does this in its default configuration.

Defaults can change.

> > Configurable address selection tables have been part of the IPv6<= br> > > spec since 2003 and have existed in implementations since then. >
> If you configure them yourself (except on OS X/iOS where they're n= ot
> supported at all), sure.

Well we should complain to Apple.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@isc.org

--e89a8ff1c2d8baf5ac04d86c7888-- From lorenzo@google.com Thu Mar 21 03:06:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604C821F8A27 for ; Thu, 21 Mar 2013 03:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 mSJCMcj3SvKv for ; Thu, 21 Mar 2013 03:06:12 -0700 (PDT) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 918BC21F893B for ; Thu, 21 Mar 2013 03:06:12 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id k14so2804236oag.25 for ; Thu, 21 Mar 2013 03:06:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=WkXttmFwfuMYLgZRGXpfzoGlTia2mO+pZ23UWgvmF+Y=; b=jgq5vKOQan3gK/cty5Ls0s9Y8Yep/effyOtQRWbNwg1DjWNlr3VhadohDZ8WvhXpGg gJLHQ/8OeYTuvZYOGr1GFAgRwN+LF23cUzd+J/3RbvURWV5bnSTR66SOQ46FTMcK3N3A FPFeA/hbvdmMyTzb2HuHWyR9qnAi+V/AjkcFD28BS4tBLWOuOzTSgm+t3+hbLSX9h3lw 26CvzQYb/k4+MJI9Y5zPdpxV5Dlr+Bc09hZbgE1sB4v6yc+Jm13zAq16FNVWWx144I1/ vns5AN4NWqA0tXMUOwzGtfobW2XhUzwYFgREiV2wV5Nz3no+v8sJzQwdGxaJTnGd1DIb 2gww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=WkXttmFwfuMYLgZRGXpfzoGlTia2mO+pZ23UWgvmF+Y=; b=j/czn18EXeVWCiqwWINxwtecHXeYnwicjzGjJFQI2Lx0QFzjw2GwXd1+57p05+9xti w2bqoOGgAaRXjtMOj7+jNNhqmkVahEtmQiMGZPubYjK0EJQ+514GeBhj9dsYQYp/jvrO v/o0AfFAdK5OkCbSK+48w9I/TeS+gFOYle7oK+vj7RL5saTiindXh2fPEqA8tnL/87fz 95QLtMWiXiwzBs6owpSyu/fzeIlZqhgz36a6jNjyVodrR9GQfyP1ncYCXzG1k3KFbMeC 1v+MKOStvGL+HtDNLsbsWRpPO3+pfxZEGCps77CDgKm9Mn79H3nbXXLwA4N5S3HlXIQy 48/A== X-Received: by 10.60.3.200 with SMTP id e8mr6421383oee.94.1363860372109; Thu, 21 Mar 2013 03:06:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Thu, 21 Mar 2013 03:05:51 -0700 (PDT) In-Reply-To: <20130321095753.1FD86314B0C7@drugs.dv.isc.org> References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <20130321094205.80104314AF45@drugs.dv.isc.org> <20130321095753.1FD86314B0C7@drugs.dv.isc.org> From: Lorenzo Colitti Date: Thu, 21 Mar 2013 03:05:51 -0700 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=e89a8fb1f55e01274b04d86c7da2 X-Gm-Message-State: ALoCoQnagsmhkUObCUDI5wn7zr8ds4pReYZ9Uwuyab52WEcq2JtUnzHw/277g1fRVl1434QvCvGD+6Mj9IlrAujkyXkzfH2EbAbwUvo2ugheJntjHU30xqFff+oov7VX3Mrx1Tgh4+Ic/Q1Ut2bnOuAT4j5LT5Rv7UKNXw3sdXa+cKsKfalgRAnQxHb6UJMtQO96DTdI3jap Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 10:06:13 -0000 --e89a8fb1f55e01274b04d86c7da2 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 21, 2013 at 2:57 AM, Mark Andrews wrote: > And OS X has good defaults. So can we please stop saying this does > not work when it does with current commercial OSs. When did the defaults change? How many users have the old and the new behaviour? --e89a8fb1f55e01274b04d86c7da2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 21, 2013 at 2:57 AM, Mark Andrews <marka@isc.org<= /a>> wrote:
And OS X has good def= aults. =A0So can we please stop saying this does
not work when it does with current commercial OSs.

When did the defaults change? How many users have the old and= the new behaviour?=A0
--e89a8fb1f55e01274b04d86c7da2-- From pkern@spike.0x539.de Thu Mar 21 03:12:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0367521F8E1D for ; Thu, 21 Mar 2013 03:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyabyvFw4PKd for ; Thu, 21 Mar 2013 03:12:52 -0700 (PDT) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B13821F8DBB for ; Thu, 21 Mar 2013 03:12:51 -0700 (PDT) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UIcUI-0006pF-TT for v6ops@ietf.org; Thu, 21 Mar 2013 11:12:46 +0100 Received: from [2001:470:720c:0:549e:7ff4:7168:b57e] (helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1UIcUK-0006nr-5e for v6ops@ietf.org; Thu, 21 Mar 2013 11:12:48 +0100 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1UIcUJ-0005PC-6v for v6ops@ietf.org; Thu, 21 Mar 2013 11:12:47 +0100 Date: Thu, 21 Mar 2013 11:12:47 +0100 From: Philipp Kern To: "v6ops@ietf.org Operations" Message-ID: <20130321101247.GB19136@spike.0x539.de> References: <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149D452.8020209@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 10:12:53 -0000 Owen, am Wed, Mar 20, 2013 at 03:58:51PM -0500 hast du folgendes geschrieben: > Remember, the RIRs are not for profit entities. Larger quantities of end-user > registrations should directly equate to lower fees. only if it can be automated. If you still need to have people reviewing contracts, checking a company's registration and stuff you'd likely need more people to process them, which means higher cost. If it were similar to the domain registries, I'd tend to agree that the price should be much lower. Like the LIR checking all requirements, have the RIR trust the LIR on this and automatically give out PI assignments up to a certain size. Kind regards Philipp Kern From otroan@employees.org Thu Mar 21 03:48:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90DF21F86A5 for ; Thu, 21 Mar 2013 03:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNhf0G+LahFQ for ; Thu, 21 Mar 2013 03:48:23 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id BE38D21F8682 for ; Thu, 21 Mar 2013 03:48:23 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 56EEE5E73; Thu, 21 Mar 2013 03:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=v5Ul+OXGAzYwwWIXVHTZVxy/bME=; b=XDh7JxCF4GmtXPhdlh odOKHrt8XzCeci3jcldffIdCkEzzWXt5EjXe28UCLN0q8CjtF0eVM+CeLGF0hcU5 ZpMO29zhkYdsT0qNAZLihxD2kVPlKJQ9PzQ/iEdyV6/TTUP7tI24f6dFADX5QPkb Jpw3fBvVmVzq8wEXzQ90Nzues= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=sJtuNZoCLP30DyVsNloWLkFWj1da4CTekXmE6pJCVS06v7VVDyU D10cLrCooUucMkl94G9wEk6vgsSOnb/v0F0hQHhL+xsdksnqVt+nN5qJE5jFS66o aBzELABY6XvlvlDePzMwW/49a34Rzg5RqEGorPsAviPFDSPn3IsiTgNI= Received: from dhcp-10-61-105-103.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id C88975E62; Thu, 21 Mar 2013 03:48:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <514AD918.3070208@gmail.com> Date: Thu, 21 Mar 2013 11:48:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <698163C9-5A5F-40A3-B740-5B4B4F076789@employees.org> References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <892E03C7-623A-4AC3-9C9C-88F3489A06DD@employees.org> <514 AD918.30 70208@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 10:48:24 -0000 Alex, >>> If Router Lifetime is zero (which it should be as soon as Internet >>> connectivity goes down and now it's only ULA left), won't that >>> invalidate the default route the clients have installed? >>=20 >> correct. that's why there is L-3. there will be more specific routes >> advertised for the internal ULA prefix(es). >=20 > Whenever there are specific routes it means it won't scale to large = sizes. This is not good - it doesnt scale. it is not meant to. RFC6204 describes a single router in the home. are = you expecting more than 17 ULA prefixes (/48s) in the home? the homenet architecture has no such limitation. the reason for the RFC6204 text is that a host with a default route and = a ULA address would not behave well. cheers, Ole= From marka@isc.org Thu Mar 21 03:48:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7423F21F8206 for ; Thu, 21 Mar 2013 03:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 sRdnfUudVrop for ; Thu, 21 Mar 2013 03:48:40 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 57FD621F86A5 for ; Thu, 21 Mar 2013 03:48:38 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id BFF21C944E; Thu, 21 Mar 2013 10:48:32 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363862918; bh=N6zNL+4dBUcIV5qLxq0jJn6WOhZtoRPkUzFrVC86V4g=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=f0uiL5O+o4bFZSY1qKTzPpLexxUg0l0MimbDLzuXy6FYAgdI/2UA29JQ5NtF4Yr0J gKfpZrdu7HMutY3BQW2PDyRg0ud3ivuf0rkwK5Ls0JBlGTCT2N+qKfh/5I7yOTx5kM lShEPe4Kug0Ckx5UrYMB80uqUK1yoPgAKo5U+tyA= 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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Thu, 21 Mar 2013 10:48:32 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 7DF2D216C3B; Thu, 21 Mar 2013 10:48:32 +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 C0E30314B4BA; Thu, 21 Mar 2013 21:48:29 +1100 (EST) To: Lorenzo Colitti From: Mark Andrews References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <20130321094205.80104314AF45@drugs .dv.isc. org> In-reply-to: Your message of "Thu, 21 Mar 2013 03:04:39 PDT." Date: Thu, 21 Mar 2013 21:48:29 +1100 Message-Id: <20130321104829.C0E30314B4BA@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 10:48:45 -0000 I'm saying apps need to be fixed regardless. We are in a multi-homed world once you turn on IPv6. Waiting 60 odd seconds for failover is not acceptable and never has been. The only reason it hasn't been fixed in the past is that most servers present as single homed. Once you are dual stacked there are no single homed servers. Links break on the internet. Those breaks may take out IPv4 connectivity, IPv6 connectivity or both IPv4 and IPv6 connectivity between pairs of sites. Apps should cope and they don't need additional assistance from the OS to cope. I'm also saying that modern OS do a reasonable job. If your OS doesn't complain to the vendor. All the vendors push out updates these days. All vendors are trying to provide a good experience. If your OS makes a wrong initial choice and the apps hasn't been updated, the fallback is still only ~4 secs rather than 60 odd if you are using ULA with only a IPv4 uplink. Mark -- 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 Thu Mar 21 05:30:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BB821F8E57 for ; Thu, 21 Mar 2013 05:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.27 X-Spam-Level: X-Spam-Status: No, score=-99.27 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 GfZH71IuRlQJ for ; Thu, 21 Mar 2013 05:30:12 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD1E21F8E55 for ; Thu, 21 Mar 2013 05:29:59 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id x56so1436575wey.0 for ; Thu, 21 Mar 2013 05:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=71zRdziTg1uhMkbujBGNRSgd2nSU4ku4/iSfy+ovT2Q=; b=BwmEj2CJKbo2phPE76J1tSixavAKuhh/b3M9EREXArfjig3KTIBy80eljV7w8Ao+xl KYiRTCmN5SRLTxnha9OGiyxQbqmHvFI1PnmjZ34/9lHZrhUaiRa9+z49lalzFyQGDLlp k80NZ7XiCa+f5vfweZE2QtxwK4owmygReLXtYPnzAiHsU90NMvKeUOwBJd27KsRvKAwp s4cEsWEd3alU5BuBwUUVlOjEDHugDBGo63HF89vnQri+gEbeMX3dunqGRdE+D/FSsyfE UnOUONgIdrnICK9LFzY5WVkUNYSItKHLwrs5qJaM1M8s7Gw7/3wuPAgdBDhQ9S0MP8yv uKhQ== X-Received: by 10.180.98.232 with SMTP id el8mr4593137wib.22.1363868999140; Thu, 21 Mar 2013 05:29:59 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-189-49.as13285.net. [2.101.189.49]) by mx.google.com with ESMTPS id h10sm4932906wic.8.2013.03.21.05.29.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Mar 2013 05:29:58 -0700 (PDT) Message-ID: <514AFD50.1000706@gmail.com> Date: Thu, 21 Mar 2013 12:30:08 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mikael Abrahamsson References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 12:30:14 -0000 On 21/03/2013 09:18, Mikael Abrahamsson wrote: > On Thu, 21 Mar 2013, Mark Andrews wrote: > >> Configurable address selection tables have been part of the IPv6 spec >> since 2003 and have existed in implementations since then. > > What's the opposite of FUD? Wishful thinking? As stated before, this > doesn't work for grandma. She needs the address selection table be > remotely automatically provisioned. As far as I know, this is not the > case in current implementations. This is the IETF, where we write specs for future implementations. Brian From alexandru.petrescu@gmail.com Thu Mar 21 06:19:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB0521F874B for ; Thu, 21 Mar 2013 06:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.885 X-Spam-Level: X-Spam-Status: No, score=-9.885 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJt0-9Z5nu1v for ; Thu, 21 Mar 2013 06:19:36 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 208F921F8714 for ; Thu, 21 Mar 2013 06:19:35 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2LDJYJO022344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 14:19:34 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2LDJYAG024134; Thu, 21 Mar 2013 14:19:34 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2LDJUEc028104; Thu, 21 Mar 2013 14:19:34 +0100 Message-ID: <514B08B7.4060000@gmail.com> Date: Thu, 21 Mar 2013 14:18:47 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Wuyts Carl References: <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <3135C2851EB6764BACEF35D8B495596806E5125D84@MOPESMBX01.eu.thmulti.com> In-Reply-To: <3135C2851EB6764BACEF35D8B495596806E5125D84@MOPESMBX01.eu.thmulti.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 13:19:37 -0000 Le 21/03/2013 10:56, Wuyts Carl a écrit : > But Alexandru, isn't this going 1 step too far ? Ok - it is going a little further but not too far. > You want to step back the "no def route allowed for ULA" principle ? I didnt know there were such a principle, but it should be considered. > It's about CPE devices, so I don't see why there would be all of a > sudden too many routes in some of these use cases ?? Please > elaborate. In an appartment building there may be several CPEs inter-connected. Within one appartment there may be a single ULA prefix. If one Client PC needs to talk to another Client PC in another appartment then each CPE should have a route for each other CPE. And each one of these routes should be told to each Client PCs. The more the appartments the more routes. Small Client PC == little memory, long search time. OTOH, if one were to use default routes, then the Client PC would need to store a single default route. Alex > > Regs Carl > > Le 21/03/2013 10:29, Mikael Abrahamsson a écrit : >> On Thu, 21 Mar 2013, Mikael Abrahamsson wrote: >> >>> From rfc6204bis: >> >> ULA-5: An IPv6 CE router MUST NOT advertise itself as a default >> router with a Router Lifetime greater than zero whenever all of its >> configured and delegated prefixes are ULA prefixes. >> >> Doesn't this make routed home useless as soon as the IPv6 Internet >> connectivity goes away? The ULAs won't get routed anymore (solving >> my problem), but it also makes the desired functionality (printer >> still works when ISP connection is down) go away as well. Right? > > In a sense I agree. This ULA-5 requirement forbids growth of large > home-to-home networks. > > This ULA-5 requirement is wrong and shouldnt be there - neither for > CPEs nor for anything else. > > A Router - any Router for that matter - should be able to be a > default router, or not a default router, whenever it wants to, even > though it has no connection to Internet. > > If this is not done (i.e. do not allow default routers when only ULA > addresses are used) then the networks using exclusively ULA > addressing can not scale to large size, because there may be too many > routes at too many Routers. An advantage of using a default route is > that it concentrates the many routes only in a few-places - the DFZ. > > Alex > >> > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From alexandru.petrescu@gmail.com Thu Mar 21 06:21:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F0A21F8CF8 for ; Thu, 21 Mar 2013 06:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.181 X-Spam-Level: X-Spam-Status: No, score=-10.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4uyhDgQFZeT for ; Thu, 21 Mar 2013 06:21:27 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 68CBB21F874B for ; Thu, 21 Mar 2013 06:21:27 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2LDLNAn008309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 14:21:24 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2LDLNiH024881; Thu, 21 Mar 2013 14:21:23 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2LDLMWh029289; Thu, 21 Mar 2013 14:21:23 +0100 Message-ID: <514B0927.60207@gmail.com> Date: Thu, 21 Mar 2013 14:20:39 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ole Troan References: <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 13:21:28 -0000 Le 21/03/2013 10:54, Ole Troan a écrit : >>> ULA-5: An IPv6 CE router MUST NOT advertise itself as a default >>> router with a Router Lifetime greater than zero whenever all of >>> its configured and delegated prefixes are ULA prefixes. >>> >>> Doesn't this make routed home useless as soon as the IPv6 >>> Internet connectivity goes away? The ULAs won't get routed >>> anymore (solving my problem), but it also makes the desired >>> functionality (printer still works when ISP connection is down) >>> go away as well. Right? >> >> In a sense I agree. This ULA-5 requirement forbids growth of large >> home-to-home networks. >> >> This ULA-5 requirement is wrong and shouldnt be there - neither for >> CPEs nor for anything else. >> >> A Router - any Router for that matter - should be able to be a >> default router, or not a default router, whenever it wants to, even >> though it has no connection to Internet. >> >> If this is not done (i.e. do not allow default routers when only >> ULA addresses are used) then the networks using exclusively ULA >> addressing can not scale to large size, because there may be too >> many routes at too many Routers. An advantage of using a default >> route is that it concentrates the many routes only in a few-places >> - the DFZ. > > that's incorrect. see my reply to Mikael. YEs, there is something incorrect above, but not all. In whatever network one builds - use default routes, it's a good thing. Don't forbid default routes. Alex > check the earlier RFC6204 threads if you want history. > > cheers, Ole > > From otroan@employees.org Thu Mar 21 06:23:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11AA21F8FA3 for ; Thu, 21 Mar 2013 06:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2U0Fr2Fg4rAl for ; Thu, 21 Mar 2013 06:23:37 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id A87DF21F8DB9 for ; Thu, 21 Mar 2013 06:23:37 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 5B2095E97; Thu, 21 Mar 2013 06:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=HzL3EcXQFw/qutVqVbkWfoLfcPM=; b=p01RqxJcO9/mwKOJMC 1XIywV7vy+ooPU8jbAbbV3QgIMl9hWcu1/QmzuciXY61ZYP9sww7hwNJd147oAZG MFnD7IIRx1MwThXZIiwrYthBecNC6lTe2ud3deGHKZpMAmy4G4cdmYOq0uCelUyL Bo8DoEJ3wi603HT5TrOi+KOHw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=Z3rWY3EsWCbP+g6AiHELZRKh/rdbg3jK2ASAnbptgo5A9D8B1H1 p/5KjwJvYWVfK9tw8vyJPqPz0lYQHXEikIpr6E0bg7IX40ZTT6+wA3yzNnIeWUIC nMkUU69lrg2jTGtIb1cHuleJbCzQIoRfssaPCv/ytfCpvcVonQniTZL8= Received: from dhcp-10-61-103-162.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id C827B5E79; Thu, 21 Mar 2013 06:23:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <514B0927.60207@gmail.com> Date: Thu, 21 Mar 2013 14:23:34 +0100 Content-Transfer-Encoding: 7bit Message-Id: <6C15E952-7432-4C6B-BF20-1CC96AB3B13E@employees.org> References: <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <51 4B0927.60207@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 13:23:38 -0000 Alex, >>>> ULA-5: An IPv6 CE router MUST NOT advertise itself as a default >>>> router with a Router Lifetime greater than zero whenever all of >>>> its configured and delegated prefixes are ULA prefixes. >>>> >>>> Doesn't this make routed home useless as soon as the IPv6 >>>> Internet connectivity goes away? The ULAs won't get routed >>>> anymore (solving my problem), but it also makes the desired >>>> functionality (printer still works when ISP connection is down) >>>> go away as well. Right? >>> >>> In a sense I agree. This ULA-5 requirement forbids growth of large >>> home-to-home networks. >>> >>> This ULA-5 requirement is wrong and shouldnt be there - neither for >>> CPEs nor for anything else. >>> >>> A Router - any Router for that matter - should be able to be a >>> default router, or not a default router, whenever it wants to, even >>> though it has no connection to Internet. >>> >>> If this is not done (i.e. do not allow default routers when only >>> ULA addresses are used) then the networks using exclusively ULA >>> addressing can not scale to large size, because there may be too >>> many routes at too many Routers. An advantage of using a default >>> route is that it concentrates the many routes only in a few-places >>> - the DFZ. >> >> that's incorrect. see my reply to Mikael. > > YEs, there is something incorrect above, but not all. > > In whatever network one builds - use default routes, it's a good thing. > Don't forbid default routes. agree, we'll fix that as soon as the host implementations are fixed. cheers, Ole From alexandru.petrescu@gmail.com Thu Mar 21 06:24:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A08121F86B1 for ; Thu, 21 Mar 2013 06:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.182 X-Spam-Level: X-Spam-Status: No, score=-10.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsvX8qRQsyt4 for ; Thu, 21 Mar 2013 06:23:59 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id B739021F862A for ; Thu, 21 Mar 2013 06:23:56 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2LDNtXe009410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 21 Mar 2013 14:23:55 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2LDNtMr025984 for ; Thu, 21 Mar 2013 14:23:55 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2LDNs5q003801 for ; Thu, 21 Mar 2013 14:23:55 +0100 Message-ID: <514B09C0.6080202@gmail.com> Date: Thu, 21 Mar 2013 14:23:12 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <892E03C7-623A-4AC3-9C9C-88F3489A06DD@employees.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 13:24:04 -0000 Le 21/03/2013 10:58, Mikael Abrahamsson a écrit : > On Thu, 21 Mar 2013, Ole Troan wrote: > >> correct. that's why there is L-3. there will be more specific >> routes advertised for the internal ULA prefix(es). > > How widely is RFC4191 section 2.3 (Route information option) > supported in currently deployed end systems? Good question - and even if it where - it were _only_ to configure Hosts. I.e. it doesnt allow to configure a router at home (other than the CPE). A router at home may have two interfaces each with ULA, no GUA addressing; and have the CPE as its Default Router, and be itself a Default Router for its Clients. Alex > From Carl.Wuyts@technicolor.com Thu Mar 21 06:25:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D3721F86B1 for ; Thu, 21 Mar 2013 06:25:26 -0700 (PDT) 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_13=0.6, 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 7XfG2NhmxZ6i for ; Thu, 21 Mar 2013 06:25:26 -0700 (PDT) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with ESMTP id 51FEE21F8314 for ; Thu, 21 Mar 2013 06:25:24 -0700 (PDT) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKUUsKQy3IeHb5R071D4ZmDKzUiyY3r4Dt@postini.com; Thu, 21 Mar 2013 06:25:25 PDT Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 21 Mar 2013 14:22:22 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.135]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Thu, 21 Mar 2013 14:22:29 +0100 From: Wuyts Carl To: Alexandru Petrescu Date: Thu, 21 Mar 2013 14:22:22 +0100 Thread-Topic: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) Thread-Index: Ac4mNsiGSmvt6qZtQ4a87XaFL5SA9QAACA3Q Message-ID: <3135C2851EB6764BACEF35D8B495596806E51C4B3B@MOPESMBX01.eu.thmulti.com> References: <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <3135C2851EB6764BACEF35D8B495596806E5125D84@MOPESMBX01.eu.thmulti.com> <514B08B7.4060000@gmail.com> In-Reply-To: <514B08B7.4060000@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 13:25:26 -0000 Well, seems like there is some misunderstanding here. If all inhabitants f= rom all these appts know each other and want to be directly connected throu= gh ULA's, you can hardly talk about home CPEs I'd say, no ? Regs Carl -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: donderdag 21 maart 2013 14:19 To: Wuyts Carl Cc: v6ops@ietf.org Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-u= sage-analysis) Le 21/03/2013 10:56, Wuyts Carl a =E9crit : > But Alexandru, isn't this going 1 step too far ? Ok - it is going a little further but not too far. > You want to step back the "no def route allowed for ULA" principle ? I didnt know there were such a principle, but it should be considered. > It's about CPE devices, so I don't see why there would be all of a=20 > sudden too many routes in some of these use cases ?? Please elaborate. In an appartment building there may be several CPEs inter-connected. Within one appartment there may be a single ULA prefix. If one Client PC needs to talk to another Client PC in another appartment t= hen each CPE should have a route for each other CPE. And each one of these= routes should be told to each Client PCs. The more the appartments the more routes. Small Client PC =3D=3D little memory, long search time. OTOH, if one were to use default routes, then the Client PC would need to s= tore a single default route. Alex > > Regs Carl > > Le 21/03/2013 10:29, Mikael Abrahamsson a =E9crit : >> On Thu, 21 Mar 2013, Mikael Abrahamsson wrote: >> >>> From rfc6204bis: >> >> ULA-5: An IPv6 CE router MUST NOT advertise itself as a default=20 >> router with a Router Lifetime greater than zero whenever all of its=20 >> configured and delegated prefixes are ULA prefixes. >> >> Doesn't this make routed home useless as soon as the IPv6 Internet=20 >> connectivity goes away? The ULAs won't get routed anymore (solving my=20 >> problem), but it also makes the desired functionality (printer still=20 >> works when ISP connection is down) go away as well. Right? > > In a sense I agree. This ULA-5 requirement forbids growth of large=20 > home-to-home networks. > > This ULA-5 requirement is wrong and shouldnt be there - neither for=20 > CPEs nor for anything else. > > A Router - any Router for that matter - should be able to be a default=20 > router, or not a default router, whenever it wants to, even though it=20 > has no connection to Internet. > > If this is not done (i.e. do not allow default routers when only ULA =20 > addresses are used) then the networks using exclusively ULA addressing=20 > can not scale to large size, because there may be too many routes at=20 > too many Routers. An advantage of using a default route is that it=20 > concentrates the many routes only in a few-places - the DFZ. > > Alex > >> > > > _______________________________________________ v6ops mailing list=20 > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From swmike@swm.pp.se Thu Mar 21 06:26:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79AC21F8BBC for ; Thu, 21 Mar 2013 06:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.253, 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 nwc1OgaNtHhI for ; Thu, 21 Mar 2013 06:26:01 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id C593121F8D02 for ; Thu, 21 Mar 2013 06:26:00 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E916C9E; Thu, 21 Mar 2013 14:25:57 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E002B9A for ; Thu, 21 Mar 2013 14:25:57 +0100 (CET) Date: Thu, 21 Mar 2013 14:25:57 +0100 (CET) From: Mikael Abrahamsson To: "v6ops@ietf.org WG" In-Reply-To: <514AFD50.1000706@gmail.com> Message-ID: References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AFD50.1000706@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 13:26:02 -0000 On Thu, 21 Mar 2013, Brian E Carpenter wrote: > On 21/03/2013 09:18, Mikael Abrahamsson wrote: >> On Thu, 21 Mar 2013, Mark Andrews wrote: >> >>> Configurable address selection tables have been part of the IPv6 spec >>> since 2003 and have existed in implementations since then. >> >> What's the opposite of FUD? Wishful thinking? As stated before, this >> doesn't work for grandma. She needs the address selection table be >> remotely automatically provisioned. As far as I know, this is not the >> case in current implementations. > > This is the IETF, where we write specs for future implementations. The IETF also tries to make the Internet work. That means take into account what the real world looks like before we give guidance. Especially an "analysis" document should take into account what the real world looks like and what problems will occur due to existing implementations that correctly implemented standards existing at the time. -- Mikael Abrahamsson email: swmike@swm.pp.se From alexandru.petrescu@gmail.com Thu Mar 21 06:27:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9DB21F86B1 for ; Thu, 21 Mar 2013 06:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.183 X-Spam-Level: X-Spam-Status: No, score=-10.183 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIZN4d6+VytL for ; Thu, 21 Mar 2013 06:27:49 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 971D321F8314 for ; Thu, 21 Mar 2013 06:27:48 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2LDRjAH011482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 14:27:46 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2LDRjhf028175; Thu, 21 Mar 2013 14:27:45 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2LDRi6F006776; Thu, 21 Mar 2013 14:27:45 +0100 Message-ID: <514B0AA6.3010006@gmail.com> Date: Thu, 21 Mar 2013 14:27:02 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ole Troan References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <892E03C7-623A-4AC3-9C9C-88F3489A06DD@employees.org> <514 AD918.3070208@gmail.com> <82A97A97-D52D-4613-A819-FF7AB1985141@cisco.com> In-Reply-To: <82A97A97-D52D-4613-A819-FF7AB1985141@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 13:27:49 -0000 Le 21/03/2013 11:47, Ole Troan a écrit : > Alex, > >>>> If Router Lifetime is zero (which it should be as soon as >>>> Internet connectivity goes down and now it's only ULA left), >>>> won't that invalidate the default route the clients have >>>> installed? >>> >>> correct. that's why there is L-3. there will be more specific >>> routes advertised for the internal ULA prefix(es). >> >> Whenever there are specific routes it means it won't scale to >> large sizes. This is not good - it doesnt scale. > > it is not meant to. RFC6204 describes a single router in the home. Ok - yes. But does it consider _several_ such Homes talking directly one to another without going through the ISP? If not then it should. > are you expecting more than 17 ULA prefixes (/48s) in the home? Not that many. Less. > the homenet architecture has no such limitation. Ok. > the reason for the RFC6204 text is that a host with a default route > and a ULA address would not behave well. Well, I dont see why? I have some in the lab doing so - it has a ULA address and a default route and it works fine - it pings another ULA behind that default route. Is this a MacOS-only software problem? Or is it actually a source address selection problem? Or a src-based route problem... Alex > > cheers, Ole > From alexandru.petrescu@gmail.com Thu Mar 21 06:30:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5224721F8DB9 for ; Thu, 21 Mar 2013 06:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.884 X-Spam-Level: X-Spam-Status: No, score=-9.884 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0vr6nB6OZ48 for ; Thu, 21 Mar 2013 06:30:41 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE4F21F8E41 for ; Thu, 21 Mar 2013 06:30:41 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2LDUddl012955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 14:30:39 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2LDUdH0029832; Thu, 21 Mar 2013 14:30:39 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2LDUc8q009349; Thu, 21 Mar 2013 14:30:39 +0100 Message-ID: <514B0B53.90608@gmail.com> Date: Thu, 21 Mar 2013 14:29:55 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Wuyts Carl References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <3135C2851EB6764BACEF35D8B495596806E5125D84@MOPESMBX01.eu.thmulti.com> <514B08B7.4060000@gmail.com> <3135C2851EB6764BACEF35D8B495596806E51C4B3B@MOPESMBX01.eu.thmulti.com> In-Reply-To: <3135C2851EB6764BACEF35D8B495596806E51C4B3B@MOPESMBX01.eu.thmulti.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 13:30:42 -0000 Le 21/03/2013 14:22, Wuyts Carl a écrit : > Well, seems like there is some misunderstanding here. If all > inhabitants from all these appts know each other and want to be > directly connected through ULA's, you can hardly talk about home > CPEs I'd say, no ? I dont know why? Home CPEs are forbidden from talking to each other? Alex > > Regs Carl > > > > > > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Sent: donderdag 21 maart 2013 > 14:19 To: Wuyts Carl Cc: v6ops@ietf.org Subject: Re: [v6ops] > questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) > > Le 21/03/2013 10:56, Wuyts Carl a écrit : >> But Alexandru, isn't this going 1 step too far ? > > Ok - it is going a little further but not too far. > >> You want to step back the "no def route allowed for ULA" principle >> ? > > I didnt know there were such a principle, but it should be > considered. > >> It's about CPE devices, so I don't see why there would be all of a >> sudden too many routes in some of these use cases ?? Please >> elaborate. > > In an appartment building there may be several CPEs inter-connected. > Within one appartment there may be a single ULA prefix. > > If one Client PC needs to talk to another Client PC in another > appartment then each CPE should have a route for each other CPE. > And each one of these routes should be told to each Client PCs. > > The more the appartments the more routes. > > Small Client PC == little memory, long search time. > > OTOH, if one were to use default routes, then the Client PC would > need to store a single default route. > > Alex > >> >> Regs Carl >> >> Le 21/03/2013 10:29, Mikael Abrahamsson a écrit : >>> On Thu, 21 Mar 2013, Mikael Abrahamsson wrote: >>> >>>> From rfc6204bis: >>> >>> ULA-5: An IPv6 CE router MUST NOT advertise itself as a default >>> router with a Router Lifetime greater than zero whenever all of >>> its configured and delegated prefixes are ULA prefixes. >>> >>> Doesn't this make routed home useless as soon as the IPv6 >>> Internet connectivity goes away? The ULAs won't get routed >>> anymore (solving my problem), but it also makes the desired >>> functionality (printer still works when ISP connection is down) >>> go away as well. Right? >> >> In a sense I agree. This ULA-5 requirement forbids growth of large >> home-to-home networks. >> >> This ULA-5 requirement is wrong and shouldnt be there - neither for >> CPEs nor for anything else. >> >> A Router - any Router for that matter - should be able to be a >> default router, or not a default router, whenever it wants to, >> even though it has no connection to Internet. >> >> If this is not done (i.e. do not allow default routers when only >> ULA addresses are used) then the networks using exclusively ULA >> addressing can not scale to large size, because there may be too >> many routes at too many Routers. An advantage of using a default >> route is that it concentrates the many routes only in a few-places >> - the DFZ. >> >> Alex >> >>> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> > > > > From alexandru.petrescu@gmail.com Thu Mar 21 06:33:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8D221F8EE1 for ; Thu, 21 Mar 2013 06:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.181 X-Spam-Level: X-Spam-Status: No, score=-10.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vofdsnj7-ft5 for ; Thu, 21 Mar 2013 06:33:25 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 1973F21F8DB9 for ; Thu, 21 Mar 2013 06:33:24 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2LDXL9s014424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 14:33:21 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2LDXKOa031174; Thu, 21 Mar 2013 14:33:21 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2LDXK2R005678; Thu, 21 Mar 2013 14:33:20 +0100 Message-ID: <514B0BF5.2040404@gmail.com> Date: Thu, 21 Mar 2013 14:32:37 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ole Troan References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <51 4B0927.60207@gmail.com> <6C15E952-7432-4C6B-BF20-1CC96AB3B13E@employees.org> In-Reply-To: <6C15E952-7432-4C6B-BF20-1CC96AB3B13E@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 13:33:26 -0000 Le 21/03/2013 14:23, Ole Troan a écrit : > Alex, > >>>>> ULA-5: An IPv6 CE router MUST NOT advertise itself as a >>>>> default router with a Router Lifetime greater than zero >>>>> whenever all of its configured and delegated prefixes are ULA >>>>> prefixes. >>>>> >>>>> Doesn't this make routed home useless as soon as the IPv6 >>>>> Internet connectivity goes away? The ULAs won't get routed >>>>> anymore (solving my problem), but it also makes the desired >>>>> functionality (printer still works when ISP connection is >>>>> down) go away as well. Right? >>>> >>>> In a sense I agree. This ULA-5 requirement forbids growth of >>>> large home-to-home networks. >>>> >>>> This ULA-5 requirement is wrong and shouldnt be there - neither >>>> for CPEs nor for anything else. >>>> >>>> A Router - any Router for that matter - should be able to be a >>>> default router, or not a default router, whenever it wants to, >>>> even though it has no connection to Internet. >>>> >>>> If this is not done (i.e. do not allow default routers when >>>> only ULA addresses are used) then the networks using >>>> exclusively ULA addressing can not scale to large size, because >>>> there may be too many routes at too many Routers. An advantage >>>> of using a default route is that it concentrates the many >>>> routes only in a few-places - the DFZ. >>> >>> that's incorrect. see my reply to Mikael. >> >> YEs, there is something incorrect above, but not all. >> >> In whatever network one builds - use default routes, it's a good >> thing. Don't forbid default routes. > > agree, we'll fix that as soon as the host implementations are fixed. Ole - sorry, do you mean my vanilla linux radvd won't set Lifetime in RA to 0 if I put only ULAs on its interfaces? (I might as well try it...) Alex > > cheers, Ole > > From Carl.Wuyts@technicolor.com Thu Mar 21 06:38:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED7B21F8765 for ; Thu, 21 Mar 2013 06:38:51 -0700 (PDT) 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_13=0.6, 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 XJNawKyjztkL for ; Thu, 21 Mar 2013 06:38:51 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4D35121F8682 for ; Thu, 21 Mar 2013 06:38:49 -0700 (PDT) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKUUsNaJ6AotQ7ba9J1vkrips0cEwQaQo8@postini.com; Thu, 21 Mar 2013 06:38:50 PDT Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 21 Mar 2013 14:36:29 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.135]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Thu, 21 Mar 2013 14:36:37 +0100 From: Wuyts Carl To: Alexandru Petrescu Date: Thu, 21 Mar 2013 14:36:31 +0100 Thread-Topic: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) Thread-Index: Ac4mOE9brPiOs5poTqyoYsffFmaa8AAAAtWw Message-ID: <3135C2851EB6764BACEF35D8B495596806E51C4B81@MOPESMBX01.eu.thmulti.com> References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <3135C2851EB6764BACEF35D8B495596806E5125D84@MOPESMBX01.eu.thmulti.com> <514B08B7.4060000@gmail.com> <3135C2851EB6764BACEF35D8B495596806E51C4B3B@MOPESMBX01.eu.thmulti.com> <514B0B53.90608@gmail.com> In-Reply-To: <514B0B53.90608@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 13:38:52 -0000 So, where do you draw the line, serve a full campus too ? I'd say there's a difference on how/where you use CPEs, but hey, this is ju= st my personal opinion. If you want to directly talk to your customers thr= ough def routes, I'd say you might bump into issues that the ULA used might= not be so "unique", after all, it's private. How will you know the ULA us= ed by your neighbor ? what if it is not persistently saved ? ... Anyway, don't want to keep discussing, seems your mind is made up, fair eno= ugh, no problem. Technicolor is the worldwide # 1 (del oro) in residential CPEs, and the sit= uation you describe is not really fitting in, but it can be done of course,= still, limitations will exist, so you will bump onto some boundaries anywa= y. regs Carl -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: donderdag 21 maart 2013 14:30 To: Wuyts Carl Cc: v6ops@ietf.org Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-u= sage-analysis) Le 21/03/2013 14:22, Wuyts Carl a =E9crit : > Well, seems like there is some misunderstanding here. If all=20 > inhabitants from all these appts know each other and want to be=20 > directly connected through ULA's, you can hardly talk about home CPEs=20 > I'd say, no ? I dont know why? Home CPEs are forbidden from talking to each other? Alex > > Regs Carl > > > > > > -----Original Message----- From: Alexandru Petrescu=20 > [mailto:alexandru.petrescu@gmail.com] Sent: donderdag 21 maart 2013 > 14:19 To: Wuyts Carl Cc: v6ops@ietf.org Subject: Re: [v6ops] questions=20 > regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) > > Le 21/03/2013 10:56, Wuyts Carl a =E9crit : >> But Alexandru, isn't this going 1 step too far ? > > Ok - it is going a little further but not too far. > >> You want to step back the "no def route allowed for ULA" principle ? > > I didnt know there were such a principle, but it should be considered. > >> It's about CPE devices, so I don't see why there would be all of a =20 >> sudden too many routes in some of these use cases ?? Please=20 >> elaborate. > > In an appartment building there may be several CPEs inter-connected. > Within one appartment there may be a single ULA prefix. > > If one Client PC needs to talk to another Client PC in another=20 > appartment then each CPE should have a route for each other CPE. > And each one of these routes should be told to each Client PCs. > > The more the appartments the more routes. > > Small Client PC =3D=3D little memory, long search time. > > OTOH, if one were to use default routes, then the Client PC would need=20 > to store a single default route. > > Alex > >> >> Regs Carl >> >> Le 21/03/2013 10:29, Mikael Abrahamsson a =E9crit : >>> On Thu, 21 Mar 2013, Mikael Abrahamsson wrote: >>> >>>> From rfc6204bis: >>> >>> ULA-5: An IPv6 CE router MUST NOT advertise itself as a default =20 >>> router with a Router Lifetime greater than zero whenever all of its=20 >>> configured and delegated prefixes are ULA prefixes. >>> >>> Doesn't this make routed home useless as soon as the IPv6 Internet=20 >>> connectivity goes away? The ULAs won't get routed anymore (solving=20 >>> my problem), but it also makes the desired functionality (printer=20 >>> still works when ISP connection is down) go away as well. Right? >> >> In a sense I agree. This ULA-5 requirement forbids growth of large =20 >> home-to-home networks. >> >> This ULA-5 requirement is wrong and shouldnt be there - neither for=20 >> CPEs nor for anything else. >> >> A Router - any Router for that matter - should be able to be a=20 >> default router, or not a default router, whenever it wants to, even=20 >> though it has no connection to Internet. >> >> If this is not done (i.e. do not allow default routers when only ULA=20 >> addresses are used) then the networks using exclusively ULA=20 >> addressing can not scale to large size, because there may be too many=20 >> routes at too many Routers. An advantage of using a default route is=20 >> that it concentrates the many routes only in a few-places >> - the DFZ. >> >> Alex >> >>> >> >> >> _______________________________________________ v6ops mailing list =20 >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> > > > > From otroan@employees.org Thu Mar 21 06:44:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE37521F9047 for ; Thu, 21 Mar 2013 06:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 J3wx8kxoF-NZ for ; Thu, 21 Mar 2013 06:44:43 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 190A421F9018 for ; Thu, 21 Mar 2013 06:44:41 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id E1EFF5EBC; Thu, 21 Mar 2013 06:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=/IzrouTTtBl3T0/3T430fwF1kbk=; b=AsvpORXkJyomJ9oo/e fQ9uIopV3ad4ViiqSQmL1ThwGtygZVqJ144sbLYIwX8lRChrpMApuN/8Cdtx/8ME L5l2ckC2grsdI/JFi8GhFTXjQ8glKxSF8GrAWkCK857b6JdbPgHUorguGt26UZYP HIXHtvYnx1KWx05ec0+KZFGYQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=KJKJPbBCbN0GxPDu2io/8CTcpWww6IbOAsEPTuoaN5XN3wa+vRU 3U8oipQDswd5wF4ya5LDtnjDIWKvhccnuxRystQ2qo5TFrr9JLrBXyDj79fp2x8+ D/qCTAPvbC+axboB0FKU6CwCD4ajT2j+deEF6RePaoS0INm7bwdfDnoU= Received: from dhcp-10-61-103-162.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 53F775E73; Thu, 21 Mar 2013 06:44:40 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <514B0BF5.2040404@gmail.com> Date: Thu, 21 Mar 2013 14:44:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <06E82209-7F2A-40BF-BB66-8CD7456B04BA@employees.org> References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <51 4B0927.60207@gmail.com> <6C15E952-7432-4C6B-BF20-1CC96AB3B13E@employees.org> <51 4B0BF5.2 040404@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 13:44:47 -0000 Alex, Tore Anderson did the testing I quoted below in December 2010: if you or someone else could redo that with the latest software and can = ensure us that=20 there no longer are problems with IPv6 breakage, that would be great. cheers, Ole ---------------- Keep in mind that ULAs are p.t. considered no different from any other globally scoped IPv6 address. No current host implementation is special-casing the ULA WKP in any way. This cannot be considered a bug, in my opinion, as the document that will change this is yet to be published by the IETF (draft-ietf-6man-rfc3484-revise). With that in mind, here's a summary of current host behaviour for a host configured with ULA or any other bogon/non-routed global IPv6 address, that attempts to contact a global dual-stacked destination: Case 1) default IPv6 route, no ICMPv6 errors from network: Windows: 21 second timeout in connect() for every published AAAA Mac OS X: 75 second timeout in connect() for every published AAAA Linux: 190 second timeout in connect() for every published AAAA Case 2) default IPv6 route, ICMPv6 errors from network: Windows: like case #1 (ICMPv6 errors appears to be ignored) Mac OS X: four second timeout in connect() (it retransmits TCP SYNs five five times with 1-second intervals before giving up) Linux: instant (i.e. ~RTT to ICMPv6 source) failback to IPv4 Case 3) no default IPv6 route: Windows: internal =ABno route to host=BB generated by IP stack, = instant fallback to IPv4 Mac OS X: like Windows Linux: like Windows Tested versions were Windows 7, Mac OS X 10.6.5, and Fedora 14 (Linux 2.6.35.9). So, the cases where the user remains a =ABhappy eyeball=BB is #3, and = for Linux users only, #2. Also it's worth noting that these timeouts occur for every single connection attempt. While it doesn't sound too bad to endure a four-second timeout (case #2, Mac OS X) to load a web page, all but the most simplest web pages usually have a multitude of elements included, often nested. So a four second timeout will quickly add up to a minute or more for HTTP traffic, which is clearly unacceptable performance both for the end user and for the content provider. Current Mac OS X, however, has a bug in that it will install a default IPv6 route if it receives an RA with a lifetime of 0, provided that it has no current information that was derived from an earlier RA with a lifetime of >0. In other words, invalidating a previously announced default route works, but continuously announcing a ULA prefix in an RIO with lifetime=3D0 will not work as expected. This, however, is clearly a bug and I'm optimistic that it can be fixed by Apple in a timely fashion (at least, it seems more likely than implementing 3484bis or Happy Eyeballs). Also, even if it is not fixed it will "only" mean a four-second connect timeout for the affected users, so in my opinion this is an acceptable compromise that allows the cpe-router draft to realise the ambition of a routed home network usin ULAs while at the same time avoiding ruining the party for the content providers that wants to deploy IPv6.= From alexandru.petrescu@gmail.com Thu Mar 21 06:56:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2410321F8837 for ; Thu, 21 Mar 2013 06:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.182 X-Spam-Level: X-Spam-Status: No, score=-11.182 tagged_above=-999 required=5 tests=[AWL=1.067, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeh7K-8qxWjH for ; Thu, 21 Mar 2013 06:56:53 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id B77DF21F84C9 for ; Thu, 21 Mar 2013 06:56:52 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2LDulP9009869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 14:56:47 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2LDulaO010455; Thu, 21 Mar 2013 14:56:47 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2LDufRS020559; Thu, 21 Mar 2013 14:56:47 +0100 Message-ID: <514B116E.9070504@gmail.com> Date: Thu, 21 Mar 2013 14:55:58 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Owen DeLong References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149C642.6060806@gmail.com> <481173D1-2F02-4B80-8E2C-BE33009EF2C9@delong.com> In-Reply-To: <481173D1-2F02-4B80-8E2C-BE33009EF2C9@delong.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 13:56:55 -0000 Le 20/03/2013 21:49, Owen DeLong a écrit : > > > Sent from my iPad > > On Mar 20, 2013, at 9:22 AM, Alexandru Petrescu > wrote: > >> Le 20/03/2013 14:18, Owen DeLong a écrit : [...] >>>> Well, then you have different concerns about disconnected >>>> operation. >>>> >>> >>> How so? GUA is a perfectly fine alternative for disconnected >>> operation. >> >> YEs and no. >> >> GUA (Global Unicast Addresses) is a good temptation to be used in >> all cases, even in disconnected operation. >> >> But, one should consider the cases of re-connection of moving >> networks at different places in the Internet, successively. >> > > How is GUA not an ideal candidate for this? Seems to me that is the > poster child for PI GUA. (I must say first that I discover the meaning of PI GUA - Provider- Independent Global Unicast Address; it is possible for an Enterprise to request a PI GUA (a prefix actually, I believe) and multi-home that Enterprise to one or several Providers.) (I must also say that all below may not be that true). A PI GUA for 2-3 Enterprises may work connected mostly all the time at the same 2-3 places. But I think 1 billion PI GUAs moving around the Internet at the speed of 1 new connection/minute may not work - it involves 'route churning', i.e. too many routing protocol messages per second and too large routing table entries. Isnt't there a risk like that? I have no figures though. >> In these cases there may be a risk, because a GUA is valid only at >> one topological place. Moving elsewhere one should use a >> different GUA. >> > > No, a GUA can be portable or non-portable. ? Is this something specified in the address? (I heard of prefix coloring?) >> Should we allow two vehicles which have GUAs and meet each other >> to talk to each other directly? At that point would topological >> correctness still be respected with respect to ingress filtering? >> (what if one of the vehicles _is_ connected to the Internet). > > Seems to me that this is an ideal application for either BGP or MIP, Right... we've seen experiments of BGP with planes, and of other vehicles with MIP. > depending on the various factors involved in the nature of the > communication between those vehicles and/or their other topological > relationships. Perhaps even a combination of BGP and MIP. That would be new. >> (I am not saying that ULA completely solves this, but that the use >> of GUA in disconnected operation may be a less tempting >> invitation). > > ULA does not provide any benefits over GUA in this context. Well, we can't just put GUAs in all vehicles of a manufacturer because these GUAs aren't topologically correct everywhere in the Internet. Puting there PI GUAs instead of GUA doesn't help, because they too can't be guaranteed to avoid 'route churn' when we talk large number of vehicles and many different points of connecting to the Internet (large area of mobility like continents). To solve 'route churn' one may use Mobile IP (or other protocol for supporting mobility) - all need an Anchor point in the infrastructure, to which to tunnel. If there's not such Anchor then there's no GUA possible. But the topology corectness and ingress filtering come into question only if we need these vehicles to talk to someone in the Internet - were them to just talk to each other then there wouldn't be a risk of Route Churn - these vehicular networks are not as large as the Internet (will they ever be). Hence we use ULAs. And, when one can have Anchors, one also uses GUAs at the same time as ULAs. One may also use only ULA between a vehicle and its Manufacturer - yet not to the Internet at large. This is a question of where to define the boundary of ULA. Where sits the Border Router? And what's the site? And how to form addresses which are sure to be unique enough witin that site. It's not a question of ULA vs GUA. Alex > > Owen > > > From alexandru.petrescu@gmail.com Thu Mar 21 07:02:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EC721F9075 for ; Thu, 21 Mar 2013 07:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNrFtFuGukq5 for ; Thu, 21 Mar 2013 07:01:59 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 31BBE21F9071 for ; Thu, 21 Mar 2013 07:01:54 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2LE1qD4013159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 21 Mar 2013 15:01:52 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2LE1pkG013211 for ; Thu, 21 Mar 2013 15:01:52 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2LE1pCM030723 for ; Thu, 21 Mar 2013 15:01:51 +0100 Message-ID: <514B12A4.3070108@gmail.com> Date: Thu, 21 Mar 2013 15:01:08 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <8C48B86A895913448548E6D15DA7553B7DDA6D@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B7DDA6D@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:02:08 -0000 Le 20/03/2013 21:41, Fred Baker (fred) a écrit : [...] > I think the primary issue that people are really raising here is > "please don't NAT". IMHO, there are already NAT66 products out > there, I agree! NAT66 is a very tempting technology for vehicular networks as well. It is so surprising how there are so many IPv6 specifications for vehicular communications relying on the fact that in IPv6 there is no NAT... and now this ip6tables MASQUERADE (i.e. NAT66) alone which is not even specified may turn everything upside down. Alex > and I have customers chomping at the bit to deploy them. I agree > that stateful NAT was at best an evil we chose to live with. I'm not > sure that complaining about them will make them go away. But in a > world without NATs, there are still valid uses for a prefix that is > advertised only within a bounded domain. I do wonder why we are so > bent on tossing the baby while we complain about the bathwater. > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From brian.e.carpenter@gmail.com Thu Mar 21 07:10:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD2A21F8E5E for ; Thu, 21 Mar 2013 07:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.079 X-Spam-Level: X-Spam-Status: No, score=-99.079 tagged_above=-999 required=5 tests=[AWL=-0.473, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_MILLIONSOF=0.315, 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 2sGkl8Xoqi8n for ; Thu, 21 Mar 2013 07:10:01 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 21B2E21F884B for ; Thu, 21 Mar 2013 07:10:00 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id c10so1250889wiw.2 for ; Thu, 21 Mar 2013 07:10:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zkkZA2ZnbXpxCb8MDYl4zu5fQ3neTezllX9XGB5fE2U=; b=bl2Bn7E1tKVWTwwrWQQykbU9mj1GbusHKtmdAWaX2MrJHyWrGwHTHAWNR7csNciAMC 3oDxgGl1IyhpmiYxeLu/SNKV8JAaW8E8upimLVPfNdFLejwJ5KxO9P2Rn6BBCtGnGYVB mTj1WsCWeovMHecR7rGA5cyuRIuPPFK/AzK7GeuuBK+NbD0oUKdCJcc2j9p9byCJWOBl Op6Yq4pWjO4iS+OX3NJSkCZCfV6+b8VOP/ixuObcOl0Rjnlb3v9RFeq5o3tw9yhYM7xN B3h1+BEQhyysL4H/VbLplQo25KIfyxCSPO2hHy+3CF/Tl5+9g7vPGEpKaiQz1GHXxjQi yy2Q== X-Received: by 10.180.94.69 with SMTP id da5mr5139826wib.30.1363875000154; Thu, 21 Mar 2013 07:10:00 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-189-49.as13285.net. [2.101.189.49]) by mx.google.com with ESMTPS id t7sm4963860wij.2.2013.03.21.07.09.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Mar 2013 07:09:59 -0700 (PDT) Message-ID: <514B14C2.3050303@gmail.com> Date: Thu, 21 Mar 2013 14:10:10 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149C642.6060806@gmail.com> <481173D1-2F02-4B80-8E2C-BE33009EF2C9@delong.com> <514B116E.9070504@gmail.com> In-Reply-To: <514B116E.9070504@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:10:02 -0000 On 21/03/2013 13:55, Alexandru Petrescu wrote: ... > A PI GUA for 2-3 Enterprises may work connected mostly all the time at > the same 2-3 places. But I think 1 billion PI GUAs moving around the > Internet at the speed of 1 new connection/minute may not work - it > involves 'route churning', i.e. too many routing protocol messages per > second and too large routing table entries. Isnt't there a risk like that? Well, it was three or four orders of magnitude smaller, but there were a lot of complaints about the churn produced by Connexion by Boeing, which was effectively a few hundred IPv4 PI prefixes moving around at almost Mach 1. OK, it's not a fair comparison, but I think we're on safe ground in doubting that increasing from 30k to millions of PI prefixes will work smoothly. Brian From alexandru.petrescu@gmail.com Thu Mar 21 07:11:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95CF821F90AC for ; Thu, 21 Mar 2013 07:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.889 X-Spam-Level: X-Spam-Status: No, score=-9.889 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPEmn7PcBw1z for ; Thu, 21 Mar 2013 07:11:20 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 4524E21F9046 for ; Thu, 21 Mar 2013 07:11:20 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2LEBJM1030477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 15:11:19 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2LEBImu018021; Thu, 21 Mar 2013 15:11:19 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2LEBE1Z004952; Thu, 21 Mar 2013 15:11:18 +0100 Message-ID: <514B14D8.9020401@gmail.com> Date: Thu, 21 Mar 2013 15:10:32 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Wuyts Carl References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <3135C2851EB6764BACEF35D8B495596806E5125D84@MOPESMBX01.eu.thmulti.com> <514B08B7.4060000@gmail.com> <3135C2851EB6764BACEF35D8B495596806E51C4B3B@MOPESMBX01.eu.thmulti.com> <514B0B53.90608@gmail.com> <3135C2851EB6764BACEF35D8B495596806E51C4B81@MOPESMBX01.eu.thmulti.com> In-Reply-To: <3135C2851EB6764BACEF35D8B495596806E51C4B81@MOPESMBX01.eu.thmulti.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:11:21 -0000 Le 21/03/2013 14:36, Wuyts Carl a écrit : > So, where do you draw the line, serve a full campus too ? YEs - a full campus as well. And even its sister campus if there it were. (multi-site Enterprises...) > I'd say there's a difference on how/where you use CPEs, but hey, this > is just my personal opinion. If you want to directly talk to your > customers through def routes, I'd say you might bump into issues that > the ULA used might not be so "unique", after all, it's private. That uniqueness is embedded in the way the ULAs are generated. The RFC gives an example algorithm. That algorithm should be improved (maybe also because it says 'SHA-1'). And there should be many variants of that algorithm. FOr each such site the uniqueness aspect can be derived from the nature of the site. If the site were a Zoo then use the animal names to form the unique ULAs and state that the Border Router is at the top of the Zoo. > How will you know the ULA used by your neighbor ? what if it is not > persistently saved ? ... That is right, I dont know how... maybe DNS, DNS Update? (once we say which protocol is used between neighbors to update their routes, then we can say also whether DHCP is involved, and thus DNS and so). > Anyway, don't want to keep discussing, seems your mind is made up, > fair enough, no problem. Technicolor is the worldwide # 1 (del oro) > in residential CPEs, and the situation you describe is not really > fitting in, but it can be done of course, still, limitations will > exist, so you will bump onto some boundaries anyway. YEs - barriers are defined here, at the same time as the ULA formation algorithms. Alex > > regs > > Carl > > > -----Original Message----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Sent: donderdag 21 maart 2013 > 14:30 To: Wuyts Carl Cc: v6ops@ietf.org Subject: Re: [v6ops] > questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) > > Le 21/03/2013 14:22, Wuyts Carl a écrit : >> Well, seems like there is some misunderstanding here. If all >> inhabitants from all these appts know each other and want to be >> directly connected through ULA's, you can hardly talk about home >> CPEs I'd say, no ? > > I dont know why? Home CPEs are forbidden from talking to each > other? > > Alex > >> >> Regs Carl >> >> >> >> >> >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: donderdag 21 maart >> 2013 14:19 To: Wuyts Carl Cc: v6ops@ietf.org Subject: Re: [v6ops] >> questions regarding rfc6204bis ( >> draft-liu-v6ops-ula-usage-analysis) >> >> Le 21/03/2013 10:56, Wuyts Carl a écrit : >>> But Alexandru, isn't this going 1 step too far ? >> >> Ok - it is going a little further but not too far. >> >>> You want to step back the "no def route allowed for ULA" >>> principle ? >> >> I didnt know there were such a principle, but it should be >> considered. >> >>> It's about CPE devices, so I don't see why there would be all of >>> a sudden too many routes in some of these use cases ?? Please >>> elaborate. >> >> In an appartment building there may be several CPEs >> inter-connected. Within one appartment there may be a single ULA >> prefix. >> >> If one Client PC needs to talk to another Client PC in another >> appartment then each CPE should have a route for each other CPE. >> And each one of these routes should be told to each Client PCs. >> >> The more the appartments the more routes. >> >> Small Client PC == little memory, long search time. >> >> OTOH, if one were to use default routes, then the Client PC would >> need to store a single default route. >> >> Alex >> >>> >>> Regs Carl >>> >>> Le 21/03/2013 10:29, Mikael Abrahamsson a écrit : >>>> On Thu, 21 Mar 2013, Mikael Abrahamsson wrote: >>>> >>>>> From rfc6204bis: >>>> >>>> ULA-5: An IPv6 CE router MUST NOT advertise itself as a >>>> default router with a Router Lifetime greater than zero >>>> whenever all of its configured and delegated prefixes are ULA >>>> prefixes. >>>> >>>> Doesn't this make routed home useless as soon as the IPv6 >>>> Internet connectivity goes away? The ULAs won't get routed >>>> anymore (solving my problem), but it also makes the desired >>>> functionality (printer still works when ISP connection is down) >>>> go away as well. Right? >>> >>> In a sense I agree. This ULA-5 requirement forbids growth of >>> large home-to-home networks. >>> >>> This ULA-5 requirement is wrong and shouldnt be there - neither >>> for CPEs nor for anything else. >>> >>> A Router - any Router for that matter - should be able to be a >>> default router, or not a default router, whenever it wants to, >>> even though it has no connection to Internet. >>> >>> If this is not done (i.e. do not allow default routers when only >>> ULA addresses are used) then the networks using exclusively ULA >>> addressing can not scale to large size, because there may be too >>> many routes at too many Routers. An advantage of using a default >>> route is that it concentrates the many routes only in a >>> few-places - the DFZ. >>> >>> Alex >>> >>>> >>> >>> >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> >> >> > > > > From brian.e.carpenter@gmail.com Thu Mar 21 07:17:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EABC621F9061 for ; Thu, 21 Mar 2013 07:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.6 X-Spam-Level: X-Spam-Status: No, score=-100.6 tagged_above=-999 required=5 tests=[AWL=1.091, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, 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 wVynS3cM-42x for ; Thu, 21 Mar 2013 07:17:01 -0700 (PDT) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by ietfa.amsl.com (Postfix) with ESMTP id C40BF21F9054 for ; Thu, 21 Mar 2013 07:17:00 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id e49so1737278eek.5 for ; Thu, 21 Mar 2013 07:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SD5dealkVIIfe5iCVMbWRT96SE8sYmZnmpmz5RKb9kk=; b=LskE0K9tcxNsJVY0DY3HPtZIkUtG0GiJtaXNKXTHjZC8P51yZ2vNwNaMoShktEluot sn3qzeP51/8Dlmq31uYGd7HVZzK7Aqo7qi8CfysMLExwYqJiTIoR5eHawxh9Mzg2EJSY k17UKzTpmWsmtAOqnbncvK9qXXAe/wq2LGqjje0h3M1D1UMvSOkIKfbA7hICXXRQbSiU qnz/T+7Qhf0Wh/BiX4kpJvh2c+/Q+VWMo+iOqE6GCf3SDcfBhtaiNNhVkkZiDeEyIYNR oMqyMokipUZfHMDvUAsc704V3x7ThHfyEEqTRAUdWdRraScw8GGMJjvhO3guUF9M5tGo kt4Q== X-Received: by 10.14.223.69 with SMTP id u45mr82777076eep.23.1363875419904; Thu, 21 Mar 2013 07:16:59 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-189-49.as13285.net. [2.101.189.49]) by mx.google.com with ESMTPS id h5sm8684773eem.1.2013.03.21.07.16.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Mar 2013 07:16:58 -0700 (PDT) Message-ID: <514B1665.4000101@gmail.com> Date: Thu, 21 Mar 2013 14:17:09 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <3135C2851EB6764BACEF35D8B495596806E5125D84@MOPESMBX01.eu.thmulti.com> <514B08B7.4060000@gmail.com> <3135C2851EB6764BACEF35D8B495596806E51C4B3B@MOPESMBX01.eu.thmulti.com> <514B0B53.90608@gmail.com> In-Reply-To: <514B0B53.90608@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:17:02 -0000 On 21/03/2013 13:29, Alexandru Petrescu wrote: > Le 21/03/2013 14:22, Wuyts Carl a =C3=A9crit : >> Well, seems like there is some misunderstanding here. If all >> inhabitants from all these appts know each other and want to be >> directly connected through ULA's, you can hardly talk about home >> CPEs I'd say, no ? >=20 > I dont know why? Home CPEs are forbidden from talking to each other? There's a terminology problem here. The phrase "customer premises equipment" implies that there's a customer and an incumbent telco, and that is the only relationship to be considered. That's the context for RFC6204(bis). Alexandru is talking about a homenet router, that may have multiple service provider relationships plus neighbourhood relationships. That's a different "business model" entirely, and there is no reason in principle why a group of neighbours can't route among themselves using prefixes that are nothing to do with any ISP. Brian From owen@delong.com Thu Mar 21 07:21:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD35E21F905C for ; Thu, 21 Mar 2013 07:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.414 X-Spam-Level: X-Spam-Status: No, score=-1.414 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 o8IzJuJMndxL for ; Thu, 21 Mar 2013 07:21:17 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 36D7121F87D3 for ; Thu, 21 Mar 2013 07:21:17 -0700 (PDT) Received: from [10.183.205.4] (mobile-198-228-232-211.mycingular.net [198.228.232.211]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2LEIpCW028743 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Mar 2013 07:18:53 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2LEIpCW028743 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363875534; bh=XBrahjsm6NNwld6sCmEOoKi0eh4=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=vt2oDZvuxrIxUlvAt1vMHJOQlp7wnLDByslLW0ycR/psMQXwK/sGYMSGUONu2jPFK EwMH0gr/TgyBetIRGVPWmTUNnWEdImbFm75ZKDHQsnB+BsBv4ymB7HJdPdaltcgfxZ gemKHLlUlzk/M0y2qPx4mpYArQbxyEBhm46LpCCE= References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <20130321034917.71CCD3147294@drugs.dv.isc.org> <7F0F3F2D-2705-413B-A548-A5C820044BC7@delong.com> <20130321060739.52FD93148050@drugs.dv.isc.org> Mime-Version: 1.0 (1.0) In-Reply-To: <20130321060739.52FD93148050@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B146) From: Owen DeLong Date: Thu, 21 Mar 2013 09:18:50 -0500 To: Mark Andrews X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 21 Mar 2013 07:18:54 -0700 (PDT) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:21:18 -0000 >> Without those flags, it is unlikely that it would have made multiple =3D >> IPv6 attempts before falling back to IPv4, but, rather would have made =3D= >> one IPv6 attempt, then upon getting the unreachable, immediately try =3D >> IPv4. >>=20 >> Owen >=20 > With modern stacks you just tell them to prefer the /48 ULA you are > using and depreference all other ULA use. If I was to disable all > other prefixes then IPv4 would be used for external connections. >=20 > % cat /etc/ip6addrctl.conf=20 > #Prefix Prec Label =20 > ::1/128 50 0 > ::/0 40 1 =20 > 2002::/16 30 2 =20 > ::/96 20 3 =20 > ::ffff:0.0.0.0/96 35 4 =20 > fd92:7065:b8e::/48 45 5=20 > fc00::/7 5 6 >=20 Remind me where I configure the router to send the contents of ip6addrctl.co= nf down to the SLAAC client... Oh, right... Owen= From owen@delong.com Thu Mar 21 07:36:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB4321F90B3 for ; Thu, 21 Mar 2013 07:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.372 X-Spam-Level: X-Spam-Status: No, score=-1.372 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 07MFtF9sPx34 for ; Thu, 21 Mar 2013 07:36:12 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEAE21F90B1 for ; Thu, 21 Mar 2013 07:36:12 -0700 (PDT) Received: from [10.183.205.4] (mobile-198-228-232-211.mycingular.net [198.228.232.211]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2LEXA1n029173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Mar 2013 07:33:12 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2LEXA1n029173 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363876393; bh=xS9dptne3L8DZebQec4pya+T2T0=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=WGIYAnBpCoTzcZ+0GcS29i87GV6TKurYQW2L9IyiBLoxJKHgqLi8WlzLcbHfdCZlc vPVvKFkHiSg7khja2fFVZrD6xNTE5FFmhFa/BSs9R2c5PPAFGxdH5DBtCM5ijSRmqq eZLBQrWfw2uWxnvrVU4OaKwE3eQeIfr9MQbhppV4= References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149EBE2.5000908@gmail.com> <0A02847A-F67C-4285-A540-8A7A6497ACF3@delong.com> <514ABC93.3000608@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <514ABC93.3000608@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <573F4589-56D1-4049-8E86-B52239D945D6@delong.com> X-Mailer: iPad Mail (10B146) From: Owen DeLong Date: Thu, 21 Mar 2013 09:33:08 -0500 To: Alexandru Petrescu X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 21 Mar 2013 07:33:13 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:36:13 -0000 >>>> What worries me is that in non-zeroconf environments, or those >>>> where manual override is possible, administrators will use >>>> fc00::/48, as it's easier to type/remember. >>>=20 >>> But not what the RFC says - it's wrong sysadmin. >>=20 >> Which matters here in the ivory tower, but makes no difference in the >> real world. >=20 > In a sense yes, but what better could one do? DEsign a better way to > generate this uniqueness? There are ways for that, like starting from > truly unique application-specific immutable IDs which hardly ever > experienced collisions (like MAC-based did). As I said at the time ULA was discussed, the best thing would have been to r= ecognize GUA as a preferable alternative and make better provisions for GUA t= o be used for disconnected networks. Unfortunately, at this point, that ship= has sailed. Now it boils down to limiting the damage done by ULA. To do tha= t, we need to recognize that ULA can and will be deployed stupidly in spite o= f the warnings in the ULA RFCs. As a result, we should avoid creating additi= onal RFCs which depend on ULA not being deployed stupidly and make sure, ins= tead, that future RFCs are designed with this expectation in mind. >>> So, Lorenzo, I wouldnt qualify it as strongly. There _is_ much >>> hope. >>=20 >> Only among overly optimistic idealists. >=20 > There could be ways to be less idealistic and yet come up with unique > ULAs in certain contexts. Sure, but we can't rationally depend on that happening in all cases which is= what you were proposing in claiming that there is "much hope". >>> Anyone who tried to configure ULAs according to that RFC knows >>> that there is some level of uniqueness guaranteed. >>=20 >>=20 >> No, there is no level of uniqueness guaranteed. There is a >> statistically high probability of uniqueness for those who deploy >> ULA according to the RFC. Even there, there is no guarantee of any >> level of uniqueness, just a strong probability. >=20 > I think this statement assumes exclusively the suggested ULA generation > algorithm in the RFC. But better algorithms could be made which remove > that probability factor, in certain contexts. OK, so now I'm confused. First you argue that the ULA RFC as is provides uniqueness and we can ignore the fact that it won't be reliably implemented per the RFC. Now you're arguing that violating the RFC is an even better way to go so that we can get guaranteed uniqueness? It is precisely the tendency for ULA discussions to spiral into tight little= circles like this that convinces me that ULA is a quagmire which causes many more problems than it solves. >> However, the probability that the majority of administrators will >> even read the ULA RFC (how many people do you think have actually >> read RFC-1918 vs. the number that have deployed 10/8 or any other >> RFC-1918 address? I'll give you a hint... Ask a bunch of >> administrators which of the following are RFC-1918 addresses. If >> it's not an open book test, I bet the results surprise you. >=20 > I agree in a sense, I let myself surprised by that. But things could be > done about it. Such as? >> 172.16.5.3 Everyone will probably get this right. >> 172.30.19.6 About half will get this wrong. >> 172.32.99.7 The other half will get this wrong. >> 172.80.15.7 About half of the ones that got the previous qu= estion wrong will >> also get this one wrong. >=20 > I got them all wrong at a quick view. I'd have to read the RFC1918 and fi= nd the prefix length of the 172. private addresses to do it right. Fortunate= ly there's that RFC. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 Yes, but how many of the IT professionals running IPv4 RFC-1918 addressed ne= tworks even know the number? How many of those have actually read the RFC? (= If it's more than 5% I would be very surprised). Do you have any idea how ma= ny people I talk to that still say "RFC-1597?" >>> (if one just tries to just try quickly ifconfig add fd::1/64 then >>> it's probably not according to the RFC, which would want more digits the= re.) >>=20 >> fd::1/64 isn't even ULA, but I wouldn't put it past administrators to thi= nk it is. >=20 > Corrected. It's not fd::1/64 but fd00::1/64. That's at least ULA... >> fd00::1/64, OTOH, will probably be the most common ULA gateway address. >=20 > Let's put that in a document! State upfront that sysadmins should not > assign fd00::1/64 on any interface (be that default or not) because it > doesnt have enough intermediary bits such that to be unique - not an ULA > by RFC. There are a number of problems with this theory. First, if you don't see the= parallels between this line of thinking and the reason that every applicati= on on the internet runs over TCP/80 or TCP/443 regardless of the application= layer protocol these days, then you aren't paying attention. However, in more detail: 1. What makes you think that an administrator that didn't read the original R= FC would read and heed this additional document? 2. The next logical thing is that they all move to fd01::1/64. Do we keep pu= blishing documents until we run out of easy to remember ULA addresses? The need here isn't to change the administrator's behavior because we don't l= ike the outcome. The need here is to recognize that administrators live and w= ork in the real world where they have enough complexity in their lives witho= ut adding very large random numbers to their daily routine. Having prefixes w= hich are easy to remember has value to them and no amount of effort to tell t= hem to make their lives more difficult with little or no perceived immediate= benefit is not likely to be readily accepted by them. Owen From owen@delong.com Thu Mar 21 07:46:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDCA121F90B4 for ; Thu, 21 Mar 2013 07:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.343 X-Spam-Level: X-Spam-Status: No, score=-1.343 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 RVtv0TPr2i30 for ; Thu, 21 Mar 2013 07:46:27 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5331921F9063 for ; Thu, 21 Mar 2013 07:46:27 -0700 (PDT) Received: from [10.183.205.4] (mobile-198-228-232-211.mycingular.net [198.228.232.211]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2LEhbuE031211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Mar 2013 07:43:41 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2LEhbuE031211 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363877022; bh=AyOJ3tsgK6ebiNhWCFdqD+8Aq/c=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=APoeh9st8rPi1+jC76pJJh0lupLB2GGnDNQArZvngDCs9PHIIaNQd0QuEkXPJQxrQ ST3UQ5bKm6ZFukfjmjPQk8Dau0i939HVJwMZr1HnqWBiCl50VFUxZAqvEw5diXBL9U HwQTawrvqc6hRz5gJ6Vx8CQexXmKIF2+XJIuufyU= References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <514AD5FE.2020705@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong.com> X-Mailer: iPad Mail (10B146) From: Owen DeLong Date: Thu, 21 Mar 2013 09:43:36 -0500 To: Alexandru Petrescu X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 21 Mar 2013 07:43:42 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:46:43 -0000 >>> =46rom rfc6204bis: >>=20 >> ULA-5: An IPv6 CE router MUST NOT advertise itself as a default >> router with a Router Lifetime greater than zero whenever all >> of its configured and delegated prefixes are ULA prefixes. >=20 > This ULA-5 requirement is wrong and shouldnt be there - neither for CPEs > nor for anything else. I disagree... ULA-5 is an important safeguard. If you want to build a large home-to-home network, do it with GUA, ULA is poorly suited to the task. > A Router - any Router for that matter - should be able to be a default > router, or not a default router, whenever it wants to, even though it > has no connection to Internet. That's worked out so well in Japan so far.... NOT! > If this is not done (i.e. do not allow default routers when only ULA > addresses are used) then the networks using exclusively ULA addressing > can not scale to large size, because there may be too many routes at too > many Routers. An advantage of using a default route is that it > concentrates the many routes only in a few-places - the DFZ. This is not a bad thing. If you want to scale a network to large size, then e= ither use GUA or expect to have to put some effort into the routing process.= ULA-5 does not prevent the router from being a default router. It prevents t= he router from advertising itself as a default router via RA packets. It can still advertise an OSPF default, BGP default, and/or participate in V= RRP. We should, in all cases, avoid doing things that are damaging to GUA-based i= nstallations for the sake of making ULA work better for fringe cases. Owen From owen@delong.com Thu Mar 21 07:56:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8A721F90B9 for ; Thu, 21 Mar 2013 07:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.323 X-Spam-Level: X-Spam-Status: No, score=-1.323 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 k0GhLe2geggS for ; Thu, 21 Mar 2013 07:56:35 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D2B0021F90CA for ; Thu, 21 Mar 2013 07:56:31 -0700 (PDT) Received: from [10.183.205.4] (mobile-198-228-232-211.mycingular.net [198.228.232.211]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2LEr91j031842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Mar 2013 07:53:12 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2LEr91j031842 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363877594; bh=Z6Uy4yS0Bi2Is3MW2QcT7nDXs/E=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=Nmi2jrTh0m5dnCt4IBMF/rtZDO4eavrNlbvCFQZQpCBK+Y14HTUmzznrrD/5BLJLH aWNp+lha25cgbxANdQI5t+WyYpidLWeEzJQIf3s5IlAnxom9THUlyccvgf65GfluZ0 RW3ZUs2xRG43/rwMp0A/QDYqYgcUh2B+10vbK2O0= References: <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <3135C2851EB6764BACEF35D8B495596806E5125D84@MOPESMBX01.eu.thmulti.com> <514B08B7.4060000@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <514B08B7.4060000@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <359831AD-83EB-43AB-932F-5A248178D202@delong.com> X-Mailer: iPad Mail (10B146) From: Owen DeLong Date: Thu, 21 Mar 2013 09:53:08 -0500 To: Alexandru Petrescu X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 21 Mar 2013 07:53:14 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:56:43 -0000 > In an appartment building there may be several CPEs inter-connected. > Within one appartment there may be a single ULA prefix. >=20 > If one Client PC needs to talk to another Client PC in another > appartment then each CPE should have a route for each other CPE. And > each one of these routes should be told to each Client PCs. >=20 > The more the appartments the more routes. >=20 > Small Client PC =3D=3D little memory, long search time. I'm sorry, but let's move back to the real world for a moment. My raspberry PI has more memory and can probably do route lookups faster tha= n most of the home-routers that are on the market today. The scale problem h= ere isn't on the client PCs being able to handle =E2=89=A41000 prefixes, it'= s in the CPE routers being unable to handle =E2=89=A5 32 prefixes or so in m= ost cases. Since your default route proposal would still require all of the C= PE routers to carry all of the ULA routes and not use a default, it fails in= the real world. > OTOH, if one were to use default routes, then the Client PC would need > to store a single default route. $35 Client PC =3D 1000s of routes workable with reasonable forwarding speeds= . $60 CPE Router =3D Can't handle 100s of routes, let alone 1000s. But thanks for playing. Owen From owen@delong.com Thu Mar 21 08:06:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9DB321F9105 for ; Thu, 21 Mar 2013 08:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.308 X-Spam-Level: X-Spam-Status: No, score=-1.308 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 abUGlj6uTY-6 for ; Thu, 21 Mar 2013 08:06:14 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 30A0C21F9104 for ; Thu, 21 Mar 2013 08:06:14 -0700 (PDT) Received: from [10.183.205.4] (mobile-198-228-232-211.mycingular.net [198.228.232.211]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2LF5Wxg002769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Mar 2013 08:05:35 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2LF5Wxg002769 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363878336; bh=lLHZLz1gSEXz5AOCkAiCvvKw7zw=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=IymGuUd0XA8cXeGmc6GxSTU4VYy6MEv4jZeYjgqV9mDNITva9VRs8cOiVpWwsd7Bv otwxOmr61p6PT6e/hXxcUKKjt4FY8c9OQuDjhmhp21lZohppsC1GV8CdRhUGkxK/hZ 0xDNnq5IylxCJV6+ql/FSCfLDcC8ZaNbypzZ2HsM= References: <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149D452.8020209@gmail.com> <20130321101247.GB19136@spike.0x539.de> Mime-Version: 1.0 (1.0) In-Reply-To: <20130321101247.GB19136@spike.0x539.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <590084D6-A0FD-4F56-B42F-57F2D0CF8874@delong.com> X-Mailer: iPad Mail (10B146) From: Owen DeLong Date: Thu, 21 Mar 2013 10:05:31 -0500 To: Philipp Kern X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 21 Mar 2013 08:05:36 -0700 (PDT) Cc: "v6ops@ietf.org Operations" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 15:06:15 -0000 Sent from my iPad On Mar 21, 2013, at 5:12 AM, Philipp Kern wrote: > Owen, >=20 > am Wed, Mar 20, 2013 at 03:58:51PM -0500 hast du folgendes geschrieben: >> Remember, the RIRs are not for profit entities. Larger quantities of end-= user >> registrations should directly equate to lower fees. >=20 > only if it can be automated. If you still need to have people reviewing > contracts, checking a company's registration and stuff you'd likely need m= ore > people to process them, which means higher cost. Every RIR does a lot of things besides processing registrations. Yes, the CO= GS per request would probably remain fairly constant... Increased workload =3D= more employees and costs there scale roughly linearly with requests. Howeve= r, the costs of outreach, meetings, list administration, DNS server maintena= nce, etc. all remain relatively fixed and increasing the number of entities b= y which those numbers are divided will inherently lower the cost per organiz= ation. > If it were similar to the domain registries, I'd tend to agree that the pr= ice > should be much lower. Like the LIR checking all requirements, have the RIR= > trust the LIR on this and automatically give out PI assignments up to a > certain size. That might be valid way to further reduce costs. Owen From owen@delong.com Thu Mar 21 08:16:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C989521F90AC for ; Thu, 21 Mar 2013 08:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.906, BAYES_00=-2.599, GB_I_INVITATION=-2, MIME_QP_LONG_LINE=1.396] 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 nN2XWOm4vxmw for ; Thu, 21 Mar 2013 08:16:19 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id EBD0E21F90A6 for ; Thu, 21 Mar 2013 08:16:18 -0700 (PDT) Received: from [10.183.205.4] (mobile-198-228-232-211.mycingular.net [198.228.232.211]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2LFEGVX004762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Mar 2013 08:14:21 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2LFEGVX004762 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363878862; bh=t8+qaY00BAXkL0vE3QkWrmrFX3g=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=Ax5bMy/iH/tTIITK14fzyNhXIK1G9F92u44WYycO7gavWpcjf3Bp+SZxbryN7+BMX h1Gopwpt8wlXuKWA3VoFZbV5TBmO9KkDALRwuIuNgLqbUXy6fRDWdMLfmKhRyL3cif gCjlhxtOW2qIo/dfJPw9BwZyMuWdkmrG6AVuXeK0= References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149C642.6060806@gmail.com> <481173D1-2F02-4B80-8E2C-BE33009EF2C9@delong.com> <514B116E.9070504@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <514B116E.9070504@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B146) From: Owen DeLong Date: Thu, 21 Mar 2013 10:14:17 -0500 To: Alexandru Petrescu X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 21 Mar 2013 08:14:22 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 15:16:19 -0000 >>> But, one should consider the cases of re-connection of moving >>> networks at different places in the Internet, successively. >>=20 >> How is GUA not an ideal candidate for this? Seems to me that is the >> poster child for PI GUA. >=20 > (I must say first that I discover the meaning of PI GUA - Provider- > Independent Global Unicast Address; it is possible for an Enterprise > to request a PI GUA (a prefix actually, I believe) and multi-home that > Enterprise to one or several Providers.) >=20 This explains a lot... > (I must also say that all below may not be that true). >=20 > A PI GUA for 2-3 Enterprises may work connected mostly all the time at > the same 2-3 places. But I think 1 billion PI GUAs moving around the > Internet at the speed of 1 new connection/minute may not work - it > involves 'route churning', i.e. too many routing protocol messages per > second and too large routing table entries. Isnt't there a risk like that= ? Right... For the latter, MIP is probably a better solution than BGP. >>> In these cases there may be a risk, because a GUA is valid only at >>> one topological place. Moving elsewhere one should use a >>> different GUA. >>=20 >> No, a GUA can be portable or non-portable. >=20 > ? Is this something specified in the address? (I heard of prefix > coloring?) Not really. (I don't know what you actually mean by prefix coloring). If you get a prefix from an ISP, it is most likely non-portable. The ISP wil= l let you use the prefix as long as you are connected to them, but when you disconnect from th= em, you must stop using the prefix. If, OTOH, you get the prefix from an RIR or other non-ISP LIR or NIR, then p= robably it is "portable" meaning you can connect and disconnect from ISPs th= at will accept your advertisement of said prefix into their routing tables a= nd forward said advertisement to other autonomous systems on your behalf. >>> Should we allow two vehicles which have GUAs and meet each other >>> to talk to each other directly? At that point would topological >>> correctness still be respected with respect to ingress filtering? >>> (what if one of the vehicles _is_ connected to the Internet). >>=20 >> Seems to me that this is an ideal application for either BGP or MIP, >=20 > Right... we've seen experiments of BGP with planes, and of other > vehicles with MIP. Yep... I expect we'll see a lot more of this in the future. >> depending on the various factors involved in the nature of the >> communication between those vehicles and/or their other topological >> relationships. Perhaps even a combination of BGP and MIP. >=20 > That would be new. Not so new. I've been multihomed using BGP at home for more than a decade. >>> (I am not saying that ULA completely solves this, but that the use >>> of GUA in disconnected operation may be a less tempting >>> invitation). >>=20 >> ULA does not provide any benefits over GUA in this context. >=20 > Well, we can't just put GUAs in all vehicles of a manufacturer because > these GUAs aren't topologically correct everywhere in the Internet. > Puting there PI GUAs instead of GUA doesn't help, because they too can't > be guaranteed to avoid 'route churn' when we talk large number of > vehicles and many different points of connecting to the Internet (large > area of mobility like continents). So what? If they're non-connected (and ULA would be non-connected and equall= y topologically incorrect), what's the difference? >=20 > To solve 'route churn' one may use Mobile IP (or other protocol for > supporting mobility) - all need an Anchor point in the infrastructure, > to which to tunnel. If there's not such Anchor then there's no GUA > possible. My point is that GUA is equally possible and workable to ULA. The only diffe= rence in that case is that with ULA, there's no hope of ever making those ad= dresses connected by any means. With GUA, you may be unable to do so practic= ally, but at least you have various options which you can try. > But the topology corectness and ingress filtering come into question > only if we need these vehicles to talk to someone in the Internet - were > them to just talk to each other then there wouldn't be a risk of Route > Churn - these vehicular networks are not as large as the Internet (will > they ever be). >=20 > Hence we use ULAs. What difference does it make in the disconnected case that you use ULA inste= ad of GUA? What advantage do you perceive from the ULAs in that context? > And, when one can have Anchors, one also uses GUAs at the same time as > ULAs. One may also use only ULA between a vehicle and its Manufacturer > - yet not to the Internet at large. What, exactly, are you gaining from this additional unnecessary complexity? > This is a question of where to define the boundary of ULA. Where sits > the Border Router? And what's the site? And how to form addresses > which are sure to be unique enough witin that site. This question is identical whether one uses ULA or GUA for this purpose. > It's not a question of ULA vs GUA. That may not be your current question, but it is most certainly the question= applicable to the issues I was raising. Owen From brian.e.carpenter@gmail.com Thu Mar 21 08:26:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E824C21F905A for ; Thu, 21 Mar 2013 08:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.647 X-Spam-Level: X-Spam-Status: No, score=-100.647 tagged_above=-999 required=5 tests=[AWL=1.044, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, 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 q4ZCaajNDAWX for ; Thu, 21 Mar 2013 08:26:56 -0700 (PDT) Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7555621F9132 for ; Thu, 21 Mar 2013 08:26:50 -0700 (PDT) Received: by mail-ee0-f50.google.com with SMTP id e51so1839381eek.37 for ; Thu, 21 Mar 2013 08:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=a4qEPSI6Y65NIARb5QeKeJljGE9lRELx/mBEpxihsDk=; b=y3F8RNj01FhOtRRNZ4usctruSzwhF2WjF2AjLhevn80Igw2SH0o6ubG+PsbQOeOVQp NlJ+8AhZjVD6XUXU9nbpcBVjIz56iZ92eoX7W718HeJF2pjsSL09cCLoUpk/wJGtBAeu qXbEuosNpkjIEiW08ZtGP9ZGvtSOwoV4oebi3F1EY63w8LKg6JQtm0MaXSOpqEnArX+p foJkw0oV2fGKLd3pk0rqKSHQ8kJPAF3RDvjl+0fEdAhOm/KuZ4t/j9eOb8n+RMofb3sP dpXyABUuSlAzTx3ka4p4a+NwxYTGL+dtfaknilB0mpAYqSZlHWKrbk0qkjgIcxjwTXmP Id4A== X-Received: by 10.14.0.73 with SMTP id 49mr83882454eea.21.1363879609578; Thu, 21 Mar 2013 08:26:49 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-189-49.as13285.net. [2.101.189.49]) by mx.google.com with ESMTPS id q42sm9050457eem.14.2013.03.21.08.26.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Mar 2013 08:26:48 -0700 (PDT) Message-ID: <514B26C3.7090001@gmail.com> Date: Thu, 21 Mar 2013 15:26:59 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Owen DeLong References: <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong. com> In-Reply-To: <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 15:26:58 -0000 On 21/03/2013 14:43, Owen DeLong wrote: ... > ULA-5 does not prevent the router from being a default router. It prevents the router from advertising itself as a default router via RA packets. > > It can still advertise an OSPF default, BGP default, and/or participate in VRRP. Absolutely. And certainly we should assume that a sophisticated home network, with or without peer connections to the neighbours, would be running a routing protocol. > We should, in all cases, avoid doing things that are damaging to GUA-based installations for the sake of making ULA work better for fringe cases. On this we agree. Since ULAs were designed to behave exactly like GUAs except for not being routed on the Internet, it really is a matter of getting the address selection preferences right. (I don't mean to say that is a done deal today.) Brian From alexandru.petrescu@gmail.com Thu Mar 21 08:39:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B4621F8FDA for ; Thu, 21 Mar 2013 08:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.187 X-Spam-Level: X-Spam-Status: No, score=-10.187 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52IeCq2xMJf6 for ; Thu, 21 Mar 2013 08:39:38 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id D4E7421F8F05 for ; Thu, 21 Mar 2013 08:39:37 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2LFdXpN004971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 16:39:33 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2LFdX8k008390; Thu, 21 Mar 2013 16:39:33 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2LFdTe4009396; Thu, 21 Mar 2013 16:39:33 +0100 Message-ID: <514B2987.5040406@gmail.com> Date: Thu, 21 Mar 2013 16:38:47 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Brian E Carpenter References: <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong. com> <514B26C3.7090001@gmail.com> In-Reply-To: <514B26C3.7090001@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 15:39:38 -0000 Le 21/03/2013 16:26, Brian E Carpenter a écrit : > On 21/03/2013 14:43, Owen DeLong wrote: ... >> ULA-5 does not prevent the router from being a default router. It >> prevents the router from advertising itself as a default router >> via RA packets. >> >> It can still advertise an OSPF default, BGP default, and/or >> participate in VRRP. > > Absolutely. And certainly we should assume that a sophisticated home > network, with or without peer connections to the neighbours, would > be running a routing protocol. Yes, routing protocol between CPEs if needed, or other form of informing each other about one home's prefix. But the Client PC iPads aren't likely to run OSPF BGP VRRP. How else to inform the address of the default router to these Client PCs? >> We should, in all cases, avoid doing things that are damaging to >> GUA-based installations for the sake of making ULA work better for >> fringe cases. > > On this we agree. Since ULAs were designed to behave exactly like > GUAs except for not being routed on the Internet, it really is a > matter of getting the address selection preferences right. (I don't > mean to say that is a done deal today.) Ok. Alex > > Brian > > From alexandru.petrescu@gmail.com Thu Mar 21 09:17:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494E421F8DEA for ; Thu, 21 Mar 2013 09:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.444 X-Spam-Level: X-Spam-Status: No, score=-9.444 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_05=-1.11, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AC41D0dWa-2 for ; Thu, 21 Mar 2013 09:17:27 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id CE25021F8DE9 for ; Thu, 21 Mar 2013 09:17:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2LGH7lZ027339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 17:17:07 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2LGH7tU023958; Thu, 21 Mar 2013 17:17:07 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2LGH3fK028680; Thu, 21 Mar 2013 17:17:07 +0100 Message-ID: <514B3255.7070304@gmail.com> Date: Thu, 21 Mar 2013 17:16:21 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Owen DeLong References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149EBE2.5000908@gmail.com> <0A02847A-F67C-4285-A540-8A7A6497ACF3@delong.com> <514ABC93.3000608@gmail.com> <573F4589-56D1-4049-8E86-B52239D945D6@delong.com> In-Reply-To: <573F4589-56D1-4049-8E86-B52239D945D6@delong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 16:17:28 -0000 Le 21/03/2013 15:33, Owen DeLong a écrit : >>>>> What worries me is that in non-zeroconf environments, or >>>>> those where manual override is possible, administrators will >>>>> use fc00::/48, as it's easier to type/remember. >>>> >>>> But not what the RFC says - it's wrong sysadmin. >>> >>> Which matters here in the ivory tower, but makes no difference in >>> the real world. >> >> In a sense yes, but what better could one do? DEsign a better way >> to generate this uniqueness? There are ways for that, like starting >> from truly unique application-specific immutable IDs which hardly >> ever experienced collisions (like MAC-based did). > > As I said at the time ULA was discussed, YEs, at that time someone put up a public automated registry... is it still up? > the best thing would have been to recognize GUA as a preferable > alternative and make better provisions for GUA to be used for > disconnected networks. But that's an ULA - it is a particular set of addresses in the total space of IPv6 addresses which are to be used for disconnected networks - your wish was realized. > Unfortunately, at this point, that ship has sailed. Now it boils down > to limiting the damage done by ULA. To do that, we need to recognize > that ULA can and will be deployed stupidly in spite of the warnings > in the ULA RFCs. I prefer education, not sure how else to limit damage. Actually I think ULA is not damage - we need them; and I think the very act of limiting something by killing some draft is not constructive. > As a result, we should avoid creating additional RFCs which depend > on ULA not being deployed stupidly and make sure, instead, that > future RFCs are designed with this expectation in mind. > >>>> So, Lorenzo, I wouldnt qualify it as strongly. There _is_ >>>> much hope. >>> >>> Only among overly optimistic idealists. >> >> There could be ways to be less idealistic and yet come up with >> unique ULAs in certain contexts. > > Sure, but we can't rationally depend on that happening in all cases > which is what you were proposing in claiming that there is "much > hope". A case could be particular site. We may define the Border Router of that site, and the ULA generation algorithm for that site. >>>> Anyone who tried to configure ULAs according to that RFC knows >>>> that there is some level of uniqueness guaranteed. >>> >>> >>> No, there is no level of uniqueness guaranteed. There is a >>> statistically high probability of uniqueness for those who >>> deploy ULA according to the RFC. Even there, there is no >>> guarantee of any level of uniqueness, just a strong probability. >> >> I think this statement assumes exclusively the suggested ULA >> generation algorithm in the RFC. But better algorithms could be >> made which remove that probability factor, in certain contexts. > > OK, so now I'm confused. First you argue that the ULA RFC as is > provides uniqueness and we can ignore the fact that it won't be > reliably implemented per the RFC. Let me explain: the ULA generation algorithm given as an example in that RFC has some uniqueness properties. E.g. its uniqueness depends much on the EUI-64 (in addition to time and SHA randomness). When one complains that may not be unique enough, then immediately one thinks that algorithms may be improved to give better uniqueness. E.g. if one worries uniqueness of EUI-64 then there exist other addressing spaces whose uniqueness is much more likely - the space of fingerprints. If we had a better ULA generation algorithm - based on fingerprints, not on EUI-64 - then we could be safer on the uniqueness side of ULA. But the task may be easier than that. One wouldn't look at global uniqueness, but maybe at uniqueness in a domain of activity, or maybe in a site. If we look at uniqueness within one particular site, then it's even easier to do better-than-EUI-64 uniqueness. Take that site's example addressing space (e.g. its phone numbers - they're all unique within that site) and put them in ULA - it's guaranteed unique in that site. > Now you're arguing that violating the RFC is an even better way to go > so that we can get guaranteed uniqueness? No, defining new ULA generation algorithms is not violating that RFC. That RFC gives one example algorithm of ULA generation algorithm (it says so 'example') so other examples _are_ possible. > It is precisely the tendency for ULA discussions to spiral into tight > little circles like this that convinces me that ULA is a quagmire > which causes many more problems than it solves. IT's not a quagmire. There are ways forward. >>> However, the probability that the majority of administrators >>> will even read the ULA RFC (how many people do you think have >>> actually read RFC-1918 vs. the number that have deployed 10/8 or >>> any other RFC-1918 address? I'll give you a hint... Ask a bunch >>> of administrators which of the following are RFC-1918 addresses. >>> If it's not an open book test, I bet the results surprise you. >> >> I agree in a sense, I let myself surprised by that. But things >> could be done about it. > > Such as? Such as defining various particular contexts: homenet, vehiculars were mentioned, and for each of those contexts describe a likely method already in use to use ULAs together with the limit of that site. >>> 172.16.5.3 Everyone will probably get this right. >>> 172.30.19.6 About half will get this wrong. 172.32.99.7 >>> The other half will get this wrong. 172.80.15.7 About half >>> of the ones that got the previous question wrong will also get >>> this one wrong. >> >> I got them all wrong at a quick view. I'd have to read the RFC1918 >> and find the prefix length of the 172. private addresses to do it >> right. Fortunately there's that RFC. > > 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 > > Yes, but how many of the IT professionals running IPv4 RFC-1918 > addressed networks even know the number? How many of those have > actually read the RFC? (If it's more than 5% I would be very > surprised). Do you have any idea how many people I talk to that still > say "RFC-1597?" Right... >>>> (if one just tries to just try quickly ifconfig add fd::1/64 >>>> then it's probably not according to the RFC, which would want >>>> more digits there.) >>> >>> fd::1/64 isn't even ULA, but I wouldn't put it past >>> administrators to think it is. >> >> Corrected. It's not fd::1/64 but fd00::1/64. > > That's at least ULA... So to stimulate sysadmins just a little bit, we could write that: fd::1/64 is a highly probable GUA - HP GUA fd00::1/64 is a highly improbable ULA - HI ULA >>> fd00::1/64, OTOH, will probably be the most common ULA gateway >>> address. >> >> Let's put that in a document! State upfront that sysadmins should >> not assign fd00::1/64 on any interface (be that default or not) >> because it doesnt have enough intermediary bits such that to be >> unique - not an ULA by RFC. > > There are a number of problems with this theory. First, if you don't > see the parallels between this line of thinking and the reason that > every application on the internet runs over TCP/80 or TCP/443 > regardless of the application layer protocol these days, then you > aren't paying attention. > > However, in more detail: > > 1. What makes you think that an administrator that didn't read the > original RFC would read and heed this additional document? I dont know. Right... > 2. The next logical thing is that they all move to fd01::1/64. Do we > keep publishing documents until we run out of easy to remember ULA > addresses? Right... > The need here isn't to change the administrator's behavior because we > don't like the outcome. The need here is to recognize that > administrators live and work in the real world where they have enough > complexity in their lives without adding very large random numbers to > their daily routine. Having prefixes which are easy to remember has > value to them and no amount of effort to tell them to make their > lives more difficult with little or no perceived immediate benefit is > not likely to be readily accepted by them. Ok, but please dont write documents in which you kill ULAs. (like when killing fec0:: site-local) Alex > > Owen > > > From owen@delong.com Thu Mar 21 09:26:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B292421F8E3B for ; Thu, 21 Mar 2013 09:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=0.514, 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 PGJJpsKivALh for ; Thu, 21 Mar 2013 09:26:21 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 10D0521F8D10 for ; Thu, 21 Mar 2013 09:26:20 -0700 (PDT) Received: from [10.183.205.4] (mobile-198-228-232-211.mycingular.net [198.228.232.211]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2LGMuCM007151 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Mar 2013 09:23:01 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2LGMuCM007151 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363882987; bh=Oys4adAZdIoHIGP7Je7ztHYBllY=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=yrKNXJKy1JPak974PpMUdz0gBCF40zamW3jpSQMLb4mbJvjtd+hVlDYM5FiK3zJMZ EtBul5ljDQopjje010mLPzctnBVS2Xx433Wcefpis5fBq32dj9Nl9LA8ESESg58DML INnfMkZ+qNcUwB/GrtjHnV77AnNCEDIRrdB7vtIY= References: <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong. com> <514B26C3.7090001@gmail.com> <514B2987.5040406@g! mail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <514B2987.5040406@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (10B146) From: Owen DeLong Date: Thu, 21 Mar 2013 11:22:56 -0500 To: Alexandru Petrescu X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 21 Mar 2013 09:23:07 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 16:26:21 -0000 > But the Client PC iPads aren't likely to run OSPF BGP VRRP. How else to > inform the address of the default router to these Client PCs? > RIO Owen From alexandru.petrescu@gmail.com Thu Mar 21 09:31:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3923421F8DBB for ; Thu, 21 Mar 2013 09:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.179 X-Spam-Level: X-Spam-Status: No, score=-10.179 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKx465jmM2Jv for ; Thu, 21 Mar 2013 09:31:36 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5B22A21F8D10 for ; Thu, 21 Mar 2013 09:31:36 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2LGVWjL004012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 17:31:32 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2LGVWeJ028694; Thu, 21 Mar 2013 17:31:32 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2LGVSbd006497; Thu, 21 Mar 2013 17:31:32 +0100 Message-ID: <514B35B5.1060907@gmail.com> Date: Thu, 21 Mar 2013 17:30:45 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Owen DeLong References: <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! .com> In-Reply-To: <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 16:31:37 -0000 Le 21/03/2013 15:43, Owen DeLong a écrit : > >>>> From rfc6204bis: >>> >>> ULA-5: An IPv6 CE router MUST NOT advertise itself as a default >>> router with a Router Lifetime greater than zero whenever all of >>> its configured and delegated prefixes are ULA prefixes. >> >> This ULA-5 requirement is wrong and shouldnt be there - neither >> for CPEs nor for anything else. > > I disagree... ULA-5 is an important safeguard. If you want to build > a large home-to-home network, do it with GUA, ULA is poorly suited > to the task. Ok, after some illuminating emails I can agree to that. But there too - keep that ULA-5 a Home only requirement. It doesnt apply everywhere. >> A Router - any Router for that matter - should be able to be a >> default router, or not a default router, whenever it wants to, >> even though it has no connection to Internet. > > That's worked out so well in Japan so far.... NOT! Not sure what you refer to... >> If this is not done (i.e. do not allow default routers when only >> ULA addresses are used) then the networks using exclusively ULA >> addressing can not scale to large size, because there may be too >> many routes at too many Routers. An advantage of using a default >> route is that it concentrates the many routes only in a few-places >> - the DFZ. > > This is not a bad thing. If you want to scale a network to large > size, then either use GUA or expect to have to put some effort into > the routing process. There is an intermediary between one home-only space and GUA which is the total space. At the very least, one may wonder why not ULA in a home be able to talk to ULA in that ISP? Firmware update from ISP to CPE can easily happen with ULA. > ULA-5 does not prevent the router from being a default router. It > prevents the router from advertising itself as a default router via > RA packets. How else can it do it in a way which a Smartphone is likely to implement? (other than RA which seems forbidden). > > It can still advertise an OSPF default, BGP default, and/or > participate in VRRP. Ok - none is implemented by a Smartphone. > We should, in all cases, avoid doing things that are damaging to > GUA-based installations for the sake of making ULA work better for > fringe cases. That is the first worry - right! First, do no harm to GUA. But I am optimistic because I see much hard work done to avoid harming GUA. Alex > > Owen > > > From alexandru.petrescu@gmail.com Thu Mar 21 09:46:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B052321F8CF9 for ; Thu, 21 Mar 2013 09:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.181 X-Spam-Level: X-Spam-Status: No, score=-10.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkCWDCkN2v3X for ; Thu, 21 Mar 2013 09:46:40 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8A78921F8FAA for ; Thu, 21 Mar 2013 09:46:34 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2LGkQlE001403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 17:46:27 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2LGkQ6m001940; Thu, 21 Mar 2013 17:46:26 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2LGkMZb012600; Thu, 21 Mar 2013 17:46:26 +0100 Message-ID: <514B3934.7090203@gmail.com> Date: Thu, 21 Mar 2013 17:45:40 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Owen DeLong References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong. com> <514B26C3.7090001@gmail.com> <514B2987.5040406@g! mail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 16:46:41 -0000 Le 21/03/2013 17:22, Owen DeLong a écrit : >> But the Client PC iPads aren't likely to run OSPF BGP VRRP. How else to >> inform the address of the default router to these Client PCs? >> > > RIO Router Information Option of RFC4191? But that relies on the fact that that the Router Lifetime is 0 in the RA, which seems forbidden by the CPE rfcbis draft. or am I missing something? Alex > > Owen > > > From owen@delong.com Thu Mar 21 09:46:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BD221F8F8A for ; Thu, 21 Mar 2013 09:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.434 X-Spam-Level: X-Spam-Status: No, score=-1.434 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 SkwjA1g9kZmV for ; Thu, 21 Mar 2013 09:46:46 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 950D121F8F75 for ; Thu, 21 Mar 2013 09:46:45 -0700 (PDT) Received: from [10.183.205.4] (mobile-198-228-232-211.mycingular.net [198.228.232.211]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2LGjXHw008073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Mar 2013 09:45:37 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2LGjXHw008073 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363884338; bh=b7RQJLs+dAlXHmvrNPBf9sqAK9w=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=4S6TQo0AUCkAxD5UD9fyB++mZ/OyiI1A6DyPXVhfrPax8bWhsggc+K5lemAsyOm+4 GJeEKsDKQRWj+PJf3H4t/1nchh6SISrs5tUtulHC4VCjClR7tylL0t6A9YuuYTlKV6 63aP4j9kdu2CtoApE8luCX/NROvGriflem0PuKN4= References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149EBE2.5000908@gmail.com> <0A02847A-F67C-4285-A540-8A7A6497ACF3@delong.com> <514ABC93.3000608@gmail.com> <573F4589-56D1-4049-8E86-B52239D945D6@delong.com> <514B3255.7070304@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <514B3255.7070304@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7A9B568E-EA07-4B15-B32A-9DD723FDF51E@delong.com> X-Mailer: iPad Mail (10B146) From: Owen DeLong Date: Thu, 21 Mar 2013 11:45:33 -0500 To: Alexandru Petrescu X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 21 Mar 2013 09:45:38 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 16:46:47 -0000 >> As I said at the time ULA was discussed, >=20 > YEs, at that time someone put up a public automated registry... is it > still up? >=20 At the time, there were at least a dozen registries created. The most popula= r was probably the one at SIXXS. I don't know if any of them are still runni= ng or not. To me, they seemed antithetical to the purpose of ULA-Random, an e= ffort to circumvent the lack of consensus around ULA-Registered. >> the best thing would have been to recognize GUA as a preferable >> alternative and make better provisions for GUA to be used for >> disconnected networks. >=20 > But that's an ULA - it is a particular set of addresses in the total > space of IPv6 addresses which are to be used for disconnected networks - > your wish was realized. No, it wasn't. Now, instead of just using GUA for everything and being able t= o decide on a case-by-case basis and dynamically change that decision as cir= cumstances change, we have, instead, restored this absurd dichotomy and crea= ted unnecessary artificial semantics around particular ranges of numbers. >> Unfortunately, at this point, that ship has sailed. Now it boils down >> to limiting the damage done by ULA. To do that, we need to recognize >> that ULA can and will be deployed stupidly in spite of the warnings >> in the ULA RFCs. >=20 > I prefer education, not sure how else to limit damage. Actually I think > ULA is not damage - we need them; and I think the very act of limiting > something by killing some draft is not constructive. I'm all for education. However, given our success rate with education in the= RFC-1918 world of IPv4, I'm also going to be realistic in realizing that edu= cation will often fail to penetrate in the real world. As to the latter, I think that depends very much on the draft. In many cases= , limiting things by killing some drafts is exactly the right thing to do. T= hink how much of the confusion and consternation in the current discussion c= ould have been avoided if we'd just done that with the original ULA draft. >>> There could be ways to be less idealistic and yet come up with >>> unique ULAs in certain contexts. >>=20 >> Sure, but we can't rationally depend on that happening in all cases >> which is what you were proposing in claiming that there is "much >> hope". >=20 > A case could be particular site. We may define the Border Router of > that site, and the ULA generation algorithm for that site. Not sure how this would address my statement. We cannot count on the idea that every site will correctly implement ULA. Just because you think we might be able to control that in some limited set o= f cases doesn't change the fact that it will never be universally true. Ergo= , a draft which depends on universal correct implementation of ULA is, IMHO,= a non-starter. >> OK, so now I'm confused. First you argue that the ULA RFC as is >> provides uniqueness and we can ignore the fact that it won't be >> reliably implemented per the RFC. >=20 > Let me explain: the ULA generation algorithm given as an example in that > RFC has some uniqueness properties. E.g. its uniqueness depends much on > the EUI-64 (in addition to time and SHA randomness). >=20 It's not that I don't understand how this works. It's that I oppose inaccura= te claims about what capabilities that provides. > When one complains that may not be unique enough, then immediately one > thinks that algorithms may be improved to give better uniqueness. E.g. if= one worries uniqueness of EUI-64 then there exist other addressing spaces w= hose uniqueness is much more likely - the space of fingerprints. I didn't say it wasn't unique enough. I said it wasn't guaranteed uniqueness= , but rather mathematically likely uniqueness. > If we had a better ULA generation algorithm - based on fingerprints, not > on EUI-64 - then we could be safer on the uniqueness side of ULA. Actually fingerprints are statistically less likely to be unique than the cu= rrent ULA algorithm. Please actually research your claims before making them= . > But the task may be easier than that. One wouldn't look at global uniquen= ess, but maybe at uniqueness in a domain of activity, or maybe in a site. >=20 > If we look at uniqueness within one particular site, then it's even easier= to do better-than-EUI-64 uniqueness. Take that site's example addressing s= pace (e.g. its phone numbers - they're all unique within that site) and put t= hem in ULA - it's guaranteed unique in that site. I'm not sure how you would propose to achieve better-than-64-bit uniqueness i= n a 40 bit address space. Even the current algorithm does not pretend to do t= hat. It just uses EUI-64 as one of the inputs into the entropy in generating= the random 40 bits. >> Now you're arguing that violating the RFC is an even better way to go >> so that we can get guaranteed uniqueness? >=20 > No, defining new ULA generation algorithms is not violating that RFC. That= RFC gives one example algorithm of ULA generation algorithm (it says so 'ex= ample') so other examples _are_ possible. Your earlier argument was that administrator assigning an address that wasn'= t chosen according to that algorithm (e.g. fd00::/64) was an RFC violation. N= ow you're saying that other algorithms are acceptable. Which is it? (Pick the first one may be a bad algorithm, but it is an example of a differ= ent algorithm). >> It is precisely the tendency for ULA discussions to spiral into tight >> little circles like this that convinces me that ULA is a quagmire >> which causes many more problems than it solves. >=20 > IT's not a quagmire. There are ways forward. >=20 There are ways forward in a quagmire, but they are difficult. ULA makes thin= gs unnecessarily difficult. To wit, this entire discussion. >>>> However, the probability that the majority of administrators >>>> will even read the ULA RFC (how many people do you think have >>>> actually read RFC-1918 vs. the number that have deployed 10/8 or >>>> any other RFC-1918 address? I'll give you a hint... Ask a bunch >>>> of administrators which of the following are RFC-1918 addresses. >>>> If it's not an open book test, I bet the results surprise you. >>>=20 >>> I agree in a sense, I let myself surprised by that. But things >>> could be done about it. >>=20 >> Such as? >=20 > Such as defining various particular contexts: homenet, vehiculars were men= tioned, and for each of those contexts describe a likely method already in u= se to use ULAs together with the limit of that site. >=20 It is unclear to me how defining additional things in more documents will so= lve the problem that people don't read the existing documents. >>>> 172.16.5.3 Everyone will probably get this right. >>>> 172.30.19.6 About half will get this wrong. 172.32.99.7 >>>> The other half will get this wrong. 172.80.15.7 About half >>>> of the ones that got the previous question wrong will also get >>>> this one wrong. >>>=20 >>> I got them all wrong at a quick view. I'd have to read the RFC1918 >>> and find the prefix length of the 172. private addresses to do it >>> right. Fortunately there's that RFC. >>=20 >> 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 >>=20 >> Yes, but how many of the IT professionals running IPv4 RFC-1918 >> addressed networks even know the number? How many of those have >> actually read the RFC? (If it's more than 5% I would be very >> surprised). Do you have any idea how many people I talk to that still >> say "RFC-1597?" >=20 > Right... >=20 >>>>> (if one just tries to just try quickly ifconfig add fd::1/64 >>>>> then it's probably not according to the RFC, which would want >>>>> more digits there.) >>>>=20 >>>> fd::1/64 isn't even ULA, but I wouldn't put it past >>>> administrators to think it is. >>>=20 >>> Corrected. It's not fd::1/64 but fd00::1/64. >>=20 >> That's at least ULA... >=20 > So to stimulate sysadmins just a little bit, we could write that: >=20 > fd::1/64 is a highly probable GUA - HP GUA > fd00::1/64 is a highly improbable ULA - HI ULA >=20 And? >> However, in more detail: >>=20 >> 1. What makes you think that an administrator that didn't read the >> original RFC would read and heed this additional document? >=20 > I dont know. Right... >=20 >> 2. The next logical thing is that they all move to fd01::1/64. Do we >> keep publishing documents until we run out of easy to remember ULA >> addresses? >=20 > Right... >=20 >> The need here isn't to change the administrator's behavior because we >> don't like the outcome. The need here is to recognize that >> administrators live and work in the real world where they have enough >> complexity in their lives without adding very large random numbers to >> their daily routine. Having prefixes which are easy to remember has >> value to them and no amount of effort to tell them to make their >> lives more difficult with little or no perceived immediate benefit is >> not likely to be readily accepted by them. >=20 > Ok, but please dont write documents in which you kill ULAs. >=20 Why not? Killing ULA would be a very good thing, IMHO. Nothing you have said= so far convinces me otherwise. > (like when killing fec0:: site-local) Personally, I thought site-local made much more sense than ULA. Owen From owen@delong.com Thu Mar 21 09:56:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21B421F9150 for ; Thu, 21 Mar 2013 09:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.415 X-Spam-Level: X-Spam-Status: No, score=-1.415 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 9g55KuKOyObU for ; Thu, 21 Mar 2013 09:56:07 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id E891521F9142 for ; Thu, 21 Mar 2013 09:56:03 -0700 (PDT) Received: from [10.183.205.4] (mobile-198-228-232-211.mycingular.net [198.228.232.211]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2LGqOvS008368 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Mar 2013 09:52:26 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2LGqOvS008368 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363884747; bh=pJT7f6ARoJwXRYaEmH6tAvrNd/U=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=x8O/gS9zkqV8shZxE0v6pu8ryMJ9wSEdYeU+bkUn0kSC522+Y3iNHdxaGcOeoxTYA 8MeP80hHPnY1HgL02dQZHevlMIElDqfjwqDNc5UDAWiDeEJzoaoshW6+7wPFr8y/Lf NO5QRJFLjQGn551yCg9/bVPOXgG/E0Ow/L6v5yh4= References: <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <514B35B5.1060907@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com> X-Mailer: iPad Mail (10B146) From: Owen DeLong Date: Thu, 21 Mar 2013 11:52:23 -0500 To: Alexandru Petrescu X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 21 Mar 2013 09:52:27 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 16:56:09 -0000 Sent from my iPad On Mar 21, 2013, at 11:30 AM, Alexandru Petrescu wrote: > Le 21/03/2013 15:43, Owen DeLong a =C3=A9crit : >>=20 >>>>> =46rom rfc6204bis: >>>>=20 >>>> ULA-5: An IPv6 CE router MUST NOT advertise itself as a default >>>> router with a Router Lifetime greater than zero whenever all of >>>> its configured and delegated prefixes are ULA prefixes. >>>=20 >>> This ULA-5 requirement is wrong and shouldnt be there - neither >>> for CPEs nor for anything else. >>=20 >> I disagree... ULA-5 is an important safeguard. If you want to build >> a large home-to-home network, do it with GUA, ULA is poorly suited >> to the task. >=20 > Ok, after some illuminating emails I can agree to that. >=20 > But there too - keep that ULA-5 a Home only requirement. It doesnt > apply everywhere. Yeah, actually, it should. Since it is a requirement for how routers are bui= lt, one cannot predict where a router will be deployed at the time the route= r is built for one thing. >>> A Router - any Router for that matter - should be able to be a >>> default router, or not a default router, whenever it wants to, >>> even though it has no connection to Internet. >>=20 >> That's worked out so well in Japan so far.... NOT! >=20 > Not sure what you refer to... >=20 Study the situation in Japan with IPv6 deployment involving NTT and their wa= lled-garden IPv6 TV content delivery system. It would really help this discussion if you made yourself aware of some of t= he history and the current context in which these issues are being considere= d. >> This is not a bad thing. If you want to scale a network to large >> size, then either use GUA or expect to have to put some effort into >> the routing process. >=20 > There is an intermediary between one home-only space and GUA which is > the total space. You are misunderstanding the concepts involved here rather substantially. > At the very least, one may wonder why not ULA in a home be able to talk > to ULA in that ISP? Firmware update from ISP to CPE can easily happen > with ULA. Or one may wonder what possible advantage ULA offers in that circumstance ov= er GUA? >> ULA-5 does not prevent the router from being a default router. It >> prevents the router from advertising itself as a default router via >> RA packets. >=20 > How else can it do it in a way which a Smartphone is likely to > implement? (other than RA which seems forbidden). RA is not forbidden. Default route via RA is forbidden. RIO via RA is perfec= tly fine. >> It can still advertise an OSPF default, BGP default, and/or >> participate in VRRP. >=20 > Ok - none is implemented by a Smartphone. Who cares? If you use VRRP, the smartphone doesn't have to implement it. The= smart phone can be given a static default to the VRRP address. Ideally, we fix DHCPv6 and add the ability to provide routing information op= tions in DHCPv6 as well. >> We should, in all cases, avoid doing things that are damaging to >> GUA-based installations for the sake of making ULA work better for >> fringe cases. >=20 > That is the first worry - right! First, do no harm to GUA. But I am > optimistic because I see much hard work done to avoid harming GUA. Or we could use GUA and avoid all the hard work and the harm. Owen From alexandru.petrescu@gmail.com Thu Mar 21 10:18:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8F021F9172 for ; Thu, 21 Mar 2013 10:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.582 X-Spam-Level: X-Spam-Status: No, score=-9.582 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_38=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoYHJNZCInIc for ; Thu, 21 Mar 2013 10:18:17 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC2121F9170 for ; Thu, 21 Mar 2013 10:18:16 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2LHI1mJ012801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 18:18:01 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2LHI1v0013226; Thu, 21 Mar 2013 18:18:01 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2LHHvoR029962; Thu, 21 Mar 2013 18:18:00 +0100 Message-ID: <514B4099.3000904@gmail.com> Date: Thu, 21 Mar 2013 18:17:13 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Owen DeLong References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com> In-Reply-To: <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 17:18:18 -0000 Le 21/03/2013 17:52, Owen DeLong a écrit : > > > Sent from my iPad > > On Mar 21, 2013, at 11:30 AM, Alexandru Petrescu > wrote: > >> Le 21/03/2013 15:43, Owen DeLong a écrit : >>> >>>>>> From rfc6204bis: >>>>> >>>>> ULA-5: An IPv6 CE router MUST NOT advertise itself as a >>>>> default router with a Router Lifetime greater than zero >>>>> whenever all of its configured and delegated prefixes are >>>>> ULA prefixes. >>>> >>>> This ULA-5 requirement is wrong and shouldnt be there - neither >>>> for CPEs nor for anything else. >>> >>> I disagree... ULA-5 is an important safeguard. If you want to >>> build a large home-to-home network, do it with GUA, ULA is >>> poorly suited to the task. >> >> Ok, after some illuminating emails I can agree to that. >> >> But there too - keep that ULA-5 a Home only requirement. It doesnt >> apply everywhere. > > Yeah, actually, it should. Since it is a requirement for how routers > are built, one cannot predict where a router will be deployed at the > time the router is built for one thing. Right. >>>> A Router - any Router for that matter - should be able to be a >>>> default router, or not a default router, whenever it wants to, >>>> even though it has no connection to Internet. >>> >>> That's worked out so well in Japan so far.... NOT! >> >> Not sure what you refer to... >> > > Study the situation in Japan with IPv6 deployment involving NTT and > their walled-garden IPv6 TV content delivery system. Ok. [...] >> At the very least, one may wonder why not ULA in a home be able to >> talk to ULA in that ISP? Firmware update from ISP to CPE can >> easily happen with ULA. > > Or one may wonder what possible advantage ULA offers in that > circumstance over GUA? Maybe not much. >>> ULA-5 does not prevent the router from being a default router. It >>> prevents the router from advertising itself as a default router >>> via RA packets. >> >> How else can it do it in a way which a Smartphone is likely to >> implement? (other than RA which seems forbidden). > > RA is not forbidden. Default route via RA is forbidden. RIO via RA > is perfectly fine. But, the CPE rfcbis says that the Router Lifetime must not be greater than 0. There is no other way in which an RA can tell a Host it's a default router than setting that lifetime to greater than 0. Any RIO in an RA with a Router Lifetime greater than 0 can not make a default route at the Host. Or am I missing something? (this is for curiosity only - as long as it stays as a CPE matter this may not be that important to other contexts). >>> It can still advertise an OSPF default, BGP default, and/or >>> participate in VRRP. >> >> Ok - none is implemented by a Smartphone. > > Who cares? If you use VRRP, the smartphone doesn't have to implement > it. The smart phone can be given a static default to the VRRP > address. Oh... but such advice may read to non-CPE operators (e.g. cellular operators) that any other typical IPv6 parameter could be hardcoded to a certain VRRP'ed address. Read - smartphones hardcoded with the IPv6 DNS Resolver address, because many reasons and the above included. Clearly this should stay CPE. > Ideally, we fix DHCPv6 and add the ability to provide routing > information options in DHCPv6 as well. That sounds like a good idea - it deserves a separate thread. I think that coupling address auto-configuration with routing is desirable. I am not sure whether you are aware, but the DHCPv6 route-options discussions is stalled right now. There are few private emails and maybe an email list would get set up about DHCPv6 and route-options: route-options, src-based routing and why not defrouter. Or maybe we should discuss it here as well. >>> We should, in all cases, avoid doing things that are damaging to >>> GUA-based installations for the sake of making ULA work better >>> for fringe cases. >> >> That is the first worry - right! First, do no harm to GUA. But I >> am optimistic because I see much hard work done to avoid harming >> GUA. > > Or we could use GUA and avoid all the hard work and the harm. YEs maybe; but GUA in vehicular moving networks and without Home Agent can not work. Killing ULA and requesting GUA without a HA may lead to NAT66 as well, which is supposedly another evil. I will not he unhappy if the recommendation is GUA+MobileIP but there are people who claim HA is a single point of failure. Alex > > Owen > > > From owen@delong.com Thu Mar 21 12:36:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B4521F8545 for ; Thu, 21 Mar 2013 12:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, J_CHICKENPOX_42=0.6] 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 USmHWcadzO2X for ; Thu, 21 Mar 2013 12:36:17 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 13E6321F8540 for ; Thu, 21 Mar 2013 12:36:16 -0700 (PDT) Received: from [10.7.13.159] (97-64-168-70.client.mchsi.com [97.64.168.70]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2LJYtIt015262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Mar 2013 12:34:56 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2LJYtIt015262 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363894497; bh=1Wu0qeojZs35mICi7bCR/I3nEVk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=VeHXpI5qwi3djFaNHg9PiNBwilrdqezSHaQbBX6ZTU5hWCZivQ4OJmflzkS6qdleW HGTOkG9ds9rbyrpc+FfHc0V0MaCQw3vuoW61QJbHio2GJgMAzwKDedYt+7ExhBkvy/ JnPIZqa9ZD51jOsmqE6BUG0qUH9lP1NLas31KYTA= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: <514B4099.3000904@gmail.com> Date: Thu, 21 Mar 2013 14:34:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 21 Mar 2013 12:34:57 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 19:36:18 -0000 >> RA is not forbidden. Default route via RA is forbidden. RIO via RA >> is perfectly fine. >=20 > But, the CPE rfcbis says that the Router Lifetime must not be greater > than 0. There is no other way in which an RA can tell a Host it's a > default router than setting that lifetime to greater than 0. If the router doesn't provide internet access, it SHOULD NOT advertise itself as a default router. That is the point. You are determined to = argue against that point, but the correct behavior is to NOT BE a default = router if you do not provide internet access. > Any RIO in an RA with a Router Lifetime greater than 0 can not make a > default route at the Host. Correct. > Or am I missing something? Yes=85 You are missing the fact that a collection of networks not = attached to the internet using ULA should use more specifics and not default = routes. > (this is for curiosity only - as long as it stays as a CPE matter this > may not be that important to other contexts). It is, actually, because you can't tell at manufacture time how a router = will be used, so you have to consider all possible use contexts of the router = when deciding how it should behave, and especially how it should behave by = default. >=20 >>>> It can still advertise an OSPF default, BGP default, and/or >>>> participate in VRRP. >>>=20 >>> Ok - none is implemented by a Smartphone. >>=20 >> Who cares? If you use VRRP, the smartphone doesn't have to implement >> it. The smart phone can be given a static default to the VRRP >> address. >=20 > Oh... but such advice may read to non-CPE operators (e.g. cellular > operators) that any other typical IPv6 parameter could be hardcoded = to > a certain VRRP'ed address. Read - smartphones hardcoded with the IPv6 > DNS Resolver address, because many reasons and the above included. >=20 > Clearly this should stay CPE. We're not talking about hard coding anything. We're talking about static configuration. I don't know about smart phones in general, but I do know that whatever = I statically configure into my phone is specific to a given connection, = e.g. part of the definition for a particular wifi SSID, etc. Phones can have different "personalities" to provide different sets of = parameters and static settings for different operational contexts. >> Ideally, we fix DHCPv6 and add the ability to provide routing >> information options in DHCPv6 as well. >=20 > That sounds like a good idea - it deserves a separate thread. I think > that coupling address auto-configuration with routing is desirable. tt has a separate thread. > I am not sure whether you are aware, but the DHCPv6 route-options > discussions is stalled right now. There are few private emails and > maybe an email list would get set up about DHCPv6 and route-options: > route-options, src-based routing and why not defrouter. >=20 > Or maybe we should discuss it here as well. >=20 No, we really shouldn't. At least not as part of this thread. Yes, I am = aware of the situation with DHCPv6 routing options. My point isn't to rehash = that discussion here (which I don't think most list participants would = appreciate), but to point out that the correct place to solve certain problems is = somewhere other than in this thread. >>>> We should, in all cases, avoid doing things that are damaging to >>>> GUA-based installations for the sake of making ULA work better >>>> for fringe cases. >>>=20 >>> That is the first worry - right! First, do no harm to GUA. But I >>> am optimistic because I see much hard work done to avoid harming >>> GUA. >>=20 >> Or we could use GUA and avoid all the hard work and the harm. >=20 > YEs maybe; but GUA in vehicular moving networks and without Home Agent > can not work. >=20 Why does "without home agent" suddenly come into play? You still are missing the point. If I use unrouted prefix = 2001:1610:53ac::/48 in the vehicles in the exact same manner as I would use unrouted prefix fd01:9c83:1ac0::/48, then there is no difference in the behavior or the = impact of the two prefixes. There is no change in the strain on the routing = system. There is no problem caused for anyone. The two prefixes have identical semantics and usage and identical impact on the routing table. > Killing ULA and requesting GUA without a HA may lead to NAT66 as well, > which is supposedly another evil. How does GUA require NAT66 where ULA would not? You make no sense here. > I will not he unhappy if the recommendation is GUA+MobileIP but there > are people who claim HA is a single point of failure. You are assuming that all GUA must be globally routed. I'm talking about = using GUA prefixes exactly as one would use ULA. I'm not necessarily talking = about providing them with global reachability or anything else that they would = not get with ULA. I'm just talking about the fact that for private use on a = disconnected network, there is no actual technical advantage to ULA vs. GUA. Owen From swmike@swm.pp.se Thu Mar 21 12:40:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B3C21F8A0D for ; Thu, 21 Mar 2013 12:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 d2BMJDW8mvOR for ; Thu, 21 Mar 2013 12:40:51 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id DA78421F8A0B for ; Thu, 21 Mar 2013 12:40:50 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2F10B9C; Thu, 21 Mar 2013 20:40:50 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2462F9A for ; Thu, 21 Mar 2013 20:40:50 +0100 (CET) Date: Thu, 21 Mar 2013 20:40:50 +0100 (CET) From: Mikael Abrahamsson To: "v6ops@ietf.org" In-Reply-To: <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> Message-ID: References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 19:40:51 -0000 On Thu, 21 Mar 2013, Owen DeLong wrote: > If the router doesn't provide internet access, it SHOULD NOT advertise > itself as a default router. That is the point. You are determined to > argue against that point, but the correct behavior is to NOT BE a > default router if you do not provide internet access. So if the host doesn't support RIO then there won't be reachability for ULAs between LANs within the home. Correct? I tried to make my home Cisco router send RIO for testing but I was unable do to do so (I believe, at least no more-specific route showed up on my Linux machine which is running 3.2). Anyone happen to know how this would be configured and how it would show up in the config? -- Mikael Abrahamsson email: swmike@swm.pp.se From joelja@bogus.com Thu Mar 21 15:11:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E8C21F8F81 for ; Thu, 21 Mar 2013 15:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.936 X-Spam-Level: X-Spam-Status: No, score=-101.936 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_MILLIONSOF=0.315, 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 hT2XPCgEdB6b for ; Thu, 21 Mar 2013 15:11:44 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6103B21F8F3A for ; Thu, 21 Mar 2013 15:11:44 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r2LMBfkS089839 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 22:11:41 GMT (envelope-from joelja@bogus.com) Message-ID: <514B8598.6090401@bogus.com> Date: Thu, 21 Mar 2013 15:11:36 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Brian E Carpenter , Alexandru Petrescu References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149C642.6060806@gmail.com> <481173D1-2F02-4B80-8E2C-BE33009EF2C9@delong.com> <514B116E.9070504@gmail.com> <514B14C2.3050303@gmail.com> In-Reply-To: <514B14C2.3050303@gmail.com> 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]); Thu, 21 Mar 2013 22:11:41 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 22:11:45 -0000 On 3/21/13 7:10 AM, Brian E Carpenter wrote: > On 21/03/2013 13:55, Alexandru Petrescu wrote: > ... >> A PI GUA for 2-3 Enterprises may work connected mostly all the time at >> the same 2-3 places. But I think 1 billion PI GUAs moving around the >> Internet at the speed of 1 new connection/minute may not work - it >> involves 'route churning', i.e. too many routing protocol messages per >> second and too large routing table entries. Isnt't there a risk like that? > Well, it was three or four orders of magnitude smaller, but there were a lot > of complaints about the churn produced by Connexion by Boeing, which was > effectively a few hundred IPv4 PI prefixes moving around at almost Mach 1. iirc there were complaints that it was a relatively bad idea. there were no complaints as far as I know due to impact of the rate of prefix churn which was way lower (by orders of magnitude) than the worst offendors out there at the time. The prefix advertisement and withdrawal was in fact done by the groundstatations not the aircraft. There were never hundreds of of transcontinental commercial aircraft engaged in roaming on the service (there were around 200 planes total with the equipment). There are many more aircraft today operating with satellite or terrestrial internet connectivity and without such behavior. > OK, it's not a fair comparison, but I think we're on safe ground in doubting > that increasing from 30k to millions of PI prefixes will work smoothly. PA prefixes count the same as far as fib slots go and if they're multihomed by customers they're rather hard to aggregate. > > Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From marka@isc.org Thu Mar 21 15:14:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379BA21F8BC5 for ; Thu, 21 Mar 2013 15:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] 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 BQi22ubb+R8w for ; Thu, 21 Mar 2013 15:14:46 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAD321F8A6F for ; Thu, 21 Mar 2013 15:14:46 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 30A0AC9465; Thu, 21 Mar 2013 22:14:40 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363904086; bh=moE6z88dPQPLnEPUwQ5PFuKSv2hctqFfwJSp0WqCgYU=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=cVHuL54WjhiRc499SvQVHewQXNaJ46UVwBR9Qda2aRGCE2A0rvLIqcz6JyVj1B+gE rfF1o4DeWEI9Ne2SBuNZak1xUF6Ycd9HJXXHd7KnedkOXUpTsntn7oZswOUoKgAMNa HePrfvImtF157EAhC9iy/TqZdasTTFEtPS6qu0Ds= 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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Thu, 21 Mar 2013 22:14:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 E45B4216C3B; Thu, 21 Mar 2013 22:14:39 +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 DAA383151072; Fri, 22 Mar 2013 09:14:32 +1100 (EST) To: Owen DeLong From: Mark Andrews References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <20130321034917.71CCD3147294@drugs.dv.isc.org> <7F0F3F2D-2705-413B-A548-A5C820044BC7@delong.com> <20130321060739.52FD93148050@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 21 Mar 2013 09:18:50 CDT." Date: Fri, 22 Mar 2013 09:14:32 +1100 Message-Id: <20130321221432.DAA383151072@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 22:14:47 -0000 In message , Owen DeLong writes: > >> Without those flags, it is unlikely that it would have made multiple =3D > >> IPv6 attempts before falling back to IPv4, but, rather would have made =3D= > > >> one IPv6 attempt, then upon getting the unreachable, immediately try =3D > >> IPv4. > >>=20 > >> Owen > >=20 > > With modern stacks you just tell them to prefer the /48 ULA you are > > using and depreference all other ULA use. If I was to disable all > > other prefixes then IPv4 would be used for external connections. > >=20 > > % cat /etc/ip6addrctl.conf=20 > > #Prefix Prec Label =20 > > ::1/128 50 0 > > ::/0 40 1 =20 > > 2002::/16 30 2 =20 > > ::/96 20 3 =20 > > ::ffff:0.0.0.0/96 35 4 =20 > > fd92:7065:b8e::/48 45 5=20 > > fc00::/7 5 6 > >=20 > > Remind me where I configure the router to send the contents of ip6addrctl.co= > nf down to the SLAAC client... Oh, right... > > Owen= draft-ietf-6man-addr-select-opt-08.txt You can do this by hand today. I can configure my dhcp servers and clients to sent this using options 224...254 today. When the option code is assigned by IANA I can change then to use that. Built in support had been requested, so the operator doesn't have to describe the option, just populate its values. This is waiting on IANA to do the assignment of the option code amongst other things. When doing the internal request we found bugs in the draft which I believe have now been fixed. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Fred.L.Templin@boeing.com Thu Mar 21 15:46:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAF521F8F05 for ; Thu, 21 Mar 2013 15:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_MILLIONSOF=0.315] 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 TPbShjrhDTAl for ; Thu, 21 Mar 2013 15:46:58 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBD821F8E5F for ; Thu, 21 Mar 2013 15:46:58 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r2LMkvuo014214 for ; Thu, 21 Mar 2013 17:46:57 -0500 Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r2LMkuAr014183 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 21 Mar 2013 17:46:57 -0500 Received: from XCH-BLV-105.nw.nos.boeing.com (130.247.25.121) by XCH-NWHT-01.nw.nos.boeing.com (130.247.70.222) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 21 Mar 2013 15:46:56 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.214]) by XCH-BLV-105.nw.nos.boeing.com ([fe80::f05d:773f:d0ec:8b0a%16]) with mapi id 14.02.0328.011; Thu, 21 Mar 2013 15:46:55 -0700 From: "Templin, Fred L" To: joel jaeggli , Brian E Carpenter , Alexandru Petrescu Thread-Topic: [v6ops] draft-liu-v6ops-ula-usage-analysis Thread-Index: AQHOJoEc0KGiDIiC/EanpZuEccj4CpiwvSqw Date: Thu, 21 Mar 2013 22:46:55 +0000 Message-ID: <2134F8430051B64F815C691A62D98318036EC8@XCH-BLV-504.nw.nos.boeing.com> References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149C642.6060806@gmail.com> <481173D1-2F02-4B80-8E2C-BE33009EF2C9@delong.com> <514B116E.9070504@gmail.com> <514B14C2.3050303@gmail.com> <514B8598.6090401@bogus.com> In-Reply-To: <514B8598.6090401@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 22:46:58 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > joel jaeggli > Sent: Thursday, March 21, 2013 3:12 PM > To: Brian E Carpenter; Alexandru Petrescu > Cc: v6ops@ietf.org > Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis >=20 > On 3/21/13 7:10 AM, Brian E Carpenter wrote: > > On 21/03/2013 13:55, Alexandru Petrescu wrote: > > ... > >> A PI GUA for 2-3 Enterprises may work connected mostly all the time at > >> the same 2-3 places. But I think 1 billion PI GUAs moving around the > >> Internet at the speed of 1 new connection/minute may not work - it > >> involves 'route churning', i.e. too many routing protocol messages per > >> second and too large routing table entries. Isnt't there a risk like > that? > > Well, it was three or four orders of magnitude smaller, but there were = a > lot > > of complaints about the churn produced by Connexion by Boeing, which wa= s > > effectively a few hundred IPv4 PI prefixes moving around at almost Mach > 1. > iirc there were complaints that it was a relatively bad idea. there were > no complaints as far as I know due to impact of the rate of prefix churn > which was way lower (by orders of magnitude) than the worst offendors > out there at the time. The prefix advertisement and withdrawal was in > fact done by the groundstatations not the aircraft. >=20 > There were never hundreds of of transcontinental commercial aircraft > engaged in roaming on the service (there were around 200 planes total > with the equipment). There are many more aircraft today operating with > satellite or terrestrial internet connectivity and without such behavior. This all happened before my time at Boeing, but my understanding is that someone noticed prefixes being announced and withdrawn due to aircraft mobility and brought the situation to light. Other factors than this were behind Boeing's decision to get out of the business, but the service itself lives on (minus the routing churn problem) in current-day deployment. Fred fred.l.templin@boeing.com > > OK, it's not a fair comparison, but I think we're on safe ground in > doubting > > that increasing from 30k to millions of PI prefixes will work smoothly. > PA prefixes count the same as far as fib slots go and if they're > multihomed by customers they're rather hard to aggregate. > > > > Brian > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jhw@apple.com Thu Mar 21 15:58:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FB921F8E5C for ; Thu, 21 Mar 2013 15:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUgE9ppmoZ61 for ; Thu, 21 Mar 2013 15:58:20 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 37ECF21F8D98 for ; Thu, 21 Mar 2013 15:58:20 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MK1007248WR6QN1@mail-out.apple.com> for v6ops@ietf.org; Thu, 21 Mar 2013 15:58:02 -0700 (PDT) X-AuditID: 11807158-b7fa36d000006cd2-b3-514b9079eafa Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 9A.BB.27858.A709B415; Thu, 21 Mar 2013 15:58:02 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MK1002WA94P0510@aniseed.apple.com> for v6ops@ietf.org; Thu, 21 Mar 2013 15:58:01 -0700 (PDT) Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated. From: james woodyatt In-reply-to: Date: Thu, 21 Mar 2013 15:58:01 -0700 Message-id: <74EC22B1-C506-4F78-B495-2335E7FABB8C@apple.com> References: <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong.com> <514B26C3.7090001@gmail.com> <514B2987.5040406@g!> To: IPv6 Operations X-Mailer: Apple Mail (2.1713) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUi2FAsrls1wTvQoKGf1eL0sb3MDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK6NuwgrXgOkvFnyW5DYzXmLsYOTkkBEwkllx/zgphi0lcuLee rYuRi0NIoJ9J4tmJNcwQzgwmiR0r7oNVCQsESHxq3McCYjMLaEms33mcCcTmFdCT+PeqGaom WmL1s6mMIDabgIrEt8t3wWo4Bewktu7vBathEVCV+Pb4KxvEHG2JJ+8usELMsZE4vfs4K8Ti Xg6JHx1fwZpFgAZNOXOfDeJUWYk7FxcwTmAUmIXkjllI7piFZO4CRuZVjAJFqTmJlaZ6iQUF Oal6yfm5mxjBoVcYsYPx/zKrQ4wCHIxKPLwaOt6BQqyJZcWVuYcYJTiYlUR4I1OAQrwpiZVV qUX58UWlOanFhxilOViUxHnnPfAMFBJITyxJzU5NLUgtgskycXBKNTDand788bXMY/t5B0tu 1n/mN7j9dXXq6YXXGmQkz/LZ7innnKhgtTEgra7qYP+549sn5rVMX3bt7LSzE9P3vNpm8U/f SvuBUbvQy/1fGc5JZImyPMgM8bixYbOINt8U3T8newM5cuRvval2c7Ht32zkYGXAWLXfRDKU /51v8KpOvoSOia2u22OUWIozEg21mIuKEwFndAlVOQIAAA== Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 22:58:20 -0000 On Mar 21, 2013, at 09:22 , Owen DeLong wrote: > On Mar 21, 2013, at 08:38 , Alexandru Petrescu wrote: >> >> Yes, routing protocol between CPEs if needed, or other form of informing >> each other about one home's prefix. >> >> But the Client PC iPads aren't likely to run OSPF BGP VRRP. How else to >> inform the address of the default router to these Client PCs? > > RIO RFC 4191 Route Information Options (RIO) are not processed by OS X or iOS hosts. -- james woodyatt core os networking From Fred.L.Templin@boeing.com Thu Mar 21 16:08:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6368621F8F2E for ; Thu, 21 Mar 2013 16:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 IArOwcVaZ1vn for ; Thu, 21 Mar 2013 16:08:25 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id B071F21F8F1E for ; Thu, 21 Mar 2013 16:08:25 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r2LN8Ot2010350 for ; Thu, 21 Mar 2013 18:08:25 -0500 Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r2LN8OiQ010343 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 21 Mar 2013 18:08:24 -0500 Received: from XCH-BLV-204.nw.nos.boeing.com (10.57.37.58) by XCH-NWHT-10.nw.nos.boeing.com (130.247.25.113) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 21 Mar 2013 16:08:23 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.214]) by XCH-BLV-204.nw.nos.boeing.com ([169.254.4.205]) with mapi id 14.02.0328.011; Thu, 21 Mar 2013 16:08:23 -0700 From: "Templin, Fred L" To: joel jaeggli , Brian E Carpenter , Alexandru Petrescu Thread-Topic: [v6ops] draft-liu-v6ops-ula-usage-analysis Thread-Index: AQHOJoEc0KGiDIiC/EanpZuEccj4CpiwvSqwgAAFYbA= Date: Thu, 21 Mar 2013 23:08:22 +0000 Message-ID: <2134F8430051B64F815C691A62D98318036F01@XCH-BLV-504.nw.nos.boeing.com> References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149C642.6060806@gmail.com> <481173D1-2F02-4B80-8E2C-BE33009EF2C9@delong.com> <514B116E.9070504@gmail.com> <514B14C2.3050303@gmail.com> <514B8598.6090401@bogus.com> <2134F8430051B64F815C691A62D98318036EC8@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D98318036EC8@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 23:08:26 -0000 FWIW, Tony Hain and I worked on a document that seems closely related to this subject about 10 years ago. This was before the publication of ULA, and intended to help the process along. I mention it in case it might offer some useful background to these discussions (see below): Fred fred.l.templin@boeing.com http://datatracker.ietf.org/doc/draft-hain-templin-ipv6-localcomm/ Abstract: The IPv6 addressing architecture specifies formats for unicast addresses, but provides no operational guidelines for their use. There is a clear need for IPv6 to support organizational-scope communications whether members of the organization are located in the same site or different sites. Aspects of certain types of sites introduce challenges for supportin= g organizational-scope communications. Of special interest are nomadic sites, e.g., sites that are intermittently-connected or disconnected from the glob= al Internet, sites that frequently change provider points of attachment, sites that temporarily or permanently merge with other sites, etc. This memo will discuss scenarios and goals for IPv6 support organizational-scope communica= tions. From joelja@bogus.com Thu Mar 21 16:10:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C98821F8FE3 for ; Thu, 21 Mar 2013 16:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.915 X-Spam-Level: X-Spam-Status: No, score=-101.915 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_MILLIONSOF=0.315, 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 RZ7ebrGJvwhe for ; Thu, 21 Mar 2013 16:10:36 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id AE95621F8F9F for ; Thu, 21 Mar 2013 16:10:36 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r2LNAXjT090481 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 21 Mar 2013 23:10:34 GMT (envelope-from joelja@bogus.com) Message-ID: <514B9364.6040803@bogus.com> Date: Thu, 21 Mar 2013 16:10:28 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: "Templin, Fred L" , Brian E Carpenter , Alexandru Petrescu References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149C642.6060806@gmail.com> <481173D1-2F02-4B80-8E2C-BE33009EF2C9@delong.com> <514B116E.9070504@gmail.com> <514B14C2.3050303@gmail.com> <514B8598.6090401@bogus.com> <2134F8430051B64F815C691A62D98318036EC8@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D98318036EC8@XCH-BLV-504.nw.nos.boeing.com> 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]); Thu, 21 Mar 2013 23:10:34 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 23:10:37 -0000 On 3/21/13 3:46 PM, Templin, Fred L wrote: > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of >> joel jaeggli >> Sent: Thursday, March 21, 2013 3:12 PM >> To: Brian E Carpenter; Alexandru Petrescu >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis >> >> On 3/21/13 7:10 AM, Brian E Carpenter wrote: >>> On 21/03/2013 13:55, Alexandru Petrescu wrote: >>> ... >>>> A PI GUA for 2-3 Enterprises may work connected mostly all the time at >>>> the same 2-3 places. But I think 1 billion PI GUAs moving around the >>>> Internet at the speed of 1 new connection/minute may not work - it >>>> involves 'route churning', i.e. too many routing protocol messages per >>>> second and too large routing table entries. Isnt't there a risk like >> that? >>> Well, it was three or four orders of magnitude smaller, but there were a >> lot >>> of complaints about the churn produced by Connexion by Boeing, which was >>> effectively a few hundred IPv4 PI prefixes moving around at almost Mach >> 1. >> iirc there were complaints that it was a relatively bad idea. there were >> no complaints as far as I know due to impact of the rate of prefix churn >> which was way lower (by orders of magnitude) than the worst offendors >> out there at the time. The prefix advertisement and withdrawal was in >> fact done by the groundstatations not the aircraft. >> >> There were never hundreds of of transcontinental commercial aircraft >> engaged in roaming on the service (there were around 200 planes total >> with the equipment). There are many more aircraft today operating with >> satellite or terrestrial internet connectivity and without such behavior. > This all happened before my time at Boeing, but my understanding > is that someone noticed prefixes being announced and withdrawn > due to aircraft mobility and brought the situation to light. Ben Abarbanel from boeing presented it at nanog 31 yeah. http://www.nanog.org/meetings/nanog31/presentations/abarbanel.pdf and about a year later at the ietf 62 technical plenary. some papers were published, etc. http://quark.net/docs/Global_IP_Network_Mobility_using_BGP.pdf > Other > factors than this were behind Boeing's decision to get out of the > business, but the service itself lives on (minus the routing churn > problem) in current-day deployment. yes as do other services with similar goals, in support of commercial aviation, general aviation, maritime, military and so forth. > Fred > fred.l.templin@boeing.com > >>> OK, it's not a fair comparison, but I think we're on safe ground in >> doubting >>> that increasing from 30k to millions of PI prefixes will work smoothly. >> PA prefixes count the same as far as fib slots go and if they're >> multihomed by customers they're rather hard to aggregate. >>> Brian >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Thu Mar 21 16:20:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A46921F8FAA for ; Thu, 21 Mar 2013 16:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.226, 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 DuwLotm2SRok for ; Thu, 21 Mar 2013 16:20:21 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 901DA21F8FA4 for ; Thu, 21 Mar 2013 16:20:21 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r2LNKKCB025742 for ; Thu, 21 Mar 2013 18:20:21 -0500 Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r2LNKJOA025726 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 21 Mar 2013 18:20:20 -0500 Received: from XCH-BLV-505.nw.nos.boeing.com (130.247.25.195) by XCH-NWHT-10.nw.nos.boeing.com (130.247.25.113) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 21 Mar 2013 16:20:19 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.214]) by XCH-BLV-505.nw.nos.boeing.com ([169.254.5.234]) with mapi id 14.02.0328.011; Thu, 21 Mar 2013 16:20:19 -0700 From: "Templin, Fred L" To: joel jaeggli , Brian E Carpenter , Alexandru Petrescu Thread-Topic: [v6ops] draft-liu-v6ops-ula-usage-analysis Thread-Index: AQHOJolG0KGiDIiC/EanpZuEccj4Cpiwxxaw Date: Thu, 21 Mar 2013 23:20:18 +0000 Message-ID: <2134F8430051B64F815C691A62D98318036F33@XCH-BLV-504.nw.nos.boeing.com> References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149C642.6060806@gmail.com> <481173D1-2F02-4B80-8E2C-BE33009EF2C9@delong.com> <514B116E.9070504@gmail.com> <514B14C2.3050303@gmail.com> <514B8598.6090401@bogus.com> <2134F8430051B64F815C691A62D98318036EC8@XCH-BLV-504.nw.nos.boeing.com> <514B9364.6040803@bogus.com> In-Reply-To: <514B9364.6040803@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 23:20:22 -0000 > > factors than this were behind Boeing's decision to get out of the > > business, but the service itself lives on (minus the routing churn > > problem) in current-day deployment. > yes as do other services with similar goals, in support of commercial > aviation, general aviation, maritime, military and so forth. I didn't say there weren't other services. Passengers on many or perhaps even most domestic flights in the US can enjoy in-flight Internet based on cellular or SATCOM. Air traffic control and airline operations are a different story, where safety-of-flight is a mildly important consideration. Fred fred.l.templin@boeing.com From owen@delong.com Thu Mar 21 17:01:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1DD21F8F9F for ; Thu, 21 Mar 2013 17:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 eKWgaFOEKEZ6 for ; Thu, 21 Mar 2013 17:01:09 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 67B6021F8E6A for ; Thu, 21 Mar 2013 17:01:01 -0700 (PDT) Received: from [10.7.13.159] (97-64-168-70.client.mchsi.com [97.64.168.70]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2LNvwtX022470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Mar 2013 16:57:59 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2LNvwtX022470 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363910280; bh=U07NF8djor5nAUFhNk+XV6c9Ilc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=oP6q9zDWx/GoqG6nFTf8jlKgZKpYrDPpbrwfkCPkyvAy4BWF3RmHCdq8Lxf0Madut SByJrZaanHAvzHXMmAw7cW1yy2xXU98YOa7nu244SR2Cn1qoe7UgRtPJE1nVXP5cEw ykFsrVX85xPZtkDxdLqVIL7hkS/BwX4YQHRYykeQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: Date: Thu, 21 Mar 2013 18:57:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 21 Mar 2013 16:58:00 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 00:01:10 -0000 On Mar 21, 2013, at 2:40 PM, Mikael Abrahamsson = wrote: > On Thu, 21 Mar 2013, Owen DeLong wrote: >=20 >> If the router doesn't provide internet access, it SHOULD NOT = advertise itself as a default router. That is the point. You are = determined to argue against that point, but the correct behavior is to = NOT BE a default router if you do not provide internet access. >=20 > So if the host doesn't support RIO then there won't be reachability = for ULAs between LANs within the home. Correct? >=20 If you have a problem with a host which does not correctly implement the = RFCs, get the host fixed. Do not break other things in other areas for the sake of this fringe = case. > I tried to make my home Cisco router send RIO for testing but I was = unable do to do so (I believe, at least no more-specific route showed up = on my Linux machine which is running 3.2). Anyone happen to know how = this would be configured and how it would show up in the config? I don't know how to help you operate your equipment. I use different = equipment. However, even if it is not possible with your equipment, see = above. Owen From owen@delong.com Thu Mar 21 17:01:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD7121F8FDA for ; Thu, 21 Mar 2013 17:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 h3R8zUsdbWgv for ; Thu, 21 Mar 2013 17:01:13 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4276C21F8FD9 for ; Thu, 21 Mar 2013 17:01:13 -0700 (PDT) Received: from [10.7.13.159] (97-64-168-70.client.mchsi.com [97.64.168.70]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2LNxh5x022497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Mar 2013 16:59:44 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2LNxh5x022497 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363910385; bh=Mtg00DLqtAQt0oNyNQh/UHpDnik=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hO7Qh2cSQlvpw90UG4iWcbdvSQklpXS3yb3bXvAj1SrQ3o++kDByy3zgORb+zllEN s28QzPss8QVfR43Mdg+uNF9MjiDZ4Gm1wEL0pV0ijBMFcGIQCjr2q9udFoQ3DBuTe/ VW0W2aODW04fUwufso93/5omkfgUAqPWNqM+oABM= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: <20130321221432.DAA383151072@drugs.dv.isc.org> Date: Thu, 21 Mar 2013 18:59:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <49D23656-3894-4DEF-92B4-2EE00749C9F4@delong.com> References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <20130321034917.71CCD3147294@drugs.dv.isc.org> <7F0F3F2D-2705-413B-A548-A5C820044BC7@delong.com> <20130321060739.52FD93148050@drugs.dv.isc.org> <20130321221432.DAA383151072@d! rugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 21 Mar 2013 16:59:45 -0700 (PDT) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 00:01:14 -0000 On Mar 21, 2013, at 5:14 PM, Mark Andrews wrote: >=20 > In message , Owen = DeLong writes: >>>> Without those flags, it is unlikely that it would have made = multiple =3D3D >>>> IPv6 attempts before falling back to IPv4, but, rather would have = made =3D3D=3D >>=20 >>>> one IPv6 attempt, then upon getting the unreachable, immediately = try =3D3D >>>> IPv4. >>>> =3D20 >>>> Owen >>> =3D20 >>> With modern stacks you just tell them to prefer the /48 ULA you are >>> using and depreference all other ULA use. If I was to disable all >>> other prefixes then IPv4 would be used for external connections. >>> =3D20 >>> % cat /etc/ip6addrctl.conf=3D20 >>> #Prefix Prec Label =3D20 >>> ::1/128 50 0 >>> ::/0 40 1 =3D20 >>> 2002::/16 30 2 =3D20 >>> ::/96 20 3 =3D20 >>> ::ffff:0.0.0.0/96 35 4 =3D20 >>> fd92:7065:b8e::/48 45 5=3D20 >>> fc00::/7 5 6 >>> =3D20 >>=20 >> Remind me where I configure the router to send the contents of = ip6addrctl.co=3D >> nf down to the SLAAC client... Oh, right... >>=20 >> Owen=3D >=20 > draft-ietf-6man-addr-select-opt-08.txt >=20 > You can do this by hand today. >=20 Bzzt=85 Non-starter for grandma. > I can configure my dhcp servers and clients to sent this using > options 224...254 today. When the option code is assigned by IANA > I can change then to use that. Bzzt=85 Granny isn't going to be configuring complex options on a DHCP server either. > Built in support had been requested, so the operator doesn't have > to describe the option, just populate its values. This is waiting > on IANA to do the assignment of the option code amongst other things. Which will then be waiting on the vendors to implement which will then = be waiting on granny to update her router=85 Right=85. We might see this in my lifetime, but I'm not optimistic. Owen From marka@isc.org Thu Mar 21 17:11:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1AB921F893B for ; Thu, 21 Mar 2013 17:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.28 X-Spam-Level: X-Spam-Status: No, score=0.28 tagged_above=-999 required=5 tests=[AWL=-2.321, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_SPCALS=2.3, MANGLED_TAKE=2.3] 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 Y3nKmU1gsZhO for ; Thu, 21 Mar 2013 17:11:32 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 5924321F867A for ; Thu, 21 Mar 2013 17:11:28 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 81365C9463; Fri, 22 Mar 2013 00:11:20 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1363911087; bh=7+jZCtgl22Z+rpLAIoQ+t5WazM02F/GWnjfqNVLZGC4=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Ry8ESqVDxXhiE9lqwsuhgkQwsqe1MWQ2mtlhKmwZNks1uZ1xaF8xetimHEz/rkXX0 DFzra0ZYUy+DlmDm2BeveNqO9PLXv2yrVyf48e7jCcETqM7FC9zBNWUOp4N+90sYmB VBA6w6K8eLCGNaVQrB8ETw03filTAuXUEjnCi8Sk= 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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Fri, 22 Mar 2013 00:11:20 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 479C9216C3B; Fri, 22 Mar 2013 00:11:20 +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 A98AB3154D2C; Fri, 22 Mar 2013 11:11:14 +1100 (EST) To: Owen DeLong From: Mark Andrews References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <1363807338.52728.YahooMailNeo@web142501.mail.bf1.yahoo.com> <62EC99DE-8F55-4E75-91C4-81F1241ED408@delong.com> In-reply-to: Your message of "Wed, 20 Mar 2013 15:10:24 CDT." <62EC99DE-8F55-4E75-91C4-81F1241ED408@delong.com> Date: Fri, 22 Mar 2013 11:11:14 +1100 Message-Id: <20130322001114.A98AB3154D2C@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 00:11:33 -0000 In message <62EC99DE-8F55-4E75-91C4-81F1241ED408@delong.com>, Owen DeLong write s: > > Why is there no hope? You're effectively saying that the ULA specifications > won't ever be followed correctly, rather than far more often than not. Could > n't the same be said about any and all specifications? Why would people follo > w nearly all specifications correctly, with the ULA specification being the s > pecial case where they won't? > > ULA is not the lone specification. There are lots of specifications that get > ignored. > > However, there is an important distinction to consider here. Most specificati > ons are to be understood and implemented by protocol developers putting those > implementations into products. In the case of ULA, you're now talking about > the need for a site administrator to follow the specification, In my experien > ce, there is a very wide range in terms of experience, capability, and motiva > tion within this group, but it is overwhelmingly weighted towards the low end > (unmotivated, not very experienced, and unlikely to even read an RFC vs. tak > e their buddy's advice that "fd00::/8 for IPv6 works just like 10/8 for IPv4" > . Actually I expect most ULA prefixes to be generated by CPE devices. Use ULA on/off with a pre-filled in, CPE generated, ULA field that is greyed out when set to off. If the field is over written it is saved to non-volatile memory. For good measure fd00::/48 is rejected. You can override it but it starts out as a random prefix. > Owen > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From swmike@swm.pp.se Thu Mar 21 20:30:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA0321F8E6A for ; Thu, 21 Mar 2013 20:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.228, 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 VDCkRqvLMC-W for ; Thu, 21 Mar 2013 20:30:46 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 4831E21F8E62 for ; Thu, 21 Mar 2013 20:30:45 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3A44A9E; Fri, 22 Mar 2013 04:30:41 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 566629C; Fri, 22 Mar 2013 04:30:41 +0100 (CET) Date: Fri, 22 Mar 2013 04:30:41 +0100 (CET) From: Mikael Abrahamsson To: Owen DeLong In-Reply-To: Message-ID: References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 03:30:47 -0000 On Thu, 21 Mar 2013, Owen DeLong wrote: > If you have a problem with a host which does not correctly implement the > RFCs, get the host fixed. I have little problem with broken intra-home connectivity if the Internet link is down. I just want to know that deploying a rfc6204bis home router won't cause people to call my customer support and complain about "slow Internet" because the customer doesn't have IPv6 Internet connectivity (but IPv4 works). It seems this is not a problem, so I'm happy. So in this ULA usage analysis document it should be noted that a routed home with ULAs won't work until the hosts support RIO. > I don't know how to help you operate your equipment. I use different > equipment. However, even if it is not possible with your equipment, see > above. Do you know of any equipment that actually supports RIO? -- Mikael Abrahamsson email: swmike@swm.pp.se From owen@delong.com Thu Mar 21 20:56:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67E011E809C for ; Thu, 21 Mar 2013 20:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhdYGO7x7ad2 for ; Thu, 21 Mar 2013 20:56:01 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7344C21F8AB7 for ; Thu, 21 Mar 2013 20:56:01 -0700 (PDT) Received: from [10.7.13.159] (97-64-168-70.client.mchsi.com [97.64.168.70]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2M3qaYa027217 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Mar 2013 20:52:37 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2M3qaYa027217 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363924358; bh=S4WeG2H7yTCioOmXUu/gIOMFNWk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=3XVf22wkq28wjf6yUOr/k4pWfpNFG2VBTDlmqu23ZyVrHoiMmkuNBw2vakDFavBUr dSl0LJpW9rdRIxqV9TDS3GSAIi84x/mbaYvQiHmlF3m3GT1J0MbmhLtFdMoVich2wP 9e5oiF5xce4DvfN5qdeFgyW6T4OfMPxD9EMSHueM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: Date: Thu, 21 Mar 2013 22:52:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 21 Mar 2013 20:52:38 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 03:56:02 -0000 On Mar 21, 2013, at 10:30 PM, Mikael Abrahamsson = wrote: > On Thu, 21 Mar 2013, Owen DeLong wrote: >=20 >> If you have a problem with a host which does not correctly implement = the RFCs, get the host fixed. >=20 > I have little problem with broken intra-home connectivity if the = Internet link is down. I just want to know that deploying a rfc6204bis = home router won't cause people to call my customer support and complain = about "slow Internet" because the customer doesn't have IPv6 Internet = connectivity (but IPv4 works). It seems this is not a problem, so I'm = happy. >=20 > So in this ULA usage analysis document it should be noted that a = routed home with ULAs won't work until the hosts support RIO. >=20 I'm all for that. >> I don't know how to help you operate your equipment. I use different = equipment. However, even if it is not possible with your equipment, see = above. >=20 > Do you know of any equipment that actually supports RIO? I haven't done such an analysis as it hasn't been important until now. = I've avoided the use of ULAs which helps a lot. Owen From john.mann@monash.edu Thu Mar 21 21:21:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A42221F8B20 for ; Thu, 21 Mar 2013 21:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.376 X-Spam-Level: X-Spam-Status: No, score=-5.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 vNdbRNeJm+yv for ; Thu, 21 Mar 2013 21:21:23 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0764221F8B4C for ; Thu, 21 Mar 2013 21:21:23 -0700 (PDT) Received: from mail-wi0-f197.google.com ([209.85.212.197]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKUUvcQvASzbqqFJ9acYbxUQcTsr6ppEmX@postini.com; Thu, 21 Mar 2013 21:21:23 PDT Received: by mail-wi0-f197.google.com with SMTP id hn17so5865326wib.8 for ; Thu, 21 Mar 2013 21:21:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=O9zafhyKYqlkztDHE3/VSGQn4M/yXKGDRYsAuDS7ctU=; b=VbLA1uxQGArvG3ZgwGcv3N2T+h6kDH0xkgBgW1iFBxCYnSCvzXdcFHZ2R6RARtv2Qw GvtGT7D+jZoBWo/zjZ36n7ksJkQiW3diMwaFVhZO42+BP+DJBb0FcZ+FE9l4a9GKeCqL 1rkGIQN+Y60mBKhajD9/9gOSSadA8YoJtIOPumaSjuvn4o3fSprxe6EggYK4xEuPKOCd d0oDMrYsMuWMcLwco2vP8QTwHxhQFl31uHBAFfajWoOMrG11DzsAGaxXH1DPuhh/AUVR 7NM4k059TgZO1YFBXjhMrIyIDxInlyRvKusftWjOTNtdvW6sk8Sp1YohfpgndeoEv75v u+bg== X-Received: by 10.180.74.131 with SMTP id t3mr453905wiv.26.1363926081491; Thu, 21 Mar 2013 21:21:21 -0700 (PDT) X-Received: by 10.180.74.131 with SMTP id t3mr453895wiv.26.1363926081343; Thu, 21 Mar 2013 21:21:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.234.207 with HTTP; Thu, 21 Mar 2013 21:21:00 -0700 (PDT) In-Reply-To: References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> From: John Mann Date: Fri, 22 Mar 2013 15:21:00 +1100 Message-ID: To: Iljitsch van Beijnum Content-Type: multipart/alternative; boundary=f46d043be130942f7304d87bc98f X-Gm-Message-State: ALoCoQnYzWI/5AokL2yxv6G7cfQ6xKKz6Uxfv+NNTKSwwTFXN/TATF/Uy4b8qpp56/i1jQainLBx4IF3nhwOKeVsAg4a7FTJ+31AkLEQkMxJl1XnngBbgH16P9rjGRUEMwXJ8moP5q5+ Cc: IPv6 Ops WG , "draft-steffann-tunnels@tools.ietf.org" Subject: Re: [v6ops] draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 04:21:24 -0000 --f46d043be130942f7304d87bc98f Content-Type: text/plain; charset=ISO-8859-1 Hi, Since you discuss LISP which among other things can tunnel IPv6 in IPv4, why not also discuss SEAL (and its friends VET, RANGER, IRON) References http://tools.ietf.org/html/rfc5320 or http://tools.ietf.org/html/draft-templin-intarea-seal-52 http://www.isatap.org/ Tunneling Mechanism Feature Comparison (v0.1) http://isatap.com/comparison.pdf Thanks, John On 20 March 2013 03:36, Iljitsch van Beijnum wrote: > On 15 feb 2013, at 9:44, Iljitsch van Beijnum wrote: > > > Three of us were asked by the Dutch academic network Surfnet to write an > overview of IPv6-in-IPv4 tunneling mechanisms. To benefit the wider > community, we did so in the form of a draft, that we intend to submit to > the RFC Editor as an independent submission. > > > However, we would very much appreciate reviews and comments from within > the IETF. > > We have submitted version -01 which addresses remarks from reviewers. The > new version can be found here: > > https://datatracker.ietf.org/doc/draft-steffann-tunnels/ > > We plan on submitting the draft to the RFC Editor at the end of the week. > > Iljitsch > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f46d043be130942f7304d87bc98f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Since you discuss LISP which among other things can = tunnel IPv6 in IPv4,
why not also discuss SEAL (and its friends V= ET, RANGER, IRON)

References
=A0 =A0 or http://tools.ietf.org/html/draft-templin-intarea-seal-52

Thanks,
=A0 =A0 John

On 20 March 2013 03:36, Iljitsch van Beijnum <iljitsch@muada.com>= wrote:
On 15 feb 2013, at 9:44, Iljitsch van Beijnum <iljitsch@muada.com> wrote:

> Three of us were asked by the Dutch academic n= etwork Surfnet to write an overview of IPv6-in-IPv4 tunneling mechanisms. T= o benefit the wider community, we did so in the form of a draft, that we in= tend to submit to the RFC Editor as an independent submission.

> However, we would very much appreciate reviews and comments from withi= n the IETF.

We have submitted version -01 which addresses remarks from reviewers.= The new version can be found here:

https://datatracker.ietf.org/doc/draft-steffann-tunnels/
We plan on submitting the draft to the RFC Editor at the end of the week.
Iljitsch
_____________________= __________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--f46d043be130942f7304d87bc98f-- From iljitsch@muada.com Fri Mar 22 01:08:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7B321F9042 for ; Fri, 22 Mar 2013 01:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqyI1y2V+Gvb for ; Fri, 22 Mar 2013 01:08:39 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAC321F9041 for ; Fri, 22 Mar 2013 01:08:39 -0700 (PDT) Received: from [IPv6:2001:470:1f0b:1289:25d4:7490:3ee0:1aec] ([IPv6:2001:470:1f0b:1289:25d4:7490:3ee0:1aec]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2M83clR084114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Mar 2013 09:03:39 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: Date: Fri, 22 Mar 2013 09:08:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <71A7DA01-4610-4B12-A3FB-6505C38CEBAF@muada.com> References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> To: John Mann X-Mailer: Apple Mail (2.1499) Cc: IPv6 Ops WG , "draft-steffann-tunnels@tools.ietf.org" Subject: Re: [v6ops] draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 08:08:40 -0000 On 22 mrt 2013, at 5:21, John Mann wrote: > Since you discuss LISP which among other things can tunnel IPv6 in = IPv4, > why not also discuss SEAL (and its friends VET, RANGER, IRON) We were unaware of RANGER and IRON, but decided against including SEAL = and VET. Like LISP, those protocols are not really meant to be = IPv6-in-IPv4 tunneling mechanisms, but we have information that LISP is = actually used as such by at least a few people. Iljitsch= From brian.e.carpenter@gmail.com Fri Mar 22 01:45:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D1321F9040 for ; Fri, 22 Mar 2013 01:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.318 X-Spam-Level: X-Spam-Status: No, score=-99.318 tagged_above=-999 required=5 tests=[AWL=-0.397, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 63VkjrNbZqVN for ; Fri, 22 Mar 2013 01:45:37 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id B397921F901E for ; Fri, 22 Mar 2013 01:45:36 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hi8so2387358wib.0 for ; Fri, 22 Mar 2013 01:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=U/PWrhkj6sMk4KLn1mt4nP27rxHbIqLXT5XLp6D50QM=; b=r3xkxui1tLsOwtQmP4BodPTgRFyV+/z86r8QKaHdRRAwPLLluc9dht6yHXZhAbORxj cgpOy1GIn3cyoYvvlWA+etwtEqh1t3t3mFudqBaB5ZszRUQctB/AyTyWKukinLfthme5 gHTCD1W5nCpn93hhwdL3/lf7DXtuluEphGfcDOMwO6jvYWMOmJj5uFHhzBNTVr10TGbY VD1lLqI6BhXiVoGWEI7P5H9vgUd8NRjXQrILnXS9ZzUrz6lPdaQPdlnChugJ9tsnli+P OfgHrczRZwmoJx0j6KMKYkJo9h1tOBwiV83zkupSVtrpEheoX0o5WST3hQjAJ/z+ppZ8 rizg== X-Received: by 10.194.77.110 with SMTP id r14mr1512653wjw.2.1363941935970; Fri, 22 Mar 2013 01:45:35 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-189-72.as13285.net. [2.101.189.72]) by mx.google.com with ESMTPS id q13sm13938963wie.0.2013.03.22.01.45.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Mar 2013 01:45:35 -0700 (PDT) Message-ID: <514C1A3D.6030006@gmail.com> Date: Fri, 22 Mar 2013 08:45:49 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: james woodyatt References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong.com> <514B26C3.7090001@gmail.com> <514B2987.5040406@g!> <74EC22B1-C506-4F78-B495-2335E7FABB8C@apple.com> In-Reply-To: <74EC22B1-C506-4F78-B495-2335E7FABB8C@apple.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 08:45:37 -0000 On 21/03/2013 22:58, james woodyatt wrote: > On Mar 21, 2013, at 09:22 , Owen DeLong wrote: >> On Mar 21, 2013, at 08:38 , Alexandru Petrescu wrote: >>> Yes, routing protocol between CPEs if needed, or other form of informing >>> each other about one home's prefix. >>> >>> But the Client PC iPads aren't likely to run OSPF BGP VRRP. How else to >>> inform the address of the default router to these Client PCs? >> RIO > > RFC 4191 Route Information Options (RIO) are not processed by OS X or iOS hosts. RIPng? From brian.e.carpenter@gmail.com Fri Mar 22 01:49:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BE421F9072 for ; Fri, 22 Mar 2013 01:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.531 X-Spam-Level: X-Spam-Status: No, score=-100.531 tagged_above=-999 required=5 tests=[AWL=0.845, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, 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 cLZOPodrgblz for ; Fri, 22 Mar 2013 01:49:25 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 09F0B21F9037 for ; Fri, 22 Mar 2013 01:49:24 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id 15so2876618wgd.31 for ; Fri, 22 Mar 2013 01:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LhVgpRul3QICZdN78m6NQ6oFIOa/ZyinV3W20mbULsw=; b=R2yuD4mFiOg46bMUfHLA+z9AMvFuzkIKyndIAeK5FCPj7uJwSKdNVJ9+dr83YgtTt4 PAtDkr1PQLAZdDCrFIU4a0wNWaXilQt+bOEmZFks4Hz+Ht6wUboNCE2oN7N0udI6nnbf djejMRdrtQPBKkZVI43lJ7zP3Yd4YtPbFgCDFPr9noXeTtLuHfG5V32Eh0SukThYt7rw XwRvn5yWqyE2USeXGSw4g0mWIG03vBNSuafAgm/TLWb6Rji1CjQs1fy0ijz1z9hRErxD /LcjepYvzpdu2w5PoWH04Op/d6aIUOj7w/tvJdiopZUi3YtVkFKbyLOCPril3fJY1BvL n4Ig== X-Received: by 10.194.120.195 with SMTP id le3mr1368679wjb.46.1363942164267; Fri, 22 Mar 2013 01:49:24 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-189-72.as13285.net. [2.101.189.72]) by mx.google.com with ESMTPS id fb8sm1991366wid.1.2013.03.22.01.49.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Mar 2013 01:49:23 -0700 (PDT) Message-ID: <514C1B21.2010307@gmail.com> Date: Fri, 22 Mar 2013 08:49:37 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: joel jaeggli References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149C642.6060806@gmail.com> <481173D1-2F02-4B80-8E2C-BE33009EF2C9@delong.com> <514B116E.9070504@gmail.com> <514B14C2.3050303@gmail.com> <514B8598.6090401@bogus.com> In-Reply-To: <514B8598.6090401@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 08:49:26 -0000 On 21/03/2013 22:11, joel jaeggli wrote: > On 3/21/13 7:10 AM, Brian E Carpenter wrote: >> On 21/03/2013 13:55, Alexandru Petrescu wrote: >> ... >>> A PI GUA for 2-3 Enterprises may work connected mostly all the time at >>> the same 2-3 places. But I think 1 billion PI GUAs moving around the >>> Internet at the speed of 1 new connection/minute may not work - it >>> involves 'route churning', i.e. too many routing protocol messages per >>> second and too large routing table entries. Isnt't there a risk like >>> that? >> Well, it was three or four orders of magnitude smaller, but there were >> a lot >> of complaints about the churn produced by Connexion by Boeing, which was >> effectively a few hundred IPv4 PI prefixes moving around at almost >> Mach 1. > iirc there were complaints that it was a relatively bad idea. there were > no complaints as far as I know due to impact of the rate of prefix churn > which was way lower (by orders of magnitude) than the worst offendors > out there at the time. The prefix advertisement and withdrawal was in > fact done by the groundstatations not the aircraft. > > There were never hundreds of of transcontinental commercial aircraft > engaged in roaming on the service (there were around 200 planes total > with the equipment). There are many more aircraft today operating with > satellite or terrestrial internet connectivity and without such behavior. >> OK, it's not a fair comparison, but I think we're on safe ground in >> doubting >> that increasing from 30k to millions of PI prefixes will work smoothly. > PA prefixes count the same as far as fib slots go and if they're > multihomed by customers they're rather hard to aggregate. Of course. The discussion here was about PI instead of ULA, however. The point is that ULA prefixes can and should be filtered, but that is not the expectation for PI. Brian Brian From lorenzo@google.com Fri Mar 22 02:11:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0227221F8F08 for ; Fri, 22 Mar 2013 02:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbLZzkagyeoo for ; Fri, 22 Mar 2013 02:10:56 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id CE86D21F8F16 for ; Fri, 22 Mar 2013 02:10:55 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id oi10so2536070obb.14 for ; Fri, 22 Mar 2013 02:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=HUmX9qlrMkJxp7D6xezaymbtxG8FYFye6RSCfTYqeLI=; b=fcDo4xpy6OdL3yUyeYFq2xFKj5B+d5tt+nlrvuJNKktjLOu9NBXCD7kUn40P/MM4jO agJJdsH3gx4EM8A/nxSZ4peW1v/viS9RIh7p8QzNX1c6iyTBdrFh2zIuRlNCrr2l9XD2 7/qopIeYMsQ1sIX2AyNQkraLc5K3Y4F3x6etYuHyODBFummVZjWdj+r/h4qf2q4EfRsy 57YPCZnfnGco+LljgVEFogDQZ96b2NciIeHysm5KLX4+fJy8PdrXsbbE9zN6JIVMNA8N Dg/8kczsXG72nhRKbOjj8wPlu8jPMUv3/m9xFsMVywOdDGUGG8o2eMLVnCBsANrWzckz eSLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=HUmX9qlrMkJxp7D6xezaymbtxG8FYFye6RSCfTYqeLI=; b=SZfY1xqPuLya+Yn5F/s+Nk21ytKZF8SoKxQPawG8A1LEZ/RX6kmaoi6qn076ZjFgKr PX98m36N0HNwfwAXbEznT8fEPvW5Yczc7bHYmLlt1qU22+wMbvAuX61+rK1oeQis6hfR NW8IiondJWdpwOPS6KusF92LaBD6NyaS6cn9Otl9ZFHkSYtEcWz1UjQNpuLStGnHC1/Y fB24qcSLPoxQ6wz2z+7vbG43vFERs/9QnND1oTOsvgaoKqFam/JVTTaQPa2Ei+5AGkQD qcgL8BnBb/TM+Igco2E0eAZYG70C5ZrpZCwH0I/hQ/myIaPhR/bNj9FV8+QuEbEy6NAR m0hQ== X-Received: by 10.60.6.199 with SMTP id d7mr830909oea.137.1363943455365; Fri, 22 Mar 2013 02:10:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Fri, 22 Mar 2013 02:10:33 -0700 (PDT) In-Reply-To: <74EC22B1-C506-4F78-B495-2335E7FABB8C@apple.com> References: <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong.com> <514B26C3.7090001@gmail.com> <514B2987.5040406@g!> <74EC22B1-C506-4F78-B495-2335E7FABB8C@apple.com> From: Lorenzo Colitti Date: Fri, 22 Mar 2013 02:10:33 -0700 Message-ID: To: james woodyatt Content-Type: multipart/alternative; boundary=e89a8fb1fd7426cfc204d87fd572 X-Gm-Message-State: ALoCoQl1ORkRyuAwuQOQ/ZLnQJgBmb8G3h2/aI6WJckNKUokEMSPB6ONcvi2iy/EVmsGR4V25Sk5jt1O4+KENiJbvSi4/e4Ru3sps1S+ErBhnVzaGnvug7jr/aSCW/wxJjDT6R5xL2MK+Yxnt2KBTMGfOtbr7dlj6NMVwakgflpzhnJ+3W+KC0/ih7trxbvIKLnEfBjDNoyb Cc: IPv6 Operations Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 09:11:09 -0000 --e89a8fb1fd7426cfc204d87fd572 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 21, 2013 at 3:58 PM, james woodyatt wrote: > >> But the Client PC iPads aren't likely to run OSPF BGP VRRP. How else to > >> inform the address of the default router to these Client PCs? > > > > RIO > > RFC 4191 Route Information Options (RIO) are not processed by OS X or iOS > hosts. > Can that be fixed, or is there some fundamental objection to RIOs (like there is to making the getaddrinfo policy table configurable) that makes it unrealistic to assume that these will be supported in the future? If you don't support RIOs, then there is no way to tell hosts that there are specific routes, so networks that want any connectivity at all are forced to give them a default route, even if there is partial connectivity. That seems unfortunate. --e89a8fb1fd7426cfc204d87fd572 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 21, 2013 at 3:58 PM, james woodyatt <jhw@apple.c= om> wrote:
>> But the Client PC iPads aren't likely to run= OSPF BGP VRRP. =A0How else to
>> inform the address of the default router to these Client PCs?
>
> RIO

RFC 4191 Route Information Options (RIO) are not processed by OS X or= iOS hosts.

Can that be fixed, or= is there some fundamental objection to RIOs (like there is to making the g= etaddrinfo policy table configurable) that makes it unrealistic to assume t= hat these will be supported in the future?

If you don't support RIOs, then there i= s no way to tell hosts that there are specific routes, so networks that wan= t any connectivity at all are forced to give them a default route, even if = there is partial connectivity. That seems unfortunate.
--e89a8fb1fd7426cfc204d87fd572-- From kaeo@merike.com Fri Mar 22 02:43:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A7321F887D for ; Fri, 22 Mar 2013 02:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dL1GYlXUSXy5 for ; Fri, 22 Mar 2013 02:43:28 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 8685021F8DCF for ; Fri, 22 Mar 2013 02:43:28 -0700 (PDT) Received: from [192.168.66.107] ([208.76.186.125]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id r2M9h01P018820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Mar 2013 02:43:01 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Merike Kaeo In-Reply-To: <514B9364.6040803@bogus.com> Date: Fri, 22 Mar 2013 02:42:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2EFC0D07-DA29-46F7-92E7-FA4C69ACF95F@merike.com> References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149C642.6060806@gmail.com> <481173D1-2F02-4B80-8E2C-BE33009EF2C9@delong.com> <514B116E.9070504@gmail.com> <514B14C2.3050303@gmail.com> <514B8598.6090401@bogus.com> <2134F8430051B64F815C691A62D98318036EC8@XCH-BLV-504.nw.nos.boeing.com> <514B9364.! 6040803@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 09:43:29 -0000 On Mar 21, 2013, at 4:10 PM, joel jaeggli wrote: > On 3/21/13 3:46 PM, Templin, Fred L wrote: >>=20 >>> -----Original Message----- >>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of >>> joel jaeggli >>> Sent: Thursday, March 21, 2013 3:12 PM >>> To: Brian E Carpenter; Alexandru Petrescu >>> Cc: v6ops@ietf.org >>> Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis >>>=20 >>> On 3/21/13 7:10 AM, Brian E Carpenter wrote: >>>> On 21/03/2013 13:55, Alexandru Petrescu wrote: >>>> ... >>>>> A PI GUA for 2-3 Enterprises may work connected mostly all the = time at >>>>> the same 2-3 places. But I think 1 billion PI GUAs moving around = the >>>>> Internet at the speed of 1 new connection/minute may not work - it >>>>> involves 'route churning', i.e. too many routing protocol messages = per >>>>> second and too large routing table entries. Isnt't there a risk = like >>> that? >>>> Well, it was three or four orders of magnitude smaller, but there = were a >>> lot >>>> of complaints about the churn produced by Connexion by Boeing, = which was >>>> effectively a few hundred IPv4 PI prefixes moving around at almost = Mach >>> 1. >>> iirc there were complaints that it was a relatively bad idea. there = were >>> no complaints as far as I know due to impact of the rate of prefix = churn >>> which was way lower (by orders of magnitude) than the worst = offendors >>> out there at the time. The prefix advertisement and withdrawal was = in >>> fact done by the groundstatations not the aircraft. >>>=20 >>> There were never hundreds of of transcontinental commercial aircraft >>> engaged in roaming on the service (there were around 200 planes = total >>> with the equipment). There are many more aircraft today operating = with >>> satellite or terrestrial internet connectivity and without such = behavior. >> This all happened before my time at Boeing, but my understanding >> is that someone noticed prefixes being announced and withdrawn >> due to aircraft mobility and brought the situation to light. > Ben Abarbanel from boeing presented it at nanog 31 yeah. >=20 > http://www.nanog.org/meetings/nanog31/presentations/abarbanel.pdf >=20 > and about a year later at the ietf 62 technical plenary. >=20 > some papers were published, etc. >=20 > http://quark.net/docs/Global_IP_Network_Mobility_using_BGP.pdf Connexion By Boeing peaked my interest since I worked for them and back = in 2005/6 developed their IPv6 strategy plus configured the testbed ground stations to be = dual-stacked (I had a /48 from Boeing's=20 /32 PI routed by NTT....that caused quite the debates internal to NTT = since at that time ISPs were still debating=20 merits of doing so). It was fun trying get the ISPs to tell me the = real deal... "no, I don't want a tunnel I want a=20 native eBGP connection and please route my /48". How times change. I can definitively state that at that time with v6 there was going to be = NO ULA usage although yes, there was routing churn that was disliked by ISPs but noone was actively saying it = was causing *great harm*. It was just very unsavory - hence the talks at NANOG and APRICOT and RIPE to explain = and get more feedback. [and the folks building the routing had talked to some global ISPs before finally = deciding on going that route] Of course using v6 routing at that time if we had gone live *could* have = shown interesting global routing behavior :) =20 It's unfortunate Connexion By Boeing went under....we were in process of = moving to production test with v6 at the time (early 2006). Although as Fred has stated, the system is = still operational but for a very limited set of folks. Stuck in v4 AFAIK. As far as mobility scenarios - due to the routing churn issues in v4 I = was following NEMO and other mobility scenarios to see how they might be utilized with v6. Not sure where that went as = I stopped following it. Whether you use ULA or GUA for mobility has no difference. The issue = comes in whether you have an entirely closed system=20 (air traffic control and some other global mobile entities do) or = whether you need to communicate to outside world. The latter gets more interesting with ULAs. - merike From Fred.L.Templin@boeing.com Fri Mar 22 08:19:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3CC21F8AA8 for ; Fri, 22 Mar 2013 08:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 8sl7RTxxfidr for ; Fri, 22 Mar 2013 08:19:10 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id BD89E21F8775 for ; Fri, 22 Mar 2013 08:19:10 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r2MFJAP6017702 for ; Fri, 22 Mar 2013 08:19:10 -0700 Received: from XCH-PHX-211.sw.nos.boeing.com (xch-phx-211.sw.nos.boeing.com [130.247.25.140]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r2MFJ8ZP017659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 22 Mar 2013 08:19:08 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.214]) by XCH-PHX-211.sw.nos.boeing.com ([169.254.11.106]) with mapi id 14.02.0328.011; Fri, 22 Mar 2013 08:19:06 -0700 From: "Templin, Fred L" To: Iljitsch van Beijnum , John Mann Thread-Topic: [v6ops] draft-steffann-tunnels-00.txt Thread-Index: AQHOJtSC7Yio3E/7Z02Ayj09oEGtYJixzyVQ Date: Fri, 22 Mar 2013 15:19:06 +0000 Message-ID: <2134F8430051B64F815C691A62D98318037A1E@XCH-BLV-504.nw.nos.boeing.com> References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> <71A7DA01-4610-4B12-A3FB-6505C38CEBAF@muada.com> In-Reply-To: <71A7DA01-4610-4B12-A3FB-6505C38CEBAF@muada.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: IPv6 Ops WG , "draft-steffann-tunnels@tools.ietf.org" Subject: Re: [v6ops] draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 15:19:11 -0000 We use SEAL and VET internally within Boeing, and have IRON as a proposed network mobility solution for civil aviation (among many other uses). The first editions of these documents were published as RFC5320, RFC5558 and RFC6179. The second editions are now in the RFC Editor queue: https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ https://datatracker.ietf.org/doc/draft-templin-intarea-vet/ https://datatracker.ietf.org/doc/draft-templin-ironbis/ Like AYIYA, these mechanisms are for encapsulation of any IP-in-IP versions, including IPv6-in-IPv4. I will eventually get around to creating a second edition of RANGER, but for now the references are RFC5720 and RFC6139. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Iljitsch van Beijnum > Sent: Friday, March 22, 2013 1:09 AM > To: John Mann > Cc: IPv6 Ops WG; draft-steffann-tunnels@tools.ietf.org > Subject: Re: [v6ops] draft-steffann-tunnels-00.txt >=20 > On 22 mrt 2013, at 5:21, John Mann wrote: >=20 > > Since you discuss LISP which among other things can tunnel IPv6 in IPv4= , > > why not also discuss SEAL (and its friends VET, RANGER, IRON) >=20 > We were unaware of RANGER and IRON, but decided against including SEAL an= d > VET. Like LISP, those protocols are not really meant to be IPv6-in-IPv4 > tunneling mechanisms, but we have information that LISP is actually used > as such by at least a few people. >=20 > Iljitsch > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Fri Mar 22 08:26:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD59821F8D3C for ; Fri, 22 Mar 2013 08:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218, 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 2w29v4IpmTSq for ; Fri, 22 Mar 2013 08:26:30 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6475421F8E65 for ; Fri, 22 Mar 2013 08:26:29 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r2MFQRPQ025884 for ; Fri, 22 Mar 2013 10:26:28 -0500 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r2MFQQuN025851 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 22 Mar 2013 10:26:27 -0500 Received: from XCH-BLV-501.nw.nos.boeing.com (130.247.25.190) by XCH-NWHT-11.nw.nos.boeing.com (130.247.25.114) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 22 Mar 2013 08:26:26 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.214]) by XCH-BLV-501.nw.nos.boeing.com ([169.254.1.96]) with mapi id 14.02.0328.011; Fri, 22 Mar 2013 08:26:24 -0700 From: "Templin, Fred L" To: Merike Kaeo , joel jaeggli Thread-Topic: [v6ops] draft-liu-v6ops-ula-usage-analysis Thread-Index: AQHOJuGj0KGiDIiC/EanpZuEccj4Cpix1FIQ Date: Fri, 22 Mar 2013 15:26:23 +0000 Message-ID: <2134F8430051B64F815C691A62D98318037A52@XCH-BLV-504.nw.nos.boeing.com> References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149C642.6060806@gmail.com> <481173D1-2F02-4B80-8E2C-BE33009EF2C9@delong.com> <514B116E.9070504@gmail.com> <514B14C2.3050303@gmail.com> <514B8598.6090401@bogus.com> <2134F8430051B64F815C691A62D98318036EC8@XCH-BLV-504.nw.nos.boeing.com> <514B9364.! 6040803@bogus.com> <2EFC0D07-DA29-46F7-92E7-FA4C69ACF95F@merike.com> In-Reply-To: <2EFC0D07-DA29-46F7-92E7-FA4C69ACF95F@merike.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 15:26:33 -0000 Hi Merike, > -----Original Message----- > From: Merike Kaeo [mailto:kaeo@merike.com] > Sent: Friday, March 22, 2013 2:43 AM > To: joel jaeggli > Cc: Templin, Fred L; Brian E Carpenter; Alexandru Petrescu; v6ops@ietf.or= g > Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis >=20 >=20 > On Mar 21, 2013, at 4:10 PM, joel jaeggli wrote: >=20 > > On 3/21/13 3:46 PM, Templin, Fred L wrote: > >> > >>> -----Original Message----- > >>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behal= f > Of > >>> joel jaeggli > >>> Sent: Thursday, March 21, 2013 3:12 PM > >>> To: Brian E Carpenter; Alexandru Petrescu > >>> Cc: v6ops@ietf.org > >>> Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis > >>> > >>> On 3/21/13 7:10 AM, Brian E Carpenter wrote: > >>>> On 21/03/2013 13:55, Alexandru Petrescu wrote: > >>>> ... > >>>>> A PI GUA for 2-3 Enterprises may work connected mostly all the time > at > >>>>> the same 2-3 places. But I think 1 billion PI GUAs moving around > the > >>>>> Internet at the speed of 1 new connection/minute may not work - it > >>>>> involves 'route churning', i.e. too many routing protocol messages > per > >>>>> second and too large routing table entries. Isnt't there a risk > like > >>> that? > >>>> Well, it was three or four orders of magnitude smaller, but there > were a > >>> lot > >>>> of complaints about the churn produced by Connexion by Boeing, which > was > >>>> effectively a few hundred IPv4 PI prefixes moving around at almost > Mach > >>> 1. > >>> iirc there were complaints that it was a relatively bad idea. there > were > >>> no complaints as far as I know due to impact of the rate of prefix > churn > >>> which was way lower (by orders of magnitude) than the worst offendors > >>> out there at the time. The prefix advertisement and withdrawal was in > >>> fact done by the groundstatations not the aircraft. > >>> > >>> There were never hundreds of of transcontinental commercial aircraft > >>> engaged in roaming on the service (there were around 200 planes tota= l > >>> with the equipment). There are many more aircraft today operating wit= h > >>> satellite or terrestrial internet connectivity and without such > behavior. > >> This all happened before my time at Boeing, but my understanding > >> is that someone noticed prefixes being announced and withdrawn > >> due to aircraft mobility and brought the situation to light. > > Ben Abarbanel from boeing presented it at nanog 31 yeah. > > > > http://www.nanog.org/meetings/nanog31/presentations/abarbanel.pdf > > > > and about a year later at the ietf 62 technical plenary. > > > > some papers were published, etc. > > > > http://quark.net/docs/Global_IP_Network_Mobility_using_BGP.pdf >=20 > Connexion By Boeing peaked my interest since I worked for them and back i= n > 2005/6 developed their > IPv6 strategy plus configured the testbed ground stations to be dual- > stacked (I had a /48 from Boeing's > /32 PI routed by NTT....that caused quite the debates internal to NTT > since at that time ISPs were still debating > merits of doing so). It was fun trying get the ISPs to tell me the rea= l > deal... "no, I don't want a tunnel I want a > native eBGP connection and please route my /48". How times change. >=20 > I can definitively state that at that time with v6 there was going to be > NO ULA usage although yes, there was > routing churn that was disliked by ISPs but noone was actively saying it > was causing *great harm*. It was just > very unsavory - hence the talks at NANOG and APRICOT and RIPE to explain > and get more feedback. [and the folks > building the routing had talked to some global ISPs before finally > deciding on going that route] >=20 > Of course using v6 routing at that time if we had gone live *could* have > shown interesting global routing behavior :) >=20 > It's unfortunate Connexion By Boeing went under....we were in process of > moving to production test with v6 > at the time (early 2006). Although as Fred has stated, the system is > still operational but for a very limited set of folks. > Stuck in v4 AFAIK. My understanding was that the service was picked up by Panasonic eXConnect. =20 > As far as mobility scenarios - due to the routing churn issues in v4 I wa= s > following NEMO and other mobility scenarios > to see how they might be utilized with v6. Not sure where that went as I > stopped following it. We have taken care of the routing churn issue with SEAL/VET/IRON: https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ https://datatracker.ietf.org/doc/draft-templin-intarea-vet/ https://datatracker.ietf.org/doc/draft-templin-ironbis/ Thanks - Fred fred.l.templin@boeing.com > Whether you use ULA or GUA for mobility has no difference. The issue > comes in whether you have an entirely closed system > (air traffic control and some other global mobile entities do) or whether > you need to communicate to outside world. The latter > gets more interesting with ULAs. >=20 > - merike From suresh.krishnan@ericsson.com Fri Mar 22 08:27:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B31221F8526 for ; Fri, 22 Mar 2013 08:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 tf7QHimA53h4 for ; Fri, 22 Mar 2013 08:27:14 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 79C7A21F8525 for ; Fri, 22 Mar 2013 08:27:14 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-dd-514c7850d4a6 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E4.B2.02411.1587C415; Fri, 22 Mar 2013 16:27:13 +0100 (CET) Received: from eusaamw0712.eamcs.ericsson.se (147.117.20.181) by EUSAAHC003.ericsson.se (147.117.188.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 22 Mar 2013 11:27:12 -0400 Received: from [142.133.112.81] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 22 Mar 2013 11:27:11 -0400 Message-ID: <514C77BD.9090708@ericsson.com> Date: Fri, 22 Mar 2013 11:24:45 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Iljitsch van Beijnum References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> In-Reply-To: <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyuXRPoG5ghU+gwcM2I4tZ7Q3MFqeP7WV2 YPJYsuQnk8fjl8cYA5iiuGxSUnMyy1KL9O0SuDIWPvMrOKZQ8fTBb8YGxiaJLkZODgkBE4mt R/+wQthiEhfurWfrYuTiEBI4wiix+fEJKGcPo8TFPyuZIZxtjBLzd/8EynBw8ApoS8ydKg3S zSKgKrH7/3OwSWxAUzfs/MwEYosKhEn0vj7HCGLzCghKnJz5hAXEFhHQlfh7eC9YnFlAQeLN nS/sILawgJFE46VdYLaQQKHEyTm32UBsTgFbiatPtzFCXCopseVFOztEr57ElKstUHPkJba/ ncMM0aspsXXNd9YJjMKzkKyehaRlFpKWBYzMqxg5SotTy3LTjQw3MQKD+JgEm+MOxgWfLA8x SnOwKInzhrpeCBASSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAeNjwxZM9t76c1PtZVr3kmHr6 Gi8zB8VFVfqmi5exrSp6xmSbf/T5vPrbLdnrQ6fNXPfrwNujrQdOik1Y81u6gvO59sqe3PUW gSf41B1UXHZfjTy1bOVE98lJc+9u/5U9Q25x4jNv5h09Byecu/76+Uq9Zas/yp32q5oTt7R4 R3yUoqxBaKNIBbsSS3FGoqEWc1FxIgCIQ0dcMAIAAA== Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 15:27:16 -0000 Hi Iljitsch, Thanks for writing this draft. I believe that it is very useful. I just had a couple of minor comments (on draft -01) that you may want to address. * Section 3.5 I think a short summary of 6to4 Provider Managed Tunnels (RFC6732) would be useful here for completeness. * Section 3.8 "Teredo is specified in [RFC4380] and a few updates" I think the security updates in RFC5991 are probably worth mentioning here. "This process is not sufficiently reliable; Teredo fails in about 37% [TERTST] of its attempts to connect to native IPv6 destinations." In this context it is probably useful to say that there are some extensions to Teredo that significantly decrease the failure rate. Please see RFC6081. * Section 6.2 As mentioned in Section 3.5, the table needs to be updated to include ISP in the 6to4 row (RFC6732) Cheers Suresh On 02/15/2013 03:44 AM, Iljitsch van Beijnum wrote: > Hi all, > > Three of us were asked by the Dutch academic network Surfnet to write an overview of IPv6-in-IPv4 tunneling mechanisms. To benefit the wider community, we did so in the form of a draft, that we intend to submit to the RFC Editor as an independent submission. > > However, we would very much appreciate reviews and comments from within the IETF. These are the mechanisms we discuss: > > 3. Tunnel Mechanisms . . . . . . . . . . . . . . . . . . . . . . 5 > 3.1. Configured Tunnels (Manual Tunnels / 6in4) . . . . . . . . 6 > 3.2. Automatic Tunneling . . . . . . . . . . . . . . . . . . . 7 > 3.3. IPv6 over IPv4 without Explicit Tunnels (6over4) . . . . . 8 > 3.4. Generic Routing Encapsulation (GRE) . . . . . . . . . . . 9 > 3.5. Connection of IPv6 Domains via IPv4 Clouds (6to4) . . . . 9 > 3.6. Anything In Anything (AYIYA) . . . . . . . . . . . . . . . 10 > 3.7. Intra-site Automatic Tunnel Addressing (ISATAP) . . . . . 11 > 3.8. Tunneling IPv6 over UDP through NATs (Teredo) . . . . . . 12 > 3.9. IPv6 Rapid Deployment (6rd) . . . . . . . . . . . . . . . 13 > 3.10. Native IPv6 behind NAT44 CPEs (6a44) . . . . . . . . . . . 14 > 3.11. Peer-to-Peer IPv6 on Any Internetwork (6bed4) . . . . . . 15 > 3.12. The Locator/ID Separation Protocol (LISP) . . . . . . . . 16 > 4. Related Protocols . . . . . . . . . . . . . . . . . . . . . . 17 > 4.1. Tunnel Information and Control protocol (TIC) . . . . . . 17 > 4.2. Tunnel Setup Protocol (TSP) . . . . . . . . . . . . . . . 18 > 4.3. Dual-Stack Lite (Softwire) . . . . . . . . . . . . . . . . 19 > > Thanks! > > Iljitsch > > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Subject: I-D Action: draft-steffann-tunnels-00.txt >> Date: 15 februari 2013 9:34:07 CET >> To: i-d-announce@ietf.org >> Reply-To: internet-drafts@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : A comparison of IPv6 tunneling mechanisms >> Author(s) : S.J.M. Steffann >> Iljitsch van Beijnum >> Rick van Rein >> Filename : draft-steffann-tunnels-00.txt >> Pages : 37 >> Date : 2013-02-15 >> >> Abstract: >> This document provides an overview of various ways to to tunnel IPv6 >> packets over IPv4 networks. It covers mechanisms in contemporary >> use, touches on several mechanisms that are now only of historic >> interest, and discusses some newer tunneling mechanisms that are not >> (yet) widely used at the time of publication. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-steffann-tunnels >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-steffann-tunnels-00 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From alexandru.petrescu@gmail.com Fri Mar 22 09:31:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7286021F8F08 for ; Fri, 22 Mar 2013 09:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.576 X-Spam-Level: X-Spam-Status: No, score=-9.576 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_38=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZE9QfNEzo0h for ; Fri, 22 Mar 2013 09:31:11 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id D9E7921F8E79 for ; Fri, 22 Mar 2013 09:31:10 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2MGV6dx024845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Mar 2013 17:31:06 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2MGV6mc004995; Fri, 22 Mar 2013 17:31:06 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2MGV2i8001123; Fri, 22 Mar 2013 17:31:06 +0100 Message-ID: <514C8719.7000004@gmail.com> Date: Fri, 22 Mar 2013 17:30:17 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Owen DeLong References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> In-Reply-To: <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 16:31:12 -0000 Le 21/03/2013 20:34, Owen DeLong a écrit : >>> RA is not forbidden. Default route via RA is forbidden. RIO via >>> RA is perfectly fine. >> >> But, the CPE rfcbis says that the Router Lifetime must not be >> greater than 0. There is no other way in which an RA can tell a >> Host it's a default router than setting that lifetime to greater >> than 0. > > If the router doesn't provide internet access, it SHOULD NOT > advertise itself as a default router. That is the point. I shared that view at some point, but I changed. The meaning of 'default' route is not necessarily Internet. It means to be used when everything else fails, that's all. It is also a high-availability feature - absence of a default route means the system is less reliable. One _wants_ a default option whenever one does something with multiple choice. There are many other networks using default routes and which don't finally lead to Internet, now. They will but later. > You are determined to argue against that point, but the correct > behavior is to NOT BE a default router if you do not provide > internet access. The default route could also lead to a certain path which is longer than the shortest path to the Internet. This is built in some protocols to which nobody seems to object. The alternatives to avoid that ('Route Optimization' == default route point to the shortest path to the Internet) don't have much tract in the Internet itself - people won't modify every other stack to make sure the default route is the shortest path to the Internet - they accept if it leads _somehow_ to the Internet. Given that, I doubt one could say 'default route==Internet'. >> Or am I missing something? > > Yes… You are missing the fact that a collection of networks not > attached to the internet using ULA should use more specifics and not > default routes. That specific routes will stop these networks from growing large. >> (this is for curiosity only - as long as it stays as a CPE matter >> this may not be that important to other contexts). > > It is, actually, because you can't tell at manufacture time how a > router will be used, so you have to consider all possible use > contexts of the router when deciding how it should behave, and > especially how it should behave by default. > >> >>>>> It can still advertise an OSPF default, BGP default, and/or >>>>> participate in VRRP. >>>> >>>> Ok - none is implemented by a Smartphone. >>> >>> Who cares? If you use VRRP, the smartphone doesn't have to >>> implement it. The smart phone can be given a static default to >>> the VRRP address. >> >> Oh... but such advice may read to non-CPE operators (e.g. cellular >> operators) that any other typical IPv6 parameter could be >> hardcoded to a certain VRRP'ed address. Read - smartphones >> hardcoded with the IPv6 DNS Resolver address, because many reasons >> and the above included. >> >> Clearly this should stay CPE. > > We're not talking about hard coding anything. We're talking about > static configuration. > > I don't know about smart phones in general, but I do know that > whatever I statically configure into my phone is specific to a given > connection, e.g. part of the definition for a particular wifi SSID, > etc. > > Phones can have different "personalities" to provide different sets > of parameters and static settings for different operational > contexts. I am talking about operators who hardcode - pre-configure - the DNS Resolver IPv6 address in each smartphone sold out, instead of automating that configuration with things like DHCP or RA. I complain about that. (I have nothing against a geeky person personalizing her smartphone with google's DNS Resolver IPv6 address, instead of the one given by the operator). >>> Ideally, we fix DHCPv6 and add the ability to provide routing >>> information options in DHCPv6 as well. >> >> That sounds like a good idea - it deserves a separate thread. I >> think that coupling address auto-configuration with routing is >> desirable. > > tt has a separate thread. What is tt? >> I am not sure whether you are aware, but the DHCPv6 route-options >> discussions is stalled right now. There are few private emails and >> maybe an email list would get set up about DHCPv6 and >> route-options: route-options, src-based routing and why not >> defrouter. >> >> Or maybe we should discuss it here as well. >> > > No, we really shouldn't. At least not as part of this thread. Yes, I > am aware of the situation with DHCPv6 routing options. My point isn't > to rehash that discussion here (which I don't think most list > participants would appreciate), but to point out that the correct > place to solve certain problems is somewhere other than in this > thread. > >>>>> We should, in all cases, avoid doing things that are >>>>> damaging to GUA-based installations for the sake of making >>>>> ULA work better for fringe cases. >>>> >>>> That is the first worry - right! First, do no harm to GUA. But >>>> I am optimistic because I see much hard work done to avoid >>>> harming GUA. >>> >>> Or we could use GUA and avoid all the hard work and the harm. >> >> YEs maybe; but GUA in vehicular moving networks and without Home >> Agent can not work. >> > > Why does "without home agent" suddenly come into play? Because that's how the planes Connexion did - without Home Agent, at a certain experiment. (I think at some point also used HA, but the BGP version may be without HA - HA is a MIP entity, BGP doesnt have HA). Because some deployments of planes and other vehicles seem to not use HA. I'll post separately. > You still are missing the point. If I use unrouted prefix > 2001:1610:53ac::/48 in the vehicles in the exact same manner as I > would use unrouted prefix fd01:9c83:1ac0::/48, then there is no > difference in the behavior or the impact of the two prefixes. There is some difference - with ULA prefix fd01:9c83:1ac0::/48 we _could_ define a border precisely (tell who's the BR and what's the generation algorithm). With GUA 2001:1610:53ac::/48 we can't do it. > There is no change in the strain on the routing system. I agree. That also means that there is no advantage on using GUA instead of ULA in a vehicle. The only reason we had to use GUA was if we could have done route injection (BGP, etc.) from each vehicle to the Internet. It may be possible for planes, but impossible for vehicles for several reasons - not the least being that a vehicle connects often with cellular and cellular operators won't accept BGP from their UE clients. > There is no problem caused for anyone. The two prefixes have > identical semantics and usage and identical impact on the routing > table. Well I guess one would be allowed to inject GUA PI prefixes with BGP from a plane, but would not be allowed to inject ULA prefixes with BGP from the same plane. >> Killing ULA and requesting GUA without a HA may lead to NAT66 as >> well, which is supposedly another evil. > > How does GUA require NAT66 where ULA would not? You make no sense > here. Well, if a vehicle can't use ULA then a vehicle must use GUA prefix within. Maybe provider-independent GUA, or maybe provider-assigned GUA. Then one is not allowed to inject the prefix at the attachment point. So one has to use a Home Agent. But there are people who think a Home Agent is a single-point of failure (all vehicles must tunnel to that HA, otherwise no Internet - if HA down then vehicles cant talk to Internet; and second - routes are artificially long, the default route points to the HA even though the Server of the vehicle is quite near - this is quantified problem). At that point - if no ULA and no HA possible then one still needs to put some addresses in that vehicle. And the most straightforward way to do that is NAT66 (ip6tables MASQUERADE kernel 3.something ok). That is independent of the kind of addresses within the vehicle - works with fd::1/64 as well. If one does that NAT66 then one reaches Internet straight - no artificially long paths, no single point of failure HA, no ULA vs GUA problem. The one thing that could be against NAT66 is the typical anti-NAT argument - reverse reachability. But many apps in the vehicle today are very exciting yet dont require that reverse reachability. Other arguments may exist. So, if one would like to avoid NAT then one better allows ULAs... (rather than forbidding them). But let me ask one the following - suppose one grandma private person ambitions to connect her own automobile to IPv6, without the participation of the vehicle manufacturer and cell network in that endeavor; the cell network simply provides a full IPv6 cellular connection. What addressing scheme would she use within the vehicle? >> I will not he unhappy if the recommendation is GUA+MobileIP but >> there are people who claim HA is a single point of failure. > > You are assuming that all GUA must be globally routed. I'm talking > about using GUA prefixes exactly as one would use ULA. At that point it is ok, but it implies several things. First, one uses GUA in a vehicle but knows somehow they shouldn't be routed to the Internet. No RFC tells that, the person just knows. I doubt it possible. Second, if one day one should connect that vehicle to the Internet, then one would supposedly need _another_ set of GUA which _should_ be routed to the Internet, typically with the help of the Home Agent. At that point one may end up with two different sets of GUAs in the same vehicle - one for non-Internet connection, and the other full Internet connection. This means that each PC in the vehicle has at least two addresses (not to mention the link-local and privacy extensions one). This brings in the src-based routing problem, or the src address selection problem. These src-based aspects are easier to describe if we talked ULA and GUA, as opposed to talking GUA1 and GUA2. It's easier to say - if the src address is ULA then do this, and if it's GUA then do that. Otherwise we'd have to say if src is a GUA which is forbidden to be put on the Internet do this, otherwise do that. > I'm not necessarily talking about providing them with global > reachability or anything else that they would not get with ULA. I'm > just talking about the fact that for private use on a disconnected > network, there is no actual technical advantage to ULA vs. GUA. I can agree to that. That doesn't mean ULA is not useful. Alex > > Owen > > > From brian.e.carpenter@gmail.com Fri Mar 22 09:46:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2909121F8E0F for ; Fri, 22 Mar 2013 09:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.734 X-Spam-Level: X-Spam-Status: No, score=-98.734 tagged_above=-999 required=5 tests=[AWL=-1.012, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, J_CHICKENPOX_13=0.6, J_CHICKENPOX_42=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 DdpiSoGV3JaE for ; Fri, 22 Mar 2013 09:46:05 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id AB01D21F8DDC for ; Fri, 22 Mar 2013 09:46:04 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hr17so899744wib.11 for ; Fri, 22 Mar 2013 09:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9azMwMrMIRJMkQBgz6OfFHD4c6dkUl1A/4SmANEOvHA=; b=qbDq8ox6VgS4SERtZVBRrvm0BuPYoqewz8vz59MSRPBloxtewf58cX0W+tyFePxu/F HGEAV+A8/4q9vvEwriR7jk/oMpfviGK1G42W5cP813xKl3RWQVcA/cTyt8t5Pb03cV2K VwezhMdb9svlFXxpENsRJ5bzYl3tic9JVJA6kw75qk9qf32TJ0HrGLA1xjGNW+5eVCq2 gTLg/UpdZL2YPccgKHA7ZCljnOuL9vLqc6tkePBAZOrTbQcnkhx99d0vuK6SfhJY3BiX N5gp/iHD8sd5KyF3HVfN7z3xzZo07SGoxmMfTed7VGqXGYiRo5qY+27ufr8ZEk7A3URG S2VA== X-Received: by 10.181.12.103 with SMTP id ep7mr12622369wid.12.1363970763723; Fri, 22 Mar 2013 09:46:03 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-189-72.as13285.net. [2.101.189.72]) by mx.google.com with ESMTPS id dm9sm11956463wib.3.2013.03.22.09.46.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Mar 2013 09:46:02 -0700 (PDT) Message-ID: <514C8AD8.8030705@gmail.com> Date: Fri, 22 Mar 2013 16:46:16 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> <514C8719.7000004@gmail.com> In-Reply-To: <514C8719.7000004@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 16:46:06 -0000 On 22/03/2013 16:30, Alexandru Petrescu wrote: > Le 21/03/2013 20:34, Owen DeLong a =C3=A9crit : >>>> RA is not forbidden. Default route via RA is forbidden. RIO via >>>> RA is perfectly fine. >>> >>> But, the CPE rfcbis says that the Router Lifetime must not be >>> greater than 0. There is no other way in which an RA can tell a >>> Host it's a default router than setting that lifetime to greater >>> than 0. >> >> If the router doesn't provide internet access, it SHOULD NOT >> advertise itself as a default router. That is the point. >=20 > I shared that view at some point, but I changed. >=20 > The meaning of 'default' route is not necessarily Internet. It means t= o > be used when everything else fails, that's all. It is also a > high-availability feature - absence of a default route means the system= > is less reliable. One _wants_ a default option whenever one does > something with multiple choice. As I've said since the beginning of MIF, a host needs a default route per source prefix. I think you'll find that solves the dilemma. Brian >=20 > There are many other networks using default routes and which don't > finally lead to Internet, now. They will but later. >=20 >> You are determined to argue against that point, but the correct >> behavior is to NOT BE a default router if you do not provide >> internet access. >=20 > The default route could also lead to a certain path which is longer tha= n > the shortest path to the Internet. This is built in some protocols to > which nobody seems to object. >=20 > The alternatives to avoid that ('Route Optimization' =3D=3D default rou= te > point to the shortest path to the Internet) don't have much tract in th= e > Internet itself - people won't modify every other stack to make sure th= e > default route is the shortest path to the Internet - they accept if it > leads _somehow_ to the Internet. >=20 > Given that, I doubt one could say 'default route=3D=3DInternet'. >=20 >>> Or am I missing something? >> >> Yes=E2=80=A6 You are missing the fact that a collection of networks no= t >> attached to the internet using ULA should use more specifics and not >> default routes. >=20 > That specific routes will stop these networks from growing large. >=20 >>> (this is for curiosity only - as long as it stays as a CPE matter >>> this may not be that important to other contexts). >> >> It is, actually, because you can't tell at manufacture time how a >> router will be used, so you have to consider all possible use >> contexts of the router when deciding how it should behave, and >> especially how it should behave by default. >> >>> >>>>>> It can still advertise an OSPF default, BGP default, and/or >>>>>> participate in VRRP. >>>>> >>>>> Ok - none is implemented by a Smartphone. >>>> >>>> Who cares? If you use VRRP, the smartphone doesn't have to >>>> implement it. The smart phone can be given a static default to >>>> the VRRP address. >>> >>> Oh... but such advice may read to non-CPE operators (e.g. cellular >>> operators) that any other typical IPv6 parameter could be >>> hardcoded to a certain VRRP'ed address. Read - smartphones >>> hardcoded with the IPv6 DNS Resolver address, because many reasons >>> and the above included. >>> >>> Clearly this should stay CPE. >> >> We're not talking about hard coding anything. We're talking about >> static configuration. >> >> I don't know about smart phones in general, but I do know that >> whatever I statically configure into my phone is specific to a given >> connection, e.g. part of the definition for a particular wifi SSID, >> etc. >> >> Phones can have different "personalities" to provide different sets >> of parameters and static settings for different operational >> contexts. >=20 > I am talking about operators who hardcode - pre-configure - the DNS > Resolver IPv6 address in each smartphone sold out, instead of automatin= g > that configuration with things like DHCP or RA. I complain about that.= >=20 > (I have nothing against a geeky person personalizing her smartphone wit= h > google's DNS Resolver IPv6 address, instead of the one given by the > operator). >=20 >>>> Ideally, we fix DHCPv6 and add the ability to provide routing >>>> information options in DHCPv6 as well. >>> >>> That sounds like a good idea - it deserves a separate thread. I >>> think that coupling address auto-configuration with routing is >>> desirable. >> >> tt has a separate thread. >=20 > What is tt? >=20 >>> I am not sure whether you are aware, but the DHCPv6 route-options >>> discussions is stalled right now. There are few private emails and >>> maybe an email list would get set up about DHCPv6 and >>> route-options: route-options, src-based routing and why not >>> defrouter. >>> >>> Or maybe we should discuss it here as well. >>> >> >> No, we really shouldn't. At least not as part of this thread. Yes, I >> am aware of the situation with DHCPv6 routing options. My point isn't >> to rehash that discussion here (which I don't think most list >> participants would appreciate), but to point out that the correct >> place to solve certain problems is somewhere other than in this >> thread. >> >>>>>> We should, in all cases, avoid doing things that are >>>>>> damaging to GUA-based installations for the sake of making >>>>>> ULA work better for fringe cases. >>>>> >>>>> That is the first worry - right! First, do no harm to GUA. But >>>>> I am optimistic because I see much hard work done to avoid >>>>> harming GUA. >>>> >>>> Or we could use GUA and avoid all the hard work and the harm. >>> >>> YEs maybe; but GUA in vehicular moving networks and without Home >>> Agent can not work. >>> >> >> Why does "without home agent" suddenly come into play? >=20 > Because that's how the planes Connexion did - without Home Agent, at a > certain experiment. (I think at some point also used HA, but the BGP > version may be without HA - HA is a MIP entity, BGP doesnt have HA). >=20 > Because some deployments of planes and other vehicles seem to not use > HA. I'll post separately. >=20 >> You still are missing the point. If I use unrouted prefix >> 2001:1610:53ac::/48 in the vehicles in the exact same manner as I >> would use unrouted prefix fd01:9c83:1ac0::/48, then there is no >> difference in the behavior or the impact of the two prefixes. >=20 > There is some difference - with ULA prefix fd01:9c83:1ac0::/48 we > _could_ define a border precisely (tell who's the BR and what's the > generation algorithm). With GUA 2001:1610:53ac::/48 we can't do it. >=20 >> There is no change in the strain on the routing system. >=20 > I agree. >=20 > That also means that there is no advantage on using GUA instead of ULA > in a vehicle. The only reason we had to use GUA was if we could have > done route injection (BGP, etc.) from each vehicle to the Internet. It= > may be possible for planes, but impossible for vehicles for several > reasons - not the least being that a vehicle connects often with > cellular and cellular operators won't accept BGP from their UE clients.= >=20 >> There is no problem caused for anyone. The two prefixes have >> identical semantics and usage and identical impact on the routing >> table. >=20 > Well I guess one would be allowed to inject GUA PI prefixes with BGP > from a plane, but would not be allowed to inject ULA prefixes with BGP > from the same plane. >=20 >>> Killing ULA and requesting GUA without a HA may lead to NAT66 as >>> well, which is supposedly another evil. >> >> How does GUA require NAT66 where ULA would not? You make no sense >> here. >=20 > Well, if a vehicle can't use ULA then a vehicle must use GUA prefix > within. Maybe provider-independent GUA, or maybe provider-assigned GUA= =2E > Then one is not allowed to inject the prefix at the attachment point. > So one has to use a Home Agent. >=20 > But there are people who think a Home Agent is a single-point of failur= e > (all vehicles must tunnel to that HA, otherwise no Internet - if HA dow= n > then vehicles cant talk to Internet; and second - routes are > artificially long, the default route points to the HA even though the > Server of the vehicle is quite near - this is quantified problem). >=20 > At that point - if no ULA and no HA possible then one still needs to pu= t > some addresses in that vehicle. And the most straightforward way to do= > that is NAT66 (ip6tables MASQUERADE kernel 3.something ok). That is > independent of the kind of addresses within the vehicle - works with > fd::1/64 as well. >=20 > If one does that NAT66 then one reaches Internet straight - no > artificially long paths, no single point of failure HA, no ULA vs GUA > problem. >=20 > The one thing that could be against NAT66 is the typical anti-NAT > argument - reverse reachability. But many apps in the vehicle today ar= e > very exciting yet dont require that reverse reachability. Other > arguments may exist. >=20 > So, if one would like to avoid NAT then one better allows ULAs... > (rather than forbidding them). >=20 > But let me ask one the following - suppose one grandma private person > ambitions to connect her own automobile to IPv6, without the > participation of the vehicle manufacturer and cell network in that > endeavor; the cell network simply provides a full IPv6 cellular > connection. What addressing scheme would she use within the vehicle? >=20 >>> I will not he unhappy if the recommendation is GUA+MobileIP but >>> there are people who claim HA is a single point of failure. >> >> You are assuming that all GUA must be globally routed. I'm talking >> about using GUA prefixes exactly as one would use ULA. >=20 > At that point it is ok, but it implies several things. >=20 > First, one uses GUA in a vehicle but knows somehow they shouldn't be > routed to the Internet. No RFC tells that, the person just knows. I > doubt it possible. >=20 > Second, if one day one should connect that vehicle to the Internet, the= n > one would supposedly need _another_ set of GUA which _should_ be routed= > to the Internet, typically with the help of the Home Agent. >=20 > At that point one may end up with two different sets of GUAs in the sam= e > vehicle - one for non-Internet connection, and the other full Internet > connection. This means that each PC in the vehicle has at least two > addresses (not to mention the link-local and privacy extensions one). > This brings in the src-based routing problem, or the src address > selection problem. >=20 > These src-based aspects are easier to describe if we talked ULA and GUA= , > as opposed to talking GUA1 and GUA2. >=20 > It's easier to say - if the src address is ULA then do this, and if it'= s > GUA then do that. Otherwise we'd have to say if src is a GUA which is > forbidden to be put on the Internet do this, otherwise do that. >=20 >> I'm not necessarily talking about providing them with global >> reachability or anything else that they would not get with ULA. I'm >> just talking about the fact that for private use on a disconnected >> network, there is no actual technical advantage to ULA vs. GUA. >=20 > I can agree to that. >=20 > That doesn't mean ULA is not useful. >=20 > Alex >=20 >> >> Owen >> >> >> >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From fgont@si6networks.com Fri Mar 22 10:23:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A81521F8DD6 for ; Fri, 22 Mar 2013 10:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFfigMX3-L4L for ; Fri, 22 Mar 2013 10:23:38 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id CF0F021F8DCF for ; Fri, 22 Mar 2013 10:23:36 -0700 (PDT) Received: from [2001:5c0:1000:a::88b] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UJ5gh-0007YP-RT; Fri, 22 Mar 2013 18:23:32 +0100 Message-ID: <514C938C.5030104@si6networks.com> Date: Fri, 22 Mar 2013 14:23:24 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Lorenzo Colitti References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <51425EB5.6040703@dougbarton.us> <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 17:23:42 -0000 On 03/21/2013 05:41 AM, Lorenzo Colitti wrote: > On Wed, Mar 20, 2013 at 8:01 PM, Mark Smith > wrote: > > Yes. Their IPv6 router will generate an ICMPv6 destination > unreachable as it doesn't have a route matching the AAAA (i.e. a > default route). That will cause the browser to fall back to IPv4. > > > Incorrect. RFC 1122, section 4.2.3.9 : "Since these > Unreachable messages indicate soft error conditions, TCP MUST NOT abort > the connection". You should be looking at RFC 5461. And if you wonder why RFC 5461 doesn't formally update the specs, my answer would be "politics!". Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From owen@delong.com Fri Mar 22 11:31:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB88521F8FFB for ; Fri, 22 Mar 2013 11:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.698, 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 gGbo-jI-OrUH for ; Fri, 22 Mar 2013 11:31:14 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7359921F8FDC for ; Fri, 22 Mar 2013 11:31:08 -0700 (PDT) Received: from [172.20.10.2] (29.sub-70-198-3.myvzw.com [70.198.3.29]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2MIUftL022411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 Mar 2013 11:30:48 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2MIUftL022411 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363977051; bh=bS9u34raSZ09QmbaRSzak+YsLRQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=yKjuQgDDDfSojQV7Vl7X0aLsmQfzesPcDglDn/zi8MQxDS+dS8CyXtzL+fPs1Z6jN frkOL27e2EDgI1/N6U+NpGpGCbVJfvJELcE2QCPR2bL7kfDgl6x1WcFzexef8JcjKy OcupGKehc0YDU9+cgpqmlO368gGx/20oBn5hk/pk= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: <514C8AD8.8030705@gmail.com> Date: Fri, 22 Mar 2013 13:30:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <722D9250-6C69-4D87-88D1-4014F340CBAB@delong.com> References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> <514C8719.7000004@gmail.com> <514C8AD8.8! 030705@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 22 Mar 2013 11:30:51 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 18:31:19 -0000 On Mar 22, 2013, at 11:46 AM, Brian E Carpenter = wrote: > On 22/03/2013 16:30, Alexandru Petrescu wrote: >> Le 21/03/2013 20:34, Owen DeLong a =E9crit : >>>>> RA is not forbidden. Default route via RA is forbidden. RIO via >>>>> RA is perfectly fine. >>>>=20 >>>> But, the CPE rfcbis says that the Router Lifetime must not be >>>> greater than 0. There is no other way in which an RA can tell a >>>> Host it's a default router than setting that lifetime to greater >>>> than 0. >>>=20 >>> If the router doesn't provide internet access, it SHOULD NOT >>> advertise itself as a default router. That is the point. >>=20 >> I shared that view at some point, but I changed. >>=20 >> The meaning of 'default' route is not necessarily Internet. It means = to >> be used when everything else fails, that's all. It is also a >> high-availability feature - absence of a default route means the = system >> is less reliable. One _wants_ a default option whenever one does >> something with multiple choice. >=20 > As I've said since the beginning of MIF, a host needs a default route > per source prefix. I think you'll find that solves the dilemma. No, it really doesn't. In fact, I would say that may well cause more = problems than it solves. Bottom line is that you should only provide a default route if you can = reasonably expect to forward all traffic received via that default = route. Otherwise, you are creating a black hole. Routes are destination based, not source based, so a default route = (route to everywhere on the internet) indicates that the next hop = gateway has announced its intention to forward all traffic to any = destination. A router which has only ULA prefixes is utterly incapable of doing = anything remotely resembling that, so it should not make a claim that it = can in its RAs. Owen From swmike@swm.pp.se Fri Mar 22 11:53:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879F121F8DF0 for ; Fri, 22 Mar 2013 11:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, 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 bqy8e-DkNlik for ; Fri, 22 Mar 2013 11:53:05 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id DA53A21F900D for ; Fri, 22 Mar 2013 11:53:04 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 065309C; Fri, 22 Mar 2013 19:53:04 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 001A09A; Fri, 22 Mar 2013 19:53:03 +0100 (CET) Date: Fri, 22 Mar 2013 19:53:03 +0100 (CET) From: Mikael Abrahamsson To: Owen DeLong In-Reply-To: <722D9250-6C69-4D87-88D1-4014F340CBAB@delong.com> Message-ID: References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> <514C8719.7000004@gmail.com> <514C8AD8.8! 030705@gmail.com> <722D9250-6C69-4D87-88D1-4014F340CBAB@delong.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 18:53:05 -0000 On Fri, 22 Mar 2013, Owen DeLong wrote: > Routes are destination based, not source based, so a default route > (route to everywhere on the internet) indicates that the next hop > gateway has announced its intention to forward all traffic to any > destination. I don't agree at all. A router will indicate to forward some traffic, some other might be dropped by uRPF upstream. So a default route should be coupled with whatever was provisioned by that router (ok, so I announced RA for a /64 prefix and default route, then this default route is only valid for that prefix). I believe IPv6 was wrongly designed from the get-go in this aspect. Routing information and prefix annuncement should be coupled together, not separately. So src, dst and routing should belong together instead of being treated as separate the way it's done right now with routing, RA prefix announcement and address selection being completely separate entities. > A router which has only ULA prefixes is utterly incapable of doing > anything remotely resembling that, so it should not make a claim that it > can in its RAs. Well, this I can agree with though. I also believe RIOs should be scoped, so basically a RIO should also have a source prefix in it's announcement. Src, dst, route. Together. This way a RIO could indicate that ULA should communicate with ULA and nothing else. If you don't have a ULA address, you can't send packet to ULA destinations. -- Mikael Abrahamsson email: swmike@swm.pp.se From rajiva@cisco.com Fri Mar 22 12:01:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DB521F9091 for ; Fri, 22 Mar 2013 12:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EG-woWvrKwIO for ; Fri, 22 Mar 2013 12:01:41 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3A621F9079 for ; Fri, 22 Mar 2013 12:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3249; q=dns/txt; s=iport; t=1363978895; x=1365188495; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=QfYUc6bHQSGzKtC8kdIFyo2fQXqLoK/kaaOynRglGUw=; b=kB+2wmYaYGNI0NjKCtHbI0wlvRWlmrD7ymgDlLaOf+hZ5hF+LaiDxo2B f4AoPi7uUB/F0qj5oHwZyx7VH0chhR9sYbMz5ufrMUfCfuyNjv+Z2b35j 2inzXMw73/CacQ050GvXQoTej2NACS1pLFmywN1cQuSUYOTdi2fMyJPh5 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFADWpTFGtJXG+/2dsb2JhbABDxVWBZRZ0giQBAQEDAQEBAWsLBQcGAQgRAwECAQpFBgsdCAIEAQ0FCId6AwkGDLgnDYlbjEiCGSYLBwaCWWEDiD+MRYJ/ikqFG4MKgig X-IronPort-AV: E=Sophos;i="4.84,893,1355097600"; d="scan'208";a="190507615" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 22 Mar 2013 19:01:34 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2MJ1YoD029429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Mar 2013 19:01:34 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.72]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 14:01:34 -0500 From: "Rajiv Asati (rajiva)" To: Owen DeLong , Brian E Carpenter Thread-Topic: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) Thread-Index: AQHOJy+r9P0kqx0nzEanBc+mLgpeHA== Date: Fri, 22 Mar 2013 19:01:33 +0000 Message-ID: In-Reply-To: <722D9250-6C69-4D87-88D1-4014F340CBAB@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.82.227.67] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 19:01:42 -0000 > Routes are destination based, not source based, so a default route >(route to This is not true, strictly speaking, although most router implementations look at only the destination IP header for deciding the next-hop in case of unicast IP traffic. This is what we tend to refer to as the "Destination based routing". Routers can be implemented to look at the source IP header or both source and destination IP headers for deciding the next-hop. Heck, routers can be implemented to look at other fields (e.g. DSCP) in the IP header or not even look at the IP header (and just look at the MPLS header). http://tools.ietf.org/html/rfc791 // gateways in the internet system. The datagrams are routed from one internet module to another through individual networks based on the interpretation of an internet address. Thus, one important mechanism // Cheers, Rajiv -----Original Message----- From: Owen DeLong Date: Friday, March 22, 2013 2:30 PM To: Brian Carpenter Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) > >On Mar 22, 2013, at 11:46 AM, Brian E Carpenter > wrote: > >> On 22/03/2013 16:30, Alexandru Petrescu wrote: >>> Le 21/03/2013 20:34, Owen DeLong a =E9crit : >>>>>> RA is not forbidden. Default route via RA is forbidden. RIO via >>>>>> RA is perfectly fine. >>>>>=20 >>>>> But, the CPE rfcbis says that the Router Lifetime must not be >>>>> greater than 0. There is no other way in which an RA can tell a >>>>> Host it's a default router than setting that lifetime to greater >>>>> than 0. >>>>=20 >>>> If the router doesn't provide internet access, it SHOULD NOT >>>> advertise itself as a default router. That is the point. >>>=20 >>> I shared that view at some point, but I changed. >>>=20 >>> The meaning of 'default' route is not necessarily Internet. It means >>>to >>> be used when everything else fails, that's all. It is also a >>> high-availability feature - absence of a default route means the system >>> is less reliable. One _wants_ a default option whenever one does >>> something with multiple choice. >>=20 >> As I've said since the beginning of MIF, a host needs a default route >> per source prefix. I think you'll find that solves the dilemma. > >No, it really doesn't. In fact, I would say that may well cause more >problems than it solves. > >Bottom line is that you should only provide a default route if you can >reasonably expect to forward all traffic received via that default route. >Otherwise, you are creating a black hole. > >Routes are destination based, not source based, so a default route (route >to everywhere on the internet) indicates that the next hop gateway has >announced its intention to forward all traffic to any destination. > >A router which has only ULA prefixes is utterly incapable of doing >anything remotely resembling that, so it should not make a claim that it >can in its RAs. > >Owen > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From owen@delong.com Fri Mar 22 13:11:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5601C21F9138 for ; Fri, 22 Mar 2013 13:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=0.523, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaf3jYASNz78 for ; Fri, 22 Mar 2013 13:11:32 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D09D321F913D for ; Fri, 22 Mar 2013 13:11:23 -0700 (PDT) Received: from [172.20.10.2] (29.sub-70-198-3.myvzw.com [70.198.3.29]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2MKAl3M026697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 Mar 2013 13:10:52 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2MKAl3M026697 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1363983055; bh=Xl6PTFYNKOA1zfdC5A6t9u42Vio=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=SMgqBuBDZHu23Bgg6oX3WHYqlWnn0f0iPGi8TZr089vD9R7H5/ffq91RCZu/sqZun 0/zAY24xM2WOOVye3BfydCxeG/h17LmEIo83ObMNwlXBr01cAq3tO5z2WopSxGl8+6 BfKFyw8fR9Sgw1vYRKV1SJ1NiU9LEx22TWYbislA= Content-Type: multipart/alternative; boundary="Apple-Mail=_3F844D68-2DB7-4579-884C-56903B631B96" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: Date: Fri, 22 Mar 2013 15:10:47 -0500 Message-Id: References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> <514C8719.7000004@gmail.com> <514C8AD8.8! 030705@gmail.com> <722D9250-6C69-4D87-88D1-4014F340CBAB@delong.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 22 Mar 2013 13:10:55 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 20:11:33 -0000 --Apple-Mail=_3F844D68-2DB7-4579-884C-56903B631B96 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 22, 2013, at 1:53 PM, Mikael Abrahamsson = wrote: > On Fri, 22 Mar 2013, Owen DeLong wrote: >=20 >> Routes are destination based, not source based, so a default route = (route to everywhere on the internet) indicates that the next hop = gateway has announced its intention to forward all traffic to any = destination. >=20 > I don't agree at all. A router will indicate to forward some traffic, = some other might be dropped by uRPF upstream. So a default route should = be coupled with whatever was provisioned by that router (ok, so I = announced RA for a /64 prefix and default route, then this default route = is only valid for that prefix). A router and routes are two different things. Here is an example of a = routing table: Routing tables Internet: Destination Gateway Flags Refs Use Netif = Expire default 172.20.10.1 UGSc 25 0 en0 127 127.0.0.1 UCS 0 0 lo0 127.0.0.1 127.0.0.1 UH 2 6150 lo0 169.254 link#4 UCS 0 0 en0 172.20.10/28 link#4 UCS 1 0 en0 172.20.10.1 36:c0:59:97:84:0 UHLWIir 27 96 en0 = 768 172.20.10.2 127.0.0.1 UHS 0 0 lo0 Internet6: Destination Gateway = Flags Netif Expire default fe80::34c0:59ff:fe97:8400%en0 = UGc en0 ::1 link#1 = UHL lo0 2600:1014:b107:3b0::/64 link#4 = UC en0 2600:1014:b107:3b0:1610:9fff:fee3:9417 14:10:9f:e3:94:17 = UHL lo0 2600:1014:b107:3b0:34c0:59ff:fe97:8400 36:c0:59:97:84:0 = UHLWIi en0 2600:1014:b107:3b0:d8a9:c2ee:6fb0:3609 14:10:9f:e3:94:17 = UHL lo0 fd00:6587:52d7::/48 = fd00:6587:52d7:1514:812b:90b3:603e:b815 UGCS utun0 fd00:6587:52d7:1514::/64 fe80::812b:90b3:603e:b815%utun0 = Uc utun0 fd00:6587:52d7:1514:812b:90b3:603e:b815 link#6 = UHL lo0 fdd7:9360:1c6c:b8ef::/64 fe80::812b:90b3:603e:b815%utun1 = Uc utun1 fdd7:9360:1c6c:b8ef:812b:90b3:603e:b815 link#7 = UHL lo0 fe80::%lo0/64 fe80::1%lo0 = UcI lo0 fe80::1%lo0 link#1 = UHLI lo0 fe80::%en0/64 link#4 = UCI en0 fe80::223:12ff:fe55:4329%en0 0:23:12:55:43:29 = UHLWIi en0 fe80::1610:9fff:fee3:9417%en0 14:10:9f:e3:94:17 = UHLI lo0 fe80::34c0:59ff:fe97:8400%en0 36:c0:59:97:84:0 = UHLWIir en0 fe80::7256:81ff:fe88:c16d%en0 70:56:81:88:c1:6d = UHLWIi en0 fe80::daa2:5eff:fe8b:d950%en0 d8:a2:5e:8b:d9:50 = UHLWIi en0 fe80::e6ce:8fff:fe34:b772%en0 e4:ce:8f:34:b7:72 = UHLWIi en0 fe80::%utun0/64 fe80::812b:90b3:603e:b815%utun0 = UcI utun0 fe80::812b:90b3:603e:b815%utun0 link#6 = UHLI lo0 fe80::%utun1/64 fe80::812b:90b3:603e:b815%utun1 = UcI utun1 fe80::812b:90b3:603e:b815%utun1 link#7 = UHLI lo0 ff01::%lo0/32 fe80::1%lo0 = UmCI lo0 ff01::%en0/32 link#4 = UmCI en0 ff01::%utun0/32 fe80::812b:90b3:603e:b815%utun0 = UmCI utun0 ff01::%utun1/32 fe80::812b:90b3:603e:b815%utun1 = UmCI utun1 ff02::%lo0/32 fe80::1%lo0 = UmCI lo0 ff02::%en0/32 link#4 = UmCI en0 ff02::%utun0/32 fe80::812b:90b3:603e:b815%utun0 = UmCI utun0 ff02::%utun1/32 fe80::812b:90b3:603e:b815%utun1 = UmCI utun1 Notice that none of the entries in there contains any mention of source. = They are all Destination, Next Hop, Flags, and (outbound) Interface. RAs can contain multiple prefixes. They do not contain default routes. = The contain a flag that indicates that the router sending the RA is a = candidate default router. > I believe IPv6 was wrongly designed from the get-go in this aspect. = Routing information and prefix annuncement should be coupled together, = not separately. So src, dst and routing should belong together instead = of being treated as separate the way it's done right now with routing, = RA prefix announcement and address selection being completely separate = entities. They really shouldn't. Source-based routing is a hack. It's also known = as "Policy based routing". Users that require such features can = configure them on routers that support them. However, they are not part = of the default way that routing is handled, nor should they be. >> A router which has only ULA prefixes is utterly incapable of doing = anything remotely resembling that, so it should not make a claim that it = can in its RAs. >=20 > Well, this I can agree with though. >=20 > I also believe RIOs should be scoped, so basically a RIO should also = have a source prefix in it's announcement. Src, dst, route. Together. = This way a RIO could indicate that ULA should communicate with ULA and = nothing else. If you don't have a ULA address, you can't send packet to = ULA destinations. There's actually no valid reason to place that limitation on ULA. It is = perfectly valid within the scope of a set of ULA addresses to reach them = from GUA addresses within that routing scope and vice versa. What is not = valid is to expect that ULA addresses are valid for reaching the entire = internet. Baking in the kind of policy-based routing you describe not only into = every host, but into all of the RAs and RIOs would seriously complicate = what was intended to be a simple, lightweight protocol which serves its = purpose very well. ULAs and policy based routing are edge corner cases. We should not look = at complicating and breaking the more general, more widely used, and = more common mechanisms in order to chase after solutions for these = corner cases. Owen --Apple-Mail=_3F844D68-2DB7-4579-884C-56903B631B96 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii swmike@swm.pp.se> = wrote:

On Fri, 22 Mar 2013, Owen DeLong wrote:

Routes are destination based, not source based, so a = default route (route to everywhere on the internet) indicates that the = next hop gateway has announced its intention to forward all traffic to = any destination.

I don't agree at all. A router will = indicate to forward some traffic, some other might be dropped by uRPF = upstream. So a default route should be coupled with whatever was = provisioned by that router (ok, so I announced RA for a /64 prefix and = default route, then this default route is only valid for that = prefix).

A router and routes are two = different things. Here is an example of a routing = table:

Routing = tables

Internet:
Destination        Gateway   =          Flags        Refs =      Use   Netif Expire
default           =  172.20.10.1        UGSc       =     25        0     = en0
127       =          127.0.0.1         =  UCS             0     =    0     lo0
127.0.0.1          127.0.0.1 =          UH           =    2     6150     = lo0
169.254       =      link#4             UCS =             0        0 =     en0
172.20.10/28 =       link#4             = UCS             1       =  0     en0
172.20.10.1        36:c0:59:97:84:0 =   UHLWIir        27       96 =     en0    768
172.20.10.2        127.0.0.1   =        UHS             = 0        0     lo0

Internet6:
Destination             =                 Gateway   =                     =   Flags         Netif = Expire
default     =                     =         fe80::34c0:59ff:fe97:8400%en0   UGc =             en0
::1               =                     =   link#1                 =          UHL           =   lo0
2600:1014:b107:3b0::/64=                 link#4   =                     =    UC             =  en0
2600:1014:b107:3b0:1610:9fff:fee3:9417 =  14:10:9f:e3:94:17               = UHL             lo0
2600:1014:b107:3b0:34c0:59ff:fe97:8400 =  36:c0:59:97:84:0               =  UHLWIi         =  en0
2600:1014:b107:3b0:d8a9:c2ee:6fb0:3609 =  14:10:9f:e3:94:17               = UHL             lo0
fd00:6587:52d7::/48           =           = fd00:6587:52d7:1514:812b:90b3:603e:b815 UGCS         =  utun0
fd00:6587:52d7:1514::/64         =        fe80::812b:90b3:603e:b815%utun0 Uc   =          utun0
fd00:6587:52d7:1514:812b:90b3:603e:b815 link#6   =                     =    UHL             = lo0
fdd7:9360:1c6c:b8ef::/64 =               =  fe80::812b:90b3:603e:b815%utun1 Uc         =    utun1
fdd7:9360:1c6c:b8ef:812b:90b3:603e:b815 link#7   =                     =    UHL             = lo0
fe80::%lo0/64     =                     =   fe80::1%lo0               =       UcI             = lo0
fe80::1%lo0     =                     =     link#1               =            UHLI       =      lo0
fe80::%en0/64             =               link#4     =                     =  UCI             = en0
fe80::223:12ff:fe55:4329%en0 =            0:23:12:55:43:29     =            UHLWIi       =    en0
fe80::1610:9fff:fee3:9417%en0       =     14:10:9f:e3:94:17           =     UHLI           =  lo0
fe80::34c0:59ff:fe97:8400%en0       =     36:c0:59:97:84:0             =    UHLWIir         = en0
fe80::7256:81ff:fe88:c16d%en0 =           70:56:81:88:c1:6d     =           UHLWIi         =  en0
fe80::daa2:5eff:fe8b:d950%en0       =     d8:a2:5e:8b:d9:50           =     UHLWIi         =  en0
fe80::e6ce:8fff:fe34:b772%en0       =     e4:ce:8f:34:b7:72           =     UHLWIi         =  en0
fe80::%utun0/64   =                     =   fe80::812b:90b3:603e:b815%utun0 UcI         =   utun0
fe80::812b:90b3:603e:b815%utun0       =   link#6                 =          UHLI         =    lo0
fe80::%utun1/64 =                     =     fe80::812b:90b3:603e:b815%utun1 UcI       =     utun1
fe80::812b:90b3:603e:b815%utun1       =   link#7                 =          UHLI         =    lo0
ff01::%lo0/32 =                     =       fe80::1%lo0           =           UmCI         =    lo0
ff01::%en0/32 =                     =       link#4             =              UmCI     =        en0
ff01::%utun0/32           =               = fe80::812b:90b3:603e:b815%utun0 UmCI         =  utun0
ff01::%utun1/32 =                     =     fe80::812b:90b3:603e:b815%utun1 UmCI       =    utun1
ff02::%lo0/32 =                     =       fe80::1%lo0           =           UmCI         =    lo0
ff02::%en0/32 =                     =       link#4             =              UmCI     =        en0
ff02::%utun0/32           =               = fe80::812b:90b3:603e:b815%utun0 UmCI         =  utun0
ff02::%utun1/32 =                     =     fe80::812b:90b3:603e:b815%utun1 UmCI       =    utun1

Notice that none of the = entries in there contains any mention of source. They are all = Destination, Next Hop, Flags, and (outbound) = Interface.

RAs can contain multiple prefixes. = They do not contain default routes. The contain a flag that indicates = that the router sending the RA is a candidate default = router.

I believe = IPv6 was wrongly designed from the get-go in this aspect. Routing = information and prefix annuncement should be coupled together, not = separately. So src, dst and routing should belong together instead of = being treated as separate the way it's done right now with routing, RA = prefix announcement and address selection being completely separate = entities.

They really shouldn't. = Source-based routing is a hack. It's also known as "Policy based = routing". Users that require such features can configure them on routers = that support them. However, they are not part of the default way that = routing is handled, nor should they be.

A router which has only ULA = prefixes is utterly incapable of doing anything remotely resembling = that, so it should not make a claim that it can in its = RAs.

Well, this I can agree with though.

I = also believe RIOs should be scoped, so basically a RIO should also have = a source prefix in it's announcement. Src, dst, route. Together. This = way a RIO could indicate that ULA should communicate with ULA and = nothing else. If you don't have a ULA address, you can't send packet to = ULA destinations.

There's actually no = valid reason to place that limitation on ULA. It is perfectly valid = within the scope of a set of ULA addresses to reach them from GUA = addresses within that routing scope and vice versa. What is not valid is = to expect that ULA addresses are valid for reaching the entire = internet.

Baking in the kind of policy-based = routing you describe not only into every host, but into all of the RAs = and RIOs would seriously complicate what was intended to be a simple, = lightweight protocol which serves its purpose very = well.

ULAs and policy based routing are edge = corner cases. We should not look at complicating and breaking the more = general, more widely used, and more common mechanisms in order to chase = after solutions for these corner = cases.

Owen

= --Apple-Mail=_3F844D68-2DB7-4579-884C-56903B631B96-- From markzzzsmith@yahoo.com.au Fri Mar 22 16:42:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF0821F8556 for ; Fri, 22 Mar 2013 16:42:26 -0700 (PDT) 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=[AWL=0.100, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] 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 g8fd6yiYJXI3 for ; Fri, 22 Mar 2013 16:42:25 -0700 (PDT) Received: from nm32-vm5.bullet.mail.bf1.yahoo.com (nm32-vm5.bullet.mail.bf1.yahoo.com [72.30.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 896D321F8525 for ; Fri, 22 Mar 2013 16:42:25 -0700 (PDT) Received: from [98.139.212.146] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 22 Mar 2013 23:42:24 -0000 Received: from [98.139.212.197] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 22 Mar 2013 23:42:24 -0000 Received: from [127.0.0.1] by omp1006.mail.bf1.yahoo.com with NNFMP; 22 Mar 2013 23:42:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 873948.35555.bm@omp1006.mail.bf1.yahoo.com Received: (qmail 50117 invoked by uid 60001); 22 Mar 2013 23:42:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1363995744; bh=BB7qvQ3YYxYi05lz86696BbivKlUdN41JwfnqacKw0Q=; 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=dIQWTtYQMAWWjJBKsLaYpKZzBkUOwIeJpG4hbj2AtyldoeSKCVCW5jD4jYOG2wfNDBsVoyVBoEOc6NLqUuI/rg/sALYGnZZlOEYqr45Hi8jecn8aNtoLCkxYYsvCqmVB89H8pg3IgQPx6kzxkuw1H3LZrxKBLvy3sfeJJ+Cnzn4= 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=JiW6ecIoKWtXQORZF9Eid8Q1RMUSy6nYgkLMObHlkx6EHPi4QpcNGeUTnfoiKYGuh951JMe6uQI+6nLNw+KHxx1Z2tgMJa6N6yENYQm8Io16F5Va6/froZZkny783eo3ajNm62/bNPXb4CqsY3hZh/ZGeTIQXxchArapDwYfB+A=; X-YMail-OSG: aPOtE88VM1nE10MEFJTmZdnhSTGVhugNe7UFBm1qtSoOCiU UH0fB4HyNYSZJnA__sFc4vfVT9hQNWIsGveky9GnvO5Jlx6oMF0UXIiEB4z1 e.BU38IVD6tkEgTaKco5af.xNlfhI2gs1mW73iDyEp9SKB4qMTCCBgW7SkUi je54xNS1_GdE8tbI6hhiUCzx4S7Hu3McGB454DEHnv.WO21UhCaRsETXcTM4 YXhnkiqdPdepIo7IoiGDeQ11DOUOnplclRUdBERMJvOiAsEQTaqZLEIwFfoa TweG91zehEunXfLzeeZ4K0JfiS4WCrtwh5DzTiaukKnSytW09Z0dSCZyi7tv PF9v4ts4zNdKnGRpAYDttYFXMnxBk0PMAJMqGPWOYFrOykqwxi5bLoiCrf9J KfLSt9ysAidGiyBuG7wVoLuaWJ0ZZ5Ygx5o2ptImFH.lcQvweDqggZSk4Eo0 idSyxTLhrPdB63rwL2ox3jRlXKNPQrNPdM3VBtQVtbqpOFHLCIg7j5KkxeuV kCl.diJwrBGvsiOEDrC8nprm.ALGwhW0SxNKtwlWB..UYaLKQSUVqVEoBPfF QYYz6vlQgxzBcbP_9YVKyJzB2EEN1xvsAz6bjGRKyvTsFb212v.c7E88YYMt Jt3WnF5EzluNqBz2rtEdcPz1s9c4Ofs1x Received: from [150.101.221.237] by web142504.mail.bf1.yahoo.com via HTTP; Fri, 22 Mar 2013 16:42:24 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBPd2VuIERlTG9uZyA8b3dlbkBkZWxvbmcuY29tPgo.IFRvOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPgo.IENjOiAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz4KPiBTZW50OiBTYXR1cmRheSwgMjMgTWFyY2ggMjAxMyA1OjMwIEFNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gcXVlc3Rpb25zIHJlZ2FyZGluZyByZmM2MjA0YmlzIChkcmFmdC1saXUtdjZvcHMtdWxhLXVzYWdlLWFuYWwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.138.524 References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> <514C8719.7000004@gmail.com> <514C8AD8.8! 030705@gmail.com> <722D9250-6C69-4D87-88D1-4014F340CBAB@delong.com> Message-ID: <1363995744.49561.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Fri, 22 Mar 2013 16:42:24 -0700 (PDT) From: Mark Smith To: Owen DeLong , Brian E Carpenter In-Reply-To: <722D9250-6C69-4D87-88D1-4014F340CBAB@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 23:42:26 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Owen DeLong =0A> To: Brian E Carpenter =0A> Cc: "v6op= s@ietf.org" =0A> Sent: Saturday, 23 March 2013 5:30 AM=0A> = Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-us= age-analysis)=0A> =0A> =0A> On Mar 22, 2013, at 11:46 AM, Brian E Carpenter= =0A> wrote:=0A> =0A>> On 22/03/2013 16:30, = Alexandru Petrescu wrote:=0A>>> Le 21/03/2013 20:34, Owen DeLong a =E9crit= :=0A>>>>>> RA is not forbidden. Default route via RA is forbidden. RIO = =0A> via=0A>>>>>> RA is perfectly fine.=0A>>>>> =0A>>>>> But, the CPE rfc= bis says that the Router Lifetime must not be=0A>>>>> greater than 0.=A0 T= here is no other way in which an RA can tell =0A> a=0A>>>>> Host it's a de= fault router than setting that lifetime to =0A> greater=0A>>>>> than 0.=0A= >>>> =0A>>>> If the router doesn't provide internet access, it SHOULD NOT= =0A>>>> advertise itself as a default router. That is the point.=0A>>> =0A= >>> I shared that view at some point, but I changed.=0A>>> =0A>>> The mea= ning of 'default' route is not necessarily Internet.=A0 It =0A> means to=0A= >>> be used when everything else fails, that's all.=A0 It is also a=0A>>> = high-availability feature - absence of a default route means the system=0A= >>> is less reliable.=A0 One _wants_ a default option whenever one does=0A= >>> something with multiple choice.=0A>>=A0=0A=0AI'd go even more abstract= and say that all a default route represents is a pointer to a next hop dev= ice that *might* have better knowledge of how to get to the destination tha= n the current device, with it's default route. This is why the behaviour of= a device with multiple default routes is either unpredictable or implement= ation specific, because there is no way to tell from default routing inform= ation which of the next hop devices may have better routing information for= a particular destination.=0A=0ACommonly the default route points towards t= he Internet, but only because it is assumed that the destination is likely = to exist on the Internet. The DFZ generally will have that knowledge, but t= hat can be inaccurate too.=0A=0AOne of the best terms I've heard for routin= g information is that it is a 'hint' that destination exists, not an assura= nce. The destination might exist at the time the first router with knowledg= e of the route for a destination forwards the packet, but as the packet is = in flight along the path, the destination may become unavailable (e.g., hos= t crashes, the last hop router crashes, or a link fails). There is latency = in the routing system, so the routing system may claim, or rather, provide = a hint, that the destination currently exists, when in fact it doesn't at a= particular moment. The 'hint' terminology, and other general discussions r= elated to flat verses=A0hierarchical=A0addressing are in the following pape= r (which also explains why MAC addresses are 48 bits)=0A=0A48-bit Absolute = Internet and Ethernet Host Numbers=0A=0Ahttp://ethernethistory.typepad.com/= papers/HostNumbers.pdf=0A=0A=0A=A0=0A=0A=0A=0ARegards,=0AMark. From swmike@swm.pp.se Fri Mar 22 18:40:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F1B21F8E92 for ; Fri, 22 Mar 2013 18:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.204, 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 Os0XttGu7hs5 for ; Fri, 22 Mar 2013 18:40:44 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 53A1F21F8A7E for ; Fri, 22 Mar 2013 18:40:44 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1DE799C; Sat, 23 Mar 2013 02:40:43 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 18C6E9A; Sat, 23 Mar 2013 02:40:43 +0100 (CET) Date: Sat, 23 Mar 2013 02:40:43 +0100 (CET) From: Mikael Abrahamsson To: Owen DeLong In-Reply-To: Message-ID: References: <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> <514C8719.7000004@gmail.com> <514C8AD8.8! 030705@gmail.com> <722D9250-6C69-4D87-88D1-4014F340CBAB@delong.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 01:40:45 -0000 On Fri, 22 Mar 2013, Owen DeLong wrote: > RAs can contain multiple prefixes. They do not contain default routes. > The contain a flag that indicates that the router sending the RA is a > candidate default router. I am well aware how this is designed. I am saying I want it changed. > They really shouldn't. Source-based routing is a hack. It's also known > as "Policy based routing". Users that require such features can > configure them on routers that support them. However, they are not part > of the default way that routing is handled, nor should they be. I have been known to say "whatever process was used when the answer was is wrong during that process". However, what I'm talking about here is gateway selection at the host depending on what IPv6 address it chose to use for this communication. Think IPv4 and IPv6. There is no reason for a router to choose its IPv4 default gateway for IPv6 communication, nor is there really any reason for the host to choose gateway 1 when it's using an IPv6 address created based on RAs seen from gateway 2 (other than that's the way it was designed historically). > There's actually no valid reason to place that limitation on ULA. It is > perfectly valid within the scope of a set of ULA addresses to reach them > from GUA addresses within that routing scope and vice versa. What is not > valid is to expect that ULA addresses are valid for reaching the entire > internet. I believe this is up to the routing policy of the network. > Baking in the kind of policy-based routing you describe not only into > every host, but into all of the RAs and RIOs would seriously complicate > what was intended to be a simple, lightweight protocol which serves its > purpose very well. I believe the discussion we've seen here says otherwise. > ULAs and policy based routing are edge corner cases. We should not look > at complicating and breaking the more general, more widely used, and > more common mechanisms in order to chase after solutions for these > corner cases. A multihomed routed home is a pipe dream unless we change things. -- Mikael Abrahamsson email: swmike@swm.pp.se From brian.e.carpenter@gmail.com Sat Mar 23 01:36:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0376121F88ED for ; Sat, 23 Mar 2013 01:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.473 X-Spam-Level: X-Spam-Status: No, score=-100.473 tagged_above=-999 required=5 tests=[AWL=1.218, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, 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 QYPy+ZQv-4PH for ; Sat, 23 Mar 2013 01:36:44 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 25BED21F8867 for ; Sat, 23 Mar 2013 01:36:43 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id es5so1517567wgb.29 for ; Sat, 23 Mar 2013 01:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5Elt891b0O5R8pzZcNqaPXeJQzEEmCJxQBLZKJ7PJ/8=; b=E2Ss60wi6mn+6nwue3myJkhqcbWfJYwiFeh9VW60GdAJGHZSGdOqR4YlJyYfx5yip7 LwY3hH2QejOPh863ynHCiYpr0663CGBgV0uYv6SmJWHaQyYqUt2bNPejGuYRWbpd1OAp A3rhwoBZRMPLgjWvAX4TsaA1Q3tJ+r26FIEajwC3mVZ8nvV4Bpl6KuQkob2+sqGAO68h on8IGRZU8+adaFBdUTVsq5E2iQy6OHYjoSGFAXnqGJ2xhwlwSKrkaJDpHRoowm5VACxP /DVKYokQgugQdL8SqmetT2QoIIdPiIysVINO4n6FCbtVqCF/dNmOu3h1FgY0MsHJhtic kpyA== X-Received: by 10.194.171.74 with SMTP id as10mr7759830wjc.0.1364027803176; Sat, 23 Mar 2013 01:36:43 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-162.as13285.net. [2.102.219.162]) by mx.google.com with ESMTPS id dm9sm15369202wib.3.2013.03.23.01.36.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Mar 2013 01:36:42 -0700 (PDT) Message-ID: <514D69A9.20105@gmail.com> Date: Sat, 23 Mar 2013 08:36:57 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Owen DeLong References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> <514C8719.7000004@gmail.com> <514C8AD8.8! 030705@gmail.com> <722D9250-6C69-4D87-88D1-4014F340CBAB@delong.com> In-Reply-To: <722D9250-6C69-4D87-88D1-4014F340CBAB@delong.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 08:36:45 -0000 On 22/03/2013 18:30, Owen DeLong wrote: > On Mar 22, 2013, at 11:46 AM, Brian E Carpenter wrote: >=20 >> On 22/03/2013 16:30, Alexandru Petrescu wrote: >>> Le 21/03/2013 20:34, Owen DeLong a =C3=A9crit : >>>>>> RA is not forbidden. Default route via RA is forbidden. RIO via >>>>>> RA is perfectly fine. >>>>> But, the CPE rfcbis says that the Router Lifetime must not be >>>>> greater than 0. There is no other way in which an RA can tell a >>>>> Host it's a default router than setting that lifetime to greater >>>>> than 0. >>>> If the router doesn't provide internet access, it SHOULD NOT >>>> advertise itself as a default router. That is the point. >>> I shared that view at some point, but I changed. >>> >>> The meaning of 'default' route is not necessarily Internet. It means= to >>> be used when everything else fails, that's all. It is also a >>> high-availability feature - absence of a default route means the syst= em >>> is less reliable. One _wants_ a default option whenever one does >>> something with multiple choice. >> As I've said since the beginning of MIF, a host needs a default route >> per source prefix. I think you'll find that solves the dilemma. >=20 > No, it really doesn't. In fact, I would say that may well cause more pr= oblems than it solves. >=20 > Bottom line is that you should only provide a default route if you can = reasonably expect to forward all traffic received via that default route.= Otherwise, you are creating a black hole. >=20 > Routes are destination based, not source based,=20 In a multi-prefix network, that is a bug. (I'm not saying we don't have to consider today's running code, but we also have to do better in future= =2E) Brian From owen@delong.com Sat Mar 23 11:51:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146F221F8BB6 for ; Sat, 23 Mar 2013 11:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywCnp6FdB5gz for ; Sat, 23 Mar 2013 11:51:11 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA1521F8AF8 for ; Sat, 23 Mar 2013 11:51:10 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2NIkStc019737 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 23 Mar 2013 11:46:28 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2NIkStc019737 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364064389; bh=+G4nspCE47MabGd5jRrUknlvj2U=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=DC9VAoWkewMmgH4YlFcO+ko9d3YvXndOwJs95vARTa4Y+91cI84MbyL3x1ircYnqy Cqo6IDsZDTP6LW9FgCNNFKNBuYlyTCzleaoGaq7uz9yEBKtkeMXwwqRQWmFQOXgmUy 82sDuJxrl07BHeyBsLFbEjsEPScx52B8qFNg/ZA8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: Date: Sat, 23 Mar 2013 11:46:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> <514C8719.7000004@gmail.com> <514C8AD8.8! 030705@gmail.com> <722D9250-6C69-4D87-88D1-4014F340CBAB@delong.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 23 Mar 2013 11:46:29 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 18:51:12 -0000 On Mar 22, 2013, at 18:40 , Mikael Abrahamsson wrote: > On Fri, 22 Mar 2013, Owen DeLong wrote: >=20 >> RAs can contain multiple prefixes. They do not contain default = routes. The contain a flag that indicates that the router sending the RA = is a candidate default router. >=20 > I am well aware how this is designed. I am saying I want it changed. >=20 >> They really shouldn't. Source-based routing is a hack. It's also = known as "Policy based routing". Users that require such features can = configure them on routers that support them. However, they are not part = of the default way that routing is handled, nor should they be. >=20 > I have been known to say "whatever process was used when the answer = was is wrong during that process". However, what = I'm talking about here is gateway selection at the host depending on = what IPv6 address it chose to use for this communication. Think IPv4 and = IPv6. There is no reason for a router to choose its IPv4 default gateway = for IPv6 communication, nor is there really any reason for the host to = choose gateway 1 when it's using an IPv6 address created based on RAs = seen from gateway 2 (other than that's the way it was designed = historically). Which to my mind is just policy based routing implemented on the source = host. In terms of protocols, IPv4 and IPv6 are already separate routing tables = and that will not happen. You cannot forward an IPv4 packet to an IPv6 = next-hop or vice versa. That is already the case today. (Note, tunneling is not an exception to this. Once you encapsulate the = IPv6 packet in an IPv4 packet for the tunnel, it is now an iPv4 packet = that is actually going to the IPv4 next hop). >=20 >> There's actually no valid reason to place that limitation on ULA. It = is perfectly valid within the scope of a set of ULA addresses to reach = them from GUA addresses within that routing scope and vice versa. What = is not valid is to expect that ULA addresses are valid for reaching the = entire internet. >=20 > I believe this is up to the routing policy of the network. >=20 Correct. I was responding to a claim that said limitation should be = baked in. It should not. Sounds like we agree. >> Baking in the kind of policy-based routing you describe not only into = every host, but into all of the RAs and RIOs would seriously complicate = what was intended to be a simple, lightweight protocol which serves its = purpose very well. >=20 > I believe the discussion we've seen here says otherwise. >=20 I remain unconvinced. In fact, if anything, the discussion here has = shown that ULAs were probably a bad idea in general which creates a = number of unnecessary corner cases. >> ULAs and policy based routing are edge corner cases. We should not = look at complicating and breaking the more general, more widely used, = and more common mechanisms in order to chase after solutions for these = corner cases. >=20 > A multihomed routed home is a pipe dream unless we change things. Correct. But this is not the direction in which we should be changing = them. Breaking the rest of the internet to enable a multihomed routed = home is not the answer. Owen From alexandru.petrescu@gmail.com Sat Mar 23 11:54:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0461321F8B1E for ; Sat, 23 Mar 2013 11:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.101 X-Spam-Level: * X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.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 Pr6Py9kDFGe2 for ; Sat, 23 Mar 2013 11:54:15 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 169C121F8765 for ; Sat, 23 Mar 2013 11:54:13 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 3F8229401CB; Sat, 23 Mar 2013 19:54:05 +0100 (CET) Message-ID: <514DFA47.1020705@gmail.com> Date: Sat, 23 Mar 2013 19:53:59 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Templin, Fred L" References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149C642.6060806@gmail.com> <481173D1-2F02-4B80-8E2C-BE33009EF2C9@delong.com> <514B116E.9070504@gmail.com> <514B14C2.3050303@gmail.com> <514B8598.6090401@bogus.com> <2134F8430051B64F815C691A62D98318036EC8@XCH-BLV-504.nw.nos.boeing.com> <514B9364.! 6040803@bogus.com> <2EFC0D07-DA29-46F7-92E7-FA4C69ACF95F@merike.com> <2134F8430051B64F815C691A62D98318037A52@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D98318037A52@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130323-1, 23/03/2013), Outbound message X-Antivirus-Status: Clean Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 18:54:26 -0000 Le 22/03/2013 16:26, Templin, Fred L a écrit : > Hi Merike, > >> -----Original Message----- From: Merike Kaeo >> [mailto:kaeo@merike.com] Sent: Friday, March 22, 2013 2:43 AM To: >> joel jaeggli Cc: Templin, Fred L; Brian E Carpenter; Alexandru >> Petrescu; v6ops@ietf.org Subject: Re: [v6ops] >> draft-liu-v6ops-ula-usage-analysis >> >> >> On Mar 21, 2013, at 4:10 PM, joel jaeggli wrote: >> >>> On 3/21/13 3:46 PM, Templin, Fred L wrote: >>>> >>>>> -----Original Message----- From: v6ops-bounces@ietf.org >>>>> [mailto:v6ops-bounces@ietf.org] On Behalf >> Of >>>>> joel jaeggli Sent: Thursday, March 21, 2013 3:12 PM To: Brian >>>>> E Carpenter; Alexandru Petrescu Cc: v6ops@ietf.org Subject: >>>>> Re: [v6ops] draft-liu-v6ops-ula-usage-analysis >>>>> >>>>> On 3/21/13 7:10 AM, Brian E Carpenter wrote: >>>>>> On 21/03/2013 13:55, Alexandru Petrescu wrote: ... >>>>>>> A PI GUA for 2-3 Enterprises may work connected mostly >>>>>>> all the time >> at >>>>>>> the same 2-3 places. But I think 1 billion PI GUAs >>>>>>> moving around >> the >>>>>>> Internet at the speed of 1 new connection/minute may not >>>>>>> work - it involves 'route churning', i.e. too many >>>>>>> routing protocol messages >> per >>>>>>> second and too large routing table entries. Isnt't there >>>>>>> a risk >> like >>>>> that? >>>>>> Well, it was three or four orders of magnitude smaller, but >>>>>> there >> were a >>>>> lot >>>>>> of complaints about the churn produced by Connexion by >>>>>> Boeing, which >> was >>>>>> effectively a few hundred IPv4 PI prefixes moving around at >>>>>> almost >> Mach >>>>> 1. iirc there were complaints that it was a relatively bad >>>>> idea. there >> were >>>>> no complaints as far as I know due to impact of the rate of >>>>> prefix >> churn >>>>> which was way lower (by orders of magnitude) than the worst >>>>> offendors out there at the time. The prefix advertisement and >>>>> withdrawal was in fact done by the groundstatations not the >>>>> aircraft. >>>>> >>>>> There were never hundreds of of transcontinental commercial >>>>> aircraft engaged in roaming on the service (there were >>>>> around 200 planes total with the equipment). There are many >>>>> more aircraft today operating with satellite or terrestrial >>>>> internet connectivity and without such >> behavior. >>>> This all happened before my time at Boeing, but my >>>> understanding is that someone noticed prefixes being announced >>>> and withdrawn due to aircraft mobility and brought the >>>> situation to light. >>> Ben Abarbanel from boeing presented it at nanog 31 yeah. >>> >>> http://www.nanog.org/meetings/nanog31/presentations/abarbanel.pdf >>> >>> >>> and about a year later at the ietf 62 technical plenary. >>> >>> some papers were published, etc. >>> >>> http://quark.net/docs/Global_IP_Network_Mobility_using_BGP.pdf >> >> Connexion By Boeing peaked my interest since I worked for them and >> back in 2005/6 developed their IPv6 strategy plus configured the >> testbed ground stations to be dual- stacked (I had a /48 from >> Boeing's /32 PI routed by NTT....that caused quite the debates >> internal to NTT since at that time ISPs were still debating merits >> of doing so). It was fun trying get the ISPs to tell me the >> real deal... "no, I don't want a tunnel I want a native eBGP >> connection and please route my /48". How times change. >> >> I can definitively state that at that time with v6 there was going >> to be NO ULA usage although yes, there was routing churn that was >> disliked by ISPs but noone was actively saying it was causing >> *great harm*. It was just very unsavory - hence the talks at NANOG >> and APRICOT and RIPE to explain and get more feedback. [and the >> folks building the routing had talked to some global ISPs before >> finally deciding on going that route] >> >> Of course using v6 routing at that time if we had gone live *could* >> have shown interesting global routing behavior :) >> >> It's unfortunate Connexion By Boeing went under....we were in >> process of moving to production test with v6 at the time (early >> 2006). Although as Fred has stated, the system is still >> operational but for a very limited set of folks. Stuck in v4 >> AFAIK. > > My understanding was that the service was picked up by Panasonic > eXConnect. This is good to know. May I mention some commercial deployments of Wi-Fi in vehicles. Currently 'Wi-Fi is already in use aboard 1600 planes that fly over the United States' according to a recent respectable paper. GoGo and OnAir as operators, and Boeing and Airbus as manufacturers. I have tried recently one Wi-Fi on-board of flight (gogo with a delta flight in US). It was NAT for the passengers and no IPv6. I have also tried recently Wi-Fi on board of the IETF shuttle bus in Orlando, and Wi-Fi on board of the Thalys train for Brussels. Both were NAT for passengers, and no IPv6. For the Thalys train I could notice handover of the train between 3G and WiFi in railway station, by checking the end-to-end RTT. When NAT IPv4 is used on-board of these vehicles, there is probably no routing churn (the onboard addresses are not propagated to the infrastructure), and probably little need for Mobile IP. The on-board WiFi networks of vehicles would be candidates for using ULA addressing when migrating to IPv6. Alex >> As far as mobility scenarios - due to the routing churn issues in >> v4 I was following NEMO and other mobility scenarios to see how >> they might be utilized with v6. Not sure where that went as I >> stopped following it. > > We have taken care of the routing churn issue with SEAL/VET/IRON: > > https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ > https://datatracker.ietf.org/doc/draft-templin-intarea-vet/ > https://datatracker.ietf.org/doc/draft-templin-ironbis/ > > Thanks - Fred fred.l.templin@boeing.com > >> Whether you use ULA or GUA for mobility has no difference. The >> issue comes in whether you have an entirely closed system (air >> traffic control and some other global mobile entities do) or >> whether you need to communicate to outside world. The latter gets >> more interesting with ULAs. >> >> - merike > > From owen@delong.com Sat Mar 23 12:16:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0936B21F8D13 for ; Sat, 23 Mar 2013 12:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrGyfu9ngSvf for ; Sat, 23 Mar 2013 12:16:05 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 24C4F21F8CF4 for ; Sat, 23 Mar 2013 12:16:05 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2NJBY9M020334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 23 Mar 2013 12:11:34 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2NJBY9M020334 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364065894; bh=SDLEV+88+oM+9gFdOxC7/hl0Rv4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=xCzWascBBbpXww8S1umtpyHWLFBDAxtpTH4CUTK7C9W4J5+kRo/NEBUVPgN1jbXSZ h80sw8b8V6nIineq1fYcRGtlXeEz2qEXA+6fgNtT1BxHt46lGrg4ya4boVT5zdQ1/I bG3rgETNM6ue0TeT94LbDJKIOgssjH5pLgnjtlQQ= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <514DFA47.1020705@gmail.com> Date: Sat, 23 Mar 2013 12:11:40 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149C642.6060806@gmail.com> <481173D1-2F02-4B80-8E2C-BE33009EF2C9@delong.com> <514B116E.9070504@gmail.com> <514B14C2.3050303@gmail.com> <514B8598.6090401@bogus.com> <2134F8430051B64F815C691A62D98318036EC8@XCH-BLV-504.nw.nos.boeing.com> <514B9364.! 6040803@bogus.com> <2EFC0D07-DA29-46F7-92E7-FA4C69ACF95F@merike.com> <2134F8430051B64F815C691A62D98318037A52@XCH-BLV-504.nw.nos.boeing.com> <514DFA47.1020705@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 23 Mar 2013 12:11:34 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 19:16:06 -0000 > When NAT IPv4 is used on-board of these vehicles, there is probably no > routing churn (the onboard addresses are not propagated to the > infrastructure), and probably little need for Mobile IP. > > The on-board WiFi networks of vehicles would be candidates for using ULA > addressing when migrating to IPv6. > I sincerely hope not. It's such a pain to make my laptop reachable behind these NATs. I'm really hoping that pain can be eliminated and that valid MIP can be made available instead. It is a much cleaner solution. It allows for the route churn to be limited to within the provider's network if done properly. Owen From v6ops@globis.net Sat Mar 23 12:19:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7220121F8DD0 for ; Sat, 23 Mar 2013 12:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Onh85dEjIJvu for ; Sat, 23 Mar 2013 12:19:28 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2BADC21F8D84 for ; Sat, 23 Mar 2013 12:19:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E816C8700DF; Sat, 23 Mar 2013 20:19:11 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dbPaQHZtk4m; Sat, 23 Mar 2013 20:18:43 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 0079887007A; Sat, 23 Mar 2013 20:18:42 +0100 (CET) Message-ID: <514E000C.1020709@globis.net> Date: Sat, 23 Mar 2013 20:18:36 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Owen DeLong References: <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> <514C8719.7000004@gmail.com> <514C8AD8.8! 030705@gmail.com> <722D9250-6C69-4D87-88D1-4014F340CBAB@delong.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 19:19:30 -0000 inline. Owen DeLong wrote: > On Mar 22, 2013, at 18:40 , Mikael Abrahamsson wrote: > >> On Fri, 22 Mar 2013, Owen DeLong wrote: >> >>> RAs can contain multiple prefixes. They do not contain default routes. The contain a flag that indicates that the router sending the RA is a candidate default router. >> I am well aware how this is designed. I am saying I want it changed. After looking at homenet architecture I am beginning to agree with Mikael. AFAIK Never before have we expected an end node to have to chose a next-hop between 2 or more routers managed by competing AS's on a shared common link . We certainly would never do that in an enterprise network. >>> They really shouldn't. Source-based routing is a hack. It's also known as "Policy based routing". Users that require such features can configure them on routers that support them. However, they are not part of the default way that routing is handled, nor should they be. >> I have been known to say "whatever process was used when the answer was is wrong during that process". However, what I'm talking about here is gateway selection at the host depending on what IPv6 address it chose to use for this communication. Think IPv4 and IPv6. There is no reason for a router to choose its IPv4 default gateway for IPv6 communication, nor is there really any reason for the host to choose gateway 1 when it's using an IPv6 address created based on RAs seen from gateway 2 (other than that's the way it was designed historically). > > Which to my mind is just policy based routing implemented on the source host. > > In terms of protocols, IPv4 and IPv6 are already separate routing tables and that will not happen. You cannot forward an IPv4 packet to an IPv6 next-hop or vice versa. That is already the case today. You seem to be assuming ships in the night dual stack en-to-end. With the roll out of NAT64, NAT444, NAT 464, NAPT, NPTv6 and who knows what other translation abominations that hide the real underlying topology, it is almost impossible for an end node to chose the "correct" next hop from several on anything except hope. But that's exactly what we seem to be expecting in the homenet architecture. > (Note, tunneling is not an exception to this. Once you encapsulate the IPv6 packet in an IPv4 packet for the tunnel, it is now an iPv4 packet that is actually going to the IPv4 next hop). > >>> There's actually no valid reason to place that limitation on ULA. It is perfectly valid within the scope of a set of ULA addresses to reach them from GUA addresses within that routing scope and vice versa. What is not valid is to expect that ULA addresses are valid for reaching the entire internet. >> I believe this is up to the routing policy of the network. >> > > Correct. I was responding to a claim that said limitation should be baked in. It should not. Sounds like we agree. > >>> Baking in the kind of policy-based routing you describe not only into every host, but into all of the RAs and RIOs would seriously complicate what was intended to be a simple, lightweight protocol which serves its purpose very well. >> I believe the discussion we've seen here says otherwise. >> > > I remain unconvinced. In fact, if anything, the discussion here has shown that ULAs were probably a bad idea in general which creates a number of unnecessary corner cases. > >>> ULAs and policy based routing are edge corner cases. We should not look at complicating and breaking the more general, more widely used, and more common mechanisms in order to chase after solutions for these corner cases. >> A multihomed routed home is a pipe dream unless we change things. > > Correct. But this is not the direction in which we should be changing them. Breaking the rest of the internet to enable a multihomed routed home is not the answer. > > Owen > > From owen@delong.com Sat Mar 23 12:56:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9850521F8DA4 for ; Sat, 23 Mar 2013 12:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSSw81ajXY-e for ; Sat, 23 Mar 2013 12:56:37 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1002921F8DC1 for ; Sat, 23 Mar 2013 12:56:36 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2NJtK2X021316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 23 Mar 2013 12:55:20 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2NJtK2X021316 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364068520; bh=ot/qwXU4qr6u/vLi3QI2pexWD2U=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=tbno5wQDG973zrDxIlbVXicG6pL8X2h6rrHGpD+2UQkAm9k6wO/zV7f98IRvWWxLS s3FGEyaWVSeyz+YWK86QP7EHDGVTr3FGv1OAA4AlDv8xUx2AkfqDA2hD53cJqFHFQj KMKqiEZ+tckicYJZq/YG4W3g7TrYMBUQ3d5yaB84= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <514E000C.1020709@globis.net> Date: Sat, 23 Mar 2013 12:55:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <16067407-EBAD-4F88-B5AC-D5A54671D1B0@delong.com> References: <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> <514C8719.7000004@gmail.com> <514C8AD8.8! 030705@gmail.com> <722D9250-6C69-4D87-88D1-4014F340CBAB@delong.com> <514E000C.1020709@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 23 Mar 2013 12:55:20 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 19:56:38 -0000 >>=20 >> In terms of protocols, IPv4 and IPv6 are already separate routing = tables and that will not happen. You cannot forward an IPv4 packet to an = IPv6 next-hop or vice versa. That is already the case today. >=20 > You seem to be assuming ships in the night dual stack en-to-end. >=20 > With the roll out of NAT64, NAT444, NAT 464, NAPT, NPTv6 and who knows > what other translation abominations that hide the real underlying > topology, it is almost impossible for an end node to chose the = "correct" > next hop from several on anything except hope. >=20 > But that's exactly what we seem to be expecting in the homenet = architecture. Primarily, I expect that IPv4 outside of the LAN is mostly a temporary = problem. I believe that eventually, NAT46 dongles will replace all of the above = absurdities. As such, I'd rather focus on solutions that meet the true needs of an = IPv6 environment than continuing to flail on more ways to increase the = complexity of a dying protocol. Owen From Ted.Lemon@nominum.com Sat Mar 23 13:15:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8DD21F8BBB for ; Sat, 23 Mar 2013 13:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.587 X-Spam-Level: X-Spam-Status: No, score=-106.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3O303gfCUKF for ; Sat, 23 Mar 2013 13:15:35 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id D4EC221F8BB6 for ; Sat, 23 Mar 2013 13:15:34 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUU4NZk7vyaXpzPw1HA0CV5mE6IE0bkHW@postini.com; Sat, 23 Mar 2013 13:15:34 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 67A281B8759 for ; Sat, 23 Mar 2013 13:15:34 -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 4E52E190061; Sat, 23 Mar 2013 13:15:34 -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.0318.004; Sat, 23 Mar 2013 13:15:34 -0700 From: Ted Lemon To: Ray Hunter Thread-Topic: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) Thread-Index: AQHOJ/dsVRa24xDvLEOLfCSvCgW0BJi0G9gAgAAP6oA= Date: Sat, 23 Mar 2013 20:15:33 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077511CD07@mbx-01.win.nominum.com> References: <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> <514C8719.7000004@gmail.com> <514C8AD8.8! 030705@gmail.com> <722D9250-6C69-4D87-88D1-4014F340CBAB@delong.com> <514E000C.1020709@globis.net> In-Reply-To: <514E000C.1020709@globis.net> 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: <9F6EC1F7CEC3454293CE9EA158863C28@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 20:15:35 -0000 On Mar 23, 2013, at 3:18 PM, Ray Hunter wrote: > it is almost impossible for an end node to chose the "correct" > next hop from several on anything except hope. It is not almost impossible. In most cases, it _is_ impossible. There a= re exceptions, but in general you have to just try. This is not, however, a problem. From dougb@dougbarton.us Sat Mar 23 13:24:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD34D21F8C4F for ; Sat, 23 Mar 2013 13:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 Rd1vBcD17L28 for ; Sat, 23 Mar 2013 13:24:08 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8354C21F8C4C for ; Sat, 23 Mar 2013 13:24:08 -0700 (PDT) Received: from [192.168.0.102] (home [12.207.105.210]) by dougbarton.us (Postfix) with ESMTPSA id 3AC7522B11 for ; Sat, 23 Mar 2013 20:24:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1364070248; bh=8jtA/Nhk4S1S4vdjUX3BgjtT/Ccy8oZH4fECv+U3xjY=; h=Date:From:To:Subject:References:In-Reply-To; b=HJ2rXqpebenP+hEWPbGrrW8JVqNcux7qcfFNItsWRYRwL1cY3I8Jl8YHWaZHZA80M huDlPYNgD2qhahHfkbarcxC6LdNDBXbgUCCbxooy/D90VyHMFQlYMqWsAOVAfrK6R4 umhaIdmXt39M+EOaXSTHnISUF6omgoU0EG/AHPKY= Message-ID: <514E0F68.2080803@dougbarton.us> Date: Sat, 23 Mar 2013 13:24:08 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> In-Reply-To: <514977CF.9030806@gmail.com> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 20:24:10 -0000 On 03/20/2013 01:48 AM, Brian E Carpenter wrote: > On 20/03/2013 07:42, Tim Chown wrote: >> On 19 Mar 2013, at 13:10, Ray Hunter wrote: >> >>> Fred Baker (fred) wrote: >>>> In the meeting at IETF 86, we discussed >>>> >>>> http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis >>>> http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis >>>> "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang, >>>> Cameron Byrne, 25-Feb-13 >>>> >>>> and the hum supported making that a working group draft. In this note, I'm asking for ratification on the list - whether you agree or disagree, I'd appreciate your thoughts. >>> I have a problem with "BCP" status for any draft recommending use of ULA >>> on Internet connected networks without some health warning, because I'm >>> not yet convinced that this may not end up being harmful [highly mobile >>> devices, split horizon, caching]. >> >> Informational seems appropriate. >> >> While some of us have been using them in various contexts, unless we hear of widescale, significant deployments, it's difficult to argue for BCP. > > It depends. If the draft says "If you choose to use a ULA prefix, here > are some guidelines on how to do it properly", BCP might be appropriate. > However, an informational description of appropriate deployment scenarios > would be quite OK. > > If it says "Use a ULA prefix!", I would certainly object to BCP. I agree with this dichotomy as well, FWIW. Doug From joelja@bogus.com Sun Mar 24 12:34:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C685121F8B27 for ; Sun, 24 Mar 2013 12:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-fyHzUYODOA for ; Sun, 24 Mar 2013 12:34:43 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6B85121F8B25 for ; Sun, 24 Mar 2013 12:34:43 -0700 (PDT) Received: from joels-MacBook-Air.local (50-0-150-57.dsl.static.sonic.net [50.0.150.57]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r2OJYapZ029694 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 24 Mar 2013 19:34:38 GMT (envelope-from joelja@bogus.com) Message-ID: <514F554A.4090001@bogus.com> Date: Sun, 24 Mar 2013 12:34:34 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Alexandru Petrescu , "Templin, Fred L" References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149C642.6060806@gmail.com> <481173D1-2F02-4B80-8E2C-BE33009EF2C9@delong.com> <514B116E.9070504@gmail.com> <514B14C2.3050303@gmail.com> <514B8598.6090401@bogus.com> <2134F8430051B64F815C691A62D98318036EC8@XCH-BLV-504.nw.nos.boeing.com> <514B9364.! 6040803@bogus.com> <2EFC0D07-DA29-46F7-92E7-FA4C69ACF95F@merike.com> <2134F8430051B64F815C691A62D98318037A52@XCH-BLV-504.nw.nos.boeing.com> <514DFA47.1020705@gmail.com> In-Reply-To: <514DFA47.1020705@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 24 Mar 2013 19:34:39 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 19:34:45 -0000 On 3/23/13 11:53 AM, Alexandru Petrescu wrote: > Le 22/03/2013 16:26, Templin, Fred L a écrit : >> Hi Merike, >> >>> -----Original Message----- From: Merike Kaeo >>> [mailto:kaeo@merike.com] Sent: Friday, March 22, 2013 2:43 AM To: >>> joel jaeggli Cc: Templin, Fred L; Brian E Carpenter; Alexandru >>> Petrescu; v6ops@ietf.org Subject: Re: [v6ops] >>> draft-liu-v6ops-ula-usage-analysis >>> >>> >>> On Mar 21, 2013, at 4:10 PM, joel jaeggli wrote: >>> >>>> On 3/21/13 3:46 PM, Templin, Fred L wrote: >>>>> >>>>>> -----Original Message----- From: v6ops-bounces@ietf.org >>>>>> [mailto:v6ops-bounces@ietf.org] On Behalf >>> Of >>>>>> joel jaeggli Sent: Thursday, March 21, 2013 3:12 PM To: Brian >>>>>> E Carpenter; Alexandru Petrescu Cc: v6ops@ietf.org Subject: >>>>>> Re: [v6ops] draft-liu-v6ops-ula-usage-analysis >>>>>> >>>>>> On 3/21/13 7:10 AM, Brian E Carpenter wrote: >>>>>>> On 21/03/2013 13:55, Alexandru Petrescu wrote: ... >>>>>>>> A PI GUA for 2-3 Enterprises may work connected mostly >>>>>>>> all the time >>> at >>>>>>>> the same 2-3 places. But I think 1 billion PI GUAs >>>>>>>> moving around >>> the >>>>>>>> Internet at the speed of 1 new connection/minute may not >>>>>>>> work - it involves 'route churning', i.e. too many >>>>>>>> routing protocol messages >>> per >>>>>>>> second and too large routing table entries. Isnt't there >>>>>>>> a risk >>> like >>>>>> that? >>>>>>> Well, it was three or four orders of magnitude smaller, but >>>>>>> there >>> were a >>>>>> lot >>>>>>> of complaints about the churn produced by Connexion by >>>>>>> Boeing, which >>> was >>>>>>> effectively a few hundred IPv4 PI prefixes moving around at >>>>>>> almost >>> Mach >>>>>> 1. iirc there were complaints that it was a relatively bad >>>>>> idea. there >>> were >>>>>> no complaints as far as I know due to impact of the rate of >>>>>> prefix >>> churn >>>>>> which was way lower (by orders of magnitude) than the worst >>>>>> offendors out there at the time. The prefix advertisement and >>>>>> withdrawal was in fact done by the groundstatations not the >>>>>> aircraft. >>>>>> >>>>>> There were never hundreds of of transcontinental commercial >>>>>> aircraft engaged in roaming on the service (there were >>>>>> around 200 planes total with the equipment). There are many >>>>>> more aircraft today operating with satellite or terrestrial >>>>>> internet connectivity and without such >>> behavior. >>>>> This all happened before my time at Boeing, but my >>>>> understanding is that someone noticed prefixes being announced >>>>> and withdrawn due to aircraft mobility and brought the >>>>> situation to light. >>>> Ben Abarbanel from boeing presented it at nanog 31 yeah. >>>> >>>> http://www.nanog.org/meetings/nanog31/presentations/abarbanel.pdf >>>> >>>> >>>> > and about a year later at the ietf 62 technical plenary. >>>> >>>> some papers were published, etc. >>>> >>>> http://quark.net/docs/Global_IP_Network_Mobility_using_BGP.pdf >>> >>> Connexion By Boeing peaked my interest since I worked for them and >>> back in 2005/6 developed their IPv6 strategy plus configured the >>> testbed ground stations to be dual- stacked (I had a /48 from >>> Boeing's /32 PI routed by NTT....that caused quite the debates >>> internal to NTT since at that time ISPs were still debating merits >>> of doing so). It was fun trying get the ISPs to tell me the >>> real deal... "no, I don't want a tunnel I want a native eBGP >>> connection and please route my /48". How times change. >>> >>> I can definitively state that at that time with v6 there was going >>> to be NO ULA usage although yes, there was routing churn that was >>> disliked by ISPs but noone was actively saying it was causing >>> *great harm*. It was just very unsavory - hence the talks at NANOG >>> and APRICOT and RIPE to explain and get more feedback. [and the >>> folks building the routing had talked to some global ISPs before >>> finally deciding on going that route] >>> >>> Of course using v6 routing at that time if we had gone live *could* >>> have shown interesting global routing behavior :) >>> >>> It's unfortunate Connexion By Boeing went under....we were in >>> process of moving to production test with v6 at the time (early >>> 2006). Although as Fred has stated, the system is still >>> operational but for a very limited set of folks. Stuck in v4 >>> AFAIK. >> >> My understanding was that the service was picked up by Panasonic >> eXConnect. > > This is good to know. May I mention some commercial deployments of > Wi-Fi in vehicles. > > Currently 'Wi-Fi is already in use aboard 1600 planes that fly over the > United States' according to a recent respectable paper. GoGo and OnAir > as operators, and Boeing and Airbus as manufacturers. > > I have tried recently one Wi-Fi on-board of flight (gogo with a delta > flight in US). It was NAT for the passengers and no IPv6. > > I have also tried recently Wi-Fi on board of the IETF shuttle bus in > Orlando, and Wi-Fi on board of the Thalys train for Brussels. Both were > NAT for passengers, and no IPv6. > > For the Thalys train I could notice handover of the train between 3G and > WiFi in railway station, by checking the end-to-end RTT. > > When NAT IPv4 is used on-board of these vehicles, there is probably no > routing churn (the onboard addresses are not propagated to the > infrastructure), and probably little need for Mobile IP. Connexion by boeing was also natted. the internal addressing was the same on every plane... It is worth noting that mobility-wise, transcontinental aircraft using geostationary satellites are not poster-children for mobility. On the timescales on which roaming occurs you can do all sorts of things that are familiar to 6renum/homenet people that don't involve moving pi /24s or /48s around. > The on-board WiFi networks of vehicles would be candidates for using ULA > addressing when migrating to IPv6. I would think that they would be good candidates for 6296 style nptv6 and what prefix is used on the inside is kind of not relevant. My experience with ip speaking devices in aviation systems is that they get certifed for operation in a particular configuration which is likely consistent across the population of those devices. > Alex > >>> As far as mobility scenarios - due to the routing churn issues in >>> v4 I was following NEMO and other mobility scenarios to see how >>> they might be utilized with v6. Not sure where that went as I >>> stopped following it. >> >> We have taken care of the routing churn issue with SEAL/VET/IRON: >> >> https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ >> https://datatracker.ietf.org/doc/draft-templin-intarea-vet/ >> https://datatracker.ietf.org/doc/draft-templin-ironbis/ >> >> Thanks - Fred fred.l.templin@boeing.com >> >>> Whether you use ULA or GUA for mobility has no difference. The >>> issue comes in whether you have an entirely closed system (air >>> traffic control and some other global mobile entities do) or >>> whether you need to communicate to outside world. The latter gets >>> more interesting with ULAs. >>> >>> - merike >> >> > From iljitsch@muada.com Sun Mar 24 14:17:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C8421F8995 for ; Sun, 24 Mar 2013 14:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPZ4mUYaWX5u for ; Sun, 24 Mar 2013 14:17:25 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 255B221F892B for ; Sun, 24 Mar 2013 14:17:24 -0700 (PDT) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2OLCI8M002969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 24 Mar 2013 22:12:19 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <514C77BD.9090708@ericsson.com> Date: Sun, 24 Mar 2013 22:17:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5E4DF003-1BDB-4BC2-AE6C-BDD60D132343@muada.com> References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> <514C77BD.9090708@ericsson.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1499) Cc: IPv6 Ops WG Subject: [v6ops] RFC 6732 can't work, was: draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 21:17:30 -0000 Hi Suresh, I'll reply to the rest of your message later. But: On 22 mrt 2013, at 16:24, Suresh Krishnan = wrote: > I think a short summary of 6to4 Provider Managed Tunnels (RFC6732) = would > be useful here for completeness. I'm surprised this was published as an RFC without a big fat IAB/IESG = warning. Or at all, really. This obviously isn't "informational", but = experimental in disguise. Besides being a very bad idea on many levels, I don't even think this = can work. What if node A, which has real 6to4 at 2002:1000:1::/48 wants to = communicate with node B, which has fake 6to4 prefix 2002:6440:1::/48 = which maps to 2001:db8:6400:1::/64? B sends a packet to A, bypassing the relay/translator, as A and B both = share the "directly connected" subnet 2002::/16. As such, B's prefix = isn't translated, and A sends back an encapsulated IPv6 packet to = 100.64.0.1, which of course never makes it because that address is not = globally unique. Iljitsch= From lorenzo@google.com Sun Mar 24 18:41:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD9B21F8E0A for ; Sun, 24 Mar 2013 18:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.677 X-Spam-Level: X-Spam-Status: No, score=-101.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZNzADUXzroI for ; Sun, 24 Mar 2013 18:41:30 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id DF5F621F8DEE for ; Sun, 24 Mar 2013 18:41:29 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id ni5so5488890obc.26 for ; Sun, 24 Mar 2013 18:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=3x8w6AmDARD1DPSxiMZbJhdGxngL7kBRinK++xpy1Jk=; b=SElUP+CinH128ZYy+then+aLm3V6ZEKtQkR5lUIqDCT1hpnv+PuL6CDNsfLQCpRJ5b CkiX7hNrksIc0M/PpIj4HOvbwxDKP9VAlsK9HGcOdrlcvwnq3FgDd19umgneZmJZiMKK cZDQvxbWE75Q7fpqckoQnqaiLjWCgYdanjIFT8ANqjnRyOehVHsaiTnBjQx4U8dfLEuj ImsIEiuO8RBo4cG79QaQJ4xgp7gxFBAk6IGd6WQmaqph1Li4FIVWVREs1xSy6bS7hjb3 SlHi/FyHLPz7gmcLMbYrwGUlll9M+0lploJeVVFPa+mhJlbUn69HLp8vtqcg82WrBJ5y 4h3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=3x8w6AmDARD1DPSxiMZbJhdGxngL7kBRinK++xpy1Jk=; b=SyBgNUQJV6l0KBwOVaijhlhzh/isj5hVw+HeuyxvQGwxArGByx3ZZJfkLt/yVS5V/+ fT0rlDBDKfeUMoYhRCjV8J2z21FA6/Js9lKjzHk7bicy6fOq2TyWVrfgRo5GwiaHt036 5fkwbGx3nMvOhqGFrv+UTqb+XWINO1b4+IWT+zFtdhq4C1oPNTgmotk5tIpZJiUklrcH Py5GJb5PKfcwXTjF4JDgdj5EOyed+bGgoBTvUFkFtRCN/c68GaNs/LOQ14xdcZyJKz3I 457xHRyA4FM7i1Av/c+zygR7XPvR27KUREgLCU9wZBmr18uQKFLTFAL7t5E7LGH2kZK+ ikjA== X-Received: by 10.60.20.193 with SMTP id p1mr9681406oee.133.1364175689317; Sun, 24 Mar 2013 18:41:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Sun, 24 Mar 2013 18:41:09 -0700 (PDT) In-Reply-To: <5E4DF003-1BDB-4BC2-AE6C-BDD60D132343@muada.com> References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> <514C77BD.9090708@ericsson.com> <5E4DF003-1BDB-4BC2-AE6C-BDD60D132343@muada.com> From: Lorenzo Colitti Date: Mon, 25 Mar 2013 10:41:09 +0900 Message-ID: To: Iljitsch van Beijnum Content-Type: multipart/alternative; boundary=e89a8ff1c2d85ff74d04d8b5e781 X-Gm-Message-State: ALoCoQk7DpIIsQXrjKEWMlT1qFS8Ye6ZZbuo5hCK6ZXtbwvC+/1QdgTWKxgTFjyrOhoHGgCMFG3XlxOrZ0j3R8ZJYkqeylgK9zVnUA9hoKDM4c2H9/5HZsnAhQlAL9+3JymYFe0DZYpw6W4PDro16CSjjE3DSjrbythSQGfXK+fJRx3yqj5s9I0xouOImqnoaWoxzX+M5pfd Cc: IPv6 Ops WG Subject: Re: [v6ops] RFC 6732 can't work, was: draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 01:41:30 -0000 --e89a8ff1c2d85ff74d04d8b5e781 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 25, 2013 at 6:17 AM, Iljitsch van Beijnum wrote: > > I think a short summary of 6to4 Provider Managed Tunnels (RFC6732) would > > be useful here for completeness. > > I'm surprised this was published as an RFC without a big fat IAB/IESG > warning. Or at all, really. This obviously isn't "informational", but > experimental in disguise. > RFC 6732 is an independent submission. It was taken to v6ops, but there was significant opposition to it, and the authors went the individual submission route. I agree it should not be cited by any v6ops document. --e89a8ff1c2d85ff74d04d8b5e781 Content-Type: text/html; charset=ISO-8859-1
On Mon, Mar 25, 2013 at 6:17 AM, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
> I think a short summary of 6to4 Provider Managed Tunnels (RFC6732) would
> be useful here for completeness.

I'm surprised this was published as an RFC without a big fat IAB/IESG warning. Or at all, really. This obviously isn't "informational", but experimental in disguise.

RFC 6732 is an independent submission. It was taken to v6ops, but there was significant opposition to it, and the authors went the individual submission route. I agree it should not be cited by any v6ops document.
--e89a8ff1c2d85ff74d04d8b5e781-- From victor@jvknet.com Sun Mar 24 19:42:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC0521F8E1A for ; Sun, 24 Mar 2013 19:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.67 X-Spam-Level: X-Spam-Status: No, score=-0.67 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, FH_RELAY_NODNS=1.451, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.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 n1nlR7Ogk0dj for ; Sun, 24 Mar 2013 19:42:05 -0700 (PDT) Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id E9BF521F8E15 for ; Sun, 24 Mar 2013 19:42:04 -0700 (PDT) Received: by mail-ia0-f178.google.com with SMTP id r13so4152430iar.9 for ; Sun, 24 Mar 2013 19:42:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding:x-gm-message-state; bh=CXFPE6D/dSCKOoaZD1JN7HlDgJWppQyZQm14WLHU+ic=; b=JquRMLp9c2RLJ6ZmRaI2WV3+CWjkzosj4zpYMf8ya9qExM7GwJrBIdg0WkrDrA/BDd pgGBEfNja3AOZKdeIzIV9+kZi6FxRemdlqKbkLHQnA8jP6oXVcGf0LgzPlV8fbB1OvcQ RNWqjoK7vevBkPpz6pZj+5GQ1wV8clCuM+zNDt7uxoS/exu6kqdbx1ijKjgbtREUD9Tl 0l1+CYDfCeZ1ZoNym+ip0ziUXyNsLYaypTOvuKXhCjHt2gfbIaUwG6iINWs7gv53rcR7 AojN5/oRlBw+Mxfc3VaPEVgF4kOWTKcqvoYIFs8ieDNzxk2RHc/KkZtQOEvsIcYlrARp XloQ== X-Received: by 10.50.154.129 with SMTP id vo1mr9963910igb.93.1364179324296; Sun, 24 Mar 2013 19:42:04 -0700 (PDT) Received: from [192.168.100.70] ([67.224.83.162]) by mx.google.com with ESMTPS id a3sm14179558igq.5.2013.03.24.19.42.02 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 24 Mar 2013 19:42:03 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Sun, 24 Mar 2013 22:41:59 +0100 From: Victor Kuarsingh To: Iljitsch van Beijnum , Suresh Krishnan Message-ID: Thread-Topic: [v6ops] RFC 6732 can't work, was: draft-steffann-tunnels-00.txt In-Reply-To: <5E4DF003-1BDB-4BC2-AE6C-BDD60D132343@muada.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQnajtfzxh2yPyLtE4oEEe41udfQNTGE6NeQkuMRfCBk10SxeaH5CSsxiyN/g265dBMd1Y9c Cc: IPv6 Ops WG Subject: Re: [v6ops] RFC 6732 can't work, was: draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 02:42:05 -0000 On 2013-03-24 10:17 PM, "Iljitsch van Beijnum" wrote: >Hi Suresh, > >I'll reply to the rest of your message later. But: > >On 22 mrt 2013, at 16:24, Suresh Krishnan >wrote: > >> I think a short summary of 6to4 Provider Managed Tunnels (RFC6732) would >> be useful here for completeness. > >I'm surprised this was published as an RFC without a big fat IAB/IESG >warning. Or at all, really. This obviously isn't "informational", but >experimental in disguise. 6to4-PMT has been in production for over two years and about 1.5 years before it was published - ISE stream not working group (as noted by Lorenzo). > >Besides being a very bad idea on many levels, I don't even think this can >work. It's been successful and has significantly reduced 6to4 issues in our network. Basic premise in the beginning was Native IPv6 tunnelled IPv6 PMT Broken IPv6 (so when broken/poor IPv6 was the alternative, then PMT is better then that). In general I dislike NATs, but NATs are better then broken IP connectivity (at least, that's what the customers seem to think- they don't seem to care much on how we un-break them). > >What if node A, which has real 6to4 at 2002:1000:1::/48 wants to >communicate with node B, which has fake 6to4 prefix 2002:6440:1::/48 >which maps to 2001:db8:6400:1::/64? > >B sends a packet to A, bypassing the relay/translator, as A and B both >share the "directly connected" subnet 2002::/16. As such, B's prefix >isn't translated, and A sends back an encapsulated IPv6 packet to >100.64.0.1, which of course never makes it because that address is not >globally unique. The case above is based on using IPv4 space for endpiont addressing which is not globally routed (includes RFC6598 and any squat or un-routed non-RFC1918 space). In such a case, the PMT function would be co-located with the CGN (since you need that for global connectivity anyway). So if node b sends packet to node a, it would be prefix translated. You are correct that if node A sends a packet to node b's 6to4 address (based on RFC6598 in that case), it's broken. But it was broken before anyway. I am by no means attempting to have draft-steffann-tunnels include PMT - I really don't care. PMT is in production, works and will be there until 6to4 issues are gone. There will be some corner cases which are not fixed, but remember this was about making something that was broken work again (not make something good - that's what native IPv6 is for). As for the draft text, I think the warning part of section 3.5 (6to4) should include not just RFC6598, but also IPv4 space which may be used that is not routed (squat or otherwise). Regards, Victor K > >Iljitsch >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Sun Mar 24 20:30:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5235D21F8DC5 for ; Sun, 24 Mar 2013 20:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.917 X-Spam-Level: X-Spam-Status: No, score=-101.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCjRclXSO6Fs for ; Sun, 24 Mar 2013 20:30:51 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id D867221F8DA2 for ; Sun, 24 Mar 2013 20:30:50 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id eh20so5464370obb.8 for ; Sun, 24 Mar 2013 20:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=20MUQE+3U0o/p+Wz/4S5OvzJvhkvo+IyRyloLYH6Axo=; b=mb6EGFgspz8kB6FMqLxthBJUGoV3QsyjmpTEZF1PglPksgQ+7Sb4OzDeiK6LQUy8NY QMwRaC0gNiIe68Gjf1UBsYPX2/wuKIa5bm9JN1I5h/enZ9ztQlNCyaASMr9KVYrj8vnD qCpJghZeStS6LFYXjHin4g7oiUn/DxamVuJ86f0x8yCbbR5sQluPHXJK2vDQP+30/Bw5 fAtAx9dQb2vrnrWFY/WyJHHmp4cXSV86jeJPpvqhloNfy2OdHeFUYBcCtWqp+1FthQL5 D+X2Zi7PwS/jdzWgXT/NYI+J8tqrCr4L1qm99uGIJwePNjOidjJanu13kqCvL8RIAuky Acjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=20MUQE+3U0o/p+Wz/4S5OvzJvhkvo+IyRyloLYH6Axo=; b=oYitlmQOCi1Il+HwdkvfWfItcZ+x1vX6U1sxpMkoJRTeDvpzX7uR8jG0rUxIvVrOKY nqKzsl3au8F3VBvPo6IRQcmDEELIqEigvM2SdUJ457Gf+amoDj3d3NtONQnp6jZJgRc7 sUi04687OAwVG8a2jwl1e52AkfWQlQgit4KG/aEorrF8tFMw9Tis31DOg4Yr2Af7+COV rIpTgh6xDCs3gSs1phS2V4lrebE/Z0dySL2veThDn7+CPR1Lzj5+Qio+ucRs2BgXsx0+ umh9qbh9ypHFQ+XyXsGoWM1m97gaZCgo03crAvGIr0oc2g20yy7A3c3zd82JYKboBZ2U xk6g== X-Received: by 10.60.171.167 with SMTP id av7mr9451753oec.77.1364182250398; Sun, 24 Mar 2013 20:30:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Sun, 24 Mar 2013 20:30:30 -0700 (PDT) In-Reply-To: References: <5E4DF003-1BDB-4BC2-AE6C-BDD60D132343@muada.com> From: Lorenzo Colitti Date: Mon, 25 Mar 2013 12:30:30 +0900 Message-ID: To: Victor Kuarsingh Content-Type: multipart/alternative; boundary=bcaec5523fe871cddc04d8b76ece X-Gm-Message-State: ALoCoQlbdCt8coO0raf1DcOjrbJVtYItkRKoSpv2FMh0imkxjSfdRNr+CmeEeb8KzAOhVFh4zS1hXFDoqvGf09PniQApgB8IHLvJyJtZYyMlxAkPxqt/os9JHcv8exsdIz1uUB++YFDzyAdWRzVhfFhoK+Q4MyWZBl6LDWfXDl+eJRW0rgToKACvLGtB+MBpIwu7O0UQHG4s Cc: IPv6 Ops WG Subject: Re: [v6ops] RFC 6732 can't work, was: draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 03:30:51 -0000 --bcaec5523fe871cddc04d8b76ece Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 25, 2013 at 6:41 AM, Victor Kuarsingh wrote: > PMT is in production, works and will be there until 6to4 issues are gone. > There will be some corner cases which are not fixed, but remember this > was about making something that was broken work again (not make something > good - that's what native IPv6 is for). > Out of curiosity, do you have usage stats from your production deployment? What percentage of users actually uses this, and has that percentage been rising or falling? I'd be very interesting in seeing those numbers. --bcaec5523fe871cddc04d8b76ece Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 25, 2013 at 6:41 AM, Victor Kuarsingh <victor= @jvknet.com> wrote:
PMT is in production, works and will be there until=A06to4 issues are gone. =A0There will be some= corner cases which are not=A0fi= xed, but remember this was about making something that was broken work=A0again (not make something good - t= hat's what native IPv6 is for).

Out of curiosity, do you have usage = stats from your production deployment? What percentage of users actually us= es this, and has that percentage been rising or falling? I'd be very in= teresting in seeing those numbers.
--bcaec5523fe871cddc04d8b76ece-- From brian.e.carpenter@gmail.com Mon Mar 25 01:22:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A04921F8CD2 for ; Mon, 25 Mar 2013 01:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.321 X-Spam-Level: X-Spam-Status: No, score=-97.321 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 uYObrRkBGef6 for ; Mon, 25 Mar 2013 01:22:31 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id BC85921F85D7 for ; Mon, 25 Mar 2013 01:22:30 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id hi18so6288990wib.9 for ; Mon, 25 Mar 2013 01:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type; bh=4/iA+sbtEr7l5b/OIyDUWE/PVRWnXnBTtxuAUYvMzrU=; b=IU1tNoMaJW0m7kkmjiebPAMVUqOGe2ivUwfrE+voKTI7ixpChxuQ4xvvkX00GfnvBJ v9wpfmcUlO/K5Dr65t54B1ZcJLU6IEO270rY/K379L+AX7agjaQW13vTbw/sovvr/FDI GZ/ll6riUdvPNBOuxP4VKS1LJL7abkQj7M5s0RkIZgBH47D4cdsS8SAWBDt5a2eyhQBG H2jHWPoNFX/FOCvDx5NaMKyJc2NJETXJihUCh/ohnqI+PWJvspoiW20PT61iCmTvQ2BE vH3Da7hyncdalA9zD208BX+IZ6Nkg6G+NjHN8QNWLmPd04WUOAFPsI3D1eBYJEhVBRG2 YzQg== X-Received: by 10.194.122.131 with SMTP id ls3mr16102616wjb.55.1364199749555; Mon, 25 Mar 2013 01:22:29 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-188-117.as13285.net. [2.101.188.117]) by mx.google.com with ESMTPS id q13sm31480080wie.0.2013.03.25.01.22.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Mar 2013 01:22:28 -0700 (PDT) Message-ID: <51500946.6030304@gmail.com> Date: Mon, 25 Mar 2013 08:22:30 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> <514C77BD.9090708@ericsson.com> <5E4DF003-1BDB-4BC2-AE6C-BDD60D132343@muada.com> In-Reply-To: <5E4DF003-1BDB-4BC2-AE6C-BDD60D132343@muada.com> Content-Type: multipart/mixed; boundary="------------010503010905060806000209" Cc: IPv6 Ops WG Subject: Re: [v6ops] RFC 6732 can't work, was: draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 08:22:33 -0000 This is a multi-part message in MIME format. --------------010503010905060806000209 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Iljistch, Did you read the "Status of This Memo" section? I don't see why the IESG would have added anything more. I was the reviewer for the Independent Series Editor for this document. fyi, I have attached my review - some changes were made as a result. But basically this is like any other Independent Submission describing running code that is not a candidate for IETF publication. Regards Brian --------------010503010905060806000209 Content-Type: text/plain; name="draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-05-carpenter.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-05-carpen"; filename*1="ter.txt" SSBoYXZlIGJlZW4gYXNrZWQgdG8gcmV2aWV3IHRoaXMgZHJhZnQgYXMgYW4gSW5kZXBlbmRl bnQgU3VibWlzc2lvbg0KdG8gdGhlIFJGQyBFZGl0b3IuDQoNCkRvY3VtZW50OiBkcmFmdC1r dWFyc2luZ2gtdjZvcHMtNnRvNC1wcm92aWRlci1tYW5hZ2VkLXR1bm5lbC0wNS50eHQgDQpS ZXZpZXdlcjogQnJpYW4gQ2FycGVudGVyDQpSZXZpZXcgRGF0ZTogMjAxMi0wMy0wNg0KDQpE aXNjbG9zdXJlOg0KLS0tLS0tLS0tLS0NCg0KSSdtIGNvLWF1dGhvciBvZiB0aGUgb3JpZ2lu YWwgNnRvNCBzcGVjIChSRkMgMzA1NikgYW5kIGF1dGhvciBvZiB0aGUNCnJlY2VudCA2dG80 IGhlYWx0aCB3YXJuaW5nIChSRkMgNjM0MykuDQoNClN1bW1hcnk6ICANCi0tLS0tLS0tDQoN ClRoaXMgaXMgYSB3ZWxsLXdyaXR0ZW4gZGVzY3JpcHRpb24gb2YgYSBydW5uaW5nLWNvZGUg c29sdXRpb24gZm9yIG9uZSANCnBhcnRpY3VsYXIgZm9ybSBvZiBJUHY2L0lQdjQgY29leGlz dGVuY2UgdGhhdCBoYXMgbm90IG1hZGUgaXQgaW4gdGhlIElFVEYuDQpJIGJlbGlldmUgaXQg c2hvdWxkIGJlIHB1Ymxpc2hlZCBhcyBhbiBJbmRlcGVuZGVudCBTdWJtaXNzaW9uLg0KDQpI b3dldmVyLCBJJ2QgbGlrZSBhbiBhbnN3ZXIgYWJvdXQgdHJhbnNwb3J0IGNoZWNrc3VtcyBh bmQgQUxHcyBmaXJzdC4NCg0KSUVURiBhc3BlY3Q6IA0KLS0tLS0tLS0tLS0tDQoNClRoaXMg ZHJhZnQgd2FzIGZpcnN0IHBvc3RlZCBmb3IgdGhlIHY2b3BzIFdHIGluIE9jdG9iZXIgMjAx MC4gSXQgYWxzbyBvdmVybGFwcw0Kc29tZXdoYXQgd2l0aCB0aGUgc29mdHdpcmVzIFdHIGFu ZCB0b3VjaGVzIG9uIHRoZSBiZWhhdmUgV0cuIEl0IGRpZG4ndCBtZWV0DQpmYXZvdXIgaW4g djZvcHMgKEkgd2FzIG9uZSBvZiB0aGUgbmF5LXNheWVycykuIFdlIGhhdmUgaXNzdWVkIGFu IGluZm9ybWF0aXZlDQpyZWNvbW1lbmRhdGlvbiB0byBkaXNhYmxlIDZ0bzQgYnkgZGVmYXVs dCAoUkZDIDYzNDMpYW5kIHRoYXQgc2VlbXMgdG8gYmUgYXMNCmZhciBhcyB0aGUgSUVURiB3 YW50cyB0byBnby4gSSBwZXJzb25hbGx5IGRvbid0IHNlZSBhbnkgZGFtYWdlIHRvIElFVEYg d29yaw0KZnJvbSB0aGlzIGRvY3VtZW50LCBob3dldmVyLg0KDQpUZWNobmljYWwgcmV2aWV3 Og0KLS0tLS0tLS0tLS0tLS0tLS0NCg0KNnRvNCwgdXNpbmcgYSBkZWZhdWx0IElQdjQgYW55 Y2FzdCBhZGRyZXNzIGZvciB0aGUgcmVsYXkgdG8gbmF0aXZlIElQdjYNCihSRkMgMzA2OCks IHN1ZmZlcnMgZnJvbSBzZXJpb3VzIG9wZXJhdGlvbmFsIHByb2JsZW1zLiBUaGlzIHByb3Bv c2FsICgiUE1UIikNCmNsYWltcyB0byBhdm9pZCB0aG9zZSBwcm9ibGVtcy4gSXQgaXMgYXNz dW1lZCB0aGF0IHRoZSB1c2VyJ3MgSVNQIGhhcyBJUHY2DQpzdXBwb3J0LCBidXQgdGhhdCB0 aGUgdXNlciBvbmx5IGhhcyBhbiBJUHY0IENQRS4gRmlyc3RseSwgdGhlIElTUCBwcm92aWRl cyBhDQptYW5hZ2VkIDZ0bzQgcmVsYXkgcmVzcG9uZGluZyB0byB0aGUgYW55Y2FzdCBhZGRy ZXNzLiAoUkZDIDYzNDMgcmVjb21tZW5kcw0KdGhpcyB0b28uKSBJbiB0aGUgUE1UIG1vZGVs LCB0aGUgcmVsYXkgYWxzbyAqdHJhbnNsYXRlcyogdGhlIDZ0bzQgcHJlZml4IG9mIHRoZQ0K Y2xpZW50J3MgSVB2NiBhZGRyZXNzIGludG8gYSBkaWZmZXJlbnQgUEEgcHJlZml4IGJlbG9u Z2luZyB0byB0aGUgSVNQIGl0c2VsZi4NClRoaXMgbWVhbnMgdGhhdCB0aGUgcmV0dXJuIHBh dGggdG8gdGhlIHVzZXIgaXMgd2VsbCBkZWZpbmVkLCBhbmQgdGhlcmVmb3JlDQp0aGUgcmV0 dXJuLXBhdGggaXNzdWVzIG9mIGFueWNhc3QgNnRvNCBnbyBhd2F5Lg0KDQpOb3RlIHRoYXQg KmFub3RoZXIqIHdheSBvZiByZXVzaW5nIHRoZSB1bmRlcmx5aW5nIGlkZWEgb2YgNnRvNCBp cyA2cmQgKElQdjYNClJhcGlkIERlcGxveW1lbnQgb24gSVB2NCBJbmZyYXN0cnVjdHVyZXMs IFJGQyA1OTY5KSB3aGljaCBpcyBhIFByb3Bvc2VkIA0KU3RhbmRhcmQuIEl0IGRvZXNuJ3Qg aW52b2x2ZSBwcmVmaXggdHJhbnNsYXRpb24gYW5kIGl0IGlzIHN1Y2Nlc3NmdWxseQ0KZGVw bG95ZWQuIEhvd2V2ZXIsIGl0IGludm9sdmVzIHVwZGF0ZXMgdG8gdGhlIFNPSE8gdXNlcidz IENQRSBmaXJtd2FyZS4NClBNVCBpcyBpbnRlbmRlZCB0byB3b3JrIHdpdGggSVB2NC1vbmx5 IENQRSBhbmQgZXhpc3RpbmcgaG9zdHMgdGhhdA0Kc3VwcG9ydCBhbnljYXN0IDZ0bzQuIFBN VCBpcyB0aGVyZWZvcmUgaW50ZXJlc3RpbmcgdG8gSVNQcyB0aGF0IGNhbm5vdA0KdXBkYXRl IHRoZWlyIHN1YnNjcmliZXJzJyBDUEVzIGFuZCB3aXNoIHRvIG9mZmVyIGFuIElQdjYgc2Vy dmljZSB0bw0KYW55IHVzZXJzIHRoYXQgZW5hYmxlIDZ0bzQgKG9yIGhhdmUgaXQgZW5hYmxl ZCBieSBkZWZhdWx0KS4gVGhlIGRvd25zaWRlDQppcyBwcmVmaXggdHJhbnNsYXRpb24sIG11 Y2ggZGlzbGlrZWQgaW4gdGhlIElFVEYuDQoNCkFub3RoZXIgYWR2YW50YWdlIG9mIFBNVCBp cyB0aGF0IGl0IHdpbGwgd29yayBldmVuIGlmIHRoZSBJU1AgaXMgdXNpbmcNCm5vbi1nbG9i YWwgSVB2NCBhZGRyZXNzIHNwYWNlIChlLmcgUkZDIDE5MTggc3BhY2Ugb3IgdGhlIGluZmFt b3VzDQpkcmFmdC13ZWlsLXNoYXJlZC10cmFuc2l0aW9uLXNwYWNlLXJlcXVlc3Qgc3BhY2Up IHRvIHN1cHBvcnQgY3VzdG9tZXJzLg0KSW4gb3RoZXIgd29yZHMsIHVubGlrZSBSRkMgMzA2 OCwgaXQgd2lsbCB3b3JrIGV2ZW4gaW4gdGhlIHByZXNlbmNlIG9mDQphIENHTi4NCg0KVGhl IGRyYWZ0IGlzIHdlbGwgd3JpdHRlbiBhbmQgZGVzY3JpYmVzIHJ1bm5pbmcgY29kZS4gSXQg d2Fzbid0IGxpa2VkDQppbiB0aGUgSUVURiBiZWNhdXNlIGl0IHByZXNzZWQgdGhyZWUgYWxh cm0gYnV0dG9ucyAocHJlZml4IHRyYW5zbGF0aW9uLA0KQ0dOIGFuZCBzaGFyZWQgYWRkcmVz cyBzcGFjZSkgYW5kIGJlY2F1c2UgdGhlIElFVEYgYWxyZWFkeSBoYXMgYSBtZW5hZ2VyaWUN Cm9mIElQdjYvSVB2NCBjb2V4aXN0ZW5jZSBzb2x1dGlvbnMuDQoNCk9uZSBpc3N1ZSwgaG93 ZXZlciwgbGVhdmVzIG1lIHB1enpsZWQuIFRoZSB0ZXh0IHNheXMgIklQdjYgUHJlZml4IA0K VHJhbnNsYXRpb24gaGFzIHNvbWUgc2ltaWxhcml0aWVzIHRvIGNvbmNlcHRzIGRpc2N1c3Nl ZCBpbiBbUkZDNjI5Nl0uIg0KVGhhdCBSRkMgaXMgYWxsIGFib3V0IHByZWZpeCB0cmFuc2xh dGlvbiwgc28gdGhhdCBzZW50ZW5jZSBtYWtlcyBubw0Kc2Vuc2UuIFJGQyA2Mjk2IHVzZXMg dGhlIHdvcmQgImNoZWNrc3VtIiBtb3JlIHRoYW4gNTAgdGltZXMsIGJlY2F1c2UNCmEgbWFq b3IgcHJvYmxlbSBpbiBwcmVmaXggdHJhbnNsYXRpb24gaXMgaGFuZGxpbmcgdGhlIHRyYW5z cG9ydCBjaGVja3N1bSwNCndoaWNoIHVzdWFsbHkgbmVlZHMgdG8gYmUgYWRqdXN0ZWQuIEhv dyBjb21lIFBNVCBkb2Vzbid0IG1lbnRpb24gdHJhbnNwb3J0DQpjaGVja3N1bXMgb25jZT8g QWxzbywgaG93IGNhbiBpdCBhdm9pZCBBTEdzIGZvciBjZXJ0YWluIHByb3RvY29scyAoc3Vj aA0KYXMgRlRQIFBTVik/DQoNCk5pdHMNCi0tLS0NCg0KY29uZmlndWF0aW9ucw0KaW50ZXJk b3JtYWluDQoNCg== --------------010503010905060806000209-- From lorenzo@google.com Mon Mar 25 04:31:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306CE21F8BE7 for ; Mon, 25 Mar 2013 04:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWhsPY0XFw5j for ; Mon, 25 Mar 2013 04:31:34 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id BADDD21F8BE4 for ; Mon, 25 Mar 2013 04:31:34 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id er7so2274207obc.35 for ; Mon, 25 Mar 2013 04:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=3q558DX0foCI6GbyZFgEGq8uBVvFfcW/s2A8FnOV5+Q=; b=BR/vI7XLFcV5iGGMTbwP09nnvKUCtl2AWgULiszwNK9pp4eSfgIbeLv5TaHUAcNSym aI8M975tSY2cuQi2+Htlnqo7fgaEUBBvnLAsRRivxJinPt82tT2WFw1VhNogP/2rB/YU hTa3dTJhD5ENI1KqEcVZXpQujmNC+YJIVwFfpR33alPWbRvsUnsmunNRwxrHCLwOXyEN nnvRDMLbGjZxz5g0wQcNwfgOQ3cRalqb1HbPgBWLwJ+m8GEoElEyX7FBclEvsiJha32e toQ1v4sCiDKZ5hsZJgVQfSZARYwHjXeUNordG2CPOc2UPC/L7TUIE8D3kJ+Jsxd3eDls fvSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=3q558DX0foCI6GbyZFgEGq8uBVvFfcW/s2A8FnOV5+Q=; b=M+BIMHd3tfwsQu/V5E5yP37QWhgS+hKD5MCKrg7VYxnzsEoIfZBmu5rdaKs3D/dxPg oEnNgD6j3rQwmksXB4sYiSuD4vywS4JyeSQIah/3k1D2EsyV5Rwf3Kr3OJzo+xmVuXFn afMuETWRpSHah9XaNPSClQfjwP2Y/1EtcFxtwDASXBBZyEoe1mNg+kgcmcd6xSheALOb qPudjO1jiWbsRWVxhjaOAP8/Uwx38Q/5MuW4DrRgamUfca3QGj8rEswSdBC0t7OlqI9U hPk6CeQ1OnjcuIVYgYHD1uafL68s0h8WdepULIBSShPh5k3LfKju9rDchtZq16Z7so3W GWfA== X-Received: by 10.60.170.140 with SMTP id am12mr10511926oec.125.1364211094159; Mon, 25 Mar 2013 04:31:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Mon, 25 Mar 2013 04:31:14 -0700 (PDT) In-Reply-To: <514DFA47.1020705@gmail.com> References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149C642.6060806@gmail.com> <481173D1-2F02-4B80-8E2C-BE33009EF2C9@delong.com> <514B116E.9070504@gmail.com> <514B14C2.3050303@gmail.com> <514B8598.6090401@bogus.com> <2134F8430051B64F815C691A62D98318036EC8@XCH-BLV-504.nw.nos.boeing.com> <2EFC0D07-DA29-46F7-92E7-FA4C69ACF95F@merike.com> <2134F8430051B64F815C691A62D98318037A52@XCH-BLV-504.nw.nos.boeing.com> <514DFA47.1020705@gmail.com> From: Lorenzo Colitti Date: Mon, 25 Mar 2013 04:31:14 -0700 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=bcaec54b4812aaf2d604d8be2551 X-Gm-Message-State: ALoCoQlTsR5FHoPG986pN6Qjvu0NqeSNnzx+x4tupc/+DBHGgb0X5FqQw1/qMEiP6n5cCsQ8HAi8jEr+tZOMvJKYuTNXM6bHozRp+SonBKxZvzPHN/LHzv5LkYGukv1t9K6c13WEmMJDnt2HaNGtpoMBU3e1Up7KYWoC3MrAYjvL9BwQbvY4Q0coUes5oSOSPRXtP7Olrr2s Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 11:31:35 -0000 --bcaec54b4812aaf2d604d8be2551 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Mar 23, 2013 at 11:53 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > When NAT IPv4 is used on-board of these vehicles, there is probably no > routing churn (the onboard addresses are not propagated to the > infrastructure), and probably little need for Mobile IP. > I very much doubt it, because your connections would be interrupted all the time. Next time, try keeping an SSH connection open on the train. If it doesn't get reset, then no IP addresses are changing. --bcaec54b4812aaf2d604d8be2551 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Mar 23, 2013 at 11:53 AM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
When NAT IPv4 is = used on-board of these vehicles, there is probably no
routing churn (the onboard addresses are not propagated to the
infrastructure), and probably little need for Mobile IP.

I very much doubt it, because your connections woul= d be interrupted all the time. Next time, try keeping an SSH connection ope= n on the train. If it doesn't get reset, then no IP addresses are chang= ing.=A0
--bcaec54b4812aaf2d604d8be2551-- From holger.metschulat@telekom.de Mon Mar 25 05:19:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98EC21F88CF for ; Mon, 25 Mar 2013 05:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_BACKHAIR_24=1, J_BACKHAIR_42=1, J_CHICKENPOX_13=0.6, 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 nZ7PaH4dArAJ for ; Mon, 25 Mar 2013 05:19:03 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id F21E221F8930 for ; Mon, 25 Mar 2013 05:19:01 -0700 (PDT) From: Received: from he113497.emea1.cds.t-internal.com ([10.206.92.154]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 25 Mar 2013 13:18:54 +0100 Received: from HE111490.emea1.cds.t-internal.com ([10.206.92.87]) by HE113497.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 25 Mar 2013 13:18:53 +0100 To: Date: Mon, 25 Mar 2013 13:18:52 +0100 Thread-Topic: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 Thread-Index: Ac4gZBPpeSjz2MlhR8mH1bow9wGq6AI7jklA Message-ID: References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> <513E61B2.2000307@gmail.com> <513F18FF.2060700@gmail.com> <513F8F69.2050204@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA141E89@SRVHKE02.rdm.cz> <514143B7.20002@gmail.com> In-Reply-To: <514143B7.20002@gmail.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 12:19:04 -0000 Alexandru, the gateway only sees the link as the next-hop, as it is a P2P link: Prefix Next-hop Device 2001:db8:1:1::/64 :: GTPtunnel0 Such a scenario Prefix Next-hop Device 2001:db8:1:1::/64 00:aa:bb:cc:dd:ee GTPtunnel0 would probably exist on the USB dongle interfacing the OS side Ethernet WWA= N interface to the 3GPP P2P interface, but that's implementation specific. = The same way as for IPv4, the USB dongle is absorbing/generating ARP reques= ts towards the OS, and sometimes sets weird netmasks on the IPv4 addresses = issued by DHCP towards the OS. Holger -----Urspr=FCngliche Nachricht----- Von: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] Im Auftrag von = Alexandru Petrescu Gesendet: Donnerstag, 14. M=E4rz 2013 04:28 An: v6ops@ietf.org Betreff: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share= -03 Le 13/03/2013 17:28, jouni korhonen a =E9crit : > > 13.3.2013 9.29 "Mikael Abrahamsson" > kirjoitti: >> >> On Wed, 13 Mar 2013, V=EDzdal Ale=B9 wrote: >> >>> It routes ... the packet core gateway (ggsn/p-gw) is the default =20 >>> router for the UE and the TTL is being decremented by the gateway. > > On the gateway you would probably see the /64 prefix linked to a PDP=20 > Context / PDN connection or a GTP tunnel. Something like: Prefix Next-hop Device 2001:db8:1:1::/64 :: GTPtunnel0 or something like: Prefix Next-hop Device 2001:db8:1:1::/64 fe80::5 GTPtunnel0 If the former, and that PDPContext/PDNconnectio-or-GTPtunnel is MAC-address= able, then 64share wont work. >> Not all GGSN/PGW decrement TTL. When I traceroute from my UE to the >> > Internet, my first hop seen in traceroute is the GUA address of the=20 > first router hop after the PGW: >> >> UE<-GTP->SPGW<-IPv6->PE >> >> So my traceroute hop 1 is the GUA address of the PE. > > This is vendor implementation specific. Very popular but not really=20 > defined in 3gpp specs except for some deprecated stuff. Jouni - this is way too generic to be understandable. (if we want to do any reverse engineering :-) Alex > > - jouni > >> >> -- Mikael Abrahamsson email: swmike@swm.pp.se >> >> >> _______________________________________________ v6ops mailing list=20 >> v6ops@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > > _______________________________________________ v6ops mailing list=20 > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From iljitsch@muada.com Mon Mar 25 05:29:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D6121F8E3E for ; Mon, 25 Mar 2013 05:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdjIzwBB6xNG for ; Mon, 25 Mar 2013 05:29:50 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id C622521F8E15 for ; Mon, 25 Mar 2013 05:29:49 -0700 (PDT) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2PCOkhW008180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Mar 2013 13:24:46 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <51500946.6030304@gmail.com> Date: Mon, 25 Mar 2013 13:29:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3CBB1B6F-DD37-4EAC-BC5D-01FCF5D82413@muada.com> References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> <514C77BD.9090708@ericsson.com> <5E4DF003-1BDB-4BC2-AE6C-BDD60D132343@muada.com> <51500946.6030304@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1499) Cc: IPv6 Ops WG Subject: Re: [v6ops] RFC 6732 can't work, was: draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 12:29:50 -0000 On 25 mrt 2013, at 9:22, Brian E Carpenter = wrote: > Did you read the "Status of This Memo" section? I don't really read those, they're boilerplate. And I believe that the = text in this instance is identical to that of other independent = submissions, which takes any bite that it may have had out of it. > I don't see why the IESG would have added anything more. Something similar to here: http://tools.ietf.org/html/rfc5572 "This work was considered in the IETF but rejected" Remember that most people don't appreciate details such as = IETF/independent or standards track/experimental/informational, an RFC = number conveys a lot of authority. As such, a very explicit warning = would have been appropriate. > I was the reviewer for the Independent Series Editor for this = document. > fyi, I have attached my review - some changes were made as a result. > But basically this is like any other Independent Submission describing > running code that is not a candidate for IETF publication. Other than the obvious issue, I find it troublesome that this RFC = doesn't cover the case of communication between a host behind a PMT and = a regular 6to4 host. This can easily be solved by intercepting all = protocol 41 packets in the CGN, but for some reason this issue is left = out of the document, making this "solution" even worse than in needs to = be, and also withholding vital information from the readers of the = document. And a better solution for the "who left the 6to4 on" problem would be to = run a gateway that returns network unreachables, which should make hosts = retry over IPv4. Iljitsch= From alexandru.petrescu@gmail.com Mon Mar 25 05:32:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163FF21F8ECB for ; Mon, 25 Mar 2013 05:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8BGchJN60No for ; Mon, 25 Mar 2013 05:32:02 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 83E7B21F8EAE for ; Mon, 25 Mar 2013 05:32:02 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2PCVtA8024257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Mar 2013 13:31:55 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2PCVtKu003782; Mon, 25 Mar 2013 13:31:55 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2PCVo5M011339; Mon, 25 Mar 2013 13:31:55 +0100 Message-ID: <51504383.60003@gmail.com> Date: Mon, 25 Mar 2013 13:30:59 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Lorenzo Colitti References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514977CF.9030806@gmail.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149C642.6060806@gmail.com> <481173D1-2F02-4B80-8E2C-BE33009EF2C9@delong.com> <514B116E.9070504@gmail.com> <514B14C2.3050303@gmail.com> <514B8598.6090401@bogus.com> <2134F8430051B64F815C691A62D98318036EC8@XCH-BLV-504.nw.nos.boeing.com> <2EFC0D07-DA29-46F7-92E7-FA4C69ACF95F@merike.com> <2134F8430051B64F815C691A62D98318037A52@XCH-BLV-504.nw.nos.boeing.com> <514DFA47.1020705@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 12:32:09 -0000 Le 25/03/2013 12:31, Lorenzo Colitti a écrit : > On Sat, Mar 23, 2013 at 11:53 AM, Alexandru Petrescu > > > wrote: > >> When NAT IPv4 is used on-board of these vehicles, there is probably >> no routing churn (the onboard addresses are not propagated to the >> infrastructure), and probably little need for Mobile IP. >> > > I very much doubt it, because your connections would be interrupted > all the time. Next time, try keeping an SSH connection open on the > train. If it doesn't get reset, then no IP addresses are changing. Well, somehow equivalent to ssh - I googled 'what is my IP address' while in the train, while the train was handed over from the WiFi in the railway station to the 3G outdoors (as noticed in the RTT change of ping). The IP address 'of the train' did not change, neither the IP address of my laptop. That means to me a form of Mobile IP was used by the train's Gateway, or other dynamic VPN registration. Even if Mobile IP were not used, nor VPN re-registration, the IP address of my laptop would have been stable, because it is a NAT. It would be unnatural for these Gateways to re-DHCP allocate the NATed addresses to Clients when the Gateway was handed over. Alex From alexandru.petrescu@gmail.com Mon Mar 25 05:39:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A6921F8CC9 for ; Mon, 25 Mar 2013 05:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.949 X-Spam-Level: X-Spam-Status: No, score=-8.949 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_BACKHAIR_24=1, J_BACKHAIR_42=1, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ur4lgOIJTnVw for ; Mon, 25 Mar 2013 05:39:09 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 421DE21F8CAA for ; Mon, 25 Mar 2013 05:39:09 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2PCd4ED029873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 25 Mar 2013 13:39:05 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2PCd4Ah006618 for ; Mon, 25 Mar 2013 13:39:04 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2PCcx47015070 for ; Mon, 25 Mar 2013 13:39:04 +0100 Message-ID: <51504530.1010002@gmail.com> Date: Mon, 25 Mar 2013 13:38:08 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <513E16C5.5090508@gmail.com> <513E24EC.9020902@gmail.com> <20130311184222.GI51699@Space.Net> <513E27BD.50005@gmail.com> <513E3F4F.1010903@gmail.com> <20130311215327.GK51699@Space.Net> <513E61B2.2000307@gmail.com> <513F18FF.2060700@gmail.com> <513F8F69.2050204@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6DA141E89@SRVHKE02.rdm.cz> <514143B7.20002@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 12:39:10 -0000 Le 25/03/2013 13:18, holger.metschulat@telekom.de a écrit : > Alexandru, > > the gateway only sees the link as the next-hop, as it is a P2P link: > > Prefix Next-hop Device > 2001:db8:1:1::/64 :: GTPtunnel0 Thanks! This is good to know. For this case, the 64share method on the Smartphone will work ok. > Such a scenario > > Prefix Next-hop Device > 2001:db8:1:1::/64 00:aa:bb:cc:dd:ee GTPtunnel0 I meant the Next-hop an IPv6 address, not a MAC address. From this on there are three other possibilities that could be reversely engineered. Depending on that, the 64share works or not. > would probably exist on the USB dongle interfacing the OS side > Ethernet WWAN interface to the 3GPP P2P interface, but that's > implementation specific. The same way as for IPv4, the USB dongle is > absorbing/generating ARP requests towards the OS, and sometimes sets > weird netmasks on the IPv4 addresses issued by DHCP towards the OS. I didnt know USB dongle would generate also ARP requests (in addition to ND). This is good to know for a potential version IPv4 version of 64share. Alex > > > Holger > > -----Ursprüngliche Nachricht----- > Von: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] Im Auftrag von Alexandru Petrescu > Gesendet: Donnerstag, 14. März 2013 04:28 > An: v6ops@ietf.org > Betreff: Re: [v6ops] Mic comments on link model in draft-ietf-v6ops-64share-03 > > Le 13/03/2013 17:28, jouni korhonen a écrit : >> >> 13.3.2013 9.29 "Mikael Abrahamsson" > > kirjoitti: >>> >>> On Wed, 13 Mar 2013, Vízdal Ale¹ wrote: >>> >>>> It routes ... the packet core gateway (ggsn/p-gw) is the default >>>> router for the UE and the TTL is being decremented by the gateway. >> >> On the gateway you would probably see the /64 prefix linked to a PDP >> Context / PDN connection or a GTP tunnel. > > Something like: > > Prefix Next-hop Device > 2001:db8:1:1::/64 :: GTPtunnel0 > > or something like: > > Prefix Next-hop Device > 2001:db8:1:1::/64 fe80::5 GTPtunnel0 > > If the former, and that PDPContext/PDNconnectio-or-GTPtunnel is MAC-addressable, then 64share wont work. > >>> Not all GGSN/PGW decrement TTL. When I traceroute from my UE to the >>> >> Internet, my first hop seen in traceroute is the GUA address of the >> first router hop after the PGW: >>> >>> UE<-GTP->SPGW<-IPv6->PE >>> >>> So my traceroute hop 1 is the GUA address of the PE. >> >> This is vendor implementation specific. Very popular but not really >> defined in 3gpp specs except for some deprecated stuff. > > Jouni - this is way too generic to be understandable. > > (if we want to do any reverse engineering :-) > > Alex > >> >> - jouni >> >>> >>> -- Mikael Abrahamsson email: swmike@swm.pp.se >>> >>> >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From tjc@ecs.soton.ac.uk Mon Mar 25 05:49:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD8C21F898A for ; Mon, 25 Mar 2013 05:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEYPKVUmaBmC for ; Mon, 25 Mar 2013 05:49:15 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 75D4021F892D for ; Mon, 25 Mar 2013 05:49:15 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r2PCn1Oc032496; Mon, 25 Mar 2013 12:49:01 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r2PCn1Oc032496 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1364215741; bh=wRQrfc53ioBzJBfF7Gkp6EdCRrY=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=0eMoGIp6sfPvdDpPbv4F5ZGHCKqc9XAoWMcXb5GrEQj2vOmBLGzsjEiHLjPmx8gO7 VdRYjb9nkxUCYfM5MCYI1/B28++mWPwCuC9P41nr/A01pXF+jAPjiYQDDwe3Pklq6j ZXjDLTl0e5IJe0FdYXNRB5+Tqlk+i6E2qMymQ4GE= 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 p2OCn10430625650Dm ret-id none; Mon, 25 Mar 2013 12:49:01 +0000 Received: from dhcp-163-132.wireless.soton.ac.uk (dhcp-163-132.wireless.soton.ac.uk [152.78.163.132]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r2PCmwTW010108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Mar 2013 12:48:59 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Tim Chown In-Reply-To: <3CBB1B6F-DD37-4EAC-BC5D-01FCF5D82413@muada.com> Date: Mon, 25 Mar 2013 12:48:58 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> <514C77BD.9090708@ericsson.com> <5E4DF003-1BDB-4BC2-AE6C-BDD60D132343@muada.com> <51500946.6030304@gmail.com> <3CBB1B6F-DD37-4EAC-BC5D-01FCF5D82413@muada.com> <63C97FA6-14BA-4FB7-A056-890472640AF0@ecs.soton.ac.uk> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1503) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p2OCn1043062565000; tid=p2OCn10430625650Dm; 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: r2PCn1Oc032496 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: IPv6 Ops WG Subject: Re: [v6ops] RFC 6732 can't work, was: draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 12:49:16 -0000 On 25 Mar 2013, at 12:29, Iljitsch van Beijnum = wrote: >=20 > Remember that most people don't appreciate details such as = IETF/independent or standards track/experimental/informational, an RFC = number conveys a lot of authority. Indeed. > As such, a very explicit warning would have been appropriate. Well, that is down to the author, unless the individual submission = boilerplates are changed to include a 'health warning'. The key point here though is that draft-steffann-tunnels says the right = thing, which I think it does, without PMT. Tim= From brian.e.carpenter@gmail.com Mon Mar 25 06:16:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096B121F8EFE for ; Mon, 25 Mar 2013 06:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.121 X-Spam-Level: X-Spam-Status: No, score=-98.121 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 xLtu-JJIVm4P for ; Mon, 25 Mar 2013 06:16:25 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1C121F882C for ; Mon, 25 Mar 2013 06:16:25 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hn17so10108617wib.16 for ; Mon, 25 Mar 2013 06:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LJGwR1HE2iKqkr4v0+hP1V4KkFUkf+DhKPQX2yYOtCo=; b=KjwiWJoH+DESOPsPiF7ciCJW/Y81cT7h0OyYe7I4qnZagwFqgPb3iIF6kSWSssRIf6 CKKK32hL41ymc5RvIU3+AXR9flN+DExUxRzz3k0WXiLw+nfZ/Z8DhUHcXZN6JxDLS34w V7/VcKK09BB8D8vYOTA0TDtPMf5Skh/ErvLLcSt1KcpAZizAYjcaBci3GZap6pdaOKyt Nyy2+KoNl8nj/z+meFofZ/iHUFOR4EV9Fh7MFtChxnedN6BrLQkXu1Q+K8ttDpYDt/WF D+LV/cFRJddutUTaLWnRJ3vpvqzR78vW2l+VKVRXz6qKNkSmEP1guN4MBg15PhYzaEoL Df5w== X-Received: by 10.180.74.131 with SMTP id t3mr17186656wiv.26.1364217384226; Mon, 25 Mar 2013 06:16:24 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-188-117.as13285.net. [2.101.188.117]) by mx.google.com with ESMTPS id er1sm19688198wib.5.2013.03.25.06.16.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Mar 2013 06:16:23 -0700 (PDT) Message-ID: <51504E28.8040402@gmail.com> Date: Mon, 25 Mar 2013 13:16:24 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tim Chown References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> <514C77BD.9090708@ericsson.com> <5E4DF003-1BDB-4BC2-AE6C-BDD60D132343@muada.com> <51500946.6030304@gmail.com> <3CBB1B6F-DD37-4EAC-BC5D-01FCF5D82413@muada.com> <63C97FA6-14BA-4FB7-A056-890472640AF0@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] RFC 6732 can't work, was: draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 13:16:26 -0000 On 25/03/2013 12:48, Tim Chown wrote: > On 25 Mar 2013, at 12:29, Iljitsch van Beijnum wrote: >> Remember that most people don't appreciate details such as IETF/independent or standards track/experimental/informational, an RFC number conveys a lot of authority. > > Indeed. To be blunt, "I don't read the boilerplate" is not an excuse for not reading the boilerplate. >> As such, a very explicit warning would have been appropriate. Which is why the boilerplate says what it does. > > Well, that is down to the author, unless the individual submission boilerplates are changed to include a 'health warning'. The IESG can and sometimes does add extra warnings to independent submissions when they decide it's necessary. Iljitsch has pointed out a failure scenario (client behind provider-managed 6to4 contacts host behind standard 6to4). I'm guessing that would break BitTorrent? It sounds like a case for http://www.rfc-editor.org/errata.php > The key point here though is that draft-steffann-tunnels says the right thing, which I think it does, without PMT. Agreed. Brian From sander@steffann.nl Mon Mar 25 06:42:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52A821F8DDE for ; Mon, 25 Mar 2013 06:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 YRJh9H1V+z8o for ; Mon, 25 Mar 2013 06:42:36 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 8D94521F8DD4 for ; Mon, 25 Mar 2013 06:42:36 -0700 (PDT) Received: from [192.168.46.133] (unknown [195.229.62.68]) by mail.sintact.nl (Postfix) with ESMTP id EC528201C; Mon, 25 Mar 2013 14:42:33 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Sander Steffann In-Reply-To: <51504E28.8040402@gmail.com> Date: Mon, 25 Mar 2013 17:42:34 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> <514C77BD.9090708@ericsson.com> <5E4DF003-1BDB-4BC2-AE6C-BDD60D132343@muada.com> <51500946.6030304@gmail.com> <3CBB1B6F-DD37-4EAC-BC5D-01FCF5D82413@muada.com> <63C97FA6-14BA-4FB7-A056-890472640AF0@ecs.soton.ac.uk> <51504E28.8040402@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1503) Cc: IPv6 Ops WG Subject: Re: [v6ops] RFC 6732 can't work, was: draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 13:42:38 -0000 Hi, >> The key point here though is that draft-steffann-tunnels says the = right thing, which I think it does, without PMT. >=20 > Agreed. Thank you all for your feedback on this! Sander From iljitsch@muada.com Mon Mar 25 06:43:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEEE921F8C00 for ; Mon, 25 Mar 2013 06:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTqmQ-5LpOVR for ; Mon, 25 Mar 2013 06:43:55 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 1F39C21F8BED for ; Mon, 25 Mar 2013 06:43:54 -0700 (PDT) Received: from [IPv6:2001:470:1f0b:1289:ad76:6d08:14c2:174a] ([IPv6:2001:470:1f0b:1289:ad76:6d08:14c2:174a]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2PDcDEP008804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Mar 2013 14:38:14 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <51504E28.8040402@gmail.com> Date: Mon, 25 Mar 2013 14:43:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <980A3378-5729-4A50-BA17-B1898D6E2EF5@muada.com> References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> <514C77BD.9090708@ericsson.com> <5E4DF003-1BDB-4BC2-AE6C-BDD60D132343@muada.com> <51500946.6030304@gmail.com> <3CBB1B6F-DD37-4EAC-BC5D-01FCF5D82413@muada.com> <63C97FA6-14BA-4FB7-A056-890472640AF0@ecs.soton.ac.uk> <51504E28.8040402@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1499) Cc: IPv6 Ops WG Subject: Re: [v6ops] RFC 6732 can't work, was: draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 13:43:56 -0000 On 25 mrt 2013, at 14:16, Brian E Carpenter = wrote: > Iljitsch has pointed out a failure scenario (client behind = provider-managed > 6to4 contacts host behind standard 6to4). I'm guessing that would = break > BitTorrent? That's an interesting question. An outgoing session from the PMT user to = the 6to4 user wouldn't work, because the PMT user's 6to4 addresses are = not globally unique and aren't seen by the prefix translator. However, = the PMT user can still receive incoming sessions through the PMT prefix, = but only if the 6to4 user somehow learns that address. And the PMT user = probably doesn't know that address themselves unless the application = uses STUN or something, which it probably won't do for IPv6... Of course everything will still work as long as there is at least one = non-6to4/non-PMT user that can receive incoming sessions participating = in the file transfer. > It sounds like a case for http://www.rfc-editor.org/errata.php I'll see what I can do. Iljitsch= From suresh.krishnan@ericsson.com Mon Mar 25 07:59:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B4311E80BA for ; Mon, 25 Mar 2013 07:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-3EVzKSZcir for ; Mon, 25 Mar 2013 07:59:17 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id E4C2011E80AD for ; Mon, 25 Mar 2013 07:59:13 -0700 (PDT) X-AuditID: c618062d-b7f0d6d00000097e-24-51506641f02d Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 21.90.02430.14660515; Mon, 25 Mar 2013 15:59:13 +0100 (CET) Received: from eusaamw0711.eamcs.ericsson.se (147.117.20.178) by EUSAAHC005.ericsson.se (147.117.188.87) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 25 Mar 2013 10:59:12 -0400 Received: from [142.133.180.233] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 25 Mar 2013 10:58:30 -0400 Message-ID: <51506579.3050803@ericsson.com> Date: Mon, 25 Mar 2013 10:55:53 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Iljitsch van Beijnum References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> <514C77BD.9090708@ericsson.com> <5E4DF003-1BDB-4BC2-AE6C-BDD60D132343@muada.com> In-Reply-To: <5E4DF003-1BDB-4BC2-AE6C-BDD60D132343@muada.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyuXRPuK5jWkCgwc6L6haz2huYLU4f28vs wOSxZMlPJo/HL48xBjBFcdmkpOZklqUW6dslcGW0blvCXrCLteL7zAvsDYzrWboYOTkkBEwk jr69xAhhi0lcuLeerYuRi0NI4AijxLvnG1kgnD2MEguabrOBVAkJbGeUuLleu4uRg4NXQFvi +CMXkDCLgKrEosV9rCA2G9DQDTs/M4HYogJhEr2vz4Et4BUQlDg58wnYYhEBXYm/h/eCxZkF FCTe3PnCDmILC/hIfOo5wQKx6hCjxLZbJSA2p4CtxKy1H1ghDpWU2PKinR2iV09iytUWqDny EtvfzmGG6NWU2LrmO+sERuFZSFbPQtIyC0nLAkbmVYwcpcWpZbnpRgabGIFBfEyCTXcH456X locYpTlYlMR5g1wvBAgJpCeWpGanphakFsUXleakFh9iZOLglGpgbGS5ftPtTMsRjreZVvoP wvgXeoorspz5//cR007rnueyPbtbTtgp1vxhm//fuO7J24NLYtJ/Fph1Ttvzdq3Fa/6WSYzM ix/e+5R3dt26a0lSj7K/ep988WaDyOG1aTuWrjt+uLGLyaGvj/PJjg9GVy9a/fjatXpTW9/q tFl+Z0QN129LS3NKy1BiKc5INNRiLipOBACK3eiFMAIAAA== Cc: IPv6 Ops WG Subject: Re: [v6ops] RFC 6732 can't work, was: draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 14:59:17 -0000 Hi Iljitsch, On 03/24/2013 05:17 PM, Iljitsch van Beijnum wrote: > Hi Suresh, > > I'll reply to the rest of your message later. But: > > On 22 mrt 2013, at 16:24, Suresh Krishnan wrote: > >> I think a short summary of 6to4 Provider Managed Tunnels (RFC6732) would >> be useful here for completeness. > > I'm surprised this was published as an RFC without a big fat IAB/IESG warning. Or at all, really. This obviously isn't "informational", but experimental in disguise. Since this draft provides an overview of existing tunneling methods, I suggested RFC6732 for *completeness*. Agree with you fully about the broken cases. Thanks Suresh From joelja@bogus.com Mon Mar 25 08:25:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FFC21E8040 for ; Mon, 25 Mar 2013 08:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 ANnahu9504Pc for ; Mon, 25 Mar 2013 08:25:22 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3E121E803F for ; Mon, 25 Mar 2013 08:25:22 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r2PFPHMX042130 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 25 Mar 2013 15:25:18 GMT (envelope-from joelja@bogus.com) Message-ID: <51506C58.9020300@bogus.com> Date: Mon, 25 Mar 2013 08:25:12 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Alexandru Petrescu , Lorenzo Colitti References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <87AB4E41-CD11-4F4F-8C93-3C1957F25EF6@ecs.soton.ac.uk> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149C642.6060806@gmail.com> <481173D1-2F02-4B80-8E2C-BE33009EF2C9@delong.com> <514B116E.9070504@gmail.com> <514B14C2.3050303@gmail.com> <514B8598.6090401@bogus.com> <2134F8430051B64F815C691A62D98318036EC8@XCH-BLV-504.nw.nos.boeing.com> <2EFC0D07-DA29-46F7-92E7-FA4C69ACF95F@merike.com> <2134F8430051B64F815C691A62D98318037A52@XCH-BLV-504.nw.nos.boeing.com> <514DFA47.1020705@gmail.com> <51504383.60003@gmail.co! m> In-Reply-To: <51504383.60003@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 25 Mar 2013 15:25:18 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 15:25:22 -0000 On 3/25/13 5:30 AM, Alexandru Petrescu wrote: > Le 25/03/2013 12:31, Lorenzo Colitti a écrit : >> On Sat, Mar 23, 2013 at 11:53 AM, Alexandru Petrescu >> > >> wrote: >> >>> When NAT IPv4 is used on-board of these vehicles, there is probably >>> no routing churn (the onboard addresses are not propagated to the >>> infrastructure), and probably little need for Mobile IP. >>> >> >> I very much doubt it, because your connections would be interrupted >> all the time. Next time, try keeping an SSH connection open on the >> train. If it doesn't get reset, then no IP addresses are changing. > > Well, somehow equivalent to ssh - I googled 'what is my IP address' > while in the train, while the train was handed over from the WiFi in the > railway station to the 3G outdoors (as noticed in the RTT change of > ping). The IP address 'of the train' did not change, neither the IP > address of my laptop. it's cellular handoff. The data is being carrier over a gtp tunnel to the GGSN, why would one expect the the ip address to change? > > > That means to me a form of Mobile IP was used by the train's Gateway, or > other dynamic VPN registration. > > Even if Mobile IP were not used, nor VPN re-registration, the IP address > of my laptop would have been stable, because it is a NAT. It would be > unnatural for these Gateways to re-DHCP allocate the NATed addresses to > Clients when the Gateway was handed over. > > Alex > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From joelja@bogus.com Mon Mar 25 08:52:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3DF21F8FC0 for ; Mon, 25 Mar 2013 08:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 CiDJsJJsUdXT for ; Mon, 25 Mar 2013 08:52:32 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 02D0021F8F24 for ; Mon, 25 Mar 2013 08:52:31 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r2PFqQQY042589 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 25 Mar 2013 15:52:27 GMT (envelope-from joelja@bogus.com) Message-ID: <515072B6.6020609@bogus.com> Date: Mon, 25 Mar 2013 08:52:22 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Brian E Carpenter , Owen DeLong References: <5149E7D7.8010508@gmail.com> <1363811028.61201.YahooMailNeo@web142502.mail.bf1.yahoo.com> <1363834867.96525.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130321085317.B1583314AC35@drugs.dv.isc.org> <514AD5FE.2020705@gmail.com> <9E1371CA-9162-4D09-948E-FF8A4EE53BC9@delong! ! .com> <514B35B5.1060907@gmail.com> <147A1585-CD8E-4003-B65F-25E1178A43D1@delong.com>! <514B4099.3000904@gmail.com> <0B7EE32B-5C80-4A90-9F83-075BF9DA6812@delong.com> <514C8719.7000004@gmail.com> <514C8AD8.8! 030705@gmail.com> <722D9250-6C69-4D87-88D1-4014F340CBAB@delong.com> <514D69A9.20105@gmail.com> In-Reply-To: <514D69A9.20105@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 25 Mar 2013 15:52:27 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 15:52:33 -0000 On 3/23/13 1:36 AM, Brian E Carpenter wrote: > On 22/03/2013 18:30, Owen DeLong wrote: >> On Mar 22, 2013, at 11:46 AM, Brian E Carpenter wrote: >> >>> On 22/03/2013 16:30, Alexandru Petrescu wrote: >>>> Le 21/03/2013 20:34, Owen DeLong a écrit : >>>>>>> RA is not forbidden. Default route via RA is forbidden. RIO via >>>>>>> RA is perfectly fine. >>>>>> But, the CPE rfcbis says that the Router Lifetime must not be >>>>>> greater than 0. There is no other way in which an RA can tell a >>>>>> Host it's a default router than setting that lifetime to greater >>>>>> than 0. >>>>> If the router doesn't provide internet access, it SHOULD NOT >>>>> advertise itself as a default router. That is the point. >>>> I shared that view at some point, but I changed. >>>> >>>> The meaning of 'default' route is not necessarily Internet. It means to >>>> be used when everything else fails, that's all. It is also a >>>> high-availability feature - absence of a default route means the system >>>> is less reliable. One _wants_ a default option whenever one does >>>> something with multiple choice. >>> As I've said since the beginning of MIF, a host needs a default route >>> per source prefix. I think you'll find that solves the dilemma. >> No, it really doesn't. In fact, I would say that may well cause more problems than it solves. >> >> Bottom line is that you should only provide a default route if you can reasonably expect to forward all traffic received via that default route. Otherwise, you are creating a black hole. >> >> Routes are destination based, not source based, > In a multi-prefix network, that is a bug. (I'm not saying we don't have > to consider today's running code, but we also have to do better in future.) policy based routing exists and works today... one observation I'd make though is when your fowarding path is influenced by the source address, path changes tend to cause you to forward into a hole, sometimes that's intentional, rfc 5635 style. mostly it's that's just a consequnce of for example one upstream being down and you having no other choice due to your policy. > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From alexandru.petrescu@gmail.com Mon Mar 25 08:54:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 546C521E8044 for ; Mon, 25 Mar 2013 08:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.299 X-Spam-Level: X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnHG1H270wft for ; Mon, 25 Mar 2013 08:54:30 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 970C521F8FEE for ; Mon, 25 Mar 2013 08:54:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2PFsEP3024065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Mar 2013 16:54:14 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2PFsDUw005185; Mon, 25 Mar 2013 16:54:14 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2PFs4i3008847; Mon, 25 Mar 2013 16:54:13 +0100 Message-ID: <515072E8.1050108@gmail.com> Date: Mon, 25 Mar 2013 16:53:12 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: joel jaeggli References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <51499D18.8030005@globis.net> <61406B78-C184-4256-BCA1-182EE50E4DD7@ecs.soton.ac.uk> <5149C642.6060806@gmail.com> <481173D1-2F02-4B80-8E2C-BE33009EF2C9@delong.com> <514B116E.9070504@gmail.com> <514B14C2.3050303@gmail.com> <514B8598.6090401@bogus.com> <2134F8430051B64F815C691A62D98318036EC8@XCH-BLV-504.nw.nos.boeing.com> <2EFC0D07-DA29-46F7-92E7-FA4C69ACF95F@merike.com> <2134F8430051B64F815C691A62D98318037A52@XCH-BLV-504.nw.nos.boeing.com> <514DFA47.1020705@gmail.com> <51504383.60003@gmail.co! m> <51506C58.9020300@bogus.com> In-Reply-To: <51506C58.9020300@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 15:54:31 -0000 Le 25/03/2013 16:25, joel jaeggli a écrit : > On 3/25/13 5:30 AM, Alexandru Petrescu wrote: >> Le 25/03/2013 12:31, Lorenzo Colitti a écrit : >>> On Sat, Mar 23, 2013 at 11:53 AM, Alexandru Petrescu >>> >> > wrote: >>> >>>> When NAT IPv4 is used on-board of these vehicles, there is >>>> probably no routing churn (the onboard addresses are not >>>> propagated to the infrastructure), and probably little need >>>> for Mobile IP. >>>> >>> >>> I very much doubt it, because your connections would be >>> interrupted all the time. Next time, try keeping an SSH >>> connection open on the train. If it doesn't get reset, then no >>> IP addresses are changing. >> >> Well, somehow equivalent to ssh - I googled 'what is my IP address' >> while in the train, while the train was handed over from the WiFi >> in the railway station to the 3G outdoors (as noticed in the RTT >> change of ping). The IP address 'of the train' did not change, >> neither the IP address of my laptop. > > it's cellular handoff. The data is being carrier over a gtp tunnel > to the GGSN, why would one expect the the ip address to change? > YEs, typically gtp tunnels stay up and cellular handovers are often just link layer change from one BS to another - no change in IP address. But in this particular case the train 'roams' from one country to another? (it's from Belgium to France in this case). This typically involves re-connection and change in IP address. In addition, it may be that this train does handovers WiFi-UMTS-Satellite, because explanation below. If so, then obviously a change in IP address is there (one couldn't keep same IP address across different access network technologies); yet the change is hidden from the passenger googling "what is my IP address" - a form of Mobile IP or VPN re-registration is suppposedly there. Alex ---------------------------------------------------------------------- In the particular case of the Thalys train, the situation may be as follows. The WiFi in-train provider claims that when the train is in the railway station the train connects to the WiFi in the railway station. (additionally, their web page claims actually "UMTS", "Satellite" and "WiFi" as means to access the Internet.) When trying it out as simple passenger, one notices a significant difference in RTT (round trip time) between when the train is in the railway station (RTT 40ms ping from laptop to google), versus when the train is quitting the railway station (600ms). From other experiments, one knows that 40ms is impossible on cellular links (other than LTE which was not deployed at the time of testing) - hence the station could only be WiFi. (details in a public video on youtube ref available upon request). This makes one think that the train performs a handover between two different access networks (maybe WiFi and maybe cellular); but yet keeps same IP address as shown by "what is my ip address". Alex >> >> >> That means to me a form of Mobile IP was used by the train's >> Gateway, or other dynamic VPN registration. >> >> Even if Mobile IP were not used, nor VPN re-registration, the IP >> address of my laptop would have been stable, because it is a NAT. >> It would be unnatural for these Gateways to re-DHCP allocate the >> NATed addresses to Clients when the Gateway was handed over. >> >> Alex >> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> > > > From iljitsch@muada.com Mon Mar 25 09:15:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655B721F884B for ; Mon, 25 Mar 2013 09:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmSs2Iw6mPro for ; Mon, 25 Mar 2013 09:15:26 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id A430921F882C for ; Mon, 25 Mar 2013 09:15:25 -0700 (PDT) Received: from [IPv6:2001:470:1f0b:1289:355d:4839:baf0:9a12] ([IPv6:2001:470:1f0b:1289:355d:4839:baf0:9a12]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2PGANeP009869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Mar 2013 17:10:23 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <514C77BD.9090708@ericsson.com> Date: Mon, 25 Mar 2013 17:15:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <095DF57C-26CC-47FA-A14F-14FDD5873A74@muada.com> References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> <514C77BD.9090708@ericsson.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1499) Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 16:15:26 -0000 On 22 mrt 2013, at 16:24, Suresh Krishnan = wrote: > * Section 3.8 > "Teredo is specified in [RFC4380] and a few updates" > I think the security updates in RFC5991 are probably worth mentioning = here. We feel this is too detailed to warrant inclusion. > "This process is not sufficiently reliable; Teredo fails in about 37% > [TERTST] of its attempts to connect to native IPv6 destinations." > In this context it is probably useful to say that there are some > extensions to Teredo that significantly decrease the failure rate. > Please see RFC6081. Interesting! Do you know if these mechanisms are implemented? > * Section 6.2 > As mentioned in Section 3.5, the table needs to be updated to include > ISP in the 6to4 row (RFC6732) Done. Thanks for the review. Iljitsch= From iljitsch@muada.com Mon Mar 25 09:18:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FE621F8A14 for ; Mon, 25 Mar 2013 09:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7gY2xmAGVWf for ; Mon, 25 Mar 2013 09:18:19 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id EE30911E80C5 for ; Mon, 25 Mar 2013 09:18:17 -0700 (PDT) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2PGDEC9009927 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Mar 2013 17:13:15 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: Date: Mon, 25 Mar 2013 17:18:20 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: To: Victor Kuarsingh X-Mailer: Apple Mail (2.1499) Cc: IPv6 Ops WG Subject: Re: [v6ops] RFC 6732 can't work, was: draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 16:18:20 -0000 On 24 mrt 2013, at 22:41, Victor Kuarsingh wrote: > As for the draft text, I think the warning part of section 3.5 (6to4) > should include not just RFC6598, but also IPv4 space which may be used > that is not routed (squat or otherwise). Do you have a reference that we can cite about this issue? Thanks, Iljitsch From iljitsch@muada.com Mon Mar 25 09:25:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA65521E8099 for ; Mon, 25 Mar 2013 09:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjysCNyJqmv8 for ; Mon, 25 Mar 2013 09:25:38 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id ECCD821E8098 for ; Mon, 25 Mar 2013 09:25:37 -0700 (PDT) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2PGKX3h010000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Mar 2013 17:20:34 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <514C77BD.9090708@ericsson.com> Date: Mon, 25 Mar 2013 17:25:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> <514C77BD.9090708@ericsson.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1499) Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 16:25:38 -0000 On 22 mrt 2013, at 16:24, Suresh Krishnan = wrote: > * Section 3.5 > I think a short summary of 6to4 Provider Managed Tunnels (RFC6732) = would > be useful here for completeness. Let me explain why we decided not to include this. (We decided this = together but the reasons below are mine and not necessarily those of my = co-authors.) One reason is to avoid endorsing NAT in IPv6. Another is length/scope: = discussing all the issues with prefix translation, which currently don't = come up, would require a significant amount of extra text. Apart from that, this is not a mechanism that a user can decide to run = on their own. Rather, it's something the ISP does that changes the 6to4 = that the user has enabled (or more likely, was enabled out of the box). Finally, although I could be mistaken, it looks like the mechanism isn't = in very wide use. Iljitsch= From victor@jvknet.com Mon Mar 25 10:45:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C76421F9515 for ; Mon, 25 Mar 2013 10:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 NwpPzucgzc7p for ; Mon, 25 Mar 2013 10:45:51 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7382421F9513 for ; Mon, 25 Mar 2013 10:45:51 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hn17so4355063wib.12 for ; Mon, 25 Mar 2013 10:45:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ZjmdGe9K2QH0ILjwdIFCspg2XyoVt9Ngp86JZ08Q0nI=; b=H0Pcuis8XZ6MBFG5ghbvDBsATy4vujBnC04fMFV62fBwRXhmxRz6TmGbklEvnrByiq PFWRjzSv87yh8RQvWlscLyqw/JGI3nmCcSZxHo+YvwCkZC7uIxtME6nfa9SPTv+p13wi QWDQHG2H68LnZwmwFtxo0Vdm7u0jqmoaPasOE4IyAUXJJt4jkL0d2l8mvkZrLwLN9300 9dsIJ26Gul2a4Idu8wTxF20yMJo+5IM1T5xmd8Ddh1fsUypE8wtcI+NJr7Rsixwl152u MG52n9dLKwnKqSzsxPjdXZwQKUuRqFvISeE8yeLK3Iz4TZt+ui12CV2L2Gqr/PDvosXn Y+1A== MIME-Version: 1.0 X-Received: by 10.194.10.129 with SMTP id i1mr7379730wjb.21.1364233549655; Mon, 25 Mar 2013 10:45:49 -0700 (PDT) Received: by 10.194.94.72 with HTTP; Mon, 25 Mar 2013 10:45:49 -0700 (PDT) X-Originating-IP: [24.114.255.99] In-Reply-To: References: Date: Mon, 25 Mar 2013 13:45:49 -0400 Message-ID: From: Victor Kuarsingh To: Iljitsch van Beijnum Content-Type: multipart/alternative; boundary=047d7b5d5bd81e4b4404d8c3608f X-Gm-Message-State: ALoCoQlzWAzu3XEmhjzaJJWwBDm6VP6JhwZi0Oj0xRXhJSmJITnjcGROkL/D91/OQFI/Ex5IfZwM Cc: IPv6 Ops WG Subject: Re: [v6ops] RFC 6732 can't work, was: draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 17:45:52 -0000 --047d7b5d5bd81e4b4404d8c3608f Content-Type: text/plain; charset=ISO-8859-1 Ilijitsch, I will look for some more, but rfc6319 has some text.. regards, Victor K On Mon, Mar 25, 2013 at 12:18 PM, Iljitsch van Beijnum wrote: > On 24 mrt 2013, at 22:41, Victor Kuarsingh wrote: > > > As for the draft text, I think the warning part of section 3.5 (6to4) > > should include not just RFC6598, but also IPv4 space which may be used > > that is not routed (squat or otherwise). > > Do you have a reference that we can cite about this issue? > > Thanks, > > Iljitsch > --047d7b5d5bd81e4b4404d8c3608f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ilijitsch,

I will look for = some more, but=A0rfc6319 has some text..=A0

regards,

Victor K

On Mon, Mar 25, 2013 at 12:18 PM, Iljitsch van Beijnum &l= t;iljitsch@muada.co= m> wrote:
On 24 mrt 2013, at 22:41, Victor Kuarsingh <victor@jvknet.com> wrote:

> As for the draft text, I think the warning part of section 3.5 (6to4)<= br> > should include not just RFC6598, but also IPv4 space which may be used=
> that is not routed (squat or otherwise).

Do you have a reference that we can cite about this issue?

Thanks,

Iljitsch

--047d7b5d5bd81e4b4404d8c3608f-- From jhw@apple.com Mon Mar 25 11:06:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60A821F9528 for ; Mon, 25 Mar 2013 11:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Nrj8UXzaL7W for ; Mon, 25 Mar 2013 11:06:47 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4135721F9518 for ; Mon, 25 Mar 2013 11:06:47 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MK8006OHA8W74H1@mail-out.apple.com> for v6ops@ietf.org; Mon, 25 Mar 2013 11:06:10 -0700 (PDT) X-AuditID: 1180715a-b7f566d000006daa-d9-515092118192 Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 6F.D1.28074.11290515; Mon, 25 Mar 2013 11:06:10 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MK800CXYAA9B580@aniseed.apple.com> for v6ops@ietf.org; Mon, 25 Mar 2013 11:06:09 -0700 (PDT) From: james woodyatt In-reply-to: <5E4DF003-1BDB-4BC2-AE6C-BDD60D132343@muada.com> Date: Mon, 25 Mar 2013 11:06:09 -0700 Message-id: References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> <514C77BD.9090708@ericsson.com> <5E4DF003-1BDB-4BC2-AE6C-BDD60D132343@muada.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1713) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FAsris0KSDQ4Lqvxelje5kdGD2WLPnJ FMAYxWWTkpqTWZZapG+XwJWx/+oTloKVHBVv9uxlb2C8y9bFyMkhIWAisfrjHVYIW0ziwr31 QHEuDiGBfiaJ61O3sEM4M5gkDtycxARSxSygJbF+53Ewm1dAT+Lfq2awbmEBX4ntm18ygths AioS3y7fBarh4OAUsJW4c1QAJMwioCqx/chdZogxChJt79oZIWxtiSfvLrBCjLSROH1pD9Te E4wS2x60gl0qIqAr8ffwXkaIS2Ul7lxcwDiBUWAWkpNmITlpFpK5CxiZVzEKFKXmJFaa6SUW FOSk6iXn525iBAdeYdQOxoblVocYBTgYlXh4NwQHBAqxJpYVV+YeYpTgYFYS4dUSAgrxpiRW VqUW5ccXleakFh9ilOZgURLnfdAGlBJITyxJzU5NLUgtgskycXBKNTBanynaprbH/9lTgY19 y4+U/X6+/kKgd/rJ7M+RYVMcNs3QkpTvO/74isdjtlWvHdeeCyy9b3Rh4z5JQYZv075NPbN/ rv9SWa+aZ8I+MVd3eF0ur54dP92tzeSS//0zZkpXEu5NylTqjfOsPG97L1LzndYNj7ltl/nn fi69xxuS4WKjKRzA4S+qxFKckWioxVxUnAgA27i+zjgCAAA= Cc: IPv6 Ops WG Subject: Re: [v6ops] RFC 6732 can't work, was: draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 18:06:47 -0000 On Mar 24, 2013, at 14:17 , Iljitsch van Beijnum wrote: > > B sends a packet to A, bypassing the relay/translator, as A and B both share the "directly connected" subnet 2002::/16. As such, B's prefix isn't translated, and A sends back an encapsulated IPv6 packet to 100.64.0.1, which of course never makes it because that address is not globally unique. This is why the very next release of AirPort and Time Capsule firmware Apple released after the publication of the 6to4-PMT draft made the 100.64/10 address space ineligible for use as outer IPv4 addresses in its "Automatic IPv6 Tunnel Router" feature. One hopes that other vendors of home gateway appliances, which implement similar features, will either remove the feature entirely or, at the very least, deploy defensive measures similar to what Apple did to prevent service providers from inflicting RFC 6732 on their innocent subscribers. Only *you* can prevent wild fires. -- james woodyatt core os networking From sander@steffann.nl Tue Mar 26 02:56:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1348C21F897A for ; Tue, 26 Mar 2013 02:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuDMN5qefMal for ; Tue, 26 Mar 2013 02:56:42 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id B32C321F8959 for ; Tue, 26 Mar 2013 02:56:42 -0700 (PDT) Received: from [IPv6:2001:610:7db:1:7160:61b1:310f:9540] (unknown [IPv6:2001:610:7db:1:7160:61b1:310f:9540]) by mail.sintact.nl (Postfix) with ESMTP id B8F042063; Tue, 26 Mar 2013 10:56:33 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Sander Steffann In-Reply-To: Date: Tue, 26 Mar 2013 13:56:32 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <947E24F9-C4FD-4FF1-8889-D5B8CBD84C8F@steffann.nl> References: <20130215083407.7412.74547.idtracker@ietfa.amsl.com> <3BF598C2-9F5D-4952-9BB3-0519A4FB4CC8@muada.com> <514C77BD.9090708@ericsson.com> <5E4DF003-1BDB-4BC2-AE6C-BDD60D132343@muada.com> To: james woodyatt X-Mailer: Apple Mail (2.1503) Cc: IPv6 Ops WG Subject: Re: [v6ops] RFC 6732 can't work, was: draft-steffann-tunnels-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 09:56:44 -0000 Hi James, > This is why the very next release of AirPort and Time Capsule firmware = Apple released after the publication of the 6to4-PMT draft made the = 100.64/10 address space ineligible for use as outer IPv4 addresses in = its "Automatic IPv6 Tunnel Router" feature. Good to hear that. Thanks! Sander From Michal.Czerwonka1@orange.com Tue Mar 26 04:17:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADFF421F8A51 for ; Tue, 26 Mar 2013 04:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.786 X-Spam-Level: X-Spam-Status: No, score=0.786 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, MIME_8BIT_HEADER=0.3] 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 UvwKJ1esZc+2 for ; Tue, 26 Mar 2013 04:17:31 -0700 (PDT) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) by ietfa.amsl.com (Postfix) with ESMTP id BDE1A21F8A53 for ; Tue, 26 Mar 2013 04:17:30 -0700 (PDT) Received: from 10.236.62.156 (EHLO OPE10HT08.tp.gk.corp.tepenet) ([10.236.62.156]) by mailin.tpsa.pl (MOS 3.10.10a-GA FastPath queued) with ESMTP id DLK85535; Tue, 26 Mar 2013 12:17:17 +0100 (CET) From: =?iso-8859-2?Q?Czerwonka_Micha=B3_-_Hurt_TP?= To: "v6ops@ietf.org" Thread-Topic: [v6ops] State of IPv6 in Mobile Cellular Networks Thread-Index: AQHOHtUTZsBNaP4Bz0O+hcPefingFpi358XQ Date: Tue, 26 Mar 2013 11:16:35 +0000 Message-ID: <2D29C51862222E49B991EF64EEB0B5B745EF5CAE@OPE10MB03.tp.gk.corp.tepenet> References: <512CF682.8030307@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6D11E055F@SRVHKE02.rdm.cz> <5130B665.1020907@gmail.com> <8D4B01C4-EC43-48A4-BC15-A4D2DC5CACC2@delong.com> <513E0D5F.4010904@gmail.com> <20130311224201.C24B230B9425@drugs.dv.isc.org> <12897BE3-E798-482B-8841-95D600E0FCA5@delong.com> <20130312015901.EAD7930BB67A@drugs.dv.isc.org> <2182BA1D-B2A2-445F-9962-338E2F0DE351@delong.com> <20130312035254.1DF2330BEFD3@drugs.dv.isc.org> In-Reply-To: <20130312035254.1DF2330BEFD3@drugs.dv.isc.org> Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0C0208.515183C9.0110,ss=1,fgs=0, ip=10.236.62.156, so=2010-07-09 01:15:44, dmn=5.4.3/2007-10-18, mode=single engine X-Junkmail-IWF: false X-Mirapoint-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0208.515183C9.0110,ss=1,fgs=0, ip=10.236.62.156, so=2010-07-09 01:15:44, dmn=5.4.3/2007-10-18 X-Mirapoint-Loop-Id: d95f1b3063b52e753d9629f536fc962b Cc: Kossut Tomasz - Hurt PTK Subject: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 11:17:31 -0000 Hi All, I would like to inform that Orange Poland (OPL) officialy launched mobile a= ccess to Internet using IPv6 protocol for their subscribers. This is done b= y APN IPv6-only with NAT64/DNS64 funcionality. This feature is ready to sup= port the 464xlat architecture. So, the mobile phone with CLAT are welcome. =20 Mobile Network Settings:=20 APN name is "internetipv6" , APN protocol is "IPv6"=20 Do not hesitate to test it if you have OPL sim card. Thanks, Mcz From leo.liubing@huawei.com Tue Mar 26 04:56:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422F321F8A8E for ; Tue, 26 Mar 2013 04:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FH0gYw8rEnpd for ; Tue, 26 Mar 2013 04:56:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 314FB21F8A7E for ; Tue, 26 Mar 2013 04:56:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APU51884; Tue, 26 Mar 2013 11:56:33 +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.7; Tue, 26 Mar 2013 11:56:10 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 26 Mar 2013 11:56:27 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.42]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.01.0323.007; Tue, 26 Mar 2013 19:56:23 +0800 From: "Liubing (Leo)" To: "" Thread-Topic: ULA discussion #BCP or Informational Thread-Index: Ac4qGON521++zMpPThuXXXszdE4eKg== Date: Tue, 26 Mar 2013 11:56:22 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 11:56:36 -0000 Hi, Dear all [Note: You can also raise some topic you consider as important with the pre= fix "ULA discussion #", so that the future discussion could be easily track= ed. Thank you.] This post is regarding the document should be a "BCP" or "Informational".=20 Personally, either BCP or Informational is OK for me. But I'd like to discu= ss it in the perspective of the document. I checked RFC2026 (The Internet Standards Process -- Revision 3), in sectio= n 5, the BCP document is described as "a vehicle by which the IETF communit= y can define and ratify the community's best current thinking on a statemen= t of principle or on what is believed to be the best way to perform some op= erations or IETF process function." So, I believe it is a good goal to publish the ULA draft as a BCP, I think = the position is valuable for the readers. However, some texts (especially N= AT relative) are still controversy that might not be consensus of represent= ing "the community's best current thinking". But let's try to find the comm= on view/principle out of the controversy materials, if not applicable, then= it is OK to be Informational. From alexandru.petrescu@gmail.com Tue Mar 26 05:10:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDAC21F856E for ; Tue, 26 Mar 2013 05:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.416 X-Spam-Level: X-Spam-Status: No, score=-9.416 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 808t5UFpjypR for ; Tue, 26 Mar 2013 05:10:04 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF2321F855C for ; Tue, 26 Mar 2013 05:10:03 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2QCA3VA014032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 26 Mar 2013 13:10:03 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2QCA2v3022288 for ; Tue, 26 Mar 2013 13:10:02 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2QCA2xk024651 for ; Tue, 26 Mar 2013 13:10:02 +0100 Message-ID: <51518FE5.6080206@gmail.com> Date: Tue, 26 Mar 2013 13:09:09 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <512CF682.8030307@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6D11E055F@SRVHKE02.rdm.cz> <5130B665.1020907@gmail.com> <8D4B01C4-EC43-48A4-BC15-A4D2DC5CACC2@delong.com> <513E0D5F.4010904@gmail.com> <20130311224201.C24B230B9425@drugs.dv.isc.org> <12897BE3-E798-482B-8841-95D600E0FCA5@delong.com> <20130312015901.EAD7930BB67A@drugs.dv.isc.org> <2182BA1D-B2A2-445F-9962-338E2F0DE351@delong.com> <20130312035254.1DF2330BEFD3@drugs.dv.isc.org> <2D29C51862222E49B991EF64EEB0B5B745EF5CAE@OPE10MB03.tp.gk.corp.tepenet> In-Reply-To: <2D29C51862222E49B991EF64EEB0B5B745EF5CAE@OPE10MB03.tp.gk.corp.tepenet> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 12:10:06 -0000 Hello, Thank you for this information. What is an 'OPL' SIM card? Is it 'Orange Poland'? I have several SIM cards in France. Does this work with LTE as well? Thanks, Alex Le 26/03/2013 12:16, Czerwonka Michał - Hurt TP a écrit : > Hi All, > > I would like to inform that Orange Poland (OPL) officialy launched > mobile access to Internet using IPv6 protocol for their subscribers. > This is done by APN IPv6-only with NAT64/DNS64 funcionality. This > feature is ready to support the 464xlat architecture. So, the mobile > phone with CLAT are welcome. > > > Mobile Network Settings: APN name is "internetipv6" , APN protocol > is "IPv6" > > > Do not hesitate to test it if you have OPL sim card. > > Thanks, Mcz > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From Michal.Czerwonka1@orange.com Tue Mar 26 05:19:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B710321F8A53 for ; Tue, 26 Mar 2013 05:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.086 X-Spam-Level: * X-Spam-Status: No, score=1.086 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] 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 CfB4LRZgRsTm for ; Tue, 26 Mar 2013 05:19:26 -0700 (PDT) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) by ietfa.amsl.com (Postfix) with ESMTP id 252C621F8A38 for ; Tue, 26 Mar 2013 05:19:24 -0700 (PDT) Received: from 10.236.62.153 (EHLO OPE10HT05.tp.gk.corp.tepenet) ([10.236.62.153]) by mailin.tpsa.pl (MOS 3.10.10a-GA FastPath queued) with ESMTP id DLO83330; Tue, 26 Mar 2013 13:19:22 +0100 (CET) From: =?iso-8859-2?Q?Czerwonka_Micha=B3_-_Hurt_TP?= To: Alexandru Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] State of IPv6 in Mobile Cellular Networks Thread-Index: AQHOKhrY6pAZohPe/kqJGdClyukQ2Ji34j0A Date: Tue, 26 Mar 2013 12:19:05 +0000 Message-ID: <2D29C51862222E49B991EF64EEB0B5B745EF5CF9@OPE10MB03.tp.gk.corp.tepenet> References: <512CF682.8030307@gmail.com> <1808340F7EC362469DDFFB112B37E2FCC6D11E055F@SRVHKE02.rdm.cz> <5130B665.1020907@gmail.com> <8D4B01C4-EC43-48A4-BC15-A4D2DC5CACC2@delong.com> <513E0D5F.4010904@gmail.com> <20130311224201.C24B230B9425@drugs.dv.isc.org> <12897BE3-E798-482B-8841-95D600E0FCA5@delong.com> <20130312015901.EAD7930BB67A@drugs.dv.isc.org> <2182BA1D-B2A2-445F-9962-338E2F0DE351@delong.com> <20130312035254.1DF2330BEFD3@drugs.dv.isc.org> <2D29C51862222E49B991EF64EEB0B5B745EF5CAE@OPE10MB03.tp.gk.corp.tepenet> <51518FE5.6080206@gmail.com> In-Reply-To: <51518FE5.6080206@gmail.com> Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090209.5151924B.0061,ss=1,fgs=0, ip=10.236.62.153, so=2010-07-09 01:15:44, dmn=5.4.3/2007-10-18, mode=single engine X-Junkmail-IWF: false X-Mirapoint-RAPID-Raw: score=unknown(0), refid=str=0001.0A090209.5151924B.0061,ss=1,fgs=0, ip=10.236.62.153, so=2010-07-09 01:15:44, dmn=5.4.3/2007-10-18 X-Mirapoint-Loop-Id: 54fbd2fcd874dd226683d4f99e537efe Subject: [v6ops] ODP: State of IPv6 in Mobile Cellular Networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 12:19:30 -0000 Yes, you need Orange Poland (OPL) SIM card :) Right now OPL support 2G/3G radio access, but in the future who knows :) Mcz =20 -----Wiadomo=B6=E6 oryginalna----- Od: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] W imieniu Alexan= dru Petrescu Wys=B3ano: 26 marca 2013 13:09 Do: v6ops@ietf.org Temat: Re: [v6ops] State of IPv6 in Mobile Cellular Networks Hello, Thank you for this information. What is an 'OPL' SIM card? Is it 'Orange Poland'? I have several SIM cards in France. Does this work with LTE as well? Thanks, Alex Le 26/03/2013 12:16, Czerwonka Micha=B3 - Hurt TP a =E9crit : > Hi All, > > I would like to inform that Orange Poland (OPL) officialy launched > mobile access to Internet using IPv6 protocol for their subscribers. > This is done by APN IPv6-only with NAT64/DNS64 funcionality. This > feature is ready to support the 464xlat architecture. So, the mobile > phone with CLAT are welcome. > > > Mobile Network Settings: APN name is "internetipv6" , APN protocol > is "IPv6" > > > Do not hesitate to test it if you have OPL sim card. > > Thanks, Mcz > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Tue Mar 26 06:52:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C1521F8B6D for ; Tue, 26 Mar 2013 06:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.177 X-Spam-Level: X-Spam-Status: No, score=-102.177 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 bQeamkJSWZgu for ; Tue, 26 Mar 2013 06:52:30 -0700 (PDT) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id 1840621F8B45 for ; Tue, 26 Mar 2013 06:52:30 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id o17so7517400oag.20 for ; Tue, 26 Mar 2013 06:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=oRRVYRFrwp4voECgVEmPfOnt/faSlFjYdvIVKBOFtiU=; b=LAmx9MSdAf8PEEtgYQrSy66ZjJzHSTGNAJWSmatipaVndosPXjocbQHUUrhTnLhrv4 oOoZuO19c1JDBs3k8fV8lcuS/kM+HS3ROxwR+bFBk8ES1eHZdq/s0PUXOGvk7xjtf6IK N/GETlS3yUnCJvrAMKz7mM8NSKa1/gG4hlnt4JadjWHvxGAIsxtjyDhF5Hp2wcYGXpOc jo+Tum8+Zdm8EOYf1HSqCQPfBJfijBdQby9ohFkcHhdIxcUbSkJ5ykHERroBR3rvJaaV KDhZ2rFYSLw08fDJDmDh4Rmaj4Io8Ir7sAyquswjZGRMgN9XO0PJdQzuNgfj++EGm7hd M5Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=oRRVYRFrwp4voECgVEmPfOnt/faSlFjYdvIVKBOFtiU=; b=FRKTEfdE5KWmTuSP0MTfoRDohHxdmyl4vPdu0GMXM2x51lEQ0YVY9Jh+dS6R/qqX9m 3l6U4V66Ik5iasvXXCIu1LAMiTh3YusTWDZEgB5UwGrEa/P33s9RaB3U2pJKoT+f/ggg RfCT4h1usq6RkJo+bzQ83CC4sQ70bxl8E/MJHIfxgecRAANFQAExMV14r+MnndQXG6qA inJ2+gwqA5vMdQeWxM/y76No6oKMTjrIncRott4ks0fEIs14L/mD5Iy0co8kJYwa//Pa CTJThF+TWTeohp0/CFdhuud+Xq18ZKDNxFgw1qfRa6YGEJkitgYTxh3xhC9wSq9nfgSu zpgQ== MIME-Version: 1.0 X-Received: by 10.182.34.131 with SMTP id z3mr2090303obi.81.1364305949700; Tue, 26 Mar 2013 06:52:29 -0700 (PDT) Received: by 10.182.227.70 with HTTP; Tue, 26 Mar 2013 06:52:29 -0700 (PDT) Received: by 10.182.227.70 with HTTP; Tue, 26 Mar 2013 06:52:29 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> Date: Tue, 26 Mar 2013 22:52:29 +0900 Message-ID: From: Lorenzo Colitti To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=001a11c2a3047f618404d8d43b62 X-Gm-Message-State: ALoCoQnpCvNybW3cJ6IOzsLaQuFgYge4C9HEyImyRSJpTFJrY/F+Oubnp6g+SeGzD2gzlj18Nv9p3IFWqeCGym3/Fk6NoiIkOS705q9iU3l1wJHsk5Nzwk0lpEODT3/qzMe2ZHqEaiamrZUdm7ZqtiZtuls5LHddp0h5AR3axfdA1TjPtIoDuE3TEHRD8Edrbd5+CdeHIFmo Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 13:52:31 -0000 --001a11c2a3047f618404d8d43b62 Content-Type: text/plain; charset=ISO-8859-1 Informational. The way I see it, the scenarios in this document are not current practice, because they are not currently deployed to any substantial degree. And if this document is not current practice, then it cannot be Best Current Practice. On 26 Mar 2013 20:56, "Liubing (Leo)" wrote: > Hi, Dear all > > [Note: You can also raise some topic you consider as important with the > prefix "ULA discussion #", so that the future discussion could be easily > tracked. Thank you.] > > This post is regarding the document should be a "BCP" or "Informational". > Personally, either BCP or Informational is OK for me. But I'd like to > discuss it in the perspective of the document. > > I checked RFC2026 (The Internet Standards Process -- Revision 3), in > section 5, the BCP document is described as "a vehicle by which the IETF > community can define and ratify the community's best current thinking on a > statement of principle or on what is believed to be the best way to perform > some operations or IETF process function." > > So, I believe it is a good goal to publish the ULA draft as a BCP, I think > the position is valuable for the readers. However, some texts (especially > NAT relative) are still controversy that might not be consensus of > representing "the community's best current thinking". But let's try to find > the common view/principle out of the controversy materials, if not > applicable, then it is OK to be Informational. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a11c2a3047f618404d8d43b62 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Informational.

The way I see it, the scenarios in this document are not cur= rent practice, because they are not currently deployed to any substantial d= egree. And if this document is not current practice, then it cannot be Best= Current Practice.

On 26 Mar 2013 20:56, "Liubing (Leo)" = <leo.liubing@huawei.com>= ; wrote:
Hi, Dear all

[Note: You can also raise some topic you consider as important with the pre= fix "ULA discussion #", so that the future discussion could be ea= sily tracked. Thank you.]

This post is regarding the document should be a "BCP" or "In= formational".
Personally, either BCP or Informational is OK for me. But I'd like to d= iscuss it in the perspective of the document.

I checked RFC2026 (The Internet Standards Process -- Revision 3), in sectio= n 5, the BCP document is described as "a vehicle by which the IETF com= munity can define and ratify the community's best current thinking on a= statement of principle or on what is believed to be the best way to perfor= m some operations or IETF process function."

So, I believe it is a good goal to publish the ULA draft as a BCP, I think = the position is valuable for the readers. However, some texts (especially N= AT relative) are still controversy that might not be consensus of represent= ing "the community's best current thinking". But let's tr= y to find the common view/principle out of the controversy materials, if no= t applicable, then it is OK to be Informational.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops
--001a11c2a3047f618404d8d43b62-- From cb.list6@gmail.com Tue Mar 26 07:00:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A5321F8B97 for ; Tue, 26 Mar 2013 07:00:15 -0700 (PDT) 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, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLBhjZ+2rYg7 for ; Tue, 26 Mar 2013 07:00:15 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id D7B5521F8B6E for ; Tue, 26 Mar 2013 07:00:14 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hm14so874067wib.10 for ; Tue, 26 Mar 2013 07:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=SDy66P/JAiY/R1FCZOIQgRGNYQWyyObnzzcVBgllbWc=; b=ml+ZJwvnGmJXs+G58k0iifj6jhAepueZqOZqOvOZY6EFgt4Vk7446PLwz1gqX2/riN oZC11lqqdss7axqD7VgdnQH6duhlnihf+0L2zH/LJuvDTtM5kfhIakmMj0RbAlEUQ014 RSNNDEvIY0DqipYreBOjndkBsWZ62iOt2DgFpfrMmpu6kcRpCkp55IR146ITua6gNsZ2 MVJ5BMNXh3Uug+Qqw4CheC+Ue61rsL27kcE54K1nYlwh/QHAT+wzrMJfYTiZ4GS0sSco rqRoYQvSEkkXGRQAkUDOsNHl0PNUMaft1Y3XCCXtHljhC3EwjHURWk03DT+tioifApy8 t8vQ== MIME-Version: 1.0 X-Received: by 10.194.20.40 with SMTP id k8mr25113392wje.16.1364306413720; Tue, 26 Mar 2013 07:00:13 -0700 (PDT) Received: by 10.194.20.35 with HTTP; Tue, 26 Mar 2013 07:00:13 -0700 (PDT) Received: by 10.194.20.35 with HTTP; Tue, 26 Mar 2013 07:00:13 -0700 (PDT) In-Reply-To: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> Date: Tue, 26 Mar 2013 07:00:13 -0700 Message-ID: From: "cb.list6" To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=047d7b5d4404279bd804d8d457c1 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 14:00:15 -0000 --047d7b5d4404279bd804d8d457c1 Content-Type: text/plain; charset=ISO-8859-1 On Mar 26, 2013 6:52 AM, "Lorenzo Colitti" wrote: > > Informational. > > The way I see it, the scenarios in this document are not current practice, because they are not currently deployed to any substantial degree. And if this document is not current practice, then it cannot be Best Current Practice. > What does substantial degree mean ? I have ULAs deployed at several places in my network consistent with the draft. I too am fine with informational status, but these ideas have been applied. Cameron > On 26 Mar 2013 20:56, "Liubing (Leo)" wrote: >> >> Hi, Dear all >> >> [Note: You can also raise some topic you consider as important with the prefix "ULA discussion #", so that the future discussion could be easily tracked. Thank you.] >> >> This post is regarding the document should be a "BCP" or "Informational". >> Personally, either BCP or Informational is OK for me. But I'd like to discuss it in the perspective of the document. >> >> I checked RFC2026 (The Internet Standards Process -- Revision 3), in section 5, the BCP document is described as "a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function." >> >> So, I believe it is a good goal to publish the ULA draft as a BCP, I think the position is valuable for the readers. However, some texts (especially NAT relative) are still controversy that might not be consensus of representing "the community's best current thinking". But let's try to find the common view/principle out of the controversy materials, if not applicable, then it is OK to be Informational. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b5d4404279bd804d8d457c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mar 26, 2013 6:52 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
> Informational.
>
> The way I see it, the scenarios in this document are not current pract= ice, because they are not currently deployed to any substantial degree. And= if this document is not current practice, then it cannot be Best Current P= ractice.
>

What does substantial degree mean ?

I have ULAs deployed at several places in my network consist= ent with the draft.

I too am fine with informational status, but these ideas hav= e been applied.

Cameron

> On 26 Mar 2013 20:56, "Liubing (Leo)" <leo.liubing@huawei.com> wrote= :
>>
>> Hi, Dear all
>>
>> [Note: You can also raise some topic you consider as important wit= h the prefix "ULA discussion #", so that the future discussion co= uld be easily tracked. Thank you.]
>>
>> This post is regarding the document should be a "BCP" or= "Informational".
>> Personally, either BCP or Informational is OK for me. But I'd = like to discuss it in the perspective of the document.
>>
>> I checked RFC2026 (The Internet Standards Process -- Revision 3), = in section 5, the BCP document is described as "a vehicle by which the= IETF community can define and ratify the community's best current thin= king on a statement of principle or on what is believed to be the best way = to perform some operations or IETF process function."
>>
>> So, I believe it is a good goal to publish the ULA draft as a BCP,= I think the position is valuable for the readers. However, some texts (esp= ecially NAT relative) are still controversy that might not be consensus of = representing "the community's best current thinking". But let= 's try to find the common view/principle out of the controversy materia= ls, if not applicable, then it is OK to be Informational.
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/v6ops
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--047d7b5d4404279bd804d8d457c1-- From alexandru.petrescu@gmail.com Tue Mar 26 09:11:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E2921F8C11 for ; Tue, 26 Mar 2013 09:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.474 X-Spam-Level: X-Spam-Status: No, score=-9.474 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esSDrPQe0dtQ for ; Tue, 26 Mar 2013 09:11:12 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3233621F8546 for ; Tue, 26 Mar 2013 09:10:34 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2QGAXgv009435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 26 Mar 2013 17:10:33 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2QGAXFt002349 for ; Tue, 26 Mar 2013 17:10:33 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2QGAOFr000309 for ; Tue, 26 Mar 2013 17:10:32 +0100 Message-ID: <5151C83B.1010203@gmail.com> Date: Tue, 26 Mar 2013 17:09:31 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "v6ops@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 16:11:22 -0000 Dear participants to V6OPS, Is there an interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? As one may remember, there was much discussion in several groups about DHCPv6 delivering routing information to Clients: generic routes, default routers' addresses and routes keyed by source address. The MIF WG has produced a document draft-ietf-mif-dhcpv6-route-option-05 but it is recently dropped from the MIF Charter to allow group to re-focus on a MIF topic. An individual proposal about DHCPv6 Default Routers List that I co-author is in draft-mouton-mif-dhcpv6-drlo-02.txt which takes on an earlier draft-droms-dhc-dhcpv6-default-router In the DHCWG there was recently discussion about IEEE 802.11ai needing to configure DefaultRouters by using link-layer messaging, or alternatively DHCP. With a purpose to realize fast configuration in crowded hotspot areas for highly mobile STAs. Also in DHCWG there was discussion about the src-based routes being communicated to Client with DHCPv6. Is there an interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? Alex From tjc@ecs.soton.ac.uk Tue Mar 26 11:13:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA97821F870F for ; Tue, 26 Mar 2013 11:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tc+soYM+bgPY for ; Tue, 26 Mar 2013 11:13:01 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id AAFC321F86D8 for ; Tue, 26 Mar 2013 11:13:00 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r2QICsDi000791 for ; Tue, 26 Mar 2013 18:12:54 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r2QICsDi000791 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1364321574; bh=gbT/g/JA8JzCu0lnStrVhUviI5w=; h=From:Mime-Version:Subject:Date:References:To:In-Reply-To; b=EUacSojkiuSdXxNN76kV5NZaXM/yWjDkt393yQid4fZt8LJaRU7fYkesHAtfrpRfZ d0YaTXfmXLqvCZ+/S9hv2rMB4vlmzto8j8AZLq3NJu8OgS9XpWjbHu1i8I+T39FP98 mWJWYkbtO2o3sUrVBlLSXLiHQewtwFmn6Q6DITpg= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id p2PICs0430646151yS ret-id none; Tue, 26 Mar 2013 18:12:54 +0000 Received: from [192.168.1.110] (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 r2QICmap024509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 26 Mar 2013 18:12:51 GMT From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_DEF91175-0749-458F-B46C-51668D363AFA" Message-ID: Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Date: Tue, 26 Mar 2013 18:12:48 +0000 References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <132E097C-4034-4560-9AE9-EC741561484D@ecs.soton.ac.uk> To: "v6ops@ietf.org WG" In-Reply-To: X-Mailer: Apple Mail (2.1503) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p2PICs043064615100; tid=p2PICs0430646151yS; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r2QICsDi000791 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 18:13:02 -0000 --Apple-Mail=_DEF91175-0749-458F-B46C-51668D363AFA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 26 Mar 2013, at 14:00, cb.list6 wrote: > On Mar 26, 2013 6:52 AM, "Lorenzo Colitti" wrote: > > > > Informational. > > > > The way I see it, the scenarios in this document are not current = practice, because they are not currently deployed to any substantial = degree. And if this document is not current practice, then it cannot be = Best Current Practice. > > >=20 > What does substantial degree mean ? >=20 > I have ULAs deployed at several places in my network consistent with = the draft. >=20 > I too am fine with informational status, but these ideas have been = applied. >=20 I think Informational. If RFC4890 is Informational, then this certainly is. Like 4890, it could be upgraded in due course. Tim --Apple-Mail=_DEF91175-0749-458F-B46C-51668D363AFA Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On 26 Mar 2013, at 14:00, cb.list6 <cb.list6@gmail.com> wrote:

On Mar 26, 2013 6:52 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
> Informational.
>
> The way I see it, the scenarios in this document are not current practice, because they are not currently deployed to any substantial degree. And if this document is not current practice, then it cannot be Best Current Practice.
>

What does substantial degree mean ?

I have ULAs deployed at several places in my network consistent with the draft.

I too am fine with informational status, but these ideas have been applied.

I think Informational.

If RFC4890 is Informational, then this certainly is.

Like 4890, it could be upgraded in due course.

Tim

--Apple-Mail=_DEF91175-0749-458F-B46C-51668D363AFA-- From lorenzo@google.com Tue Mar 26 18:46:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCC921E8043 for ; Tue, 26 Mar 2013 18:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 or2-s6TawCMj for ; Tue, 26 Mar 2013 18:46:08 -0700 (PDT) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id EB19921E803F for ; Tue, 26 Mar 2013 18:46:07 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id g12so4915419oah.24 for ; Tue, 26 Mar 2013 18:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=aGH3m76OhXDaFs2MLfbcusP7NKF6YxDyyN2Isz7Z1p0=; b=o20wtBxyf6BuWkntzIfpgOPRQM27GfK9mWHdzBH1bHaC/7q2dqcecaQXEd4r3tKq/6 cAogZlWzTu1hoLRD/LAT9/KdJiOS9QY2cKUsk+0nVvdh0TuWP7rRBr9X9VAwSsHIGh+1 AtY4rQzmjr1AgIP/UV3BpXhhtPQP7X/4TaUVTHMVkuXV/xl9Eu9nNCp/WN7DjO/LTuJA VWvG2P4T6faiNAYoc9s6QpqRyvsvAUi6NgjxVTb7mPYQYoCpuUVBPCjplYyxt9DicxtT gZyx+46C2QyH/ff0hQvbXQS1xijr2gnR/XlO2MIixr/0jnzF4o/wAfba70iYXqkgrslp IgrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=aGH3m76OhXDaFs2MLfbcusP7NKF6YxDyyN2Isz7Z1p0=; b=GrZtvxzxj8ipbyULYTRUk0hopdKE7pixstLQpeTIlvizKpvI/BWE6RZcNPWcLMlEx/ /h7Nc5JUViKZTOK5IHajcb/IEb1KY31N47teL7Z11sWqXeMor4mUvKd2oNsh1BEsg/2k R4nnhlQEUmRf8luqT8xocHptCrhnQemBQ3o470WWv5FuJmSlY7V8SGYdneyyc7meIFOv c1ImKYHiKc8/U7SU80K8nydntLzCTfYo2Fk7bIee5aXTI3U4zHmjuASVYSUdnrTlRgbH a3nbHk0gNLiI/uhgGj7lLuyu7bgn7GAtvZkDdCeSrvOGLR6coy2PuyIF0j7sXCV4vy9E j3WQ== X-Received: by 10.182.34.131 with SMTP id z3mr3066693obi.81.1364348767444; Tue, 26 Mar 2013 18:46:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Tue, 26 Mar 2013 18:45:47 -0700 (PDT) In-Reply-To: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> From: Lorenzo Colitti Date: Wed, 27 Mar 2013 10:45:47 +0900 Message-ID: To: "cb.list6" Content-Type: multipart/alternative; boundary=001a11c2a304a242ee04d8de3370 X-Gm-Message-State: ALoCoQlzf/Q8W5PjXC6pgmR9uWY4fkE0MEQB86MLqqNNIkJwPNHFwMUkLHtNYctnH4DA+lyCU925yWBLEr8dCf6mCIH90bzH/iXhudYR8DWAe5EbCebi8i0ZJz/orQR2uFjh65ftFBruPfUMcnpsrYgaCNjK0JZgeCb8UF5La6vtRDU6/86Fm4d6sqcOgiGIGhtZtjSc7ApD Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 01:46:08 -0000 --001a11c2a304a242ee04d8de3370 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 26, 2013 at 11:00 PM, cb.list6 wrote: > What does substantial degree mean ? > "Deployments in multiple different networks of each of the scenarios in the draft" would be a minimum requirement, I'd think. > I too am fine with informational status, but these ideas have been applied. > Which ones? All of them? --001a11c2a304a242ee04d8de3370 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 26, 2013 at 11:00 PM, cb.list6 <cb.list6@gma= il.com> wrote:

What does substantial degree mean ?

"Deployments in multiple different networks of each of the = scenarios in the draft" would be a minimum requirement, I'd think.=

I too = am fine with informational status, but these ideas have been applied.

Which ones? All of them?=A0
<= /div>
--001a11c2a304a242ee04d8de3370-- From shtsuchi@cisco.com Tue Mar 26 20:41:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DDF21F8767 for ; Tue, 26 Mar 2013 20:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2RRgEVHou1t for ; Tue, 26 Mar 2013 20:41:00 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7B46521E803F for ; Tue, 26 Mar 2013 20:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1410; q=dns/txt; s=iport; t=1364355660; x=1365565260; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=XMdoQq3FePXUHdl6hNfxC+l/Em3jMZ95cyAX5Y7O3F4=; b=FZ2OvY8uGkRaLqOb0sbCvcMdwsMGnLQVmpjRg0idVjs+wpy53Tjw4bsz k9A2csud6I9dkFsPFHQtJy5m6hmYDQCytwpmBgioWcFKEEjD8qFGkJGZM pvLa5K90I6F0u8AQk+fqhT2y6x8Hvcb3oLstKV7YvF9zaxObnju24RnTv A=; X-IronPort-AV: E=Sophos;i="4.84,915,1355097600"; d="scan'208";a="81570579" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 27 Mar 2013 03:40:59 +0000 Received: from [10.141.43.192] (dhcp-10-141-43-192.cisco.com [10.141.43.192]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2R3etce020051; Wed, 27 Mar 2013 03:40:56 GMT Message-ID: <51526A1C.5030908@cisco.com> Date: Wed, 27 Mar 2013 12:40:12 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 03:41:02 -0000 Informational. And it should investigate more detail. Regards, -Shishio (2013/03/26 20:56), Liubing (Leo) wrote: > Hi, Dear all > > [Note: You can also raise some topic you consider as important with the prefix "ULA discussion #", so that the future discussion could be easily tracked. Thank you.] > > This post is regarding the document should be a "BCP" or "Informational". > Personally, either BCP or Informational is OK for me. But I'd like to discuss it in the perspective of the document. > > I checked RFC2026 (The Internet Standards Process -- Revision 3), in section 5, the BCP document is described as "a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function." > > So, I believe it is a good goal to publish the ULA draft as a BCP, I think the position is valuable for the readers. However, some texts (especially NAT relative) are still controversy that might not be consensus of representing "the community's best current thinking". But let's try to find the common view/principle out of the controversy materials, if not applicable, then it is OK to be Informational. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From randy@psg.com Tue Mar 26 23:15:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B1921F8804 for ; Tue, 26 Mar 2013 23:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 3IxwjwKG5Lfp for ; Tue, 26 Mar 2013 23:15:01 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id B1F7B21F906B for ; Tue, 26 Mar 2013 23:15:01 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UKjdP-00042b-Hh; Wed, 27 Mar 2013 06:14:55 +0000 Date: Wed, 27 Mar 2013 15:14:54 +0900 Message-ID: From: Randy Bush To: Lorenzo Colitti In-Reply-To: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 06:15:02 -0000 BOP == bad occasional practice From randy@psg.com Tue Mar 26 23:16:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5707921F9079 for ; Tue, 26 Mar 2013 23:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 jRqDatlT2Q5I for ; Tue, 26 Mar 2013 23:16:56 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 0552621F9077 for ; Tue, 26 Mar 2013 23:16:56 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UKjfL-000437-3M; Wed, 27 Mar 2013 06:16:55 +0000 Date: Wed, 27 Mar 2013 15:16:54 +0900 Message-ID: From: Randy Bush To: Alexandru Petrescu In-Reply-To: <5151C83B.1010203@gmail.com> References: <5151C83B.1010203@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 06:16:56 -0000 > Is there an interest in DHCPv6 Route/DefRouter/Src-basedRoute > configuration to Client? it would make it easier for current enterprise operators to add ipv6 to their network. this has long been considered unacceptable by the ipv6 gods. randy From lorenzo@google.com Tue Mar 26 23:46:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54BA921F9041 for ; Tue, 26 Mar 2013 23:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.577 X-Spam-Level: X-Spam-Status: No, score=-101.577 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 vjR3qlvXteBy for ; Tue, 26 Mar 2013 23:46:49 -0700 (PDT) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id B46E321F9039 for ; Tue, 26 Mar 2013 23:46:49 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id k1so8445451oag.5 for ; Tue, 26 Mar 2013 23:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=22D6F9FvelvYSujLsPenbh01Xz54GKGIIvWaAjMTPns=; b=cz2Nn8ghI+/wyWSWGKP4+4sdS00diftZ2DRH2tWx4u2nQf2B8JtRVtO4NldD6cHHKg CJ0mPs2iWCnWpq8XCOOcTNM1XI1D6sBv/0Cj9KXezRbWOy0dFnh9S7pYa8TflTQrT8Y2 iLco8tYV3510UqyTt1vRlRK+vecuULLHhFaLMvWRofd3UK5xlB4wDy3yg645dNz1mYR9 IozUYxvXjbOHE4EtZB4wnsdNs0TFoUh3jo/5d+c87Da7L7IiYXM+J5/nsf4EKl5blfur gayXBi3wpZjgP0FCGe1i0zeZjsoEgOY2AdTFVgvb9uJr+14wDfUCOrXVYjXMaPIZUiBC aoeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=22D6F9FvelvYSujLsPenbh01Xz54GKGIIvWaAjMTPns=; b=Bk1L5Rm5wZlRCWDZFfC6flN8BJa0DyGIFR/F+b/fUWdATatIGIk0NNEOh/qnU9kyWw hnNHoYp2yo3agoYMLFhOR63GdJvrocTviqgRBSbcJQrj5hQqWflu/yyFj/KnfzKn4H4o adohwVNdyy8yJK0N4k1bK6tg8CTlx0GxY7z0JWvBf5wLlH5ENRLpimQRNVFctG1nH3W8 jZrpywE8kau0Ew2D0wXxIfZUun23/vcU6SeejkrXAgJpxTlgyTPNLc5FGDddz8ijiGLN kEh+hL6nyMf8KjvX3mY9k3NieipcCUtr8H6Zy+rxLWEuS1m6RzOUonOZMF/1p0vx7qFt y7Mg== X-Received: by 10.182.34.131 with SMTP id z3mr3314149obi.81.1364366809223; Tue, 26 Mar 2013 23:46:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Tue, 26 Mar 2013 23:46:29 -0700 (PDT) In-Reply-To: <5151C83B.1010203@gmail.com> References: <5151C83B.1010203@gmail.com> From: Lorenzo Colitti Date: Wed, 27 Mar 2013 15:46:29 +0900 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=001a11c2a30401f95904d8e267ae X-Gm-Message-State: ALoCoQlm/Cc1DVMuLNbkNHvfetLHSaAAuZQAgjKBCNBEy6S7qTAacnIar9cFUtGaNXLddaijNviadzuZxUFBR0P64eB2y9cuAUXomGSXfo0wlkbsVfekz87ICr3rWb5m6r2LwT8hhvMMrH+AROX3aqGMDYd+qttZ8R3IJz9xKBM93hJkJdrAYGmEHIT/p+rTQVsLNbewkiR9 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 06:46:50 -0000 --001a11c2a30401f95904d8e267ae Content-Type: text/plain; charset=ISO-8859-1 Alexandru, v6ops does not create protocols. You should probably take this to 6man. Regards, Lorenzo On Wed, Mar 27, 2013 at 1:09 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Dear participants to V6OPS, > > Is there an interest in DHCPv6 Route/DefRouter/Src-basedRoute > configuration to Client? > > As one may remember, there was much discussion in several groups about > DHCPv6 delivering routing information to Clients: generic routes, > default routers' addresses and routes keyed by source address. > > The MIF WG has produced a document > draft-ietf-mif-dhcpv6-route-**option-05 > but it is recently dropped from the MIF Charter to allow group to > re-focus on a MIF topic. > > An individual proposal about DHCPv6 Default Routers List that I > co-author is in > draft-mouton-mif-dhcpv6-drlo-**02.txt > which takes on an earlier draft-droms-dhc-dhcpv6-**default-router > > In the DHCWG there was recently discussion about IEEE 802.11ai needing > to configure DefaultRouters by using link-layer messaging, or > alternatively DHCP. With a purpose to realize fast configuration in > crowded hotspot areas for highly mobile STAs. > > Also in DHCWG there was discussion about the src-based routes being > communicated to Client with DHCPv6. > > Is there an interest in DHCPv6 Route/DefRouter/Src-basedRoute > configuration to Client? > > Alex > > ______________________________**_________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/**listinfo/v6ops > --001a11c2a30401f95904d8e267ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Alexandru,

v6ops does not create protoc= ols. You should=A0probably=A0take this to 6man.

Regards,
Lorenzo


On Wed, Mar 27, 2013 at 1:09 AM, Alexandru Petrescu <<= a href=3D"mailto:alexandru.petrescu@gmail.com" target=3D"_blank">alexandru.= petrescu@gmail.com> wrote:
Dear participants to V6OPS,

Is there an interest in DHCPv6 Route/DefRouter/Src-basedRoute
configuration to Client?

As one may remember, there was much discussion in several groups about
DHCPv6 delivering routing information to Clients: generic routes,
default routers' addresses and routes keyed by source address.

The MIF WG has produced a document
draft-ietf-mif-dhcpv6-route-option-05
but it is recently dropped from the MIF Charter to allow group to
re-focus on a MIF topic.

An individual proposal about DHCPv6 Default Routers List that I
co-author is in
draft-mouton-mif-dhcpv6-drlo-02.txt
which takes on an earlier =A0draft-droms-dhc-dhcpv6-default-router
In the DHCWG there was recently discussion about IEEE 802.11ai needing
to configure DefaultRouters by using link-layer messaging, or
alternatively DHCP. =A0With a purpose to realize fast configuration in
crowded hotspot areas for highly mobile STAs.

Also in DHCWG there was discussion about the src-based routes being
communicated to Client with DHCPv6.

Is there an interest in DHCPv6 Route/DefRouter/Src-basedRoute
configuration to Client?

Alex

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

--001a11c2a30401f95904d8e267ae-- From iljitsch@muada.com Wed Mar 27 00:54:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BDE21F90A4 for ; Wed, 27 Mar 2013 00:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKKm+hukXGWp for ; Wed, 27 Mar 2013 00:54:44 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id DC8CC21F90A9 for ; Wed, 27 Mar 2013 00:54:41 -0700 (PDT) Received: from [IPv6:2001:470:1f0b:1289:98af:7d78:2a4e:9bce] ([IPv6:2001:470:1f0b:1289:98af:7d78:2a4e:9bce]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2R7nXT6024789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Mar 2013 08:49:34 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <5151C83B.1010203@gmail.com> Date: Wed, 27 Mar 2013 08:54:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> References: <5151C83B.1010203@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 07:54:49 -0000 On 26 mrt 2013, at 17:09, Alexandru Petrescu = wrote: > Is there an interest in DHCPv6 Route/DefRouter/Src-basedRoute > configuration to Client? The big issue with having DHCPv6 deliver a default route is that it = breaks the fate sharing that having the default router address in a = router advertisement from the router holding that address provides. But I gather there are people who want to be able to make one group of = hosts on a subnet use router A as their default router but another group = of hosts router B, on that same subnet. My suggestion: rather than having a DHCPv6 option that flat out = specifies a default router address, make an option that tells the host = which router address it should pick when multiple are available. If = everything is configured correctly this leads to the exact same result, = but it degrades much more gracefully when there are problems. Also, don't forget that the DHCPv6 implementation is not a = user-serviceable part in the most widely used operating systems, and as = such it will take a long time to get anything new implemented = (publication of RFC 3315 -> implementation in MacOS: 8 years) so there = will be a long time during which hosts not supporting the new option and = hosts supporting the new option will have to coexist. One might also observe that routing protocols exist and their = convergence properties are a better fit to the task of delivering = routing information than that of DHCP.= From dougb@dougbarton.us Wed Mar 27 01:13:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F41621F8FF2 for ; Wed, 27 Mar 2013 01:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315] 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 8WHrfQoK1h0N for ; Wed, 27 Mar 2013 01:13:50 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 59A3721F8FF0 for ; Wed, 27 Mar 2013 01:13:50 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:8858:6569:5523:c5ad] (unknown [IPv6:2001:470:d:5e7:8858:6569:5523:c5ad]) by dougbarton.us (Postfix) with ESMTPSA id D68D722B0F for ; Wed, 27 Mar 2013 08:13:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1364372030; bh=VIP4lEHhyMcfaoJbJQHr9810TyL+3+1r1q5RKIccwHI=; h=Date:From:To:Subject:References:In-Reply-To; b=DWyl8G4xJA1ga8d6Zfg90UYQeTiS8nfQzO/U4+e/oN4mTOUFq1+qrB4aaai6VJTjh efuPMumNI/cAo5MNo+9LlAyJcPjj6AsR4IjQ7MpViK47ryt/NalBVjekqfEerVQmTD maoX6nGKkWIrkf3KYC2jDFiSiV4yXzLOczCmgmTg= Message-ID: <5152AA3D.80606@dougbarton.us> Date: Wed, 27 Mar 2013 01:13:49 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> In-Reply-To: <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 08:13:51 -0000 On 3/27/2013 12:54 AM, Iljitsch van Beijnum wrote: > The big issue with having DHCPv6 deliver a default route is that it breaks the fate sharing that having the default router address in a router advertisement from the router holding that address provides. And yet that's not a problem for the hundreds of millions of hosts in the world configured with DHCPv4. Doug From brian.e.carpenter@gmail.com Wed Mar 27 01:33:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C282921F9028 for ; Wed, 27 Mar 2013 01:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.932 X-Spam-Level: X-Spam-Status: No, score=-99.932 tagged_above=-999 required=5 tests=[AWL=1.159, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, 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 t3dPidXdd-h2 for ; Wed, 27 Mar 2013 01:33:40 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id 18FC021F9027 for ; Wed, 27 Mar 2013 01:33:39 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id m15so222353wgh.3 for ; Wed, 27 Mar 2013 01:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FDf334ItxSdYA14+6K2K+ZmeFuG4ULXal/zb4HnjDqY=; b=r+a24mdsd8dz9hGxn9VglttbAj5hn2p/aOouCYfMGtv4fe64aI5W4oyaVq+yoAQy95 LaWEiNVd0dB9FmFBr56jtOzWJBBEQ4lX9g5Wv7i8q84HdX3YTfzZ/o6j4TrTZOHWq2IP W5apuVrrvbTvIAlfhuXiGefy7Z8IpZ5A6rtUWdn1NyLnttAdtWP1TgbrWhcDbRSAk3vA HY3243vbk5dCCeeC/bU35PFh6w6aUkTvRA97I70aSQar4oJ7jSZoHxas2Icx3onpkj73 xH575Y5iD0lG7TF9I8RL/FvCs7GJ7hMzjstupfMbJ6RJaMfLGLMyTOLVI9EMOBL2hPv7 LCdQ== X-Received: by 10.180.103.40 with SMTP id ft8mr8051128wib.28.1364373219230; Wed, 27 Mar 2013 01:33:39 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-189-245.as13285.net. [2.101.189.245]) by mx.google.com with ESMTPS id s2sm8125762wib.4.2013.03.27.01.33.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Mar 2013 01:33:38 -0700 (PDT) Message-ID: <5152AEE8.4010500@gmail.com> Date: Wed, 27 Mar 2013 08:33:44 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Liubing (Leo)" References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 08:33:40 -0000 I think we have a much better chance of reaching consensus with Informational status, because it limits the content to description of scenarios that are expected to work, and removes endless arguments about whether we recommend any of those scenarios. Regards Brian On 26/03/2013 11:56, Liubing (Leo) wrote: > Hi, Dear all > > [Note: You can also raise some topic you consider as important with the prefix "ULA discussion #", so that the future discussion could be easily tracked. Thank you.] > > This post is regarding the document should be a "BCP" or "Informational". > Personally, either BCP or Informational is OK for me. But I'd like to discuss it in the perspective of the document. > > I checked RFC2026 (The Internet Standards Process -- Revision 3), in section 5, the BCP document is described as "a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function." > > So, I believe it is a good goal to publish the ULA draft as a BCP, I think the position is valuable for the readers. However, some texts (especially NAT relative) are still controversy that might not be consensus of representing "the community's best current thinking". But let's try to find the common view/principle out of the controversy materials, if not applicable, then it is OK to be Informational. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Wed Mar 27 01:41:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4641221F8F67 for ; Wed, 27 Mar 2013 01:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.692 X-Spam-Level: X-Spam-Status: No, score=-98.692 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 X6r2GRUWgjfl for ; Wed, 27 Mar 2013 01:41:41 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 98F1021F8E94 for ; Wed, 27 Mar 2013 01:41:41 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so236379wgg.2 for ; Wed, 27 Mar 2013 01:41:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Za2AvShG0um+7WVDYuzna3OdJOhDkBdYaA5Td+KQ4dw=; b=ff6VimCmGjnUPLb7bhfUHlBaAnDSeINkLd9UFrC6c6xk8WgwNQ310Kyzb8FwnCq3b8 /nuftKOeN8aWzoMFmR+6jsOsiMHYVSIzBEbniPVZuUALjkyX//z+BPKJ1+WbKtMk7rdK kXETmKcN+UADpJ8KNnELZOp8R0RkHvqDdMh1S9SwFI4z921Wjb92WluODyV1M2hRESEk NHbj1aXdlDNgcRC2A/T8oTvNg8ACkI6yFtDc8wGa8yCZMQeJKxCZrOeJ2Rv9LvGeVeGt 7MWxyD5uSTyc4fTJJhcxmGr+X0VitFtut3TH4HlL/ajZ1ndXbscA5EjtXhBvhkhA8E+8 CWDw== X-Received: by 10.194.57.137 with SMTP id i9mr29719948wjq.18.1364373699593; Wed, 27 Mar 2013 01:41:39 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-189-245.as13285.net. [2.101.189.245]) by mx.google.com with ESMTPS id fg6sm8124272wib.10.2013.03.27.01.41.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Mar 2013 01:41:38 -0700 (PDT) Message-ID: <5152B0C9.8010906@gmail.com> Date: Wed, 27 Mar 2013 08:41:45 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "v6ops@ietf.org" References: <5151C83B.1010203@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 08:41:42 -0000 On 27/03/2013 06:46, Lorenzo Colitti wrote: > Alexandru, > > v6ops does not create protocols. You should probably take this to 6man. I think he's asking whether there is an operational need for this. If there's an operational need, the actual protocol development will be done elsewhere. It might be reasonable to develop a requirements document here. I'm not an operator, but it seems to me that any site planning to use DHCPv6 to manage its IPv6 setup, including multiple prefixes, would be looking for something in this space. On 27/03/2013 06:16, Randy Bush wrote: > it would make it easier for current enterprise operators to add ipv6 > to their network. this has long been considered unacceptable by the > ipv6 gods. The gods must be crazy. Brian From v6ops@globis.net Wed Mar 27 01:48:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBED21F90D4 for ; Wed, 27 Mar 2013 01:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.142 X-Spam-Level: X-Spam-Status: No, score=-1.142 tagged_above=-999 required=5 tests=[AWL=1.142, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 abe6qoq8EUpG for ; Wed, 27 Mar 2013 01:48:29 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6700621F85B3 for ; Wed, 27 Mar 2013 01:48:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 9E36A870085; Wed, 27 Mar 2013 09:48:13 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id or9OTXtyJb4b; Wed, 27 Mar 2013 09:48:04 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 9EC9C87007B; Wed, 27 Mar 2013 09:48:04 +0100 (CET) Message-ID: <5152B23E.9080306@globis.net> Date: Wed, 27 Mar 2013 09:47:58 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Doug Barton References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <5152AA3D.80606@dougbarton.us> In-Reply-To: <5152AA3D.80606@dougbarton.us> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 08:48:30 -0000 Doug Barton wrote: > On 3/27/2013 12:54 AM, Iljitsch van Beijnum wrote: >> The big issue with having DHCPv6 deliver a default route is that it >> breaks the fate sharing that having the default router address in a >> router advertisement from the router holding that address provides. > > And yet that's not a problem for the hundreds of millions of hosts in > the world configured with DHCPv4. > > Doug > > Exactly. We have NUD in IPv6. The default router list populated by RA is "A list of routers to which packets may be sent." Note the may. Any end node that continues to send packets to a dead router when it has feasible alternatives is brain dead. From jiangsheng@huawei.com Wed Mar 27 01:50:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4D721F90EC for ; Wed, 27 Mar 2013 01:50:33 -0700 (PDT) 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_13=0.6, 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 kUJt0JRaF+U2 for ; Wed, 27 Mar 2013 01:50:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0F77921F90E5 for ; Wed, 27 Mar 2013 01:50:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARD32623; Wed, 27 Mar 2013 08:50:30 +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.7; Wed, 27 Mar 2013 08:50:14 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Mar 2013 08:50:27 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.21]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Wed, 27 Mar 2013 16:50:15 +0800 From: Sheng Jiang To: Brian E Carpenter , "Liubing (Leo)" Thread-Topic: [v6ops] ULA discussion #BCP or Informational Thread-Index: Ac4qGON521++zMpPThuXXXszdE4eKgAadk0AABE4SdA= Date: Wed, 27 Mar 2013 08:50:15 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AA06B9D@nkgeml512-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <5152AEE8.4010500@gmail.com> In-Reply-To: <5152AEE8.4010500@gmail.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.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 08:50:33 -0000 PkkgdGhpbmsgd2UgaGF2ZSBhIG11Y2ggYmV0dGVyIGNoYW5jZSBvZiByZWFjaGluZyBjb25zZW5z dXMgd2l0aA0KPkluZm9ybWF0aW9uYWwgc3RhdHVzLCBiZWNhdXNlIGl0IGxpbWl0cyB0aGUgY29u dGVudCB0byBkZXNjcmlwdGlvbg0KPm9mIHNjZW5hcmlvcyB0aGF0IGFyZSBleHBlY3RlZCB0byB3 b3JrLCBhbmQgcmVtb3ZlcyBlbmRsZXNzIGFyZ3VtZW50cw0KPmFib3V0IHdoZXRoZXIgd2UgcmVj b21tZW5kIGFueSBvZiB0aG9zZSBzY2VuYXJpb3MuDQoNCkFncmVlLiBJdCBpcyBiZXR0ZXIgdG8g c3RhcnQgYXMgSW5mb3JtYXRpb25hbCwgZ2l2aW5nIHRoYXQgdGhlcmUgYXJlIHN0aWxsIGEgbG90 IHVuY2VydGFpbm5lc3MgZm9yIHJlY29tbWVuZGF0aW9ucy4gSWYgaW4gdGhlIGRldmVsb3Bpbmcg cHJvY2VzcyBvZiB0aGlzIGRvY3VtZW50LCB0aGUgY29tbXVuaXR5IHJlYWNoZXMgY29uc2Vuc3Vz IG9uIGFsbCByZWNvbW1lbmRhdGlvbiBvciBndWlkYW5jZSwgaXQgbWF5IGJlIHVwZ3JhZGVkLg0K DQpSZWdhcmRzLA0KDQpTaGVuZw0KDQo+UmVnYXJkcw0KPiAgIEJyaWFuDQo+DQo+T24gMjYvMDMv MjAxMyAxMTo1NiwgTGl1YmluZyAoTGVvKSB3cm90ZToNCj4+IEhpLCBEZWFyIGFsbA0KPj4NCj4+ IFtOb3RlOiBZb3UgY2FuIGFsc28gcmFpc2Ugc29tZSB0b3BpYyB5b3UgY29uc2lkZXIgYXMgaW1w b3J0YW50IHdpdGggdGhlDQo+cHJlZml4ICJVTEEgZGlzY3Vzc2lvbiAjIiwgc28gdGhhdCB0aGUg ZnV0dXJlIGRpc2N1c3Npb24gY291bGQgYmUgZWFzaWx5IHRyYWNrZWQuDQo+VGhhbmsgeW91Ll0N Cj4+DQo+PiBUaGlzIHBvc3QgaXMgcmVnYXJkaW5nIHRoZSBkb2N1bWVudCBzaG91bGQgYmUgYSAi QkNQIiBvciAiSW5mb3JtYXRpb25hbCIuDQo+PiBQZXJzb25hbGx5LCBlaXRoZXIgQkNQIG9yIElu Zm9ybWF0aW9uYWwgaXMgT0sgZm9yIG1lLiBCdXQgSSdkIGxpa2UgdG8gZGlzY3VzcyBpdA0KPmlu IHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgZG9jdW1lbnQuDQo+Pg0KPj4gSSBjaGVja2VkIFJGQzIw MjYgKFRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgUHJvY2VzcyAtLSBSZXZpc2lvbiAzKSwgaW4gc2Vj dGlvbg0KPjUsIHRoZSBCQ1AgZG9jdW1lbnQgaXMgZGVzY3JpYmVkIGFzICJhIHZlaGljbGUgYnkg d2hpY2ggdGhlIElFVEYgY29tbXVuaXR5DQo+Y2FuIGRlZmluZSBhbmQgcmF0aWZ5IHRoZSBjb21t dW5pdHkncyBiZXN0IGN1cnJlbnQgdGhpbmtpbmcgb24gYSBzdGF0ZW1lbnQgb2YNCj5wcmluY2lw bGUgb3Igb24gd2hhdCBpcyBiZWxpZXZlZCB0byBiZSB0aGUgYmVzdCB3YXkgdG8gcGVyZm9ybSBz b21lDQo+b3BlcmF0aW9ucyBvciBJRVRGIHByb2Nlc3MgZnVuY3Rpb24uIg0KPj4NCj4+IFNvLCBJ IGJlbGlldmUgaXQgaXMgYSBnb29kIGdvYWwgdG8gcHVibGlzaCB0aGUgVUxBIGRyYWZ0IGFzIGEg QkNQLCBJIHRoaW5rIHRoZQ0KPnBvc2l0aW9uIGlzIHZhbHVhYmxlIGZvciB0aGUgcmVhZGVycy4g SG93ZXZlciwgc29tZSB0ZXh0cyAoZXNwZWNpYWxseSBOQVQNCj5yZWxhdGl2ZSkgYXJlIHN0aWxs IGNvbnRyb3ZlcnN5IHRoYXQgbWlnaHQgbm90IGJlIGNvbnNlbnN1cyBvZiByZXByZXNlbnRpbmcg InRoZQ0KPmNvbW11bml0eSdzIGJlc3QgY3VycmVudCB0aGlua2luZyIuIEJ1dCBsZXQncyB0cnkg dG8gZmluZCB0aGUgY29tbW9uDQo+dmlldy9wcmluY2lwbGUgb3V0IG9mIHRoZSBjb250cm92ZXJz eSBtYXRlcmlhbHMsIGlmIG5vdCBhcHBsaWNhYmxlLCB0aGVuIGl0IGlzIE9LDQo+dG8gYmUgSW5m b3JtYXRpb25hbC4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4+IHY2b3BzQGlldGYub3JnDQo+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+Pg0KPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+djZvcHMgbWFpbGluZyBsaXN0 DQo+djZvcHNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Y2b3BzDQo= From iljitsch@muada.com Wed Mar 27 01:55:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F1521F900B for ; Wed, 27 Mar 2013 01:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, 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 7nK3v7v5gw0n for ; Wed, 27 Mar 2013 01:55:47 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id B120A21F9001 for ; Wed, 27 Mar 2013 01:55:46 -0700 (PDT) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2R8odRa025135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Mar 2013 09:50:39 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <5152AA3D.80606@dougbarton.us> Date: Wed, 27 Mar 2013 09:55:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <05033B02-2931-481B-AFDF-7CAE4EC9FF64@muada.com> References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <5152AA3D.80606@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 08:55:47 -0000 On 27 mrt 2013, at 9:13, Doug Barton wrote: >> The big issue with having DHCPv6 deliver a default route is that it = breaks the fate sharing that having the default router address in a = router advertisement from the router holding that address provides. > And yet that's not a problem for the hundreds of millions of hosts in = the world configured with DHCPv4. Ah yes, but what about the hosts that fail to be configured with IPv4 = DHCP? We all experience this from time to time, but few people realize = that it's the DHCP that's the issue.= From markzzzsmith@yahoo.com.au Wed Mar 27 02:05:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA2421F90F1 for ; Wed, 27 Mar 2013 02:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.24 X-Spam-Level: X-Spam-Status: No, score=-0.24 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FROM_LOCAL_NOVOWEL=0.5] 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 qd0H1NlD1bCL for ; Wed, 27 Mar 2013 02:05:08 -0700 (PDT) Received: from nm5-vm0.bullet.mail.bf1.yahoo.com (nm5-vm0.bullet.mail.bf1.yahoo.com [98.139.213.150]) by ietfa.amsl.com (Postfix) with SMTP id 14C7B21F90E7 for ; Wed, 27 Mar 2013 02:05:07 -0700 (PDT) Received: from [98.139.215.140] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 27 Mar 2013 09:05:07 -0000 Received: from [98.139.212.196] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 27 Mar 2013 09:05:07 -0000 Received: from [127.0.0.1] by omp1005.mail.bf1.yahoo.com with NNFMP; 27 Mar 2013 09:05:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 494398.1121.bm@omp1005.mail.bf1.yahoo.com Received: (qmail 62293 invoked by uid 60001); 27 Mar 2013 09:05:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1364375107; bh=kWb/rIz1n+OyXVvgiqhVrdbw5LWJ+qDXuzusEdrpaiE=; 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=x05VEe/J8NTO20F9zX/+B75qMlDextwpNFi3oJX5rXfVJhd4QNTBwYBkWBiinQ98pO56IfS6MEKUnJXhynRkj2UMkA/AESR/HsBW2KAfIID+gZ9eYC/S1oVo2W1fdeaz9uxJbuR7U9xJBleFdlTT2r/ZoiAmahJULakk93mOXH0= 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=3baa8zOydzTrb1bzKMrSrC5UX9wh7sQOKWyVcskLL86cD0P6N7M6oDR/hxK1Oi6T8FAHjuS9yDCHpnMahnKKa/lZk5o3Ft7y9hE69g+yLBvEdMJKLbQVwpJc7bShoX6fyehvk37NwNDKlrIh8CxaMIXRGYaUI5pu88fpSQPPYpU=; X-YMail-OSG: 9hjummkVM1n4MfYKxDbdmE8SvCJe4kBssUK1oY67LKN2gug ISGd31w1U8TA8t0XnhnTC4FeXtQUBgEDBIjnD12W_DHamqsUuhht4kBSRJ54 a4NUmDKVZ1GpoZ7rwjh.BNPTpxszHKMAqbJV44ti2IjARbXKRo74RU4.nXsy 4gsg4k7FFClsr8fYX2rOME1Iu3TaNGn_Iqn4WJtTw2ebpk27.h2Rr2dTAUgC dK0ncTRZ.8XVIvqOdTF71yU8GS4gFAPExFtFfdQvgRRJ10bIEwSvyGeM4.qa 7BtdPNAW.RioeU9.adlizX1E.NzyvbAcIhqj.Vc3oslNd7F1Ldzl2PxPA3IS eT2IT_p5Uxvd87FecTDTQAgfND79TF3jfadL8Ffo18ldh1HUjTxMlWLTMigK p3H4Mb_ilb9OD.HQz.GRO_DKzgd58zvcNjU.ZjyHF90qRG61YVdYEvzo06ed 62G.CUE7XGieK0AhgNQ4fI5l4tncyiF9mPsNmNmXuAvB4KQs0uGO8JyR.j2b n3uucr21DOIruEhdniNk9.UPQow-- Received: from [150.101.221.237] by web142504.mail.bf1.yahoo.com via HTTP; Wed, 27 Mar 2013 02:05:07 PDT X-Rocket-MIMEInfo: 002.001, Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gRnJvbTogSWxqaXRzY2ggdmFuIEJlaWpudW0gPGlsaml0c2NoQG11YWRhLmNvbT4KPlRvOiBBbGV4YW5kcnUgUGV0cmVzY3UgPGFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb20.IAo.Q2M6ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGlldGYub3JnPiAKPlNlbnQ6IFdlZG5lc2RheSwgMjcgTWFyY2ggMjAxMyA2OjU0IFBNCj5TdWJqZWN0OiBSZTogW3Y2b3BzXSBJbnRlcmVzdCBpbiBESENQdjYgUm91dGUvRGVmUm91dGVyL1NyYy1iYXNlZFJvdXQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.139.530 References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> Message-ID: <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Wed, 27 Mar 2013 02:05:07 -0700 (PDT) From: Mark Smith To: Iljitsch van Beijnum , Alexandru Petrescu In-Reply-To: <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 09:05:09 -0000 >________________________________=0A> From: Iljitsch van Beijnum =0A>To: Alexandru Petrescu =0A>Cc:= "v6ops@ietf.org" =0A>Sent: Wednesday, 27 March 2013 6:54 = PM=0A>Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRout= e configuration to Client?=0A> =0A>On 26 mrt 2013, at 17:09, Alexandru Petr= escu wrote:=0A>=0A>> Is there an interest in= DHCPv6 Route/DefRouter/Src-basedRoute=0A>> configuration to Client?=0A>=0A= >The big issue with having DHCPv6 deliver a default route is that it breaks= the fate sharing that having the default router address in a router advert= isement from the router holding that address provides.=0A>=0A>But I gather = there are people who want to be able to make one group of hosts on a subnet= use router A as their default router but another group of hosts router B, = on that same subnet.=0A>=0A=0AThis should already possible using RAs, with = an example implementation being the clients section in radvd/radvd.conf. He= re is the manual page help text:=0A=0A=C2=A0=C2=A0 =C2=A0 =C2=A0 By =C2=A0d= efault =C2=A0radvd will send route advertisements so that every node on=0A= =C2=A0 =C2=A0 =C2=A0 =C2=A0the link can use them. =C2=A0The list of clients= (IPv6 address) to advertise=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0to, =C2=A0and =C2= =A0accept =C2=A0route solicitations from can be configured. =C2=A0If done,= =0A=C2=A0 =C2=A0 =C2=A0 =C2=A0radvd does not send send messages to the mult= icast addresses but to the=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0configured =C2=A0un= icast addresses only. =C2=A0Solicitations from other addresses=0A=C2=A0 =C2= =A0 =C2=A0 =C2=A0are refused. =C2=A0This is similar to UnicastOnly but incl= udes periodic mes=E2=80=90=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0sages =C2=A0and =C2= =A0incoming client access configuration. =C2=A0See examples section=0A=C2= =A0 =C2=A0 =C2=A0 =C2=A0for a use case of this.=0A=0A=C2=A0 =C2=A0 =C2=A0 = =C2=A0The definitions are of the form:=0A=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0clie= nts {=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list of IPv6= addresses=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0};=0A=0A=0AFurther into the manual = page is an example configuration:=0A=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0interface= eth0=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0{=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0AdvSendAdvert on;=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0prefix 2001:db8:0:1::/64=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0{=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0AdvOnLink on;=0A=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0AdvAutono= mous on;=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0};=0A=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clients=0A=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fe80::21f:16ff:fe06:= 3aab;=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0fe80::21d:72ff:fe96:aaff;=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0};=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0};=0A=0A=C2=A0 = =C2=A0 =C2=A0 =C2=A0This =C2=A0 configuration =C2=A0 would =C2=A0 =C2=A0onl= y =C2=A0 =C2=A0announce =C2=A0 =C2=A0the =C2=A0 =C2=A0prefix =C2=A0 =C2=A0t= o=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0fe80::21f:16ff:fe06:3aab =C2=A0and =C2=A0fe8= 0::21d:72ff:fe96:aaff. =C2=A0 Furthermore,=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0all= RA requests of other clients are denied.=0A=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0T= his may come in handy if you want to =C2=A0roll =C2=A0out =C2=A0IPv6 =C2=A0= only =C2=A0partially=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0because some clients are = broken or untested.=0A=0A=0A=0ARegards,=0A=0AMark. From leo.liubing@huawei.com Wed Mar 27 02:09:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6421B21F9016 for ; Wed, 27 Mar 2013 02:09:00 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOOJQb6k+IYd for ; Wed, 27 Mar 2013 02:08:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 28AC121F8F7D for ; Wed, 27 Mar 2013 02:08:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APV26802; Wed, 27 Mar 2013 09:08:58 +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.7; Wed, 27 Mar 2013 09:08:44 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 27 Mar 2013 09:08:57 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.42]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.01.0323.007; Wed, 27 Mar 2013 17:08:49 +0800 From: "Liubing (Leo)" To: Brian E Carpenter , "v6ops@ietf.org" Thread-Topic: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? Thread-Index: AQHOKjycwyFl488WUk28Ks8Bl1DeTZi4kwmAgAAgNICAAIqyYA== Date: Wed, 27 Mar 2013 09:08:48 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC5E2@nkgeml506-mbx.china.huawei.com> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> In-Reply-To: <5152B0C9.8010906@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 09:09:00 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Brian E Carpenter > Sent: Wednesday, March 27, 2013 4:42 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute > configuration to Client? >=20 > On 27/03/2013 06:46, Lorenzo Colitti wrote: > > Alexandru, > > > > v6ops does not create protocols. You should probably take this to 6man. >=20 > I think he's asking whether there is an operational need for this. >=20 > If there's an operational need, the actual protocol development will > be done elsewhere. It might be reasonable to develop a requirements > document here. >=20 > I'm not an operator, but it seems to me that any site planning to use > DHCPv6 to manage its IPv6 setup, including multiple prefixes, would > be looking for something in this space. [Bing] Agreed. In multihoming case, if the ISPs enabled ingress filtering, = then there comes an exit router selection problem, which seems requiring bo= th the hosts and the routers to deploy source-based routing. >=20 > On 27/03/2013 06:16, Randy Bush wrote: >=20 > > it would make it easier for current enterprise operators to add ipv6 > > to their network. this has long been considered unacceptable by the > > ipv6 gods. >=20 > The gods must be crazy. >=20 > Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Wed Mar 27 02:11:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC7821F8FFC for ; Wed, 27 Mar 2013 02:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.662 X-Spam-Level: X-Spam-Status: No, score=-101.662 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315, 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 xQU7Qjbc8Gmj for ; Wed, 27 Mar 2013 02:11:33 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2208521F90AF for ; Wed, 27 Mar 2013 02:11:32 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id er7so4369479obc.35 for ; Wed, 27 Mar 2013 02:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=g0RdsnSF2mNS9e3xoDcOUMIptI6Hp3QvBM9kHhiz5Gg=; b=GfMuP/5dA1nC6hAmu2Hei/yOmuXiSS2vPqTYim6ur5IgBTG8m+mm2pd7JM5JBB1GEg 0PynNqaMs+M+tzHCp2xIZq4si0sG/CwNqAG5VVMDn85zKiBa+KDsI8plZKHIgx/nPoeF 5MxbBEZAp/6Nud6Ia2oLpRtaqaERx4rmmU6vr+cj2t2kyhafXXt1qHYYkl342B3DnH8G 3QKQYo8REgZ3grvl+/plESvU0q0IASQe8NyvPdYi5oULqZ51KLhudONu9pUJMHDZSAiv dbyF9JdxzaMH25KelUQad6bjFPLJzb5+UJPTWPV6jxw2XnhKh2PUm/i7Xn8lOGlFczlz X6YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=g0RdsnSF2mNS9e3xoDcOUMIptI6Hp3QvBM9kHhiz5Gg=; b=KbDgFKH6PS+n7QWFQDZ0QrbDrjCAFKuwRrzDbopFjumnsnuw99sM4haj2p2SLcFvmC 2iLYVDXWWcRnPkw2aHPX7TPrb4gnbiZq33Y3EiiVADbVbHi0VGFOf8+cmJWk7vpTYBSd 7ptvZOHfFoAfFcHbuAJNyjhb7mUwb5SlOL8MumLmGCcuSjQfRRG2qUEHPxSnsbw4jny/ Fsri86hZ24qaMjZF2AETgO7/AShzf0eWCFUJrlWkaLmY2T6v0wKBzbvAm+ecUPM4uvp9 qL3Gmh3S85WoTeZhcFGjpBdU1fxwlXa6mC+AhNbP2lMnrnh2kBdCef1oazYettteYdHm dNNw== X-Received: by 10.182.108.104 with SMTP id hj8mr3551040obb.44.1364375488825; Wed, 27 Mar 2013 02:11:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Wed, 27 Mar 2013 02:11:08 -0700 (PDT) In-Reply-To: <5152AA3D.80606@dougbarton.us> References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <5152AA3D.80606@dougbarton.us> From: Lorenzo Colitti Date: Wed, 27 Mar 2013 18:11:08 +0900 Message-ID: To: Doug Barton Content-Type: multipart/alternative; boundary=f46d0447a1e95a312504d8e46cae X-Gm-Message-State: ALoCoQmoV468B33WOfd8EVzH2HEADfgUgRc+VWKnrAX6I+HdIqptCqwg/fSf5IAx9nmkCfERzrruczVCArIC3n9TiBEej6+DoleUuNS4igExsaEO5+0wf31zAXZZmeelpTKOL5EOvgFOJ6bSviyhsALtdTIGjH85kEwpPsW5/RK4eae50ErypitOLUkrK0tsv/weyfk/sNFz Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 09:11:34 -0000 --f46d0447a1e95a312504d8e46cae Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 27, 2013 at 5:13 PM, Doug Barton wrote: > The big issue with having DHCPv6 deliver a default route is that it breaks >> the fate sharing that having the default router address in a router >> advertisement from the router holding that address provides. >> > > And yet that's not a problem for the hundreds of millions of hosts in the > world configured with DHCPv4. But it is a problem for the network administrators, because they are forced to run VRRP to overcome the lack of fate sharing. --f46d0447a1e95a312504d8e46cae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 27, 2013 at 5:13 PM, Doug Barton <dougb@dou= gbarton.us> wrote:
The big issue with having DHCPv6 deliver a default route is that it breaks = the fate sharing that having the default router address in a router adverti= sement from the router holding that address provides.

And yet that's not a problem for the hundreds of millions of hosts in t= he world configured with DHCPv4.

But = it is a problem for the network administrators, because they are forced to = run VRRP to overcome the lack of fate sharing.
--f46d0447a1e95a312504d8e46cae-- From v6ops@globis.net Wed Mar 27 02:27:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA68621F90AF for ; Wed, 27 Mar 2013 02:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 HMk+CJ+4MgWq for ; Wed, 27 Mar 2013 02:27:40 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFE321F90A6 for ; Wed, 27 Mar 2013 02:27:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id DA6A787006B; Wed, 27 Mar 2013 10:27:21 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpzNTuugowvZ; Wed, 27 Mar 2013 10:27:05 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 570CA8700F7; Wed, 27 Mar 2013 10:27:05 +0100 (CET) Message-ID: <5152BB63.5060801@globis.net> Date: Wed, 27 Mar 2013 10:26:59 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Lorenzo Colitti References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <5152AA3D.80606@dougbarton.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 09:27:41 -0000 Lorenzo Colitti wrote: > On Wed, Mar 27, 2013 at 5:13 PM, Doug Barton > wrote: > > The big issue with having DHCPv6 deliver a default route is > that it breaks the fate sharing that having the default router > address in a router advertisement from the router holding that > address provides. > > > And yet that's not a problem for the hundreds of millions of hosts > in the world configured with DHCPv4. > > > But it is a problem for the network administrators, because they are > forced to run VRRP to overcome the lack of fate sharing. MIF thinks multi-interface is a problem with the current RA mechanism, so there should be interest. Not sure I get your logic, Lorenzo. If DHCPv6 was used to populate a default router list, how would there be a problem with fate sharing? (assuming more than one router in the default router list, more than one router acting as a DHCPv6 relay, and end nodes performing NUD) From internet-drafts@ietf.org Wed Mar 27 02:32:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607C921F90BB; Wed, 27 Mar 2013 02:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4gQFf7U+0JG; Wed, 27 Mar 2013 02:32:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDEBD21F90BD; Wed, 27 Mar 2013 02:32:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130327093238.29058.4046.idtracker@ietfa.amsl.com> Date: Wed, 27 Mar 2013 02:32:38 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 09:32:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Internet Protocol Version 6 (IPv6) Profile for Mobile De= vices Author(s) : David Binet Mohamed Boucadair Ales Vizdal Cameron Byrne Gang Chen Filename : draft-ietf-v6ops-mobile-device-profile-01.txt Pages : 16 Date : 2013-03-27 Abstract: This document specifies an IPv6 profile for mobile devices. It lists the set of features a mobile device is to be compliant with to connect to an IPv6-only or dual-stack mobile network. This document defines a different profile than the one for general connection to IPv6 mobile networks defined in [RFC3316]. In particular, this document identifies also features to ensure IPv4 service continuity over an IPv6-only transport. Both Hosts and devices with LAN capabilities are in scope. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device-profile-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iljitsch@muada.com Wed Mar 27 02:35:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FA021F8EB5 for ; Wed, 27 Mar 2013 02:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6EK5TVIQORO for ; Wed, 27 Mar 2013 02:35:05 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 19B6C21F900E for ; Wed, 27 Mar 2013 02:35:04 -0700 (PDT) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2R9Ti0l025458 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Mar 2013 10:29:44 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <5152BB63.5060801@globis.net> Date: Wed, 27 Mar 2013 10:34:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <25D0CBBD-9A56-475C-AC27-D1A10D38E331@muada.com> References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <5152AA3D.80606@dougbarton.us> <5152BB63.5060801@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1499) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 09:35:05 -0000 On 27 mrt 2013, at 10:26, Ray Hunter wrote: > If DHCPv6 was used to populate a default router list, how would there = be > a problem with fate sharing? > (assuming more than one router in the default router list, more than = one > router acting as a DHCPv6 relay, and end nodes performing NUD) The DHCPv6 server may supply an incorrect router address, for one of two = reasons: - misconfiguration - the router holding that address is down This problem doesn't occur with RAs because the router address in an RA = is automatically set so it can't be misconfigured, and if a router is = down it won't be sending RAs. Please note that we've had this discussion for many years now, it would = be more fruitful to explore alternate ways to get the desired behavior = than expecting the same arguments to be more persuasive this time = around. From mohamed.boucadair@orange.com Wed Mar 27 02:45:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0863E21F8FFF for ; Wed, 27 Mar 2013 02:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 134w8FW15OOw for ; Wed, 27 Mar 2013 02:45:05 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 1226421F8FDD for ; Wed, 27 Mar 2013 02:45:05 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id D9A5C22CD8F for ; Wed, 27 Mar 2013 10:45:03 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id C0DFB4C024 for ; Wed, 27 Mar 2013 10:45:03 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Wed, 27 Mar 2013 10:45:03 +0100 From: To: "v6ops@ietf.org" Date: Wed, 27 Mar 2013 10:45:02 +0100 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-01.txt Thread-Index: Ac4qzg1hh603tbrJRX28Hnz5BzolkgAAAhWQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EBBE68FFC@PUEXCB1B.nanterre.francetelecom.fr> References: <20130327093238.29058.4046.idtracker@ietfa.amsl.com> In-Reply-To: <20130327093238.29058.4046.idtracker@ietfa.amsl.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: 2013.3.25.85421 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 09:45:06 -0000 Dear all, The changes in the new version are as follows: (1) Tweak the text in the Abstract and Introduction to answer to the commen= t raised by F. Baker here: http://www.ietf.org/mail-archive/web/v6ops/curre= nt/msg15672.html (2) Soften the tone for REQ#29 as discussed with Mickael here: http://www.i= etf.org/mail-archive/web/v6ops/current/msg15742.html (3) Add a disclaimer some features require activating some functions at the= network side as suggested by Jouni (4) Add an explicit reference to RFC6434 + whenever needed, indicate whethe= r the new language form is stronger + Justification. The new version integrates all the comments received so far.=20 Cheers, Med >-----Message d'origine----- >De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De=20 >la part de internet-drafts@ietf.org >Envoy=E9 : mercredi 27 mars 2013 10:33 >=C0 : i-d-announce@ietf.org >Cc : v6ops@ietf.org >Objet : [v6ops] I-D Action:=20 >draft-ietf-v6ops-mobile-device-profile-01.txt > > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working=20 >Group of the IETF. > > Title : Internet Protocol Version 6 (IPv6)=20 >Profile for Mobile Devices > Author(s) : David Binet > Mohamed Boucadair > Ales Vizdal > Cameron Byrne > Gang Chen > Filename : draft-ietf-v6ops-mobile-device-profile-01.txt > Pages : 16 > Date : 2013-03-27 > >Abstract: > This document specifies an IPv6 profile for mobile devices.=20 > It lists > the set of features a mobile device is to be compliant with to > connect to an IPv6-only or dual-stack mobile network. > > This document defines a different profile than the one for general > connection to IPv6 mobile networks defined in [RFC3316]. In > particular, this document identifies also features to ensure IPv4 > service continuity over an IPv6-only transport. > > Both Hosts and devices with LAN capabilities are in scope. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device >-profile-01 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops >= From tjc@ecs.soton.ac.uk Wed Mar 27 04:19:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF40C21F8E84 for ; Wed, 27 Mar 2013 04:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] 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 Y2NoNgh8OZxu for ; Wed, 27 Mar 2013 04:19:56 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id F3EF521F88BD for ; Wed, 27 Mar 2013 04:19:55 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r2RBJq2d023248; Wed, 27 Mar 2013 11:19:52 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r2RBJq2d023248 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1364383192; bh=o7VjGZrCRSOOGDSyAgEvshyOo4c=; h=References:Mime-Version:In-Reply-To:Cc:From:Subject:Date:To; b=EzgNqtcn+hI8VbGDzzOyzRorbAvhrYF0XS6nTRJYBuCH1lOo02kKu1M0GHAAU4lHI JLNxRq087san+T1zSnT2Nel6uF3xI+FjBndXCPy4TQcO3tSYIEO8+qsTtvJWVrpRgW 3ubKNrG7EGC4dTY9wcpjDulpDLsP+pclkTIyl6VQ= 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 p2QBJq0430653272JQ ret-id none; Wed, 27 Mar 2013 11:19:52 +0000 Received: from [10.29.37.181] (dab-ell1-h-1-8.dab.02.net [82.132.238.244]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r2RBIX3h017618 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Mar 2013 11:18:34 GMT References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5152B0C9.8010906@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: X-Mailer: iPhone Mail (10B146) From: Tim Chown Date: Wed, 27 Mar 2013 11:18:31 +0000 To: Brian E Carpenter X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p2QBJq043065327200; tid=p2QBJq0430653272JQ; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r2RBJq2d023248 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 11:19:57 -0000 On 27 Mar 2013, at 08:41, Brian E Carpenter wr= ote: > On 27/03/2013 06:46, Lorenzo Colitti wrote: >> Alexandru, >>=20 >> v6ops does not create protocols. You should probably take this to 6man. >=20 > I think he's asking whether there is an operational need for this. >=20 > If there's an operational need, the actual protocol development will > be done elsewhere. It might be reasonable to develop a requirements > document here. >=20 > I'm not an operator, but it seems to me that any site planning to use > DHCPv6 to manage its IPv6 setup, including multiple prefixes, would > be looking for something in this space. >=20 > On 27/03/2013 06:16, Randy Bush wrote: >=20 >> it would make it easier for current enterprise operators to add ipv6 >> to their network. this has long been considered unacceptable by the >> ipv6 gods. >=20 > The gods must be crazy. All this has happened before. All this will happen again. Tim= From lorenzo@google.com Wed Mar 27 04:30:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A93521F910D for ; Wed, 27 Mar 2013 04:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.82 X-Spam-Level: X-Spam-Status: No, score=-101.82 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOEMr8mf11kZ for ; Wed, 27 Mar 2013 04:30:02 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id E47F021F85B2 for ; Wed, 27 Mar 2013 04:30:01 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id wd20so8136397obb.9 for ; Wed, 27 Mar 2013 04:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=QVUaA+VtPAWuOFvhaKgUMwjcx0/wPhMcH4wGzyL5sE8=; b=H/TNL1RCzzgOfejh/2UeKxswGJE/OqsTdeK/3y4RWg6KI9xKjnPJtMbPDnaRj+u2Q1 +n2v8kNOpz69kUhpOABeUKIxA99ikosDnkDhRyPC7qmGN6Wcczn+cNcy6+Ws0r6rMJ2z RinXiPPYZ/O8alKbw2cr99snmS21m58LDLKhI58JrQkwqo0IFlyioqBrtzbDcCWWKgwh gniM7he0st+5OwHb5PttpQsxySGh2SM9lR8xYnqo0QBaz3fYKaTwgSTUjKyhUj4cDp1H LUwlh3RL5D6n1UpStFFfXSjttSJ8UliakrA1gi8EgdW0+77BEWuFSD54TnPUPxsrxonx XXvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=QVUaA+VtPAWuOFvhaKgUMwjcx0/wPhMcH4wGzyL5sE8=; b=ThsmPcFRqGw8RLT4V0dLA4ryuyDNvU1ICYscvA/jfF+IBNgTqm4PRTTTSqUqx4d98J 6qYyzon38VBakaS+erOk2NupI0u8JWH6mcxWxyGK2Q7PeIJG9SFZ+AfQF1gxLgoDiQ46 g9yohAxMstXVOQp/tzC2FDURw3OQMaMgAtro+xpqcK5d6n9UoIkUxneZIqpU0cOPj2Ke gSI2SeH/jgvD7pOUCuhEeCpO19B+bLGBMyn9UYRENXCuvHv1TgAXYGliy5G2dv99ZLiA 74VLAW1B9YZfcZFm0CH7X6n1SbwTO1rDXhaGD3XLdkn53iAw1wJgpfcP1B0XZc7vuWTY xuUA== X-Received: by 10.60.25.35 with SMTP id z3mr14657687oef.98.1364383801491; Wed, 27 Mar 2013 04:30:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Wed, 27 Mar 2013 04:29:41 -0700 (PDT) In-Reply-To: References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> From: Lorenzo Colitti Date: Wed, 27 Mar 2013 20:29:41 +0900 Message-ID: To: Tim Chown Content-Type: multipart/alternative; boundary=e89a8f923cfed36f8104d8e65b8c X-Gm-Message-State: ALoCoQl7fzHC/PDYGKbVC1HjNIibwujgMz6jdGk/1DQn/hgXYO3qSyRjGPZdWuwEH5t1jmhxYLFwLTXIaFi6Cwip93YdQJv8Svwb0yIBe2FiL4iQYiamIfnJcEX4dCwqjpE7mBqlGuOyns4pz4n0esusIXi/V3aNnoID9hyZRBU+jRBLqX3/lJikR4UGHjOE31KESyxXIODh Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 11:30:02 -0000 --e89a8f923cfed36f8104d8e65b8c Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 27, 2013 at 8:18 PM, Tim Chown wrote: > >> it would make it easier for current enterprise operators to add ipv6 > >> to their network. this has long been considered unacceptable by the > >> ipv6 gods. > > > > The gods must be crazy. > > All this has happened before. All this will happen again. > Yes, but not forever. All we need to do is get to a point where there is enough IPv6 deployment for enterprise operators to decide that they are going to deploy IPv6 even though - oh, the sheer horror! - there is no way to configure routing in DHCPv6. Once they get past that and deploy using RAs, they will find out that it's really not a problem. Our company's enterprise operators know this already. We just need to give the others time to find out. --e89a8f923cfed36f8104d8e65b8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 27, 2013 at 8:18 PM, Tim Chown <tjc@ecs.sot= on.ac.uk> wrote:
>> it would make it = easier for current enterprise operators to add ipv6
>> to their network. =A0this has long been considered unacceptable by= the
>> ipv6 gods.
>
> The gods must be crazy.

All this has happened before. All this will happen again.

Yes, but not forever.

All we need to do is get to a point where there is enough = =A0IPv6 deployment for enterprise operators to decide that they are going t= o deploy IPv6 even though - oh, the sheer horror! - there is no way to conf= igure routing in DHCPv6.

Once they get past that and deploy using RA= s, they will find out that it's really not a problem. Our company's= enterprise operators know this already. We just need to give the others ti= me to find out.
--e89a8f923cfed36f8104d8e65b8c-- From victor@jvknet.com Wed Mar 27 05:06:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCD121F912D for ; Wed, 27 Mar 2013 05:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.983 X-Spam-Level: ** X-Spam-Status: No, score=2.983 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MANGLED_PREMTR=2.3, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.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 8X-cjqASgzSb for ; Wed, 27 Mar 2013 05:05:58 -0700 (PDT) Received: from mail-ia0-x231.google.com (mail-ia0-x231.google.com [IPv6:2607:f8b0:4001:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 79EC321F9105 for ; Wed, 27 Mar 2013 05:05:58 -0700 (PDT) Received: by mail-ia0-f177.google.com with SMTP id w33so4183686iag.22 for ; Wed, 27 Mar 2013 05:05:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :x-gm-message-state; bh=qPkXLrCrQ06dYKmHUVZy4Dx9kd1N0E1aeE/dxu847cQ=; b=dyi0KJ3me7T0XkUpuPlikcoxpt2kiDw5cZIevE9dcTqXjv6VOWNOZEdJIZzYdXdXU0 ajCjHk4VDM6AmXfh5E5Wym7s42ba5uwkNSScLwCHIju90geFtMp7ph12z2BEW6ZHTK37 zgpDDjCZfyEozun7BtGSiHR0dPAKEhQ500w4ZCS8v4NVEi/JGcEWRDjdaYzbvO8duufY aOoDf8FMDpcUrn1IC1YbthG1eMhsIw9vWF9fYbdJvcnGZGJskJbGWGmmqSSFMteJZQmF cUkOwjx0CFf7mzJ488rNl5MtR1QxL3hjzZP/B1ZZ3JD1bMx0X5ozb9iUlZmIszMjJ9+F bjzw== X-Received: by 10.50.6.3 with SMTP id w3mr3971214igw.76.1364385958049; Wed, 27 Mar 2013 05:05:58 -0700 (PDT) Received: from [192.168.100.70] ([67.224.83.162]) by mx.google.com with ESMTPS id dy5sm6928438igc.1.2013.03.27.05.05.55 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 27 Mar 2013 05:05:57 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 27 Mar 2013 08:05:48 -0400 From: Victor Kuarsingh To: "cb.list6" , Lorenzo Colitti Message-ID: Thread-Topic: [v6ops] ULA discussion #BCP or Informational In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3447216356_7525790" X-Gm-Message-State: ALoCoQnMVqpIxayRI7KvpCHgaRiohMYw4J+e2sd43brOzn/ytFU6zJFpOp2HeVK4PV6K08WxmzzZ Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 12:06:00 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3447216356_7525790 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On Mar 26, 2013 6:52 AM, "Lorenzo Colitti" wrote: > > Informational. > > The way I see it, the scenarios in this document are not current practice, because they are not currently deployed to any substantial degree. And if this document is not current practice, then it cannot be Best Current Practice. > >I have ULAs deployed at several places in my network consistent with the draft. >I too am fine with informational status, but these ideas have been applied. >Cameron I also think Informational is the correct status of this document. As noted before, although some of us have used ULAs for legitimate reasons which align with some parts of the draft, perhaps BCP is a bit pre-mature. I say this since there may be some of the scenarios which have not had much time in production. Victor K --B_3447216356_7525790 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable


On Mar 26, 2013 6:52 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
> Informational.
>
> The way I see it, the scenarios in this document are not current pract= ice, because they are not currently deployed to any substantial degree. And = if this document is not current practice, then it cannot be Best Current Pra= ctice.
>

>I have ULAs deployed at several places in my netwo= rk consistent with the draft.

>I too am fine with informa= tional status, but these ideas have been applied.

>Camer= on


I also think Informational is the correct s= tatus of this document.  As noted before, although some of us have used= ULAs for legitimate reasons which align with some parts of the draft, perha= ps BCP is a bit pre-mature.  I say this since there may be some of the = scenarios which have not had much time in production.

Victor K



--B_3447216356_7525790-- From arturo.servin@gmail.com Wed Mar 27 05:16:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3845321F9047 for ; Wed, 27 Mar 2013 05:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 W8hACAPT4xbn for ; Wed, 27 Mar 2013 05:16:32 -0700 (PDT) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id 76EDF21F9019 for ; Wed, 27 Mar 2013 05:16:32 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id cy12so1948315veb.18 for ; Wed, 27 Mar 2013 05:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=JqnL3zs4HWErJn65xfYOhQd9iqccxg0x3g4a+ikEf24=; b=O1QPPlLMKqrrOo6jQcwQ28xaQyqMYoTBQ1JNlwdHFxYs6QElwC14AczNur1ny9dO06 HimsvxjHT4igX7/pjFv6slkG8vIICsbblk0lF8tc1zOvewLcfZ+98WGUfVR5vRF+j9dk b4I5f1lfU2memSwjNwm/t19oFyLROkJavLXSJxbVjWGqPa3ukxOVeVoY1aBiQYWLG7YF CP6GuLT5dHCanjmTfPenCENcJerC/8x/YDQDzf5uWacDhbyQmVRMJrD5PjUewL/1XFug o6n33ws1nE1doCqNhDb2XUoL3Q5UmaixkbTOKgYNkiPR+zy5YcZpy8HrHeCgJkAbXdUc iNXQ== X-Received: by 10.220.153.69 with SMTP id j5mr22642870vcw.35.1364386591931; Wed, 27 Mar 2013 05:16:31 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy ([200.7.85.146]) by mx.google.com with ESMTPS id b7sm29077628veq.7.2013.03.27.05.16.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Mar 2013 05:16:30 -0700 (PDT) Message-ID: <5152E31B.6070001@gmail.com> Date: Wed, 27 Mar 2013 09:16:27 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 12:16:33 -0000 Informational. Regards as On 3/26/13 8:56 AM, Liubing (Leo) wrote: > Hi, Dear all > > [Note: You can also raise some topic you consider as important with the prefix "ULA discussion #", so that the future discussion could be easily tracked. Thank you.] > > This post is regarding the document should be a "BCP" or "Informational". > Personally, either BCP or Informational is OK for me. But I'd like to discuss it in the perspective of the document. > > I checked RFC2026 (The Internet Standards Process -- Revision 3), in section 5, the BCP document is described as "a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function." > > So, I believe it is a good goal to publish the ULA draft as a BCP, I think the position is valuable for the readers. However, some texts (especially NAT relative) are still controversy that might not be consensus of representing "the community's best current thinking". But let's try to find the common view/principle out of the controversy materials, if not applicable, then it is OK to be Informational. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From mackermann@bcbsm.com Wed Mar 27 07:05:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC5D21F8B61 for ; Wed, 27 Mar 2013 07:05:39 -0700 (PDT) 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_13=0.6] 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 J2gVDq45R-Vu for ; Wed, 27 Mar 2013 07:05:38 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id B09C421F85F5 for ; Wed, 27 Mar 2013 07:05:37 -0700 (PDT) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 6F5D42FF72F for ; Wed, 27 Mar 2013 09:05:36 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 0CC163074C7; Wed, 27 Mar 2013 09:05:36 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 589BC4F8051; Wed, 27 Mar 2013 10:04:01 -0400 (EDT) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) by imsva1.bcbsm.com (Postfix) with ESMTP id 4AE564F8049; Wed, 27 Mar 2013 10:04:01 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([fe80::716f:e3f0:b97f:8900%14]) with mapi id 14.01.0438.000; Wed, 27 Mar 2013 10:05:35 -0400 From: "Ackermann, Michael" To: Brian E Carpenter , "v6ops@ietf.org" Thread-Topic: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? Thread-Index: AQHOKjyV245aKa0zuUe8lncJ9YSY+Ji5XDOAgAAgNYCAABadoA== Date: Wed, 27 Mar 2013 14:05:34 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A671F49@PWN401EA160.ent.corp.bcbsm.com> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> In-Reply-To: <5152B0C9.8010906@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 14:05:39 -0000 Good point regarding sites planning to use DHCPv6 may need things like = this. It would be beneficial to all to get ahead of the curve and = consider providing such controls BEFORE Enterprises and Operators try to = deploy and then discover issues that slow the deployment. =20 -----Original Message----- From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Brian E Carpenter Sent: Wednesday, March 27, 2013 4:42 AM To: v6ops=40ietf.org Subject: Re: =5Bv6ops=5D Interest in DHCPv6 Route/DefRouter/Src-basedRoute = configuration to Client? On 27/03/2013 06:46, Lorenzo Colitti wrote: > Alexandru, >=20 > v6ops does not create protocols. You should probably take this to 6man. I think he's asking whether there is an operational need for this. If there's an operational need, the actual protocol development will be = done elsewhere. It might be reasonable to develop a requirements document = here. I'm not an operator, but it seems to me that any site planning to use DHCPv6 to manage its IPv6 setup, including multiple prefixes, would be = looking for something in this space. On 27/03/2013 06:16, Randy Bush wrote: > it would make it easier for current enterprise operators to add ipv6=20 > to their network. this has long been considered unacceptable by the > ipv6 gods. The gods must be crazy. Brian _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From iljitsch@muada.com Wed Mar 27 08:26:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4926321F9199 for ; Wed, 27 Mar 2013 08:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+sxlsNpwGXp for ; Wed, 27 Mar 2013 08:26:03 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 888CB21F8C74 for ; Wed, 27 Mar 2013 08:26:03 -0700 (PDT) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2RFKssI027751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Mar 2013 16:20:55 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <4FC37E442D05A748896589E468752CAA0A671F49@PWN401EA160.ent.corp.bcbsm.com> Date: Wed, 27 Mar 2013 16:25:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <4FC37E442D05A748896589E468752CAA0A671F49@PWN401EA160.ent.corp.bcbsm.com> To: "Ackermann, Michael" X-Mailer: Apple Mail (2.1499) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 15:26:04 -0000 On 27 mrt 2013, at 15:05, "Ackermann, Michael" = wrote: > Good point regarding sites planning to use DHCPv6 may need things like = this. It would be beneficial to all to get ahead of the curve and = consider providing such controls BEFORE Enterprises and Operators try to = deploy and then discover issues that slow the deployment. =20 There were similar sentiments around IPv6 PI. Now with PI in place the = IPv6 routing table is certainly a lot larger than before, but there was = not an immediate uptick in IPv6 deployment. If the IETF standardizes a new, highly sought after DHCPv6 option, then = that still doesn't buy anyone anything, because it needs to be = implemented in a whole bunch of operating systems first. That takes many = years.= From alexandru.petrescu@gmail.com Wed Mar 27 08:37:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA0821F9188 for ; Wed, 27 Mar 2013 08:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.509 X-Spam-Level: X-Spam-Status: No, score=-9.509 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52CEJaylKH-r for ; Wed, 27 Mar 2013 08:37:43 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 784BE21F917E for ; Wed, 27 Mar 2013 08:37:43 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2RFbgnP010275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 27 Mar 2013 16:37:42 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2RFbgqL013136 for ; Wed, 27 Mar 2013 16:37:42 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2RFbUVw005783 for ; Wed, 27 Mar 2013 16:37:41 +0100 Message-ID: <51531203.1020609@gmail.com> Date: Wed, 27 Mar 2013 16:36:35 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <4FC37E442D05A748896589E468752CAA0A671F49@PWN401EA160.ent.corp.bcbsm.com> <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> In-Reply-To: <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 15:37:44 -0000 Le 27/03/2013 16:25, Iljitsch van Beijnum a écrit : > On 27 mrt 2013, at 15:05, "Ackermann, Michael" > wrote: > >> Good point regarding sites planning to use DHCPv6 may need things >> like this. It would be beneficial to all to get ahead of the >> curve and consider providing such controls BEFORE Enterprises and >> Operators try to deploy and then discover issues that slow the >> deployment. > > There were similar sentiments around IPv6 PI. Now with PI in place > the IPv6 routing table is certainly a lot larger than before, but > there was not an immediate uptick in IPv6 deployment. > > If the IETF standardizes a new, highly sought after DHCPv6 option, > then that still doesn't buy anyone anything, because it needs to be > implemented in a whole bunch of operating systems first. That takes > many years. Iljitsch, Is this worry about Route, DefRouters, src-basedRoute? I believe the worry may be different in each case. E.g. whereas DefRouter could be configured equally well by DHCP as much as by RA, the src-basedRoute option does not exist in RA either. I am trying to understand. Alex _______________________________________________ v6ops > mailing list v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From owen@delong.com Wed Mar 27 08:41:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CFA21F91E6 for ; Wed, 27 Mar 2013 08:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xj3QaEHjE1lL for ; Wed, 27 Mar 2013 08:41:50 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id CEC1721F91D4 for ; Wed, 27 Mar 2013 08:41:50 -0700 (PDT) Received: from [10.255.252.140] ([207.102.63.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2RFbNpJ014384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 08:37:25 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2RFbNpJ014384 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364398646; bh=fUrgTnqyC9xH8N3sPbE8rJJm8tk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=BXOgnv4nKnOSKJUYIAEPafa7l280Fr5rli5/kF04a3sRK1Kdm0dsJGx5nsV0oCLmV d6eHnNyOl62UJWF19LCr9Pt8007kBdIzp5P++G6cMAFG8HBBy5S2tvZ1uAAAk4vP6p txSm/BPNEuPiFE8Cf8wy9tLWEef2zOjm2eeqVyw8= Content-Type: multipart/alternative; boundary="Apple-Mail=_3711A80A-0E95-4F1B-9580-602C51A353E1" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: Date: Wed, 27 Mar 2013 08:37:24 -0700 Message-Id: References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 27 Mar 2013 08:37:26 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 15:41:51 -0000 --Apple-Mail=_3711A80A-0E95-4F1B-9580-602C51A353E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Mar 27, 2013, at 4:29 AM, Lorenzo Colitti wrote: > On Wed, Mar 27, 2013 at 8:18 PM, Tim Chown = wrote: > >> it would make it easier for current enterprise operators to add = ipv6 > >> to their network. this has long been considered unacceptable by = the > >> ipv6 gods. > > > > The gods must be crazy. >=20 > All this has happened before. All this will happen again. >=20 > Yes, but not forever. >=20 > All we need to do is get to a point where there is enough IPv6 = deployment for enterprise operators to decide that they are going to = deploy IPv6 even though - oh, the sheer horror! - there is no way to = configure routing in DHCPv6. >=20 What is more likely is that DHCP server authors will develop this = functionality to meet demand and it will eventually be documented as = running code in an RFC. > Once they get past that and deploy using RAs, they will find out that = it's really not a problem. Our company's enterprise operators know this = already. We just need to give the others time to find out. There are a multitude of reasons that having an ability to place routing = information into DHCPv6 would be useful to some operators. There are = risks associated with doing so. Operators are, IMHO, capable of = evaluating the tradeoffs and choosing the solution that best meets their = needs. Note that for maximum functionality, it should _NOT_ be limited to a = default router. It should be a routing information option which can be used to configure = zero or more routes on the client. Frankly, this would provide the ability to address some of the problems = presented by ULA. Owen --Apple-Mail=_3711A80A-0E95-4F1B-9580-602C51A353E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 lorenzo@google.com> = wrote:

On Wed, Mar 27, 2013 at 8:18 PM, Tim = Chown <tjc@ecs.soton.ac.uk> wrote:
>> it would make it easier for current enterprise = operators to add ipv6
>> to their network.  this has long been considered = unacceptable by the
>> ipv6 gods.
>
> The gods must be crazy.

All this has happened before. All this will happen = again.

Yes, but not = forever.

All we need to = do is get to a point where there is enough  IPv6 deployment for = enterprise operators to decide that they are going to deploy IPv6 even = though - oh, the sheer horror! - there is no way to configure routing in = DHCPv6.


What = is more likely is that DHCP server authors will develop this = functionality to meet demand and it will eventually be documented as = running code in an RFC.


Once they get past that and deploy = using RAs, they will find out that it's really not a problem. Our = company's enterprise operators know this already. We just need to give = the others time to find = out.

There are a = multitude of reasons that having an ability to place routing information = into DHCPv6 would be useful to some operators. There are risks = associated with doing so. Operators are, IMHO, capable of evaluating the = tradeoffs and choosing the solution that best meets their = needs.

Note that for maximum functionality, it = should _NOT_ be limited to a default router.

It = should be a routing information option which can be used to configure = zero or more routes on the client.

Frankly, = this would provide the ability to address some of the problems presented = by ULA.

Owen

= --Apple-Mail=_3711A80A-0E95-4F1B-9580-602C51A353E1-- From alexandru.petrescu@gmail.com Wed Mar 27 08:49:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E1A21F91DD for ; Wed, 27 Mar 2013 08:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.532 X-Spam-Level: X-Spam-Status: No, score=-9.532 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OYUK89brWmg for ; Wed, 27 Mar 2013 08:49:41 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id A3BD521F9159 for ; Wed, 27 Mar 2013 08:49:40 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2RFna8V011717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 27 Mar 2013 16:49:36 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2RFna7J017628 for ; Wed, 27 Mar 2013 16:49:36 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2RFnVrm024813 for ; Wed, 27 Mar 2013 16:49:35 +0100 Message-ID: <515314D4.8090609@gmail.com> Date: Wed, 27 Mar 2013 16:48:36 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 15:49:41 -0000 Le 27/03/2013 12:29, Lorenzo Colitti a écrit : > On Wed, Mar 27, 2013 at 8:18 PM, Tim Chown > wrote: > >>> it would make it easier for current enterprise operators to add >>> ipv6 to their network. this has long been considered >>> unacceptable by the ipv6 gods. >> >> The gods must be crazy. > > All this has happened before. All this will happen again. > > > Yes, but not forever. > > All we need to do is get to a point where there is enough IPv6 > deployment for enterprise operators to decide that they are going to > deploy IPv6 even though - oh, the sheer horror! - there is no way to > configure routing in DHCPv6. (there is no way to configure routing in DHCPv4 either). But that is a good point. I think migrating a network from IPv4 to IPv6 involves making IPv6 look as much as possible as IPv4. > Once they get past that and deploy using RAs, they will find out > that it's really not a problem. Our company's enterprise operators > know this already. We just need to give the others time to find out. Ok, deploying RAs needs an effort of understanding RA. And some people already figured it out, somehow. But, how do your company's enterprise operators maintain the supposedly numerous radvd.conf files on the routers? Do they think there may be a problem in that? (like e.g. when some PC software misinterprets the M/O flags, or when the frequency must be increased because of a growing number of PCs). Alex > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From alexandru.petrescu@gmail.com Wed Mar 27 08:52:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF2A21F91FE for ; Wed, 27 Mar 2013 08:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.549 X-Spam-Level: X-Spam-Status: No, score=-9.549 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCjG25fJzlx2 for ; Wed, 27 Mar 2013 08:52:24 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6FA21F91E0 for ; Wed, 27 Mar 2013 08:52:24 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2RFqNsM015961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 27 Mar 2013 16:52:23 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2RFqNgu018535 for ; Wed, 27 Mar 2013 16:52:23 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2RFqLeo026351 for ; Wed, 27 Mar 2013 16:52:22 +0100 Message-ID: <5153157E.3040309@gmail.com> Date: Wed, 27 Mar 2013 16:51:26 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 15:52:25 -0000 Le 27/03/2013 12:18, Tim Chown a écrit : > On 27 Mar 2013, at 08:41, Brian E Carpenter > wrote: > >> On 27/03/2013 06:46, Lorenzo Colitti wrote: >>> Alexandru, >>> >>> v6ops does not create protocols. You should probably take this to >>> 6man. >> >> I think he's asking whether there is an operational need for this. >> >> If there's an operational need, the actual protocol development >> will be done elsewhere. It might be reasonable to develop a >> requirements document here. >> >> I'm not an operator, but it seems to me that any site planning to >> use DHCPv6 to manage its IPv6 setup, including multiple prefixes, >> would be looking for something in this space. >> >> On 27/03/2013 06:16, Randy Bush wrote: >> >>> it would make it easier for current enterprise operators to add >>> ipv6 to their network. this has long been considered >>> unacceptable by the ipv6 gods. >> >> The gods must be crazy. > > All this has happened before. All this will happen again. Not sure what 'all' refers to, but there is some novelty now vs before. There is an SDO who seem to require something around this space, otherwise they do it their own way. This is new now. Additionaly: we talk src-basedRoute in addition to Route and DefRouters. How do you see what has happened before with respect to SDO? And with respect to src-basedRoute? Alex > > Tim _______________________________________________ v6ops mailing > list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From alexandru.petrescu@gmail.com Wed Mar 27 09:11:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CACC721F9041 for ; Wed, 27 Mar 2013 09:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.562 X-Spam-Level: X-Spam-Status: No, score=-9.562 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqnxDl+PCGbQ for ; Wed, 27 Mar 2013 09:11:19 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 29BFB21F8EAE for ; Wed, 27 Mar 2013 09:11:17 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2RGBG5o014189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 27 Mar 2013 17:11:16 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2RGBGiE024988 for ; Wed, 27 Mar 2013 17:11:16 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2RGB7G2023799 for ; Wed, 27 Mar 2013 17:11:16 +0100 Message-ID: <515319E4.60707@gmail.com> Date: Wed, 27 Mar 2013 17:10:12 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <5152AA3D.80606@dougbarton.us> <5152BB63.5060801@globis.net> <25D0CBBD-9A56-475C-AC27-D1A10D38E331@muada.com> In-Reply-To: <25D0CBBD-9A56-475C-AC27-D1A10D38E331@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 16:11:19 -0000 Le 27/03/2013 10:34, Iljitsch van Beijnum a écrit : > On 27 mrt 2013, at 10:26, Ray Hunter wrote: > >> If DHCPv6 was used to populate a default router list, how would >> there be a problem with fate sharing? (assuming more than one >> router in the default router list, more than one router acting as a >> DHCPv6 relay, and end nodes performing NUD) > > The DHCPv6 server may supply an incorrect router address, for one of > two reasons: > > - misconfiguration - the router holding that address is down > > This problem doesn't occur with RAs because the router address in an > RA is automatically set so it can't be misconfigured, and if a > router is down it won't be sending RAs. For DefRouter -- Yes - one makes an RA to be that of a defaultrouter by setting the Lifetime to non-zero value. That's all; indeed it doesnt put an address inside, but one has to set that value of lifetime. Yes - if the router is down then no RA. But, Sure the problem can happen with RAs - I did myself in error. I have two Access Routers with two different egress links, yet a single Ethernet link on which a Client PC connects to. The PC receives two different RAs, each telling it it is the default router. My error was that I set one day one radvd.conf and another day the other radvd.conf. In the meantime I forgot which is the right DefaultRouter. So there I sit with a PC switching back and forth between the ARs, at a high frequency. That's a problem - misconfiguration, misunderstanding of where that default route should come from, etc. The problem happens as much with RAs as with any other protocol. For src-basedRoute -- the argumentation doesnt hold because RA doesnt advertise src-basedRoute. If RA did that, then the RA had to contain an src-basedRoute which should be present in the RA - hence misconfiguration risks. For Routes -- RA with RFC4191 specific routes doesnt really exist, so this misconfiguration problem doesnt really exist either. If it existed, the misconfiguration problem existed as well. > Please note that we've had this discussion for many years now, it > would be more fruitful to explore alternate ways to get the desired > behavior than expecting the same arguments to be more persuasive this > time around. Well, we need a place to discuss this. I currently try here. There are new arguments now, like that SDO. Alternate ways - I am open to suggestions of alternate ways for DHCPv6 DefRouters to small PC Mobile Router for fast configuration. Listening. IMHO, for these alternate ways - in my particular case of DefRouters DHCPv6, using small PC Mobile Router which needs to use a single and fast protocol to configure as many parameters as possible, one alternative is the use of Neighbor Discovery Prefix Delegation. That alternative has much less tract. There is a single individual draft now, and another one in 2007. There is no SDO asking for this ND-PD, no expired WG item, a few and negative comments of being architecturally problematic. Alex > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From alexandru.petrescu@gmail.com Wed Mar 27 09:19:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493F321F906A for ; Wed, 27 Mar 2013 09:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.871 X-Spam-Level: X-Spam-Status: No, score=-9.871 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbzIGcSA1c3r for ; Wed, 27 Mar 2013 09:19:46 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6633321F8BE2 for ; Wed, 27 Mar 2013 09:19:46 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2RGJjX8002564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Mar 2013 17:19:45 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2RGJjOK027818; Wed, 27 Mar 2013 17:19:45 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2RGJeMH008394; Wed, 27 Mar 2013 17:19:45 +0100 Message-ID: <51531BE5.2070809@gmail.com> Date: Wed, 27 Mar 2013 17:18:45 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Mark Smith References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> In-Reply-To: <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 16:19:47 -0000 Le 27/03/2013 10:05, Mark Smith a écrit : >> ________________________________ >> From: Iljitsch van Beijnum >> To: Alexandru Petrescu >> Cc: "v6ops@ietf.org" >> Sent: Wednesday, 27 March 2013 6:54 PM >> Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? >> >> On 26 mrt 2013, at 17:09, Alexandru Petrescu wrote: >> >>> Is there an interest in DHCPv6 Route/DefRouter/Src-basedRoute >>> configuration to Client? >> >> The big issue with having DHCPv6 deliver a default route is that it >> breaks the fate sharing that having the default router address in a >> router advertisement from the router holding that address >> provides. >> >> But I gather there are people who want to be able to make one group >> of hosts on a subnet use router A as their default router but >> another group of hosts router B, on that same subnet. >> > > This should already possible using RAs, with an example > implementation being the clients section in radvd/radvd.conf. Thank you for the example below. That helps to have two Access Routers to configure clients differently on the same link, differentiating by clients' link-local unicast addresses. This could work ok! Although I doubt one could maintain such list of link-local addresses in multiple distributed radvd.conf files without some automation. I may ask you whether such a method exists for src-basedRoute and Route as well? I.e. is it possible to use RA to configure different Client PCs on the link with different src-basedRoutes, and different Routes? But, for the case of DefRouters - this would fit fine some needs of small PC Mobile Router needing fast auto-configuration if RA did also Prefix Delegation. Currently RA doesnt do such. Alex > Here is > the manual page help text: > > By default radvd will send route advertisements so that every node on > the link can use them. The list of clients (IPv6 address) to advertise > to, and accept route solicitations from can be configured. If done, > radvd does not send send messages to the multicast addresses but to the > configured unicast addresses only. Solicitations from other addresses > are refused. This is similar to UnicastOnly but includes periodic mes†> sages and incoming client access configuration. See examples section > for a use case of this. > > The definitions are of the form: > > clients { > list of IPv6 addresses > }; > > > Further into the manual page is an example configuration: > > interface eth0 > { > AdvSendAdvert on; > prefix 2001:db8:0:1::/64 > { > AdvOnLink on; > AdvAutonomous on; > }; > clients > { > fe80::21f:16ff:fe06:3aab; > fe80::21d:72ff:fe96:aaff; > }; > }; > > This configuration would only announce the prefix to > fe80::21f:16ff:fe06:3aab and fe80::21d:72ff:fe96:aaff. Furthermore, > all RA requests of other clients are denied. > > This may come in handy if you want to roll out IPv6 only partially > because some clients are broken or untested. > > > > Regards, > > Mark. > > From owen@delong.com Wed Mar 27 09:21:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CA021F9168 for ; Wed, 27 Mar 2013 09:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PKudHKP6D9Q for ; Wed, 27 Mar 2013 09:21:01 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D9DBA21F9161 for ; Wed, 27 Mar 2013 09:21:00 -0700 (PDT) Received: from [10.255.252.140] ([207.102.63.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2RGGunC015860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 09:16:57 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2RGGunC015860 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364401018; bh=jDvrg0M/oZbOwRjEFWyzLdebKEc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=veUu+TjbwHSiwJzwARk45gBWdxHLNsRVlsIUcJecZhlLCk+N8QMApOTN78iGE2K3K 0B7VkAetodnBvqyEjr4T0xJiFrysb34oAW4tQrpQ79mVPZOrBqQYTUKUMGZtdhO1yK 50gn865n+CqQCeOgWITsIfbeEoM2PQ/c2ev6TXEM= Content-Type: multipart/alternative; boundary="Apple-Mail=_B44956EA-4760-4E88-8D12-E27AEE91E6EE" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: <515314D4.8090609@gmail.com> Date: Wed, 27 Mar 2013 09:16:57 -0700 Message-Id: <5E0D1481-6BA6-495B-9F6A-2418153EC02C@delong.com> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <515314D4.8090609@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 27 Mar 2013 09:16:58 -0700 (PDT) Cc: v6ops@ietf.org Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 16:21:02 -0000 --Apple-Mail=_B44956EA-4760-4E88-8D12-E27AEE91E6EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Mar 27, 2013, at 8:48 AM, Alexandru Petrescu = wrote: > Le 27/03/2013 12:29, Lorenzo Colitti a =E9crit : >> On Wed, Mar 27, 2013 at 8:18 PM, Tim Chown > > wrote: >>=20 >>>> it would make it easier for current enterprise operators to add >>>> ipv6 to their network. this has long been considered >>>> unacceptable by the ipv6 gods. >>>=20 >>> The gods must be crazy. >>=20 >> All this has happened before. All this will happen again. >>=20 >>=20 >> Yes, but not forever. >>=20 >> All we need to do is get to a point where there is enough IPv6 >> deployment for enterprise operators to decide that they are going to >> deploy IPv6 even though - oh, the sheer horror! - there is no way to >> configure routing in DHCPv6. >=20 > (there is no way to configure routing in DHCPv4 either). >=20 > But that is a good point. >=20 > I think migrating a network from IPv4 to IPv6 involves making IPv6 = look > as much as possible as IPv4. >=20 There are some ways in which this can be beneficial. There are a number of ways in which this would be a very bad idea. For example, adding NAT to IPv6 to make it look like IPv4 would be very detrimental. It will, unfortunately probably happen to some extent = (sadly, it already has). However, there is still tremendous benefit to be had = from limiting that extent. I believe that providing routing information in DHCPv6 would offer = benefits beyond what a default router would. It should come with some level of warning-label, however, because as has been pointed out, it can lead to tradeoffs. It would not look like DHCPv4, but it would provide more functionality and wouldn't look all that different. Default is just one = case of routing information that would then be possible. e.g. =85 routing-option { 2001:db8:1234::/48, 2001:db8:1234:fe96::1, 1002 = }; routing-option { ::/0, 2001:db8:1234:fe96::ea99, 512 }; =85 This would provide two routes. The first, a /48 more specific to the = local prefix via a router at 2001:db8:1234:fe96::1 and the other a default via a different router at =85::ea99. The first route has a metric of 1002. The second a metric of 512. >> Once they get past that and deploy using RAs, they will find out >> that it's really not a problem. Our company's enterprise operators >> know this already. We just need to give the others time to find out. >=20 > Ok, deploying RAs needs an effort of understanding RA. And some = people > already figured it out, somehow. >=20 Deploying RAs is pretty straight forward and you have to do that anyway just to bootstrap DHCP in most cases. > But, how do your company's enterprise operators maintain the = supposedly > numerous radvd.conf files on the routers? Do they think there may be = a > problem in that? (like e.g. when some PC software misinterprets the = M/O > flags, or when the frequency must be increased because of a growing > number of PCs). >=20 ? There's only one radvd.conf file on any given router and that's only = if the router is running linux. Configuring routers is necessary no matter = what. Maintaining the RA configuration as part of the router configuration is = nothing unusual. Normal routers configure RAs just like any other part of configuring a = router: fe-0/0/0 { unit 0 { description LAN; family inet { mtu 1500; filter { output deny-bad-actors; } address 192.159.10.251/24 { vrrp-group 1 { virtual-address 192.159.10.254; priority 250; advertise-interval 5; preempt; accept-data; } } inactive: address 192.124.40.1/30; } family inet6 { mtu 1500; address 2620:0:930::dead:beef/64; address 2620:0:930::/64 { eui-64; primary; } address 2001:470:1f00:3142::dead:beef/64; address 2620:0:930::200:30/64; } } } The above interface configuration is running code from a Juniper SRX-100 providing RAs for SLAAC on the interface in question. In this case, use of the "eui-64" configuration parameter is sufficient to trigger RAs. One can add additional RA configuration options within that address clause if necessary to control the content and other aspects of the RAs more specifically, if needed. It is usually not needed. The primary keyword causes the router to use this address to initiate sessions. It is unrelated to RAs. Owen --Apple-Mail=_B44956EA-4760-4E88-8D12-E27AEE91E6EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 alexandru.petrescu@gmail.com<= /a>> wrote:

Le 27/03/2013 12:29, Lorenzo Colitti a =E9crit = :
On Wed, Mar 27, 2013 at 8:18 PM, Tim = Chown <tjc@ecs.soton.ac.uk
<mailto:tjc@ecs.soton.ac.uk>>= wrote:

it = would make it easier for current enterprise operators to add
ipv6 to = their network.  this has long been considered
unacceptable by = the ipv6 gods.

The gods must be = crazy.

All this has happened before. All this will = happen again.


Yes, but not forever.

All we need to do = is get to a point where there is enough  IPv6
deployment for = enterprise operators to decide that they are going to
deploy IPv6 = even though - oh, the sheer horror! - there is no way to
configure = routing in DHCPv6.

(there is no way to configure = routing in DHCPv4 either).

But that is a good point.

I = think migrating a network from IPv4 to IPv6 involves making IPv6 = look
as much as possible as = IPv4.


There are some ways in which = this can be beneficial. There are a number
of ways in which = this would be a very bad idea.

For example, = adding NAT to IPv6 to make it look like IPv4 would be = very
detrimental. It will, unfortunately probably happen to = some extent (sadly,
it already has). However, there is still = tremendous benefit to be had from
limiting that = extent.

I believe that providing routing = information in DHCPv6 would offer benefits
beyond what a = default router would. It should come with some level = of
warning-label, however, because as has been pointed out, it = can lead
to tradeoffs. It would not look like DHCPv4, but it = would provide more
functionality and wouldn't look all that = different. Default is just one case
of routing information = that would then be = possible.

e.g.

=85
=
= routing-option { 2001:db8:1234::/48, 2001:db8:1234:fe96::1, 1002 = };
= routing-option { ::/0, 2001:db8:1234:fe96::ea99, 512 = };
=85

This would provide two routes. = The first, a /48 more specific to the local
prefix via a = router at 2001:db8:1234:fe96::1 and the other a default = via
a different router at = =85::ea99.

The first route has a metric of = 1002. The second a metric of = 512.


Once they get past that and = deploy using RAs, they will find out
that it's really not a problem. = Our company's enterprise operators
know this already. We just need to = give the others time to find out.

Ok, deploying RAs = needs an effort of understanding RA.  And some people
already = figured it out, somehow.


Deploying = RAs is pretty straight forward and you have to do that = anyway
just to bootstrap DHCP in most = cases.

But, how do your = company's enterprise operators maintain the supposedly
numerous = radvd.conf files on the routers?  Do they think there may be = a
problem in that?  (like e.g. when some PC software = misinterprets the M/O
flags, or when the frequency must be increased = because of a growing
number of = PCs).


? There's only one radvd.conf = file on any given router and that's only if the
router is = running linux. Configuring routers is necessary no matter = what.
Maintaining the RA configuration as part of the router = configuration is = nothing
unusual.

Normal routers = configure RAs just like any other part of configuring a = router:

fe-0/0/0 = {
    unit 0 = {
        = description LAN;
    =     family inet {
 =           mtu 1500;
            filter = {
        =         output = deny-bad-actors;
    =         }
            address = 192.159.10.251/24 {
  =               vrrp-group 1 = {
        =             virtual-address = 192.159.10.254;
    =                 priority = 250;
        =             advertise-interval = 5;
        =             = preempt;
      =               = accept-data;
    =             }
            = }
        =     inactive: address 192.124.40.1/30;
        }
        family inet6 = {
        =     mtu 1500;
  =           address = 2620:0:930::dead:beef/64;
  =           address 2620:0:930::/64 = {
        =         eui-64;
                = primary;
      =       }
  =           address = 2001:470:1f00:3142::dead:beef/64;
            address = 2620:0:930::200:30/64;
        }
    }
}


The =  above interface configuration is running code from a = Juniper
SRX-100 providing RAs for SLAAC on the interface in = question.

In this case, use of the "eui-64" = configuration parameter is sufficient
to trigger RAs. One can = add additional RA configuration options
within that address = clause if necessary to control the content and
other aspects = of the RAs more specifically, if needed. It is = usually
not needed.

The primary = keyword causes the router to use this address to
initiate = sessions. It is unrelated to = RAs.

Owen


= --Apple-Mail=_B44956EA-4760-4E88-8D12-E27AEE91E6EE-- From randy@psg.com Wed Mar 27 09:25:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1563321F90ED for ; Wed, 27 Mar 2013 09:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 qUJm9QAkuJD4 for ; Wed, 27 Mar 2013 09:25:13 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 0590D21F90B3 for ; Wed, 27 Mar 2013 09:25:13 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UKt9y-0005fM-Hk; Wed, 27 Mar 2013 16:25:10 +0000 Date: Thu, 28 Mar 2013 01:25:09 +0900 Message-ID: From: Randy Bush To: Lorenzo Colitti In-Reply-To: References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 16:25:14 -0000 > All we need to do is get to a point where there is enough IPv6 deployment > for enterprise operators to decide that they are going to deploy IPv6 even > though - oh, the sheer horror! - there is no way to configure routing in > DHCPv6. you have not figured it out, have you? my way or the highway has led to the nat4444 highway. hope you like living in hell. i don't and i don't thank you for it. randy From joelja@bogus.com Wed Mar 27 09:36:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E412021F91C8 for ; Wed, 27 Mar 2013 09:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.756 X-Spam-Level: X-Spam-Status: No, score=-101.756 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, SARE_MILLIONSOF=0.315, 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 jQfsq4XhUQ4f for ; Wed, 27 Mar 2013 09:36:31 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 73FC421F91E8 for ; Wed, 27 Mar 2013 09:36:31 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r2RGaUHW076413 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 27 Mar 2013 16:36:30 GMT (envelope-from joelja@bogus.com) Message-ID: <51532008.3030305@bogus.com> Date: Wed, 27 Mar 2013 09:36:24 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Thunderbird/20.0 MIME-Version: 1.0 To: Doug Barton , v6ops@ietf.org References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <5152AA3D.80606@dougbarton.us> In-Reply-To: <5152AA3D.80606@dougbarton.us> 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, 27 Mar 2013 16:36:30 +0000 (UTC) Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 16:36:32 -0000 On 3/27/13 1:13 AM, Doug Barton wrote: > On 3/27/2013 12:54 AM, Iljitsch van Beijnum wrote: >> The big issue with having DHCPv6 deliver a default route is that it >> breaks the fate sharing that having the default router address in a >> router advertisement from the router holding that address provides. > > And yet that's not a problem for the hundreds of millions of hosts in > the world configured with DHCPv4. > Which continue to dhcpv4 forever in the absence of a dhcp server just like they did in 1995. I'll be coupled to the fact that IPV4 doesn't care if there's a router or not long after I have nominally v6only subnets because ipv4 doesn't have this relationship. > Doug > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From alexandru.petrescu@gmail.com Wed Mar 27 09:48:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5567821F8F17 for ; Wed, 27 Mar 2013 09:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.909 X-Spam-Level: X-Spam-Status: No, score=-9.909 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6PCkNxO2QKp for ; Wed, 27 Mar 2013 09:48:33 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 126EC21F8ECD for ; Wed, 27 Mar 2013 09:48:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2RGmHuO023243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Mar 2013 17:48:17 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2RGmGk3003936; Wed, 27 Mar 2013 17:48:17 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2RGm6mK021896; Wed, 27 Mar 2013 17:48:16 +0100 Message-ID: <5153228F.2070905@gmail.com> Date: Wed, 27 Mar 2013 17:47:11 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Owen DeLong References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <515314D4.8090609@gmail.com> <5E0D1481-6BA6-495B-9F6A-2418153EC02C@delong.com> In-Reply-To: <5E0D1481-6BA6-495B-9F6A-2418153EC02C@delong.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 16:48:34 -0000 Le 27/03/2013 17:16, Owen DeLong a écrit : > > On Mar 27, 2013, at 8:48 AM, Alexandru Petrescu > > wrote: > >> Le 27/03/2013 12:29, Lorenzo Colitti a écrit : >>> On Wed, Mar 27, 2013 at 8:18 PM, Tim Chown >> >>> > wrote: >>> >>>>> it would make it easier for current enterprise operators to add >>>>> ipv6 to their network. this has long been considered >>>>> unacceptable by the ipv6 gods. >>>> >>>> The gods must be crazy. >>> >>> All this has happened before. All this will happen again. >>> >>> >>> Yes, but not forever. >>> >>> All we need to do is get to a point where there is enough IPv6 >>> deployment for enterprise operators to decide that they are going to >>> deploy IPv6 even though - oh, the sheer horror! - there is no way to >>> configure routing in DHCPv6. >> >> (there is no way to configure routing in DHCPv4 either). >> >> But that is a good point. >> >> I think migrating a network from IPv4 to IPv6 involves making IPv6 look >> as much as possible as IPv4. >> > > There are some ways in which this can be beneficial. There are a number > of ways in which this would be a very bad idea. Right, I agree. > For example, adding NAT to IPv6 to make it look like IPv4 would be very > detrimental. It will, unfortunately probably happen to some extent (sadly, > it already has). However, there is still tremendous benefit to be had from > limiting that extent. Right. > I believe that providing routing information in DHCPv6 would offer benefits > beyond what a default router would. It should come with some level of > warning-label, however, because as has been pointed out, it can lead > to tradeoffs. It would not look like DHCPv4, but it would provide more > functionality and wouldn't look all that different. Right, a warning label should be added. And no, it wouldnt look like DHCPv4 because this latter doesnt do routing to Client. > Default is just one case of routing information that would then be > possible. Yes and no. Yes conceptually a default route is just a route with all-zeros prefix and reset prefix length. But in more detail the default route is present in addition in other IPv6-exclusive places - like the DefaultRoutersList of ND, where normal routes are absent. That list has some parameters which dont exist with, or have different lengths than, mundane routes (lifetime, etc.). Also, in other more human terms - often the entire effort of DHCPv6 Route/DefRouters/src-basedRoute gets killed entirely only because of this DefRouter aspect. I mean - it _could_ be possible to have a spec that DHCPv6 Routes-nonDefault should have some status, and maybe another place which says that DHCPv6 defRoutes has other status. A DHCPv6-Route-butnotDefRoutes (i.e. say that the prefix and its length each must be non-zero) whould not compete to either RA DefRouters, hence no reason to kill it. A DHCPv6-Route-butnotDefRoutes-to-configureRouters-but-nottoconfigureHosts would not compete to RFC4191 either. Rather than having nothing. > e.g. > > … > routing-option { 2001:db8:1234::/48, 2001:db8:1234:fe96::1, 1002 }; > routing-option { ::/0, 2001:db8:1234:fe96::ea99, 512 }; > … > > This would provide two routes. The first, a /48 more specific to the local > prefix via a router at 2001:db8:1234:fe96::1 and the other a default via > a different router at …::ea99. The syntax looks reasonable, expressing the contents of a fictitious dhcpd.conf file doing what we'd like to achieve with Routes and DefRouters. I wonder how src-basedRoutes would fit? > The first route has a metric of 1002. The second a metric of 512. > > >>> Once they get past that and deploy using RAs, they will find out >>> that it's really not a problem. Our company's enterprise operators >>> know this already. We just need to give the others time to find out. >> >> Ok, deploying RAs needs an effort of understanding RA. And some people >> already figured it out, somehow. >> > > Deploying RAs is pretty straight forward and you have to do that anyway > just to bootstrap DHCP in most cases. YEs, in most cases. One may also consider cases where RA is completely absent, no ND implementation. (e.g. RPL and 6lowpan machines). >> But, how do your company's enterprise operators maintain the supposedly >> numerous radvd.conf files on the routers? Do they think there may be a >> problem in that? (like e.g. when some PC software misinterprets the M/O >> flags, or when the frequency must be increased because of a growing >> number of PCs). >> > > ? There's only one radvd.conf file on any given router and that's only > if the > router is running linux. Configuring routers is necessary no matter what. > Maintaining the RA configuration as part of the router configuration is > nothing unusual. Well, I meant to ask how to update large number of radvd.conf files on multiple such access routers? I don't know how people update these radvd.conf files with an automated manner. I am asking because DHCP is easier to manage in that sense. The Access Routers are pre-configured with the stable address of the Server, and one describes the entire topology of the Access Routers only in a single configuration file - dhcpd.conf. Alex > > Normal routers configure RAs just like any other part of configuring a > router: > > fe-0/0/0 { > unit 0 { > description LAN; > family inet { > mtu 1500; > filter { > output deny-bad-actors; > } > address 192.159.10.251/24 { > vrrp-group 1 { > virtual-address 192.159.10.254; > priority 250; > advertise-interval 5; > preempt; > accept-data; > } > } > inactive: address 192.124.40.1/30; > } > family inet6 { > mtu 1500; > address 2620:0:930::dead:beef/64; > address 2620:0:930::/64 { > eui-64; > primary; > } > address 2001:470:1f00:3142::dead:beef/64; > address 2620:0:930::200:30/64; > } > } > } > > > The above interface configuration is running code from a Juniper > SRX-100 providing RAs for SLAAC on the interface in question. > > In this case, use of the "eui-64" configuration parameter is sufficient > to trigger RAs. One can add additional RA configuration options > within that address clause if necessary to control the content and > other aspects of the RAs more specifically, if needed. It is usually > not needed. > > The primary keyword causes the router to use this address to > initiate sessions. It is unrelated to RAs. > > Owen > > From iljitsch@muada.com Wed Mar 27 10:06:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24BF21F91F8 for ; Wed, 27 Mar 2013 10:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wC4swIEecps for ; Wed, 27 Mar 2013 10:06:05 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id E39D021F91F6 for ; Wed, 27 Mar 2013 10:06:04 -0700 (PDT) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2RH0wEe028661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Mar 2013 18:00:59 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <515319E4.60707@gmail.com> Date: Wed, 27 Mar 2013 18:06:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <5152AA3D.80606@dougbarton.us> <5152BB63.5060801@globis.net> <25D0CBBD-9A56-475C-AC27-D1A10D38E331@muada.com> <515319E4.60707@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 17:06:05 -0000 On 27 mrt 2013, at 17:10, Alexandru Petrescu = wrote: > Sure the problem can happen with RAs - I did myself in error. Of course there are ways to make RAs work incorrectly, but there's the = fate sharing advantage and we've had RAs for 18 years now so the = likelihood of problems is much smaller than with something new that = doesn't have fate sharing. > So there I sit with a PC switching back and forth between the ARs, at = a > high frequency. This is strange. The situation where two routers send out RAs is = prefectly normal, you would expect a host to choose one default router = and stick to that until the RA lifetime expires or neighbor = unreachability detection kicks in. But it seems like the OS on your PC = simply switched with every new RA received or did some kind of load = balancing. > The problem happens as much with RAs as with any other protocol. Not as much. And if you make another protocol, then you have a problem if one of the = two doesn't work (~ 2 times as likely as that one of one doesn't work) = or when the two provide conflicting information. > For src-basedRoute -- the argumentation doesnt hold because RA doesnt > advertise src-basedRoute. Right. My arguments don't apply to that. > Well, we need a place to discuss this. I currently try here. I think this is as good a place as any, for the time being. So no = problem with that. > There are new arguments now, like that SDO. What SDO? > Alternate ways - I am open to suggestions of alternate ways for DHCPv6 > DefRouters to small PC Mobile Router for fast configuration. = Listening. My suggestion is that a new DHCPv6 option carries a list of preferred = default routers. Then, if multiple default routers are available from = RAs, the information from the DHCPv6 option allows the host to select = the right one. So in the case where everything works as expected, this provides the = same functionality as having a default route in DHCPv6 the same way as = with IPv4 DHCP. However, if the router that the DHCPv6 server points to is down, there = will be no RA from that router, and the host will use a different = router. This makes the mechanism much more robust against failures. Iljitsch= From owen@delong.com Wed Mar 27 10:06:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B7621F9212 for ; Wed, 27 Mar 2013 10:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 cHPmASoxzcSJ for ; Wed, 27 Mar 2013 10:06:27 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id EF0E321F8B19 for ; Wed, 27 Mar 2013 10:06:26 -0700 (PDT) Received: from [10.255.252.171] ([207.102.63.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2RH5QKv017656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 10:05:27 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2RH5QKv017656 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364403928; bh=jWJtvubv+4G3NDiKaokOqGs8L6g=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=jbtiUvOJc8kcoh42VFWv8CH8OJ7xtB9fqGssK10NSBZpz/eAu9op8G0uLdPP5Nuwc 2xWbg5ezh4y8vn1A/hYHaNejwMC5m+iquhfMHD3525twjUmvCHlgZ8YE0FNxlBIQDU Wn1rRNSSF07Xo5GlOzWVbXkF4SOiS/RYPfkLc9Qg= References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <515314D4.8090609@gmail.com> <5E0D1481-6BA6-495B-9F6A-2418153EC02C@delong.com> <5153228F.2070905@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5153228F.2070905@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <6796C48D-4C02-49F3-B15B-79B8C900E9BA@delong.com> X-Mailer: iPad Mail (10B146) From: Owen DeLong Date: Wed, 27 Mar 2013 10:05:28 -0700 To: Alexandru Petrescu X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 27 Mar 2013 10:05:28 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 17:06:28 -0000 >> Default is just one case of routing information that would then be >> possible. >=20 > Yes and no. >=20 > Yes conceptually a default route is just a route with all-zeros prefix and= reset prefix length. >=20 > But in more detail the default route is present in addition in other IPv6-= exclusive places - like the DefaultRoutersList of ND, where normal routes ar= e absent. That list has some parameters which dont exist with, or have diff= erent lengths than, mundane routes (lifetime, etc.). >=20 But it doesn't _HAVE_ to have them outside of the ones provided by RA. For example, if I type: route -f inet6 add -net ::/0 gw 2001:db8::1 I get a default route that has none of those extra attributes. They are opti= onal. Further, nothing prevents other more specific routes from having those attri= butes, either. Likely any route configured via DHPCv6 would, in fact, have t= hose attributes. > Also, in other more human terms - often the entire effort of DHCPv6 Route/= DefRouters/src-basedRoute gets killed entirely only because of this DefRoute= r aspect. >=20 I disagree. This effort gets killed because certain religious zealots in the= IETF believe that systems administrators should not be granted any control o= ver how packets move and it should be the exclusive province of network admi= nistrators/engineers/architects. > I mean - it _could_ be possible to have a spec that DHCPv6 Routes-nonDefau= lt should have some status, and maybe another place which says that DHCPv6 d= efRoutes has other status. >=20 To what possible advantage? If we provide a generic route option where default is just a particular pref= ix/length combination (and there is actually some valid argument for using 2= 000::/3 rather than ::/0 for default for now, especially in light of the var= ious problems caused by ULA. Unfortunately, RA does not support this behavio= r, but I digress). > A DHCPv6-Route-butnotDefRoutes (i.e. say that the prefix and its length ea= ch must be non-zero) whould not compete to either RA DefRouters, hence no re= ason to kill it. >=20 I think you are not paying attention to the argument being raised by the voc= al few who insist on killing this. For the most part, they are people that h= ave opposed DHCP since before it was even documented in IPv4. > A DHCPv6-Route-butnotDefRoutes-to-configureRouters-but-nottoconfigureHosts= would not compete to RFC4191 either. I'm still not seeing an advantage to doing this. I don't think it will impro= ve the politics of the situation. It certainly doesn't provide a better alte= rnative to operators. >=20 > Rather than having nothing. >=20 Based on discussions I've had with a variety of people in a position to cont= rol actual code development, I don't think that "having nothing" situation w= ill last all that long. Every effort is being made to solve this problem wit= hin the IETF. If that doesn't work, it will eventually get solved without th= e IETF. >> e.g. >>=20 >> =E2=80=A6 >> routing-option { 2001:db8:1234::/48, 2001:db8:1234:fe96::1, 1002 }; >> routing-option { ::/0, 2001:db8:1234:fe96::ea99, 512 }; >> =E2=80=A6 >>=20 >> This would provide two routes. The first, a /48 more specific to the loca= l >> prefix via a router at 2001:db8:1234:fe96::1 and the other a default via >> a different router at =E2=80=A6::ea99. >=20 > The syntax looks reasonable, expressing the contents of a fictitious dhcpd= .conf file doing what we'd like to achieve with Routes and DefRouters. >=20 > I wonder how src-basedRoutes would fit? >=20 They would not. If you want policy routing, create an option to support tha= t. I, personally, have no interest in the development of such an option. I d= on't have any strong objection to it, either, but I believe that policy rout= ing has its own unique pathologies and should be treated separately from gen= eric destination-based routing. >> ? There's only one radvd.conf file on any given router and that's only >> if the >> router is running linux. Configuring routers is necessary no matter what.= >> Maintaining the RA configuration as part of the router configuration is >> nothing unusual. >=20 > Well, I meant to ask how to update large number of radvd.conf files on mul= tiple such access routers? >=20 This doesn't usually happen. That's probably one of the reasons that this op= tion is usually discounted when it is raised. > I don't know how people update these radvd.conf files with an automated ma= nner. >=20 Mostly, they don't. If you want a customized router configuration, you manag= e your routers. If you're talking about customizing the router configuration= on a bunch of CPE routers, the average residential ISP will tell you that i= t is a non-starter. > I am asking because DHCP is easier to manage in that sense. The Access Ro= uters are pre-configured with the stable address of the Server, and one desc= ribes the entire topology of the Access Routers only in a single configurati= on file - dhcpd.conf. There is no available mechanism for this today. Owen From dougb@dougbarton.us Wed Mar 27 10:22:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF14521F915F for ; Wed, 27 Mar 2013 10:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t44xk1G5NNjt for ; Wed, 27 Mar 2013 10:22:56 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA7421F9052 for ; Wed, 27 Mar 2013 10:22:56 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:e1fc:a7d2:7967:b54e] (unknown [IPv6:2001:470:d:5e7:e1fc:a7d2:7967:b54e]) by dougbarton.us (Postfix) with ESMTPSA id BBA4022B12 for ; Wed, 27 Mar 2013 17:22:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1364404975; bh=o57CjcRryaImCYNEdQZMUC0jcg2eb+R89xxlPVEYmhE=; h=Date:From:To:Subject:References:In-Reply-To; b=wWHS4uRZND0cG+elwTiX4wWFdWhT8si4Xa8upgsaWE8y0ym7Vb5a/IgO6hCRDXsrl Lp2jtAs6AxqG57/FCE2+IZ7eNYcQtUMAgM2Z58G3ZOY7/7CPJKjUlIyfPNgjbLH/ax OCWEUAQP955xu0EFs7qTesD/khbkMb13z1Zwk2MQ= Message-ID: <51532AEF.2030702@dougbarton.us> Date: Wed, 27 Mar 2013 10:22:55 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <4FC37E442D05A748896589E468752CAA0A671F49@PWN401EA160.ent.corp.bcbsm.com> <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> In-Reply-To: <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 17:23:00 -0000 On 03/27/2013 08:25 AM, Iljitsch van Beijnum wrote: > On 27 mrt 2013, at 15:05, "Ackermann, Michael" wrote: > >> Good point regarding sites planning to use DHCPv6 may need things like this. It would be beneficial to all to get ahead of the curve and consider providing such controls BEFORE Enterprises and Operators try to deploy and then discover issues that slow the deployment. > > There were similar sentiments around IPv6 PI. Now with PI in place the IPv6 routing table is certainly a lot larger than before, but there was not an immediate uptick in IPv6 deployment. > > If the IETF standardizes a new, highly sought after DHCPv6 option, then that still doesn't buy anyone anything, because it needs to be implemented in a whole bunch of operating systems first. That takes many years. So just like every other IETF protocol, the effect of the change won't be instantaneous. That doesn't mean we shouldn't do the right thing now, so that at some point down the road it can be used. If this particular change had been done 12 years ago like some of us were asking the problem would have been solved a long time ago. Doug From alexandru.petrescu@gmail.com Wed Mar 27 10:26:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866CD21F84A8 for ; Wed, 27 Mar 2013 10:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.34 X-Spam-Level: X-Spam-Status: No, score=-9.34 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xr97krLaar-L for ; Wed, 27 Mar 2013 10:26:41 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 0843A21F89B2 for ; Wed, 27 Mar 2013 10:26:34 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2RHQXXW015525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 27 Mar 2013 18:26:33 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2RHQXR2013192 for ; Wed, 27 Mar 2013 18:26:33 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2RHQPJ7024299 for ; Wed, 27 Mar 2013 18:26:33 +0100 Message-ID: <51532B89.7070701@gmail.com> Date: Wed, 27 Mar 2013 18:25:29 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6E5795@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6E5795@nkgeml506-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] ULA discussion #1 ULA+NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 17:26:41 -0000 I think one could write down that packet headers containing an address prefixed by fd00:: must not be rewritten other than maybe decrementing the HopLimit. (in similar way that it's written that a link-local address can't go out of a link). Alex Le 04/03/2013 13:20, Liubing (Leo) a écrit : > Hi, Dear all > > (Note: Thanks for your comments, those would help the authors a lot. > I split and summarize some topics from the discussion, for ease of > further discussion, hope we can make some consensus. Any specific > discussion please going to the relevant thread, many thanks.) > > For ULA+NPTv6, as I understand according to the discussion, we > considering it because we want to get independence address space, > then coming the compare of NPTv6 vs PI. (Please correct me if I > mistakenly understood it) > > we mainly have two views: A: ULA+NPTv6 should be "Not recommended" in > this document. Since we need to promote E2E transparence in IPv6. > NPTv6 broke the transparence and made more overall cost by adjust the > network/applications to fit the NAT environment. Contrastively, > acquiring a PI would not cost too much, and easy to deploy with BGP. > B: "Not recommended" is way too much, we need fairly stating the pros > and cons in the document. Since NPTv6 is a reasonable requirement of > the real end-users. Configuring BGP for PI would not feet all the > users, especially the small enterprises and home users. And needs no > cost on RIR fees. Moreover, no limited PI might potentially cause > serious BGP4 scaling issue, considering the multihoming requirement > in IPv6 might explode. > > Please supplement if I missed some points, and hope more people could > comment on this topic. > > Thanks a lot. > > Cheers, Bing > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From iljitsch@muada.com Wed Mar 27 10:37:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F45821F923F for ; Wed, 27 Mar 2013 10:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MG3TfH2vUnA7 for ; Wed, 27 Mar 2013 10:37:20 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id AB0E621F920E for ; Wed, 27 Mar 2013 10:37:19 -0700 (PDT) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2RHWDDh028947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Mar 2013 18:32:13 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <51532AEF.2030702@dougbarton.us> Date: Wed, 27 Mar 2013 18:37:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0FACA054-11D6-41D3-9ADB-0EFC7E583415@muada.com> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <4FC37E442D05A748896589E468752CAA0A671F49@PWN401EA160.ent.corp.bcbsm.com> <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> <51532AEF.2030702@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 17:37:20 -0000 On 27 mrt 2013, at 18:22, Doug Barton wrote: >> If the IETF standardizes a new, highly sought after DHCPv6 option, = then that still doesn't buy anyone anything, because it needs to be = implemented in a whole bunch of operating systems first. That takes many = years. > So just like every other IETF protocol, the effect of the change won't = be instantaneous. That doesn't mean we shouldn't do the right thing now, = so that at some point down the road it can be used. In general that's true, but with configuration stuff it's more = complicated. See the situation where some OSes (Windows as of Vista) had = DHCPv6 support but others (MacOS 10.6) didn't. That was a very = unpleasant situation, because either you had to forego using DHCPv6 = altogether, or you had to make a configuration that would work for both = types (and probably suboptimally for at least one). If someone really has a special need in this area, it's probably a = better idea to install a routing daemon on their hosts rather than = expect ALL hosts connected to the internet to implement something new = that comes with additional failure modes. > If this particular change had been done 12 years ago like some of us = were asking the problem would have been solved a long time ago. Maybe after 5 or 10 years it would have been a good idea to start = looking at different options that provide the same benefits but are less = contentious. See my suggestion at the end of my previous message. Iljitsch= From dougb@dougbarton.us Wed Mar 27 10:53:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FCF21F9265 for ; Wed, 27 Mar 2013 10:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 U5Uh92pcaJIt for ; Wed, 27 Mar 2013 10:53:07 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCE921F9284 for ; Wed, 27 Mar 2013 10:53:07 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:e1fc:a7d2:7967:b54e] (unknown [IPv6:2001:470:d:5e7:e1fc:a7d2:7967:b54e]) by dougbarton.us (Postfix) with ESMTPSA id 42E2522B12 for ; Wed, 27 Mar 2013 17:53:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1364406787; bh=p5Q5IlMzcHwwJgc1ZxKnAmyD+t8pxXMMubOKQ7e9Zz8=; h=Date:From:To:Subject:References:In-Reply-To; b=G1/Ct047H5Lt+XP1A7GepN2Cf0wBtqyEU8zT5L62O8TTCtEti7lLcJu0rq5e3zo2p dTZzMipS820zGGwHDxkRkraMJhZITagXEh16nSeHPq6zfzaezlXnjYXCw/Hyx5La/T Sb5TtAlDaqiSp2GpqQPR9oY8aVoykRXAtJ3u2TKQ= Message-ID: <51533203.5010600@dougbarton.us> Date: Wed, 27 Mar 2013 10:53:07 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <4FC37E442D05A748896589E468752CAA0A671F49@PWN401EA160.ent.corp.bcbsm.com> <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> <51532AEF.2030702@dougbarton.us> <0FACA054-11D6-41D3-9ADB-0EFC7E583415@muada.com> In-Reply-To: <0FACA054-11D6-41D3-9ADB-0EFC7E583415@muada.com> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 17:53:09 -0000 On 03/27/2013 10:37 AM, Iljitsch van Beijnum wrote: > On 27 mrt 2013, at 18:22, Doug Barton wrote: > >>> If the IETF standardizes a new, highly sought after DHCPv6 >>> option, then that still doesn't buy anyone anything, because it >>> needs to be implemented in a whole bunch of operating systems >>> first. That takes many years. > >> So just like every other IETF protocol, the effect of the change >> won't be instantaneous. That doesn't mean we shouldn't do the right >> thing now, so that at some point down the road it can be used. > > In general that's true, but with configuration stuff it's more > complicated. See the situation where some OSes (Windows as of Vista) > had DHCPv6 support but others (MacOS 10.6) didn't. That was a very > unpleasant situation, because either you had to forego using DHCPv6 > altogether, or you had to make a configuration that would work for > both types (and probably suboptimally for at least one). No one is saying that it isn't going to take time to sort out the clients once the default router option is available. But the logical conclusion from that premise is not, "Don't do it," the logical conclusion is, "Do it as soon as possible." > If someone really has a special need in this area, it's probably a > better idea to install a routing daemon on their hosts rather than > expect ALL hosts connected to the internet to implement something new > that comes with additional failure modes. Completely unrealistic. The realistic scenario is: Fix the protocol, wait 3 years for the clients to be updated, then deploy IPv6. See below on why that's a perfectly acceptable scenario. >> If this particular change had been done 12 years ago like some of >> us were asking the problem would have been solved a long time ago. > > Maybe after 5 or 10 years it would have been a good idea to start > looking at different options that provide the same benefits but are > less contentious. See my suggestion at the end of my previous > message. Or, maybe (as Randy's message so ably stated) it would have been nice if people like you would realize that "my way or the highway" has resulted in the vast majority of operators taking the highway. We make happy noises about wanting input from the operator community. But when the message of, "We want full parity with DHCPv4 in DHCPv6" comes through loud, clear, and consistently for over a decade certain among us choose to stick their fingers in their ears and sing "la-la-la-la-la, I can't hear you." It's not Ok to continue playing that game. Enterprises have well established policies and procedures about who manages what bits of data/configuration/network policy/etc. They want to be able to manage DHCPv6 in a way that fits with their existing structures, and won't deploy IPv6 at all if they can't. And what some people around here seem to be missing is that there is absolutely no motivation for them to do so. In fact, there is little to no incentive for them to deploy v6 inside an end-user network at all right now, and there isn't going to be any time in the next 5 years for sure, and likely for another decade if not longer. So keep up your ivory tower "my way or the highway" stance if you want. You can be quite happy up there in your ivory tower while the rest of the world moves right on by you. Doug From nalini.elkins@insidethestack.com Wed Mar 27 11:01:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396EF21F910B for ; Wed, 27 Mar 2013 11:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] 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 yTS+8IDJCPQ1 for ; Wed, 27 Mar 2013 11:01:09 -0700 (PDT) Received: from nm21-vm0.access.bullet.mail.sp2.yahoo.com (nm21-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD3921F8D2D for ; Wed, 27 Mar 2013 11:01:09 -0700 (PDT) Received: from [98.139.44.96] by nm21.access.bullet.mail.sp2.yahoo.com with NNFMP; 27 Mar 2013 18:01:02 -0000 Received: from [98.139.44.81] by tm1.access.bullet.mail.sp2.yahoo.com with NNFMP; 27 Mar 2013 18:01:01 -0000 Received: from [127.0.0.1] by omp1018.access.mail.sp2.yahoo.com with NNFMP; 27 Mar 2013 18:01:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 987280.76551.bm@omp1018.access.mail.sp2.yahoo.com Received: (qmail 21429 invoked by uid 60001); 27 Mar 2013 18:01:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1364407261; bh=fxNjQHLeCZpxgZigscTvYCQZBeAkFoVw2Bq3EB7XSPg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=jNz5vE2KXh0LgQSAlpsObLoFlrmC/m2ThP71+BUUUPYyIMsRUIMKNJ1JXe+sZbW7KOOCu4o+PFUhXVNd4r7gUb6oFNhZTW+4qmfKC5eE+g5QcEH6HmmAoF0f5ivUgv5slrejTX6l/enRYqNh830I6GZBd6DI1tfLCLOsBvj49EA= X-YMail-OSG: 3bA597QVM1l28hqiF5dNXbAghEuYScIQQEfvKJAm.wwusxG zDRh192RVztT7cgsBIh_45_HyvLoYSfx2OgfB0qWy5n6xxQHOJjCZlObGhaG FFN.QhAUbp19wUZUuJrS3mgBtRXha72lU1orrt8a3O9yILzE55vrCcbM_G6x 9pL8f0VAf.z3ohyL_Hx8zmOYev_k3oaTvcAsPU8MJWbQLxBmE5GaeUxXcead 29jhv.xF_JBdHKS99d6iO5.9cPjXEyQNdJuhJuzkeLpQRf.Sqc93txE8Q82. DDzXhUmX8NEall7XwJ68Vu9bmuAV1g3ORqw4fyQgpmasboCzdDr.paOf3493 D48plyM7WZrs62MIytwSfeXGQ5Zxf6Bo_dinPebK8PT3fiz_izAfTPD51ReU 46LhFkAHIRJk0JFVmHwlrNYDSgoaeffFQUcj_cyH5xVsatQKYssoubbo.g7V oho5AdeZetPzZ5hAyQz79LdLKFnonvoPykH7TLqUWxBmon8Xiv.Hns_a36dm akHAXFvxoDiLVfQxbxGQDtbw0x2bd_yPhcwJ2QkuPwwnDrVJ5HVbO73BmixI .UeVLrNZSUVVZINH3hEv.TSZDxzlZSngvXQ_skux2QzgV Received: from [24.130.37.147] by web2805.biz.mail.ne1.yahoo.com via HTTP; Wed, 27 Mar 2013 11:01:01 PDT X-Rocket-MIMEInfo: 002.001, RG91ZywKCllvdSBnbywgZ2lybCEKwqAKVGhhbmtzLAoKCk5hbGluaSBFbGtpbnMKSW5zaWRlIFByb2R1Y3RzLCBJbmMuCig4MzEpIDY1OS04MzYwCnd3dy5pbnNpZGV0aGVzdGFjay5jb20KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206IERvdWcgQmFydG9uIDxkb3VnYkBkb3VnYmFydG9uLnVzPgpUbzogdjZvcHNAaWV0Zi5vcmcgClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMjcsIDIwMTMgMTA6NTMgQU0KU3ViamVjdDogUmU6IFt2Nm9wc10gSW50ZXJlc3QgaW4gREhDUHY2IFJvdXQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.139.530 References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <4FC37E442D05A748896589E468752CAA0A671F49@PWN401EA160.ent.corp.bcbsm.com> <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> <51532AEF.2030702@dougbarton.us> <0FACA054-11D6-41D3-9ADB-0EFC7E583415@muada.com> <51533203.5010600@dougbarton.us> Message-ID: <1364407261.16787.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Wed, 27 Mar 2013 11:01:01 -0700 (PDT) From: Nalini Elkins To: Doug Barton , "v6ops@ietf.org" In-Reply-To: <51533203.5010600@dougbarton.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1619178251-2131178922-1364407261=:16787" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 18:01:24 -0000 --1619178251-2131178922-1364407261=:16787 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Doug,=0A=0AYou go, girl!=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Pro= ducts, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A__________= ______________________=0A From: Doug Barton =0ATo: v6o= ps@ietf.org =0ASent: Wednesday, March 27, 2013 10:53 AM=0ASubject: Re: [v6o= ps] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Clie= nt?=0A =0AOn 03/27/2013 10:37 AM, Iljitsch van Beijnum wrote:=0A> On 27 mrt= 2013, at 18:22, Doug Barton wrote:=0A> =0A>>> If the= IETF standardizes a new, highly sought after DHCPv6=0A>>> option, then tha= t still doesn't buy anyone anything, because it=0A>>> needs to be implement= ed in a whole bunch of operating systems=0A>>> first. That takes many years= .=0A> =0A>> So just like every other IETF protocol, the effect of the chang= e=0A>> won't be instantaneous. That doesn't mean we shouldn't do the right= =0A>> thing now, so that at some point down the road it can be used.=0A> = =0A> In general that's true, but with configuration stuff it's more=0A> com= plicated. See the situation where some OSes (Windows as of Vista)=0A> had D= HCPv6 support but others (MacOS 10.6) didn't. That was a very=0A> unpleasan= t situation, because either you had to forego using DHCPv6=0A> altogether, = or you had to make a configuration that would work for=0A> both types (and = probably suboptimally for at least one).=0A=0ANo one is saying that it isn'= t going to take time to sort out the clients once the default router option= is available. But the logical conclusion from that premise is not, "Don't = do it," the logical conclusion is, "Do it as soon as possible."=0A=0A> If s= omeone really has a special need in this area, it's probably a=0A> better i= dea to install a routing daemon on their hosts rather than=0A> expect ALL h= osts connected to the internet to implement something new=0A> that comes wi= th additional failure modes.=0A=0ACompletely unrealistic.=0A=0AThe realisti= c scenario is: Fix the protocol, wait 3 years for the clients to be updated= , then deploy IPv6. See below on why that's a perfectly acceptable scenario= .=0A=0A>> If this particular change had been done 12 years ago like some of= =0A>> us were asking the problem would have been solved a long time ago.=0A= > =0A> Maybe after 5 or 10 years it would have been a good idea to start=0A= > looking at different options that provide the same benefits but are=0A> l= ess contentious. See my suggestion at the end of my previous=0A> message.= =0A=0AOr, maybe (as Randy's message so ably stated) it would have been nice= if people like you would realize that "my way or the highway" has resulted= in the vast majority of operators taking the highway.=0A=0AWe make happy n= oises about wanting input from the operator community. But when the message= of, "We want full parity with DHCPv4 in DHCPv6" comes through loud, clear,= and consistently for over a decade certain among us choose to stick their = fingers in their ears and sing "la-la-la-la-la, I can't hear you." It's not= Ok to continue playing that game.=0A=0AEnterprises have well established p= olicies and procedures about who manages what bits of data/configuration/ne= twork policy/etc. They want to be able to manage DHCPv6 in a way that fits = with their existing structures, and won't deploy IPv6 at all if they can't.= And what some people around here seem to be missing is that there is absol= utely no motivation for them to do so. In fact, there is little to no incen= tive for them to deploy v6 inside an end-user network at all right now, and= there isn't going to be any time in the next 5 years for sure, and likely = for another decade if not longer.=0A=0ASo keep up your ivory tower "my way = or the highway" stance if you want. You can be quite happy up there in your= ivory tower while the rest of the world moves right on by you.=0A=0ADoug= =0A_______________________________________________=0Av6ops mailing list=0Av= 6ops@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/v6ops --1619178251-2131178922-1364407261=:16787 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Doug,
=
You go, girl!
 
<= div>Thanks,

Nalini Elkins
Inside Products, Inc.
(83= 1) 659-8360
www.insidethestack.com

From: Doug Barton <dougb@dougbarton.us>=
To: v6ops@ietf.org
Sent: Wednesday, March 27, 2013 10:5= 3 AM
Subject: Re: [v6o= ps] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Clie= nt?

=0AOn 03/27/2013 10:37 AM, Iljitsch van Beijnum = wrote:
> On 27 mrt 2013, at 18:22, Doug Barton <dougb@dougbarto= n.us> wrote:
>
>>> If the IETF standardizes a new= , highly sought after DHCPv6
>>> option, then that still doesn'= t buy anyone anything, because it
>>> needs to be implemented i= n a whole bunch of operating systems
>>> first. That takes many= years.
>
>> So just like every other IETF protocol, the ef= fect of the change
>> won't be instantaneous. That doesn't mean we= shouldn't do the right
>> thing now, so that at some point down t= he road it can be used.
>
> In general that's true, but with c= onfiguration stuff it's more
> complicated. See the situation where s= ome OSes (Windows as of Vista)
> had DHCPv6 support but others (MacOS= 10.6) didn't. That was a very
> unpleasant situation, because either you had to forego using = DHCPv6
> altogether, or you had to make a configuration that would wo= rk for
> both types (and probably suboptimally for at least one).
=
No one is saying that it isn't going to take time to sort out the clien= ts once the default router option is available. But the logical conclusion = from that premise is not, "Don't do it," the logical conclusion is, "Do it = as soon as possible."

> If someone really has a special need in t= his area, it's probably a
> better idea to install a routing daemon o= n their hosts rather than
> expect ALL hosts connected to the interne= t to implement something new
> that comes with additional failure mod= es.

Completely unrealistic.

The realistic scenario is: Fix th= e protocol, wait 3 years for the clients to be updated, then deploy IPv6. S= ee below on why that's a perfectly acceptable scenario.

>> If this particular change had been done 12 years= ago like some of
>> us were asking the problem would have been so= lved a long time ago.
>
> Maybe after 5 or 10 years it would h= ave been a good idea to start
> looking at different options that pro= vide the same benefits but are
> less contentious. See my suggestion = at the end of my previous
> message.

Or, maybe (as Randy's mes= sage so ably stated) it would have been nice if people like you would reali= ze that "my way or the highway" has resulted in the vast majority of operat= ors taking the highway.

We make happy noises about wanting input fro= m the operator community. But when the message of, "We want full parity wit= h DHCPv4 in DHCPv6" comes through loud, clear, and consistently for over a = decade certain among us choose to stick their fingers in their ears and sin= g "la-la-la-la-la, I can't hear you." It's not Ok to continue playing that game.

Enterprises have well established policies and p= rocedures about who manages what bits of data/configuration/network policy/= etc. They want to be able to manage DHCPv6 in a way that fits with their ex= isting structures, and won't deploy IPv6 at all if they can't. And what som= e people around here seem to be missing is that there is absolutely no moti= vation for them to do so. In fact, there is little to no incentive for them= to deploy v6 inside an end-user network at all right now, and there isn't = going to be any time in the next 5 years for sure, and likely for another d= ecade if not longer.

So keep up your ivory tower "my way or the high= way" stance if you want. You can be quite happy up there in your ivory towe= r while the rest of the world moves right on by you.

Doug
_______= ________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/m= ailman/listinfo/v6ops


--1619178251-2131178922-1364407261=:16787-- From mackermann@bcbsm.com Wed Mar 27 11:07:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24D221F91BC for ; Wed, 27 Mar 2013 11:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] 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 sEgqrjn6kN5K for ; Wed, 27 Mar 2013 11:07:46 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id 3802B21F91B9 for ; Wed, 27 Mar 2013 11:07:45 -0700 (PDT) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id B3AC72FF71B for ; Wed, 27 Mar 2013 13:07:44 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 0E7CC3074C1; Wed, 27 Mar 2013 13:07:44 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 6CDB72F004D; Wed, 27 Mar 2013 14:06:07 -0400 (EDT) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) by imsva2.bcbsm.com (Postfix) with ESMTP id 60D022F004A; Wed, 27 Mar 2013 14:06:07 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([fe80::716f:e3f0:b97f:8900%14]) with mapi id 14.01.0438.000; Wed, 27 Mar 2013 14:07:43 -0400 From: "Ackermann, Michael" To: Iljitsch van Beijnum Thread-Topic: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? Thread-Index: AQHOKjyV245aKa0zuUe8lncJ9YSY+Ji5XDOAgAAgNYCAABadoIAAWlGA///proA= Date: Wed, 27 Mar 2013 18:07:41 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A672248@PWN401EA160.ent.corp.bcbsm.com> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <4FC37E442D05A748896589E468752CAA0A671F49@PWN401EA160.ent.corp.bcbsm.com> <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> In-Reply-To: <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 18:07:46 -0000 In the large enterprise and data center operator environments there is = still a great deal of resistance to IPv6. The more things like this we = can do to remove potential excuses the better in my view. Even if we may = have to wait. =20 -----Original Message----- From: Iljitsch van Beijnum =5Bmailto:iljitsch=40muada.com=5D=20 Sent: Wednesday, March 27, 2013 11:26 AM To: Ackermann, Michael Cc: Brian E Carpenter; v6ops=40ietf.org Subject: Re: =5Bv6ops=5D Interest in DHCPv6 Route/DefRouter/Src-basedRoute = configuration to Client? On 27 mrt 2013, at 15:05, =22Ackermann, Michael=22 = wrote: > Good point regarding sites planning to use DHCPv6 may need things like = this. It would be beneficial to all to get ahead of the curve and = consider providing such controls BEFORE Enterprises and Operators try to = deploy and then discover issues that slow the deployment. =20 There were similar sentiments around IPv6 PI. Now with PI in place the = IPv6 routing table is certainly a lot larger than before, but there was = not an immediate uptick in IPv6 deployment. If the IETF standardizes a new, highly sought after DHCPv6 option, then = that still doesn't buy anyone anything, because it needs to be implemented = in a whole bunch of operating systems first. That takes many years. The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From mackermann@bcbsm.com Wed Mar 27 11:23:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B176921F91CA for ; Wed, 27 Mar 2013 11:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 Vf616IyOUZ-z for ; Wed, 27 Mar 2013 11:23:03 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id C155E21F91A2 for ; Wed, 27 Mar 2013 11:23:03 -0700 (PDT) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 4A8642FF723 for ; Wed, 27 Mar 2013 13:23:03 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id C40983074D4; Wed, 27 Mar 2013 13:23:02 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 933B04F804F; Wed, 27 Mar 2013 14:21:27 -0400 (EDT) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) by imsva1.bcbsm.com (Postfix) with ESMTP id 8367F4F804D; Wed, 27 Mar 2013 14:21:27 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([fe80::716f:e3f0:b97f:8900%14]) with mapi id 14.01.0438.000; Wed, 27 Mar 2013 14:23:01 -0400 From: "Ackermann, Michael" To: Doug Barton , "v6ops@ietf.org" Thread-Topic: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? Thread-Index: AQHOKxP4YmeUZpdsYEmuNEkVHSFu+5i52SVA Date: Wed, 27 Mar 2013 18:23:01 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0A6722FD@PWN401EA160.ent.corp.bcbsm.com> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <4FC37E442D05A748896589E468752CAA0A671F49@PWN401EA160.ent.corp.bcbsm.com> <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> <51532AEF.2030702@dougbarton.us> <0FACA054-11D6-41D3-9ADB-0EFC7E583415@muada.com> <51533203.5010600@dougbarton.us> In-Reply-To: <51533203.5010600@dougbarton.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 18:23:07 -0000 Doug, You speak for many of us=21 Thanks=21 =20 I push very hard for IPv6 in my organizations but the push back is strong = when existing capabilities are removed. =20 I realize in many cases the push backs are little more than feeble = excuses, but nonetheless, they provide a convenient barrier and make it = that much more difficult for those of us trying to promote IPv6. =20 -----Original Message----- From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Doug Barton Sent: Wednesday, March 27, 2013 1:53 PM To: v6ops=40ietf.org Subject: Re: =5Bv6ops=5D Interest in DHCPv6 Route/DefRouter/Src-basedRoute = configuration to Client? On 03/27/2013 10:37 AM, Iljitsch van Beijnum wrote: > On 27 mrt 2013, at 18:22, Doug Barton wrote: > >>> If the IETF standardizes a new, highly sought after DHCPv6 option,=20 >>> then that still doesn't buy anyone anything, because it needs to be=20 >>> implemented in a whole bunch of operating systems first. That takes=20 >>> many years. > >> So just like every other IETF protocol, the effect of the change=20 >> won't be instantaneous. That doesn't mean we shouldn't do the right=20 >> thing now, so that at some point down the road it can be used. > > In general that's true, but with configuration stuff it's more=20 > complicated. See the situation where some OSes (Windows as of Vista)=20 > had DHCPv6 support but others (MacOS 10.6) didn't. That was a very=20 > unpleasant situation, because either you had to forego using DHCPv6=20 > altogether, or you had to make a configuration that would work for=20 > both types (and probably suboptimally for at least one). No one is saying that it isn't going to take time to sort out the clients = once the default router option is available. But the logical conclusion = from that premise is not, =22Don't do it,=22 the logical conclusion is, = =22Do it as soon as possible.=22 > If someone really has a special need in this area, it's probably a=20 > better idea to install a routing daemon on their hosts rather than=20 > expect ALL hosts connected to the internet to implement something new=20 > that comes with additional failure modes. Completely unrealistic. The realistic scenario is: Fix the protocol, wait 3 years for the clients = to be updated, then deploy IPv6. See below on why that's a perfectly = acceptable scenario. >> If this particular change had been done 12 years ago like some of us=20 >> were asking the problem would have been solved a long time ago. > > Maybe after 5 or 10 years it would have been a good idea to start=20 > looking at different options that provide the same benefits but are=20 > less contentious. See my suggestion at the end of my previous message. Or, maybe (as Randy's message so ably stated) it would have been nice if = people like you would realize that =22my way or the highway=22 has = resulted in the vast majority of operators taking the highway. We make happy noises about wanting input from the operator community.=20 But when the message of, =22We want full parity with DHCPv4 in DHCPv6=22=20 comes through loud, clear, and consistently for over a decade certain = among us choose to stick their fingers in their ears and sing = =22la-la-la-la-la, I can't hear you.=22 It's not Ok to continue playing = that game. Enterprises have well established policies and procedures about who = manages what bits of data/configuration/network policy/etc. They want to = be able to manage DHCPv6 in a way that fits with their existing = structures, and won't deploy IPv6 at all if they can't. And what some = people around here seem to be missing is that there is absolutely no = motivation for them to do so. In fact, there is little to no incentive for = them to deploy v6 inside an end-user network at all right now, and there = isn't going to be any time in the next 5 years for sure, and likely for = another decade if not longer. So keep up your ivory tower =22my way or the highway=22 stance if you = want.=20 You can be quite happy up there in your ivory tower while the rest of the = world moves right on by you. Doug _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From pkern@spike.0x539.de Wed Mar 27 11:38:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C61C21F913B for ; Wed, 27 Mar 2013 11:38:31 -0700 (PDT) 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_13=0.6] 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 AlOleai0Oo9d for ; Wed, 27 Mar 2013 11:38:30 -0700 (PDT) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E5121F9135 for ; Wed, 27 Mar 2013 11:38:29 -0700 (PDT) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UKvEn-0003kU-IB for v6ops@ietf.org; Wed, 27 Mar 2013 19:38:17 +0100 Received: from p2003006b0d000d01dcabdf10aa1dd3b9.dip.t-dialin.net ([2003:6b:d00:d01:dcab:df10:aa1d:d3b9] helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1UKvEo-0008Jm-Qs for v6ops@ietf.org; Wed, 27 Mar 2013 19:38:18 +0100 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1UKvEo-0005uF-2G for v6ops@ietf.org; Wed, 27 Mar 2013 19:38:18 +0100 Date: Wed, 27 Mar 2013 19:38:18 +0100 From: Philipp Kern To: "v6ops@ietf.org" Message-ID: <20130327183818.GA22021@spike.0x539.de> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5152B0C9.8010906@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 18:38:31 -0000 Brian, am Wed, Mar 27, 2013 at 08:41:45AM +0000 hast du folgendes geschrieben: > On 27/03/2013 06:46, Lorenzo Colitti wrote: > > v6ops does not create protocols. You should probably take this to 6man. > I think he's asking whether there is an operational need for this. I think there is an operational need to communicate flexible (source prefix, destination prefix, route target) tuples to clients, regardless if that protocol is DHCPv6 or RA. (This lack is currently biting us with high bandwidth applications, on IPv4 however.) Kind regards Philipp Kern From markzzzsmith@yahoo.com.au Wed Mar 27 12:11:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3EC421F9058 for ; Wed, 27 Mar 2013 12:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.17 X-Spam-Level: X-Spam-Status: No, score=-1.17 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] 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 DqpT4WGl9r7J for ; Wed, 27 Mar 2013 12:11:52 -0700 (PDT) Received: from nm25.bullet.mail.bf1.yahoo.com (nm25.bullet.mail.bf1.yahoo.com [98.139.212.184]) by ietfa.amsl.com (Postfix) with ESMTP id 2A55A21F9047 for ; Wed, 27 Mar 2013 12:11:52 -0700 (PDT) Received: from [98.139.212.149] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 27 Mar 2013 19:11:51 -0000 Received: from [98.139.212.229] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 27 Mar 2013 19:11:51 -0000 Received: from [127.0.0.1] by omp1038.mail.bf1.yahoo.com with NNFMP; 27 Mar 2013 19:11:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 668119.78067.bm@omp1038.mail.bf1.yahoo.com Received: (qmail 11018 invoked by uid 60001); 27 Mar 2013 19:11:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1364411511; bh=rmK4ek0Tnrpb3eR8i8Yxm2Zs/DnoF6aNSeiiKgIxPMs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=FK61okT033H6CUImgES00OWUEXO33R0sw9gxB9txO2XWqXWyiFkFc03sIDC/syOlDvL7BjA5rx7QKK2LBuS2ryIpUfT/WU821PGHa5ZE9PH+QPcus4iuYD8wsEQHZIFq3jtGWmEdN6DwpMWzWpLy9CBPmnI3zTyWOtexWVYuX+g= 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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ee4NWCkzmIbNAEqeWRGFjjN1LqKxiKMxKGiBpfZXuJCRwaUVga7k2m45KBrqfsxB4IR88fb79bLNGspL/JWRVEncfeTaVbT+G43BakPcRwIkn9HxgwDQdvlNVOYcbOUn3R9AIph1cmxZPcxcnerqbXlbbxsT3HvFZbkojehBPlU=; X-YMail-OSG: x0Dd0yIVM1k3BNKqtx9KWNTumbxACYKR18x0R5brpKUto.p ZcnYBq0H9UaDwoefvAfXd2XmNjTHHOohWJgpHUprUHrzHqNBoDuc73gL5FGV UkMEB4VY47pwjJJ8KrFX4bckbU6lcZ.pd9W4BnO4IYp_7FGx.qhZja636jHz LQ1zw.dQyERczLp6u7vnk8yu4Mor3y988SUBs1bHVWi21hXmwYrp6eir2SCx NT1zm3ko.EcaGUhz.tTd2sv8ALKnEdp_Bp3owbgdnb3QellmvAfwz7khd5iO ghCpbOHfoHU0tXnFoYV0y24MoQvMSC1dalLR6Bm6ASTMyET9Jq7ab8kek1JZ MtKVToGPElwppugxZSTJ_JaGUYNXr4s.giK2tnfRLK2Nas8boiEbVkylhm1E Fwnnq7yM.NHv5_XGQ7hYI_FGQ0uJ6Fm1b18xjxq52S96_sIEITPDMfvowMFJ HzVFLLFlMQ9WyO41Q1_W9Kuy4M4HVVw5q7XLSno.nGSn1.bq.Hf7jTPw6the 5W09rSbSlYyQpFzoDEGEF6hag Received: from [150.101.221.237] by web142502.mail.bf1.yahoo.com via HTTP; Wed, 27 Mar 2013 12:11:50 PDT X-Rocket-MIMEInfo: 002.001, U2luY2UgdGhlIGZvbGxvd2luZyBpdCBzZWVtcyB0byBoYXZlIGJlZW4gbWlzc2VkLCBhbmQgdGhpcyBkaXNjdXNzaW9uIGlzIGp1c3QgYnVybmluZyB1cCBtb3JlIGJhbmR3aWR0aCBhbmQgcGVvcGxlcycgdGltZSAocGVyaGFwcyBmb3IgdGhlIDUwdGggdGltZSBpbiB0aGUgbGFzdCBkZWNhZGU_KSwgSSdtIHJlcG9zdGluZyBpdC4KClJBcyBjYW4gYmUgc2VsZWN0aXZlbHkgdW5pY2FzdCB0byBjbGllbnRzLCBhbmQgdGhlIHJhZHZkIElQdjYgUkEgaW1wbGVtZW50YXRpb24gcHJvdmlkZXMgdGhhdCBvcHRpb24BMAEBAQE- X-Mailer: YahooMailWebService/0.8.139.530 References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> Message-ID: <1364411510.8596.YahooMailNeo@web142502.mail.bf1.yahoo.com> Date: Wed, 27 Mar 2013 12:11:50 -0700 (PDT) From: Mark Smith To: v6ops v6ops WG In-Reply-To: <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 19:11:54 -0000 Since the following it seems to have been missed, and this discussion is ju= st burning up more bandwidth and peoples' time (perhaps for the 50th time i= n the last decade?), I'm reposting it.=0A=0ARAs can be selectively unicast = to clients, and the radvd IPv6 RA implementation provides that option. The = email below has the manual page text and an example.=0A=0AIt may not be the= way that DHCPv4 solved this problem (which perhaps is a symptom of IPv4 no= t having autoconfiguration from the outset), but all that does is make it a= different way of solving the problem. The DHCPv4 model is not the be all a= nd end all solution to all network configuration problems.=0A=0AOther than = other router implementations not providing the option to do unicast RAs to = select clients (not a problem the IETF can solve), the only gap I can see t= hat DHCPv4 fills verses unicast RAs for influencing client's default router= selection is the ability to have the mapping of client to router centralis= ed on a DHCPv4 server and then having routers use that information via DHCP= v4 forwarding. So what is necessary for IPv6 is a method to either distribu= te the list of clients to unicast RAs map to to the routers, or to have the= router query a centralised server when it receives an RS. That is a better= solution than duplicating functionality from RAs into DHCPv6, as it would = only require changes to router implementations, rather than the deployed IP= v6 implementations in hosts, and avoid the inevitable issues around what to= do when conflicting default router information is received from an RA vers= es DHCPv6.=0A=0A=0A=0A=0A=0A=0A----- Forwarded Message -----=0A> From: Mark= Smith =0A> To: Iljitsch van Beijnum ; Alexandru Petrescu =0A> Cc: "v6ops= @ietf.org" =0A> Sent: Wednesday, 27 March 2013 8:05 PM=0A> = Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute conf= iguration to Client?=0A> =0A>> ________________________________=0A>> From:= Iljitsch van Beijnum =0A>> To: Alexandru Petrescu =0A>> Cc: "v6ops@ietf.org" =0A>= > Sent: Wednesday, 27 March 2013 6:54 PM=0A>> Subject: Re: [v6ops] Interest= in DHCPv6 Route/DefRouter/Src-basedRoute =0A> configuration to Client?=0A>= > =0A>> On 26 mrt 2013, at 17:09, Alexandru Petrescu =0A> wrote:=0A>> =0A>>> Is there an interest in DHCPv6 Route/DefR= outer/Src-basedRoute=0A>>> configuration to Client?=0A>> =0A>> The big iss= ue with having DHCPv6 deliver a default route is that it breaks =0A> the fa= te sharing that having the default router address in a router =0A> advertis= ement from the router holding that address provides.=0A>> =0A>> But I gathe= r there are people who want to be able to make one group of hosts =0A> on a= subnet use router A as their default router but another group of hosts =0A= > router B, on that same subnet.=0A>> =0A> =0A> This should already possibl= e using RAs, with an example implementation being the =0A> clients section = in radvd/radvd.conf. Here is the manual page help text:=0A> =0A> =C2=A0=C2= =A0 =C2=A0 =C2=A0 By =C2=A0default =C2=A0radvd will send route advertisemen= ts so that every node on=0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0the link can use th= em. =C2=A0The list of clients (IPv6 address) to advertise=0A> =C2=A0 =C2=A0= =C2=A0 =C2=A0to, =C2=A0and =C2=A0accept =C2=A0route solicitations from can= be configured. =C2=A0If done,=0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0radvd does no= t send send messages to the multicast addresses but to the=0A> =C2=A0 =C2= =A0 =C2=A0 =C2=A0configured =C2=A0unicast addresses only. =C2=A0Solicitatio= ns from other addresses=0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0are refused. =C2=A0T= his is similar to UnicastOnly but includes periodic mes=E2=80=90=0A> =C2=A0= =C2=A0 =C2=A0 =C2=A0sages =C2=A0and =C2=A0incoming client access configura= tion. =C2=A0See examples section=0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0for a use c= ase of this.=0A> =0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0The definitions are of the= form:=0A> =0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0clients {=0A> =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list of IPv6 addresses=0A> =C2=A0 =C2= =A0 =C2=A0 =C2=A0};=0A> =0A> =0A> Further into the manual page is an exampl= e configuration:=0A> =0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0interface eth0=0A> =C2= =A0 =C2=A0 =C2=A0 =C2=A0{=0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0AdvSendAdvert on;=0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0prefix 2001:db8:0:1::/64=0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0{=0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0AdvOnLink on;=0A> =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0AdvAutono= mous on;=0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0};=0A> = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clients=0A> =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{=0A> =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fe80::21f:16f= f:fe06:3aab;=0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0fe80::21d:72ff:fe96:aaff;=0A> =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0};=0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0};= =0A> =0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0This =C2=A0 configuration =C2=A0 would= =C2=A0 =C2=A0only =C2=A0 =C2=A0announce =C2=A0 =C2=A0the =C2=A0 =C2=A0pref= ix =C2=A0 =C2=A0to=0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0fe80::21f:16ff:fe06:3aab = =C2=A0and =C2=A0fe80::21d:72ff:fe96:aaff. =C2=A0 Furthermore,=0A> =C2=A0 = =C2=A0 =C2=A0 =C2=A0all RA requests of other clients are denied.=0A> =0A> = =C2=A0 =C2=A0 =C2=A0 =C2=A0This may come in handy if you want to =C2=A0roll= =C2=A0out =C2=A0IPv6 =C2=A0only =C2=A0partially=0A> =C2=A0 =C2=A0 =C2=A0 = =C2=A0because some clients are broken or untested.=0A> =0A> =0A> =0A>= Regards,=0A> =0A> Mark.=0A> From alexandru.petrescu@gmail.com Wed Mar 27 12:43:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404D321F9259 for ; Wed, 27 Mar 2013 12:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.616 X-Spam-Level: X-Spam-Status: No, score=-9.616 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzOo+XfVnBiI for ; Wed, 27 Mar 2013 12:43:16 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 27C8B21F9256 for ; Wed, 27 Mar 2013 12:43:15 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2RJhFNk015802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 27 Mar 2013 20:43:15 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2RJhEFL002425 for ; Wed, 27 Mar 2013 20:43:15 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2RJh37Z030199 for ; Wed, 27 Mar 2013 20:43:14 +0100 Message-ID: <51534B90.9040102@gmail.com> Date: Wed, 27 Mar 2013 20:42:08 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 19:43:17 -0000 I tend to agree with the status INFORMATIONAL because it is the least conflictual as I read recently. So, number 0 - yes I agree INFORMATIONAL. Also, the BCP makes me think of a large deployment experience, which doesnt seem to be the case here. BCP also makes me think of an old very old deployment about which we could discuss but couldnt make any suggestion for improvement because few care anylonger. For example FTP directory listing is BCP, but IPv6 RFC2460 is not BCP. Alex ---------------------------------------------------------------------- Then, if place is left for discussion, and if disagreements to below dont risk the INFORMATIONAL status as suggested above, here are some other comments. I think it is good to go towards a practice like this: - don't write ULAs like this: fd::1, because it's not an ULA. The ULA must start with fd00: and not fd:, because whereas the leading 0s can be ommitted the subsequent 0s are significant, in this Western- inspired textual address representation system (like 003 dollars is same value as 3 dollars, but 300 dollars is not the same as 3 dollars). - don't write example ULAs like this: fd00::1 because there seems to be only 0s between fd and 1, whereas a real ULA has randomness in that space, to ensure uniqueness. fd00:face:booc::1 is probably a better ULA although a trained eye may notice a surprising coincidence hard to generate randomly. - dont assign fd00::1/128 address on the default Gateway, even though one is used to assign such in IPv4; the reason same as above - lack of randomnes. - if you want to set up a small network which has multiple subnets, and you can't get IPv6 global unicast addresses from an authority or an authoritative sysadmin (prefixed by 001 first three bits), like a Provider Independepent, or Provider Assigned addresses - then use ULAs to configure your small network. - for that small network use ULAs rather than making up some global unicast addresses out of a prefix which was not previously guaranteed unique by the administration. - dont use 2001:db8:: prefix to assign to that small network - it's a Documentation prefix, has sense for humans but not for computers. Rather use ULAs, or global unicast addresses if you can get some. - dont use ULA with NAT - it doesnt work. Alex Le 26/03/2013 12:56, Liubing (Leo) a écrit : > Hi, Dear all > > [Note: You can also raise some topic you consider as important with > the prefix "ULA discussion #", so that the future discussion could > be easily tracked. Thank you.] > > This post is regarding the document should be a "BCP" or > "Informational". Personally, either BCP or Informational is OK for > me. But I'd like to discuss it in the perspective of the document. > > I checked RFC2026 (The Internet Standards Process -- Revision 3), in > section 5, the BCP document is described as "a vehicle by which the > IETF community can define and ratify the community's best current > thinking on a statement of principle or on what is believed to be > the best way to perform some operations or IETF process function." > > So, I believe it is a good goal to publish the ULA draft as a BCP, I > think the position is valuable for the readers. However, some texts > (especially NAT relative) are still controversy that might not be > consensus of representing "the community's best current thinking". > But let's try to find the common view/principle out of the > controversy materials, if not applicable, then it is OK to be > Informational. _______________________________________________ v6ops > mailing list v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From iljitsch@muada.com Wed Mar 27 12:48:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E01121F9041 for ; Wed, 27 Mar 2013 12:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzoB8er95tcw for ; Wed, 27 Mar 2013 12:48:22 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 9C09521F9005 for ; Wed, 27 Mar 2013 12:48:21 -0700 (PDT) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2RJhEi8029784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Mar 2013 20:43:15 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <51533203.5010600@dougbarton.us> Date: Wed, 27 Mar 2013 20:48:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <245C63EB-935D-40F6-9949-028BE99CDE1D@muada.com> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <4FC37E442D05A748896589E468752CAA0A671F49@PWN401EA160.ent.corp.bcbsm.com> <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> <51532AEF.2030702@dougbarton.us> <0FACA054-11D6-41D3-9ADB-0EFC7E583415@muada.com> <51533203.5010600@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 19:48:22 -0000 On 27 mrt 2013, at 18:53, Doug Barton wrote: > No one is saying that it isn't going to take time to sort out the = clients once the default router option is available. But the logical = conclusion from that premise is not, "Don't do it," the logical = conclusion is, "Do it as soon as possible." I don't think anyone is arguing for "do it, but wait half a decade = first". :-) >> If someone really has a special need in this area, it's probably a >> better idea to install a routing daemon on their hosts rather than >> expect ALL hosts connected to the internet to implement something new >> that comes with additional failure modes. > Completely unrealistic. You think it's less realistic to install some software under your own = control on devices under your own control than getting IETF rough = consensus after you couldn't get it for (at least) four years, and then = wait for third parties with no skin in the game to implement it in their = software? > Enterprises have well established policies and procedures about who = manages what bits of data/configuration/network policy/etc. They want to = be able to manage DHCPv6 in a way that fits with their existing = structures, and won't deploy IPv6 at all if they can't. I am extremely skeptical of that argument. It's used for other stuff = that did see the light of day in the past. So show me the evidence that = this is true in this instance, and not just a convenient excuse to delay = IPv6 deployment that was never going to happen anyway. > And what some people around here seem to be missing is that there is = absolutely no motivation for them to do so. In fact, there is little to = no incentive for them to deploy v6 inside an end-user network at all = right now, and there isn't going to be any time in the next 5 years for = sure, and likely for another decade if not longer. IPv4 is a profoundly flawed protocol. But we've used it for 30 years = now. We'll have to use IPv6 for longer than that in all likelihood. So = it's important to refrain from importing those IPv4 flaws in IPv6 as = much as we can. For that reason, when a whole bunch of protocol designers tell you a = specific way to implement a feature you like is a bad way to do it, it = might be useful to listen to them, and perhaps explore different ways to = get that same feature. So far you haven't bothered to address my suggestion of replacing a = proposed DHCPv6 default router option with a DHCPv6 option that lets a = host select the desired default router from the ones available through = RAs.= From Fred.L.Templin@boeing.com Wed Mar 27 12:57:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1A021F913B for ; Wed, 27 Mar 2013 12:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 MzBoNH835Ars for ; Wed, 27 Mar 2013 12:57:48 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id DC8FF21F9133 for ; Wed, 27 Mar 2013 12:57:47 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r2RJvk7P028522 for ; Wed, 27 Mar 2013 12:57:46 -0700 Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r2RJvk7J028517 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 27 Mar 2013 12:57:46 -0700 Received: from XCH-BLV-505.nw.nos.boeing.com (130.247.25.195) by XCH-NWHT-01.nw.nos.boeing.com (130.247.70.222) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 27 Mar 2013 12:57:46 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.214]) by XCH-BLV-505.nw.nos.boeing.com ([169.254.5.234]) with mapi id 14.02.0328.011; Wed, 27 Mar 2013 12:57:46 -0700 From: "Templin, Fred L" To: Mark Smith , v6ops v6ops WG Thread-Topic: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? Thread-Index: AQHOKx8HPG29nlvlC0O/0oFBy98Pvpi5862g Date: Wed, 27 Mar 2013 19:57:45 +0000 Message-ID: <2134F8430051B64F815C691A62D9831803D8DB@XCH-BLV-504.nw.nos.boeing.com> References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1364411510.8596.YahooMailNeo@web142502.mail.bf1.yahoo.com> In-Reply-To: <1364411510.8596.YahooMailNeo@web142502.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 19:57:50 -0000 SGkgTWFyaywNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB2Nm9wcy1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mDQo+IE1hcmsgU21pdGgNCj4gU2VudDogV2VkbmVzZGF5LCBNYXJjaCAyNywgMjAxMyAxMjox MiBQTQ0KPiBUbzogdjZvcHMgdjZvcHMgV0cNCj4gU3ViamVjdDogW3Y2b3BzXSBJVCdTIE1PU1RM WSBBIFNPTFZFRCBQUk9CTEVNIC0gRnc6IEludGVyZXN0IGluIERIQ1B2Ng0KPiBSb3V0ZS9EZWZS b3V0ZXIvU3JjLWJhc2VkUm91dGUgY29uZmlndXJhdGlvbiB0byBDbGllbnQ/DQo+IA0KPiBTaW5j ZSB0aGUgZm9sbG93aW5nIGl0IHNlZW1zIHRvIGhhdmUgYmVlbiBtaXNzZWQsIGFuZCB0aGlzIGRp c2N1c3Npb24gaXMNCj4ganVzdCBidXJuaW5nIHVwIG1vcmUgYmFuZHdpZHRoIGFuZCBwZW9wbGVz JyB0aW1lIChwZXJoYXBzIGZvciB0aGUgNTB0aA0KPiB0aW1lIGluIHRoZSBsYXN0IGRlY2FkZT8p LCBJJ20gcmVwb3N0aW5nIGl0Lg0KPiANCj4gUkFzIGNhbiBiZSBzZWxlY3RpdmVseSB1bmljYXN0 IHRvIGNsaWVudHMsIGFuZCB0aGUgcmFkdmQgSVB2NiBSQQ0KPiBpbXBsZW1lbnRhdGlvbiBwcm92 aWRlcyB0aGF0IG9wdGlvbi4gVGhlIGVtYWlsIGJlbG93IGhhcyB0aGUgbWFudWFsIHBhZ2UNCj4g dGV4dCBhbmQgYW4gZXhhbXBsZS4NCg0KQWx0aG91Z2ggSSBjYW5ub3Qgc2F5IGlmIGl0IHdhcyAq dGhlKiByZWFzb24sIG9uZSBvZiB0aGUgcmVhc29ucw0KZm9yIHRoaXMgb3B0aW9uIHdhcyB0byBh Y2NvbW1vZGF0ZSBJU0FUQVAuIFRoYXQgc2FpZCwgUkZDNDg2MQ0KZG9lcyBwZXJtaXQgdW5pY2Fz dGluZyBvZiBSQXMuDQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20N Cg0KPiBJdCBtYXkgbm90IGJlIHRoZSB3YXkgdGhhdCBESENQdjQgc29sdmVkIHRoaXMgcHJvYmxl bSAod2hpY2ggcGVyaGFwcyBpcyBhDQo+IHN5bXB0b20gb2YgSVB2NCBub3QgaGF2aW5nIGF1dG9j b25maWd1cmF0aW9uIGZyb20gdGhlIG91dHNldCksIGJ1dCBhbGwNCj4gdGhhdCBkb2VzIGlzIG1h a2UgaXQgYSBkaWZmZXJlbnQgd2F5IG9mIHNvbHZpbmcgdGhlIHByb2JsZW0uIFRoZSBESENQdjQN Cj4gbW9kZWwgaXMgbm90IHRoZSBiZSBhbGwgYW5kIGVuZCBhbGwgc29sdXRpb24gdG8gYWxsIG5l dHdvcmsgY29uZmlndXJhdGlvbg0KPiBwcm9ibGVtcy4NCj4gDQo+IE90aGVyIHRoYW4gb3RoZXIg cm91dGVyIGltcGxlbWVudGF0aW9ucyBub3QgcHJvdmlkaW5nIHRoZSBvcHRpb24gdG8gZG8NCj4g dW5pY2FzdCBSQXMgdG8gc2VsZWN0IGNsaWVudHMgKG5vdCBhIHByb2JsZW0gdGhlIElFVEYgY2Fu IHNvbHZlKSwgdGhlIG9ubHkNCj4gZ2FwIEkgY2FuIHNlZSB0aGF0IERIQ1B2NCBmaWxscyB2ZXJz ZXMgdW5pY2FzdCBSQXMgZm9yIGluZmx1ZW5jaW5nDQo+IGNsaWVudCdzIGRlZmF1bHQgcm91dGVy IHNlbGVjdGlvbiBpcyB0aGUgYWJpbGl0eSB0byBoYXZlIHRoZSBtYXBwaW5nIG9mDQo+IGNsaWVu dCB0byByb3V0ZXIgY2VudHJhbGlzZWQgb24gYSBESENQdjQgc2VydmVyIGFuZCB0aGVuIGhhdmlu ZyByb3V0ZXJzDQo+IHVzZSB0aGF0IGluZm9ybWF0aW9uIHZpYSBESENQdjQgZm9yd2FyZGluZy4g U28gd2hhdCBpcyBuZWNlc3NhcnkgZm9yIElQdjYNCj4gaXMgYSBtZXRob2QgdG8gZWl0aGVyIGRp c3RyaWJ1dGUgdGhlIGxpc3Qgb2YgY2xpZW50cyB0byB1bmljYXN0IFJBcyBtYXAgdG8NCj4gdG8g dGhlIHJvdXRlcnMsIG9yIHRvIGhhdmUgdGhlIHJvdXRlciBxdWVyeSBhIGNlbnRyYWxpc2VkIHNl cnZlciB3aGVuIGl0DQo+IHJlY2VpdmVzIGFuIFJTLiBUaGF0IGlzIGEgYmV0dGVyIHNvbHV0aW9u IHRoYW4gZHVwbGljYXRpbmcgZnVuY3Rpb25hbGl0eQ0KPiBmcm9tIFJBcyBpbnRvIERIQ1B2Niwg YXMgaXQgd291bGQgb25seSByZXF1aXJlIGNoYW5nZXMgdG8gcm91dGVyDQo+IGltcGxlbWVudGF0 aW9ucywgcmF0aGVyIHRoYW4gdGhlIGRlcGxveWVkIElQdjYgaW1wbGVtZW50YXRpb25zIGluIGhv c3RzLA0KPiBhbmQgYXZvaWQgdGhlIGluZXZpdGFibGUgaXNzdWVzIGFyb3VuZCB3aGF0IHRvIGRv IHdoZW4gY29uZmxpY3RpbmcgZGVmYXVsdA0KPiByb3V0ZXIgaW5mb3JtYXRpb24gaXMgcmVjZWl2 ZWQgZnJvbSBhbiBSQSB2ZXJzZXMgREhDUHY2Lg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAt LS0tLSBGb3J3YXJkZWQgTWVzc2FnZSAtLS0tLQ0KPiA+IEZyb206IE1hcmsgU21pdGggPG1hcmt6 enpzbWl0aEB5YWhvby5jb20uYXU+DQo+ID4gVG86IElsaml0c2NoIHZhbiBCZWlqbnVtIDxpbGpp dHNjaEBtdWFkYS5jb20+OyBBbGV4YW5kcnUgUGV0cmVzY3UNCj4gPGFsZXhhbmRydS5wZXRyZXNj dUBnbWFpbC5jb20+DQo+ID4gQ2M6ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGlldGYub3JnPg0K PiA+IFNlbnQ6IFdlZG5lc2RheSwgMjcgTWFyY2ggMjAxMyA4OjA1IFBNDQo+ID4gU3ViamVjdDog UmU6IFt2Nm9wc10gSW50ZXJlc3QgaW4gREhDUHY2IFJvdXRlL0RlZlJvdXRlci9TcmMtYmFzZWRS b3V0ZQ0KPiBjb25maWd1cmF0aW9uIHRvIENsaWVudD8NCj4gPg0KPiA+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+PiAgRnJvbTogSWxqaXRzY2ggdmFuIEJlaWpudW0gPGls aml0c2NoQG11YWRhLmNvbT4NCj4gPj4gVG86IEFsZXhhbmRydSBQZXRyZXNjdSA8YWxleGFuZHJ1 LnBldHJlc2N1QGdtYWlsLmNvbT4NCj4gPj4gQ2M6ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGll dGYub3JnPg0KPiA+PiBTZW50OiBXZWRuZXNkYXksIDI3IE1hcmNoIDIwMTMgNjo1NCBQTQ0KPiA+ PiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBJbnRlcmVzdCBpbiBESENQdjYgUm91dGUvRGVmUm91dGVy L1NyYy1iYXNlZFJvdXRlDQo+ID4gY29uZmlndXJhdGlvbiB0byBDbGllbnQ/DQo+ID4+DQo+ID4+ IE9uIDI2IG1ydCAyMDEzLCBhdCAxNzowOSwgQWxleGFuZHJ1IFBldHJlc2N1DQo+ID4gPGFsZXhh bmRydS5wZXRyZXNjdUBnbWFpbC5jb20+IHdyb3RlOg0KPiA+Pg0KPiA+Pj4gIElzIHRoZXJlIGFu IGludGVyZXN0IGluIERIQ1B2NiBSb3V0ZS9EZWZSb3V0ZXIvU3JjLWJhc2VkUm91dGUNCj4gPj4+ ICBjb25maWd1cmF0aW9uIHRvIENsaWVudD8NCj4gPj4NCj4gPj4gVGhlIGJpZyBpc3N1ZSB3aXRo IGhhdmluZyBESENQdjYgZGVsaXZlciBhIGRlZmF1bHQgcm91dGUgaXMgdGhhdCBpdA0KPiBicmVh a3MNCj4gPiB0aGUgZmF0ZSBzaGFyaW5nIHRoYXQgaGF2aW5nIHRoZSBkZWZhdWx0IHJvdXRlciBh ZGRyZXNzIGluIGEgcm91dGVyDQo+ID4gYWR2ZXJ0aXNlbWVudCBmcm9tIHRoZSByb3V0ZXIgaG9s ZGluZyB0aGF0IGFkZHJlc3MgcHJvdmlkZXMuDQo+ID4+DQo+ID4+IEJ1dCBJIGdhdGhlciB0aGVy ZSBhcmUgcGVvcGxlIHdobyB3YW50IHRvIGJlIGFibGUgdG8gbWFrZSBvbmUgZ3JvdXAgb2YNCj4g aG9zdHMNCj4gPiBvbiBhIHN1Ym5ldCB1c2Ugcm91dGVyIEEgYXMgdGhlaXIgZGVmYXVsdCByb3V0 ZXIgYnV0IGFub3RoZXIgZ3JvdXAgb2YNCj4gaG9zdHMNCj4gPiByb3V0ZXIgQiwgb24gdGhhdCBz YW1lIHN1Ym5ldC4NCj4gPj4NCj4gPg0KPiA+IFRoaXMgc2hvdWxkIGFscmVhZHkgcG9zc2libGUg dXNpbmcgUkFzLCB3aXRoIGFuIGV4YW1wbGUgaW1wbGVtZW50YXRpb24NCj4gYmVpbmcgdGhlDQo+ ID4gY2xpZW50cyBzZWN0aW9uIGluIHJhZHZkL3JhZHZkLmNvbmYuIEhlcmUgaXMgdGhlIG1hbnVh bCBwYWdlIGhlbHAgdGV4dDoNCj4gPg0KPiA+IMKgwqAgwqAgwqAgQnkgwqBkZWZhdWx0IMKgcmFk dmQgd2lsbCBzZW5kIHJvdXRlIGFkdmVydGlzZW1lbnRzIHNvIHRoYXQgZXZlcnkNCj4gbm9kZSBv bg0KPiA+IMKgIMKgIMKgIMKgdGhlIGxpbmsgY2FuIHVzZSB0aGVtLiDCoFRoZSBsaXN0IG9mIGNs aWVudHMgKElQdjYgYWRkcmVzcykgdG8NCj4gYWR2ZXJ0aXNlDQo+ID4gwqAgwqAgwqAgwqB0bywg wqBhbmQgwqBhY2NlcHQgwqByb3V0ZSBzb2xpY2l0YXRpb25zIGZyb20gY2FuIGJlIGNvbmZpZ3Vy ZWQuIMKgSWYNCj4gZG9uZSwNCj4gPiDCoCDCoCDCoCDCoHJhZHZkIGRvZXMgbm90IHNlbmQgc2Vu ZCBtZXNzYWdlcyB0byB0aGUgbXVsdGljYXN0IGFkZHJlc3NlcyBidXQNCj4gdG8gdGhlDQo+ID4g wqAgwqAgwqAgwqBjb25maWd1cmVkIMKgdW5pY2FzdCBhZGRyZXNzZXMgb25seS4gwqBTb2xpY2l0 YXRpb25zIGZyb20gb3RoZXINCj4gYWRkcmVzc2VzDQo+ID4gwqAgwqAgwqAgwqBhcmUgcmVmdXNl ZC4gwqBUaGlzIGlzIHNpbWlsYXIgdG8gVW5pY2FzdE9ubHkgYnV0IGluY2x1ZGVzDQo+IHBlcmlv ZGljIG1lc+KAkA0KPiA+IMKgIMKgIMKgIMKgc2FnZXMgwqBhbmQgwqBpbmNvbWluZyBjbGllbnQg YWNjZXNzIGNvbmZpZ3VyYXRpb24uIMKgU2VlIGV4YW1wbGVzDQo+IHNlY3Rpb24NCj4gPiDCoCDC oCDCoCDCoGZvciBhIHVzZSBjYXNlIG9mIHRoaXMuDQo+ID4NCj4gPiDCoCDCoCDCoCDCoFRoZSBk ZWZpbml0aW9ucyBhcmUgb2YgdGhlIGZvcm06DQo+ID4NCj4gPiDCoCDCoCDCoCDCoGNsaWVudHMg ew0KPiA+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbGlzdCBvZiBJUHY2IGFkZHJlc3Nlcw0KPiA+ IMKgIMKgIMKgIMKgfTsNCj4gPg0KPiA+DQo+ID4gRnVydGhlciBpbnRvIHRoZSBtYW51YWwgcGFn ZSBpcyBhbiBleGFtcGxlIGNvbmZpZ3VyYXRpb246DQo+ID4NCj4gPiDCoCDCoCDCoCDCoGludGVy ZmFjZSBldGgwDQo+ID4gwqAgwqAgwqAgwqB7DQo+ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBB ZHZTZW5kQWR2ZXJ0IG9uOw0KPiA+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcHJlZml4IDIwMDE6 ZGI4OjA6MTo6LzY0DQo+ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB7DQo+ID4gwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBBZHZPbkxpbmsgb247DQo+ID4gwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBBZHZBdXRvbm9tb3VzIG9uOw0KPiA+IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgfTsNCj4gPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNsaWVudHMNCj4gPiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoHsNCj4gPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoGZlODA6OjIxZjoxNmZmOmZlMDY6M2FhYjsNCj4gPiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoGZlODA6OjIxZDo3MmZmOmZlOTY6YWFmZjsNCj4gPiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoH07DQo+ID4gwqAgwqAgwqAgwqB9Ow0KPiA+DQo+ID4gwqAgwqAgwqAgwqBU aGlzIMKgIGNvbmZpZ3VyYXRpb24gwqAgd291bGQgwqAgwqBvbmx5IMKgIMKgYW5ub3VuY2UgwqAg wqB0aGUgwqAgwqBwcmVmaXgNCj4gwqAgwqB0bw0KPiA+IMKgIMKgIMKgIMKgZmU4MDo6MjFmOjE2 ZmY6ZmUwNjozYWFiIMKgYW5kIMKgZmU4MDo6MjFkOjcyZmY6ZmU5NjphYWZmLg0KPiBGdXJ0aGVy bW9yZSwNCj4gPiDCoCDCoCDCoCDCoGFsbCBSQSByZXF1ZXN0cyBvZiBvdGhlciBjbGllbnRzIGFy ZSBkZW5pZWQuDQo+ID4NCj4gPiDCoCDCoCDCoCDCoFRoaXMgbWF5IGNvbWUgaW4gaGFuZHkgaWYg eW91IHdhbnQgdG8gwqByb2xsIMKgb3V0IMKgSVB2NiDCoG9ubHkNCj4gwqBwYXJ0aWFsbHkNCj4g PiDCoCDCoCDCoCDCoGJlY2F1c2Ugc29tZSBjbGllbnRzIGFyZSBicm9rZW4gb3IgdW50ZXN0ZWQu DQo+ID4NCj4gPiA8c25pcD4NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4NCj4gPiBNYXJrLg0KPiA+ DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2 b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= From lorenzo@google.com Wed Mar 27 14:34:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DD221F8F53 for ; Wed, 27 Mar 2013 14:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.898 X-Spam-Level: X-Spam-Status: No, score=-101.898 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPOXesOxmsGR for ; Wed, 27 Mar 2013 14:34:26 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD3421F8F46 for ; Wed, 27 Mar 2013 14:34:26 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id un3so8575857obb.24 for ; Wed, 27 Mar 2013 14:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=PRj+mAuymDrKbPH42d4hKQnD+MiGZgdnAV6WdJmvO8M=; b=KqLdOl/+kRh/bhLniKVlAybtDeT1Zpn9CFZzTx1X4znRfv0Tip0oon99wVktoOILeA yPlLDenSn3/wfipZzHV+i51OeXn76erF4m09PDvUj9e+jwgQw2a4gwB3VabH9IP9n3c6 Dr+kPWWXoiJskuGl1C5GG1VQS6D92rtRCc+9eVuUWuIkq7EEtlgMXPwvPo8FJgPsaqhO rw3AKccgzryYM0pLf1aXQXqwUt6IF+neeoyjejtggqEpljzVYGrw7XupjaaBDPmIJmX5 MZQS8Fg1/EVnLm39bM8wp2GF8BWKzT4/50enptpqP1hSgTz1/PZdphOo1Llk+Wwu9Pto RHDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=PRj+mAuymDrKbPH42d4hKQnD+MiGZgdnAV6WdJmvO8M=; b=FDmaaqJYkFq163KTjprj21UtZtN4akroUBJPRT/kKUiYCEPGdCeuVDNdWPqvDluMOo y+EJL4Xs2Gtwct+3Qds5m7SuOwbiZs5vLXWxqTLVHVtNV8R0pjBrTxUqrLAFh5EWWJ75 DaSXS9Dv/s2qAwjbCJdEZgvsLgIOzwv29I1dp87Pg3YjQmhHW/iPd4UGPMTkr7TQm4mv aZMe5X8cKa9g5QXTVyVvKmMjr1l3dvsFnw98jzaFACiacdYjXXlQj21kowfwq9HHaSRb MJ3ECAfoP0guXzNbDfVNw4yOJRtXo0u7xi78LXz3qJATVqgA92PddojQ9QhKT2Pd5hdF 452A== X-Received: by 10.182.34.131 with SMTP id z3mr4433191obi.81.1364420065448; Wed, 27 Mar 2013 14:34:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Wed, 27 Mar 2013 14:34:04 -0700 (PDT) In-Reply-To: References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> From: Lorenzo Colitti Date: Thu, 28 Mar 2013 06:34:04 +0900 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=001a11c2a304537b0304d8eecde0 X-Gm-Message-State: ALoCoQkO5p10EkpDIkg+g9ZPNxWLvo+che/DrErjOA4TMEcnXr7eg00ZCRXT5aQPcg67HJXgCvnz1LYCWPoZFM/Vwc8fLlBlphCBCzZVM+OFq0XKTP8LW37HoskWgfVEqTp0zRTfEBwAtnGCR90x2BMkcTm6aAHg+Knc8Tt6SFJ2ayR5Rs46ykpDMQ9V3O/amF0TKjwBRyMt Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 21:34:26 -0000 --001a11c2a304537b0304d8eecde0 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 27, 2013 at 9:25 AM, Randy Bush wrote: > you have not figured it out, have you? my way or the highway has led to > the nat4444 highway. hope you like living in hell. i don't and i don't > thank you for it. > Well, but I don't really think that's true. What I've seen, over and over again, is that teams/companies/enterprises/... say "we can't deploy IPv6 because of X", but then, when X arrives, the very same people move on to saying "we can't deploy IPv6 because of Y", where Y != X. So X is not the real reason, it's just a red herring. What they are actually saying is "we see no need to deploy IPv6 at the moment". The IETF cannot create a business need to deploy IPv6. Perhaps it can lower the barriers to adoption, but I'm skeptical that lowering this particular barrier would make much difference at all. On the other hand, defining a mechanism for distributing routes whose semantics are much weaker than the one we have will lower the robustness of IPv6 and increase operational costs (for example, by forcing us to run VRRP forever because there is no fate sharing). --001a11c2a304537b0304d8eecde0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 27, 2013 at 9:25 AM, Randy Bush <randy@psg.com> wrote:
you have not figured = it out, have you? =A0my way or the highway has led to
the nat4444 highway. =A0hope you like living in hell. =A0i don't and i = don't
thank you for it.

Well, but I don= 't really think that's true.

W= hat I've seen, over and over again, is that teams/companies/enterprises= /... say "we can't deploy IPv6 because of X", but then, when = X arrives, the very same people move on to saying "we can't deploy= IPv6 because of Y", where Y !=3D X. So X is not the real reason, it&#= 39;s just a red herring. What they are actually saying is "we see no n= eed to deploy IPv6 at the moment".

The IETF cannot create a business need to d= eploy IPv6. Perhaps it can lower the barriers to adoption, but I'm skep= tical that lowering this particular barrier would make much difference at a= ll. On the other hand, defining a mechanism for distributing routes whose s= emantics are much weaker than the one we have will lower the robustness of = IPv6 and increase operational costs (for example, by forcing us to run VRRP= forever because there is no fate sharing).
--001a11c2a304537b0304d8eecde0-- From tperrine@scea.com Wed Mar 27 15:40:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0DE21F87F5 for ; Wed, 27 Mar 2013 15:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UGKN0XazsWl for ; Wed, 27 Mar 2013 15:40:02 -0700 (PDT) Received: from ironport02a.scea.com (ironport02a.scea.com [160.33.44.43]) by ietfa.amsl.com (Postfix) with ESMTP id EEBDF21F8804 for ; Wed, 27 Mar 2013 15:40:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,361,1363158000"; d="scan'208";a="24213791" Received: from inbetweener01.scea.com ([160.33.45.195]) by ironport02a.scea.com with ESMTP; 27 Mar 2013 15:40:01 -0700 Received: from sd-tperrine-mpl.pd.scea.com (unknown [172.31.30.191]) by inbetweener01.scea.com (Postfix) with ESMTP id 8BC23F0531 for ; Wed, 27 Mar 2013 15:40:01 -0700 (PDT) Message-ID: <51537541.5050806@scea.com> Date: Wed, 27 Mar 2013 15:40:01 -0700 From: Tom Perrine User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: IETF v6ops list References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 22:40:02 -0000 On 3/27/13 2:34 PM, Lorenzo Colitti wrote: > On Wed, Mar 27, 2013 at 9:25 AM, Randy Bush > wrote: > > you have not figured it out, have you? my way or the highway has led to > the nat4444 highway. hope you like living in hell. i don't and i don't > thank you for it. > > > Well, but I don't really think that's true. > > What I've seen, over and over again, is that teams/companies/enterprises/... say "we can't deploy IPv6 because of X", > but then, when X arrives, the very same people move on to saying "we can't deploy IPv6 because of Y", where Y != X. So X > is not the real reason, it's just a red herring. What they are actually saying is "we see no need to deploy IPv6 at the > moment". SNIP I'm seeing the possibility of no longer having to coordinate RFC 1918 space across business units and partners as a compelling factor for adoption of IPv6. Consider a large multinational that has had mostly independent *internal* networks (in 1918 space) for the past 10-20 years, as they merge those together. Throw in ongoing mergers and acquisitions and you can get a 10.0.0.0/8 and NAT nightmare from all the cruft that can accumulate over that period of time. Because, of course, renumbering is expensive and contributes nothing to the bottom line. And network teams have gotten pretty good at gluing nets together with NATs. Add transient business partners that also used 1918 for their internal nets, that you now need to see inside of, or they need to see inside yours. It can get..... interesting. I saw a business case from one of those multinationals in November. They cut the time to merge in a newly acquired company's network from 12-24 months to less than 3 months by agreeing to only connect over IPv6 and doing 6/4 translation at the boundaries as needed. I think they also rolled some of the IPv6 transition costs for both companies (and the 6/4 translation project) in as part of the M&A costs :-) so they got an infrastructure upgrade and a new capability that they can reuse, that IT didn't have to pay for. Finally, a carrot? From owen@delong.com Wed Mar 27 16:11:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4302321F8FD4 for ; Wed, 27 Mar 2013 16:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 m1ICqYivalbV for ; Wed, 27 Mar 2013 16:11:55 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE2221F8FC6 for ; Wed, 27 Mar 2013 16:11:39 -0700 (PDT) Received: from [10.255.252.140] ([207.102.63.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2RNAleH029991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 16:10:48 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2RNAleH029991 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364425849; bh=vOcHTX8HAr9c1Zsk4hn49eUx1MY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qEOd83qxGh+bppK8qyRNAVB/BPlm5Eae7+XhbjVuj0hXLVvF+933thzrH/VIHJFzk ++ij70McA8j65kTASVk3XrzmIN1aI7Tjmx+Y+eyLqnZpRmvU8Utk9c+u3M+Vj7iAnv x1NgkhZqgT8wiOxoyk4a1TGV14RaY+TplenrwhtQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: <0FACA054-11D6-41D3-9ADB-0EFC7E583415@muada.com> Date: Wed, 27 Mar 2013 16:10:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <4FC37E442D05A748896589E468752CAA0A671F49@PWN401EA160.ent.corp.bcbsm.com> <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> <51532AEF.2030702@dougbarton.us> <0FACA054-11D6-41D3-9ADB-0EFC7E583415@muada.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 27 Mar 2013 16:10:49 -0700 (PDT) Cc: v6ops@ietf.org Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 23:11:56 -0000 On Mar 27, 2013, at 10:37 AM, Iljitsch van Beijnum = wrote: > On 27 mrt 2013, at 18:22, Doug Barton wrote: >=20 >>> If the IETF standardizes a new, highly sought after DHCPv6 option, = then that still doesn't buy anyone anything, because it needs to be = implemented in a whole bunch of operating systems first. That takes many = years. >=20 >> So just like every other IETF protocol, the effect of the change = won't be instantaneous. That doesn't mean we shouldn't do the right = thing now, so that at some point down the road it can be used. >=20 > In general that's true, but with configuration stuff it's more = complicated. See the situation where some OSes (Windows as of Vista) had = DHCPv6 support but others (MacOS 10.6) didn't. That was a very = unpleasant situation, because either you had to forego using DHCPv6 = altogether, or you had to make a configuration that would work for both = types (and probably suboptimally for at least one). But it got resolved because Apple succumbed to the pressure to implement = DHCPv6. Frankly, Apple would have done that a lot earlier if it hadn't been for = all the IETF BS from people trying to block DHCPv6 in the first place. > If someone really has a special need in this area, it's probably a = better idea to install a routing daemon on their hosts rather than = expect ALL hosts connected to the internet to implement something new = that comes with additional failure modes. Not so much, no. These aren't special needs. This is a relatively common = set of circumstances in much of the currently deployed network in the = real world. >=20 >> If this particular change had been done 12 years ago like some of us = were asking the problem would have been solved a long time ago. >=20 > Maybe after 5 or 10 years it would have been a good idea to start = looking at different options that provide the same benefits but are less = contentious. See my suggestion at the end of my previous message. Maybe it would be good to stop standing in the way of something that has = shown strong demand for so many years instead of preserving the = contentiousness. Owen From nalini.elkins@insidethestack.com Wed Mar 27 16:15:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C4021F8EB4 for ; Wed, 27 Mar 2013 16:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] 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 stmSE+nv0JZu for ; Wed, 27 Mar 2013 16:15:36 -0700 (PDT) Received: from nm21.access.bullet.mail.mud.yahoo.com (nm21.access.bullet.mail.mud.yahoo.com [66.94.237.222]) by ietfa.amsl.com (Postfix) with ESMTP id 18E6121F8EAF for ; Wed, 27 Mar 2013 16:15:36 -0700 (PDT) Received: from [66.94.237.199] by nm21.access.bullet.mail.mud.yahoo.com with NNFMP; 27 Mar 2013 23:15:35 -0000 Received: from [66.94.237.112] by tm10.access.bullet.mail.mud.yahoo.com with NNFMP; 27 Mar 2013 23:15:35 -0000 Received: from [127.0.0.1] by omp1017.access.mail.mud.yahoo.com with NNFMP; 27 Mar 2013 23:15:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 766131.48112.bm@omp1017.access.mail.mud.yahoo.com Received: (qmail 64668 invoked by uid 60001); 27 Mar 2013 23:15:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1364426135; bh=+P4nNxBpZmA8+mj3fAcZZWjiB+pCW1uarBW2/tNP4Rw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=BpneTmcU6oU8hO4HnwGVuFwR9IAuEqaNuGAo5Tc4gQ7jWDrbpEwSwavW1+HTIoDD9bxOlzP+/p3HcSUIT+bIpawRFX3N0U33DXKBUFHT2fx3YR0qw0kjmX4OnTFZNmukrI+zepAQh5UJPpMJA7FGlBdZWEJ2Ba0hCOqdpIkW+AA= X-YMail-OSG: FWZceckVM1kgMTdWXx0bPiWdqX4I7VuzEQrTpJGbQ6lFuAM 7R7ldmtcwM63K2xa04O8_ekMaZiBiBLYEGEsmX9X1cvzt4biBAPHHNhV1Mhl mYbLV3yo74tN3xJYV9OBIajZLOEny_fHkDfLd4KdveulTYIr0nrn2nv06H2y iuS6OcuKcT1pokp8jNkE7quGVFbkgV26xH35CMczk72DJ1KkiVTlB0KskbOO z7tyC6.lcXZF3wL_fB06DEiurAV8bsfDPuyqXvS5J3uHcfZp8xa1tXufPwTM VF86Htns6LMUZJMMp.NEw7TZ3F9G.BjxixkvH7BHZKuoK0whUE.ifSoXriBY WfivLMQWLSftt16JGyS7qS4KzMuEaSLOAI9Q8CMQh4HobGRjFAI.fZIe8cYL yfyhK3S8snw2FAcs.xIDuSjqYKSXZhpaxDWRUtx0FLCOjzQB9BSCNL.iU39k tAu6aN2BHuvKE0fXPX7Vn6OGwsaHWiFYyoYvaup7aZO1BZtuNHufCds8oRQP iELbSS_lZHWJq4caIxWZJgw.hFq4ydgsp0b1dsLXoXdO.gQfCrM1vb5vFHUx o1LGu_LSOUyMXTab7CaGVkXk_nMfl9G5N5_pEHh_EcwNKilR4BlSq81cvvIG XiJvAA5h00PvhNrPe3.59 Received: from [24.130.37.147] by web2802.biz.mail.ne1.yahoo.com via HTTP; Wed, 27 Mar 2013 16:15:35 PDT X-Rocket-MIMEInfo: 002.001, VmVyeSBpbnRlcmVzdGluZyEKwqAKVGhhbmtzLAoKCk5hbGluaSBFbGtpbnMKSW5zaWRlIFByb2R1Y3RzLCBJbmMuCig4MzEpIDY1OS04MzYwCnd3dy5pbnNpZGV0aGVzdGFjay5jb20KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206IFRvbSBQZXJyaW5lIDx0cGVycmluZUBzY2VhLmNvbT4KVG86IElFVEYgdjZvcHMgbGlzdCA8djZvcHNAaWV0Zi5vcmc.IApTZW50OiBXZWRuZXNkYXksIE1hcmNoIDI3LCAyMDEzIDM6NDAgUE0KU3ViamVjdDogUmU6IFt2Nm9wc10gSW50ZXJlc3QgaW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.139.530 References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <51537541.5050806@scea.com> Message-ID: <1364426135.64362.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> Date: Wed, 27 Mar 2013 16:15:35 -0700 (PDT) From: Nalini Elkins To: Tom Perrine , IETF v6ops list In-Reply-To: <51537541.5050806@scea.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-153701192-1417290576-1364426135=:64362" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 23:15:37 -0000 ---153701192-1417290576-1364426135=:64362 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Very interesting!=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Products, = Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A_________________= _______________=0A From: Tom Perrine =0ATo: IETF v6ops l= ist =0ASent: Wednesday, March 27, 2013 3:40 PM=0ASubject: = Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration= to Client?=0A =0AOn 3/27/13 2:34 PM, Lorenzo Colitti wrote:=0A> On Wed, Ma= r 27, 2013 at 9:25 AM, Randy Bush > wr= ote:=0A> =0A>=A0 =A0 you have not figured it out, have you?=A0 my way or t= he highway has led to=0A>=A0 =A0 the nat4444 highway.=A0 hope you like liv= ing in hell.=A0 i don't and i don't=0A>=A0 =A0 thank you for it.=0A> =0A> = =0A> Well, but I don't really think that's true.=0A> =0A> What I've seen, o= ver and over again, is that teams/companies/enterprises/... say "we can't d= eploy IPv6 because of X",=0A> but then, when X arrives, the very same peopl= e move on to saying "we can't deploy IPv6 because of Y", where Y !=3D X. So= X=0A> is not the real reason, it's just a red herring. What they are actua= lly saying is "we see no need to deploy IPv6 at the=0A> moment".=0A=0ASNIP= =0A=0AI'm seeing the possibility of no longer having to coordinate RFC 1918= space across business units and partners as a compelling factor for adopti= on of IPv6.=0A=0AConsider a large multinational that has had mostly indepen= dent *internal* networks (in 1918 space) for the past 10-20 years, as they = merge those together.=A0 Throw in ongoing mergers and acquisitions and you = can get a 10.0.0.0/8 and NAT nightmare from all the cruft that can accumula= te over that period of time. Because, of course, renumbering is expensive a= nd contributes nothing to the bottom line.=A0 And network teams have gotten= pretty good at gluing nets together with NATs. Add transient business part= ners that also used 1918 for their internal nets, that you now need to see = inside of, or they need to see inside yours.=0A=0AIt can get..... interesti= ng.=0A=0AI saw a business case from one of those multinationals in November= . They cut the time to merge in a newly acquired company's network from 12-= 24 months to less than 3 months by agreeing to only connect over IPv6 and d= oing 6/4 translation at the boundaries as needed.=0A=0AI think they also ro= lled some of the IPv6 transition costs for both companies (and the 6/4 tran= slation project) in as part of the M&A costs :-) so they got an infrastruct= ure upgrade and a new capability that they can reuse, that IT didn't have t= o pay for.=0A=0AFinally, a carrot?=0A=0A___________________________________= ____________=0Av6ops mailing list=0Av6ops@ietf.org=0Ahttps://www.ietf.org/m= ailman/listinfo/v6ops ---153701192-1417290576-1364426135=:64362 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Very interesting!
 
Thanks,

Nalini = Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com=

From: T= om Perrine <tperrine@scea.com>
To: IETF v6ops list <v6ops@ietf.org>
Sent: Wednesday, March 27, 2013 3:40 P= M
Subject: Re: [v6ops]= Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client?=

=0AOn 3/27/13 2:34 PM, Lorenzo Colitti wrote:
> On Wed, M= ar 27, 2013 at 9:25 AM, Randy Bush <randy@psg.com <mailto:randy@psg.com>>= wrote:
>
>    you have not figured it out, have yo= u?  my way or the highway has led to
>    the nat4444= highway.  hope you like living in hell.  i don't and i don't
= >    thank you for it.
>
>
> Well, but I = don't really think that's true.
>
> What I've seen, over and o= ver again, is that teams/companies/enterprises/... say "we can't deploy IPv= 6 because of X",
> but then, when X arrives, the very same people mov= e on to saying "we can't deploy IPv6 because of Y", where Y !=3D X. So X> is not the real reason, it's just a red herring. What they are actual= ly saying is "we see no need to deploy IPv6 at the
> moment".

SNIP

I'm = seeing the possibility of no longer having to coordinate RFC 1918 space acr= oss business units and partners as a compelling factor for adoption of IPv6= .

Consider a large multinational that has had mostly independent *in= ternal* networks (in 1918 space) for the past 10-20 years, as they merge th= ose together.  Throw in ongoing mergers and acquisitions and you can g= et a 10.0.0.0/8 and NAT nightmare from all the cruft that can accumulate ov= er that period of time. Because, of course, renumbering is expensive and co= ntributes nothing to the bottom line.  And network teams have gotten p= retty good at gluing nets together with NATs. Add transient business partne= rs that also used 1918 for their internal nets, that you now need to see in= side of, or they need to see inside yours.

It can get..... interesti= ng.

I saw a business case from one of those multinationals in November. They cut the time to merge in a newly acquired company's network= from 12-24 months to less than 3 months by agreeing to only connect over I= Pv6 and doing 6/4 translation at the boundaries as needed.

I think t= hey also rolled some of the IPv6 transition costs for both companies (and t= he 6/4 translation project) in as part of the M&A costs :-) so they got= an infrastructure upgrade and a new capability that they can reuse, that I= T didn't have to pay for.

Finally, a carrot?

________________= _______________________________
v6ops mailing list
v6ops@ietf.org
http= s://www.ietf.org/mailman/listinfo/v6ops


---153701192-1417290576-1364426135=:64362-- From owen@delong.com Wed Mar 27 16:26:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1267721F85C6 for ; Wed, 27 Mar 2013 16:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 YNUQ08DcZ7Pq for ; Wed, 27 Mar 2013 16:26:13 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D0BF421F85F5 for ; Wed, 27 Mar 2013 16:26:13 -0700 (PDT) Received: from [10.255.252.140] ([207.102.63.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2RNMdFF030333 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 16:22:40 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2RNMdFF030333 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364426561; bh=3udlzZQ5q4lWrBYooxwqD70O6ZI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=GshJjl4zfrHryPBEnkS9v1oeIVEpFOfe5jMf9fi/mGVMMU6gZcxY4UDWn8nNRyVmb BGZQp1y6wQNQpIHetBZ/jsDWFRTHN098dr+5v9oFRicsZDrJqhdIMNZZfvk1Fz2n25 9eRf0fPPjTnEk49V2s8Dn9v5Ck50jsj+uFyZwQw0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: <245C63EB-935D-40F6-9949-028BE99CDE1D@muada.com> Date: Wed, 27 Mar 2013 16:22:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <4FC37E442D05A748896589E468752CAA0A671F49@PWN401EA160.ent.corp.bcbsm.com> <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> <51532AEF.2030702@dougbarton.us> <0FACA054-11D6-41D3-9ADB-0EFC7E583415@muada.com> <51533203.5010600@dougbarton.us> <245C63EB-935D-40F6-9949-028BE99CDE1D@muada.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 27 Mar 2013 16:22:41 -0700 (PDT) Cc: v6ops@ietf.org Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 23:26:15 -0000 On Mar 27, 2013, at 12:48 PM, Iljitsch van Beijnum = wrote: > On 27 mrt 2013, at 18:53, Doug Barton wrote: >=20 >> No one is saying that it isn't going to take time to sort out the = clients once the default router option is available. But the logical = conclusion from that premise is not, "Don't do it," the logical = conclusion is, "Do it as soon as possible." >=20 > I don't think anyone is arguing for "do it, but wait half a decade = first". >=20 > :-) >=20 No, but your consistent FUD every time this comes up has managed to = delay it 12 years and counting. It's going to get done. The question is whether it gets done within the = IETF or without. >>> If someone really has a special need in this area, it's probably a >>> better idea to install a routing daemon on their hosts rather than >>> expect ALL hosts connected to the internet to implement something = new >>> that comes with additional failure modes. >=20 >> Completely unrealistic. >=20 > You think it's less realistic to install some software under your own = control on devices under your own control than getting IETF rough = consensus after you couldn't get it for (at least) four years, and then = wait for third parties with no skin in the game to implement it in their = software? >=20 There's a difference now. The operator community is starting to pay more = attention. IETF consensus would be nice, but the feature will most = likely get implemented with or without IETF consensus at this point. = IETF certainly could accelerate the process and improve it by finding = consensus on the best way to implement the feature and documenting that. >> Enterprises have well established policies and procedures about who = manages what bits of data/configuration/network policy/etc. They want to = be able to manage DHCPv6 in a way that fits with their existing = structures, and won't deploy IPv6 at all if they can't. >=20 > I am extremely skeptical of that argument. It's used for other stuff = that did see the light of day in the past. So show me the evidence that = this is true in this instance, and not just a convenient excuse to delay = IPv6 deployment that was never going to happen anyway. What evidence would you like? I know there are definitely organizations where the IT department will = strongly oppose IPv6 until such time as they can gain proper = administrative controls over the clients. To their perspective, this = includes controlling the selection of gateways. WIll implementing this option instantaneously increase IPv6 uptake? No, = of course it won't. Will failing to do so continue to delay IPv6 uptake? You bet it will. If you don't think that the number of people saying so on this list is = evidence of this fact, then I'm not sure what form of evidence you are = looking for. Your claims that IPv6 PI has not lead to greater IPv6 adoption by multi = homed end-users is also specious. There are, in fact, many end-user = organizations that have made use of the PI IPv6 policy. >=20 >> And what some people around here seem to be missing is that there is = absolutely no motivation for them to do so. In fact, there is little to = no incentive for them to deploy v6 inside an end-user network at all = right now, and there isn't going to be any time in the next 5 years for = sure, and likely for another decade if not longer. >=20 > IPv4 is a profoundly flawed protocol. But we've used it for 30 years = now. We'll have to use IPv6 for longer than that in all likelihood. So = it's important to refrain from importing those IPv4 flaws in IPv6 as = much as we can. >=20 Allowing operators to specify routing information in DHCP isn't = importing a flaw. It's providing a feature. I understand that you don't = like eliminating fate sharing. Many operators want very badly to = eliminate fate sharing for a variety of reasons. You run your network = your way and let them run their network(s) their way. Unlike NAT or NPT, = adding this option to DHCPv6 would not be harmful to anyone who doesn't = use it. As such, your arguments against it do not really hold water in = my book. > For that reason, when a whole bunch of protocol designers tell you a = specific way to implement a feature you like is a bad way to do it, it = might be useful to listen to them, and perhaps explore different ways to = get that same feature. When a whole bunch of operators tell you that they don't agree, it might = be good for protocol designers to consider what harm is actually done by = implementing what is requested. When they realize that it is harmless, = perhaps it is better to just implement it and move on rather than have = the good aspects of what you have designed be tossed aside because of = the inability to compromise over the religion about one particular = feature. > So far you haven't bothered to address my suggestion of replacing a = proposed DHCPv6 default router option with a DHCPv6 option that lets a = host select the desired default router from the ones available through = RAs. 1. It doesn't address the entire problem set. 2. You've now added a level of complexity (how is the DHCP server = supposed to know what the available choices are?) 3. It offers no advantages over just providing a static routing option. 4. It addresses only the default router case and not the more general = routing information case. Owen From owen@delong.com Wed Mar 27 16:26:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DCD21F8ECA for ; Wed, 27 Mar 2013 16:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zn8GWIa7M9nt for ; Wed, 27 Mar 2013 16:26:29 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 05A8A21F8EBD for ; Wed, 27 Mar 2013 16:26:27 -0700 (PDT) Received: from [10.255.252.140] ([207.102.63.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2RNPndt030373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 16:25:50 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2RNPndt030373 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364426751; bh=6Zj/tGoOMZQMTGwAJgahaK3GSBs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=3gpbArZWVK5mOubNwmIMMCdJ4ozQs1NeCximgZWTK8BWojUX1V+tUONQu1krx1fpL ztdiQ4vzUMRPwW7SqcYfCZVOtfMv5Uagl2aFbPGhEo0+4t4wIerQPjaZ/x4NXnq7GV lfTJpWCAwwQ2NvOk3Zg8cMXAhp2pyS3YW172zfvE= Content-Type: multipart/alternative; boundary="Apple-Mail=_7C48D890-678B-4D39-999B-E45F0612B608" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: Date: Wed, 27 Mar 2013 16:25:49 -0700 Message-Id: <6E974F14-4902-4345-9B09-5E06BE0D2AE5@delong.com> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 27 Mar 2013 16:25:51 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 23:26:30 -0000 --Apple-Mail=_7C48D890-678B-4D39-999B-E45F0612B608 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Mar 27, 2013, at 2:34 PM, Lorenzo Colitti wrote: > On Wed, Mar 27, 2013 at 9:25 AM, Randy Bush wrote: > you have not figured it out, have you? my way or the highway has led = to > the nat4444 highway. hope you like living in hell. i don't and i = don't > thank you for it. >=20 > Well, but I don't really think that's true. >=20 > What I've seen, over and over again, is that = teams/companies/enterprises/... say "we can't deploy IPv6 because of X", = but then, when X arrives, the very same people move on to saying "we = can't deploy IPv6 because of Y", where Y !=3D X. So X is not the real = reason, it's just a red herring. What they are actually saying is "we = see no need to deploy IPv6 at the moment". >=20 Lorenzo, this simply isn't always true. It may be that they can't deploy IPv6 because of A, B, C, D, E, F, G, H, = X, Y, and Z. It may be that they tell you about X. When you eliminate X, they tell = you about Y. Eventually, they run out of reasons. Just because they don't tell you all of the reasons at once does not = mean that there are not multiple reasons. There are red herrings out there, but this really isn't one of them. > The IETF cannot create a business need to deploy IPv6. Perhaps it can = lower the barriers to adoption, but I'm skeptical that lowering this = particular barrier would make much difference at all. On the other hand, = defining a mechanism for distributing routes whose semantics are much = weaker than the one we have will lower the robustness of IPv6 and = increase operational costs (for example, by forcing us to run VRRP = forever because there is no fate sharing). Lowering this particular barrier will certainly make IPv6 an easier = concept for a number of enterprises. Will having it instantaneously increase IPv6 adoption in the enterprise? = Probably not. Will failing to deploy it continue to impede IPv6 deployment in the = enterprise? You bet. Owen --Apple-Mail=_7C48D890-678B-4D39-999B-E45F0612B608 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 lorenzo@google.com> = wrote:

On Wed, Mar 27, 2013 at 9:25 AM, Randy = Bush <randy@psg.com> wrote:
you have not = figured it out, have you?  my way or the highway has led = to
the nat4444 highway.  hope you like living in hell.  i don't = and i don't
thank you for it.

Well, = but I don't really think that's true.

What I've seen, over and over again, is that = teams/companies/enterprises/... say "we can't deploy IPv6 because of X", = but then, when X arrives, the very same people move on to saying "we = can't deploy IPv6 because of Y", where Y !=3D X. So X is not the real = reason, it's just a red herring. What they are actually saying is "we = see no need to deploy IPv6 at the moment".


Lorenzo= , this simply isn't always true.

It may be that = they can't deploy IPv6 because of A, B, C, D, E, F, G, H, X, Y, and = Z.

It may be that they tell you about X. When = you eliminate X, they tell you about = Y.

Eventually, they run out of = reasons.

Just because they don't tell you all = of the reasons at once does not mean that there are not multiple = reasons.

There are red herrings out there, but = this really isn't one of them.

The IETF cannot create a business = need to deploy IPv6. Perhaps it can lower the barriers to adoption, but = I'm skeptical that lowering this particular barrier would make much = difference at all. On the other hand, defining a mechanism for = distributing routes whose semantics are much weaker than the one we have = will lower the robustness of IPv6 and increase operational costs (for = example, by forcing us to run VRRP forever because there is no fate = sharing).

Lowerin= g this particular barrier will certainly make IPv6 an easier concept for = a number of enterprises.

Will having it = instantaneously increase IPv6 adoption in the enterprise? Probably = not.

Will failing to deploy it continue to = impede IPv6 deployment in the enterprise? You = bet.

Owen

= --Apple-Mail=_7C48D890-678B-4D39-999B-E45F0612B608-- From owen@delong.com Wed Mar 27 16:36:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2784E21F86CD for ; Wed, 27 Mar 2013 16:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 fIPNHxe2ubKs for ; Wed, 27 Mar 2013 16:36:20 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 66A9C21F86B7 for ; Wed, 27 Mar 2013 16:36:20 -0700 (PDT) Received: from [10.255.252.140] ([207.102.63.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2RNV59J030531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 16:31:07 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2RNV59J030531 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364427068; bh=u4lSKWhK6icAzqpppCinZppqPfE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QLVrrT76typ9DDzylSkFp3FPnsFNWcEPu/Zw9qSODXE6LPRvo9CnA+R1iSpnCurgJ kNQj/tWK10UAqenNiRtsCLn6GfmB4+8QkKG9vkcrhpyWoF++4K6+F43YqJrpafIVfC 8Lpi8Qrcd5QaiYvMEqqZzMwGCTbk1B9UZmwlGL5s= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: <2134F8430051B64F815C691A62D9831803D8DB@XCH-BLV-504.nw.nos.boeing.com> Date: Wed, 27 Mar 2013 16:31:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <83602E3F-011F-4C90-A130-C82BE38A63FB@delong.com> References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1364411510.8596.YahooMailNeo@web142502.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D9831803D8DB@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 27 Mar 2013 16:31:08 -0700 (PDT) Cc: v6ops v6ops WG Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 23:36:21 -0000 While unicasting of RAs can solve the problem, it does so at a much = higher administrative inconvenience than being able to use DHCPv6. It also doesn't cover the additional functionality that would be gained = from a generic DHCPv6 Routing Information option rather than just a default = router ala DHCPv4. Owen On Mar 27, 2013, at 12:57 PM, "Templin, Fred L" = wrote: > Hi Mark, >=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of >> Mark Smith >> Sent: Wednesday, March 27, 2013 12:12 PM >> To: v6ops v6ops WG >> Subject: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in = DHCPv6 >> Route/DefRouter/Src-basedRoute configuration to Client? >>=20 >> Since the following it seems to have been missed, and this discussion = is >> just burning up more bandwidth and peoples' time (perhaps for the = 50th >> time in the last decade?), I'm reposting it. >>=20 >> RAs can be selectively unicast to clients, and the radvd IPv6 RA >> implementation provides that option. The email below has the manual = page >> text and an example. >=20 > Although I cannot say if it was *the* reason, one of the reasons > for this option was to accommodate ISATAP. That said, RFC4861 > does permit unicasting of RAs. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> It may not be the way that DHCPv4 solved this problem (which perhaps = is a >> symptom of IPv4 not having autoconfiguration from the outset), but = all >> that does is make it a different way of solving the problem. The = DHCPv4 >> model is not the be all and end all solution to all network = configuration >> problems. >>=20 >> Other than other router implementations not providing the option to = do >> unicast RAs to select clients (not a problem the IETF can solve), the = only >> gap I can see that DHCPv4 fills verses unicast RAs for influencing >> client's default router selection is the ability to have the mapping = of >> client to router centralised on a DHCPv4 server and then having = routers >> use that information via DHCPv4 forwarding. So what is necessary for = IPv6 >> is a method to either distribute the list of clients to unicast RAs = map to >> to the routers, or to have the router query a centralised server when = it >> receives an RS. That is a better solution than duplicating = functionality >> from RAs into DHCPv6, as it would only require changes to router >> implementations, rather than the deployed IPv6 implementations in = hosts, >> and avoid the inevitable issues around what to do when conflicting = default >> router information is received from an RA verses DHCPv6. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> ----- Forwarded Message ----- >>> From: Mark Smith >>> To: Iljitsch van Beijnum ; Alexandru Petrescu >> >>> Cc: "v6ops@ietf.org" >>> Sent: Wednesday, 27 March 2013 8:05 PM >>> Subject: Re: [v6ops] Interest in DHCPv6 = Route/DefRouter/Src-basedRoute >> configuration to Client? >>>=20 >>>> ________________________________ >>>> From: Iljitsch van Beijnum >>>> To: Alexandru Petrescu >>>> Cc: "v6ops@ietf.org" >>>> Sent: Wednesday, 27 March 2013 6:54 PM >>>> Subject: Re: [v6ops] Interest in DHCPv6 = Route/DefRouter/Src-basedRoute >>> configuration to Client? >>>>=20 >>>> On 26 mrt 2013, at 17:09, Alexandru Petrescu >>> wrote: >>>>=20 >>>>> Is there an interest in DHCPv6 Route/DefRouter/Src-basedRoute >>>>> configuration to Client? >>>>=20 >>>> The big issue with having DHCPv6 deliver a default route is that it >> breaks >>> the fate sharing that having the default router address in a router >>> advertisement from the router holding that address provides. >>>>=20 >>>> But I gather there are people who want to be able to make one group = of >> hosts >>> on a subnet use router A as their default router but another group = of >> hosts >>> router B, on that same subnet. >>>>=20 >>>=20 >>> This should already possible using RAs, with an example = implementation >> being the >>> clients section in radvd/radvd.conf. Here is the manual page help = text: >>>=20 >>> By default radvd will send route advertisements so that = every >> node on >>> the link can use them. The list of clients (IPv6 address) to >> advertise >>> to, and accept route solicitations from can be configured. = If >> done, >>> radvd does not send send messages to the multicast addresses = but >> to the >>> configured unicast addresses only. Solicitations from other >> addresses >>> are refused. This is similar to UnicastOnly but includes >> periodic mes=E2=80=90 >>> sages and incoming client access configuration. See = examples >> section >>> for a use case of this. >>>=20 >>> The definitions are of the form: >>>=20 >>> clients { >>> list of IPv6 addresses >>> }; >>>=20 >>>=20 >>> Further into the manual page is an example configuration: >>>=20 >>> interface eth0 >>> { >>> AdvSendAdvert on; >>> prefix 2001:db8:0:1::/64 >>> { >>> AdvOnLink on; >>> AdvAutonomous on; >>> }; >>> clients >>> { >>> fe80::21f:16ff:fe06:3aab; >>> fe80::21d:72ff:fe96:aaff; >>> }; >>> }; >>>=20 >>> This configuration would only announce the = prefix >> to >>> fe80::21f:16ff:fe06:3aab and fe80::21d:72ff:fe96:aaff. >> Furthermore, >>> all RA requests of other clients are denied. >>>=20 >>> This may come in handy if you want to roll out IPv6 only >> partially >>> because some clients are broken or untested. >>>=20 >>> >>>=20 >>> Regards, >>>=20 >>> Mark. >>>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Wed Mar 27 17:09:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B9721F933F for ; Wed, 27 Mar 2013 17:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 kc11sz1siRZG for ; Wed, 27 Mar 2013 17:09:35 -0700 (PDT) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE0021F92BE for ; Wed, 27 Mar 2013 17:09:35 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id j6so9275299oag.8 for ; Wed, 27 Mar 2013 17:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=PFvArkuU3ma2k3DovvKTQ9ukYw8Jek+9JkZxzC+DZOw=; b=f+wzbfc0W5ue25A81VPhg2Q/eAOySB6RU4ZX6fHgEfcgECZYYjiRhQZuC0aEoIDVNc vRt/USi+MYdJeQomXeklrgYyZ7rv9lRSKDQTtr95/p1bKOzeWAJG5265uoGqy1EuzN1w 1DeyhzDXoPkBfMvQcS75egb2UgkEPRtCC6AHxlR6sfFmWY88bagVgpaxm9oVb10mRgyS eaz9PrITHpFbnGCBoyvpltQz7aK/XlJNxLZi1oMj6YtDYzowog1L0HTw+je2DvN+PFen ZOTVe49/RH5dIdz4nXt0W2xChwi3VsstRwt4RZ0cDHt2xJkrx+MQGdHQbDNzs1Eyw5qu rVFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=PFvArkuU3ma2k3DovvKTQ9ukYw8Jek+9JkZxzC+DZOw=; b=RtUITnTtkjSn7+kXGZoX+PrABkk2NJxGKhvh56EAbSq73TQ6fXHSxzpAHMLry8a7rq 3MZuhscD52t7UBP+Y+TEk/2raDlY+P0C5OhSPrCHhdJ2fensB43DtxJtybKr2kL4Q4uB miLyOZGFaMSVCZfwLIbY5TZzhAJoU+sEV2Dn3uDUvDKirsILG4NDgTnNCkbNg+qWYyNK s7lDsW7p7oR7UUfpdGEXacEk/G0gF4xpqntN1Ok2vaqz3AWi2TgT4aKWg0dVfHtr44ci Ot7qvX79i9B0GGsiu5GkJ1cSUIikK7tpeVWEqYY9Qb3VThoGtIz+ADU/SHsA8TZfRosX 1Osw== X-Received: by 10.60.20.193 with SMTP id p1mr16494407oee.133.1364429374128; Wed, 27 Mar 2013 17:09:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Wed, 27 Mar 2013 17:09:14 -0700 (PDT) In-Reply-To: <6E974F14-4902-4345-9B09-5E06BE0D2AE5@delong.com> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <6E974F14-4902-4345-9B09-5E06BE0D2AE5@delong.com> From: Lorenzo Colitti Date: Thu, 28 Mar 2013 09:09:14 +0900 Message-ID: To: Owen DeLong Content-Type: multipart/alternative; boundary=e89a8ff1c2d82aa02204d8f0f822 X-Gm-Message-State: ALoCoQklzK17b8KcIv1Z+golNjSV7zELlsmRYgt6LE02dPnwXp59T+XP/NAcQM0N5kKkhlhh5NdW0gYG2ONSLdeAjZ4864oOtWQycdIBZEMxHHNAx9Gp07RKKVK0u4lZcgPXCoGj0/DdtnN5BmSWTYb/jPGlDP3DEbz401MeNe6wh7aGdaj9DZ0U1JS6eaRMV9ElHleW1Aa+ Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 00:09:36 -0000 --e89a8ff1c2d82aa02204d8f0f822 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 28, 2013 at 8:25 AM, Owen DeLong wrote: > It may be that they tell you about X. When you eliminate X, they tell you > about Y. > > Eventually, they run out of reasons. > Sometimes that happens, yes. But you're assuming that they think this is necessary. In many cases I've seen, reason Z is "we see no need to deploy IPv6". When you ask them about IPv6 deployment, they prefer not to cite reason Z, because that's a matter of opinion, and prefer to cite A, B, and C, which are absolute blockers. If that's the case, all the other reasons are removed, nothing happens anyway. Conversely, once Z is removed, suddenly all the other reasons simply become engineering problems which then get solved. Again: our own enterprise network is a large deployment of IPv6, and we didn't need DHCPv6 routing to do it. In fact, we don't even run DHCPv6 servers, which is good because it removes a maintenance burden. --e89a8ff1c2d82aa02204d8f0f822 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 28, 2013 at 8:25 AM, Owen DeLong <owen@delong.c= om> wrote:
It may be that they tell you about= X. When you eliminate X, they tell you about Y.

E= ventually, they run out of reasons.

Sometimes that happens, yes. But you're assuming that they t= hink this is necessary.

In many cases = I've seen, reason Z is "we see no need to deploy IPv6". When = you ask them about IPv6 deployment, they prefer not to cite reason Z, becau= se that's a matter of opinion, and prefer to cite A, B, and C, which ar= e absolute blockers. If that's the case, all the other reasons are remo= ved, nothing happens anyway. Conversely, once Z is removed, suddenly all th= e other reasons simply become engineering problems which then get solved.

Again: our own enterprise network is a larg= e deployment of IPv6, and we didn't need DHCPv6 routing to do it. In fa= ct, we don't even run DHCPv6 servers, which is good because it removes = a maintenance burden.
--e89a8ff1c2d82aa02204d8f0f822-- From lorenzo@google.com Wed Mar 27 17:17:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E8E21F9371 for ; Wed, 27 Mar 2013 17:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.925 X-Spam-Level: X-Spam-Status: No, score=-101.925 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNKPx8XPJpOK for ; Wed, 27 Mar 2013 17:17:36 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 96A6021F9370 for ; Wed, 27 Mar 2013 17:17:36 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id eh20so8605180obb.8 for ; Wed, 27 Mar 2013 17:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=bxNFqXMaCBgqRwBlJsG4BCW/ZSkUBfjrVBndboysghA=; b=QIX5OOtcMvEfgo8Ktq+tteEg4YiMNu6f8nU/Ap8pfzsNlJGTJ02ishFZ2L3KoLD7qU LOPCAo5z9FimQmMH7JQRl0kxMzIoiFxqOAT2s4FYJ8qCsaDlYEW9w77qdnaCC3Mbeqs6 sxO0tifF6ClShUdgyubTW16C39WGgXh7rL0N/NrRmezdC4s3x/seRNnJFBixl5P0YlR9 bAys0Lm/oQ4+A75a5Xd8xpPKRroFkPlOhFfnfDEOZ4DH/UbaAe5267Nt/R17SjdabJcz pLwYFdRTUckcMSBolj9DoNwe+NPlnCUxSKFaUbM6GfEubCO9rNMKz8qh2MjOFQwl28VS 55pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=bxNFqXMaCBgqRwBlJsG4BCW/ZSkUBfjrVBndboysghA=; b=DvmKm1nRypn3L8h6oMEPcsWiFOv5YUCO/sUd/DR7asiBhVg5OEDc3F2516E7SogaSd f5G8EQZUbNhvKekTYZLIXU3sEA2Gue1sHXYW5QYwXFvXohzRcxWPTqGbtX5C+shMpjJM zaS1AOjjDgck4kUWBOYw7QERuXnVh2OgOKUiQGYiEav4fEDOgVNKA8JX0gt26B/LBiiG OElcuoLI+JzNdoV399geZj14/bqLS3zecAGW4RA+h66z0ujAtAUQRRaEnzdLGpVNGtwo VHLCADfDZiNehdBhc8wtCHhCh4jORTD0TqBXRfYu02UqDpvAWQAMgccQZpDUVFTg3f5+ 6I0g== X-Received: by 10.182.188.69 with SMTP id fy5mr4801829obc.14.1364429856041; Wed, 27 Mar 2013 17:17:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Wed, 27 Mar 2013 17:17:15 -0700 (PDT) In-Reply-To: <83602E3F-011F-4C90-A130-C82BE38A63FB@delong.com> References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1364411510.8596.YahooMailNeo@web142502.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D9831803D8DB@XCH-BLV-504.nw.nos.boeing.com> <83602E3F-011F-4C90-A130-C82BE38A63FB@delong.com> From: Lorenzo Colitti Date: Thu, 28 Mar 2013 09:17:15 +0900 Message-ID: To: Owen DeLong Content-Type: multipart/alternative; boundary=f46d0447f2a8e41ac104d8f11439 X-Gm-Message-State: ALoCoQljoJmKdlDwtQAqIDqXUO+SAOt/6rdA/JkPyUpWAGF00zroH9RCXnVjL7jCc26XLTgJTTRwdhWi2DmSbZu7ejHVxNxLKFPh6UNZVaME+IGqFBpw5hzfFUnXJjKJXoffofFbZUcUrlvvfHPzVZWJtYIGoDX/KCS6FOyqGwXANhSxMcMu6+bX833J6bw7+nN3tZG1bk7j Cc: v6ops v6ops WG Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 00:17:37 -0000 --f46d0447f2a8e41ac104d8f11439 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 28, 2013 at 8:31 AM, Owen DeLong wrote: > It also doesn't cover the additional functionality that would be gained > from a > generic DHCPv6 Routing Information option rather than just a default router > ala DHCPv4. > What functionality would such an option provide that cannot be provided using the Route Information Option in the RA? --f46d0447f2a8e41ac104d8f11439 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 28, 2013 at 8:31 AM, Owen DeLong <owen@delong.c= om> wrote:
It also doesn't cover the additional functionality that would be gained= from a
generic DHCPv6 Routing Information option rather than just a default router=
ala DHCPv4.

What functionality wo= uld such an option provide that cannot be provided using the Route Informat= ion Option in the RA?=A0
--f46d0447f2a8e41ac104d8f11439-- From owen@delong.com Wed Mar 27 17:26:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8642721F8E6B for ; Wed, 27 Mar 2013 17:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noEgkIl35E13 for ; Wed, 27 Mar 2013 17:26:05 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id E2D8021F8E5F for ; Wed, 27 Mar 2013 17:26:04 -0700 (PDT) Received: from [10.255.252.140] ([207.102.63.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2S0MtbT031931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 17:22:56 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2S0MtbT031931 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364430177; bh=lA8sOJbMhCcmY7CWRUaC3dLWDTI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=1Pa5hb7M8lLqNBu/Qj/4DgWyz9swpaic9Rw28yMDh1Xr14zSxVqpwqZ6hYRhJR7Mt lqPXYoPfIky0F35ZdX3sK9GBFr346Vja9hCdOvkbW4WQqBBLbCbG4AU/Ih/OO8wcqH gIu8UOezbMZLhg5JXtXJK63rAIoEjCTsCKPlA5Pc= Content-Type: multipart/alternative; boundary="Apple-Mail=_6CA36F64-C231-4166-847F-731EE74F4154" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: Date: Wed, 27 Mar 2013 17:22:55 -0700 Message-Id: <804490FF-EB5D-4624-9E88-295BA247191F@delong.com> References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1364411510.8596.YahooMailNeo@web142502.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D9831803D8DB@XCH-BLV-504.nw.nos.boeing.com> <83602E3F-011F-4C90-A130-C82BE38A63FB@delong.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 27 Mar 2013 17:22:57 -0700 (PDT) Cc: v6ops v6ops WG Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 00:26:05 -0000 --Apple-Mail=_6CA36F64-C231-4166-847F-731EE74F4154 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Mar 27, 2013, at 5:17 PM, Lorenzo Colitti wrote: > On Thu, Mar 28, 2013 at 8:31 AM, Owen DeLong wrote: > It also doesn't cover the additional functionality that would be = gained from a > generic DHCPv6 Routing Information option rather than just a default = router > ala DHCPv4. >=20 > What functionality would such an option provide that cannot be = provided using the Route Information Option in the RA?=20 The combination of that functionality with deterministic and auditable = client addressing? Owen --Apple-Mail=_6CA36F64-C231-4166-847F-731EE74F4154 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Mar 27, 2013, at 5:17 PM, Lorenzo Colitti <lorenzo@google.com> wrote:

On Thu, Mar 28, 2013 at 8:31 AM, Owen DeLong <owen@delong.com> wrote:
It also doesn't cover the additional functionality that would be gained from a
generic DHCPv6 Routing Information option rather than just a default router
ala DHCPv4.

What functionality would such an option provide that cannot be provided using the Route Information Option in the RA? 

The combination of that functionality with deterministic and auditable client addressing?

Owen

--Apple-Mail=_6CA36F64-C231-4166-847F-731EE74F4154-- From owen@delong.com Wed Mar 27 17:26:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE3D21F8E6E for ; Wed, 27 Mar 2013 17:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVwGOgdyBdda for ; Wed, 27 Mar 2013 17:26:05 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C0C2721F8E5F for ; Wed, 27 Mar 2013 17:26:05 -0700 (PDT) Received: from [10.255.252.140] ([207.102.63.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2S0LcTo031909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 17:21:39 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2S0LcTo031909 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364430099; bh=brBAY1T+ykCU/q5PxQyUPmhf9/w=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=DAnOU6SK7csjo47Koyh9AFTOfKRrCUjbSejNiQfGJ+Yi4JrwBThYo5WTRLh4mkj61 /fs7cdZKA1XUd8QvtcQb3RVVtGqCpLjynMNG7M2Y+vOk9EDR1J1HvwZSpmFrUeUUBM dYncTRGAuxay0p5smGrk04KiwIjCRRUD18EVEj/w= Content-Type: multipart/alternative; boundary="Apple-Mail=_BEC84804-F74C-4E18-AB23-46E1E01169FE" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: Date: Wed, 27 Mar 2013 17:21:38 -0700 Message-Id: <9DE8AA62-60EB-43ED-A462-B9647F2A28E8@delong.com> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <6E974F14-4902-4345-9B09-5E06BE0D2AE5@delong.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 27 Mar 2013 17:21:39 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 00:26:06 -0000 --Apple-Mail=_BEC84804-F74C-4E18-AB23-46E1E01169FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Mar 27, 2013, at 5:09 PM, Lorenzo Colitti wrote: > On Thu, Mar 28, 2013 at 8:25 AM, Owen DeLong wrote: > It may be that they tell you about X. When you eliminate X, they tell = you about Y. >=20 > Eventually, they run out of reasons. >=20 > Sometimes that happens, yes. But you're assuming that they think this = is necessary. >=20 > In many cases I've seen, reason Z is "we see no need to deploy IPv6". = When you ask them about IPv6 deployment, they prefer not to cite reason = Z, because that's a matter of opinion, and prefer to cite A, B, and C, = which are absolute blockers. If that's the case, all the other reasons = are removed, nothing happens anyway. Conversely, once Z is removed, = suddenly all the other reasons simply become engineering problems which = then get solved. >=20 > Again: our own enterprise network is a large deployment of IPv6, and = we didn't need DHCPv6 routing to do it. In fact, we don't even run = DHCPv6 servers, which is good because it removes a maintenance burden. A-Y may be seen as engineering problems which get solved, but I = guarantee you that in at least some organizations, this will get solved = by deploying some sort of routing functionality in DHCP. It really would = be best if we standardized this at the IETF level. What harm comes from having a routing information option documented for = DHCPv6? Those organizations that don't feel they need it won't use it. Owen --Apple-Mail=_BEC84804-F74C-4E18-AB23-46E1E01169FE Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Mar 27, 2013, at 5:09 PM, Lorenzo Colitti <lorenzo@google.com> wrote:

On Thu, Mar 28, 2013 at 8:25 AM, Owen DeLong <owen@delong.com> wrote:
It may be that they tell you about X. When you eliminate X, they tell you about Y.

Eventually, they run out of reasons.

Sometimes that happens, yes. But you're assuming that they think this is necessary.

In many cases I've seen, reason Z is "we see no need to deploy IPv6". When you ask them about IPv6 deployment, they prefer not to cite reason Z, because that's a matter of opinion, and prefer to cite A, B, and C, which are absolute blockers. If that's the case, all the other reasons are removed, nothing happens anyway. Conversely, once Z is removed, suddenly all the other reasons simply become engineering problems which then get solved.

Again: our own enterprise network is a large deployment of IPv6, and we didn't need DHCPv6 routing to do it. In fact, we don't even run DHCPv6 servers, which is good because it removes a maintenance burden.


A-Y may be seen as engineering problems which get solved, but I guarantee you that in at least some organizations, this will get solved by deploying some sort of routing functionality in DHCP. It really would be best if we standardized this at the IETF level.

What harm comes from having a routing information option documented for DHCPv6? Those organizations that don't feel they need it won't use it.

Owen

--Apple-Mail=_BEC84804-F74C-4E18-AB23-46E1E01169FE-- From lorenzo@google.com Wed Mar 27 17:32:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24C321F9221 for ; Wed, 27 Mar 2013 17:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 NoQKXdIcqjp6 for ; Wed, 27 Mar 2013 17:32:17 -0700 (PDT) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id 3260321F9269 for ; Wed, 27 Mar 2013 17:32:17 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id k1so9420708oag.19 for ; Wed, 27 Mar 2013 17:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=LpFdyCQcwYeBwkpSx1v6NJ+18uDzEaMlXch0vOvSsPk=; b=JP6zuV6Z0hqAKvsXhu0i4+oT+nKV2jJpmPNNUCjYc9/ln/0yQOadD7SUJTeiMUuSRZ G7XWc7XIcR0VJQhIP0lGQZ3SNdO9rJlqV8HSikLP6inNrCvH9IZzLygwJKeivmLsmSpT a5wHoCbbUhx7AXOffMQYeimY+Zj0J3fGUPZaBJPPzZMfbsBAC8KMQNQ6JkNwLFtulgbV 6wSTx+xN4r5ta6mKV0nHL42dC4SG/bAiD+J4Kynw1zog+DlyROWmf8/Ry7k75nEDXS+A yDyvezwudjJfE6aCDlYVSImi5ZH/Z5yrsVZCyql0eeyXwGFVxqvDpFyom3MvAU8c7A9d K49Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=LpFdyCQcwYeBwkpSx1v6NJ+18uDzEaMlXch0vOvSsPk=; b=S7Zm4zm22x9TZR4slCAFihnThaX+nlZf2DlE1hhrgVQXNeUx+YUX1wGlSE+Khcpy6U JkCAS/d6eJaycdVYoD9RwwpfvPdxaAUhtbmJw1nzpyYF90lxoq95x7QUWsuU8SaSzvyA Fm6Tt7DRfCkdgYRuFgE1Xlabc3fX8zU3FJQpCIuVddVWG2rk9f49Z7EZ3SN6A5EV2eE0 QWYhwtz2tGmVB68DX+gTFNGWSX6jV6WbtdcpEGyiv9G4M59++JVVOtF24SykMRVEFgka xU6WobeKvvEymw/KAg/SN8e+bV7EgKvfuDscurWIT5Ayc3D9d7ROof7HkSAf/pe1uIrF qrhA== X-Received: by 10.60.6.199 with SMTP id d7mr15675398oea.137.1364430727283; Wed, 27 Mar 2013 17:32:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Wed, 27 Mar 2013 17:31:47 -0700 (PDT) In-Reply-To: <804490FF-EB5D-4624-9E88-295BA247191F@delong.com> References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1364411510.8596.YahooMailNeo@web142502.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D9831803D8DB@XCH-BLV-504.nw.nos.boeing.com> <83602E3F-011F-4C90-A130-C82BE38A63FB@delong.com> <804490FF-EB5D-4624-9E88-295BA247191F@delong.com> From: Lorenzo Colitti Date: Thu, 28 Mar 2013 09:31:47 +0900 Message-ID: To: Owen DeLong Content-Type: multipart/alternative; boundary=e89a8fb1fd74d22e6804d8f1482f X-Gm-Message-State: ALoCoQkvq4NJ8YG/8vTKee36CXo6qGN8rJ0BPNuGVyBqtQVlMidcx9YPEv1d2OY48ZMYpLfT17cpovTcdGcpaElaZGDLAG3sWBtbzOzva1lBRiJClMYVENLM3Utgo/am4TuChoJasldaPRyfTCGbL8lMKQ4T6YX2lLcT4ufsOfIhP71IwF6tG/pKtUW8MJWFwrwIUA37tcwI Cc: v6ops v6ops WG Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 00:32:17 -0000 --e89a8fb1fd74d22e6804d8f1482f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 28, 2013 at 9:22 AM, Owen DeLong wrote: > What functionality would such an option provide that cannot be provided > using the Route Information Option in the RA? > > The combination of that functionality with deterministic and auditable > client addressing? > I don't understand that statement. You can have deterministic and auditable addressing with DHCPv6 today, without having to use DHCPv6 to configure routing. --e89a8fb1fd74d22e6804d8f1482f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 28, 2013 at 9:22 AM, Owen DeLong <owen@delong.c= om> wrote:
What functionality would such an option provide that cannot= be provided using the Route Information Option in the RA?=A0
The combination of th= at functionality with deterministic and auditable client addressing?
<= /div>

I don't understand that sta= tement. You can have deterministic and auditable addressing with DHCPv6 tod= ay, without having to use DHCPv6 to configure routing.
--e89a8fb1fd74d22e6804d8f1482f-- From randy@psg.com Wed Mar 27 17:51:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60B321F936C for ; Wed, 27 Mar 2013 17:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 ma0o1SAQJtx0 for ; Wed, 27 Mar 2013 17:51:33 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 27E7621F936B for ; Wed, 27 Mar 2013 17:51:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UL140-0008MC-4F; Thu, 28 Mar 2013 00:51:32 +0000 Date: Thu, 28 Mar 2013 09:51:31 +0900 Message-ID: From: Randy Bush To: Tom Perrine In-Reply-To: <51537541.5050806@scea.com> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <51537541.5050806@scea.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 00:51:33 -0000 > I'm seeing the possibility of no longer having to coordinate RFC 1918 > space across business units and partners as a compelling factor for > adoption of IPv6. yep, you just have to coordinate ula, a major advance. From ek@google.com Wed Mar 27 18:12:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F8621F9405 for ; Wed, 27 Mar 2013 18:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAm2+Eq-T8uG for ; Wed, 27 Mar 2013 18:12:59 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0B95E21F93FC for ; Wed, 27 Mar 2013 18:12:58 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id er7so5216843obc.35 for ; Wed, 27 Mar 2013 18:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=OHy4DWBV18H38kzb9Rj5tFKgND85OG50jtLZ0XxEWlg=; b=YY+aVkzUvCB0rVG4/hmTGnVRe2oSG8mttTTD16MPEocvyOOO6QYFsvLf6iLlzg5Q0f dEDwwNgGTT9rs7pgXa7gfQC2eG7CWmGqbjndElekGYaYpW2/gTtpuh1XINeggOzczORW 0ocp4GmcNrh++d4/rF5Ik8QN1rv8F0Xw0x5XXoYi9RkuHaXoHZEkku8rGgqrViynPmEC lcxioxQ0u67eLcgHP3Q2Co9ErSBk7PCQ9sz7W+KVAscK8THjpOJIRDcPFcUIo1XLwxmZ SG3fUNSh3ria1gGijRB5PqvSCG+YVCHHma0eLWWhfgyc0rp13ydLG9Gt/ARYX+KZSWMG M9kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=OHy4DWBV18H38kzb9Rj5tFKgND85OG50jtLZ0XxEWlg=; b=h6tfmEHsX5KHG119He3SZNPLIA/RrZNrULJIDpnnZLOqL6oE6L2IPYRxBPFCEMgRz9 atUyDA/OXBTKUm+VhxynSsbI9o+0oqUGMXb6cw+L8EMzwenEsPXcJ8vIhiYT8I/jLj1E BDdP8+hS28VASf1JMBQicLYc/L7jX/vyRIWeXtQp3+f2uw2Ehx8FFM/jjSfFMiEPJAUQ /BbUaFVPk2cslJO/NauSuBQlmQeCKoVKgM2gj3FftPUc7dZ+gzt/vSIHreQXJSGTm9E9 446JtkuLhTE2ax7AjkMm+xO9WUl12d1VkMJ7FVBbnLEE2spijX/i01ZacQMNuF64Z5x9 bdyg== X-Received: by 10.60.37.132 with SMTP id y4mr15740196oej.34.1364433178379; Wed, 27 Mar 2013 18:12:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.50.227 with HTTP; Wed, 27 Mar 2013 18:12:37 -0700 (PDT) In-Reply-To: <804490FF-EB5D-4624-9E88-295BA247191F@delong.com> References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1364411510.8596.YahooMailNeo@web142502.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D9831803D8DB@XCH-BLV-504.nw.nos.boeing.com> <83602E3F-011F-4C90-A130-C82BE38A63FB@delong.com> <804490FF-EB5D-4624-9E88-295BA247191F@delong.com> From: Erik Kline Date: Thu, 28 Mar 2013 10:12:37 +0900 Message-ID: To: Owen DeLong Content-Type: multipart/alternative; boundary=089e01176e87eadc2104d8f1da9f X-Gm-Message-State: ALoCoQmeisYAKwT8mERNRjN3KWCrnFQHoNRqonksIkm/8i9quhxNjxsp8eI3DZuXiTKx80XtjOOAgLcJSrvYeLu1fQ96Q1SLYqvKLKQMzkIUFi7vjyJAZwdUysbVzan9CKcU73fd/UvkHEWXAs51WTptm4I0BkJbjGEEpJOAegU3fGmDXKqJRWIjF0HwfijTTNDqaHgHOTkN Cc: v6ops v6ops WG Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 01:12:59 -0000 --089e01176e87eadc2104d8f1da9f Content-Type: text/plain; charset=UTF-8 > > > What functionality would such an option provide that cannot be provided > using the Route Information Option in the RA? > > > The combination of that functionality with deterministic and auditable > client addressing? > Unless you also use some Layer 2 security features you can only have a vague squishy feeling of "auditable client addressing". Of all the people and organizations with whom I've discussed this only 1 or 2 actually do run some kind link-level control (I'm sure there are others though). For all the others, I strongly feel that we should focus on the far far better solution of whatever it is that would make it easier for switches and routers to log L2-L3 pairs (neighbor cache entries) as they come and go. That will allow people to audit devices that try to change IPv4 addresses as well. --089e01176e87eadc2104d8f1da9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

What functionality would such an option prov= ide that cannot be provided using the Route Information Option in the RA?= =C2=A0

The combination of that functionali= ty with deterministic and auditable client addressing?

Unless you also use some Layer 2= security features you can only have a vague squishy feeling of "audit= able client addressing". =C2=A0Of all the people and organizations wit= h whom I've discussed this only 1 or 2 actually do run some kind link-l= evel control (I'm sure there are others though).

For all the others, I strongly feel that we should focus on the far far be= tter solution of whatever it is that would make it easier for switches and = routers to log L2-L3 pairs (neighbor cache entries) as they come and go. = =C2=A0That will allow people to audit devices that try to change IPv4 addre= sses as well.
--089e01176e87eadc2104d8f1da9f-- From tperrine@scea.com Wed Mar 27 18:20:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E8921F9221 for ; Wed, 27 Mar 2013 18:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riQNQdxjfn-j for ; Wed, 27 Mar 2013 18:20:42 -0700 (PDT) Received: from ironport02a.scea.com (ironport02a.scea.com [160.33.44.43]) by ietfa.amsl.com (Postfix) with ESMTP id A178C21F9215 for ; Wed, 27 Mar 2013 18:20:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,363,1363158000"; d="scan'208";a="24218053" Received: from inbetweener02.scea.com ([160.33.45.196]) by ironport02a.scea.com with ESMTP; 27 Mar 2013 18:20:42 -0700 Received: from sd-tperrine-mpl.pd.scea.com (unknown [172.31.30.191]) by inbetweener02.scea.com (Postfix) with ESMTP id 6D63EB829A for ; Wed, 27 Mar 2013 18:20:42 -0700 (PDT) Message-ID: <51539AEA.6040403@scea.com> Date: Wed, 27 Mar 2013 18:20:42 -0700 From: Tom Perrine User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: IETF v6ops list References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <51537541.5050806@scea.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 01:20:43 -0000 On 3/27/13 5:51 PM, Randy Bush wrote: >> I'm seeing the possibility of no longer having to coordinate RFC 1918 >> space across business units and partners as a compelling factor for >> adoption of IPv6. > > yep, you just have to coordinate ula, a major advance. > Nope. In our specific case, which is slightly different from the one I described, each business unit (all in different regions, or at least countries) is going to the local registry for PI space. Some of the space will be used internally (and between the business units) and some will be consumer-facing. All the units (in our case) are already multi-homed/multi-provider, so PI space is appropriate and this seemed the best way to just make the address space coordination problem go away. The registries and global space are there for a reason, so we don't have to do that :-) I've been watching the discussions of "how to deal with ULA space" and it seems that ULA just causes more headaches than necessary, *for an enterprise which is not an ISP*. I can't speak to the ISP issues, but for us, it seems like NAT, with all the problems that we're glad to finally be rid of (some day). We're not an ISP, so no compelling reason to go anywhere near ULA. From randy@psg.com Wed Mar 27 18:29:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B634B21F9410 for ; Wed, 27 Mar 2013 18:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 XWDKHqZXetrx for ; Wed, 27 Mar 2013 18:29:10 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEF821F9403 for ; Wed, 27 Mar 2013 18:29:10 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UL1eP-0008SC-L8; Thu, 28 Mar 2013 01:29:09 +0000 Date: Thu, 28 Mar 2013 10:29:08 +0900 Message-ID: From: Randy Bush To: Tom Perrine In-Reply-To: <51539AEA.6040403@scea.com> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <51537541.5050806@scea.com> <51539AEA.6040403@scea.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 01:29:10 -0000 >>> I'm seeing the possibility of no longer having to coordinate RFC 1918 >>> space across business units and partners as a compelling factor for >>> adoption of IPv6. >> >> yep, you just have to coordinate ula, a major advance. > > Nope. In our specific case, which is slightly different from the one > I described, each business unit (all in different regions, or at least > countries) is going to the local registry for PI space. > ... > The registries and global space are there for a reason, so we don't > have to do that :-) 96 more bits, no magic. excellent. > I've been watching the discussions of "how to deal with ULA space" nancy regan applies here if we spent half as much energy on fixing the broken registry cartel as we do complicating the technology to hack around it, the world would be a better and simpler place a decade from now. randy From Ted.Lemon@nominum.com Wed Mar 27 19:11:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37ED321E8089 for ; Wed, 27 Mar 2013 19:11:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6O6bZkBOpFWR for ; Wed, 27 Mar 2013 19:11:19 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id ED64B21E8087 for ; Wed, 27 Mar 2013 19:11:17 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUVOmxUrqXboNdKldaF5iDiX+WNp7W1uQ@postini.com; Wed, 27 Mar 2013 19:11:18 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1083D1B807E for ; Wed, 27 Mar 2013 19:11:17 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 069D119005C; Wed, 27 Mar 2013 19:11:17 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Wed, 27 Mar 2013 19:11:11 -0700 From: Ted Lemon To: Owen DeLong Thread-Topic: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? Thread-Index: AQHOKxHBmujApcsxFk6K3pZTlhjfApi6n9aAgAAyawA= Date: Thu, 28 Mar 2013 02:11:10 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751240AF@mbx-01.win.nominum.com> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <4FC37E442D05A748896589E468752CAA0A671F49@PWN401EA160.ent.corp.bcbsm.com> <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> <51532AEF.2030702@dougbarton.us> <0FACA054-11D6-41D3-9ADB-0EFC7E583415@muada.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 02:11:21 -0000 On Mar 27, 2013, at 7:10 PM, Owen DeLong wrote: > But it got resolved because Apple succumbed to the pressure to implement = DHCPv6. >=20 > Frankly, Apple would have done that a lot earlier if it hadn't been for a= ll the IETF BS from people trying to block DHCPv6 in the first place. As far as I know, the reason that Apple didn't release DHCPv6 until Mountai= n Lion is that Stuart Cheshire said "over my dead body," not that some evil= cabal within the IETF pushed Apple not to do it. And Stuart wasn't even = against it for reasons relating to the conversation you guys are now having= . From leo.liubing@huawei.com Wed Mar 27 20:19:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01AC221F9441 for ; Wed, 27 Mar 2013 20:19:05 -0700 (PDT) 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_33=0.6, 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 f7PmOOxS0ZRK for ; Wed, 27 Mar 2013 20:19:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7F621F943E for ; Wed, 27 Mar 2013 20:19:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARD99130; Thu, 28 Mar 2013 03:19:01 +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.7; Thu, 28 Mar 2013 03:18:43 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 28 Mar 2013 03:18:57 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.42]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Thu, 28 Mar 2013 11:18:54 +0800 From: "Liubing (Leo)" To: Alexandru Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] ULA discussion #BCP or Informational Thread-Index: Ac4qGON521++zMpPThuXXXszdE4eKgAxzkMAAB9FuJA= Date: Thu, 28 Mar 2013 03:18:54 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> In-Reply-To: <51534B90.9040102@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: BxRj CP4z Cddx DV44 Fpk+ Gqoy GzNy Ij+g Mp1S NTmD Nz/6 PWGh Tp1x UIdo V9pR ZQrr; 2; YQBsAGUAeABhAG4AZAByAHUALgBwAGUAdAByAGUAcwBjAHUAQABnAG0AYQBpAGwALgBjAG8AbQA7AHYANgBvAHAAcwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {D0F71FA6-742B-48B0-B32D-D0CC4BEC2862}; bABlAG8ALgBsAGkAdQBiAGkAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Thu, 28 Mar 2013 03:18:47 GMT; UgBFADoAIABbAHYANgBvAHAAcwBdACAAVQBMAEEAIABkAGkAcwBjAHUAcwBzAGkAbwBuACAAIwBCAEMAUAAgAG8AcgAgAEkAbgBmAG8AcgBtAGEAdABpAG8AbgBhAGwA x-cr-puzzleid: {D0F71FA6-742B-48B0-B32D-D0CC4BEC2862} x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 03:19:05 -0000 Hi, Alex Thanks for the detailed suggestion, they are good operational concerns. Rig= ht now I haven't figured out whether to include these fine granularity cons= iderations into the general guidance. But I'll consider them in the next ve= rsion. Some other replies inline as below. > I think it is good to go towards a practice like this: >=20 > - don't write ULAs like this: fd::1, because it's not an ULA. The ULA > must start with fd00: and not fd:, because whereas the leading 0s can > be ommitted the subsequent 0s are significant, in this Western- > inspired textual address representation system (like 003 dollars is > same value as 3 dollars, but 300 dollars is not the same as 3 > dollars). [Bing] I think fc00:/7 might be more accurate? Although most of the time it= would be fd00:/8, but maybe it is not necessarily to exclude L=3D0.=20 =20 > - don't write example ULAs like this: fd00::1 because there seems to be > only 0s between fd and 1, whereas a real ULA has randomness in that > space, to ensure uniqueness. fd00:face:booc::1 is probably a better > ULA although a trained eye may notice a surprising coincidence hard > to generate randomly. >=20 > - dont assign fd00::1/128 address on the default Gateway, even though > one is used to assign such in IPv4; the reason same as above - lack > of randomnes. >=20 > - if you want to set up a small network which has multiple subnets, and > you can't get IPv6 global unicast addresses from an authority or an > authoritative sysadmin (prefixed by 001 first three bits), like a > Provider Independepent, or Provider Assigned addresses - then use > ULAs to configure your small network. >=20 > - for that small network use ULAs rather than making up some global > unicast addresses out of a prefix which was not previously guaranteed > unique by the administration. >=20 > - dont use 2001:db8:: prefix to assign to that small network - it's a > Documentation prefix, has sense for humans but not for computers. > Rather use ULAs, or global unicast addresses if you can get some. > - dont use ULA with NAT - it doesnt work. [Bing] Well, this is the big issue I need to address in the next version: )= =20 According to the discussions, I prefer NOT explicitly recommend against ULA= +NAT, but give pros/cons, benefit/drawbacks, and maybe some operational con= cerns/warning as well. And I'll separate the NPTv6 with NAPT, and limit the= scope within NPTv6, because it is the only IPv6 NAT related standard avail= able so far. > Alex From owen@delong.com Wed Mar 27 21:47:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8A421F91B8 for ; Wed, 27 Mar 2013 21:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 Q0nbO3MEJFb5 for ; Wed, 27 Mar 2013 21:46:49 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0D521F91AE for ; Wed, 27 Mar 2013 21:46:30 -0700 (PDT) Received: from [10.255.252.140] ([207.102.63.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2S4ioqC005867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 21:44:52 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2S4ioqC005867 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364445893; bh=y6tCBPl8cK4jME6G0Kh1HT5vHU0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=KmNElrDoHwKumTX0OUbQgq1XsqQ8Dzs0NfXIpJEcekdSLm0EjGOQjh3og87WUjN+J yCFxUXxhz8iU2uAsCoefXAIi1Ix8DLNM/uSE34uFmSo6XewhMPXJze4fo7tI9KtKx4 UqiNUP9t5bnN3Rw0izyPQboleDkv+cfzfpch+bqk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: Date: Wed, 27 Mar 2013 21:44:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <31C71587-217B-44C7-A507-D8A9C31AF5BB@delong.com> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <51537541.5050806@scea.com> <51539AEA.6040403@scea.com> To: Randy Bush X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 27 Mar 2013 21:44:53 -0700 (PDT) Cc: IETF v6ops list , Tom Perrine Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 04:47:01 -0000 >=20 > if we spent half as much energy on fixing the broken registry cartel = as > we do complicating the technology to hack around it, the world would = be > a better and simpler place a decade from now. >=20 This isn't any of the 10+ lists I know of that are designated for that = purpose. I will point out that I haven't seen anything from you that even = remotely approaches a solution to issues with the alleged registry cartel on any of the = aforementioned lists. (No, I do not think proposing to eliminate the policy process remotely = approached any such solution). Owen From owen@delong.com Wed Mar 27 21:47:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406F121F925C for ; Wed, 27 Mar 2013 21:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 ft9tu1x0lMmf for ; Wed, 27 Mar 2013 21:47:42 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id AC79721F9275 for ; Wed, 27 Mar 2013 21:47:32 -0700 (PDT) Received: from [10.255.252.140] ([207.102.63.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2S4ioqD005867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 21:45:21 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2S4ioqD005867 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364445922; bh=W/FLkGJDP8lIHO1ThDqHOZG4nHE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=s3QkqgHfdWliI9jf1JHxL6r1/jgMZ40b06Dhn7GA4b8DaMgXLNIvdT0qck0QuifDA jrgYU2X2Ywv0il2VXsnM9zY9qAkLEBXaLVZApMs5leBUOyDONcqy5wtK9TQVDRRRbR BIqDJUrObxEUhMsijyGtUZpBuGHKHPeYAC4nRRMw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751240AF@mbx-01.win.nominum.com> Date: Wed, 27 Mar 2013 21:45:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <844D2086-E10B-4393-BE80-D1E041B8BD8C@delong.com> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <4FC37E442D05A748896589E468752CAA0A671F49@PWN401EA160.ent.corp.bcbsm.com> <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> <51532AEF.2030702@dougbarton.us> <0FACA054-11D6-41D3-9ADB-0EFC7E583415@muada.com> <8D23D4052ABE7A4490E77B1A012B6307751240AF@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 27 Mar 2013 21:45:22 -0700 (PDT) Cc: "" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 04:47:43 -0000 On Mar 27, 2013, at 7:11 PM, Ted Lemon wrote: > On Mar 27, 2013, at 7:10 PM, Owen DeLong wrote: >> But it got resolved because Apple succumbed to the pressure to = implement DHCPv6. >>=20 >> Frankly, Apple would have done that a lot earlier if it hadn't been = for all the IETF BS from people trying to block DHCPv6 in the first = place. >=20 > As far as I know, the reason that Apple didn't release DHCPv6 until = Mountain Lion is that Stuart Cheshire said "over my dead body," not that = some evil cabal within the IETF pushed Apple not to do it. And Stuart = wasn't even against it for reasons relating to the conversation you guys = are now having. DHCPv6 support was added in Lion. Owen From owen@delong.com Wed Mar 27 21:57:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549AF21F9397 for ; Wed, 27 Mar 2013 21:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 4dLOJuF-dhu9 for ; Wed, 27 Mar 2013 21:57:55 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7476321F9393 for ; Wed, 27 Mar 2013 21:57:54 -0700 (PDT) Received: from [10.255.252.140] ([207.102.63.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2S4rx9m006140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 21:54:00 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2S4rx9m006140 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364446440; bh=UozQeN07akQzXylbSw+JMMLCiWc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qZAVcFszIRwosD26NVipzgu3Ps9cz7hx00KUI9DcBB2nTc2AS+OSUBPpFAL2s4cD4 szg73h2CRxUka2v5Z1D1e8nTADscGbWqGPVg2YXmbP8DPjMduVwl2i8oFFMxqqhuG5 xBI8RU9TF3HbgFUV9oZtV4aKtPozvG5eJZsg5l+Q= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Owen DeLong In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> Date: Wed, 27 Mar 2013 21:53:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> To: Liubing (Leo) X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 27 Mar 2013 21:54:00 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 04:57:56 -0000 On Mar 27, 2013, at 8:18 PM, Liubing (Leo) = wrote: > Hi, Alex >=20 > Thanks for the detailed suggestion, they are good operational = concerns. Right now I haven't figured out whether to include these fine = granularity considerations into the general guidance. But I'll consider = them in the next version. >=20 > Some other replies inline as below. >=20 >> I think it is good to go towards a practice like this: >>=20 >> - don't write ULAs like this: fd::1, because it's not an ULA. The = ULA >> must start with fd00: and not fd:, because whereas the leading 0s = can >> be ommitted the subsequent 0s are significant, in this Western- >> inspired textual address representation system (like 003 dollars is >> same value as 3 dollars, but 300 dollars is not the same as 3 >> dollars). >=20 > [Bing] I think fc00:/7 might be more accurate? Although most of the = time it would be fd00:/8, but maybe it is not necessarily to exclude = L=3D0.=20 There is no valid use of L=3D0 currently. The IETF did not gain = consensus for that draft and no substitute proposal has emerged or shown any signs of gaining consensus. IIRC, it was slightly more controversial than the = idea of routing information in DHCP. >=20 >> - don't write example ULAs like this: fd00::1 because there seems to = be >> only 0s between fd and 1, whereas a real ULA has randomness in that >> space, to ensure uniqueness. fd00:face:booc::1 is probably a = better >> ULA although a trained eye may notice a surprising coincidence hard >> to generate randomly. Actually, I would recommend that we use fd00:2001:db8::/48 as the = example ULA. I will submit a draft for that update to the Example Prefix RFC. >>=20 >> - dont assign fd00::1/128 address on the default Gateway, even though >> one is used to assign such in IPv4; the reason same as above - lack >> of randomness. True, but there's nothing wrong with establishing an example ULA prefix at fd00:2001:db8::/48 and then using fd00:2001:db8::/64 as the first prefix in that /48 and fd00:2001:db8::1/128 as the gateway address for that /64. >> - if you want to set up a small network which has multiple subnets, = and >> you can't get IPv6 global unicast addresses from an authority or an >> authoritative sysadmin (prefixed by 001 first three bits), like a >> Provider Independepent, or Provider Assigned addresses - then use >> ULAs to configure your small network. Why would you be unable to get such address space? To the best of my knowledge, all of the RIRs have provisions for granting addresses to non-connected networks. >> - for that small network use ULAs rather than making up some global >> unicast addresses out of a prefix which was not previously = guaranteed >> unique by the administration. ULA is definitely preferable to squatting on bosons, but much in the = same way that the flu is preferable to cancer. >> - dont use 2001:db8:: prefix to assign to that small network - it's a >> Documentation prefix, has sense for humans but not for computers. >> Rather use ULAs, or global unicast addresses if you can get some. Agreed=85 This should be in the document. Especially if we use the example prefix of fd00:2001:db8::/48 as our example ULA. >=20 >=20 >> - dont use ULA with NAT - it doesnt work. >=20 > [Bing] Well, this is the big issue I need to address in the next = version: ) =20 > According to the discussions, I prefer NOT explicitly recommend = against ULA+NAT, but give pros/cons, benefit/drawbacks, and maybe some = operational concerns/warning as well. And I'll separate the NPTv6 with = NAPT, and limit the scope within NPTv6, because it is the only IPv6 NAT = related standard available so far. I would strongly urge you to recommend against NAT. NAT is just too expensive and too destructive to the internet in = general. There is no valid reason not to recommend against it. However, a statement that it "does not work" would be inappropriate. For = better or worse (and I believe mostly worse), it does actually work. It = just has very harmful side effects while it works. Owen From leo.liubing@huawei.com Wed Mar 27 23:23:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7463921F8DC9 for ; Wed, 27 Mar 2013 23:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 bSu+QCJ0ZSla for ; Wed, 27 Mar 2013 23:23:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A17AB21F8D2E for ; Wed, 27 Mar 2013 23:23:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARE08999; Thu, 28 Mar 2013 06:23:40 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 28 Mar 2013 06:23:22 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 28 Mar 2013 06:23:36 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.42]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Thu, 28 Mar 2013 14:23:29 +0800 From: "Liubing (Leo)" To: Owen DeLong Thread-Topic: [v6ops] ULA discussion #BCP or Informational Thread-Index: Ac4qGON521++zMpPThuXXXszdE4eKgAxzkMAAB9FuJD//6ABgP//a4Fg Date: Thu, 28 Mar 2013 06:23:28 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6ECA24@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Azm5 BZah CvOJ DOeY Fqaa JtgF OHd5 O5g4 Q9b0 Rksg V8qU Wfs0 ZGE6 ay74 dOl9 fLbh; 3; YQBsAGUAeABhAG4AZAByAHUALgBwAGUAdAByAGUAcwBjAHUAQABnAG0AYQBpAGwALgBjAG8AbQA7AG8AdwBlAG4AQABkAGUAbABvAG4AZwAuAGMAbwBtADsAdgA2AG8AcABzAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {1B6253C6-9618-4258-9296-927471464770}; bABlAG8ALgBsAGkAdQBiAGkAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Thu, 28 Mar 2013 06:23:22 GMT; UgBFADoAIABbAHYANgBvAHAAcwBdACAAVQBMAEEAIABkAGkAcwBjAHUAcwBzAGkAbwBuACAAIwBCAEMAUAAgAG8AcgAgAEkAbgBmAG8AcgBtAGEAdABpAG8AbgBhAGwA x-cr-puzzleid: {1B6253C6-9618-4258-9296-927471464770} x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 06:23:45 -0000 Hi, Owen Thanks for your comments. Please see inline. Best regards, Bing > >> - don't write ULAs like this: fd::1, because it's not an ULA. The ULA > >> must start with fd00: and not fd:, because whereas the leading 0s ca= n > >> be ommitted the subsequent 0s are significant, in this Western- > >> inspired textual address representation system (like 003 dollars is > >> same value as 3 dollars, but 300 dollars is not the same as 3 > >> dollars). > > > > [Bing] I think fc00:/7 might be more accurate? Although most of the tim= e it > would be fd00:/8, but maybe it is not necessarily to exclude L=3D0. >=20 > There is no valid use of L=3D0 currently. The IETF did not gain consensus= for > that draft and no substitute proposal has emerged or shown any signs of > gaining consensus. IIRC, it was slightly more controversial than the idea= of > routing information in DHCP. [Bing] I understand the L=3D0 situation. But is it necessary to exclude it?= In another word, is fc00:/7 harmful?=20 My concern is that the fc00::/7 form is more compliance to the definition i= n RFC4193. > >> - don't write example ULAs like this: fd00::1 because there seems to b= e > >> only 0s between fd and 1, whereas a real ULA has randomness in that > >> space, to ensure uniqueness. fd00:face:booc::1 is probably a better > >> ULA although a trained eye may notice a surprising coincidence hard > >> to generate randomly. >=20 > Actually, I would recommend that we use fd00:2001:db8::/48 as the example > ULA. I will submit a draft for that update to the Example Prefix RFC. [Bing] I'm not very sure, 2001:db8 is a typical GUA form, will it lead some= confusion about randomness? > >> - dont assign fd00::1/128 address on the default Gateway, even though > >> one is used to assign such in IPv4; the reason same as above - lack > >> of randomness. >=20 > True, but there's nothing wrong with establishing an example ULA prefix > at fd00:2001:db8::/48 and then using fd00:2001:db8::/64 as the first > prefix in that /48 and fd00:2001:db8::1/128 as the gateway address for > that /64. >=20 > >> - if you want to set up a small network which has multiple subnets, an= d > >> you can't get IPv6 global unicast addresses from an authority or an > >> authoritative sysadmin (prefixed by 001 first three bits), like a > >> Provider Independepent, or Provider Assigned addresses - then use > >> ULAs to configure your small network. >=20 > Why would you be unable to get such address space? To the best of my > knowledge, all of the RIRs have provisions for granting addresses to > non-connected networks. [Bing] I guess Alex was talking about some situations lack of money/conditi= ons to apply address space from RIRs/LIRs.=20 > >> - for that small network use ULAs rather than making up some global > >> unicast addresses out of a prefix which was not previously guarantee= d > >> unique by the administration. >=20 > ULA is definitely preferable to squatting on bosons, but much in the same > way that the flu is preferable to cancer. >=20 > >> - dont use 2001:db8:: prefix to assign to that small network - it's a > >> Documentation prefix, has sense for humans but not for computers. > >> Rather use ULAs, or global unicast addresses if you can get some. >=20 > Agreed... This should be in the document. Especially if we use the > example prefix of fd00:2001:db8::/48 as our example ULA. >=20 > > > > > >> - dont use ULA with NAT - it doesnt work. > > > > [Bing] Well, this is the big issue I need to address in the next versio= n: ) > > According to the discussions, I prefer NOT explicitly recommend against > ULA+NAT, but give pros/cons, benefit/drawbacks, and maybe some > operational concerns/warning as well. And I'll separate the NPTv6 with NA= PT, > and limit the scope within NPTv6, because it is the only IPv6 NAT related > standard available so far. >=20 > I would strongly urge you to recommend against NAT. >=20 > NAT is just too expensive and too destructive to the internet in general. > There is no valid reason not to recommend against it. [Bing] A valid reason as I can tell is, when you want independent address s= pace and you cannot or do not want to afford the cost of PI (thinking about= SOHO/SMEs). Since this topic is the controversy focus, later I'll raise another separat= ed thread to talk about what could be possibly consensus. >=20 > However, a statement that it "does not work" would be inappropriate.=20 [Bing] Agreed. >For better or worse (and I believe mostly worse), it does actually work. I= t just has > very harmful side effects while it works. >=20 > Owen From markzzzsmith@yahoo.com.au Thu Mar 28 01:06:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13D821F8C93 for ; Thu, 28 Mar 2013 01:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] 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 ZWi6I276KdCB for ; Thu, 28 Mar 2013 01:06:18 -0700 (PDT) Received: from nm17-vm0.bullet.mail.bf1.yahoo.com (nm17-vm0.bullet.mail.bf1.yahoo.com [98.139.213.157]) by ietfa.amsl.com (Postfix) with SMTP id 16DB221F8AC3 for ; Thu, 28 Mar 2013 01:06:17 -0700 (PDT) Received: from [98.139.215.140] by nm17.bullet.mail.bf1.yahoo.com with NNFMP; 28 Mar 2013 08:06:17 -0000 Received: from [98.139.212.202] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 28 Mar 2013 08:06:17 -0000 Received: from [127.0.0.1] by omp1011.mail.bf1.yahoo.com with NNFMP; 28 Mar 2013 08:06:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 464021.74683.bm@omp1011.mail.bf1.yahoo.com Received: (qmail 73702 invoked by uid 60001); 28 Mar 2013 08:06:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1364457977; bh=y4WMaL1R9oo0VX7W/Vy5CRzsFJJu0A1T2ii3jP+rW4k=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Jt38G2JHfTvytaaNq/W8+qkT8K39URbjimpwr0JSBIVwBhpUjicEmmKCDJyqtbHKisTxgzRe0Mwa3sVD8lp9k8roflQn7OZVGyN4m1RUnovTauNYNcm1vxWb0Pp0iK3WnhfP/9ezdcxItmKKbhqzm+YXMt9Oyl6eZEef3oGDsD0= 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:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cFsImleSN09FDS4XgNNiC30rJQ5/ZaMS9r0iEefrAuqKiGFUtoLIKqUrJGPOXcyF6gPDeHga0R2bEzQQPVuwD1mx6svwT1KPzxPxpIfH+gqaejRYXPS88GT92GtObGqTaVMiFvPX4NCBJULW2I+r/AcotA9FuB/BDY+TTHCYw7c=; X-YMail-OSG: WbnGqYAVM1kaSUzVX49mjxmdQC68tFWIg8tl6WgyIP9mhmg y07L5sAgX0CcjvX47VVn2OlRhmyd1zcJAvl46tLT6UA7Kjm3dgNameMYepsJ 6RPdeZ1BHsoLCy7ghV7g8kkCdsiAe65y23GmbuUZRl7LtKDBLROFDJE71B_R psUs2xL8oKZbd3LxgwmmFfjm4lqz__6TZqDZ8dNhjveqY9BlAHXmJvGk6pMr 2Mxt8_eNqs.MbJ3rGk9ywLn3B_nG90xYw6wYaQA2l3NnVqK4yK0gU9iNDnnL 9aYGUGcVreSMMJezDvEdBckdPzSFOtpsLo_VIYywJFXf6v8ZZNkAfyBVBw_. BaKrNVaceE5APB_XKNGkSQYjJXL30Rz3W1F.BUmzCx6fiqkOiIyJypO5HbHQ NlpQ8aY7K5UB66wQtDvd0bY2WVneQgLinUBBIqUwtyDzN6FzB47huomL9kFP y0EZeW1mMjNc7.Mz6OKCeQhDUFuiGo73HM_8aOT8Fm5YBLlqEkvAklMRE31j Zyres Received: from [150.101.221.237] by web142505.mail.bf1.yahoo.com via HTTP; Thu, 28 Mar 2013 01:06:17 PDT X-Rocket-MIMEInfo: 002.001, CgoKPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gRnJvbTogTG9yZW56byBDb2xpdHRpIDxsb3JlbnpvQGdvb2dsZS5jb20.Cj5UbzogT3dlbiBEZUxvbmcgPG93ZW5AZGVsb25nLmNvbT4gCj5DYzogdjZvcHMgdjZvcHMgV0cgPHY2b3BzQGlldGYub3JnPiAKPlNlbnQ6IFRodXJzZGF5LCAyOCBNYXJjaCAyMDEzIDExOjMxIEFNCj5TdWJqZWN0OiBSZTogW3Y2b3BzXSBJVCdTIE1PU1RMWSBBIFNPTFZFRCBQUk9CTEVNIC0gRnc6IEludGVyZXN0IGluIERIQ1B2NiBSb3V0ZS9EZWZSb3V0ZXIvU3IBMAEBAQE- X-Mailer: YahooMailWebService/0.8.139.530 References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1364411510.8596.YahooMailNeo@web142502.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D9831803D8DB@XCH-BLV-504.nw.nos.boeing.com> <83602E3F-011F-4C90-A130-C82BE38A63FB@delong.com> <804490FF-EB5D-4624-9E88-295BA247191F@delong.com> Message-ID: <1364457977.67128.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Thu, 28 Mar 2013 01:06:17 -0700 (PDT) From: Mark Smith To: Lorenzo Colitti , Owen DeLong MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 08:06:19 -0000 =0A=0A=0A>________________________________=0A> From: Lorenzo Colitti =0A>To: Owen DeLong =0A>Cc: v6ops v6ops WG = =0A>Sent: Thursday, 28 March 2013 11:31 AM=0A>Subject: Re:= [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRou= ter/Src-basedRoute configuration to Client?=0A> =0A>=0A>On Thu, Mar 28, 201= 3 at 9:22 AM, Owen DeLong wrote:=0A>=0A>What functionalit= y would such an option provide that cannot be provided using the Route Info= rmation Option in the RA?=A0=0A>>The combination of that functionality with= deterministic and auditable client addressing?=0A>=0A>=0A>I don't understa= nd that statement. You can have deterministic and auditable addressing with= DHCPv6 today, without having to use DHCPv6 to configure routing.=0A>=0A>= =0A=0A=0AActually, stateful DHCPv6 will only provide auditability for the a= ddresses it hands out. It won't capture information about hosts configured = with static addresses, or hosts that ignore DHCPv6 and just use link-local = addresses for on-link communication. Assuming this auditability is for secu= rity purposes, I'd think stateful DHCPv6 records would be quite inadequate.= DHCPv4 has the same sorts of limitations.=0A=0A=0AThe only way to record a= ll addresses in use on an segment is to observe neighbor discovery messages= , primarily DADs, and once learned, actively probe them using methods simil= ar to NUD to detect when they disappear. If that is still not acceptable, t= hen admission control via e.g. 802.1x, and then isolating authorised client= s in their own virtual point-to-point link with the router (e.g. individual= VLAN with individual /64) would be the way to control who attaches to the = network, and what they can reach.=0A=0A=0A>________________________________= _______________=0A>v6ops mailing list=0A>v6ops@ietf.org=0A>https://www.ietf= .org/mailman/listinfo/v6ops=0A>=0A>=0A>=0A From lorenzo@google.com Thu Mar 28 01:12:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0BCC21F9056 for ; Thu, 28 Mar 2013 01:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.938 X-Spam-Level: X-Spam-Status: No, score=-101.938 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4aAYEXnKC3Z for ; Thu, 28 Mar 2013 01:12:34 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9944821F902E for ; Thu, 28 Mar 2013 01:12:33 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id wo10so6577007obc.39 for ; Thu, 28 Mar 2013 01:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=VIkgqzfTyhmv8llInLuCl5qwjRREWVtyorj8KTnneEY=; b=hBRZ8Kq9oMGrU7z68yzXcZwHQQm8/Cv4tjst//GlYylhMXS0WUxmPi0nyHvdsL950u Ge2mVpqtFroF2H8OSh7uX735hn9fqbpktictTpdU5bjmKxnDZLYL4Q1e5Gxmd+PENcUA W7QBtkbbXVVkhIqFXU1rpyuSeOuuY88UqV9N1LcGH9Itkh+zRjwhp5W7+YCSWBCLSOIJ Wz/unqnTONXLGEYTn+CAI3BsbMSGkjrT++x4P44TQmIWxg0EXnX3vppBvLSjLz46br4N 4EVk/1EvSPPicrFWgYdtBWj5oTAoRgmpMHAXkfGFT6qyRnPNv3ZN73lc4GawXmK019Bw dB1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=VIkgqzfTyhmv8llInLuCl5qwjRREWVtyorj8KTnneEY=; b=YnZBKM/Qxjb6FQDRVBB1l1J+8IqP2P00v11CRl3g3yqVFOia3oS3DrOkxC5plgd3qA iE5sc/y6U823scq+uhWSAITCsku7lo/v5EjCvRof/pjxQJ3nhCXNXtwH5yCD/egdNhqs BPMBcoK4cGhJ1hbyI1bj3O8DoxpE1yEcNuWr7FfunP8VO4U7OvfHuRVmlDek5j3NqxYM wSi8wSnxysCh/SP+ecMwN+65c0vgjkf171MYc0GTsBhJAT7FYwyUTtTD9nfuIJ7bemND PECvjUeiTHbE57Fm3l1NDdkbSIywb9r+JYndS/mP4fS/4dAZR9la89ap6vyWPaTbmlSo wEng== X-Received: by 10.182.132.43 with SMTP id or11mr5010602obb.67.1364458353146; Thu, 28 Mar 2013 01:12:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Thu, 28 Mar 2013 01:12:12 -0700 (PDT) In-Reply-To: <1364457977.67128.YahooMailNeo@web142505.mail.bf1.yahoo.com> References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1364411510.8596.YahooMailNeo@web142502.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D9831803D8DB@XCH-BLV-504.nw.nos.boeing.com> <83602E3F-011F-4C90-A130-C82BE38A63FB@delong.com> <804490FF-EB5D-4624-9E88-295BA247191F@delong.com> <1364457977.67128.YahooMailNeo@web142505.mail.bf1.yahoo.com> From: Lorenzo Colitti Date: Thu, 28 Mar 2013 17:12:12 +0900 Message-ID: To: Mark Smith Content-Type: multipart/alternative; boundary=14dae93a0c1773631304d8f7b7d2 X-Gm-Message-State: ALoCoQk2dgFO0szWsDAJcXo4OqqScB2yxqiQYTyxoR5nTfuKBX8d4GkNGoVpdr0Febm0ScBELA6t7HocfnUtul5QE+m6r2cIohdZ983wmI3Xu6MQ2CdKzGQXvoI+fZOhzm0814YtiAaP9tyKKHhHu06xjGE1X5RbQLatMhxQY8yTaAUVPFsyx4UEkUR2+NU4v4IsGozdNmIO Cc: v6ops v6ops WG Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 08:12:34 -0000 --14dae93a0c1773631304d8f7b7d2 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 28, 2013 at 5:06 PM, Mark Smith wrote: > Actually, stateful DHCPv6 will only provide auditability for the addresses > it hands out. It won't capture information about hosts configured with > static addresses, or hosts that ignore DHCPv6 and just use link-local > addresses for on-link communication. Assuming this auditability is for > security purposes, I'd think stateful DHCPv6 records would be quite > inadequate. DHCPv4 has the same sorts of limitations. > > > The only way to record all addresses in use on an segment is to observe > neighbor discovery messages, primarily DADs, and once learned, actively > probe them using methods similar to NUD to detect when they disappear. If > that is still not acceptable, then admission control via e.g. 802.1x, and > then isolating authorised clients in their own virtual point-to-point link > with the router (e.g. individual VLAN with individual /64) would be the way > to control who attaches to the network, and what they can reach. What he said. --14dae93a0c1773631304d8f7b7d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 28, 2013 at 5:06 PM, Mark Smith <mark= zzzsmith@yahoo.com.au> wrote:
<= div class=3D"gmail_quote">
Actually, stateful DHCPv6 will only provide = auditability for the addresses it hands out. It won't capture informati= on about hosts configured with static addresses, or hosts that ignore DHCPv= 6 and just use link-local addresses for on-link communication. Assuming thi= s auditability is for security purposes, I'd think stateful DHCPv6 reco= rds would be quite inadequate. DHCPv4 has the same sorts of limitations.

The only way to record all addresses in use on an segment is to observe nei= ghbor discovery messages, primarily DADs, and once learned, actively probe = them using methods similar to NUD to detect when they disappear. If that is= still not acceptable, then admission control via e.g. 802.1x, and then iso= lating authorised clients in their own virtual point-to-point link with the= router (e.g. individual VLAN with individual /64) would be the way to cont= rol who attaches to the network, and what they can reach.

What he said.
--14dae93a0c1773631304d8f7b7d2-- From brian.e.carpenter@gmail.com Thu Mar 28 01:21:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9552021F8E4C for ; Thu, 28 Mar 2013 01:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.456 X-Spam-Level: X-Spam-Status: No, score=-100.456 tagged_above=-999 required=5 tests=[AWL=1.235, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, 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 hZfC--B3C4qp for ; Thu, 28 Mar 2013 01:21:49 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8D92321F8FF0 for ; Thu, 28 Mar 2013 01:21:44 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so1307094wgg.12 for ; Thu, 28 Mar 2013 01:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=54IJDtp9s0C01GUp6jH0JhuTehFxav2FLhAlgnImd/Y=; b=yG82wZL+aOuKAwGbg1cyFkXE2gZBrrC/WOpf/U6siXdK+HNvq3aA9c6+U1xQENcXhQ qhyJ7XBzbzKGgE5Q5MuCMG7Mm1mv+o0tnc+KvJYcLaKFOzNVOdLzFnFwgd/tcyHEIADo IPMSx4IbPP4yVR8uCZK6G2ilUpyRnd8NeC9ViWTauBEKJdayantA2NiyAKi+QvtJ0P49 sXOf79PtANRCBx7ECuN+uotAUGq3FPpSxhVdAoa+BZVCD1RRR/69epHi1ge+lYBYcVtb cJEfUVFMNuhVIn8aItgTSdYqRCe0PhV32sMpfibKWBBaj8Ku5r0ycWrN1ObBsoVq+oMQ X7Sg== X-Received: by 10.180.189.205 with SMTP id gk13mr14478425wic.25.1364458903664; Thu, 28 Mar 2013 01:21:43 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-189-148.as13285.net. [2.101.189.148]) by mx.google.com with ESMTPS id g4sm14246209wib.11.2013.03.28.01.21.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Mar 2013 01:21:39 -0700 (PDT) Message-ID: <5153FD9C.60807@gmail.com> Date: Thu, 28 Mar 2013 08:21:48 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1364411510.8596.YahooMailNeo@web142502.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D9831803D8DB@XCH-BLV-504.nw.nos.boeing.com> <83602E3F-011F-4C90-A130-C82BE38A63FB@delong.com> <804490FF-EB5D-4624-9E88-295BA247191F@delong.com> <1364457977.67128.YahooMailNeo@web142505.mail.bf1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops v6ops WG Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 08:21:52 -0000 On 28/03/2013 08:12, Lorenzo Colitti wrote: > On Thu, Mar 28, 2013 at 5:06 PM, Mark Smith wrote: > >> Actually, stateful DHCPv6 will only provide auditability for the addresses >> it hands out. It won't capture information about hosts configured with >> static addresses, or hosts that ignore DHCPv6 and just use link-local >> addresses for on-link communication. Assuming this auditability is for >> security purposes, I'd think stateful DHCPv6 records would be quite >> inadequate. DHCPv4 has the same sorts of limitations. >> >> >> The only way to record all addresses in use on an segment is to observe >> neighbor discovery messages, primarily DADs, and once learned, actively >> probe them using methods similar to NUD to detect when they disappear. If >> that is still not acceptable, then admission control via e.g. 802.1x, and >> then isolating authorised clients in their own virtual point-to-point link >> with the router (e.g. individual VLAN with individual /64) would be the way >> to control who attaches to the network, and what they can reach. > > > What he said. There's this saying in successful retail operations that "the customer is always right [even when wrong]." If IT managers want to manage their networks using DHCPv6, they are right [even if they're wrong]. What we need to analyse are the requirements for route configuration in hosts; then we can figure out how to satisfy those requirements in both RA-style and DHCPv6-style environments. IMHO, of course. Brian From lorenzo@google.com Thu Mar 28 01:24:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623BF21F91AE for ; Thu, 28 Mar 2013 01:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.654 X-Spam-Level: X-Spam-Status: No, score=-102.654 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 QxVrrA07aqVe for ; Thu, 28 Mar 2013 01:24:30 -0700 (PDT) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id E535A21F919D for ; Thu, 28 Mar 2013 01:24:25 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id n12so9697464oag.13 for ; Thu, 28 Mar 2013 01:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=0Gc+VduqKoIjR/P4jNta7YHxd2N9jdP+Hs3NRgC0WQ0=; b=oEuNlre2DiZEspAvZEWQ9Hx/CTDPrFstXE3gMFXY6zzFpjLPhXZWi1nJYjfMo080I1 gsrodREX2R4i8SWKC0HFmGByTE2Aw4+Pqi2Od66PgNLTLC7emz5wLPVWzyS1jsZHnbiA dB+WqMIlvTgSLbWVQLFujYUFT3VO3MsbVmSqH3I4hUC+wm+HtS3qQuqYWsDzrWWObnu8 DcVrFkSQfZMqv4WVG56I83bEcxmWoRooLID1rl47I/0D22o5FaoxHVts5TedfppZ6rum qLNuTwz0EC6OzB19X4+C7RGf+VNlz3QaJaVDx46xrYy4cL7DCFkmG3VXm7pqtk6uMKij 248w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=0Gc+VduqKoIjR/P4jNta7YHxd2N9jdP+Hs3NRgC0WQ0=; b=Je5bVPJ5MEXdmcQ5SH7XVlgRoCQf7DydwqYj24y2vwe3hejs8nCekt67SpjD/IyYB6 PZfaizZaZYN3J6o0x4xW4o9seu8Wdh7eZX8oMAhjsCrBEI2eoT6Ej7aDupwVwBmn7FQ1 uyy1OsHGBTob6HV0fhDWoCz7HMoHj+KKwLdQmTnG6OWxm0lcTX71JGAFkk5zg/E3lnzP XS60FHVLTU3NsWNgzvC8iWvmQw5wl4IWzsmh/PhNvGtqlSFel5+ZJJzaMVDPc9b+pdDW mAtgKiaaoFfmnFvrR16YBK4zgi0Xr8s2nwu3JpPRx4Zsq9H74RDm6sA3FCQBFSwGGf/w j6vg== X-Received: by 10.60.170.140 with SMTP id am12mr129560oec.125.1364459065443; Thu, 28 Mar 2013 01:24:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Thu, 28 Mar 2013 01:24:05 -0700 (PDT) In-Reply-To: <5153FD9C.60807@gmail.com> References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1364411510.8596.YahooMailNeo@web142502.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D9831803D8DB@XCH-BLV-504.nw.nos.boeing.com> <83602E3F-011F-4C90-A130-C82BE38A63FB@delong.com> <804490FF-EB5D-4624-9E88-295BA247191F@delong.com> <1364457977.67128.YahooMailNeo@web142505.mail.bf1.yahoo.com> <5153FD9C.60807@gmail.com> From: Lorenzo Colitti Date: Thu, 28 Mar 2013 17:24:05 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=bcaec54b4812e81e1404d8f7e139 X-Gm-Message-State: ALoCoQnVgrDDf54zEFnAsM9gqTeilrvJaom2hJ1DFuUlfHfABzT6Gbs5TKcVKhBDjPgT1W7cAJkLQr22m4WSj9jwDL1NfR5LsYr0i9MQ+XaWyfQ3/hFDRtqWEkKRzZbrGl/t9AqA8Y5Y/Qd+mET5oEZxmKDS+Bg67NHzU5COy6GaHtQeYLRASaEun4jI2k4nRIBA9BPIPIxU Cc: v6ops v6ops WG Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 08:24:31 -0000 --bcaec54b4812e81e1404d8f7e139 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 28, 2013 at 5:21 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > There's this saying in successful retail operations that "the customer is > always right [even when wrong]." > But fortunately the IETF is not in the business of selling things? --bcaec54b4812e81e1404d8f7e139 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 28, 2013 at 5:21 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
There's this= saying in successful retail operations that "the customer is
always right [even when wrong]."

But fortunately the IETF is not in the business of selling things?
--bcaec54b4812e81e1404d8f7e139-- From ipepelnjak@gmail.com Thu Mar 28 01:47:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BF421F907B for ; Thu, 28 Mar 2013 01:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.734 X-Spam-Level: X-Spam-Status: No, score=0.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.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 ZELqSWITaSFP for ; Thu, 28 Mar 2013 01:47:52 -0700 (PDT) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 79FD221F9068 for ; Thu, 28 Mar 2013 01:47:52 -0700 (PDT) Received: by mail-ea0-f177.google.com with SMTP id q14so1437101eaj.36 for ; Thu, 28 Mar 2013 01:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received: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=aeI+AZA84uwwakxPPpf/FwOhvu5BXCWjeYdHXktLt00=; b=KEqb0/BHil4JXNqzpmpvqnlAJsVgTVrbaUQJIumoas0MyP6rC3N55Qk2QVRkLDsIk9 2cnmV5mYXtMk0yn9gaksg/6vMDJwo0plq5RfQfkeF3n31yanr/CZR95NSmlps6zS2D1g OLyP6OLzdtVnjGzSFQf0MHmQpp3EWGfa4XwIkgpTOxUNwOq8avzp3ymEfIPg0ReEFV0u 8PKa27xD3P7sGZnRfk7Z/0OSJWgF/8pq61W8syUCJSUg+Rd+FyW1+dL7Mu1fwJSZaPm/ 6aI9GThm1QzWhiDFwJxAqMo3cM68qzJGMXQVi5GPgIQExtDeRHFuVGPqknQhazEkNTF1 VnjA== X-Received: by 10.15.111.202 with SMTP id cj50mr24486945eeb.6.1364460471593; Thu, 28 Mar 2013 01:47:51 -0700 (PDT) Received: from PIPINB2009 ([89.142.19.177]) by mx.google.com with ESMTPS id ca4sm36218447eeb.15.2013.03.28.01.47.50 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 28 Mar 2013 01:47:51 -0700 (PDT) From: "Ivan Pepelnjak" To: "'Brian E Carpenter'" , "'Lorenzo Colitti'" References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1364411510.8596.YahooMailNeo@web142502.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D9831803D8DB@XCH-BLV-504.nw.nos.boeing.com> <83602E3F-011F-4C90-A130-C82BE38A63FB@delong.com> <804490FF-EB5D-4624-9E88-295BA247191F@delong.com> <1364457977.67128.YahooMailNeo@web142505.mail.bf1.yahoo.com> <5153FD9C.60807@gmail.com> In-Reply-To: <5153FD9C.60807@gmail.com> Date: Thu, 28 Mar 2013 09:47:49 +0100 Message-ID: <003501ce2b90$ee1d84c0$ca588e40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4rjWhEf4v3/yh1TRqTBwKa8x4v4QAA0Xug Content-Language: sl Cc: 'v6ops v6ops WG' Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 08:47:53 -0000 How about using OpenFlow to push forwarding entries into said hosts? We would solve the "influence the host behavior" problem once and for all times ;) > There's this saying in successful retail operations that "the customer is > always right [even when wrong]." > > If IT managers want to manage their networks using DHCPv6, they are right > [even if they're wrong]. > > What we need to analyse are the requirements for route configuration in > hosts; then we can figure out how to satisfy those requirements in both > RA-style and DHCPv6-style environments. From brian.e.carpenter@gmail.com Thu Mar 28 02:03:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AB521F909C for ; Thu, 28 Mar 2013 02:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.309 X-Spam-Level: X-Spam-Status: No, score=-99.309 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, MANGLED_ATIVAN=2.5, RCVD_ILLEGAL_IP=1.908, 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 sdJntkl8+fug for ; Thu, 28 Mar 2013 02:03:27 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id B7F2F21F901D for ; Thu, 28 Mar 2013 02:03:26 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id a12so1276409wgh.33 for ; Thu, 28 Mar 2013 02:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=R5zLZiZ6B76oXlPTGZGUithwXycQL5urHJjso2K4IOQ=; b=FxYhUydwAm0nb3rTjqG0YthkVbrO1UwGahY2fST60EsIejOuDkTQ7RJMIUmMP0B3tD UmD7RYO2Ma9kIRAKCla2Ug78xacOzmzVc42FzjLWVA2aJdZKotHvQ7Fvc6R58oXB2gmE aiM6qY9KkITxS0AwFAouATWxUJQbqNO7YN+2bn+JbFgUYnvoKyKeoaPzP2CNLLfK940K 7+xC0GG/ze73UF3Qp6eh3XsNFPnPyEbOwwyZ5LBmHCm6q8tA7+cwpk4vMf+nDdxFHn5M A+cU3rvYz6tErbNe6Sgt8yAZr3yhciIihaKOzn1QPYTUYSoTnZYTvsN5w4LaD7M+Ne9I McVg== X-Received: by 10.180.109.82 with SMTP id hq18mr14840728wib.0.1364461405940; Thu, 28 Mar 2013 02:03:25 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-189-148.as13285.net. [2.101.189.148]) by mx.google.com with ESMTPS id h10sm14457181wic.8.2013.03.28.02.03.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Mar 2013 02:03:25 -0700 (PDT) Message-ID: <51540766.7050809@gmail.com> Date: Thu, 28 Mar 2013 09:03:34 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ivan Pepelnjak References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1364411510.8596.YahooMailNeo@web142502.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D9831803D8DB@XCH-BLV-504.nw.nos.boeing.com> <83602E3F-011F-4C90-A130-C82BE38A63FB@delong.com> <804490FF-EB5D-4624-9E88-295BA247191F@delong.com> <1364457977.67128.YahooMailNeo@web142505.mail.bf1.yahoo.com> <5153FD9C.60807@gmail.com> <003501ce2b90$ee1d84c0$ca588e40$@com> In-Reply-To: <003501ce2b90$ee1d84c0$ca588e40$@com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'v6ops v6ops WG' Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 09:03:27 -0000 On 28/03/2013 08:47, Ivan Pepelnjak wrote: > > How about using OpenFlow to push forwarding entries into said hosts? > We would solve the "influence the host behavior" problem once and > for all times ;) > I appreciate the sarcasm, but really, why should the IETF care? Getting hosts to choose the best next-hop in a multi-interface, multi-prefix, multi-protocol world is not a trivial problem. Brian > >> There's this saying in successful retail operations that "the customer is >> always right [even when wrong]." >> >> If IT managers want to manage their networks using DHCPv6, they are right >> [even if they're wrong]. >> >> What we need to analyse are the requirements for route configuration in >> hosts; then we can figure out how to satisfy those requirements in both >> RA-style and DHCPv6-style environments. > > From ipepelnjak@gmail.com Thu Mar 28 02:13:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8964921F8EE6 for ; Thu, 28 Mar 2013 02:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.183 X-Spam-Level: X-Spam-Status: No, score=-0.183 tagged_above=-999 required=5 tests=[AWL=0.916, BAYES_00=-2.599, MANGLED_ATIVAN=2.5, 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 9YO2GzFbXZJx for ; Thu, 28 Mar 2013 02:13:22 -0700 (PDT) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by ietfa.amsl.com (Postfix) with ESMTP id AAF5821F8E55 for ; Thu, 28 Mar 2013 02:13:21 -0700 (PDT) Received: by mail-ee0-f49.google.com with SMTP id d41so4664240eek.22 for ; Thu, 28 Mar 2013 02:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received: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=ikXksdKE0aTtbjl2AOvKsi4bcyCGG9mF8HHamRILWd0=; b=t+wNDbFyCMyrtPcYDya1n8nXQwenpcOr34QH28TnVXN7BY01LN8u1909h36L4R5za8 YV4HibFXi3kQTibdRghL1w14qEyUIDzRRReTHM8xO+C3DAn1/geT+MVenCMEScM7vxRI iVGqhZMYqUJnHiTq4nVtaiD+Z0PbxvIf7pRnj5G2I2E6vJinum2iaXw1HHnnbYqSZrbX 6dRI4FgaFm62q71dwKGxJb6Xv7qm03Jdaiit8FbLx5ZXYp4jUUOXw1OUJ+mRNvF2hH5c LTBiCw/OGmEzHZaOQH2jWdVjveP0hoxY0C5nnxqNtfQSeHBscgLZY3T1jO+YUrWx9s55 lfDA== X-Received: by 10.14.5.6 with SMTP id 6mr65040937eek.42.1364462000466; Thu, 28 Mar 2013 02:13:20 -0700 (PDT) Received: from PIPINB2009 ([89.142.19.177]) by mx.google.com with ESMTPS id f47sm36355395eep.13.2013.03.28.02.13.19 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 28 Mar 2013 02:13:19 -0700 (PDT) From: "Ivan Pepelnjak" To: "'Brian E Carpenter'" References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1364411510.8596.YahooMailNeo@web142502.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D9831803D8DB@XCH-BLV-504.nw.nos.boeing.com> <83602E3F-011F-4C90-A130-C82BE38A63FB@delong.com> <804490FF-EB5D-4624-9E88-295BA247191F@delong.com> <1364457977.67128.YahooMailNeo@web142505.mail.bf1.yahoo.com> <5153FD9C.60807@gmail.com> <003501ce2b90$ee1d84c0$ca588e40$@com> <51540766.7050809@gmail.com> In-Reply-To: <51540766.7050809@gmail.com> Date: Thu, 28 Mar 2013 10:13:18 +0100 Message-ID: <004401ce2b94$7d6be420$7843ac60$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4rkxtjpu/m0LCyT2Kq3Nv/zgMXzwAAQR2Q Content-Language: sl Cc: 'v6ops v6ops WG' Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 09:13:22 -0000 > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >=20 > On 28/03/2013 08:47, Ivan Pepelnjak wrote: > > > > How about using OpenFlow to push forwarding entries into said = hosts? > > We would solve the "influence the host behavior" problem once and > > for all times ;) > > >=20 > I appreciate the sarcasm, but really, why should the IETF care? >=20 > Getting hosts to choose the best next-hop in a multi-interface, multi- > prefix, multi-protocol world is not a trivial problem. And there will always be someone asking for the next knob, eventually = resulting in a flowspec-like baroque construct. Maybe we should just = repackage RFC 5575 in DHCPv6 options format? ;=3D) Ivan From randy@psg.com Thu Mar 28 02:48:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90CF21F8FF3 for ; Thu, 28 Mar 2013 02:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 3o1v5jgv98jI for ; Thu, 28 Mar 2013 02:48:09 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 80C9A21F8FE5 for ; Thu, 28 Mar 2013 02:48:09 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UL9RF-0009Sw-F3; Thu, 28 Mar 2013 09:48:05 +0000 Date: Thu, 28 Mar 2013 18:48:03 +0900 Message-ID: From: Randy Bush To: Lorenzo Colitti In-Reply-To: References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1364411510.8596.YahooMailNeo@web142502.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D9831803D8DB@XCH-BLV-504.nw.nos.boeing.com> <83602E3F-011F-4C90-A130-C82BE38A63FB@delong.com> <804490FF-EB5D-4624-9E88-295BA247191F@delong.com> <1364457977.67128.YahooMailNeo@web142505.mail.bf1.yahoo.com> <5153FD9C.60807@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: v6ops v6ops WG Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 09:48:10 -0000 >> There's this saying in successful retail operations that "the customer is >> always right [even when wrong]." > But fortunately the IETF is not in the business of selling things? as is stunningly demonstrated by the extent of ipv6 deployment randy From swmike@swm.pp.se Thu Mar 28 03:18:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C587B21F92BB for ; Thu, 28 Mar 2013 03:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.114, 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 j5kNOS0LHQwv for ; Thu, 28 Mar 2013 03:18:33 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id CE06521F9292 for ; Thu, 28 Mar 2013 03:18:32 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8E9A99E; Thu, 28 Mar 2013 11:18:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 82D269C; Thu, 28 Mar 2013 11:18:31 +0100 (CET) Date: Thu, 28 Mar 2013 11:18:31 +0100 (CET) From: Mikael Abrahamsson To: Mark Smith In-Reply-To: <1364457977.67128.YahooMailNeo@web142505.mail.bf1.yahoo.com> Message-ID: References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1364411510.8596.YahooMailNeo@web142502.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D9831803D8DB@XCH-BLV-504.nw.nos.boeing.com> <83602E3F-011F-4C90-A130-C82BE38A63FB@delong.com> <804490FF-EB5D-4624-9E88-295BA247191F@delong.com> <1364457977.67128.YahooMailNeo@web142505.mail.bf1.yahoo.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops v6ops WG Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 10:18:33 -0000 On Thu, 28 Mar 2013, Mark Smith wrote: > The only way to record all addresses in use on an segment is to observe > neighbor discovery messages, primarily DADs, and once learned, actively > probe them using methods similar to NUD to detect when they disappear. > If that is still not acceptable, then admission control via e.g. 802.1x, > and then isolating authorised clients in their own virtual > point-to-point link with the router (e.g. individual VLAN with > individual /64) would be the way to control who attaches to the network, > and what they can reach. I'd imagine doing similar to DHCP option 82 and using SAVI functionality in the L2 access layer actually gives good tracability. -- Mikael Abrahamsson email: swmike@swm.pp.se From rajiva@cisco.com Thu Mar 28 03:26:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0516021F92BE for ; Thu, 28 Mar 2013 03:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.114 X-Spam-Level: X-Spam-Status: No, score=-9.114 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XqcfsW3hr-p for ; Thu, 28 Mar 2013 03:26:54 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D70A321F90DB for ; Thu, 28 Mar 2013 03:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10534; q=dns/txt; s=iport; t=1364466414; x=1365676014; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WoXnjydOgm2wJlI5v3DdS2y08E5BTko5pkxamuWsKGQ=; b=NYj44t1R+7de/TGJumdwhpLVzVx9tdG3ileGh4fTUjoVst6yq1RXlzWT dxX/0M35QI8DNF3PhDGyCsgjgfYjggybJdqeWW8HctVrFP4m24FuqqxGV Q7bIGBMvbzrRTJAyGFf7drtYDPnjD5pdazfta2v01X7ji+U6Q+oymYcRg s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAFAKQaVFGtJV2a/2dsb2JhbABDgkN3tjoBiCqBAxZ0gh8BAQEEAQEBawsQAgEIEQQBASQEBycLFAkIAgQOBYgCAw8MvmeCTol6gkUHBAeCX2EDlQuBXIEfik2FG4FVgTY X-IronPort-AV: E=Sophos;i="4.84,925,1355097600"; d="scan'208,217";a="192410698" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 28 Mar 2013 10:26:46 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2SAQkPE026782 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Mar 2013 10:26:46 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.72]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Thu, 28 Mar 2013 05:26:46 -0500 From: "Rajiv Asati (rajiva)" To: Mark Smith Thread-Topic: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? Thread-Index: AQHOK4sftXkxP7Zcs0mVHJof9Ju2oZi65mi+ Date: Thu, 28 Mar 2013 10:26:45 +0000 Message-ID: <0D6FF6F0-2682-456A-B4DE-B875D46E2286@cisco.com> References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1364411510.8596.YahooMailNeo@web142502.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D9831803D8DB@XCH-BLV-504.nw.nos.boeing.com> <83602E3F-011F-4C90-A130-C82BE38A63FB@delong.com> <804490FF-EB5D-4624-9E88-295BA247191F@delong.com> , <1364457977.67128.YahooMailNeo@web142505.mail.bf1.yahoo.com> In-Reply-To: <1364457977.67128.YahooMailNeo@web142505.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_0D6FF6F02682456AB4DEB875D46E2286ciscocom_" MIME-Version: 1.0 Cc: v6ops v6ops WG Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 10:26:55 -0000 --_000_0D6FF6F02682456AB4DEB875D46E2286ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The only way to record all addresses in use on an segment is to observe nei= ghbor discovery messages, primarily DADs, and once learned, actively probe = them using methods similar to NUD to I agree. And just let the first hope router (or even switch) export the bin= dings to the DHCP server where this database almost always existed. http://tools.ietf.org/html/draft-asati-dhc-ipv6-autoconfig-address-tracking= -00 http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-02 Cheers, Rajiv Sent from my Phone On Mar 28, 2013, at 4:06 PM, "Mark Smith" > wrote: ________________________________ From: Lorenzo Colitti > To: Owen DeLong > Cc: v6ops v6ops WG > Sent: Thursday, 28 March 2013 11:31 AM Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 = Route/DefRouter/Src-basedRoute configuration to Client? On Thu, Mar 28, 2013 at 9:22 AM, Owen DeLong > wrote: What functionality would such an option provide that cannot be provided usi= ng the Route Information Option in the RA? The combination of that functionality with deterministic and auditable clie= nt addressing? I don't understand that statement. You can have deterministic and auditable= addressing with DHCPv6 today, without having to use DHCPv6 to configure ro= uting. Actually, stateful DHCPv6 will only provide auditability for the addresses = it hands out. It won't capture information about hosts configured with stat= ic addresses, or hosts that ignore DHCPv6 and just use link-local addresses= for on-link communication. Assuming this auditability is for security purp= oses, I'd think stateful DHCPv6 records would be quite inadequate. DHCPv4 h= as the same sorts of limitations. The only way to record all addresses in use on an segment is to observe nei= ghbor discovery messages, primarily DADs, and once learned, actively probe = them using methods similar to NUD to detect when they disappear. If that is= still not acceptable, then admission control via e.g. 802.1x, and then iso= lating authorised clients in their own virtual point-to-point link with the= router (e.g. individual VLAN with individual /64) would be the way to cont= rol who attaches to the network, and what they can reach. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_0D6FF6F02682456AB4DEB875D46E2286ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The only way to record all addresses in use on an segment is to observe nei= ghbor discovery messages, primarily DADs, and once learned, actively probe = them using methods similar to NUD to

I agree. And just let the first hope router (or even switch) export the bin= dings to the DHCP server where this database almost always existed. 


Cheers,
Rajiv

Sent from my Phone

On Mar 28, 2013, at 4:06 PM, "Mark Smith" <markzzzsmith@yahoo.com.au> wrote:




________________________________
From: Lorenzo Colitti <lorenzo@google.com>
To: Owen DeLong <owen@delong.com>
Cc: v6ops v6ops WG <v6ops@ietf.org>
Sent: Thursday, 28 March 2013 11:31 AM
Subject: Re: [v6ops] IT'S MOSTLY A SOLVED P= ROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuratio= n to Client?


On Thu, Mar 28, 2013 at 9:22 AM, Owen DeLon= g <owen@delong.com> wrote:

What functionality would such an option pro= vide that cannot be provided using the Route Information Option in the RA?&= nbsp;
The combination of that functionality with = deterministic and auditable client addressing?


I don't understand that statement. You can = have deterministic and auditable addressing with DHCPv6 today, without havi= ng to use DHCPv6 to configure routing.




Actually, stateful DHCPv6 will only provide auditability for the addr= esses it hands out. It won't capture information about hosts configured wit= h static addresses, or hosts that ignore DHCPv6 and just use link-local add= resses for on-link communication. Assuming this auditability is for security purposes, I'd think stateful DH= CPv6 records would be quite inadequate. DHCPv4 has the same sorts of limita= tions.


The only way to record all addresses in use on an segment is to obser= ve neighbor discovery messages, primarily DADs, and once learned, actively = probe them using methods similar to NUD to detect when they disappear. If t= hat is still not acceptable, then admission control via e.g. 802.1x, and then isolating authorised clients i= n their own virtual point-to-point link with the router (e.g. individual VL= AN with individual /64) would be the way to control who attaches to the net= work, and what they can reach.


___________________________________________= ____
v6ops mailing list
v6ops@iet= f.org
https://www.ietf.org/mailman/listinfo/v6ops




_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.i= etf.org/mailman/listinfo/v6ops
--_000_0D6FF6F02682456AB4DEB875D46E2286ciscocom_-- From v6ops@globis.net Thu Mar 28 03:55:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B2321F8BAE for ; Thu, 28 Mar 2013 03:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] 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 8NNj83PqfKED for ; Thu, 28 Mar 2013 03:55:24 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id E82B721F8BA1 for ; Thu, 28 Mar 2013 03:55:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 301A38700B6; Thu, 28 Mar 2013 11:55:08 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVC+EXwMxpCC; Thu, 28 Mar 2013 11:54:39 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 3054487007F; Thu, 28 Mar 2013 11:54:39 +0100 (CET) Message-ID: <51542169.5050406@globis.net> Date: Thu, 28 Mar 2013 11:54:33 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Brian E Carpenter References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1364411510.8596.YahooMailNeo@web142502.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D9831803D8DB@XCH-BLV-504.nw.nos.boeing.com> <83602E3F-011F-4C90-A130-C82BE38A63FB@delong.com> <804490FF-EB5D-4624-9E88-295BA247191F@delong.com> <1364457977.67128.YahooMailNeo@web142505.mail.bf1.yahoo.com> <5153FD9C.60807@gmail.com> In-Reply-To: <5153FD9C.60807@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops v6ops WG Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 10:55:25 -0000 Brian E Carpenter wrote: > On 28/03/2013 08:12, Lorenzo Colitti wrote: >> On Thu, Mar 28, 2013 at 5:06 PM, Mark Smith wrote: >> >>> Actually, stateful DHCPv6 will only provide auditability for the addresses >>> it hands out. It won't capture information about hosts configured with >>> static addresses, or hosts that ignore DHCPv6 and just use link-local >>> addresses for on-link communication. Assuming this auditability is for >>> security purposes, I'd think stateful DHCPv6 records would be quite >>> inadequate. DHCPv4 has the same sorts of limitations. >>> >>> >>> The only way to record all addresses in use on an segment is to observe >>> neighbor discovery messages, primarily DADs, and once learned, actively >>> probe them using methods similar to NUD to detect when they disappear. If >>> that is still not acceptable, then admission control via e.g. 802.1x, and >>> then isolating authorised clients in their own virtual point-to-point link >>> with the router (e.g. individual VLAN with individual /64) would be the way >>> to control who attaches to the network, and what they can reach. >> What he said. > > There's this saying in successful retail operations that "the customer is > always right [even when wrong]." > > If IT managers want to manage their networks using DHCPv6, they are right > [even if they're wrong]. > > What we need to analyse are the requirements for route configuration in > hosts; then we can figure out how to satisfy those requirements in both > RA-style and DHCPv6-style environments. > > IMHO, of course. > > Brian > Agreed. If you just count the number of current drafts in various WGs that incorporate distribution of policy or other information from a router/infrastructure to a mobile end node, we clearly need a generic mechanism for that. I frankly don't care about the details of the transport, but no-one can deny that RA has very limited transmission capacity, which will be used up very quickly once policy tables have to be distributed. It also places a hard link between upgrading all infra and all end nodes in order to introduce anything new. Putting any technical arguments aside (this is after all supposedly more of an operations list) if I go to the CFO and say, hey we've got this great feature and we can implement it by: 1) buying new switch hardware (write off period 7-12 years and we've just upgraded) 2) upgrading the software of all of our switches and all of our end nodes before we can roll out the first feature company-wide to support travelling users (3-5 year investment cycle, or 1 year project to upgrade everything) 3) Investing a small delta in a generic transport for hand off of management information between our infra and our end nodes (where the transport is configured once by the switch operator and the end node operator, and where the content of the management information is centrally managed by a small team responsible for end node services, and by the way we already have this IPAM solution in place for IPv4 so we can leverage that, and the trust solution is also in place via Active Directory so we can leverage that too) 4) sticking with IPv4 and sticking plasters and proxy.pac configs etc. but having to increase team size to stay on top of changes or not being able to perform M&A or expansion. I know which one he will choose. From Ted.Lemon@nominum.com Thu Mar 28 07:59:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9AE21F8B8F for ; Thu, 28 Mar 2013 07:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-SkETkZxAYB for ; Thu, 28 Mar 2013 07:59:27 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 0B91D21F8B65 for ; Thu, 28 Mar 2013 07:59:27 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUVRaziP4+WVYhh6yKwqcSRU5Upo+xpzJ@postini.com; Thu, 28 Mar 2013 07:59:27 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7EE5C1B8094 for ; Thu, 28 Mar 2013 07:59:26 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 759A819005C; Thu, 28 Mar 2013 07:59:26 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 28 Mar 2013 07:59:26 -0700 From: Ted Lemon To: Owen DeLong Thread-Topic: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? Thread-Index: AQHOK2+uoqY6K2NqJkWi/DCmjQPco5i7qCcA Date: Thu, 28 Mar 2013 14:59:26 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775124DB1@mbx-01.win.nominum.com> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <4FC37E442D05A748896589E468752CAA0A671F49@PWN401EA160.ent.corp.bcbsm.com> <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> <51532AEF.2030702@dougbarton.us> <0FACA054-11D6-41D3-9ADB-0EFC7E583415@muada.com> <8D23D4052ABE7A4490E77B1A012B6307751240AF@mbx-01.win.nominum.com> <844D2086-E10B-4393-BE80-D1E041B8BD8C@delong.com> In-Reply-To: <844D2086-E10B-4393-BE80-D1E041B8BD8C@delong.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: <14CDA65D903B5F4988B0586E0A1FFE11@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 14:59:27 -0000 On Mar 28, 2013, at 5:45 AM, Owen DeLong wrote: > DHCPv6 support was added in Lion. I thought stateful didn't come in until Mountain Lion, but it doesn't reall= y matter=97the point is that it wasn't the IETF that delayed this; it was a= n internal architectural debate at Apple; a debate that actually had nothin= g to do with the question of default routes in DHCP. From iljitsch@muada.com Thu Mar 28 09:04:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAD421F90CE for ; Thu, 28 Mar 2013 09:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gldk8zaa86-l for ; Thu, 28 Mar 2013 09:04:43 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 4312621F8491 for ; Thu, 28 Mar 2013 09:04:43 -0700 (PDT) Received: from [IPv6:2001:470:1f0b:1289:dd2f:f185:bff0:dd82] ([IPv6:2001:470:1f0b:1289:dd2f:f185:bff0:dd82]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2SFxbI8047913 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Mar 2013 16:59:38 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum Date: Thu, 28 Mar 2013 17:04:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130328155646.15588.7427.idtracker@ietfa.amsl.com> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1499) Cc: "draft-steffann-tunnels@tools.ietf.org" Subject: [v6ops] draft-steffann-tunnels-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 16:04:44 -0000 Hi all, We've incorporated a number of comments. Please have a look (the diff is = handy) and see if everything is to your liking. I think I put in all the = names of people who reviewed or had significant comments in the = acknowledgments, let us know if I overlooked anyone. > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > Title : A Comparison of IPv6 over IPv4 Tunnel = Mechanisms > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-steffann-tunnels > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-steffann-tunnels-02 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-steffann-tunnels-02 From Fred.L.Templin@boeing.com Thu Mar 28 09:19:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E1121F90D9 for ; Thu, 28 Mar 2013 09:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 CU7mHI4JoZZw for ; Thu, 28 Mar 2013 09:19:04 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9FF21F90D4 for ; Thu, 28 Mar 2013 09:19:04 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r2SGJ3eV001344 for ; Thu, 28 Mar 2013 09:19:03 -0700 Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r2SGJ2Nm001319 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 28 Mar 2013 09:19:02 -0700 Received: from XCH-BLV-205.nw.nos.boeing.com (10.57.37.61) by XCH-NWHT-06.nw.nos.boeing.com (130.247.25.110) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 28 Mar 2013 09:19:02 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.119]) by XCH-BLV-205.nw.nos.boeing.com ([169.254.5.17]) with mapi id 14.02.0328.011; Thu, 28 Mar 2013 09:19:01 -0700 From: "Templin, Fred L" To: Iljitsch van Beijnum , "v6ops@ietf.org WG" Thread-Topic: [v6ops] draft-steffann-tunnels-02.txt Thread-Index: AQHOK84tEXstNLJQv0OtriFHrCBoZZi7RzKg Date: Thu, 28 Mar 2013 16:19:01 +0000 Message-ID: <2134F8430051B64F815C691A62D9831803F99C@XCH-BLV-504.nw.nos.boeing.com> References: <20130328155646.15588.7427.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "draft-steffann-tunnels@tools.ietf.org" Subject: Re: [v6ops] draft-steffann-tunnels-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 16:19:04 -0000 Hi Iljitsch, In the diffs, I see: Although SEAL [RFC5320] and related protocols (such as VET, RANGER =20 and IRON) are capable of tunneling IPv6 over IPv4, these protocols =20 are not discussed in this document because their scope goes well =20 beyond basic IPv6-in-IPv4 tunneling." However, the same is true of LISP (which is looking at IPv4-in-IPv4 in its current phases). Do you want to de-emphasize LISP also? Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Iljitsch van Beijnum > Sent: Thursday, March 28, 2013 9:05 AM > To: v6ops@ietf.org WG > Cc: draft-steffann-tunnels@tools.ietf.org > Subject: [v6ops] draft-steffann-tunnels-02.txt >=20 > Hi all, >=20 > We've incorporated a number of comments. Please have a look (the diff is > handy) and see if everything is to your liking. I think I put in all the > names of people who reviewed or had significant comments in the > acknowledgments, let us know if I overlooked anyone. >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > > Title : A Comparison of IPv6 over IPv4 Tunnel Mechanisms >=20 > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-steffann-tunnels >=20 > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-steffann-tunnels-02 >=20 > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-steffann-tunnels-02 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From alexandru.petrescu@gmail.com Thu Mar 28 10:15:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9400B21F8B98 for ; Thu, 28 Mar 2013 10:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.38 X-Spam-Level: X-Spam-Status: No, score=-9.38 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_26=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ancdHNQxV8Eu for ; Thu, 28 Mar 2013 10:15:13 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 73CD521F8B49 for ; Thu, 28 Mar 2013 10:15:12 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2SHF42K007382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Mar 2013 18:15:04 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2SHF3XF031416; Thu, 28 Mar 2013 18:15:04 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2SHExId003893; Thu, 28 Mar 2013 18:15:03 +0100 Message-ID: <51547A5C.8030409@gmail.com> Date: Thu, 28 Mar 2013 18:14:04 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Owen DeLong References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 17:15:15 -0000 Le 28/03/2013 05:53, Owen DeLong a écrit : > > On Mar 27, 2013, at 8:18 PM, Liubing (Leo) wrote: > >> Hi, Alex >> >> Thanks for the detailed suggestion, they are good operational concerns. Right now I haven't figured out whether to include these fine granularity considerations into the general guidance. But I'll consider them in the next version. >> >> Some other replies inline as below. >> >>> I think it is good to go towards a practice like this: >>> >>> - don't write ULAs like this: fd::1, because it's not an ULA. The ULA >>> must start with fd00: and not fd:, because whereas the leading 0s can >>> be ommitted the subsequent 0s are significant, in this Western- >>> inspired textual address representation system (like 003 dollars is >>> same value as 3 dollars, but 300 dollars is not the same as 3 >>> dollars). >> >> [Bing] I think fc00:/7 might be more accurate? Although most of the time it would be fd00:/8, but maybe it is not necessarily to exclude L=0. > > There is no valid use of L=0 currently. The IETF did not gain consensus for > that draft and no substitute proposal has emerged or shown any signs of > gaining consensus. IIRC, it was slightly more controversial than the idea of > routing information in DHCP. Ok, the RFC says "L==0 may be defined in the future" ; probably we're not yet there. >>> - don't write example ULAs like this: fd00::1 because there seems to be >>> only 0s between fd and 1, whereas a real ULA has randomness in that >>> space, to ensure uniqueness. fd00:face:booc::1 is probably a better >>> ULA although a trained eye may notice a surprising coincidence hard >>> to generate randomly. > > Actually, I would recommend that we use fd00:2001:db8::/48 as the example > ULA. I will submit a draft for that update to the Example Prefix RFC. Sounds a reasonable idea to say fd00:2001:db8::/48 to be the Documentation ULA. I am interested if a draft gets written, it could be very short. At the same time, I wonder how much right are we to agree that a real ULA is always FD00::something. I mean the presence of these two 00 digits. I mean it is also correct to say that this is a ULA prefix: FD79:0D81:183C:D1A0::/59 Right? (for information this is generated using the ULA RFC suggested method in section 3.2.2, but using the VIN VF2R97K9XN87R9869 instead of an EUI-64 (because we didnt know _which_ EUI-64 of the vehicle to use). >>> - dont assign fd00::1/128 address on the default Gateway, even though >>> one is used to assign such in IPv4; the reason same as above - lack >>> of randomness. > > True, but there's nothing wrong with establishing an example ULA prefix > at fd00:2001:db8::/48 and then using fd00:2001:db8::/64 as the first > prefix in that /48 and fd00:2001:db8::1/128 as the gateway address for > that /64. Right. >>> - if you want to set up a small network which has multiple subnets, and >>> you can't get IPv6 global unicast addresses from an authority or an >>> authoritative sysadmin (prefixed by 001 first three bits), like a >>> Provider Independepent, or Provider Assigned addresses - then use >>> ULAs to configure your small network. > > Why would you be unable to get such address space? To the best of my > knowledge, all of the RIRs have provisions for granting addresses to > non-connected networks. I have never tried to ask RIRs directly but I have doubts. In the past I usually asked the operator of the Internet line (T1, E2, etc.) to provide me IPv4 Class C or better - I had to insist and spend time to get Class C. I thought that an end user (like a vehicle manufacturer) would not be in a position to ask RIR directly. I guess it could cost a lot of money to ask for as many IPv6 subnets as VIN offers to that manufacturer. Do you mean that a person like in my position (I am not an ISP, nor a IXP) could ask RIR for e.g. a 61bit space? (i.e. asking a /3 prefix)? (sorry I bring vehicle in the picture, just to illustrate one particular need for ULAs that I think will grow - one single vehicle manufacturer by definition and without paying has the right to VIN space which roughly translates into 61bit space). >>> - for that small network use ULAs rather than making up some global >>> unicast addresses out of a prefix which was not previously guaranteed >>> unique by the administration. > > ULA is definitely preferable to squatting on bosons, but much in the same > way that the flu is preferable to cancer. Well, I would be careful with the first statement. I am not sure there are enough IPv6 prefixes available to put one on each boson (if that boson had Interface ID of length 64). >>> - dont use 2001:db8:: prefix to assign to that small network - it's a >>> Documentation prefix, has sense for humans but not for computers. >>> Rather use ULAs, or global unicast addresses if you can get some. > > Agreed… This should be in the document. Especially if we use the > example prefix of fd00:2001:db8::/48 as our example ULA. The ULA Documentation prefix is a good idea. It allows people to talk about it meaningfully. >>> - dont use ULA with NAT - it doesnt work. >> >> [Bing] Well, this is the big issue I need to address in the next version: ) >> According to the discussions, I prefer NOT explicitly recommend against ULA+NAT, but give pros/cons, benefit/drawbacks, and maybe some operational concerns/warning as well. And I'll separate the NPTv6 with NAPT, and limit the scope within NPTv6, because it is the only IPv6 NAT related standard available so far. > > I would strongly urge you to recommend against NAT. > > NAT is just too expensive and too destructive to the internet in general. There is no valid reason not to recommend against it. > > > However, a statement that it "does not work" would be inappropriate. > For better or worse (and I believe mostly worse), it does actually > work. The situation could be improved. I think it would be easy to locate the ip6tables MASQUERADE C code and add a if condition by which if ULA then don't rewrite. Then submit to kernel maintainers and suggest inclusion in mainline. It's the same as with link-local addressees - packets whose src/dst are such dont get forwarded, by a simple rule in the C code, in agreement with RFC. Alex > It just has very harmful side effects while it works. > > Owen > > > From alexandru.petrescu@gmail.com Thu Mar 28 10:18:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8718221F90F4 for ; Thu, 28 Mar 2013 10:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.661 X-Spam-Level: X-Spam-Status: No, score=-9.661 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VszDcyqNeddV for ; Thu, 28 Mar 2013 10:18:50 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2370121F8B49 for ; Thu, 28 Mar 2013 10:18:49 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2SHIaln011285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Mar 2013 18:18:36 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2SHIZvW032364; Thu, 28 Mar 2013 18:18:36 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2SHIYNj005446; Thu, 28 Mar 2013 18:18:35 +0100 Message-ID: <51547B33.2060701@gmail.com> Date: Thu, 28 Mar 2013 18:17:39 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Liubing (Leo)" References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6ECA24@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6ECA24@nkgeml506-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 17:18:53 -0000 Le 28/03/2013 07:23, Liubing (Leo) a écrit : > Hi, Owen > > Thanks for your comments. Please see inline. > > Best regards, Bing > >>>> - don't write ULAs like this: fd::1, because it's not an ULA. >>>> The ULA must start with fd00: and not fd:, because whereas the >>>> leading 0s can be ommitted the subsequent 0s are significant, >>>> in this Western- inspired textual address representation system >>>> (like 003 dollars is same value as 3 dollars, but 300 dollars >>>> is not the same as 3 dollars). >>> >>> [Bing] I think fc00:/7 might be more accurate? Although most of >>> the time it >> would be fd00:/8, but maybe it is not necessarily to exclude L=0. >> >> There is no valid use of L=0 currently. The IETF did not gain >> consensus for that draft and no substitute proposal has emerged or >> shown any signs of gaining consensus. IIRC, it was slightly more >> controversial than the idea of routing information in DHCP. > > [Bing] I understand the L=0 situation. But is it necessary to exclude > it? In another word, is fc00:/7 harmful? My concern is that the > fc00::/7 form is more compliance to the definition in RFC4193. Right... >>>> - don't write example ULAs like this: fd00::1 because there >>>> seems to be only 0s between fd and 1, whereas a real ULA has >>>> randomness in that space, to ensure uniqueness. >>>> fd00:face:booc::1 is probably a better ULA although a trained >>>> eye may notice a surprising coincidence hard to generate >>>> randomly. >> >> Actually, I would recommend that we use fd00:2001:db8::/48 as the >> example ULA. I will submit a draft for that update to the Example >> Prefix RFC. > > [Bing] I'm not very sure, 2001:db8 is a typical GUA form, will it > lead some confusion about randomness? Hm. But we'd still need a means to talk example ULAs, draw on a board, etc. I wouldn't draw something that says 2001:db8:: is a ULA. >>>> - dont assign fd00::1/128 address on the default Gateway, even >>>> though one is used to assign such in IPv4; the reason same as >>>> above - lack of randomness. >> >> True, but there's nothing wrong with establishing an example ULA >> prefix at fd00:2001:db8::/48 and then using fd00:2001:db8::/64 as >> the first prefix in that /48 and fd00:2001:db8::1/128 as the >> gateway address for that /64. >> >>>> - if you want to set up a small network which has multiple >>>> subnets, and you can't get IPv6 global unicast addresses from >>>> an authority or an authoritative sysadmin (prefixed by 001 >>>> first three bits), like a Provider Independepent, or Provider >>>> Assigned addresses - then use ULAs to configure your small >>>> network. >> >> Why would you be unable to get such address space? To the best of >> my knowledge, all of the RIRs have provisions for granting >> addresses to non-connected networks. > > [Bing] I guess Alex was talking about some situations lack of > money/conditions to apply address space from RIRs/LIRs. Lack of knowledge also. I dont know which RIRs/LIRs should I ask? Do they have a formal procedure? Does it cost a lot of money? How much maximum could I get if I were a vehicle manufacturer? Alex >>>> - for that small network use ULAs rather than making up some >>>> global unicast addresses out of a prefix which was not >>>> previously guaranteed unique by the administration. >> >> ULA is definitely preferable to squatting on bosons, but much in >> the same way that the flu is preferable to cancer. >> >>>> - dont use 2001:db8:: prefix to assign to that small network - >>>> it's a Documentation prefix, has sense for humans but not for >>>> computers. Rather use ULAs, or global unicast addresses if you >>>> can get some. >> >> Agreed... This should be in the document. Especially if we use the >> example prefix of fd00:2001:db8::/48 as our example ULA. >> >>> >>> >>>> - dont use ULA with NAT - it doesnt work. >>> >>> [Bing] Well, this is the big issue I need to address in the next >>> version: ) According to the discussions, I prefer NOT explicitly >>> recommend against >> ULA+NAT, but give pros/cons, benefit/drawbacks, and maybe some >> operational concerns/warning as well. And I'll separate the NPTv6 >> with NAPT, and limit the scope within NPTv6, because it is the only >> IPv6 NAT related standard available so far. >> >> I would strongly urge you to recommend against NAT. >> >> NAT is just too expensive and too destructive to the internet in >> general. There is no valid reason not to recommend against it. > > [Bing] A valid reason as I can tell is, when you want independent > address space and you cannot or do not want to afford the cost of PI > (thinking about SOHO/SMEs). Since this topic is the controversy > focus, later I'll raise another separated thread to talk about what > could be possibly consensus. > >> >> However, a statement that it "does not work" would be >> inappropriate. > [Bing] Agreed. > >> For better or worse (and I believe mostly worse), it does actually >> work. It just has very harmful side effects while it works. >> >> Owen > > > From mpounsett@afilias.info Thu Mar 28 10:44:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61CF221F8F1F for ; Thu, 28 Mar 2013 10:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YXlZCHrQuzG for ; Thu, 28 Mar 2013 10:44:10 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id C9E5D21F8EBC for ; Thu, 28 Mar 2013 10:44:10 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1ULGry-0003e0-44 for v6ops@ietf.org; Thu, 28 Mar 2013 17:44:10 +0000 Received: from mail-qc0-f200.google.com ([209.85.216.200]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1ULGry-0002gu-3o for v6ops@ietf.org; Thu, 28 Mar 2013 17:44:10 +0000 Received: by mail-qc0-f200.google.com with SMTP id j34so12344180qco.3 for ; Thu, 28 Mar 2013 10:44:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ftmXhSfLwWjVyQEJJBAuDYPXUnqCOABux0ihZ96sbjE=; b=b3uCG53s8OqRk807n/13ubna0+L0MeXEldVpDT2FHvb1BQhApUGETM9LJvr4njwBm2 32c5DFBKzHlSuDbpHRr3sjSu/SFlX2bdSc1xSXIXE+uO4KXy57Q1jVrI0un/La2ipI5g 6iR9f2/tPDvSCZuQ4OA0ig2hy6CU1ghTqGLo14trjaT/v14rnNXrTDhCA2cUP6/JSl59 y+fqlohUowkG7NyOJSWeVP3pS98hjh4cIZ7o2ZNbSxaahSX4Mk3bVQJ9tzDlFb6h6x+V s3YSLutsoBnFlRKWEHD+IfI69QbK7t/IGYgVgmhaAFJVWursnNZuRGm2BXD1oEjKluvb I4Zw== X-Received: by 10.58.23.199 with SMTP id o7mr28240788vef.2.1364492644724; Thu, 28 Mar 2013 10:44:04 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.58.23.199 with SMTP id o7mr28240785vef.2.1364492644651; Thu, 28 Mar 2013 10:44:04 -0700 (PDT) Received: by 10.220.24.11 with HTTP; Thu, 28 Mar 2013 10:44:04 -0700 (PDT) In-Reply-To: <6E974F14-4902-4345-9B09-5E06BE0D2AE5@delong.com> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <6E974F14-4902-4345-9B09-5E06BE0D2AE5@delong.com> Date: Thu, 28 Mar 2013 13:44:04 -0400 Message-ID: From: Matthew Pounsett To: Owen DeLong Content-Type: multipart/alternative; boundary=047d7b339a156227db04d8ffb381 X-Gm-Message-State: ALoCoQk71OjLz+C9+CLo/CV8m7tv6ssOB9CBZX3KhKUNQg3/nYRAHmO4qD41AenoP9kDJC3O4h27zfLcOr7O3zuDYVERAOpaVoiSTFENlyWRauVhJbxcRspTaUpvq7Dws2spCNJCj9A+ Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 17:44:11 -0000 X-List-Received-Date: Thu, 28 Mar 2013 17:44:11 -0000 --047d7b339a156227db04d8ffb381 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 27, 2013 at 7:25 PM, Owen DeLong wrote: > > On Mar 27, 2013, at 2:34 PM, Lorenzo Colitti wrote: > > What I've seen, over and over again, is that > teams/companies/enterprises/... say "we can't deploy IPv6 because of X", > but then, when X arrives, the very same people move on to saying "we can't > deploy IPv6 because of Y", where Y != X. So X is not the real reason, it's > just a red herring. What they are actually saying is "we see no need to > deploy IPv6 at the moment". > > > Lorenzo, this simply isn't always true. > > It may be that they can't deploy IPv6 because of A, B, C, D, E, F, G, H, > X, Y, and Z. > > It may be that they tell you about X. When you eliminate X, they tell you > about Y. > Or it may be that they don't even figure out that Y is a problem until they can move beyond X. That is not uncommon. --047d7b339a156227db04d8ffb381 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Mar 27, 2013 at 7:25 PM, Owen De= Long <owen@delong.com> wrote:

On Mar = 27, 2013, at 2:34 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
What I've seen, over and over again, is that teams/companies/enterpris= es/... say "we can't deploy IPv6 because of X", but then, whe= n X arrives, the very same people move on to saying "we can't depl= oy IPv6 because of Y", where Y !=3D X. So X is not the real reason, it= 's just a red herring. What they are actually saying is "we see no= need to deploy IPv6 at the moment".


Lorenzo,= this simply isn't always true.

It may be that= they can't deploy IPv6 because of A, B, C, D, E, F, G, H, X, Y, and Z.=

It may be that they tell you about X. When you eliminat= e X, they tell you about Y.

Or = it may be that they don't even figure out that Y is a problem until the= y can move beyond X. =C2=A0That is not uncommon.

--047d7b339a156227db04d8ffb381-- From dougb@dougbarton.us Thu Mar 28 21:28:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A04721F8EE1 for ; Thu, 28 Mar 2013 21:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vltVTHFOEgqr for ; Thu, 28 Mar 2013 21:28:39 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7555321F89B5 for ; Thu, 28 Mar 2013 21:28:36 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:cd62:cbc3:90a9:ce8b] (unknown [IPv6:2001:470:d:5e7:cd62:cbc3:90a9:ce8b]) by dougbarton.us (Postfix) with ESMTPSA id 0AEF622B12 for ; Fri, 29 Mar 2013 04:28:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1364531316; bh=lL8mJBDfk8HfJ3ND5aDQFaWhwLPZ+8BI6oje1al+zcc=; h=Date:From:To:Subject:References:In-Reply-To; b=K+q+l+XVQ3tWJSRvbFjgBgJgF4yucZPT3fa0H8NYZLSrBv0bPQtNFRVBwNUdldwN+ SE6n6ZWZfdZhY78pO5/4esWaZzOah1I7MNVPwliLDVFKiBnSEspJMs4GaP5YtazYrv 1iftKpcXIfRBwiX/wv0BVBOPrr3oMGF1k53Y7X5k= Message-ID: <51551873.30406@dougbarton.us> Date: Thu, 28 Mar 2013 21:28:35 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <4FC37E442D05A748896589E468752CAA0A671F49@PWN401EA160.ent.corp.bcbsm.com> <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> <51532AEF.2030702@dougbarton.us> <0FACA054-11D6-41D3-9ADB-0EFC7E583415@muada.com> <8D23D4052ABE7A4490E77B1A012B6307751240AF@mbx-01.win.nominum.com> <844D2086-E10B-4393-BE80-D1E041B8BD8C@delong.com> <8D23D4052ABE7A4490E77B1A012B630775124DB1@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775124DB1@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 04:28:40 -0000 On 03/28/2013 07:59 AM, Ted Lemon wrote: > On Mar 28, 2013, at 5:45 AM, Owen DeLong wrote: >> DHCPv6 support was added in Lion. > > I thought stateful didn't come in until Mountain Lion, but it doesn't really matter—the point is that it wasn't the IETF that delayed this; it was an internal architectural debate at Apple; a debate that actually had nothing to do with the question of default routes in DHCP. Actually it's a great example of how one (or a few) individual(s) can stall progress due to their dogmatic beliefs. Doug From pkern@spike.0x539.de Wed Mar 27 09:33:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9E521F8D2D for ; Wed, 27 Mar 2013 09:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzPUNcIjzGjT for ; Wed, 27 Mar 2013 09:33:23 -0700 (PDT) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id 1582F21F8D2C for ; Wed, 27 Mar 2013 09:33:22 -0700 (PDT) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UKtHp-0002Na-UX; Wed, 27 Mar 2013 17:33:18 +0100 Received: from p2003006b0d000d01dcabdf10aa1dd3b9.dip.t-dialin.net ([2003:6b:d00:d01:dcab:df10:aa1d:d3b9] helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1UKtHr-000816-71; Wed, 27 Mar 2013 17:33:19 +0100 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1UKtHq-0002rw-E6; Wed, 27 Mar 2013 17:33:18 +0100 Date: Wed, 27 Mar 2013 17:33:18 +0100 From: Philipp Kern To: Randy Bush Message-ID: <20130327163318.GA10704@spike.0x539.de> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: Organization: Ubuntu (http://www.ubuntu.com) User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 29 Mar 2013 08:08:17 -0700 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 16:33:23 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Randy, am Thu, Mar 28, 2013 at 01:25:09AM +0900 hast du folgendes geschrieben: > > All we need to do is get to a point where there is enough IPv6 deployment > > for enterprise operators to decide that they are going to deploy IPv6 even > > though - oh, the sheer horror! - there is no way to configure routing in > > DHCPv6. > you have not figured it out, have you? my way or the highway has led to > the nat4444 highway. hope you like living in hell. i don't and i don't > thank you for it. this missing feature has not come up in any of my discussions with (potential) users at all. Most are confused about DUIDs and no MAC-based addressing, though. Please don't make this issue as big as an elephant while it really isn't. Kind regards Philipp Kern --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJRUx9OAAoJEERuJUU10FbsqcgH/RRC4fVBRktHYbfjESBaYRXS fjIuV8pkkhaOvncDNPZk83nNccM5k0zdbD5y4xqI0bRKb8xXyVID5HGBMKs6TFBR rxozsoMChYJWrxc9pGJOTkGM3ILBm7UCjV8ACKi+ue4rA5m4BM/RkjD0fzPg+486 WSAhFTpVMDol6QTPfJuJQB58fFIb200Q3T2HGmrNXKPgqvngQEF7fP/+fzt1MCvK yRczc313crldrKYnlWLPaZ1wsF1LizgqoGX302NCYHrh7oH/hb+QJnLgb3NkJBIO IxCDT854cRi5tzdlGvqLW04Q8321rCcAvgCInyGmYD1HB4ECWjIz/349JcnTFPs= =mMNJ -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From owen@delong.com Fri Mar 29 10:36:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72E021F9430 for ; Fri, 29 Mar 2013 10:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+DGGYy3AtTv for ; Fri, 29 Mar 2013 10:36:12 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 32E2D21F9429 for ; Fri, 29 Mar 2013 10:36:11 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2THZfjB020106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Mar 2013 10:35:41 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2THZfjB020106 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364578541; bh=0a05QbNpQr6CGLsbvIsRhqYHMaI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=iiof9sAF3YIYslgZuGfPDLE4jn4ua7WiW3X/BRuSoiH4RDCHcKPWeV3GE+uV5tJmK J0L6wR2aG7mRjq079LieviXgKqUcbtobN2jgY7Yb4n2iB+d9YdEs8MnWdOhsWpCNsb 7DOJsxG13r891kWJzTM1jJaUAiSTKKVfBsNFaUbc= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <1364457977.67128.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Fri, 29 Mar 2013 10:35:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1623EC87-01B3-4FE7-B994-27561167448D@delong.com> References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1364411510.8596.YahooMailNeo@web142502.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D9831803D8DB@XCH-BLV-504.nw.nos.boeing.com> <83602E3F-011F-4C90-A130-C82BE38A63FB@delong.com> <804490FF-EB5D-4624-9E88-295BA247191F@delong.com> <1364457977.67128.YahooMailNeo@web142505.mail.bf1.yahoo.com> To: Mark Smith X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 29 Mar 2013 10:35:41 -0700 (PDT) Cc: v6ops v6ops WG Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 17:36:13 -0000 On Mar 28, 2013, at 01:06 , Mark Smith = wrote: >=20 >=20 >=20 >> ________________________________ >> From: Lorenzo Colitti >> To: Owen DeLong =20 >> Cc: v6ops v6ops WG =20 >> Sent: Thursday, 28 March 2013 11:31 AM >> Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in = DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? >>=20 >>=20 >> On Thu, Mar 28, 2013 at 9:22 AM, Owen DeLong wrote: >>=20 >> What functionality would such an option provide that cannot be = provided using the Route Information Option in the RA?=20 >>> The combination of that functionality with deterministic and = auditable client addressing? >>=20 >>=20 >> I don't understand that statement. You can have deterministic and = auditable addressing with DHCPv6 today, without having to use DHCPv6 to = configure routing. >>=20 >>=20 >=20 >=20 > Actually, stateful DHCPv6 will only provide auditability for the = addresses it hands out. It won't capture information about hosts = configured with static addresses, or hosts that ignore DHCPv6 and just = use link-local addresses for on-link communication. Assuming this = auditability is for security purposes, I'd think stateful DHCPv6 records = would be quite inadequate. DHCPv4 has the same sorts of limitations. >=20 Unless the DHCP server is tied into your network admission controls. > The only way to record all addresses in use on an segment is to = observe neighbor discovery messages, primarily DADs, and once learned, = actively probe them using methods similar to NUD to detect when they = disappear. If that is still not acceptable, then admission control via = e.g. 802.1x, and then isolating authorised clients in their own virtual = point-to-point link with the router (e.g. individual VLAN with = individual /64) would be the way to control who attaches to the network, = and what they can reach. Yep Owen From owen@delong.com Fri Mar 29 10:41:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582A121F939B for ; Fri, 29 Mar 2013 10:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPGnPphGFqcP for ; Fri, 29 Mar 2013 10:41:05 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 074CD21F9409 for ; Fri, 29 Mar 2013 10:41:03 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2THdxxk020207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Mar 2013 10:39:59 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2THdxxk020207 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364578800; bh=D2TAfgHasrkGSO3nlS3+KMfIwio=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=cP2gC7XKaHAlkABKWjW7rE/JMMetmqdjz4k1+Glj1Q4lz3IfoJAiG+Jb0tra/g0xv /ADK11vdT/UVexoHnt+k+VlHptYciA3DXmHmn1RxpztlDzLcHQ21/OoIkRf4lf6uWg ErWLFQhyxd1tUVJbCyul1iz3ovNDDg5t0LyfSJak= Content-Type: multipart/alternative; boundary="Apple-Mail=_6763E067-E462-4BD8-B136-15676DBCE07C" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: Date: Fri, 29 Mar 2013 10:39:31 -0700 Message-Id: <5DB9F68B-8F33-4168-9AB6-8CBC95064F38@delong.com> References: <5151C83B.1010203@gmail.com> <03A645B2-205F-4E01-BF85-0024D9ED9D07@muada.com> <1364375107.59425.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1364411510.8596.YahooMailNeo@web142502.mail.bf1.yahoo.com> <2134F8430051B64F815C691A62D9831803D8DB@XCH-BLV-504.nw.nos.boeing.com> <83602E3F-011F-4C90-A130-C82BE38A63FB@delong.com> <804490FF-EB5D-4624-9E88-295BA247191F@delong.com> <1364457977.67128.YahooMailNeo@web142505.mail.bf1.yahoo.com> <5153FD9C.60807@gmail.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 29 Mar 2013 10:40:00 -0700 (PDT) Cc: v6ops v6ops WG Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 17:41:07 -0000 --Apple-Mail=_6763E067-E462-4BD8-B136-15676DBCE07C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Mar 28, 2013, at 01:24 , Lorenzo Colitti wrote: > On Thu, Mar 28, 2013 at 5:21 PM, Brian E Carpenter = wrote: > There's this saying in successful retail operations that "the customer = is > always right [even when wrong]." >=20 > But fortunately the IETF is not in the business of selling things? Herein lies the fundamental flaw in the assumptions being made by the = our way or the highway thinkers in the IETF. The IETF may not be in the business of exchanging products for money. = That does not mean that sales is not an important part of what the IETF = does. If you think of sales not as merely the exchange of goods and services = for money, but, as the process of gaining market acceptance of your = output, then, the sales is absolutely critical to continued IETF = relevance. As I said, routing information in DHCPv6 will happen. Either within the = IETF or without it. Everyone is better off if we standardize it within = the IETF and don't end up with competing multiple disparate = implementations. Owen --Apple-Mail=_6763E067-E462-4BD8-B136-15676DBCE07C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 lorenzo@google.com> = wrote:
On Thu, Mar 28, 2013 at 5:21 PM, Brian E = Carpenter <brian.e.carpenter@gmail.com> = wrote:
There's this saying in successful retail = operations that "the customer is
always right [even when wrong]."

But fortunately the IETF is not in the business of selling = things?

Herein = lies the fundamental flaw in the assumptions being made by the our way = or the highway thinkers in the IETF.

The IETF may not = be in the business of exchanging products for money. That does not mean = that sales is not an important part of what the IETF = does.

If you think of sales not as merely the = exchange of goods and services for money, but, as the process of gaining = market acceptance of your output, then, the sales is absolutely critical = to continued IETF relevance.

As I said, routing = information in DHCPv6 will happen. Either within the IETF or without it. = Everyone is better off if we standardize it within the IETF and don't = end up with competing multiple disparate = implementations.

Owen

= = --Apple-Mail=_6763E067-E462-4BD8-B136-15676DBCE07C-- From owen@delong.com Fri Mar 29 10:51:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC7521F8910 for ; Fri, 29 Mar 2013 10:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2e16D0cNoc+e for ; Fri, 29 Mar 2013 10:51:21 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1E76921F890F for ; Fri, 29 Mar 2013 10:51:21 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2THmsGh020455 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Mar 2013 10:48:55 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2THmsGh020455 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364579336; bh=y4zzo28iS1kRlJSmICwCA9w4Fvo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=4yluzbg+ixtBeBQiSCOJuu54LKX6+enf+DWRFSl0HBTa9xd1YJ2T35twjLqT725eK refkpv+pEFAD1RmmaM0xRl0KHE1AMc25wDy9QVfExu0/9CEl2KWPRYbYjYmG5At930 pimFkKFafziiOtR7zEQn3NB2sBSkMu+Yo+ZOO7zc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <2134F8430051B64F815C691A62D9831803F99C@XCH-BLV-504.nw.nos.boeing.com> Date: Fri, 29 Mar 2013 10:48:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5B96BC3F-5B49-46F0-8551-09C509060A56@delong.com> References: <20130328155646.15588.7427.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831803F99C@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 29 Mar 2013 10:48:56 -0700 (PDT) Cc: "v6ops@ietf.org WG" , "draft-steffann-tunnels@tools.ietf.org" Subject: Re: [v6ops] draft-steffann-tunnels-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 17:51:22 -0000 Agreed... LISP should not be any more emphasized than SEAL et. al. Owen On Mar 28, 2013, at 09:19 , "Templin, Fred L" = wrote: > Hi Iljitsch, >=20 > In the diffs, I see: >=20 > Although SEAL [RFC5320] and related protocols (such as VET, RANGER =20= > and IRON) are capable of tunneling IPv6 over IPv4, these protocols =20= > are not discussed in this document because their scope goes well =20 > beyond basic IPv6-in-IPv4 tunneling." >=20 > However, the same is true of LISP (which is looking at IPv4-in-IPv4 > in its current phases). Do you want to de-emphasize LISP also? >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of >> Iljitsch van Beijnum >> Sent: Thursday, March 28, 2013 9:05 AM >> To: v6ops@ietf.org WG >> Cc: draft-steffann-tunnels@tools.ietf.org >> Subject: [v6ops] draft-steffann-tunnels-02.txt >>=20 >> Hi all, >>=20 >> We've incorporated a number of comments. Please have a look (the diff = is >> handy) and see if everything is to your liking. I think I put in all = the >> names of people who reviewed or had significant comments in the >> acknowledgments, let us know if I overlooked anyone. >>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>=20 >>> Title : A Comparison of IPv6 over IPv4 Tunnel = Mechanisms >>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-steffann-tunnels >>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-steffann-tunnels-02 >>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-steffann-tunnels-02 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From owen@delong.com Fri Mar 29 11:01:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7FB21F9399 for ; Fri, 29 Mar 2013 11:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2mXf0I1q-8L for ; Fri, 29 Mar 2013 11:01:28 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 546CF21F9369 for ; Fri, 29 Mar 2013 11:01:28 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2THwbjJ020765 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Mar 2013 10:58:38 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2THwbjJ020765 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364579918; bh=0h30qb+FL8nQthGn1+Wd3O3IwDA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=iLe4dQDkW3CG7iuyaE1sypwrVK4iung8c+9kQv5UpjQiziC4Q45FiIDKZmAFpYV39 ybh2Zoh0KKDRDyxXzUskn6RP58n6fqvW3i1uvemxZyfoH4ORi7siGz4WlSTbLr/bsx ntVcSC15AGbWi5gwYbpgwQu9YynbecDplo4nQ95k= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6ECA24@nkgeml506-mbx.china.huawei.com> Date: Fri, 29 Mar 2013 10:58:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <731D2903-56BD-4A4D-9D86-EC1C3CF9D5E1@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6ECA24@nkgeml506-mbx.china.huawei.com> To: Liubing (Leo) X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 29 Mar 2013 10:58:38 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 18:01:29 -0000 On Mar 27, 2013, at 23:23 , Liubing (Leo) = wrote: > Hi, Owen >=20 > Thanks for your comments. Please see inline. >=20 > Best regards, > Bing >=20 >>>> - don't write ULAs like this: fd::1, because it's not an ULA. The = ULA >>>> must start with fd00: and not fd:, because whereas the leading 0s = can >>>> be ommitted the subsequent 0s are significant, in this Western- >>>> inspired textual address representation system (like 003 dollars = is >>>> same value as 3 dollars, but 300 dollars is not the same as 3 >>>> dollars). >>>=20 >>> [Bing] I think fc00:/7 might be more accurate? Although most of the = time it >> would be fd00:/8, but maybe it is not necessarily to exclude L=3D0. >>=20 >> There is no valid use of L=3D0 currently. The IETF did not gain = consensus for >> that draft and no substitute proposal has emerged or shown any signs = of >> gaining consensus. IIRC, it was slightly more controversial than the = idea of >> routing information in DHCP. >=20 > [Bing] I understand the L=3D0 situation. But is it necessary to = exclude it? In another word, is fc00:/7 harmful?=20 > My concern is that the fc00::/7 form is more compliance to the = definition in RFC4193. >=20 I don't object to including fc00::/7 so long as it is made clear that: "Though we document fc00::/7 here as compliant with RFC4193, at the time = of writing, there is no documented legitimate use for fc00::/8 (L=3D0) and only addresses within = fd00::/8 have a valid documented use. The draft for the original intent of fc00::/8 expired = without consensus." >>>> - don't write example ULAs like this: fd00::1 because there seems = to be >>>> only 0s between fd and 1, whereas a real ULA has randomness in = that >>>> space, to ensure uniqueness. fd00:face:booc::1 is probably a = better >>>> ULA although a trained eye may notice a surprising coincidence = hard >>>> to generate randomly. >>=20 >> Actually, I would recommend that we use fd00:2001:db8::/48 as the = example >> ULA. I will submit a draft for that update to the Example Prefix RFC. >=20 > [Bing] I'm not very sure, 2001:db8 is a typical GUA form, will it lead = some confusion about randomness? >=20 I think it's just about as random as any other example you could use. At = least if someone mistakenly configures that following the examples, it's a = clear case of misconfiguration by example. There is only so much we can do to help the illiterate to read the RFC. >>>> - dont assign fd00::1/128 address on the default Gateway, even = though >>>> one is used to assign such in IPv4; the reason same as above - = lack >>>> of randomness. >>=20 >> True, but there's nothing wrong with establishing an example ULA = prefix >> at fd00:2001:db8::/48 and then using fd00:2001:db8::/64 as the first >> prefix in that /48 and fd00:2001:db8::1/128 as the gateway address = for >> that /64. >>=20 >>>> - if you want to set up a small network which has multiple subnets, = and >>>> you can't get IPv6 global unicast addresses from an authority or = an >>>> authoritative sysadmin (prefixed by 001 first three bits), like a >>>> Provider Independepent, or Provider Assigned addresses - then use >>>> ULAs to configure your small network. >>=20 >> Why would you be unable to get such address space? To the best of my >> knowledge, all of the RIRs have provisions for granting addresses to >> non-connected networks. >=20 > [Bing] I guess Alex was talking about some situations lack of = money/conditions to apply address space from RIRs/LIRs.=20 The RIR policies have been rather stingy in the IPv4 world, but to the = best of my knowledge, each of the RIRs has pretty liberal policies WRT = getting IPv6 addresses. The monetary issue is a separate problem and is = really outside of the scope of IETF. >>>> - for that small network use ULAs rather than making up some global >>>> unicast addresses out of a prefix which was not previously = guaranteed >>>> unique by the administration. >>=20 >> ULA is definitely preferable to squatting on bosons, but much in the = same >> way that the flu is preferable to cancer. >>=20 >>>> - dont use 2001:db8:: prefix to assign to that small network - it's = a >>>> Documentation prefix, has sense for humans but not for computers. >>>> Rather use ULAs, or global unicast addresses if you can get some. >>=20 >> Agreed... This should be in the document. Especially if we use the >> example prefix of fd00:2001:db8::/48 as our example ULA. >>=20 >>>=20 >>>=20 >>>> - dont use ULA with NAT - it doesnt work. >>>=20 >>> [Bing] Well, this is the big issue I need to address in the next = version: ) >>> According to the discussions, I prefer NOT explicitly recommend = against >> ULA+NAT, but give pros/cons, benefit/drawbacks, and maybe some >> operational concerns/warning as well. And I'll separate the NPTv6 = with NAPT, >> and limit the scope within NPTv6, because it is the only IPv6 NAT = related >> standard available so far. >>=20 >> I would strongly urge you to recommend against NAT. >>=20 >> NAT is just too expensive and too destructive to the internet in = general. >> There is no valid reason not to recommend against it. >=20 > [Bing] A valid reason as I can tell is, when you want independent = address space and you cannot or do not want to afford the cost of PI = (thinking about SOHO/SMEs). > Since this topic is the controversy focus, later I'll raise another = separated thread to talk about what could be possibly consensus. I run a SOHO... I have PI v4 and v6. Currently I pay $100/year for my PI = space. Shortly that will jump to $300/year ($200 for my IPv4 and $100 = for my IPv6). I consult for several SMEs and have installed PI v4 and v6 solutions for = them. The cost of the IP space has been a trivial portion of the overall = expense of their network deployments. Even if you choose to use ULA for stable internal addressing, there is = still no valid reason not to use PA or PI space for your external = connectivity. All hosts in IPv6 are required to support multiple = addresses per interface. Bare bones connectivity off the local subnet = requires at least two addresses (link local and some form of global = scoped address, whether that's a ULA global scoped address or a GUA = global scoped address or something else we invent later). Owen From alexandru.petrescu@gmail.com Fri Mar 29 11:28:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D6321F86CE for ; Fri, 29 Mar 2013 11:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.713 X-Spam-Level: X-Spam-Status: No, score=-9.713 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygDksjdf5K3S for ; Fri, 29 Mar 2013 11:28:17 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id D23DB21F86B9 for ; Fri, 29 Mar 2013 11:28:16 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2TIS74C025558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Mar 2013 19:28:07 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2TIS7n3025662; Fri, 29 Mar 2013 19:28:07 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2TIRsWS006849; Fri, 29 Mar 2013 19:28:06 +0100 Message-ID: <5155DCEE.2020909@gmail.com> Date: Fri, 29 Mar 2013 19:26:54 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Owen DeLong References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6ECA24@nkgeml506-mbx.china.huawei.com> <731D2903-56BD-4A4D-9D86-EC1C3CF9D5E1@delong.com> In-Reply-To: <731D2903-56BD-4A4D-9D86-EC1C3CF9D5E1@delong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 18:28:18 -0000 Le 29/03/2013 18:58, Owen DeLong a écrit : [...] >>>>> - if you want to set up a small network which has multiple >>>>> subnets, and you can't get IPv6 global unicast addresses from >>>>> an authority or an authoritative sysadmin (prefixed by 001 >>>>> first three bits), like a Provider Independepent, or Provider >>>>> Assigned addresses - then use ULAs to configure your small >>>>> network. >>> >>> Why would you be unable to get such address space? To the best of >>> my knowledge, all of the RIRs have provisions for granting >>> addresses to non-connected networks. >> >> [Bing] I guess Alex was talking about some situations lack of >> money/conditions to apply address space from RIRs/LIRs. > > The RIR policies have been rather stingy in the IPv4 world, but to > the best of my knowledge, each of the RIRs has pretty liberal > policies WRT getting IPv6 addresses. The monetary issue is a separate > problem and is really outside of the scope of IETF. I checked some RIR conditions about allocating PI space. Other than the price tag (I don't know) there is a set of other administrative and technical requirements which make me doubt about its adaptation to vehicular traits like mobility. - RIR says only a maximum of /48 prefix can be allocated as PI, to end user. I am not sure one /48 is enough for a vehicle manufacturer, because it would give only 2^16 /64 prefixes. This is way too little for the number of vehicles manufactured by one manufacturer in 10 years time. RIR says exceptions are possible, but then one has to go and motivate. - RIR says that a contractual relationship must be developped between enduser and a LIR (Local...). They dont say what happens when that vehicle manufacturer is itself also a LIR for its business offices, or for its other small fleet. - it seems to me RIR also says that PI space may be allocated _only_ within that LIR. Whereas this may work with a LIR which is e.g. T-Mobile (it has presence in many countries where a vehicle would go), it may not work otherwise. - there may be other aspects in that pdf that I didnt have time yet to read and understand. I will look later. All these things seem complicated. It seems much easier just make ULAs and stamp them on vehicles. Vehicle manufacturers, insurers, government are all used to stamp unique numbers on vehicles - the VIN, the engine number, insurance ids, license plate, etc. Of course - state they dont reach the Internet. If Internet car-to-cloud application is needed then use PI or PA addressing space, not ULA. But ULA may be sufficient for numerous in-vehicle applications, or even vehicle-to-vehicle applications (without infrastructure). >>>>> - for that small network use ULAs rather than making up some >>>>> global unicast addresses out of a prefix which was not >>>>> previously guaranteed unique by the administration. >>> >>> ULA is definitely preferable to squatting on bosons, but much in >>> the same way that the flu is preferable to cancer. >>> >>>>> - dont use 2001:db8:: prefix to assign to that small network >>>>> - it's a Documentation prefix, has sense for humans but not >>>>> for computers. Rather use ULAs, or global unicast addresses >>>>> if you can get some. >>> >>> Agreed... This should be in the document. Especially if we use >>> the example prefix of fd00:2001:db8::/48 as our example ULA. >>> >>>> >>>> >>>>> - dont use ULA with NAT - it doesnt work. >>>> >>>> [Bing] Well, this is the big issue I need to address in the >>>> next version: ) According to the discussions, I prefer NOT >>>> explicitly recommend against >>> ULA+NAT, but give pros/cons, benefit/drawbacks, and maybe some >>> operational concerns/warning as well. And I'll separate the NPTv6 >>> with NAPT, and limit the scope within NPTv6, because it is the >>> only IPv6 NAT related standard available so far. >>> >>> I would strongly urge you to recommend against NAT. >>> >>> NAT is just too expensive and too destructive to the internet in >>> general. There is no valid reason not to recommend against it. >> >> [Bing] A valid reason as I can tell is, when you want independent >> address space and you cannot or do not want to afford the cost of >> PI (thinking about SOHO/SMEs). Since this topic is the controversy >> focus, later I'll raise another separated thread to talk about >> what could be possibly consensus. > > I run a SOHO... I have PI v4 and v6. Currently I pay $100/year for my > PI space. Shortly that will jump to $300/year ($200 for my IPv4 and > $100 for my IPv6). > > I consult for several SMEs and have installed PI v4 and v6 solutions > for them. The cost of the IP space has been a trivial portion of the > overall expense of their network deployments. Hmm... I tend to agree. But depends where one looks at it from. I think in many fixed cases (like SOHO) the PI cost and usefulness make a very good tradeoff, like suggested above. > Even if you choose to use ULA for stable internal addressing, there > is still no valid reason not to use PA or PI space for your external > connectivity. Agreed. > All hosts in IPv6 are required to support multiple addresses per > interface. Bare bones connectivity off the local subnet requires at > least two addresses (link local and some form of global scoped > address, (not to mention the Privacy Extensions addresses) > whether that's a ULA global scoped address or a GUA global scoped > address or something else we invent later). I agree, multiple addresses on a single interface is the norm in IPv6 deployments (it was there in the very first IPv6 stacks), rather than the exception as it is with IPv4. Alex > > Owen > > > From joelja@bogus.com Fri Mar 29 12:01:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE4821F89A6 for ; Fri, 29 Mar 2013 12:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.848 X-Spam-Level: X-Spam-Status: No, score=-101.848 tagged_above=-999 required=5 tests=[AWL=-0.449, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, 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 Pu5KYBtqFQV8 for ; Fri, 29 Mar 2013 12:01:27 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA1C21F8930 for ; Fri, 29 Mar 2013 12:01:27 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r2TJ1Nt3011188 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 29 Mar 2013 19:01:23 GMT (envelope-from joelja@bogus.com) Message-ID: <5155E4FE.8060707@bogus.com> Date: Fri, 29 Mar 2013 12:01:18 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Thunderbird/20.0 MIME-Version: 1.0 To: Alexandru Petrescu , Owen DeLong References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6ECA24@nkgeml506-mbx.china.huawei.com> <731D2903-56BD-4A4D-9D86-EC1C3CF9D5E1@delong.com> <5155DCEE.2020909@gmail.com> In-Reply-To: <5155DCEE.2020909@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 29 Mar 2013 19:01:24 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 19:01:28 -0000 On 3/29/13 11:26 AM, Alexandru Petrescu wrote: > Le 29/03/2013 18:58, Owen DeLong a écrit : > [...] >>>>>> - if you want to set up a small network which has multiple >>>>>> subnets, and you can't get IPv6 global unicast addresses from >>>>>> an authority or an authoritative sysadmin (prefixed by 001 >>>>>> first three bits), like a Provider Independepent, or Provider >>>>>> Assigned addresses - then use ULAs to configure your small >>>>>> network. >>>> >>>> Why would you be unable to get such address space? To the best of >>>> my knowledge, all of the RIRs have provisions for granting >>>> addresses to non-connected networks. >>> >>> [Bing] I guess Alex was talking about some situations lack of >>> money/conditions to apply address space from RIRs/LIRs. >> >> The RIR policies have been rather stingy in the IPv4 world, but to >> the best of my knowledge, each of the RIRs has pretty liberal >> policies WRT getting IPv6 addresses. The monetary issue is a separate >> problem and is really outside of the scope of IETF. > > I checked some RIR conditions about allocating PI space. > > Other than the price tag (I don't know) there is a set of other > administrative and technical requirements which make me doubt about its > adaptation to vehicular traits like mobility. > > - RIR says only a maximum of /48 prefix can be allocated as PI, to end > user. I am not sure one /48 is enough for a vehicle manufacturer, > because it would give only 2^16 /64 prefixes. This is way too little > for the number of vehicles manufactured by one manufacturer in 10 > years time. > Entirely aside the issue of whether you want to number cars out of pi or not, this is also nonsense. You can see the arin direct assignment policy here: https://www.arin.net/policy/nrpm.html#six58 My company with 11 current locations 5 of which were at time of request datacenters received a /44 under the ARIN policy... let's look elsewhere... (maybe you should ask these folks to come to the meeting in berlin, (they're not that far away) and talk about their assignment experience). joels-MacBook-Air:~ jjaeggli$ whois -h whois.ripe.net 2a01:4dc0::/29 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '2a01:4dc0::/29' inet6num: 2a01:4dc0::/29 netname: DE-VOLKSWAGENAG-20120530 descr: Volkswagen AG country: DE org: ORG-VA303-RIPE admin-c: VWAG1-RIPE tech-c: VWAG1-RIPE status: ALLOCATED-BY-RIR mnt-by: RIPE-NCC-HM-MNT mnt-lower: AB82394-MNT mnt-routes: AB82394-MNT source: RIPE # Filtered organisation: ORG-VA303-RIPE org-name: Volkswagen AG org-type: LIR address: Volkswagen AG address: Harald Berg Brieffach 1693 address: Berliner Ring 2 address: 38436 address: Wolfsburg address: GERMANY phone: +495361927082 fax-no: +49536195727082 admin-c: AB24611-RIPE mnt-ref: AB82394-MNT tech-c: VWAG1-RIPE mnt-by: RIPE-NCC-HM-MNT source: RIPE # Filtered role: VW AG Network Planning address: Berliner Ring 2 address: 38440 Wolfsburg address: Germany org: ORG-VA303-RIPE admin-c: VWAG1-RIPE tech-c: AB24611-RIPE nic-hdl: VWAG1-RIPE mnt-by: AB82394-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.58.1 (WHOIS2) > RIR says exceptions are possible, but then one has to go and > motivate. > > - RIR says that a contractual relationship must be developped between > enduser and a LIR (Local...). They dont say what happens when that > vehicle manufacturer is itself also a LIR for its business offices, > or for its other small fleet. > > - it seems to me RIR also says that PI space may be allocated _only_ > within that LIR. Whereas this may work with a LIR which is e.g. > T-Mobile (it has presence in many countries where a vehicle > would go), it may not work otherwise. > > - there may be other aspects in that pdf that I didnt have time yet to > read and understand. I will look later. > > All these things seem complicated. > > It seems much easier just make ULAs and stamp them on vehicles. Vehicle > manufacturers, insurers, government are all used to stamp unique numbers > on vehicles - the VIN, the engine number, insurance ids, license > plate, etc. > > Of course - state they dont reach the Internet. If Internet > car-to-cloud application is needed then use PI or PA addressing space, > not ULA. But ULA may be sufficient for numerous in-vehicle > applications, or even vehicle-to-vehicle applications (without > infrastructure). > >>>>>> - for that small network use ULAs rather than making up some >>>>>> global unicast addresses out of a prefix which was not >>>>>> previously guaranteed unique by the administration. >>>> >>>> ULA is definitely preferable to squatting on bosons, but much in >>>> the same way that the flu is preferable to cancer. >>>> >>>>>> - dont use 2001:db8:: prefix to assign to that small network >>>>>> - it's a Documentation prefix, has sense for humans but not >>>>>> for computers. Rather use ULAs, or global unicast addresses >>>>>> if you can get some. >>>> >>>> Agreed... This should be in the document. Especially if we use >>>> the example prefix of fd00:2001:db8::/48 as our example ULA. >>>> >>>>> >>>>> >>>>>> - dont use ULA with NAT - it doesnt work. >>>>> >>>>> [Bing] Well, this is the big issue I need to address in the >>>>> next version: ) According to the discussions, I prefer NOT >>>>> explicitly recommend against >>>> ULA+NAT, but give pros/cons, benefit/drawbacks, and maybe some >>>> operational concerns/warning as well. And I'll separate the NPTv6 >>>> with NAPT, and limit the scope within NPTv6, because it is the >>>> only IPv6 NAT related standard available so far. >>>> >>>> I would strongly urge you to recommend against NAT. >>>> >>>> NAT is just too expensive and too destructive to the internet in >>>> general. There is no valid reason not to recommend against it. >>> >>> [Bing] A valid reason as I can tell is, when you want independent >>> address space and you cannot or do not want to afford the cost of >>> PI (thinking about SOHO/SMEs). Since this topic is the controversy >>> focus, later I'll raise another separated thread to talk about >>> what could be possibly consensus. >> >> I run a SOHO... I have PI v4 and v6. Currently I pay $100/year for my >> PI space. Shortly that will jump to $300/year ($200 for my IPv4 and >> $100 for my IPv6). >> >> I consult for several SMEs and have installed PI v4 and v6 solutions >> for them. The cost of the IP space has been a trivial portion of the >> overall expense of their network deployments. > > Hmm... I tend to agree. But depends where one looks at it from. I > think in many fixed cases (like SOHO) the PI cost and usefulness make a > very good tradeoff, like suggested above. > >> Even if you choose to use ULA for stable internal addressing, there >> is still no valid reason not to use PA or PI space for your external >> connectivity. > > Agreed. > >> All hosts in IPv6 are required to support multiple addresses per >> interface. Bare bones connectivity off the local subnet requires at >> least two addresses (link local and some form of global scoped >> address, > > (not to mention the Privacy Extensions addresses) > >> whether that's a ULA global scoped address or a GUA global scoped >> address or something else we invent later). > > I agree, multiple addresses on a single interface is the norm in IPv6 > deployments (it was there in the very first IPv6 stacks), rather than > the exception as it is with IPv4. > > Alex > >> >> Owen >> >> >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From owen@delong.com Fri Mar 29 12:27:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F1F21F8EAC for ; Fri, 29 Mar 2013 12:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7Lr-iqpuq61 for ; Fri, 29 Mar 2013 12:27:38 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id BCB3E21F8E87 for ; Fri, 29 Mar 2013 12:27:37 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2TJMJRb028282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Mar 2013 12:22:19 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2TJMJRb028282 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364584939; bh=LwlzlDjL94ft23uITGI8LnWV/xI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=QJoKSHEZSK+cdt1kc1waZYB1DUg+JuHNz6Urik7goGgnuNI9uFnHjvEcoW6eVnCwe kiheYwCjquuBABxR08b0IZVhuke1jYNGq9dTiuf6RdIHSDdCVvJbDE+/NGTJ5ALk8q lQin99ZYuMEvkB9nu8KwbyLCJdENeIypoWmS15nw= Content-Type: multipart/alternative; boundary="Apple-Mail=_2219327D-4A01-446C-A458-CA16F3F2FAAE" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <51547A5C.8030409@gmail.com> Date: Fri, 29 Mar 2013 12:21:48 -0700 Message-Id: <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 29 Mar 2013 12:22:19 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: [v6ops] Documentation Prefixes for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 19:27:40 -0000 --Apple-Mail=_2219327D-4A01-446C-A458-CA16F3F2FAAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I am considering submitting the following as an internet draft. I wanted = to get feedback from folks on this list about it first. Ideally, I would = like to see it adopted by this working group for publication as an = informational RFC alongside RFC 3849. Executive Summary: Designate fc00:2001:db8::/48 and fd00:2001:db8::/48 = as additional documentation prefixes so that we have ULA prefix examples = for use in documentation and training materials. Any feedback is welcome, including nitpicks about formatting errors, = grammar, etc. This is my first time writing an Internet Draft. I have = attempted to incorporate the vast array of specifications, hints, and = suggestions from the IETF website, but any help is appreciated. Thanks, Owen =3D=3D=3D=3D=3D=3D Network Working Group O. DeLong Internet-Draft DeLong Consulting Category: Informational March 2013 ULA IPv6 Address Prefix Reserved for Documentation Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2013). Abstract To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, an IPv6 Unicast Address prefix is reserved for use in examples in RFCs, books, documentation, and the like. Since the publication of [RFC 4193] (ULA), it is necessary to provide examples of ULA addresses in various documents, including some Internet-Drafts currently under consideration. This draft seeks to add fd00:2001:db8::/48 to the prefixes reserved for documentation purposes as is 2001:db8::/32 in [RFC 3849]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 29, 2013. DeLong Informational [Page 1] =20 Internet-Draft ULA Documentation Prefix March 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents. (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction.....................................................2 2. Acknowledgements.................................................2 3. Documentation IPv6 Unique Local Address Prefix...................3 4. Operational Implications.........................................3 5. IANA Considerations..............................................3 6. Security Considerations..........................................3 7. References.......................................................4 7.1. Normative References.........................................4 7.2. Informative References.......................................4 Authors' Addresses..................................................4 1. Introduction [RFC 4193] does not specify a ULA prefix to be used for documentation purposes. For the same reasons an IPv6 Global Unicast Prefix (GUA) is needed for documentation in [RFC 3849], there is also need for a ULA prefix. Whereas [RFC 3849] delegates 2001:db8::/32 to be used for documentation purposes where an IPv6 GUA prefix or address is needed, this memo proposes designating two /48s from ULA space for that purpose when an example of ULA is needed. 2. Acknowledgements This draft is a logical extension of the work in [RFC 3849] and I wish to thank and acknowledge the contributions of its authors Geoff Huston, Anne Lord, and Phil Smith. DeLong Informational [Page 2] =20 Internet-Draft ULA Documentation Prefix March 2013 3. Documentation IPv6 ULA Prefix To allow documentation to accurately describe deployment examples, the use of site local or link local addresses is inappropriate, and a unicast address block is required. While there is Global Unicast space designated for Documentation in [RFC 3849], no such provision exists within the ULA prefix (fc00::/7) for either random (fd000::/8) or registered (fc00::/8). Since 2001:db8::/32 was designated for documentation purposes in [RFC 3849] and is widely and readily recognized as such throughout the networking community, this memo suggests the use of similar ranges within the ULA prefixes for that same purpose. The proposed prefixes are fc00:2001:db8::/48 (ULA Registered) and fd00:2001:db8::/48 (ULA Random), respectively. In the case of fc00:2001:db8::/48 this would serve only as a statement of intent until such time as the use of fc00::/8 is documented by the IETF. 4. Operational Implications This assignment implies that IPv6 network operators should not use these prefixes in their actual deployments of IPv6 ULA. Further it implies that these prefixes should be specifically filtered in any situation where overlapping ULA prefixes may be otherwise permitted by route or packet filters. This is not a local-use prefix, and the filters may be used in both local and public contexts, though in the public context, a more general filter of all ULA space (fc00::/7) may be more desirable. In general, the combination of the specific and more generic filter together should, while unnecessary, not have any harmful effects. 5. IANA Considerations IANA is to record the allocation of the IPv6 ULA prefixes fc00:2001:db8::/48 and fd00:2001:db8::/48 as additional documentation-only prefixes in the IPv6 address registry. No end party is to be assigned these addresses. 6. Security Considerations IPv6 addressing documents do not have any direct impact on Internet infrastructure security. DeLong Informational [Page 3] =20 Internet-Draft ULA Documentation Prefix March 2013 7. References 7.1. Normative References [RFC3849] Huston, G., Lord, A., and Smith, P., "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004. 7.2. Informative References [RFC4193] Hinden, R. and Haberman, B., "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. Authors' Addresses Owen DeLong DeLong Consulting EMail: owen@delong.com Full Copyright Statement Copyright (C) The Internet Society (2013). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. DeLong Informational [Page 3] =20 Internet-Draft ULA Documentation Prefix March 2013 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. --Apple-Mail=_2219327D-4A01-446C-A458-CA16F3F2FAAE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I am considering submitting the = following as an internet draft. I wanted to get feedback from folks on = this list about it first. Ideally, I would like to see it adopted by = this working group for publication as an informational RFC alongside RFC = 3849.

Executive Summary: Designate fc00:2001:db8::/48 = and fd00:2001:db8::/48 as additional documentation prefixes so that we = have ULA prefix examples for use in documentation and training = materials.

Any feedback is welcome, including = nitpicks about formatting errors, grammar, etc. This is my first time = writing an Internet Draft. I have attempted to incorporate the vast = array of specifications, hints, and suggestions from the IETF website, = but any help is = appreciated.

Thanks,

Owe= n



=3D=3D=3D=3D=3D=3D=

Network Working = Group                   =                     =    O. DeLong
Internet-Draft             =                     =         DeLong Consulting
Category: Informational
                =                     =                     =       March 2013


  =          ULA IPv6 Address Prefix Reserved for = Documentation

Status of = this Memo

  =  This memo provides information for the Internet community. =  It does
   not = specify an Internet standard of any kind.  Distribution of = this
   memo is = unlimited.

Copyright = Notice

   Copyright (C) The Internet Society = (2013).

Abstract

  =  To reduce the likelihood of conflict and confusion when = relating
   documented = examples to deployed systems, an IPv6 Unicast = Address
   prefix is = reserved for use in examples in RFCs, books, = documentation,
   and = the like.

  =  Since the publication of [RFC 4193] (ULA), it is necessary = to
   provide examples = of ULA addresses in various documents, including
   some Internet-Drafts currently under = consideration.

  =  This draft seeks to add fd00:2001:db8::/48 to the prefixes = reserved
   for = documentation purposes as is 2001:db8::/32 in [RFC = 3849].

Status of this Memo

  =  This Internet-Draft is submitted in full conformance with = the
   provisions of = BCP 78 and BCP 79.

  =  Internet-Drafts are working documents of the Internet = Engineering
   Task = Force (IETF).  Note that other groups may also = distribute
   working = documents as Internet-Drafts. The list of current = Internet-

  =  Internet-Drafts are draft documents valid for a maximum of six = months
   and may be = updated, replaced, or obsoleted by other documents at = any
   time.  It = is inappropriate to use Internet-Drafts as = reference
   material = or to cite them other than as "work in progress."

  =  This Internet-Draft will expire on September 29, = 2013.

DeLong               =         Informational         =              [Page = 1]
 
Internet-Draft         ULA = Documentation Prefix               = March 2013

Copyright = Notice

   Copyright (c) 2013 IETF Trust and the = persons identified as the
  =  document authors. All rights reserved.

  =  This document is subject to BCP 78 and the IETF Trust's = Legal
   Provisions = Relating to IETF Documents.
  =  (http://trustee.ietf.org/lice= nse-info) in effect on the date of
   publication of this document.  Please = review these documents
  =  carefully, as they describe your rights and restrictions with = respect
   to this = document.  Code Components extracted from this document = must
   include = Simplified BSD License text as described in section 4.e = of
   the Trust Legal = Provisions and are provided without warranty as
   described in the Simplified BSD = License.

Table of = Contents

  =  1. = Introduction.....................................................2<= /div>
   2. = Acknowledgements.................................................2<= /div>
   3. Documentation IPv6 = Unique Local Address Prefix...................3
   4. Operational = Implications.........................................3
   5. IANA = Considerations..............................................3
=
   6. Security = Considerations..........................................3
   7. = References.......................................................4<= /div>
     7.1. Normative = References.........................................4
     7.2. Informative = References.......................................4
   Authors' = Addresses..................................................4
<= div>
1. = Introduction

  =  [RFC 4193] does not specify a ULA prefix to be used = for
   documentation = purposes. For the same reasons an IPv6 Global
   Unicast Prefix (GUA) is needed for = documentation in [RFC 3849],
 =  there is also need for a ULA prefix.

  =  Whereas [RFC 3849] delegates 2001:db8::/32 to be used = for
   documentation = purposes where an IPv6 GUA prefix or address
   is needed, this memo proposes designating = two /48s from
   ULA = space for that purpose when an example of ULA is = needed.

2. Acknowledgements

  =  This draft is a logical extension of the work in [RFC 3849] = and
   I wish to thank = and acknowledge the contributions of its authors
   Geoff Huston, Anne Lord, and Phil = Smith.



DeLong =                     =   Informational               =        [Page 2]
 
Internet-Draft         ULA = Documentation Prefix               = March 2013

3. = Documentation IPv6 ULA Prefix

  =  To allow documentation to accurately describe deployment = examples,
   the use of = site local or link local addresses is inappropriate, and = a
   unicast address = block is required. While there is Global Unicast
   space designated for Documentation in [RFC = 3849], no such provision
  =  exists within the ULA prefix (fc00::/7) for either random = (fd000::/8)
   or = registered (fc00::/8).

  =  Since 2001:db8::/32 was designated for documentation purposes = in
   [RFC 3849] and is = widely and readily recognized as such throughout
   the networking community, this memo = suggests the use of similar
  =  ranges within the ULA prefixes for that same purpose. The = proposed
   prefixes = are fc00:2001:db8::/48 (ULA Registered) and
   fd00:2001:db8::/48 (ULA Random), = respectively.

  =  In the case of fc00:2001:db8::/48 this would serve only as = a
   statement of = intent until such time as the use of fc00::/8 is
   documented by the = IETF.

4.  Operational Implications

  =  This assignment implies that IPv6 network operators should = not
   use these = prefixes in their actual deployments of IPv6 ULA.

  =  Further it implies that these prefixes should be = specifically
  =  filtered in any situation where overlapping ULA prefixes may = be
   otherwise = permitted by route or packet filters.

  =  This is not a local-use prefix, and the filters may be used = in
   both local and = public contexts, though in the public context, a
   more general filter of all ULA space = (fc00::/7) may be more
  =  desirable. In general, the combination of the specific and = more
   generic filter = together should, while unnecessary, not have
   any harmful effects.

5. =  IANA Considerations

  =  IANA is to record the allocation of the IPv6 ULA = prefixes
  =  fc00:2001:db8::/48 and fd00:2001:db8::/48 as = additional
  =  documentation-only prefixes in the IPv6 address = registry.
   No end = party is to be assigned these addresses.

6. =  Security Considerations

  =  IPv6 addressing documents do not have any direct impact on = Internet
  =  infrastructure security.

DeLong =                     =   Informational               =        [Page 3]
 
Internet-Draft         ULA = Documentation Prefix               = March 2013

7. =  References
7.1. =  Normative References
  =  [RFC3849] Huston, G., Lord, A., and Smith, P., "IPv6 Address = Prefix
      =        Reserved for Documentation", RFC 3849, July = 2004.

7.2.  Informative References
   [RFC4193] Hinden, R. and Haberman, B., = "Unique Local IPv6 Unicast
  =            Addresses", RFC 4193, October = 2005.

Authors' Addresses

  =  Owen DeLong
  =  DeLong Consulting

  =  EMail: owen@delong.com

Full = Copyright Statement

  =  Copyright (C) The Internet Society (2013).  This document is = subject
   to the = rights, licenses and restrictions contained in BCP 78, = and
   except as set = forth therein, the authors retain all their = rights.

   This document and the information = contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE = ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET = SOCIETY AND THE INTERNET
  =  ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR = IMPLIED,
   INCLUDING = BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF = THE
   INFORMATION = HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY = IMPLIED
   WARRANTIES = OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR = PURPOSE.

Intellectual = Property

  =  The IETF takes no position regarding the validity or scope of = any
   Intellectual = Property Rights or other rights that might be claimed = to
   pertain to the = implementation or use of the technology described = in
   this document or = the extent to which any license under such rights
   might or might not be available; nor does = it represent that it has
  =  made any independent effort to identify any such rights. =  Information
   on = the procedures with respect to rights in RFC documents can = be
   found in BCP 78 = and BCP 79.

  =  Copies of IPR disclosures made to the IETF Secretariat and = any
   assurances of = licenses to be made available, or the result of = an
   attempt made to = obtain a general license or permission for the use = of
   such proprietary = rights by implementers or users of this
   specification can be obtained from the IETF = on-line IPR repository at
=

DeLong               =         Informational         =              [Page = 3]
 
Internet-Draft         ULA = Documentation Prefix               = March 2013

  =  The IETF invites any interested party to bring to its attention = any
   copyrights, = patents or patent applications, or other = proprietary
   rights = that may cover technology that may be required to = implement
   this = standard.  Please address the information to the IETF at = ietf-

Acknowledgement

  =  Funding for the RFC Editor function is currently provided by = the
   Internet = Society.

= --Apple-Mail=_2219327D-4A01-446C-A458-CA16F3F2FAAE-- From owen@delong.com Fri Mar 29 12:36:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBF821F8E94 for ; Fri, 29 Mar 2013 12:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id po1ZSNX6ZrRy for ; Fri, 29 Mar 2013 12:36:06 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9AD21F8E7E for ; Fri, 29 Mar 2013 12:36:06 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2TJYeK1028521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Mar 2013 12:34:40 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2TJYeK1028521 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364585680; bh=eiB9mf4JxyBd7Z5ZOBlcY7s0SbY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=AM1TIAdmDc2OwErJL1Bju4lB85E8UVyVEdJ12kD//xnfXfmovzq9UWcThDkTLtMor B6b8yZ8kYTgjau/pmQl6DI3bH09vgDUDbXOOGfo1+Rwc9mnmJNPWRswomb6QMO0v0n aQXL6PHTi6rDEzeERaJmIadjDxS+h2hoBG3iZd+w= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <51547A5C.8030409@gmail.com> Date: Fri, 29 Mar 2013 12:34:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6A887128-9A75-4A50-904A-F53A29FC88B4@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 29 Mar 2013 12:34:40 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 19:36:07 -0000 >>=20 >> Actually, I would recommend that we use fd00:2001:db8::/48 as the = example >> ULA. I will submit a draft for that update to the Example Prefix RFC. >=20 > Sounds a reasonable idea to say fd00:2001:db8::/48 to be the = Documentation ULA. I am interested if a draft gets written, it could be = very short. >=20 > At the same time, I wonder how much right are we to agree that a real = ULA is always FD00::something. I mean the presence of these two 00 = digits. >=20 It is not... It is fdxx:something. > I mean it is also correct to say that this is a ULA prefix: >=20 > FD79:0D81:183C:D1A0::/59 >=20 > Right? >=20 Yes. However, when writing all-ULA as a prefix, it is one of fc00::/8 (ULA = Global, not currently standardized), fd00::/8 (ULA Random, RFC4193), or = fc00::/7 (ULA in general with L bit unspecified). >>>> - if you want to set up a small network which has multiple subnets, = and >>>> you can't get IPv6 global unicast addresses from an authority or = an >>>> authoritative sysadmin (prefixed by 001 first three bits), like a >>>> Provider Independepent, or Provider Assigned addresses - then use >>>> ULAs to configure your small network. >>=20 >> Why would you be unable to get such address space? To the best of my >> knowledge, all of the RIRs have provisions for granting addresses to >> non-connected networks. >=20 > I have never tried to ask RIRs directly but I have doubts. >=20 I can't speak with certainty for all RIRs, but I know the ARIN policy = well. I have been involved in writing all of the current IPv6 policy in = ARIN and was the primary author of the current IPv6 ISP policy. I am quite certain that you can apply to ARIN for a non-connected = network. > In the past I usually asked the operator of the Internet line (T1, E2, = etc.) to provide me IPv4 Class C or better - I had to insist and spend = time to get Class C. That is IPv4. IPv6 is a very different ball game. No scarcity. > I thought that an end user (like a vehicle manufacturer) would not be = in a position to ask RIR directly. You are mistaken. > I guess it could cost a lot of money to ask for as many IPv6 subnets = as VIN offers to that manufacturer. In theory, a vehicle manufacturer could, within ARIN policy, approach = ARIN with a desire to interconnect all of the vehicles they manufacture = and treat each as a separate end-site with a /48. Getting that many /48s = would, in fact, be rather expensive, but policy would allow them to do = so. > Do you mean that a person like in my position (I am not an ISP, nor a = IXP) could ask RIR for e.g. a 61bit space? (i.e. asking a /3 prefix)? = (sorry I bring vehicle in the picture, just to illustrate one particular = need for ULAs that I think will grow - one single vehicle manufacturer = by definition and without paying has the right to VIN space which = roughly translates into 61bit space). Obviously you aren't going to get a /3. I think the current policy in = ARIN limits you to a maximum of a /12. However, I can absolutely = guarantee you that no vehicle manufacturer has ever built enough = vehicles to justify 61 bits of space. You are talking about more than = 1,000,000,000,000,000,000 vehicles if you give each one a /64. Even if you give each one a /48, you're still talking about more = than 15,000,000,000,000 vehicles. >>>> - for that small network use ULAs rather than making up some global >>>> unicast addresses out of a prefix which was not previously = guaranteed >>>> unique by the administration. >>=20 >> ULA is definitely preferable to squatting on bosons, but much in the = same >> way that the flu is preferable to cancer. >=20 > Well, I would be careful with the first statement. I am not sure = there are enough IPv6 prefixes available to put one on each boson (if = that boson had Interface ID of length 64). I meant bogons, not bosons. It was a typo. >>> [Bing] Well, this is the big issue I need to address in the next = version: ) >>> According to the discussions, I prefer NOT explicitly recommend = against ULA+NAT, but give pros/cons, benefit/drawbacks, and maybe some = operational concerns/warning as well. And I'll separate the NPTv6 with = NAPT, and limit the scope within NPTv6, because it is the only IPv6 NAT = related standard available so far. >>=20 >> I would strongly urge you to recommend against NAT. >>=20 >> NAT is just too expensive and too destructive to the internet in = general. There is no valid reason not to recommend against it. >>=20 >>=20 >> However, a statement that it "does not work" would be inappropriate. >> For better or worse (and I believe mostly worse), it does actually >> work. >=20 > The situation could be improved. I think it would be easy to locate = the ip6tables MASQUERADE C code and add a if condition by which if ULA = then don't rewrite. Then submit to kernel maintainers and suggest = inclusion in mainline. You miss the point completely. If you're going to MASQUERADE (NAT) IPv6, = then it doesn't matter if you use ULA with your NAT or not. The problem = is the use of NAT, not the use of ULA inside the NAT. > It's the same as with link-local addressees - packets whose src/dst = are such dont get forwarded, by a simple rule in the C code, in = agreement with RFC. No, it's very different with Link Local. Link Local carries lots of = assumptions about not getting forwarded by routers. There's no such = expectation with ULA. Owen From owen@delong.com Fri Mar 29 12:41:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4378521F8E49 for ; Fri, 29 Mar 2013 12:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEOd1A5LHBSD for ; Fri, 29 Mar 2013 12:41:16 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5634421F890F for ; Fri, 29 Mar 2013 12:41:16 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2TJe9Va028634 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Mar 2013 12:40:09 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2TJe9Va028634 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364586009; bh=b710cZtpudNOqoxPRJjooq45fu4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=LlchQyzL3uSWacJWfy9KlCfnhhJKJFVxvU25Y1UnZEXkNEHwygAJjkvKF8REt38S5 HH9Ayg47/5OfvH4+lHchRQ0ygH49R5ZUOkkxZBKUYYiyduqQUuvqERp5XB/paMFGwV JOxG58Mh8+m/PY8QXMDKKQA2oaBzDXtbSpPeKVmU= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <5155DCEE.2020909@gmail.com> Date: Fri, 29 Mar 2013 12:39:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6ECA24@nkgeml506-mbx.china.huawei.com> <731D2903-56BD-4A4D-9D86-EC1C3CF9D5E1@delong.com> <5155DCEE.2020909@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 29 Mar 2013 12:40:09 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 19:41:17 -0000 On Mar 29, 2013, at 11:26 , Alexandru Petrescu = wrote: > Le 29/03/2013 18:58, Owen DeLong a =E9crit : > [...] >>>>>> - if you want to set up a small network which has multiple >>>>>> subnets, and you can't get IPv6 global unicast addresses from >>>>>> an authority or an authoritative sysadmin (prefixed by 001 >>>>>> first three bits), like a Provider Independepent, or Provider >>>>>> Assigned addresses - then use ULAs to configure your small >>>>>> network. >>>>=20 >>>> Why would you be unable to get such address space? To the best of >>>> my knowledge, all of the RIRs have provisions for granting >>>> addresses to non-connected networks. >>>=20 >>> [Bing] I guess Alex was talking about some situations lack of >>> money/conditions to apply address space from RIRs/LIRs. >>=20 >> The RIR policies have been rather stingy in the IPv4 world, but to >> the best of my knowledge, each of the RIRs has pretty liberal >> policies WRT getting IPv6 addresses. The monetary issue is a separate >> problem and is really outside of the scope of IETF. >=20 > I checked some RIR conditions about allocating PI space. >=20 > Other than the price tag (I don't know) there is a set of other > administrative and technical requirements which make me doubt about = its > adaptation to vehicular traits like mobility. >=20 > - RIR says only a maximum of /48 prefix can be allocated as PI, to end > user. I am not sure one /48 is enough for a vehicle manufacturer, > because it would give only 2^16 /64 prefixes. This is way too little > for the number of vehicles manufactured by one manufacturer in 10 > years time. >=20 No, RIR says /48 per end site is the MINIMUM. It is also by default the maximum per end site because an end site is defined as a single building or structure or a single tenant within a building or structure and it is pretty much inconceivable that one of those things would require more than 65,536 subnets. In the manufacturer case, each vehicle would be an end site. > RIR says exceptions are possible, but then one has to go and > motivate. >=20 > - RIR says that a contractual relationship must be developped between > enduser and a LIR (Local...). They dont say what happens when that > vehicle manufacturer is itself also a LIR for its business offices, > or for its other small fleet. This is a RIPE oddity. This limitation does not exist outside of Europe to the best of my knowledge. There is a process for changing this policy in the RIPE region if you feel strongly about it. > - it seems to me RIR also says that PI space may be allocated _only_ > within that LIR. Whereas this may work with a LIR which is e.g. > T-Mobile (it has presence in many countries where a vehicle > would go), it may not work otherwise. You are conflating disparate things here. > - there may be other aspects in that pdf that I didnt have time yet to > read and understand. I will look later. To which PDF do you refer? > All these things seem complicated. >=20 > It seems much easier just make ULAs and stamp them on vehicles. = Vehicle > manufacturers, insurers, government are all used to stamp unique = numbers > on vehicles - the VIN, the engine number, insurance ids, license = plate, etc. >=20 > Of course - state they dont reach the Internet. If Internet > car-to-cloud application is needed then use PI or PA addressing space, > not ULA. But ULA may be sufficient for numerous in-vehicle > applications, or even vehicle-to-vehicle applications (without > infrastructure). Link Local is probably sufficient for most in-vehicle applications. Owen From owen@delong.com Fri Mar 29 13:11:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DA621F8814 for ; Fri, 29 Mar 2013 13:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4lpz6eAEjo0 for ; Fri, 29 Mar 2013 13:11:01 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 40C0421F87CB for ; Fri, 29 Mar 2013 13:11:01 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2TK763O029699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Mar 2013 13:07:06 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2TK763O029699 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364587626; bh=MWBFAV33d/SbrmUR3HU0Q+/9gAo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=5bnCuU4rgNwe/DAORItasMW8/LW/tUYSmojFAHoPmq5GBpeqObQeK5eKlq7lugGuD fucFuNz/9E9L4GazVvlAp6BHx5r2ZZssXDDJq/eFBw6EfQJ++HX9wOgB06WoUGbRMK bk9MWV+zlJMfwL3WrAQOwLirwrHGsAusLn65/ONE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <20130327163318.GA10704@spike.0x539.de> Date: Fri, 29 Mar 2013 13:06:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <20130327163318.GA10704@spike.0x539.de> To: Philipp Kern X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 29 Mar 2013 13:07:06 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 20:11:03 -0000 On Mar 27, 2013, at 09:33 , Philipp Kern wrote: > Randy, >=20 > am Thu, Mar 28, 2013 at 01:25:09AM +0900 hast du folgendes = geschrieben: >>> All we need to do is get to a point where there is enough IPv6 = deployment >>> for enterprise operators to decide that they are going to deploy = IPv6 even >>> though - oh, the sheer horror! - there is no way to configure = routing in >>> DHCPv6. >> you have not figured it out, have you? my way or the highway has led = to >> the nat4444 highway. hope you like living in hell. i don't and i = don't >> thank you for it. >=20 > this missing feature has not come up in any of my discussions with = (potential) > users at all. Most are confused about DUIDs and no MAC-based = addressing, though. >=20 I'm happy for you. It has come up in many of my discussions with = potential users. DUIDs vs MAC comes up frequently too. Usually that's settled pretty = quickly by explaining the history of Ethernet Cards and wanting an address that = survived replacement of the card. > Please don't make this issue as big as an elephant while it really = isn't. It's a big issue. Depending on how you map virtual size onto real size, = it may be larger or smaller than an elephant. YMMV. Owen From iljitsch@muada.com Fri Mar 29 13:38:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEC921F8EDF for ; Fri, 29 Mar 2013 13:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlpmygHXFvdS for ; Fri, 29 Mar 2013 13:38:09 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id CBEB121F8E94 for ; Fri, 29 Mar 2013 13:38:07 -0700 (PDT) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2TKWuTx067065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Mar 2013 21:32:57 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> Date: Fri, 29 Mar 2013 21:37:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> To: Owen DeLong X-Mailer: Apple Mail (2.1499) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Documentation Prefixes for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 20:38:09 -0000 On 29 mrt 2013, at 20:21, Owen DeLong wrote: > I am considering submitting the following as an internet draft. I = wanted to get feedback from folks on this list about it first. Since you ask... First, either you are informational or you tell people what they SHOULD = and SHOULDN'T do. Combining the two is problematic. Realize that you are = in effect updating RFC 4193, which is standards track. Second, disallowing the use of fd00:2001:db8::/48 the way RFC 4193 = intends it to be used is problematic in my opinion, as now there can be = people that use it as per RFC 4193 and people who use it as per = draft-delong-... I think it would be better to suggest that = fd00:2001:db8::/48 is used for documentation, but recognize that people = using the procedure in RFC 4193 to generate a ULA prefix have a small = chance of landing on fd00:2001:db8::/48 and therefore, this prefix = shouldn't be treated differently from other ULA space. Third, fd000::/8 ? By the way, it's probably easier to submit the draft and ask people to = find it in the draft repository than to attach it to an email and trust = that email clients keep the formatting intact. Iljitsch= From owen@delong.com Fri Mar 29 13:51:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86AEB21F8ED5 for ; Fri, 29 Mar 2013 13:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdL9gCNcyCq6 for ; Fri, 29 Mar 2013 13:51:09 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 73E9321F8ED4 for ; Fri, 29 Mar 2013 13:51:06 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2TKkFSw030740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Mar 2013 13:46:15 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2TKkFSw030740 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364589975; bh=0S+M+H9p3tNIl7BYZC9cztgl5vU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=bxbU6sfuQtDAPiMkIHSNBNrc4F7djas4Bxis/Jc93D9ZVEaabgKmCJ5K2N4PCx68/ SZnviTga0LCJzxI4GyvpecREK3c/2eE373K0MDMDIduHEugmnCOnmlCEfr2WJlLOVW O3JreIyZEswxS5wCjrQRtJQ5zVG46mfmd5alm22M= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: Date: Fri, 29 Mar 2013 13:45:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5A1AF2E3-728F-467D-BE05-914C11CF220C@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 29 Mar 2013 13:46:15 -0700 (PDT) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Documentation Prefixes for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 20:51:11 -0000 On Mar 29, 2013, at 13:37 , Iljitsch van Beijnum = wrote: > On 29 mrt 2013, at 20:21, Owen DeLong wrote: >=20 >> I am considering submitting the following as an internet draft. I = wanted to get feedback from folks on this list about it first. >=20 > Since you ask... >=20 > First, either you are informational or you tell people what they = SHOULD and SHOULDN'T do. Combining the two is problematic. Realize that = you are in effect updating RFC 4193, which is standards track. >=20 I thought I was updating 3849 which is Informational and the language in = that regard is, btw, copied from 3849. Do you have alternative language suggestions? > Second, disallowing the use of fd00:2001:db8::/48 the way RFC 4193 = intends it to be used is problematic in my opinion, as now there can be = people that use it as per RFC 4193 and people who use it as per = draft-delong-... I think it would be better to suggest that = fd00:2001:db8::/48 is used for documentation, but recognize that people = using the procedure in RFC 4193 to generate a ULA prefix have a small = chance of landing on fd00:2001:db8::/48 and therefore, this prefix = shouldn't be treated differently from other ULA space. I want more opinions, but I'm actually OK with going either way on this. >=20 > Third, fd000::/8 ? >=20 Typo. Fixed. > By the way, it's probably easier to submit the draft and ask people to = find it in the draft repository than to attach it to an email and trust = that email clients keep the formatting intact. Fair enough. I wanted to at least run one pass by people here to get = feedback (such as what you have provided) to have a decent chance of = getting it published when submitted. Owen From iljitsch@muada.com Fri Mar 29 14:00:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8BB1F0CF7 for ; Fri, 29 Mar 2013 14:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFVS7yrKhBsp for ; Fri, 29 Mar 2013 14:00:24 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 099D71F0C74 for ; Fri, 29 Mar 2013 14:00:23 -0700 (PDT) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2TKtD9e067296 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Mar 2013 21:55:14 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <5A1AF2E3-728F-467D-BE05-914C11CF220C@delong.com> Date: Fri, 29 Mar 2013 22:00:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> <5A1AF2E3-728F-467D-BE05-914C11CF220C@delong.com> To: Owen DeLong X-Mailer: Apple Mail (2.1499) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Documentation Prefixes for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 21:00:25 -0000 On 29 mrt 2013, at 21:45, Owen DeLong wrote: >> First, either you are informational or you tell people what they = SHOULD and SHOULDN'T do. Combining the two is problematic. Realize that = you are in effect updating RFC 4193, which is standards track. > I thought I was updating 3849 which is Informational and the language = in that regard is, btw, copied from 3849. That part is fine, but you are telling people to treat = fd00:2001:db8::/48 differently from what RFC 4193 specifies. > Do you have alternative language suggestions? If you implement what I say below you are not going against RFC 4193 and = there is no problem. Check your text for "should" and "must", though, = these are dangerous words. Alternatively, make it an official update and = use RFC 2119 language. >> Second, disallowing the use of fd00:2001:db8::/48 the way RFC 4193 = intends it to be used is problematic in my opinion, as now there can be = people that use it as per RFC 4193 and people who use it as per = draft-delong-... I think it would be better to suggest that = fd00:2001:db8::/48 is used for documentation, but recognize that people = using the procedure in RFC 4193 to generate a ULA prefix have a small = chance of landing on fd00:2001:db8::/48 and therefore, this prefix = shouldn't be treated differently from other ULA space. > I want more opinions, but I'm actually OK with going either way on = this. Ok. >> By the way, it's probably easier to submit the draft and ask people = to find it in the draft repository than to attach it to an email and = trust that email clients keep the formatting intact. > Fair enough. I wanted to at least run one pass by people here to get = feedback (such as what you have provided) to have a decent chance of = getting it published when submitted. Many drafts are submitted, few are published. :-) A slight variation on Randy Bush: anyone with a keyboard and time on = their hands can submit an internet draft.= From Fred.L.Templin@boeing.com Fri Mar 29 15:35:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4DB21F866F for ; Fri, 29 Mar 2013 15:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 pc2OzK9fyQ3a for ; Fri, 29 Mar 2013 15:35:23 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE5521F866E for ; Fri, 29 Mar 2013 15:35:19 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r2TMZIGt014218 for ; Fri, 29 Mar 2013 17:35:18 -0500 Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r2TMZHqP014209 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 29 Mar 2013 17:35:18 -0500 Received: from XCH-BLV-406.nw.nos.boeing.com (130.247.25.162) by XCH-NWHT-03.nw.nos.boeing.com (130.247.71.23) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 29 Mar 2013 15:35:17 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.119]) by XCH-BLV-406.nw.nos.boeing.com ([169.254.6.228]) with mapi id 14.02.0328.011; Fri, 29 Mar 2013 15:35:16 -0700 From: "Templin, Fred L" To: Iljitsch van Beijnum , Owen DeLong Thread-Topic: [v6ops] Documentation Prefixes for ULA Thread-Index: AQHOLMB4cDdAwILAM0uCxMTQdnmtp5i9QQtA Date: Fri, 29 Mar 2013 22:35:15 +0000 Message-ID: <2134F8430051B64F815C691A62D9831804227B@XCH-BLV-504.nw.nos.boeing.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> <5A1AF2E3-728F-467D-BE05-914C11CF220C@delong.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Documentation Prefixes for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 22:35:23 -0000 I think submitting as a draft would be the next logical step, and I agree with Iljitsch's points which it sounds like Owen is amenable to. Thanks - Fred > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Iljitsch van Beijnum > Sent: Friday, March 29, 2013 2:00 PM > To: Owen DeLong > Cc: v6ops@ietf.org WG > Subject: Re: [v6ops] Documentation Prefixes for ULA >=20 > On 29 mrt 2013, at 21:45, Owen DeLong wrote: >=20 > >> First, either you are informational or you tell people what they SHOUL= D > and SHOULDN'T do. Combining the two is problematic. Realize that you are > in effect updating RFC 4193, which is standards track. >=20 > > I thought I was updating 3849 which is Informational and the language i= n > that regard is, btw, copied from 3849. >=20 > That part is fine, but you are telling people to treat fd00:2001:db8::/48 > differently from what RFC 4193 specifies. >=20 > > Do you have alternative language suggestions? >=20 > If you implement what I say below you are not going against RFC 4193 and > there is no problem. Check your text for "should" and "must", though, > these are dangerous words. Alternatively, make it an official update and > use RFC 2119 language. >=20 > >> Second, disallowing the use of fd00:2001:db8::/48 the way RFC 4193 > intends it to be used is problematic in my opinion, as now there can be > people that use it as per RFC 4193 and people who use it as per draft- > delong-... I think it would be better to suggest that fd00:2001:db8::/48 > is used for documentation, but recognize that people using the procedure > in RFC 4193 to generate a ULA prefix have a small chance of landing on > fd00:2001:db8::/48 and therefore, this prefix shouldn't be treated > differently from other ULA space. >=20 > > I want more opinions, but I'm actually OK with going either way on this= . >=20 > Ok. >=20 > >> By the way, it's probably easier to submit the draft and ask people to > find it in the draft repository than to attach it to an email and trust > that email clients keep the formatting intact. >=20 > > Fair enough. I wanted to at least run one pass by people here to get > feedback (such as what you have provided) to have a decent chance of > getting it published when submitted. >=20 > Many drafts are submitted, few are published. :-) >=20 > A slight variation on Randy Bush: anyone with a keyboard and time on thei= r > hands can submit an internet draft. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From owen@delong.com Fri Mar 29 15:41:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB6C11E80A5 for ; Fri, 29 Mar 2013 15:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRxFyh6gjuqj for ; Fri, 29 Mar 2013 15:41:19 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id BD8CF11E80A3 for ; Fri, 29 Mar 2013 15:41:19 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2TMaZZB001331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Mar 2013 15:36:35 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2TMaZZB001331 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364596595; bh=gPBgHlyv6niigbuAd/XHxf/P8FQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=KFSk2F7VfpGH7be9DDlKuizC6S8SbGmslzCnvs/W4vu4AzVxrTS/zRM5YvrYzWhy0 MvfOsdy6egl6/ALhC5DQ/f8LJNn/Ug2pekmq0MmclPyJn30BzfpXFmE2lLk/Hexj7X wJOPIx/LWAYh+oT4XvuUeKMhujzS3b5Z0gtRwAE8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: Date: Fri, 29 Mar 2013 15:35:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> <5A1AF2E3-728F-467D-BE05-914C11CF220C@delong.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 29 Mar 2013 15:36:35 -0700 (PDT) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Documentation Prefixes for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 22:41:20 -0000 This is now an ID available at: http://www.ietf.org/id/draft-delong-ula-example-00.txt Unless there is objection, the next version will incorporate the changes = suggested by Iljitsch. Are there any other changes people would like to see? Owen From farmer@umn.edu Fri Mar 29 17:45:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECAE21F8A41 for ; Fri, 29 Mar 2013 17:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ct6FoJ1+-fNg for ; Fri, 29 Mar 2013 17:45:28 -0700 (PDT) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id 3545221F8EC8 for ; Fri, 29 Mar 2013 17:45:27 -0700 (PDT) Received: from mail-ie0-f198.google.com (mail-ie0-f198.google.com [209.85.223.198]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Fri, 29 Mar 2013 19:45:16 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ie0-f198.google.com [209.85.223.198] #+LO+TR X-Umn-Classification: local Received: by mail-ie0-f198.google.com with SMTP id 17so5618212iea.1 for ; Fri, 29 Mar 2013 17:45:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=bM5myTITkmj4YEeI+c46qXPcowG7U7H6lNUHxe3Yyq8=; b=KX7GfeeCTyxm49doVL+rinuI1HF7KKiaBICKkDmIlLlUQuPa6UUZOOJaBgzBDybQJc tQtYeLs0to9rEv27E8dgpClqlAP+u7j9pLPTRtluXzR6g9SFdgFQ42ZQjl102ZaXpu9i JK+cfM5MmqyGC+uUVhF5Qv0FqXpyO5cuqqCR0lpqJX2fPycQnfToJYtA4dtnAX5ptnna iFYG2ojQqaDG0fQYs2m2eOPBg6IO2P5WQn3JV/1BtwHFyGaqFFj8HW0JoVu4xdp3uazN bdAD6c9OWDQb5dyXKvmOWV8EL4TDUFFqxOQ6j4xf/OGdhk42sjankHo/NahWQyyb+MsV SRRA== X-Received: by 10.50.51.167 with SMTP id l7mr434610igo.11.1364604315869; Fri, 29 Mar 2013 17:45:15 -0700 (PDT) X-Received: by 10.50.51.167 with SMTP id l7mr434606igo.11.1364604315745; Fri, 29 Mar 2013 17:45:15 -0700 (PDT) Received: from x-134-84-88-75.nts.umn.edu ([2607:ea00:101:2001:89f2:47ad:6a6f:f560]) by mx.google.com with ESMTPS id dy5sm774403igc.1.2013.03.29.17.45.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Mar 2013 17:45:15 -0700 (PDT) Message-ID: <51563599.2040808@umn.edu> Date: Fri, 29 Mar 2013 19:45:13 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Owen DeLong References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> <5A1AF2E3-728F-467D-BE05-914C11CF220C@delong.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnxo8z33AHaif9pFB6rMK4a3gaSyzxRQG97rXzK2RlfIthsH6TisgehY84hDp5pUtbX1SPt8BDD3oGreUkuM+NvCisXwK9XecBvCM/7MfgXEBwmLpwzaMN5R0ZECaOqMU/2e2yI Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Documentation Prefixes for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 00:45:28 -0000 On 3/29/13 17:35 , Owen DeLong wrote: > This is now an ID available at: > > http://www.ietf.org/id/draft-delong-ula-example-00.txt > > Unless there is objection, the next version will incorporate the changes suggested by Iljitsch. fd00:2001:db8::/48 should remain a valid ULA prefix as defined in RFC 4193, but you might want to suggest it may be reasonable to establish local policy not to use it, even though it remains valid ULA prefix. > Are there any other changes people would like to see? As for fc00:2001:db8::/48, I would add something like the follow to what you said; If fc00::/8 were defined similar to contemplated in [draft-ietf-ipv6-ula-central] or [draft-hain-ipv6-ulac], fc00:2001:db8::/48 should be reserved in such a registry, if such a registry were ever created for fc00::/8. Where draft-ietf-ipv6-ula-central and draft-hain-ipv6-ulac would be Informative References. Since it has come up, is there any interest in moving forward some from of ULA-C? Owen, has your views on the utility of registered ULA softened? Thanks -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From jiangsheng@huawei.com Fri Mar 29 18:21:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5218921F8EC1 for ; Fri, 29 Mar 2013 18:21:55 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMEYIt-VTVwE for ; Fri, 29 Mar 2013 18:21:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6349C21F86F7 for ; Fri, 29 Mar 2013 18:21:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARG12307; Sat, 30 Mar 2013 01:21:45 +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.7; Sat, 30 Mar 2013 01:21:14 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 30 Mar 2013 09:21:42 +0800 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.21]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.01.0323.007; Sat, 30 Mar 2013 09:21:37 +0800 From: Sheng Jiang To: Owen DeLong , Iljitsch van Beijnum Thread-Topic: [v6ops] Documentation Prefixes for ULA Thread-Index: AQHOLLOEKpagWuqVpEK8rvz+2BCqepi8mxUAgAACKICAAAQTAIAAGr0AgACtBsA= Date: Sat, 30 Mar 2013 01:21:36 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AA09364@nkgeml512-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> <5A1AF2E3-728F-467D-BE05-914C11CF220C@delong.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.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Documentation Prefixes for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 01:21:55 -0000 SSBzdXBwb3J0IHRoZSBpZGVhIHRvIGFzc2lnbiBhIGZpeGVkIHByZWZpeGVzIGZvciBVTEEgZG9j dW1lbnRhdGlvbi4gZmMwMDoyMDAxOmRiODo6LzQ4IGFzIGRvY3VtZW50YXRpb24gVUxBIHByZWZp eCBsb29rcyBhIGdvb2QgaWRlYS4NCg0KSG93ZXZlciwgYWZ0ZXIgcmVhZCB0aGUgY3VycmVudCBk cmFmdCwgSSBhbSB2ZXJ5IHdvcnJpZWQgdGhlcmUgYXJlIHNvbWUgcHJvYmxlbSBpbiBpdC4gVGhl IGJsb3cgYXJlIHNvbWUgY29uY2VybnMgSSBoYXZlOg0KDQpBLCBzdGFuZGFyZCB0cmFjayB2cyBp bmZvcm1hdGlvbmFsLiBJZGVhbGx5LCB0aGUgVUxBIFByZWZpeCBSZXNlcnZlZCBmb3IgRG9jdW1l bnRhdGlvbiBzaG91bGQgYmUgSW5mb3JtYXRpb25hbCwgbGlrZSBSRkMgMzg0OSBmb3IgSVB2NiBk b2N1bWVudGF0aW9uIHByZWZpeC4gSG93ZXZlciwgYmVpbmcgaW5mb3JtYXRpb25hbCBtZWFucyBp dCBkb2VzIG5vdCBjaGFuZ2UgYW55IHN0YW5kYXJkIHRyYWNrIG1lYW5pbmcgb3IgZXhpc3Rpbmcg aW1wbGVtZW50YXRpb25zLiBNeSByZWFkaW5nIGZyb20gdGhlIGN1cnJlbnQgSUQgaXMgaXQgcmVx dWVzdHMgY2hhbmdlIG9uIGJvdGggc2VtYW50aWMgYW5kIGV4aXN0aW5nIGltcGxlbWVudGF0aW9u LiBTbywgZm9yIG15IHVuZGVyc3RhbmRpbmcsIGl0IGhhcyB0byBiZSBzdGFuZGFyZCB0cmFjayBp ZiBpdCByZW1haW5zIHRoZSBjdXJyZW50IGZvcm0uDQoNCkIsIHNlbWFudGljIGNoYW5nZSBmb3Jt IFJGQyA0MTkzLiBSRkM0MTkzIGhhcyBkZWZpbmVkIEwgYml0ICJTZXQgdG8gMCBtYXkgYmUgZGVm aW5lZCBpbiB0aGUgZnV0dXJlIi4gQnV0IHRoZSBjdXJyZW50IGRyYWZ0IGhhcyBvdmVycmlkZSBp dCBieSAicmVnaXN0ZXJlZCAoZmMwMDo6LzgpIi4gUGVyc29uYWxseSwgSSB0aGluayB0byBjcmVh dGUgSUFOQSByZWdpc3RyYXRpb24gZm9yIFVMQSBwcmVmaXggZmMwMDo6LzggbWF5IGJlIGFuIGlk ZWEgbm90IGJhZCBhdCBhbGwuIFRoaXMgbmVlZCB0byBmb3JtYWxseSB1cGRhdGUgUkZDNDE5My4g Q29uc2VxdWVudGx5LCB0aGlzIHdvcmsgc2hvdWxkIGJlIGRvbmUgaW4gNm1hbi4gDQoNCkMsIGZk MDA6MjAwMTpkYjg6Oi80OCBoYXMgbWFnbmlmaWNlbnQgaW1wb3J0YW50IHRvIHRoZSBleGlzdGlu ZyBpbXBsZW1lbnRhdGlvbnMuIEl0IHJlcXVlc3RzIGFsbCBleGlzdGluZyBpbXBsZW1lbnRhdGlv biB0byBhdm9pZCB0aGlzIHJhbmdlcyBpbiB0aGVpciByYW5kb20gYWxnb3JpdGhtLiBJIGFtIG5v dCBzdXJlIHdoeSB5b3UgbmVlZCB0d28gcHJlZml4IGZvciBkb2N1bWVudGF0aW9uIHVzYWdlLiBG b3IgbWUsIGZjMDA6MjAwMTpkYjg6Oi80OCBpcyBlbm91Z2ggdG8gcmVwcmVzZW50IFVMQS4gVGhl cmUgaXMgbm8gbmVlZCB0byBkaXN0aW5ndWlzaCB3aGV0aGVyIGl0cyBHbG9iYWwgSUQgaXMgcmFu ZG9tbHkgZ2VuZXJhdGVkIG9yIG5vdC4NCg0KQmVzdCByZWdhcmRzLA0KDQpTaGVuZw0KDQo+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiB2Nm9wcy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+T2YgT3dlbiBEZUxvbmcN Cj5TZW50OiBTYXR1cmRheSwgTWFyY2ggMzAsIDIwMTMgNjozNiBBTQ0KPlRvOiBJbGppdHNjaCB2 YW4gQmVpam51bQ0KPkNjOiB2Nm9wc0BpZXRmLm9yZyBXRw0KPlN1YmplY3Q6IFJlOiBbdjZvcHNd IERvY3VtZW50YXRpb24gUHJlZml4ZXMgZm9yIFVMQQ0KPg0KPlRoaXMgaXMgbm93IGFuIElEIGF2 YWlsYWJsZSBhdDoNCj4NCj5odHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWRlbG9uZy11bGEt ZXhhbXBsZS0wMC50eHQNCj4NCj5Vbmxlc3MgdGhlcmUgaXMgb2JqZWN0aW9uLCB0aGUgbmV4dCB2 ZXJzaW9uIHdpbGwgaW5jb3Jwb3JhdGUgdGhlIGNoYW5nZXMNCj5zdWdnZXN0ZWQgYnkgSWxqaXRz Y2guDQo+DQo+QXJlIHRoZXJlIGFueSBvdGhlciBjaGFuZ2VzIHBlb3BsZSB3b3VsZCBsaWtlIHRv IHNlZT8NCj4NCj5Pd2VuDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj52Nm9wcyBtYWlsaW5nIGxpc3QNCj52Nm9wc0BpZXRmLm9yZw0KPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From jiangsheng@huawei.com Fri Mar 29 18:41:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6290A21F8E7A for ; Fri, 29 Mar 2013 18:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wzdsRtD-3PC for ; Fri, 29 Mar 2013 18:41:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AF81A21F8E79 for ; Fri, 29 Mar 2013 18:41:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARG13021; Sat, 30 Mar 2013 01:41:48 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 30 Mar 2013 01:41:27 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 30 Mar 2013 09:41:48 +0800 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.21]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Sat, 30 Mar 2013 09:41:41 +0800 From: Sheng Jiang To: David Farmer , Owen DeLong Thread-Topic: [v6ops] Documentation Prefixes for ULA Thread-Index: AQHOLLOEKpagWuqVpEK8rvz+2BCqepi8mxUAgAACKICAAAQTAIAAGr0AgAAkHICAAJKbwA== Date: Sat, 30 Mar 2013 01:41:41 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AA09397@nkgeml512-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> <5A1AF2E3-728F-467D-BE05-914C11CF220C@delong.com> <51563599.2040808@umn.edu> In-Reply-To: <51563599.2040808@umn.edu> 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.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Documentation Prefixes for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 01:41:51 -0000 PlNpbmNlIGl0IGhhcyBjb21lIHVwLCBpcyB0aGVyZSBhbnkgaW50ZXJlc3QgaW4gbW92aW5nIGZv cndhcmQgc29tZSBmcm9tDQo+b2YgVUxBLUM/DQoNClNpbmNlIHlvdSBhc2tlZCwgSSBoYXZlIG5v IG11Y2ggaXNzdWVzIGZvciB0aGUgVUxBLUMgcHJvcG9zYWwuDQoNCkhvd2V2ZXIsIEkgZG8gbm90 IHNlZSBtdWNoIGJlbmVmaXQgb3IgbW90aXZhdGlvbiBmcm9tIGl0LCBlaXRoZXIuIFRoZSBvbmx5 IGNvbmNyZXRlIGJlbmVmaXQgSSBjYW4gc2VlIGlzIHRoZSBndWFyYW50ZWVkIGdsb2JhbCB1bmlx dWVuZXNzLiBUaGUgcmFuZG9tIGFsZ29yaXRobSBpbiBSRkM0MTkzIGhhcyBvbmx5IHNtYWxsIGNv bGxpc2lvbiBjaGFuY2UsIGJ1dCBubyByZWFsIGd1YXJhbnRlZSBmb3IgZ2xvYmFsIHVuaXF1ZW5l c3MuIE9uIGFub3RoZXIgc2lkZSwgVUxBIGlzIG9ubHkgZm9yIGxvY2FsIHVzZSBhbmQgc2hvdWxk IG5vdCBiZSBhbm5vdW5jZWQgdG8gZ2xvYmFsIHJvdXRpbmcgc3lzdGVtIChnbG9iYWwgcm91dGlu ZyBzeXN0ZW0gY2FuIGFsc28gZWFzaWx5IGZpbHRlciB0aGUgbGVha2VkIFVMQSBhbm5vdW5jZW1l bnQpLiBUaGUgZ2xvYmFsIHVuaXF1ZW5lc3Mgb2YgVUxBIHNlZW1zIG5vdCB2ZXJ5IGNyaXRpY2Fs Lg0KDQpJZiB0aGVyZSBhcmUgb3RoZXIgYmVuZWZpdC9tb3RpdmF0aW9uIG9mIFVMQS1DLCBJIGFt IGdsYWQgdG8gZGlzY3VzcyBmdXJ0aGVyLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCj49 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj5EYXZpZCBG YXJtZXIgICAgICAgICAgICAgICBFbWFpbDogZmFybWVyQHVtbi5lZHUNCj5PZmZpY2Ugb2YgSW5m b3JtYXRpb24gVGVjaG5vbG9neQ0KPlVuaXZlcnNpdHkgb2YgTWlubmVzb3RhDQo+MjIxOCBVbml2 ZXJzaXR5IEF2ZSBTRSAgICAgUGhvbmU6IDEtNjEyLTYyNi0wODE1DQo+TWlubmVhcG9saXMsIE1O IDU1NDE0LTMwMjkgIENlbGw6IDEtNjEyLTgxMi05OTUyDQo+PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj52Nm9wcyBtYWlsaW5nIGxpc3QNCj52Nm9wc0BpZXRmLm9y Zw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From owen@delong.com Fri Mar 29 22:56:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F6E21F8F08 for ; Fri, 29 Mar 2013 22:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sd-dk68WwKBk for ; Fri, 29 Mar 2013 22:56:34 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7C321F8E3C for ; Fri, 29 Mar 2013 22:56:33 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2U5qgdQ011795 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Mar 2013 22:52:42 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2U5qgdQ011795 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364622762; bh=ebOmLwIL6MnY82XR2ohKG+IkXTQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=SKW7hcTXMKU0HUXcnYHt5Sb2pbcJthcEQEqNgUZqU590pxe+MPyl144uRUcd+sulz 3VuVeGXfWyc5bb50FadAO/TrktKIwIgOyFdFWKsm73Es+kZ/0IxfpNANjbmNdwkkE3 1tPQBDhjTtpiEDWu8j8xeaITqqtBNSmAnrJmlufU= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <51563599.2040808@umn.edu> Date: Fri, 29 Mar 2013 22:51:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <031BFC1A-0A5E-488A-A070-7B0CE53FC387@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> <5A1AF2E3-728F-467D-BE05-914C11CF220C@delong.com> <51563599.2040808@umn.edu> To: David Farmer X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 29 Mar 2013 22:52:42 -0700 (PDT) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Documentation Prefixes for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 05:56:35 -0000 On Mar 29, 2013, at 17:45 , David Farmer wrote: > On 3/29/13 17:35 , Owen DeLong wrote: >> This is now an ID available at: >>=20 >> http://www.ietf.org/id/draft-delong-ula-example-00.txt >>=20 >> Unless there is objection, the next version will incorporate the = changes suggested by Iljitsch. >=20 > fd00:2001:db8::/48 should remain a valid ULA prefix as defined in RFC = 4193, but you might want to suggest it may be reasonable to establish = local policy not to use it, even though it remains valid ULA prefix. >=20 >> Are there any other changes people would like to see? >=20 > As for fc00:2001:db8::/48, I would add something like the follow to = what you said; >=20 > If fc00::/8 were defined similar to contemplated in > [draft-ietf-ipv6-ula-central] or [draft-hain-ipv6-ulac], > fc00:2001:db8::/48 should be reserved in such a registry, if such a > registry were ever created for fc00::/8. >=20 Actually, I would rather leave it as is. If the travesty of ULA-C ever = comes to be, then I would not want to limit the authors options with this older document. = Instead, I would expect them to consider this reservation and make a decision whether a = documentation prefix within that space is desirable. If so, then it has already been = set aside for their convenience. If not, then this becomes yet another piece of road kill on = the information super highway. > Where draft-ietf-ipv6-ula-central and draft-hain-ipv6-ulac would be = Informative References. I'd rather not make informative references to expired drafts if I can = avoid it. > Since it has come up, is there any interest in moving forward some = from of ULA-C? Not from me there isn't. > Owen, has your views on the utility of registered ULA softened? Not in the least. Personally, I'd rather eliminate ULA altogether, but = given the current bad situation, not having a documentation prefix is likely to make it worse. = As such, this seeks to use the art of the possible to minimize the damage. Owen From owen@delong.com Fri Mar 29 22:56:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA84E21F8F24 for ; Fri, 29 Mar 2013 22:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43kzv565NxIY for ; Fri, 29 Mar 2013 22:56:56 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCCE21F8F14 for ; Fri, 29 Mar 2013 22:56:56 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2U5tI1O011825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Mar 2013 22:55:19 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2U5tI1O011825 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364622919; bh=OM+3LDKlC1r3LnYP+PEO9gZYbqc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=YloKS/8EfM8cMhX7/zq6aF2kXv+McmknLkJsYyfxCwyUVNV9X31WGE9mga7Oz4chx fVs3+wYbeLh4JAaALYEGe4xEjef8CeY9x1IlvWfzXXBW75Jy3/+lqsqAs2xZpPxsf6 nLPw6Lr633WKVVh1my2c7IDLaJoEDyvu3uTtt+RU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AA09364@nkgeml512-mbx.china.huawei.com> Date: Fri, 29 Mar 2013 22:54:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <375BE199-DEB3-43C2-8CAE-FB54884054BA@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> <5A1AF2E3-728F-467D-BE05-914C11CF220C@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AA09364@nkgeml512-mbx.china.huawei.com> To: Sheng Jiang X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 29 Mar 2013 22:55:19 -0700 (PDT) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Documentation Prefixes for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 05:56:56 -0000 On Mar 29, 2013, at 18:21 , Sheng Jiang wrote: > I support the idea to assign a fixed prefixes for ULA documentation. = fc00:2001:db8::/48 as documentation ULA prefix looks a good idea. >=20 > However, after read the current draft, I am very worried there are = some problem in it. The blow are some concerns I have: >=20 > A, standard track vs informational. Ideally, the ULA Prefix Reserved = for Documentation should be Informational, like RFC 3849 for IPv6 = documentation prefix. However, being informational means it does not = change any standard track meaning or existing implementations. My = reading from the current ID is it requests change on both semantic and = existing implementation. So, for my understanding, it has to be standard = track if it remains the current form. >=20 This will be corrected in -01. > B, semantic change form RFC 4193. RFC4193 has defined L bit "Set to 0 = may be defined in the future". But the current draft has override it by = "registered (fc00::/8)". Personally, I think to create IANA registration = for ULA prefix fc00::/8 may be an idea not bad at all. This need to = formally update RFC4193. Consequently, this work should be done in 6man.=20= >=20 I will also attempt to correct this in -01. If you have language = suggestions, they are appreciated. > C, fd00:2001:db8::/48 has magnificent important to the existing = implementations. It requests all existing implementation to avoid this = ranges in their random algorithm. I am not sure why you need two prefix = for documentation usage. For me, fc00:2001:db8::/48 is enough to = represent ULA. There is no need to distinguish whether its Global ID is = randomly generated or not. Unless you are seeking to make examples of these two different usages of = ULA, which is a very likely scenario should L=3D0 ever become defined. I don't believe fd00:2001:db8::/48 has magnificent importance to = existing implementations and with the corrections to A, even that will = not really be a problem. Owen From dougb@dougbarton.us Fri Mar 29 23:57:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F29D21F8F2B for ; Fri, 29 Mar 2013 23:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRbSIxejpkyy for ; Fri, 29 Mar 2013 23:57:01 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE8E21F8F26 for ; Fri, 29 Mar 2013 23:56:58 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:419a:9be7:fced:aa28] (unknown [IPv6:2001:470:d:5e7:419a:9be7:fced:aa28]) by dougbarton.us (Postfix) with ESMTPSA id A16ED22C58 for ; Sat, 30 Mar 2013 06:56:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1364626617; bh=IskKFwviynnheQKsNrkv8H8dfkJgoOS/1cWuH+RwP48=; h=Date:From:To:Subject:References:In-Reply-To; b=coMLb87yo1cJAIBswi61vDcwnr76ESi9950VmeVaYc4mFpjLxnbTqJdiCXwfCkZ/u II1rfOskSJJk9I6sz9/3K/8jkA73/WAJekp/qgvr99dg97zNPLAXc9PKiY0cbzRu0K 7C27jqvL/5I3B0RsFuLHCPNFqCKbP/VA/i1y3yQY= Message-ID: <51568CB9.7010609@dougbarton.us> Date: Fri, 29 Mar 2013 23:56:57 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <4FC37E442D05A748896589E468752CAA0A671F49@PWN401EA160.ent.corp.bcbsm.com> <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> <51532AEF.2030702@dougbarton.us> <0FACA054-11D6-41D3-9ADB-0EFC7E583415@muada.com> <51533203.5010600@dougbarton.us> <245C63EB-935D-40F6-9949-028BE99CDE1D@muada.com> In-Reply-To: <245C63EB-935D-40F6-9949-028BE99CDE1D@muada.com> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 06:57:02 -0000 On 03/27/2013 12:48 PM, Iljitsch van Beijnum wrote: > On 27 mrt 2013, at 18:53, Doug Barton wrote: > >>> If someone really has a special need in this area, it's probably >>> a better idea to install a routing daemon on their hosts rather >>> than expect ALL hosts connected to the internet to implement >>> something new that comes with additional failure modes. > >> Completely unrealistic. > > You think it's less realistic to install some software under your own > control on devices under your own control than getting IETF rough > consensus after you couldn't get it for (at least) four years, and > then wait for third parties with no skin in the game to implement it > in their software? If there is market demand the "third parties with no skin in the game" will implement it, just like they do every other aspect of the protocol. And no, I don't think "Here is this great protocol, but in order to manage it in a way similar to what you already know and have structures for you have to install stuff on every host" is in any way realistic. It's much more realistic that they'll skip it altogether (kind of like they are doing now). >> And what some people around here seem to be missing is that there >> is absolutely no motivation for them to do so. In fact, there is >> little to no incentive for them to deploy v6 inside an end-user >> network at all right now, and there isn't going to be any time in >> the next 5 years for sure, and likely for another decade if not >> longer. > > IPv4 is a profoundly flawed protocol. But we've used it for 30 years > now. We'll have to use IPv6 for longer than that in all likelihood. > So it's important to refrain from importing those IPv4 flaws in IPv6 > as much as we can. Yeah, I get that is how you feel. However there is a lot of opinion on the side of "things that are already working should be migrated." > For that reason, when a whole bunch of protocol designers tell you a > specific way to implement a feature you like is a bad way to do it, > it might be useful to listen to them, and perhaps explore different > ways to get that same feature. OTOH, when a whole bunch of protocol designers have spent way too much time in their ivory towers and refuse to listen to needs of the people who would be implementing said protocol, it might be useful if they listened to someone who didn't live in the echo chamber with them. See what I did there? :) > So far you haven't bothered to address my suggestion of replacing a > proposed DHCPv6 default router option with a DHCPv6 option that lets > a host select the desired default router from the ones available > through RAs. Um, yeah, no. One of the key goals of a robust DHCPv6 implementation is not having to use RAs at all. What you're proposing not only adds complexity, it has the extra side benefit of not actually meeting that goal. Doug From iljitsch@muada.com Sat Mar 30 00:11:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13C821F8F26 for ; Sat, 30 Mar 2013 00:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sw4JR-nLljll for ; Sat, 30 Mar 2013 00:11:18 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 39F8A21F8EF1 for ; Sat, 30 Mar 2013 00:11:18 -0700 (PDT) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2U7612I070624 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 30 Mar 2013 08:06:02 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <51568CB9.7010609@dougbarton.us> Date: Sat, 30 Mar 2013 08:11:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6EE826D8-F3EA-415B-837A-8DB793BA5617@muada.com> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <4FC37E442D05A748896589E468752CAA0A671F49@PWN401EA160.ent.corp.bcbsm.com> <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> <51532AEF.2030702@dougbarton.us> <0FACA054-11D6-41D3-9ADB-0EFC7E583415@muada.com> <51533203.5010600@dougbarton.us> <245C63EB-935D-40F6-9949-028BE99CDE1D@muada.com> <51568CB9.7010609@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 07:11:19 -0000 On 30 mrt 2013, at 7:56, Doug Barton wrote: > One of the key goals of a robust DHCPv6 implementation is not having = to use RAs at all. What you're proposing not only adds complexity, it = has the extra side benefit of not actually meeting that goal. But without RAs, how do you see M=3D1 so you start up your DHCPv6 = client? Oh wait, you want to run your DHCPv6 client always, even if there is no = M=3D1. This means that networks will see tons of multicasts looking for = a DHCPv6 server, retransmitted at infinitum if there is no DHCPv6 = server, wasting precious airtime on wireless networks where multicasts = are sent at a very low rate because for multicasts, there are no = acknowledgments and therefore they must be sent at a very low bitrate to = make a chance to get through. No thanks. Iljitsch= From dougb@dougbarton.us Sat Mar 30 00:23:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3EE921F8AD5 for ; Sat, 30 Mar 2013 00:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 URG97yBXjsK4 for ; Sat, 30 Mar 2013 00:23:50 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 3411921F8ACE for ; Sat, 30 Mar 2013 00:23:50 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:419a:9be7:fced:aa28] (unknown [IPv6:2001:470:d:5e7:419a:9be7:fced:aa28]) by dougbarton.us (Postfix) with ESMTPSA id DA8E722BBE for ; Sat, 30 Mar 2013 07:23:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1364628230; bh=kf52sI0OhErXPrHc+yDu1khiQclESVh91z8ZmK/R8ow=; h=Date:From:To:Subject:References:In-Reply-To; b=LamKEaTllpvwimnGooIyqURtKvh+2nuchV72KHm/CWbxuyaft+qdJmQFo8BdJ1aT8 Mo23WUwWrutt17aCb9aKIVcuP5+aoiV7gOFf/W+ebHsP/sLtv3i+CukGnoctz5phKj 8mkgTxLHFQgWsNwgcpGPr7VSVY73jeoamhyPPoc8= Message-ID: <51569305.8080706@dougbarton.us> Date: Sat, 30 Mar 2013 00:23:49 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <4FC37E442D05A748896589E468752CAA0A671F49@PWN401EA160.ent.corp.bcbsm.com> <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> <51532AEF.2030702@dougbarton.us> <0FACA054-11D6-41D3-9ADB-0EFC7E583415@muada.com> <51533203.5010600@dougbarton.us> <245C63EB-935D-40F6-9949-028BE99CDE1D@muada.com> <51568CB9.7010609@dougbarton.us> <6EE826D8-F3EA-415B-837A-8DB793BA5617@muada.com> In-Reply-To: <6EE826D8-F3EA-415B-837A-8DB793BA5617@muada.com> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 07:23:50 -0000 On 03/30/2013 12:11 AM, Iljitsch van Beijnum wrote: > On 30 mrt 2013, at 7:56, Doug Barton wrote: > >> One of the key goals of a robust DHCPv6 implementation is not >> having to use RAs at all. What you're proposing not only adds >> complexity, it has the extra side benefit of not actually meeting >> that goal. > > But without RAs, how do you see M=1 so you start up your DHCPv6 > client? I've seen plenty of discussion about how the semantics of the various combinations of M and O bits are not really well understood, less well implemented, and open for discussion. > Oh wait, you want to run your DHCPv6 client always, even if there is > no M=1. Didn't say that. Are you saying that someone would run an IPv6 network with no RA, AND no DHCPv6? I think it's obvious that any implementation of a DHCPv6 routing option would require a decision matrix which takes into consideration the presence and absence of RA, presence/absence of M/O bits, lack of response from a DHCP server, etc. DHCPv4 already has progressive backoff, including eventually giving up. It's not hard to imagine doing the same for v6. In other words, this can be done in a way that takes everyone's needs into account. Stop standing in the way. Doug From sthaug@nethelp.no Sat Mar 30 00:31:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2042421F8B49 for ; Sat, 30 Mar 2013 00:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeVhdaB5Wmc9 for ; Sat, 30 Mar 2013 00:31:09 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 1F12E21F8B45 for ; Sat, 30 Mar 2013 00:31:08 -0700 (PDT) Received: (qmail 60038 invoked from network); 30 Mar 2013 07:31:07 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 30 Mar 2013 07:31:07 -0000 Date: Sat, 30 Mar 2013 08:31:07 +0100 (CET) Message-Id: <20130330.083107.74693658.sthaug@nethelp.no> To: iljitsch@muada.com From: sthaug@nethelp.no In-Reply-To: <6EE826D8-F3EA-415B-837A-8DB793BA5617@muada.com> References: <245C63EB-935D-40F6-9949-028BE99CDE1D@muada.com> <51568CB9.7010609@dougbarton.us> <6EE826D8-F3EA-415B-837A-8DB793BA5617@muada.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: v6ops@ietf.org Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 07:31:10 -0000 > > One of the key goals of a robust DHCPv6 implementation is not having to use RAs at all. What you're proposing not only adds complexity, it has the extra side benefit of not actually meeting that goal. > > But without RAs, how do you see M=1 so you start up your DHCPv6 client? > > Oh wait, you want to run your DHCPv6 client always, even if there is no M=1. This means that networks will see tons of multicasts looking for a DHCPv6 server, retransmitted at infinitum if there is no DHCPv6 server, wasting precious airtime on wireless networks where multicasts are sent at a very low rate because for multicasts, there are no acknowledgments and therefore they must be sent at a very low bitrate to make a chance to get through. How is this worse than current DHCPv4 client behavior? Steinar Haug, AS 2116 From iljitsch@muada.com Sat Mar 30 00:33:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A467E21F8BA4 for ; Sat, 30 Mar 2013 00:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5n6LTcV-jMVO for ; Sat, 30 Mar 2013 00:33:45 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id E586221F8BA1 for ; Sat, 30 Mar 2013 00:33:44 -0700 (PDT) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2U7SZfs070755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 30 Mar 2013 08:28:36 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <51569305.8080706@dougbarton.us> Date: Sat, 30 Mar 2013 08:33:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <86BD2241-A88E-46F6-BEF4-4654E2573936@muada.com> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <4FC37E442D05A748896589E468752CAA0A671F49@PWN401EA160.ent.corp.bcbsm.com> <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> <51532AEF.2030702@dougbarton.us> <0FACA054-11D6-41D3-9ADB-0EFC7E583415@muada.com> <51533203.5010600@dougbarton.us> <245C63EB-935D-40F6-9949-028BE99CDE1D@muada.com> <51568CB9.7010609@dougbarton.us> <6EE826D8-F3EA-415B-837A-8DB793BA5617@muada.com> <51569305.8080706@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 07:33:45 -0000 On 30 mrt 2013, at 8:23, Doug Barton wrote: > I've seen plenty of discussion about how the semantics of the various = combinations of M and O bits are not really well understood, less well = implemented, and open for discussion. So now you want: > I think it's obvious that any implementation of a DHCPv6 routing = option would require a decision matrix which takes into consideration = the presence and absence of RA, presence/absence of M/O bits, lack of = response from a DHCP server, etc. > In other words, this can be done in a way that takes everyone's needs = into account. Stop standing in the way. We finally are in a situation where stateless autoconfiguration and = DHCPv6 work reasonably well together in the real world, and now you want = to mess that up for all of us just because a few people find it = inconvenient to install special purpose software on hosts they want to = have a special purpose configuration. If me standing in the way prevents that from happening, I'm not going = anywhere. But isn't there a slight chance you're giving me too much credit here? Iljitsch= From iljitsch@muada.com Sat Mar 30 00:42:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA2421F8BBD for ; Sat, 30 Mar 2013 00:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLGZ2sTHjQq7 for ; Sat, 30 Mar 2013 00:42:06 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id E930D21F8BBB for ; Sat, 30 Mar 2013 00:42:05 -0700 (PDT) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2U7awAG070796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 30 Mar 2013 08:36:59 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <20130330.083107.74693658.sthaug@nethelp.no> Date: Sat, 30 Mar 2013 08:42:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <245C63EB-935D-40F6-9949-028BE99CDE1D@muada.com> <51568CB9.7010609@dougbarton.us> <6EE826D8-F3EA-415B-837A-8DB793BA5617@muada.com> <20130330.083107.74693658.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.1499) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 07:42:06 -0000 On 30 mrt 2013, at 8:31, sthaug@nethelp.no wrote: >>> you want to run your DHCPv6 client always, even if there is no M=3D1. = This means that networks will see tons of multicasts looking for a = DHCPv6 server, retransmitted at infinitum if there is no DHCPv6 server, = wasting precious airtime on wireless networks where multicasts are sent = at a very low rate > How is this worse than current DHCPv4 client behavior? In the IPv4 world, DHCP is the only game in town. So it's reasonable to = assume the presence of a DHCP server. In the IPv4 world, there can be = stateless autoconfig or DHCPv6 for address assignment. If hosts are = going to solicit an address through DHCPv6 that means everyone has to = run a DHCPv6 server to soak up those requests, even the people who just = want to use stateless autoconfiguration. This would have been a bad idea in 1998, but it's an even worse idea now = with IPv6 implemented widely already. Iljitsch= From dougb@dougbarton.us Sat Mar 30 00:50:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8051521F84DF for ; Sat, 30 Mar 2013 00:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 FUBM3GZSZhD8 for ; Sat, 30 Mar 2013 00:50:35 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id BEF7121F84D9 for ; Sat, 30 Mar 2013 00:50:35 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:419a:9be7:fced:aa28] (unknown [IPv6:2001:470:d:5e7:419a:9be7:fced:aa28]) by dougbarton.us (Postfix) with ESMTPSA id 6791C22BBE for ; Sat, 30 Mar 2013 07:50:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1364629835; bh=/rWe8Qw74jx44OsLui7sEUUf6dFTLgx2FSZauSbDi3M=; h=Date:From:To:Subject:References:In-Reply-To; b=dECUgQF/48d7fMgeFK0dQwa7emUbc8xQamimNcecfv+i7I4tSBenw7PTwU/0o0iga UR/TfsmN1a2XfW0OS8+17fCAlPtW4RF2pHPV6Ydsgh/5tDx7p+GGoAXkVUXJdlp/zd ZGqcY0PLJUuqPB78I72vZu8zKjFcAxL00O8V1k5s= Message-ID: <5156994B.1090204@dougbarton.us> Date: Sat, 30 Mar 2013 00:50:35 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <4FC37E442D05A748896589E468752CAA0A671F49@PWN401EA160.ent.corp.bcbsm.com> <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> <51532AEF.2030702@dougbarton.us> <0FACA054-11D6-41D3-9ADB-0EFC7E583415@muada.com> <51533203.5010600@dougbarton.us> <245C63EB-935D-40F6-9949-028BE99CDE1D@muada.com> <51568CB9.7010609@dougbarton.us> <6EE826D8-F3EA-415B-837A-8DB793BA5617@muada.com> <51569305.8080706@dougbarton.us> <86BD2241-A88E-46F6-BEF4-4654E2573936@muada.com> In-Reply-To: <86BD2241-A88E-46F6-BEF4-4654E2573936@muada.com> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 07:50:36 -0000 On 03/30/2013 12:33 AM, Iljitsch van Beijnum wrote: > We finally are in a situation where stateless autoconfiguration and > DHCPv6 work reasonably well together in the real world ... except for the parts where various critical client configuration options aren't available via RA, and lack of robust DHCP is hindering deployment. > and now you > want to mess that up for all of us just because a few people find it > inconvenient to install special purpose software on hosts they want > to have a special purpose configuration. Your definition of "special purpose" is what most network operators refer to as "how we do things." I've never said I want RA to go away. I think for the limited purpose it was designed for, it's a great tool. When RA was designed 15 years (or so) ago DHCPv4 was still in its early days, and certainly hadn't "won the day" in terms of being ubiquitous, or even particularly mature. However, things changed. DHCPv4 got better, and got implemented pretty much everywhere when it comes to end-user deployments. The whole idea of stateless autoconfiguration is interesting, and has a place for "dumb" endpoints that just need an address and connectivity. But for typical end-user host networks it shouldn't be mandatory. Doug From jiangsheng@huawei.com Sat Mar 30 01:04:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E3221F8AB0 for ; Sat, 30 Mar 2013 01:04:56 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALVOy3saXNfw for ; Sat, 30 Mar 2013 01:04:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 96B8C21F8AA8 for ; Sat, 30 Mar 2013 01:04:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APX45336; Sat, 30 Mar 2013 08:04:51 +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.7; Sat, 30 Mar 2013 08:04:48 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 30 Mar 2013 08:04:48 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.21]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Sat, 30 Mar 2013 16:04:41 +0800 From: Sheng Jiang To: Owen DeLong Thread-Topic: [v6ops] Documentation Prefixes for ULA Thread-Index: AQHOLLOEKpagWuqVpEK8rvz+2BCqepi8mxUAgAACKICAAAQTAIAAGr0AgACtBsD//81/gIAAj6YQ Date: Sat, 30 Mar 2013 08:04:40 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AA097F6@nkgeml512-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> <5A1AF2E3-728F-467D-BE05-914C11CF220C@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AA09364@nkgeml512-mbx.china.huawei.com> <375BE199-DEB3-43C2-8CAE-FB54884054BA@delong.com> In-Reply-To: <375BE199-DEB3-43C2-8CAE-FB54884054BA@delong.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.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Documentation Prefixes for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 08:04:56 -0000 Pj4gQiwgc2VtYW50aWMgY2hhbmdlIGZvcm0gUkZDIDQxOTMuIFJGQzQxOTMgaGFzIGRlZmluZWQg TCBiaXQgIlNldCB0byAwIG1heQ0KPmJlIGRlZmluZWQgaW4gdGhlIGZ1dHVyZSIuIEJ1dCB0aGUg Y3VycmVudCBkcmFmdCBoYXMgb3ZlcnJpZGUgaXQgYnkgInJlZ2lzdGVyZWQNCj4oZmMwMDo6Lzgp Ii4gUGVyc29uYWxseSwgSSB0aGluayB0byBjcmVhdGUgSUFOQSByZWdpc3RyYXRpb24gZm9yIFVM QSBwcmVmaXgNCj5mYzAwOjovOCBtYXkgYmUgYW4gaWRlYSBub3QgYmFkIGF0IGFsbC4gVGhpcyBu ZWVkIHRvIGZvcm1hbGx5IHVwZGF0ZSBSRkM0MTkzLg0KPkNvbnNlcXVlbnRseSwgdGhpcyB3b3Jr IHNob3VsZCBiZSBkb25lIGluIDZtYW4uDQo+DQo+SSB3aWxsIGFsc28gYXR0ZW1wdCB0byBjb3Jy ZWN0IHRoaXMgaW4gLTAxLiBJZiB5b3UgaGF2ZSBsYW5ndWFnZSBzdWdnZXN0aW9ucywNCj50aGV5 IGFyZSBhcHByZWNpYXRlZC4NCg0KSXQgZGVwZW5kcyBvbiB3aGV0aGVyIHlvdSB3YW50IHRvIGNy ZWF0ZSBhIElBTkEgcmVnaXN0cmF0aW9uIGZvciB3aG9sZSBmYzAwOjovOCBvciBub3QuIElmIHll cywgbW9zdCBvZiBVTEEtQyBjYW4gYmUgaW1wb3J0ZWQuIElmIG5vLCB5b3UgY2FuIGp1c3Qgc2F5 IHNvbWV0aGluZyBsaWtlOiB0aGlzIGRvY3VtZW50IHByb3Bvc2VzIHRvIHJlc2VydmUgYSAvNDgg cHJlZml4IGZvciBVTEEgZG9jdW1lbnRhdGlvbiB1c2FnZSBmcm9tIHRoZSBhZGRyZXNzIHNwYWNl IHRoYXQgUkZDNDE5MyByZXNlcnZlZCBmb3IgZnV0dXJlIHVzYWdlLiBJQU5BIHNob3VsZCBjcmVh dGUgYSByZWdpc3RyYXRpb24gZW50cnkgZm9yIHRoaXMgcmVzZXJ2ZWQgLzQ4IHByZWZpeC4NCg0K Pj4gQywgZmQwMDoyMDAxOmRiODo6LzQ4IGhhcyBtYWduaWZpY2VudCBpbXBvcnRhbnQgdG8gdGhl IGV4aXN0aW5nDQo+aW1wbGVtZW50YXRpb25zLiBJdCByZXF1ZXN0cyBhbGwgZXhpc3RpbmcgaW1w bGVtZW50YXRpb24gdG8gYXZvaWQgdGhpcyByYW5nZXMNCj5pbiB0aGVpciByYW5kb20gYWxnb3Jp dGhtLiBJIGFtIG5vdCBzdXJlIHdoeSB5b3UgbmVlZCB0d28gcHJlZml4IGZvcg0KPmRvY3VtZW50 YXRpb24gdXNhZ2UuIEZvciBtZSwgZmMwMDoyMDAxOmRiODo6LzQ4IGlzIGVub3VnaCB0byByZXBy ZXNlbnQNCj5VTEEuIFRoZXJlIGlzIG5vIG5lZWQgdG8gZGlzdGluZ3Vpc2ggd2hldGhlciBpdHMg R2xvYmFsIElEIGlzIHJhbmRvbWx5DQo+Z2VuZXJhdGVkIG9yIG5vdC4NCj4NCj5Vbmxlc3MgeW91 IGFyZSBzZWVraW5nIHRvIG1ha2UgZXhhbXBsZXMgb2YgdGhlc2UgdHdvIGRpZmZlcmVudCB1c2Fn ZXMgb2YNCj5VTEEsIHdoaWNoIGlzIGEgdmVyeSBsaWtlbHkgc2NlbmFyaW8gc2hvdWxkIEw9MCBl dmVyIGJlY29tZSBkZWZpbmVkLg0KDQpVbmxlc3Mgd2UgYXJlIGFscmVhZHkgY2xlYXIgd2hhdCB0 d28gZGlmZmVyZW50IHVzYWdlcyBhcmUsIHdlIGRvbid0IGhhdmUgdG8gZGlzdGluZ3Vpc2ggdGhl bS4gRm9yIG5vdywgd2Ugb25seSBoYXZlIG9uZSBjb25jcmV0ZSBVTEEgdXNhZ2UsIHdoaWNoIGNv dmVycyBieSBMPTEuDQoNCj5JIGRvbid0IGJlbGlldmUgZmQwMDoyMDAxOmRiODo6LzQ4IGhhcyBt YWduaWZpY2VudCBpbXBvcnRhbmNlIHRvIGV4aXN0aW5nDQo+aW1wbGVtZW50YXRpb25zIGFuZCB3 aXRoIHRoZSBjb3JyZWN0aW9ucyB0byBBLCBldmVuIHRoYXQgd2lsbCBub3QgcmVhbGx5IGJlIGEN Cj5wcm9ibGVtLg0KDQpTb3JyeSBmb3IgdHlwby4gSSB3YXMgbWVhbiAibWFnbmlmaWNlbnQgaW1w YWN0Ii4gQWxsIGV4aXN0aW5nIGltcGxlbWVudGF0aW9uIG5lZWQgdG8gYmUgbW9kaWZpZWQgdG8g YXZvaWQgdGhpcyByYW5nZXMgaWYgdGhlaXIgcmFuZG9tIGFsZ29yaXRobXMgaGFwcGVuIHRvIGNv bGxpZGUuIFRoZSBtb2RpZmljYXRpb24gbWF5IG5vdCBiZSBiaWcuIFBlcnNvbmFsbHksIEkgYmVs aWV2ZSBJRVRGIHNob3VsZCBhdm9pZCB0byBjaGFuZ2UgZXhpc3RpbmcgaW1wbGVtZW50YXRpb24g YXMgbXVjaCBhcyBwb3NzaWJsZS4NCg0KPk93ZW4NCg0K From tarko@lanparty.ee Sat Mar 30 01:09:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B56221F8B35 for ; Sat, 30 Mar 2013 01:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9DEbbsOnWUQ for ; Sat, 30 Mar 2013 01:09:04 -0700 (PDT) Received: from valgus.lanparty.ee (valgus.lanparty.ee [194.126.124.108]) by ietfa.amsl.com (Postfix) with ESMTP id CC23D21F8B27 for ; Sat, 30 Mar 2013 01:09:03 -0700 (PDT) Received: from hg.lanparty.ee ([194.126.106.156] helo=[10.10.10.41]) by valgus.lanparty.ee with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1ULqqU-0003yi-0X for v6ops@ietf.org; Sat, 30 Mar 2013 10:09:02 +0200 Message-ID: <51569D9D.7070900@lanparty.ee> Date: Sat, 30 Mar 2013 10:09:01 +0200 From: Tarko Tikan User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <4FC37E442D05A748896589E468752CAA0A671F49@PWN401EA160.ent.corp.bcbsm.com> <586D6C25-E0B2-4C86-A25F-422418A7C652@muada.com> <51532AEF.2030702@dougbarton.us> <0FACA054-11D6-41D3-9ADB-0EFC7E583415@muada.com> <51533203.5010600@dougbarton.us> <245C63EB-935D-40F6-9949-028BE99CDE1D@muada.com> <51568CB9.7010609@dougbarton.us> <6EE826D8-F3EA-415B-837A-8DB793BA5617@muada.com> <51569305.8080706@dougbarton.us> In-Reply-To: <51569305.8080706@dougbarton.us> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 194.126.106.156 X-SA-Exim-Mail-From: tarko@lanparty.ee X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on valgus.lanparty.ee) Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 08:09:04 -0000 hey, > I've seen plenty of discussion about how the semantics of the various > combinations of M and O bits are not really well understood, less well > implemented, and open for discussion. Yes, it's broken. No way to influence if end host/router should do IA_NA or IA_PD or both. There is no correct config if you want to provide PD only and run your HGW uplinks unnumbered. Sure, set M, some routers will not start DHCPv6 without it at all, others will. Still have to manually configure routers to make PD only request. And you will still get NA requests from misconfigured routers or people attaching PCs directly to the uplinks. As a network provider, mess around RA+DHCPv6 is much worse than putting routing information into DHCPv6 and killing RA altogether. -- tarko From brian.e.carpenter@gmail.com Sat Mar 30 01:23:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6020521F8B0B for ; Sat, 30 Mar 2013 01:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, 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 xp-vVOYNTXz8 for ; Sat, 30 Mar 2013 01:23:16 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id B433021F8B08 for ; Sat, 30 Mar 2013 01:23:14 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id f12so928940wgh.10 for ; Sat, 30 Mar 2013 01:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=o8AIQ1oGUcBiPfWQKQ+plBkUtYd2G+hNkLDjC22XXGE=; b=Ygzxyt1EwnNn7rGh6WzQjS8EJsoRPG6D1gcHvwc+H0oyKP2uhGmzpIVlWPhChJIwj3 vgaPhmv4E4OW47HR9fh6HW/qTPSpdkBVYraMXYrKrKeF5zSly5NAOipYdgoeK1My4nd0 y99eXNsdLcQCA6x4OiLsRyk6jGEeFn7ebO98N1enEpN86NvQEGCmKCNI+4Oy9efVmwON whXQAdgDQJ6NFsP8iWTDnPLy+yxnOmgANG08heUJzMxezkjU30ozR7ZcvemXz+pPdk4U SY/fLLD9XtbQZRtOxIEwIPf0HKEK7crkJnYaBiAbaotVMOtRGQMaS7C+b8Q/k5UkvqmE V8LA== X-Received: by 10.180.12.33 with SMTP id v1mr1689058wib.24.1364631793136; Sat, 30 Mar 2013 01:23:13 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-115.as13285.net. [2.102.216.115]) by mx.google.com with ESMTPS id ej8sm2070243wib.9.2013.03.30.01.23.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 30 Mar 2013 01:23:12 -0700 (PDT) Message-ID: <5156A0FB.1060603@gmail.com> Date: Sat, 30 Mar 2013 08:23:23 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David Farmer References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> <5A1AF2E3-728F-467D-BE05-914C11CF220C@delong.com> <51563599.2040808@umn.edu> In-Reply-To: <51563599.2040808@umn.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Documentation Prefixes for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 08:23:17 -0000 On 30/03/2013 00:45, David Farmer wrote: ... > Since it has come up, is there any interest in moving forward some from > of ULA-C? I don't see why. Although it could be automated, there is a cost involved in any form of guaranteed uniqueness, and that cost simply isn't justified by the tiny probability of a ULA prefix collision. The considerably greater cost of a PI prefix applies if a site wants routeability, but that's beside the point. As for Owen's draft, I have a counter-proposal. Just use the "zero" addresses as the documentation prefixes: The proposed prefixes are fd00::/48 (example Locally Assigned Global ID) and fc00::/48 (example possible future use), respectively. These will work perfectly well as examples, and are simple and straightforward to include in operational filters and exclude in ULA-generation algorithms. Also, using them as the documentation prefixes will make it even more egregious to use them as lazy choices. Brian PS I think the draft belongs in 6man. From brian.e.carpenter@gmail.com Sat Mar 30 01:46:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C627121F89D8 for ; Sat, 30 Mar 2013 01:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, 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 bTooHs4Kw1y1 for ; Sat, 30 Mar 2013 01:46:58 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id 2667221F89D3 for ; Sat, 30 Mar 2013 01:46:57 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id y10so908086wgg.2 for ; Sat, 30 Mar 2013 01:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Duo3Q8+V92nC0mksrfrQCBk/r2yOwV5FGLiwpgD00fE=; b=q5kTjbgC8vAeM72Ro7HBnaLj0PZnnMINw/MZDKH8CjVwacC9ruMxFhAbw7yBGt1ALC zVxehLP/tv0KPlFA/PublrSHZxLtCQyJBK23HMQkeI28YtnSulgd/lCRTsC0xFHOxrd0 rLejkw2AHAv1WMW8otJbPUsR6ddvgFlzyvaEbxM/QbDXzpZzoQavf1ziQpCuxc4X7wbf PkH/5h9W3g9koFhh8an6egThIB1IZ8ITHsUwpxTuKkbZB834XCh/k948K3Ik0dbM4dWA o1bjNF1d+Y5awibK2UaHlfu8Wtt12JnLV/MWqwAEiU/5HeXhz0P5tNtxDj2gwl9/F4C4 W+8A== X-Received: by 10.180.79.6 with SMTP id f6mr1732876wix.26.1364633217309; Sat, 30 Mar 2013 01:46:57 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-115.as13285.net. [2.102.216.115]) by mx.google.com with ESMTPS id g4sm2445457wib.11.2013.03.30.01.46.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 30 Mar 2013 01:46:56 -0700 (PDT) Message-ID: <5156A690.4000506@gmail.com> Date: Sat, 30 Mar 2013 08:47:12 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Owen DeLong References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6ECA24@nkgeml506-mbx.china.huawei.com> <731D2903-56BD-4A4D-9D86-EC1C3CF9D5E1@delong.com> In-Reply-To: <731D2903-56BD-4A4D-9D86-EC1C3CF9D5E1@delong.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 08:46:58 -0000 On 29/03/2013 17:58, Owen DeLong wrote: ... > Even if you choose to use ULA for stable internal addressing, there is still no valid reason not to use PA or PI space for your external connectivity. With an emphasis on the "or". A billion SOHOs each with their own PI prefix announced in BGP4+ is not a realistic option. If 99.99% of SOHOs use a PA prefix, we will be fine. Those are not unrealistic numbers. Brian From iljitsch@muada.com Sat Mar 30 01:48:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7E021F8A38 for ; Sat, 30 Mar 2013 01:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+TVctwPwsra for ; Sat, 30 Mar 2013 01:48:19 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 3056C21F8A2A for ; Sat, 30 Mar 2013 01:48:19 -0700 (PDT) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2U8hCQ3071219 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 30 Mar 2013 09:43:12 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <5156A0FB.1060603@gmail.com> Date: Sat, 30 Mar 2013 09:48:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6FE499A1-D1C8-49AB-8D36-D7BD7A59D845@muada.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> <5A1AF2E3-728F-467D-BE05-914C11CF220C@delong.com> <51563599.2040808@umn.edu> <5156A0FB.1060603@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1499) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Documentation Prefixes for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 08:48:20 -0000 On 30 mrt 2013, at 9:23, Brian E Carpenter = wrote: > As for Owen's draft, I have a counter-proposal. Just use the "zero" > addresses as the documentation prefixes: Hm, the downside of that is that due to the zero compression those = prefixes look very different from "normal" ones and thus don't make for = good examples. Of course anyone can generate any number of ULAs to do with as they = please, including using them in examples. Iljitsch= From randy@psg.com Sat Mar 30 01:51:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6559C21F8AC3 for ; Sat, 30 Mar 2013 01:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 oxGIMm7i9Hqi for ; Sat, 30 Mar 2013 01:51:12 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id E504221F8A91 for ; Sat, 30 Mar 2013 01:51:12 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1ULrVG-000Hw8-FG; Sat, 30 Mar 2013 08:51:10 +0000 Date: Sat, 30 Mar 2013 17:51:09 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <5156A0FB.1060603@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <51547A5C.8030409@gmail.com> <895761CC-A25C-4FE4-84AD-76325ED8095A@delong.com> <5A1AF2E3-728F-467D-BE05-914C11CF220C@delong.com> <51563599.2040808@umn.edu> <5156A0FB.1060603@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] Documentation Prefixes for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 08:51:13 -0000 >> Since it has come up, is there any interest in moving forward some >> from of ULA-C? > I don't see why. Although it could be automated, there is a cost > involved in any form of guaranteed uniqueness we could have internet registry or registries keep track of assignments. ;~> randy From brian.e.carpenter@gmail.com Sat Mar 30 01:54:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCFD021F8B0A for ; Sat, 30 Mar 2013 01:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.306 X-Spam-Level: X-Spam-Status: No, score=-100.306 tagged_above=-999 required=5 tests=[AWL=-1.385, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 n2xuo+LQyeYe for ; Sat, 30 Mar 2013 01:54:04 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2B24C21F8B11 for ; Sat, 30 Mar 2013 01:54:03 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id d7so773818wer.40 for ; Sat, 30 Mar 2013 01:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=y3+1Q38GuL9KebHlYbSILJ2UfLPGlaqtQuCCSN6SDBY=; b=dDRU4E2S6P7mWaTFg/2V8E7R9LcTQRT2ckwYrqrurHZox1i9yrI+PHXZDeotn3F7VV 9dcpqdiVA+XbFRc5RozuaTmFYK2ojxaOiS4RhlsHxMjz553Y55o7eB0cEPg6s2sMjsXS VywY4aZPyxuvHJHJa6lcOapTZW1oH8mONuWPPN/anpQUTSuDxesymkD8zyyyv9OwHoWy H4zfnc2mCqplckTMyGFrXH5FcxZ4S3WIc/+CbFY0jEFhuRZk+MjLjSVyUOeBeOHwNDEC p96TbWN3nYPVQNgLDJ8nalJGCBIEW0FHUuVl+lc6+7hU6nBCiOgieRqjtsK8Rpnh7WjU 2CFg== X-Received: by 10.194.93.97 with SMTP id ct1mr7112274wjb.48.1364633643368; Sat, 30 Mar 2013 01:54:03 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-115.as13285.net. [2.102.216.115]) by mx.google.com with ESMTPS id s2sm2544003wib.4.2013.03.30.01.54.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 30 Mar 2013 01:54:02 -0700 (PDT) Message-ID: <5156A83A.2090604@gmail.com> Date: Sat, 30 Mar 2013 08:54:18 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <245C63EB-935D-40F6-9949-028BE99CDE1D@muada.com> <51568CB9.7010609@dougbarton.us> <6EE826D8-F3EA-415B-837A-8DB793BA5617@muada.com> <20130330.083107.74693658.sthaug@nethelp.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: [v6ops] dhcpv6-slaac-problem [was Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client?] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 08:54:04 -0000 On 30/03/2013 07:42, Iljitsch van Beijnum wrote: > On 30 mrt 2013, at 8:31, sthaug@nethelp.no wrote: > >>>> you want to run your DHCPv6 client always, even if there is no M=1. This means that networks will see tons of multicasts looking for a DHCPv6 server, retransmitted at infinitum if there is no DHCPv6 server, wasting precious airtime on wireless networks where multicasts are sent at a very low rate > >> How is this worse than current DHCPv4 client behavior? > > In the IPv4 world, DHCP is the only game in town. So it's reasonable to assume the presence of a DHCP server. In the IPv4 world, there can be stateless autoconfig or DHCPv6 for address assignment. If hosts are going to solicit an address through DHCPv6 that means everyone has to run a DHCPv6 server to soak up those requests, even the people who just want to use stateless autoconfiguration. I think people should look at draft-liu-bonica-dhcpv6-slaac-problem, because it really is time to resolve this issue. And it's orthogonal to the default/source route issue. Brian From leo.liubing@huawei.com Sat Mar 30 02:44:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63FF21F86F5 for ; Sat, 30 Mar 2013 02:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.074 X-Spam-Level: X-Spam-Status: No, score=-6.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 AEh1L4KhP6-k for ; Sat, 30 Mar 2013 02:44:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B9B3521F86F0 for ; Sat, 30 Mar 2013 02:44:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARG31987; Sat, 30 Mar 2013 09:44:05 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 30 Mar 2013 09:44:04 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 30 Mar 2013 09:44:04 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.42]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.01.0323.007; Sat, 30 Mar 2013 17:44:02 +0800 From: "Liubing (Leo)" To: Brian E Carpenter , Iljitsch van Beijnum Thread-Topic: [v6ops] dhcpv6-slaac-problem [was Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client?] Thread-Index: AQHOLSQnH1oAQEnPN0iF2Ic0n8/Uzpi99h/A Date: Sat, 30 Mar 2013 09:44:02 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6ED152@nkgeml506-mbx.china.huawei.com> References: <245C63EB-935D-40F6-9949-028BE99CDE1D@muada.com> <51568CB9.7010609@dougbarton.us> <6EE826D8-F3EA-415B-837A-8DB793BA5617@muada.com> <20130330.083107.74693658.sthaug@nethelp.no> <5156A83A.2090604@gmail.com> In-Reply-To: <5156A83A.2090604@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] dhcpv6-slaac-problem [was Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client?] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 09:44:08 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Brian E Carpenter > Sent: Saturday, March 30, 2013 4:54 PM > To: Iljitsch van Beijnum > Cc: v6ops@ietf.org WG > Subject: [v6ops] dhcpv6-slaac-problem [was Interest in DHCPv6 > Route/DefRouter/Src-basedRoute configuration to Client?] >=20 > On 30/03/2013 07:42, Iljitsch van Beijnum wrote: > > On 30 mrt 2013, at 8:31, sthaug@nethelp.no wrote: > > > >>>> you want to run your DHCPv6 client always, even if there is no M=3D1= . > This means that networks will see tons of multicasts looking for a DHCPv6 > server, retransmitted at infinitum if there is no DHCPv6 server, wasting > precious airtime on wireless networks where multicasts are sent at a very > low rate > > > >> How is this worse than current DHCPv4 client behavior? > > > > In the IPv4 world, DHCP is the only game in town. So it's reasonable to > assume the presence of a DHCP server. In the IPv4 world, there can be > stateless autoconfig or DHCPv6 for address assignment. If hosts are going= to > solicit an address through DHCPv6 that means everyone has to run a DHCPv6 > server to soak up those requests, even the people who just want to use > stateless autoconfiguration. >=20 > I think people should look at draft-liu-bonica-dhcpv6-slaac-problem, > because it really is time to resolve this issue. And it's > orthogonal to the default/source route issue. [Bing] Hi, Brian, thank you mentioned this. Hope more people could notice t= he problem.=20 Let me to summarize several important points of the draft here:=20 - at initial state, Win7 would start DHCPv6 solicit if no RA received, whil= e Linux/MAC won't start DHCPv6 unless received M=3D1 - the hosts configured by SLAAC first, and then M changed from 0 to 1, Win7= would initiate DHCPv6 along with SLAAC; Linux/MAC did nothing - the hosts configured by DHCPv6 first, and then M changed from 1 to 0, Win= 7 would release DHCPv6 address while Linux/MAC did nothing These different behaviors would be problematic especially when renumbering.= =20 >=20 > Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From iljitsch@muada.com Sat Mar 30 02:44:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E5721F875A for ; Sat, 30 Mar 2013 02:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEkq4kyvsJWp for ; Sat, 30 Mar 2013 02:44:38 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id A1BD421F874B for ; Sat, 30 Mar 2013 02:44:37 -0700 (PDT) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r2U9dUPw071515 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 30 Mar 2013 10:39:30 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <5156A83A.2090604@gmail.com> Date: Sat, 30 Mar 2013 10:44:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <245C63EB-935D-40F6-9949-028BE99CDE1D@muada.com> <51568CB9.7010609@dougbarton.us> <6EE826D8-F3EA-415B-837A-8DB793BA5617@muada.com> <20130330.083107.74693658.sthaug@nethelp.no> <5156A83A.2090604@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1499) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 09:44:38 -0000 On 30 mrt 2013, at 9:54, Brian E Carpenter = wrote: > I think people should look at draft-liu-bonica-dhcpv6-slaac-problem, > because it really is time to resolve this issue. And it's > orthogonal to the default/source route issue. That draft mainly looks at what happens when the different bits go from = 1 to 0. While it's useful to clean up the differences in behavior for = that case, all of that seems largely orthogonal to the issues we were = discussing previously. Other than the above, my vote is for leaving well enough alone. But if we collectively decide that the status quo is insufficient, we = need to make changes in the right way, not haphazardly throw new DHCP = options against the wall and see which ones stick. Going back to first principle, if we want to support both some form of = stateless autoconfiguration as well as some form of centrally managed = configuration, it makes sense that hosts send one message that can = initiate either or both rather than have two protocols that operate = independently. This saves on messages exchanged, timeouts incurred and = client-side guessing required. Fortunately, it looks like the IPv6 designers knew what they were doing = (for the most part) back in the day, and allowed pretty much every = message to have options. So what we could do is put a DHCPv6 request = inside a router solicitation message, and thus have a single message = that can initiate both stateless autoconfig and DHCPv6. We now also have = a clean upgrade path: old hosts don't include the DHCPv6 request and get = back a normal RA (with A=3D1 and/or M=3D1 as desired). The same is true = for new hosts that talk to old routers. But when a new host talks to a = new router, we get to throw out all the old behavior. Then, for = instance, the router can send back a regular RA, or relay the DHCPv6 = message to a DHCPv6 server, which can take it from there. Iljitsch= From Ted.Lemon@nominum.com Sat Mar 30 07:10:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6873721F87C5 for ; Sat, 30 Mar 2013 07:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNVydB1VXOUs for ; Sat, 30 Mar 2013 07:10:42 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id ADF6621F87A4 for ; Sat, 30 Mar 2013 07:10:42 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUVbyYv0Cuze0mg8KnYnSJewNOB3VnSiK@postini.com; Sat, 30 Mar 2013 07:10:42 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E665C108163 for ; Sat, 30 Mar 2013 07:10:41 -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 B814419005C; Sat, 30 Mar 2013 07:10:41 -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.0318.004; Sat, 30 Mar 2013 07:10:41 -0700 From: Ted Lemon To: Iljitsch van Beijnum Thread-Topic: [v6ops] dhcpv6-slaac-problem Thread-Index: AQHOLSs9bvEC1tE4bkGvzWLh43T+hpi+u7qA Date: Sat, 30 Mar 2013 14:10:41 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775127A32@mbx-01.win.nominum.com> References: <245C63EB-935D-40F6-9949-028BE99CDE1D@muada.com> <51568CB9.7010609@dougbarton.us> <6EE826D8-F3EA-415B-837A-8DB793BA5617@muada.com> <20130330.083107.74693658.sthaug@nethelp.no> <5156A83A.2090604@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 14:10:43 -0000 On Mar 30, 2013, at 5:44 AM, Iljitsch van Beijnum wrot= e: > Fortunately, it looks like the IPv6 designers knew what they were doing (= for the most part) back in the day, and allowed pretty much every message t= o have options. So what we could do is put a DHCPv6 request inside a router= solicitation message, and thus have a single message that can initiate bot= h stateless autoconfig and DHCPv6. We now also have a clean upgrade path: o= ld hosts don't include the DHCPv6 request and get back a normal RA (with A= =3D1 and/or M=3D1 as desired). The same is true for new hosts that talk to = old routers. But when a new host talks to a new router, we get to throw out= all the old behavior. Then, for instance, the router can send back a regul= ar RA, or relay the DHCPv6 message to a DHCPv6 server, which can take it fr= om there. Interesting. And on the way back (since the relay chain plays in both dir= ections) the response could come back to the host as a DHCPv6 message encap= sulated in an RA that also contained prefix information, and now you have f= ate sharing and DHCP in a single exchange. From alexandru.petrescu@gmail.com Sat Mar 30 07:16:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C0121F8556 for ; Sat, 30 Mar 2013 07:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.779 X-Spam-Level: X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_13=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.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 5vUIuR8zZTV0 for ; Sat, 30 Mar 2013 07:16:04 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id D9C5421F8546 for ; Sat, 30 Mar 2013 07:16:02 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 83BDA9400D3 for ; Sat, 30 Mar 2013 15:15:57 +0100 (CET) Message-ID: <5156F398.4070902@gmail.com> Date: Sat, 30 Mar 2013 15:15:52 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <245C63EB-935D-40F6-9949-028BE99CDE1D@muada.com> <51568CB9.7010609@dougbarton.us> <6EE826D8-F3EA-415B-837A-8DB793BA5617@muada.com> <20130330.083107.74693658.sthaug@nethelp.no> <5156A83A.2090604@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775127A32@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775127A32@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130330-0, 30/03/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [v6ops] dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 14:16:04 -0000 Le 30/03/2013 15:10, Ted Lemon a écrit : > On Mar 30, 2013, at 5:44 AM, Iljitsch van Beijnum > wrote: >> Fortunately, it looks like the IPv6 designers knew what they were >> doing (for the most part) back in the day, and allowed pretty much >> every message to have options. So what we could do is put a DHCPv6 >> request inside a router solicitation message, and thus have a >> single message that can initiate both stateless autoconfig and >> DHCPv6. We now also have a clean upgrade path: old hosts don't >> include the DHCPv6 request and get back a normal RA (with A=1 >> and/or M=1 as desired). The same is true for new hosts that talk to >> old routers. But when a new host talks to a new router, we get to >> throw out all the old behavior. Then, for instance, the router can >> send back a regular RA, or relay the DHCPv6 message to a DHCPv6 >> server, which can take it from there. > > Interesting. And on the way back (since the relay chain plays in > both directions) the response could come back to the host as a DHCPv6 > message encapsulated in an RA that also contained prefix information, > and now you have fate sharing and DHCP in a single exchange. I think too it is interesting. The message encoding ('encapsulate DHCP messages - Solicit in RS, Adv in RA, etc.) is a matter how to encode. One may also encode the same behaviour without really encapsulating IP in IP. Or a middle ground somewhere. (we approached a similar thing when we tried to realize Prefix Delegation with RS/RA - engineered the typical PD operations down into RS/RA messages - draft-kaiser-nd-pd-01) Alex > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From pkern@spike.0x539.de Sat Mar 30 10:09:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B883F21F8814 for ; Sat, 30 Mar 2013 10:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] 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 cKDhCQQGQo01 for ; Sat, 30 Mar 2013 10:09:03 -0700 (PDT) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id 8150721F87AB for ; Sat, 30 Mar 2013 10:09:01 -0700 (PDT) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1ULzH1-0008Fr-5K for v6ops@ietf.org; Sat, 30 Mar 2013 18:08:59 +0100 Received: from p2003006b0d036c01c5058db06ec2bf0b.dip.t-dialin.net ([2003:6b:d03:6c01:c505:8db0:6ec2:bf0b] helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ULzH1-0004yX-Qi for v6ops@ietf.org; Sat, 30 Mar 2013 18:09:00 +0100 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1ULzH1-0006un-Dh for v6ops@ietf.org; Sat, 30 Mar 2013 18:08:59 +0100 Date: Sat, 30 Mar 2013 18:08:59 +0100 From: Philipp Kern To: "v6ops@ietf.org" Message-ID: <20130330170859.GA25715@spike.0x539.de> References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <51425EB5.6040703@dougbarton.us> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <1363805194.86628.YahooMailNeo@web142505.mail.bf1.yahoo.com> <20130320185148.GA26639@spike.0x539.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="98e8jtXdkpgskNou" Content-Disposition: inline In-Reply-To: <20130320185148.GA26639@spike.0x539.de> Organization: 0x539 dev group User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 17:09:06 -0000 --98e8jtXdkpgskNou Content-Type: multipart/mixed; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2013 at 07:51:48PM +0100, Philipp Kern wrote: > On Wed, Mar 20, 2013 at 11:46:34AM -0700, Mark Smith wrote: > > The Fritzbox CPE a few years back made a failed attempt at using ULAs. = They > > did exactly that i.e. no random ID, and attempted to *swap* the ULA for= the > > GUA when the GUA disappeared due to the WAN link going down and vice > > versa. > I need to check it again but that's exactly what a DTAG CPE (Speedport) in > Germany does. You can turn on ULAs through the web interface and don't ev= en get > to pick the bits. My personal guess is that DTAG fixed it on all but I do= n't > have multiple devices to test. Ok, the device does not actually revoke the ULA but keeps it. The remaining= bit is still true: you don't get to pick your ULA, not even the subnet bits. In case somebody wonders about this a screenshot (in German) is attached. Maybe they hash the MAC or something, a Google search of the ULA prefix does not = turn up anything. They even revoke the ULA prefix correctly when the flag is uns= et in the web interface. So maybe I should give them the benefit of the doubt that the ULA is somewhat random=E2=80=A6 Kind regards Philipp Kern --HcAYCG3uE/tztfnV Content-Type: application/pdf Content-Disposition: attachment; filename="speedport-lan-config.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjUKJbXtrvsKMyAwIG9iago8PCAvTGVuZ3RoIDQgMCBSCiAgIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlCj4+CnN0cmVhbQp4nCvkKuTSTzRQSC9W0K8wVXDJ5woEQgBAEAVACmVuZHN0 cmVhbQplbmRvYmoKNCAwIG9iagogICAyOAplbmRvYmoKMiAwIG9iago8PAogICAvRXh0R1N0 YXRlIDw8CiAgICAgIC9hMCA8PCAvQ0EgMSAvY2EgMSA+PgogICA+PgogICAvWE9iamVjdCA8 PCAveDUgNSAwIFIgPj4KPj4KZW5kb2JqCjYgMCBvYmoKPDwgL1R5cGUgL1BhZ2UKICAgL1Bh cmVudCAxIDAgUgogICAvTWVkaWFCb3ggWyAwIDAgNTk0IDQ4MCBdCiAgIC9Db250ZW50cyAz IDAgUgogICAvR3JvdXAgPDwKICAgICAgL1R5cGUgL0dyb3VwCiAgICAgIC9TIC9UcmFuc3Bh cmVuY3kKICAgICAgL0kgdHJ1ZQogICAgICAvQ1MgL0RldmljZVJHQgogICA+PgogICAvUmVz b3VyY2VzIDIgMCBSCj4+CmVuZG9iago1IDAgb2JqCjw8IC9MZW5ndGggOCAwIFIKICAgL0Zp bHRlciAvRmxhdGVEZWNvZGUKICAgL1R5cGUgL1hPYmplY3QKICAgL1N1YnR5cGUgL0Zvcm0K ICAgL0JCb3ggWyAwIDAgNTk0IDQ4MCBdCiAgIC9Hcm91cCA8PAogICAgICAvVHlwZSAvR3Jv dXAKICAgICAgL1MgL1RyYW5zcGFyZW5jeQogICAgICAvSSB0cnVlCiAgICAgIC9DUyAvRGV2 aWNlUkdCCiAgID4+CiAgIC9SZXNvdXJjZXMgNyAwIFIKPj4Kc3RyZWFtCnicK+Qq5DK1NFEw AEITCwMwnZzLpZ9ooJBerKBfYangks8VCIQAtccI3AplbmRzdHJlYW0KZW5kb2JqCjggMCBv YmoKICAgNDIKZW5kb2JqCjcgMCBvYmoKPDwKICAgL0V4dEdTdGF0ZSA8PAogICAgICAvYTAg PDwgL0NBIDEgL2NhIDEgPj4KICAgPj4KICAgL1hPYmplY3QgPDwgL3g5IDkgMCBSID4+Cj4+ CmVuZG9iago5IDAgb2JqCjw8IC9MZW5ndGggMTAgMCBSCiAgIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlCiAgIC9UeXBlIC9YT2JqZWN0CiAgIC9TdWJ0eXBlIC9JbWFnZQogICAvV2lkdGggNTk0 CiAgIC9IZWlnaHQgNDgwCiAgIC9Db2xvclNwYWNlIC9EZXZpY2VSR0IKICAgL0ludGVycG9s YXRlIHRydWUKICAgL0JpdHNQZXJDb21wb25lbnQgOAo+PgpzdHJlYW0KeJzsnQdgFMX3x0m/ dEIooYUivapIUVSkI016kV6F0HsP1R/NBqKC/q1YAcUCKqKIlFBSIEAIkBBCei/Xe/5vb+4m m7295e5IuXDvw+by5r2ZN7ObZb6Z3b1LSQmCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiC INWJvAU/ptRYydkkhy5xquUM+gRqWkqS0WaPQLT6ormfZ8fRYFO86wxkEKgg/z3e/vEhCIIg NgKzN2jWI6uh6tmHsOpB1JqDjyAIgpQXqHoCVLTqWXnwEQRBkPLC0sQr/z0epmsIwStM3VT1 VFGpxAkbOEllonrkYinYUIcmJzXBSS7lMZ6gjdCQ+CGzpYFBNdIEstGaugI5+MEDSkSHQXsE J0R5MzO7E7QRmpMi2SPeEZL1F8nDJDTtPtlfkoEcDaKJYJORwCt4SgxayR4bUT1oSPea1CSC SLbH+QkiCIIg1sN7X6/EpHp0BUfmeZi6YcYmekHmdlKBzO1ENYgKlJiWOVRKQEegCemOrJ6I TZXIfGAkOclDOqXiBa9UhYmMsp2kCRVfAoyKrtqIxvGOkO0kukZEir2/bNUDJ3TN2KbeyREA JxkbOZ7ESWSRHiJc6yEIglQywms9Khxknuc4iVKUlL3CSZZmZElIF4MlhrUb1CdrPXYXlh7n IAJHumZWSQabSiEbUoF0AZ1aWj/S9R3NzDtCulMlZlc4aYiterQ7MgxGfFlNqLKza9JDhKqH IAhSyQirHlmblJjmeXLFz3xhyNYaqhT0Kh/diOrR7oRVr8QgQ2S5RHSK2iUG4aDXVNkrQXoV EQw6eAK9Okqv1vKOkP2ECdkXOkKy++Bkqx4VOKJ6lpqYHzeog6qHIAhSydikesRpfk3S0lrP fF1mk+pBZaJi5KYYXfHRG2pEejhLthLTDT6Ok/ZOl6u8IxRQPd61Hkf1OMs6cr2UOM33FFUP QRCkkrFJ9chyiagJ+x4fefwDpIQ4ze/rkSUPZ3XzSNWjT9SUlL27R7IR5aJ+9vVG9j0484RU DXlHaK567Jt05vf1OKpXwrqFRx9rKSl7X49c5oWc7KupCIIgSCXA+zQLXdZxVK+k7DOcdBon Skee3KBOTnKiR7yqRwzeNwiUeWqFJZHsK5l0Dch+hpM+b8mB/UwL7wh5VY99HbXkUapHpF/4 GU7246l0Meuw6z7zM0R4S05OlslkVT1qBEEQxwXmfPyUEseEXJ41bkEbfx+y7evN++GVeEjx s6U76e8bsB06dAiEr6oHjiAI4qCQxZGltzAgVQtVvWPPLFu+bPmBAwdOnjxJVQ+cxHP48GG6 wt2+fXtcXFxVDxxBEARBbMb4AGrQRpA8WMSBnOXk5NArw6B6oHewsgNnREQEWfHB0g9VD0EQ BKmOENWDxR2s4EDXyA07juqB5IETQsQPqgc1lUplVY8dQRAEQWyDPHIDQgbqlpmZSZy8qldi ekIJVQ9BEASpphDVO3ToEF3olVhWPbIw/HrzflQ9BEEQpDoC4hUXF3fy5En2rTpLqseujKqH IAiCVEdgiZeZmcl+C54l1eOtjCAIgiCVgDXvHLevjrnqVVxfWAfrYB2sg3Wwjnkd4Vbk/QXl VUdY9cq3L6yDdbAO1sE6WMe8jnArS+8ct6+OsOqVb19YB+tgHayDdbCOeZ3K7B1VD+tgHayD dbBO1dYxB5aEIEnbDVhaIdpXx1z1Kq4vrIN1sA7WwTpYx7yOOTKZDGrGGUi2cDfQvjrmqldx fWEdrIN1sA7WwTrmdSoTgXcuIAiCIMgTBqoegiAI4iQolUr6R4VSgjYeZn0+J4IgCII8MUgO XYJVXqnkmYQPnMW7zshkMvwUMgRBEOSJoYzYmW0RERF4qRNBEAR5YsjMzDx58uSBAwe2m0H+ ojpe6kQQBEGeGNiPkprjCA+XIgiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiC IAiCIAiCIAiCIAiCIAiCIIh9CH+eKm644Yab42y2zm8FBQWHDh3aZSAqKqoiplBhoNPTp0/D MCqz09MG2J2SYbCPAERJNXbD+/fvn+aDnYoeT6jM6Rc8JHTkyBF2L+ZH3rzrSsN4Ih26hxtu uOHm4JutwgeTbVBQUA0Wc+fOrbjplJd+/fpBvxU3w/NKeZcuXaBTkCeOB16pB7SJ46FOc8j4 QdRIHsqaNWtoW+iOHYKaBQbAhp8CZ8zgbN68eXkdBOshp5B+/239+7dLX4nB2TCKUYw6Z7TK B1A2apPwwbwKsyvM5DBpw5xMFJCtBZVAhaoekXVzP4g7R5KoGAnUKTEoV7+ykGNItJXsy9ix Y82PJwgiUTcowkKPiCMc+RKT4LLVmWgrp+vKAU4e7d5YnWnTGjaDcd1gXDdsGMUoRp05WuUD 4EatVD2YmTlrGbIYgUm7wuZUHipU9YigmPvJnkLXpEgOBXvVVsK3HjSHqCoRL6Jr7AUa+3gS IaNLaRA+OgBQN05H0AQ89CpoZQInj2ZbpGbbVWbbanglxa2RhiLYkeqtGMUoRp04WuUDMIva pHoCl9HoHTd4JXejzO++wcwMfpixzUPQ3NLtLRqCVmzVI3fN7ht4ZFuOKNDRkgoxMTFUy0hO TmX2yo5KEl1/lZhWf+YDYNPFALHJmNniRQZApI3uGj1uNERs9rVlskis5HudBDh5lGsuqJjt PBhkU5k88Eqq6Q5dISFSpFEl83qetlUduqu7L7cU5WS2I0p7t9g2PLZEUUyjpD5P5q1x9Aio t0WoWMm1h648om257hFGMVodolU+AG7U+iucZHaFlQXvBEv0iGgBAerTmmCw72FBiH2Njt2K s5Bh394iqkFVj6gPjId9t5G9DCTLIgqMkI6HM9rdu3eza1Ito7BFja6tqPoQweK9OkohoxVY pXLWdxR6+48IN7m1R3/9IIpM16GVDJw8igV/y2Fb+LdioeHVUFQYPPIFpp0tzlIsYjykRKOk IW0rHOVktiNK8gu0VezN0iffoNHS8ZTNrDiQR4+A7qMLJEr3VL5IqG357hFGMer40SofgHnU etVjP80CkzNnAic6UsN0449M1HQOpwpFVoLmFwyhPszq5PYWlUtyGZCTk6N6dDBEwqgcEFXi 3BqjN784o4W1Hs1GPJx9J/WJ7jQ3UGKQQrJ2o3tn6dDB7sBIBLSJHluBo0qdZF/IISJdm8t0 5QAnj3Tab9JpJ6TTDRsYpqJsOhi/0Zqaff+An9hMdMbvqr+z9HJdiVyh/ee2bOYJdlpoy+kI 2upVel1EBLRVfF8IHu17fzP2OWmJSmbokZXw7zjZzN8gStqq78j06fdLe4cRLo7QirUl8kLF 4j/YY1b8J9F++q90+m9kd0rrs/YIoopYOfh1pyXwqr91hUTL7KnltsYDxXesMIrRJzRa5QPg Rm16jBNkiL0uY6/7yPxMZYUKFikSLaN5SBKy3CNLJ7r0I4s7Mo1zlj80J1v12LcaybMiJErS 0mUjZzx0rcfeO3YFDmTZSC6iUoEjSejuCEgP2SlLd/0EHg2Cfqnw0SgZDJFgEq2Sd5GUGFRP PPqYePTR4tFHiWF8HXWUOEk1nVJXIsmSjDEWISr7iTltNO/+Jd2bDIb2pzPi0aVRY8JRRyVb 7oFHfyMWPOoCjb4wCZzKTDXjTIwEpwqcBffBMEv4D02o3vq75I3jtFg86ywjecpi2bzjnDGr ctWKucc5g+fsERgaaA7ruCWRhnAGibL3VDzGYluBY4VRjD6Z0SofgFnUvnftwQxPL3gSp/lz JvRqJL0AyHmUkcgEvfxIIK3YssK+JcfuxXyZQ7WJpmVfjGVfHTXPXCKoevRRE7KEJF2Q7ugi VODqJXt1xjmSRJ3JmtRSc84VVDIG8gtGjSp6zwIBTp6iAYdhKzRtpuJXsBUN/IpUEx/Iglf1 np9JEUIaKSMc4mFfFw4+xrgk6dCWRknbwlePaCTaErVMMvIbiMqSFCV6XfFrR/RavT5TA/6i YcdL9CX6pHMQNSU8XDj4KCdh8dCvyahIUWvQLPWmn7hjHvSdXq0qfvUr6if1OXtUOOxX6LRE JSkc+DWjcfoSyXAYHv+ectuyDpT5scIoRp/gaJUPgB21Q/UIsOohwkfudpmrHvWwH3pkw5Yn DuRioEDOEj7VY3vMJYzdlvdZUAHVo++Jo0pXwlrBCTQsMS0zea9/EjWEwQg/BlNSVrLJrT3w kANb+e+apMDJk//8x/kvfMy8Pv9xnuHVWHyB2Ui1/Be/ZFRJlmMsPv+xXlc2kU4DbWmUtC3+ nKmvfusoyVz8E3NhU7WOWf0pFtyAV+XqxBJmWfdLHl/CfFPCPNN4jCGNQqvU6R9c44y54LUr +uzrdF/yOeMxjapgyl1w6h9eBI8UhBiGMe2r0spme8puSzPzHiuMYvRJjVb5ADhRK1WP901h 5jrCXj3R96YJP3FBpJM3xLlKWVL2Gqb5kNhXGtmKzBlPie2qR6PsdzeQ/TJ/xzoHS7feLD2+ UmK6sMm+bskZMH0HX41Kf8skGzh5cjvtz+m4P7cj88oYpiIY8EqqgZG//gFtBUWyNMvvciCX 1ZZZQxmi0DbvpZ+ZNV36bZIQtoKVaUwYVmoaRd6zB3VqfQlZta34Mqc04fuk39yO79Pe6ahI UTrr08LPmMdRZCMOscdcsDlD++NR2rZ08GX3qPD7fM5B0P5whLWn7xew97RsW5qZ91hhFKNP ZLTKB2AetVL16GKH/Vim+VqPrmg4F+XYNTkNOdJG8pAi73MvHNWjQ6Jp2bcLqdZwxmOH6tH7 a2yBo4tTgTeJk5GYX/9kP7fDgXOjkCzuarCukbIfT62S9ywQ4OTJbr43q/kesoFtKhqdpBpj t3hXVaQxFfcWfMWshpSrD+cM/AsMXWIkNIQlGNg5z74D9SWRUrAlgw/QzDl9rpPm+uT/wCNO VJCivM/+bCZhrinhKZIQeiEV6KjoYLI7/1CiK9ElXGKPuShWphhxwDT40vqcPZJmqJhOB70P du5ow7ov4wrti6nW4j26p5y2NDPvscIoRp/QaJUPgBu1/gonmfZBZWA2hlmXLJ3oUoWKAkzy 9K4fnbepQoFBanK0DOpDTjLbUy2gQsbOWcPsGU6QIbDp1UKSlr7JDnJCZs54BFQPKvOunqjQ sAXO/FETc8iB4n0PIPteJ4HkofoOg4cxkwzsfsmtPeE1ZiWQWW9HRr3tsGWG7MiEV1qst4Ns xmqGaM60W7RVZoO94i/uaYvUJWqV+r8bea13gjMnLEKn1OluR9CG7I4y2x4jtnrHx0zlNWmk WNiWaZvRYE/ZhLsyQnbQtmRUrOKO4huMqopf2kujKrE2r8VOEoW2mSHcMTBtG74FK1Aw8ltC ze1Zrb5jvFpVdkNjZdI2Z/otU7HM0aCZeY8VRjH6REarfADmUetVDzSI88Y6mIc5z3CytYlz 7Y69PGG/da6E9RAjUUb2lT322yVghmffVqNXOOk7GsiHVdK2IA3st/KxrzHyqh4dIe/FWHr/ ji1wtInAjTlSgeMUvtfJOSY1zNaSdPVXVe9ZIKQFbIIt3bClmTZDMZxsGMUoRjFa5QPgRG19 moX+cQHOhTWqI6QCrwpY+pMBBIE/HMDbin2/7JFprbwMSD6z5ZHPllQaNg2+8kn1XMu7pVHb C6MYxahzR6t8AGZRu5/h5FDRfw3BnKp9gzZSgn9ZDzfccKueW7lMgKh6TkiVn7q44YYbbnZs 5TIBkr+OWpnXBsmHm1XVX1NFSlD1cMMNt+q5VfXciVRXqvzUxQ033HCzY6vquROpruDJgyBI tQMnLsRu4OSJQhAEqVag6iF2gycPgiDVDpy4ELuBk0ev1xsLxIBXZisxFjCKUYxi1MGiqHqI 3RDVKws5yyyBUYxiFKNVHOVVvS8Q58M+1dMx6PXMC7H0xhLzqscoRjGKUUeL8qqeEnEy7BM+ g+pptcwX88pBq9NiFKMYxaijRXlVr6ofsUEqj+jo6OvXr9snfHDyaHnR8LsxilGMYrTKo3hf z9mAlb5Go5FKpdnZ2YmJideuXYuLi6MrPptSwckDqbSGzfBlejVB/jCEeVSS/RP9cxLfZ4qJ nxTn/f1QuC1FoF+MYhSjGLUUtah6lftojeM83uPIUfvycIqw0ler1RKJJCsrKyEhISYm5tat W/arHuSCL43pu9r4ZXCoiXKZR5N+f5Wq3oBf7hM3KfqGjJWrhdqSzML9YhSjGMWopSiv6rGe dqm0R2sc5fEeh4/ancdYhAW+SqUSi8WZmZn37t17TNVTqdTwD16Zb3BGqRjUpn9EucyjJwY1 Bn+bsLbw2qjvLyRKdXDiTwkCbY3/BPvFKEYxilFLUX7V01X6ozUO83iPg0ftyMMplrfqqZSl X0wSw6vK8F1lVC6z6IhgH/B/HPspvHrXGkKipHI7Xw9RrX4FcqWltiSzcL8YxShGMWopyqt6 zA0/yw/AVEy0cnqp7lF78nCKsNSHk6C4uDgjI+Pu3bvR0dE3b960W/WUSgX8I7C+k82oXJyo tCDG1cXFXdRMppC19PZwcXGJypcoTJWvvdsLXgd/eou3Lc0s3C9GMYpRjFqKWlS9inl4Rijq GI/3VI+o3Xk0Wlj0KxSKoqKi9PR0UL2oqKgbN26Qk8MO1VMo5AwKgskwlYlycaJpV6eCM6jl 2+DZ37YW2JOvpIJtrCzO6Bbg5en/HG9bmlm4X4xiFKMYtRTlVz0rHo9RFN1cOWlQk9qB7m7u fsENXhw642RCAYTi/zk8sVdL6x+tKa1vy0M4ZEpkmp/hNnfYB4fKJWpPnrJFWOPDz72wsDAt Le3OnTuRkZGPo3qGM0wuM2wGg3w3usmPiRM9O7dtjbK0nv0v+I0yJ5ff+KT0WRdLmYX7xShG MYpRS1Fe1bPm8Zjtz9WFSenT83elCvnN37cwN2hqD4aoUY+sfrTG9KienY/oGJs7xqNBlRC1 Iw+nCOomk8kKCgpSU1Pj4+OvXr36OKonE8SoXGVZ3sgfnFMiU8FOOjMCbP9Gy9iVpZKcPjVF vG0RBEEeE17Vs+bxGH83V5iUxr/5g1RZGmX/Ag/lggcnx7zcMVDk4ebhHdruxb2/JdE6q15q Xqft4rL11RlXPxvYpaWvl7und81Ovcb9kVzEdKUoeGvekJAAkXdg/aHz9uTLmVHUMIPpX1EI NevRmgqVQz04VA5Ru/JwirDIl0qlRPVu37595cqV2NhYu1UPUsmYTWYw4ISSGmC+w5f5j0lS lOZnOHNOZxVAvfy042C7uvmlFxkrk7bxP4w1qp6FzML9YhSjGMWopSi/6lnxeMzCZoFkXgru OPiz03do1KhBhrazQwNWHI0Sy+Wp14+BU1Szl8r0XN/c3++kJhYolez6qt6G3/D/Ts5LvvQO GAFNZoP/3KouYI/6Ivr6d5PAeHbVBXYvxCAjNNb8MjrWWPO8wPgd7bEi66L25OEUYYEvkUjy 8/NTUlLi4uJA9chns9itelJIJyGnlsGEAvwDj0SKUYxiFKOOFhX4HE7hx2PyH5zo+1QA/R3+ 6SHzIrKKIUqKtO2dMz9sXDrrxU6NwOni6qU0Pap3u0hG0ppki7Gf8nYHu06n/ts/PJoilpO+ Xwz0AmdsoUQuTmKkM6g/uxd2c2PNAqlc/MBYs3IfDaroqL15yhThtx+xWJyXl/fw4cNbt25d vnz52rVrJGyH6knMEJsZGMUoRjHqOFFe1bPy8RiZNOfbvcvb1/Ym0lOz9RK56ZkE0vbcrtEu Li4thoUd+df4ILrc9FxfkdyY2VSfsa99vKiBjzvxePo3XfVZDHi9XV3Yl8hc3LzZvRgNQzae mo704FD5RO3MU1qEH3pRUVFOTs6DBw9u3LgRERHxOKonFkvEBDipDLaEmGIJ9WAUoxjFqONE eVXPpsdjpOK0z3fNNtyd8YWimwsjPSTawMsN7MQiibQo0XibxiRYNDOtT5AWp/7x/aHFk3uD 010UCp7n/D3BvgdrPdYYjBpatjmt6ZgPDpVL1I48nCL80AsLC7Ozs5OSkmJjYy9evBgTE/MY qocgCFKd4Fc9K5jQwA8kZvXRywVicdw/+2owN/jWgb+ZiFmsJaUVgP2cHyNDb19J/mffMKPY mT3Xx64/uxlzyfTdi/ez7pyowXxqx2Bw/vlGe7CHHzyfErWfWVG2WsxOwm7OWxPhUFxcXFBQ kJWVdf/+fVC9CxcuREdHo+ohCOIk8KueFY/H5Cb8MX3IC/WDfGG15Vuz/itjFl7OKoRAzKfL aok86rZfDvVvfrmscYDIv17TCUsWGXVKSgXLmJnWBzs/+fTk/l0CvT3cPH1bdxt8ODqd6Uuc uW324AaBPuDs1Pv1f1LzoCnNFvOZqTtIVlrTD2qeSc13qAeHHj9qXx5OsaioKD8/PzMzMzEx 8fr166B6UVFRqHoIgjgJvKpX+Y/WVE4vT0DUjjycYmFhYV5eXkZGRkJCwrVr186fP4+qhyCI 82BB9YQegKmIaOX08mRE7cjDLhYUFOTm5qanp5OPnj537tzjqF7V/klcBEEQW+FVPUYOK/fR Gsd5vMfxozbnKVssX9WzqT6CIEiVY1H1kCeU/Pz8nJyctLQ08gcX/vvvv8jISFQ9BEGcBFQ9 ZyMvLy87Ozs1NfXOnTuwyjt79iyqHoIgzgOqnrORm5ublZWVkpISHx8PeoeqhyCIU4Gq52yA 5KWnpycnJ9++fRtVD0EQZ4N34qrqR2yQiiImJibaBBQvXLhw2QCRPFQ9BEGeeAQ+fRpxHuyQ PEsnD4IgiCPDO3F9gTgf5XXyIAiCODI4cSF2U2knj14rqZyOkCcePJcQVD3Ebqw5edh/+8lD 5N/uhVEn06S2djSgdU27BohUNvKsM1MHPBfo4+EbVH/IjG2ZKl25dwEn0uM0FziXegZ4RUnU xM6+Oh06mn41mxTVkiivwJ4CQyr9A2euXsYMlw6+1K6Rh5tH404Df34gJs6iez++1rWlr6fo qW7DT6ZK5blHvQJ6qPTsZLp+QaIPUy1Ks1aR+GKgF29Imvpjj1Yhnu6iZs/0PRSVK+AUbqIs vDS6W3MvUWDPCevzNaafoF71ztyBtXw86zXruu9spqXhVQtQ9RC7sVL1qK0ozjzy5rDAZots 7egxJzqk0ghrFjDz4F9FCq28MO3zdX1bvH683Lt4zJNBoPl3Xeu9EZ9P7F9fDe20pHPooF9I MT/+jXpdv3tk8gc/vdF93RliDwgS7fs7TqGSnn5vZECThcQ5McR39dErcpXs/P9ND2y+GDyb WgUtv5FHMxTEbwgIXWgpvyIn6vXOwZZ24fjA0LHv/VGklJ/a9XJIt58EnMJNPng+JOyXWLVW fe/Mhs6rLhPn3U8Hddl5SqxS3/lruyio3yMPhSODqofYja2qB+g0ua5uvsTWyOMXDHo2wMu7 3SvTb8s05vWJTX+LLjH8oju3fydvD1H7PrPvK7S02r9vDg5uMZ7YP+wM69goEHoJ/zWJVMi/ /uWAZ5t7e7gHhrRacugGbXVx/4Jmwb4+tZpu+DM14589bev5sVtZ6suOA+U8BLi7ZqtLVwci 7+bEZP7w5bH19Xx9WvaccENqXE/xHmFeJ5wq03q39fWts/SzK/RHwJvT0klFzhD2uWTOnf/r 2eXN64aRazr7+17NjvT166gxLMRidz7X8//uCO+7VpHQoV6vfI2e49dri1zd/Hic7kFgpP09 qUGvr6j/+36NRvySbKmLxn4hiz84Z2n8o2v7xBl2WVl01qfuBAGncJP6nm7kh6jXFPrUGUuc 60MDDmTYfJXGMUHVQ+zGVtXTqhXnPxlXs8UyUjw2vOnr30bCr5SR30xsOvyYeX32/EaME+Of OpWQo1WLL373Zuspf9Ho1CPXirPExH5h3eF8mfb+L+FUXsfV9Qn/I06j01w7tsjd+ynaqsvi /8uWqhP/We/XYM7Mrd/mSjXsVrx9IcLs791g8PotBz79/mp8OtsPR7v91AO5ckXk1+ObjTAu AHmPMK/zlzHNpx2JUSrzP53XgX1WmOe0dFKxzxBLgxen7q7T6UuDsTeo1Q4wtrcM2vmQaXX4 6Tp7UsXC+35xeafBXyeY+1XF531DprE9Wnn+j3tGNHjlnRJG/sSdAuskGPRdq3xQz79lrsbi ZeEb2QqBXQC1kuv0hpzFbp71BJzCTYI93MRavWE8D6mzhbf7sZ3T6weImnYeeiZLLnwoHBxU PcRubL2v5+rh/9zA6WdN/2U6+3kmKJjfMzWKBA/fDrQ+uy3H6OLvSf6TwjrCK6AnjT5Qlq7F SM4SvslBr5O5uLjQ6HWyQNApwE5RcldzvH0hwsBSa9m8ab26tPJydQlu9fIPd4qIH47qP4VK Q4V7nv7PESfvEeZ1dvP3TDLogqr4AvusMM9p6aR6YPbzNQdm/rrBr4ARuarToKPMkj/p6MAO S66A0b923WItdxHHRqfOblWzWek6l0XM3p7LT6fRolaVVqd+bTc30fqfjFcVLi5u3/8bRi4T vxvYZs6/Ar0I74Knq4upe52Lq6eAU7jJzo61w/9NUEgSt0zs6OLiQZzwA31lw5EilSrhv621 O+185CAdGVQ9xG5sWOvptTHHt4U06k8lqcTw/8h4H1+vdHHzLlPf4DVXPWhi/tgAr1CybbUk ft+WVZNGD+ncoi47p06wFW9fiJWoi9N+3DfDt/4UUoRjqDb9rOlqmvcI8zp93FxNp4qa/RPk zSl4Uj3iGvXqxgFxMs30+sHkup9GFhdUe6hafi+g8Wrh/c2MmNyw91Fzvzj5SK+wY+b+xBMr vQJeILYi/2TNxsy9vIWNA3/Me/QyytIu1PM0rtEMC7f6Ak7hJvKsM0OfbibyC5m5+4Sru/Hh H1gAZhieTYLFqZtH8CMH6cig6iF2Y+sVzlsfj240YC8tdvT1SDP8P9LI73r6PcupD6sGc9Xr 4Osh1XF/5X6k6s1rETjx7R9+/+3P2Lv3zHNasnn7QoQJFbmnqYyrKphIXd0DiA1HNcawstbI 73gFvkScvEeY1/l8gFe8nJEhtSSG/RM0zyl8UpU8SvUuzGo9/J0Fwe3fop632geP2zmszeyL wjt+on/jIX+ncpyKnCuTR60p4lsk6nVS9s2+nR2CP7v9Za22W4V7IVjahTF1fC4Wq0oM11R9 ao8WcAo3ochzj3j6dyP2uDo+5OapXlPoLmpmzTgdFnyXOkJQKpXlcvJwKPs/VL/hubpLzhjv +BwZHLqMud3G3IJpMsz4e7Kvm2v4r0laRf7Xq1+kbf3cXBOkzLPcx4Y1OXkvR6dXR367ICA0 zLwLXjvE0+1YXLZKnH5wUQ/rVY+3L0SYHye0GLP7u6RcsVZR+OveEXWe2Ub8zF3U5d8Wq1VX Do9rPdN4t473CPM6/5zacvTnl5Wqom+WdWH/BM1z8p5U7J8vPZd4yb46ESoPP/GQepJ/Gwae iaa3MFgCROFwtqxMqogPe3Sfz7nmOaiW6OO4bH2J7v6FnbXah1N/5oVZge0CZ/yXIdyL+e6w OTGgcf+3T0mUkt9392488LiAU7hJvyDRrrP31YrC05+MCnnhIHFeXt7plQNXtHptwr8bG/ax 50MtHAf8RDJEWZGfSMb5H6rIOx1at2+uYSpQS2Mnv9zGy8OnQ/9Z9HG7+7+Eg/B5BTaa9/5l 2nZH3xYeImbVoJHFzejTQeTu3rBd76OJxeZd8Nq3vtnavUXtoEat5+45Zb3qPbIvxBydOnPL 1P4hASJ3UUDXIXOjDOuIEsNx++vdmTW9/Z4dtojeQuU9wrxOrfLB3P4d/AObL/uozH0985y8 JxX7p0bPJV5UxRdhCZZoena0xPBkJgjlRdOOWCLI3TW97JsTewZ6sW9qE2du1Gd924eKPESt e447l6eglfU6+fP1n5dZd22BcxLSYlHC/o6hwa6uHiEtux9LkQg4hZuk/72nY8NAD9/gl8ct uS42PhyrU2evGNHNx9PrqR5jrj7qaDg4+OnTTk50dPT169ftEz68PI5YSUX8toC/gSD2gROX s6HX6zUajVQqzc7OTkxMvHbtWlxcHF3x2ZQKTx7EShxN9WrwUUGtKm14iJVYnLj0euMrs5UY C3p9BUUrp5fqHrUvD6eo0+nUarVEIsnKykpISIiJibl16xaqHoIgTgLvxKUvhUyWlijHaOX0 8gRE7c5jLGq1WpVKJRaLMzMz7927h6qHIIhTwa96sB5gvnQwScKX0SAuY7m8o5XTS/WP2pGH U0TVQxDEmeGduGBi1Oq4aOGfTmv4qoho5fRS3aP25OEUNRoNCFxxcXFGRsbdu3ejo6Nv3ryJ qocgiJNgUfXYaLiOColWTi9PRtTuPBqtWq1WKBRFRUXp6emgelFRUTdu3EDVQxDESeBXPVgP MF+mVxZa4jP4JTk/0eeLvssUc6LCbeGVNORWMtWM/+fwxF4trcnDhrSyfgzVLmpPnrJFlUol l8sLCwvT0tLu3LkTGRmJqocgiPPAO3GpNRpYEWgMG/kyOExFUzTp5KtU9Qb8fJ8TFW7LiZrX NGqijXlIK/vGUC2iduThFEHdZDJZQUFBampqfHz81atXH0f1qvrthgiCILbBq3oqlVqtgn/w yqCm/8iLKXpiYGOQmDZhbeG1Ud9fSDTjyucDu7T09XL39K7Zqde4P5KLwJl55fMBbOfDIkhD FIonmlzEfpcK1FQqCt6aN6RegMg7sP7QeXvyFUroi0T//ebtwc+F1mrcbv2Re2VbPXr81S9q Vx5OUaFQSKVSonq3b9++cuVKbGwsrvUQBHES+FUPVIX5YmZCw6vK8F1FvDQ6ItgH9OXj65/C q3etIcTbu6YIin8n5yZHvA1GQJM50NbkzHsY8Y7BORuSEnkqjT7ISzZG5yipJhrGcG4V8+F7 o76Ijv1uEhjPrroAPZEKnZb8mByxBwyvmi9Tp5Xjr4ZRe/JwinK5XCKR5Ofnp6SkxMXFgeqR z2ZB1UMQxBkQ+BxOhZJ+V5hKCuqVFFxzdXFxFzWTKWQtvT1cXFyi8sUQfcrbHXSnTqf+2z86 miKWkbZlnXKSw6R67OgRiJJeSJTUfNHwiXaxhRK5+AEYopr9afPYQqlCngeGi4sHK+ejx18d o/bmKVOUyWRisTgvL+/hw4e3bt26fPnytWvXSBhVD0GQJx7eiUuuIMiNhqnMeORGZ9rVqaAv QS3fhuj+trXAnnwlBYIxHy9q4ONO1MfTv+mqT2Og8jWO87NoSGLUNd6oXG6KMt15s/7kFiNw bt60ucwwGJqKGNaMv7pG7cxTWoSFXlFRUU5OzoMHD27cuBEREYGqhyCI88A7ccnkcplhBpUZ v8uNJdM32M7ObVujLG1m/0uikuK0P74/tHjyK+B0F4WSRlKjszdxQmajQvFFweXm4kKiUPM5 f0+w78FajzUGo+oZPKZUMtLKmvFX06gdeThFWOgVFhZmZ2cnJSXFxsZevHgxJiYGVQ9BECeB X/WsYHkjf9CXKZGpYCedGQG2f6NlYM9uFgD2uxfvZ905YbjfN9iS0yhbFqLNRMzqLymtAOw/ 32gP9vCD51Oi9oNRs9VidnO2zW6F8FJcXFxQUJCVlXX//n1QvQsXLkRHR6PqIQjiJPCrnlQm lcIXzJFSA8x3YssMfklRmp+bK+jL6cwCcOSnHQfb1c0vvUiSn3x6cv8ugd4ebp6+rbsNPhyd AU3yH5o5ZVKjVPFE08EZ8+myWiKPuu2XQ01Jcea22YMbBPpAhU69Xz+TmgdjMCkdMypqR5ta CY+/mkbty8MpFhUV5efnZ2ZmJiYmXr9+HVQvKioKVQ9BECeBd+KSSMgMKZUYkMI/8Eioq/yj ldPLExC1Iw+nWFhYmJeXl5GRkZCQcO3atfPnz6PqIQjiPFhQvVLEZkZFRCunlycjakcedrGg oCA3Nzc9PZ189PS5c+dQ9RAEcR54Jy4xAJOkWCI2fEnId5OnIqKV08uTEbU5T9liJatew059 Nuw7SYsn923o06khLaafHV+jRo3xZ9PZTbIvfz2xb+dafr6vzttxLUNmKTNvW0qNSv8rnJZ6 NB8nFMd9dc+attWO7EsHX2rXyMPNo3GngT8/EBOnNPXHHq1CPN1FzZ7peygq18pW9DE5V6bh gG/jCvl7tHy2aBWJLwZ6WRqqWnKV/TCela34K+hV78wdWMvHs16zrvvOZlrfl/A5jFQQFlUP eULJz8/PyclJS0sjf3Dhv//+i4yMrDjVg//UvWsFZah0YOtU6TVrdmf/r/+8e0jvna+EdP+8 9NxL/qqOf5v9P10qkKmyk67M79Z40rsxvJnN23L6tWVXygFLPZqPE2qOCG0fKVE/sm21Y0CQ aN/fcQqV9PR7IwOaLCTO4wNDx773R5FSfmrXyyHdfrKyFT0mGqX47CeTvWu/Zt5Q4GxR5ES9 3jlY4MDmx82u3eFTjvORrXgr3P10UJedp8Qq9Z2/touC+lnZV8mjzmGkgkDVczby8vKys7NT U1Pv3LkDq7yzZ89WtOodf7nBgtv5YOffXhDS/Xs6Y+jU2XW9g1PFyTW962WrdcT5aY+QkT8n 0+aK/N8GTNhonpa3rUYeP613W1/fOks/u0J7AePfNwcHtxhfYvgtfW7/Tt4eovZ9Zt9XaEmF pF/Dfd1cXd28Qjv1PngxW8DJ25y9p1aOE2rmxe4NHbjPvO0TI396bZGrmx+xR9f2iZNpwFAW nfWpO8HKVuxDAX53r1Dz+gJnS2O/kMUfnBM4njFbnnl22zWO85GteCusDw04kCG1uFcW+uI9 N5BKAFXP2cjNzc3KykpJSYmPjwe9qwTVe3C8X9s3IsCOmNe21zcJdMbIjJhau+MHYOxrHzz1 UhZxtvHxiGItgizB2/aXMc2nHYlRKvM/ndeBrSNTj1wrzmKum50Y/9SphBytWnzxuzdbT/mL VAB1G3Y4vkSnvHFis3etIQJO3ubsPbVynKTm0Wmtlp1OE2hbrVEVn/cNmUbs+p5ucp2+hBGv YjfPela2osdEr5Gf+3z2iB0XzesLnC03shUlggf2k/bBTUf2qevv06rbmPO5Citb8VZo4e1+ bOf0+gGipp2HnsmSW9kX77mBVAKoes4GSF56enpycvLt27crR/XkOd/71Z8L9rz6fp9kSumM 8e3LDQb8lARG0rEBDV7+ljg9XV3IDCkMb9tu/p5JhiWYqvgCW/UeKI3rsi7+nsbkepVXQE/i XN8zpOnIrT//dSlPWbp843XyNmfvqZXjJDW1ygc9G7yYbMj/5KlezN6ey02aDj9T00pG5+Lq aWUr9o0wFxfXMXt5LnQ/8mwROLBd/T13RaXpdNqMW0dqd95lZSveCl6uLq9sOFKkUiX8t7V2 p51W9sV7biCVAO/EVaV/BQKpQGJiYqJNQPHChQuXDVSo6sFc19ZXdCv/tsi7iVpvnDH0msKG Xm50WnPzalioYaavZ/w8L4tVrAS6h4WqEtYcKNDWx81VRaZAvZr3mqEX66PtXFyNDyRoZDeH v9TZz93VzSvky9uFAk7e5mX3tAyWxklrpp1e2mr6Md621Rpx8pFeYcdosZ6nm1hL13r1S8r+ NC21Kl3raZV3zh/w9O9m3tDS2WKexFKnhg40ru5BNrXiFIM93Mida71W7OYRbE1fls4NpBJA 1UOiKvIZTvIf/7POdYYeHl6rzfvUkxM9t1ab7bTatja15kbngHG4Z/3hR5Kov/j+2/QCI8VS 2+cDvOLlzP0jtSSGV/U6+HpILSwNdOrCC8fme/o/I+AUaF7Cp1yWxsmu+d6A0Ldj858k1VPk XJk8ak2RtvRAjanjc7GYESNV8Xmf2qOtbMU+JqAmru6B5q0eebZYdWD1Snfv5ja14lQYV8fn hpS50Apa5i5qZk1fls4NpBLgnbjeQp50tm3btnbt2sWLF8+ePfv111+vaNWLP/SCR4BH1z03 qOfH/o2n/Fv6wHbaP6837v8jGEWJH/n7tT54MlqiUj64fnJE04ARn9zh5LTU9s+pLUd/flmp KvpmWRde1Ts2rMnJezk6vTry2wUBoWHE+Vqw96bfriu1+qRfw13dfAWcvM05e2rNONk11ZKr 7ZuMfGJULzviwx7d53OezTgxoHH/t09JlJLfd/duPPC4la1K13oa6b8fT67Vbot5w0eeLQIH tn+Q6Jt7eXq9NvXaF01fO2JlK94Kl5d3euXAFa1em/DvxoZ9eP4Tmfdl6dxAKgHeiWtvKW+V Md7aWxZnjTraeGyPbt26bc2aNYsWLZo1a/bEiRMrWvUkae+CsTm5mHj0WkmrWp3ErF/s4Zfk tkGtJAbPvZ/3vtQ+1MvNLbB+63m7uJOkQFut8sHc/h38A5sv++gCr+ppZHEz+nQQubs3bNf7 aGIxceZcOdizdX13VxdQt/Bf7gs4eZuz95SDpXFy5sx7X4zlHW11pKfhj4Jxru8VJezvGBrs 6uoR0rL7sRSJla1o0d3Lr8NLY05ZeOem8NkicDxzLh18oVU9d3fvTgPmJpR9ItdW1dOps1eM 6Obj6fVUjzFXi1Xm9Tl9CZ//SEXDO3HtIcDkCC97LIBRxxyPddGtW7asWb164cKFM2fOnDBh An42C4IgTgLvxLXbwK7dQmC0qnosl+jmzZtXrVq1YMGCGTNmjB8/HlUPQRAngXfi2kXYafja udPwHV7Jv10Ydbzx2BwND9+0csWK+WFh06dNGztuLKoegiBOAu/E9b//7fwfwfS9bMnZo442 HjuiGzdtXL58+bx586ZOnTpmzBhUPQRBnATeietNhh07dry5g/nOmMw3o2OH9dHt4UtffrpV TR+Rq6urp49/0zZdpq8Mt9SW3LkWzkzqgLV81vjOzWqT6LLZ4wx2mVHNH/VKwyBfNzfP2k36 vmlITqKM8dhjNh+PQE7jfu3YsdwwThJdPpsZ/+MfYbuj6zdsWLZ02Rtz506ZMnn0qFGoegiC OAm8E9d2E9u2C/HIaL+GvjDhj5q7fMvWLYun9QXbw6e1pbZEHazMzK7MtmlbT8Mbipdt2rwp fGtFj9nKo8Q75sc8wnZH165bt2TJkjlz5kyaNGnkyJGoegiCOAm8E9fWbdu2bt1q+jJ9I85t W62Pks+y6Nh/QvjWMtGtm9cP6t4mwNvT1c2zbtMO01dvAh8RgnmTR7RrGCDyr9tvygqoTZwv NqnlW+d5aGv+cDgb2i/HyY6abG5m28e8kY5n3pQRbemYTc4XmzKZaY8Wx/x4R9ju6Jq1pW9b eG3ECFQ9BEGcBN6Ja/PmzVuYfwybyZfBwzgNWBntHiQic7tPvVYjpy+h0RnP1wdnu1FvrA4b AYaoZldwkprNu/dfsWA4GO7eraiz65QlK5euh7akCJmNhiEbsTmjMlXYQiuQKLU5mW0ds1fN rnQ8dMwe3i1p5ueYzBvMeyRHyTjmxz7CdkdXr169YOHCmTNmThg/fviw4ah6CII4CbwTV7iJ TczXJub7JrbL2ui6pZOa1yp9/2lIq65zVm+AUGPDB9AtXLeR3ZbUWb4ByhsYy8UdosS5aL2x GiluMhlsJ2dUbCefzc1s25hNe0rqLIMxb1pvGnN4aWa+Hklbaj/mEbY7umLlyrD586dPnzZu 7LihQ4ei6iEI4iTwTlwbCZtMr5uMZhmsjG5cPWbA83V83Mk8LwruAS53w4f4rt1Ypi2pQFoZ bZOxzqyOUf44DVn9sp2szBssZbZpzBSeMW8sm9lsX8o0LJcjbFeUeYBz/ryp06aOHTNm8ODB qHoIgjgJvBPXemDDhvWEDWAysFw2R9etXT6i77PMYsjFA1zkw8bnrl7LbkuEgLQlNoSMhimx sc769S6mCtDWxeRk92uqybjcDDVWr9+wdtVcS5ltG7PZeNg91ig7HtqjC6vH0jGX0xG2Nbp0 6dK5b8ydMmXK6NGjBw16FVUPQRAngXfiWrdu7dp1lLWGzeRbu876aAd/T5jbXxgza/WaNfOn DALbu25PiE7uWhfsVkNnLJ3zKhhegU9DZaIOpK1xubRurckwZqbFmu6uYCxeuhp6M9mr2KMy 1jSMpYWIWbUNmL1kzHN1LGW2a8ysJKweaRecfWGNmTX+xzvCdkcND3DOnjTp9ZEjRw4cMABV D0EQJ4F34lqzds2atWtNG1NiWLvG5Lc2unzhxM4tGvmJPGFp4yHya9K268zlq5jQmmWvPP2U r6ebq5tnndC24xcsh1ZEHUhDowKuoU5jZlpn9rDu3u6uvnV6gJNll46K1XDN/DEvBnl7eNcM HTZtnqXMto95RdkxlyYsm7l0X9jjLDtm+4+w3dFFixfPmj3r9YkTX3vttf4D+qPqIQjiJPBO XKuRJx36udPDhw/v168fqh6CIE4C78S1cuUqgsEwFky+VRh1wPHYGg0LWzBjxvTx48cPGzas T9++qHoIgjgJvBPXipUrYaOwbShh1CHHY1s0LCxs+vTpY8cxb1vo06cPqh6CIE4Cv+ohTzrz 58+fNm3a2LFjhwwZ0rt3b1Q9BEGcBFQ95wRVD0EQ5wRVzzlB1UMQxDlB1XNOUPUQBHFOeCeu KMTJIJKHqocgyBMP78SlRJwMOyTP0smDIAjiyPBOXF8gzkd5nTwIgiCODE5ciN3gyYMgSLUD Jy7EbvDkQRCk2oETF2I3ePIgCFLtwIkLsRs8eRAEqXbgxIXYDZ48CIJUO3DiQuwGTp6qfqMh giCIbaDqIXaDJw+CINUOnLgQu4GTR6/XGwvEgFdmKzEWMIpRjGLUwaL4LnWEoFQqzc8EYYjq lYWcZZbAKEYxitEqjuInkiHKx/hEMh2DXs+8EEtvLDGveoxiFKMYdbQofvq0kxMdHX39+nX7 hM+gelot88W8ctDqtBjFKEYx6mhRvK/nbMDvPBqNRiqVZmdnJyYmXrt2LS4ujq74bEoFJ4+W Fw2/G6MYxShGqzxqUfUq9yaj49zodOSofXk4RfidR61WSySSrKyshISEmJiYW7du2a16IKBa w2b4Mr2aqGFAazIAVzd3n4Dg7q/NjxcrBNoqxPHNvN1JW97Mwv1iFKMYxailKK/qse77VdpN Rke50enwUbvzGIvwq45KpRKLxZmZmffu3Xtc1QMFhS+N6bva+GVwqInSqU2qBz6lvOi3//UB u/5LBwTanlrYnrblzSzcL0YxilGMWoryq56u0m8yOsyNTgeP2pGHUyxf1VOp1PAPXplvcEap GNSmf0S5VCaDRBXiRLr0q/P0btp299N1wLMyMkOce7pecC/aljezcL8YxShGMWopyqt6zKVP y7cCKyZaOb1U96g9eThF+KUHBK64uDgjI+Pu3bvR0dE3b958DNVTKUu/mCSGV5Xhu8qoXCaD RGXF98B292o0rq6vi4vb0YxicBZn/ODm4uJTZ5RcqfpsaOjEowm0LW9m4X4xilGMYtRS1KLq VcxtRKGoY9zorB5Ru/NotPDrj0KhKCoqSk9PB9WLioq6ceOG3aqnVCrgH4H1nWxKKnbUkIlz ft7GrOMaD/r8znfDwGg56QT4f5vUAuxBX8XlJX5Ss/FkqaK0CW9m4X4xilGMYtRSlF/1rLhR aLxTY0CWf+WFWiIPnzZ/pBZbf5Mx4tP1zzat6+Hp2/KFLexsj3+zkkbjzxye2Ksl8dMnKxzz BquVUXvylC3CbztyubywsDAtLe3OnTuRkZGPo3oKhZxBQTAZpjI55nKTAcDizjewbr8pq24X SuWSzPa+Hm6eIfHZ8SGebh7eLdPEsvBnaq+LSGW35c0s3C9GMYpRjFqK8qqeNTcKTQ8bqJXS 5AktAl09an0UmWnTTUY/N1fIcLdQUlCkqKBbmcZBOsYt1HKJ2pGHUwR1k8lkBQUFqamp8fHx V69efRzVM5xhcplhMxjku9FNjj+4TEaZKHxFrH8a/O2ntWVel5yRm2qy4c0s3C9GMYpRjFqK 8qqeNTcKjbddFEVretUHY/mRe8aoovj9RaMb1PLxDmwwYvF+qZJxkspnvn178HOhtRq3W38k gT2tlWZTq+SF117v2TKgbqd1+4+YoioaVZs9ILHqpeZ12i4Gf0HyyTEvdwwUecCaIbTdi3t/ e8Dugo7B+hE61O1XY9SuPJwi/LojlUqJ6t2+ffvKlSuxsbF2q55MEKNssQwORTmXA92ZX35c 3Lz/ySrkbYsgCFKO8KueFTcKyaT00TTjE+ZvxueQyKXw56E45OPLlz8eDMYL4ZeVpocZOi35 KfniXjC8ar6kLL3XwzSj9vdDQsEY+WX0+6Obm5w8Nakx9/c7qYkFEJoVGrDiaJREIU+JPQZ+ Uc2X6SDJ+I22LSN0nNuvfF/W5uEU4VcdiUSSn5+fkpISFxcHqkc+m8U+1QMBlTGbzGDACSU1 wHyHL6NySamElYmStt8Pbwqhhq98Yqktb2bhfjGKUYxi1FJU4HM4hW8UkknJxVU0aGInZtbq +yWJvhjoBcXIAqkkP8qgPr3ATyrHFkgV8nymlYsHS8sUbLuTnyepKc45a6Z67JpG43aRjI7w zpkfNi6d9WKnRoaBeSnKNDSOwaYROs7tVyX125OnTBHOA7FYnJeX9/Dhw1u3bl2+fPnatWuP o3pSEFEJObUMJhTgH3gkUoxiFKMYdbQor+pZc6OQyMQ3Eamy4rRm3u6u7gGR+WIIerq6gL+Q ua5aUIP5LA4fWllmaEtsaihY2cDwMjQvkMplhuZmNWUcZ5HcOMJzu0a7uLi0GDb/yJmbpvrG m0Rk/MaGtozQcW6/yu2oWSZaWoRzoKioKCcn58GDBzdu3IiIiHgc1ZOYITYzMIpRjGLUcaK8 qmfNjUIqIsCfM1qD3X1XFNgvBBhWUnniotwrhpVUXzmrsoz1YAMrQ6lN1nrReeLC7H9pTSKF +VKZOC+GyhONkjE08HKDYmKRRFp0n2Zzc3Ghg6RO60dYvrdQyyVqRx5OERZ6hYWF2dnZSUlJ sbGxFy9ejImJsVv1xGKJmAAnlcGWEFMsoR6MYhSjGHWcKL/qWYFRGgzkpX7n6uIiqtm7WCo7 vaAj+AcfunTp4KtgvLT9MqcytXmdP7zWFIwRn0d+NKlVDeZKows4BwV5g/1u5MMjYe14mwPP GeTy7SvJ/+wbRkPNRMxnOSalFbDrWz/CJ5Li4uKCgoKsrKz79++D6l24cCE6OvoxVA9BEKQ6 wa96VtwoJNJAo5vbBEFx4cVkaXHWm3OGN6jpI/KvP2Lx+4USJmrUEUNbk6awnCy7ODdyXPdm fnXar3j7B/C4edaB6J0j658K9g1u9uJn/90y1eQ+IHHzy2WNA0T+9ZpOWLKI1on5bFktkUfd 9svZY7B+hJb2vapuztqXh1MsKirKz8/PzMxMTEy8fv06qF5UVBSqHoIgTgKv6lX+TUZqw+ps 7Ls/p+QUpt48DtIT2GxVpY2hWkTtyMMpFhYW5uXlZWRkJCQkXLt27fz586h6CII4DxZUT+hW YEVEqX3zuy3dWjcWebi5e/m26THsSFxWpY2hukTtyMMuFhQU5Obmpqenk4+ePnfuHKoegiDO A6/qMYHKvcnoODc6HT9qc56yxfJVvSr9O/AIgiA2Y1H1kCeU/Pz8nJyctLS0u4Y/uPDff/9F RkbarXo21UcQBKlyUPWcjby8vOzs7NTU1Dt37sCvPWfPnkXVQxDEeUDVczZyc3OzsrJSUlLi 4+NB71D1EARxKlD1nA2QvPT09OTk5Nu3b6PqIQjibPBOXFV9sxGpKGJiYqJNQPHChQuXDaDq Ic6LXl9UWJiWkpKcdP9xtrTUlMKCAr1eXz26dmJQ9ZCox3iGs5xOQwSpIvT6rIz0iIvn3317 z+oVS1csXWTfBm0hw+WLF+UyWTXo2rnhnbjeQp50tm3btnbt2sWLF8+ePfv1119H1UOcE1hq RVw4v31LeNTVKxkZGdnZ2VmZmbxbRno675aWmgrbw+TkiAsXtm8Nv3kjVqfTOXjXTg7vxLW3 lLfKGG/tLYuzRh1tPLZHt27dtmbNmkWLFs2aNXvixImoeohzkpbyEBZKkVeuiMVijQmdFfBe ToyPv/3JoY+0Wo2Dd+3k8E5cewgwOcLLHgtg1DHHY11065Yta1avXrhw4cyZMydMmICqV5no tZKqHgJiJDnp/uoVS1MePiyXm2IZGekH9r8L4uXgXTs5vBPXbgO7dguB0arqsVyimzdvXrVq 1YIFC2bMmDF+/PiKU70aNWpQg+Dm7tXs6f7f3C4UaFUQ9yZtaE762fEQHX82XbjHyiTp13Bf N1fo2tW95p4zGcKVB7SuWTmjqhK0isQXA73YHmXhpdHdmnuJAntOWJ+vMV6Cy7508KV2jTzc PBp3GvjzA7F9mUv0qnfmDqzl41mvWdd9ZzOJT5L866vPNPV092reZdgfaVLhnCA9K5YuSktN tXLvhDFJj9qayrxd63V23puzqWsnh3fi2kXYafjaudPwHV7Jv10Ydbzx2BwND9+0csWK+WFh 06dNGztubOWoHjH0WuWlr2b5NZwl0GpD+1oC4vV595DeO18J6f65cI+VBkien4df+C/3wb5z ZLWPV533I7IF6leJLlcOipyo1zsHc3bwg+dDwn6JVWvV985s6LzqMnEOCBLt+ztOoZKefm9k QJOF9mW+++mgLjtPiVXqO39tFwX1I84FTQLev/pQo9MkX3kvsPky4bQgPRvWrnqYnEyK93/d EtqwYYMGDRo1brH3r4dW7jUFpOf9fe9Yr3rsrvNjLn/21oburZvY2qkdXTs5vBPX//63838E 0/eyJWePOtp47Ihu3LRx+fLl8+bNmzp16pgxYypT9UoY4StydfMDY1iw9x8FCjCUBX941x5J orDQq9V+gyVp0Kmz63oHp4qTa3rXy1YbFw4aefy03m19fess/ewKu8d/3xwc3GJ8iWGZMLd/ J28PUfs+s+8rtKQCWaC5unmFdup98GK2gJO3OQXqE8kj3DmyduHWI8TOv/7lgGebe3u4B4a0 WnLoRglrzcubdmiw958FSjCkmR9DnT2pzCJIkX/Su9YQ3myjavucMtRX5P/mU2dMSVVLamO/ kMUfnOOMob6nG/lJ6TWFPnXGcprQk8GOzOtDAw5kcFdz/m6ucsN5odfJXd0DhNMapGf1/cRE UnzmqVb7zjNrxuRTe0H4HjkqDvl5eW/t3mmL6pV2TQDBtbVTO7p2cngnrjcZduzY8eYO5jtj Mt+Mjh3WR7eHL3356VY1fUSurq6ePv5N23SZvjIcouR/vaW2wlGBfklDa8Zs6mLHstnjOjer bev+2nocHDC6fsOGZUuXvTF37pQpk0ePGlWZqqdVic98MjWgySKwz89o3fcIoxdJP/Vvt/AS qQALvR1xBZZm78yIqbU7fgDGvvbBUy9lEecvY5pPOxKjVOZ/Oq8Du8epR64VZzHCcWL8U6cS crRq8cXv3mw95S9SAdRq2OH4Ep3yxonNRFYsOXmbm++jOePq+oT/EQfrjmvHFrl7P8Wpb572 7OSWA44/ACP+0AuiOqKuuxlpS/y2d4sJZ3izXV7cvteX98BIONyrzZwLFn8MlcWNbOZ3GM4B CfZwE2uZW1da5UM3z3qcJqri874h0+zL3MLb/djO6fUDRE07Dz2TJSfOVW1rfRCdotPr0mIO BrV5xCnKKz0MOkW7PksfOSoOhQUFVaV6NnXt5PBOXNtNbNsuxCOj/Rr6wlk6au7yLVu3LJ7W F2wPn9aPbEskyY5+SUObxszpy779fcyjVCXRtevWLVmyZM6cOZMmTRo5cmSl3tfz9G3TfehP 9xkxKri7qu6zn4HxVdd6byYXl5gWeiWWpeTblxsM+CkJjKRjAxq8/C1xdvP3TDKslVTFF9g9 PlAa12Vd/D3lOsMzA3qVV0BP4lzfM6TpyK0//3UpT1m6fON18jY338eSsks5NnqdzMXFhVPf PG1+3KKQbl+D8WH74IV/zq751C6wP+pYe25sLm82ccruWq33grG/XfCqu0K3SisTzu7v7Fg7 /N8EhSRxy8SOLi4enMoxe3suP51mX2YvV5dXNhwpUqkS/ttau9NO4iy6dzDA3XCP1c3v4/vF wgkfPkjatmWTueol/vXdPbnNT4aA9Ozd9T8rpYe368dRPeu7dnJ4J66t27Zt3brV9GX6Rpzb tlofhXMSzr2O/SeEby0TJdMCGFs2bxjUvU2At6erm2fdph2mr95Eo/Mmj2jbMEDkX7fflJWG XqBmaz8vdw+Rf+tuAzds3gK5SM0Xm9TyrfM8ZDY2nEIbrgDnli0bXjU1bAMNt2yhXbCxdX9t Og4OGF2ztvRtC6+NGFHJVzgpeq24cUAzuVbZJriz2jD9k4VeCZ9clhgukTX0cisVUK+GhRqm mY+bq4o8B6dX8/ZITkWCi6vxiQiN7Obwlzr7ubu6eYV8aXq6htfJ29x8H809akn8vi2rJo0e 0rlFXfOBmafVafLrBbRRa+Wh/o3FytxaouB8ZVF975qZKh1/Nr3m2cBaKdLsOj4NirWO8tEc nAMizzoz9OlmIr+QmbtPuLqXeZJHnHykV9gxuzPDKjLDcGTgRHLzCCbORc0CP4pKgRXxg8vv BrV6xCmakvxg+9bwxIQEtvPeX7/dFNsjHyA9kM1K6eHt+nFUz/qunRzeiWvz5s1bmH8Mm8mX wcM4DVgZ7R4kIv+jfeq1Gjl9CY0SJ9SZ+Xx9MNqPemN12AgwvGp2pdHm3fuvCBsOhod3K3DO erEB2O1GzV8wrjMY9V+cQ2t2nbJk5dL1kLm04QLSsCXUmV22YYMX50C/pGbpSGzeX9uOgwNG V69evWDhwpkzZk4YP374sOFVpXrAZ13qzj++PHTQr7QaG07lnOi5tdpsp8VtbWrNjc4B4/kA r3jDb+ZqSQxvjx18PaQ6flHQqQsvHJvv6f+MgFOgeQm5r/drEi0m/Rru6uZL7HktAie+/cPv v/0Ze/ee+cB408KqbcelDXU6fwz2m81rvvHnGzVb/E8g2x+vNR175PU6T39saXiVj6WftTz3 iKd/N1pU5FyZPGpNkS1izck8ro7PDSkzz8OvQ+6iZsQZ4OGtIQtoneyR9/WI9MTHxVFP1Jf7 /jVdLLUVqVRqq+qxuy55DNWzqWsnh3fiCjexifnaxHzfxHZZG123dFLzWl50Bgtp1XXO6g0Q IkVo29jwe/vC9ZvYbUl0+fqN4eHrDb8Eu4OziaFm2PqNmzYsA8Nd9BQ0IDUXrTcOgBSXbYCi YMNNxoalI7F1f208Dg4YXbFyZdj8+dOnTxs3dtzQoUOrUPWSfx0EoZmR3Iceeev/2L/xlH9L 37CQ9s/rjfv/CMafU1uO/vyyUlX0zbIuvD0eG9bk5L0cnV4d+e2CgNAw4nwt2HvTb9eVWj1b p3idvM0p938xPMNpED7285xAiKfbsbhslTj94KIedDx+bq4JUomltAmHewW0CejzPZMhdudz ojqiHvvjBLLlxoa5+7r3O5pU4jBwfnb9gkS7zt5XKwpPfzIq5IWDxJkd8WGP7vPp80j2Zb68 vNMrB65o9dqEfzc27GM8exc0b3wiMkGl06ZGf+QfOk84IUjPnp1vUulJ+XPrzwnGi6J2CJBC Id++xQbVY3dtd6d2dO3k8E5cGwmbTK+bjGYZrIxuXD1mwPN1fNyJvoiCe4CL2BB1N1zgWbuh TFMahc1obzTWLMXFnUbXcRputLZhmSa27K89x8HBoswDnPPnTZ02deyYMYMHD65C1VOJr7h7 BJnPfub19VpJq1qdxKylAfyG3zaolQRmPeWDuf07+Ac2X/bRBd4eNbK4GX06iNzdG7brfTTR OK3lXDnYs3V9d1cXUDeqU7xO3uZsQPiM79djtQJufbO1e4vaQY1az91zio5nR98WHqIAS2kV +b9Bzd8Nj7aKU3eD/X9ZMoFsWmUy2GeKlMLHuTLhjCH97z0dGwZ6+Aa/PG7JddOVw56BXuz/ l8IZLPl16uwVI7r5eHo91WPM1WIVcYof/Dzo6SYebh5Nnh5k/k5ATgaQnr27/0elp2No4wYs bNhnAyA9G9autiQ9wl03KEv5do2w4Z241gMbNqwnbACTgeWyObpu7fIRfZ9lNMfFA1zkPIco uUczd9U6dlsa3WCyIdrA07AqXLuenZlGCcaGhqjJ3mBsuGYde1Q06lLaxJY9svc4OE506dKl c9+YO2XKlNGjRw8a9Cp+Nkv1Jf3GVr8Gc6p6FNUVjvQ8JjZJTxV27eTwTlzr1q1du46y1rCZ fGvXWR/t4O8JmvLCmFmr16yZP4W5kOVdtydEjWu0dWsnd2VuyrcaOmPpnMFgeAU+zY7CZrLX TXq2DlNzyPSlc5g8ouBu7Cjpt7RI7bVrJ3UxNlxi3nDt2pqGZ70WL11l+/7acBwcMGp4gHP2 pEmvjxw5cuCAAah61Zea3oFrT/N/TA3ySEB69r3z1vVrMeWSTaPR2KR6VdW1k8M7ca1Zu2bN 2rWmjSkxrF1j8lsbXb5wYucWjfxEnrCk8hD5NWnbdebyVeAnosO0Xb30laef8vV0c3XzrBPa dvyC5WWia9ZQe82aZb2eaeEv8nAxPO05eemKMlFDv6Yi24aGS8s2XMmOzh7W3dvd1bdOD9v2 18bj4IDRRYsXz5o96/WJE1977bX+A/qj6iHOCUjP+/veLS/pAVYsXWS96lVV104O78S1GnnS oZ87PXz48H79+qHqIc5J+UqPVqtdvWJplaieTV07ObwT18qVqwgGw1gw+VZh1AHHY2s0LGzB jBnTx48fP2zYsD59+6LqIc5JWsrDgx++f+H8uXLJdvdO/Hvv7LX+Lw1VVddODu/EtWLlStgo bBtKGHXI8dgWDQsLmz59+thxzNsW+vTpg6qHOCeFBQWXLjJ/khVUA5ZL1C+Xycy3PD7SUlNS U5jt9u04yHPr5g0r/7RrFXbt5PCrHvKkM3/+/GnTpo0dO3bIkCG9e/dG1UOcE71eD5py62bs e++8tXrF0hVLF8G2cd3qjevX0G3H1s3/276Fbm/t3vnu23vodmD/uwc/PADboY8+gDzWr7aq sGsnB1XPOUHVQxAKLJFAMjQa9eNskMGOpVYVdu20oOo5J+WlelEIgiDVClQ95wTXegiCOCe8 E1dVSzFS2aDqIQjiJODEhQCoegiCOAm8E1fe/53H7cneUvafurPreEz4NxdWfvJX2D5UPQRB nARUPefcUPUQBHFO+FXvo//yPjyb+9FZ5vXD/2jR4PnPUlQg9ORFHXBINkUfvv37nW0/xqw7 fGHxwVNz3kHVQxDESeCduHLf+4d/e9eCXzj05EUdcEg2Rh+++Vv8xh+il39+ft4Hp6buRdVD EMRJ4J24cnb9mbvrVM6uU7m7/mTsnWAwNtkEonY3rI5RBxyS9dGH4T/Fr/w6Kuzj89P3/Tlu J6oegiBOAr/qhZ/I2QzbScOryQ432bxRgZBww+oYdcAh2RhNXnXk9oIvoqZ/eG78W38O2/5k qJ5eK6nqISAI4ujwTlzZq47nrDzOvBoMeM1eSbafwWkhyhMi2eQf/UGipcn50uZ9FKlMlNjY qQ1R0ns5ZS6fIVVh9EHYt3EzPokcv+/c0J1/9N1UcaonzzozdcBzgT4evkH1h8zYlqkS+tyk GjVq2DQADgNa13yc5tbwmCN84sm+dPCldo083Dwadxr48wMxcaolV2uwEHBWSebK7MIS0tQf e7QK8XQXNXum76Go3MdPiAjAO3Flhf2QHXbEtP2QveAHtkcgygmRbPrilOwFjIcULaUVjto9 JBo15S+3zI8/pCqMPpj+Rdy4D68O3ftfn21/9FhbcaoX1ixg5sG/ihRaeWHa5+v6tnj9uEDl x5xAKkGSUPWEGRAk2vd3nEIlPf3eyIAmC4kzP2527Q6fcmryOqskc2V2YYnjA0PHvvdHkVJ+ atfLId1+KsfMiDn8qjft66zp32RN+4YxGBtev8kmttHDjfKGaELFe8dpkYlO/178d5pOrtXL 5cq/o7NnfM3p3Xw8WpVeG3Ea2uZ9lwceFZPwm4JzxSUqiaHTsglnMkMibaV3JLr0eBgVTZW9 +C+1GGrmFSz6ztLu2LGz1jR0nGjS2I9vDXnvau//ne2x6feOKypO9QLcXbPVpvWdXiXybk5M tnxQG4yMm78Pbhbc5uUpN6Rq6vxhZ1jHRoGubr7hvyYRp1aROLd/J28PUfs+s+8rtKSaOS6u HiR0cf+CZsG+PrWabvgzNeOfPW3r+bGz5V//csCzzb093ANDWi05dIM4k34N93VzdXXzCu3U ++DFbM5Q/9456vmlR3lHUoLiyFxtLnJ18yN2zJZnnt12jVOB11m1mSuzCw6ja/vEyZi/mKAs OutTd0I5ZkbM4Z24Msd8nsVsn2WO+SxrNLNlGu3PMxmbJ8obItk0Sp1ekg5OUgQj7zizhAcp zH0rEQz1T79lji6N0rTZW2+BR3fjKkRlBWp94T2IirNUjDPxPFRjnAV3IMqT0NSdbOvR7HmH YVSkmD3rD5C8EmVhwfzDArtjx85a09BxokmvfnCz154r3bae7bDm9+YLK0719vduMHj9lgOf fn81Pp3tt6R6bWYezFMo71/c0/S149T5wrrD+TLt/V/CQaqI88T4p04l5GjV4ovfvdl6yl/m OYFLb/Z5ZctZ4u+y+P+yperEf9b7NZgzc+u3uVINO9u4uj7hf8RpdJprxxa5ez9FnCB5ww7H l+iUN05s9q41hN3Ff2+NbzH6La3lkSCq4vO+IdOI/Un74KYj+9T192nVbcz5XIWAs2ozV2YX HOp7usl1+hJGcIvdPOs9fkJEAN6JK+PVQxmDDmYOOmQwDmW+eoixBx3MIK/8UZ4QyZbzITPd Kfd+R4oQVUmZCSP3tU8yhx4GQy9JhVY0akw79EummlqaN/oTiBYmKUr0upyRX+m0en2mGvxZ r32r15fokv6GqDHh8E8yhhkTZpp6zx5OEhrzM5IHg9n8zaN2x+adta6ho0QTX373xnM7Lrff cKbp0pN136g41dPI45fNm9arSysvV5fgVi//cKeI+C2p3sVi5rcavSbf0+9p6kxQaDg1u/h7 klkC1o9eAT3NcxbGH2r28kaN3ui/TlaOOgXYKUqLKzK9Tubi4kLs9T1Dmo7c+vNfl/KUpX/x E5pE7JvsW29SsVYvMBIkZm/P5afTiN3V33NXVJpOp824daR2510CzqrNXJldcPB0dTFdENG5 uHo+fkJEAH7Ve+n9jJf2G17ZBnsTiJaGjNle+UQt1eplWTS5nvNEg04DTlbXTNu8L5lrSsp3 viWevJ8LoKjYEA+v0sUx8Cpbew9eNT8fFU6Y+XKZwcAsDGtPXXKU1btj7c7a2LCKo4lddt9o u/lyk1Vn6oSd8J1RCc9wqovTftw3w7f+FFJkKY6erXoK8qPUa1xcRWY1S23QUNZlTC9OVKdK G9ayL7lkRPw6swxsWy2J37dl1aTRQzq3qEudGtnN4S919nN3dfMK+fJ2IW3yzOvb2gXUu2BQ Z0sjcXLEyUd6hR3jCeg1ru5BVjkrPXNldmFOPU83sZau9eo/fkJEAH7Ve/bt9GffzjBs6cbt nfRnjK/8Ub4QyQb+7PD77ORqGfPLc1aPd9hpS/TGKLP1/pFZ06XfyjB1nb06BaJ6WKlpFJnd 39ep9Xqyalv9KURJwuwe77CHRHtnD6b4jUO5X+SAIR79gdDu2L6zVjV0mGhCmx2xjdddrr3k H585J2pMqjjVCxW5p6mMayX4H+3qHkDsUnGRx7NV74OkYjB06hxP/26cmmy7g6+HVKfn9EWj n0/q9OHNfHO/JXtei8CJb//w+29/xt69x1kA6tSFF47N9/R/hjaBXu/839Bmo78TGIkzo8i5 MnnUmiIt3zHRK91NN3Yf4azczJXZBS9j6viQqxyq4vM+tUc/fkJEAN6JK63NrvTWzJZGtjYm G4w2u/ijfCFjNrDbva0sNv7iDdHcrxndka//InPIn2Do7l+FtrAEAzuz216oXxTFvPFKPHwf 7TRjoPHese7hWabCfeO1dOnA9yCa+w2TULHuiwya0NQ7HRUdTHrXb2FtqEuIENod23fWqoYO E70XGh5be2WET9g/Nab/VmNcxanejxNajNn9XVKuWKso/HXviDrPbCN+XzfX8F+TtIr8r1e/ yFa92i3XSTXqe/9ubjn5D+qk2ah9bFiTk/dydHp15LcLAkLDiNPPzTVBKkk+HtZh8Vn2GB6p eiGebsfislXi9IOLelDna8Hem367rtTqk34tvQNojOqV4xrU/CpVYmkkTkt2xIc9us8vfX7J QP8g0Tf38vR6beq1L5q+dkTAWSWZK7MLS5wY0Lj/26ckSsnvu3s3Hij0nDPy+PCrXuPtxi2U 9dp4W6mfJ8oTMmVjGmbOulWavNme4sP3tMXqErVKfT42p+NOcGYtjtApdbr4i9DWfDzpnY3X HNS7DjGVN6aSYn5npm1a07IJO+1k9W4cUmkxdHvRTSnYxX32Wt4dm3fWuoaOEr0XvO6695KI GnP+rjHp1xojK071dOrMLVP7hwSI3EUBXYfMjTJdGLz/y/+zdx0ATV3rH8hmDxniAsW92lpX 9Vm3VMXFUpGliAxFkBVAptva93/ta1/H63ivrdoi1tZRrX1V2zqr4kRUBJU9ZIUdIP7PzUku l+QmhMiI5vtxk3zn+53znZHr+XmSk3uJHZIck/4B/7xMVb2qB6fmD7KeuDAsr4nm2zfKx48Z vrPHcJnMfqNmHXpUjZ3b5ziwuMaO5lyZ31J1qHp39ydPduhj1n+4/95fSGfplU+mDe/L1NMl dnv+lC1TpPRagtWEbYpaorV7OKeZcOR/yFZ66ZO3hlkzmbxx8/2zpNtcaZ0k5Aew+yJ3eRWK oKTqqqwPxg600NNj2QydnJYLF1voXtBOXHl9EuSOxHxsWMpTBKuEUl7wZWQ1sEmdZR/oR9zQ Dbqg4/OrjttPOotfjWuzAAAAQIegVz2j2DxD4sg1lBh5RnF5bbZiVu2CLyOrgU1SmX2gF3pD x/+CzppfdVb8pOMIqgcAALQEtBNXLisqlxWdx47KY0XnsokjDz0TziipQcMqoV49VgOb1Cn2 vs7GGzrrzuusPK2z9CeduaB6AABAS0CvejoRcLzax32doHQdn/M6bqd1Fv+oMxtUDwAAaAlo J65en5Ph6O4DVA8AAGgnaCeuXp+T4ejuA1QPAABoJ2gnrl6fk+Ho7gNUDwAAaCdg4gIggOoB AAAtAe3EdQ2gZQDVAwAAWgLaiWsf4FVHSkoKn88PCQnx8/NbvXo1qB4AANAS0E5c77ZhXztj 37vtoa2sprWn82xyckp0dPSmTZvWrfNbtWoVqB4AANAS0E5cezHQ5Iie9ioAsJrZHtXY5KSk 6KiojRs3rl27duXKlaB6AABAS0A7ce0RY/ceZQC2t2rsEjYxMTEyMjI4ONjX19fd3R1UDwAA aAloJ67dGLvEj127xK/oGf/tBlbz2tNpNiEhPiI8PDAoyMfb29XNFVQPAABoCWgnrp07d+3E kL62T2k7q2ntUYPdGr91y5YtAQEBXl5eLi4uoHoAAEBLQDtx7SCwffv2HduJV8IkXiSO7aqz OnKgLSul6CMHrphpa2bAYLD7DJqreqskMTvfZlXY7ojZw2xsXFxYaNgGf39PzzXOK1aA6gEA AC0B7cS1TYqUbcqgIosFSElZ+QxUlq2ni9iw+MT4hOQubFUXsprWHlVYfkzM5s2b169f7+Hh sXx5N95VFgAAADQKtBNXckpKcnKy9CF9wc6U5M6yWNQwm5S81XHScEMOk8U1Gj5pQVwikQNn oGWp60Rx+a2Lp4425rFYXOORUxcnJBFBMbvO7Z1h/Ux5JlZvrwwjYyI2KSnuncmSmCNQzKSk F++R2qU0h43mt/1sYemyZaB6AABAS0A7cSUmJiYRfwQS8UPsIZxidIrFAoTZddNtkT3KOTDY bTwybKevR16coUMWwX/WAGQPX7phw9JhyBg4y5+Mbz11Vfj6Bchgcu1QvWSlfjjmiraYL94j dUtpEBsVFRW8ceNa37Ur3d2XOC0B1QMAAFoC2okrQYp44hFPvMZTXZ1jsQBh1yAOA9lBsVu3 xoWJFWoIckoydMQi4AwbYrZu5W/AAoecOAMqlRAfIzb1UL1kpWTM+LaYL9ojNUtpEhseEREU GOjj4+3m6rZ48WJQPQAAoCWgnbi2YsRLn+MlZjuozGIBwm6mbvvdLbpMlIXMoJxFYIgz8OOQ ySd4XdbW9hkkdryymC/eI/VKaRRLbOAMDPDy9nJ1cVm4cCGoHgAA0BLQTlyxCHFxsRhxyCRA cXWOxWqDXbZsYuW1MTqGWhZn6JBFGCBeuPlF8vlRfuKFmz3K15aBzBwXK3XGtcXsuh6pWUqT 2NDQUP8N/p6ens7Ozo6O74DqAQAALQHtxBUTw+fHkOCLD6mPH9NZFgsQTnlMsET2sEU+oesd kcG1mITckgwdsaj8molWyB66aO3aRQ46xPd661Bt0vhEvaQtLcUnY25ui/miPXqBUprCijdw +nl4rF6+fPmC+fNB9QAAgJaAduKK5kdH8/nSg0gR4EdL/Z1jsQBJ/NGhb7/uYMRl6TLYVnZj PDeHR7dl6Iglagqb9cYwlIHJMRwxyTFSXC81Pmm3OdvHXBMa8eI9UrOUJrGbQkLW+a1bvWrV 0qVL582fB6oHAAC0BLQTVxTgVQd53eklS5bMnTsXVA8AAGgJaCeuiIhIDLEhSUh9kcBqYHs6 ywYFBfv6+ri7uzs5Oc2eMwdUDwAAaAloJ67wiAh0kKDaKAWsRranc2xQUJCPj4+rG/Gzhdmz Z4PqAQAALQG96gFedQQGBnp7e7u6ui5atGjWrFmgegAAQEsAqqed6CrVuwYAAAAvFUD1tBOw 1gMAANoJUD3tRFepnkgkkiSwgZ6J47kkASywwAKrYSyt6vX2AhTQ08CSp57qtQc+yxQBWGCB BbaXWVrVawRoGdSQPKx6rQREIuIJWyJJingWAQsssMBqGkurev8BaB86K3lS1WtpIR7Eswxa WluABRZYYDWNhQ0JALWBTp4WWjTTu4EFFlhge50F1QOoDXTyNDc3t4gP8UP6LAW+GmqL1EDQ YzD1jS0mLw3MFDQoKnvuXxHj7SxZTM6gsbM/v1REZXGQZqlDUb1tORWw1LLUmMoj15T8QHbk YLFASX9Vqbe72ZyjQfqWLvKtIvtLGjJl23WzSIBZZ0v99WmPerdHwALbJSyoHkBtEKonFArR o1n6KpQ8xA4hnjmF5AQrFDbWVx3bORvZff/2IW3ZxyeCEOv1zdXiO19yDEyHvuFHZSUByYoU 1NssbJdTnqWWleakZ6llc068Q8rB/B+zlfRXlXq7lW1sKHzDiD1yw5/yrSL7S74pMmVzfm7X Tcz+4T+CbTgur66xt3oELLBdxYLqAdQGOnmamoToDz0TL+iMaiIglP7hmbNJamC2QfCInFQt X9tDlt3zmqVkPcg0q24Q0kaWxmnPNlb/c5Ozrbk+z8R22eYPahuFlBqFVfn/m27J45i8eTq/ uuLJCZcZY024LAaLN3DU9HePPW4StuVsbKzYF7DI2pjLM+m7OGBvRX2TTI+OLxiAco4IHome +8/5CbO1zy67TB5sZD0+7qMfZfob+bfBliNDFEUuuvLl/AlDDThMNs903NtuJ59UoSoKr3y1 QM7Z1FBJLV7eQPhwFWcOvLfozYHmA0bFpj6kjtW9r+Yidu3NQuq7gFmyv6RfZpzlukmwRek+ KDn3y3vU91f5uw8ssJrJguoB1IZY9Zoa2x7EdlDxc5P4VTIzkwZm66ofIpvJ6e9mZaCryzhU WI2c1YXfM3R19S1X2POYLIPRa2eOMdQ3n7go5G5lHTUyGZBa76XEKci56LPLlz9biIxpCZdJ fazK+2WqBY+lP+Jw1jMUYN1A4/BD12oa6nNvpSGWazqDjInYPyInIGPFf6/f/M4DGW9E/inT o2UW+sj/2a0v0DPPYhFm/zunP0ou/+raNxvGyfTX/+f7eY8qFEWeZcpF9v8eP3ty8e/IMB60 HtUkcT4pe3LxPYmTUvzWQUlxVC+uYtzmH55ceBcZHNQXyruwzd4UOX8sqqa+C5gl+ytVPdl3 cFkfcTdvSrqJmeoi4mNP08HJ1PdX+bsPLLCayYLqAdQGOnkaGxvQHwblFR/kBNtm1AlKf0x5 G9kDHL+6f9AJGUM9jiP/MQ/iNsGOX99h6eoiw+/wnVupXsiwnfkxNTIZh1rvdBMOcl6rqKkp vyrWsrfJnBPNCRFZ9MNDslX3z3y/NXTd9HGEVOnqcRra2taA49yqrKmvfkzEMZtH7VFtRbqe ri6Ta19XXz+Uh5qpe7W8BnEj9Vko853KmtqKGzL9vVdVh8vSRh7CYyLbcty8bR+n5grqcY8o zkO5gvbFK2rrBZLiZBUoZkN9OdEXXRb1XUAtRM68mjrq4GNWnFmXMpjt3kHUC0k3G+pwN689 I7pZX5NH/F+FN5j6/ip/94EFVjNZUD2A2kAnT0NDPYEGDKkhTeN5tV5qiOdbhoGJ1VzPyHuV tfU1RaMNWAy2TWZJpg2bweINzasswtkKa+rrxDM8g21NjYxZiUdaL1uPEMrKugakTDrEhhl9 xOKcDFYfNHWbjYjErfpjtzOaxh2cAlPP3JGGkuRELE8cp62pDB61R/l/ESpsNvQ9VO0HI82R veZKLmI54lLVyKqvlulvVb2kLG3k9M822eozsYdtZBf55XUUWdb5RToKIF+8njK2De1t3GY8 JjVilzFTD9m1ErZWPESGqFXkCFDfwTxpN1FC0s3LRDcb6gU6+P8JlPdX+bsPLLCayYLqAdQG OnnEZ1h9nfgQG/hV4sbzKnJJjXYselyMfQ35R3sTXyGN3nwGeRzEi5TMSkGdoJBYXHAHUCNL pndpHFzvW8bEUujqM0F12V86xFpvNplz+8/Zf2wZg4zE64XIacthIPtRVU1tVbY0FBmz/k0j NjIeohUZXY/O+Y/UaY8RfmcRO86QKHWjHNV+SVF/FUWurc4/+d2nIWtmiXs6ELM1EudM0kkW p5Ylm00dZ5LFK9C86lqUmiwen4dVRPHaKuL/EmzD16gdp7bqrP8Ium7W10gKjpd5B5W8+8AC q5ks/EodgIEW/2qoXp1SSGZjiiGDqtLLJuKVCFq//FZciTzHNxAiteTTi/d+DkHGoEVf0Qak 4tfgsci58NNLlz4hNh/+bdtlas6KopMsPV2zEVHIflOsUO9defLb+07ybTu1YTRR9Sd/5l77 ABmmw0KotWzpb4ScnlfzkJ1zZhmyjfqHIfvAwkHIXvr5pbSwCYr6SxvZz94Y2f93Ibv4/nFk 8MwXKnLSFqdWIT8s7w4nlmlHCsqRnbZS/OnxnmOlleVnP3MjRtXpW0WDqaib5XkHkW0x+gOl bzgA8BIArkgGaHyBK5LV1tbWEUed2EAnVK0YxCt6SObVWnKCbcfist8tsUNUv5n/xp4aQdk/ NrsMNNNn8kynO4dllguokXXkQHiri3f6L7E11eca9V0e8s+q2racuOy74t2hidcK7vw3bIAx 18jabuXmTTJtIzJWF23zW2hros9gG4ybtfq3vGdkvTVVBYYMQp1/LapAjvJ8YrumHsOwoLqm qjTd460RBsYDQj44pqi/tJHLn/66Zt4EEx4LOYdPWvjN9QIi8hMZZyERQ1CUIiluiIqfySun jG27cSbHKuMgsbHH52ousgVVuUlr3+lvbqinq6tv2ne+V+zDiupaaSPbDWZbNyuJxhQckXSz qvbplTWE8qZlyr+Dit59YIHVTBauPq3luH79+s2bN9UTPqx6tTUI+NQSmyiB/pCnphbY3mKr K3PRwnZk4Nmuinw2YCTHaHJ+pUAz+wsssKqz8L2etkEkEjU3N6M3v6Sk5NGjRzdu3MjIyCBX fJ0KhU6eGjkI5Axge4W9l+qn38e5qyI799H3T8t88VYBC2yvswpVr2dve6Q5t17SZFa9ODLJ 1tZWoVCI3vri4uKsrKz09PS7d++qrXoCQY0AA51UYrsGm4Ia0gMssMACqzksrepR7kTUY7c9 0pRbL2k8q3YcSbKlpaWpqQm99UVFRQ8fPnxh1QMAAICXCfSq19rjtz3SmFsvaTirRhyZJKge AADQZtCqHnEzBsU3J+oetmdqedlZdeLIJJubm5HAVVdXFxYWPnjw4Pr163fu3AHVAwAAWgKF qtc9NzZSxmrGrZdeDlbtOM0tQqGwoaGhqqqqoKAAqd61a9du374NqgcAALQE9Kqnwq2LGqru RHg4DupjwmQwDS1spy/2PZFVgajM375Z9fZQJWUzz4gzyLGdukGS1rLqxGmfbGpqqq+vr6ys zM/Pv3///tWrV19E9Xr7hxcAAADQOdCqniq3Ltr2ppWOjs4Xfz6obai/83MScR2JPguF0jug KSlLZqCymnPrJQ1n1Ygjk0TqVldXV1FRkZeXl5mZ+ddff72I6nUqPwAAAPQ6aCcuVW5dZCS+ hoP7ju+J25lJWep1HlC64rHM7cxyqBma2t0urc0uvPJV233HZrqdfFLZtTdXeolZteLIJBsa Gmpra7Hq3bt378qVK7du3QLVAwAAWgJ61VPh1kUb7U2wTlmMXfjlr/dJVqpoRFk/8e3MBPX1 eTfx7czelrnVmiSzOCBpk/cde3oJ32LMT3NuzNTbrDpxZJL19fU1NTXl5eW5ubkZGRlI9fC1 WUD1AACANkDJdTiV37qo/PHxOUOMyYXba4sCLhZXIxYnybIytzNrbHe3rwZam3qLsafEfccU tkHTbtvU3ay6cdol6+rqBALBs2fPnj59evfu3cuXL9+4cQPToHoAAOCVB+3EpeKti+pqSw+8 u2V0Hx4WLNPhm+ulty/BZaW3MwtKPXsX+2nvCyY260j7hux9x9I158ZMvc+qGactiRZ6VVVV paWljx8/vn379sWLF0H1AACA9oB24urUrYtqBflf7fYTX5vdACUZ4nthY5ZyO7NHWMXqpBlw WXxHzvLaWsGzdIka4phy9x3rsVsvaTirRhyZJFroVVZWlpSU5OTk3Lp168KFC+np6aB6AABA S0Cveipgpa0hkqSoQ5crBIKM394Xf8EXg/z2XGKZlpNfUafgdmbUDI5mxDrx/64+TQ0aRWag vcUYoKtQXV1dUVFRXFycnZ2NVO/8+fPXr18H1QMAAFoCetVT4dZFZVknfRa91dfMAK3dDEz7 znTZeLmYuCdX+hdh5lyW1egtKD/t7cyuSzOgIPdTYx0sDCwGT//i3F2p6tU+k7nFWHqBojZo 2m2buptVL45Msqqqqry8vKio6NGjRzdv3kSqd+3aNVA9wIujsqL8SU628uPp45zGhobebilA q0E7cfX8bY96ppZXgFUjjkyysrLy2bNnhYWFWVlZN27c+PPPP0H1AF0CpGinfj7GjwxTdMTx I079fLy5ubm3WwrQaihQPWU3J+oOtmdqeTVYNeJQkxUVFWVlZQUFBfjS03/88Ue3qh5av5MG BoPJsX9t3v57lfQFRE1/919grs+2tp/4/rkiRdFo49PGKzjnjij3cwVK2qa85cqhYraeRG81 CS3lkK41NTUqyiAQCHbvSAHVA/QuaCcu4lJlPXvbI8259ZLms52O0z7Zi6qHDVFL46Wv1xn2 W0eb/8EXjhN2/SJoEt4/vY1rNldRNCXxZfDVZJtZu2baTP5KSduUt1w5QPVIINVDCzolGRoa GkD1AL0OhaoHeEVRXl5eWlqan5+Pb7jw+++/X716tSdV7zkhfFV6DENkOFnwTlYQ3/I0Vpzk 9VmOjNiBxh8W1nYYTXl8Eq3CEiueRZ7giSnPukTYqqhsc31msOMbxhzeqJk+9+qaZdj/7Vox NfQQMspv/nf+G4N5LKaJzbDNn96mrVe+Ry0Nj/znjeOxuKNn+2U3tJClzu5YaOHgvtiCd6qC WBzVFn2GnHvzBMhuKD/BM1+kpOz3u4LG9jfRYxgkHM0hu+A9a6SBgWXol1fIJqlevEuE8unj nA5Vb3tyQnOz8MXrAgDUBqietuHZs2clJSV5eXn3799Hq7xz5871sOq1NAnO/NvLeNAmZP/p O3xOajYycn6YN2rjJWQ48Jhpu3z6GnPtxi8+U1yvKJqS+FQUXfTqM/YjZLw/2sLrUrGismlL 7FYfuCpsEV7dv8puSRqV/X2fu4PzPiwYblb6CSczmlubb6RtYvKG0NYr36Pj7kN+ySptEQou HNwx3PM0Wcor9UZ1seDcmqHzjzxGnsxP3+JacifuIcT00YFZDivPKCn7Vsw35XUt2T8lIOXC zp9cBnunpjc2ln8RMIZskurFuwS5Tx4nxscoydDa2poUHwOqB+hdgOppG8rKyoqLi3NzczMz M5He9aTqSb7XYxuMmLz4h2xiUVPxINLqjS+R8fVE6x1PqpHB0dOdGZda1dSU9Xtyn3G7FEWj jS9f+4EZtvN/IJYzOWnzbWccUFR2vCE7q4FY4jU3ZLEMxpDsxffXGFh7VLeIZAqKWut0dXVp 65Xv0QQjdn2rOIKoiWM8jSz1uJHQ0vKMTTaTvkXGv0ZbbDzlZzpkN7I/HtvH/1aZkrK4tdTa Jxmxc8Sruabq86RT9eJdAqR6SUpVDwFUD9DrANXTNiDJKygoePLkyb1793pY9eRZUYtggLF9 fUvjCIvxQvH0bMFiFDa1YorBspDJb8zUq21t0yBRa70e01hRfFFzZT/xdRIkasvpV9ncTr/I IkhqmzAjatRl8Ej29dUpo4ytz1c3YY+wJvP9pEgP50XjHawU9Uu+R/hSDBi6ehyZUq3N5dbG I4Qt9QONBggay8y5FuWNVX15pkXiQVBelmrrM/SkXRBS+6Vi8S4BqB7gpQDtxNWr9z4CdCPS 09OvS4GS58+fvyxGb6kewpcTrAKPbBnoeBQn3Sz1b9cSsyLSLCbXXiZzSH+jI8/afu1VX5Zm PChMUfzS6/7mI7aRyZQR5v7XS2nbNtaAlS9Wmeb6B2zDN0gWycj9zxfbOx/EngAHk1Xvff/z sVO3HjxU0i+ZHo0xYFGVWr7UB6Mstl+Ksxz/GbJ3DDbdcGqDqcNOFcuS9lRjTmY9sYIT1qST TtWLdwlA9QAvBUD1ANd6dg+nDJ4cdUTU2qslOHl5y7iZH15pEbVknd3ab7Zse0ou7bSbu+Vq dklza3Pp4/S4xUP/fr1MUfzD8wZ4nm37wUL+b6sHzDtM27bUhQPDiC/siO/1BjkdaseKGt1s Tb/Oq0GmDZuRllHSJCj4ZNMUJf2S6VGa06ATD0tbRcKrB4KNBwbJl8r65m3jEcazvyO+Dby1 602uJXfKBxkqliXtU15Dnb+63NhUtT9sQtv3lSoX7xJg1RMKlYlabHQ4qB6gd0E7ce0DvOpI SUnh8/khISF+fn6rV6/uRdVrElxhsszIDZatwpLwZZP02ZwhU1z+kn60SMXtb6JH2prp6eqZ 9hsZc+AetSIZDDMfJ6B8JYcWjyPNhtVQPGSThLW31swYwWHpj5m3Tn4PZ+m1BKsJxJrx7v7k yQ59zPoP99/7i5J+yfSouS7Dd/YYLpPZb9SsQ4+q5Us1lB9DyZ/FOz8FeXuQ/XlxnYpl2/YI NT72nzfGyGRw2Mdt3+upXrxL5A+p3s7tSQ1KL73CjwwD1QP0LmgnrnfbsK+dse/d9tBWVtPa 03k2OTklOjp606ZN69b5rVq1Cq7NAnhx5Oc+3b0jRVBdTcs2NTVVV1XF8SNA9QC9C9qJay8G mhzR014FAFYz26Mam5yUFB0VtXHjxrVr165cuRJUD/DiQKp36ufjSNfw9ceSEmKTKcfunSl7 d20/fepnUD1A74J24tojxu49ygBsb9XYJWxiYmJkZGRwcLCvr6+7uzuoHuDF0djQgBRNydHS 0oyO1taW3m4pQKtBO3HtxtglfuzaJX5Fz/hvd2dZHR0dzCGjayP3Hqtp7ek0m5AQHxEeHhgU 5OPt7ermCqoHAAC0BLQT186du3ZiSF/bp7Sd1bT2qMFujd+6ZcuWgIAALy8vFxcXUD0AAKAl oJ24dhDYvn37ju3EK2ESLxLHdtVZvJWOZMmkxHiByFRWGrYT7JZ1buPt+6hd74u0VkPY2Li4 sNCwDf7+np5rnFesANUDAABaAtqJa5sUKduUoUMWKw7pIZMyfjUiq87K1JVC53zBeruwtT3G 8mNiNm/evH79eg8Pj+XLl4PqAQAALQHtxJWckpKcnCx9SF+wMyVZdRaLC8mSSWysdJxqqc82 7z8mIC5RHCfOcfJwQw6TxTUaPmlBXGISKoZzTh9kbmA5FQWJDlgx1NaCzdRjsLg29mO9I7Yi pyRsSkpSYqzj5BHGPLYeg21lN8Ynso0N8Fw+sp8x18hqrmc49Sddne0RyapXSnPYaH7bzxaW LlsGqgcAALQEtBNXYmJiEvFHIBE/xB7CKYaKLFYWkpUmJYbNJJfAFSORYTLYGTnXTbdF9qgV gcFu45HRd/p6MudEz80RobEo8mAuEyV9w2PC/d9BBsd0ApkHsWun9kXG6BUbIoOXIYNrOpFk B0+eFx60BBks3rDEtoZ1ukdSVr1SGsRGRUUFb9y41nftSnf3JU5L1Fa93r6oDAAAAHQOtKqX IEU88YgnXuOpLlVZLC6kU5KUGgH8uK0xAcjQY1ki5yDxhYKDYrfGx4Uhg8kdgmLgnJtiJVWY M/VQ0sB6yJzFbuFxW7GTDDtAHCGYyNzWKsxuiUOJOMLSZSKWLNLZHklY9UppEhseEREUGOjj 4+3m6rZ48WJY6wEAAC0B7cS1FSNe+hwvMdtBBRZf8l3qIkRHV5eNLCw6MUQevliJGMhitl0e XgfLEwoiySkNEeA02Yilh50Mtum0pQFkNDIC0lJqq0i2zY5v5+xUjzCrXimNYokNnIEBXt5e ri4uCxcuBNUDAABaAtqJKxYhLi4WIw6ZBCguVVl8n5dNfHG+6M1iqbJBLBYdvyh+THQAdqIC tmwi80Z+LDUyzkmNHMMP83BePHmcHbFIZJogF85DVucfyae2imTJehGrK3F2ukcSVr1SmsSG hob6b/D39PR0dnZ2dHwHVA8AAGgJaCeumBg+P4YEX3xIffwY1VnXMWZIXBzmroyIjPBaPBrZ JsOWIRarT//Jy9YvG0E4HZajzB5vWCJ72CKf0PXEJeu5FpNQKMlaTxr5dVMOSi7w3bQleCXx KShvKKpNmofvMZG469mwxWtD14u/9TN5jcqS9SLbVPxJaUhoZGd7RGHVK6UprHgDp5+Hx+rl y5cvmD8fVA8AAGgJaCeuaH50NJ8vPYgUAX601K8qGxUV8vZrQ4x5bLS2YnENB4+bHhQZFS1V Is+l0025rD79x/iFR4qjhL39uoMRl6Ur3oG5JjQc+XBOMnJ4yJqxg/tymHq6DJaFrcNSv1Dk bMsTHTbztSEGbAaxh3PgSPegLe1Yab3IXu80mcfUM7Cc0tkeSVj1SmkSuykkZJ3futWrVi1d unTe/HmgegCARkAkqqqszM/NfZKT3eVHfl5uZUWFSCR7y0VtA+3EFQV41UFed3rJkiVz584F 1QMAeh8iUXFhwb27d06fPH7o4Lff7/+6Cw8UEIW9n3G3vq6ut/vZy6CduCIiIjHEhiQh9UUC q4Ht6SwbFBTs6+vj7u7u5OQ0e84cUD0AoNeBVnn37t4+eiTtwb2MwrzcooL8Do/CfHTkqXIU 5D29l3Hn2JG0vNwnra2tvd3X3gTtxBUeEYEOElQbpYDVyPZ0jg0KCvLx8XF1I362MHv2bFA9 AKDXkZ/7lFiO3csoLS56VlZKPco7dTwrU3RkPbj/+5n/tbQ093ZfexP0qgd41REYGOjt7e3q 6rpo0aJZs2aB6gEAvY4nOdmHDn6LFmVKZOsFj6ePc347faq5GVRPFr09JQO6HT2mejo6OipG UzFnZ7ORPwBlMDn2r83bf6+SvoCo6e/+C8z12db2E98/V0SbpeCcO4rjfq7gRRrWtXh6LHjg wn/S1k4dAdqyMt355zsDgo89fcH25BxNMGAyX/e7QNsSjIqMHe08Kow8FTVPjr7zuh2byRk8 welkfi1ZBQldPQ6ZuaXh0XQTDrV41cPDSycONWBzh0xaciKvtlO9I5strPmLWiNtN5W0VhGQ 6n2//+vC/LyuVLqyYjrV68SNfeXH8GUHqJ52QqtUDxuilsZLX68z7LeONv+DLxwn7PpF0CS8 f3ob12wubZ6vJtvM2jXTZvJXL9KwLkRrc9lk8/7XaoS0tXeoejLdEdZcG2gxuaz5hb7xMWDo JfyU3dLabpegTAPiRptTPaqMPBXBg4z/+dfT5tbmJ1f+YTI4TIZ9/MOGyTFnsN1Qem31eAuZ 2lfZGEQdulLfVPfn5z4mg0M61TsyVHmGX58xXyhiVW+tDJDq/ZB6kFzrFeVcO3b6wunUb1MP 7P8rM7fTzuyHt678fvT7b2VV75eTqqse7Ri+7ADV0070ruo112cGO75hzOGNmulzr65ZJuf/ dq2YGnoIGeU3/zv/jcE8FtPEZtjmT2/LZEP/BfWfN47H4o6e7ZfdIHt7bto5X9RSpccwRIaT Be9kRQMyGitO8vosR0bsQOMPC5X9V7xVWGLFs8gTPDHlWZcIW8mOeM8aaWBgGfrlFWqNZ3cs tHBwV9RIYkHE0NNjcAaOm/XJhRIlTuV9zP7unaFepxWNs3LVo+3OL55D3/kuW0kp5aCufWhH 5rl4oWc+Oo7qUT7y8s0wYujVi9sraq3XYxpTqZaGrDHWb5c3SzR3gKFNyEd/KOoIcTIwzTqs jrYj6Umvv5FyQ75s4Z2fF9pbjJjhebtW2GFr5avDqpf75DFWqBOHjuSVEl/SFT26efjg/s46 8YEWj9Rkfl7uqRNHZVRPyamifAxfUtBOXL19cVBAT6OHVS9tid3qA1eFLcKr+1fZLUmj5vx9 n7uD8z48v7tZ6SeczED/T76RtonJGyIT8Lj7kF+ySluEggsHdwz3PK2o3jaVbBKc+beX8aBN yP7Td/icVGJ6z/lh3qiNl5DhwGOm7fLpa8y1G7/4THG9fJuLLnr1GfsRMt4fbeF1qRg7f3IZ 7J2a3thY/kXAGGqNXqk3qosFihqJ1M3pm8znrY23jyfyzBcpcSrv456hZvxHVYrGWbnq0Xan MivabOge+cyqg6yLdmSeixd62zMqqJ4OR14GkSPNP7qe2ypqzU//xGxEuzPwwpZxC7/NIpO3 SxqeK+h+S3354b3LbGf+vcPqaDvy79EWdstnWxnpD5vk8mdZA9n3EWs/edbQmH1hr93SIx22 Vh4yqnco9Wd58VLdSZssyKdRPSVQMoYvL0D1ANd6XPXGG7KzGoglXnNDFstgDJnz4vtrDKw9 qltkf0Uraq3T1dWVCTjBiF2PP0kTNXGMpymqt+17PbbBiMmLf8gmxKjiQaTVG18i4+uJ1jue VCODo6c7My61qqkp6/fkPuN2ybf5wAzb+T/kICMnbb7tjAPYOcmInSNegjVVn6fW+LixRUkj Y6fZ2C1P/vH0pWeNbcs3WqfyPg7lsTLrZVfKtCOgYnfQuobFGyqfWXWQddGODF7oyTSpw5GX QdXDT4zF11ZCy/bPsqtJP1q9DjO1J9et8k0i0dKUb9m3D4PBjRWPgHLQdmSiEXv3tfzW1pbC u6l9xu8mK7pQ3YQMUXM52/A15a2lxdPHOUePpJGql3rggLx4qe5UpHonj3dC9ciudSq/hoN2 4toHeNWRkpLC5/NDQkL8/PxWr17dw6qHJromrGyiRl0Gj8z5+uqUUcbW58VTx3Pim6bM95Mi PZwXjXewkp/D8bXN5TcwyGSjbYCoRTDA2L6+pXGExXihuCUWLEZhUyumGCyL5+0/rxM1V+Kr vEoElNOvUvwxmj5DT9oRIW2NtI1srruz5G/jDZl6DI7Nf6W7a2idyvvIIofx+XM0tdZSvk2j fp4mPwKKukO8HXps+eFSHWRdtCODF3oyTZIfeeXYZG/y8bXc5tbmx5f/z2xY2xlYdHFNv1mH lDRJBo+OR3CM3+qwOtqOtEHUTH5MitiGVolTV4+rvLW0QHp37Mjh3Cc58oJF2qo7FanesR8P g+rJO99tw752xr5320NbWU1rT+fZ5OSU6Oi2G8v2sOqNNWDliye65voHbMM3yJxodrn/+WJ7 54PYE+Bgsuq9738+durWg4fymjLGgFXbqvDaSspVD+HLCVaBR7YMdDyKk26W+vi7GKQITK69 TObS6/7mI7aRyZQR5v7XS5Ex1ZiDV1vCmnTaGpU0slVYeT4tkG30uhKn8j4O129b64X0Nzry rIGk6svSjAeFKRoBRd0h1nr6IxRVpwrIuhSNDBXYqXzk5WHM4kkkurWO+k3Z8XkDFv0vT0mT ZCBqrcVf8ioHbUcoURqZvMFkRR/lEKu5VmEp22iS8tbSAqve4+wsWi0r66STVvWKCwtA9Wgn rr0YaHJET3sVAFjNbI9qbHJSUjTlumQ9rHqpCweGEV/YEd/rDXI61C6nqNHN1vTrvBpk2rAZ aRklTYKCTzZNkdeUNKdBJx6WtoqEVw8EGw8MUlSvon+wT44SFzlfe1Wyb+TylnEzP7zSImrJ Oru132zZcTg8b4Dn2bYfLOT/tnrAvMPIOOU11Pmry41NVfvDJtDWSNvIpRa8+GM3G1tEOUcT 9BgGSpzK+7h3qNmW+xXYLrm0027ulqvZJWhZUfo4PW7x0L9fL1M0Aoq6U3F/i9mwfbTDpSLI umhHRj7b845GXh7Bgwccv5rV1NqSd/1jo4EBpB+p5zclNNfakqnd0Zz7WUaJ6Hlr9vld5qMT OqyOtiPzzLj7Hz4TiVrybvzHbmkqWVGfoTG1zcKHZxOHrjmpvLW0QKp38thPpOqlHdx/91E+ Mkpy01MPHCor65yTVvVKiouQsILqyTv3iLF7jzIA21s1dgmbmJgYGRkZHBzs6+vr7u7eraon /z98Ye2tNTNGcFj6Y+atk9/DWXotwWoCsRK5uz95skMfs/7D/ff+Iq8pzXUZvrPHcJnMfqNm HXok+41Jh6rXJLjCZJmRXwO1CkvCl03SZ3OGTHH5S/oRK4aopWaY+TgB5dtGtCoZaTasBs3U jY/9540xMhkc9vF52hppG1l65ZNpw/sy9XSRuiX8lK3EqbyP2d8vHux8nEze/iZ6pK0ZCmDa b2TMgXtK3gJF3TnuPHjp4cfKx005yFK0IyOf7bnSkadthuDxj46vDWIxWINec/zxsYD0mzH1 CppofnYhE6Hs2pdzRg/ksrjDp7n9QVkdK6qOtiOllz55a5g1k8kbN98/S7q3FrFVD07NH2Q9 cWFYXlOL8tbSVodU79SJo6Tq5d+7mHbgm9SDB4+mfnczp7CzTpnrcJKq90PqQdX3cCr3v6Sg nbh2Y+wSP3btEr+iZ/y3G1jNa0+n2YSE+Ijw8MCgIB9vb1c3V7g2y8sIpFaTzGyuCGSVQj2g /wb0NX9LfisRoMcgo3rdcdCqnraBduLauXPXTgzpa/uUtrOa1h41WMnt1AMCvLy8XFxcQPVe UuSe2Dhw8UddEuqjRQM3naT5XgzQY0Cq9+upn7Me3O8+1SsrLQHVo524dhDYvn37ju3EK2ES LxLHdtVZyvYzhpFFv9muwUrKbvFzG2/fR0lkHAolsKF2q16c7fkau5yNjYsLCw3b4O/v6bnG ecUKUD0AoNeBVO+30ye7VfXwJ5+gevLObVKkbFOGDlksT8hOio+eOdBQV1d3bmCMorJk5g4j U3Oq0aouZ3u+xhdn+ZLbqa/38PBYvnw5qB4A0OvoAdVDa71DB78F1ZN3JqekJCcnSx/SF+xM SVadxfKE2diwucjWt15EJJPiHCcPN+QwWVyj4ZMWxCUlU79qR2XjIrzG2FlzmQw9BsvUapCj Z3iKNBpipWFTogNWOPSzYDNRLq6N/VjviK0v3mYV2e6I2ZNsNL/tZwtLly0D1QMAeh35uU/P /u90xt3b3ad6jx4++PXkCbjTkLwzMTExifgjkIgfYg/hFENFFssTZhPjI5Ctx7JE9rrptsge 5RwY7DYeGbbT1yOnNDNRdoIpZ9rKwPiEhIjglcjJ5NqhsDhDYlvYpMFcJjJ8t8SE+xO70Dmm b754m1VjuyNmj7JRUVHBGzeu9V270t19idMSUD0AoNdRWVGRmXH32JE0pE1oUSazC6W4qJD2 KCzIz897Snvk5T59nPOIPLIeZKLgyA93lZV3JkgRTzziidd4qktVFsuT1LlV/A0fE1mDxNeF CIqJi48LFYvakAQys7RsiI/r21PfGGRtLC7FQC4yg9SINxdf6sfAesicxe7hcfFd0maV2O6I 2bNseEREUGCgj4+3mytxY1lQPQCg1yESierr6tCK79dTJw4d/Bb/4iD1wDdHDn0nc/x4OPX4 Tz/IHCeP/3T65AmZ48yvv5z77VfyQMG1fKH3XMHEtRUjXvocLzHbQQUWyxNm42LDiLUe0wzZ zLbLLOHNLkwyMy7rO3cUss2HT3TzCSb9EiO+zQh0mmzE0sNJBtt02tKAF2+zKmx3xOxhltjA GRjg5e3l6uKycOFCUD0AQEOAFmJImJqbhV1+oLBavsrDoJ24YhHi4mIx4pBJgOJSlcV6hNmo kAXI5lnOQawtm1jrbeTHUMtiJcRljRhEKoQfG8sPwUHIaNSwCDH8LWucF08eayeWVJMXb7NK bHfE7Fk2NDTUf4O/p6ens7Ozo+M7oHoAAEBLQDtxxcTw+TEk+OJD6uPHqM5ieSJckWHzhpmg Rd0M3xDEekywRP5hi3xC1xPfx3EtJqE8puKPKzeFRiEby+L8dSGejsMkQfht0aQG/3VTDjIW +G7aErSK+KSUN/TF26wy2x0xe44Vb+D08/BYvXz58gXz54PqAQAALQHtxBXNj47m86UHkSLA j5b6VWUpn2EyDM1tpzv5StjosLdfdzDisnQZbCu7MWtCw5Hfz2kKj6lnYDkFZdiwdIoxh8kx MBk9aSIOQEYjDRQlfJPH2MF9OUw9XQbLwtZh6frQF2+zSmx3xOxZdlNIyDq/datXrVq6dOm8 +fNA9QAAgJaAduKKArzqIK87vWTJkrlz54LqAQAALQHtxBUREYkhNiQJqS8SWA1sT2fZoKBg X18fd3d3Jyen2XPmgOoBAAAtAe3EFR4RgQ4SVBulgNXI9nSODQoK8vHxcXUjfrYwe/ZsUD0A AKAloFc9wKuOwMBAb29vV1fXRYsWzZo1C1QPAABoCUD1tBOgegAAQDsBqqedANUDAADaCVA9 7QSoHgAA0E7QTlzXAFoGLHmgegAA4JUH7cTVCNAyqCF5ik4eAAAA0GTQTlz/AWgfuurkAQAA AE0GTFwAtQEnDwAAeOkAExdAbcDJAwAAXjrAxAVQG3DyAACAlw4wcQHUBpw8AADgpQNMXAC1 gU6e3v7JBQAAAHQOoHoAtQEnDwAAeOkAExdAbaCTRyQSSRLYQM/E8VySABZYYIHVMBZUD6A2 sOq1Bz7LFAFYYIEFtpdZ+JU6AKOxsVEN1WslIBIRT9gSSVLEswhYYIEFVtNYuCIZoPEFrkjW 2trSQjyIZxm0tLZ0E6ujo4NZZPRkvcACC+wrwMLVp7Uc169fv3nzpnrCh06eFlo007uBBRZY YHudhe/1tA1opd/c3FxbW1tSUvLo0aMbN25kZGSQK75OhUInDwrVIj7ED+mzFDpitEgNBD0G U9/YYvLSwExBg6Ky5/4VMd7OksXkDBo7+/NLRTJs0eVvXGa9bmrA4RqZT5y/5vDtMsxe/CL2 DTsrFttg6FtJVFu+VYrqzfztm1VvD8UO3NpmikFbVjmrYr3AAgtsT7IKVa9nt9ZozvYeTWbV iyOTRCt9oVBYU1NTXFyclZWVnp5+9+5d9VUPxUKPZumrUPIQO4RYFISkOgiFjfVVx3bORnbf v31IW/bxiSDEen1ztfjOlxwD06Fv+FHZyqcHLVkMo4GLz2cWlOdeXTXEhMHpe/hpFWINGXqo 4IPKmoqqBmzfr6xFtnyrFLWZbCRKkrbyspIOdhQZWGCB1RyWVvUou116bGuNpmzv0XhW7TiS JFrgNzU1CQSCoqKihw8fvqDqNTUJ0R96Jl7QGdVEQCj9w6LQJDUw2yB4RC79LF/bQ5bd85ql ZD3INKtuENJG/vdbfVGG0OtFmC26sQUlbWf+V0cBUKbGxsp9AYusjbk8k76LA/ZW1DeR7Tm7 /72Fbw40HzAq9vuH1FIostQQtsVpePZu4JJ+ZgYMtuHoGa6/5FaR7F9HP182sZ+Jzahtxx4r GQ3lYwUssMD2DEuveq09vrVGY7b3aDirRhyZZFerXlNj24MIIn5uEr9KtUNqYLaumpAYJqe/ m5WBri7jUGE1clYXfs/Q1dW3XGHPY7IMRq+dOcZQ33ziopC7lXXUyCP1WcSCrqoe11df9QAl 2YavIVZaRbt6UeKPyAnIXvHfazcPeiDjjcjzyIszjNt8+MnFvcjgmP6tkSwljiy128Ke2fwa Mpz/c6Xg5r+RYWK3gWRnB+96cuNjZPDM31EyGsrHClhgge0Zllb1iC/8FG+A6R62Z2p52Vl1 4sgk0VIfnQTV1dWFhYUPHjy4fv36nTt31Fa9xsYG9IdBecUHKRltRp2g9MeUt5E9wPGr+wed kDHU4zjyH/NwQLbj13dYurrI8Dt851aql3gd9zE1MkePYGsbGiX1NtSgpC6DR6miXb0I0004 yL5VWVMvyEEG12weyoMz3Kqsra8vJyLoskgnjoztBkrYKcZEnIyqWmo/MftEUNfYUEXE0eMq GQ3lYwUssMD2DKtQ9bpn84wyVjO297wcrNpxmlvQor+hoaGqqqqgoACp3rVr127fvo1PDjVU r6GhnkADhtSQprEo1EsNsb4wDEys5npG3kOKU1M02oDFYNtklmTasBks3tC8yiKcrbCmvk7w GBkMtjU1MsqPnHcra3G9gsq7xFrPYAxZhUy9CDyxULY1gMFDZSkZJDZqszQCEZm0SRbHqaxr 11+SbatU8WgoHytggQW2Z1h61etoe4yntQH6B/5JXhXpr3zyPvIYWK9Re2uNkpx4PmmW7rLT 2K1BPcCqE6d9Eq3x0fteWVmZn59///79q1evvojqic+w+jrxITbwq8SN37g6qYjIsOhxMZb4 2HC090jiefMZ5HHgEbqWWSmoExQig8kdQI386Vs2yLnh4lMcIvdyIEr2nf7vOmldMvWi400j NrIforUepV4yA2kjgyFeZta3d5LGZPFa7/ozAbW/lErbbEWjoXysgAUW2J5haVWvw+0xN/dN Rv/ARwb8TrK/+Q5Hnkn7bqi3tUZ5TqnqkXsCNXRrUA+wasSRSSJ1q6urq6ioyMvLy8zM/Ouv v15E9eqUQiIuFEMGVaWXTZh6eAn2W3El8hzfMAYll3x68d7PIcgYtOgrav6Sh1/3YTEM+s77 380nubfPvNPfkMG2+iarVKYKqn1qw2gi4Cd/5l77ABmmw0IUZbbnMpGRk19B2/LTwWOJOP++ mHf9X8gwGuirpFIAAKCxoFW9DrfH1Jb+hv5jzDGeUteIXbUTjNi6uoxfSor2BSyyke6XK69v FEr3y0X8bbDlyBBU1p7HdFj1GyqTvmci8s8/koXynPUZxuTZo0iVj0+4zBhrwmUxWLyBo6a/ e+yxULq1gAqZbYFSW+I8s/+9ReK9eXHfPySWNpU3Vk8bamw5LuaDVDKnpm0rUolVK45MEi3y a2trserdu3fvypUrt27dUlv1UKg64qgTG+iEqhWDeEUPiRDUkorQjsVlv1tih6h+M/+NPTWC sn9sdhlops/kmU53DsssF8hEzr/4revM100M2GwDk9fedv32Uh5mpXW1q5coUV28zW+hrYk+ g204btbqM/nPkA9nwJGldl36F2HmXJbV6C11tbItJzJWF25f52htyGFyDMf8zeXowxIqSymi cDSUjxWwwALbMyy96qmwPSZuiCn6Nx5ztxhRRbcjdYhdbVHkfrlb363WIfbL/Ulujdtw8kHu o0pUdr2NoYG1Dwq6bTARwWrCv5HT38bQ0MYfZfYbaByedk3QUJ93Mw2xXNMZjZTteRJD3Aap k2iZRAobyb15P5B78xB7cNFAZC//z/V/Og+WiqbGbStSjVUnjkwSLfBramrKy8tzc3MzMjKQ 6uFrs6iterUoXA0+tcQmSqA/5KmpBRZYYIHVNFbJdTiVb4/JPLgAyccgp8PIeXghIStzvs6Q 7perxVsRqPvl7kk3v30zto+uLiujLNeUqWdoZ8jk9CutuM/W0+0z9htcy/0z32/dvG76uP46 xKY4DkX1pLvsxHFI1WvzS52oAQ2UvXnjDNnYKSg9S+bUtG1FqrDqxmmXRP/7EQgEz549e/r0 6d27dy9fvnzjxg1Mq6F6NXIQyBnAAgsssJrD0qqeKttjaivvGDP1mFz7osqiQVymHkM/vVxA s19OujWuul5S9tz6ESjp/B3x46mNp4jvbvwOuaLnEX7nUNg/djvr6uo6OAWmnr2LC1K350k8 4jgk29BQJ5OhTtxC0smR7L5rqK8rJ52atq1IVVbNOG1J9KZXVVWVlpY+fvz49u3bFy9efBHV EwhqBBjopBLbNdgU1JAeYIEFFljNYWlVT8XtMR9OsEIK4riXWPRZjH23Xrpf7oF4vxxZtk2q xAXvfjsDJdkmbAbLvLiqxIrNQDbyzPg2A2Ww5TCQ/agKTc3ZEgmjbM8jd9mhOFjLntXWCp6l SzO027xHlsJrvevPqqtKzpIZumNrUA+wasSRSaI3vbKysqSkJCcn59atWxcuXEhPT38B1QMA AICXCfSqpxpyfvMgl3XOJ7LqVNgvh1Bwax32mAzZhpLvDjPDSb9bBSj5plih3rvy5Lf3nciC pEHdZedoxkP2/119mho0Sj4n1f5+qR0yln119WOPYcQKVFdXxQ6+kqiurq6oqCguLs7Ozkaq d/78+evXr4PqAQAALQG96qm2Paa2On+gWIYYbKucKmKvXW11EXW/3G95aClG7nOTlC17+i32 vJF8GTnS/28yTu5/+gxluPPfsAHGXCNru5WbQ6Sy1bY7Lv1Lcpdd3f3UWAcLA4vB0784d1cu J9FCst6q0mtuk+0NLUeHv/eduLWWqvROA1n14sgkq6qqysvLi4qKHj16dPPmTaR6165dA9UD AABaAlrV6/mtNd1aC1ohuv79x9zSqvw7R4g1pn1kD/euC1k14sgkKysrnz17VlhYmJWVdePG jT///BNUDwAAaA8UqJ6yDTDdwXZrLXcPJk0aPoDLYjA5BiOmOKVmFHdV5F5h1YhDTVZUVJSV lRUUFOBLT//xxx8vonq9e0tcAAAA6CxoVY+Qw57dWqM523s0n+10nPbJrlW9TuUHAACAXodC 1QO8oigvLy8tLc3Pz8c3XPj999+vXr0KqgcAALQEoHrahmfPnpWUlOTl5d2/fx+t8s6dOweq BwAAtAegetqGsrKy4uLi3NzczMxMpHegegAAQKsAqqdtQJJXUFDw5MmTe/fugeoBAABtA+3E 1dtbbADdhfT09OtSoOT58+cviwGqBwAAtASgeoBrsIcTAABoDWgnrn2AVx0pKSl8Pj8kJMTP z2/16tWgegAAQEtAO3G924Z97Yx977aHtrKa1p7Os8nJKdHR0Zs2bVq3zm/VqlWao3qilpou jwkAdAg48bQHtBPXXgw0OaKnvQoArGa2RzU2OSkpOipq48aNa9euXblyZfepno6OjtvXD2U8 SvLPH26qKE6n2tZZkPHJC6ozmBz71+btv1dJX0DU9Hf/Beb6bGv7ie+fK6LNUnDOHcVxP1eg vMYuRBfGVBJKeS05RxMMmMzX/S6QOTtslXwG5UW6Y+gUnXgvgu4+aQHqgXbi2iPG7j3KAGxv 1dglbGJiYmRkZHBwsK+vr7u7e7eq3rKBo6/WCKke5fk75e8qUFUPG6KWxktfrzPst442/4Mv HCfs+kXQJLx/ehvXbC5tnq8m28zaNdNm8lfKa+xC9Mw0q7wWA4Zewk/ZLa2iFwnY83rx8r4d gM6CduLajbFL/Ni1S/yKnvHfbmA1rz2dZhMS4iPCwwODgny8vV3dXLtV9Z7denfggvepHhnj OWVRIA9dPRamCu/8vNDeYsQMz9u1Eg0tv/nf+W8M5rGYJjbDNn96mwx1dsdCCwd3ZLc0PPKf N47H4o6e7Zfd0CKfQXmrRC1VegxDZDhZ8E5WNCCjseIkr89yZMQONP6wsFZJx1uFJVY8izzB E1OedYmwFTub6zO9Z400MLAM/fIKtUblDSZWTww9PQZn4LhZn1woUeKkHaUOB0FRBmzUFZ2a PcLGoI998rFckrq/P8rOjKvHMEg4miMzjBi072+Hgy/vUd42ZFz4INjewkDf3C7uVF7hb3tH WhtSW4UyfL8raGx/E6pTPqaiE2+xBe9URSPKUFv0GfLszRMgu6H8BM98kSoDS7bzf7tWTA09 RNtTQM+DduLauXPXTgzpa/uUtrOa1h412K3xW7ds2RIQEODl5eXi4tKtqoeeD3kPC/s1n+p5 rnhWpBa/tGP2zKRz2D9i7SfPGhqzL+y1W3oEs25W+gknM5pbm2+kbWLyhpARvFJvVBcTE9Rx 9yG/ZJW2CAUXDu4Y7nlaPoOSBrQ0Cc7828t40CZk/+k7fE5qNjJyfpg3auMlZDjwmGm7fPoa c+3GLz5TXC/f8aKLXn3GfoSM90dbeF0qxs6fXAZ7p6Y3NpZ/ETCGWqPyBiN1c/om83lr4+3j iXi+VeSkHaUOB0FRBmx8PtXG8V+XSm99zDWdQ1KO/G/LG1qyf0pAaiLT8Q7fXyWDL+9R3jZk TAj5vKRW+Oi3WEPb9WuTD5TVNlNbhTK8FfNNeV27piqPiYFPvHNrhs4/8hglMz99i2vJnbiH +J/VowOzHFaeUWVgcczf97k7OO9reQ7QFNBOXDsIbN++fcd24pUwiReJY7vqLP4vE8mSSYmx XZph+/YA55n9zAwYDHafQXPUqxeHQokwP/fx9n0wu2WdG2ErLittUuf629lx0EA2Ni4uLDRs g7+/p+ca5xUrulv1WhofT7Od/qSx5XlnVK8y81P7GVubRRL/heomZIiay9mGr8nUImqt09XV JSM8bpTMMROM2PX4ozZRE8d4mnwG2gZgMNgGIyYv/iGbmL4qHkRavfElMr6eaL3jSTUyOHq6 M+NSq5qasn5P7jNul3zHD8ywnf8DsbjISZtvO+MAdk4yYueIFwVN1eepNSpvcOw0G7vlyT+e vvSM0mxaJ+0odTgIijJgY7QBi1w2ktSD+maZbLQjSeukHXx5qNI2ZNzEbWttQHZuI81iMKtB tqnKYz6nnHjlGZtsJn2LPP8abbHxlJ/pkN3I/nhsH/9bZaoMLLIvvr/GwNqjuqUTn/cCuhu0 E9c2KVK2KUOHLD57SQ81mdLew9bTRUZYfGJ8QvIL1kutRaYB8mVlMqhX7wuOUq+w/JiYzZs3 r1+/3sPDY/ny5d2tegj5v4YO80l7Tj8riuSdrU35TkPnZNS1TVkN+GNCUbOuHhc7hTWZ7ydF ejgvGu9gRTvZcsTnFYauHkc+g3w7aVlRi2CAsX19S+MIi/FC8QRmwWIUNrViisGyeN7+wz1R c2U/DqNNQDn9KsXirc/Qa8Lzn0ioeoOb6+4s+dt4Q6Yeg2PzX+nuGlon7Sh1OAjKMyBWElNu rGiHS8X3V1FA+dqVtA0ZrXRBaKtTMSb1xGttLrc2HiFsqR9oNEDQWGbOtShvrOrLMy0Sv/Ud DiyyX1+dMsrY+rz4vyIADQHtxJWckpKcnCx9SF+wMyVZdRafDyRLJmUMKpCTH7DCoZ8FG/1z ZnFt7Md6R8aTOT2Xzx9ma8Limrw+x33Voulm+iyesfVcz/CUFJpQ7cKmpCQlxb0zabghh8ni Gg2f5BiXmIScJNvZ/nZqHDSQjea3/Wxh6bJlPaB6CP+YP/C9W+XyM1Jzfaa88yuPcf+6U06N 81EOschqFZayjSZhZ4CDyar3vv/52KlbDx7STnRjDFi1ctsqlE+8tCzClxOsAo9sGeh4FCfd LPXxCggJHJNrL5O59Lq/+YhtZDJlhLn/9VJkTDXmZIpXScKadNUbjNEqrDyfFsg2el2Jk3aU OhwE5RkceMxM6cpOvqwqqkf7/ioKKONR3jZFLVGeQXlMmRPvg1EW2y/FWY7/DNk7BptuOLXB 1GGnKnGwjej7ny+2dz4o32tAb4F24kpMTEwi/ggk4ofYQzjFUJHFmkKy0qTESEyS84hz2nOZ yPYJjwn3fwcZHNM3yQzWk9yjNq/AttWbrlEblyKDyR2MCsrHTCKdYvhNt0X2KOfAYLfxyLCd 7idTb2f627lx0EA2KioqeOPGtb5rV7q7L3Fa0jOqJ6z5a/Sg5aSH2Ox3NKelofzbqOmk05Ch l1Vb8+RI0JiQczJx+gyNqW0WPjybOHTNSey0YTPSMkqaBAWfbJpCO9GlOQ068bC0VSS8eiDY eGCQfAb5dipSvSdHHRG19qpk38jlLeNmfnilRdSSdXZrv9my43Z43gDPs20/WMj/bfWAeYeR ccprqPNXlxubqvaHTVC9wUstePHHbja2iHKOtn05ReukHaUOB0F5ho8mWK34+kbZnc+5prPl yyoRLNr3t7Oqp7xt6qkebUxFJ17WN28bjzCe/R3xre6tXW9yLblTPshQpW1ttqjRzdb06zz4 PaCmgHbiSpAinnjEE6/xVJeqrA4dEqR+VFbWI4Y5Uw/ZBtZD5ji5hcdKIuIMQbFbExLisB0Q E5cQL7Z1GagyuVDxbU5xjEHiT5wCY7fGx4aKtXKITL2d6G8nx0ED2fCIiKDAQB8fbzdXt8WL F/eM6iE8/I8r6cn+idiFyDHpH/DPy6Rz+xwHFtfY0ZxLPWdwnKoHp+YPsp64MCyvSfK9yd39 yZMd+pj1H+6/9xfaia65LsN39hguk9lv1KxDj6ppmyTjVKR6TYIrTJYZuRuzVVgSvmySPpsz ZIrLX+0/vxK11AwzHyegfJWD1oMjzYbVII1sfOw/b4yRyeCwj8+r3uDSK59MG96XqadLbET8 KVuJk3aUOhwE5Rlq845MtTMzsHTYfiJPvqwSwaJ9fzuresrbpp7q0cZUdOI1lB9Dxs/iHbyC vD3I/ry4TpW2Ue3SawlWE7Yp6j6gh0E7cW3FiJc+x0vMdlCBxWcOyeJkmxEv5xEjYMlkI5Ye 9jDYptOWBrTLIC0VJ65XYcz2LAKz7TN4MXSZMvWq3t/OjoMGssQGzsAAL28vVxeXhQsXas61 WQAAAKBbQTtxxSLExcVixCGTAMWlKiuRJymLk8iUGlJPrNQjLRvDD/NwWTx5nB1y6jFNqGWp YePi2gqShi6F1SXDxsbasom13sboGGqbZepVtb+dHAcNZENDQ/03+Ht6ejo7Ozs6vgOqBwAA tAS0E1dMDJ8fQ4IvPqQ+fozqLNYUksVJfpufLzH4fNKD2NdNOche4LtxS/BKZDB5DtSylLBt MZFJ1mUq/oA0JDSSYkehzKsnWCJ72CKf0PXEFzRci0ky9Xayv50YBw1kxRs4/Tw8Vi9fvnzB /PmgegAAQEtAO3FF86Oj+XzpQaQI8KOlflVZrCkkK0mS/jZPm4HY8JA1Ywf35TD1dBksC1uH petDqWXJ4rheuZh8P6cpPKaegeUUxPo5TZbYRO6wt193MOKydBlsa7sxazaHy9Tbif52chw0 kN0UErLOb93qVauWLl06b/48UD0AAKAloJ24ogCvOsjrTi9ZsmTu3LmgegAAQEtAO3FFRERi iA1JQuqLBFYD29NZNigo2NfXx93d3cnJafacOaB6AABAS0A7cYVHRKCDBNVGKWA1sj2dY4OC gnx8fFzdiJ8tzJ49G1QPAABoCehVD/CqIzAw0Nvb29XVddGiRbNmzQLVAwAAWgJQPe0EqB4A ANBOgOppJ0D1AACAdgJUTzsBqgcAALQTtBPXNYCWAVQPAABoCUD1ANdA9boPIlFVZWV+bu6T nGwVj/y83MqKCpEI7kMKAHQLaCeufYBXHSkpKXw+PyQkxM/Pb/Xq1aB63QKRqLiw4N7dO6dP Hj908Nvv93/d4YGyocz3M+7W19X1dusBgFcTtBPXu23Y187Y9257aCurae3pPJucnBId3XZj WVC97gBa5d27e/vokbQH9zIK83KLCvKpRyE68vNkjoK8p/cy7hw7kpaX+6S1tbXjOgAAQCdB O3HtxUCTI3raqwDAamZ7VGOTk5KiKdclA9XrDuTnPiUWbvcySouLnpWV4qOc9nhWRj2yHtz/ /cz/WlqaO64DAAB0ErQT1x4xdu9RBmB7q8YuYRMTEyMjI4ODg319fd3d3UH1ugNPcrIPHfwW Ld9kRK3D4+njnN9On2puBtUDALoetBPXboxd4seuXeJX9Iz/dgOree3pNJuQEB8RHh4YFOTj 7e3q5tp9qldy6ZO/jerPYrAGjFvw42MBdtbmHZ4yzIbN5Nq/PufTa2VKnFUPDy+dONSAzR0y acmJvFrZ6KKmv/svMNdnW9tPfP9cEfbpqHy7ap2224V3TdUyQKr3/f6vC/PzOla6smI61ROq 2JGm6gsck2nKW1WRsUP1kQEAXmHQTlw7d+7aiSF9bZ/SdlbT2qMGK7mdekCAl5eXi4tL96ne fDPu+//LaGiq/fUfy40HbcTOIwsGuv7jZFVj/S+7Z9hM+kGJc5WNQdShK/VNdX9+7mMyOEQm +IMvHCfs+kXQJLx/ehvXbC52qqF6XVW1DJDq/ZB6kFzrFeVcO3b6wunUb1MP7P8rM1fizH54 68rvR7//Vlb1fjmpuuqV/LXKeuJB5a2KG20OqgcAPFcwce0gsH379h3biVfCJF4kju2qs/ju dZ0tKymlbr1RPgv7Wxgx9BhGFgMWr42WL7stIXTGa8NM9bl6enpsfSO7ERN8IhI6rJfKdnYc NJCNjYsLCw3b4O/v6bnGecWKHviEU9RSpccwxLZzH/2MOuLju8aqc/pWK5U42xVnmmGbnL1j Bxp/WCi7CkNs4Z2fF9pbjJjhebtWKFOkuT7Te9ZIAwPL0C+vkM6uqrqu6NTsETYGfeyTj+U+ l6pe7pPHWMtOHDqSV0p8hVf06Obhg/upMoeWhNRkfl7uqRNHZVSPrFpevM6vGz7t8/uKWvVc vNAzHx0HqgcAPFcwcW2TImWbMnTIYqXobFklpVSp14rNQMWDojagZwbbVr7s3H4GiFrhvyUp OSnEew6yWfrDX6RVLzhKvcLyJbdTX+/h4bF8+fIeUL2m6j8NbLyx3ZfNqG8lfo8maqlmsK2V ODFa6ssP711mO/PvMjEdeMy0XT59jbl24xefKa7HTvQ2jVj7ybOGxuwLe+2WHpEp8pPLYO/U 9MbG8i8CxpAq0FVVfz7VxvFfl0pvfcw1nfNcTvUOpf6sSOZkkgX5NKqnBFEDjPfmCRS16rl4 obc9owJUDwB4rmDiSk5JSU5Olj6kL9iZkqw6i5VCho0L9xpjZ81lotUYy9RqkKNnOHImxAaM GWDOMbR528mDLJWUtNVx0nBDDpPFNRoxaUFcEhEJs+tc3xnWz5RnYvX2yi0y9Y4zYqMMs7zn oWcmz0G+VRw9XUSNnbcyIbldm9vqTYxznDzCmMfWY7Ct7Mb4RMWTbMCaZSP7GXONrOaKm52U FPeOtIXDJznGJSYhJ8453c7cwHJqCk2Dwzo1ht3ERvPbfrawdNmyHlC99Henbfk1H9tsPV3p pvxWXT22EidCS1O+Zd8+DAY39occmZjorZwZl1rV1JT1e3KfcbuwE432heomZIiay9mGr8kU mWTEzmloeU6o8HlSBbqq6tEGLHJ1ifD0cc7RI2mk6qUeOKC66p08rqrqIaU245hVt4gUtQov 9J535rNfAOAVBu3ElZiYmET8EUjED7GHcIqhIosnfBl2ggln2srA+MSEiOCVhDBx7RDlPNgE 2SNXBLhMtMGlUAm/6bbIGLUiMNhtPDL6TvdDOTFrPXVV+PoFZHFqvTGh7iZMPWIFZ9hvRUC0 fKsmm3FxEH3rYct9NpMsWe/aqX2RMXrFhqigZcjgmE4k2cGT54UHLRHr6VBUStJCZ0kLbSkt fNNzc0QokkFJ0obS4E6NYTexUVFRwRs3rvVdu9LdfYnTku5WPcGT1LeD0sikNZshaCHXVn2V OEk8Oh7BMX5LxmnBYhQ2tYqLCBgsC+xEg9yANUzUrKvHlSmiz9Brwlc9EQlJFeiqqpHoNFB+ Y4f07tiRw7lPcuSlrUPVO/bjYRVVT5C3x3hAlJJW4YXec1A9AEAM2okrQYp44hFPvMZTXaqy eMKXZ0N83GZMfWOQtTFB6zKQx5JF6FRw7NatMYHSUvGDOOLPKmO3xseFifViSII0ZlBMXEI8 X2zqUSNv5W943c4M5zEbvRw5vNejAO1aFRPqMdicoyOFzbCJ66PiEtpaGz9AXO/G2HhqZMxu IWLFipvNRE7cwkDUwthQmRZuio2nFgyKjUvYGiNpcGfGsJvY8IiIoMBAHx9vN1fixrLdqnoN pVfWrIiuamm7xJaLpT5ejjVV/6nfx1mJk4SotZb8WpCEm6U+XluJmiuZXHvsREP8UU41MlqF pWyjSTJFphpzMuuJr/CENemkCnRV1Q48Jg6OgVXvcXYWreqVKVa94sIC1VXv/ufTRvhdUD4g VKgSEwB4hUE7cW3FiJc+x0vMdlCBxf/KZFjfuaOQ03z4RDffYJwBORnEh446MQQfI3HGb2Xq tv/nqsskY+J6yeIkZtjoE4uvhavHEJ9z6k5cQNTF4PaNjmvf5q1RLvOnWuozcQSuxRRqZFwv P65ds2nrVdLCGOk4kAXjt8o1+IVHWG2W2MAZGODl7eXq4rJw4cJu/OXCxX9NmRxYImx3mZHj 8wfMe++Xmsaan/fMGrDgiBKnozn3s4wS0fPW7PO7zEcnyAS/vGXczA+vtIhass5u7Tdb0ng0 wn2GxtQ2Cx+eTRy65qRMkVNeQ52/utzYVLU/bAIpAV1V9UcTrFZ8faPszudc09nPxap38thP pOqlHdx/91E+Mkpy01MPHCorU6h6JcVFSC5VVL2DE61X/VWipFUkQPIAgOcKJq5YhLi4WIw4 ZBKguFRl8SQvwxqJFW5TdEwMPwRnQKy1eAvKhig+P8pP4oyLtRU7N0bHUiOTbJzUprJsXSJ4 WExMqM8UUosGz/OjbXMMf8uyOW8QYqXLokbuJ17B+UfGKK8XuaUtjKGOA8niGslBoBbsqhFW mw0NDfXf4O/p6ens7Ozo+E73qd40k7ZlNTnrVmV9MHaghZ4ey2bo5LTcGiXOsmtfzhk9kMvi Dp/m9sezBuwk47QKS8KXTdJnc4ZMcflLvFjDbNWDU/MHWU9cGJbX1CJTpKXxsf+8MUYmg8M+ Pq+8PWpUXZt3ZKqdmYGlw/YTec/FqnfqxFFS9fLvXUw78E3qwYNHU7+7mVNI6h31IFXvh9SD Ku7hnGbMuSBtAG2r5CMAANoM2okLCRI/hgRffEh9/BjVWcmqpz3bV6wU89dt9nQcJsnA568Y SnyvN9zJ12VKX2kpvscES2QMW+gTut5Rh1iRTeK3xSTqpcSX1DHdkoc8c3w2bly7FCsgQv8x 03yCw8lWiZeBOm+5rIuKjg70JCLzrKZRI6+ZaEXUu9g3dP1CZHBMXlNQL381buGithaiVpAs v90g8NvszoxhN7HiDZx+Hh6rly9fvmD+fLg2S3dARvVUP2hVDwAAdAloJ65ofnQ0ny89iBQB frTUryqrIwfEblg6xZjD5BiYjp48kXRGhvuNGdCHxTGe6LiSdPKjQt9+3cGIy9IV76VcExpO xsT1kjZZb0SYz+tD+3FZDF0G09TafobjvPHDBhpyTSbNX0m2asvGVeMd+hty2UgUWVzDQSMn rt3y/+3deWxUxx0HcBbHt7lFOFSgUEIDqKZpUiA0KeWqWlwMLSEU+ANQqAimMSUBohCVpJcq hRIEKGoaNQKaw8GEIyoEahcwxuBr1xc2vvFtr9d73+s1bn/v9Nv1uRuv8fp9P367npnfzOy8 p6f56YFsH/SY+dDvfvL970SHhYwOCZs8c/7mva/3+rlv7hdXOIVWuI9W6LUqfiB3lYSQD9cw QNHXEhNf2fXK1i1b1q9fv+ana5D1AoGyXur1ryvLy3zNem2aVmQ9gADpceM6BCOd+Hun4+Pj V69ejawXCJT1bqRc8yPrcf/yiawHEAg9blwHDhzksAW+IrQdRHQYrsfXaELC3p07d2zevHnd unUrV61C1gsEv7MePeudT/oUWQ8gEHrcuN44cIAOkbRMNUSH5Xp8iyYkJOzYsWPTy8yPLaxc uRJZLxAa6+tu/TelpLjI16xXVVGeeu0q/tIQQCD0nPVgpNuzZ8/27ds3bdoUFxe3YsUKZL1A MOj1pSXF/770JWUxenyjdKZt06hbmsWjuamxsaFOPGprqmseVlWWl9IQquKvygIEArKePCHr DYHOzk67zUZPfKnXr55P+vTcZ/+6kJx06fwXdFy+kHzlq4vckfL1lZRrV+m48Z9raTdS6aAh eNADCBBkPXlC1hsy9MhGKcztbh/gQZ3xlAcQOMh68oSsBwDy1OPGpQSZ4VIesh4AjHg9blxO kBk/Ul5vNw8AwHDW48Z1BuRnsG4eAIDhDBsX+A03DwAEHWxc4DfcPAAQdLBxgd9w8wBA0MHG BX7DzQMAQQcbF/gNNw8ABB1sXOA33DwAEHSwcYHfcPMAQNDBxgV+w80DAEEHP6UOHKfTOSg3 DwDAcIbfSAZO/EYyAJAN/PZpmVOpVAUFBf4lPmQ9AAg62LjkprOz0+12W63W1tbWqqqq/Pz8 kpIS8YnPp6lw8wBA0Ol14+rs5N+Z4398hWsMQHRoPiXYo/7N41V99OhRe3u7xWJRq9WVlZV5 eXnFxcXIegAgEz1uXJ1duM2yN4MYHZpPGQFRv+fhqx0dHS6Xy2w2t7S0VFRUfMOsh8QHAEGk t12rk54HmNcj2iTpxRe4Jr4+2NGh+ZTgj/oxj1d1ELNeH7cQAMBw08d+RRtjxyNvHfT1qIN9 BSI6NJ8S7FF/5vGqut1uSnAmk6m5ubm8vFylUt2/f9/vrCfeSDhw4MAx/I/e9rEOL27vhoBE h+ZTRkbU73ncHe3t7Q6Hw2g0NjU1UdZTKpVFRUXfJOsBAAS7DnoeYF7Cu0QH19bhHiVQKBSh ETHzFsd/VW0Qo32P7THavSc3v6/ziNGaq0d/OHdqaEjo1LlLjqfUdx/Lz+/7zL5GS298smX5 U4Mysz9r8Ky6XC673W4wGBobG8vKynJzc5H1AEDm2t1ueiJwswf3YhuEKlvhUgZVXS5nVdof qDx21m4x2vfY7tEee/JZyZd5pNEF0aE0PKcug97DYp7pPpY/Bd9n9jUqXKtBmNmPNXhVKbvZ bDa9Xt/Q0FBaWpqTk4OsBwAy53K1t7voi94Z7eIX98ZGuZ2cizodOiqHhE6iitNh+NurcVPG RkSOm/aLV9/T25keLs9GnYNp42a4+fmxuOdmTpyx4O1zldRq02a/tGTOmCmLDn9wmU8WlFYd es/hTpewgFufHVvLDj+cXOG1wi3TYqjDket/pveICau9oi4xGXmdncN06rWN0ydGRY6bviHx pNXJNNoN+Vt/9NTYJ2PfOpksrsrlMEp6nrKwl6orKpygVL9XtZ/owHtKol5Vh8NhtVq5rPfg wYPs7OzCwkJkPQCQMxdlFebF7ITsu4v97uJauZeQ9SjqKL56iMqL91ykSPrBZ6n8q7PKgqSt VPjBwQwaKzSqCpO2sY13aBg3Q+y+i7V3j1IhfPyPqefZVd+i8i/PKD/ZHct1oJ788DPi8Axa gzD8Qu2997jhXivUVpybEf4EhaKmLj6d0+IVFU/B6+wyjzxPjXEfZWV9tJYKy45kUfSLuJnM qs6qTm2cI64q852lbM/sbK7nO1niqrjrxl8ioXEgV7W/6MB7dkW9qna73WKx6HS6+vr6kpIS ynrc72ZB1gMA2eL2QIdT/O4Qag6x1espZlLsxtRSDUVfGBdO1QKD1W6uYR+y1tAorrFQL23k Zyg0WBx25lFRoQilnvOjmH+WvK+np5F8MYPwww0Wfvh46XCrw64Vhnet0NKWs2M5n6Fmbzrt dJhT7xUa7HbpWQnze5wd91m5eqtFp2Q/azm1x8aEces3a9K8VqXUWyQ9xTmZ2cSypLGfq9p3 dOA9PaMeVZvNZjabtVptXV1dcXFxVlZWfn4+sh4AyJndwbHzBaHOtNj5Rm4nZ5qsptzzv6Vy 5MQ4CkaOVkizoSIkkvp0b7QLM3jNFs72NNpoJpPYoY/hNs/h4grfXjSJWjaeuPLraTEKxei9 7780inkefEZrtYlnx4/yPLsw9rMMtACbngqjQ6LEVVHStrGN3KqEng6H0NPzpGziqqRn2vdV 7T868J4e0a4qPegZjUaNRlNTU1NUVHTv3j1kPQCQOWbLZ3dQG//dzteEb3TwOznXYm1jt/0x VH5uDPNYVGGwSMdKGrtmlszQVeaeqvJ1ZmNbFp/X7DZxuHQNYtTetZiuaEzIaGppMFvq0vaL 6XL10Rxx/XbPUxDHLhvLPutpaQHZo5gnuFXiqlRas6H1lvi5Yk+T0JOm4PKj1mo1a/PEVYUo FOyQ/q9qv9GB97RJWqRVetAzGAytra0PHz4sLCy8e/duXl4esh4AyJltAPjNn2EtTfk9lcfN 3UeV67sXUjn+wzv1ypNUGD8vsbdGyQxd5c/XzqLC+n9mfrn/WbFx4MNFby2cSC1/Ta+uzDzD ZUDy/NY308s1PZ1Cl9S936PGtf/IzPzw51R48U9Z1Hhu/bepvOF07t+3zRvF/rBGbz1/NiGS ysdz65ITFojzz45g/nvxYaN+IBc20Ewmk16vV6vV1dXVlPUyMjJUKhWyHgDImc1qs1rpRXuk lcV858o2tp0K4gOUQjE6PDJm/tL4yxWtTMCk/uOutdPHRYWERceu2HqjQcc0mluExhhqvEmN Nn4GbmaxbGrL27bs6eixMxJPXBGyhtViapHOebNBS2sQo+JipCvUN2fsilsyITosJCxy9qJV 7554f2f8i1PHz0o8fkU8u1HdcOv/y2/ip4+PihgzbUPiKXo8ZVeV+/KS2TGTF75x7Bx1Cwmb zK1K2tNoYeYsSz48d1L0pDkvfJxWLK5K9fH+iRGhTy58vd+r2nd04D2lUa+q0WjU6XQtLS1V VVUFBQWU9ZRKJbIeAMiZxcLtkFYLy0pf1GIRmwY/OjSf4neUHtY2Hb9crzE03L/EPNXOPvi4 VuXHPF5Vg8Gg1Wqbm5srKyvz8/Pv3LmDrAcAMmeRMHcrBCI6NJ/id/R+0ruLvzsjIjTkifDo p5euSy5RP8ZV+TGPtKrX69va2pqamrhfPZ2eno6sBwAyZya0SZotZvZl4b4LLYGIDs2njIyo z/N4VpH1AAC8mGHk0ul0Go2msbGR+4MLt2/fzs3NRdYDADl73BszBJBWq21tbW1oaCgrK6On vLS0NGQ9AJC5x70xQwC1tbWp1er6+vrS0lLKd8h6AACPe2OGAKKU19TUVFtb++DBA2Q9AACi hBEqLy9PJaBqRkZGFotLech6ACBPTpAZpDwAkLMzID+P+6YDAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAIAv8HGxtObgplbmRzdHJlYW0KZW5kb2JqCjEwIDAgb2JqCiAgIDQ3 NTU0CmVuZG9iagoxIDAgb2JqCjw8IC9UeXBlIC9QYWdlcwogICAvS2lkcyBbIDYgMCBSIF0K ICAgL0NvdW50IDEKPj4KZW5kb2JqCjExIDAgb2JqCjw8IC9DcmVhdG9yIChjYWlybyAxLjEy LjIgKGh0dHA6Ly9jYWlyb2dyYXBoaWNzLm9yZykpCiAgIC9Qcm9kdWNlciAoY2Fpcm8gMS4x Mi4yIChodHRwOi8vY2Fpcm9ncmFwaGljcy5vcmcpKQo+PgplbmRvYmoKMTIgMCBvYmoKPDwg L1R5cGUgL0NhdGFsb2cKICAgL1BhZ2VzIDEgMCBSCj4+CmVuZG9iagp4cmVmCjAgMTMKMDAw MDAwMDAwMCA2NTUzNSBmIAowMDAwMDQ4NjY1IDAwMDAwIG4gCjAwMDAwMDAxNDEgMDAwMDAg biAKMDAwMDAwMDAxNSAwMDAwMCBuIAowMDAwMDAwMTIwIDAwMDAwIG4gCjAwMDAwMDA0NTUg MDAwMDAgbiAKMDAwMDAwMDI0MSAwMDAwMCBuIAowMDAwMDAwNzcyIDAwMDAwIG4gCjAwMDAw MDA3NTEgMDAwMDAgbiAKMDAwMDAwMDg3MiAwMDAwMCBuIAowMDAwMDQ4NjQwIDAwMDAwIG4g CjAwMDAwNDg3MzAgMDAwMDAgbiAKMDAwMDA0ODg1OCAwMDAwMCBuIAp0cmFpbGVyCjw8IC9T aXplIDEzCiAgIC9Sb290IDEyIDAgUgogICAvSW5mbyAxMSAwIFIKPj4Kc3RhcnR4cmVmCjQ4 OTExCiUlRU9GCg== --HcAYCG3uE/tztfnV-- --98e8jtXdkpgskNou Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJRVxwrAAoJEERuJUU10FbsvyYIAIJmPkB6DRr29Muw+8vXrOIS ZJ8Od0hO3EnBZFuGXphSJ7HAUSStL7fuSIJTGuBWafW+xwQv6Fch4jFwEurMXzi+ dxzSVb55a39kpxljGJRHlX2/mNamxMIur3aWr58WoQMN5japegccnIhljOseJ+zL 0dZlmji7K+qcpDJGwkFo3EYc3KQ5rcNUSJedDOSl01wbiD1LXNcOKQc4rR4SCnz7 mOxRy9po0xdI0kKD4/D11UDrKNt9UM5nNDaREh7L+Re0q8AJ6ASZI8B94vACI28R /B3ICqxTcZYkY4L9sdsi9wmHdYvH71g4L8C2Kzglz/BZVtjmSbyXq4cItOk8lFY= =lsTb -----END PGP SIGNATURE----- --98e8jtXdkpgskNou-- From pkern@spike.0x539.de Sat Mar 30 04:05:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AB621F8606 for ; Sat, 30 Mar 2013 04:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QYlJYKkDH4C for ; Sat, 30 Mar 2013 04:05:54 -0700 (PDT) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A5321F85F3 for ; Sat, 30 Mar 2013 04:05:53 -0700 (PDT) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1ULtbU-0002Rq-Ti; Sat, 30 Mar 2013 12:05:44 +0100 Received: from p2003006b0d036c01c5058db06ec2bf0b.dip.t-dialin.net ([2003:6b:d03:6c01:c505:8db0:6ec2:bf0b] helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ULtbW-0003x9-65; Sat, 30 Mar 2013 12:05:46 +0100 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1ULtbV-00085M-PD; Sat, 30 Mar 2013 12:05:45 +0100 Date: Sat, 30 Mar 2013 12:05:45 +0100 From: Philipp Kern To: Owen DeLong Message-ID: <20130330110545.GA29987@spike.0x539.de> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <20130327163318.GA10704@spike.0x539.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline In-Reply-To: Organization: The Debian Project (http://www.debian.org) X-Debbugs-No-Ack: yes User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sat, 30 Mar 2013 10:16:33 -0700 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 11:05:54 -0000 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 29, 2013 at 01:06:33PM -0700, Owen DeLong wrote: > DUIDs vs MAC comes up frequently too. Usually that's settled pretty quick= ly by > explaining the history of Ethernet Cards and wanting an address that surv= ived > replacement of the card. True. But it so utterly fails in multiboot and initially installation / provisioning scenarios that it isn't funny. So what should an installer do? Ubuntu did DUID-LL, but that's not really allowed in terms of the RFC. Maybe one should pass a fixed DUID in using PXE. People want the same address for the machine regardless which OS runs. If machines shipped with an NVRAM to use for it=E2=80=A6 Maybe UEFI will solve= everything for us, but so far it did not, especially not across OS vendors. Kind regards Philipp Kern --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJRVscJAAoJEERuJUU10FbsXxgH/1uhhZC6F2qEedumhLbxdEUC c1e9vIGxnZ6KKafsByMCE50EpzcrCiqbKg79KxmThC2jGvIdcm9NU3EkbvuAH1lh DBhyrg82VACOK2jCern/wnOmRJIHyVMIBVK8SkkzbVHJFtRd9V3FItY776Z8jgAL JcP/D9IcHysYxeAaH2V7sHD6udVaUlBWMHhIKMwbUugqjUdkncJpEtR7eT7Z/QUH BEN0K1EH3tqMIktMIuY0bEY8BYpWfTVsNI0slhGN/Rqo7UvTlUlWRMWgAhJn+3GK 0jV85VoA9LQY05bp8usAmRew/kKVwg9ckKp7S8LIlXqB7hqZ+MpopByC82Is/2c= =9i0M -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- From alexandru.petrescu@gmail.com Sat Mar 30 11:28:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9A921F875D for ; Sat, 30 Mar 2013 11:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.056 X-Spam-Level: * X-Spam-Status: No, score=1.056 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_13=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.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 4I+46-Oxg5wO for ; Sat, 30 Mar 2013 11:28:55 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id D1E2421F875C for ; Sat, 30 Mar 2013 11:28:53 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 419299401A8 for ; Sat, 30 Mar 2013 19:28:47 +0100 (CET) Message-ID: <51572EDB.1080208@gmail.com> Date: Sat, 30 Mar 2013 19:28:43 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: v6ops@ietf.org References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <51425EB5.6040703@dougbarton.us> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <1363805194.86628.YahooMailNeo@web142505.mail.bf1.yahoo.com> <20130320185148.GA26639@spike.0x539.de> <20130330170859.GA25715@spike.0x539.de> In-Reply-To: <20130330170859.GA25715@spike.0x539.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130330-0, 30/03/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 18:28:56 -0000 Le 30/03/2013 18:08, Philipp Kern a écrit : > On Wed, Mar 20, 2013 at 07:51:48PM +0100, Philipp Kern wrote: >> On Wed, Mar 20, 2013 at 11:46:34AM -0700, Mark Smith wrote: >>> The Fritzbox CPE a few years back made a failed attempt at using >>> ULAs. They did exactly that i.e. no random ID, and attempted to >>> *swap* the ULA for the GUA when the GUA disappeared due to the >>> WAN link going down and vice versa. >> I need to check it again but that's exactly what a DTAG CPE >> (Speedport) in Germany does. You can turn on ULAs through the web >> interface and don't even get to pick the bits. My personal guess is >> that DTAG fixed it on all but I don't have multiple devices to >> test. > > Ok, the device does not actually revoke the ULA but keeps it. The > remaining bit is still true: you don't get to pick your ULA, not even > the subnet bits. In case somebody wonders about this a screenshot (in > German) is attached. (yes, the screenshot shows a web interface of Speedport W 723V, with logo pink T-mobile. Among various Netzwerk parameters one can see: IPv6 ULA local verwenden (use): [unchecked] Lokale IPv6-Adresse (ULA): fd46:8713:d5b8:0001::1') By the suggested example algorithm in RFC4193, the overall length of the 'random' part should be 48, which seems to be the case with the example above.) > Maybe they hash the MAC or something, a Google search of the ULA > prefix does not turn up anything. They even revoke the ULA prefix > correctly when the flag is unset in the web interface. So maybe I > should give them the benefit of the doubt that the ULA is somewhat > random… Simply curious: when you say revoke, is it that it disappears from the web interface? Or that DHCPv6 revoke message is sent? Thanks for the example use. Alex > > Kind regards Philipp Kern > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From Ted.Lemon@nominum.com Sat Mar 30 12:13:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC0221F874E for ; Sat, 30 Mar 2013 12:13:55 -0700 (PDT) X-Quarantine-ID: X-Amavis-Modified: Mail body modified (defanged) by ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper use of control character (char 0D hex): References: ...wtou7x6.wl%randy@psg.com>\r <2013032716331[...] 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LITR-oatrq3k for ; Sat, 30 Mar 2013 12:13:54 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1364670835-18023-0" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id BFD5621F86BC for ; Sat, 30 Mar 2013 12:13:54 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUVc5cuGCfwCaLWBj6AvZp2rAjyCNx6UD@postini.com; Sat, 30 Mar 2013 12:13:54 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 44E5F108280 for ; Sat, 30 Mar 2013 12:13:54 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 34FB119005C; Sat, 30 Mar 2013 12:13:54 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Sat, 30 Mar 2013 12:13:48 -0700 From: Ted Lemon To: Philipp Kern Date: Sat, 30 Mar 2013 19:13:47 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775127F3E@mbx-01.win.nominum.com> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> \015 <20130327163318.GA10704@spike.0x539.de> <20130330110545.GA29987@spike.0x539.de> In-Reply-To: <20130330110545.GA29987@spike.0x539.de> Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 19:13:55 -0000 This is a multi-part message in MIME format... ------------=_1364670835-18023-0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: bad headers - Improper use of control character (char 0D hex): References: ...wtou7x6.wl%randy@psg.com>\r <2013032716331[...] ------------=_1364670835-18023-0 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Return-Path: Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id BFD5621F86BC for ; Sat, 30 Mar 2013 12:13:54 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUVc5cuGCfwCaLWBj6AvZp2rAjyCNx6UD@postini.com; Sat, 30 Mar 2013 12:13:54 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 44E5F108280 for ; Sat, 30 Mar 2013 12:13:54 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 34FB119005C; Sat, 30 Mar 2013 12:13:54 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Sat, 30 Mar 2013 12:13:48 -0700 From: Ted Lemon To: Philipp Kern CC: Owen DeLong , "v6ops@ietf.org" Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? Thread-Topic: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client? Thread-Index: AQHOLWpahvi1M2OnDUiO+PVte2eG8Zi/D+yA Date: Sat, 30 Mar 2013 19:13:47 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775127F3E@mbx-01.win.nominum.com> References: <5151C83B.1010203@gmail.com> <5152B0C9.8010906@gmail.com> <20130327163318.GA10704@spike.0x539.de> <20130330110545.GA29987@spike.0x539.de> In-Reply-To: <20130330110545.GA29987@spike.0x539.de> 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 On Mar 30, 2013, at 7:05 AM, Philipp Kern wrote: > True. But it so utterly fails in multiboot and initially installation / > provisioning scenarios that it isn't funny. So what should an installer d= o? > Ubuntu did DUID-LL, but that's not really allowed in terms of the RFC. Ma= ybe > one should pass a fixed DUID in using PXE. We're hoping that this will finally put the problem to bed: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-ad= dr-opt/ Should be an RFC soon. Put it in your RFPs and RFQs as a requirement. ------------=_1364670835-18023-0-- From owen@delong.com Sat Mar 30 12:16:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A1521F86BA for ; Sat, 30 Mar 2013 12:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edkWab2gn1dm for ; Sat, 30 Mar 2013 12:16:15 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 869D421F867D for ; Sat, 30 Mar 2013 12:16:14 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2UJF3r3005495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 30 Mar 2013 12:15:04 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2UJF3r3005495 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364670904; bh=BJ/JJBy7QQwbjv/2OUMqoiG6BR4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=KdK1mr3fbKBUX31nw9Bui05yO9LHm46JcM1UgKKxIJbCm4F005AfmEHpOlak6OutA UdZkjfwVzyYPyJjV5vvOmCCJpyl8P3eHeP8l+GtjTBWn9u2fc9QEPPw4NUYWUWfyR8 VSbbebD93fojIjstBNMICmVlv/YEFy/GE0yvOFIM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <20130330170859.GA25715@spike.0x539.de> Date: Sat, 30 Mar 2013 12:13:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7A6025B7-A7BA-47F4-9AF5-213B32151849@delong.com> References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <51425EB5.6040703@dougbarton.us> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <1363805194.86628.YahooMailNeo@web142505.mail.bf1.yahoo.com> <20130320185148.GA26639@spike.0x539.de> <20130330170859.GA25715@spike.0x539.de> To: Philipp Kern X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 30 Mar 2013 12:15:04 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 19:16:16 -0000 > Ok, the device does not actually revoke the ULA but keeps it. The = remaining bit > is still true: you don't get to pick your ULA, not even the subnet = bits. In The screen shot looks like you DO get to pick the subnet bits in that = there's a greyed out fill-in field. I suspect that when you click the ULA = checkbox, that field gets un-greyed and you can put any 16 bit value you want into the subnet field. Am I misreading the screen shot? Owen From alexandru.petrescu@gmail.com Sat Mar 30 12:17:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB9721F875C for ; Sat, 30 Mar 2013 12:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.18 X-Spam-Level: X-Spam-Status: No, score=-0.18 tagged_above=-999 required=5 tests=[AWL=1.086, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.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 8gB6AEPOMoPT for ; Sat, 30 Mar 2013 12:17:25 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id CA24021F86CD for ; Sat, 30 Mar 2013 12:17:23 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id AFC799400A8; Sat, 30 Mar 2013 20:17:15 +0100 (CET) Message-ID: <51573A36.7070407@gmail.com> Date: Sat, 30 Mar 2013 20:17:10 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: joel jaeggli References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6ECA24@nkgeml506-mbx.china.huawei.com> <731D2903-56BD-4A4D-9D86-EC1C3CF9D5E1@delong.com> <5155DCEE.2020909@gmail.com> <5155E4FE.8060707@bogus.com> In-Reply-To: <5155E4FE.8060707@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130330-0, 30/03/2013), Outbound message X-Antivirus-Status: Clean Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 19:17:26 -0000 Joël, Thanks for the message. Reply below. Le 29/03/2013 20:01, joel jaeggli a écrit : > On 3/29/13 11:26 AM, Alexandru Petrescu wrote: >> Le 29/03/2013 18:58, Owen DeLong a écrit : >> [...] >>>>>>> - if you want to set up a small network which has multiple >>>>>>> subnets, and you can't get IPv6 global unicast addresses from >>>>>>> an authority or an authoritative sysadmin (prefixed by 001 >>>>>>> first three bits), like a Provider Independepent, or Provider >>>>>>> Assigned addresses - then use ULAs to configure your small >>>>>>> network. >>>>> >>>>> Why would you be unable to get such address space? To the best of >>>>> my knowledge, all of the RIRs have provisions for granting >>>>> addresses to non-connected networks. >>>> >>>> [Bing] I guess Alex was talking about some situations lack of >>>> money/conditions to apply address space from RIRs/LIRs. >>> >>> The RIR policies have been rather stingy in the IPv4 world, but to >>> the best of my knowledge, each of the RIRs has pretty liberal >>> policies WRT getting IPv6 addresses. The monetary issue is a separate >>> problem and is really outside of the scope of IETF. >> >> I checked some RIR conditions about allocating PI space. >> >> Other than the price tag (I don't know) there is a set of other >> administrative and technical requirements which make me doubt about its >> adaptation to vehicular traits like mobility. >> >> - RIR says only a maximum of /48 prefix can be allocated as PI, to end >> user. I am not sure one /48 is enough for a vehicle manufacturer, >> because it would give only 2^16 /64 prefixes. This is way too little >> for the number of vehicles manufactured by one manufacturer in 10 >> years time. >> > Entirely aside the issue of whether you want to number cars out of pi or > not, this is also nonsense. > > You can see the arin direct assignment policy here: > > https://www.arin.net/policy/nrpm.html#six58 Ok, that seems to say "Provider independent (portable) addresses issued directly from ARIN or other Regional Registries are not guaranteed to be globally routable." I suppose it would be hardly acceptable to put PI space in a vehicle and suppose that Internet-at-wide not to be reachable. If by that statement ARIN means that a communication flow issued out of a vehicle may need to first get through some 'upstream provider' or 'provider's provider', then this may pose challenges to straight vehicle-to-vehicle communications as well. > My company with 11 current locations 5 of which were at time of request > datacenters received a /44 under the ARIN policy... Ok, this is good to know. > let's look elsewhere... (maybe you should ask these folks to come to the > meeting in berlin, (they're not that far away) and talk about their > assignment experience). Yes, I would like to ask them to come to IETF Berlin and present their assignment experience: is that /29 for offices or for vehicles, or both, prefixlen inside a vehicle, etc. This invitation may not be that simple to do, and I need help for that. (in which WG to present, should they write first a draft, etc.) These are problems I face daily with other parties which may be interested, if. > joels-MacBook-Air:~ jjaeggli$ whois -h whois.ripe.net 2a01:4dc0::/29 > % This is the RIPE Database query service. [...] > % Information related to '2a01:4dc0::/29' > > inet6num: 2a01:4dc0::/29 > netname: DE-VOLKSWAGENAG-20120530 > descr: Volkswagen AG > country: DE > org: ORG-VA303-RIPE > admin-c: VWAG1-RIPE > tech-c: VWAG1-RIPE > status: ALLOCATED-BY-RIR > mnt-by: RIPE-NCC-HM-MNT > mnt-lower: AB82394-MNT > mnt-routes: AB82394-MNT > source: RIPE # Filtered [...] Alex From pkern@spike.0x539.de Sat Mar 30 13:05:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0BA221F856D for ; Sat, 30 Mar 2013 13:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t05GBRDMJwFQ for ; Sat, 30 Mar 2013 13:05:02 -0700 (PDT) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id 475F021F855A for ; Sat, 30 Mar 2013 13:05:02 -0700 (PDT) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UM21L-0001bS-Hu for v6ops@ietf.org; Sat, 30 Mar 2013 21:04:59 +0100 Received: from p2003006b0d036c01c5058db06ec2bf0b.dip.t-dialin.net ([2003:6b:d03:6c01:c505:8db0:6ec2:bf0b] helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1UM21M-0005ce-QJ for v6ops@ietf.org; Sat, 30 Mar 2013 21:05:00 +0100 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1UM21M-0001ri-Hf for v6ops@ietf.org; Sat, 30 Mar 2013 21:05:00 +0100 Date: Sat, 30 Mar 2013 21:05:00 +0100 From: Philipp Kern To: "v6ops@ietf.org" Message-ID: <20130330200500.GA7020@spike.0x539.de> References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <51425EB5.6040703@dougbarton.us> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <1363805194.86628.YahooMailNeo@web142505.mail.bf1.yahoo.com> <20130320185148.GA26639@spike.0x539.de> <20130330170859.GA25715@spike.0x539.de> <7A6025B7-A7BA-47F4-9AF5-213B32151849@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7A6025B7-A7BA-47F4-9AF5-213B32151849@delong.com> Organization: SCC-NET, SCC, KIT User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 20:05:03 -0000 Owen, am Sat, Mar 30, 2013 at 12:13:52PM -0700 hast du folgendes geschrieben: > > Ok, the device does not actually revoke the ULA but keeps it. The remaining bit > > is still true: you don't get to pick your ULA, not even the subnet bits. In > The screen shot looks like you DO get to pick the subnet bits in that there's > a greyed out fill-in field. I suspect that when you click the ULA checkbox, that > field gets un-greyed and you can put any 16 bit value you want into the > subnet field. > > Am I misreading the screen shot? sadly so. They both don't activate if you hit any checkboxes (i.e. they are still greyed out). Just as the "Firewall" "option" is always ticked on (and it doesn't seem to have any actual option behind it), causing all incoming IPv6 traffic to be dropped. Kind regards Philipp Kern From joelja@bogus.com Sat Mar 30 13:24:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84D721F8606 for ; Sat, 30 Mar 2013 13:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 tuvhXhJ1J6QC for ; Sat, 30 Mar 2013 13:24:59 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id DFC8B21F85F5 for ; Sat, 30 Mar 2013 13:24:58 -0700 (PDT) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r2UKOsVR025973 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 30 Mar 2013 20:24:54 GMT (envelope-from joelja@bogus.com) Message-ID: <51574A11.9050402@bogus.com> Date: Sat, 30 Mar 2013 13:24:49 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Thunderbird/20.0 MIME-Version: 1.0 To: Alexandru Petrescu References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6ECA24@nkgeml506-mbx.china.huawei.com> <731D2903-56BD-4A4D-9D86-EC1C3CF9D5E1@delong.com> <5155DCEE.2020909@gmail.com> <5155E4FE.8060707@bogus.com> <51573A36.7070407@gmail.com> In-Reply-To: <51573A36.7070407@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 30 Mar 2013 20:24:55 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 20:25:00 -0000 On 3/30/13 12:17 PM, Alexandru Petrescu wrote: > Joël, > > Thanks for the message. Reply below. > > Le 29/03/2013 20:01, joel jaeggli a écrit : >> On 3/29/13 11:26 AM, Alexandru Petrescu wrote: >>> Le 29/03/2013 18:58, Owen DeLong a écrit : >>> [...] >>>>>>>> - if you want to set up a small network which has multiple >>>>>>>> subnets, and you can't get IPv6 global unicast addresses from >>>>>>>> an authority or an authoritative sysadmin (prefixed by 001 >>>>>>>> first three bits), like a Provider Independepent, or Provider >>>>>>>> Assigned addresses - then use ULAs to configure your small >>>>>>>> network. >>>>>> >>>>>> Why would you be unable to get such address space? To the best of >>>>>> my knowledge, all of the RIRs have provisions for granting >>>>>> addresses to non-connected networks. >>>>> >>>>> [Bing] I guess Alex was talking about some situations lack of >>>>> money/conditions to apply address space from RIRs/LIRs. >>>> >>>> The RIR policies have been rather stingy in the IPv4 world, but to >>>> the best of my knowledge, each of the RIRs has pretty liberal >>>> policies WRT getting IPv6 addresses. The monetary issue is a separate >>>> problem and is really outside of the scope of IETF. >>> >>> I checked some RIR conditions about allocating PI space. >>> >>> Other than the price tag (I don't know) there is a set of other >>> administrative and technical requirements which make me doubt about its >>> adaptation to vehicular traits like mobility. >>> >>> - RIR says only a maximum of /48 prefix can be allocated as PI, to end >>> user. I am not sure one /48 is enough for a vehicle manufacturer, >>> because it would give only 2^16 /64 prefixes. This is way too little >>> for the number of vehicles manufactured by one manufacturer in 10 >>> years time. >>> >> Entirely aside the issue of whether you want to number cars out of pi or >> not, this is also nonsense. >> >> You can see the arin direct assignment policy here: >> >> https://www.arin.net/policy/nrpm.html#six58 > > Ok, that seems to say > "Provider independent (portable) addresses issued directly from ARIN > or other Regional Registries are not guaranteed to be globally routable." > It says that for ipv4 as well... address assignment by an rir is not a license to route, nor is it an assurance that network operators will accept your prefix. > I suppose it would be hardly acceptable to put PI space in a vehicle > and suppose that Internet-at-wide not to be reachable. If you advertise a route longer than a /48 today the chances of it being accepted globally on the internet today are about zero. > If by that statement ARIN means that a communication flow issued out > of a vehicle may need to first get through some 'upstream > provider' or 'provider's provider', then this may pose challenges to > straight vehicle-to-vehicle communications as well. RIRs are not involved in the topology consideration, they assign addresses, and provide attestations about the validity of things. Locally signficant routing and adjacency decisions are clearly relevant locally. You have (imho) a set of separable problems, machine to machine communication vs internet connectivity) and they can be solved in all likelihood without boiling an ocean. Today, cars with internet connectivity receive addressing from a service provider, sometimes more than one, I don't see any reason to expect that model is unworkable in the future, wether they do that becasue of a relationship between the manufacturer and the service provider (as is frequently the case) the consumer and the service provider, or some device to which they are tethered doesn't seem particularly relevant. Using more than one address range, e.g. a provider assigned one, and a locally significant one doesn't seem particularly daunting either. >> My company with 11 current locations 5 of which were at time of request >> datacenters received a /44 under the ARIN policy... > > Ok, this is good to know. > >> let's look elsewhere... (maybe you should ask these folks to come to the >> meeting in berlin, (they're not that far away) and talk about their >> assignment experience). > > Yes, I would like to ask them to come to IETF Berlin and present > their assignment experience: is that /29 for offices or for vehicles, > or both, prefixlen inside a vehicle, etc. > volkswagen ag is clearly an LIR in the scope of it's ripe prefix assignment... I have no particular insight into how they use that prefix. A rather small portion of it appears into the ipv6 routing table. It has generally been my experience that enterprises that need address space are able to work within the system as it exists now to secure the resources that they need. Clearly that is getting harder with IPv4. I don't see much evidence for that's a problem in IPv6. > This invitation may not be that simple to do, and I need help for that. > (in which WG to present, should they write first a draft, etc.) These > are problems I face daily with other parties which may be interested, if. > >> joels-MacBook-Air:~ jjaeggli$ whois -h whois.ripe.net 2a01:4dc0::/29 >> % This is the RIPE Database query service. > [...] >> % Information related to '2a01:4dc0::/29' >> >> inet6num: 2a01:4dc0::/29 >> netname: DE-VOLKSWAGENAG-20120530 >> descr: Volkswagen AG >> country: DE >> org: ORG-VA303-RIPE >> admin-c: VWAG1-RIPE >> tech-c: VWAG1-RIPE >> status: ALLOCATED-BY-RIR >> mnt-by: RIPE-NCC-HM-MNT >> mnt-lower: AB82394-MNT >> mnt-routes: AB82394-MNT >> source: RIPE # Filtered > > [...] > > Alex > From pkern@spike.0x539.de Sat Mar 30 13:48:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242E521F86AF for ; Sat, 30 Mar 2013 13:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 tyJmWixyHJfv for ; Sat, 30 Mar 2013 13:48:29 -0700 (PDT) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id 8878B21F86AE for ; Sat, 30 Mar 2013 13:48:29 -0700 (PDT) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UM2hP-00028C-0Y for v6ops@ietf.org; Sat, 30 Mar 2013 21:48:27 +0100 Received: from p2003006b0d036c01c5058db06ec2bf0b.dip.t-dialin.net ([2003:6b:d03:6c01:c505:8db0:6ec2:bf0b] helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1UM2hQ-0005ik-AJ for v6ops@ietf.org; Sat, 30 Mar 2013 21:48:28 +0100 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1UM2hQ-0002sN-0D for v6ops@ietf.org; Sat, 30 Mar 2013 21:48:28 +0100 Date: Sat, 30 Mar 2013 21:48:27 +0100 From: Philipp Kern To: v6ops@ietf.org Message-ID: <20130330204827.GA7629@spike.0x539.de> References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <51425EB5.6040703@dougbarton.us> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <1363805194.86628.YahooMailNeo@web142505.mail.bf1.yahoo.com> <20130320185148.GA26639@spike.0x539.de> <20130330170859.GA25715@spike.0x539.de> <51572EDB.1080208@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline In-Reply-To: <51572EDB.1080208@gmail.com> Organization: The Debian Project (http://www.debian.org) X-Debbugs-No-Ack: yes User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 20:48:30 -0000 --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Mar 30, 2013 at 07:28:43PM +0100, Alexandru Petrescu wrote: > Simply curious: when you say revoke, is it that it disappears from > the web interface? Or that DHCPv6 revoke message is sent? When the box is unchecked and the settings saved, it will send an RA with preferred=0s to deprecate the old addresses. No DHCPv6 at all, just plain RAs. Kind regards Philipp Kern --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJRV0+bAAoJEERuJUU10FbsUpEH/1Lvpg/FahJCi/RC/kIk609h ZUcoTeU4HiD6IXsVft/z4EKj3M0gmpCnSJHF7pSpUAe+Bt4hYqiaVgurrx53JAml UPAVlqhmwUDxGrLJWDscJC6ZujlEM1KAy/Fd15hzEX/qhkBKnHsCcyTZAQyMCv1k Xeq6inNK/UeyocPUAC+h8IVtrvTZiCY4LnquEJWOpWqmdxXEo5O0pCVNoaCN2CjI WbGWVgtU4ephKR5Ttqab53p4b8MieEsALAlu0hVNUrYc7Qzynfuz9laTGtvdVkds iUbafJ0CMcsrl4Xmv5a1kHcsMXMTSPlgesfmyqhZtuAAmMmCXqQagYiudvjmOeU= =C8uV -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- From owen@delong.com Sun Mar 31 01:01:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784BE21F8511 for ; Sun, 31 Mar 2013 01:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlUemPkyPin1 for ; Sun, 31 Mar 2013 01:01:15 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 279EB21F860B for ; Sun, 31 Mar 2013 01:01:15 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2V7x7fb014365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 31 Mar 2013 01:00:07 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2V7x7fb014365 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364716808; bh=w2xECYp9qdM9kkCp4s9SmwBktZs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=2UetcSgv+I4iWZdPS5LbBp+i8Pfnjra+uH1vDC42yV7XXQvQcAzgeuyKa2buJlpDx Rn34CEhEhycIvYC28/8XCiMa3aL4DiWG5ryNfa0bebV371aWEVfjzdq3ki/vS8JIQz NDdmUf2VGI2QsU9nl1AYtnpp7NZ60Z0nC2CGLBik= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <20130330200500.GA7020@spike.0x539.de> Date: Sun, 31 Mar 2013 00:58:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5142129D.5000503@dougbarton.us> <97FC977A-38A6-4C65-AD65-FF32590E8C2B@delong.com> <51425EB5.6040703@dougbarton.us> <30A2BBDF-0745-455A-9C4D-E437795920EF@ecs.soton.ac.uk> <1363805194.86628.YahooMailNeo@web142505.mail.bf1.yahoo.com> <20130320185148.GA26639@spike.0x539.de> <20130330170859.GA25715@spike.0x539.de> <7A6025B7-A7BA-47F4-9AF5-213B32151849@delong.com> <20130330200500.GA7020@spike.0x539.de> To: Philipp Kern X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sun, 31 Mar 2013 01:00:08 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 08:01:16 -0000 On Mar 30, 2013, at 13:05 , Philipp Kern wrote: > Owen, >=20 > am Sat, Mar 30, 2013 at 12:13:52PM -0700 hast du folgendes = geschrieben: >>> Ok, the device does not actually revoke the ULA but keeps it. The = remaining bit >>> is still true: you don't get to pick your ULA, not even the subnet = bits. In >> The screen shot looks like you DO get to pick the subnet bits in = that there's >> a greyed out fill-in field. I suspect that when you click the ULA = checkbox, that >> field gets un-greyed and you can put any 16 bit value you want into = the >> subnet field. >>=20 >> Am I misreading the screen shot? >=20 > sadly so. They both don't activate if you hit any checkboxes (i.e. = they are > still greyed out). Just as the "Firewall" "option" is always ticked on = (and it > doesn't seem to have any actual option behind it), causing all = incoming IPv6 > traffic to be dropped. That might be a "customized" artifact of the DT custom firmware load. Owen From owen@delong.com Sun Mar 31 01:06:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392EE21F84F5 for ; Sun, 31 Mar 2013 01:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1PlpO6nNXe8 for ; Sun, 31 Mar 2013 01:06:15 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 732F721F84E7 for ; Sun, 31 Mar 2013 01:06:15 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2V83F87014460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 31 Mar 2013 01:03:15 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2V83F87014460 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364716995; bh=g6FHFTDhpn3JHMEU17ZjZ+hvaKY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=BsuxbYEYWyRBCJJTk9M/G3qfiCaKKe5nTbr0zG/zqjhZwhP9HKGDnSrNIxVWOswV0 qy2MB0v4QWjCbrxMkWnBKc0o6Ab3TMauaunMMwzJ2V/SoWu+wFtveYPx4YvbIhQmva 3EX2e09wjzhYunzMXcH12Qxr8ekcRKFTEc1yfXgc= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <51573A36.7070407@gmail.com> Date: Sun, 31 Mar 2013 01:01:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5B1350D9-3F76-492E-9C3A-8841BB7B6939@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6ECA24@nkgeml506-mbx.china.huawei.com> <731D2903-56BD-4A4D-9D86-EC1C3CF9D5E1@delong.com> <5155DCEE.2020909@gmail.com> <5155E4FE.8060707@bogus.com> <51573A36.7070407@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sun, 31 Mar 2013 01:03:15 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 08:06:16 -0000 >>=20 >> You can see the arin direct assignment policy here: >>=20 >> https://www.arin.net/policy/nrpm.html#six58 >=20 > Ok, that seems to say > "Provider independent (portable) addresses issued directly from ARIN = or other Regional Registries are not guaranteed to be globally = routable." >=20 Correct. > I suppose it would be hardly acceptable to put PI space in a vehicle = and suppose that Internet-at-wide not to be reachable. >=20 Why? > If by that statement ARIN means that a communication flow issued out = of a vehicle may need to first get through some 'upstream provider' or = 'provider's provider', then this may pose challenges to straight = vehicle-to-vehicle communications as well. >=20 That statement simply means "ARIN doesn't control the routers and has no = authority over those who do." When you attempt to advertise a prefix, it is up to your peers, = upstreams, etc. and up to each individual more distant network whether = or not they accept it into their routing table. I wouldn't read much more into it. Owen From v6ops@globis.net Sun Mar 31 01:07:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04EF121F86A5 for ; Sun, 31 Mar 2013 01:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 CPZoYI66gOFi for ; Sun, 31 Mar 2013 01:07:22 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2976521F8651 for ; Sun, 31 Mar 2013 01:07:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 02B388700C7; Sun, 31 Mar 2013 10:07:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuYGiklBqY0t; Sun, 31 Mar 2013 10:06:46 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id BC78587005F; Sun, 31 Mar 2013 10:06:45 +0200 (CEST) Message-ID: <5157EE8E.7070207@globis.net> Date: Sun, 31 Mar 2013 10:06:38 +0200 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Alexandru Petrescu References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6ECA24@nkgeml506-mbx.china.huawei.com> <731D2903-56BD-4A4D-9D86-EC1C3CF9D5E1@delong.com> <5155DCEE.2020909@gmail.com> <5155E4FE.8060707@bogus.com> <51573A36.7070407@gmail.com> In-Reply-To: <51573A36.7070407@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 08:07:23 -0000 Alexandru Petrescu wrote: > Joël, > > Thanks for the message. Reply below. > > Le 29/03/2013 >>> >> Entirely aside the issue of whether you want to number cars out of pi or >> not, this is also nonsense. >> >> You can see the arin direct assignment policy here: >> >> https://www.arin.net/policy/nrpm.html#six58 > > Ok, that seems to say > "Provider independent (portable) addresses issued directly from ARIN > or other Regional Registries are not guaranteed to be globally routable." > Correct. RIRs are address registration authorities. How an LIR routes their assigned prefixes to the global Internet (or not) is the LIR's problem. > I suppose it would be hardly acceptable to put PI space in a vehicle > and suppose that Internet-at-wide not to be reachable. > Why would that happen? > If by that statement ARIN means that a communication flow issued out > of a vehicle may need to first get through some 'upstream provider' or > 'provider's provider', then this may pose challenges to straight > vehicle-to-vehicle communications as well. > No. Not at all. There is no link between an RIR's allocation policy and an LIR"s peering policy. An LIR is free to peer with whomever they like. I think the automotive guys can even do that with their existing PA space, never mind PI, because they *are already* the LIR in most cases. There are any number of existing protocols that will allow an automotive LIR to create a contiguous network over various media (including the public Internet operated by other LIRs), and then break out to the Public Internet at a number of gateways with a (large) summary route that would be globally routed. e.g. take a /32 and split it into 16 /36's with a breakout per sub region e.g. NA-E, NA-W, SA, EU, Africa, AP-N, AP-S, India, China ..... How do think today's enterprise networks work (for travelling users with laptops)? Suggest you check out: NHRP, SSL, GRE, IPSec tunnel mode ..... I humbly suggest that you do not think of a car as a single end host, but rather a small site that moves around, that you then decompose your problem into many different communication flows, and then I'm pretty convinced you'll find an existing off-the-shelf solution for the vast majority of your problems. I think it would also help if you went and talked to some large corporate network operators. I'd be happy to help (offline). From alexandru.petrescu@gmail.com Sun Mar 31 10:43:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03EA21F8525 for ; Sun, 31 Mar 2013 10:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.903 X-Spam-Level: X-Spam-Status: No, score=0.903 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_13=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.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 m-DBacwhrJUX for ; Sun, 31 Mar 2013 10:43:24 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 5417021F8526 for ; Sun, 31 Mar 2013 10:43:22 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id E7E449401F0; Sun, 31 Mar 2013 19:43:15 +0200 (CEST) Message-ID: <515875AD.6030408@gmail.com> Date: Sun, 31 Mar 2013 19:43:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ray Hunter References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6ECA24@nkgeml506-mbx.china.huawei.com> <731D2903-56BD-4A4D-9D86-EC1C3CF9D5E1@delong.com> <5155DCEE.2020909@gmail.com> <5155E4FE.8060707@bogus.com> <51573A36.7070407@gmail.com> <5157EE8E.7070207@globis.net> In-Reply-To: <5157EE8E.7070207@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130331-0, 31/03/2013), Outbound message X-Antivirus-Status: Clean Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 17:43:25 -0000 Le 31/03/2013 10:06, Ray Hunter a écrit : > Alexandru Petrescu wrote: >> Joël, >> >> Thanks for the message. Reply below. >> >> Le 29/03/2013 >>>> >>> Entirely aside the issue of whether you want to number cars out of pi or >>> not, this is also nonsense. >>> >>> You can see the arin direct assignment policy here: >>> >>> https://www.arin.net/policy/nrpm.html#six58 >> >> Ok, that seems to say >> "Provider independent (portable) addresses issued directly from ARIN >> or other Regional Registries are not guaranteed to be globally routable." >> > > Correct. RIRs are address registration authorities. > > How an LIR routes their assigned prefixes to the global Internet (or > not) is the LIR's problem. Ok... >> I suppose it would be hardly acceptable to put PI space in a vehicle >> and suppose that Internet-at-wide not to be reachable. >> > > Why would that happen? If there is doubt about the PI space being or not routed to the Internet by the organization who provided that PI space then it is useless as "PI". ULA would make more sense - we know for sure it shouldnt be routed to Internet. Or I misunderstand PI entirely. >> If by that statement ARIN means that a communication flow issued out >> of a vehicle may need to first get through some 'upstream provider' or >> 'provider's provider', then this may pose challenges to straight >> vehicle-to-vehicle communications as well. >> > > No. Not at all. > > There is no link between an RIR's allocation policy and an LIR"s peering > policy. > An LIR is free to peer with whomever they like. Ok, but what about a vehicle? Suppose a vehicle has a PI or PA /63 inside it (not ULA), and another vehicle has another different such /63. Each of that /63 is valid at one or several points in the Internet, ok (i.e. someone else's router points to it). Would those two vehicles be ok to exchange their respective /63s? I don't think so, because it may create loops. Their prefixes should be advertised _only_ at the place which is correct. One couldn't imagine that one particular stable prefix of a vehicle could be advertised to all random vehicle passing by, which itself may be connected to Internet, etc. > I think the automotive guys can even do that with their existing PA > space, never mind PI, because they *are already* the LIR in most cases. > > There are any number of existing protocols that will allow an automotive > LIR to create a contiguous network over various media (including the > public Internet operated by other LIRs), and then break out to the > Public Internet at a number of gateways with a (large) summary route > that would be globally routed. e.g. take a /32 and split it into 16 > /36's with a breakout per sub region e.g. NA-E, NA-W, SA, EU, Africa, > AP-N, AP-S, India, China ..... > > How do think today's enterprise networks work (for travelling users with > laptops)? VPN - ok. I am talking without tunnels. One wouldnt want two vehicles nearby to go first through their VPN Gateways in Enterprise. > Suggest you check out: NHRP, SSL, GRE, IPSec tunnel mode ..... Yes, and protocol Mobile IP. All lack optimal routes - all go through anchor points, triangular routing, and multi-angular routing in case of moving networks. > > I humbly suggest that you do not think of a car as a single end host, > but rather a small site that moves around, that you then decompose your > problem into many different communication flows, and then I'm pretty > convinced you'll find an existing off-the-shelf solution for the vast > majority of your problems. I think it would also help if you went and > talked to some large corporate network operators. > > I'd be happy to help (offline). YEs, let us exchange offline about this. Additionally, for information, there is this ITS email list at ietf: ietf.org/mailman/listinfo/its In v6ops WG I find there is a right mindset and skill for IPv6 operational addressing architecture which may pertain to vehicular communications. Alex > From alexandru.petrescu@gmail.com Sun Mar 31 10:54:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE61321F861B for ; Sun, 31 Mar 2013 10:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.025 X-Spam-Level: X-Spam-Status: No, score=-0.025 tagged_above=-999 required=5 tests=[AWL=0.641, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, J_CHICKENPOX_13=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.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 7OFIWfqUaBsw for ; Sun, 31 Mar 2013 10:54:32 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 788A921F8617 for ; Sun, 31 Mar 2013 10:54:30 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 17F8B9400F9; Sun, 31 Mar 2013 19:54:24 +0200 (CEST) Message-ID: <5158784A.1020005@gmail.com> Date: Sun, 31 Mar 2013 19:54:18 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: joel jaeggli References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6ECA24@nkgeml506-mbx.china.huawei.com> <731D2903-56BD-4A4D-9D86-EC1C3CF9D5E1@delong.com> <5155DCEE.2020909@gmail.com> <5155E4FE.8060707@bogus.com> <51573A36.7070407@gmail.com> <51574A11.9050402@bogus.com> In-Reply-To: <51574A11.9050402@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130331-0, 31/03/2013), Outbound message X-Antivirus-Status: Clean Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 17:54:33 -0000 Le 30/03/2013 21:24, joel jaeggli a écrit : [...] > Locally signficant routing and adjacency decisions are clearly > relevant locally. YEs right. And there is a difference between adjacency of two large fixed sites (Enterprise) and more dynamic adjacency as in moving vehicles. > You have (imho) a set of separable problems, machine to machine > communication vs internet connectivity) YEs, that is right. V2V communications problems could be separated from the Internet connectivity problems (although there's als argument about 'nested' mobility which realizes both at the same time). > and they can be solved in all likelihood without boiling an ocean. Ok, vehicular communications are one particular aspect in v6ops. That aspect may be the necessity of ULA. All I am trying to say - dont kill ULA. And each time I have to explain why, only for this particular reason. Ido not boil the ocean. There is another list where this could be discussed: its, ietf.org/mailman/listinfo/its. > Today, cars with internet connectivity receive addressing from a > service provider, sometimes more than one, Curious about that 'sometimes' - I never saw. > I don't see any reason to expect that model is unworkable in the > future, If an operator puts a prefix into a vehicle, would that vehicle be allowed to advertise that same prefix to another vehicle (i.e. inform that other vehicle it owns that prefix, so route to it) - and vice versa. Or would that create routing problems? These are dynamic relationships which last maybe a few minutes or so. > wether they do that becasue of a relationship between the > manufacturer and the service provider (as is frequently the case) the > consumer and the service provider, or some device to which they are > tethered doesn't seem particularly relevant. Using more than one > address range, e.g. a provider assigned one, and a locally > significant one doesn't seem particularly daunting either. I agree in that sense, yes, two different address spaces for different purposes. Are you saying that one such PI space should be used instead of ULA? I.e. put PI inside a vehicle, and would be ok to do routing with this PI directly between vehicles? I.e. use a PI as if we were it's never routed to the Internet? I am lost. >>> My company with 11 current locations 5 of which were at time of >>> request datacenters received a /44 under the ARIN policy... >> >> Ok, this is good to know. >> >>> let's look elsewhere... (maybe you should ask these folks to >>> come to the meeting in berlin, (they're not that far away) and >>> talk about their assignment experience). >> >> Yes, I would like to ask them to come to IETF Berlin and present >> their assignment experience: is that /29 for offices or for >> vehicles, or both, prefixlen inside a vehicle, etc. >> > volkswagen ag is clearly an LIR in the scope of it's ripe prefix > assignment... > > I have no particular insight into how they use that prefix. A rather > small portion of it appears into the ipv6 routing table. > > It has generally been my experience that enterprises that need > address space are able to work within the system as it exists now to > secure the resources that they need. Clearly that is getting harder > with IPv4. I don't see much evidence for that's a problem in IPv6. I tend to agree yes. Alex >> This invitation may not be that simple to do, and I need help for >> that. (in which WG to present, should they write first a draft, >> etc.) These are problems I face daily with other parties which may >> be interested, if. >> >>> joels-MacBook-Air:~ jjaeggli$ whois -h whois.ripe.net >>> 2a01:4dc0::/29 % This is the RIPE Database query service. >> [...] >>> % Information related to '2a01:4dc0::/29' >>> >>> inet6num: 2a01:4dc0::/29 netname: DE-VOLKSWAGENAG-20120530 >>> descr: Volkswagen AG country: DE org: >>> ORG-VA303-RIPE admin-c: VWAG1-RIPE tech-c: >>> VWAG1-RIPE status: ALLOCATED-BY-RIR mnt-by: >>> RIPE-NCC-HM-MNT mnt-lower: AB82394-MNT mnt-routes: >>> AB82394-MNT source: RIPE # Filtered >> >> [...] >> >> Alex >> > > From alexandru.petrescu@gmail.com Sun Mar 31 10:57:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E51721F8617 for ; Sun, 31 Mar 2013 10:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.583 X-Spam-Level: X-Spam-Status: No, score=0.583 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.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 GiEe9I-Ut5LC for ; Sun, 31 Mar 2013 10:57:45 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 5E31321F84BC for ; Sun, 31 Mar 2013 10:57:35 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 7392694018C; Sun, 31 Mar 2013 19:57:30 +0200 (CEST) Message-ID: <51587904.5080007@gmail.com> Date: Sun, 31 Mar 2013 19:57:24 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Owen DeLong References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6ECA24@nkgeml506-mbx.china.huawei.com> <731D2903-56BD-4A4D-9D86-EC1C3CF9D5E1@delong.com> <5155DCEE.2020909@gmail.com> <5155E4FE.8060707@bogus.com> <51573A36.7070407@gmail.com> <5B1350D9-3F76-492E-9C3A-8841BB7B6939@delong.com> In-Reply-To: <5B1350D9-3F76-492E-9C3A-8841BB7B6939@delong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130331-0, 31/03/2013), Outbound message X-Antivirus-Status: Clean Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 17:57:46 -0000 Le 31/03/2013 10:01, Owen DeLong a écrit : >>> >>> You can see the arin direct assignment policy here: >>> >>> https://www.arin.net/policy/nrpm.html#six58 >> >> Ok, that seems to say "Provider independent (portable) addresses >> issued directly from ARIN or other Regional Registries are not >> guaranteed to be globally routable." >> > > Correct. > >> I suppose it would be hardly acceptable to put PI space in a >> vehicle and suppose that Internet-at-wide not to be reachable. >> > > Why? > >> If by that statement ARIN means that a communication flow issued >> out of a vehicle may need to first get through some 'upstream >> provider' or 'provider's provider', then this may pose challenges >> to straight vehicle-to-vehicle communications as well. >> > > That statement simply means "ARIN doesn't control the routers and has > no authority over those who do." > > When you attempt to advertise a prefix, it is up to your peers, > upstreams, etc. and up to each individual more distant network > whether or not they accept it into their routing table. These peers and upstreams seem to me as entities which develop longer term relationships between them (like when sysadmins know each other, orgs sign contracts, SLAs, and so on). This would be hardly feasible between two other vehicles following each other the time of a traffic jam. Who would be the upstream of the other for 10 minutes... etc. Alex > > I wouldn't read much more into it. > > Owen > > From owen@delong.com Sun Mar 31 13:11:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE43621F8696 for ; Sun, 31 Mar 2013 13:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOLdGaw-Wxeq for ; Sun, 31 Mar 2013 13:11:06 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB4821F866F for ; Sun, 31 Mar 2013 13:11:03 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r2VK8QvR012209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 31 Mar 2013 13:08:27 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r2VK8QvR012209 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1364760507; bh=iNEZuIy+4eNd1gjWYcYGE7XXuwM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=VgSBRT+wSBliOBIZNvqR01GGbh4tkp9M2bxrVBiIx+P0gNMOHys/lN6dQERNGAzhe LE56pNt+89fAfofSxQPZUyc+9PtMB0EKdb6s7QruEcLveTtK6GTwnK7CF4zJv6OvfA 0XBCcw4VDjdqsNTkWNkPIOfwhuBsOK08SmWj9ToQ= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <51587904.5080007@gmail.com> Date: Sun, 31 Mar 2013 13:06:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <82C3DB2C-79F9-45EB-AC60-05249285C985@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6ECA24@nkgeml506-mbx.china.huawei.com> <731D2903-56BD-4A4D-9D86-EC1C3CF9D5E1@delong.com> <5155DCEE.2020909@gmail.com> <5155E4FE.8060707@bogus.com> <51573A36.7070407@gmail.com> <5B1350D9-3F76-492E-9C3A-8841BB7B6939@delong.com> <51587904.5080007@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sun, 31 Mar 2013 13:08:27 -0700 (PDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 20:11:15 -0000 On Mar 31, 2013, at 10:57 , Alexandru Petrescu = wrote: > Le 31/03/2013 10:01, Owen DeLong a =E9crit : >>>>=20 >>>> You can see the arin direct assignment policy here: >>>>=20 >>>> https://www.arin.net/policy/nrpm.html#six58 >>>=20 >>> Ok, that seems to say "Provider independent (portable) addresses >>> issued directly from ARIN or other Regional Registries are not >>> guaranteed to be globally routable." >>>=20 >>=20 >> Correct. >>=20 >>> I suppose it would be hardly acceptable to put PI space in a >>> vehicle and suppose that Internet-at-wide not to be reachable. >>>=20 >>=20 >> Why? >>=20 >>> If by that statement ARIN means that a communication flow issued >>> out of a vehicle may need to first get through some 'upstream >>> provider' or 'provider's provider', then this may pose challenges >>> to straight vehicle-to-vehicle communications as well. >>>=20 >>=20 >> That statement simply means "ARIN doesn't control the routers and has >> no authority over those who do." >>=20 >> When you attempt to advertise a prefix, it is up to your peers, >> upstreams, etc. and up to each individual more distant network >> whether or not they accept it into their routing table. >=20 > These peers and upstreams seem to me as entities which develop longer = term relationships between them (like when sysadmins know each other, = orgs sign contracts, SLAs, and so on). >=20 > This would be hardly feasible between two other vehicles following = each other the time of a traffic jam. >=20 Right... We were talking about internet routing and the statement from = the RIR about prefixes not being guaranteed by the RIR to be routable on = the internet. Obviously two vehicles following each other in a traffic jam are = unlikely to be involved in global routing of a prefix in any meaningful = way. > Who would be the upstream of the other for 10 minutes... etc. >=20 Your questions make no sense to me in the context. One of us is very = much NOT understanding the other. I am not sure which. For vehicles, the most likely upstreams would be cellular networks, = wifi, or other such services. Probably on a somewhat dynamic basis using = locally assigned PA addresses for the links and MIP to actually carry = the permanent addresses. I suppose something like a 6lowpan mesh of automobiles could eventually = deliver some services for very low bandwidth applications. However, you really need to try and find a way to wrap your head around = the fact that routing and end point identity are two very distinct and = separate applications for IP addresses. In a fixed scenario, it = sometimes makes sense to use the same address for both purposes and = topology will dictate the prefix. In the mobile scenario, you need to, instead, consider that there will = be different IP addresses used for these purposes and some form of = Map/Encap will likely be used, whether that includes LISP, MIP, other = various technologies such as IRON, etc. is yet to be determined and no = one answer may fit every scenario. Further, the selection of solution and the choice of infrastructure, = routing, protocols, etc. can be fluid and dynamic as well. You have often talked about various options which can work in parallel = as if they are mutually exclusive. Owen From randy@psg.com Sun Mar 31 16:55:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D6E21F8615 for ; Sun, 31 Mar 2013 16:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjeInAvUrdNy for ; Sun, 31 Mar 2013 16:55:27 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 621DA21F8606 for ; Sun, 31 Mar 2013 16:55:27 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UMS5r-000O7F-Sy; Sun, 31 Mar 2013 23:55:24 +0000 Date: Mon, 01 Apr 2013 08:55:22 +0900 Message-ID: From: Randy Bush To: Alexandru Petrescu In-Reply-To: <515875AD.6030408@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC275@nkgeml506-mbx.china.huawei.com> <51534B90.9040102@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EC98F@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6ECA24@nkgeml506-mbx.china.huawei.com> <731D2903-56BD-4A4D-9D86-EC1C3CF9D5E1@delong.com> <5155DCEE.2020909@gmail.com> <5155E4FE.8060707@bogus.com> <51573A36.7070407@gmail.com> <5157EE8E.7070207@globis.net> <515875AD.6030408@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] ULA discussion #BCP or Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 23:55:27 -0000 > If there is doubt about the PI space being or not routed to the > Internet by the organization who provided that PI space then it is > useless as "PI". ULA would make more sense - we know for sure it > shouldnt be routed to Internet. either may be announced or not at the holder's discretion. who is willing to listen may vary. randy