From nobody Thu May 1 00:14:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA8F1A0A25 for ; Thu, 1 May 2014 00:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHxfjoYjZLWZ for ; Thu, 1 May 2014 00:12:50 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 0048A1A0A24 for ; Thu, 1 May 2014 00:12:45 -0700 (PDT) Received: (qmail 66636 invoked from network); 1 May 2014 07:12:42 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 1 May 2014 07:12:42 -0000 Date: Thu, 01 May 2014 09:12:42 +0200 (CEST) Message-Id: <20140501.091242.74687867.sthaug@nethelp.no> To: swmike@swm.pp.se From: sthaug@nethelp.no In-Reply-To: References: 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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/iChJzko3rHPeFWiQNjwgfU1MlrE Cc: mpls@ietf.org, v6ops@ietf.org, 6man@ietf.org Subject: Re: [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 07:12:52 -0000 > http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02 > > I realise this draft seems to have died, but I would never expect to see > packets with these addresses on the wire or in the routing table and if > they're there, I would want hosts/routers to drop them. Not doing this > seems to me it would open to all kinds of unwanted consequences when it > comes to filtering etc. On the wire, definitely no. In the routing tables - ::ffff:127.0.0.0 is not expected, but other IPv4-mapped IPv6 address are possible, for instance if you use 6VPE. Steinar Haug, AS 2116 From nobody Thu May 1 01:13:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8221A88E1 for ; Thu, 1 May 2014 01:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkcRDYaotcqN for ; Thu, 1 May 2014 01:13:29 -0700 (PDT) Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22]) by ietfa.amsl.com (Postfix) with SMTP id D648C1A88DE for ; Thu, 1 May 2014 01:13:28 -0700 (PDT) Received: (qmail 40787 messnum 12470400 invoked from network[213.94.190.14/avas02.vendorsvc.cra.dublin.eircom.net]); 1 May 2014 08:13:25 -0000 Received: from avas02.vendorsvc.cra.dublin.eircom.net (213.94.190.14) by mail06.svc.cra.dublin.eircom.net (qp 40787) with SMTP; 1 May 2014 08:13:25 -0000 Received: from [192.168.1.1] ([86.44.181.141]) by avas02.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id wYDM1n01E33Sln201YDRJd; Thu, 01 May 2014 09:13:25 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ross Chandler In-Reply-To: Date: Thu, 1 May 2014 09:12:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6CF1D618-F8F8-4E3E-832C-7011396138F0@eircom.net> References: To: v6ops@ietf.org X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/C5eJAB61-BFLTGKR2IN_HCKVNho Subject: Re: [v6ops] Thoughts on draft-byrne-v6ops-clatip-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 08:13:32 -0000 On 30 Apr 2014, at 23:48, Fred Baker (fred) wrote: >>=20 >>=20 >> 3. Choosing 192.0.0.0/29 >>=20 >> To avoid conflicts with any other network that may communicate with >> the CLAT, a locally unique address must be assigned. >=20 > Dumb question. Is there a reason to not use 169.254.0.0/16? I don=92t = suppose you have a MAC address, but if you can pick a number in 0..31, I = should think you could pick a number in 0..65535, and you might even = have a source for it. Operationally if I saw an address from 169.254.0.0/16 for the clatd I = might think it was in a transition state waiting to get another address = assigned instead of it. Ross= From nobody Thu May 1 01:59:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548FA1A88E4 for ; Thu, 1 May 2014 01:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g90T7t_tkFUZ for ; Thu, 1 May 2014 01:59:42 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCD71A88E1 for ; Thu, 1 May 2014 01:59:42 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 9810E62A49 for ; Thu, 1 May 2014 10:59:39 +0200 (CEST) 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 5F6D562A3B for ; Thu, 1 May 2014 10:59:39 +0200 (CEST) Received: (qmail 66840 invoked by uid 1007); 1 May 2014 10:59:39 +0200 Date: Thu, 1 May 2014 10:59:39 +0200 From: Gert Doering To: "Rajiv Asati \(rajiva\)" Message-ID: <20140501085939.GG43641@Space.Net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YQHsFhmV_jPq4MzGkLSd6AmH8Bc Cc: "mpls@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org> Subject: Re: [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 08:59:45 -0000 Hi, On Thu, May 01, 2014 at 06:08:51AM +0000, Rajiv Asati (rajiva) wrote: > We need your guidance on handling v4-mapped v6 addresses (section 2.5.5.2 > of [RFC4291]). > > 1. Should/Would they appear in IPv6 routing table? "Yes and no". It depends on the context - if the packet comes in and has an IPv6 header, address lookup happens via the IPv6 routing table. If a packet comes in with an IPv4 header, address lookup happens via the IPv4 routing table. So, IPv4 should never "bleed over" to the IPv6 routing table, but if you happen to receive an IPv6 packet with a destination IPv6 address in it's header of ::ffff:1.2.3.4, you'd either drop it right away, or use the IPv6 routing table to find the destination. The router itself should never ever source packets with a v4-mapped destination address in the packet (see below). > 2. Should an IPv6 packet with ::FFFF:127.0.0.0 be forwarded or dropped or > treated as a loopback packet, if ever received? Dropped. v4-mapped is an internal representation of an IPv4 address recevied on an ipv6 socket, and should never ever appear in packets on the wire. 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 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu May 1 02:02:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85AE31A88EA for ; Thu, 1 May 2014 02:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_ZR8lXH84I5 for ; Thu, 1 May 2014 02:02:19 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 83C611A6F04 for ; Thu, 1 May 2014 02:02:19 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 6C97262A51 for ; Thu, 1 May 2014 11:02:17 +0200 (CEST) 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 370DE62A41 for ; Thu, 1 May 2014 11:02:17 +0200 (CEST) Received: (qmail 67576 invoked by uid 1007); 1 May 2014 11:02:17 +0200 Date: Thu, 1 May 2014 11:02:17 +0200 From: Gert Doering To: Hesham Soliman Message-ID: <20140501090217.GH43641@Space.Net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/USkE-kgceWwe_Ag6w_v-TAUEssU Cc: "mpls@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org> Subject: Re: [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 09:02:22 -0000 Hi, On Thu, May 01, 2014 at 04:46:33PM +1000, Hesham Soliman wrote: > >I realise this draft seems to have died, but I would never expect to see > >packets with these addresses on the wire > > => I recall an information RFC but donıt remember the number. I agree they > will most likely not appear on the wire. > > > or in the routing table > > => Thatıs a different story. I donıt think there is anything banning this, If the packets are not going to appear on the wire, argueing about the content of the routing table is a bit... theoretical. I'd argue for internal representations of stuff to not use that format either, as it will just confuse things. The dual-stack API is bad enough for operating system implementors (ran into a bunch of issues with Linux recently) to avoid further use of v4-mapped stuff, anywhere. 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 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu May 1 05:38:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242B21A88E4 for ; Thu, 1 May 2014 05:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mu4vxAgO-dKf for ; Thu, 1 May 2014 05:37:28 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 368C51A082F for ; Thu, 1 May 2014 05:37:27 -0700 (PDT) Received: from [203.219.211.243] (helo=[192.168.0.8]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1WfqEs-0000hA-7Z; Thu, 01 May 2014 22:37:22 +1000 User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Thu, 01 May 2014 22:37:12 +1000 From: Hesham Soliman To: Gert Doering Message-ID: Thread-Topic: [v6ops] Q about IPv4-mapped IPv6 address & MPLS References: <20140501090217.GH43641@Space.Net> In-Reply-To: <20140501090217.GH43641@Space.Net> Mime-version: 1.0 Content-type: text/plain; charset="EUC-KR" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/I8JoVUiDx6x6a9zAHK2TfOsb5lU Cc: "mpls@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org> Subject: Re: [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 12:37:30 -0000 >Hi, > >On Thu, May 01, 2014 at 04:46:33PM +1000, Hesham Soliman wrote: >> >I realise this draft seems to have died, but I would never expect to >>see >> >packets with these addresses on the wire >>=20 >> =3D> I recall an information RFC but don=A9=F6t remember the number. I agree >>they >> will most likely not appear on the wire. >>=20 >> > or in the routing table >>=20 >> =3D> That=A9=F6s a different story. I don=A9=F6t think there is anything banning >>this, > >If the packets are not going to appear on the wire, argueing about the >content of the routing table is a bit... theoretical. =3D> Of course it is. In theory we have no business mandating what hosts should do internally, we can discuss best practices ..etc. The question was whether it can happen and it can. Hesham > >I'd argue for internal representations of stuff to not use that format >either, as it will just confuse things. The dual-stack API is bad enough >for operating system implementors (ran into a bunch of issues with Linux >recently) to avoid further use of v4-mapped stuff, anywhere. > >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 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu May 1 13:46:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5621A0990; Thu, 1 May 2014 13:46:51 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sx7D12ddkuHm; Thu, 1 May 2014 13:46:49 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id C7FAE1A093E; Thu, 1 May 2014 13:46:49 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id fp1so3644114pdb.9 for ; Thu, 01 May 2014 13:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=q4FEWSZC9vwYJLDdeQ1/jPvgcYHqofYoJYJ6ed0Jz/w=; b=AsCKhMR9N/AcugBVP+j2w8Ib0E+yd2WpE906gcYhS+WsA6mBsV+WoeU/WW10OTEpbY LJmX0Y+69eWseQrgcEil4wdHzS6gqdgN4ZEDJwsj5u8TGwVgaeTQVVpGBXOsNtLl9nSR 7SGTKWPUG9AT8R3bWsUsw5XpBMIIicOhe1b9O8tWUeyJasKUsZrp02hAeJHkufMdpKxp ZRIMTXutmMLn5V/Q4tnMlELQfUCK3gh9mPgPCVG45KnvNamA+FiwIxD3PmA5R5xrWcOy GQcMf9fBbxaa6/7BeBOFhIKOTaZqupFC86r7WFeOsdzgF4OzsLyXrH+RzPFrMXGeoiLH RGlw== X-Received: by 10.66.146.170 with SMTP id td10mr25414186pab.105.1398977207665; Thu, 01 May 2014 13:46:47 -0700 (PDT) Received: from [192.168.178.20] (234.193.69.111.dynamic.snap.net.nz. [111.69.193.234]) by mx.google.com with ESMTPSA id ss2sm164748278pab.8.2014.05.01.13.46.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 May 2014 13:46:46 -0700 (PDT) Message-ID: <5362B2BD.7060602@gmail.com> Date: Fri, 02 May 2014 08:46:53 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gert Doering References: <20140501085939.GG43641@Space.Net> In-Reply-To: <20140501085939.GG43641@Space.Net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-_Op2-7S1oeqQXyIfbXLQ3egejo Cc: "mpls@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org> Subject: Re: [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 20:46:51 -0000 On 01/05/2014 20:59, Gert Doering wrote: > Hi, > > On Thu, May 01, 2014 at 06:08:51AM +0000, Rajiv Asati (rajiva) wrote: >> We need your guidance on handling v4-mapped v6 addresses (section 2.5.5.2 >> of [RFC4291]). >> >> 1. Should/Would they appear in IPv6 routing table? > > "Yes and no". It depends on the context - if the packet comes in and has > an IPv6 header, address lookup happens via the IPv6 routing table. If > a packet comes in with an IPv4 header, address lookup happens via the > IPv4 routing table. > > So, IPv4 should never "bleed over" to the IPv6 routing table, but if > you happen to receive an IPv6 packet with a destination IPv6 address > in it's header of ::ffff:1.2.3.4, you'd either drop it right away, > or use the IPv6 routing table to find the destination. > > The router itself should never ever source packets with a v4-mapped > destination address in the packet (see below). > >> 2. Should an IPv6 packet with ::FFFF:127.0.0.0 be forwarded or dropped or >> treated as a loopback packet, if ever received? > > Dropped. v4-mapped is an internal representation of an IPv4 address > recevied on an ipv6 socket, and should never ever appear in packets on > the wire. Nobody seems to have mentioned RFC 4038, which makes this very clear. These addresses are an artefact and have no place in the routing system as such, and still less on the wire. Brian From nobody Thu May 1 13:53:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD651A6FA7; Thu, 1 May 2014 13:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TvX5G1glsY5; Thu, 1 May 2014 13:53:55 -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 269AB1A093E; Thu, 1 May 2014 13:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1739; q=dns/txt; s=iport; t=1398977633; x=1400187233; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=alqSDzlX9MhUwXav2nw6kw4kGN8px33LmluVDrbdgdw=; b=S0BdYAEpDuMZV455Q3iMnhPJK5vNljlgKXuhRFrxIKFJOIIRvulNpJow 3gQ0M/1Edaq1e2E4syXgE22vL4OTuLBa8mfU9ocUgD4qpmpuB7i+bYyjl DVwEAwsNlB6QoFbLl4Pbru8mczVGLXITeBBIy4K5JXelRVVnecp33H9Va o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAEizYlOrRDoG/2dsb2JhbABagwZPV8RagRQWdIIlAQEBAwE6PwwEAgEIEQMBAh8QMh0IAgQBDQWIOQcBDcluF45SBwaEMwEDhFmUVoE8kTKDM4Ir X-IronPort-AV: E=Sophos;i="4.97,966,1389744000"; d="scan'208";a="109108251" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 01 May 2014 20:53:52 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s41Krptj019847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 May 2014 20:53:52 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.41]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Thu, 1 May 2014 15:53:50 -0500 From: "Rajiv Asati (rajiva)" To: Christian Huitema , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org" Thread-Topic: Q about IPv4-mapped IPv6 address & MPLS Thread-Index: AQHPZQPSCzbpGVI9y0mONiS9cBGpH5srRWcQgAEANQA= Date: Thu, 1 May 2014 20:53:49 +0000 Message-ID: References: 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.9.131030 x-originating-ip: [10.82.218.19] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1JJaLYzP1Tp-TTpJysBd0iFMDuY Cc: "mpls@ietf.org" Subject: Re: [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 20:53:56 -0000 Hi Christian, Thanks for the pointer. WKPs surely qualify to be in in the RIB/FIB and label allocations.=20 However, v4-mapped v6 addresses are not used by RFC 6052. :o =20 --=20 Cheers, Rajiv Asati Distinguished Engineer, Cisco -----Original Message----- From: Christian Huitema Date: Thursday, May 1, 2014 at 2:44 AM To: Rajiv Asati , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org" Cc: "mpls@ietf.org" Subject: RE: Q about IPv4-mapped IPv6 address & MPLS >> We need your guidance on handling v4-mapped v6 addresses (section >>2.5.5.2 >> of [RFC4291]).=20 >> >> 1. Should/Would they appear in IPv6 routing table? >> 2. Should an IPv6 packet with ::FFFF:127.0.0.0 be forwarded or dropped >>or >> treated as a loopback packet, if ever received? >> >> The answer to Q#1 will help MPLS WG to decide the proper handling of >> v4-mapped v6 addresses in LDPv6 draft section 7 1st para. >> http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-12#section-7 * > >You may want to check RFC 6052, IPv6 Addressing of IPv4/IPv6 Translators. >RFC 6052 updates RFC4291, and lets translators construct domain specific >addresses that can actually be used in the routing tables. It also >includes an answer to your loopback packet question: > > The Well-Known Prefix MUST NOT be used to represent non-global IPv4 > addresses, such as those defined in [RFC1918] or listed in Section 3 > of [RFC5735]. Address translators MUST NOT translate packets in > which an address is composed of the Well-Known Prefix and a non- > global IPv4 address; they MUST drop these packets. > >-- Christian Huitema > > > From nobody Thu May 1 14:10:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422861A7D81; Thu, 1 May 2014 14:10:36 -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=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSDUeGsRvbXR; Thu, 1 May 2014 14:10:27 -0700 (PDT) Received: from nomis80.org (nomis80.org [23.92.21.33]) by ietfa.amsl.com (Postfix) with ESMTP id 444661A0971; Thu, 1 May 2014 14:10:27 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:ada6:3fa9:d0fd:fbe0]) by nomis80.org (Postfix) with ESMTPSA id 97BCC10EAB; Thu, 1 May 2014 21:10:45 +0000 (UTC) Message-ID: <5362B83F.4020808@per.reau.lt> Date: Thu, 01 May 2014 17:10:23 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BG6STKP_93l9UBrfgxnPkFHoivE Cc: mpls@ietf.org, 6man WG Subject: Re: [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 21:10:36 -0000 Le 2014-05-01 02:08, Rajiv Asati (rajiva) a écrit : > The answer to Q#1 will help MPLS WG to decide the proper handling of > v4-mapped v6 addresses in LDPv6 draft section 7 1st para. > http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-12#section-7 * Rajiv, In addition to what the others have said, to provide very precise guidance, I think this text in your draft... An LSR MUST NOT allocate and MUST NOT advertise FEC-Label bindings for link-local IPv6 address, and ignore such bindings, if ever received. An LSR MUST treat the IPv4-mapped IPv6 address, defined in section 2.5.5.2 of [RFC4291], the same as that of a global IPv6 address and not mix it with the 'corresponding' IPv4 address. ...should be changed to: An LSR MUST NOT allocate and MUST NOT advertise FEC-Label bindings for link-local or IPv4-mapped IPv6 address, and ignore such bindings, if ever received. Simon From nobody Thu May 1 15:20:26 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6301A0948; Thu, 1 May 2014 15:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6a3X7n5ZGhr; Thu, 1 May 2014 15:20:22 -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 5837D1A06DB; Thu, 1 May 2014 15:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1520; q=dns/txt; s=iport; t=1398982820; x=1400192420; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=k4S/nS0HaDlaEU0x2uJcZ98uVGbisT63Zg6f8W/d8qc=; b=LUJJBZHVxCSUVfdN0YGrobWgpYPJzdaPKsFuSCFYWOZSvOzAJbI8mO/+ FsGk4OfA7KwRtL1vwzBIZ4PMTQ6+4yQIIyFp/4UNuTZrdxbSBGSCs6o25 Sexfi0uYS1jihnH8nGaRfQ9Hrtw2qFLPp9OmJjvNKMYmxzWVcRbFkECmR I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFACTIYlOtJA2D/2dsb2JhbABagwZPvXOHPoEUFnSCJQEBAQMBAQEBawsFCwIBCBguJwslAgQOBYg5CA3JaBeOUgeDJIEVBIlMj2OBPJEygzM X-IronPort-AV: E=Sophos;i="4.97,967,1389744000"; d="scan'208";a="321837749" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP; 01 May 2014 22:20:20 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s41MKJO7032112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 May 2014 22:20:19 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.41]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 1 May 2014 17:20:19 -0500 From: "Rajiv Asati (rajiva)" To: Simon Perreault Thread-Topic: [v6ops] Q about IPv4-mapped IPv6 address & MPLS Thread-Index: AQHPZYHVKyuQb1xSnUicpDemuoOtD5ssTA69 Date: Thu, 1 May 2014 22:20:19 +0000 Message-ID: References: ,<5362B83F.4020808@per.reau.lt> In-Reply-To: <5362B83F.4020808@per.reau.lt> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/CZoViCCzlQ9xSYnsApr4DoohyZw Cc: "mpls@ietf.org" , "v6ops@ietf.org" , 6man WG Subject: Re: [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 22:20:23 -0000 Hi Simon, Ditto. This is what I was about to suggest for Q#1. Thanks.=20 I wish there was something like that for ospfv3, isis, rip, BGP etc. too.=20 Cheers, Rajiv > On May 1, 2014, at 5:10 PM, "Simon Perreault" wrote: >=20 > Le 2014-05-01 02:08, Rajiv Asati (rajiva) a =E9crit : >> The answer to Q#1 will help MPLS WG to decide the proper handling of >> v4-mapped v6 addresses in LDPv6 draft section 7 1st para. >> http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-12#section-7 * >=20 > Rajiv, >=20 > In addition to what the others have said, to provide very precise > guidance, I think this text in your draft... >=20 > An LSR MUST NOT allocate and MUST NOT advertise FEC-Label bindings > for link-local IPv6 address, and ignore such bindings, if ever > received. An LSR MUST treat the IPv4-mapped IPv6 address, defined in > section 2.5.5.2 of [RFC4291], the same as that of a global IPv6 > address and not mix it with the 'corresponding' IPv4 address. >=20 > ...should be changed to: >=20 > An LSR MUST NOT allocate and MUST NOT advertise FEC-Label bindings > for link-local or IPv4-mapped IPv6 address, and ignore such > bindings, if ever received. >=20 > Simon >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu May 1 15:21:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3911A0948; Thu, 1 May 2014 15:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGou2mUIlS-b; Thu, 1 May 2014 15:21:29 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id EE7331A09C3; Thu, 1 May 2014 15:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1716; q=dns/txt; s=iport; t=1398982884; x=1400192484; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=myYq2XzCSmfR0qTQjRtA3D652avJA/7IdtRy07C9q9c=; b=NxfuQKN55d1iNsknSrfUoa05TsgBXINv8Di+Ia0grH1+4KKCBcMJ0UjR z5l7UGgQARY7QZNO0v6juLiA3Rz3VEtLAj8iaCYuYfXJvYHvTSJs+J/FR 7VGD/A/LMmEWh3J4YCdAAZJx72n7rl1+dVt9FAm5GysHxYp0Ym/dAzmt7 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAK/HYlOtJA2N/2dsb2JhbABagwbGAIEUFnSCJQEBAQMBOj8FCwIBCBgeECERJQIEDgWILQMJCMMiDYZFF4w7gWQzB4MkgRUBA5c9gXKNE4VbgzM X-IronPort-AV: E=Sophos;i="4.97,967,1389744000"; d="scan'208";a="40393657" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP; 01 May 2014 22:21:23 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s41MLNSx024751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 May 2014 22:21:23 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.41]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Thu, 1 May 2014 17:21:23 -0500 From: "Rajiv Asati (rajiva)" To: Brian E Carpenter Thread-Topic: [v6ops] Q about IPv4-mapped IPv6 address & MPLS Thread-Index: AQHPZRuxmza+wZtqAkG9xRAfqumSLZsshpGA///GlVc= Date: Thu, 1 May 2014 22:21:22 +0000 Message-ID: References: <20140501085939.GG43641@Space.Net>,<5362B2BD.7060602@gmail.com> In-Reply-To: <5362B2BD.7060602@gmail.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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rNCMbtrppDAySPTfjadebSx0WvM Cc: "mpls@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org> Subject: Re: [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 22:21:30 -0000 Thanks, Brian. Which RFC 4038 section in particular should be referenced to= ? Cheers, Rajiv > On May 1, 2014, at 4:47 PM, "Brian E Carpenter" wrote: >=20 >> On 01/05/2014 20:59, Gert Doering wrote: >> Hi, >>=20 >>> On Thu, May 01, 2014 at 06:08:51AM +0000, Rajiv Asati (rajiva) wrote: >>> We need your guidance on handling v4-mapped v6 addresses (section 2.5.5= .2 >>> of [RFC4291]).=20 >>>=20 >>> 1. Should/Would they appear in IPv6 routing table? >>=20 >> "Yes and no". It depends on the context - if the packet comes in and ha= s >> an IPv6 header, address lookup happens via the IPv6 routing table. If=20 >> a packet comes in with an IPv4 header, address lookup happens via the >> IPv4 routing table. =20 >>=20 >> So, IPv4 should never "bleed over" to the IPv6 routing table, but if=20 >> you happen to receive an IPv6 packet with a destination IPv6 address >> in it's header of ::ffff:1.2.3.4, you'd either drop it right away, >> or use the IPv6 routing table to find the destination. >>=20 >> The router itself should never ever source packets with a v4-mapped >> destination address in the packet (see below). >>=20 >>> 2. Should an IPv6 packet with ::FFFF:127.0.0.0 be forwarded or dropped= or >>> treated as a loopback packet, if ever received? >>=20 >> Dropped. v4-mapped is an internal representation of an IPv4 address >> recevied on an ipv6 socket, and should never ever appear in packets on >> the wire. >=20 > Nobody seems to have mentioned RFC 4038, which makes this very clear. > These addresses are an artefact and have no place in the routing > system as such, and still less on the wire. >=20 > Brian >=20 From nobody Thu May 1 15:23:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721041A6FD1; Thu, 1 May 2014 15:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqWOY5IsAyC6; Thu, 1 May 2014 15:23:23 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id AEDAC1A09FD; Thu, 1 May 2014 15:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1486; q=dns/txt; s=iport; t=1398983002; x=1400192602; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=96vsd51YQJo+TPtRwY3YG0Z6Lb+rTV+ilM9D0NirNpM=; b=Ee4z89Vx/aT0/I3insgTNdEk+3UyKPW2S70UfYAij50jTQl5s0K9egCm I7sFlzuWRpMqP6EH8xzV83nJDASwtHJgcvpRjzo/UZLhrOhafSWOwlAhx DY9LGjBihDHS4UbYGgUoGHBW2f75Gm/LBBbel8NQ8ZQ+K+LRu7l8yvnah Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAjJYlOtJA2G/2dsb2JhbABagwbGAIEUFnSCJQEBAQMBeQULAgEIGC4yJQIEDgWIOQjJdReOHzMHgySBFQSJTI9jkm6DMw X-IronPort-AV: E=Sophos;i="4.97,967,1389744000"; d="scan'208";a="318773423" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-9.cisco.com with ESMTP; 01 May 2014 22:23:21 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s41MNLZ2028760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 May 2014 22:23:21 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.41]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Thu, 1 May 2014 17:23:20 -0500 From: "Rajiv Asati (rajiva)" To: Gert Doering Thread-Topic: [v6ops] Q about IPv4-mapped IPv6 address & MPLS Thread-Index: AQHPZQkfIYq9UHb5jEKNapytnrV9qJsrwdmAgACL/+k= Date: Thu, 1 May 2014 22:23:21 +0000 Message-ID: References: ,<20140501090217.GH43641@Space.Net> In-Reply-To: <20140501090217.GH43641@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/OfZ4EjmJEg36lMTgSJQwC29iwlM Cc: "mpls@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org> Subject: Re: [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 22:23:25 -0000 I wish there was a document stating this. It would help to refine the proto= col behavior.=20 Cheers, Rajiv > On May 1, 2014, at 5:02 AM, "Gert Doering" wrote: >=20 > Hi, >=20 > On Thu, May 01, 2014 at 04:46:33PM +1000, Hesham Soliman wrote: >>> I realise this draft seems to have died, but I would never expect to se= e >>> packets with these addresses on the wire >>=20 >> =3D> I recall an information RFC but don=B9t remember the number. I agre= e they >> will most likely not appear on the wire. >>=20 >>> or in the routing table >>=20 >> =3D> That=B9s a different story. I don=B9t think there is anything banni= ng this, >=20 > If the packets are not going to appear on the wire, argueing about the > content of the routing table is a bit... theoretical. >=20 > I'd argue for internal representations of stuff to not use that format > either, as it will just confuse things. The dual-stack API is bad enough > for operating system implementors (ran into a bunch of issues with Linux > recently) to avoid further use of v4-mapped stuff, anywhere. >=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-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu May 1 15:33:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D4A1A06DB for ; Thu, 1 May 2014 15:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.641 X-Spam-Level: X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ad0AQYUp26eu for ; Thu, 1 May 2014 15:33: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 C5DD81A09D4 for ; Thu, 1 May 2014 15:33:27 -0700 (PDT) Received: from [10.5.16.141] (adsl-69-228-81-237.dsl.pltn13.pacbell.net [69.228.81.237]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s41MVe0I026836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 1 May 2014 15:31:49 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s41MVe0I026836 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1398983515; bh=hixHDbA5BVBDoBF4XG0UIAOVPw8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=KrixBnC93442UVaaY3fxDB1r+Qd8jLvkglnaNbHFNDHmP2bQTP878FgnQAfj/RFSL 00PoPA86M//RPauKVY2FpFm+gTIO+W3plA7gs8bbt1qtTSL32z2X89pagjQmGmsvoU qRedvH/t55vQUOjC8B4y3StO/2c9kVUiubbMoQkg= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <5361DBFA.3010403@bogus.com> Date: Thu, 1 May 2014 15:31:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <40C41DA9-3513-4BC3-B6C9-7A1EEF98BBC7@cisco.com> <5361DBFA.3010403@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 01 May 2014 15:31:55 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mE2CZskOGDhHdx4LPiR47AUSVk4 Cc: V6 Ops List , "Byrne, Cameron" Subject: Re: [v6ops] Thoughts on draft-byrne-v6ops-clatip-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 22:33:29 -0000 On Apr 30, 2014, at 10:30 PM, joel jaeggli wrote: > On 4/30/14, 7:55 PM, Lorenzo Colitti wrote: >> On Thu, May 1, 2014 at 8:24 AM, Fred Baker (fred) > > wrote: >>=20 >> Ask me someday what thoughts go through my mind about applications >> making inferences from network layer addresses. >>=20 >>=20 >> The wording in RFC 3927 is much stronger. For example, it states >> multiple times that packets sourced from 169.254/16 MUST NOT be >> forwarded, and that they MUST NOT ever be sent to any router for >> forwarding. I think it's perfectly reasonable for an app (or even an >> OS!) to assume that such addresses have no connectivity. >>=20 >>=20 >> Hey, 192.168.0.0/16 is for networks that >> don=92t connect to the Internet. You want proof? =46rom RFC 1918, = the >> motivation is >>=20 >> With the proliferation of TCP/IP technology worldwide, including >> outside the Internet itself, an increasing number of = non-connected >> enterprises use this technology and its addressing capabilities = for >> sole intra-enterprise communications, without any intention to = ever >> directly connect to other enterprises or the Internet itself. >>=20 >>=20 >> Funny, that's what the proponents of ULA-only networks say too - "no, >> this network will NEVER connect to the Internet, ever!!11" I suspect >> they do so because they know that saying "we want to use NAT to = connect >> this network to the Internet like we do in IPv4" is going to result = in >> strong opinions and removal of support for the use case. But that's >> off-topic here. >=20 > site-local unicast in ipv6 and rfc 1918 are relatively = contemporaneous > ideas... >=20 > I don't thing the pressures that produce such solutions are = particularly > new in fact it's pretty easy to assert that they co-evolved. Yes, but unlike RFC-1918, we came to our senses and deprecated = site-local. ULA came later as a result of pressure from people who loved their NAT. = Sad, really, that the problem was not addressed through education = instead of better RIR policies for global unicast. Owen From nobody Thu May 1 15:52:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E931A8026 for ; Thu, 1 May 2014 15:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7t5Lhmoh7p-7 for ; Thu, 1 May 2014 15:51:59 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3531A09B8 for ; Thu, 1 May 2014 15:51:59 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s41MpkZp020172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 1 May 2014 22:51:46 GMT (envelope-from joelja@bogus.com) Message-ID: <5362CFFC.2040609@bogus.com> Date: Thu, 01 May 2014 15:51:40 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Thunderbird/29.0 MIME-Version: 1.0 To: Owen DeLong References: <40C41DA9-3513-4BC3-B6C9-7A1EEF98BBC7@cisco.com> <5361DBFA.3010403@bogus.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GkGombuktf3bBVaR4QLPNgFN5RdveU3Da" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Thu, 01 May 2014 22:51:48 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/oF7y6y1VPjGilULN5PT9m_lst7U Cc: V6 Ops List , "Byrne, Cameron" Subject: Re: [v6ops] Thoughts on draft-byrne-v6ops-clatip-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 22:52:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GkGombuktf3bBVaR4QLPNgFN5RdveU3Da Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 5/1/14, 3:31 PM, Owen DeLong wrote: >=20 > On Apr 30, 2014, at 10:30 PM, joel jaeggli wrote: >=20 >> On 4/30/14, 7:55 PM, Lorenzo Colitti wrote: >>> On Thu, May 1, 2014 at 8:24 AM, Fred Baker (fred) >> > wrote: >>> >>> Ask me someday what thoughts go through my mind about applications >>> making inferences from network layer addresses. >>> >>> >>> The wording in RFC 3927 is much stronger. For example, it states >>> multiple times that packets sourced from 169.254/16 MUST NOT be >>> forwarded, and that they MUST NOT ever be sent to any router for >>> forwarding. I think it's perfectly reasonable for an app (or even an >>> OS!) to assume that such addresses have no connectivity. >>> >>> >>> Hey, 192.168.0.0/16 is for networks that >>> don=92t connect to the Internet. You want proof? From RFC 1918, the= >>> motivation is >>> >>> With the proliferation of TCP/IP technology worldwide, including= >>> outside the Internet itself, an increasing number of non-connect= ed >>> enterprises use this technology and its addressing capabilities = for >>> sole intra-enterprise communications, without any intention to e= ver >>> directly connect to other enterprises or the Internet itself. >>> >>> >>> Funny, that's what the proponents of ULA-only networks say too - "no,= >>> this network will NEVER connect to the Internet, ever!!11" I suspect >>> they do so because they know that saying "we want to use NAT to conne= ct >>> this network to the Internet like we do in IPv4" is going to result i= n >>> strong opinions and removal of support for the use case. But that's >>> off-topic here. >> >> site-local unicast in ipv6 and rfc 1918 are relatively contemporaneou= s >> ideas... >> >> I don't thing the pressures that produce such solutions are particular= ly >> new in fact it's pretty easy to assert that they co-evolved. >=20 > Yes, but unlike RFC-1918, we came to our senses and deprecated site-loc= al. > > ULA came later as a result of pressure from people who loved their NAT.= Sad, really, that the problem was not addressed through education instea= d of better RIR policies for global unicast. fec0::/10 was reserved way back in rfc 1884 3879 and 4193 are contemporaneous activities. meany people on this list were present for them. The fact that we did a bad job at something 20 years ago doesn't mean the problem that we were attempting to address went away. > Owen >=20 >=20 --GkGombuktf3bBVaR4QLPNgFN5RdveU3Da Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNiz/wACgkQ8AA1q7Z/VrKivQCcCI62tOgeuyqlwc0OTfSmBZjo pAkAn0SmRI3XtIr+k0nq6mzhyrQumENg =E5M6 -----END PGP SIGNATURE----- --GkGombuktf3bBVaR4QLPNgFN5RdveU3Da-- From nobody Thu May 1 15:53:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2DA1A06DB; Thu, 1 May 2014 15:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXM7UiMTaTHl; Thu, 1 May 2014 15:53: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 739241A09B8; Thu, 1 May 2014 15:53:29 -0700 (PDT) Received: from [10.5.16.141] (adsl-69-228-81-237.dsl.pltn13.pacbell.net [69.228.81.237]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s41MoxI2027613 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 1 May 2014 15:51:00 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s41MoxI2027613 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1398984668; bh=s/p5JdKTZkmXXHVyAP7o24EKXZg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=1HIL8aJbARsPdUde/tN3ZJQ+NYbjdZc+4C4Rrz3yiP2WP7QuhO8tq9eCiyLKwQOR/ jaBlI2ECfYVrLpIcbY2l1PRFolk2xgH9oGdCu9ZmbfMKCsIsTFsvS7kR8og9ipqTXz 48WTF+Dn7gmRl3dbI7tzGrl14oqlvbniUB89t+HA= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: Date: Thu, 1 May 2014 15:50:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <52768D51-C3DB-4EE8-BBDA-C54CF5027F27@delong.com> References: , <5362B83F.4020808@per.reau.lt> To: "Rajiv Asati (rajiva)" X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 01 May 2014 15:51:08 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/gpiXbMAQCLTqRikbirBv0hij0dI Cc: "v6ops@ietf.org" , 6man WG , "mpls@ietf.org" Subject: Re: [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 22:53:30 -0000 I like this proposed change as well. Owne On May 1, 2014, at 3:20 PM, Rajiv Asati (rajiva) = wrote: > Hi Simon, >=20 > Ditto. This is what I was about to suggest for Q#1. Thanks.=20 >=20 > I wish there was something like that for ospfv3, isis, rip, BGP etc. = too.=20 >=20 > Cheers, > Rajiv >=20 >> On May 1, 2014, at 5:10 PM, "Simon Perreault" = wrote: >>=20 >> Le 2014-05-01 02:08, Rajiv Asati (rajiva) a =E9crit : >>> The answer to Q#1 will help MPLS WG to decide the proper handling of >>> v4-mapped v6 addresses in LDPv6 draft section 7 1st para. >>> http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-12#section-7 * >>=20 >> Rajiv, >>=20 >> In addition to what the others have said, to provide very precise >> guidance, I think this text in your draft... >>=20 >> An LSR MUST NOT allocate and MUST NOT advertise FEC-Label bindings >> for link-local IPv6 address, and ignore such bindings, if ever >> received. An LSR MUST treat the IPv4-mapped IPv6 address, defined in >> section 2.5.5.2 of [RFC4291], the same as that of a global IPv6 >> address and not mix it with the 'corresponding' IPv4 address. >>=20 >> ...should be changed to: >>=20 >> An LSR MUST NOT allocate and MUST NOT advertise FEC-Label bindings >> for link-local or IPv4-mapped IPv6 address, and ignore such >> bindings, if ever received. >>=20 >> Simon >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu May 1 16:00:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3458C1A09FA; Thu, 1 May 2014 16:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0crbun9m1HHn; Thu, 1 May 2014 16:00:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) by ietfa.amsl.com (Postfix) with ESMTP id 851A81A0986; Thu, 1 May 2014 16:00:18 -0700 (PDT) Received: from BLUPR03MB424.namprd03.prod.outlook.com (10.141.78.152) by BLUPR03MB424.namprd03.prod.outlook.com (10.141.78.152) with Microsoft SMTP Server (TLS) id 15.0.929.12; Thu, 1 May 2014 23:00:15 +0000 Received: from BLUPR03MB424.namprd03.prod.outlook.com ([10.141.78.152]) by BLUPR03MB424.namprd03.prod.outlook.com ([10.141.78.152]) with mapi id 15.00.0929.001; Thu, 1 May 2014 23:00:15 +0000 From: Christian Huitema To: "Rajiv Asati (rajiva)" , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org" Thread-Topic: Q about IPv4-mapped IPv6 address & MPLS Thread-Index: AQHPZQPSCzbpGVI9y0mONiS9cBGpH5srRWcQgAEANQCAABITAA== Date: Thu, 1 May 2014 23:00:15 +0000 Message-ID: <85910072e0794eae8149ba10ff933c58@BLUPR03MB424.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::2] x-forefront-prvs: 01986AE76B x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(86362001)(81542001)(76482001)(4396001)(86612001)(77982001)(81342001)(87936001)(101416001)(33646001)(92566001)(2656002)(558084003)(46102001)(83072002)(83322001)(31966008)(80022001)(20776003)(85852003)(80976001)(2201001)(74502001)(99396002)(79102001)(50986999)(76576001)(77096999)(76176999)(74316001)(99286001)(54356999)(74662001)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB424; H:BLUPR03MB424.namprd03.prod.outlook.com; FPR:BF12F1BD.36B147A3.39E38DCF.C4CE9E18.20082; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qJSHsE9c6SRKygBQcIfRDuvUlJ4 Cc: "mpls@ietf.org" Subject: Re: [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 23:00:21 -0000 > However, v4-mapped v6 addresses are not used by RFC 6052. :o =20 That's intentional. The short answer is that you should not use them, and y= ou should not place them in the routing tables. -- Christian Huitema From nobody Thu May 1 16:19:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E021A882B; Thu, 1 May 2014 16:18:58 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tI4kly5hdEFs; Thu, 1 May 2014 16:18:56 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id DE5411A8829; Thu, 1 May 2014 16:18:55 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id ld10so4384151pab.40 for ; Thu, 01 May 2014 16:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=E8J5t2zwBb7fIQheP/TNx4iWEF6ghG08CIDi8SUWrRA=; b=Kql3njOjXa1/zkBTtQIWvyEDFtUK+kOnzAFYRc5I1NgQeWmTEow3IvwP3r0oYT5KX5 bsGHIlAfW11yAhqY7VOy939+24A5l3wFWyazNPtzfrYhsehivNvw4S50tiaKBhFCbzkV dE7sP95EKquEU/cnpM4flvmwKZY+LOHO9QOSZS1lTIg5x1y1D1VEvyrYmYsTEZuMmMQK gGC8b+Ju0d87WpMGgs5Uu/t4vzpI2qGMfGBbwP7xPg1EO2K1uEF6xtGVyTKLQd8+ZJji GQLnhcvOQHTftmXvyoOZSoB+5Fh0h7SFUg0xuKnSk9f7NfxUavLYIgNsnkMJlqUpG88z no9Q== X-Received: by 10.66.153.80 with SMTP id ve16mr26839745pab.143.1398986333809; Thu, 01 May 2014 16:18:53 -0700 (PDT) Received: from [192.168.178.20] (234.193.69.111.dynamic.snap.net.nz. [111.69.193.234]) by mx.google.com with ESMTPSA id vx10sm167396420pac.17.2014.05.01.16.18.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 May 2014 16:18:53 -0700 (PDT) Message-ID: <5362D663.7090501@gmail.com> Date: Fri, 02 May 2014 11:18:59 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Rajiv Asati (rajiva)" References: <20140501085939.GG43641@Space.Net>, <5362B2BD.7060602@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xl4HBUydwBm4csAsLrOp156eCgY Cc: "mpls@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org> Subject: Re: [v6ops] Q about IPv4-mapped IPv6 address & MPLS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 23:18:59 -0000 On 02/05/2014 10:21, Rajiv Asati (rajiva) wrote: > Thanks, Brian. Which RFC 4038 section in particular should be referenced to? I think section 4.2. "IPv6 Applications in a Dual-Stack Node". It has a diagram that very clearly shows that packets that are "decorated" inside the host with an IPv4-mapped address are sent or received as native IPv4 packets. It's an Informational RFC but even so it seem to be the authoritative text in this case. Brian > Cheers, > Rajiv > >> On May 1, 2014, at 4:47 PM, "Brian E Carpenter" wrote: >> >>> On 01/05/2014 20:59, Gert Doering wrote: >>> Hi, >>> >>>> On Thu, May 01, 2014 at 06:08:51AM +0000, Rajiv Asati (rajiva) wrote: >>>> We need your guidance on handling v4-mapped v6 addresses (section 2.5.5.2 >>>> of [RFC4291]). >>>> >>>> 1. Should/Would they appear in IPv6 routing table? >>> "Yes and no". It depends on the context - if the packet comes in and has >>> an IPv6 header, address lookup happens via the IPv6 routing table. If >>> a packet comes in with an IPv4 header, address lookup happens via the >>> IPv4 routing table. >>> >>> So, IPv4 should never "bleed over" to the IPv6 routing table, but if >>> you happen to receive an IPv6 packet with a destination IPv6 address >>> in it's header of ::ffff:1.2.3.4, you'd either drop it right away, >>> or use the IPv6 routing table to find the destination. >>> >>> The router itself should never ever source packets with a v4-mapped >>> destination address in the packet (see below). >>> >>>> 2. Should an IPv6 packet with ::FFFF:127.0.0.0 be forwarded or dropped or >>>> treated as a loopback packet, if ever received? >>> Dropped. v4-mapped is an internal representation of an IPv4 address >>> recevied on an ipv6 socket, and should never ever appear in packets on >>> the wire. >> Nobody seems to have mentioned RFC 4038, which makes this very clear. >> These addresses are an artefact and have no place in the routing >> system as such, and still less on the wire. >> >> Brian >> > . > From nobody Thu May 1 21:03:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251A31A090B for ; Thu, 1 May 2014 21:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwRxY5Vo_qRk for ; Thu, 1 May 2014 21:03: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 6BE181A08CF for ; Thu, 1 May 2014 21:03:01 -0700 (PDT) Received: from [10.5.16.141] (adsl-69-228-81-237.dsl.pltn13.pacbell.net [69.228.81.237]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s423w0ph005146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 1 May 2014 20:58:12 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s423w0ph005146 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1399003094; bh=3BmcdZ38OhNl5JmDlqOXfEG8pbc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=BYJML+yUEmajx3e9NfYJa3IjBchGe9nNtctRNGU3WuNfijDYPOUqKYY5HSGqX+aSA 52RqRUv/6AlIstCKub+iXF9a+qGdxskOFZ8AmnwUDAFz+r2pzBFU8QXnSe2B6d8TfP QLklDGACNmqaQmeASoPB3FI9q3+8bZO6HhDC+avU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <5362CFFC.2040609@bogus.com> Date: Thu, 1 May 2014 20:57:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <40C41DA9-3513-4BC3-B6C9-7A1EEF98BBC7@cisco.com> <5361DBFA.3010403@bogus.com> <5362CFFC.2040609@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 01 May 2014 20:58:14 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/J71hD-bJ5_YKU2Y-MRlywVp0r60 Cc: V6 Ops List , "Byrne, Cameron" Subject: Re: [v6ops] Thoughts on draft-byrne-v6ops-clatip-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 04:03:03 -0000 > fec0::/10 was reserved way back in rfc 1884 >=20 > 3879 and 4193 are contemporaneous activities. meany people on this = list > were present for them. >=20 > The fact that we did a bad job at something 20 years ago doesn't mean > the problem that we were attempting to address went away. I agree=85 People wanting to do NAT rather than learn how to do things = better without it is an education problem which continues to persist to = this day. Owen From nobody Sat May 3 17:47:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D351A013E for ; Sat, 3 May 2014 17:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.902 X-Spam-Level: * X-Spam-Status: No, score=1.902 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSXaRxNJSQ48 for ; Sat, 3 May 2014 17:47:49 -0700 (PDT) Received: from nm14-vm0.bullet.mail.bf1.yahoo.com (nm14-vm0.bullet.mail.bf1.yahoo.com [98.139.213.164]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADC41A013D for ; Sat, 3 May 2014 17:47:49 -0700 (PDT) Received: from [98.139.215.140] by nm14.bullet.mail.bf1.yahoo.com with NNFMP; 04 May 2014 00:47:46 -0000 Received: from [98.139.212.200] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 04 May 2014 00:47:46 -0000 Received: from [127.0.0.1] by omp1009.mail.bf1.yahoo.com with NNFMP; 04 May 2014 00:47:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 226371.16547.bm@omp1009.mail.bf1.yahoo.com Received: (qmail 61931 invoked by uid 60001); 4 May 2014 00:47:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1399164466; bh=NXYzWX+7IQXGDtiSgfqQdCpZDiU3ZEQIHfrT33Xgsqs=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bBNSXKTjh+ep+p0ixrdbhDcljSgWFej7NfpkfkXUZES2XMSHVjtM7mPEJtB+vkb+9JFPeoYRv35sfnmDuTjdRu6wk5b6t4lYx0Ww15SK8OmZ5mAyVdzxXx4T+eWqadVtg6950eiRVFRaK4rpvS4cno38PTkRQIAJyfu6XPXhjng= X-YMail-OSG: EB45.zEVM1mTm5cBtsgoyTRbB96cn9veZy3yq.cpSkWmn.y QKS760tyLcxZIzUQSS7Mj06tHbpwm.4cFTpFo2ZKhdIdc6VQY7SE3CbWQT5E jSlj2GB_kBZdefRzYXXEiH56w7rOkhmgX2cV3KTF_wTSmDRulLJOfXQXy2DT 1GUqiVoJCu.HBrTi47iieo33nT9C0cV0faWGT.OgllVunz1T.3Nlk0pWAKiD KhDdXKgoBvUqNFCFxQFY7hoyhFAcsn1V0BhtWLYNbYs2xOImUgdCfrsEwBEy V_xbel5.H5qJ.lFoh.RjuTLZOtV4y9Zzh9PXp.oW.ZmMmJJMs3tyY9oZl_z7 sHCVwsQ6IVrOZuFLYAJh1HgAVXmWnyxvyTBAnaZ0UBui9atz.FP_jYfjx7Z7 bAHW.TdEaCe4PZDGATJhsFd7S9qJgUBTF14tH7VRN43San25ZwAXLLQbItdM GbyccZhssaZFVe36z0lmOvwqPb7VEBr_ZfDLoAYIpJ_HjkI11J4KQe4kVml_ 1cSQxjP790sxHe0MDEKhba63C.TicHK3WndkY7b9BZJABrBH_kffCYrbBq_F 6d4P1NdDMakAQZSavN41ntm_skzAtp.bcPsKKhloKaH8ngPWRGKF..Bkz Received: from [150.101.221.237] by web162201.mail.bf1.yahoo.com via HTTP; Sat, 03 May 2014 17:47:46 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBPd2VuIERlTG9uZyA8b3dlbkBkZWxvbmcuY29tPgo.IFRvOiBqb2VsIGphZWdnbGkgPGpvZWxqYUBib2d1cy5jb20.Cj4gQ2M6IFY2IE9wcyBMaXN0IDx2Nm9wc0BpZXRmLm9yZz47ICJCeXJuZSwgQ2FtZXJvbiIgPENhbWVyb24uQnlybmVAdC1tb2JpbGUuY29tPgo.IFNlbnQ6IEZyaWRheSwgMiBNYXkgMjAxNCA4OjMxIEFNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gVGhvdWdodHMgb24gZHJhZnQtYnlybmUtdjZvcHMtY2xhdGlwLTAxCj4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: <40C41DA9-3513-4BC3-B6C9-7A1EEF98BBC7@cisco.com> <5361DBFA.3010403@bogus.com> Message-ID: <1399164466.73074.YahooMailNeo@web162201.mail.bf1.yahoo.com> Date: Sat, 3 May 2014 17:47:46 -0700 (PDT) From: Mark ZZZ Smith To: Owen DeLong , joel jaeggli In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-MvCzXJzPKE6tDc1Nat9Q3oBq9E Cc: V6 Ops List , "Byrne, Cameron" Subject: Re: [v6ops] Thoughts on draft-byrne-v6ops-clatip-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 00:47:50 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Owen DeLong =0A> To: joel jaeggli =0A> Cc: V6 Ops List ; "Byrne, Cameron" =0A> Sent: Friday, 2 = May 2014 8:31 AM=0A> Subject: Re: [v6ops] Thoughts on draft-byrne-v6ops-cla= tip-01=0A> =0A> =0A> On Apr 30, 2014, at 10:30 PM, joel jaeggli wrote:=0A> =0A>> On 4/30/14, 7:55 PM, Lorenzo Colitti wrote:=0A>>>= On Thu, May 1, 2014 at 8:24 AM, Fred Baker (fred) >> = > wrote:=0A>>> =0A>>> =C2=A0 Ask me someday what th= oughts go through my mind about applications=0A>>> =C2=A0 making inference= s from network layer addresses.=0A>>> =0A>>> =0A>>> The wording in RFC 392= 7 is much stronger. For example, it states=0A>>> multiple times that packe= ts sourced from 169.254/16 MUST NOT be=0A>>> forwarded, and that they MUST= NOT ever be sent to any router for=0A>>> forwarding. I think it's perfect= ly reasonable for an app (or even =0A> an=0A>>> OS!) to assume that such a= ddresses have no connectivity.=0A>>> =0A>>> =0A>>> =C2=A0 Hey, 192.168.0.0= /16 is for networks that=0A>>> =C2=A0 don=E2=80=99t= connect to the Internet. You want proof? From RFC 1918, the=0A>>> =C2=A0 = motivation is=0A>>> =0A>>> =C2=A0 =C2=A0 =C2=A0 With the proliferation of T= CP/IP technology worldwide, including=0A>>> =C2=A0 =C2=A0 =C2=A0 outside th= e Internet itself, an increasing number of non-connected=0A>>> =C2=A0 =C2= =A0 =C2=A0 enterprises use this technology and its addressing capabilities = =0A> for=0A>>> =C2=A0 =C2=A0 =C2=A0 sole intra-enterprise communications, w= ithout any intention to =0A> ever=0A>>> =C2=A0 =C2=A0 =C2=A0 directly conne= ct to other enterprises or the Internet itself.=0A>>> =0A>>> =0A>>> Funny,= that's what the proponents of ULA-only networks say too - =0A> "no,=0A>>> = this network will NEVER connect to the Internet, ever!!11" I =0A> suspect= =0A>>> they do so because they know that saying "we want to use NAT to =0A= > connect=0A>>> this network to the Internet like we do in IPv4" is going = to =0A> result in=0A>>> strong opinions and removal of support for the use= case. But that's=0A>>> off-topic here.=0A>> =0A>> site-local unicast in = ipv6=C2=A0 and rfc 1918 are relatively contemporaneous=0A>> ideas...=0A>> = =0A>> I don't thing the pressures that produce such solutions are =0A> par= ticularly=0A>> new in fact it's pretty easy to assert that they co-evolved= .=0A> =0A> Yes, but unlike RFC-1918, we came to our senses and deprecated s= ite-local.=0A> =0A> ULA came later as a result of pressure from people who = loved their NAT.=C2=A0=0A=0AThat's not correct. As I remember it ULAs were = a solution to the drawbacks of site-locals (the discussions of both took to= pics place in mid to late 2002). Site-locals were deprecated because ULAs h= ad been defined to take their place. The main attribute of ULAs - the rando= m ID component - is there to eliminate the ambiguity that site-locals had, = which would have caused people to deploy NAT when interconnecting two diffe= rent site-local domains. There were other reasons site-locals were deprecat= ed:=0A=0ADeprecating Site Local Addresses=0Ahttps://tools.ietf.org/rfc/rfc3= 879.txt=0A=0A(which can also be used a good guide to the drawbacks of RFC19= 18s)=C2=A0=0A=0A> Sad, =0A> really, that the problem was not addressed thro= ugh education instead of better =0A> RIR policies for global unicast.=0A>= =C2=A0=0A=0AI'm pretty sure the people involved in the ULA/site-local discu= ssions well and truly know about global addressing and its benefits and dra= wbacks.=C2=A0=0A=0AYour assertion seems to be that global only addressing w= ould make NAT non-existent and that ULAs will ensure it does. People have c= hosen to deploy NAT/NAPT in IPv4 networks to attempt to solve more than jus= t the lack of public IPv4 addresses problem. Plentiful and relatively cheap= global IPv6 addresses won't address these other needs. Work such as RFC486= 4 or DHCPv6-PD will.=0A=0ARegards,=0AMark From nobody Sat May 3 18:41:49 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8D11A0150 for ; Sat, 3 May 2014 18:41:47 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIPH9eLfREbE for ; Sat, 3 May 2014 18:41:45 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A1C841A014D for ; Sat, 3 May 2014 18:41:45 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id kx10so4752197pab.33 for ; Sat, 03 May 2014 18:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=baG/dmgdVBby9q6q654wXm0lLX5NPl5/sEBzeaBnmBk=; b=BWMN0y62YGD5PuS/a/Xy0dfgujwjJjWmRr5VcGLsJzDJUaBAEdrOqji5NeN4yqV+mw wCoR+zNIXIom0ego3AA8YuIfLLwdqFCPWA45SsKZptGPZRA85Xd92K2Vu1H3dzhcXgDh DGt18ZkOev1k+J6m4TTIn4aSPTsztbI81ii6f80tsYU4n6Dbv2Pb+EQono227a1wrdSx fCI75S84TI2W/P1kWXieLvZNUzeh4jSlJCrrORBpuzv6mXZmBDZctPCh2pOdHXFByQje Ppt2TuPiLVpMCNqo8SbqTV+ukxhIFX70dvi61wqxtaTut9FKUlW8RifxBSbXy13sUgDr 12Ug== X-Received: by 10.66.177.168 with SMTP id cr8mr54133264pac.128.1399167702755; Sat, 03 May 2014 18:41:42 -0700 (PDT) Received: from [192.168.178.20] (23.195.69.111.dynamic.snap.net.nz. [111.69.195.23]) by mx.google.com with ESMTPSA id xr9sm31612763pab.5.2014.05.03.18.41.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 03 May 2014 18:41:42 -0700 (PDT) Message-ID: <53659AD2.1070802@gmail.com> Date: Sun, 04 May 2014 13:41:38 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark ZZZ Smith References: <40C41DA9-3513-4BC3-B6C9-7A1EEF98BBC7@cisco.com> <5361DBFA.3010403@bogus.com> <1399164466.73074.YahooMailNeo@web162201.mail.bf1.yahoo.com> In-Reply-To: <1399164466.73074.YahooMailNeo@web162201.mail.bf1.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DKQjQFnGUKrS2Jjw9BcTcwPNdB8 Cc: V6 Ops List , "Byrne, Cameron" Subject: Re: [v6ops] Thoughts on draft-byrne-v6ops-clatip-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 01:41:47 -0000 On 04/05/2014 12:47, Mark ZZZ Smith wrote: >=20 >=20 >=20 > ----- Original Message ----- >> From: Owen DeLong >> To: joel jaeggli >> Cc: V6 Ops List ; "Byrne, Cameron" >> Sent: Friday, 2 May 2014 8:31 AM >> Subject: Re: [v6ops] Thoughts on draft-byrne-v6ops-clatip-01 >> >> >> On Apr 30, 2014, at 10:30 PM, joel jaeggli wrote: >> >>> On 4/30/14, 7:55 PM, Lorenzo Colitti wrote: >>>> On Thu, May 1, 2014 at 8:24 AM, Fred Baker (fred) >>> > wrote: >>>> >>>> Ask me someday what thoughts go through my mind about application= s >>>> making inferences from network layer addresses. >>>> >>>> >>>> The wording in RFC 3927 is much stronger. For example, it states >>>> multiple times that packets sourced from 169.254/16 MUST NOT be >>>> forwarded, and that they MUST NOT ever be sent to any router for >>>> forwarding. I think it's perfectly reasonable for an app (or even=20 >> an >>>> OS!) to assume that such addresses have no connectivity. >>>> >>>> >>>> Hey, 192.168.0.0/16 is for networks that >>>> don=E2=80=99t connect to the Internet. You want proof? From RFC 1= 918, the >>>> motivation is >>>> >>>> With the proliferation of TCP/IP technology worldwide, includi= ng >>>> outside the Internet itself, an increasing number of non-conne= cted >>>> enterprises use this technology and its addressing capabilitie= s=20 >> for >>>> sole intra-enterprise communications, without any intention to= =20 >> ever >>>> directly connect to other enterprises or the Internet itself. >>>> >>>> >>>> Funny, that's what the proponents of ULA-only networks say too -=20 >> "no, >>>> this network will NEVER connect to the Internet, ever!!11" I=20 >> suspect >>>> they do so because they know that saying "we want to use NAT to=20 >> connect >>>> this network to the Internet like we do in IPv4" is going to=20 >> result in >>>> strong opinions and removal of support for the use case. But that's= >>>> off-topic here. >>> site-local unicast in ipv6 and rfc 1918 are relatively contemporane= ous >>> ideas... >>> >>> I don't thing the pressures that produce such solutions are=20 >> particularly >>> new in fact it's pretty easy to assert that they co-evolved. >> Yes, but unlike RFC-1918, we came to our senses and deprecated site-lo= cal. >> >> ULA came later as a result of pressure from people who loved their NAT= =2E=20 >=20 > That's not correct. As I remember it ULAs were a solution to the drawba= cks of site-locals (the discussions of both took topics place in mid to l= ate 2002). Site-locals were deprecated because ULAs had been defined to t= ake their place. The main attribute of ULAs - the random ID component - i= s there to eliminate the ambiguity that site-locals had, which would have= caused people to deploy NAT when interconnecting two different site-loca= l domains. There were other reasons site-locals were deprecated: >=20 > Deprecating Site Local Addresses > https://tools.ietf.org/rfc/rfc3879.txt >=20 > (which can also be used a good guide to the drawbacks of RFC1918s)=20 >=20 >> Sad,=20 >> really, that the problem was not addressed through education instead o= f better=20 >> RIR policies for global unicast. >> =20 >=20 > I'm pretty sure the people involved in the ULA/site-local discussions w= ell and truly know about global addressing and its benefits and drawbacks= =2E=20 >=20 > Your assertion seems to be that global only addressing would make NAT n= on-existent and that ULAs will ensure it does. People have chosen to depl= oy NAT/NAPT in IPv4 networks to attempt to solve more than just the lack = of public IPv4 addresses problem. Plentiful and relatively cheap global I= Pv6 addresses won't address these other needs. Work such as RFC4864 or DH= CPv6-PD will. Actually, one of the use cases for ULAs is to avoid the need for NATs in the case that two enterprise networks that have insisted on private addressing merge, or for some other reason need to route directly between= their private address spaces. Spare me the argument about not needing private addressing at all, becaus= e some enterprise network managers simply want it and aren't interested in the counter-arguments. Brian From nobody Sat May 3 20:25:48 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071171A0140 for ; Sat, 3 May 2014 20:25:46 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buuO1qh0L1ZO for ; Sat, 3 May 2014 20:25:44 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB441A0144 for ; Sat, 3 May 2014 20:25:44 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id w61so6207830wes.32 for ; Sat, 03 May 2014 20:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Uz3HNFQ2Kufn4AF0iI/J8Gg21GW48zEX+Zu6eaGQh5A=; b=GSYQLQTXP/xeVhEnJWHf6jR/MvELuIV1MT9GJYOztnOMg8DnGCrbTQiMzoy5v/NBgg PnK4X9IIZSOwc1MJiQIn/89DmfmnuwOy+C1UzICIGevdkI8rlu4MIF3bLG6fEsio3MXt vNl9idX6MJ7Sjn8ch2oZ12W6Ncu/o5ByI78U/OQIfiT7D704z538fqrrk+wp+tJI5vLn I31fR3wthjgImF2YH34uQ0NOJi6xqzTqBwODJ1wsBxirO8WzMWlxqPSWXX4o7s9515DL k5tvsSM4dFwVn1gF0l3sBjni5Bd479ZkJpL6fZ7zF+DDVylRU55+P457QhgOn8rulinq us5Q== MIME-Version: 1.0 X-Received: by 10.180.84.129 with SMTP id z1mr9754327wiy.8.1399173940851; Sat, 03 May 2014 20:25:40 -0700 (PDT) Received: by 10.217.61.198 with HTTP; Sat, 3 May 2014 20:25:40 -0700 (PDT) In-Reply-To: <53659AD2.1070802@gmail.com> References: <40C41DA9-3513-4BC3-B6C9-7A1EEF98BBC7@cisco.com> <5361DBFA.3010403@bogus.com> <1399164466.73074.YahooMailNeo@web162201.mail.bf1.yahoo.com> <53659AD2.1070802@gmail.com> Date: Sat, 3 May 2014 20:25:40 -0700 Message-ID: From: Ca By To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/MazPL2Ia8fh8jYU7FytoARR68Lg Cc: V6 Ops List , "Byrne, Cameron" Subject: Re: [v6ops] Thoughts on draft-byrne-v6ops-clatip-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 03:25:46 -0000 Folks, Feel free to start a new thread to talk about ULA vs the world. I don't believe it is relate to draft-byrne-v6ops-clatip-01 Regards, Cameron On Sat, May 3, 2014 at 6:41 PM, Brian E Carpenter wrote: > On 04/05/2014 12:47, Mark ZZZ Smith wrote: >> >> >> >> ----- Original Message ----- >>> From: Owen DeLong >>> To: joel jaeggli >>> Cc: V6 Ops List ; "Byrne, Cameron" >>> Sent: Friday, 2 May 2014 8:31 AM >>> Subject: Re: [v6ops] Thoughts on draft-byrne-v6ops-clatip-01 >>> >>> >>> On Apr 30, 2014, at 10:30 PM, joel jaeggli wrote: >>> >>>> On 4/30/14, 7:55 PM, Lorenzo Colitti wrote: >>>>> On Thu, May 1, 2014 at 8:24 AM, Fred Baker (fred) >>>> > wrote: >>>>> >>>>> Ask me someday what thoughts go through my mind about applications >>>>> making inferences from network layer addresses. >>>>> >>>>> >>>>> The wording in RFC 3927 is much stronger. For example, it states >>>>> multiple times that packets sourced from 169.254/16 MUST NOT be >>>>> forwarded, and that they MUST NOT ever be sent to any router for >>>>> forwarding. I think it's perfectly reasonable for an app (or even >>> an >>>>> OS!) to assume that such addresses have no connectivity. >>>>> >>>>> >>>>> Hey, 192.168.0.0/16 is for networks that >>>>> don=E2=80=99t connect to the Internet. You want proof? From RFC 19= 18, the >>>>> motivation is >>>>> >>>>> With the proliferation of TCP/IP technology worldwide, includin= g >>>>> outside the Internet itself, an increasing number of non-connec= ted >>>>> enterprises use this technology and its addressing capabilities >>> for >>>>> sole intra-enterprise communications, without any intention to >>> ever >>>>> directly connect to other enterprises or the Internet itself. >>>>> >>>>> >>>>> Funny, that's what the proponents of ULA-only networks say too - >>> "no, >>>>> this network will NEVER connect to the Internet, ever!!11" I >>> suspect >>>>> they do so because they know that saying "we want to use NAT to >>> connect >>>>> this network to the Internet like we do in IPv4" is going to >>> result in >>>>> strong opinions and removal of support for the use case. But that's >>>>> off-topic here. >>>> site-local unicast in ipv6 and rfc 1918 are relatively contemporaneo= us >>>> ideas... >>>> >>>> I don't thing the pressures that produce such solutions are >>> particularly >>>> new in fact it's pretty easy to assert that they co-evolved. >>> Yes, but unlike RFC-1918, we came to our senses and deprecated site-loc= al. >>> >>> ULA came later as a result of pressure from people who loved their NAT. >> >> That's not correct. As I remember it ULAs were a solution to the drawbac= ks of site-locals (the discussions of both took topics place in mid to late= 2002). Site-locals were deprecated because ULAs had been defined to take t= heir place. The main attribute of ULAs - the random ID component - is there= to eliminate the ambiguity that site-locals had, which would have caused p= eople to deploy NAT when interconnecting two different site-local domains. = There were other reasons site-locals were deprecated: >> >> Deprecating Site Local Addresses >> https://tools.ietf.org/rfc/rfc3879.txt >> >> (which can also be used a good guide to the drawbacks of RFC1918s) >> >>> Sad, >>> really, that the problem was not addressed through education instead of= better >>> RIR policies for global unicast. >>> >> >> I'm pretty sure the people involved in the ULA/site-local discussions we= ll and truly know about global addressing and its benefits and drawbacks. >> >> Your assertion seems to be that global only addressing would make NAT no= n-existent and that ULAs will ensure it does. People have chosen to deploy = NAT/NAPT in IPv4 networks to attempt to solve more than just the lack of pu= blic IPv4 addresses problem. Plentiful and relatively cheap global IPv6 add= resses won't address these other needs. Work such as RFC4864 or DHCPv6-PD w= ill. > > Actually, one of the use cases for ULAs is to avoid the need for NATs > in the case that two enterprise networks that have insisted on private > addressing merge, or for some other reason need to route directly between > their private address spaces. > > Spare me the argument about not needing private addressing at all, becaus= e > some enterprise network managers simply want it and aren't interested > in the counter-arguments. > > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun May 4 01:02:49 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBF01A015F for ; Sun, 4 May 2014 01:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAKd8pXrjUyL for ; Sun, 4 May 2014 01:02:47 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id EB1CC1A00F9 for ; Sun, 4 May 2014 01:02:46 -0700 (PDT) Received: from [IPv6:2620::930:0:225:ff:fe44:af17] ([IPv6:2620:0:930:0:225:ff:fe44:af17]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s4480VUS014679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 4 May 2014 01:00:32 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s4480VUS014679 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1399190433; bh=xnyHqz45f3Iz/aqpiUMJS7GhWhE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Hhg8m4Ji+3GtsCygocYcUpJwU604cXHvV13Cc63LBu5wHJ9dJd5TYBUX9vavUHBVv GtdODqlM7AuTMGhOFiXKo5+jVcDxWkQ8/ZsCkOm8aN+aknP+IdNl9l+Byxz5u41LY7 fT4A926vpK+eoPXnvEx3akCq0+t0ooiUad13P06o= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <53659AD2.1070802@gmail.com> Date: Sun, 4 May 2014 01:04:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7BA49415-6F21-44F4-B857-5FED23A20352@delong.com> References: <40C41DA9-3513-4BC3-B6C9-7A1EEF98BBC7@cisco.com> <5361DBFA.3010403@bogus.com> <1399164466.73074.YahooMailNeo@web162201.mail.bf1.yahoo.com> <53659AD2.1070802@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sun, 04 May 2014 01:00:33 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/T9_SgrCXhoZJqb3ZECvHWHDvxes Cc: V6 Ops List , "Byrne, Cameron" Subject: Re: [v6ops] Thoughts on draft-byrne-v6ops-clatip-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 08:02:48 -0000 >=20 > Spare me the argument about not needing private addressing at all, = because > some enterprise network managers simply want it and aren't interested > in the counter-arguments. >=20 > Brian Thank you for proving my case that at least to some extent, determined = ignorance is a driving factor for ULA. Owen From nobody Sun May 4 05:14:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD85B1A0083 for ; Sun, 4 May 2014 05:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAmsANc_yV3F for ; Sun, 4 May 2014 05:14:42 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 10A591A0117 for ; Sun, 4 May 2014 05:14:42 -0700 (PDT) Received: from mb-aye.local (75-148-161-129-Houston.hfc.comcastbusiness.net [75.148.161.129]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s44CEXBw047873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 4 May 2014 12:14:34 GMT (envelope-from joelja@bogus.com) Message-ID: <53662F25.60609@bogus.com> Date: Sun, 04 May 2014 07:14:29 -0500 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Thunderbird/29.0 MIME-Version: 1.0 To: Owen DeLong , Brian E Carpenter References: <40C41DA9-3513-4BC3-B6C9-7A1EEF98BBC7@cisco.com> <5361DBFA.3010403@bogus.com> <1399164466.73074.YahooMailNeo@web162201.mail.bf1.yahoo.com> <53659AD2.1070802@gmail.com> <7BA49415-6F21-44F4-B857-5FED23A20352@delong.com> In-Reply-To: <7BA49415-6F21-44F4-B857-5FED23A20352@delong.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GVjaCJR40qKRmvNc3rCf8QLkm7hshRvUM" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Sun, 04 May 2014 12:14:35 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-Bw9tYbPusMTUzfXyj8_bma-_oY Cc: V6 Ops List , "Byrne, Cameron" Subject: [v6ops] Done now... Re: Thoughts on draft-byrne-v6ops-clatip-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 12:14:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GVjaCJR40qKRmvNc3rCf8QLkm7hshRvUM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I Think we can consider this discussion closed. discussion of the draft is fine. the ipv6 addressing architecture is not something we need to re-litigate to discuss it. Thanks joel On 5/4/14, 3:04 AM, Owen DeLong wrote: >=20 >> >> Spare me the argument about not needing private addressing at all, bec= ause >> some enterprise network managers simply want it and aren't interested >> in the counter-arguments. >> >> Brian >=20 > Thank you for proving my case that at least to some extent, determined = ignorance is a driving factor for ULA. >=20 > Owen >=20 >=20 --GVjaCJR40qKRmvNc3rCf8QLkm7hshRvUM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNmLyUACgkQ8AA1q7Z/VrLj6gCfSL0dR6SSt7gXC0MZ2TCWeDVm KPAAn2+uQoIsQ00flQ99tnEuoFK911AZ =v6Aq -----END PGP SIGNATURE----- --GVjaCJR40qKRmvNc3rCf8QLkm7hshRvUM-- From nobody Sun May 4 11:00:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B728A1A00E2 for ; Sun, 4 May 2014 11:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZ6lH7Da3uoj for ; Sun, 4 May 2014 11:00:30 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9651A00DE for ; Sun, 4 May 2014 11:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1297; q=dns/txt; s=iport; t=1399226427; x=1400436027; h=date:from:message-id:to:subject:cc; bh=bv/H6wMVCZAfNSTtObQ53UuWcjWWl6BJJYCUlZaALo8=; b=mnJOCGDuCRu8XyW97sP5mViGQkTAGTu05Rz+brfCnJQLM327cM3R5JbG y4QoHsf4ra1q6SlsVzPjIVT9lgZIB8qRq5kLPeZ0EREURaL65G7mwDBjm wtSqlekzZjk7EiKDBjoZAQKDKo7cdxEcvpgXnDJD34rxeRwAqzUJxA21V A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0KAPp/ZlOrRDoI/2dsb2JhbABSBoMGT64YAZcmgQ8WdIMlPDSJIQ7JexeOD0MdhCkEigeQaZE4g1Q X-IronPort-AV: E=Sophos;i="4.97,983,1389744000"; d="scan'208";a="108592627" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 04 May 2014 18:00:26 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s44I0NBm008363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2014 18:00:25 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id s44I0NIs002030; Sun, 4 May 2014 11:00:23 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id s44I0Mvh002013; Sun, 4 May 2014 11:00:22 -0700 (PDT) Date: Sun, 4 May 2014 11:00:22 -0700 (PDT) From: Fred Baker Message-Id: <201405041800.s44I0Mvh002013@irp-view13.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/PmqdKNuWCLdb82lDLUaKn6yK1LE Subject: [v6ops] draft-byrne-v6ops-clatip WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 18:00:32 -0000 This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-byrne-v6ops-clatip. This is unusual. Please bear with me here. We have discussed it several times. In March, the working group decided to offer it to softwire, whose chairs told me they wanted to take it on themselves and pursue it. However, it is HOL blocked by MAP, which they want to complete first. With their concurrence, noting that the working group has said in the past couple of weeks that it wants to finish it, we need to finish it here. My game plan is to collect comments on the existing draft, including any idnits issues, and have Cameron post an update named draft-ietf-v6ops-clatip - a working group draft. If that passes the smell test, we'll send it to Joel. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. From nobody Mon May 5 08:20:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0351A03BB for ; Mon, 5 May 2014 08:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.116 X-Spam-Level: X-Spam-Status: No, score=-1.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgXMgj0t_6G2 for ; Mon, 5 May 2014 08:20:30 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 941AE1A03BD for ; Mon, 5 May 2014 08:20:30 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.97,988,1389762000"; d="scan'208";a="298855186" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 05 May 2014 11:18:46 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Mon, 5 May 2014 11:19:30 -0400 From: "George, Wes" To: Fred Baker , "v6ops@ietf.org" Date: Mon, 5 May 2014 11:19:29 -0400 Thread-Topic: [v6ops] draft-byrne-v6ops-clatip WGLC Thread-Index: Ac9odWlEayjKINLpT6+vtoW1QkcXgg== Message-ID: References: <201405041800.s44I0Mvh002013@irp-view13.cisco.com> In-Reply-To: <201405041800.s44I0Mvh002013@irp-view13.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kXLfJXb3Ngczct2WCyoxHOoXPiA Subject: Re: [v6ops] draft-byrne-v6ops-clatip WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 15:20:32 -0000 SSBzdXBwb3J0IGFkb3B0aW9uL3B1YmxpY2F0aW9uIG9mIHRoaXMgZHJhZnQuIEkgdGhpbmsgaXTi gJlzIHVzZWZ1bCB0bw0KY29kaWZ5IHRoZSBibG9jayB0aGF0IGlzIGFscmVhZHkgYmVpbmcgdXNl ZCBpbiBhIHByb2R1Y3Rpb24gbmV0d29yayBzbw0KdGhhdCBvdGhlcnMgY2FuIHRha2UgYWR2YW50 YWdlIG9mIHRoaXMgaW1wbGVtZW50YXRpb24gZXhwZXJpZW5jZSwgYW5kDQp2Nm9wcyBpcyBhbiBh Y2NlcHRhYmxlIHBsYWNlIGluIHdoaWNoIHRvIGRvIGl0Lg0KDQpUaHJlZSBjb21tZW50czoNCg0K Rmlyc3QsIHRoaXMgZHJhZnQgbmVlZHMgdG8gZm9ybWFsbHkgdXBkYXRlIFJGQyA2MzMzIGluIGl0 cyBtZXRhZGF0YSwgYXMgSQ0KdGhpbmsgdGhlcmXigJlzIGEgbmVlZCBmb3IgYSBmb3JtYWwgbGlu ayBiZXR3ZWVuIHRoZSB0d28uDQoNClNlY29uZCwgdGhlcmUgaXMgYSBmYWlybHkgc21hbGwgZGlz Y3Vzc2lvbiBhYm91dCB0aGUgcG90ZW50aWFsIGNvbmZsaWN0DQpiZXR3ZWVuIERTTGl0ZSBhbmQg NDY0WExhdCB3aGVuIHRoZXkgYm90aCB1c2UgdGhpcyByZXNlcnZlZCBibG9jay4gUmlnaHQNCm5v dyBpdCBwcmltYXJpbHkgaW1wbGllcyB0aGF0IGl04oCZcyBvbmx5IGxvY2FsbHkgc2lnbmlmaWNh bnQsIHRodXMgYXZvaWRpbmcNCmdsb2JhbCBjb25mbGljdHMsIGJ1dCBJdCBtaWdodCBiZSB3b3J0 aCBleHBhbmRpbmcgaXQgYSBiaXQgdG8gZGlzY3VzcyB0aGUNCnNjb3BlIG9mIHRoYXQgc2lnbmlm aWNhbmNlIGluIGEgc2luZ2xlIG5ldHdvcmssIEkuZS4gZWl0aGVyIGV4cGxpY2l0bHkNCnJlY29t bWVuZCBhZ2FpbnN0IHVzaW5nIERTTGl0ZSBhbmQgNDY0WExhdCBvbiB0aGUgc2FtZSBuZXR3b3Jr L3JvdXRpbmcNCmRvbWFpbiwgb3IgdG8gZXhwbGljaXRseSBjb25maXJtIHRoYXQgdGhpcyB3aWxs IHdvcmssIGRpc2N1c3MgYW55IGRlc2lnbg0KY29uc2lkZXJhdGlvbnMgKHN1Y2ggYXMgbG9jYXRp b24gb3IgaXNvbGF0aW9uIG9mIHRoZSByb3V0aW5nIGRvbWFpbg0KYmV0d2VlbiB0aGUgQjQgYW5k IHRoZSBBRlRSKSB0byBhdm9pZCBjb25mbGljdHMuDQoNCkxhc3RseSwgSeKAmW0gbm90IHN1cmUg YWJvdXQgdGhlIOKAnElQdjYgdHJhbnNpdGlvbmFsIFRlY2hub2xvZ3kgSVB2NCBQcmVmaXjigJ0N CmRlc2lnbmF0aW9uLCBhcyB0aGlzIGNvdWxkIGxlYWQgdG8gY29uZnVzaW9uIGJ5IGltcGx5aW5n IHRoYXQgaXQgaXMNCmFwcHJvcHJpYXRlIHRvIGJlIHVzZWQgZm9yIGFueSBJUHY2IHRyYW5zaXRp b24gdGVjaG5vbG9neSB0aGF0IG5lZWRzIGENCnNtYWxsIElQdjQgcHJlZml4LiBUaGF0IG1heSBi ZSB0cnVlLCBidXQgaXQgYWxzbyBtYXkgbm90IGJlLCBzbyBzb21lDQphZGRpdGlvbmFsIGxhbmd1 YWdlIGNsYXJpZnkgd2hhdCB5b3UgbWVhbiBhbmQgcmVjb21tZW5kaW5nIHRoYXQgb3RoZXINCnBv dGVudGlhbCB1c2VzIGZvciB0aGlzIGFkZHJlc3Mgc3BhY2Ugc2hvdWxkIGJlIHNlcGFyYXRlbHkg ZXZhbHVhdGVkIG1pZ2h0DQpiZSBhIGdvb2QgaWRlYS4NCg0KVGhhbmtzLA0KDQpXZXMNCg0KDQoN Ck9uIDUvNC8xNCwgMjowMCBQTSwgIkZyZWQgQmFrZXIiIDxmcmVkQGNpc2NvLmNvbT4gd3JvdGU6 DQoNCj5UaGlzIGlzIHRvIGluaXRpYXRlIGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNh bGwgb2YNCj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ieXJuZS12Nm9wcy1jbGF0 aXAuDQo+DQo+VGhpcyBpcyB1bnVzdWFsLiBQbGVhc2UgYmVhciB3aXRoIG1lIGhlcmUuIFdlIGhh dmUgZGlzY3Vzc2VkIGl0IHNldmVyYWwNCj50aW1lcy4gSW4gTWFyY2gsIHRoZSB3b3JraW5nIGdy b3VwIGRlY2lkZWQgdG8gb2ZmZXIgaXQgdG8gc29mdHdpcmUsDQo+d2hvc2UgY2hhaXJzIHRvbGQg bWUgdGhleSB3YW50ZWQgdG8gdGFrZSBpdCBvbiB0aGVtc2VsdmVzIGFuZCBwdXJzdWUNCj5pdC4g IEhvd2V2ZXIsIGl0IGlzIEhPTCBibG9ja2VkIGJ5IE1BUCwgd2hpY2ggdGhleSB3YW50IHRvIGNv bXBsZXRlDQo+Zmlyc3QuIFdpdGggdGhlaXIgY29uY3VycmVuY2UsIG5vdGluZyB0aGF0IHRoZSB3 b3JraW5nIGdyb3VwIGhhcyBzYWlkDQo+aW4gdGhlIHBhc3QgY291cGxlIG9mIHdlZWtzIHRoYXQg aXQgd2FudHMgdG8gZmluaXNoIGl0LCB3ZSBuZWVkIHRvDQo+ZmluaXNoIGl0IGhlcmUuDQo+DQo+ TXkgZ2FtZSBwbGFuIGlzIHRvIGNvbGxlY3QgY29tbWVudHMgb24gdGhlIGV4aXN0aW5nIGRyYWZ0 LCBpbmNsdWRpbmcNCj5hbnkgaWRuaXRzIGlzc3VlcywgYW5kIGhhdmUgQ2FtZXJvbiBwb3N0IGFu IHVwZGF0ZSBuYW1lZA0KPmRyYWZ0LWlldGYtdjZvcHMtY2xhdGlwIC0gYSB3b3JraW5nIGdyb3Vw IGRyYWZ0LiBJZiB0aGF0IHBhc3NlcyB0aGUNCj5zbWVsbCB0ZXN0LCB3ZSdsbCBzZW5kIGl0IHRv IEpvZWwuDQo+DQo+UGxlYXNlIHJlYWQgaXQgbm93LiBJZiB5b3UgZmluZCBuaXRzIChzcGVsbGlu ZyBlcnJvcnMsIG1pbm9yIHN1Z2dlc3RlZA0KPndvcmRpbmcgY2hhbmdlcywgZXRjKSwgY29tbWVu dCB0byB0aGUgYXV0aG9yczsgaWYgeW91IGZpbmQgZ3JlYXRlcg0KPmlzc3Vlcywgc3VjaCBhcyBk aXNhZ3JlZWluZyB3aXRoIGEgc3RhdGVtZW50IG9yIGZpbmRpbmcgYWRkaXRpb25hbA0KPmlzc3Vl cyB0aGF0IG5lZWQgdG8gYmUgYWRkcmVzc2VkLCBwbGVhc2UgcG9zdCB5b3VyIGNvbW1lbnRzIHRv IHRoZQ0KPmxpc3QuDQo+DQo+V2UgYXJlIGxvb2tpbmcgc3BlY2lmaWNhbGx5IGZvciBjb21tZW50 cyBvbiB0aGUgaW1wb3J0YW5jZSBvZiB0aGUNCj5kb2N1bWVudCBhcyB3ZWxsIGFzIGl0cyBjb250 ZW50LiBJZiB5b3UgaGF2ZSByZWFkIHRoZSBkb2N1bWVudCBhbmQNCj5iZWxpZXZlIGl0IHRvIGJl IG9mIG9wZXJhdGlvbmFsIHV0aWxpdHksIHRoYXQgaXMgYWxzbyBhbiBpbXBvcnRhbnQNCj5jb21t ZW50IHRvIG1ha2UuDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj52Nm9wcyBtYWlsaW5nIGxpc3QNCj52Nm9wc0BpZXRmLm9yZw0KPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0KDQpUaGlzIEUtbWFpbCBhbmQg YW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9w cmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBv ciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRo aXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVh bCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmll ZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlv biB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRv IHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5h bCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg== From nobody Mon May 5 11:47:57 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B3C1A0443; Mon, 5 May 2014 11:47:52 -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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acp_mtDqr5gN; Mon, 5 May 2014 11:47:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 395B31A044A; Mon, 5 May 2014 11:47:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140505184745.30585.88926.idtracker@ietfa.amsl.com> Date: Mon, 05 May 2014 11:47:45 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6bWCUxZpBrxWCo3L8RrZvAaPqtE Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-clatip-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 18:47:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv4 Service Continuity Prefix Author : Cameron Byrne Filename : draft-ietf-v6ops-clatip-00.txt Pages : 4 Date : 2014-05-05 Abstract: DS-Lite, defined in RFC 6333, directs IANA to reserve 192.0.0.0/29 for the B4 element. This memo directs IANA to generalize that reservation to include other cases where a non-routed IPv4 interface must be numbered as part of an IPv6 transition solution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-clatip/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-clatip-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 5 13:00:17 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0571A0189 for ; Mon, 5 May 2014 13:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KKpyG8R-x7n for ; Mon, 5 May 2014 13:00:13 -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 72CAF1A0156 for ; Mon, 5 May 2014 13:00:13 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id k48so7908056wev.5 for ; Mon, 05 May 2014 13:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UR6f/EXwKP+N2I9NaPvSyUJUvLgc7vSXKtZ9GBIso44=; b=R69w6/opLCA4t1ZQYRKEJwrvzHmCsN47z8Hndp9LWIFwWw4OFrf5QERaHpQH9Ixw3J 4TiWQDphykq9XjYGBXbuOpiUR9fQ8T/bzX0oyQD9SwJhHqlaB9p3xN0Ufvf8Zx1QFUgV Vqn+e+wWsASEnPFpsmNHriOq9N3vqToCiKuNPi4+5klM9LNLoqLBtwqRa6oEDhXgnMb7 6hBtQAoOJhBbXIYxHqo10X8vdBRltOdcD7TrCHC+Z7ZuIiEgD/vbJPKKV9Ybr9QJ/kuR 0h6Y6FfgR5iU2+mAElbSH8dBGcmJ0kE8Lf3P7K//PuQE35aKVtlvy96O11LrZfHkxDdG jUOg== MIME-Version: 1.0 X-Received: by 10.194.171.198 with SMTP id aw6mr29427421wjc.23.1399320009404; Mon, 05 May 2014 13:00:09 -0700 (PDT) Received: by 10.217.61.198 with HTTP; Mon, 5 May 2014 13:00:09 -0700 (PDT) In-Reply-To: References: <201405041800.s44I0Mvh002013@irp-view13.cisco.com> Date: Mon, 5 May 2014 13:00:09 -0700 Message-ID: From: Ca By To: "George, Wes" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1eHCIxhHGBeSF-GFkdDll8A2cfs Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-byrne-v6ops-clatip WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 20:00:15 -0000 Thanks the comments Wes. On Mon, May 5, 2014 at 8:19 AM, George, Wes wro= te: > I support adoption/publication of this draft. I think it=E2=80=99s useful= to > codify the block that is already being used in a production network so > that others can take advantage of this implementation experience, and > v6ops is an acceptable place in which to do it. > > Three comments: > > First, this draft needs to formally update RFC 6333 in its metadata, as I > think there=E2=80=99s a need for a formal link between the two. > I humbly disagree. Nothing changes in DS-lite or RFC6333 as function of draft-ietf-v6ops-clatip-00. What does change is the IANA registery of 192.0.0.0/29 to be more general and serve a super set of scenarios, and that change will be reflected there in IANA, not in DS-lite. I am open to other opinions on this, but mine is that RFC6333 updated IANA and draft-ietf-v6ops-clatip-00 updates IANA again. draft-ietf-v6ops-clatip-00 does not update RFC6333 > Second, there is a fairly small discussion about the potential conflict > between DSLite and 464XLat when they both use this reserved block. Right > now it primarily implies that it=E2=80=99s only locally significant, thus= avoiding > global conflicts, but It might be worth expanding it a bit to discuss the > scope of that significance in a single network, I.e. either explicitly > recommend against using DSLite and 464XLat on the same network/routing > domain, or to explicitly confirm that this will work, discuss any design > considerations (such as location or isolation of the routing domain > between the B4 and the AFTR) to avoid conflicts. > I have added some new text to http://tools.ietf.org/html/draft-ietf-v6ops-clatip-00 " It is important that a host never be deployed with 2 active IPv4 continuity solutions simultaneously in a way that would cause a node to have overlapping address from 192.0.0.0/29." > Lastly, I=E2=80=99m not sure about the =E2=80=9CIPv6 transitional Technol= ogy IPv4 Prefix=E2=80=9D > designation, as this could lead to confusion by implying that it is > appropriate to be used for any IPv6 transition technology that needs a > small IPv4 prefix. That may be true, but it also may not be, so some > additional language clarify what you mean and recommending that other > potential uses for this address space should be separately evaluated migh= t > be a good idea. > Mohamed Boucadair has suggested "IPv4 Service Continuity Prefix" so i adopted in the latest WG I-D. This additional text was also added to provide scope. "The result is that 192.0.0.0/29 may be used in any system that requires IP= v4 addresses for backward compatibility with IPv4 communications in an IPv6-only network, but does not emit IPv4 packets "on the wire"." Thanks again for the feedback. CB > Thanks, > > Wes > > > > On 5/4/14, 2:00 PM, "Fred Baker" wrote: > >>This is to initiate a two week working group last call of >>http://tools.ietf.org/html/draft-byrne-v6ops-clatip. >> >>This is unusual. Please bear with me here. We have discussed it several >>times. In March, the working group decided to offer it to softwire, >>whose chairs told me they wanted to take it on themselves and pursue >>it. However, it is HOL blocked by MAP, which they want to complete >>first. With their concurrence, noting that the working group has said >>in the past couple of weeks that it wants to finish it, we need to >>finish it here. >> >>My game plan is to collect comments on the existing draft, including >>any idnits issues, and have Cameron post an update named >>draft-ietf-v6ops-clatip - a working group draft. If that passes the >>smell test, we'll send it to Joel. >> >>Please read it now. If you find nits (spelling errors, minor suggested >>wording changes, etc), comment to the authors; if you find greater >>issues, such as disagreeing with a statement or finding additional >>issues that need to be addressed, please post your comments to the >>list. >> >>We are looking specifically for comments on the importance of the >>document as well as its content. If you have read the document and >>believe it to be of operational utility, that is also an important >>comment to make. >> >>_______________________________________________ >>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 prop= rietary information, which is privileged, confidential, or subject to copyr= ight 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 t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately 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 From nobody Mon May 5 14:04:57 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7121A0438 for ; Mon, 5 May 2014 14:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.416 X-Spam-Level: X-Spam-Status: No, score=-0.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9JHKwV4rgc6 for ; Mon, 5 May 2014 14:04:52 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 582381A041B for ; Mon, 5 May 2014 14:04:52 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.97,991,1389762000"; d="scan'208";a="291699469" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 05 May 2014 17:03:59 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Mon, 5 May 2014 17:04:48 -0400 From: "George, Wes" To: Ca By Date: Mon, 5 May 2014 17:04:46 -0400 Thread-Topic: [v6ops] draft-byrne-v6ops-clatip WGLC Thread-Index: Ac9opaW1s13wZm8nRgqaO5UjZDMvbQ== Message-ID: References: <201405041800.s44I0Mvh002013@irp-view13.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/L6MMBy2MeEXAI_DkxB8K9cl-KIU Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-byrne-v6ops-clatip WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 21:04:53 -0000 DQpPbiA1LzUvMTQsIDQ6MDAgUE0sICJDYSBCeSIgPGNiLmxpc3Q2QGdtYWlsLmNvbT4gd3JvdGU6 DQoNCj4+DQo+PiBGaXJzdCwgdGhpcyBkcmFmdCBuZWVkcyB0byBmb3JtYWxseSB1cGRhdGUgUkZD IDYzMzMgaW4gaXRzIG1ldGFkYXRhLCBhcw0KPj5JDQo+PiB0aGluayB0aGVyZeKAmXMgYSBuZWVk IGZvciBhIGZvcm1hbCBsaW5rIGJldHdlZW4gdGhlIHR3by4NCj4+DQo+DQo+SSBodW1ibHkgZGlz YWdyZWUuICBOb3RoaW5nIGNoYW5nZXMgaW4gRFMtbGl0ZSBvciBSRkM2MzMzIGFzIGZ1bmN0aW9u DQo+b2YgZHJhZnQtaWV0Zi12Nm9wcy1jbGF0aXAtMDAuDQo+DQo+V2hhdCBkb2VzIGNoYW5nZSBp cyB0aGUgSUFOQSByZWdpc3Rlcnkgb2YgMTkyLjAuMC4wLzI5IHRvIGJlIG1vcmUNCj5nZW5lcmFs IGFuZCBzZXJ2ZSBhIHN1cGVyIHNldCBvZiBzY2VuYXJpb3MsIGFuZCB0aGF0IGNoYW5nZSB3aWxs IGJlDQo+cmVmbGVjdGVkIHRoZXJlIGluIElBTkEsIG5vdCBpbiBEUy1saXRlLg0KPg0KPkkgYW0g b3BlbiB0byBvdGhlciBvcGluaW9ucyBvbiB0aGlzLCBidXQgbWluZSBpcyB0aGF0IFJGQzYzMzMg dXBkYXRlZA0KPklBTkEgYW5kIGRyYWZ0LWlldGYtdjZvcHMtY2xhdGlwLTAwIHVwZGF0ZXMgSUFO QSBhZ2Fpbi4NCj5kcmFmdC1pZXRmLXY2b3BzLWNsYXRpcC0wMCBkb2VzIG5vdCB1cGRhdGUgUkZD NjMzMw0KDQpBIGZhaXIgcG9pbnQuIEkgYWdyZWUgdGhhdCB0aGUgZGlyZWN0aW9uIHRvIElBTkEg ZG9lc27igJl0IGV4cGxpY2l0bHkNCnJlcXVpcmUgYW4gdXBkYXRlIHRvIDYzMzMgYW5kIHlvdeKA mXJlIG5vdCByZWFsbHkgY2hhbmdpbmcgRFNMaXRlLiBNeQ0KdGhvdWdodCB3YXMgbW9yZSBmcm9t IHRoZSBwZXJzcGVjdGl2ZSB0aGF0IG9yaWdpbmFsbHkgNjMzMyB3YXMgd3JpdHRlbg0KYXNzdW1p bmcgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYmxvY2ssIGFuZCBpdCBubyBsb25nZXIgaGFzIGl0LiBT aW5jZSB0aGVyZQ0KYXJlIGF0IGxlYXN0IHNtYWxsIGNvbnNpZGVyYXRpb25zIGFib3V0IG92ZXJs YXAsIGl04oCZcyB3b3J0aCB0aGUgRFNMaXRlIGRvYw0KaGF2aW5nIGEgbGluayB0byB0aGlzIG9u ZSBmb3IgdGhvc2UgaW1wbGVtZW50aW5nIERTTGl0ZSB0aGF0IG1heSBub3QgYmUNCmF3YXJlIG9m IHRoaXMgY2hhbmdlLg0KDQpXZXMNCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1h dGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNv cHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGlu dGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8g d2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNz ZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxh dGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlz IHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkg b2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg== From nobody Mon May 5 15:43:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC531A0461 for ; Mon, 5 May 2014 15:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-s2jz2e3F3E for ; Mon, 5 May 2014 15:43:26 -0700 (PDT) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA0C1A01CB for ; Mon, 5 May 2014 15:43:26 -0700 (PDT) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 5 May 2014 17:43:20 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ie0-f169.google.com [209.85.223.169] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ie0-f169.google.com with SMTP id rl12so8960014iec.0 for ; Mon, 05 May 2014 15:43:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ojqx1iOfgR1kIZQ2qX0j5dKurdM+CVPTrENiwc9YMbQ=; b=W+6Y5GAcczS1ocQdyMqSnSOs4iJX8YagUcceePyOahC2hUjqESDw+ScUtm6bkz1Zmo 6mogRg2L4P92FKcwPu08x1Yay28b/G84vthBTQNoEbz4qInkHwGsjig8U1uhVvJDeurG FPolmeksweEmuHKZgQcmlY7PRnvNp9XCmBm7wkGdfjGAhL2yrCaxm5RwJ8UTQgrjMvYH rZ7IFUdsS+wlnvl/WkUNW9DSfvInQRxEwzI8J1IgviP3XyBmJph8N6O1vbFZDvFrbfsD jRy5mqxkDhF+wlM54lmhCEb4Km5CEKKp8RPRb7D0ld2O6aQyEpQWjAnRcuya5IygK+4E 7p9Q== X-Gm-Message-State: ALoCoQn3ZwT6EvR6Oq4eKwhgxLMqI6SWoOjsONxkKU3ScY7mnyGu1Y0MCgDhTY/5CeA9Jkh081UCk69nXSjuMWyZaYre0vvxk9x60saOlVm9qvWjUZLQwVY= X-Received: by 10.43.80.5 with SMTP id zs5mr6445691icb.72.1399329800115; Mon, 05 May 2014 15:43:20 -0700 (PDT) X-Received: by 10.43.80.5 with SMTP id zs5mr6445680icb.72.1399329799965; Mon, 05 May 2014 15:43:19 -0700 (PDT) Received: from x-160-94-246-71.uofm-secure.wireless.umn.edu (x-160-94-246-71.uofm-secure.wireless.umn.edu. [160.94.246.71]) by mx.google.com with ESMTPSA id ii6sm6559646igb.17.2014.05.05.15.43.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 May 2014 15:43:18 -0700 (PDT) Message-ID: <53681403.8010205@umn.edu> Date: Mon, 05 May 2014 17:43:15 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "George, Wes" , Fred Baker , "v6ops@ietf.org" References: <201405041800.s44I0Mvh002013@irp-view13.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/fEf55PeT_i6OYkF6awhZsBMMlRo Subject: Re: [v6ops] draft-byrne-v6ops-clatip WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 05 May 2014 22:43:28 -0000 +1 On 5/5/14, 10:19 , George, Wes wrote: > I support adoption/publication of this draft. I think it’s useful to > codify the block that is already being used in a production network so > that others can take advantage of this implementation experience, and > v6ops is an acceptable place in which to do it. -- ================================================ 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 nobody Mon May 5 15:46:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A901A01CB for ; Mon, 5 May 2014 15:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koGyUR5VZCqr for ; Mon, 5 May 2014 15:46:07 -0700 (PDT) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id C7B0C1A048C for ; Mon, 5 May 2014 15:46:06 -0700 (PDT) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 5 May 2014 17:46:03 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ig0-f177.google.com [209.85.213.177] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ig0-f177.google.com with SMTP id l13so2987649iga.4 for ; Mon, 05 May 2014 15:46:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=BOKvv83HboTKg6GP5AX9DMf2TZ+OOjW5ejddmgGDM1s=; b=T6X3kjxICnNmKKxvn3tlq2Mh+yF0jt48/lBw6s0XOMtozSldLgS3i1Y/x+JPVbEM5W oibgoDMOxzY1hRovdLGZcOeV2azfQLJGZfVr8Q+gEjmOhYKDHaZZQe8qUoOCo+y4CZTp E4lNmjPgQKJiZ3TVD7oLROfAMhY1olvLykAVZtRcIlK+TJ+jDtl8OUUozkk6n5dpSAmN KdnU2WX7P/vw9NwsZ5jWvJsAuGgnBMLMbw/AfaPTsxbf9HoYhNGbQjcSgL1cW4ZsgYXP PvMJv9WPIbFyLYespGJ5Tg/07WrRD442s6zKyyeGcnP0hCLOwXnANSkCKHIRoNKEoVvk Jlqw== X-Gm-Message-State: ALoCoQnFqgQczwJPlNPHcRSxt5TssOjyn8gtxVXx78RUkZ7FWoDqTekEMocoQQkT2Ire6mWI4JkEiWQAz25W0EaRqK1lEp5B29N4OrKFKjfGVWL6a9Cbr/E= X-Received: by 10.42.253.130 with SMTP id na2mr6181212icb.82.1399329962717; Mon, 05 May 2014 15:46:02 -0700 (PDT) X-Received: by 10.42.253.130 with SMTP id na2mr6181197icb.82.1399329962526; Mon, 05 May 2014 15:46:02 -0700 (PDT) Received: from x-160-94-246-71.uofm-secure.wireless.umn.edu (x-160-94-246-71.uofm-secure.wireless.umn.edu. [160.94.246.71]) by mx.google.com with ESMTPSA id h7sm31613176igy.2.2014.05.05.15.45.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 May 2014 15:46:00 -0700 (PDT) Message-ID: <536814A4.7070606@umn.edu> Date: Mon, 05 May 2014 17:45:56 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "George, Wes" , Ca By References: <201405041800.s44I0Mvh002013@irp-view13.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/z1RhUngeV8sE2iRP8j2YnID0Y04 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-byrne-v6ops-clatip WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 05 May 2014 22:46:08 -0000 On 5/5/14, 16:04 , George, Wes wrote: > > On 5/5/14, 4:00 PM, "Ca By" wrote: > >>> >>> First, this draft needs to formally update RFC 6333 in its metadata, as >>> I >>> think there’s a need for a formal link between the two. >>> >> >> I humbly disagree. Nothing changes in DS-lite or RFC6333 as function >> of draft-ietf-v6ops-clatip-00. >> >> What does change is the IANA registery of 192.0.0.0/29 to be more >> general and serve a super set of scenarios, and that change will be >> reflected there in IANA, not in DS-lite. >> >> I am open to other opinions on this, but mine is that RFC6333 updated >> IANA and draft-ietf-v6ops-clatip-00 updates IANA again. >> draft-ietf-v6ops-clatip-00 does not update RFC6333 > > A fair point. I agree that the direction to IANA doesn’t explicitly > require an update to 6333 and you’re not really changing DSLite. My > thought was more from the perspective that originally 6333 was written > assuming exclusive use of the block, and it no longer has it. Since there > are at least small considerations about overlap, it’s worth the DSLite doc > having a link to this one for those implementing DSLite that may not be > aware of this change. > > Wes I think maybe formally updating Section 5.7 of RFC6333 by adding a version of the text from the last paragraph of Section 3 of draft-ietf-v6ops-clatip-00 as the last paragraph of Section 5.7 of RFC6333, would ensure that DS-lite implementers are made aware of the new constraint created by this change. 192.0.0.0/29 has now been generalized across multiple IPv4 continuity solutions such as 464XLAT and DS-lite. It is important that a host never be deployed with 2 active IPv4 continuity solutions simultaneously in a way that would cause a node to have overlapping address from 192.0.0.0/29. Just a thought. -- ================================================ 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 nobody Tue May 6 05:45:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE5F1A02F0 for ; Tue, 6 May 2014 05:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qG1kBqOTcPhr for ; Tue, 6 May 2014 05:45:33 -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 9404C1A02E6 for ; Tue, 6 May 2014 05:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=125; q=dns/txt; s=iport; t=1399380330; x=1400589930; h=date:from:message-id:to:subject:cc; bh=Wawl+AhkTarnx341pLb1/0lCm18c9jwNpkfi4vYBe40=; b=E2a9zaB8Af/sgjuaFOGgmEu659w6SqkYsjM4ExFd69+oCtZaYF+uM3D7 FQBvK0epqgP/OkW4MYQwujim/K+lFdg+Q7u+t8JVfxzfclzVoI+N6KhkB VxBmiXxY/GZo01ZiPbQrRhL9YGWDA2w2L/g5SmvEzjnto/xMF4WjTrJiH w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0SAOPYaFOrRDoJ/2dsb2JhbABZgwZPrgwBlx4DBAKBHRZ0gyU8NIkhDs1MF45SHYQpBIoIkGuRP4NU X-IronPort-AV: E=Sophos;i="4.97,997,1389744000"; d="scan'208";a="111996239" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 06 May 2014 12:45:25 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s46CjPcZ026889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2014 12:45:25 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id s46CjOZQ013095; Tue, 6 May 2014 05:45:24 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id s46CjNEi013073; Tue, 6 May 2014 05:45:23 -0700 (PDT) Date: Tue, 6 May 2014 05:45:23 -0700 (PDT) From: Fred Baker Message-Id: <201405061245.s46CjNEi013073@irp-view13.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NlBoil8umVCW1y_Ezns4gDUbBVI Cc: draft-ietf-v6ops-clatip@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-clatip X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 12:45:34 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-clatip. Please take a look at it and comment. From nobody Sun May 11 11:00:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEF11A0336 for ; Sun, 11 May 2014 11:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yryuJByHAbZl for ; Sun, 11 May 2014 11:00:40 -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 B58751A0330 for ; Sun, 11 May 2014 11:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=129; q=dns/txt; s=iport; t=1399831235; x=1401040835; h=date:from:message-id:to:subject:cc; bh=4kIRMaErY1jozgSq+oF7sLMWlB9Xgi2sO31pBVcvju4=; b=H513xeR4WFXBmjirlvC4vuk1yWexa0chBFMD1/ZMQ33A8Xfvo/W9aSGE vFNR+Qx4LCIEDuFAoAnt4Afvt9MK3Kj2OAymg/vs904jem3S9BMLsXfxP GWCUO5SpuaHyi3nnM7l/QJJIELqE5xsvdgYDzmcrfP8zJSC1NFTVC/1/d 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcIAIK5b1OtJV2a/2dsb2JhbABZgwavTAGXNYEUFnSCSVw8NIkhAc5pF45SHYQqBIoPokCDVg X-IronPort-AV: E=Sophos;i="4.97,1030,1389744000"; d="scan'208";a="324118916" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 11 May 2014 18:00:34 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s4BI0YCx002468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 May 2014 18:00:34 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id s4BI0X2C002205; Sun, 11 May 2014 11:00:33 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id s4BI0WFG002101; Sun, 11 May 2014 11:00:32 -0700 (PDT) Date: Sun, 11 May 2014 11:00:32 -0700 (PDT) From: Fred Baker Message-Id: <201405111800.s4BI0WFG002101@irp-view13.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Zmf1UaxrnGKuULTJPE-BjCTBlfI Subject: [v6ops] draft-byrne-v6ops-clatip WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 18:00:42 -0000 The working group last call for this draft announced last week continues for another week. Please feel free to comment on it. From nobody Tue May 13 17:08:56 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4EF21A0142 for ; Tue, 13 May 2014 17:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.253 X-Spam-Level: X-Spam-Status: No, score=-104.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIVEpG_NHO3n for ; Tue, 13 May 2014 17:08:52 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0D48A1A0130 for ; Tue, 13 May 2014 17:08:52 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1AF7818000E; Tue, 13 May 2014 17:07:50 -0700 (PDT) To: elwynd@dial.pipex.com, mohacsi@niif.hu, bclaise@cisco.com, joelja@bogus.com, fred.baker@cisco.com, john_brzozowski@cable.comcast.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140514000750.1AF7818000E@rfc-editor.org> Date: Tue, 13 May 2014 17:07:50 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/GWe1CABDR9r9AHv5gnxEeu-vj6Y Cc: jamesrobertson@live.com, v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] [Technical Errata Reported] RFC4890 (3985) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 00:08:54 -0000 The following errata report has been submitted for RFC4890, "Recommendations for Filtering ICMPv6 Messages in Firewalls". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4890&eid=3985 -------------------------------------- Type: Technical Reported by: James Robertson Section: Appendix B Original Text ------------- if [ "$STATE_ENABLED" -eq "1" ] then # Allow incoming time exceeded code 0 messages # only for existing sessions for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -m state -p icmpv6 \ -d $inner_prefix \ --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \ -j ACCEPT done else # Allow incoming time exceeded code 0 messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ --icmpv6-type ttl-zero-during-transit -j ACCEPT done fi Corrected Text -------------- if [ "$STATE_ENABLED" -eq "1" ] then # Allow incoming time exceeded code 0 messages # only for existing sessions for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -m state -p icmpv6 \ -d $inner_prefix \ --state ESTABLISHED,RELATED --icmpv6-type ttl-zero-during-transit \ -j ACCEPT done else # Allow incoming time exceeded code 0 messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ --icmpv6-type ttl-zero-during-transit -j ACCEPT done fi Notes ----- RFC 4890 Errata ID 2706 states that icmpv6-type packet-too-big should state icmpv6-type ttl-zero-during-transmit. This should read ttl-zero-during-transit. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4890 (draft-ietf-v6ops-icmpv6-filtering-recs-03) -------------------------------------- Title : Recommendations for Filtering ICMPv6 Messages in Firewalls Publication Date : May 2007 Author(s) : E. Davies, J. Mohacsi Category : INFORMATIONAL Source : IPv6 Operations Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue May 13 23:08:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398D91A023C for ; Tue, 13 May 2014 23:07:59 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CZKtPyV973N for ; Tue, 13 May 2014 23:07:57 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5A91E1A0233 for ; Tue, 13 May 2014 23:07:57 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id lh14so1807639vcb.5 for ; Tue, 13 May 2014 23:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=I9EN5zj2qVFTAvXt9rvTy3kXBXf8iR4Xj5gLc4GXC/o=; b=JWolk6AHpGvEjkejwfd1C3GxQC1K8LSCn9e8oifE8UYQwR2AKr2idx1jaTEIYxgJd4 Iq4QAgJ1iSw9Owpg0mVHDy6UfJDGVB1hFMG2YDgJSk7aOrGRTwIdVec5c9/iyJSEJ5Wm p04YPOhk2hWu3+aGLNgfmYMo7pQNGne3PaswSFZvQ05QOPU3bn6rgo3Z6SxNFzgnA/OV mEyURbOY1/ocDRi02vSqGuVbIKyoGn0NQlSpMQqfs4ndES5Cchr8wmCqEahAhxA15y6s vxqdayPQ/DNBsMcaYx4azKTLyqya0UiFxFBZskpKVPsAytzEpdrLy6VmPutH8xKyyX2G Lcrg== X-Received: by 10.52.183.228 with SMTP id ep4mr1158793vdc.30.1400047670630; Tue, 13 May 2014 23:07:50 -0700 (PDT) Received: from [192.168.124.104] ([186.188.97.64]) by mx.google.com with ESMTPSA id gi3sm968215vec.14.2014.05.13.23.07.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 May 2014 23:07:48 -0700 (PDT) Message-ID: <5373082E.5040007@gmail.com> Date: Wed, 14 May 2014 01:37:42 -0430 From: Alejandro Acosta User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <201405061245.s46CjNEi013073@irp-view13.cisco.com> In-Reply-To: <201405061245.s46CjNEi013073@irp-view13.cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/l3zwn_7OBtKi-iCULOia5zVczqw Subject: Re: [v6ops] new draft: draft-ietf-v6ops-clatip X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 06:07:59 -0000 Hi, Sorry if this question have been done before (and I guess it have been). I'm know this kind of mechanism are oriented to simple devices such smartphones, but anyway I wonder how the prefix 192.0.0.0/29 is handle in a device with more than one interface. I read in section three you mention: " ..... It is important that a host never be deployed with 2 active IPv4 continuity solutions simultaneously in a way that would cause a node to have overlapping address from 192.0.0.0/29." Can I subnet this prefix in two /30 and then there won't be overlapping?, should I assign one /29 and then I can not used ds-lite/464xlat in the next interface (this is what I understand from the text above). Thanks, El 5/6/2014 8:15 AM, Fred Baker escribió: > > A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-clatip. Please take a look at it and comment. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed May 14 09:12:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501B01A0133 for ; Wed, 14 May 2014 09:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v07XC3Sbf-_u for ; Wed, 14 May 2014 09:12:16 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 239CE1A029F for ; Wed, 14 May 2014 09:12:15 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id l18so2163807wgh.14 for ; Wed, 14 May 2014 09:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1hG1jrF72rfvNMXGKK4Wqb0DXPwlYO8qqP2lXwbH+SM=; b=GEogyz/W91cIVUlAvI3v0Ie9D5j+NYCromsZ19kzJVkjuwxHI5QITnca5q94qrgqrE K2yvc3otEc7thPBaxfBeJ4gOvbgkqEaThdEQUwq8b4EjE/XsdoHj+JdbxqT3vlV+cdHn 2LLnLIp1ZPuI13nPWoySVKv4RJ3uVecPhez8ocESMU2D+mIHlCpYpKdfJ6v6CAQCpUTF S7Y7ghVPMRIS3hl0SKWhhvqrlz/R+a8PGWFyhKXIeN5oKDx8HEZeewFuoN5GIEFnkNNa OFnTw2P5EYTDEkPpY9ptTcK13ShS+XzbpcMfv9gI3MBH0pvcuV8z0GSTl2LOa2Yk0R5x hagw== MIME-Version: 1.0 X-Received: by 10.194.91.175 with SMTP id cf15mr3924028wjb.5.1400083928960; Wed, 14 May 2014 09:12:08 -0700 (PDT) Received: by 10.217.61.198 with HTTP; Wed, 14 May 2014 09:12:08 -0700 (PDT) In-Reply-To: <5373082E.5040007@gmail.com> References: <201405061245.s46CjNEi013073@irp-view13.cisco.com> <5373082E.5040007@gmail.com> Date: Wed, 14 May 2014 09:12:08 -0700 Message-ID: From: Ca By To: Alejandro Acosta Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_1_S87kVAHH8G1EsdPPw2NbuhVk Cc: IPv6 Ops WG Subject: Re: [v6ops] new draft: draft-ietf-v6ops-clatip X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 16:12:22 -0000 On Tue, May 13, 2014 at 11:07 PM, Alejandro Acosta wrote: > Hi, > Sorry if this question have been done before (and I guess it have been). > I'm know this kind of mechanism are oriented to simple devices such > smartphones, but anyway I wonder how the prefix 192.0.0.0/29 is handle > in a device with more than one interface. > > I read in section three you mention: > > " ..... It is important > that a host never be deployed with 2 active IPv4 continuity solutions > simultaneously in a way that would cause a node to have overlapping > address from 192.0.0.0/29." > > Can I subnet this prefix in two /30 and then there won't be > overlapping?, should I assign one /29 and then I can not used > ds-lite/464xlat in the next interface (this is what I understand from > the text above). > > Thanks, > Hi Alejandro, Thanks for taking the time to read the I-D. The goal of the I-D is lift restrictions. David Thaler suggested that since the 192.0.0.0/29 has fewer restriction on its use, it is possible for solutions to overlap and cause problems on a host that has both solutions. For example, if a host has both a DS-lite and 464XLAT capability, and both are active at the same time and both are assuming the full 192.0.0.0/29 can be used, this will cause a problem since the host will have 2 connected routes to the same place. To avoid this scenario of overlapping space (in the unlikely event a host has 2 active IPv6 transition scenarios), the text you quoted was added. The text simply says "be smart" ... don't use overlapping addresses on a host and cause yourself a problem. That said, i find it perfectly reasonable, as you suggest, to take the 192.0.0.0/29 and create 2 /30s, 1 for DS-lite and the other for 464XLAT... if you must have this ability. The common Android solution for this is to just use 192.0.0.4/32, only 1 IPv4 address is needed for 464XLAT to function on Android https://android.googlesource.com/platform/external/android-clat/+/master/cl= atd.conf > > El 5/6/2014 8:15 AM, Fred Baker escribi=C3=B3: >> >> A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6= ops-clatip. 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://www.ietf.org/mailman/listinfo/v6ops From nobody Wed May 14 12:51:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493631A02B5 for ; Wed, 14 May 2014 12:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0iQNlmhlYj5 for ; Wed, 14 May 2014 12:51:31 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 698011A02C0 for ; Wed, 14 May 2014 12:51:31 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id as1so46544iec.39 for ; Wed, 14 May 2014 12:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5V6sfMUtXeU/Ay/8+U8elARBN6EVzB7pD6ywc/+yVlg=; b=pkV+PvSzUD3FtHyYCGKB1yspRl19xOGh/NJxYZDq+K6hDNTQb82NedBnSUnV1nAUpf ME35UwRO/pyGSQjMth8psRzhCd13TFP3OzgxBws/tm5Hcwy50ZfEL/esBXeQo1vDNoSQ G9HfrViYhXuW0B3qeI/5eukL34saXSqYBTBkQOXF4+W94rBb1NvUgDOfZxgNJrhbvkIe RqlMUTE9EB2oRRzxvsSdiyrD3col8P5hypgvSGDwrGkEg7/4aoVyraLNOtiiIKoSARj3 n5cHPpU93BZg3bRo3g2uox97GyDihEsLZ2QuCvcB2Tbrx6fBrMaHC+xtA1PjsWyx3Pcq 4NXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5V6sfMUtXeU/Ay/8+U8elARBN6EVzB7pD6ywc/+yVlg=; b=cn+V7nMvZ5w3FEGqlqALzdQFJPoVfzbRJjJcjhTOBo6swi7hRpzSgyOu+izSTs/qGV KsHSqmlPnhJ9qJHEoNzJnCuxjSHcoogpSLG6dIdXzo4Bya89nNqvD/S8d1ibJqSBUOi/ lzZS9S21QeJKERmU9v2dvqYCWippBne8GwNJVXuqtaFpR7VVRl6gNAObub53nkDevNl4 LmvslotiL5EwWQ2HFWmuDk2DOtOAJUZl7GP7JT64dgGtnPUAqRENpu9S7t3ylzYNEj5I aNu1QuPc7hAKigT/0jU25rwezO6hJwsomEn/9SzSk7ahCsjOo/ruMie7Kq3VIhI6UfRE +6Ow== X-Gm-Message-State: ALoCoQkik9sqiNlLKN4jafMiuEmHlBYPTPduO/lqypKWxHQirQYnxDt6Y6BoCxexkwVPWyIFIW/6 X-Received: by 10.50.238.229 with SMTP id vn5mr7423526igc.45.1400097084592; Wed, 14 May 2014 12:51:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Wed, 14 May 2014 12:51:04 -0700 (PDT) In-Reply-To: References: <201405061245.s46CjNEi013073@irp-view13.cisco.com> <5373082E.5040007@gmail.com> From: Lorenzo Colitti Date: Thu, 15 May 2014 04:51:04 +0900 Message-ID: To: Ca By Content-Type: multipart/alternative; boundary=001a1134cb966103b704f961812a Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/JzE5pIcCw6w5LLnNHScrPG77dsw Cc: IPv6 Ops WG Subject: Re: [v6ops] new draft: draft-ietf-v6ops-clatip X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 19:51:33 -0000 --001a1134cb966103b704f961812a Content-Type: text/plain; charset=UTF-8 On Thu, May 15, 2014 at 1:12 AM, Ca By wrote: > The common Android solution > for this is to just use 192.0.0.4/32, only 1 IPv4 address is needed > for 464XLAT to function on Android > > > https://android.googlesource.com/platform/external/android-clat/+/master/clatd.conf Bear in mind, though, that Android does not support DS-Lite and it does not support running 464xlat on more than one interface at a time. --001a1134cb966103b704f961812a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, May 15, 2014 at 1:12 AM, Ca By <cb.list6@gmail.com> wro= te:
The common Android solution
for this is to just use 1= 92.0.0.4/32, only 1 IPv4 address is needed
for 464XLAT to function on Android

https://android.googlesource.com/pla= tform/external/android-clat/+/master/clatd.conf

Bear in mind, though, that Android does not support DS-Lite and it doe= s not support running 464xlat on more than one interface at a time.
--001a1134cb966103b704f961812a-- From nobody Wed May 14 20:25:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B721A03B5 for ; Wed, 14 May 2014 20:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.552 X-Spam-Level: X-Spam-Status: No, score=-109.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_26=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLt_R8ML0x3J for ; Wed, 14 May 2014 20:25:44 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB5051A03A9 for ; Wed, 14 May 2014 20:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3535; q=dns/txt; s=iport; t=1400124337; x=1401333937; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nh8v1nzHSkYV/8YyhAIJJBzz5ehme8vH02hNH5V8NSk=; b=joi8v4EDDYI49J0ohMHsIhpBiH7/MCFF3IOW0JCxTMaBn1zNnqg3OHxA W9wA7REGBDgaMyKzlLBHPPxmkM2XDIAc7CzHsZ1j1+7gx4YPko8rsKb67 xuzLCpRDCRkSd/HSco4HahrlmwLvzfka1x12c47XWF7Tfxl8tDHs1lXCo k=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAHUydFOtJV2R/2dsb2JhbAA/GoMGT1itUZdqAYEbFnSCJQEBAQMBeQULAgEIRjIlAgQBDQUOiB8DCQgNNtEKF4tAeYE0YQeDK4EVBJE1gTmGY5MUgzZtEXFB X-IronPort-AV: E=Sophos;i="4.97,1056,1389744000"; d="asc'?scan'208";a="43999366" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP; 15 May 2014 03:25:36 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s4F3Pa3r022451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 May 2014 03:25:36 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.239]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Wed, 14 May 2014 22:25:35 -0500 From: "Fred Baker (fred)" To: Elwyn Davies , Mohacsi Janos , "jamesrobertson@live.com" Thread-Topic: [Technical Errata Reported] RFC4890 (3985) Thread-Index: AQHPb+1Vy8ZdmtKE2UWIbX9rOxY3OQ== Date: Thu, 15 May 2014 03:25:34 +0000 Message-ID: <8DA928AC-FCAF-4AB6-BE39-C6D155C91F17@cisco.com> References: <20140514000750.1AF7818000E@rfc-editor.org> In-Reply-To: <20140514000750.1AF7818000E@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_623A6FBD-16E8-425F-8153-7AF4A62F0C75"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/j1SKoyQzkObh7D3xXVKHCxsnLvc Cc: V6 Ops List Subject: Re: [v6ops] [Technical Errata Reported] RFC4890 (3985) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 03:25:45 -0000 --Apple-Mail=_623A6FBD-16E8-425F-8153-7AF4A62F0C75 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Guys: Do we agree with this? On May 13, 2014, at 5:07 PM, RFC Errata System = wrote: > The following errata report has been submitted for RFC4890, > "Recommendations for Filtering ICMPv6 Messages in Firewalls". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4890&eid=3D3985 >=20 > -------------------------------------- > Type: Technical > Reported by: James Robertson >=20 > Section: Appendix B >=20 > Original Text > ------------- > if [ "$STATE_ENABLED" -eq "1" ] > then > # Allow incoming time exceeded code 0 messages > # only for existing sessions > for inner_prefix in $INNER_PREFIXES > do > ip6tables -A icmpv6-filter -m state -p icmpv6 \ > -d $inner_prefix \ > --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \ > -j ACCEPT > done > else > # Allow incoming time exceeded code 0 messages > for inner_prefix in $INNER_PREFIXES > do > ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ > --icmpv6-type ttl-zero-during-transit -j ACCEPT > done > fi >=20 > Corrected Text > -------------- > if [ "$STATE_ENABLED" -eq "1" ] > then > # Allow incoming time exceeded code 0 messages > # only for existing sessions > for inner_prefix in $INNER_PREFIXES > do > ip6tables -A icmpv6-filter -m state -p icmpv6 \ > -d $inner_prefix \ > --state ESTABLISHED,RELATED --icmpv6-type ttl-zero-during-transit = \ > -j ACCEPT > done > else > # Allow incoming time exceeded code 0 messages > for inner_prefix in $INNER_PREFIXES > do > ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ > --icmpv6-type ttl-zero-during-transit -j ACCEPT > done > fi >=20 > Notes > ----- > RFC 4890 Errata ID 2706 states that icmpv6-type packet-too-big should > state icmpv6-type ttl-zero-during-transmit. This should read > ttl-zero-during-transit. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC4890 (draft-ietf-v6ops-icmpv6-filtering-recs-03) > -------------------------------------- > Title : Recommendations for Filtering ICMPv6 Messages in = Firewalls > Publication Date : May 2007 > Author(s) : E. Davies, J. Mohacsi > Category : INFORMATIONAL > Source : IPv6 Operations > Area : Operations and Management > Stream : IETF > Verifying Party : IESG --Apple-Mail=_623A6FBD-16E8-425F-8153-7AF4A62F0C75 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTdDOtbjEdbHIsm0MRAjHOAJ0Z0oVIokOkXhrFcxc+hbVexPfkVgCg9XB1 uVGuhTrZyM6wTSfdXz0bZhk= =L4Js -----END PGP SIGNATURE----- --Apple-Mail=_623A6FBD-16E8-425F-8153-7AF4A62F0C75-- From nobody Wed May 14 21:09:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF921A03C1 for ; Wed, 14 May 2014 21:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAz_rEhuKHbh for ; Wed, 14 May 2014 21:09:44 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2B5B1A03BC for ; Wed, 14 May 2014 21:09:43 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s4F49KtP032788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 15 May 2014 04:09:21 GMT (envelope-from joelja@bogus.com) Message-ID: <53743DEA.4030703@bogus.com> Date: Wed, 14 May 2014 21:09:14 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Thunderbird/29.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , Elwyn Davies , Mohacsi Janos , "jamesrobertson@live.com" References: <20140514000750.1AF7818000E@rfc-editor.org> <8DA928AC-FCAF-4AB6-BE39-C6D155C91F17@cisco.com> In-Reply-To: <8DA928AC-FCAF-4AB6-BE39-C6D155C91F17@cisco.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mKrMilxNrrOBA1q814bEW3hKUN65cMHNC" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Thu, 15 May 2014 04:09:22 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Aore5LAja1NsTNhSjacRdjDcmjc Cc: V6 Ops List Subject: Re: [v6ops] [Technical Errata Reported] RFC4890 (3985) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 04:09:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mKrMilxNrrOBA1q814bEW3hKUN65cMHNC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 5/14/14, 8:25 PM, Fred Baker (fred) wrote: > Guys: >=20 > Do we agree with this? it's not really normative text, it's an example in an appendix. assuming you think it's an issue and the correction is reasonable I would probably just hold it for a document update (seems unlikely atm but who knows) > On May 13, 2014, at 5:07 PM, RFC Errata System wrote: >=20 >> The following errata report has been submitted for RFC4890, >> "Recommendations for Filtering ICMPv6 Messages in Firewalls". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D4890&eid=3D3985 >> >> -------------------------------------- >> Type: Technical >> Reported by: James Robertson >> >> Section: Appendix B >> >> Original Text >> ------------- >> if [ "$STATE_ENABLED" -eq "1" ] >> then >> # Allow incoming time exceeded code 0 messages >> # only for existing sessions >> for inner_prefix in $INNER_PREFIXES >> do >> ip6tables -A icmpv6-filter -m state -p icmpv6 \ >> -d $inner_prefix \ >> --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \ >> -j ACCEPT >> done >> else >> # Allow incoming time exceeded code 0 messages >> for inner_prefix in $INNER_PREFIXES >> do >> ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ >> --icmpv6-type ttl-zero-during-transit -j ACCEPT >> done >> fi >> >> Corrected Text >> -------------- >> if [ "$STATE_ENABLED" -eq "1" ] >> then >> # Allow incoming time exceeded code 0 messages >> # only for existing sessions >> for inner_prefix in $INNER_PREFIXES >> do >> ip6tables -A icmpv6-filter -m state -p icmpv6 \ >> -d $inner_prefix \ >> --state ESTABLISHED,RELATED --icmpv6-type ttl-zero-during-transit = \ >> -j ACCEPT >> done >> else >> # Allow incoming time exceeded code 0 messages >> for inner_prefix in $INNER_PREFIXES >> do >> ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ >> --icmpv6-type ttl-zero-during-transit -j ACCEPT >> done >> fi >> >> Notes >> ----- >> RFC 4890 Errata ID 2706 states that icmpv6-type packet-too-big should >> state icmpv6-type ttl-zero-during-transmit. This should read >> ttl-zero-during-transit. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary.=20 >> >> -------------------------------------- >> RFC4890 (draft-ietf-v6ops-icmpv6-filtering-recs-03) >> -------------------------------------- >> Title : Recommendations for Filtering ICMPv6 Messages in= Firewalls >> Publication Date : May 2007 >> Author(s) : E. Davies, J. Mohacsi >> Category : INFORMATIONAL >> Source : IPv6 Operations >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG >=20 --mKrMilxNrrOBA1q814bEW3hKUN65cMHNC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlN0PeoACgkQ8AA1q7Z/VrI4aQCffeUj4vLgrJA7El+1ObhjcIwy KZsAn1i6NC66wmGt4Z5W7MF87xkYWYBY =au9X -----END PGP SIGNATURE----- --mKrMilxNrrOBA1q814bEW3hKUN65cMHNC-- From nobody Thu May 15 03:25:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A838C1A04A6 for ; Thu, 15 May 2014 03:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsMGJHkDGWVk for ; Thu, 15 May 2014 03:24:56 -0700 (PDT) Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FCF01A04A8 for ; Thu, 15 May 2014 03:24:55 -0700 (PDT) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by b.painless.aa.net.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WksqA-0000jK-Hj; Thu, 15 May 2014 11:24:42 +0100 From: Elwyn Davies To: joel jaeggli , Suresh Krishnan In-Reply-To: <53743DEA.4030703@bogus.com> References: <20140514000750.1AF7818000E@rfc-editor.org> <8DA928AC-FCAF-4AB6-BE39-C6D155C91F17@cisco.com> <53743DEA.4030703@bogus.com> Content-Type: text/plain Date: Thu, 15 May 2014 11:24:39 +0100 Message-Id: <1400149479.29419.2590.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/m8olZYZKAHjFYmMhyzDOinS-FTc Cc: V6 Ops List , "jamesrobertson@live.com" Subject: Re: [v6ops] [Technical Errata Reported] RFC4890 (3985) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 10:24:58 -0000 HI. This looks correct. I am forwarding the message to Suresh who actually authored the script for an opinion. Assuming that he concurs, I don't see any harm in issuing an erratum and a very few people might actually be using the script verbatim. There was a move afoot to make a new version (and possibly transition this to BCP) but we haven't managed to get it together to do so yet. Regards, Elwyn On Wed, 2014-05-14 at 21:09 -0700, joel jaeggli wrote: > On 5/14/14, 8:25 PM, Fred Baker (fred) wrote: > > Guys: > > > > Do we agree with this? > > it's not really normative text, it's an example in an appendix. > > assuming you think it's an issue and the correction is reasonable I > would probably just hold it for a document update (seems unlikely atm > but who knows) > > > > On May 13, 2014, at 5:07 PM, RFC Errata System wrote: > > > >> The following errata report has been submitted for RFC4890, > >> "Recommendations for Filtering ICMPv6 Messages in Firewalls". > >> > >> -------------------------------------- > >> You may review the report below and at: > >> http://www.rfc-editor.org/errata_search.php?rfc=4890&eid=3985 > >> > >> -------------------------------------- > >> Type: Technical > >> Reported by: James Robertson > >> > >> Section: Appendix B > >> > >> Original Text > >> ------------- > >> if [ "$STATE_ENABLED" -eq "1" ] > >> then > >> # Allow incoming time exceeded code 0 messages > >> # only for existing sessions > >> for inner_prefix in $INNER_PREFIXES > >> do > >> ip6tables -A icmpv6-filter -m state -p icmpv6 \ > >> -d $inner_prefix \ > >> --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \ > >> -j ACCEPT > >> done > >> else > >> # Allow incoming time exceeded code 0 messages > >> for inner_prefix in $INNER_PREFIXES > >> do > >> ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ > >> --icmpv6-type ttl-zero-during-transit -j ACCEPT > >> done > >> fi > >> > >> Corrected Text > >> -------------- > >> if [ "$STATE_ENABLED" -eq "1" ] > >> then > >> # Allow incoming time exceeded code 0 messages > >> # only for existing sessions > >> for inner_prefix in $INNER_PREFIXES > >> do > >> ip6tables -A icmpv6-filter -m state -p icmpv6 \ > >> -d $inner_prefix \ > >> --state ESTABLISHED,RELATED --icmpv6-type ttl-zero-during-transit \ > >> -j ACCEPT > >> done > >> else > >> # Allow incoming time exceeded code 0 messages > >> for inner_prefix in $INNER_PREFIXES > >> do > >> ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ > >> --icmpv6-type ttl-zero-during-transit -j ACCEPT > >> done > >> fi > >> > >> Notes > >> ----- > >> RFC 4890 Errata ID 2706 states that icmpv6-type packet-too-big should > >> state icmpv6-type ttl-zero-during-transmit. This should read > >> ttl-zero-during-transit. > >> > >> Instructions: > >> ------------- > >> This errata is currently posted as "Reported". If necessary, please > >> use "Reply All" to discuss whether it should be verified or > >> rejected. When a decision is reached, the verifying party (IESG) > >> can log in to change the status and edit the report, if necessary. > >> > >> -------------------------------------- > >> RFC4890 (draft-ietf-v6ops-icmpv6-filtering-recs-03) > >> -------------------------------------- > >> Title : Recommendations for Filtering ICMPv6 Messages in Firewalls > >> Publication Date : May 2007 > >> Author(s) : E. Davies, J. Mohacsi > >> Category : INFORMATIONAL > >> Source : IPv6 Operations > >> Area : Operations and Management > >> Stream : IETF > >> Verifying Party : IESG > > > > From nobody Thu May 15 07:45:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9BA1A02A0 for ; Thu, 15 May 2014 07:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.552 X-Spam-Level: X-Spam-Status: No, score=-109.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_26=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXNMO63BfIhk for ; Thu, 15 May 2014 07:45:06 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08AA1A0297 for ; Thu, 15 May 2014 07:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4725; q=dns/txt; s=iport; t=1400165099; x=1401374699; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pUieAnsT2z05jW7IyUcjGiHbpOWs7cYxh071LRKGedk=; b=nByT6bIXEgvyENFBp4wzKcZk8HdkfoB/6XJOT7VZOHXtO5HUC5SapsIC WxqfW+mNUQ//djrwwislExrztfw7fc1p8lT/h0fVkt1o98KLcNpmbbJpr 9lyjA74qFLPgWjqqxaplTc4ZT11FV6h8i+GFungb/casnGXMaAPq9S36k k=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAIbSdFOtJA2F/2dsb2JhbAA/GoMGT1itL5dqAYEQFnSCJQEBAQMBeQULAgEIGC4yJQIEDgUOiB8DCQgNNtBZF4tAeYE0YQeDK4EVBJE1gTmGY5MUgzZtEXFB X-IronPort-AV: E=Sophos;i="4.97,1059,1389744000"; d="asc'?scan'208";a="44120396" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP; 15 May 2014 14:44:58 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s4FEiwgY007548 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 May 2014 14:44:58 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.239]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Thu, 15 May 2014 09:44:57 -0500 From: "Fred Baker (fred)" To: Elwyn Davies Thread-Topic: [Technical Errata Reported] RFC4890 (3985) Thread-Index: AQHPcEw9bxFeSe5gY0OpzKQXlWYP5Q== Date: Thu, 15 May 2014 14:44:57 +0000 Message-ID: <10FBEF6F-DD9D-4DA6-89A6-8699110270B4@cisco.com> References: <20140514000750.1AF7818000E@rfc-editor.org> <8DA928AC-FCAF-4AB6-BE39-C6D155C91F17@cisco.com> <53743DEA.4030703@bogus.com> <1400149479.29419.2590.camel@mightyatom> In-Reply-To: <1400149479.29419.2590.camel@mightyatom> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_825943BA-66BC-4C86-BE8E-0BF2341D9240"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/U57VWerFOZ4dcEhSXjUi1e1neZ0 Cc: "jamesrobertson@live.com" , V6 Ops List Subject: Re: [v6ops] [Technical Errata Reported] RFC4890 (3985) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 14:45:13 -0000 --Apple-Mail=_825943BA-66BC-4C86-BE8E-0BF2341D9240 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks On May 15, 2014, at 3:24 AM, Elwyn Davies wrote: > HI. >=20 > This looks correct. I am forwarding the message to Suresh who = actually > authored the script for an opinion. >=20 > Assuming that he concurs, I don't see any harm in issuing an erratum = and > a very few people might actually be using the script verbatim. >=20 > There was a move afoot to make a new version (and possibly transition > this to BCP) but we haven't managed to get it together to do so yet. >=20 > Regards, > Elwyn >=20 > On Wed, 2014-05-14 at 21:09 -0700, joel jaeggli wrote: >> On 5/14/14, 8:25 PM, Fred Baker (fred) wrote: >>> Guys: >>>=20 >>> Do we agree with this? >>=20 >> it's not really normative text, it's an example in an appendix. >>=20 >> assuming you think it's an issue and the correction is reasonable I >> would probably just hold it for a document update (seems unlikely atm >> but who knows) >>=20 >>=20 >>> On May 13, 2014, at 5:07 PM, RFC Errata System = wrote: >>>=20 >>>> The following errata report has been submitted for RFC4890, >>>> "Recommendations for Filtering ICMPv6 Messages in Firewalls". >>>>=20 >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=3D4890&eid=3D3985 >>>>=20 >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: James Robertson >>>>=20 >>>> Section: Appendix B >>>>=20 >>>> Original Text >>>> ------------- >>>> if [ "$STATE_ENABLED" -eq "1" ] >>>> then >>>> # Allow incoming time exceeded code 0 messages >>>> # only for existing sessions >>>> for inner_prefix in $INNER_PREFIXES >>>> do >>>> ip6tables -A icmpv6-filter -m state -p icmpv6 \ >>>> -d $inner_prefix \ >>>> --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \ >>>> -j ACCEPT >>>> done >>>> else >>>> # Allow incoming time exceeded code 0 messages >>>> for inner_prefix in $INNER_PREFIXES >>>> do >>>> ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ >>>> --icmpv6-type ttl-zero-during-transit -j ACCEPT >>>> done >>>> fi >>>>=20 >>>> Corrected Text >>>> -------------- >>>> if [ "$STATE_ENABLED" -eq "1" ] >>>> then >>>> # Allow incoming time exceeded code 0 messages >>>> # only for existing sessions >>>> for inner_prefix in $INNER_PREFIXES >>>> do >>>> ip6tables -A icmpv6-filter -m state -p icmpv6 \ >>>> -d $inner_prefix \ >>>> --state ESTABLISHED,RELATED --icmpv6-type = ttl-zero-during-transit \ >>>> -j ACCEPT >>>> done >>>> else >>>> # Allow incoming time exceeded code 0 messages >>>> for inner_prefix in $INNER_PREFIXES >>>> do >>>> ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ >>>> --icmpv6-type ttl-zero-during-transit -j ACCEPT >>>> done >>>> fi >>>>=20 >>>> Notes >>>> ----- >>>> RFC 4890 Errata ID 2706 states that icmpv6-type packet-too-big = should >>>> state icmpv6-type ttl-zero-during-transmit. This should read >>>> ttl-zero-during-transit. >>>>=20 >>>> Instructions: >>>> ------------- >>>> This errata is currently posted as "Reported". If necessary, please >>>> use "Reply All" to discuss whether it should be verified or >>>> rejected. When a decision is reached, the verifying party (IESG) >>>> can log in to change the status and edit the report, if necessary.=20= >>>>=20 >>>> -------------------------------------- >>>> RFC4890 (draft-ietf-v6ops-icmpv6-filtering-recs-03) >>>> -------------------------------------- >>>> Title : Recommendations for Filtering ICMPv6 Messages = in Firewalls >>>> Publication Date : May 2007 >>>> Author(s) : E. Davies, J. Mohacsi >>>> Category : INFORMATIONAL >>>> Source : IPv6 Operations >>>> Area : Operations and Management >>>> Stream : IETF >>>> Verifying Party : IESG >>>=20 >>=20 >>=20 >=20 --Apple-Mail=_825943BA-66BC-4C86-BE8E-0BF2341D9240 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTdNLkbjEdbHIsm0MRApbjAKDvk/jSrXI8MPMffIKzaSg2ZCX8GACfbaiP OXpEXD+DCVyLAelZocGdQ0E= =02kU -----END PGP SIGNATURE----- --Apple-Mail=_825943BA-66BC-4C86-BE8E-0BF2341D9240-- From nobody Thu May 15 07:48:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260441A00D6 for ; Thu, 15 May 2014 07:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3vEC47GYvkp for ; Thu, 15 May 2014 07:48:10 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95FDD1A00BE for ; Thu, 15 May 2014 07:48:10 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-ce-53748435a993 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id B1.49.07420.53484735; Thu, 15 May 2014 11:09:10 +0200 (CEST) Received: from [142.133.113.185] (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.87) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 15 May 2014 10:48:01 -0400 Message-ID: <5374D39C.6060402@ericsson.com> Date: Thu, 15 May 2014 10:47:56 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Fred Baker (fred)" , Elwyn Davies References: <20140514000750.1AF7818000E@rfc-editor.org> <8DA928AC-FCAF-4AB6-BE39-C6D155C91F17@cisco.com> <53743DEA.4030703@bogus.com> <1400149479.29419.2590.camel@mightyatom> <10FBEF6F-DD9D-4DA6-89A6-8699110270B4@cisco.com> In-Reply-To: <10FBEF6F-DD9D-4DA6-89A6-8699110270B4@cisco.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [147.117.188.8] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyuXRPuK5ZS0mwwdVtjBZHH0tYbDsuaPF+ 3Rk2iz9PutgtXp1aw2gxv+0mu8XOeZsYLU4f28vswOFx9sgCRo/nj309pvzeyOpxfMVOdo8l S34yeXTcamD1uD0rKIA9issmJTUnsyy1SN8ugSvj1PHfbAWLlSqmPvnH2MA4WbqLkZNDQsBE 4u6nSSwQtpjEhXvr2boYuTiEBI4ySjzZMpUZwtnOKLH7wzQ2kCpeAW2JdwsWg3WwCKhKPJ0+ FSzOBjRpw87PTCC2qECYRPuFmcwQ9YISJ2c+AasXEfCTWDDjOwvIUGaBRiaJ5cffgzULC5hL XJjQwAqx7T7Qts1LwLo5BWwluic0s4LYzED2hTnXWSBseYntb+eA1QgJaEpsXfOdFeIHRYkX x38yTWAUmoVk+Swk7bOQtC9gZF7FyFFanFqWm25ksIkRGBnHJNh0dzDueWl5iFGAg1GJh/dB WXGwEGtiWXFl7iFGaQ4WJXHeipKSYCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MOw4I8uon xCkICd8o2KEeF/to/78zieUzPorft71Y5rWvPiHccsWnjcU7v5nl3y92iO+3fuz/gvtQ4Oad gqV8JiIiOhJF8+/tFGJMOLvmycGdD+c0ih1Wuf90d6rJZ38tBhWnz3K1/LevHJ/58tGn24Yl rdVbl3Jeza3+HaW8o1+di2nqsa6fSizFGYmGWsxFxYkAr3OFTm0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/67MmlofuIFs_TpKhERP3kyb5_5Y Cc: "jamesrobertson@live.com" , V6 Ops List Subject: Re: [v6ops] [Technical Errata Reported] RFC4890 (3985) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 14:48:12 -0000 Yes. This is a copy paste error on my part. The script probably needs to be rewritten to make use of more modern netfilter features like conntrack. I am willing to take a shot at a -bis version if Elwyn wants to go that way. Thanks Suresh On 05/15/2014 10:44 AM, Fred Baker (fred) wrote: > Thanks > > On May 15, 2014, at 3:24 AM, Elwyn Davies wrote: > >> HI. >> >> This looks correct. I am forwarding the message to Suresh who actually >> authored the script for an opinion. >> >> Assuming that he concurs, I don't see any harm in issuing an erratum and >> a very few people might actually be using the script verbatim. >> >> There was a move afoot to make a new version (and possibly transition >> this to BCP) but we haven't managed to get it together to do so yet. >> >> Regards, >> Elwyn >> >> On Wed, 2014-05-14 at 21:09 -0700, joel jaeggli wrote: >>> On 5/14/14, 8:25 PM, Fred Baker (fred) wrote: >>>> Guys: >>>> >>>> Do we agree with this? >>> >>> it's not really normative text, it's an example in an appendix. >>> >>> assuming you think it's an issue and the correction is reasonable I >>> would probably just hold it for a document update (seems unlikely atm >>> but who knows) >>> >>> >>>> On May 13, 2014, at 5:07 PM, RFC Errata System wrote: >>>> >>>>> The following errata report has been submitted for RFC4890, >>>>> "Recommendations for Filtering ICMPv6 Messages in Firewalls". >>>>> >>>>> -------------------------------------- >>>>> You may review the report below and at: >>>>> http://www.rfc-editor.org/errata_search.php?rfc=4890&eid=3985 >>>>> >>>>> -------------------------------------- >>>>> Type: Technical >>>>> Reported by: James Robertson >>>>> >>>>> Section: Appendix B >>>>> >>>>> Original Text >>>>> ------------- >>>>> if [ "$STATE_ENABLED" -eq "1" ] >>>>> then >>>>> # Allow incoming time exceeded code 0 messages >>>>> # only for existing sessions >>>>> for inner_prefix in $INNER_PREFIXES >>>>> do >>>>> ip6tables -A icmpv6-filter -m state -p icmpv6 \ >>>>> -d $inner_prefix \ >>>>> --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \ >>>>> -j ACCEPT >>>>> done >>>>> else >>>>> # Allow incoming time exceeded code 0 messages >>>>> for inner_prefix in $INNER_PREFIXES >>>>> do >>>>> ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ >>>>> --icmpv6-type ttl-zero-during-transit -j ACCEPT >>>>> done >>>>> fi >>>>> >>>>> Corrected Text >>>>> -------------- >>>>> if [ "$STATE_ENABLED" -eq "1" ] >>>>> then >>>>> # Allow incoming time exceeded code 0 messages >>>>> # only for existing sessions >>>>> for inner_prefix in $INNER_PREFIXES >>>>> do >>>>> ip6tables -A icmpv6-filter -m state -p icmpv6 \ >>>>> -d $inner_prefix \ >>>>> --state ESTABLISHED,RELATED --icmpv6-type ttl-zero-during-transit \ >>>>> -j ACCEPT >>>>> done >>>>> else >>>>> # Allow incoming time exceeded code 0 messages >>>>> for inner_prefix in $INNER_PREFIXES >>>>> do >>>>> ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ >>>>> --icmpv6-type ttl-zero-during-transit -j ACCEPT >>>>> done >>>>> fi >>>>> >>>>> Notes >>>>> ----- >>>>> RFC 4890 Errata ID 2706 states that icmpv6-type packet-too-big should >>>>> state icmpv6-type ttl-zero-during-transmit. This should read >>>>> ttl-zero-during-transit. >>>>> >>>>> Instructions: >>>>> ------------- >>>>> This errata is currently posted as "Reported". If necessary, please >>>>> use "Reply All" to discuss whether it should be verified or >>>>> rejected. When a decision is reached, the verifying party (IESG) >>>>> can log in to change the status and edit the report, if necessary. >>>>> >>>>> -------------------------------------- >>>>> RFC4890 (draft-ietf-v6ops-icmpv6-filtering-recs-03) >>>>> -------------------------------------- >>>>> Title : Recommendations for Filtering ICMPv6 Messages in Firewalls >>>>> Publication Date : May 2007 >>>>> Author(s) : E. Davies, J. Mohacsi >>>>> Category : INFORMATIONAL >>>>> Source : IPv6 Operations >>>>> Area : Operations and Management >>>>> Stream : IETF >>>>> Verifying Party : IESG >>>> >>> >>> >> > From nobody Thu May 15 15:31:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD441A01C4 for ; Thu, 15 May 2014 15:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ri0fXZqYLpK1 for ; Thu, 15 May 2014 15:31:09 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814F91A01AF for ; Thu, 15 May 2014 15:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1003; q=dns/txt; s=iport; t=1400193062; x=1401402662; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Aojn7tFGW1yRTgRaxlMpIDDWBJ5nwOEdZf3+FqT9/BU=; b=SmPJL5+qsjqhFzJBHqQMO4tWOIfgCK5Wx715eCAXoWtb2zn5f55zZIu+ cBxPPIJv4jZOi75Q4UZUjRyRztuHGYVJRbKukv12WEa4Xwx3kdGTJ0idk n1DudtCWvB5EATysFglySqf192QEbUPzUc3G9jbFIZyG23bsxJZxuiCuI Q=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAMM+dVOtJA2L/2dsb2JhbABZgwaBJ8UfAYESFnSCJQEBAQMBeQULAgEIDjghESUCBA4FDg2IEgMJCMs7DYYXF4w5ghUHgyuBFQSRNYE5hHCBc40qdoR0gzaCMA X-IronPort-AV: E=Sophos;i="4.97,1062,1389744000"; d="asc'?scan'208";a="325231137" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-2.cisco.com with ESMTP; 15 May 2014 22:31:02 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s4FMV2n3011542 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 May 2014 22:31:02 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.239]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Thu, 15 May 2014 17:31:01 -0500 From: "Fred Baker (fred)" To: Ca By Thread-Topic: [v6ops] new draft: draft-ietf-v6ops-clatip Thread-Index: AQHPcI1ZD3xRW9efUUKK6udTGgvr2g== Date: Thu, 15 May 2014 22:31:00 +0000 Message-ID: <4FCED5AE-F95C-46E1-9325-46B639CA9696@cisco.com> References: <201405061245.s46CjNEi013073@irp-view13.cisco.com> <5373082E.5040007@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_B69FE73F-BF51-41E5-8FEF-ACD50766B8E7"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1j8hQCU2urnNUB03ArNhCgjWo6M Cc: IPv6 Ops WG Subject: Re: [v6ops] new draft: draft-ietf-v6ops-clatip X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 22:31:11 -0000 --Apple-Mail=_B69FE73F-BF51-41E5-8FEF-ACD50766B8E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 14, 2014, at 9:12 AM, Ca By wrote: > The common Android solution > for this is to just use 192.0.0.4/32, only 1 IPv4 address is needed > for 464XLAT to function on Android between us girls, I would expect most usages to be point-to-point and = /32. But of course I wasn=92t asked. --Apple-Mail=_B69FE73F-BF51-41E5-8FEF-ACD50766B8E7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTdUAebjEdbHIsm0MRApoWAJ4t5QePqOlWsAY6KiWff0C3B6HVKwCfWm+G M42+iRXOFw4h4O8U1dcHmLE= =J8r2 -----END PGP SIGNATURE----- --Apple-Mail=_B69FE73F-BF51-41E5-8FEF-ACD50766B8E7-- From nobody Fri May 16 09:04:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C801A0092 for ; Fri, 16 May 2014 09:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4y5CISs-qbl7 for ; Fri, 16 May 2014 09:04:35 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CDC61A007C for ; Fri, 16 May 2014 09:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5184; q=dns/txt; s=iport; t=1400256268; x=1401465868; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=KNWckAF87HhWZ+BTUAenZbz0GwBNnbXNvJpTk/h51Po=; b=QS4f8hGV/98Qom4VPFiBozE2zmW7nPqWjGx/qbgwFqUPPO6al2nz7FqG 8K5ql6C7Nwg8f0SRmchLo9PTqcz5WRBPlvxEOTtygfb3sSyR9YsONFfYr akjYQEeeWyl0faMGsrCFzYVdZGrnQFPZHrefDx0cKtv7hWbMsiZ0RpA2D I=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFANU1dlOtJA2I/2dsb2JhbABZgwZPWMNuAYEWFnSCJQEBAQQdSyECARkDAQIvMhQHAggCBBMOBgiIJQ3NAYRzEwSJMIIRAYIrDgMBPxgCgymBFQSROIE6hmaTGYM3gXc5 X-IronPort-AV: E=Sophos;i="4.97,1068,1389744000"; d="asc'?scan'208";a="325499966" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP; 16 May 2014 16:04:27 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s4GG4Rqp001398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 16 May 2014 16:04:27 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.239]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Fri, 16 May 2014 11:04:27 -0500 From: "Fred Baker (fred)" To: IPv6 Ops WG Thread-Topic: NomCom 2014-2015 Call for Volunteers Thread-Index: AQHPcRLQ1IdZ+WY2EEmlAMPuvcKmPZtDsqIA Date: Fri, 16 May 2014 16:04:26 +0000 Message-ID: <8936E630-7FDA-40F2-B6B6-F7477017F692@cisco.com> References: <9913.1400250296@sandelman.ca> In-Reply-To: <9913.1400250296@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_B05AC604-D8EE-430D-9407-D52C10AD5272"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/SEteCxTRhJ5Y2rom-q2Ye2PcV6c Subject: [v6ops] Fwd: NomCom 2014-2015 Call for Volunteers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 16:04:37 -0000 --Apple-Mail=_B05AC604-D8EE-430D-9407-D52C10AD5272 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI. If you have been thinking that the IETF needs to change in some way = or have new leadership, this is your opportunity to make that happen. From: Michael Richardson Subject: NomCom 2014-2015 Call for Volunteers Date: May 16, 2014 at 7:24:56 AM PDT To: Reply-To: {I have to post using my subscribed address. Appologies for duplicates} The IETF nominating committee (nomcom) process for 2014-15 has begun. = The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG (including IETF Chair). Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we = have of choosing a random yet representative cross section of the IETF = population. Let's break the 200 volunteer mark again this year! The details of the operation of the nomcom can be found in RFC 3777, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As = specified in RFC 3777, that means three out of the five past meetings up to the time = this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are IETF 85(Atlanta), \ 86(Orlando), \ 87(Berlin), *** ANY THREE! 88(Vancouver), / 89(London) / If you qualify, please volunteer. However, much as we want this, = before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. The list of people and posts whose terms end with the March 2015 IETF meeting, and thus the positions for which this nomcom is responsible, = are IAOC: To be confirmed IAB: Joel Halpern Russ Housley Eliot Lear Xing Li Andrew Sullivan Dave Thaler IESG: Pete Resnick (Applications) Ted Lemon (Internet) Joel Jaeggli (Operations and Management) Richard Barnes (RAI) Adrian Farrel* (Routing) Stephen Farrell (Security) Spencer Dawkins (Transport) Jari Arkko (Gen) (names with * have publically indicated they will not serve another = term) The primary activity for this nomcom will begin in July 2014 and should = be completed in January 2015. The nomcom will have regularly scheduled conference calls to ensure progress. (We might dogfood WebRTC) There will be activities to collect requirements from the community, = review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment; but it is = also a very rewarding experience. It is very important that you be able to attend IETF91 to conduct = interviews. Being at IETF90 is useful for training. Being at IETF92 is not = essential. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 = hours) June 22, 2013, as follows: To: nomcom-chair-2014@ietf.org Subject: Nomcom 2014-15 Volunteer Please include the following information in the email body: // First/Given Name followed by Last/Family Name // matching how you enter it in the IETF Registration Form) // Typically what goes in the Company field // in the IETF Registration Form [] // For confirmation if selected You should expect an email response from me within 3 business days = stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject = line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You can find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2014/ I will be publishing a more detailed target timetable, as well as = details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Michael Richardson mcr+nomcom@sandelman.ca nomcom-chair-2014@ietf.org --Apple-Mail=_B05AC604-D8EE-430D-9407-D52C10AD5272 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTdjb+bjEdbHIsm0MRAmBAAJ9VzIMjm4WsHmiUt+5MDvFOq2YhUQCffMk6 ZOICnp+BFJ1GV0Ls3YJDlXk= =+1IB -----END PGP SIGNATURE----- --Apple-Mail=_B05AC604-D8EE-430D-9407-D52C10AD5272-- From nobody Sun May 18 06:17:42 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA581A00C2 for ; Sun, 18 May 2014 06:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.295 X-Spam-Level: * X-Spam-Status: No, score=1.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, J_CHICKENPOX_26=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUAQzZ7PZDIN for ; Sun, 18 May 2014 06:17:38 -0700 (PDT) Received: from strudel.ki.iif.hu (strudel.ki.iif.hu [IPv6:2001:738:0:411:20f:1fff:fe6e:ec1e]) by ietfa.amsl.com (Postfix) with ESMTP id C19101A0075 for ; Sun, 18 May 2014 06:17:37 -0700 (PDT) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by strudel.ki.iif.hu (Postfix) with ESMTP id 7B3D94C3; Sun, 18 May 2014 15:17:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from strudel.ki.iif.hu ([IPv6:::ffff:193.6.222.244]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id G++bPrWg1+J2; Sun, 18 May 2014 15:17:32 +0200 (CEST) Received: by strudel.ki.iif.hu (Postfix, from userid 9002) id 6DBFA506; Sun, 18 May 2014 15:17:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by strudel.ki.iif.hu (Postfix) with ESMTP id 644864C3; Sun, 18 May 2014 15:17:32 +0200 (CEST) Date: Sun, 18 May 2014 15:17:30 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@strudel.ki.iif.hu To: "Fred Baker (fred)" In-Reply-To: <8DA928AC-FCAF-4AB6-BE39-C6D155C91F17@cisco.com> Message-ID: References: <20140514000750.1AF7818000E@rfc-editor.org> <8DA928AC-FCAF-4AB6-BE39-C6D155C91F17@cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_CKREtjpgadxSDzW1EWnFgU4Qw8 Cc: V6 Ops List , "jamesrobertson@live.com" Subject: Re: [v6ops] [Technical Errata Reported] RFC4890 (3985) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 13:17:40 -0000 Dear Fred and alls, I looked it, and it seems to me the errata should be accepted. Kinest Regards, Janos Mohacsi Head of HBONE+ project Network Engineer, Director Network and Multimedia NIIF/HUNGARNET, HUNGARY Co-chair of Hungarian IPv6 Forum Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Thu, 15 May 2014, Fred Baker (fred) wrote: > Guys: > > Do we agree with this? > > On May 13, 2014, at 5:07 PM, RFC Errata System wrote: > >> The following errata report has been submitted for RFC4890, >> "Recommendations for Filtering ICMPv6 Messages in Firewalls". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=4890&eid=3985 >> >> -------------------------------------- >> Type: Technical >> Reported by: James Robertson >> >> Section: Appendix B >> >> Original Text >> ------------- >> if [ "$STATE_ENABLED" -eq "1" ] >> then >> # Allow incoming time exceeded code 0 messages >> # only for existing sessions >> for inner_prefix in $INNER_PREFIXES >> do >> ip6tables -A icmpv6-filter -m state -p icmpv6 \ >> -d $inner_prefix \ >> --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \ >> -j ACCEPT >> done >> else >> # Allow incoming time exceeded code 0 messages >> for inner_prefix in $INNER_PREFIXES >> do >> ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ >> --icmpv6-type ttl-zero-during-transit -j ACCEPT >> done >> fi >> >> Corrected Text >> -------------- >> if [ "$STATE_ENABLED" -eq "1" ] >> then >> # Allow incoming time exceeded code 0 messages >> # only for existing sessions >> for inner_prefix in $INNER_PREFIXES >> do >> ip6tables -A icmpv6-filter -m state -p icmpv6 \ >> -d $inner_prefix \ >> --state ESTABLISHED,RELATED --icmpv6-type ttl-zero-during-transit \ >> -j ACCEPT >> done >> else >> # Allow incoming time exceeded code 0 messages >> for inner_prefix in $INNER_PREFIXES >> do >> ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ >> --icmpv6-type ttl-zero-during-transit -j ACCEPT >> done >> fi >> >> Notes >> ----- >> RFC 4890 Errata ID 2706 states that icmpv6-type packet-too-big should >> state icmpv6-type ttl-zero-during-transmit. This should read >> ttl-zero-during-transit. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC4890 (draft-ietf-v6ops-icmpv6-filtering-recs-03) >> -------------------------------------- >> Title : Recommendations for Filtering ICMPv6 Messages in Firewalls >> Publication Date : May 2007 >> Author(s) : E. Davies, J. Mohacsi >> Category : INFORMATIONAL >> Source : IPv6 Operations >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG > > From nobody Sun May 18 14:05:42 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7250A1A02D3 for ; Sun, 18 May 2014 14:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.852 X-Spam-Level: X-Spam-Status: No, score=-111.852 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSURa4mbWoDm for ; Sun, 18 May 2014 14:05:39 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98E9C1A02AC for ; Sun, 18 May 2014 14:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3588; q=dns/txt; s=iport; t=1400447140; x=1401656740; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aHXMISSJwkCYlaAeMdpHCCmtfZ4ttx6PMK6ctNkCU3A=; b=KfoQzP0vu+Wenp58BbnDRtTXO51gfWgqqrnRqXutVxFeY5MThxFzqjwP K20931zKgfXq2xt5idcfWj83wWMxBkHrXxuH2T0PuniA/Ape/kYWdeLHH fR4GuijFlyU73A/TLP2hmXTzzgRIPREGv2vXs3eR4uo9vJ4YXMYdeb7I0 Y=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8FAGAfeVOtJV2Z/2dsb2JhbAA/GoMGT1isEJd4AYELFnSCJQEBAQMBeQULAgEIRjIlAgQBDQUOiB8DCQgNNtBNF4tCeYE0YQeDK4EVBJE6gTqGZpMagzdtEXFB X-IronPort-AV: E=Sophos;i="4.98,863,1392163200"; d="asc'?scan'208";a="44916002" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP; 18 May 2014 21:05:38 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s4IL5cqF008797 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 18 May 2014 21:05:38 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.239]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Sun, 18 May 2014 16:05:37 -0500 From: "Fred Baker (fred)" To: RFC Errata System , joel jaeggli Thread-Topic: [Technical Errata Reported] RFC4890 (3985) Thread-Index: AQHPctzq8qN6nK86IUeel0sJIo+V+A== Date: Sun, 18 May 2014 21:05:37 +0000 Message-ID: <797B02F7-6639-49A7-90D1-DF3C95BD1396@cisco.com> References: <20140514000750.1AF7818000E@rfc-editor.org> In-Reply-To: <20140514000750.1AF7818000E@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_863C51DE-0868-4AE6-AE20-141C5113EAFA"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yckWI273GbAHX8PVb6n_Qe6ry1c Cc: IPv6 Ops WG , "jamesrobertson@live.com" Subject: Re: [v6ops] [Technical Errata Reported] RFC4890 (3985) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 21:05:41 -0000 --Apple-Mail=_863C51DE-0868-4AE6-AE20-141C5113EAFA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I gather the erratum should be accepted. Apparently that=92s your todo, = Joel. On May 13, 2014, at 5:07 PM, RFC Errata System = wrote: > The following errata report has been submitted for RFC4890, > "Recommendations for Filtering ICMPv6 Messages in Firewalls". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4890&eid=3D3985 >=20 > -------------------------------------- > Type: Technical > Reported by: James Robertson >=20 > Section: Appendix B >=20 > Original Text > ------------- > if [ "$STATE_ENABLED" -eq "1" ] > then > # Allow incoming time exceeded code 0 messages > # only for existing sessions > for inner_prefix in $INNER_PREFIXES > do > ip6tables -A icmpv6-filter -m state -p icmpv6 \ > -d $inner_prefix \ > --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \ > -j ACCEPT > done > else > # Allow incoming time exceeded code 0 messages > for inner_prefix in $INNER_PREFIXES > do > ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ > --icmpv6-type ttl-zero-during-transit -j ACCEPT > done > fi >=20 > Corrected Text > -------------- > if [ "$STATE_ENABLED" -eq "1" ] > then > # Allow incoming time exceeded code 0 messages > # only for existing sessions > for inner_prefix in $INNER_PREFIXES > do > ip6tables -A icmpv6-filter -m state -p icmpv6 \ > -d $inner_prefix \ > --state ESTABLISHED,RELATED --icmpv6-type ttl-zero-during-transit = \ > -j ACCEPT > done > else > # Allow incoming time exceeded code 0 messages > for inner_prefix in $INNER_PREFIXES > do > ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ > --icmpv6-type ttl-zero-during-transit -j ACCEPT > done > fi >=20 > Notes > ----- > RFC 4890 Errata ID 2706 states that icmpv6-type packet-too-big should > state icmpv6-type ttl-zero-during-transmit. This should read > ttl-zero-during-transit. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC4890 (draft-ietf-v6ops-icmpv6-filtering-recs-03) > -------------------------------------- > Title : Recommendations for Filtering ICMPv6 Messages in = Firewalls > Publication Date : May 2007 > Author(s) : E. Davies, J. Mohacsi > Category : INFORMATIONAL > Source : IPv6 Operations > Area : Operations and Management > Stream : IETF > Verifying Party : IESG --Apple-Mail=_863C51DE-0868-4AE6-AE20-141C5113EAFA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTeSB6bjEdbHIsm0MRAt1dAJ4rhjHoKZrao42hMRvrsHhOF5ReNgCfSTZb HSo3LiB00Oci1vWydNfGeaE= =6B0h -----END PGP SIGNATURE----- --Apple-Mail=_863C51DE-0868-4AE6-AE20-141C5113EAFA-- From nobody Mon May 19 07:34:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2FC1A00F0; Mon, 19 May 2014 07:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.953 X-Spam-Level: X-Spam-Status: No, score=-101.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nI92DzlqJa2; Mon, 19 May 2014 07:34:28 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id DA6081A008D; Mon, 19 May 2014 07:34:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id F25E7180016; Mon, 19 May 2014 07:34:22 -0700 (PDT) To: jamesrobertson@live.com, elwynd@dial.pipex.com, mohacsi@niif.hu X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140519143422.F25E7180016@rfc-editor.org> Date: Mon, 19 May 2014 07:34:22 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Mz9VvTYAs10d2p35S3lZgLhOzo8 Cc: v6ops@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] [Errata Verified] RFC4890 (3985) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 14:34:30 -0000 The following errata report has been verified for RFC4890, "Recommendations for Filtering ICMPv6 Messages in Firewalls". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4890&eid=3985 -------------------------------------- Status: Verified Type: Technical Reported by: James Robertson Date Reported: 2014-05-13 Verified by: Joel Jaeggli (IESG) Section: Appendix B Original Text ------------- if [ "$STATE_ENABLED" -eq "1" ] then # Allow incoming time exceeded code 0 messages # only for existing sessions for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -m state -p icmpv6 \ -d $inner_prefix \ --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \ -j ACCEPT done else # Allow incoming time exceeded code 0 messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ --icmpv6-type ttl-zero-during-transit -j ACCEPT done fi Corrected Text -------------- if [ "$STATE_ENABLED" -eq "1" ] then # Allow incoming time exceeded code 0 messages # only for existing sessions for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -m state -p icmpv6 \ -d $inner_prefix \ --state ESTABLISHED,RELATED --icmpv6-type ttl-zero-during-transit \ -j ACCEPT done else # Allow incoming time exceeded code 0 messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ --icmpv6-type ttl-zero-during-transit -j ACCEPT done fi Notes ----- RFC 4890 Errata ID 2706 states that icmpv6-type packet-too-big should state icmpv6-type ttl-zero-during-transmit. This should read ttl-zero-during-transit. -------------------------------------- RFC4890 (draft-ietf-v6ops-icmpv6-filtering-recs-03) -------------------------------------- Title : Recommendations for Filtering ICMPv6 Messages in Firewalls Publication Date : May 2007 Author(s) : E. Davies, J. Mohacsi Category : INFORMATIONAL Source : IPv6 Operations Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Mon May 19 07:35:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078451A0126 for ; Mon, 19 May 2014 07:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fH4ny5qscaMn for ; Mon, 19 May 2014 07:35:37 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D45451A0102 for ; Mon, 19 May 2014 07:35:37 -0700 (PDT) Received: from [192.168.43.134] (m800536d0.tmodns.net [208.54.5.128]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s4JEZ3Sl083249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 19 May 2014 14:35:13 GMT (envelope-from joelja@bogus.com) Message-ID: <537A168F.6060600@bogus.com> Date: Mon, 19 May 2014 07:34:55 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Thunderbird/29.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , RFC Errata System References: <20140514000750.1AF7818000E@rfc-editor.org> <797B02F7-6639-49A7-90D1-DF3C95BD1396@cisco.com> In-Reply-To: <797B02F7-6639-49A7-90D1-DF3C95BD1396@cisco.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="c4JEOCrnF9j5aRkHPNcXL5tR5DeC6SGtV" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 19 May 2014 14:35:25 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kc0XQHvJKYTV2VoTmg-9dTnKdB4 Cc: IPv6 Ops WG , "jamesrobertson@live.com" Subject: Re: [v6ops] [Technical Errata Reported] RFC4890 (3985) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 14:35:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --c4JEOCrnF9j5aRkHPNcXL5tR5DeC6SGtV Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 5/18/14, 2:05 PM, Fred Baker (fred) wrote: > I gather the erratum should be accepted. Apparently that=92s your todo,= Joel. Set as verified. Thank you. joel > On May 13, 2014, at 5:07 PM, RFC Errata System wrote: >=20 >> The following errata report has been submitted for RFC4890, >> "Recommendations for Filtering ICMPv6 Messages in Firewalls". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D4890&eid=3D3985 >> >> -------------------------------------- >> Type: Technical >> Reported by: James Robertson >> >> Section: Appendix B >> >> Original Text >> ------------- >> if [ "$STATE_ENABLED" -eq "1" ] >> then >> # Allow incoming time exceeded code 0 messages >> # only for existing sessions >> for inner_prefix in $INNER_PREFIXES >> do >> ip6tables -A icmpv6-filter -m state -p icmpv6 \ >> -d $inner_prefix \ >> --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \ >> -j ACCEPT >> done >> else >> # Allow incoming time exceeded code 0 messages >> for inner_prefix in $INNER_PREFIXES >> do >> ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ >> --icmpv6-type ttl-zero-during-transit -j ACCEPT >> done >> fi >> >> Corrected Text >> -------------- >> if [ "$STATE_ENABLED" -eq "1" ] >> then >> # Allow incoming time exceeded code 0 messages >> # only for existing sessions >> for inner_prefix in $INNER_PREFIXES >> do >> ip6tables -A icmpv6-filter -m state -p icmpv6 \ >> -d $inner_prefix \ >> --state ESTABLISHED,RELATED --icmpv6-type ttl-zero-during-transit = \ >> -j ACCEPT >> done >> else >> # Allow incoming time exceeded code 0 messages >> for inner_prefix in $INNER_PREFIXES >> do >> ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ >> --icmpv6-type ttl-zero-during-transit -j ACCEPT >> done >> fi >> >> Notes >> ----- >> RFC 4890 Errata ID 2706 states that icmpv6-type packet-too-big should >> state icmpv6-type ttl-zero-during-transmit. This should read >> ttl-zero-during-transit. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary.=20 >> >> -------------------------------------- >> RFC4890 (draft-ietf-v6ops-icmpv6-filtering-recs-03) >> -------------------------------------- >> Title : Recommendations for Filtering ICMPv6 Messages in= Firewalls >> Publication Date : May 2007 >> Author(s) : E. Davies, J. Mohacsi >> Category : INFORMATIONAL >> Source : IPv6 Operations >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG >=20 --c4JEOCrnF9j5aRkHPNcXL5tR5DeC6SGtV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlN6FpAACgkQ8AA1q7Z/VrLiewCdHyYjWh4vfMMTE7rT/My+HD0u qQAAn0hero8vfVbRxladwLQ4OAL9RXeG =SzZZ -----END PGP SIGNATURE----- --c4JEOCrnF9j5aRkHPNcXL5tR5DeC6SGtV-- From nobody Mon May 19 07:37:20 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3B51A0152 for ; Mon, 19 May 2014 07:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5y3kEFRdmz7D for ; Mon, 19 May 2014 07:37:12 -0700 (PDT) Received: from auth.a.painless.aa.net.uk (a.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BBC81A010F for ; Mon, 19 May 2014 07:37:12 -0700 (PDT) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by a.painless.aa.net.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1WmOgX-0004xQ-71; Mon, 19 May 2014 15:37:06 +0100 From: Elwyn Davies To: joel jaeggli In-Reply-To: <537A168F.6060600@bogus.com> References: <20140514000750.1AF7818000E@rfc-editor.org> <797B02F7-6639-49A7-90D1-DF3C95BD1396@cisco.com> <537A168F.6060600@bogus.com> Content-Type: text/plain; charset="iso-8859-7" Date: Mon, 19 May 2014 15:36:57 +0100 Message-Id: <1400510218.29419.2677.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4TF1zBFEbsmMzZNPRepOsO5ExIU Cc: IPv6 Ops WG , "jamesrobertson@live.com" , RFC Errata System Subject: Re: [v6ops] [Technical Errata Reported] RFC4890 (3985) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 14:37:17 -0000 Thanks, Elwyn On Mon, 2014-05-19 at 07:34 -0700, joel jaeggli wrote: > On 5/18/14, 2:05 PM, Fred Baker (fred) wrote: > > I gather the erratum should be accepted. Apparently that=A2s your todo,= Joel. >=20 > Set as verified. >=20 > Thank you. > joel >=20 > > On May 13, 2014, at 5:07 PM, RFC Errata System wrote: > >=20 > >> The following errata report has been submitted for RFC4890, > >> "Recommendations for Filtering ICMPv6 Messages in Firewalls". > >> > >> -------------------------------------- > >> You may review the report below and at: > >> http://www.rfc-editor.org/errata_search.php?rfc=3D4890&eid=3D3985 > >> > >> -------------------------------------- > >> Type: Technical > >> Reported by: James Robertson > >> > >> Section: Appendix B > >> > >> Original Text > >> ------------- > >> if [ "$STATE_ENABLED" -eq "1" ] > >> then > >> # Allow incoming time exceeded code 0 messages > >> # only for existing sessions > >> for inner_prefix in $INNER_PREFIXES > >> do > >> ip6tables -A icmpv6-filter -m state -p icmpv6 \ > >> -d $inner_prefix \ > >> --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \ > >> -j ACCEPT > >> done > >> else > >> # Allow incoming time exceeded code 0 messages > >> for inner_prefix in $INNER_PREFIXES > >> do > >> ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ > >> --icmpv6-type ttl-zero-during-transit -j ACCEPT > >> done > >> fi > >> > >> Corrected Text > >> -------------- > >> if [ "$STATE_ENABLED" -eq "1" ] > >> then > >> # Allow incoming time exceeded code 0 messages > >> # only for existing sessions > >> for inner_prefix in $INNER_PREFIXES > >> do > >> ip6tables -A icmpv6-filter -m state -p icmpv6 \ > >> -d $inner_prefix \ > >> --state ESTABLISHED,RELATED --icmpv6-type ttl-zero-during-transit = \ > >> -j ACCEPT > >> done > >> else > >> # Allow incoming time exceeded code 0 messages > >> for inner_prefix in $INNER_PREFIXES > >> do > >> ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ > >> --icmpv6-type ttl-zero-during-transit -j ACCEPT > >> done > >> fi > >> > >> Notes > >> ----- > >> RFC 4890 Errata ID 2706 states that icmpv6-type packet-too-big should > >> state icmpv6-type ttl-zero-during-transmit. This should read > >> ttl-zero-during-transit. > >> > >> Instructions: > >> ------------- > >> This errata is currently posted as "Reported". If necessary, please > >> use "Reply All" to discuss whether it should be verified or > >> rejected. When a decision is reached, the verifying party (IESG) > >> can log in to change the status and edit the report, if necessary.=20 > >> > >> -------------------------------------- > >> RFC4890 (draft-ietf-v6ops-icmpv6-filtering-recs-03) > >> -------------------------------------- > >> Title : Recommendations for Filtering ICMPv6 Messages in= Firewalls > >> Publication Date : May 2007 > >> Author(s) : E. Davies, J. Mohacsi > >> Category : INFORMATIONAL > >> Source : IPv6 Operations > >> Area : Operations and Management > >> Stream : IETF > >> Verifying Party : IESG > >=20 >=20 >=20 From nobody Mon May 19 11:58:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C741A026F; Mon, 19 May 2014 11:58:32 -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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxeGT-p5lhDn; Mon, 19 May 2014 11:58:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93EE41A039F; Mon, 19 May 2014 11:58:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140519185805.20830.51452.idtracker@ietfa.amsl.com> Date: Mon, 19 May 2014 11:58:05 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ug7A9HSicpOFKfkzVKkQC6Z0qGg Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-clatip-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 18:58:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv4 Service Continuity Prefix Author : Cameron Byrne Filename : draft-ietf-v6ops-clatip-01.txt Pages : 4 Date : 2014-05-19 Abstract: DS-Lite, defined in RFC 6333, directs IANA to reserve 192.0.0.0/29 for the B4 element. This memo directs IANA to generalize that reservation to include other cases where a non-routed IPv4 interface must be numbered as part of an IPv6 transition solution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-clatip/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-clatip-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-clatip-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 19 22:18:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4273A1A0016 for ; Mon, 19 May 2014 22:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B33Adpu9JWQW for ; Mon, 19 May 2014 22:18:27 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C5241A0234 for ; Mon, 19 May 2014 22:18:27 -0700 (PDT) Received: from ([24.40.56.121]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.133475423; Mon, 19 May 2014 23:18:20 -0600 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.114]) by pacdcexhub04.cable.comcast.com ([fe80::1532:d330:f9a5:c8a1%18]) with mapi id 14.03.0181.006; Tue, 20 May 2014 01:18:20 -0400 From: "Brzozowski, John" To: v6ops Thread-Topic: Time for a change... Thread-Index: AQHPc+rparD7kPui7UaKIzM9AGDfiA== Date: Tue, 20 May 2014 05:18:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [68.87.16.247] Content-Type: text/plain; charset="utf-8" Content-ID: <6863FF81B989AA4F838BFA2CC3BB0176@cable.comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mfKvnHct45WracXjJhWkrb_bsls Cc: chairs Subject: [v6ops] Time for a change... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 05:18:28 -0000 Rm9sa3MsDQoNClRpbWUgYXZhaWxhYmlsaXR5IGhhcyBiZWNvbWUgYSBiaXQgb2YgYSBjaGFsbGVu Z2UgZm9yIG1lIGFzIG9mIGxhdGUuICBUaGUNCmZvY3VzIG9mIG15IGRheSBqb2IgaGFzIGJlZW4g aW1wYWN0aW5nIHRoZSBhdmFpbGFiaWxpdHkgb2YgY3ljbGVzIHRoYXQgSQ0KaGF2ZSB0byBoZWxw IEZyZWQgcnVuIGFuZCBndWlkZSB0aGUgd29ya2luZyBncm91cCBvbiBhIGRhaWx5IGJhc2lzLiAg Sm9lbCwNCkZyZWQsIGFuZCBJIGFncmVlIHRoYXQgaXQgbWF5IGJlIGJlc3QgdG8gaWRlbnRpZnkg YSBuZXcgY28tY2hhaXIgZm9yDQp2Nm9wcywgYXMgc3VjaCBJIHdpbGwgYmUgc3RlcHBpbmcgZG93 biBhcyBXRyBjby1jaGFpci4NCg0KSSB3YW50IHRvIHRha2UgYSBtb21lbnQgdG8gdGhhbmsgRnJl ZCwgSm9lbCwgYW5kIHRoZSBlbnRpcmUgV0cgZm9yIHRoZQ0Kb3Bwb3J0dW5pdHkgdG8gd29yayB3 aXRoIHlvdSBhbGwuDQoNCg0KDQpBbGwgdGhlIGJlc3QsDQoNCkpvaG4NCg0K From nobody Mon May 19 23:00:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75A81A028C for ; Mon, 19 May 2014 23:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytlHd3ih8rQY for ; Mon, 19 May 2014 23:00:05 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 505D51A028F for ; Mon, 19 May 2014 23:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1373; q=dns/txt; s=iport; t=1400565605; x=1401775205; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FLX8cMz/VSV2JdPm9K86fPkTh6uaQyDbumb0Ll+SDAE=; b=HqxXYCj7HS7pWzK507B48jtnZzEMJWMEsEN4U2Ch9ME0JKSGjGgPOdUE etYNF/+WYp4fL85On5xpNIoOnSjtR8H7fNiEjY/rSvaavDS0k5tDHed2V L9uUHXI9pPlTFlvFU50qqO/UK9SRwvZaV6BowDXRagNlu138s/AmiYzne w=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAEXuelOtJA2N/2dsb2JhbABPCoMGgSnEEAGBFhZ0giUBAQEDAXkFCwIBCEYyJQIEDgUOiCsI0mUXjXJcB4MrgRUEkT+BOoZnkx2DOIIw X-IronPort-AV: E=Sophos;i="4.98,871,1392163200"; d="asc'?scan'208";a="326259952" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-7.cisco.com with ESMTP; 20 May 2014 06:00:04 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s4K604BN013082 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 May 2014 06:00:04 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.239]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Tue, 20 May 2014 01:00:04 -0500 From: "Fred Baker (fred)" To: John Brzozowski Thread-Topic: Time for a change... Thread-Index: AQHPc/C+SdaMhXDQckCOD8p+OEFdRw== Date: Tue, 20 May 2014 06:00:03 +0000 Message-ID: <3028D33A-DD13-49DF-9114-D779F418CCE3@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_B6ECD7EC-023E-477F-95D3-EC1390DDEB9F"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/lnZEfH3qJUQC5nAFU8S2Cb8EoDw Cc: v6ops , chairs Subject: Re: [v6ops] Time for a change... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 06:00:08 -0000 --Apple-Mail=_B6ECD7EC-023E-477F-95D3-EC1390DDEB9F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 19, 2014, at 10:18 PM, Brzozowski, John = wrote: > Folks, >=20 > Time availability has become a bit of a challenge for me as of late. = The > focus of my day job has been impacting the availability of cycles that = I > have to help Fred run and guide the working group on a daily basis. = Joel, > Fred, and I agree that it may be best to identify a new co-chair for > v6ops, as such I will be stepping down as WG co-chair. >=20 > I want to take a moment to thank Fred, Joel, and the entire WG for the > opportunity to work with you all. >=20 > All the best, >=20 > John Thanks, John, for your help and your participation. --Apple-Mail=_B6ECD7EC-023E-477F-95D3-EC1390DDEB9F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTeu9cbjEdbHIsm0MRAk/fAKCkJ8/jOpf9wctcFxIALdb0XT9jrgCgifYz /kHJqfRnDFWOeOAwQDgR+uw= =+JZj -----END PGP SIGNATURE----- --Apple-Mail=_B6ECD7EC-023E-477F-95D3-EC1390DDEB9F-- From nobody Mon May 19 23:27:17 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664071A028C for ; Mon, 19 May 2014 23:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgyIKRpzMjdX for ; Mon, 19 May 2014 23:27:15 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 579C31A02A6 for ; Mon, 19 May 2014 23:27:15 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s4K6RCdp089159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 20 May 2014 06:27:13 GMT (envelope-from joelja@bogus.com) Message-ID: <537AF5B8.7000304@bogus.com> Date: Mon, 19 May 2014 23:27:04 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Thunderbird/29.0 MIME-Version: 1.0 To: "Brzozowski, John" , v6ops References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MjJEsFQTARImAhrRaqTOhDsFSsc9giFIS" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Tue, 20 May 2014 06:27:13 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/C87fdvPBTrnki_E5Zf5z8meHwYc Cc: chairs Subject: Re: [v6ops] Time for a change... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 06:27:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MjJEsFQTARImAhrRaqTOhDsFSsc9giFIS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/19/14, 10:18 PM, Brzozowski, John wrote: > Folks, >=20 > Time availability has become a bit of a challenge for me as of late. T= he > focus of my day job has been impacting the availability of cycles that = I > have to help Fred run and guide the working group on a daily basis. Jo= el, > Fred, and I agree that it may be best to identify a new co-chair for > v6ops, as such I will be stepping down as WG co-chair. John, I am very sorry to see you go. It is not everyone who can step into this role having brought so much real-world deployment to fruition. I hope that we can retain you as a contributor and that your involvement in the IETF can escalate again as time permits. In the mean-time I wish you well and good luck. thanks joel > I want to take a moment to thank Fred, Joel, and the entire WG for the > opportunity to work with you all. >=20 >=20 >=20 > All the best, >=20 > John >=20 >=20 --MjJEsFQTARImAhrRaqTOhDsFSsc9giFIS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlN69bkACgkQ8AA1q7Z/VrJmFwCfSmHo0YjhFIuZD6/zMQ31PP3s hS4AnR+bCcbfmSWKNOAUP1pTTZFhJOTJ =+hlr -----END PGP SIGNATURE----- --MjJEsFQTARImAhrRaqTOhDsFSsc9giFIS-- From nobody Mon May 19 23:38:12 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842D21A02F1 for ; Mon, 19 May 2014 23:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3uhtZSOw4uc for ; Mon, 19 May 2014 23:38:08 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B611A02EA for ; Mon, 19 May 2014 23:38:08 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id jz11so32300veb.21 for ; Mon, 19 May 2014 23:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HlRT5JrMyu1jJrbZPUrGpw01/RvLilSfwZvdlWqOTPI=; b=pFm3OwUw0Nk6Jx0sRwyuuf73QpPnSkfpih+iodA8RTE9liUqIbsvuz4w0NZ3viyhjb gLcBjR1wYMNCojEIQFHmJDQ2nkeXipL8WSuhOXPY/ZnpYhQtcGz9Rz1OprO7mIPGzvax 3e9IwmXftseRV2zFX3l9rdhqfKJwYMz6/5QDWo0CYW670gVVjvxC9FrGapGMf9iyrKGI lKzC83WSko1w3vZppFR+chP2c74kXL70pb5FzLOJ5fQ24nhvi7kWPusZ5yng70Kilq8i OSyIu5xvKssMLnjgwJI6woggyDIJcfHF8bYU44eBNMu7bddX+zaRJGp5jeeGQdEyvD6W hc0w== MIME-Version: 1.0 X-Received: by 10.52.120.39 with SMTP id kz7mr1768171vdb.41.1400567887823; Mon, 19 May 2014 23:38:07 -0700 (PDT) Sender: mpetach@gmail.com Received: by 10.220.173.193 with HTTP; Mon, 19 May 2014 23:38:07 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 May 2014 23:38:07 -0700 X-Google-Sender-Auth: 4mwR4EPavgzAdSCRLZVWyye_Hnc Message-ID: From: Matthew Petach To: "Brzozowski, John" Content-Type: multipart/alternative; boundary=089e013a1d707007c704f9cf1fe8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/cIYNN6DZ4gpR_N3Xy-u5gaWGD8Y Cc: v6ops , chairs Subject: Re: [v6ops] Time for a change... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 06:38:09 -0000 --089e013a1d707007c704f9cf1fe8 Content-Type: text/plain; charset=UTF-8 On Mon, May 19, 2014 at 10:18 PM, Brzozowski, John < John_Brzozowski@cable.comcast.com> wrote: > Folks, > > Time availability has become a bit of a challenge for me as of late. The > focus of my day job has been impacting the availability of cycles that I > have to help Fred run and guide the working group on a daily basis. Joel, > Fred, and I agree that it may be best to identify a new co-chair for > v6ops, as such I will be stepping down as WG co-chair. > > I want to take a moment to thank Fred, Joel, and the entire WG for the > opportunity to work with you all. > > All the best, > > John > John, Thank you for all your hard work supporting the efforts of the WG, and carrying the v6 torch; you've done an incredible amount to move the state of the industry forward, and demonstrate real-world deployments at a size and scope far beyond what most networks are even now starting to begin thinking about. Keep fighting the good fight, and if there's ever anything we can do to help out, just let us know. Thank you again for all your help! Matt --089e013a1d707007c704f9cf1fe8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, May 19, 2014 at 10:18 PM, Brzozowski, John <John_Brzozowski@cable.comcast.com> wrote:
Folks,

Time availability has become a bit of a challenge for me as of late. =C2=A0= The
focus of my day job has been impacting the availability of cycles that I have to help Fred run and guide the working group on a daily basis. =C2=A0J= oel,
Fred, and I agree that it may be best to identify a new co-chair for
v6ops, as such I will be stepping down as WG co-chair.

I want to take a moment to thank Fred, Joel, and the entire WG for the
opportunity to work with you all.

All the best,

John

John,

Thank you for all you= r hard work supporting
the efforts of the WG, and carrying the v6
torch; you've done an incredible amount
to move the state of= the industry forward,
and demonstrate real-world deployments
at a size and scope far beyond wh= at
most networks are even now starting
to begin thinking about.
Keep fighting the good fight, and if
there's ever anyth= ing we can do to
help out, just let us know.

Thank you again for all your help!
Matt
=C2=A0
--089e013a1d707007c704f9cf1fe8-- From nobody Tue May 20 10:43:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBC51A02D7 for ; Tue, 20 May 2014 10:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHvhHq5FXghB for ; Tue, 20 May 2014 10:43:26 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02C571A02C9 for ; Tue, 20 May 2014 10:43:25 -0700 (PDT) Received: from mb-aye.local ([173.247.205.34]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s4KHhO5A098248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 20 May 2014 17:43:25 GMT (envelope-from joelja@bogus.com) Message-ID: <537B943C.7000204@bogus.com> Date: Tue, 20 May 2014 10:43:24 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Thunderbird/29.0 MIME-Version: 1.0 To: IPv6 Ops WG , V6ops Chairs X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="18JipmONvaoqODm7ETsxFORwJXra7dPpt" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Tue, 20 May 2014 17:43:25 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LEdGCTZbnhBhfAtTfbMQubRwYno Subject: [v6ops] v6ops Co-chair administrivia. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 17:43:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --18JipmONvaoqODm7ETsxFORwJXra7dPpt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fyi, It wasn't that long ago that we filled this position previously. We have some decent candidates in the pool and we should be able to announce a replacement within a coupled of days after confirming willingness and availability. Thanks joel --18JipmONvaoqODm7ETsxFORwJXra7dPpt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlN7lDwACgkQ8AA1q7Z/VrKf4ACfX358MAgilKKeBOtvhZKaIRMI IV4An1b+muGisjlyUA08XZG0EP1hAAzO =Xafq -----END PGP SIGNATURE----- --18JipmONvaoqODm7ETsxFORwJXra7dPpt-- From nobody Wed May 21 10:39:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0D71A06C5 for ; Wed, 21 May 2014 10:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.257 X-Spam-Level: X-Spam-Status: No, score=0.257 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXKKyICvR2vI for ; Wed, 21 May 2014 10:39:30 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C6B9E1A048D for ; Wed, 21 May 2014 10:39:29 -0700 (PDT) Received: from [172.26.21.123] (65-123-255-137.dia.static.qwest.net [65.123.255.137]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s4LHcLlR030974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 21 May 2014 10:38:21 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s4LHcLlR030974 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1400693904; bh=nWX9r8IM/FoGZc0YD0iERNlcFAY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=cV9dTlKaYLBuoZgLJK+4G22Oa4CZq2FcWKF9IYXqceQoEXmgTipYAs9OuoXbuxWQK o9BssNpCFBD9+XXdbQdtqxvlF65t2W+GKm42Q7P5yfgJ2+ca4uQFobihyCc1l2GDAE rvtvEv/m5uw/2T3fsbirFDJmnfCJPJBrCMIslrDU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: Date: Wed, 21 May 2014 10:38:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Brzozowski, John" X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 21 May 2014 10:38:24 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/b6xONQbE3gymglnq9yQ6V27Hw7I Cc: v6ops , chairs Subject: Re: [v6ops] Time for a change... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 17:39:31 -0000 Thanks, John for all that you have done. Owen On May 19, 2014, at 10:18 PM, Brzozowski, John = wrote: > Folks, >=20 > Time availability has become a bit of a challenge for me as of late. = The > focus of my day job has been impacting the availability of cycles that = I > have to help Fred run and guide the working group on a daily basis. = Joel, > Fred, and I agree that it may be best to identify a new co-chair for > v6ops, as such I will be stepping down as WG co-chair. >=20 > I want to take a moment to thank Fred, Joel, and the entire WG for the > opportunity to work with you all. >=20 >=20 >=20 > All the best, >=20 > John >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed May 21 12:43:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1131A0843 for ; Wed, 21 May 2014 12:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dp0GpK8MpX1N for ; Wed, 21 May 2014 12:43:17 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232511A083F for ; Wed, 21 May 2014 12:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2291; q=dns/txt; s=iport; t=1400701396; x=1401910996; h=from:to:subject:date:message-id:mime-version; bh=yC0+C+oD9rvf4u0geJGj7z9clM8sQmq26Xy3K9URi0M=; b=XZIzhLQTD/J8BzR0bDr3Ez5IRBvZksNSil5K5jW4yXvWvzpwUh4n0jaQ CY1DFNTTOWlasrbc3wIFouASOy7mTlA/Fj5p+sPvxBsWTPt9TSOz9NnvW fsZGJ7+iysLL5Eg+KcnNjdgQh+VvS42ygqG9zbZ4vXY/YiLcSL5ErVlaX U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAI0BfVOtJV2Y/2dsb2JhbABZgwmBKsUqFnSCLGUmAYEAJwQhiDOhXrRgF5IAgRUEkUqBOoZqkySDOIIw X-IronPort-AV: E=Sophos;i="4.98,881,1392163200"; d="asc'?scan'208";a="323749412" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 21 May 2014 19:43:01 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s4LJh1RA008158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 21 May 2014 19:43:01 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.239]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Wed, 21 May 2014 14:43:00 -0500 From: "Fred Baker (fred)" To: v6ops Thread-Topic: Planning for IETF #90 Thread-Index: AQHPdSzfBnWUD3cMwE+7V8ANe7NhvA== Date: Wed, 21 May 2014 19:43:00 +0000 Message-ID: <43AE4B9F-206F-4969-81B8-AE003DC9DF4C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_9C081ED2-402F-496A-AD07-F80A03FD4D05"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Xs5RxJRDq6x5oBBmqp2zDS_Oudg Subject: [v6ops] Planning for IETF #90 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 19:43:19 -0000 --Apple-Mail=_9C081ED2-402F-496A-AD07-F80A03FD4D05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 IETF #90 is two months away, and we have about six weeks to get drafts = updated or new drafts filed. This is a heads-up. My rule for putting = drafts on the agenda is that they are file or updated since the last = IETF meeting and have had supportive working group commentary on the = list. Filing at the last instant generally doesn=92t help with folks=92 = commentary - you want to give them some time to read and think. So, = filing drafts or making updates in June is recommended. Current draft status: IESG: Jan 12 draft-ietf-v6ops-enterprise-incremental-ipv6 Mar 10 draft-ietf-v6ops-nat64-experience Apr 1 draft-ietf-v6ops-64share Exiting WGLC; on its way to IESG: May 19 draft-ietf-v6ops-clatip Working Group Document updated since IETF: Mar 6 draft-ietf-v6ops-design-choices Mar 11 draft-ietf-v6ops-mobile-device-profile Individual Submission updated since IETF: Mar 4 draft-cui-v6ops-lte-lw4over6 Apr 7 draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node Working Group Document NOT updated since IETF: Nov 26 draft-ietf-v6ops-dhcpv6-slaac-problem Dec 6 draft-ietf-v6ops-balanced-ipv6-security Jan 13 draft-ietf-v6ops-ipv6-roaming-analysis Feb 4 draft-ietf-v6ops-dc-ipv6 Feb 14 draft-ietf-v6ops-ula-usage-recommendations Individual Submission NOT updated since IETF: Dec 3 draft-taylor-v6ops-fragdrop Jan 11 draft-osamu-v6ops-ipv4-literal-in-url Feb 13 draft-cui-v6ops-lte-lw4over6 Feb 14 draft-foo-v6ops-6rdmtu Feb 14 draft-liu-v6ops-dhcpv6-slaac-guidance --Apple-Mail=_9C081ED2-402F-496A-AD07-F80A03FD4D05 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTfQGxbjEdbHIsm0MRAlEkAKCLczWNuIWqCkmHlmUy1iP+L5qLagCfYk13 nHmXDj4TlmVwbuR/pJh0IMQ= =80MN -----END PGP SIGNATURE----- --Apple-Mail=_9C081ED2-402F-496A-AD07-F80A03FD4D05-- From nobody Wed May 21 14:30:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883B91A02D1 for ; Wed, 21 May 2014 14:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0abRAaIkgJo for ; Wed, 21 May 2014 14:30:08 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACA3D1A075F for ; Wed, 21 May 2014 14:30:08 -0700 (PDT) Received: from mb-aye.local ([173.247.205.34]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s4LLTjD0018658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 21 May 2014 21:29:45 GMT (envelope-from joelja@bogus.com) Message-ID: <537D1AC8.6070200@bogus.com> Date: Wed, 21 May 2014 14:29:44 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Thunderbird/29.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , Elwyn Davies References: <20140514000750.1AF7818000E@rfc-editor.org> <8DA928AC-FCAF-4AB6-BE39-C6D155C91F17@cisco.com> <53743DEA.4030703@bogus.com> <1400149479.29419.2590.camel@mightyatom> <10FBEF6F-DD9D-4DA6-89A6-8699110270B4@cisco.com> In-Reply-To: <10FBEF6F-DD9D-4DA6-89A6-8699110270B4@cisco.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gvvftjI3A8WWjvmnViCFBigipHNNhjULn" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Wed, 21 May 2014 21:29:47 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xwhC4yaRfTInuo7qNu0b-RFwHRo Cc: V6 Ops List , "jamesrobertson@live.com" Subject: Re: [v6ops] [Technical Errata Reported] RFC4890 (3985) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 21:30:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gvvftjI3A8WWjvmnViCFBigipHNNhjULn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, just to confirm with you guys that I verified that errata. joel On 5/15/14, 7:44 AM, Fred Baker (fred) wrote: > Thanks >=20 > On May 15, 2014, at 3:24 AM, Elwyn Davies wrote= : >=20 >> HI. >> >> This looks correct. I am forwarding the message to Suresh who actuall= y >> authored the script for an opinion. >> >> Assuming that he concurs, I don't see any harm in issuing an erratum a= nd >> a very few people might actually be using the script verbatim. >> >> There was a move afoot to make a new version (and possibly transition >> this to BCP) but we haven't managed to get it together to do so yet. >> >> Regards, >> Elwyn >> >> On Wed, 2014-05-14 at 21:09 -0700, joel jaeggli wrote: >>> On 5/14/14, 8:25 PM, Fred Baker (fred) wrote: >>>> Guys: >>>> >>>> Do we agree with this? >>> >>> it's not really normative text, it's an example in an appendix. >>> >>> assuming you think it's an issue and the correction is reasonable I >>> would probably just hold it for a document update (seems unlikely atm= >>> but who knows) >>> >>> >>>> On May 13, 2014, at 5:07 PM, RFC Errata System wrote: >>>> >>>>> The following errata report has been submitted for RFC4890, >>>>> "Recommendations for Filtering ICMPv6 Messages in Firewalls". >>>>> >>>>> -------------------------------------- >>>>> You may review the report below and at: >>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D4890&eid=3D3985 >>>>> >>>>> -------------------------------------- >>>>> Type: Technical >>>>> Reported by: James Robertson >>>>> >>>>> Section: Appendix B >>>>> >>>>> Original Text >>>>> ------------- >>>>> if [ "$STATE_ENABLED" -eq "1" ] >>>>> then >>>>> # Allow incoming time exceeded code 0 messages >>>>> # only for existing sessions >>>>> for inner_prefix in $INNER_PREFIXES >>>>> do >>>>> ip6tables -A icmpv6-filter -m state -p icmpv6 \ >>>>> -d $inner_prefix \ >>>>> --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \ >>>>> -j ACCEPT >>>>> done >>>>> else >>>>> # Allow incoming time exceeded code 0 messages >>>>> for inner_prefix in $INNER_PREFIXES >>>>> do >>>>> ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ >>>>> --icmpv6-type ttl-zero-during-transit -j ACCEPT >>>>> done >>>>> fi >>>>> >>>>> Corrected Text >>>>> -------------- >>>>> if [ "$STATE_ENABLED" -eq "1" ] >>>>> then >>>>> # Allow incoming time exceeded code 0 messages >>>>> # only for existing sessions >>>>> for inner_prefix in $INNER_PREFIXES >>>>> do >>>>> ip6tables -A icmpv6-filter -m state -p icmpv6 \ >>>>> -d $inner_prefix \ >>>>> --state ESTABLISHED,RELATED --icmpv6-type ttl-zero-during-transi= t \ >>>>> -j ACCEPT >>>>> done >>>>> else >>>>> # Allow incoming time exceeded code 0 messages >>>>> for inner_prefix in $INNER_PREFIXES >>>>> do >>>>> ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ >>>>> --icmpv6-type ttl-zero-during-transit -j ACCEPT >>>>> done >>>>> fi >>>>> >>>>> Notes >>>>> ----- >>>>> RFC 4890 Errata ID 2706 states that icmpv6-type packet-too-big shou= ld >>>>> state icmpv6-type ttl-zero-during-transmit. This should read >>>>> ttl-zero-during-transit. >>>>> >>>>> Instructions: >>>>> ------------- >>>>> This errata is currently posted as "Reported". If necessary, please= >>>>> use "Reply All" to discuss whether it should be verified or >>>>> rejected. When a decision is reached, the verifying party (IESG) >>>>> can log in to change the status and edit the report, if necessary. = >>>>> >>>>> -------------------------------------- >>>>> RFC4890 (draft-ietf-v6ops-icmpv6-filtering-recs-03) >>>>> -------------------------------------- >>>>> Title : Recommendations for Filtering ICMPv6 Messages= in Firewalls >>>>> Publication Date : May 2007 >>>>> Author(s) : E. Davies, J. Mohacsi >>>>> Category : INFORMATIONAL >>>>> Source : IPv6 Operations >>>>> Area : Operations and Management >>>>> Stream : IETF >>>>> Verifying Party : IESG >>>> >>> >>> >> >=20 --gvvftjI3A8WWjvmnViCFBigipHNNhjULn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlN9GsgACgkQ8AA1q7Z/VrJdpwCfZn0KjYtBFDnzb/RW98OcngN4 80cAn10U0J/CTj1U7h4rZgJLcO/AVr8f =csX/ -----END PGP SIGNATURE----- --gvvftjI3A8WWjvmnViCFBigipHNNhjULn-- From nobody Wed May 21 22:40:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64691A004D for ; Wed, 21 May 2014 22:40:32 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIrO5_AIBcvz for ; Wed, 21 May 2014 22:40:30 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435851A0011 for ; Wed, 21 May 2014 22:40:30 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id pn19so2248013lab.6 for ; Wed, 21 May 2014 22:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=/4p/EbzSUOvjFy56XvMWknb2ekvRcd9gpUeU/xmgZBA=; b=DEbOERq01JGRHxTBrxa3GZAxroNvAUQWuocIxOk++J+gsUB+eqxv2glVo9W+pgjjRx qLP2iXnhzMqooigkrtS7XmsWV4gCGKGddfWeoXuRWJY0Fo6RdN/1dTlmPGqwqwNmBghW v2i7bsOMsf+bfW/fcFFmicW4+R9l8WMEOvbFlfHEFCCCUCqpDfqS48cEUb6B/ADH9Vuh 2W1lgSJl7KTWNp7VNSdfV7n6jJwzZZZyy4EbMZQ8+qsAmW1xfc3jWwNrAT1c7ZQ3z9OT mGLPHUeP8jS11j0FYj0MeLCH2YyU6f5tC2hd/yW64DGEuTDmESAM6ubFTJpnckZ79oww LXXg== MIME-Version: 1.0 X-Received: by 10.112.52.167 with SMTP id u7mr38894779lbo.28.1400737227572; Wed, 21 May 2014 22:40:27 -0700 (PDT) Received: by 10.114.21.4 with HTTP; Wed, 21 May 2014 22:40:27 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 May 2014 10:40:27 +0500 Message-ID: From: Tariq Saraj To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=001a11c3f0acdf8aa104f9f68cbf Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Mb7Y_vJfqcVHj_SpqCd9a2GKVRE Subject: Re: [v6ops] v6ops Digest, Vol 45, Issue 14 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 05:40:32 -0000 --001a11c3f0acdf8aa104f9f68cbf Content-Type: text/plain; charset=UTF-8 Wish you all the best for future.... On Thu, May 22, 2014 at 12:00 AM, wrote: > Send v6ops mailing list submissions to > v6ops@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/v6ops > or, via email, send a message with subject or body 'help' to > v6ops-request@ietf.org > > You can reach the person managing the list at > v6ops-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of v6ops digest..." > > Today's Topics: > > 1. Re: Time for a change... (Owen DeLong) > > > ---------- Forwarded message ---------- > From: Owen DeLong > To: "Brzozowski, John" > Cc: v6ops , chairs > Date: Wed, 21 May 2014 10:38:21 -0700 > Subject: Re: [v6ops] Time for a change... > Thanks, John for all that you have done. > > Owen > > On May 19, 2014, at 10:18 PM, Brzozowski, John < > John_Brzozowski@Cable.Comcast.com> wrote: > > > Folks, > > > > Time availability has become a bit of a challenge for me as of late. The > > focus of my day job has been impacting the availability of cycles that I > > have to help Fred run and guide the working group on a daily basis. > Joel, > > Fred, and I agree that it may be best to identify a new co-chair for > > v6ops, as such I will be stepping down as WG co-chair. > > > > I want to take a moment to thank Fred, Joel, and the entire WG for the > > opportunity to work with you all. > > > > > > > > All the best, > > > > John > > > > _______________________________________________ > > 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 > > -- Regards Tariq Saraj Center for Research in Networks and Telecom (*CoReNeT*) --001a11c3f0acdf8aa104f9f68cbf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wish you all the best for future....


On Thu, May 22, 2014 at= 12:00 AM, <v6ops-request@ietf.org> wrote:
Send v6ops mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 v6ops@ietf.or= g

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/v6ops<= br> or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 v6ops= -request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 v6ops-o= wner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of v6ops digest..."

Today's Topics:

=C2=A0 =C2=A01. Re: Time for a change... (Owen DeLong)


---------- Forwarded message ----------
From:=C2=A0Owen DeLong &= lt;owen@delong.com>
To:=C2=A0&= quot;Brzozowski, John" <John_Brzozowski@Cable.Comcast.com>
Cc:=C2=A0v6ops <v6ops@ietf.org>= , chairs <v6ops-chairs@to= ols.ietf.org>
Date:=C2=A0Wed, 21 May 2014 10:38:21 -0700
Subje= ct:=C2=A0Re: [v6ops] Time for a change...
Thanks, John for all that you have done.

Owen

On May 19, 2014, at 10:18 PM, Brzozowski, John <John_Brzozowski@Cable.Comcast.com> wrot= e:

> Folks,
>
> Time availability has become a bit of a challenge for me as of late. = =C2=A0The
> focus of my day job has been impacting the availability of cycles that= I
> have to help Fred run and guide the working group on a daily basis. = =C2=A0Joel,
> Fred, and I agree that it may be best to identify a new co-chair for > v6ops, as such I will be stepping down as WG co-chair.
>
> I want to take a moment to thank Fred, Joel, and the entire WG for the=
> opportunity to work with you all.
>
>
>
> All the best,
>
> John
>
> _______________________________________________
> 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




--
Regards
Tariq= Saraj
Center for Research in Networks and Telecom (CoReNeT<= /b>)
--001a11c3f0acdf8aa104f9f68cbf-- From nobody Wed May 21 22:47:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E811A0024 for ; Wed, 21 May 2014 22:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Jlc9ntQmxF0 for ; Wed, 21 May 2014 22:46:57 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7BB61A0011 for ; Wed, 21 May 2014 22:46:57 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s4M5krBi034181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 22 May 2014 05:46:54 GMT (envelope-from joelja@bogus.com) Message-ID: <537D8F47.8050809@bogus.com> Date: Wed, 21 May 2014 22:46:47 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Thunderbird/29.0 MIME-Version: 1.0 To: IPv6 Ops WG , V6ops Chairs X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QrCKmH1q6IV124UeaA9sr27L1Dnk4ApCs" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Thu, 22 May 2014 05:46:56 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1H-N2Lmne8QUAcU2cU0dKzqSNM8 Cc: "Howard, Lee" Subject: [v6ops] New v6ops WG co-chair X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 05:46:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QrCKmH1q6IV124UeaA9sr27L1Dnk4ApCs Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Folks, Lee Howard has agreed to step into the role of V6ops WG co-chair. I'd like to thank Lee for stepping up. We should be back to the regularly scheduled program. Thanks joel --QrCKmH1q6IV124UeaA9sr27L1Dnk4ApCs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlN9j0gACgkQ8AA1q7Z/VrJFqwCdGsW18/T7iH18dugWXzESEzP4 wPsAoIb5yRPF8bA2FWmICgaEvk9y+7mz =FL77 -----END PGP SIGNATURE----- --QrCKmH1q6IV124UeaA9sr27L1Dnk4ApCs-- From nobody Wed May 21 22:56:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E60D1A00C6 for ; Wed, 21 May 2014 22:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHp6L5Uy0fqM for ; Wed, 21 May 2014 22:56:32 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B690B1A0011 for ; Wed, 21 May 2014 22:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1118; q=dns/txt; s=iport; t=1400738191; x=1401947791; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mEwwj0vvYMJq5YqW7m0bSEm1M5Li2GNvDYNFWH0mZgs=; b=DCZNLdz/h4YqGfzyHbuFz5TC8R57sqjqO+F0WvqmOla+d0xhULbtsnEy JYfBex5Au7ijMEE0CBOisW657ppP/k23kbSllpIcpem5OydI1DuOhZmFs LxTRcpRObvTj2qOjPvzQnAiwAGWL7XHlxwz5YWNmVzKKeNC56QggMjVdQ w=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmMFADCRfVOtJV2c/2dsb2JhbABZgwlSWLxYhzsBgQsWdIIlAQEBAwEBAQFrCwULAgEIRicLJQIEDgUOiCsIDdY4EwSOTgeDK4EVBJFLgTqGa5MlgziCMA X-IronPort-AV: E=Sophos;i="4.98,885,1392163200"; d="asc'?scan'208";a="46143114" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP; 22 May 2014 05:56:30 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s4M5uUlu031936 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 May 2014 05:56:30 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.239]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Thu, 22 May 2014 00:56:30 -0500 From: "Fred Baker (fred)" To: "Howard, Lee" Thread-Topic: [v6ops] New v6ops WG co-chair Thread-Index: AQHPdYKTtxNdF1feCki6vFR9bN/SnQ== Date: Thu, 22 May 2014 05:56:29 +0000 Message-ID: <5A4A3A89-0C57-4819-AD13-B535E916999D@cisco.com> References: <537D8F47.8050809@bogus.com> In-Reply-To: <537D8F47.8050809@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_31429F35-9A91-4CF2-8EEF-290E72175580"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/V468OxI5Ucj6JtEud6G0u_0N5O0 Cc: IPv6 Ops WG , V6ops Chairs Subject: Re: [v6ops] New v6ops WG co-chair X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 05:56:33 -0000 --Apple-Mail=_31429F35-9A91-4CF2-8EEF-290E72175580 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Welcome aboard, Lee. On May 21, 2014, at 10:46 PM, joel jaeggli wrote: > Folks, > > Lee Howard has agreed to step into the role of V6ops WG co-chair. > > I'd like to thank Lee for stepping up. > > We should be back to the regularly scheduled program. > > Thanks > joel > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_31429F35-9A91-4CF2-8EEF-290E72175580 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTfZF4bjEdbHIsm0MRAk/BAJ9NKsYNior+Ndy5q/SNGFqK+tPtFQCeJQIg HZ2msmvkq+QE0mCLOmMmtVU= =9/5m -----END PGP SIGNATURE----- --Apple-Mail=_31429F35-9A91-4CF2-8EEF-290E72175580-- From nobody Wed May 21 23:49:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F35B1A00E2 for ; Wed, 21 May 2014 23:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBWY9gABAWL1 for ; Wed, 21 May 2014 23:49:34 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36F8E1A0016 for ; Wed, 21 May 2014 23:49:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id A9F8A4B; Thu, 22 May 2014 08:49:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzIGg--ORQ-A; Thu, 22 May 2014 08:49:23 +0200 (CEST) Received: from [100.64.0.100] (vimes.steffann.nl [94.142.242.222]) by mail.sintact.nl (Postfix) with ESMTPSA id 1561146; Thu, 22 May 2014 08:49:18 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Sander Steffann In-Reply-To: <537D8F47.8050809@bogus.com> Date: Thu, 22 May 2014 09:49:24 +0300 Content-Transfer-Encoding: 7bit Message-Id: <24ACF7FF-3BA3-498E-B7D0-E380B7D4FBF3@steffann.nl> References: <537D8F47.8050809@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/MUvagAXExqrjK02byCEbbqFKX1o Cc: "Howard, Lee" , IPv6 Ops WG , V6ops Chairs Subject: Re: [v6ops] New v6ops WG co-chair X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 06:49:35 -0000 Hi, > Lee Howard has agreed to step into the role of V6ops WG co-chair. Welcome Lee! Sander From nobody Thu May 22 07:46:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE24C1A015C for ; Thu, 22 May 2014 07:46:29 -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=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fz5NV6M_RTtk for ; Thu, 22 May 2014 07:46:28 -0700 (PDT) Received: from atl4mhob05.myregisteredsite.com (atl4mhob05.myregisteredsite.com [209.17.115.43]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6821A01BA for ; Thu, 22 May 2014 07:46:26 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s4MEkMSP018169 for ; Thu, 22 May 2014 10:46:22 -0400 Received: (qmail 20324 invoked by uid 0); 22 May 2014 14:46:22 -0000 X-TCPREMOTEIP: 204.235.115.161 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?10.71.36.73?) (lee@asgard.org@204.235.115.161) by 0 with ESMTPA; 22 May 2014 14:46:21 -0000 User-Agent: Microsoft-MacOutlook/14.4.1.140326 Date: Thu, 22 May 2014 10:46:22 -0400 From: Lee Howard To: joel jaeggli , IPv6 Ops WG , V6ops Chairs Message-ID: Thread-Topic: [v6ops] New v6ops WG co-chair References: <537D8F47.8050809@bogus.com> In-Reply-To: <537D8F47.8050809@bogus.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NVVvwBZhP5Rtu9KDM7u9HrfIo0k Cc: "Howard, Lee" Subject: Re: [v6ops] New v6ops WG co-chair X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 14:46:29 -0000 I will do my best to support the work of the people contributing to this group, in support of its charter. I thank John for all he has done in support of IPv6, both as chair and elsewhere. Lee On 5/22/14 1:46 AM, "joel jaeggli" wrote: >Folks, > >Lee Howard has agreed to step into the role of V6ops WG co-chair. > >I'd like to thank Lee for stepping up. > >We should be back to the regularly scheduled program. > >Thanks >joel > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu May 22 08:01:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D311A01E5 for ; Thu, 22 May 2014 08:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ig5RqVvhFoqY for ; Thu, 22 May 2014 08:01:43 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A83DF1A0039 for ; Thu, 22 May 2014 08:01:43 -0700 (PDT) Received: by mail-yk0-f179.google.com with SMTP id 19so2889289ykq.38 for ; Thu, 22 May 2014 08:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0rMr0odSkq/j6PItRLKLzVGTPqYD3nwql3O8IyfTFm4=; b=W5SmdGRt4ym+uJA+rnYu/jRo7Ze0lGva7s/ZiemEHxRa2c18Vw/AYMiX9rUgFq1L4j ZGD0cl7kWXHALYK0tj7o8Mx7GJajdPheFAVcget/qoTz/yMBT6n3YLFLOpS3e+A102o8 S3YgCUdn+eHJVSKiMjhk94LQEtU/rdaI8SMmQfZFIkncTEb6env33lAGIAodNUsky60K ItWZMwpbJxizJExgCgfuyEbQRVfUV09VUgDrDOkjCvULkACyIgwxvh1HzAuLLOcl0Ly9 5dV3QZ6GZl0KXfcpl/r4Qf9iFsK2P3w9/EJo/CDlR3+6QTz1VrEgDF3tfPHW6QrDERAJ V5Mw== X-Received: by 10.236.153.10 with SMTP id e10mr46865825yhk.118.1400770902017; Thu, 22 May 2014 08:01:42 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy ([200.7.87.35]) by mx.google.com with ESMTPSA id a104sm114787yhq.5.2014.05.22.08.01.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 08:01:40 -0700 (PDT) Message-ID: <537E1152.6040403@gmail.com> Date: Thu, 22 May 2014 12:01:38 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <537D8F47.8050809@bogus.com> In-Reply-To: <537D8F47.8050809@bogus.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5lDnPiiLPzZBqb_1Q4-l54B5Qwg Subject: Re: [v6ops] New v6ops WG co-chair X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: carlos@lacnic.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 15:01:44 -0000 Welcome Lee, this is good news! On 5/22/14, 2:46 AM, joel jaeggli wrote: > Folks, > > Lee Howard has agreed to step into the role of V6ops WG co-chair. > > I'd like to thank Lee for stepping up. > > We should be back to the regularly scheduled program. > > Thanks > joel > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu May 22 08:03:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D1E1A021C for ; Thu, 22 May 2014 08:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sL1c4vO2gvVs for ; Thu, 22 May 2014 08:03:31 -0700 (PDT) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435241A0208 for ; Thu, 22 May 2014 08:03:31 -0700 (PDT) Received: by mail-yh0-f46.google.com with SMTP id 29so3080185yhl.19 for ; Thu, 22 May 2014 08:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=vOBuNebgUZn48JiiTtwrXhYukpoo1W5DPnPcQJd0u5w=; b=wJQ2u2M7DZzhnzhVDpndqe3IHkwMJadJQUJWecog79+tJ3HRFr1QNdVGbVmLLpMLf1 snYKBkVhQzGcGb0sNurNOXlOxsOIiQLYyFDOQ81LfESVd7nwoMKejDRjRqeW7BaAiWU9 qLCTpfikLF0m2AIgIJL5UD76o/BfMICjWfrR7aOzitKfnt+nWXv3ppsDd9IB+cMSZGzV 4Eq9Ls3vsf1xShnTl6WFXxO+kP/dpHfaQOErfOfYl7Yh0FXBmm3CfVWZFn5e0PSLQsaQ 6gL/Y4ypscTuQub5w5KX3Gwi0aN/NV8N7WQ3btUuHcIurHDVkLEwVLu8inJUqnnhtWY4 nWNg== X-Received: by 10.236.190.72 with SMTP id d48mr74240938yhn.62.1400771009658; Thu, 22 May 2014 08:03:29 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy ([200.7.87.35]) by mx.google.com with ESMTPSA id o69sm110703yho.19.2014.05.22.08.03.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 08:03:28 -0700 (PDT) Message-ID: <537E11BE.3000602@gmail.com> Date: Thu, 22 May 2014 12:03:26 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Aje4Jrnl_rGzkKm_X-LWqoFxV-I Subject: Re: [v6ops] Time for a change... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: carlos@lacnic.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 15:03:32 -0000 +1 to Owen's words. I hope you will still be able to offer us your insight and contributions. Best, ~Carlos On 5/21/14, 2:38 PM, Owen DeLong wrote: > Thanks, John for all that you have done. > > Owen > > On May 19, 2014, at 10:18 PM, Brzozowski, John wrote: > >> Folks, >> >> Time availability has become a bit of a challenge for me as of late. The >> focus of my day job has been impacting the availability of cycles that I >> have to help Fred run and guide the working group on a daily basis. Joel, >> Fred, and I agree that it may be best to identify a new co-chair for >> v6ops, as such I will be stepping down as WG co-chair. >> >> I want to take a moment to thank Fred, Joel, and the entire WG for the >> opportunity to work with you all. >> >> >> >> All the best, >> >> John >> >> _______________________________________________ >> 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 nobody Thu May 22 09:24:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D161A026D for ; Thu, 22 May 2014 09:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cg7i5wMlsL8 for ; Thu, 22 May 2014 09:24:43 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7D71A0253 for ; Thu, 22 May 2014 09:24:42 -0700 (PDT) Received: from [IPv6:2620::930:0:225:ff:fe44:af17] ([IPv6:2620:0:930:0:225:ff:fe44:af17]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s4MGJP0W030429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 22 May 2014 09:19:25 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s4MGJP0W030429 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1400775566; bh=4BTjWBpZWejDWNNOCf6MnbtbrEk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=eqJrW2UVx6lOoSWhZ0nSwsvWZjRSmqlKfCpcPOnk1LX0BX1qlOZc7i+xrYcCGLwe8 g5irdLt9t2tyC61WCztD6hhfZuq1aU7LL1Ra3yjOeJdZrJdAUYSxq3119bWqmDaHL/ RMqPoAbosW/pqwMKi3PcqyZwsKuR65VH2vE1DMNo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: Date: Thu, 22 May 2014 09:22:53 -0700 Content-Transfer-Encoding: 7bit Message-Id: <1F2F4A31-00E3-482F-BC56-3244D2B83761@delong.com> References: <537D8F47.8050809@bogus.com> To: Lee Howard X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 22 May 2014 09:19:26 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ijDRISpHFMjvfqg7FlYKtft_8dc Cc: "Howard, Lee" , IPv6 Ops WG , V6ops Chairs Subject: Re: [v6ops] New v6ops WG co-chair X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 16:24:44 -0000 Excellent choice. Welcome, Lee! Owen On May 22, 2014, at 7:46 AM, Lee Howard wrote: > I will do my best to support the work of the people contributing to this > group, in support of its charter. > I thank John for all he has done in support of IPv6, both as chair and > elsewhere. > > Lee > > On 5/22/14 1:46 AM, "joel jaeggli" wrote: > >> Folks, >> >> Lee Howard has agreed to step into the role of V6ops WG co-chair. >> >> I'd like to thank Lee for stepping up. >> >> We should be back to the regularly scheduled program. >> >> Thanks >> joel >> >> _______________________________________________ >> 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 nobody Mon May 26 05:36:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942B71A0146 for ; Mon, 26 May 2014 05:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gicpLzBuOq-p for ; Mon, 26 May 2014 05:36:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AA901A0129 for ; Mon, 26 May 2014 05:36:05 -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.7-GA FastPath queued) with ESMTP id BHG12407; Mon, 26 May 2014 12:36:02 +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.3.158.1; Mon, 26 May 2014 13:35:36 +0100 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.3.158.1; Mon, 26 May 2014 13:35:59 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 26 May 2014 20:35:57 +0800 From: "Liubing (Leo)" To: v6ops WG Thread-Topic: ULA draft revision #1 Changing "Recommendations/Guidelines" to "Considerations" Thread-Index: Ac943wSjzwW9m3FNR/yVvstojWcTyg== Date: Mon, 26 May 2014 12:35:56 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B8B@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.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ynGjdGZ3hmMcWnkVDJHnz4HMHfI Cc: "v6ops-chairs@tools.ietf.org" Subject: [v6ops] ULA draft revision #1 Changing "Recommendations/Guidelines" to "Considerations" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 12:36:07 -0000 Hi, All We're going to update the ULA draft. Before making a new version, I think i= t would be helpful to confirm/discuss several important topics which were d= iscussed in last IETF meeting.=20 I'd like to discuss the topics in different mail threads respectively. (Current Draft link: http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-= recommendations-02) ***************************************************************************= *** #1: Changing "Recommendations/Guidelines" to "Considerations". As discussed and confirmed in former meetings, this draft is to be informat= ional, not a BCP. So it is not proper to "recommend to do..." or "not recom= mended to do...". Thus we're going to basically replace all the keywords "r= ecommendations", "Guidelines" to "Considerations", including the title.=20 Either in the meeting venue or in the mailing list, we've received a decent= number of feedbacks of people's real ULA deployment experiences on various= scenarios described in the document.=20 Based on the real experiences and analysis, we'll keep the content of Secti= on 5, but change the title from "ULA usage recommendations" to "ULA usages = considered beneficial". Please send your comments. Thanks a lot. Best regards, Bing From nobody Mon May 26 05:37:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE6D1A0147 for ; Mon, 26 May 2014 05:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6AszKagBT3G for ; Mon, 26 May 2014 05:37:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC491A0129 for ; Mon, 26 May 2014 05:37:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEO11839; Mon, 26 May 2014 12:36:57 +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.3.158.1; Mon, 26 May 2014 13:36:31 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 26 May 2014 13:36:56 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Mon, 26 May 2014 20:36:51 +0800 From: "Liubing (Leo)" To: v6ops WG Thread-Topic: ULA draft revision #2 Regarding isolated networks Thread-Index: Ac943yf4qhJ96dkPR9CtEDOlyHC2QQ== Date: Mon, 26 May 2014 12:36:50 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@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.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/36mN11UcMW2pAz6SwTZ21avilWU Cc: "v6ops-chairs@tools.ietf.org" Subject: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 12:37:02 -0000 Hi, All We're going to update the ULA draft. Before making a new version, I think i= t would be helpful to confirm/discuss several important topics which were d= iscussed in last IETF meeting.=20 I'd like to discuss the topics in different mail threads respectively. (Current Draft link: http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-= recommendations-02) ***************************************************************************= *** #2 Regarding isolated networks Current draft is a little blurry on what the "isolated" means. Based on for= mer discussion, we'll make it more comprehensive description as the followi= ng (just a summary, not the specific revision wording): - "Temporarily isolated" or "Forever isolated". In general, ULAs fit both c= ases. Whatever it is temporarily or forever, when administrators need some = prefixes to be on-demand and free to use, ULAs are good choice. However, fo= r the temporarily isolated cases, the administrator needs to consider once = it gets to connected, the hosts might need to be renumbered; or NAT might b= e involved if renumbering is not acceptable. If renumbering or NAT for some= reason is considered as heavy burden, then the administrators need to care= fully consider the adoption of ULAs. - "Isolated to all networks" or "Isolated to the public Internet". These ar= e two separate scenarios. However, in the perspective of adopting ULAs, the= re is no essential difference between them. So long as it doesn't connect t= o the global Internet, ULAs fit them as well. Comparing to other alternativ= es (an arbitrary GUA, or documentation prefixes), ULAs could provide a lowe= r possibility of collision if they are generated according to the standard = method. And the ACL rules for ULAs are much convenient to be set than arbit= rary prefixes, to prevent the prefixes leaked if the isolated networks occa= sionally connected to the global networks.=20 Please send your comments. Thanks a lot! Best regards, Bing From nobody Mon May 26 13:02:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7EA1A0248 for ; Mon, 26 May 2014 13:02:08 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbBcEAcJIZI6 for ; Mon, 26 May 2014 13:02:07 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DFC41A023D for ; Mon, 26 May 2014 13:02:07 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id rd3so7995547pab.15 for ; Mon, 26 May 2014 13:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/bozuqmZOyphynNrnbMwm5eFmF6dMK8ug7YmIVr9mGM=; b=0rNPQe8X87E8Sm18BYHEE+3vG3PcjndN5tMAZBHL7teWVbvIhepqXD94JqF5o29tjM tL4fP9z6C73r5WgLT8RM8VKZsR6gS2XBFDDBSmpqu6vf1JNxj7h2excviZR0PEBldJAN Fj4cFYgpSQyUw6uymU/PL6klHsPV7oNbbZWZlwp40MhxAiYao2m32k6brJdoO7OJ1qFH Xrlv2/36u9OE6qq+f699w/ssu5yU2ULY51gk3WDg61NLIxYtrcfItJpwIg4AG6WKhyLo gCsHHTPLvuCK9WM+1pizC/lSxxJH461xtL4VSk5cw2+nQUOdCT7dbsTyQ0Z96+WNjJpg fr5Q== X-Received: by 10.68.163.100 with SMTP id yh4mr30629522pbb.122.1401134524188; Mon, 26 May 2014 13:02:04 -0700 (PDT) Received: from [192.168.178.23] (155.199.69.111.dynamic.snap.net.nz. [111.69.199.155]) by mx.google.com with ESMTPSA id ky8sm19600282pbc.64.2014.05.26.13.02.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 May 2014 13:02:03 -0700 (PDT) Message-ID: <53839DB5.9090602@gmail.com> Date: Tue, 27 May 2014 08:01:57 +1200 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: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B8B@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B8B@nkgeml506-mbx.china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5Hflu0MadSjiJE-NfyyYvKAOTUk Cc: v6ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] ULA draft revision #1 Changing "Recommendations/Guidelines" to "Considerations" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 20:02:08 -0000 Hi, On 27/05/2014 00:35, Liubing (Leo) wrote: ... > #1: Changing "Recommendations/Guidelines" to "Considerations". > > As discussed and confirmed in former meetings, this draft is to be informational, not a BCP. So it is not proper to "recommend to do..." or "not recommended to do...". Thus we're going to basically replace all the keywords "recommendations", "Guidelines" to "Considerations", including the title. I agree. Ten years from now, there might be enough experience to justify a BCP. > Either in the meeting venue or in the mailing list, we've received a decent number of feedbacks of people's real ULA deployment experiences on various scenarios described in the document. > Based on the real experiences and analysis, we'll keep the content of Section 5, but change the title from "ULA usage recommendations" to "ULA usages considered beneficial". How about "ULA usages considered helpful"? "Beneficial" is bit like saying "good". Brian From nobody Mon May 26 13:14:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D281A026B for ; Mon, 26 May 2014 13:14:45 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUaf8uHj9JG9 for ; Mon, 26 May 2014 13:14:44 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DBC91A0248 for ; Mon, 26 May 2014 13:14:44 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rp16so8099858pbb.34 for ; Mon, 26 May 2014 13:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bzCUzD8eQYEKZHVNaSEzXpAWIjyq9RTDRCbOsBcoJvM=; b=0ugbAbe1qZ2e0AydHb2lo9MTHJDbKCOinwroKqkmx/QH6XQlhIjZX6PKLWUY7OFCeC UthpdkhJfZ+b83VKFadIo3g3pG9H1f95SGXzzA0WgmX/89Gt81B5fF5nh9Rjm0aH0pve 9eCdtfyOlYtQSOZPlhxMvDVUAAcLt/ztlpVJokwmzJ5yn1vYET87yYZ+/DC+/9mDdIGO XO1W5dsUXqocafPW6aKqI6lJvbE1eLH38+Nwv4sOL+cXOW7UdlinI1wDrmobBpXV7G87 7yJdQN5EtubB7LsnQ1q/IGPl54b702+/cBrpde9v+68T7HWGk/wY5sGTuUVldMo/DNC1 NQ+w== X-Received: by 10.66.139.168 with SMTP id qz8mr29890524pab.3.1401135280487; Mon, 26 May 2014 13:14:40 -0700 (PDT) Received: from [192.168.178.23] (155.199.69.111.dynamic.snap.net.nz. [111.69.199.155]) by mx.google.com with ESMTPSA id ix7sm19648647pbd.36.2014.05.26.13.14.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 May 2014 13:14:40 -0700 (PDT) Message-ID: <5383A0AE.2030900@gmail.com> Date: Tue, 27 May 2014 08:14:38 +1200 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: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vUxbdRhFCXJVCrvIJojP3z_3UjI Cc: v6ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 20:14:45 -0000 On 27/05/2014 00:36, Liubing (Leo) wrote: > Hi, All > > We're going to update the ULA draft. Before making a new version, I think it would be helpful to confirm/discuss several important topics which were discussed in last IETF meeting. > > I'd like to discuss the topics in different mail threads respectively. > (Current Draft link: http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02) > ****************************************************************************** > > #2 Regarding isolated networks > > Current draft is a little blurry on what the "isolated" means. Based on former discussion, we'll make it more comprehensive description as the following (just a summary, not the specific revision wording): > > - "Temporarily isolated" or "Forever isolated". In general, ULAs fit both cases. Whatever it is temporarily or forever, when administrators need some prefixes to be on-demand and free to use, ULAs are good choice. However, for the temporarily isolated cases, the administrator needs to consider once it gets to connected, the hosts might need to be renumbered; or NAT might be involved if renumbering is not acceptable. If renumbering or NAT for some reason is considered as heavy burden, then the administrators need to carefully consider the adoption of ULAs. Such networks (which in the IPng design phase we called "dentist's office networks") are in the class where fully autonomic operation, with no expert manager, is the normal case. As we observed in 6man, these networks get automatically renumbered after every power cut. So we should simply state that renumbering will happen in such networks whenever necessary. I don't think we should even mention NPTv6. The two cases are different though. If a network is running with an ISP prefix and becomes isolated, it is not *forced* to use a ULA prefix, but it might need to renumber when it gets reconnected with a different ISP prefix. If it's forever isolated, a ULA would be appropriate (and fail-safe if it does, in reality, get connected to an ISP). > - "Isolated to all networks" or "Isolated to the public Internet". These are two separate scenarios. However, in the perspective of adopting ULAs, there is no essential difference between them. So long as it doesn't connect to the global Internet, ULAs fit them as well. Comparing to other alternatives (an arbitrary GUA, or documentation prefixes), ULAs could provide a lower possibility of collision if they are generated according to the standard method. And the ACL rules for ULAs are much convenient to be set than arbitrary prefixes, to prevent the prefixes leaked if the isolated networks occasionally connected to the global networks. Yes. It seems to me that in "Internet of Things" scenarios, this would be the normal mode. A group of IoT devices will be connected to some sort of application-layer gateway, and by using ULA for that, isolation from other networks is easier to ensure. Brian From nobody Mon May 26 14:57:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BE71A02A1 for ; Mon, 26 May 2014 14:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enUBIouTxNsT for ; Mon, 26 May 2014 14:57:08 -0700 (PDT) Received: from nm17-vm1.bullet.mail.bf1.yahoo.com (nm17-vm1.bullet.mail.bf1.yahoo.com [98.139.213.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 024321A02AA for ; Mon, 26 May 2014 14:57:06 -0700 (PDT) Received: from [98.139.215.142] by nm17.bullet.mail.bf1.yahoo.com with NNFMP; 26 May 2014 21:57:03 -0000 Received: from [98.139.212.197] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 26 May 2014 21:57:03 -0000 Received: from [127.0.0.1] by omp1006.mail.bf1.yahoo.com with NNFMP; 26 May 2014 21:57:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 447860.56650.bm@omp1006.mail.bf1.yahoo.com Received: (qmail 21414 invoked by uid 60001); 26 May 2014 21:57:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1401141423; bh=TC3yGcrM9XacXrIk8LsP1bMNBnfBhcRT8k1+8W9K7mk=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lOKXL/ahLnQD7D28G1DGSxA3h/n1zjAhbYckcQYfN9iNEACjTuQ3AfYU0V3cgLRdwqeXNf74X9olUEqjGfuri81eDrLQjsu1rAnMJ2dgFHvuw6HNlW2kS8RH3fHhAiNqlyMmRvsPpE+HduLWXahnYPsTR/PFUXN9FVoauIfVTbE= X-YMail-OSG: S6F8I8sVM1ndkxT11p0HTy5_reIfBTe6CPAvSCX8m5MxDLP 7_shOgQtyUe5vGbB2O251WXhGzhtrowb2Z.6gqvE9j354exaW14YzIpnupjZ ncM1OvXEWe_ZRusLRuGVFtaNTcbSLykk_CF91tmC.3C7r38yjMCxoS_7t8ZF v9CDNgmOmHfRk7aTrGXTMGjQPF6j6NulCki.qXbugQfT4SlOg.A36NfPkfXn 74k2IEil2TR7xDiEROHJO7PjCwskjIJBcowGK7K4gqM0sgDR2sPDPrusu49O qm7l6aCQHt1U0MpZMKs3nqISdj4ROb0MSIJffWiQuWF7UCjnSZM43mkzadMY 6OJuLW1ppjSVvIHbUn_sRyoZ9jw5gOGGiyBmKjayuf0h24AEyQTeL0KQhu6L 20v0bliL6MqPrkj_Z2vqHCi01UUlGQU_OMId7Su3BgH9rNZkWSafTV.EBoPu Yn5aNwzOmewMFq7jAJ0h7_90SP9sBUo3e6sfTDvcLy0DB9nah85MRnn3mClO NV6lq3aweGyka3eD_PUYFQji8KGZ._mYc4dt8SUM1ZkmxnbDqjAEf7w-- Received: from [150.101.221.237] by web162206.mail.bf1.yahoo.com via HTTP; Mon, 26 May 2014 14:57:03 PDT X-Rocket-MIMEInfo: 002.001, CgoKCgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogTGl1YmluZyAoTGVvKSA8bGVvLmxpdWJpbmdAaHVhd2VpLmNvbT4KPiBUbzogdjZvcHMgV0cgPHY2b3BzQGlldGYub3JnPgo.IENjOiAidjZvcHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIiA8djZvcHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPgo.IFNlbnQ6IE1vbmRheSwgMjYgTWF5IDIwMTQgMTA6MzYgUE0KPiBTdWJqZWN0OiBbdjZvcHNdIFVMQSBkcmFmdCByZXZpc2lvbiAjMiBSZWdhcmRpbmcgaXNvbGF0ZWQgbmV0d29ya3MKPiAKPiABMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> Message-ID: <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com> Date: Mon, 26 May 2014 14:57:03 -0700 (PDT) From: Mark ZZZ Smith To: "Liubing \(Leo\)" , v6ops WG In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yebMwNf_cn_Y_wUyVymJE0iS7BI Cc: "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 21:57:10 -0000 =0A=0A=0A=0A=0A----- Original Message -----=0A> From: Liubing (Leo) =0A> To: v6ops WG =0A> Cc: "v6ops-chairs@t= ools.ietf.org" =0A> Sent: Monday, 26 May 2014 = 10:36 PM=0A> Subject: [v6ops] ULA draft revision #2 Regarding isolated netw= orks=0A> =0A> Hi, All=0A> =0A> We're going to update the ULA draft. Before = making a new version, I think it =0A> would be helpful to confirm/discuss s= everal important topics which were =0A> discussed in last IETF meeting. =0A= > =0A> I'd like to discuss the topics in different mail threads respectivel= y.=0A> (Current Draft link: =0A> http://tools.ietf.org/html/draft-ietf-v6op= s-ula-usage-recommendations-02)=0A> ***************************************= ***************************************=0A> =0A> #2 Regarding isolated netw= orks=0A> =0A> Current draft is a little blurry on what the "isolated" means= . Based =0A> on former discussion, we'll make it more comprehensive descrip= tion as the =0A> following (just a summary, not the specific revision wordi= ng):=0A> =0A> - "Temporarily isolated" or "Forever isolated". In general, = =0A> ULAs fit both cases. Whatever it is temporarily or forever, when admin= istrators =0A> need some prefixes to be on-demand and free to use, ULAs are= good choice. =0A> However, for the temporarily isolated cases, the adminis= trator needs to consider =0A> once it gets to connected, the hosts might ne= ed to be renumbered; or NAT might =0A> be involved if renumbering is not ac= ceptable. If renumbering or NAT for some =0A> reason is considered as heavy= burden, then the administrators need to carefully =0A> consider the adopti= on of ULAs.=0A>=A0=0A=0AThis paragraph seems to show a fundamental misunder= standing of IPv6's multi-addressing capabilities. IPv6 supports multiple co= ncurrent addresses (from different prefixes), and can learn new ones or dep= recate old ones over time. Attachment to a new network doesn't require renu= mbering, it requires propagating new prefixes for the hosts to use in addit= ion to their existing ones. Primarily RFC6724 address selection will help t= he hosts choose the right addresses to use as source and destinations when = they have multiple addresses.=0A=0A=0A> - "Isolated to all networks" or "Is= olated to the public =0A> Internet". These are two separate scenarios. Howe= ver, in the perspective of =0A> adopting ULAs, there is no essential differ= ence between them. So long as it =0A> doesn't connect to the global Interne= t, ULAs fit them as well. Comparing to =0A> other alternatives (an arbitrar= y GUA, or documentation prefixes), ULAs could =0A> provide a lower possibil= ity of collision if they are generated according to the =0A> standard metho= d. And the ACL rules for ULAs are much convenient to be set than =0A> arbit= rary prefixes, to prevent the prefixes leaked if the isolated networks =0A>= occasionally connected to the global networks. =0A> =0A> Please send your = comments. Thanks a lot!=0A> =0A> Best regards,=0A> Bing=0A> =0A> __________= _____________________________________=0A> v6ops mailing list=0A> v6ops@ietf= .org=0A> https://www.ietf.org/mailman/listinfo/v6ops=0A> From nobody Mon May 26 15:40:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5A41A02BC for ; Mon, 26 May 2014 15:40:21 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5V5YU8GhS77Y for ; Mon, 26 May 2014 15:40:19 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C02F51A02B7 for ; Mon, 26 May 2014 15:40:19 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id ld10so8099274pab.31 for ; Mon, 26 May 2014 15:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/1qnOEViLv2IIVcjJdAlc7sRY4WqAVnWISO7eyLKm40=; b=FCCw6KID6a9PMmSrYhQS9rbocj45XEi7jzuqOxPzFPU5/8MwVZmbwE6DTBhSBTHiIz k7CrWafC55izgCdw2I3rrWVItb0gBl2v332iJ5f/g3SzPvUjq84Dc8RuUlJUpxTCEmVN VuXyn862LNSGJWkKX1qF2SCjJsdCXOz+dSBh7bR1ZYiUwSwa+e1mnI/LBiLovjjXGe66 2zI2BYMe/TizRhNBlRnVEMRXzwT2+5f099Iv0lO6wErlGrc1aoE2vaIS1MfoK4h+Vptk Wv64Z7WqmW2nX0tTVuWyIdevDLlYGHZzBhi7yGzyIVJsOcDFd6stidp2k13Zm4OzSqTf Ke4Q== X-Received: by 10.68.202.230 with SMTP id kl6mr31612822pbc.55.1401144016838; Mon, 26 May 2014 15:40:16 -0700 (PDT) Received: from [192.168.178.23] (155.199.69.111.dynamic.snap.net.nz. [111.69.199.155]) by mx.google.com with ESMTPSA id cz3sm19968307pbc.9.2014.05.26.15.40.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 May 2014 15:40:16 -0700 (PDT) Message-ID: <5383C2CF.6040205@gmail.com> Date: Tue, 27 May 2014 10:40:15 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark ZZZ Smith References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com> In-Reply-To: <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/swDCe-cNK_ONH2-BXlrMceFErPE Cc: v6ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 22:40:21 -0000 Mark, On 27/05/2014 09:57, Mark ZZZ Smith wrote: ... >> - "Temporarily isolated" or "Forever isolated". In general, >> ULAs fit both cases. Whatever it is temporarily or forever, when administrators >> need some prefixes to be on-demand and free to use, ULAs are good choice. >> However, for the temporarily isolated cases, the administrator needs to consider >> once it gets to connected, the hosts might need to be renumbered; or NAT might >> be involved if renumbering is not acceptable. If renumbering or NAT for some >> reason is considered as heavy burden, then the administrators need to carefully >> consider the adoption of ULAs. >> > > This paragraph seems to show a fundamental misunderstanding of IPv6's multi-addressing capabilities. IPv6 supports multiple concurrent addresses (from different prefixes), and can learn new ones or deprecate old ones over time. Attachment to a new network doesn't require renumbering, it requires propagating new prefixes for the hosts to use in addition to their existing ones. Primarily RFC6724 address selection will help the hosts choose the right addresses to use as source and destinations when they have multiple addresses. I didn't read it that way. Of course an IPv6 network runs well with multiple prefixes, which is why overlapped renumbering is possible. As Fred Baker once pointed out, the real problem is therefore *numbering* a network (i.e. adding a new prefix, regardless of whether there are zero or more existing prefixes). The text needs to be clear about that, for sure. Brian From nobody Mon May 26 16:45:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B091A030B; Mon, 26 May 2014 16:45:18 -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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SNYjvYOmMUm; Mon, 26 May 2014 16:45:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 731001A0306; Mon, 26 May 2014 16:45:15 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140526234515.29509.85296.idtracker@ietfa.amsl.com> Date: Mon, 26 May 2014 16:45:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6MGDYM7QOrzJ7rLr7I7cJKH4ixo Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (Enterprise IPv6 Deployment Guidelines) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 23:45:18 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Enterprise IPv6 Deployment Guidelines' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-06-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks. The administrators face different challenges than operators of Internet access providers, and have reasons for different priorities. The overall problem for many administrators will be to offer Internet- facing services over IPv6, while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network. The overall transition will take most networks from an IPv4-only environment to a dual stack network environment and eventually an IPv6-only operating mode. This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-enterprise-incremental-ipv6/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-enterprise-incremental-ipv6/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon May 26 18:07:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E8B1A02D6 for ; Mon, 26 May 2014 18:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqC_j1AYV2qk for ; Mon, 26 May 2014 18:07:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A28191A02D4 for ; Mon, 26 May 2014 18:07:29 -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.7-GA FastPath queued) with ESMTP id BEO55438; Tue, 27 May 2014 01:07:23 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 May 2014 02:06:56 +0100 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.3.158.1; Tue, 27 May 2014 02:07:22 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Tue, 27 May 2014 09:07:15 +0800 From: "Liubing (Leo)" To: Brian E Carpenter , Mark ZZZ Smith Thread-Topic: [v6ops] ULA draft revision #2 Regarding isolated networks Thread-Index: Ac943yf4qhJ96dkPR9CtEDOlyHC2QQACzceAAAGCPYAAFXOEwA== Date: Tue, 27 May 2014 01:07:15 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6CD2@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com> <5383C2CF.6040205@gmail.com> In-Reply-To: <5383C2CF.6040205@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.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7bRLMGVVcL6ngSHcbacEiwCop1s Cc: v6ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 01:07:32 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4gRSBDYXJwZW50 ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6IFR1ZXNkYXks IE1heSAyNywgMjAxNCA2OjQwIEFNDQo+IFRvOiBNYXJrIFpaWiBTbWl0aA0KPiBDYzogTGl1Ymlu ZyAoTGVvKTsgdjZvcHMgV0c7IHY2b3BzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW3Y2b3BzXSBVTEEgZHJhZnQgcmV2aXNpb24gIzIgUmVnYXJkaW5nIGlzb2xhdGVkIG5l dHdvcmtzDQo+IA0KPiBNYXJrLA0KPiANCj4gT24gMjcvMDUvMjAxNCAwOTo1NywgTWFyayBaWlog U21pdGggd3JvdGU6DQo+IC4uLg0KPiA+PiAtICJUZW1wb3JhcmlseSBpc29sYXRlZCIgb3IgIkZv cmV2ZXIgaXNvbGF0ZWQiLiBJbiBnZW5lcmFsLCBVTEFzIGZpdA0KPiA+PiBib3RoIGNhc2VzLiBX aGF0ZXZlciBpdCBpcyB0ZW1wb3JhcmlseSBvciBmb3JldmVyLCB3aGVuDQo+ID4+IGFkbWluaXN0 cmF0b3JzIG5lZWQgc29tZSBwcmVmaXhlcyB0byBiZSBvbi1kZW1hbmQgYW5kIGZyZWUgdG8gdXNl LA0KPiBVTEFzIGFyZSBnb29kIGNob2ljZS4NCj4gPj4gSG93ZXZlciwgZm9yIHRoZSB0ZW1wb3Jh cmlseSBpc29sYXRlZCBjYXNlcywgdGhlIGFkbWluaXN0cmF0b3IgbmVlZHMNCj4gPj4gdG8gY29u c2lkZXIgb25jZSBpdCBnZXRzIHRvIGNvbm5lY3RlZCwgdGhlIGhvc3RzIG1pZ2h0IG5lZWQgdG8g YmUNCj4gPj4gcmVudW1iZXJlZDsgb3IgTkFUIG1pZ2h0IGJlIGludm9sdmVkIGlmIHJlbnVtYmVy aW5nIGlzIG5vdA0KPiA+PiBhY2NlcHRhYmxlLiBJZiByZW51bWJlcmluZyBvciBOQVQgZm9yIHNv bWUgcmVhc29uIGlzIGNvbnNpZGVyZWQgYXMNCj4gPj4gaGVhdnkgYnVyZGVuLCB0aGVuIHRoZSBh ZG1pbmlzdHJhdG9ycyBuZWVkIHRvIGNhcmVmdWxseSBjb25zaWRlciB0aGUNCj4gYWRvcHRpb24g b2YgVUxBcy4NCj4gPj4NCj4gPg0KPiA+IFRoaXMgcGFyYWdyYXBoIHNlZW1zIHRvIHNob3cgYSBm dW5kYW1lbnRhbCBtaXN1bmRlcnN0YW5kaW5nIG9mIElQdjYncw0KPiBtdWx0aS1hZGRyZXNzaW5n IGNhcGFiaWxpdGllcy4gSVB2NiBzdXBwb3J0cyBtdWx0aXBsZSBjb25jdXJyZW50IGFkZHJlc3Nl cw0KPiAoZnJvbSBkaWZmZXJlbnQgcHJlZml4ZXMpLCBhbmQgY2FuIGxlYXJuIG5ldyBvbmVzIG9y IGRlcHJlY2F0ZSBvbGQgb25lcyBvdmVyDQo+IHRpbWUuIEF0dGFjaG1lbnQgdG8gYSBuZXcgbmV0 d29yayBkb2Vzbid0IHJlcXVpcmUgcmVudW1iZXJpbmcsIGl0IHJlcXVpcmVzDQo+IHByb3BhZ2F0 aW5nIG5ldyBwcmVmaXhlcyBmb3IgdGhlIGhvc3RzIHRvIHVzZSBpbiBhZGRpdGlvbiB0byB0aGVp ciBleGlzdGluZw0KPiBvbmVzLiBQcmltYXJpbHkgUkZDNjcyNCBhZGRyZXNzIHNlbGVjdGlvbiB3 aWxsIGhlbHAgdGhlIGhvc3RzIGNob29zZSB0aGUNCj4gcmlnaHQgYWRkcmVzc2VzIHRvIHVzZSBh cyBzb3VyY2UgYW5kIGRlc3RpbmF0aW9ucyB3aGVuIHRoZXkgaGF2ZSBtdWx0aXBsZQ0KPiBhZGRy ZXNzZXMuDQo+IA0KPiBJIGRpZG4ndCByZWFkIGl0IHRoYXQgd2F5LiBPZiBjb3Vyc2UgYW4gSVB2 NiBuZXR3b3JrIHJ1bnMgd2VsbCB3aXRoIG11bHRpcGxlDQo+IHByZWZpeGVzLCB3aGljaCBpcyB3 aHkgb3ZlcmxhcHBlZCByZW51bWJlcmluZyBpcyBwb3NzaWJsZS4NCj4gDQo+IEFzIEZyZWQgQmFr ZXIgb25jZSBwb2ludGVkIG91dCwgdGhlIHJlYWwgcHJvYmxlbSBpcyB0aGVyZWZvcmUNCj4gKm51 bWJlcmluZyogYSBuZXR3b3JrIChpLmUuIGFkZGluZyBhIG5ldyBwcmVmaXgsIHJlZ2FyZGxlc3Mg b2Ygd2hldGhlcg0KPiB0aGVyZSBhcmUgemVybyBvciBtb3JlIGV4aXN0aW5nIHByZWZpeGVzKS4g VGhlIHRleHQgbmVlZHMgdG8gYmUgY2xlYXIgYWJvdXQNCj4gdGhhdCwgZm9yIHN1cmUuDQoNCltC aW5nXSBZZXMuIEkgY29uc2lkZXJlZCAqbnVtYmVyaW5nIGEgbmV3IHByZWZpeCogYXMgYSBzcGVj aWFsIGtpbmQgb2YgKnJlbnVtYmVyaW5nKiBpbiB0aGUgYWJvdmUgdGV4dHMuIEkgbmVlZCB0byBt YWtlIGl0IGNsZWFyLiBVTEErR1VBIGlzIGEgcmVjb21tZW5kZWQgKHdlIHdvbid0IHVzZSB0aGUg d29yZCBpbiB0aGUgbmV3IHZlcnNpb24pIHVzZSBjYXNlIGluIHRoZSBjdXJyZW50IGRyYWZ0LiBX aGF0IEkgbmVlZCB0byBlbXBoYXNpemUgc2hvdWxkIGJlOiB0aGUgYWRtaW5pc3RyYXRvcnMgbmVl ZCB0byBjb25zaWRlciB0aGUgb3BlcmF0aW9uYWwgYnVyZGVuIG9mIG51bWJlcmluZyBhIG5ldyBw cmVmaXggYW5kIGVuc3VyaW5nIHRoZSBSRkM2NzI0IGFkZHJlc3Mgc2VsZWN0aW9uIGlmIHRoZSBp c29sYXRlZCBuZXR3b3JrIGdldHMgY29ubmVjdGVkIGluIHRoZSBmdXR1cmUuDQoNClJlZ2FyZHMs DQpCaW5nDQoNCj4gDQo+ICAgICBCcmlhbg0K From nobody Mon May 26 18:22:20 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE7D1A02D6 for ; Mon, 26 May 2014 18:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFNdbKVco-KR for ; Mon, 26 May 2014 18:22:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366E51A02D5 for ; Mon, 26 May 2014 18:22:16 -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.7-GA FastPath queued) with ESMTP id BEO56101; Tue, 27 May 2014 01:22:12 +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.3.158.1; Tue, 27 May 2014 02:21:44 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 May 2014 02:22:11 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 27 May 2014 09:22:08 +0800 From: "Liubing (Leo)" To: Brian E Carpenter Thread-Topic: [v6ops] ULA draft revision #1 Changing "Recommendations/Guidelines" to "Considerations" Thread-Index: Ac943wSjzwW9m3FNR/yVvstojWcTyv//9oyA//8kd/A= Date: Tue, 27 May 2014 01:22:07 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6CE6@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B8B@nkgeml506-mbx.china.huawei.com> <53839DB5.9090602@gmail.com> In-Reply-To: <53839DB5.9090602@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.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KdO1BIDpRnn1ByXlh82NhUF4_2s Cc: v6ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] ULA draft revision #1 Changing "Recommendations/Guidelines" to "Considerations" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 01:22:19 -0000 SGkgQnJpYW4sDQoNCj4gPiBCYXNlZCBvbiB0aGUgcmVhbCBleHBlcmllbmNlcyBhbmQgYW5hbHlz aXMsIHdlJ2xsIGtlZXAgdGhlIGNvbnRlbnQgb2YNCj4gU2VjdGlvbiA1LCBidXQgY2hhbmdlIHRo ZSB0aXRsZSBmcm9tICJVTEEgdXNhZ2UgcmVjb21tZW5kYXRpb25zIiB0byAiVUxBDQo+IHVzYWdl cyBjb25zaWRlcmVkIGJlbmVmaWNpYWwiLg0KPiANCj4gSG93IGFib3V0ICJVTEEgdXNhZ2VzIGNv bnNpZGVyZWQgaGVscGZ1bCI/DQo+DQo+ICJCZW5lZmljaWFsIiBpcyBiaXQgbGlrZSBzYXlpbmcg Imdvb2QiLg0KDQpbQmluZ10gVGhhbmtzIGZvciB5b3VyIHN1Z2dlc3Rpb24uIEkgYmVsaWV2ZSB5 b3VyIHByb3Bvc2FsIHNob3VsZCBiZSBtb3JlIGFjY3VyYXRlIGluIHRoZSBsYW5ndWFnZSBzZW5z ZS4gQXMgYSBub24tbmF0aXZlIEVuZ2xpc2ggc3BlYWtlciwgc29tZXRpbWVzIEkgY2FuJ3QgZGlz dGluZ3Vpc2ggdGhlIHN1YnRsZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIHdvcmRzOiApDQoNClJlZ2Fy ZHMsDQpCaW5nDQoNCj4gDQo+ICAgICBCcmlhbg0K From nobody Mon May 26 19:31:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23B51A02F8 for ; Mon, 26 May 2014 19:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6doww_pkoueO for ; Mon, 26 May 2014 19:31:45 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F4331A02F4 for ; Mon, 26 May 2014 19:31:45 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1Wp7An-0008VD-0U; Tue, 27 May 2014 02:31:29 +0000 Date: Tue, 27 May 2014 11:31:35 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <53839DB5.9090602@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B8B@nkgeml506-mbx.china.huawei.com> <53839DB5.9090602@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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kQmuLQvlxhmYstyNGCgRTGfQGgA Cc: v6ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] ULA draft revision #1 Changing "Recommendations/Guidelines" to "Considerations" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 02:31:46 -0000 > How about "ULA usages considered helpful"? how about ula usages consdered dangerous and unnecessary? From nobody Mon May 26 19:33:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B871A02F4 for ; Mon, 26 May 2014 19:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZywQzHTxycK for ; Mon, 26 May 2014 19:33:48 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069401A0307 for ; Mon, 26 May 2014 19:33:48 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1Wp7Cy-0008Va-6e; Tue, 27 May 2014 02:33:44 +0000 Date: Tue, 27 May 2014 11:33:51 +0900 Message-ID: From: Randy Bush To: "Liubing (Leo)" In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6jsLyXjQR2xMvog77lmATjDNy1U Cc: v6ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 02:33:48 -0000 > - "Temporarily isolated" or "Forever" we long ago concluded that today's isolated network will most likely be connected some day. randy From nobody Mon May 26 19:51:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA49F1A032F for ; Mon, 26 May 2014 19:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdjhlZ7SHjtp for ; Mon, 26 May 2014 19:51:42 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by ietfa.amsl.com (Postfix) with ESMTP id F0F0A1A032D for ; Mon, 26 May 2014 19:51:41 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 6AC31349421; Tue, 27 May 2014 02:51:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0640B160055; Tue, 27 May 2014 02:56:44 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id C57BC160052; Tue, 27 May 2014 02:56:43 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 9CAB916B31AA; Tue, 27 May 2014 12:51:39 +1000 (EST) To: Randy Bush From: Mark Andrews References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B8B@nkgeml506-mbx.china.huawei.com> <53839DB5.9090602@gmail.com> In-reply-to: Your message of "Tue, 27 May 2014 11:31:35 +0900." Date: Tue, 27 May 2014 12:51:39 +1000 Message-Id: <20140527025139.9CAB916B31AA@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LoKtTnHuT7pN9xc8rMW0y_w5GOE Cc: v6ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] ULA draft revision #1 Changing "Recommendations/Guidelines" to "Considerations" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 02:51:43 -0000 In message , Randy Bush writes: > > How about "ULA usages considered helpful"? > > how about ula usages consdered dangerous and unnecessary? When *everyone* in the world can get address space from RIR's for $0 to be used to when disconnected, renumbering etc. Not that it would really help as there would still be the incentive to NAT. What is need is a way to scale routing so that everyone can have their own permanent address space regardless of their size which they use to connect to everyone with. Until that is a possibility can we please stop complaining that people want/need to use ULA or that it is dangerous or that it encourages NAT. It is not useful to anyone. > _______________________________________________ > 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 nobody Mon May 26 19:54:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F041A032B for ; Mon, 26 May 2014 19:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNgJUbPsoCnf for ; Mon, 26 May 2014 19:54:43 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D8731A0322 for ; Mon, 26 May 2014 19:54:43 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1Wp7XC-00007V-Jo; Tue, 27 May 2014 02:54:39 +0000 Date: Tue, 27 May 2014 11:54:45 +0900 Message-ID: From: Randy Bush To: Mark Andrews In-Reply-To: <20140527025139.9CAB916B31AA@rock.dv.isc.org> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B8B@nkgeml506-mbx.china.huawei.com> <53839DB5.9090602@gmail.com> <20140527025139.9CAB916B31AA@rock.dv.isc.org> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/FNryhmfu11iebkI-inmcsfymlPI Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #1 Changing "Recommendations/Guidelines" to "Considerations" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 02:54:45 -0000 > When *everyone* in the world can get address space from RIR's for > $0 to be used to when disconnected, renumbering etc. don't forget free routers and circuits too and cash will fall from the sky the lack of reality in this wg is always impressive randy From nobody Mon May 26 19:58:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404181A0337 for ; Mon, 26 May 2014 19:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YL4IGIl7-y4Z for ; Mon, 26 May 2014 19:58:56 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE18E1A0322 for ; Mon, 26 May 2014 19:58:55 -0700 (PDT) Received: from mbp.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s4R2wpVc022577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 May 2014 02:58:52 GMT (envelope-from joelja@bogus.com) Message-ID: <5383FF64.10209@bogus.com> Date: Mon, 26 May 2014 19:58:44 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0 MIME-Version: 1.0 To: Randy Bush , Mark Andrews References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B8B@nkgeml506-mbx.china.huawei.com> <53839DB5.9090602@gmail.com> <20140527025139.9CAB916B31AA@rock.dv.isc.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xaIgFft3oBRIVSEtIw8xpH5CwJCdU7haF" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Tue, 27 May 2014 02:58:52 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/b9Cas873X6_5W-1NFLc0pt83Epc Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #1 Changing "Recommendations/Guidelines" to "Considerations" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 02:58:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xaIgFft3oBRIVSEtIw8xpH5CwJCdU7haF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable we know where this conversation goes. we can move on now. thanks joel On 5/26/14, 7:54 PM, Randy Bush wrote: >> When *everyone* in the world can get address space from RIR's for >> $0 to be used to when disconnected, renumbering etc. >=20 > don't forget free routers and circuits too >=20 > and cash will fall from the sky >=20 > the lack of reality in this wg is always impressive >=20 > randy >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --xaIgFft3oBRIVSEtIw8xpH5CwJCdU7haF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOD/2QACgkQ8AA1q7Z/VrLLaQCePnzVK+UwcA5+ZU1E+BK6Btoz Ol0AoIZ14MizyK/ousvJgvp0xjNNlm88 =K0/5 -----END PGP SIGNATURE----- --xaIgFft3oBRIVSEtIw8xpH5CwJCdU7haF-- From nobody Mon May 26 20:03:17 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F561A032D for ; Mon, 26 May 2014 20:03: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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjuUNXREIjal for ; Mon, 26 May 2014 20:03:15 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB2CD1A0322 for ; Mon, 26 May 2014 20:03:14 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz1so8362130pad.2 for ; Mon, 26 May 2014 20:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0ngeoyN2pHN0ckiBrSfDnfHiT//uI+KhRwhwnAgIu74=; b=kTv5QObd8GEB7D/OnfaTkvjVVIlrHHOq1JSYdFDRflLR6SvllW09loGY9JzzTdI5Hf fhHAvXO8LM0Nxb5OhpRl8FqhfhHk+qCCGgEm5l1r5fnRLYpmiITa6qk0JJ+f3aMxZOxe fMGFXhAt5zThohU50BOY21MMw4VB3JiWGoDMDB+SgWgqZRXwIaA6S0aBUWzVQ+tv92rn c28/lcO5fhcARzwCeVFMEoHvIA0PJQs3WPPockLrweFKVQSiZPslCLi/nZ6dBjAJpwTh QcXK7o0kbfajda89kJLblHJjIFwTVJ2wj8nxjY8i7Bg5dWEJTl/YotfaMjsBIaKtgUcZ /5YQ== X-Received: by 10.67.23.135 with SMTP id ia7mr32037305pad.5.1401159792050; Mon, 26 May 2014 20:03:12 -0700 (PDT) Received: from [192.168.178.23] (155.199.69.111.dynamic.snap.net.nz. [111.69.199.155]) by mx.google.com with ESMTPSA id ko10sm20550319pbd.52.2014.05.26.20.03.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 May 2014 20:03:11 -0700 (PDT) Message-ID: <53840070.90801@gmail.com> Date: Tue, 27 May 2014 15:03:12 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Bush References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KUnmf0XfAuYFWmMA5d8hibPNiCo Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 03:03:16 -0000 On 27/05/2014 14:33, Randy Bush wrote: >> - "Temporarily isolated" or "Forever" > > we long ago concluded that today's isolated network will most likely be > connected some day. Exactly why I said "If it's forever isolated, a ULA would be appropriate (and fail-safe if it does, in reality, get connected to an ISP)." In fact, I should have said: If it's forever isolated, a ULA would be appropriate (and fail-safe if it does, in reality, get connected to an ISP or another "isolated" network). Brian Brian From nobody Mon May 26 20:06:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9101A0348 for ; Mon, 26 May 2014 20:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7vmJxOnXxS8 for ; Mon, 26 May 2014 20:06:20 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B5DB1A0347 for ; Mon, 26 May 2014 20:06:20 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1Wp7iR-0000As-LY; Tue, 27 May 2014 03:06:16 +0000 Date: Tue, 27 May 2014 12:06:22 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <53840070.90801@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/AlAZnxR9jqQ2eRtaVtRcOZk6pkM Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 03:06:21 -0000 >> we long ago concluded that today's isolated network will most likely >> be connected some day. > > Exactly why I said "If it's forever isolated, a ULA would > be appropriate (and fail-safe if it does, in reality, get > connected to an ISP)." > > In fact, I should have said: If it's forever isolated, a ULA would > be appropriate (and fail-safe if it does, in reality, get > connected to an ISP or another "isolated" network). not really. my point is that it has been proven to be unsafe to assume that any network will be forever isolated. randy From nobody Mon May 26 20:23:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B751A0343 for ; Mon, 26 May 2014 20:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0S5nFAbmNbXU for ; Mon, 26 May 2014 20:23:05 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04D81A01C8 for ; Mon, 26 May 2014 20:23:05 -0700 (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 C8B521B81BC for ; Mon, 26 May 2014 20:23:02 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 6B95519005C; Mon, 26 May 2014 20:23:02 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 26 May 2014 20:23:02 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Mon, 26 May 2014 23:22:59 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <7E9A58C5-8BD1-4AAB-B5B1-153B2D4EB707@nominum.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> To: Randy Bush X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/j6-zSVTE4i25D45ATn0w5ZF6tWY Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 03:23:06 -0000 On May 26, 2014, at 11:06 PM, Randy Bush wrote: > not really. my point is that it has been proven to be unsafe to = assume > that any network will be forever isolated. Oh. You utterly failed to make that clear. Not that it matters, = since the whole point of ULAs is to address that concern. You might = argue that they fail to do so, but you did not. From nobody Mon May 26 20:23:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B741A0347 for ; Mon, 26 May 2014 20:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aFZ-TDWXuGQ for ; Mon, 26 May 2014 20:23:50 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB4D1A01C8 for ; Mon, 26 May 2014 20:23:50 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 6920C3493AF; Tue, 27 May 2014 03:23:47 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id F0A9B160055; Tue, 27 May 2014 03:28:51 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id C2925160052; Tue, 27 May 2014 03:28:51 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 4C88116B357F; Tue, 27 May 2014 13:23:48 +1000 (EST) To: Randy Bush From: Mark Andrews References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> In-reply-to: Your message of "Tue, 27 May 2014 12:06:22 +0900." Date: Tue, 27 May 2014 13:23:48 +1000 Message-Id: <20140527032348.4C88116B357F@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2DdWoKqZsQcj42SszmaSAwoqz5o Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 03:23:51 -0000 In message , Randy Bush writes: > >> we long ago concluded that today's isolated network will most likely > >> be connected some day. > > > > Exactly why I said "If it's forever isolated, a ULA would > > be appropriate (and fail-safe if it does, in reality, get > > connected to an ISP)." > > > > In fact, I should have said: If it's forever isolated, a ULA would > > be appropriate (and fail-safe if it does, in reality, get > > connected to an ISP or another "isolated" network). > > not really. my point is that it has been proven to be unsafe to assume > that any network will be forever isolated. > > randy You are both saying that networks that are notionally isolated tend to get connected. There is no "assumsion that networks will remain isolated forever". > _______________________________________________ > 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 nobody Mon May 26 20:25:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2049B1A0343 for ; Mon, 26 May 2014 20:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 632PPjXDXByn for ; Mon, 26 May 2014 20:25:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF311A01C8 for ; Mon, 26 May 2014 20:25:37 -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.7-GA FastPath queued) with ESMTP id BHG64353; Tue, 27 May 2014 03:25:33 +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.3.158.1; Tue, 27 May 2014 04:25:05 +0100 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.3.158.1; Tue, 27 May 2014 04:25:32 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Tue, 27 May 2014 11:25:24 +0800 From: "Liubing (Leo)" To: Randy Bush , Brian E Carpenter Thread-Topic: [v6ops] ULA draft revision #2 Regarding isolated networks Thread-Index: Ac943yf4qhJ96dkPR9CtEDOlyHC2QQAMeJCAAAEGaQAAABxQAAAQ4U9Q Date: Tue, 27 May 2014 03:25:24 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6DB6@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.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.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ttHbKt8SNCdhJkAREj-6JgTeXuA Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 03:25:39 -0000 Hi Randy, > > In fact, I should have said: If it's forever isolated, a ULA would be > > appropriate (and fail-safe if it does, in reality, get connected to an > > ISP or another "isolated" network). >=20 > not really. my point is that it has been proven to be unsafe to assume t= hat > any network will be forever isolated. [Bing] Whatever it is *forever* or not, during the period when it is isolat= ed, ULAs are reasonable choice. Only if the operational burden of adding a = global prefix and ensuring the RFC6724 address selection would be not accep= table when the network connects globally in the future, there might be prob= lem of using ULAs. Regards, Bing > randy From nobody Mon May 26 20:31:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A571A0358 for ; Mon, 26 May 2014 20:31:51 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6CQ7sfQJJoe for ; Mon, 26 May 2014 20:31:50 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A6A1A0350 for ; Mon, 26 May 2014 20:31:50 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id ma3so8537503pbc.38 for ; Mon, 26 May 2014 20:31:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KIyy9g7WrPZmn5X5SIestj2F0eJ+xnJsYMZwlq4m2Rc=; b=mdwlSRGbpgrrVCrZXwudhsdyAl7vjFF4vUCNGpBJ2NXxONFwpO2OQo0olsMOkgk6n0 vnlOs6UwpdEr6NjcFFBmiULjkEuQiLv/kAtCXsh4ksFg4FYBLrikOeNns/qMJjhyuA4P +OwQ9+MDP/JX/USTtr8ZJadbKplp6/fDizP2mHNzFmO/IRvx7aqirlpBF7Qcd0nFqUah tJfif0DEjrKidg08+AXJsCQQhOXxyv6HBuD0AWZbADvYTO60Nqvv27NC6BeBVlnoxRca MXZ4pDOD/Gnv93jx6nX2imnK/eLEc9bWUPXUHzM/Xp5tJsZW/PfOM9al14XrFf9Q6HFy t3+A== X-Received: by 10.69.25.69 with SMTP id io5mr33817170pbd.22.1401161507357; Mon, 26 May 2014 20:31:47 -0700 (PDT) Received: from [192.168.178.23] (155.199.69.111.dynamic.snap.net.nz. [111.69.199.155]) by mx.google.com with ESMTPSA id dd5sm20612677pbc.85.2014.05.26.20.31.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 May 2014 20:31:46 -0700 (PDT) Message-ID: <53840723.8010606@gmail.com> Date: Tue, 27 May 2014 15:31:47 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Bush References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UOheHKyzgWKjkmW0YDQMYqE9dRo Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 03:31:51 -0000 On 27/05/2014 15:06, Randy Bush wrote: >>> we long ago concluded that today's isolated network will most likely >>> be connected some day. >> Exactly why I said "If it's forever isolated, a ULA would >> be appropriate (and fail-safe if it does, in reality, get >> connected to an ISP)." >> >> In fact, I should have said: If it's forever isolated, a ULA would >> be appropriate (and fail-safe if it does, in reality, get >> connected to an ISP or another "isolated" network). > > not really. my point is that it has been proven to be unsafe to assume > that any network will be forever isolated. I really think we're agreeing. The only safe assumption is that a "forever isolated" network will be connected at some time in the future. Even if it only happens one time in a hundred, we have to assume it. If you unexpectedly connect two Net 10s together bad things will happen. If you unexpectedly connect ULA1 and ULA2 together, less bad things will happen. Brian From nobody Mon May 26 20:35:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536EA1A029E for ; Mon, 26 May 2014 20:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_RyhdN9X0hY for ; Mon, 26 May 2014 20:35:50 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B41C1A0343 for ; Mon, 26 May 2014 20:35:50 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1Wp8Ay-0000HC-Sl; Tue, 27 May 2014 03:35:45 +0000 Date: Tue, 27 May 2014 12:35:51 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <53840723.8010606@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mk4ps7sAGTmnYz21mb-TXq3od4Y Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 03:35:51 -0000 >If you unexpectedly connect ULA1 and ULA2 together, less bad things > will happen. s/will/might not/ From nobody Mon May 26 20:51:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5716E1A0365 for ; Mon, 26 May 2014 20:51:38 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuI1V0Gbt_Wz for ; Mon, 26 May 2014 20:51:37 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F067D1A0360 for ; Mon, 26 May 2014 20:51:36 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id y20so8279106ier.20 for ; Mon, 26 May 2014 20:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AfKNjg+UQ7yTQSg8EtV1xyEIKjJGuNzVhTWmYwJQc60=; b=Y80Y86cu2yK3I69vX5Yr/BjCpCz5zlEVITkDVoDm16+KbmTVZ5/HX3Ve5sG7JNPKTc MEHx6k53rgciQq82VgYH/RtD4bv3xqODh1uvcSqhzLZyAYr4QYAqppp8hNp/qmBBpAWR DkCD6265DGamGmVBBYEt4hwPVFr67qDDZ2o5Ve8SJgJH/No4EGsG8wKOhknCbvbhr8TU g/C6fcCNPxfF/vPZAuigCvlAaJrCJY4KrSbb71FTwQvEuvOemkosWz6GnrLsxJNhjH4j 3JJmO9s5xm2Mo6eEnd9HH6oZUeKobAxN9WkMUh5qhq/bzS7nWcI6VZjrV0FcuTAwbu2f 2YxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=AfKNjg+UQ7yTQSg8EtV1xyEIKjJGuNzVhTWmYwJQc60=; b=TBq0nZrAw6Fdftgn/MhWfZZukdQv90Bj9JeYtsc5MMBn/hhh9boED/FSBJ/s+zE3NX w0wFwIL0/Q75oDRSGm4wb6T5XrAC2+Hio8iioXsEVDUPtLSQe5SkT/ANPnP55/KZjA1e H9TB2wLIlJNdZhNxf4aFBmZ8/3AWld7IfAYGMFReYZ5oDeTmc0AalhrUCuIvOgQSJKBy ruye8JSDwyQRR719/AVQ+Z/zaAwdyD2F40T8iqvpLrr1kdaJ64738QQxTckZ40dodF7A +QIWuXWCFXrVudu5z4dbmA9YhO/7zHjdqJrXD1WnbSKHOBpimS45kwgCFyJL1A9dYPHu qPdw== X-Gm-Message-State: ALoCoQk35B6/GU7ZpX0SDge/govhBTZ2m0Ymt8rIQW/s8dKCAZUG88TNr4R0bWWqQ89qDmay1a7h X-Received: by 10.50.129.104 with SMTP id nv8mr30387289igb.45.1401162693687; Mon, 26 May 2014 20:51:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.203 with HTTP; Mon, 26 May 2014 20:51:13 -0700 (PDT) In-Reply-To: <53840723.8010606@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> From: Lorenzo Colitti Date: Tue, 27 May 2014 12:51:13 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=047d7b414174a15d4904fa599c1e Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jfZAhZL1YJdVfdj3_K2ptKE98_Y Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 03:51:38 -0000 --047d7b414174a15d4904fa599c1e Content-Type: text/plain; charset=UTF-8 On Tue, May 27, 2014 at 12:31 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > not really. my point is that it has been proven to be unsafe to assume > > that any network will be forever isolated. > > I really think we're agreeing. The only safe assumption is > that a "forever isolated" network will be connected at some > time in the future. Even if it only happens one time in a > hundred, we have to assume it. > OK, we agree that "forever isolated" just means "will be connected in the future". But if we agree on that, then we must accept that "forever isolated" is no different from "temporarily isolated". Therefore: 1. There is only one case - "temporarily isolated". 2. We should not design for "forever isolated", since it does not exist. Agreed? --047d7b414174a15d4904fa599c1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, May 27, 2014 at 12:31 PM, Brian E Carpenter <brian.e.carpent= er@gmail.com> wrote:
> not really. =C2=A0my po= int is that it has been proven to be unsafe to assume
> that any network will be forever isolated.

I really think we're agreeing. The only safe assumption is
that a "forever isolated" network will be connected at some
time in the future. Even if it only happens one time in a
hundred, we have to assume it.

OK, we a= gree that "forever isolated" just means "will be connected i= n the future". But if we agree on that, then we must accept that "= ;forever isolated" is no different from "temporarily isolated&quo= t;. Therefore:

1. There is only one case - "temporarily isolated&= quot;.
2. We should not design for "forever isolated", = since it does not exist.

Agreed?
--047d7b414174a15d4904fa599c1e-- From nobody Mon May 26 21:13:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9AC1A0363 for ; Mon, 26 May 2014 21:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1dQK86A6NtI for ; Mon, 26 May 2014 21:12:59 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 264331A0347 for ; Mon, 26 May 2014 21:12:59 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1Wp8kv-0000MI-RE; Tue, 27 May 2014 04:12:54 +0000 Date: Tue, 27 May 2014 13:13:00 +0900 Message-ID: From: Randy Bush To: Lorenzo Colitti In-Reply-To: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hg1nLQkvMy2GuSsR_A40wf9raKI Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 04:13:00 -0000 >>> not really. my point is that it has been proven to be unsafe to assume >>> that any network will be forever isolated. >> >> I really think we're agreeing. The only safe assumption is >> that a "forever isolated" network will be connected at some >> time in the future. Even if it only happens one time in a >> hundred, we have to assume it. > > OK, we agree that "forever isolated" just means "will be connected in the > future". But if we agree on that, then we must accept that "forever > isolated" is no different from "temporarily isolated". Therefore: > > 1. There is only one case - "temporarily isolated". > 2. We should not design for "forever isolated", since it does not > exist. damn! houston, we have found a clueon! randy From nobody Mon May 26 21:23:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9961A0368 for ; Mon, 26 May 2014 21:23:54 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMGBOIXwTF-p for ; Mon, 26 May 2014 21:23:53 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D3351A0360 for ; Mon, 26 May 2014 21:23:53 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id x19so985763ier.27 for ; Mon, 26 May 2014 21:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qD1W3Q8hrPrudHzDAHx10BGxPt5o+apKm0kDWbDXEG4=; b=erH6SmrqjrXmudhx6Q6FLQ96Ahrd8mSuiOT7AbJ9exyi73ks5pI8T+LXSzG0dRAZZC VrNY/F60VLkH93UTqE4BTEc4PK3beKPuKFvKZenB6XjLJMnpES2C6nJK0UNTRMzY9AAD hBQe9RbBfV9sW4m80sGsDO7Ae425ezOYEmTRDYmxPG54TCnYM23V2AhhaJVR8TS8PGLa yASzsvh6Ow7zNUg/HMEs9Bg6H9bYvQWjxXVvksnzxkpWsStTP2e1CZiBtMXNkWCiNbvg rNgy8X5sC4z0cYhDzRgFgYS7b/DGr6grpL6/3l/5o0iJcmdLF62+nZ7fwDTFMZhqUAZt OBJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qD1W3Q8hrPrudHzDAHx10BGxPt5o+apKm0kDWbDXEG4=; b=Ts5zVHKLkYdWFvDTIZb7TRo0PaK3IkKjEo1XSf1o74Sr0mxTjBQj2XQdclayscsV+/ xC5KToRo/SZvpAkMF2BqzYih7dOvQGavZC3hsoqqFo+RmCbwLz+X7jWl9TkosyGfkNE/ DGmTt5o4HiZf7RD52bIYmyL34/OsSgMR+R4u0WqjUoe/g6yBRN5laoK8dzJywOwPRcwo XAOlUunn2uRpjrnSFKjCc8+W2HBmIhCkQcENaoLhbGw0JiODY3bS1OgUNHUduadC7K5K L0pWauKBPDIrS/iCDQkQ7yfpgckDexr/241Tgymvh3qtJdm3q48BmruQhn7ogn/jaMHM ZiGA== X-Gm-Message-State: ALoCoQnCw9qoiguOww8EBmuquOvnxIkN7nFl1FrdN2W95DszfUqKAdetxnRIVWL7JBi8Cj+C4hSk X-Received: by 10.50.79.227 with SMTP id m3mr29503033igx.47.1401164630173; Mon, 26 May 2014 21:23:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.203 with HTTP; Mon, 26 May 2014 21:23:29 -0700 (PDT) In-Reply-To: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> From: Lorenzo Colitti Date: Tue, 27 May 2014 13:23:29 +0900 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=089e01175f5d0dc95604fa5a10b1 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wuXTKAfxEEO-TuTY1-Vhfa1NTdU Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 04:23:54 -0000 --089e01175f5d0dc95604fa5a10b1 Content-Type: text/plain; charset=UTF-8 On Tue, May 27, 2014 at 1:13 PM, Randy Bush wrote: > > > > OK, we agree that "forever isolated" just means "will be connected in the > > future". But if we agree on that, then we must accept that "forever > > isolated" is no different from "temporarily isolated". Therefore: > > > > 1. There is only one case - "temporarily isolated". > > 2. We should not design for "forever isolated", since it does not > > exist. > > damn! houston, we have found a clueon! > Just wanted to put that down in writing very clearly. If everyone agrees with it, then great - call me an idiot for stating the obvious. If people don't agree with it, then better to find that out sooner rather than later. --089e01175f5d0dc95604fa5a10b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, May 27, 2014 at 1:13 PM, Randy Bush <randy@psg.com> wrote:
>
> OK, we agree that "forever isolated" just means "will b= e connected in the
> future". But if we agree on that, then we must accept that "= forever
> isolated" is no different from "temporarily isolated". = Therefore:
>
> 1. There is only one case - "temporarily isolated".
> 2. We should not design for "forever isolated", since it doe= s not
> =C2=A0 =C2=A0exist.

damn! =C2=A0houston, we have found a clueon!
Just wanted to put that down in writing very clearly. If everyo= ne agrees with it, then great - call me an idiot for stating the obvious. I= f people don't agree with it, then better to find that out sooner rathe= r than later.
--089e01175f5d0dc95604fa5a10b1-- From nobody Mon May 26 22:09:20 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641351A0373 for ; Mon, 26 May 2014 22:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmoVZkrLYYV8 for ; Mon, 26 May 2014 22:09:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90B631A036E for ; Mon, 26 May 2014 22:09:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHG70047; Tue, 27 May 2014 05:09:09 +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.3.158.1; Tue, 27 May 2014 06:08:41 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 May 2014 06:09:08 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Tue, 27 May 2014 13:09:02 +0800 From: "Liubing (Leo)" To: Lorenzo Colitti , Randy Bush Thread-Topic: [v6ops] ULA draft revision #2 Regarding isolated networks Thread-Index: Ac943yf4qhJ96dkPR9CtEDOlyHC2QQAMeJCAAAEGaQAAABxQAAAA4z6AAACtv4AAAMLCAAAAXbuAABGuc9A= Date: Tue, 27 May 2014 05:09:02 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.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.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/b8CeUo5qhQM1cgLoLJlsx1lU8oM Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 05:09:16 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02nkgeml506mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIExvcmVuem8gQ29saXR0aQ0KU2VudDogVHVlc2RheSwgTWF5IDI3LCAyMDE0IDEyOjIzIFBN DQpUbzogUmFuZHkgQnVzaA0KQ2M6IHY2b3BzIFdHDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBVTEEg ZHJhZnQgcmV2aXNpb24gIzIgUmVnYXJkaW5nIGlzb2xhdGVkIG5ldHdvcmtzDQoNCk9uIFR1ZSwg TWF5IDI3LCAyMDE0IGF0IDE6MTMgUE0sIFJhbmR5IEJ1c2ggPHJhbmR5QHBzZy5jb208bWFpbHRv OnJhbmR5QHBzZy5jb20+PiB3cm90ZToNCj4NCj4gT0ssIHdlIGFncmVlIHRoYXQgImZvcmV2ZXIg aXNvbGF0ZWQiIGp1c3QgbWVhbnMgIndpbGwgYmUgY29ubmVjdGVkIGluIHRoZQ0KPiBmdXR1cmUi LiBCdXQgaWYgd2UgYWdyZWUgb24gdGhhdCwgdGhlbiB3ZSBtdXN0IGFjY2VwdCB0aGF0ICJmb3Jl dmVyDQo+IGlzb2xhdGVkIiBpcyBubyBkaWZmZXJlbnQgZnJvbSAidGVtcG9yYXJpbHkgaXNvbGF0 ZWQiLiBUaGVyZWZvcmU6DQo+DQo+IDEuIFRoZXJlIGlzIG9ubHkgb25lIGNhc2UgLSAidGVtcG9y YXJpbHkgaXNvbGF0ZWQiLg0KPiAyLiBXZSBzaG91bGQgbm90IGRlc2lnbiBmb3IgImZvcmV2ZXIg aXNvbGF0ZWQiLCBzaW5jZSBpdCBkb2VzIG5vdA0KPiAgICBleGlzdC4NCmRhbW4hICBob3VzdG9u LCB3ZSBoYXZlIGZvdW5kIGEgY2x1ZW9uIQ0KDQpKdXN0IHdhbnRlZCB0byBwdXQgdGhhdCBkb3du IGluIHdyaXRpbmcgdmVyeSBjbGVhcmx5LiBJZiBldmVyeW9uZSBhZ3JlZXMgd2l0aCBpdCwgdGhl biBncmVhdCAtIGNhbGwgbWUgYW4gaWRpb3QgZm9yIHN0YXRpbmcgdGhlIG9idmlvdXMuIElmIHBl b3BsZSBkb24ndCBhZ3JlZSB3aXRoIGl0LCB0aGVuIGJldHRlciB0byBmaW5kIHRoYXQgb3V0IHNv b25lciByYXRoZXIgdGhhbiBsYXRlci4NCltCaW5nXSBIaSBMb3JlbnpvICYgYWxsLA0KSG93IGFi b3V0IHdyaXRpbmcgaXQgdGhpcyB3YXk6DQotIERvbuKAmXQgc3BlY2lmaWNhbGx5IGRpdmlkZSB0 aGUgY2FzZXMgaW50byDigJx0ZW1wb3JhcmlseeKAnSBhbmQg4oCcZm9yZXZlcuKAnSBpbiB0aGUg ZHJhZnQuDQotIEp1c3Qgc2F5LCBub3cgeW91IGhhdmUgYW4gaXNvbGF0ZWQgbmV0d29yaywgVUxB cyBhcmUgcmVhc29uYWJsZSBjaG9pY2UsIGJlY2F1c2UgaXQgaXMgZnJlZSBhbmQgY2FuIGJlIHVz ZWQgcmlnaHQgYXdheS4NCi0gQnV0IHRoZXJlIGFyZSBzb21lIGNvbnNpZGVyYXRpb25zIGlmIHRo ZSBuZXR3b3JrIGlzIGNvbm5lY3RlZCBzb21lZGF5Og0KICAgKiBJZiBpdCBjb25uZWN0cyB0byBh bm90aGVyIGlzb2xhdGVkL3ByaXZhdGUgbmV0d29yaywgdGhlbiBjb21lcyB0aGUgY29sbGlzaW9u IHByb2JsZW0uIEhvd2V2ZXIsIGlmIHRoZSBVTEFzIHdlcmUgZ2VuZXJhdGVkIGJ5IHRoZSBzdGFu ZGFyZCB3YXksIHRoaXMgd29u4oCZdCBiZSBhIGJpZyBwcm9ibGVtLg0KICAqIElmIGl0IGNvbm5l Y3RzIHRvIHRoZSBnbG9iYWwgSW50ZXJuZXQsIHRoZW4gbmVlZCBzb21lIG9wZXJhdGlvbiB0byBh ZGQgYSBuZXcgZ2xvYmFsIHByZWZpeCBhbmQgZW5zdXJlIHRoZSBhZGRyZXNzIHNlbGVjdGlvbiBp biB0aGUgcmlnaHQgZm9ybS4gT3IganVzdCBwdXQgYSBOQVQuDQotIElmIHRoZXNlIGZ1cnRoZXIg b3BlcmF0aW9ucy9jb25zaWRlcmF0aW9ucyBhcmUgdW5hY2NlcHRhYmxlIGZvciBzb21lIHJlYXNv bnMsIHRoZW4gdGhlIGFkbWluaXN0cmF0b3JzIG5lZWQgdG8gYmUgY2FyZWZ1bCB3aXRoIHVzaW5n IFVMQXMgaW4gY3VycmVudCBpc29sYXRlZCBuZXR3b3Jrcy4NCg0KRG8geW91IGFncmVlPw0KDQpS ZWdhcmRzLA0KQmluZw0K --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02nkgeml506mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwg ZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtaW5kZW50OjIxLjBwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMzU2NjkwMTYxOw0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNjQ2ODEwMzAyIC02NTUwNTA4OTYgNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCglt YXJnaW4tbGVmdDo4MS44cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OuWui+S9kzt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGll dGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Mb3JlbnpvIENvbGl0dGk8YnI+DQo8Yj5TZW50 OjwvYj4gVHVlc2RheSwgTWF5IDI3LCAyMDE0IDEyOjIzIFBNPGJyPg0KPGI+VG86PC9iPiBSYW5k eSBCdXNoPGJyPg0KPGI+Q2M6PC9iPiB2Nm9wcyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W3Y2b3BzXSBVTEEgZHJhZnQgcmV2aXNpb24gIzIgUmVnYXJkaW5nIGlzb2xhdGVkIG5ldHdvcmtz PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ T24gVHVlLCBNYXkgMjcsIDIwMTQgYXQgMToxMyBQTSwgUmFuZHkgQnVzaCAmbHQ7PGEgaHJlZj0i bWFpbHRvOnJhbmR5QHBzZy5jb20iIHRhcmdldD0iX2JsYW5rIj5yYW5keUBwc2cuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs8 YnI+DQomZ3Q7IE9LLCB3ZSBhZ3JlZSB0aGF0ICZxdW90O2ZvcmV2ZXIgaXNvbGF0ZWQmcXVvdDsg anVzdCBtZWFucyAmcXVvdDt3aWxsIGJlIGNvbm5lY3RlZCBpbiB0aGU8YnI+DQomZ3Q7IGZ1dHVy ZSZxdW90Oy4gQnV0IGlmIHdlIGFncmVlIG9uIHRoYXQsIHRoZW4gd2UgbXVzdCBhY2NlcHQgdGhh dCAmcXVvdDtmb3JldmVyPGJyPg0KJmd0OyBpc29sYXRlZCZxdW90OyBpcyBubyBkaWZmZXJlbnQg ZnJvbSAmcXVvdDt0ZW1wb3JhcmlseSBpc29sYXRlZCZxdW90Oy4gVGhlcmVmb3JlOjxicj4NCiZn dDs8YnI+DQomZ3Q7IDEuIFRoZXJlIGlzIG9ubHkgb25lIGNhc2UgLSAmcXVvdDt0ZW1wb3Jhcmls eSBpc29sYXRlZCZxdW90Oy48YnI+DQomZ3Q7IDIuIFdlIHNob3VsZCBub3QgZGVzaWduIGZvciAm cXVvdDtmb3JldmVyIGlzb2xhdGVkJnF1b3Q7LCBzaW5jZSBpdCBkb2VzIG5vdDxicj4NCiZndDsg Jm5ic3A7ICZuYnNwO2V4aXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmRhbW4hICZuYnNwO2hvdXN0b24sIHdl IGhhdmUgZm91bmQgYSBjbHVlb24hPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+SnVzdCB3YW50ZWQgdG8gcHV0IHRoYXQgZG93biBpbiB3cml0aW5nIHZlcnkgY2xlYXJs eS4gSWYgZXZlcnlvbmUgYWdyZWVzIHdpdGggaXQsIHRoZW4gZ3JlYXQgLSBjYWxsIG1lIGFuIGlk aW90IGZvciBzdGF0aW5nIHRoZSBvYnZpb3VzLiBJZiBwZW9wbGUgZG9uJ3QgYWdyZWUgd2l0aCBp dCwgdGhlbiBiZXR0ZXIgdG8gZmluZCB0aGF0IG91dCBzb29uZXIgcmF0aGVyIHRoYW4gbGF0ZXIu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bQmluZ10gSGkgTG9y ZW56byAmYW1wOyBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5Ib3cgYWJvdXQgd3JpdGluZyBpdCB0aGlzIHdheTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPi0gRG9u4oCZdCBzcGVjaWZpY2FsbHkgZGl2aWRlIHRoZSBjYXNl cyBpbnRvIOKAnHRlbXBvcmFyaWx54oCdIGFuZCDigJxmb3JldmVy4oCdIGluIHRoZSBkcmFmdC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0gSnVzdCBzYXksIG5v dyB5b3UgaGF2ZSBhbiBpc29sYXRlZCBuZXR3b3JrLCBVTEFzIGFyZSByZWFzb25hYmxlIGNob2lj ZSwgYmVjYXVzZSBpdCBpcyBmcmVlIGFuZCBjYW4gYmUgdXNlZCByaWdodCBhd2F5Lg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tIEJ1dCB0aGVyZSBhcmUgc29t ZSBjb25zaWRlcmF0aW9ucyBpZiB0aGUgbmV0d29yayBpcyBjb25uZWN0ZWQgc29tZWRheTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyAqIElm IGl0IGNvbm5lY3RzIHRvIGFub3RoZXIgaXNvbGF0ZWQvcHJpdmF0ZSBuZXR3b3JrLCB0aGVuIGNv bWVzIHRoZSBjb2xsaXNpb24gcHJvYmxlbS4gSG93ZXZlciwgaWYgdGhlIFVMQXMgd2VyZSBnZW5l cmF0ZWQgYnkgdGhlIHN0YW5kYXJkDQogd2F5LCB0aGlzIHdvbuKAmXQgYmUgYSBiaWcgcHJvYmxl bS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyAqIElm IGl0IGNvbm5lY3RzIHRvIHRoZSBnbG9iYWwgSW50ZXJuZXQsIHRoZW4gbmVlZCBzb21lIG9wZXJh dGlvbiB0byBhZGQgYSBuZXcgZ2xvYmFsIHByZWZpeCBhbmQgZW5zdXJlIHRoZSBhZGRyZXNzIHNl bGVjdGlvbiBpbiB0aGUgcmlnaHQgZm9ybS4NCiBPciBqdXN0IHB1dCBhIE5BVC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0gSWYgdGhlc2UgZnVydGhlciBvcGVy YXRpb25zL2NvbnNpZGVyYXRpb25zIGFyZSB1bmFjY2VwdGFibGUgZm9yIHNvbWUgcmVhc29ucywg dGhlbiB0aGUgYWRtaW5pc3RyYXRvcnMgbmVlZCB0byBiZSBjYXJlZnVsIHdpdGggdXNpbmcgVUxB cyBpbiBjdXJyZW50DQogaXNvbGF0ZWQgbmV0d29ya3MuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5EbyB5b3UgYWdyZWU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5CaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02nkgeml506mbxchi_-- From nobody Mon May 26 22:22:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6177E1A0377 for ; Mon, 26 May 2014 22:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgPG9oC4Nyca for ; Mon, 26 May 2014 22:22:04 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 993071A0372 for ; Mon, 26 May 2014 22:22:04 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1Wp9pn-0000Vf-Ku; Tue, 27 May 2014 05:22:00 +0000 Date: Tue, 27 May 2014 14:22:06 +0900 Message-ID: From: Randy Bush To: "Liubing (Leo)" In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@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=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/uPDYHj-TGlmQSJsOOkOJpgLCTq4 Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 05:22:05 -0000 > How about writing it this way: > - Don=E2=80=99t specifically divide the cases into =E2=80=9Ctemporarily= =E2=80=9D and =E2=80=9Cforever=E2=80=9D > in the draft.=20 > - But there are some considerations if the network is connected > someday: no. in front, state very clearly that you may think you have an isolated network now but the wisdom of the internet is that it is unlikely to stay isolated forever no matter what you think today. > - Just say, now you have an isolated network, ULAs are reasonable > choice, because it is free and can be used right away.=20 and because you can not assume it will remain isolated, if you are silly enough to use a ULA today, you had best plan to change that. randy From nobody Mon May 26 22:27:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBD91A037A for ; Mon, 26 May 2014 22:27:04 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjdoEHsWXB94 for ; Mon, 26 May 2014 22:27:03 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731551A0377 for ; Mon, 26 May 2014 22:27:03 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id tp5so8410557ieb.17 for ; Mon, 26 May 2014 22:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kUTek/G/rhw32F12L+NAvW5yvXT0VCdyRq9ahAZmsD8=; b=YSJvmpL8xDl/48Wxxz6ecwFp3Qg8o0wDLoa8SiNfMFG5I7FY5R/CD01FnV8MbdEC0q 8kDKaBFn9HdGuXS6slKVWldoV7k8sT53RMv6nwThYpTsxA43uF86VlUGYpc867rUWyoi 9pQmvI0vjZLtFEmjAzTtFxhjnxglxOW8pZrSGweESrgEhUBg80E8UJ6+NU73PK93T9SJ l2LuHCTXBdFUgMWo58/ZRlAZN76PpcU3xUEFnIr+wgxoGZF4RAX9uKFpsU3eXLgJwGEK 5cp5eltC3Ad6toqb0xecRZX2qbHhwPwbjVzoCV/F9qm7bzTkerP2bcq/dRaWSae5Ll+W ofmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kUTek/G/rhw32F12L+NAvW5yvXT0VCdyRq9ahAZmsD8=; b=YuR5cnSokrvYMzeb6AcEZg50mkETdz0rlqumKtbjKl/m6A5EZubT6O2ltDVACBWMcy qJk7OKGWIZvdMczsoD+W3dKgG97ihjcubzmxiSFyMoYYEGs8iB5ZIfKi6y5byqA072GJ 01Tx6vM3U1+wRV+mHwj2mJGGQ+Lw3FWCV1F6ItP9+2edRPx339cNZEkmw8owkeNwVLNp K70TLatZwri09FN8noH4rytXxE9VMinSylsm9SDe88mlfOMfYS/GBSiX9zEegATR5Zr3 0CvFyvMH9q4mMxp8Iq7awgr7eemUuGbtAKOTQwUQ9LO//JG1K5Ehh8a2+yljmnUQOvfN P7LA== X-Gm-Message-State: ALoCoQnyD5owqR2VAim9sXjYe4NRfSUyhf82h7U00oXuWPuIgqn07vsI8Z/md6iBY2chHGR96mRu X-Received: by 10.50.26.3 with SMTP id h3mr30885970igg.31.1401168420168; Mon, 26 May 2014 22:27:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.203 with HTTP; Mon, 26 May 2014 22:26:40 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> From: Lorenzo Colitti Date: Tue, 27 May 2014 14:26:40 +0900 Message-ID: To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=047d7bd76970f4903204fa5af13d Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LhEQcvwQTX8xm7x0q_XFfDFL2nw Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 05:27:04 -0000 --047d7bd76970f4903204fa5af13d Content-Type: text/plain; charset=UTF-8 On Tue, May 27, 2014 at 2:09 PM, Liubing (Leo) wrote: > > * If it connects to the global Internet, then need some operation to add > a new global prefix and ensure the address selection in the right form. Or > just put a NAT. > Please don't propose NAT as a solution to this. - NAT imposes substantial additional complexity on many applications, and breaks applications that do not implement that complexity. - NAT is strongly discouraged by the IAB (RFC 5902 section 4.1). - NAT provides no advantages compared to using ULA + GUA. --047d7bd76970f4903204fa5af13d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, May 27, 2014 at 2:09 PM, Liubing (Leo) <leo.liubing@huawei.com> wrote:

=C2=A0 * If it connects to the global Internet, then nee= d some operation to add a new global prefix and ensure the address selectio= n in the right form. Or just put a NAT.


Please don't propose NAT as a solution to= this.
  • NAT imposes substantial additional complexity on m= any applications, and breaks applications that do not implement that comple= xity.
  • NAT is strongly discouraged by the IAB (RFC 5902 section 4.1).
    =
  • NAT provides no advantages compared to using ULA + GUA.
<= /div>
--047d7bd76970f4903204fa5af13d-- From nobody Mon May 26 23:04:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CED31A0372 for ; Mon, 26 May 2014 23:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNOduHgx4Eqj for ; Mon, 26 May 2014 23:04:26 -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 91A771A0384 for ; Mon, 26 May 2014 23:04:26 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id F184A3494D0; Tue, 27 May 2014 06:04:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0520E160055; Tue, 27 May 2014 06:09:28 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id CAF77160052; Tue, 27 May 2014 06:09:27 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 0157A16B6C6E; Tue, 27 May 2014 16:04:17 +1000 (EST) To: Randy Bush From: Mark Andrews References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> In-reply-to: Your message of "Tue, 27 May 2014 14:22:06 +0900." Date: Tue, 27 May 2014 16:04:17 +1000 Message-Id: <20140527060418.0157A16B6C6E@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/bOOo2eNvIE4_aHMVLsJyLCdKANA Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 06:04:28 -0000 In message , Randy Bush writes: > > How about writing it this way: > > - Dont specifically divide the cases into temporarily and forever > > in the draft. > > - But there are some considerations if the network is connected > > someday: > > no. > > in front, state very clearly that you may think you have an isolated > network now but the wisdom of the internet is that it is unlikely to > stay isolated forever no matter what you think today. > > > - Just say, now you have an isolated network, ULAs are reasonable > > choice, because it is free and can be used right away. > > and because you can not assume it will remain isolated, if you are silly > enough to use a ULA today, you had best plan to change that. Using ULA does not preclude using a GUA as well. ULA doesn't preclude using a second ULA prefix. You seem to assume that you will need renumber/remove the existing ULA addresses. For all practical senarios you will never need to do this. Even if two or more sites using the same ULA prefix connect you just add additional ULA prefixes to communicate. The old ULA addresses are not used for inter site communication. Mark > randy > > _______________________________________________ > 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 nobody Mon May 26 23:49:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F211A03AA for ; Mon, 26 May 2014 23:49:45 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiPxPrYk9Din for ; Mon, 26 May 2014 23:49:42 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B7AB1A0392 for ; Mon, 26 May 2014 23:49:42 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7F6689C; Tue, 27 May 2014 08:49:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1401173377; bh=/NnrxRyJ9QI5wKL5UMlRd+gOIBAN8x6kJu6TcbM55hs=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=yZOMu3EWaJL/ZDxYsc3+iZOo76Sn4+ZWF1CjAnl4LjcwC5p4tDF3mDCNEWoEsBIsR lLNplalyQBCH7MbVALkcD38N+UFFHRLhr3YSFh36696L7no26GBuNfHPbe6NxygIa5 xf87I+hYOBn1mIIj5ETWCmIFpxxHnN4E7C+gO+eM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 76E0C9A; Tue, 27 May 2014 08:49:37 +0200 (CEST) Date: Tue, 27 May 2014 08:49:37 +0200 (CEST) From: Mikael Abrahamsson To: Mark Andrews In-Reply-To: <20140527060418.0157A16B6C6E@rock.dv.isc.org> Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <20140527060418.0157A16B6C6E@rock.dv.isc.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/dNSBPr0LX99ytX-Hv6p6AfecpNM Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 06:49:45 -0000 On Tue, 27 May 2014, Mark Andrews wrote: > You seem to assume that you will need renumber/remove the existing ULA > addresses. For all practical senarios you will never need to do this. > Even if two or more sites using the same ULA prefix connect you just add > additional ULA prefixes to communicate. The old ULA addresses are not > used for inter site communication. That means that all resources that needs to be accessed from one organizaton to the next uses this new common ULA in order for source address selection to work properly. Only way to solve this that I can see it to use split horizon DNS, which is yet another mess operationally, in addition that all the new services addresses will need to be configured in firewalls etc. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon May 26 23:54:56 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3102D1A03B7 for ; Mon, 26 May 2014 23:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yAtsFE-Uvnd for ; Mon, 26 May 2014 23:54:50 -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 E3BE51A0273 for ; Mon, 26 May 2014 23:54:50 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 89C423493B8; Tue, 27 May 2014 06:54:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id BB926160064; Tue, 27 May 2014 06:59:51 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 8DF1016005B; Tue, 27 May 2014 06:59:51 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 3E98316B6F9D; Tue, 27 May 2014 16:54:41 +1000 (EST) To: Mikael Abrahamsson From: Mark Andrews References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <20140527060418.0157A16B6C6E@rock.dv.isc.org> In-reply-to: Your message of "Tue, 27 May 2014 08:49:37 +0200." Date: Tue, 27 May 2014 16:54:41 +1000 Message-Id: <20140527065441.3E98316B6F9D@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/JK2l84I4stEYwS0ZDUmecn97lpM Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 06:54:54 -0000 In message , Mikael Abrah amsson writes: > On Tue, 27 May 2014, Mark Andrews wrote: > > > You seem to assume that you will need renumber/remove the existing ULA > > addresses. For all practical senarios you will never need to do this. > > Even if two or more sites using the same ULA prefix connect you just add > > additional ULA prefixes to communicate. The old ULA addresses are not > > used for inter site communication. > > That means that all resources that needs to be accessed from one > organizaton to the next uses this new common ULA in order for source > address selection to work properly. Only way to solve this that I can see > it to use split horizon DNS, which is yet another mess operationally, in > addition that all the new services addresses will need to be configured in > firewalls etc. You need split horizon if you use ULA regardless of whether you connect to another ULA site or not. ULA + GUA requires split horizon. > -- > 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 nobody Tue May 27 00:05:12 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39311A0163 for ; Tue, 27 May 2014 00:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mb4nkAmnol15 for ; Tue, 27 May 2014 00:05:09 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237131A0273 for ; Tue, 27 May 2014 00:05:09 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E6A6BA1; Tue, 27 May 2014 09:05:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1401174303; bh=Jp6cCepeQKWEUDT+jAqprgOXdcKCmzLqIHTeFArBYNE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=rWTVxXXP2LrWwZ3LNMpMwgxlgeNlifjOL6S2FUW8q4SVHppPR7gghYDIbTz8A1ULQ NEdChphvJgGneFpVj1i0nhvYFYIKyyKno2k9todpQZhcQOSM2T0ixZ309B2lcjIz1h LP7uWkrNURBIUrFF5GBp2mxiXrmG/JfvgMnVvA/8= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E2DF49C; Tue, 27 May 2014 09:05:03 +0200 (CEST) Date: Tue, 27 May 2014 09:05:03 +0200 (CEST) From: Mikael Abrahamsson To: Mark Andrews In-Reply-To: <20140527065441.3E98316B6F9D@rock.dv.isc.org> Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <20140527060418.0157A16B6C6E@rock.dv.isc.org> <20140527065441.3E98316B6F9D@rock.dv.isc.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/uJIYW4Md7FPJj09-0qXQOp0O3WU Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 07:05:10 -0000 On Tue, 27 May 2014, Mark Andrews wrote: > You need split horizon if you use ULA regardless of whether you connect > to another ULA site or not. ULA + GUA requires split horizon. Well, if that's the methodology then you now have 3 prefixes so it's an additional split horizon to maintain. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue May 27 01:13:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598741A03E4 for ; Tue, 27 May 2014 01:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqQJcYeB-PND for ; Tue, 27 May 2014 01:13:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D63AC1A03DA for ; Tue, 27 May 2014 01:12:58 -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.7-GA FastPath queued) with ESMTP id BHG86778; Tue, 27 May 2014 08:12:54 +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.3.158.1; Tue, 27 May 2014 09:12:25 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 May 2014 09:12:50 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 27 May 2014 16:12:44 +0800 From: "Liubing (Leo)" To: Lorenzo Colitti Thread-Topic: [v6ops] ULA draft revision #2 Regarding isolated networks Thread-Index: Ac943yf4qhJ96dkPR9CtEDOlyHC2QQAMeJCAAAEGaQAAABxQAAAA4z6AAACtv4AAAMLCAAAAXbuAABGuc9D//4QzAP//S/mg Date: Tue, 27 May 2014 08:12:44 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E8F@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@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.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E8Fnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ptc8GpiLlqemlmQbEwmvM4jtMxQ Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 08:13:09 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E8Fnkgeml506mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NClNl bnQ6IFR1ZXNkYXksIE1heSAyNywgMjAxNCAxOjI3IFBNDQpUbzogTGl1YmluZyAoTGVvKQ0KQ2M6 IFJhbmR5IEJ1c2g7IHY2b3BzIFdHDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBVTEEgZHJhZnQgcmV2 aXNpb24gIzIgUmVnYXJkaW5nIGlzb2xhdGVkIG5ldHdvcmtzDQoNCk9uIFR1ZSwgTWF5IDI3LCAy MDE0IGF0IDI6MDkgUE0sIExpdWJpbmcgKExlbykgPGxlby5saXViaW5nQGh1YXdlaS5jb208bWFp bHRvOmxlby5saXViaW5nQGh1YXdlaS5jb20+PiB3cm90ZToNCiAgKiBJZiBpdCBjb25uZWN0cyB0 byB0aGUgZ2xvYmFsIEludGVybmV0LCB0aGVuIG5lZWQgc29tZSBvcGVyYXRpb24gdG8gYWRkIGEg bmV3IGdsb2JhbCBwcmVmaXggYW5kIGVuc3VyZSB0aGUgYWRkcmVzcyBzZWxlY3Rpb24gaW4gdGhl IHJpZ2h0IGZvcm0uIE9yIGp1c3QgcHV0IGEgTkFULg0KDQpQbGVhc2UgZG9uJ3QgcHJvcG9zZSBO QVQgYXMgYSBzb2x1dGlvbiB0byB0aGlzLg0KDQogICogICBOQVQgaW1wb3NlcyBzdWJzdGFudGlh bCBhZGRpdGlvbmFsIGNvbXBsZXhpdHkgb24gbWFueSBhcHBsaWNhdGlvbnMsIGFuZCBicmVha3Mg YXBwbGljYXRpb25zIHRoYXQgZG8gbm90IGltcGxlbWVudCB0aGF0IGNvbXBsZXhpdHkuDQogICog ICBOQVQgaXMgc3Ryb25nbHkgZGlzY291cmFnZWQgYnkgdGhlIElBQiAoUkZDIDU5MDIgc2VjdGlv biA0LjEpLg0KICAqICAgTkFUIHByb3ZpZGVzIG5vIGFkdmFudGFnZXMgY29tcGFyZWQgdG8gdXNp bmcgVUxBICsgR1VBLg0KW0JpbmddIE9rLCBJIHNob3VsZG7igJl0IG1lbnRpb24gaXQuIFRoYW5r cy4NCg0KUmVnYXJkcywNCkJpbmcNCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E8Fnkgeml506mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjE4ODYzMjg0NjA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE2MTgyNTQ5OTg7fQ0KQGxp c3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9t OjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow Y20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPGJyPg0K PGI+U2VudDo8L2I+IFR1ZXNkYXksIE1heSAyNywgMjAxNCAxOjI3IFBNPGJyPg0KPGI+VG86PC9i PiBMaXViaW5nIChMZW8pPGJyPg0KPGI+Q2M6PC9iPiBSYW5keSBCdXNoOyB2Nm9wcyBXRzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBVTEEgZHJhZnQgcmV2aXNpb24gIzIgUmVnYXJk aW5nIGlzb2xhdGVkIG5ldHdvcmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+T24gVHVlLCBNYXkgMjcsIDIwMTQgYXQgMjowOSBQTSwgTGl1 YmluZyAoTGVvKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxlby5saXViaW5nQGh1YXdlaS5jb20iIHRh cmdldD0iX2JsYW5rIj5sZW8ubGl1YmluZ0BodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsg KiBJZiBpdCBjb25uZWN0cyB0byB0aGUgZ2xvYmFsIEludGVybmV0LCB0aGVuIG5lZWQgc29tZSBv cGVyYXRpb24gdG8gYWRkIGEgbmV3IGdsb2JhbA0KIHByZWZpeCBhbmQgZW5zdXJlIHRoZSBhZGRy ZXNzIHNlbGVjdGlvbiBpbiB0aGUgcmlnaHQgZm9ybS4gT3IganVzdCBwdXQgYSBOQVQuPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPlBsZWFzZSBkb24ndCBwcm9wb3NlIE5BVCBhcyBhIHNvbHV0aW9uIHRvIHRoaXMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBsYW5nPSJF Ti1VUyI+TkFUIGltcG9zZXMgc3Vic3RhbnRpYWwgYWRkaXRpb25hbCBjb21wbGV4aXR5IG9uIG1h bnkgYXBwbGljYXRpb25zLCBhbmQgYnJlYWtzIGFwcGxpY2F0aW9ucyB0aGF0IGRvIG5vdCBpbXBs ZW1lbnQgdGhhdCBjb21wbGV4aXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+ TkFUIGlzIHN0cm9uZ2x5IGRpc2NvdXJhZ2VkIGJ5IHRoZSBJQUIgKFJGQyA1OTAyIHNlY3Rpb24g NC4xKS48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPk5BVCBwcm92aWRlcyBubyBh ZHZhbnRhZ2VzIGNvbXBhcmVkIHRvIHVzaW5nIFVMQSAmIzQzOyBHVUEuPG86cD48L286cD48L3Nw YW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltCaW5nXSBPaywgSSBzaG91bGRu 4oCZdCBtZW50aW9uIGl0LiBUaGFua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5CaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E8Fnkgeml506mbxchi_-- From nobody Tue May 27 01:34:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B656F1A007F for ; Tue, 27 May 2014 01:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMZ-E_Z_gVuL for ; Tue, 27 May 2014 01:34:40 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 236C51A0064 for ; Tue, 27 May 2014 01:34:40 -0700 (PDT) Received: from [IPv6:2620::930:0:225:ff:fe44:af17] ([IPv6:2620:0:930:0:225:ff:fe44:af17]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s4R8VFNh005032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 May 2014 01:31:16 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s4R8VFNh005032 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1401179476; bh=lA1UqPR3GouUeTo0J5PBoLlVESY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=WP/xW19nPoRX6Aos38CN9/bFtiIZtXSHkWMoHWmZSUUnLaYzQQ95vUUjjcyj2Nq8a 69vXZscse4qRP3SKZDVdmb0f3mDdeyQao/0gtyezyeGjmaE4ahgkNpii9ESIA+WOJV fsoiVgNJEAsfeMNsJ0fe+RzCFuEJPI/UoF6pvlKQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: Date: Tue, 27 May 2014 01:34:39 -0700 Content-Transfer-Encoding: 7bit Message-Id: <0A3FEB9F-6233-4ECE-B1A2-47ACD8D9FFEE@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B8B@nkgeml506-mbx.china.huawei.com> <53839DB5.9090602@gmail.com> To: Randy Bush X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 27 May 2014 01:31:16 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/MqKBqFaKXdBshgQMml4BGbGCzgo Cc: v6ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] ULA draft revision #1 Changing "Recommendations/Guidelines" to "Considerations" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 08:34:40 -0000 On May 26, 2014, at 7:31 PM, Randy Bush wrote: >> How about "ULA usages considered helpful"? > > how about ula usages considered dangerous and unnecessary? > +1 Owen From nobody Tue May 27 01:50:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1712D1A002F for ; Tue, 27 May 2014 01:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.641 X-Spam-Level: X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGDflKBJxnkM for ; Tue, 27 May 2014 01:50: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 684DF1A002D for ; Tue, 27 May 2014 01:50:49 -0700 (PDT) Received: from [IPv6:2620::930:0:225:ff:fe44:af17] ([IPv6:2620:0:930:0:225:ff:fe44:af17]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s4R8jiN0005262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 May 2014 01:45:44 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s4R8jiN0005262 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1401180345; bh=jThOJuDCtQN35nSF6e0wQ+47/d0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=yj/309dS/UwP1d2BhZHOJqAme1DpOemK1NshwHm+FRTYjaoiV0mGQMpJwd8Suyhh8 oslTNu2Y0Jsp6PvfdLxnpu6Nv1+LyOoAKRv9quARj6MabpTuRMaYIEtUIV9m7Xb6gM d+7rfq/dtQqntb+TzrbUNd3xWPDsMKLx75aXgLkM= Content-Type: multipart/alternative; boundary="Apple-Mail=_52F1EC17-706B-4084-9BAB-7128A5E80CB3" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: Date: Tue, 27 May 2014 01:49:07 -0700 Message-Id: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 27 May 2014 01:45:45 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ogSeOQx5_ECYAsAnpjJ1Q1dvjOA Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 08:50:51 -0000 --Apple-Mail=_52F1EC17-706B-4084-9BAB-7128A5E80CB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 26, 2014, at 10:26 PM, Lorenzo Colitti = wrote: > On Tue, May 27, 2014 at 2:09 PM, Liubing (Leo) = wrote: > * If it connects to the global Internet, then need some operation to = add a new global prefix and ensure the address selection in the right = form. Or just put a NAT. >=20 >=20 > Please don't propose NAT as a solution to this. > NAT imposes substantial additional complexity on many applications, = and breaks applications that do not implement that complexity. > NAT is strongly discouraged by the IAB (RFC 5902 section 4.1). > NAT provides no advantages compared to using ULA + GUA. +1 NAT in all its forms, including NPT should be avoided wherever possible. We certainly should not be endorsing in in WG output or RFCs. Owen --Apple-Mail=_52F1EC17-706B-4084-9BAB-7128A5E80CB3 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

On Tue, May 27, 2014 at 2:09 PM, Liubing (Leo) <leo.liubing@huawei.com> wrote:

  * If it connects to the global Internet, then need some operation to add a new global prefix and ensure the address selection in the right form. Or just put a NAT.


Please don't propose NAT as a solution to this.
  • NAT imposes substantial additional complexity on many applications, and breaks applications that do not implement that complexity.
  • NAT is strongly discouraged by the IAB (RFC 5902 section 4.1).
  • NAT provides no advantages compared to using ULA + GUA.

+1

NAT in all its forms, including NPT should be avoided wherever possible.

We certainly should not be endorsing in  in WG output or RFCs.

Owen

--Apple-Mail=_52F1EC17-706B-4084-9BAB-7128A5E80CB3-- From nobody Tue May 27 02:24:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762A01A006D for ; Tue, 27 May 2014 02:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMwSr-jif-c6 for ; Tue, 27 May 2014 02:24:43 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 7882E1A0049 for ; Tue, 27 May 2014 02:24:42 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1WpDcc-0000BMC; Tue, 27 May 2014 11:24:38 +0200 Message-Id: To: v6ops WG From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> In-reply-to: Your message of "Tue, 27 May 2014 14:22:06 +0900 ." Date: Tue, 27 May 2014 11:24:28 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hP355_GqB5lf9NNhHM6nGuF2dj0 Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 09:24:45 -0000 In your letter dated Tue, 27 May 2014 14:22:06 +0900 you wrote: > and because you can not assume it will remain isolated, if you are > silly enough to use a ULA today, you had best plan to change that. In most markets, a 'dentist office' that has an Internet connection and switches ISPs will get a new prefix. This is problem that need to be solved anyhow. So if we can migrate a small business from one prefix to another, we can just as well do that from ULA to GUA. I don't see why we would need to discuss the foreverness of ULA, when GUAs are not at all forever. (I naively assume that having all small businesses get a PI prefix is not going to happen) From nobody Tue May 27 02:31:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AA91A006D for ; Tue, 27 May 2014 02:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIYJ8LXAWFDj for ; Tue, 27 May 2014 02:31:14 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id B71871A004E for ; Tue, 27 May 2014 02:31:13 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1WpDiw-0000BIC; Tue, 27 May 2014 11:31:10 +0200 Message-Id: To: v6ops WG From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <20140527060418.0157A16B6C6E@rock.dv.isc.org> <20140527065441.3E98316B6F9D@rock.dv.isc.org> In-reply-to: Your message of "Tue, 27 May 2014 09:05:03 +0200 (CEST) ." Date: Tue, 27 May 2014 11:31:10 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wdeA3aFn07ogAefMjat-7zOzM60 Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 09:31:15 -0000 In your letter dated Tue, 27 May 2014 09:05:03 +0200 (CEST) you wrote: >On Tue, 27 May 2014, Mark Andrews wrote: > >> You need split horizon if you use ULA regardless of whether you connect >> to another ULA site or not. ULA + GUA requires split horizon. > >Well, if that's the methodology then you now have 3 prefixes so it's an >additional split horizon to maintain. I always assumed that connecting two ULA prefixes just involved setting up routing between them. So each host would just get one ULA prefix. With split horizon you would have to do something to make sure that DNS requests get routed properly. From nobody Tue May 27 05:52:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586C71A011D for ; Tue, 27 May 2014 05:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlgrK4spMtcS for ; Tue, 27 May 2014 05:52:06 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD34A1A011A for ; Tue, 27 May 2014 05:52:06 -0700 (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 C4EC21B8038 for ; Tue, 27 May 2014 05:52:03 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id BAA4A19005C; Tue, 27 May 2014 05:52:03 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 May 2014 05:52:03 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Tue, 27 May 2014 08:52:02 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> To: Philip Homburg X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xYZ9_-O_qH-CHfmpiA_6ArWOYvc Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 12:52:08 -0000 On May 27, 2014, at 5:24 AM, Philip Homburg = wrote: > I don't see why we would need to discuss the foreverness of ULA, when = GUAs are not > at all forever.=20 You'd like to think that, and in some circumstances it makes sense. If = my homenet has a ULA, it has it so that local communications can proceed = when I don't have an internet connection. A renumbering event that = switches to a new ULA shouldn't be a big deal. The operational situation that's problematic is the large enterprise = scenario, where you have two large enterprises with their own ULAs that = merge. If those ULAs happen to clash, you have to renumber at least = one of them. If they don't clash, you still have to deal with routing = them (although I think the split-horizon complexity objection Mikael = raised ought to be thought through carefully before being asserted as = factual, because I think it can be addressed through routing and not = naming). I wish people wouldn't say "that is evil and must be burned" because = it's clearly useful in some real scenarios where there is no better = alternative, and hence I think documenting those scenarios and = explaining how to do them right (IOW, not wind up with NAT) is a = valuable service we can do for the community, which will use them = regardless.= From nobody Tue May 27 06:30:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920B11A0137 for ; Tue, 27 May 2014 06:30:43 -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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdub8Gd6C8Qc for ; Tue, 27 May 2014 06:30:41 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 405D51A011D for ; Tue, 27 May 2014 06:30:40 -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.8/8.14.5) with ESMTP id s4RDUYNV032164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 27 May 2014 14:30:34 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <5384937A.90409@foobar.org> Date: Tue, 27 May 2014 14:30:34 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ted Lemon , Philip Homburg References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> In-Reply-To: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_wGFgYS6MeXgBQoHlWuJj5JBPcA Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 13:30:43 -0000 On 27/05/2014 13:52, Ted Lemon wrote: > If those ULAs happen to clash, you have to renumber at least one of them. or use NAT. I'm not saying this in order to throw fuel on an existing fire, but simply because this is the reality for many organisations in the ipv4 world, and I see little reason why it will change for ipv6. The IETF can make recommendations about whether it thinks this is a good idea or not, but it is not productive to pretend that the elephant isn't in the room. Nick From nobody Tue May 27 06:35:43 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADFF51A011D for ; Tue, 27 May 2014 06:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qiiz5GQqAc-p for ; Tue, 27 May 2014 06:35:39 -0700 (PDT) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73D3C1A0148 for ; Tue, 27 May 2014 06:35:30 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKU4SUnMfUNgM05qiezEibzIGESow+7PxL@postini.com; Tue, 27 May 2014 06:35:36 PDT Received: from MOPESMAILHTC01.eu.thmulti.com (141.11.100.10) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.342.0; Tue, 27 May 2014 15:35:18 +0200 Received: from MOPESMBX03.eu.thmulti.com ([169.254.2.100]) by MOPESMAILHTC01.eu.thmulti.com ([141.11.100.10]) with mapi id 14.03.0174.001; Tue, 27 May 2014 15:35:23 +0200 From: Wuyts Carl To: Nick Hilliard , Ted Lemon , Philip Homburg Thread-Topic: [v6ops] ULA draft revision #2 Regarding isolated networks Thread-Index: Ac943yf4qhJ96dkPR9CtEDOlyHC2QQAZCzeAAAEGaAAAABxQAAAA4z6AAACtwIAAAMLCAAAAXbqAAAGXQAAAAHTTAAAMrhbdAAMIogAAAViEAAAERMAA Date: Tue, 27 May 2014 13:35:22 +0000 Message-ID: <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.thmulti.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> In-Reply-To: <5384937A.90409@foobar.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [141.11.249.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Ba4U3h_X2dle4V0pjcJJiJJGQDI Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 13:35:41 -0000 And what's next ? Stop path MTU discovery support ? Allow Fragmentation a= gain ? Anything else ? If we start mimic IPv4 fully, we're really going the wrong way .... (my per= sonal opinion of course) Regs Carl -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Nick Hilliard Sent: dinsdag 27 mei 2014 15:31 To: Ted Lemon; Philip Homburg Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks On 27/05/2014 13:52, Ted Lemon wrote: > If those ULAs happen to clash, you have to renumber at least one of them. or use NAT. I'm not saying this in order to throw fuel on an existing fire= , but simply because this is the reality for many organisations in the ipv4 world, and I see little reason why it will change for ipv6. The IETF = can make recommendations about whether it thinks this is a good idea or not= , but it is not productive to pretend that the elephant isn't in the room. Nick _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue May 27 06:52:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5691A034E for ; Tue, 27 May 2014 06:52:04 -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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEI5-1K7yhh8 for ; Tue, 27 May 2014 06:52:02 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A8331A014C for ; Tue, 27 May 2014 06:52:01 -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.8/8.14.5) with ESMTP id s4RDpuqW032478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 27 May 2014 14:51:56 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <5384987C.8060405@foobar.org> Date: Tue, 27 May 2014 14:51:56 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Wuyts Carl , Ted Lemon , Philip Homburg References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.thmulti.com> In-Reply-To: <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.thmulti.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sB8BiOyikcFvTG7Bv7QRtiXnzzQ Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 13:52:04 -0000 On 27/05/2014 14:35, Wuyts Carl wrote: > And what's next ? Stop path MTU discovery support ? Allow > Fragmentation again ? Anything else ? > If we start mimic IPv4 fully, we're really going the wrong way .... (my > personal opinion of course) if you feel that NAT may have drawbacks which makes it a less appropriate choice than renumbering, then feel free to suggest some wording for the draft. Ignoring the existence of NAT will not make it go away. Educating people on its limitations may lessen its deployment, maybe. Nick From nobody Tue May 27 06:56:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE8B1A038E for ; Tue, 27 May 2014 06:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kP9OToI2-33J for ; Tue, 27 May 2014 06:56:41 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 024BA1A014E for ; Tue, 27 May 2014 06:56:40 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1WpHrp-0000BQC; Tue, 27 May 2014 15:56:37 +0200 Message-Id: To: v6ops WG From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> In-reply-to: Your message of "Tue, 27 May 2014 08:52:02 -0400 ." <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> Date: Tue, 27 May 2014 15:56:36 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qhvbh_AV6xagtHdkYNkL45cJTas Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 13:56:48 -0000 In your letter dated Tue, 27 May 2014 08:52:02 -0400 you wrote: >The operational situation that's problematic is the large enterprise >scenario, where you have two large enterprises with their own ULAs that >merge. If those ULAs happen to clash, you have to renumber at least >one of them. If they don't clash, you still have to deal with routing >them (although I think the split-horizon complexity objection Mikael >raised ought to be thought through carefully before being asserted as >factual, because I think it can be addressed through routing and not >naming). If you are a large entrprise, just spend the 50 euro or so (RIPE service region) it costs to get your own prefix. I assume that any large enterprise is very likely to be multi-homed anyhow. Even becoming an LIR should not even be noticable in the budget. No real reason for a large enterprise to use ULA. From nobody Tue May 27 07:00:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A531A014C for ; Tue, 27 May 2014 07:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KC_YLx87HQNO for ; Tue, 27 May 2014 07:00:02 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 198181A011D for ; Tue, 27 May 2014 07:00:02 -0700 (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 113911B8078 for ; Tue, 27 May 2014 06:59:59 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id E8D4F19005C; Tue, 27 May 2014 06:59:58 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 May 2014 06:59:53 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <5384937A.90409@foobar.org> Date: Tue, 27 May 2014 09:59:51 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <1CFC65A0-22E6-4D2B-BA01-D5F4C0E17BAC@nominum.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZLkUhHUaD9uRLUSqiBpD2I9tLIs Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:00:07 -0000 On May 27, 2014, at 9:30 AM, Nick Hilliard wrote: > or use NAT. I'm not saying this in order to throw fuel on an existing > fire, but simply because this is the reality for many organisations in = the > ipv4 world, and I see little reason why it will change for ipv6. The = IETF > can make recommendations about whether it thinks this is a good idea = or > not, but it is not productive to pretend that the elephant isn't in = the room. Right, the point is that if we provide advice on how to set up ULA = networks so that future transitions of this sort do not require NAT, = that's worth doing. Actually, for the enterprise scenario, I think the = advice should just be "get a GUA, use it like a ULA" because that = excludes the possibility of a future clash when two behemoths merge. = But it makes source address selection harder. And there was a document = a while back about informal ULA registries, IIRC, which could also = represent a good mitigation strategy if it were to happen (but I think = that's outside our scope of work). From nobody Tue May 27 07:02:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183401A038E for ; Tue, 27 May 2014 07:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roryq_zs6e9y for ; Tue, 27 May 2014 07:02:46 -0700 (PDT) Received: from na3sys009aog123.obsmtp.com (na3sys009aog123.obsmtp.com [74.125.149.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6F01A011D for ; Tue, 27 May 2014 07:02:38 -0700 (PDT) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob123.postini.com ([74.125.148.12]) with SMTP ID DSNKU4Sa+QxEnR8l2Vbl4YR5StjVcdu/m9Ro@postini.com; Tue, 27 May 2014 07:02:43 PDT Received: from MOPESMAILHTC01.eu.thmulti.com (141.11.100.10) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.342.0; Tue, 27 May 2014 15:57:26 +0200 Received: from MOPESMBX03.eu.thmulti.com ([169.254.2.100]) by MOPESMAILHTC01.eu.thmulti.com ([141.11.100.10]) with mapi id 14.03.0174.001; Tue, 27 May 2014 15:57:28 +0200 From: Wuyts Carl To: Nick Hilliard , Ted Lemon , Philip Homburg Thread-Topic: [v6ops] ULA draft revision #2 Regarding isolated networks Thread-Index: Ac943yf4qhJ96dkPR9CtEDOlyHC2QQAZCzeAAAEGaAAAABxQAAAA4z6AAACtwIAAAMLCAAAAXbqAAAGXQAAAAHTTAAAMrhbdAAMIogAAAViEAAAERMAA///j0gD//90zMA== Date: Tue, 27 May 2014 13:57:28 +0000 Message-ID: <96747494E3D74D41B20907035DB1E48D335AAB94@MOPESMBX03.eu.thmulti.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.thmulti.com> <5384987C.8060405@foobar.org> In-Reply-To: <5384987C.8060405@foobar.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [141.11.249.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/R3rS-1NKRgLRIN16PTZfSYF15dU Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:02:52 -0000 Well, lately, it seems more and more the case that NAT can solve all proble= ms, which I don't think will do. Education indeed will help and there's no magic, but dragging NAT along eac= h time is not helping either. -----Original Message----- From: Nick Hilliard [mailto:nick@foobar.org]=20 Sent: dinsdag 27 mei 2014 15:52 To: Wuyts Carl; Ted Lemon; Philip Homburg Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks On 27/05/2014 14:35, Wuyts Carl wrote: > And what's next ? Stop path MTU discovery support ? Allow=20 > Fragmentation again ? Anything else ? > If we start mimic IPv4 fully, we're really going the wrong way ....=20 > (my personal opinion of course) if you feel that NAT may have drawbacks which makes it a less appropriate c= hoice than renumbering, then feel free to suggest some wording for the draf= t. Ignoring the existence of NAT will not make it go away. Educating people o= n its limitations may lessen its deployment, maybe. Nick From nobody Tue May 27 07:08:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF0E1A0424 for ; Tue, 27 May 2014 07:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RsYKzaQH00v for ; Tue, 27 May 2014 07:08:56 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66681A03BE for ; Tue, 27 May 2014 07:08:53 -0700 (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 E20291B8078 for ; Tue, 27 May 2014 07:08:50 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id DB4C119005C; Tue, 27 May 2014 07:08:50 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 May 2014 07:08:50 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Tue, 27 May 2014 10:08:48 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> To: Philip Homburg X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1zXSzJCzyuyNYqeAtlAUJ_RQIx0 Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:08:57 -0000 On May 27, 2014, at 9:56 AM, Philip Homburg = wrote: > If you are a large entrprise, just spend the 50 euro or so (RIPE = service region) it > costs to get your own prefix. Yes, but do we tell them to do that? Do we tell them how to make it = work? Do we tell them how to make source address selection do the = right thing? ULAs have a nice feature that GUAs don't: your stack won't = choose a ULA as a source when the destination is a GUA. If they get a = GUA from RIPE, they lose that feature. From nobody Tue May 27 07:19:42 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741031A011D for ; Tue, 27 May 2014 07:19:40 -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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGvR-zTYCxjZ for ; Tue, 27 May 2014 07:19:37 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48BBF1A0158 for ; Tue, 27 May 2014 07:19:36 -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.8/8.14.5) with ESMTP id s4REJUX8032637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 27 May 2014 15:19:31 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <53849EF2.3030604@foobar.org> Date: Tue, 27 May 2014 15:19:30 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ted Lemon References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <1CFC65A0-22E6-4D2B-BA01-D5F4C0E17BAC@nominum.com> In-Reply-To: <1CFC65A0-22E6-4D2B-BA01-D5F4C0E17BAC@nominum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/iHkKcRBKv11wJ1bwGYWsrOUC96Q Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:19:40 -0000 On 27/05/2014 14:59, Ted Lemon wrote: > Right, the point is that if we provide advice on how to set up ULA > networks so that future transitions of this sort do not require NAT, > that's worth doing. sounds good to me. > Actually, for the enterprise scenario, I think the > advice should just be "get a GUA, use it like a ULA" because that > excludes the possibility of a future clash when two behemoths merge. > But it makes source address selection harder. And there was a document > a while back about informal ULA registries, IIRC, which could also > represent a good mitigation strategy if it were to happen (but I think > that's outside our scope of work). register or do not register. there is no "informal". Nick From nobody Tue May 27 07:21:57 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD801A0158 for ; Tue, 27 May 2014 07:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ei9T3yZKi29 for ; Tue, 27 May 2014 07:21:53 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE21A1A011D for ; Tue, 27 May 2014 07:21:53 -0700 (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 D414B1B8067 for ; Tue, 27 May 2014 07:21:50 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id C5E4119005C; Tue, 27 May 2014 07:21:50 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 May 2014 07:21:50 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <53849EF2.3030604@foobar.org> Date: Tue, 27 May 2014 10:21:48 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <3EB0A6D5-2C17-44B8-8EE5-DB31E7614F01@nominum.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <1CFC65A0-22E6-4D2B-BA01-D5F4C0E17BAC@nominum.com> <53849EF2.3030604@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XHS_HsM5s7XBwaUSv8wTrtR760U Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:21:55 -0000 On May 27, 2014, at 10:19 AM, Nick Hilliard wrote: > register or do not register. there is no "informal". It depends on whether you want certainty or mitigation. I don't think = we can have certainty with ULAs. From nobody Tue May 27 07:26:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C744E1A041C for ; Tue, 27 May 2014 07:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfRuhzoiUL-Y for ; Tue, 27 May 2014 07:26:27 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA091A0424 for ; Tue, 27 May 2014 07:26:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 9FFD463; Tue, 27 May 2014 16:26:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiQ9W3dYJfKl; Tue, 27 May 2014 16:26:18 +0200 (CEST) Received: from [IPv6:2a00:8640:1::5572:2ac8:dfe6:71dc] (unknown [IPv6:2a00:8640:1:0:5572:2ac8:dfe6:71dc]) by mail.sintact.nl (Postfix) with ESMTPSA id 09F8856; Tue, 27 May 2014 16:26:17 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Sander Steffann In-Reply-To: <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> Date: Tue, 27 May 2014 16:26:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9255C827-9F28-4E4E-9A2E-A678ADFACDAF@steffann.nl> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/bl-O0UBN27KS4fqFSpp6UwOMCMo Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:26:28 -0000 Hi Ted, Op 27 mei 2014, om 16:08 heeft Ted Lemon het = volgende geschreven: > On May 27, 2014, at 9:56 AM, Philip Homburg = wrote: >> If you are a large entrprise, just spend the 50 euro or so (RIPE = service region) it >> costs to get your own prefix. >=20 > Yes, but do we tell them to do that? Do we tell them how to make it = work? Do we tell them how to make source address selection do the = right thing? ULAs have a nice feature that GUAs don't: your stack won't = choose a ULA as a source when the destination is a GUA. If they get a = GUA from RIPE, they lose that feature. I know one big enterprise that uses ULA for certain networks for exactly = that reason. They have networks that are by security policy not allowed = to have any direct layer-3 connection to the outside world. All such = communication must go through layer-7 gateways/proxies. Using ULA for = such high-security-zones makes the source address selection simpler for = the devices on its border, like the proxy servers. All other networks = use the RIPE-assigned /48. Cheers, Sander From nobody Tue May 27 07:34:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0C01A041C for ; Tue, 27 May 2014 07:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-lBewTySOSW for ; Tue, 27 May 2014 07:34:43 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id DF76C1A0158 for ; Tue, 27 May 2014 07:34:42 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1WpISc-0000CGC; Tue, 27 May 2014 16:34:38 +0200 Message-Id: To: Ted Lemon From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> In-reply-to: Your message of "Tue, 27 May 2014 10:08:48 -0400 ." <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> Date: Tue, 27 May 2014 16:30:45 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2yw0cFcVDael7IfXQ-d7PZ94KAk Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:34:44 -0000 In your letter dated Tue, 27 May 2014 10:08:48 -0400 you wrote: >On May 27, 2014, at 9:56 AM, Philip Homburg wrote: >> If you are a large entrprise, just spend the 50 euro or so (RIPE service region) it >> costs to get your own prefix. > >Yes, but do we tell them to do that? Do we tell them how to make it work? Do we te >ll them how to make source address selection do the right thing? ULAs have a nice fea >ture that GUAs don't: your stack won't choose a ULA as a source when the destination i >s a GUA. If they get a GUA from RIPE, they lose that feature. At the moment, I would not advice anyone to use more than one prefix at the same time. It can be made to work, but the operational complexity is high. I didn't keep track. Are GUAs now considered out of scope for ULAs? From nobody Tue May 27 07:37:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C771A0159 for ; Tue, 27 May 2014 07:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2Lly0Ciu7Dl for ; Tue, 27 May 2014 07:37:34 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F28D51A011D for ; Tue, 27 May 2014 07:37:33 -0700 (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 EE2BB1B81BF for ; Tue, 27 May 2014 07:37:30 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id DDACC19005C; Tue, 27 May 2014 07:37:30 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 May 2014 07:37:30 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Tue, 27 May 2014 10:37:28 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> To: Philip Homburg X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/MBMtEv-DyJke0tgD2IosIFWylDw Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:37:37 -0000 On May 27, 2014, at 10:30 AM, Philip Homburg = wrote: > At the moment, I would not advice anyone to use more than one prefix = at the same > time. It can be made to work, but the operational complexity is high. ULAs give you a lot of complexity reduction for free. I tend to agree = that multiple prefixes are hard, but this is a problem we need to solve. > I didn't keep track. Are GUAs now considered out of scope for ULAs? Yes. From nobody Tue May 27 07:51:43 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49BA1A0171 for ; Tue, 27 May 2014 07:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aZs09tOcl2k for ; Tue, 27 May 2014 07:51:38 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id AAAF01A0158 for ; Tue, 27 May 2014 07:51:37 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1WpIj0-0000BNC; Tue, 27 May 2014 16:51:34 +0200 Message-Id: To: v6ops WG From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> In-reply-to: Your message of "Tue, 27 May 2014 10:37:28 -0400 ." Date: Tue, 27 May 2014 16:51:34 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wNnMXyV_VtNTR7FzJvHgbvIOtUU Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:51:42 -0000 In your letter dated Tue, 27 May 2014 10:37:28 -0400 you wrote: >> I didn't keep track. Are GUAs now considered out of scope for ULAs? > >Yes. Hmm. What RFC changed that? I looked at RFC-6724, but that still considers ULAs as a special case of global scope. (Section 3.1 "Also, note that ULAs are considered as global, not site-local, [...]") From nobody Tue May 27 08:01:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C191B1A045D for ; Tue, 27 May 2014 08:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEVTX7dIVzC2 for ; Tue, 27 May 2014 08:01:32 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B151A0446 for ; Tue, 27 May 2014 08:01:18 -0700 (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 8EAA31B8067 for ; Tue, 27 May 2014 08:01:15 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 8808419005C; Tue, 27 May 2014 08:01:15 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 May 2014 08:01:15 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Tue, 27 May 2014 11:01:13 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <3CD5F864-EF19-49B4-9103-BD134C39C842@nominum.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> To: Philip Homburg X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hI9Jc32Ew6zVMYqZVu0OgYpMlXU Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 15:01:35 -0000 On May 27, 2014, at 10:51 AM, Philip Homburg = wrote: > Hmm. What RFC changed that? I looked at RFC-6724, but that still = considers ULAs as > a special case of global scope. (Section 3.1 "Also, note that ULAs are = considered as > global, not site-local, [...]") Read section 10. I'm not sure if/where there's a clear normative = requirement that ULAs be treated as less preferable than GUAs, but they = are definitely treated that way by stacks I've used. I have a ULA = configured on my home network, and none of the IPv6-capable devices in = the home have trouble getting out to the internet. ULAs are global in scope in the sense that they are (notionally) unique = across the internet, but not in the sense that they are globally = reachable. From nobody Tue May 27 08:19:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01AF61A0428 for ; Tue, 27 May 2014 08:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dL1qUVb-ffe for ; Tue, 27 May 2014 08:19:47 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1B61A0168 for ; Tue, 27 May 2014 08:19:46 -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 s4RFJWZF017006; Tue, 27 May 2014 16:19:32 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s4RFJWZF017006 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1401203973; bh=R53/ryuSzB9uh9U737HgqwAu6rw=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=OB6g0/lpjuxxqZIVNYCEtRSgR0Y0R91bDgCSr6rn+7g7YkIfLzyVmybOWKIAMRI2G lO5jQ5gsgk0RRfxbbKK7NWBk9N7jyIDLF2qvLwOfvHtAph1/QmZTm30R+g4POXefoR HbMpGv2NuiBoblqNTn90UEmRbpwdOPFQTJ4+DAsk= 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 q4QGJW0546013678YX ret-id none; Tue, 27 May 2014 16:19:33 +0100 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s4RFJVlk024112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 May 2014 16:19:32 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_E39499A1-1813-4F66-916E-8ECE58873777" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Chown In-Reply-To: <1CFC65A0-22E6-4D2B-BA01-D5F4C0E17BAC@nominum.com> Date: Tue, 27 May 2014 16:19:31 +0100 Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <1CFC65A0-22E6-4D2B-BA01-D5F4C0E17BAC@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1878.2) X-smtpf-Report: sid=q4QGJW054601367800; tid=q4QGJW0546013678YX; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s4RFJWZF017006 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/73GGEnGwNHraGq9U3ALZgo3NOZE Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 15:19:49 -0000 --Apple-Mail=_E39499A1-1813-4F66-916E-8ECE58873777 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 27 May 2014, at 14:59, Ted Lemon wrote: > On May 27, 2014, at 9:30 AM, Nick Hilliard wrote: >> or use NAT. I'm not saying this in order to throw fuel on an = existing >> fire, but simply because this is the reality for many organisations = in the >> ipv4 world, and I see little reason why it will change for ipv6. The = IETF >> can make recommendations about whether it thinks this is a good idea = or >> not, but it is not productive to pretend that the elephant isn't in = the room. >=20 > Right, the point is that if we provide advice on how to set up ULA = networks so that future transitions of this sort do not require NAT, = that's worth doing. Actually, for the enterprise scenario, I think the = advice should just be "get a GUA, use it like a ULA" because that = excludes the possibility of a future clash when two behemoths merge. = But it makes source address selection harder. And there was a document = a while back about informal ULA registries, IIRC, which could also = represent a good mitigation strategy if it were to happen (but I think = that's outside our scope of work). The enterprise IPv6 incremental deployment text is just going up for = publication, see = http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-05= . That pretty much captures what Ted says, but also points to the draft = under discussion here. See section 2.6 in particular. Tim > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_E39499A1-1813-4F66-916E-8ECE58873777 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 27 May 2014, at 14:59, Ted Lemon = <ted.lemon@nominum.com>= wrote:

On May 27, 2014, at 9:30 AM, Nick Hilliard <nick@foobar.org> = wrote:
or use NAT.  I'm not saying = this in order to throw fuel on an existing
fire, but simply because = this is the reality for many organisations in the
ipv4 world, and I = see little reason why it will change for ipv6.  The IETF
can = make recommendations about whether it thinks this is a good idea = or
not, but it is not productive to pretend that the elephant isn't = in the room.

Right, the point is that if we provide = advice on how to set up ULA networks so that future transitions of this = sort do not require NAT, that's worth doing.   Actually, for = the enterprise scenario, I think the advice should just be "get a GUA, = use it like a ULA" because that excludes the possibility of a future = clash when two behemoths merge.   But it makes source address = selection harder.   And there was a document a while back = about informal ULA registries, IIRC, which could also represent a good = mitigation strategy if it were to happen (but I think that's outside our = scope of work).

The enterprise IPv6 = incremental deployment text is just going up for publication, = see http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-increment= al-ipv6-05.
That pretty much captures what Ted says, but = also points to the draft under discussion here.  See section 2.6 in = particular.

Tim

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

= --Apple-Mail=_E39499A1-1813-4F66-916E-8ECE58873777-- From nobody Tue May 27 08:24:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C0B1A0538 for ; Tue, 27 May 2014 08:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YOhvkHzQt_x for ; Tue, 27 May 2014 08:24:00 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD361A0463 for ; Tue, 27 May 2014 08:23:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 43C4560; Tue, 27 May 2014 17:23:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfsNzgzozXSW; Tue, 27 May 2014 17:22:57 +0200 (CEST) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTPSA id A922F56; Tue, 27 May 2014 17:22:57 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Sander Steffann In-Reply-To: Date: Tue, 27 May 2014 17:22:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <353EC670-85C3-495F-923D-55FEB561E98C@steffann.nl> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> To: Philip Homburg X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Zb_MQcgalyJPBlys5hhP7aeu1Kg Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 15:24:03 -0000 Hi Philip, > Hmm. What RFC changed that? I looked at RFC-6724, but that still = considers ULAs as > a special case of global scope. (Section 3.1 "Also, note that ULAs are = considered as > global, not site-local, [...]") They are still considered to be in the global scope. Section 3.1 of that = RFC is indeed very clear on that. They have a specific precedence and = label, but are considered to be in the global scope. Cheers, Sander From nobody Tue May 27 08:28:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2781A0428 for ; Tue, 27 May 2014 08:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Maig5iE_T70s for ; Tue, 27 May 2014 08:28:05 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967451A0137 for ; Tue, 27 May 2014 08:28:04 -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 s4RFRxb3019423; Tue, 27 May 2014 16:27:59 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s4RFRxb3019423 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1401204479; bh=5pwiz1553V9KNN86R8WTxmQRUSQ=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=bUGYAnsRTVgPuVAz53gNh/ExtfeYJ4madm7XKVOmyQRn2/KeZn/HJsnyvEYnuXDFi jTgHCp0xkvf3pGM9eNqYPQrM0SnZbPO8OD69qbyfEmMXeQiJx04aO0We/42PeBtwuG VtYqS/MDYFPUjbEeL0NzsQTr4/zgsWbDaYMYU4Gc= 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 q4QGRx0546013735S8 ret-id none; Tue, 27 May 2014 16:27:59 +0100 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s4RFRxrs025528 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 May 2014 16:27:59 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Chown In-Reply-To: <3CD5F864-EF19-49B4-9103-BD134C39C842@nominum.com> Date: Tue, 27 May 2014 16:27:59 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <3CD5F864-EF19-49B4-9103-BD134C39C842@nominum.com> <9501818D-AD68-4ACF-9FA8-3EB2C3479062@ecs.soton.ac.uk> To: Ted Lemon X-Mailer: Apple Mail (2.1878.2) X-smtpf-Report: sid=q4QGRx054601373500; tid=q4QGRx0546013735S8; 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: s4RFRxb3019423 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yZ_OyJGq4A72Y4NguyVt7KttZF8 Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 15:28:06 -0000 On 27 May 2014, at 16:01, Ted Lemon wrote: > On May 27, 2014, at 10:51 AM, Philip Homburg = wrote: >> Hmm. What RFC changed that? I looked at RFC-6724, but that still = considers ULAs as >> a special case of global scope. (Section 3.1 "Also, note that ULAs = are considered as >> global, not site-local, [...]") >=20 > Read section 10. I'm not sure if/where there's a clear normative = requirement that ULAs be treated as less preferable than GUAs, but they = are definitely treated that way by stacks I've used. I have a ULA = configured on my home network, and none of the IPv6-capable devices in = the home have trouble getting out to the internet. As you say Ted, RFC6724 observes the scope of ULAs being what it is, but = in the part Philip quotes the rest of the sentence replacing the =93=85=94= reads =93... but are handled via the prefix policy table as discussed = in Section 10.6.)=94 Any system that is 6724-compliant should prefer = globals over ULAs, unless the policy table has been modified. This issue = was discussed in some depth in homenet. > ULAs are global in scope in the sense that they are (notionally) = unique across the internet, but not in the sense that they are globally = reachable. Perhaps (probabilistically) rathr than (notionally). Tim From nobody Tue May 27 08:28:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE011A03DD for ; Tue, 27 May 2014 08:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDeJkLzjlR5k for ; Tue, 27 May 2014 08:28:14 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 331FE1A0137 for ; Tue, 27 May 2014 08:28:10 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1WpJIM-0000CSC; Tue, 27 May 2014 17:28:06 +0200 Message-Id: To: v6ops WG From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <353EC670-85C3-495F-923D-55FEB561E98C@steffann.nl> In-reply-to: Your message of "Tue, 27 May 2014 17:22:56 +0200 ." <353EC670-85C3-495F-923D-55FEB561E98C@steffann.nl> Date: Tue, 27 May 2014 17:28:05 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3V1pgz5tg7JiZDH5TGHaTQJbabg Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 15:28:18 -0000 In your letter dated Tue, 27 May 2014 17:22:56 +0200 you wrote: >Hi Philip, > >> Hmm. What RFC changed that? I looked at RFC-6724, but that still = >considers ULAs as >> a special case of global scope. (Section 3.1 "Also, note that ULAs are = >considered as >> global, not site-local, [...]") > >They are still considered to be in the global scope. Section 3.1 of that >RFC is indeed very clear on that. They have a specific precedence and >label, but are considered to be in the global scope. I guess longest prefix matching would in practice already take care of the precedence/label difference. But I noticed that longest prefix matching is only adviced. From nobody Tue May 27 11:56:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81EE91A06D1 for ; Tue, 27 May 2014 11:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b_JM5bcZkNW4 for ; Tue, 27 May 2014 11: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 E457E1A0670 for ; Tue, 27 May 2014 11:55:40 -0700 (PDT) Received: from [IPv6:2620::930:0:225:ff:fe44:af17] ([IPv6:2620:0:930:0:225:ff:fe44:af17]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s4RIomvj029808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 May 2014 11:50:49 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s4RIomvj029808 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1401216649; bh=n0tjMVCLI1suJY9pznXxhwdsjXg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=RZs/ZybpWwVSLL1nCiEayMc8W4bb9s+5cLoNmVoVlLDfDHdAW3DErGEV/BEjhKSJD 2KkwvXZ6nRzDURbJnyS5N2MEjJCf1SD4SP8/EeTWSq1P4g9TrancoIM87uG8H1+PwD 8QSbaJRrLdsy/zsoUEnSU9yI1MuLwA3Nqq9Vxick= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> Date: Tue, 27 May 2014 11:54:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 27 May 2014 11:50:49 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Hljl4AEqUGYCdOp_XWP_knJxj8U Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 18:56:02 -0000 On May 27, 2014, at 7:08 AM, Ted Lemon wrote: > On May 27, 2014, at 9:56 AM, Philip Homburg = wrote: >> If you are a large entrprise, just spend the 50 euro or so (RIPE = service region) it >> costs to get your own prefix. >=20 > Yes, but do we tell them to do that? Do we tell them how to make it = work? Do we tell them how to make source address selection do the = right thing? ULAs have a nice feature that GUAs don't: your stack won't = choose a ULA as a source when the destination is a GUA. If they get a = GUA from RIPE, they lose that feature. If they get GUA from RIPE, they don=92t need that feature, as there = aren=92t multiple source addresses to choose from. You=92re not making much sense here, Ted. Owen From nobody Tue May 27 12:05:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC1B1A06FA for ; Tue, 27 May 2014 12:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGUwfttGgeYL for ; Tue, 27 May 2014 12:05:06 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6142B1A06F5 for ; Tue, 27 May 2014 12:05:06 -0700 (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 2FF671B81C6 for ; Tue, 27 May 2014 12:05:03 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id E1F5119005C; Tue, 27 May 2014 12:05:02 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 May 2014 12:04:56 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> Date: Tue, 27 May 2014 15:04:54 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> To: Owen DeLong X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2Ngrqncvb5tUZSMdICb938rkmQc Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 19:05:07 -0000 On May 27, 2014, at 2:54 PM, Owen DeLong wrote: > If they get GUA from RIPE, they don=92t need that feature, as there = aren=92t multiple source addresses to choose from. > You=92re not making much sense here, Ted. If they can get it routed, you are correct. But we are not assuming = that they can, and even if they can, it will probably be costly. So in = practice we can expect them to use that GUA as if it were a ULA, and = then they need to use source address selection to ensure that it is only = used internally. From nobody Tue May 27 12:09:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457E71A0225 for ; Tue, 27 May 2014 12:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5Y3TSgsVOIh for ; Tue, 27 May 2014 12:09:52 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 8F03D1A06DC for ; Tue, 27 May 2014 12:09:52 -0700 (PDT) Received: from [IPv6:2620::930:0:225:ff:fe44:af17] ([IPv6:2620:0:930:0:225:ff:fe44:af17]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s4RJ7e4M030441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 May 2014 12:07:40 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s4RJ7e4M030441 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1401217661; bh=SyJ97c81/TKmUEPC20xX1WmV7Y0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=0EUfxQM7LEMWwZ0bkQ6Qwse3coOel37J3hZNTFANvWkOjqSK1SIy0Qnfp1M0Ps0c8 9GabTnMaoVmCtF9N0TMq0srlfkRRbuJRfEKqHlW5ERyxWVmoPWca85wrfjsILRsWwb qPx2LECHRNXeRqgAjlVT15lRX29hKruUfqUTqHxY= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: Date: Tue, 27 May 2014 12:11:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> To: Ted Lemon X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 27 May 2014 12:07:41 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/X27MuM7BxC_41QKUimqAc8oOeNY Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 19:09:53 -0000 On May 27, 2014, at 12:04 PM, Ted Lemon wrote: > On May 27, 2014, at 2:54 PM, Owen DeLong wrote: >> If they get GUA from RIPE, they don=92t need that feature, as there = aren=92t multiple source addresses to choose from. >> You=92re not making much sense here, Ted. >=20 > If they can get it routed, you are correct. But we are not assuming = that they can, and even if they can, it will probably be costly. So in = practice we can expect them to use that GUA as if it were a ULA, and = then they need to use source address selection to ensure that it is only = used internally. In my experience, it is quite easy and not particularly costly to get a = /48 routed. Do you have different experience? Owen AS 1734 2620:0:930::/48 routed from my home. From nobody Tue May 27 12:18:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A1C1A0668 for ; Tue, 27 May 2014 12:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQQD0rCJovAi for ; Tue, 27 May 2014 12:18:20 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B8171A020A for ; Tue, 27 May 2014 12:18:20 -0700 (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 4FD331B8078 for ; Tue, 27 May 2014 12:18:17 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 48D5B19005C; Tue, 27 May 2014 12:18:17 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 May 2014 12:18:17 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Tue, 27 May 2014 15:18:15 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> To: Owen DeLong X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2Ejtp2TzRyQ2RQbKs2v18nr6M_Y Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 19:18:21 -0000 On May 27, 2014, at 3:11 PM, Owen DeLong wrote: > In my experience, it is quite easy and not particularly costly to get = a /48 routed. Do you have different experience? I'm just a poor bastard with a home connection that now (thanks, = Comcast!) has native IPv6. If you tell me that every enterprise on the = planet can easily get a /48 routed at no cost, then indeed that's = probably the right way to go. I will defer to others with more = experience in these matters to tell me whether or not that is so; my = understanding hitherto has been that it is not. From nobody Tue May 27 12:18:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BABF01A068E; Tue, 27 May 2014 12:18:27 -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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UC0WLXWtzY-v; Tue, 27 May 2014 12:18:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B771A0693; Tue, 27 May 2014 12:18:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140527191822.27263.56530.idtracker@ietfa.amsl.com> Date: Tue, 27 May 2014 12:18:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yCRAIZXXT9I0q4wfhosW-7pk0cc Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-clatip-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 19:18:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv4 Service Continuity Prefix Author : Cameron Byrne Filename : draft-ietf-v6ops-clatip-02.txt Pages : 4 Date : 2014-05-27 Abstract: DS-Lite, defined in RFC 6333, directs IANA to reserve 192.0.0.0/29 for the B4 element. This memo directs IANA to generalize that reservation to include other cases where a non-routed IPv4 interface must be numbered as part of an IPv6 transition solution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-clatip/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-clatip-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-clatip-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 27 15:17:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CD31A07A7 for ; Tue, 27 May 2014 15:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ul1Mc29eOpty for ; Tue, 27 May 2014 15:17:16 -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 9334E1A0797 for ; Tue, 27 May 2014 15:17:16 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 9B253349473; Tue, 27 May 2014 22:17:11 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 973F7160064; Tue, 27 May 2014 22:22:20 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 682B716005B; Tue, 27 May 2014 22:22:20 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A980B16B8C6E; Wed, 28 May 2014 08:17:08 +1000 (EST) To: Philip Homburg From: Mark Andrews References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> In-reply-to: Your message of "Tue, 27 May 2014 15:56:36 +0200." Date: Wed, 28 May 2014 08:17:08 +1000 Message-Id: <20140527221708.A980B16B8C6E@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4vtiLFmiTYqDf2DWzaKaCb77I6k Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 22:17:18 -0000 In message , Philip Homburg writes: > In your letter dated Tue, 27 May 2014 08:52:02 -0400 you wrote: > >The operational situation that's problematic is the large enterprise > >scenario, where you have two large enterprises with their own ULAs that > >merge. If those ULAs happen to clash, you have to renumber at least > >one of them. If they don't clash, you still have to deal with routing > >them (although I think the split-horizon complexity objection Mikael > >raised ought to be thought through carefully before being asserted as > >factual, because I think it can be addressed through routing and not > >naming). > > If you are a large entrprise, just spend the 50 euro or so (RIPE service region) it > costs to get your own prefix. A /56 is over AUD1180 (+10% GST) annually. Thanks for playing. > I assume that any large enterprise is very likely to be multi-homed anyhow. Even > becoming an LIR should not even be noticable in the budget. > > No real reason for a large enterprise to use ULA. > > > _______________________________________________ > 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 nobody Tue May 27 15:22:27 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9814D1A07C8 for ; Tue, 27 May 2014 15:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9uCZOXdWNmn for ; Tue, 27 May 2014 15:22:24 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 023831A07A2 for ; Tue, 27 May 2014 15:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1614; q=dns/txt; s=iport; t=1401229341; x=1402438941; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DYKusDJEB9tHDZspgQR5S/f1sfLCmjyFV4gau76HI+0=; b=E3IOpPmYnF1eBdXFNUBaJ0V35aDK3VbgrMKicetNi2jVlu61u56JPFVl nF9lEDEWFJczU5ThTqdqkkDxOSt2oxThLXFpG95MkWR6l+Gnnq+ff+2Ty 3CscM8UJIV/zNqexm+urASDKfQCHKjQuDMGlc6Py0IWNaTX3VC7XeznzI s=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFACMPhVOtJV2S/2dsb2JhbABZgweBKsIcAYEHFnSCJQEBAQMBeQULAgEIGC4yJQIEDgUOiCwI1WcXjlIHgyuBFQSRTIE6hm2TJ4M4gi8 X-IronPort-AV: E=Sophos;i="4.98,922,1392163200"; d="asc'?scan'208";a="47701189" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-1.cisco.com with ESMTP; 27 May 2014 22:22:20 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s4RMMKRJ024412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 May 2014 22:22:20 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.239]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Tue, 27 May 2014 17:22:19 -0500 From: "Fred Baker (fred)" To: Ted Lemon Thread-Topic: [v6ops] ULA draft revision #2 Regarding isolated networks Thread-Index: AQHPefofKXjflEQNIUin3HFi5dt8+Q== Date: Tue, 27 May 2014 22:22:19 +0000 Message-ID: <99D0C1E7-A15F-46ED-9B40-84649AF467D0@cisco.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> In-Reply-To: <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.125] Content-Type: multipart/signed; boundary="Apple-Mail=_3AA61208-3BD1-47BE-88F0-D96BD815D4C9"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8JjagsEBZ5dbIDIDC-rA4tuQHj0 Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 22:22:25 -0000 --Apple-Mail=_3AA61208-3BD1-47BE-88F0-D96BD815D4C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 27, 2014, at 12:18 PM, Ted Lemon wrote: > On May 27, 2014, at 3:11 PM, Owen DeLong wrote: >> In my experience, it is quite easy and not particularly costly to get = a /48 routed. Do you have different experience? >=20 > I'm just a poor bastard with a home connection that now (thanks, = Comcast!) has native IPv6. If you tell me that every enterprise on the = planet can easily get a /48 routed at no cost, then indeed that's = probably the right way to go. I will defer to others with more = experience in these matters to tell me whether or not that is so; my = understanding hitherto has been that it is not. Speaking for myself, identifying every residence on a residential = network as a reasonable target for PI prefix assignment sounds like a = great reason to dramatically increase the cost to a network that = presents a PI prefix, for scaling reasons. --Apple-Mail=_3AA61208-3BD1-47BE-88F0-D96BD815D4C9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFThRAZbjEdbHIsm0MRAn0IAJ9MNH/i+sGLPj7QUHagfsS4b3GjrQCgvz4V nVX2dD9vLsXRLauyDmnlVL0= =Iijj -----END PGP SIGNATURE----- --Apple-Mail=_3AA61208-3BD1-47BE-88F0-D96BD815D4C9-- From nobody Tue May 27 15:23:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715EE1A07A4 for ; Tue, 27 May 2014 15:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HEcG_Ot_qsi for ; Tue, 27 May 2014 15:23:18 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by ietfa.amsl.com (Postfix) with ESMTP id 258AE1A07A2 for ; Tue, 27 May 2014 15:23:18 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 8DAC234942E; Tue, 27 May 2014 22:23:14 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id AFB34160064; Tue, 27 May 2014 22:28:23 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 7D72E16005B; Tue, 27 May 2014 22:28:23 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7B12716B8D59; Wed, 28 May 2014 08:23:13 +1000 (EST) To: Wuyts Carl From: Mark Andrews References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.thmulti.com> In-reply-to: Your message of "Tue, 27 May 2014 13:35:22 +0000." <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.thmulti.com> Date: Wed, 28 May 2014 08:23:13 +1000 Message-Id: <20140527222313.7B12716B8D59@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/M3xQSlvh4g8Il_GA04sFjuWNfKQ Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 22:23:19 -0000 In message <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.thmulti.com>, Wuyts Carl writes: > And what's next ? Stop path MTU discovery support ? Allow Fragmentation again ? Anything else ? > If we start mimic IPv4 fully, we're really going the wrong way .... (my personal opinion of course) Please state clearly the RFC which disallows fragmentation? Hint: There isn't one. Fragmentation is a BASIC part of IPv6. It is done in the sending host rather than in the core of the network but it is DONE!!!!! > Regs > Carl > > > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Nick Hilliard > Sent: dinsdag 27 mei 2014 15:31 > To: Ted Lemon; Philip Homburg > Cc: v6ops WG > Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks > > On 27/05/2014 13:52, Ted Lemon wrote: > > If those ULAs happen to clash, you have to renumber at least one of them. > > or use NAT. I'm not saying this in order to throw fuel on an existing fire, but simply because this is the reality fo > r many organisations in the > ipv4 world, and I see little reason why it will change for ipv6. The IETF can make recommendations about whether it t > hinks this is a good idea or not, but it is not productive to pretend that the elephant isn't in the room. > > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue May 27 15:30:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28D81A078B; Tue, 27 May 2014 15:30:38 -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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBHXSX3XojeN; Tue, 27 May 2014 15:30:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 043A91A02A2; Tue, 27 May 2014 15:30:37 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140527223037.3668.66881.idtracker@ietfa.amsl.com> Date: Tue, 27 May 2014 15:30:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/PDTH21bubxXbPyxe0-Uuz4sme8s Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (IPv4 Service Continuity Prefix) to Proposed Standard X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 22:30:39 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'IPv4 Service Continuity Prefix' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-06-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract DS-Lite, defined in RFC 6333, directs IANA to reserve 192.0.0.0/29 for the B4 element. This memo directs IANA to generalize that reservation to include other cases where a non-routed IPv4 interface must be numbered as part of an IPv6 transition solution. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-clatip/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-clatip/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue May 27 15:31:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9571A0795 for ; Tue, 27 May 2014 15:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oA6Ra9OmqYiV for ; Tue, 27 May 2014 15:31:28 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF0CA1A0796 for ; Tue, 27 May 2014 15:31:27 -0700 (PDT) Received: from mbp.local (31.66.208.web-pass.com [208.66.31.202] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s4RMVN3A029487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 May 2014 22:31:24 GMT (envelope-from joelja@bogus.com) Message-ID: <53851236.8020209@bogus.com> Date: Tue, 27 May 2014 15:31:18 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0 MIME-Version: 1.0 To: Mark Andrews , Wuyts Carl References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.thmulti.com> <20140527222313.7B12716B8D59@rock.dv.isc.org> In-Reply-To: <20140527222313.7B12716B8D59@rock.dv.isc.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VuCKSKMJMcusWKUlpsUBcXRvkXr8liNU3" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Tue, 27 May 2014 22:31:24 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/U85B9q-I-mahCXaiB4qqhfamagw Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 22:31:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VuCKSKMJMcusWKUlpsUBcXRvkXr8liNU3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 5/27/14, 3:23 PM, Mark Andrews wrote: >=20 > In message <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.thmu= lti.com>, Wuyts Carl writes: >> And what's next ? Stop path MTU discovery support ? Allow Fragmentat= ion again ? Anything else ? >> If we start mimic IPv4 fully, we're really going the wrong way .... (m= y personal opinion of course) >=20 > Please state clearly the RFC which disallows fragmentation? > Hint: There isn't one. you know he's referring to intermediate fragmentation... http://tools.ietf.org/html/rfc2460#section-5 > Fragmentation is a BASIC part of IPv6. It is done in the sending > host rather than in the core of the network but it is DONE!!!!! yes. >> Regs >> Carl >> >> >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Nick Hilliard= >> Sent: dinsdag 27 mei 2014 15:31 >> To: Ted Lemon; Philip Homburg >> Cc: v6ops WG >> Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks= >> >> On 27/05/2014 13:52, Ted Lemon wrote: >>> If those ULAs happen to clash, you have to renumber at least one of t= hem. >> >> or use NAT. I'm not saying this in order to throw fuel on an existing= fire, but simply because this is the reality fo >> r many organisations in the >> ipv4 world, and I see little reason why it will change for ipv6. The = IETF can make recommendations about whether it t >> hinks this is a good idea or not, but it is not productive to pretend = that the elephant isn't in the room. >> >> 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 --VuCKSKMJMcusWKUlpsUBcXRvkXr8liNU3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOFEjYACgkQ8AA1q7Z/VrKOJACdH35TP3o3jZ7BH8FsYvDlLe8F g3wAn3Dxl4l1lPGAv51OW3/Ht8Mnx/nS =/bYT -----END PGP SIGNATURE----- --VuCKSKMJMcusWKUlpsUBcXRvkXr8liNU3-- From nobody Tue May 27 15:37:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCB81A0503 for ; Tue, 27 May 2014 15:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nqq2TZYHP4Kl for ; Tue, 27 May 2014 15:37:48 -0700 (PDT) Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C771A078B for ; Tue, 27 May 2014 15:37:47 -0700 (PDT) Received: from [98.139.215.143] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 27 May 2014 22:37:43 -0000 Received: from [98.139.212.216] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 27 May 2014 22:37:43 -0000 Received: from [127.0.0.1] by omp1025.mail.bf1.yahoo.com with NNFMP; 27 May 2014 22:37:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 900508.70283.bm@omp1025.mail.bf1.yahoo.com Received: (qmail 5371 invoked by uid 60001); 27 May 2014 22:37:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1401230263; bh=IpL9/raHRJiEdrLQRKJqP2Phg8uizWk0xVDBx3rxhI4=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YSNnQYu9zw/oogq3860xFygQxXyfrvGBCU9n9NCrfoUTFslMerY0orlHlMxmCKlYZVI23QauF93lo3RXO7Pv2XNcTOty9DWhvzHpHoBaVyoRy5oAbRzlf49884NmW2yUFv3TSlG0fxhSicUMNU/bhLDOeTL1dGkMUNtArTIy86g= X-YMail-OSG: FOTUDKsVM1mNQ9mbKmjBhaag8TucygRvCTKfytvgbuIWygy LHmUaZWlTTsZUow4aywIL1X8OsENIGjC.EHbRbcjNCrya3b8guQmvXVDPf_h G7cVJwCTFcuv_Hdcrc_Gwc1b.TyeXZeKxdBfaaNzY0VFlQdiHRrS81Kwk.ae uVVlY7_rTe3JKIkc5qjnCST.R7AKORipnanXdA7BJ595N_dS5kn5RthrCPfa zaTuGRlRAats2OD9jSB5AHInKTq9DMZKeyydkX1aNbGXChGGyknWk9h9KVfA aPTQKZZxn26PbKiSGpAnOcZt1Ifmoy47_X7WUk0wAKgvm.rxxYqVMXdVYWNh UgWaldXPkZXwzJWlI7fMYH_JcXNhI7a6ve.W06BPseoHU4HJaB6.7nMfHR7C Lmwfy6lrDtDy1ezAEBP5uAUZJrynnWioK_g4MqT6vn5oOExdhYL6pUwKQhWc ESrgwNgn8cZK3tQqzULzn8eivPUk2eKVNolvdortbdm3gnF81x.c3inpEeqX ltY5WvUj2uibh2ikG4Nh9bK2P24D8JHeaGAjLAHa4qhw9h5KsxnxHIw-- Received: from [150.101.221.237] by web162206.mail.bf1.yahoo.com via HTTP; Tue, 27 May 2014 15:37:43 PDT X-Rocket-MIMEInfo: 002.001, SGkgQnJpYW4sCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20.Cj4gVG86IE1hcmsgWlpaIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1Pgo.IENjOiBMaXViaW5nIChMZW8pIDxsZW8ubGl1YmluZ0BodWF3ZWkuY29tPjsgdjZvcHMgV0cgPHY2b3BzQGlldGYub3JnPjsgInY2b3BzLWNoYWlyc0B0b29scy5pZXRmLm9yZyIgPHY2b3BzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4KPiBTZW50OiBUdWUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com> <5383C2CF.6040205@gmail.com> Message-ID: <1401230263.69077.YahooMailNeo@web162206.mail.bf1.yahoo.com> Date: Tue, 27 May 2014 15:37:43 -0700 (PDT) From: Mark ZZZ Smith To: Brian E Carpenter In-Reply-To: <5383C2CF.6040205@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_uDpcdpYG5EgG_gojE2fr53UEZI Cc: v6ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 22:37:48 -0000 Hi Brian,=0A=0A=0A----- Original Message -----=0A> From: Brian E Carpenter = =0A> To: Mark ZZZ Smith =0A> Cc: Liubing (Leo) ; v6ops WG ; "v6ops-chairs@tools.ietf.org" =0A> Sent:= Tuesday, 27 May 2014 8:40 AM=0A> Subject: Re: [v6ops] ULA draft revision #= 2 Regarding isolated networks=0A> =0A> Mark,=0A> =0A> =0A> On 27/05/2014 09= :57, Mark ZZZ Smith wrote:=0A> ...=0A>>> - "Temporarily isolated" or "Fore= ver isolated". In =0A> general, =0A>>> ULAs fit both cases. Whatever it is= temporarily or forever, when =0A> administrators =0A>>> need some prefixe= s to be on-demand and free to use, ULAs are good =0A> choice. =0A>>> Howev= er, for the temporarily isolated cases, the administrator needs to =0A> con= sider =0A>>> once it gets to connected, the hosts might need to be renumbe= red; or =0A> NAT might =0A>>> be involved if renumbering is not acceptable= . If renumbering or NAT for =0A> some =0A>>> reason is considered as heavy= burden, then the administrators need to =0A> carefully =0A>>> consider th= e adoption of ULAs.=0A>>> =A0 =0A>> =0A>> This paragraph seems to show a f= undamental misunderstanding of IPv6's =0A> multi-addressing capabilities. I= Pv6 supports multiple concurrent addresses (from =0A> different prefixes), = and can learn new ones or deprecate old ones over time. =0A> Attachment to = a new network doesn't require renumbering, it requires =0A> propagating new= prefixes for the hosts to use in addition to their existing =0A> ones. Pri= marily RFC6724 address selection will help the hosts choose the right =0A> = addresses to use as source and destinations when they have multiple address= es.=0A> =0A> I didn't read it that way. Of course an IPv6 network runs well= with=0A> multiple prefixes, which is why overlapped renumbering is possibl= e.=0A>=A0=0A=0AI think there are a number of reasons I read it that way.=0A= =0AFirstly, to me, the word 'renumber' reads as 'replace the numbers', so r= enumbering a network involves just that - removing the old numbers and addi= ng new ones. The suggestion of using NAT has been in IPv4 the alternative t= o 'replacing the numbers', so suggesting that for IPv6 seemed to further su= pport the misunderstanding of IPv6's ability to support multiple concurrent= addresses/prefixes/spaces.=0A=0AThe other reason is that I've actually see= n a residential CPE try to swap between global addresses and ULAs. I deal w= ith a number of residential IPv6 CPE vendors in around 2009, and one of the= m had attempted to support ULAs, but had not done a good job of it. When th= e global prefix went away because the WAN link failed, the CPE would try to= both flush the global prefix by setting a 0 valid liftime (or similar, I c= an't quite recall) and replace it with a ULA in the RAs on the LAN side. Wh= en the WAN link came back, it tried to do the opposite. When I provided fee= dback to this vendor on this issue and others related to their IPv6 impleme= ntation, they just ignored it, unlike the other CPE vendors I was dealing w= ith.=0A=0A=0ARegards,=0AMark.=0A=0A=0A=0A=0A=0A> As Fred Baker once pointed= out, the real problem is therefore=0A> *numbering* a network (i.e. adding = a new prefix, regardless of=0A> whether there are zero or more existing pre= fixes). The text needs=0A> to be clear about that, for sure.=0A> =0A> =A0 = =A0 Brian=0A> From nobody Tue May 27 15:41:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F34A1A078B for ; Tue, 27 May 2014 15:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6FLJp0BmH2E for ; Tue, 27 May 2014 15:41:18 -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 48A531A0503 for ; Tue, 27 May 2014 15:41:18 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id D078F3493AF; Tue, 27 May 2014 22:41:11 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D9307160064; Tue, 27 May 2014 22:46:20 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 7686E16005B; Tue, 27 May 2014 22:46:20 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 6D59B16B9108; Wed, 28 May 2014 08:41:10 +1000 (EST) To: joel jaeggli From: Mark Andrews References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.thmulti.com> <20140527222313.7B12716B8D59@rock.dv.isc.org> <53851236.8020209@bogus.com> In-reply-to: Your message of "Tue, 27 May 2014 15:31:18 -0700." <53851236.8020209@bogus.com> Date: Wed, 28 May 2014 08:41:10 +1000 Message-Id: <20140527224110.6D59B16B9108@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ewnGaPEetyK77W5-WoNulA-0rW8 Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 22:41:20 -0000 In message <53851236.8020209@bogus.com>, joel jaeggli writes: > > On 5/27/14, 3:23 PM, Mark Andrews wrote: > >=20 > > In message <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.thmu= > lti.com>, Wuyts Carl writes: > >> And what's next ? Stop path MTU discovery support ? Allow Fragmentat= > ion again ? Anything else ? > >> If we start mimic IPv4 fully, we're really going the wrong way .... (m= > y personal opinion of course) > >=20 > > Please state clearly the RFC which disallows fragmentation? > > Hint: There isn't one. > > you know he's referring to intermediate fragmentation... > > http://tools.ietf.org/html/rfc2460#section-5 Except it isn't clear that that is what he is referring to. I've seen too many people assume that fragmentation no longer exists, period. "Allow router to fragment again" would be much clearer. As for MTU discovery support I really wish we could get POSIXs to pick up the Advanced Socket API as it is the part with the fragmention controls in it which are needed by nameservers. > > Fragmentation is a BASIC part of IPv6. It is done in the sending > > host rather than in the core of the network but it is DONE!!!!! > > yes. > > >> Regs > >> Carl > >> > >> > >> -----Original Message----- > >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Nick Hilliard= > > >> Sent: dinsdag 27 mei 2014 15:31 > >> To: Ted Lemon; Philip Homburg > >> Cc: v6ops WG > >> Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks= > > >> > >> On 27/05/2014 13:52, Ted Lemon wrote: > >>> If those ULAs happen to clash, you have to renumber at least one of t= > hem. > >> > >> or use NAT. I'm not saying this in order to throw fuel on an existing= > fire, but simply because this is the reality fo > >> r many organisations in the > >> ipv4 world, and I see little reason why it will change for ipv6. The = > IETF can make recommendations about whether it t > >> hinks this is a good idea or not, but it is not productive to pretend = > that the elephant isn't in the room. > >> > >> 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 > > > > --VuCKSKMJMcusWKUlpsUBcXRvkXr8liNU3 > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: OpenPGP digital signature > Content-Disposition: attachment; filename="signature.asc" > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlOFEjYACgkQ8AA1q7Z/VrKOJACdH35TP3o3jZ7BH8FsYvDlLe8F > g3wAn3Dxl4l1lPGAv51OW3/Ht8Mnx/nS > =/bYT > -----END PGP SIGNATURE----- > > --VuCKSKMJMcusWKUlpsUBcXRvkXr8liNU3-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue May 27 19:32:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488C01A02F3 for ; Tue, 27 May 2014 19:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjvz1OkvfT7H for ; Tue, 27 May 2014 19:32:36 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C75591A02EB for ; Tue, 27 May 2014 19:32:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WpTfI-0004By-NE; Wed, 28 May 2014 02:32:29 +0000 Date: Wed, 28 May 2014 11:32:37 +0900 Message-ID: From: Randy Bush To: Nick Hilliard In-Reply-To: <5384937A.90409@foobar.org> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/99Q7V4JO-DotEfQxcQPtKhD6s2s Cc: V6 Ops List Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 02:32:37 -0000 >> If those ULAs happen to clash, you have to renumber at least one of >> them. > > or use NAT. I'm not saying this in order to throw fuel on an existing > fire, but simply because this is the reality for many organisations in > the ipv4 world, and I see little reason why it will change for ipv6. > The IETF can make recommendations about whether it thinks this is a > good idea or not, but it is not productive to pretend that the > elephant isn't in the room. so, bottom line here is, in its inimitable fashion, the ietf will push ULA and get NAT. what a win! randy From nobody Tue May 27 19:33:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2691A02E9 for ; Tue, 27 May 2014 19:33:42 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeqMLvQlSHHJ for ; Tue, 27 May 2014 19:33:41 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41EE11A02D7 for ; Tue, 27 May 2014 19:33:41 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id rd3so10264675pab.1 for ; Tue, 27 May 2014 19:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RZP3527fDpuMa44VbAWDejkPjLeqNBvthoWcQpdBqmc=; b=PbaKNK3t6gQNnqGibTys7gdWU7DVBFDS2L0HlFb0xZ/++ui7ftqloAzKeVh1tla0sJ rA1uZi6KxDBmKmW5NoE9rUFy9GM3O1La3SyIk/Qbwfs6/M0TNesJ1UMJo/ljqAklopYO Hksld/msggaXBXOsnv6cNQyXEw0ah+h0KLUa+zJoPmNeCj1a/L6jDtT5QZ6wjRvFwPZ1 Va5sZCzKvx5TH9bSe0ZFVbJp4C0kIhtu5RrMxRitbM8+o+T2r/B63bzQEWXWGIEmzFZ1 QBV/ZkLRkcs8qBAcWoaloJrA0EY8jYAi2/66eZmjN23Fs1prcNzRscHHfvQw6Ki+7NH2 a23w== X-Received: by 10.66.145.233 with SMTP id sx9mr18392367pab.151.1401244417980; Tue, 27 May 2014 19:33:37 -0700 (PDT) Received: from [192.168.178.23] (178.200.69.111.dynamic.snap.net.nz. [111.69.200.178]) by mx.google.com with ESMTPSA id io6sm81326867pac.44.2014.05.27.19.33.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 19:33:37 -0700 (PDT) Message-ID: <53854B03.8040702@gmail.com> Date: Wed, 28 May 2014 14:33:39 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark ZZZ Smith References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com> <5383C2CF.6040205@gmail.com> <1401230263.69077.YahooMailNeo@web162206.mail.bf1.yahoo.com> In-Reply-To: <1401230263.69077.YahooMailNeo@web162206.mail.bf1.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4RUW4KQ3XU-myIMDw0JNrZy8dc8 Cc: v6ops WG Subject: [v6ops] (re)numbering [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 02:33:43 -0000 Hi Mark, On 28/05/2014 10:37, Mark ZZZ Smith wrote: > Hi Brian, > > > ----- Original Message ----- >> From: Brian E Carpenter >> To: Mark ZZZ Smith >> Cc: Liubing (Leo) ; v6ops WG ; "v6ops-chairs@tools.ietf.org" >> Sent: Tuesday, 27 May 2014 8:40 AM >> Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks >> >> Mark, >> >> >> On 27/05/2014 09:57, Mark ZZZ Smith wrote: >> ... >>>> - "Temporarily isolated" or "Forever isolated". In >> general, >>>> ULAs fit both cases. Whatever it is temporarily or forever, when >> administrators >>>> need some prefixes to be on-demand and free to use, ULAs are good >> choice. >>>> However, for the temporarily isolated cases, the administrator needs to >> consider >>>> once it gets to connected, the hosts might need to be renumbered; or >> NAT might >>>> be involved if renumbering is not acceptable. If renumbering or NAT for >> some >>>> reason is considered as heavy burden, then the administrators need to >> carefully >>>> consider the adoption of ULAs. >>>> >>> This paragraph seems to show a fundamental misunderstanding of IPv6's >> multi-addressing capabilities. IPv6 supports multiple concurrent addresses (from >> different prefixes), and can learn new ones or deprecate old ones over time. >> Attachment to a new network doesn't require renumbering, it requires >> propagating new prefixes for the hosts to use in addition to their existing >> ones. Primarily RFC6724 address selection will help the hosts choose the right >> addresses to use as source and destinations when they have multiple addresses. >> >> I didn't read it that way. Of course an IPv6 network runs well with >> multiple prefixes, which is why overlapped renumbering is possible. >> > > I think there are a number of reasons I read it that way. > > Firstly, to me, the word 'renumber' reads as 'replace the numbers', so renumbering a network involves just that - removing the old numbers and adding new ones. The suggestion of using NAT has been in IPv4 the alternative to 'replacing the numbers', so suggesting that for IPv6 seemed to further support the misunderstanding of IPv6's ability to support multiple concurrent addresses/prefixes/spaces. Whereas in RFC 4192 it means exactly the opposite: adding new numbers and then removing the old ones. That really is a change in thinking for IPv6 and of course you are right - multi-addressing is not understood in the industry. > The other reason is that I've actually seen a residential CPE try to swap between global addresses and ULAs. I deal with a number of residential IPv6 CPE vendors in around 2009, and one of them had attempted to support ULAs, but had not done a good job of it. When the global prefix went away because the WAN link failed, the CPE would try to both flush the global prefix by setting a 0 valid liftime (or similar, I can't quite recall) and replace it with a ULA in the RAs on the LAN side. When the WAN link came back, it tried to do the opposite. When I provided feedback to this vendor on this issue and others related to their IPv6 implementation, they just ignored it, unlike the other CPE vendors I was dealing with. That's horrible. It doesn't conform to RFC 7084 either, which clearly states that "prefix(es) (and ULA prefix if configured...)" must be advertised. Brian > Regards, > Mark. > > > > > >> As Fred Baker once pointed out, the real problem is therefore >> *numbering* a network (i.e. adding a new prefix, regardless of >> whether there are zero or more existing prefixes). The text needs >> to be clear about that, for sure. >> >> Brian >> > . > From nobody Tue May 27 19:48:42 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36DFD1A02E9 for ; Tue, 27 May 2014 19:48:42 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAxQbLf9soPE for ; Tue, 27 May 2014 19:48:41 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FD761A02D9 for ; Tue, 27 May 2014 19:48:41 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rp16so10256387pbb.6 for ; Tue, 27 May 2014 19:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hCbdQyLpVQs6jHb9wCC7LLsyKbY4bqEIyMhaJKuKVTo=; b=O87lPlxHd7Y673YLXSdHlmy0QcuQmFM5l+bfIqjN3ATjHC5yTQu+JR6rU+FzaoN+xR Q2p8qKxpCaQ1FmqmOUd/crIzyy9HNs3XmO/CmLYoeXO+030Ty62HIp4bfIQMYZVdjbnt IlggaW0AVe+0hl829wVR6zLtSIyIFy9FaYmo3CVcOUTTfPzX80ThLoAfUcAOkXhI4cSk AHquvH7dz3py8EY4rYKajoMtm+umT1a4bg/qWyEo83DVawfua/hxqiMrC/MxxCbCivxX csyYU65xYnqNtgIQGl913dWXxRXT7yveYH7kLeJFwImWgmJgjWCTwn3BC9PZUv5OnimU hBAw== X-Received: by 10.66.164.201 with SMTP id ys9mr42081219pab.40.1401245317783; Tue, 27 May 2014 19:48:37 -0700 (PDT) Received: from [192.168.178.23] (178.200.69.111.dynamic.snap.net.nz. [111.69.200.178]) by mx.google.com with ESMTPSA id ia2sm11407474pbb.32.2014.05.27.19.48.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 19:48:37 -0700 (PDT) Message-ID: <53854E87.9020500@gmail.com> Date: Wed, 28 May 2014 14:48:39 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sander Steffann References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <9255C827-9F28-4E4E-9A2E-A678ADFACDAF@steffann.nl> In-Reply-To: <9255C827-9F28-4E4E-9A2E-A678ADFACDAF@steffann.nl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Fuf0nMm0tPcnZj6ZCAUb4TMN0nw Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 02:48:42 -0000 On 28/05/2014 02:26, Sander Steffann wrote: > Hi Ted, > > Op 27 mei 2014, om 16:08 heeft Ted Lemon het volgende geschreven: > >> On May 27, 2014, at 9:56 AM, Philip Homburg wrote: >>> If you are a large entrprise, just spend the 50 euro or so (RIPE service region) it >>> costs to get your own prefix. >> Yes, but do we tell them to do that? Do we tell them how to make it work? Do we tell them how to make source address selection do the right thing? ULAs have a nice feature that GUAs don't: your stack won't choose a ULA as a source when the destination is a GUA. If they get a GUA from RIPE, they lose that feature. > > I know one big enterprise that uses ULA for certain networks for exactly that reason. They have networks that are by security policy not allowed to have any direct layer-3 connection to the outside world. All such communication must go through layer-7 gateways/proxies. Using ULA for such high-security-zones makes the source address selection simpler for the devices on its border, like the proxy servers. All other networks use the RIPE-assigned /48. Exactly. This was always one of the expected use cases for ULAs. Some people think it's a bad idea, but some corporate security policies will prefer this, and it isn't for the IETF ivory tower to tell them not to. The nature of ULAs makes it easier to talk them out of NAT, though, which is absolutely not the case for RFC 1918 addresses. (If we say anything about NATs in this draft, it should be to say that since ULAs are guaranteed* not to clash, and can co-exist with routeable GUAs, NAT is always unnecessary.) *i.e., guaranteed to very high probability if correctly generated. Brian From nobody Tue May 27 20:00:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FFC1A02FC for ; Tue, 27 May 2014 20:00:04 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mMrFiGSCutP for ; Tue, 27 May 2014 20:00:02 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 612CA1A02E9 for ; Tue, 27 May 2014 20:00:02 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id rd3so10213980pab.15 for ; Tue, 27 May 2014 19:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3gHyB1E5xzbV9siAnBBxt4pXZc3oHm7finXTTY0sp4M=; b=rR83LH3w3ZX37MTqBmZfgkRtmFZfi0vRcFqnRcVdZ2lJJyAliEXrREPWlDuTlYtJYQ ue2RjfsOUa6L1r31/wOV6qOsRECwRfMQng0yNGqTurfs8HfQ3TWIuM+F8S9Fa+fcHz4i RYmDLF6KfdS/FXCte34L7KkB5NoYfGXqYLAX2IvhHf8Cmcv9jarxRCqodgD1ep0S3iah bJ3peDLJ6Gb3EihQJ/FniFHKjAT1vkwtvOk5+TzsZOisIzcoYAeJxxF2ZLdpzb4tnNDX 3z8CXXahhJ/mKDD0RjDBe01uJd6l0oA2JQp5b0wpg4F+AT0u7BOir2UebXUFqpYMiIRK bpCg== X-Received: by 10.66.146.199 with SMTP id te7mr42229523pab.106.1401245999088; Tue, 27 May 2014 19:59:59 -0700 (PDT) Received: from [192.168.178.23] (178.200.69.111.dynamic.snap.net.nz. [111.69.200.178]) by mx.google.com with ESMTPSA id be7sm81676432pad.9.2014.05.27.19.59.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 19:59:58 -0700 (PDT) Message-ID: <53855130.8040105@gmail.com> Date: Wed, 28 May 2014 15:00:00 +1200 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: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> In-Reply-To: <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/W1HwIHkKM4ftQHBY8pvM6QP1nlw Cc: Philip Homburg , v6ops WG Subject: [v6ops] Routing /48s [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 03:00:04 -0000 On 28/05/2014 07:18, Ted Lemon wrote: > On May 27, 2014, at 3:11 PM, Owen DeLong wrote: >> In my experience, it is quite easy and not particularly costly to get a /48 routed. Do you have different experience? > > I'm just a poor bastard with a home connection that now (thanks, Comcast!) has native IPv6. If you tell me that every enterprise on the planet can easily get a /48 routed at no cost, then indeed that's probably the right way to go. I will defer to others with more experience in these matters to tell me whether or not that is so; my understanding hitherto has been that it is not. Let's assume a paltry 5 billion homenets, each with a routed /48. Well, today BGP-4 has 17687 entries for IPv6, according to http://bgp.potaroo.net/v6/as2.0/index.html It will be interesting when that number changes to 5000000000. Somehow I doubt this will happen. Quite how far we go in that direction is an interesting question. Brian From nobody Tue May 27 20:04:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5642B1A02FC for ; Tue, 27 May 2014 20:04:18 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMzomgvla9Fi for ; Tue, 27 May 2014 20:04:17 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0653C1A02E9 for ; Tue, 27 May 2014 20:04:16 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id ld10so10269626pab.3 for ; Tue, 27 May 2014 20:04:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0YrIIzgQv5bcfwUvRVFqmSJ+JvRFAAN6sZzfWtWMoPg=; b=WiMzxOKmG0EMKtquTqTPBjcmkPJhoNRNUo99Ncuy9DUCuSvCsiK5KIdiqxW8+evgE/ 2TZnRgwhkVqvAJo39ldKdje6d5uqxl2Y3CDGoLO7l2pEFGgCk1k0Lb+dmmsSR9W2zcNT EPZgyjMaS9RakMLhrORyFpVRMbGMV6MK2xTmbbREGwm2fii4/XJ+o0KvpQlwsIsIlbLt sShm/Qpn74XfwPK9LAOtHy6MRKOczxDrteMsss+aDRoxqqeKAKgMR7A9lE+0drU5sJty pP80zv9IUkT+3Oy2GpM4jHY1dV/CfxMYoEZ9mUYwpl2F3kw4shqtZ7u+3nuvgVG0UZYj exMA== X-Received: by 10.68.106.130 with SMTP id gu2mr41401900pbb.59.1401246253693; Tue, 27 May 2014 20:04:13 -0700 (PDT) Received: from [192.168.178.23] (178.200.69.111.dynamic.snap.net.nz. [111.69.200.178]) by mx.google.com with ESMTPSA id ak1sm25652244pbc.58.2014.05.27.20.04.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 20:04:13 -0700 (PDT) Message-ID: <5385522F.40305@gmail.com> Date: Wed, 28 May 2014 15:04:15 +1200 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: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.thmulti.com> <20140527222313.7B12716B8D59@rock.dv.isc.org> <53851236.8020209@bogus.com> In-Reply-To: <53851236.8020209@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LBlVJ6nPVwBiCnKYP5WDhVBGY_Y Cc: Philip Homburg , v6ops WG Subject: [v6ops] Fragments [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 03:04:18 -0000 On 28/05/2014 10:31, joel jaeggli wrote: > On 5/27/14, 3:23 PM, Mark Andrews wrote: >> In message <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.thmulti.com>, Wuyts Carl writes: >>> And what's next ? Stop path MTU discovery support ? Allow Fragmentation again ? Anything else ? >>> If we start mimic IPv4 fully, we're really going the wrong way .... (my personal opinion of course) >> Please state clearly the RFC which disallows fragmentation? >> Hint: There isn't one. > > you know he's referring to intermediate fragmentation... > > http://tools.ietf.org/html/rfc2460#section-5 > >> Fragmentation is a BASIC part of IPv6. It is done in the sending >> host rather than in the core of the network but it is DONE!!!!! > > yes. But see http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop for a dose of reality. Brian > >>> Regs >>> Carl >>> >>> >>> -----Original Message----- >>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Nick Hilliard >>> Sent: dinsdag 27 mei 2014 15:31 >>> To: Ted Lemon; Philip Homburg >>> Cc: v6ops WG >>> Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks >>> >>> On 27/05/2014 13:52, Ted Lemon wrote: >>>> If those ULAs happen to clash, you have to renumber at least one of them. >>> or use NAT. I'm not saying this in order to throw fuel on an existing fire, but simply because this is the reality fo >>> r many organisations in the >>> ipv4 world, and I see little reason why it will change for ipv6. The IETF can make recommendations about whether it t >>> hinks this is a good idea or not, but it is not productive to pretend that the elephant isn't in the room. >>> >>> 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 > > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue May 27 20:11:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EE91A02EF for ; Tue, 27 May 2014 20:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkYURUcOM1gJ for ; Tue, 27 May 2014 20:11:47 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C25B1A02E9 for ; Tue, 27 May 2014 20:11:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WpUHF-0004Kv-RF; Wed, 28 May 2014 03:11:42 +0000 Date: Wed, 28 May 2014 12:11:51 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <53854E87.9020500@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <9255C827-9F28-4E4E-9A2E-A678ADFACDAF@steffann.nl> <53854E87.9020500@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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/e5zYTfqQmRLAiPq-oLWfr67jJ-o Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 03:11:48 -0000 > The nature of ULAs makes it easier to talk them out of NAT, though, > which is absolutely not the case for RFC 1918 addresses. (If we say > anything about NATs in this draft, it should be to say that since > ULAs are guaranteed* not to clash, and can co-exist with routeable > GUAs, NAT is always unnecessary.) > > *i.e., guaranteed to very high probability if correctly generated. can we return to the real world? you have seen the distribution of the ULAs that were leaked. wanna guess at the ones that were not leaked? do not design specs that work only when standing on your left foot and holding your right ear. design them to work when chaos reigns and the rack and stack folk are working at three in the morning. randy From nobody Tue May 27 20:12:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556661A02EF for ; Tue, 27 May 2014 20:12:52 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjwLzEpr505v for ; Tue, 27 May 2014 20:12:50 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3D101A02E9 for ; Tue, 27 May 2014 20:12:50 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id uq10so1924751igb.8 for ; Tue, 27 May 2014 20:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dIRWRckEe9UZNBG9wWDHInzSJ+PlS4QajF2GGlBOc7k=; b=CLhGZhy7/MOXBaXhB2JGwEeKWa2dSvUt34BH5vAMUMXCQvUZM5O9UwZQQB/9cQwWe7 CT7bfrnQpTqGq+rgDfznZZ1tGXMlucQYEW92IZZfEzdRsJDX7BdH98pB98pMMXPS3mwN NzETC6gSpUuaQJ4gAalMnXL2GJ+TCaU+KAV6RkGDi0l7R5vVJudVE9LwO1I74KuoYGbt xyOR+CMvr7CJ6EWtcTQKP+0tcGRsRt5ucjksurWfuPf6QgLDQ6t3xVZSW3FC9C/nYuJ2 +83jy2S+KOC3/Fi/po2GNtIG1FxB7c0vNGwm0G8zx9xqR5rOOdgKdgJdmnMk79oUmmVw 7UlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=dIRWRckEe9UZNBG9wWDHInzSJ+PlS4QajF2GGlBOc7k=; b=l7M/iCOOMPc6ycAq97a2yO1yoSqjI0d3y3nL3i5vmJXShzrEKsMDZCeIwJNWxaU8K5 JRO1H2f28epssoTHxU1YGkt0sqXy9FrNIBvuddzqU+JK8NdTl9Zb6puiI9t3DY5imRBh cVqHH3ziMXB6Y6SIkT34ZKenNx3KnaPxvouZY5m1iD/ziKQ4bJTtAE1x4GTMMn18dt8U ozot7e3s01jtxKWpPSoI/YWAFeUE4pcigGTXbIpWH+jh6iFsUxnb2yBHMl+8IbsaQart Tat9ADc1YFLg3B7EQZFlRbcSauLKa9aL99NQZeHoyGzELg5oiY3PLFHJQW1Pmirmmy2E O+Hw== X-Gm-Message-State: ALoCoQlgrD6NiQLQwpuIJ2s/6texzmt+EZ+1YXJd0/UIDtyQEtvd8UiCgDeO6sNCtiQ4vpXeNbME X-Received: by 10.50.153.49 with SMTP id vd17mr39715756igb.40.1401246767205; Tue, 27 May 2014 20:12:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.203 with HTTP; Tue, 27 May 2014 20:12:27 -0700 (PDT) In-Reply-To: <53855130.8040105@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> <53855130.8040105@gmail.com> From: Lorenzo Colitti Date: Wed, 28 May 2014 12:12:27 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=089e014954becd785004fa6d2fca Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/zfEhYIyxd_pnKoPUOhXp7md8qbw Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] Routing /48s [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 03:12:52 -0000 --089e014954becd785004fa6d2fca Content-Type: text/plain; charset=UTF-8 On Wed, May 28, 2014 at 12:00 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Let's assume a paltry 5 billion homenets, each with a routed /48. > > Well, today BGP-4 has 17687 entries for IPv6, according to > http://bgp.potaroo.net/v6/as2.0/index.html > It will be interesting when that number changes to 5000000000. > > Somehow I doubt this will happen. Quite how far we go in that > direction is an interesting question. > You don't need ULA to solve this. homenet is solving this problem using source+destination routing. --089e014954becd785004fa6d2fca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, May 28, 2014 at 12:00 PM, Brian E Carpenter <brian.e.carpent= er@gmail.com> wrote:
Let's assume a paltry 5 billion homenets= , each with a routed /48.

Well, today BGP-4 has 17687 entries for IPv6, according to
ht= tp://bgp.potaroo.net/v6/as2.0/index.html
It will be interesting when that number changes to 5000000000.

Somehow I doubt this will happen. Quite how far we go in that
direction is an interesting question.

Y= ou don't need ULA to solve this. homenet is solving this problem using = source+destination routing.=C2=A0
--089e014954becd785004fa6d2fca-- From nobody Tue May 27 20:13:42 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534421A02EF for ; Tue, 27 May 2014 20:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNmH2yO38G45 for ; Tue, 27 May 2014 20:13:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A67D51A02E9 for ; Tue, 27 May 2014 20:13:36 -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.7-GA FastPath queued) with ESMTP id BEP61400; Wed, 28 May 2014 03:13:31 +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.3.158.1; Wed, 28 May 2014 04:13:03 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 May 2014 04:13:26 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Wed, 28 May 2014 11:13:23 +0800 From: "Liubing (Leo)" To: Ted Lemon , Philip Homburg Thread-Topic: [v6ops] ULA draft revision #2 Regarding isolated networks Thread-Index: Ac943yf4qhJ96dkPR9CtEDOlyHC2QQAMeJCAAAEGaQAAABxQAAAA4z6AAACtv4AAAMLCAAAAXbuAABGuc9D//4LtAIAAzDrt//+xewCAAJhKW///fSkA//6mNvA= Date: Wed, 28 May 2014 03:13:22 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7268@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> In-Reply-To: <9DB71B37-999E-4F7F-A7DA-6B243574E818@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.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/aRnZgbvsN2vzuxi3ZPfBh8vm8Ho Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 03:13:39 -0000 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ted Lemon > Sent: Tuesday, May 27, 2014 10:09 PM > To: Philip Homburg > Cc: v6ops WG > Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks >=20 > On May 27, 2014, at 9:56 AM, Philip Homburg > wrote: > > If you are a large entrprise, just spend the 50 euro or so (RIPE > > service region) it costs to get your own prefix. >=20 > Yes, but do we tell them to do that? Do we tell them how to make it wor= k? > Do we tell them how to make source address selection do the right thing? > ULAs have a nice feature that GUAs don't: your stack won't choose a ULA a= s > a source when the destination is a GUA. If they get a GUA from RIPE, th= ey > lose that feature. [Bing] This is a very good point. In current draft, we proposed to use ULA+= GUA for separated local and global communication, and pointed out the addre= ss selection issue. But we didn't make an explicit comparison that "ULA+GUA= " prefers "GUA1+GUA2" because of the address selection policy. We'll add some description of it. Thanks Ted for pointing it out. Regards, Bing =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue May 27 21:25:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C761A02D2 for ; Tue, 27 May 2014 21:25:02 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lR22OCO5JpXw for ; Tue, 27 May 2014 21:25:00 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980FF1A029E for ; Tue, 27 May 2014 21:25:00 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id rr13so10498486pbb.11 for ; Tue, 27 May 2014 21:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8z+XBo0WNIXp/0OUjWmhSwuNz7BGz4pxDa5ZOsfXcy8=; b=DsmEgNpZuEnXio04elVUs7LJ6Z/D5BNObt/CrNx8ksVecGCjefam/tgdujrp9jv181 6vMMA31IZlj+3rhlTxBaZqN9AHKWI25pUnvTRrixWs49QGBs6GA6mKl1LM5mPBbJ6ISY cOT48JeMgd6z9ku4GOagqKgxe65iRZAhgm88x75BVYaTigvFItdTNlPb5h3WqqkmGhyP lEcmnXiqo7lDDVU70mXWdYZ6MDwpwjZlCkeGT0i/zSdPmJKj0/epT8rTQMYTXtdt9hMI lEy0UD68CQlb+6dHtJ355b6DOo3HMxuNX0dbbVB2K1Ko9zESD1GsBE1LO0iXnrJd/y9W E3SQ== X-Received: by 10.68.129.99 with SMTP id nv3mr41306108pbb.128.1401251097214; Tue, 27 May 2014 21:24:57 -0700 (PDT) Received: from [192.168.178.23] (178.200.69.111.dynamic.snap.net.nz. [111.69.200.178]) by mx.google.com with ESMTPSA id gg3sm25948138pbc.34.2014.05.27.21.24.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 21:24:56 -0700 (PDT) Message-ID: <5385651B.7090604@gmail.com> Date: Wed, 28 May 2014 16:24:59 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Bush References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <9255C827-9F28-4E4E-9A2E-A678ADFACDAF@steffann.nl> <53854E87.9020500@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QQ_hlLoK_k4slDKyXmeWil-mC_4 Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 04:25:02 -0000 On 28/05/2014 15:11, Randy Bush wrote: >> The nature of ULAs makes it easier to talk them out of NAT, though, >> which is absolutely not the case for RFC 1918 addresses. (If we say >> anything about NATs in this draft, it should be to say that since >> ULAs are guaranteed* not to clash, and can co-exist with routeable >> GUAs, NAT is always unnecessary.) >> >> *i.e., guaranteed to very high probability if correctly generated. > > can we return to the real world? you have seen the distribution of > the ULAs that were leaked. wanna guess at the ones that were not > leaked? > > do not design specs that work only when standing on your left foot > and holding your right ear. design them to work when chaos reigns > and the rack and stack folk are working at three in the morning. I understand the problem. Users are idiots, including us when we act as users. I am not arguing that ULAs will prevent all operational problems caused by private addressing. I am only arguing that there will be private addressing and that ULAs will cause fewer problems than RFC1918-for-IPv6 would. Brian From nobody Tue May 27 21:29:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00E91A0308 for ; Tue, 27 May 2014 21:29:31 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTIE4p7D1PUB for ; Tue, 27 May 2014 21:29:30 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 083441A02F8 for ; Tue, 27 May 2014 21:29:30 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rp16so10457017pbb.34 for ; Tue, 27 May 2014 21:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=t/GUiojytSLIYzAaO3Rx3fvSjRmLqVWui82UxH2OFL0=; b=Ma/1hmJiwfaCEG3gTmgomcO90ZFbG1fwhQq+4q41eJtJvE8T8PZW0/ry/4LmUv16f2 2qBpdneOT46YW0LjOmStG55iLT50Lbnz2c40HtHLtJ4Jq7Q6a8lrqujTxb3205xFaUle 4BS9+nEM/an3BCdebDNfPj2mEdgg+jkq1qUqfP/M3JWAOf7dA0MYq6aS8r0mcLHnFhac bZ3YCKELSgZjnf+qe21mo1N5HUv6AC1f5BphLkqsfAuObEkB3kfsuK166mywsQQHUyuc 3zumimXQRrxM84sYd+Jgg2DvQ8JldTAjiG4isj2oVMrFjUXCM1cgIBat8mCS5eqbWYHS o36w== X-Received: by 10.66.191.9 with SMTP id gu9mr42711037pac.27.1401251366642; Tue, 27 May 2014 21:29:26 -0700 (PDT) Received: from [192.168.178.23] (178.200.69.111.dynamic.snap.net.nz. [111.69.200.178]) by mx.google.com with ESMTPSA id xr9sm82642565pab.5.2014.05.27.21.29.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 21:29:26 -0700 (PDT) Message-ID: <53856628.2070201@gmail.com> Date: Wed, 28 May 2014 16:29:28 +1200 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: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> <53855130.8040105@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/JEluv8LabIXXw09ttUld5IfGhDE Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] Routing /48s [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 04:29:31 -0000 On 28/05/2014 15:12, Lorenzo Colitti wrote: > On Wed, May 28, 2014 at 12:00 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> Let's assume a paltry 5 billion homenets, each with a routed /48. >> >> Well, today BGP-4 has 17687 entries for IPv6, according to >> http://bgp.potaroo.net/v6/as2.0/index.html >> It will be interesting when that number changes to 5000000000. >> >> Somehow I doubt this will happen. Quite how far we go in that >> direction is an interesting question. >> > > You don't need ULA to solve this. homenet is solving this problem using > source+destination routing. Indeed, and not just homenet. I just wanted to remind people that prefix-per-site has a scaling issue. That's why I changed the Subject:. On the other hand, and I speak from experience, persuading IT departments to support SADR is harder than persuading them to allow multiple prefixes. Brian From nobody Tue May 27 21:39:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAB21A0341 for ; Tue, 27 May 2014 21:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzF5l7qXR-gK for ; Tue, 27 May 2014 21:39:17 -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 D2F291A032F for ; Tue, 27 May 2014 21:39:17 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 747413493B4; Wed, 28 May 2014 04:39:13 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B5E3D16005B; Wed, 28 May 2014 04:44:23 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 7A6C6160049; Wed, 28 May 2014 04:44:23 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 441F616BFEB4; Wed, 28 May 2014 14:39:10 +1000 (EST) To: Brian E Carpenter From: Mark Andrews References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> <53855130.8040105@gmail.com> <53856628.2070201@gmail.com> In-reply-to: Your message of "Wed, 28 May 2014 16:29:28 +1200." <53856628.2070201@gmail.com> Date: Wed, 28 May 2014 14:39:10 +1000 Message-Id: <20140528043910.441F616BFEB4@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7X_EbVsSGXXdZTACqoq8ytmBZ0M Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] Routing /48s [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 04:39:19 -0000 In message <53856628.2070201@gmail.com>, Brian E Carpenter writes: > On 28/05/2014 15:12, Lorenzo Colitti wrote: > > On Wed, May 28, 2014 at 12:00 PM, Brian E Carpenter < > > brian.e.carpenter@gmail.com> wrote: > > > >> Let's assume a paltry 5 billion homenets, each with a routed /48. > >> > >> Well, today BGP-4 has 17687 entries for IPv6, according to > >> http://bgp.potaroo.net/v6/as2.0/index.html > >> It will be interesting when that number changes to 5000000000. > >> > >> Somehow I doubt this will happen. Quite how far we go in that > >> direction is an interesting question. > >> > > > > You don't need ULA to solve this. homenet is solving this problem using > > source+destination routing. > > Indeed, and not just homenet. I just wanted to remind people that prefix-per-site > has a scaling issue. That's why I changed the Subject:. > > On the other hand, and I speak from experience, persuading IT departments > to support SADR is harder than persuading them to allow multiple prefixes. Given SADR normally implies multiple prefixes it stands to reason. > Brian > > _______________________________________________ > 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 nobody Tue May 27 22:08:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB45A1A033A for ; Tue, 27 May 2014 22:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgF6Qnts8dJb for ; Tue, 27 May 2014 22:08:22 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA5431A032B for ; Tue, 27 May 2014 22:08:21 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C4A2E9C; Wed, 28 May 2014 07:08:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1401253696; bh=OY+1xOdq2ZJPim8+5H8x5cbkjDpBTAnNiTuZqDPTk28=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=CmvJV1TENfGFAQ5Qvjms7q3R5SFvep5cmtwxqBa7nNp0ooDQCof/WM1SaCJuugq5w 7w1CZ9Mhm6PxeGd9hzRuBzcvJqAS+hjg8i6ViCns3uBcmOheuRCg8trCXeXL+IU6qt CI0FiVzGJhjlBt75ElI1D/SgczB2e1FYG+tUwqXM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B866E9A; Wed, 28 May 2014 07:08:16 +0200 (CEST) Date: Wed, 28 May 2014 07:08:16 +0200 (CEST) From: Mikael Abrahamsson To: Ted Lemon In-Reply-To: <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/tBfZV-v0RIR76rOfnCv4jercz9A Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 05:08:23 -0000 On Tue, 27 May 2014, Ted Lemon wrote: > I'm just a poor bastard with a home connection that now (thanks, > Comcast!) has native IPv6. If you tell me that every enterprise on the > planet can easily get a /48 routed at no cost, then indeed that's > probably the right way to go. I will defer to others with more > experience in these matters to tell me whether or not that is so; my > understanding hitherto has been that it is not. We should spend more time on getting renumbering working properly. Having all Enterprise get PI space will make the routing system melt down. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue May 27 22:38:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98061A033E for ; Tue, 27 May 2014 22:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yS3vD4JyNe1X for ; Tue, 27 May 2014 22:37:58 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07DC41A0330 for ; Tue, 27 May 2014 22:37:58 -0700 (PDT) Received: from [192.168.2.6] (unknown [99.146.30.218]) by dougbarton.us (Postfix) with ESMTPSA id 12E7E22B1D; Wed, 28 May 2014 05:37:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1401255474; bh=aj7k+amiVb49Ab/+ZQcmO0fls9C0p1mXLODcuWniDdQ=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=lBlXTXCpWXfWDHrEpDVE8j+zvOa5g+u/kiziAL+nM7eYG3M1rQWP8Yy7lsql7zWVC bF6A2zcr7QYzRJ4wtNncZGm8ZDwprB5bmns1ME9/Wu3o7UxGxavayq4aXgARk0tlS5 /vedyYe7d+xI36jXjSAVfW26p8XHg2JZ1N5rSKcI= Message-ID: <5385762E.5020901@dougbarton.us> Date: Tue, 27 May 2014 22:37:50 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Randy Bush References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> In-Reply-To: X-Enigmail-Version: 1.7a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qaecheYPnQVfmC6kJJUB7FTGsM4 Cc: V6 Ops List Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 05:37:59 -0000 On 05/27/2014 07:32 PM, Randy Bush wrote: > so, bottom line here is, in its inimitable fashion, the ietf will push > ULA and get NAT. Randy, We have a substantial number of medium-sized enterprises which share the following characteristics: 1. They are large enough to have some internal resources that need addressing (printers, file servers, maybe a web site or two) 2. They are small enough that PI space and their own ASN are not practical 3. Some of them want to have multiple service providers, either for failover or traffic shaping 4. They don't want to have to renumber all of their internal resources when they change providers What's your solution for them? Doug From nobody Tue May 27 22:39:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C561A0341 for ; Tue, 27 May 2014 22:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8x8ccyO21zs for ; Tue, 27 May 2014 22:39:45 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801BC1A0330 for ; Tue, 27 May 2014 22:39:45 -0700 (PDT) Received: from [192.168.2.6] (unknown [99.146.30.218]) by dougbarton.us (Postfix) with ESMTPSA id A17B122B1D for ; Wed, 28 May 2014 05:39:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1401255581; bh=ba1xFTvryTf7cdclh+/oUj/M1vQBL96XDHYvWXaSMpU=; h=Date:From:To:Subject:References:In-Reply-To; b=V4kUldmXWFqCXvOCTwecyRfsxksLanoLwMrhyTa4VJnJzR6ARlwgGVNJNxwdGHLHy pfT1+uP9W7t+ijWJ4987c2EiAN74gqPAYYyacbLfstq9OnlGs5jqgbW41RRZ0OZspQ mfQ/OmcxfBfg/wUqP85316UhYdYnwUjSjCQUwZQg= Message-ID: <5385769B.9000406@dougbarton.us> Date: Tue, 27 May 2014 22:39:39 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com> In-Reply-To: <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com> X-Enigmail-Version: 1.7a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/WBSHIBvucw6skxO3P5aR96e4NNg Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 05:39:46 -0000 On 05/26/2014 02:57 PM, Mark ZZZ Smith wrote: > This paragraph seems to show a fundamental misunderstanding of IPv6's multi-addressing capabilities. IPv6 supports multiple concurrent addresses (from different prefixes), and can learn new ones or deprecate old ones over time. Attachment to a new network doesn't require renumbering, it requires propagating new prefixes for the hosts to use in addition to their existing ones. Primarily RFC6724 address selection will help the hosts choose the right addresses to use as source and destinations when they have multiple addresses. Mark, How does this help the medium-sized enterprise which has internal resources that need host names? Doug From nobody Tue May 27 22:41:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324201A0346 for ; Tue, 27 May 2014 22:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOnAWMyd3wsJ for ; Tue, 27 May 2014 22:41:24 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 348D71A0330 for ; Tue, 27 May 2014 22:41:24 -0700 (PDT) Received: from [192.168.2.6] (unknown [99.146.30.218]) by dougbarton.us (Postfix) with ESMTPSA id 9F35422B1D for ; Wed, 28 May 2014 05:41:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1401255681; bh=cg0HgF4WFTzS6GTJJbWbRxR4GhxXXVnw71eym/kE+7Q=; h=Date:From:To:Subject:References:In-Reply-To; b=nOlMkc6X+tulf4WrGjaujjOPge7gdXtedpD+wUi2cdg9Ta5+lSiV3nFcPQKt20JOh ODHJb4HgCBVS8qbXdEsInebKOfDm/i6CveD3Ge9km6E5ZVVx1dNf277v3qhOZG9JhZ 7H2Up/HwYpN93+jV8DKhAFmuk1vKHJz8sQz6P4xk= Message-ID: <538576FB.2030805@dougbarton.us> Date: Tue, 27 May 2014 22:41:15 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.thmulti.com> In-Reply-To: <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.thmulti.com> X-Enigmail-Version: 1.7a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/WYDGEMw1Tc4Gl0UwbLpb7mwOC0A Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 05:41:25 -0000 On 05/27/2014 06:35 AM, Wuyts Carl wrote: > And what's next ? Stop path MTU discovery support ? Allow Fragmentation again ? Anything else ? > If we start mimic IPv4 fully, we're really going the wrong way .... Argumentum ad absurdum From nobody Tue May 27 23:51:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC621A037B for ; Tue, 27 May 2014 23:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hijx2r11Sr-5 for ; Tue, 27 May 2014 23:51:00 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 5F2D81A0372 for ; Tue, 27 May 2014 23:50:58 -0700 (PDT) Received: (qmail 14887 invoked from network); 28 May 2014 06:50:52 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 28 May 2014 06:50:52 -0000 Date: Wed, 28 May 2014 08:49:37 +0200 (CEST) Message-Id: <20140528.084937.74738378.sthaug@nethelp.no> To: randy@psg.com From: sthaug@nethelp.no In-Reply-To: References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/nYi_8Z3_Co2E_m8K8_O13OIGN9c Cc: v6ops@ietf.org Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 06:51:02 -0000 > > or use NAT. I'm not saying this in order to throw fuel on an existing > > fire, but simply because this is the reality for many organisations in > > the ipv4 world, and I see little reason why it will change for ipv6. > > The IETF can make recommendations about whether it thinks this is a > > good idea or not, but it is not productive to pretend that the > > elephant isn't in the room. > > so, bottom line here is, in its inimitable fashion, the ietf will push > ULA and get NAT. what a win! IPv6 will get NAT no matter what the IETF does. Trying to reduce the damage from NAT, for instance by having sensible rules for ULA, seems like a good thing. Steinar Haug, AS2116 From nobody Wed May 28 00:59:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4D61A03B1 for ; Wed, 28 May 2014 00:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OThmoc2zPe05 for ; Wed, 28 May 2014 00:59: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 EA8F21A03AB for ; Wed, 28 May 2014 00:59:26 -0700 (PDT) Received: from [IPv6:2620::930:0:225:ff:fe44:af17] ([IPv6:2620:0:930:0:225:ff:fe44:af17]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s4S7uMZ5024769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 May 2014 00:56:23 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s4S7uMZ5024769 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1401263784; bh=kv6M5lCpLE0zixb7A6p4pfjj30w=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=osqCIPyh+khsgJszk8dheHc/QYrXouU4iV0CNNlaJDzoxKVLVEjpllNdR4CPW1B6d BSL6PpFd6GZDpw2ycKmTVAimuKBq6fzEZ+Nf+9sNJGoa1GU//tJ6IUOmbkuzeN1g/i ri1FvuryrscK0DGfGeowGWTStGq0vMU5jSPmJqiQ= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <53855130.8040105@gmail.com> Date: Wed, 28 May 2014 00:59:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> <53855130.8040105@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 28 May 2014 00:56:24 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/WoqTbnvJDnDSER3UikAhZ-H6JSU Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] Routing /48s [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 07:59:28 -0000 On May 27, 2014, at 8:00 PM, Brian E Carpenter = wrote: > On 28/05/2014 07:18, Ted Lemon wrote: >> On May 27, 2014, at 3:11 PM, Owen DeLong wrote: >>> In my experience, it is quite easy and not particularly costly to = get a /48 routed. Do you have different experience? >>=20 >> I'm just a poor bastard with a home connection that now (thanks, = Comcast!) has native IPv6. If you tell me that every enterprise on the = planet can easily get a /48 routed at no cost, then indeed that's = probably the right way to go. I will defer to others with more = experience in these matters to tell me whether or not that is so; my = understanding hitherto has been that it is not. >=20 > Let=92s assume a paltry 5 billion homenets, each with a routed /48. That=92s a pretty absurd number. There are roughly 7.1 billion people on the planet. The average = household size in the us is 3.4 people. In most countries, it tends to = be somewhat larger. By my calculation, 7.1/3 is a little less than 2.4, = nowhere near 5. > Well, today BGP-4 has 17687 entries for IPv6, according to > http://bgp.potaroo.net/v6/as2.0/index.html > It will be interesting when that number changes to 5000000000. Yes, BGP4 has a limited future and we need to find a better way to do = routing. This is not news. However, in reality, this would only apply to = the subset of households that feel they cannot easily renumber and = choose to pay RIR and other fees to enable the use of a portable prefix. > Somehow I doubt this will happen. Quite how far we go in that > direction is an interesting question. Yep. Owen From nobody Wed May 28 01:09:49 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1064C1A03D7 for ; Wed, 28 May 2014 01:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIZio_RoHFmk for ; Wed, 28 May 2014 01:09:46 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB071A0873 for ; Wed, 28 May 2014 01:09:46 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1WpYve-0000BIC; Wed, 28 May 2014 10:09:42 +0200 Message-Id: To: v6ops WG From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <9255C827-9F28-4E4E-9A2E-A678ADFACDAF@steffann.nl> <53854E87.9020500@gmail.com> <5385651B.7090604@gmail.com> In-reply-to: Your message of "Wed, 28 May 2014 16:24:59 +1200 ." <5385651B.7090604@gmail.com> Date: Wed, 28 May 2014 10:09:42 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/I0QMxBC7ojgTcsQRY-MMmQP4Zn0 Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 08:09:48 -0000 In your letter dated Wed, 28 May 2014 16:24:59 +1200 you wrote: >I understand the problem. Users are idiots, including us when we >act as users. I am not arguing that ULAs will prevent all operational >problems caused by private addressing. I am only arguing that there will >be private addressing and that ULAs will cause fewer problems than >RFC1918-for-IPv6 would. Maybe we can keep a bit of context around what scenario we are talking about. Say: 1) Small organisation, doesn't get PI space, has to renumber when moving to a different ISP. The IPv4 solution is to use NAT. Maybe we can do better for IPv6. Probably collisions of ULA space during a merger are not a big deal. 2) Bigger organisation, does have PI space and has a more or less homogenous network. No real need for ULA. 3) Big organisation, wants to have a secret network that only communicates through application layer gateways. Should be able to pick a proper ULA if they need one. Otherwise, though luck. No real need for ULA. It may make source address selection a bit easier, but that is only a small part of the puzzle. I think the only interesting case is 1). Whether or not we make renumbering easy enough that they don't do NAT is an open question. A large part of that is in software configuration: is it possible to store the current prefix in such a way that software can easily pick it up. From nobody Wed May 28 01:14:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6CB1A01D2 for ; Wed, 28 May 2014 01:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.642 X-Spam-Level: X-Spam-Status: No, score=-3.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbLKszPOo_5D for ; Wed, 28 May 2014 01:14: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 9C8781A081A for ; Wed, 28 May 2014 01:14:21 -0700 (PDT) Received: from [IPv6:2620::930:0:225:ff:fe44:af17] ([IPv6:2620:0:930:0:225:ff:fe44:af17]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s4S8DYO4025111 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 May 2014 01:13:35 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s4S8DYO4025111 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1401264815; bh=J1UBADvZeQZ91h3AvKQatvI77hc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=A8Mb/CJI0gqECVwJ5NsOQTb2lE7PMEobzvhJEcv8t7SQW7ubAjFyhdGYYctsOrI5k Wzdsxh+MX7OvcmhzGFqZEHTfZqtF0OzKHoTLeExNFS8acovRfECoBJSIMR/GV1ijUx ZH1U0LZ7Vf6GCG2f99r5sO1PcHAg+BQhXKqNpaeM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <20140527221708.A980B16B8C6E@rock.dv.isc.org> Date: Wed, 28 May 2014 01:16:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <20140527221708.A980B16B8C6E@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 28 May 2014 01:13:35 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/cHXlfyXbXIkH9FdJ6qdatlyMq5U Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 08:14:23 -0000 On May 27, 2014, at 3:17 PM, Mark Andrews wrote: >=20 > In message , Philip Homburg = writes: >> In your letter dated Tue, 27 May 2014 08:52:02 -0400 you wrote: >>> The operational situation that's problematic is the large enterprise=20= >>> scenario, where you have two large enterprises with their own ULAs = that=20 >>> merge. If those ULAs happen to clash, you have to renumber at = least=20 >>> one of them. If they don't clash, you still have to deal with = routing=20 >>> them (although I think the split-horizon complexity objection Mikael=20= >>> raised ought to be thought through carefully before being asserted = as=20 >>> factual, because I think it can be addressed through routing and not=20= >>> naming). >>=20 >> If you are a large entrprise, just spend the 50 euro or so (RIPE = service region) it >> costs to get your own prefix. >=20 > A /56 is over AUD1180 (+10% GST) annually. Thanks for playing. >=20 Yes, APNIC now has the distinction of being the absolutely most = expensive RIR on the planet. However, outside of the APNIC region, prices are much more reasonable. US 100 per resource (regardless of size) ARIN EU 50 (flat rate, regardless of resources) RIPE US 600 (up to a /35) LACNIC US 100 (per /48?) AfriNIC AU1180 (/56, logarithmic formula for larger blocks) APNIC So, it looks like at a little less than twice your next closest = competitor, APNIC is the clear winner for the highest prices. Owen From nobody Wed May 28 01:24:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E581A0884 for ; Wed, 28 May 2014 01:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUx7XOHjmWKU for ; Wed, 28 May 2014 01:24: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 D24BF1A0883 for ; Wed, 28 May 2014 01:24:21 -0700 (PDT) Received: from [IPv6:2620::930:0:225:ff:fe44:af17] ([IPv6:2620:0:930:0:225:ff:fe44:af17]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s4S8JPaP025227 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 May 2014 01:19:26 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s4S8JPaP025227 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1401265166; bh=0KY+JED4hFpCV9E+uDFF056sv0s=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=1/AC5uJzEUrN45AnGclgamuIuNApyECj3mDvOWVWSAHlz5JxJQ6UUNkr/qDnheMbn o/rLEM9MoZW/O5OXgJgEb6DH8DVuN08QkCBIT+cw0/KP1clJiZfHRR4xi79b5dRTSm CvK8wSm9pv/Y1fbk9UXCqNlsIRurTB9VSiE7VHXY= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <5385651B.7090604@gmail.com> Date: Wed, 28 May 2014 01:22:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <9255C827-9F28-4E4E-9A2E-A678ADFACDAF@steffann.nl> <53854E87.9020500@gmail.com> <5385651B.7090604@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 28 May 2014 01:19:26 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/OrQyN6N4p6_WOEYQtYijBke1eFo Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 08:24:23 -0000 > I understand the problem. Users are idiots, including us when we > act as users. I am not arguing that ULAs will prevent all operational > problems caused by private addressing. I am only arguing that there = will > be private addressing and that ULAs will cause fewer problems than > RFC1918-for-IPv6 would. I agree, but that=92s rather like an argument that the common cold = causes less severe symptoms than small pox. Owen From nobody Wed May 28 02:21:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA031A0052 for ; Wed, 28 May 2014 02:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGOjQUOpkCYY for ; Wed, 28 May 2014 02:21:37 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536EC1A0041 for ; Wed, 28 May 2014 02:21:37 -0700 (PDT) Received: from [2a02:fe0:c410:3310::1] (port=52038 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Wpa35-00062F-SZ; Wed, 28 May 2014 11:21:27 +0200 Message-ID: <5385AA97.1050207@fud.no> Date: Wed, 28 May 2014 11:21:27 +0200 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Doug Barton , Randy Bush References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> In-Reply-To: <5385762E.5020901@dougbarton.us> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DcilE918JxrPkjyKe7J5w_6zsHk Cc: V6 Ops List Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 09:21:39 -0000 * Doug Barton > We have a substantial number of medium-sized enterprises which share the > following characteristics: > > 1. They are large enough to have some internal resources that need > addressing (printers, file servers, maybe a web site or two) > > 2. They are small enough that PI space and their own ASN are not practical You don't need an ASN to use PI space. > 3. Some of them want to have multiple service providers, either for > failover or traffic shaping > > 4. They don't want to have to renumber all of their internal resources > when they change providers > > What's your solution for them? We have a few customers in the same situation. So we obtained a PI prefix for them, which costs next to nothing in the RIPE region at least, and advertise the prefix on their behalf (and in the cases where there's a second upstream, the second upstream does the same). Works perfectly well, and is much less complex than anything solution involving ULA, NAT, multiple prefixes on the hosts, or whatever. The customer just gets a bunch of addresses he can use in perpetuity. Tore, who prefers to KISS From nobody Wed May 28 02:28:15 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865E71A0041 for ; Wed, 28 May 2014 02:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vykpRFBDxonI for ; Wed, 28 May 2014 02:28:12 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26B721A0033 for ; Wed, 28 May 2014 02:28:12 -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 s4S9RxHQ008158; Wed, 28 May 2014 10:27:59 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s4S9RxHQ008158 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1401269280; bh=bPa3NJKoAlAGOLOef0Ag77V8d5g=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=GXCL+cEIRTBmiuGnG+0HpP2Rl+5rcqcSXHlU/W4vaX9GvqQRDAe9fdLMgY2zFxfvA QX1s4Bk0Z9y6LQ9wQOYTH7CFzUHMmsw3e1EqUcQLK0/omTvahUVSgHVs0JBkfQ0UlK S4+2pYYUNwOwbIJM7I8WjY4V763JE3oBcWdCsLPY= 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 q4RARx0546019200YW ret-id none; Wed, 28 May 2014 10:28:00 +0100 Received: from [IPv6:2001:630:d0:ed04:99c4:f52:b5cc:ec1e] ([IPv6:2001:630:d0:ed04:99c4:f52:b5cc:ec1e]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s4S9RuRD028830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 May 2014 10:27:57 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Chown In-Reply-To: <5385522F.40305@gmail.com> Date: Wed, 28 May 2014 10:27:56 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.thmulti.com> <20140527222313.7B12716B8D59@rock.dv.isc.org> <53851236.8020209@bogus.com> <5385522F.40305@gmail.com> <4BA71D7E-7A38-4327-8C7D-7E49F047CDDB@ecs.soton.ac.uk> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.2) X-smtpf-Report: sid=q4RARx054601920000; tid=q4RARx0546019200YW; 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: s4S9RxHQ008158 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/32d7ClQd_MK4VKYnMAOIw05smE4 Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] Fragments [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 09:28:14 -0000 On 28 May 2014, at 04:04, Brian E Carpenter = wrote: > On 28/05/2014 10:31, joel jaeggli wrote: >> On 5/27/14, 3:23 PM, Mark Andrews wrote: >>> In message = <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.thmulti.com>, = Wuyts Carl writes: >>>> And what's next ? Stop path MTU discovery support ? Allow = Fragmentation again ? Anything else ? >>>> If we start mimic IPv4 fully, we're really going the wrong way .... = (my personal opinion of course) >>> Please state clearly the RFC which disallows fragmentation? >>> Hint: There isn't one. >>=20 >> you know he's referring to intermediate fragmentation... >>=20 >> http://tools.ietf.org/html/rfc2460#section-5 >>=20 >>> Fragmentation is a BASIC part of IPv6. It is done in the sending >>> host rather than in the core of the network but it is DONE!!!!! >>=20 >> yes. >=20 > But see http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop > for a dose of reality. Tests that Fernando and I reported at the last IEPG show around 50% of = the Alexa top 1m sites which support IPv6 also drop frags. Tests for = other types of EH are far from encouraging too. Tim >=20 > Brian >=20 >>=20 >>>> Regs >>>> Carl >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Nick = Hilliard >>>> Sent: dinsdag 27 mei 2014 15:31 >>>> To: Ted Lemon; Philip Homburg >>>> Cc: v6ops WG >>>> Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated = networks >>>>=20 >>>> On 27/05/2014 13:52, Ted Lemon wrote: >>>>> If those ULAs happen to clash, you have to renumber at least one = of them. >>>> or use NAT. I'm not saying this in order to throw fuel on an = existing fire, but simply because this is the reality fo >>>> r many organisations in the >>>> ipv4 world, and I see little reason why it will change for ipv6. = The IETF can make recommendations about whether it t >>>> hinks this is a good idea or not, but it is not productive to = pretend that the elephant isn't in the room. >>>>=20 >>>> Nick >>>>=20 >>>> _______________________________________________ >>>> 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 >>=20 >>=20 >>=20 >> = ------------------------------------------------------------------------ >>=20 >> _______________________________________________ >> 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 nobody Wed May 28 02:28:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1121A0896 for ; Wed, 28 May 2014 02:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnuYIPTqqObO for ; Wed, 28 May 2014 02:28:35 -0700 (PDT) Received: from na3sys009aog138.obsmtp.com (na3sys009aog138.obsmtp.com [74.125.149.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1EA31A0041 for ; Wed, 28 May 2014 02:28:29 -0700 (PDT) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob138.postini.com ([74.125.148.12]) with SMTP ID DSNKU4WsOI1yVDJUZ+k8oiiJewwIfpWS+GN5@postini.com; Wed, 28 May 2014 02:28:31 PDT Received: from MOPESMAILHTC02.eu.thmulti.com (141.11.100.178) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.342.0; Wed, 28 May 2014 11:25:45 +0200 Received: from MOPESMBX03.eu.thmulti.com ([169.254.2.100]) by MOPESMAILHTC02.eu.thmulti.com ([141.11.100.178]) with mapi id 14.03.0174.001; Wed, 28 May 2014 11:25:49 +0200 From: Wuyts Carl To: Tore Anderson , Doug Barton , Randy Bush Thread-Topic: [v6ops] ULA draft revision #2 Regarding isolated networks Thread-Index: Ac943yf4qhJ96dkPR9CtEDOlyHC2QQAZCzeAAAEGaAAAABxQAAAA4z6AAACtwIAAAMLCAAAAXbqAAAGXQAAAAHTTAAAMrhbdAAMIogAAAViEAAAbUBKAAAZ39wAAB89KgAAERUbw Date: Wed, 28 May 2014 09:25:49 +0000 Message-ID: <96747494E3D74D41B20907035DB1E48D335AB201@MOPESMBX03.eu.thmulti.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> In-Reply-To: <5385AA97.1050207@fud.no> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.11.182.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ESB7yhOY-Juq40qajZhISI9kqJI Cc: V6 Ops List Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 09:28:36 -0000 +1 for PI usage, however, seems some have difficulties getting it, as you n= eed to be RIPE (or other region) member (not free-of-charge) to get one and= an ISP is not always really "happy" to do this (as they become a little mo= re independent) Carl=20 -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Tore Anderson Sent: woensdag 28 mei 2014 11:21 To: Doug Barton; Randy Bush Cc: V6 Ops List Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks * Doug Barton > We have a substantial number of medium-sized enterprises which share=20 > the following characteristics: >=20 > 1. They are large enough to have some internal resources that need=20 > addressing (printers, file servers, maybe a web site or two) >=20 > 2. They are small enough that PI space and their own ASN are not=20 > practical You don't need an ASN to use PI space. > 3. Some of them want to have multiple service providers, either for=20 > failover or traffic shaping >=20 > 4. They don't want to have to renumber all of their internal resources=20 > when they change providers >=20 > What's your solution for them? We have a few customers in the same situation. So we obtained a PI prefix f= or them, which costs next to nothing in the RIPE region at least, and adver= tise the prefix on their behalf (and in the cases where there's a second up= stream, the second upstream does the same). Works perfectly well, and is mu= ch less complex than anything solution involving ULA, NAT, multiple prefixe= s on the hosts, or whatever. The customer just gets a bunch of addresses he= can use in perpetuity. Tore, who prefers to KISS _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed May 28 02:51:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33031A08A7 for ; Wed, 28 May 2014 02:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.871 X-Spam-Level: X-Spam-Status: No, score=-3.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuY2LRBQHJqR for ; Wed, 28 May 2014 02:50:59 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2286B1A007D for ; Wed, 28 May 2014 02:50:58 -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 s4S9osdV021221; Wed, 28 May 2014 10:50:54 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s4S9osdV021221 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1401270654; bh=DwB5uSz1Dd9A/FnK8A8gRSTTS0o=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=folAKDnlqUnrzeinh691suH6lfZmBzdMWy7o1ydgRT7w9JD3MqfZup5QE0pIywBuU nikvw+IwqKLwddAjIPGP/7ePVGGc+wciQL4vGAdVP+bW6lfVw+4RqGfQLsnmz0c2+Z W9SQnmk6vXW8BjLCjMDK0QNZMt0P9zqibvs7ro04= 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 q4RAos0546020208vY ret-id none; Wed, 28 May 2014 10:50:54 +0100 Received: from [IPv6:2001:630:d0:ed04:99c4:f52:b5cc:ec1e] ([IPv6:2001:630:d0:ed04:99c4:f52:b5cc:ec1e]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s4S9orqS001253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 May 2014 10:50:54 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_C29353C5-ABD0-464D-A4A5-14721AFC3A2B" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Chown In-Reply-To: Date: Wed, 28 May 2014 10:50:53 +0100 Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <9255C827-9F28-4E4E-9A2E-A678ADFACDAF@steffann.nl> <53854E87.9020500@gmail.com> <5385651B.7090604@gmail.com> To: Philip Homburg X-Mailer: Apple Mail (2.1878.2) X-smtpf-Report: sid=q4RAos054602020800; tid=q4RAos0546020208vY; 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: s4S9osdV021221 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LS_Ce-Cx1J86diXLigERAswl6ak Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 09:51:02 -0000 --Apple-Mail=_C29353C5-ABD0-464D-A4A5-14721AFC3A2B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 28 May 2014, at 09:09, Philip Homburg = wrote: > In your letter dated Wed, 28 May 2014 16:24:59 +1200 you wrote: >> I understand the problem. Users are idiots, including us when we >> act as users. I am not arguing that ULAs will prevent all operational >> problems caused by private addressing. I am only arguing that there = will >> be private addressing and that ULAs will cause fewer problems than >> RFC1918-for-IPv6 would. >=20 > Maybe we can keep a bit of context around what scenario we are talking = about. >=20 > Say: > 1) Small organisation, doesn't get PI space, has to renumber when = moving to a different > ISP. The IPv4 solution is to use NAT. Maybe we can do better for = IPv6. Probably > collisions of ULA space during a merger are not a big deal. > 2) Bigger organisation, does have PI space and has a more or less = homogenous network. > No real need for ULA. > 3) Big organisation, wants to have a secret network that only = communicates through > application layer gateways. Should be able to pick a proper ULA if = they need one. > Otherwise, though luck. No real need for ULA. It may make source = address selection > a bit easier, but that is only a small part of the puzzle. >=20 > I think the only interesting case is 1). Whether or not we make = renumbering easy enough > that they don't do NAT is an open question. A large part of that is in = software > configuration: is it possible to store the current prefix in such a = way that software > can easily pick it up. And we spent two years batting that topic around in 6renum, for = site/enterprise networks (not targeting homenets). IPv6 network renumbering on the wire =3D reasonably straight forward = (Fred=92s work is now 10 years old) The complexity is all the places addresses are embedded in interesting = ways, in your sites and sites you speak to. Three RFCs emerged, see http://datatracker.ietf.org/wg/6renum/ Tim --Apple-Mail=_C29353C5-ABD0-464D-A4A5-14721AFC3A2B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 28 May 2014, at 09:09, Philip = Homburg <pch-v6ops-3a@u-1.phicoh.com> wrote:

In your letter dated Wed, 28 May 2014 16:24:59 +1200 you = wrote:
I understand the problem. Users are = idiots, including us when we
act as users. I am not arguing that ULAs = will prevent all operational
problems caused by private addressing. I = am only arguing that there will
be private addressing and that ULAs = will cause fewer problems than
RFC1918-for-IPv6 = would.

Maybe we can keep a bit of context around = what scenario we are talking about.

Say:
1) Small = organisation, doesn't get PI space, has to renumber when moving to a = different
  ISP. The IPv4 solution is to use NAT. Maybe we = can do better for IPv6. Probably
  collisions of ULA space = during a merger are not a big deal.
2) Bigger organisation, does have = PI space and has a more or less homogenous network.
  No = real need for ULA.
3) Big organisation, wants to have a secret = network that only communicates through
  application layer = gateways. Should be able to pick a proper ULA if they need one.
=   Otherwise, though luck. No real need for ULA. It may make = source address selection
  a bit easier, but that is only = a small part of the puzzle.

I think the only interesting case is = 1). Whether or not we make renumbering easy enough
that they don't do = NAT is an open question. A large part of that is in = software
configuration: is it possible to store the current prefix in = such a way that software
can easily pick it = up.

And we spent two years batting that = topic around in 6renum, for site/enterprise networks (not targeting = homenets).



Tim

<= /html>= --Apple-Mail=_C29353C5-ABD0-464D-A4A5-14721AFC3A2B-- From nobody Wed May 28 02:52:12 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38AD81A0898 for ; Wed, 28 May 2014 02:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gkpkf04f40Sj for ; Wed, 28 May 2014 02:52:09 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BCAC1A088D for ; Wed, 28 May 2014 02:52:09 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 4908060AF9 for ; Wed, 28 May 2014 11:52:04 +0200 (CEST) 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 1189460A90 for ; Wed, 28 May 2014 11:52:04 +0200 (CEST) Received: (qmail 52607 invoked by uid 1007); 28 May 2014 11:52:04 +0200 Date: Wed, 28 May 2014 11:52:04 +0200 From: Gert Doering To: Doug Barton Message-ID: <20140528095203.GP46558@Space.Net> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5385762E.5020901@dougbarton.us> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Fl2RJQt0ILUjCtaUnRXBfGjVQOo Cc: V6 Ops List Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 09:52:11 -0000 Hi, On Tue, May 27, 2014 at 10:37:50PM -0700, Doug Barton wrote: > We have a substantial number of medium-sized enterprises which share the > following characteristics: > > 1. They are large enough to have some internal resources that need > addressing (printers, file servers, maybe a web site or two) > > 2. They are small enough that PI space and their own ASN are not practical > > 3. Some of them want to have multiple service providers, either for > failover or traffic shaping > > 4. They don't want to have to renumber all of their internal resources > when they change providers > > What's your solution for them? These requirements can be perfectly well met with "renumbering when they change provider", except for 4. - if a bit of planning is involved, and not trying to stick to last century's technology. Like: use mDNS or AD-provided DNS to find your printer and file server (so the actual address it has today does not really matter). Think twice whether you really want to run your web site locally, instead of hosting it somewhere which has more bandwidth, proper 7x24 operations, etc. And indeed it would be nice if firewall vendors would hear the message that being able to specify rules referencing a DHCPv6-PD-acquired prefix is a needed thing... But of course, you can provide all technology there is, and someone will still want NAT. 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 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed May 28 02:52:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306181A08AD for ; Wed, 28 May 2014 02:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1ZfxIK_YJr7 for ; Wed, 28 May 2014 02:52:18 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A63481A08AC for ; Wed, 28 May 2014 02:52:17 -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 s4S9qCjj021523; Wed, 28 May 2014 10:52:12 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s4S9qCjj021523 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1401270732; bh=wQMk3fJsLfnLFyVlfkePUY0bMpc=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=U8S8xw+iIp2Ej7+CjuH5ApfGjPVyrT/6PvBRu+Xwz/swb8Fe91761hTCpAYZgPM2N EEjaniG6HDyS/ctUkAdiy8CdpsUOkfvuTXEHLUlNBBqIV/uu3t/R+tA2KUejonJBVa jkhQQPWS4VRGXpmrycwdgZqvndYbb+yNfcmSvKlM= 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 q4RAqC0546020216b8 ret-id none; Wed, 28 May 2014 10:52:12 +0100 Received: from [IPv6:2001:630:d0:ed04:99c4:f52:b5cc:ec1e] ([IPv6:2001:630:d0:ed04:99c4:f52:b5cc:ec1e]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s4S9qBUR001441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 May 2014 10:52:12 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Chown In-Reply-To: Date: Wed, 28 May 2014 10:52:11 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> <43044F17-CAFE-4A6C-94FB-2BEA089CD425@ecs.soton.ac.uk> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1878.2) X-smtpf-Report: sid=q4RAqC054602021600; tid=q4RAqC0546020216b8; 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: s4S9qCjj021523 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/WAgR4wPFVp0CP4v-T_itOc_Gscs Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 09:52:24 -0000 On 28 May 2014, at 06:08, Mikael Abrahamsson wrote: > On Tue, 27 May 2014, Ted Lemon wrote: >=20 >> I'm just a poor bastard with a home connection that now (thanks, = Comcast!) has native IPv6. If you tell me that every enterprise on the = planet can easily get a /48 routed at no cost, then indeed that's = probably the right way to go. I will defer to others with more = experience in these matters to tell me whether or not that is so; my = understanding hitherto has been that it is not. >=20 > We should spend more time on getting renumbering working properly. = Having all Enterprise get PI space will make the routing system melt = down. I think it was Brian who did some analysis a few years ago on just how = many =93large sites=94 are out there. It=92s not *that* scary a number. = Though nor is it small. Obviously if you include homenets the meltdown = is massive, but no one in the homenet wg is proposing PI for homenets. Tim= From nobody Wed May 28 05:12:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4594E1A00D4 for ; Wed, 28 May 2014 05:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tL_dEVube_Uq for ; Wed, 28 May 2014 05:11:52 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33FDD1A00C5 for ; Wed, 28 May 2014 05:11:52 -0700 (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 660BB1B8078 for ; Wed, 28 May 2014 05:11:47 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id B4C2619005C; Wed, 28 May 2014 05:11:45 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 May 2014 05:11:45 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Wed, 28 May 2014 08:11:41 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <210C5A37-30EC-454F-A74A-7489E012D379@nominum.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> <53855130.8040105@gmail.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/liEe4lIsI_a3Hexjk8O2jnttsx8 Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] Routing /48s [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 12:11:58 -0000 On May 27, 2014, at 11:12 PM, Lorenzo Colitti = wrote: > You don't need ULA to solve this. homenet is solving this problem = using source+destination routing.=20 Er, homenet is (likely) using ULAs, just not as a way to finesse = multi-homing. From nobody Wed May 28 05:21:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736B21A00E5 for ; Wed, 28 May 2014 05:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgSnAjorfdJq for ; Wed, 28 May 2014 05:21:27 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5499A1A03FC for ; Wed, 28 May 2014 05:21:27 -0700 (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 459001B8078 for ; Wed, 28 May 2014 05:21:23 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 3584719005C; Wed, 28 May 2014 05:21:23 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 May 2014 05:21:22 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <53856628.2070201@gmail.com> Date: Wed, 28 May 2014 08:21:18 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <4042F444-2A43-499C-823E-52BCDEF112CE@nominum.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> <53855130.8040105@gmail.com> <53856628.2070201@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/00y4K0ggiidxVCjjb4orb42mK34 Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] Routing /48s [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 12:21:29 -0000 On May 28, 2014, at 12:29 AM, Brian E Carpenter = wrote: > On the other hand, and I speak from experience, persuading IT = departments > to support SADR is harder than persuading them to allow multiple = prefixes. Do we have implementations we could in theory try to persuade them to = run? From nobody Wed May 28 05:24:56 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6981A0964 for ; Wed, 28 May 2014 05:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiDRNvZ_Nv0L for ; Wed, 28 May 2014 05:24:52 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1594D1A095D for ; Wed, 28 May 2014 05:24:52 -0700 (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 28C9A1B8078 for ; Wed, 28 May 2014 05:24:48 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 2314919005C; Wed, 28 May 2014 05:24:48 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 May 2014 05:24:47 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Wed, 28 May 2014 08:24:42 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <8756262F-E022-4685-A805-BE6C2F6AA321@nominum.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/uIJGJ_zK13TK-pX8K0rh-IMdfk0 Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 12:24:54 -0000 On May 28, 2014, at 1:08 AM, Mikael Abrahamsson = wrote: > We should spend more time on getting renumbering working properly. = Having all Enterprise get PI space will make the routing system melt = down. This is what I was getting at, and you and Brian have both confirmed my = original understanding. Thanks. From nobody Wed May 28 05:35:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01981A096B for ; Wed, 28 May 2014 05:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.662 X-Spam-Level: X-Spam-Status: No, score=-1.662 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBXZNIBh082X for ; Wed, 28 May 2014 05:35:09 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F10A1A0928 for ; Wed, 28 May 2014 05:35:09 -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 s4SCYRJ8009094; Wed, 28 May 2014 13:34:27 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s4SCYRJ8009094 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1401280467; bh=MaiPViSawFJTfJIy0r7HzcU5VXY=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=slYidJZbPPvUmJy03j5dTGS1oAruuq1nMEI+QFKyZiRiqG26MQ/NcemBNVWKcjmdA va9eR1ElKN/cY5UQsXNQonaErnZPA+goEAE+9s6bwuhxQ9sDdHjS7qYV6NfFHt+J7s SuSf7WilvB9UsK0cF4MCEzKghEc+2b6yEEsVXtgM= 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 q4RDYR0546021887A0 ret-id none; Wed, 28 May 2014 13:34:27 +0100 Received: from [IPv6:2001:630:d0:ed04:99c4:f52:b5cc:ec1e] ([IPv6:2001:630:d0:ed04:99c4:f52:b5cc:ec1e]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s4SCYQd9000524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 May 2014 13:34:26 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Chown In-Reply-To: <210C5A37-30EC-454F-A74A-7489E012D379@nominum.com> Date: Wed, 28 May 2014 13:34:26 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> <53855130.8040105@gmail.com> <210C5A37-30EC-454F-A74A-7489E012D3! 79@nominum.com> <92F4AACD-271A-4B81-9448-429DB3B72F72@ecs.soton.ac.uk> To: Ted Lemon X-Mailer: Apple Mail (2.1878.2) X-smtpf-Report: sid=q4RDYR054602188700; tid=q4RDYR0546021887A0; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s4SCYRJ8009094 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/x5VPEXXCKoKO0n9BaTEs2HCc4xQ Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] Routing /48s [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 12:35:12 -0000 On 28 May 2014, at 13:11, Ted Lemon wrote: > On May 27, 2014, at 11:12 PM, Lorenzo Colitti = wrote: >> You don't need ULA to solve this. homenet is solving this problem = using source+destination routing.=20 >=20 > Er, homenet is (likely) using ULAs, just not as a way to finesse = multi-homing. ULAs internally, plus SADR for externally provided prefixes when = multihomed and multiaddressed. This has been demonstrated 3 or 4 IETFs = ago in the siderooms/bits=92n=92bites sessions. I think there=92s an = architecture doc around somewhere about it... Tim= From nobody Wed May 28 05:35:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA291A0971 for ; Wed, 28 May 2014 05:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTDF2v4L1YZz for ; Wed, 28 May 2014 05:35:36 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 481911A0928 for ; Wed, 28 May 2014 05:35:36 -0700 (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 5D77C1B8032 for ; Wed, 28 May 2014 05:35:32 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 5719A19005C; Wed, 28 May 2014 05:35:32 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 May 2014 05:35:32 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Wed, 28 May 2014 08:35:28 -0400 Content-Transfer-Encoding: 7bit Message-ID: <131B222A-1ECC-405D-A709-120ED7755FFE@nominum.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <9255C827-9F28-4E4E-9A2E-A678ADFACDAF@steffann.nl> <53854E87.9020500@gmail.com> <5385651B.7090604@gmail.com> To: Tim Chown X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rAruoC09n2F5A7KpPG3A2M-lm08 Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 12:35:38 -0000 On May 28, 2014, at 5:50 AM, Tim Chown wrote: > Three RFCs emerged, see http://datatracker.ietf.org/wg/6renum/ There were, unfortunately, lots of interesting gaps... :) From nobody Wed May 28 05:38:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57FE1A0064 for ; Wed, 28 May 2014 05:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8UaWvkl0-f3 for ; Wed, 28 May 2014 05:38:33 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F0261A00EA for ; Wed, 28 May 2014 05:38:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id B13D156; Wed, 28 May 2014 14:38:28 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1pTAFAVoqSp; Wed, 28 May 2014 14:38:20 +0200 (CEST) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTPSA id 1861837; Wed, 28 May 2014 14:38:19 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Sander Steffann In-Reply-To: Date: Wed, 28 May 2014 14:38:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0ED911FA-D24C-4FC8-9D6A-F38F9711F115@steffann.nl> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Ii4iu-kAAr-kou35mM9UzFbIOfI Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 12:38:35 -0000 Hi Mikael, > We should spend more time on getting renumbering working properly. = Having all Enterprise get PI space will make the routing system melt = down. Either that, or coming up with a routing protocol that can handle the = number of prefixes.. Cheers, Sander From nobody Wed May 28 05:40:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C9E1A097B for ; Wed, 28 May 2014 05:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2S7XG5liM3U for ; Wed, 28 May 2014 05:40:30 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0BE1A0966 for ; Wed, 28 May 2014 05:40:30 -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 s4SCePej010983; Wed, 28 May 2014 13:40:25 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s4SCePej010983 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1401280825; bh=JArYUxd3anXmB0ypwPiY9uNSF9M=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=1hSAHaSCu6s4p+KVaZe4gZmsS7u2Gp8sO/CCzIF/jWtUo6HTCD2aZPHIM0eKXDdYM KXOmYqvVpfLx7mnaGbPGY+SgIf9+4z5inMbVGSgFep9HwVyHNqgipr6zEOvW4dBPbB DePJY0ue04uZ5dtSejrD49bO0MmL//ijRyR+1PY0= 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 q4RDeP0546021927Ql ret-id none; Wed, 28 May 2014 13:40:25 +0100 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s4SCeOUi001727 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 May 2014 13:40:25 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Chown In-Reply-To: <0ED911FA-D24C-4FC8-9D6A-F38F9711F115@steffann.nl> Date: Wed, 28 May 2014 13:40:24 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> <0ED911FA-D24C-4FC8-9D6A-F38F9711F115@steffann.nl> <98EB60B3-E979-4CFB-86F9-94F08B2C95E7@ecs.soton.ac.uk> To: Sander Steffann X-Mailer: Apple Mail (2.1878.2) X-smtpf-Report: sid=q4RDeP054602192700; tid=q4RDeP0546021927Ql; 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: s4SCePej010983 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/EyqB5RELwmjZ8Ler4W_KeDkYdDk Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 12:40:32 -0000 On 28 May 2014, at 13:38, Sander Steffann wrote: > Hi Mikael, >=20 >> We should spend more time on getting renumbering working properly. = Having all Enterprise get PI space will make the routing system melt = down. >=20 > Either that, or coming up with a routing protocol that can handle the = number of prefixes.. You may still need renumbering tools even without changing provider. tim From nobody Wed May 28 05:48:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B173A1A0972 for ; Wed, 28 May 2014 05:48:44 -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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuh9eMXON1qY for ; Wed, 28 May 2014 05:48:43 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A276F1A0383 for ; Wed, 28 May 2014 05:48:42 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from vpn-254.int.inex.ie (vpn-254.int.inex.ie [193.242.111.254]) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s4SCmaUu044722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 28 May 2014 13:48:37 +0100 (IST) (envelope-from nick@foobar.org) Message-ID: <5385DB24.8070107@foobar.org> Date: Wed, 28 May 2014 13:48:36 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Sander Steffann , Mikael Abrahamsson References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> <0ED911FA-D24C-4FC8-9D6A-F38F9711F115@steffann.nl> In-Reply-To: <0ED911FA-D24C-4FC8-9D6A-F38F9711F115@steffann.nl> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Q-cJz_HXIhoBoA6XWPvQ1GYFG0s Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 12:48:44 -0000 On 28/05/2014 13:38, Sander Steffann wrote: > Either that, or coming up with a routing protocol that can handle the number of prefixes.. it's not the routing protocol that matters but the FIB capacity on the routers. Churn and RIB size are not causing problems. Nick From nobody Wed May 28 07:16:27 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E7F1A09C8 for ; Wed, 28 May 2014 07:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCSMm0ai_Gyv for ; Wed, 28 May 2014 07:16:10 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137B01A014A for ; Wed, 28 May 2014 07:16:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s4SEG14B017169; Wed, 28 May 2014 07:16:01 -0700 Received: from XCH-PHX-511.sw.nos.boeing.com (xch-phx-511.sw.nos.boeing.com [10.57.37.28]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s4SEFojK016830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 28 May 2014 07:15:51 -0700 Received: from XCH-BLV-104.nw.nos.boeing.com (130.247.25.120) by XCH-PHX-511.sw.nos.boeing.com (10.57.37.28) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 28 May 2014 07:15:49 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-BLV-104.nw.nos.boeing.com ([169.254.4.243]) with mapi id 14.03.0181.006; Wed, 28 May 2014 07:15:48 -0700 From: "Templin, Fred L" To: Tim Chown , Brian E Carpenter Thread-Topic: [v6ops] Fragments [ULA draft revision #2 Regarding isolated networks] Thread-Index: AQHPelc3tRwXeugDckevBPuYoqC0+JtWCYEQ Date: Wed, 28 May 2014 14:15:48 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2B5F33@XCH-BLV-504.nw.nos.boeing.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.thmulti.com> <20140527222313.7B12716B8D59@rock.dv.isc.org> <53851236.8020209@bogus.com> <5385522F.40305@gmail.com> <4BA71D7E-7A38-4327-8C7D-7E49F047CDDB@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: [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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XU9FEVZHPSqwoggT4IT68osCY10 Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] Fragments [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 14:16:19 -0000 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Tim Chown > Sent: Wednesday, May 28, 2014 2:28 AM > To: Brian E Carpenter > Cc: Philip Homburg; v6ops WG > Subject: Re: [v6ops] Fragments [ULA draft revision #2 Regarding isolated = networks] >=20 >=20 > On 28 May 2014, at 04:04, Brian E Carpenter = wrote: >=20 > > On 28/05/2014 10:31, joel jaeggli wrote: > >> On 5/27/14, 3:23 PM, Mark Andrews wrote: > >>> In message <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.th= multi.com>, Wuyts Carl > writes: > >>>> And what's next ? Stop path MTU discovery support ? Allow Fragment= ation again ? Anything else > ? > >>>> If we start mimic IPv4 fully, we're really going the wrong way .... = (my personal opinion of > course) > >>> Please state clearly the RFC which disallows fragmentation? > >>> Hint: There isn't one. > >> > >> you know he's referring to intermediate fragmentation... > >> > >> http://tools.ietf.org/html/rfc2460#section-5 > >> > >>> Fragmentation is a BASIC part of IPv6. It is done in the sending > >>> host rather than in the core of the network but it is DONE!!!!! > >> > >> yes. > > > > But see http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop > > for a dose of reality. >=20 > Tests that Fernando and I reported at the last IEPG show around 50% of th= e Alexa top 1m sites which > support IPv6 also drop frags. Tests for other types of EH are far from e= ncouraging too. Then, how are we ever going to support tunnels over IPv6? Thanks - Fred fred.l.templin@boeing.com > Tim >=20 > > > > Brian > > > >> > >>>> Regs > >>>> Carl > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Nick Hillia= rd > >>>> Sent: dinsdag 27 mei 2014 15:31 > >>>> To: Ted Lemon; Philip Homburg > >>>> Cc: v6ops WG > >>>> Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networ= ks > >>>> > >>>> On 27/05/2014 13:52, Ted Lemon wrote: > >>>>> If those ULAs happen to clash, you have to renumber at least one of= them. > >>>> or use NAT. I'm not saying this in order to throw fuel on an existi= ng fire, but simply because > this is the reality fo > >>>> r many organisations in the > >>>> ipv4 world, and I see little reason why it will change for ipv6. Th= e IETF can make > recommendations about whether it t > >>>> hinks this is a good idea or not, but it is not productive to preten= d that the elephant isn't in > the room. > >>>> > >>>> 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 > >> > >> > >> > >> ----------------------------------------------------------------------= -- > >> > >> _______________________________________________ > >> 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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed May 28 07:23:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2C81A0125 for ; Wed, 28 May 2014 07:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MN-SANsFfqwo for ; Wed, 28 May 2014 07:23:19 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id E4F881A0119 for ; Wed, 28 May 2014 07:23:18 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1Wpel8-0000BZC; Wed, 28 May 2014 16:23:14 +0200 Message-Id: To: v6ops WG From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.thmulti.com> <20140527222313.7B12716B8D59@rock.dv.isc.org> <53851236.8020209@bogus.com> <5385522F.40305@gmail.com> <4BA71D7E-7A38-4327-8C7D-7E49F047CDDB@ecs.soton.ac.uk> <2134F8430051B64F815C691A62D983181B2B5F33@XCH-BLV-504.nw.no s.boeing.com> In-reply-to: Your message of "Wed, 28 May 2014 14:15:48 +0000 ." <2134F8430051B64F815C691A62D983181B2B5F33@XCH-BLV-504.nw.nos.boeing.com> Date: Wed, 28 May 2014 16:23:14 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/JsUcuEvuyAyPtOuw-7tkz9JKbFw Subject: Re: [v6ops] Fragments [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 14:23:21 -0000 In your letter dated Wed, 28 May 2014 14:15:48 +0000 you wrote: >> Tests that Fernando and I reported at the last IEPG show around 50% of the Alexa top >1m sites which >> support IPv6 also drop frags. Tests for other types of EH are far from encouraging t >oo. > >Then, how are we ever going to support tunnels over IPv6? Measurements using RIPE Atlas suggest that most filtering is done near the edges. So if you want a tunnel, make sure that your site and the remote site don't do that kind of filtering. In addition, fragmentation involving DNS seems to work way better than sending fragmented packets to the Alexa top 1m sites. So the kind of filtering you encounter may also depend on where you look. From nobody Wed May 28 07:37:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F211A09A8 for ; Wed, 28 May 2014 07:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.662 X-Spam-Level: X-Spam-Status: No, score=-3.662 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8M71jIQlXqr for ; Wed, 28 May 2014 07:36:55 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC1111A0153 for ; Wed, 28 May 2014 07:36:51 -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 s4SEakdO019445; Wed, 28 May 2014 15:36:46 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s4SEakdO019445 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1401287806; bh=NpXOaCRbVDgvsLL7fa2ayNw5BEE=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=Sm61OB4/ub52PfKXBcpD4KYwHlm0n//snGF2a+yrVhOgt4vVZKt/Afmg8SLcjuduz eGODmAefSI9vBoI1t2Rwa0i84pmDszThb/1Rop1US5foOlB5UhZS2nd1uzTQHNsvlj Fn7GiWdAtXV/D02CLD5+D6faV0sNCYNQFU9jD+QU= 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 q4RFak05460236832A ret-id none; Wed, 28 May 2014 15:36:46 +0100 Received: from dhcp-207-135.wireless.soton.ac.uk (dhcp-207-135.wireless.soton.ac.uk [152.78.207.135] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s4SEakbG026540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 May 2014 15:36:46 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Chown In-Reply-To: Date: Wed, 28 May 2014 15:36:47 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.thmulti.com> <20140527222313.7B12716B8D59@rock.dv.isc.org> <53851236.8020209@bogus.com> <5385522F.40305@gmail.com> <4BA71D7E-7A38-4327-8C7D-7E49F047CDDB@ecs.soton.ac.uk> <2134F8430051B64F815C691A62D983181B2B5F33@XCH-BLV-! 504.nw.no s.boeing.com> <415376E7-9A8F-46CB-ABEA-FD86102DFACF@ecs.soton.ac.uk> To: Philip Homburg X-Mailer: Apple Mail (2.1878.2) X-smtpf-Report: sid=q4RFak054602368300; tid=q4RFak05460236832A; 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: s4SEakdO019445 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3HeOGxUWTRRKYSPC8IJVpGg0y4M Cc: v6ops WG Subject: Re: [v6ops] Fragments [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 14:37:04 -0000 Hi, On 28 May 2014, at 15:23, Philip Homburg = wrote: > In your letter dated Wed, 28 May 2014 14:15:48 +0000 you wrote: >>> Tests that Fernando and I reported at the last IEPG show around 50% = of the Alexa top=20 >> 1m sites which >>> support IPv6 also drop frags. Tests for other types of EH are far = from encouraging t >> oo. >>=20 >> Then, how are we ever going to support tunnels over IPv6? >=20 > Measurements using RIPE Atlas suggest that most filtering is done near = the edges. > So if you want a tunnel, make sure that your site and the remote site = don't do that > kind of filtering. >=20 > In addition, fragmentation involving DNS seems to work way better than = sending > fragmented packets to the Alexa top 1m sites. So the kind of filtering = you encounter > may also depend on where you look. Do you have a pointer to these results? Thanks, Tim= From nobody Wed May 28 07:37:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655841A0386 for ; Wed, 28 May 2014 07:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.852 X-Spam-Level: X-Spam-Status: No, score=-6.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AT5NvTuKBZAu for ; Wed, 28 May 2014 07:37:20 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1431A0153 for ; Wed, 28 May 2014 07:37:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s4SEbEvI021636; Wed, 28 May 2014 09:37:14 -0500 Received: from XCH-PHX-310.sw.nos.boeing.com (xch-phx-310.sw.nos.boeing.com [130.247.25.169]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s4SEbCSl021600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 28 May 2014 09:37:12 -0500 Received: from XCH-BLV-304.nw.nos.boeing.com (2002:82f7:19d8::82f7:19d8) by XCH-PHX-310.sw.nos.boeing.com (2002:82f7:19a9::82f7:19a9) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 28 May 2014 07:37:11 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-BLV-304.nw.nos.boeing.com ([169.254.4.139]) with mapi id 14.03.0181.006; Wed, 28 May 2014 07:37:11 -0700 From: "Templin, Fred L" To: Philip Homburg , v6ops WG Thread-Topic: [v6ops] Fragments [ULA draft revision #2 Regarding isolated networks] Thread-Index: AQHPeoBctRwXeugDckevBPuYoqC0+JtWDPmw Date: Wed, 28 May 2014 14:37:10 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2B6F86@XCH-BLV-504.nw.nos.boeing.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.thmulti.com> <20140527222313.7B12716B8D59@rock.dv.isc.org> <53851236.8020209@bogus.com> <5385522F.40305@gmail.com> <4BA71D7E-7A38-4327-8C7D-7E49F047CDDB@ecs.soton.ac.uk> <2134F8430051B64F815C691A62D983181B2B5F33@XCH-BLV-504.nw.no s.boeing.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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3IvBMFh-4A7vzZSZgDUFqMWawUM Subject: Re: [v6ops] Fragments [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 14:37:22 -0000 Hi Philip, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Philip Homburg > Sent: Wednesday, May 28, 2014 7:23 AM > To: v6ops WG > Subject: Re: [v6ops] Fragments [ULA draft revision #2 Regarding isolated = networks] >=20 > In your letter dated Wed, 28 May 2014 14:15:48 +0000 you wrote: > >> Tests that Fernando and I reported at the last IEPG show around 50% of= the Alexa top > >1m sites which > >> support IPv6 also drop frags. Tests for other types of EH are far fro= m encouraging t > >oo. > > > >Then, how are we ever going to support tunnels over IPv6? >=20 > Measurements using RIPE Atlas suggest that most filtering is done near th= e edges. > So if you want a tunnel, make sure that your site and the remote site don= 't do that > kind of filtering. Interesting, but I'm not sure how that would play for "opportunistic" tunnels where there may not be a way to manipulate the filters at the remote site.=20 > In addition, fragmentation involving DNS seems to work way better than se= nding > fragmented packets to the Alexa top 1m sites. So the kind of filtering yo= u encounter > may also depend on where you look. OK. But additionally in the tunnel case we need IPv6 fragmentation to work across whatever opportunistic path the tunnel happens to traverse. Thanks - Fred fred.l.templin@boeing.com =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed May 28 08:16:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D3E1A09F6 for ; Wed, 28 May 2014 08:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9P77UQQR9JJ for ; Wed, 28 May 2014 08:16:38 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 6954B1A09E1 for ; Wed, 28 May 2014 08:16:36 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1Wpfah-0000DjC; Wed, 28 May 2014 17:16:31 +0200 Message-Id: To: v6ops WG From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <96747494E3D74D41B20907035DB1E48D335AAB3D@MOPESMBX03.eu.thmulti.com> <20140527222313.7B12716B8D59@rock.dv.isc.org> <53851236.8020209@bogus.com> <5385522F.40305@gmail.com> <4BA71D7E-7A38-4327-8C7D-7E49F047CDDB@ecs.soton.ac.uk> <2134F8430051B64F815C691A62D983181B2B5F33@XCH-BLV-! 504.nw. no s.boeing.com> <415376E7-9A8F-46CB-ABEA-FD86102DFACF@ecs.soton.ac.uk> In-reply-to: Your message of "Wed, 28 May 2014 15:36:47 +0100 ." Date: Wed, 28 May 2014 17:16:31 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/nvEcpdsrGKndYO5FQd27bTEQfGY Subject: Re: [v6ops] Fragments [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 15:16:40 -0000 In your letter dated Wed, 28 May 2014 15:36:47 +0100 you wrote: >> Measurements using RIPE Atlas suggest that most filtering is done near = >the edges. >> So if you want a tunnel, make sure that your site and the remote site = >don't do that >> kind of filtering. >>=20 >> In addition, fragmentation involving DNS seems to work way better than = >sending >> fragmented packets to the Alexa top 1m sites. So the kind of filtering = >you encounter >> may also depend on where you look. > >Do you have a pointer to these results? I'm not aware of any measurements using RIPE Atlas that sent fragmented traffic to the Alexa top 1m. In general, TCP does not generate that kind of traffic so it doesn't seem to be a real world scenario. The people from NLnetlabs did use Atlas to look at fragmentation in the context of DNS. The main publication is https://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf Section 5.4 provides an analysis of where blocks happen. Other measurements using ICMP get in the same ballpark as the DNS results. https://labs.ripe.net/Members/emileaben/ripe-atlas-packet-size-matters It is possible to directly run PMTU experiments on Atlas, but as far as I know nobody reported on that. From nobody Wed May 28 08:35:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400901A03DE for ; Wed, 28 May 2014 08:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.641 X-Spam-Level: X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, LOTS_OF_MONEY=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9NdEd3H4JiB for ; Wed, 28 May 2014 08:35: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 452E31A0366 for ; Wed, 28 May 2014 08:35:16 -0700 (PDT) Received: from [IPv6:2620::930:0:225:ff:fe44:af17] ([IPv6:2620:0:930:0:225:ff:fe44:af17]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s4SFTDo8009533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 May 2014 08:29:14 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s4SFTDo8009533 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1401290954; bh=OUXDhGQhZJyygo4UB5mOahCK8io=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=aJo3UOboJRIps7kl5nvA0tN+tlZt6h643Bg90+F8X92N4xDDHPVG4rkVF0UYVPPS3 okRH7JeszXHeBbr0zw2lAYrCcCXiDbbAE5xk2bCQ9Lopp7nLTQHc0BBhRlG3Z2cGhN 6FRzImAceS3mJQjqS2M1G5e+YNPyiBYx1xhuIs98= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <5385AA97.1050207@fud.no> Date: Wed, 28 May 2014 08:32:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6740CB67-2CE3-4F41-A513-971C3307975D@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> To: Tore Anderson X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 28 May 2014 08:29:14 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QNPycYODU1xyFw3NQvO1KyYdTAA Cc: V6 Ops List Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 15:35:18 -0000 On May 28, 2014, at 2:21 AM, Tore Anderson wrote: > * Doug Barton >=20 >> We have a substantial number of medium-sized enterprises which share = the=20 >> following characteristics: >>=20 >> 1. They are large enough to have some internal resources that need=20 >> addressing (printers, file servers, maybe a web site or two) >>=20 >> 2. They are small enough that PI space and their own ASN are not = practical >=20 > You don=92t need an ASN to use PI space. Except possibly in the APNIC region due to previously discussed very = high fees, I=92m not sure why you think PI space is not practical for small = organizations. I=92ve set up multi homed connections for a number of small businesses, = including even some one-man operations with gross revenues under US $250,000 annually. >=20 >> 3. Some of them want to have multiple service providers, either for=20= >> failover or traffic shaping >>=20 Which makes an ASN and a PI prefix the easiest tactic possible. (Even easier than NAT, really.) >> 4. They don't want to have to renumber all of their internal = resources=20 >> when they change providers >>=20 >> What's your solution for them? >=20 > We have a few customers in the same situation. So we obtained a PI > prefix for them, which costs next to nothing in the RIPE region at > least, and advertise the prefix on their behalf (and in the cases = where > there's a second upstream, the second upstream does the same). Works > perfectly well, and is much less complex than anything solution > involving ULA, NAT, multiple prefixes on the hosts, or whatever. The > customer just gets a bunch of addresses he can use in perpetuity. Exactly, but it does have the drawback of black holing traffic in = certain failure modes. If you really want to avoid an ASN (not sure why), it is possible to do this using a private ASN that is stripped off by the upstream provider(s), but using a real ASN is much simpler. Owen From nobody Wed May 28 13:40:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C5A1A024B for ; Wed, 28 May 2014 13:40:05 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ch-yyRsLEAtM for ; Wed, 28 May 2014 13:40:04 -0700 (PDT) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9838C1A0246 for ; Wed, 28 May 2014 13:40:04 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id rr13so11714842pbb.7 for ; Wed, 28 May 2014 13:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qxQBX9axxzPMXMVjSXPwxPtqbPf9CODOU9Br6Wg83yA=; b=TTg/01MQRboAc7QMvqCD4xNnFgfHSsIVyv40VFPChqs8QZBYWrfQVKZRvNmAj/7WvX 8dix3XQ8azvCQcHSZWj7WKtut7Y5A58Xysp8CES291GWfek0zF1P5ar2VZTiorLlEIwp 3/eU5x+nCeypnduXvCDDqy33tpj0E6upy51gzBr6yVBV33Yj74GjK987QOOjKfkkVyWX HgVr4Dnfu0/wTYihewmZbH/15QE4bostkiDGbCDWBkYXkURia7T2yjgap9N11kY1IOhr qsBiOo0A5DW0PH6gZb6uHm3aug1bpIa9/sg9FEK8npF+G3rbHT+LywLYRyAlZ/cL4FAl 0YJA== X-Received: by 10.68.237.33 with SMTP id uz1mr2815798pbc.76.1401309601104; Wed, 28 May 2014 13:40:01 -0700 (PDT) Received: from [192.168.178.23] (209.199.69.111.dynamic.snap.net.nz. [111.69.199.209]) by mx.google.com with ESMTPSA id yv7sm93405937pac.33.2014.05.28.13.39.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 13:40:00 -0700 (PDT) Message-ID: <538649A4.6010103@gmail.com> Date: Thu, 29 May 2014 08:40:04 +1200 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: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> <53855130.8040105@gmail.com> <53856628.2070201@gmail.com> <4042F444-2A43-499C-823E-52BCDEF112CE@nominum.com> In-Reply-To: <4042F444-2A43-499C-823E-52BCDEF112CE@nominum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/cJKMDKMMchNUfK1eeA3wAQuku8g Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] Routing /48s [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 20:40:05 -0000 On 29/05/2014 00:21, Ted Lemon wrote: > On May 28, 2014, at 12:29 AM, Brian E Carpenter wrote: >> On the other hand, and I speak from experience, persuading IT departments >> to support SADR is harder than persuading them to allow multiple prefixes. > > Do we have implementations we could in theory try to persuade them to run? I was referring to SADR in a site border router that leads to two different ISPs. That, I understand, is readily available but requires extra config and extra cycles. SADR for a host to select the next hop indeed needs new stuff, afaik. Brian From nobody Wed May 28 13:57:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A8D1A0461 for ; Wed, 28 May 2014 13:57:49 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glaoteimgdvG for ; Wed, 28 May 2014 13:57:47 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509F21A022D for ; Wed, 28 May 2014 13:57:47 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rp16so11721307pbb.6 for ; Wed, 28 May 2014 13:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+TXiSk2PMpzeC5Hops5p5JMZcQtc97HwL1dyslLURGM=; b=YtuCJ41Q9Evx7YOJWgQNsLrm7sthpKiv+CX7bj5QFJX9Ybrp6KGPYcBtULnv5wia2t fnrgj/FU5slRg29YGMd2cSpfDu478XfGuMxqgijwrAvcEAbzgw7Bduw3l0ODjukvWWvd 1amrTkKB1hCIQ/o9EZadVnf5YOx4Bd9uQ6Zv6b00KH4P0qgLYFf3JplF50Yz0B9soa4T ZMEkMvEIgMbbzuT+8HQSoaqVU6uC0VUAoklqOmejB30TBTlR4uY0Gr4w/eXpbafM6db8 i2d2b6JzbDcW++CtDersuLVsdVYiFUZodFKG3bt0sQKwxTxrcb3HRAk9iz2vBH0m3x9h JRxA== X-Received: by 10.66.188.80 with SMTP id fy16mr2676432pac.85.1401310663785; Wed, 28 May 2014 13:57:43 -0700 (PDT) Received: from [192.168.178.23] (209.199.69.111.dynamic.snap.net.nz. [111.69.199.209]) by mx.google.com with ESMTPSA id ko10sm29880698pbd.52.2014.05.28.13.57.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 13:57:43 -0700 (PDT) Message-ID: <53864DCB.5070202@gmail.com> Date: Thu, 29 May 2014 08:57:47 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tore Anderson References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> In-Reply-To: <5385AA97.1050207@fud.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/uspLm-ciwNVpuKmN2ZDnJzSPTbA Cc: V6 Ops List Subject: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 20:57:50 -0000 Tore, On 28/05/2014 21:21, Tore Anderson wrote: > * Doug Barton > >> We have a substantial number of medium-sized enterprises which share the >> following characteristics: >> >> 1. They are large enough to have some internal resources that need >> addressing (printers, file servers, maybe a web site or two) >> >> 2. They are small enough that PI space and their own ASN are not practical > > You don't need an ASN to use PI space. > >> 3. Some of them want to have multiple service providers, either for >> failover or traffic shaping >> >> 4. They don't want to have to renumber all of their internal resources >> when they change providers >> >> What's your solution for them? > > We have a few customers in the same situation. So we obtained a PI > prefix for them, The important words there are "a few". As long as the numbers are reasonable, this scales. When the numbers cease to be reasonable, it doesn't scale. The estimate I made some years ago, based on a little research into statistics in a few countries, was that there must be about 10 million small or medium enterprises in the world. We don't know how to route 10M prefixes in BGP-4. So somewhere between "PI for a few customers" and "PI for every enterprise", we have to stop. See the RRG archives. Brian which costs next to nothing in the RIPE region at > least, and advertise the prefix on their behalf (and in the cases where > there's a second upstream, the second upstream does the same). Works > perfectly well, and is much less complex than anything solution > involving ULA, NAT, multiple prefixes on the hosts, or whatever. The > customer just gets a bunch of addresses he can use in perpetuity. > > Tore, > who prefers to KISS > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > . > From nobody Wed May 28 14:25:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311E41A065F for ; Wed, 28 May 2014 14:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toZxPtX1v2rd for ; Wed, 28 May 2014 14:25:03 -0700 (PDT) Received: from nm23-vm1.bullet.mail.bf1.yahoo.com (nm23-vm1.bullet.mail.bf1.yahoo.com [98.139.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357611A0686 for ; Wed, 28 May 2014 14:25:03 -0700 (PDT) Received: from [66.196.81.174] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 28 May 2014 21:24:59 -0000 Received: from [98.139.212.220] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 28 May 2014 21:24:59 -0000 Received: from [127.0.0.1] by omp1029.mail.bf1.yahoo.com with NNFMP; 28 May 2014 21:24:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 15587.22488.bm@omp1029.mail.bf1.yahoo.com Received: (qmail 42514 invoked by uid 60001); 28 May 2014 21:24:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1401312298; bh=lMI2NLvgerzFSb7j1J+iYKaXqtiXMRqgVRdwLjtz0BY=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=u/wq2Tn6sFtTVELVCemuiS8s7vja3Lbfi9ag6qjVOeTh2dG2i5onQjDzAyc8L0BTwyHKrNYGXYoDREuBANrv6kV/QFFkFVprydAGfdYEemZMLDj3dwtcu7B14hkITndzXGM+/5XvKOZy/d39WPuOAQAWMjmYuoXxPbjF1eRBjmg= X-YMail-OSG: TZJsRscVM1lSC7g.E.f_pi9rg3WmPK6ioA6kEARQqnacRGl ZttjPdl1BnCTfSLBaRrzC1J1QwT.G9tI8EQCbQin6.9NOJK64Lr5DpRhxM.s M5OOcMKGvraRHTv3jLSOE2.TYS.r.bBKhm.OXgMoAbMxdWGwecovqBj6KgvB YkibBuuba4IcKzDcYbipsNVwuXTGftTSantb1f45VYVusKkWwu_aJr3BY3DE PTcRfz.7ZEe2.ZWxpCgfz8IqLyyRO1hEA1GcJa6GMRBFxIqfgD9QyGXPkAFy dvlwPSpLj.40Fmc63RZ7lbCedk3kElEi5gJtpIjwshbO3q2aUMvrWzKBL54S EjwtDUrET.SYyaJHsaAOwDVzIsdm3_ejkQjykKDwOi1F4EAJ4Pq__5fhADRN HPbKginZpRpWhl9EjvK1_LsWaLe0EM6tx4QqlPVoK_di2ouZwoF_n9e0ScCC IMYAcl.KJ9Yf8dusDT6xyPrfn80z89yIRfrfYgTeq3MxNGpcbV6D41aIk4mZ IibC0aIqx3C3XiSTNXQfSe4w0o0oXH6xYuaYGxTz445CQMawbxxM9.EZ6yA- - Received: from [150.101.221.237] by web162205.mail.bf1.yahoo.com via HTTP; Wed, 28 May 2014 14:24:58 PDT X-Rocket-MIMEInfo: 002.001, SGkgQnJpYW4sCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPgo.VG86IE1hcmsgWlpaIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1PiAKPkNjOiBMaXViaW5nIChMZW8pIDxsZW8ubGl1YmluZ0BodWF3ZWkuY29tPjsgdjZvcHMgV0cgPHY2b3BzQGlldGYub3JnPiAKPlNlbnQ6IFdlZG5lc2RheSwgMjggTWF5IDIwMTQgMTI6MzMgUE0KPlN1YmplY3Q6IChyZSludW1iZXJpbmcgW1VMQSABMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com> <5383C2CF.6040205@gmail.com> <1401230263.69077.YahooMailNeo@web162206.mail.bf1.yahoo.com> <53854B03.8040702@gmail.com> Message-ID: <1401312298.99614.YahooMailNeo@web162205.mail.bf1.yahoo.com> Date: Wed, 28 May 2014 14:24:58 -0700 (PDT) From: Mark ZZZ Smith To: Brian E Carpenter In-Reply-To: <53854B03.8040702@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/JnRe7g_f8FWifbV7R8ljlr1WBb0 Cc: v6ops WG Subject: Re: [v6ops] (re)numbering [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 21:25:04 -0000 Hi Brian,=0A=0A>________________________________=0A> From: Brian E Carpente= r =0A>To: Mark ZZZ Smith =0A>Cc: Liubing (Leo) ; v6ops WG =0A>Sent: Wednesday, 28 May 2014 12:33 PM=0A>Subject: (re)numbering [= ULA draft revision #2 Regarding isolated networks]=0A> =0A>=0A>Hi Mark,=0A>= =0A=0A=0A=0A=0A>industry.=0A>=0A>> The other reason is that I've actu= ally seen a residential CPE try to swap between global addresses and ULAs. = I deal with a number of residential IPv6 CPE vendors in around 2009, and on= e of them had attempted to support ULAs, but had not done a good job of it.= When the global prefix went away because the WAN link failed, the CPE woul= d try to both flush the global prefix by setting a 0 valid liftime (or simi= lar, I can't quite recall) and replace it with a ULA in the RAs on the LAN = side. When the WAN link came back, it tried to do the opposite. When I prov= ided feedback to this vendor on this issue and others related to their IPv6= implementation, they just ignored it, unlike the other CPE vendors I was d= ealing with.=0A>=0A>That's horrible.=0A=0ACertainly was.=0A=0AWhile obvious= ly not correct behaviour, I think it shows that internal connectivity shoul= d be impervious to external connectivity changes and failures.=0A=0ARFC1918= s have provided that internal connectivity robustness to both home networks= and enterprise networks. Of course the drawback is that in IPv4 it is bina= ry - hosts either have RFC1918s or public addresses, so if you have RFC1918= s you have to use NAT to access external destinations on the Internet.=0A= =0AFortunately in IPv6 we can support both=A0ULAs + Globals concurrently, h= aving both independent internal connectivity as well as global connectivity= , which is why I think there is a lot of value in a network (home net or en= terprise) having ULA addressing for internal reachability, regardless of wh= ether it is isolated or not from the Internet. ULAs reduce external depende= ncies, and I think doing that increases robustness (sure there is a cost, b= ut everything is a trade-off).=0A=0AThe use case I like to imagine is a hom= e user streaming a video from their NAS to their TV over their internal net= work. That should use ULAs so that a failure of their Internet connection/G= lobal addressing has no impact on watching their movie. If the movie failed= because the Internet connection/global addressing failed, that user will c= all the ISP's helpdesk. But why should it fail! The home users internal net= work is fine, it is only external connectivity that has failed.=A0=0A=0APeo= ple might argue that enterprise networks are different and they are - they'= re simpler! Enterprise networks have technical staff on hand that can troub= leshoot networks and resolve faults. If you can make IPv6 work seamlessly f= or home networks and their non-technical "operators", you've solved the har= der problem. Since enterprise networks also value the same things home netw= orks do - seamless operation, robustness against failure, stable internal c= onnectivity, you've solved most of the enterprise network problems too.=0A= =0A> It doesn't conform to RFC 7084 either, which clearly=0A=0A>states that= "prefix(es) (and ULA prefix if configured...)" must=0A>be advertised.=0A>= =0A=0AThe precursor to 7084 (6204) was in development at the time, but it w= ouldn't have helped because they were ignoring our feedback. (Another CPE v= endor was much better and almost too keen - they were sending me new softwa= re to test within 24 hours after reporting an IPv6 issue.)=0A=0ARegards,=0A= Mark. From nobody Wed May 28 14:52:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A964A1A06BB for ; Wed, 28 May 2014 14:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHRaCWnG3DY5 for ; Wed, 28 May 2014 14:52:45 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88CF61A0282 for ; Wed, 28 May 2014 14:52:45 -0700 (PDT) Received: from [2a02:fe0:c410:3310::3] (port=35752 helo=wrath.fud.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Wplm2-0004r6-Pe; Wed, 28 May 2014 23:52:38 +0200 Message-ID: <53865AA6.2080905@fud.no> Date: Wed, 28 May 2014 23:52:38 +0200 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Owen DeLong References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <6740CB67-2CE3-4F41-A513-971C3307975D@delong.com> In-Reply-To: <6740CB67-2CE3-4F41-A513-971C3307975D@delong.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/b68onkauZiyeq6wFjJb0hq97qiY Cc: V6 Ops List Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 21:52:47 -0000 * Owen DeLong > On May 28, 2014, at 2:21 AM, Tore Anderson wrote: > >> We have a few customers in the same situation. So we obtained a PI >> prefix for them, which costs next to nothing in the RIPE region at >> least, and advertise the prefix on their behalf (and in the cases >> where there's a second upstream, the second upstream does the >> same). Works perfectly well, and is much less complex than >> anything solution involving ULA, NAT, multiple prefixes on the >> hosts, or whatever. The customer just gets a bunch of addresses he >> can use in perpetuity. > > Exactly, but it does have the drawback of black holing traffic in > certain failure modes. If the upstream starts blackholing in his core network somewhere and the customer is singlehoming, he's toast no matter how he's connected to the upstream. If he's multihoming, however, he can just physically pull the plug or shut the interface and traffic converges on the remaining good upstream, in pretty much in the same way it would if he used BGP. Of course, if the problematic upstream provider doesn't withdraw the BGP announcement when the customer shuts his interface then there's still going to be a problem, but that's equally true both for connections with or without BGP between the provider and the customer. Blackholing of traffic during failure modes is something you can get with any form of deployment. The way I see it, the use of BGP or non-use of BGP doesn't really change the risks of this happening either for the worse or the better. So I don't quite see why you call this a Ğdrawbackğ. > If you really want to avoid an ASN (not sure why), it is possible to > do this using a private ASN that is stripped off by the upstream > provider(s), but using a real ASN is much simpler. It's not I who want to avoid it, it's the end user. He doesn't necessarily know how internet routing works, how to set up or operate BGP, have equipment that can do so [without extra licences], and so forth. Even if he does, he might not want the extra bother. So the point isn't to avoid an ASN - if the customer is going to use BGP it's simpler with an ASN than without - but to avoid requiring BGP. Where the end user simply wants plain no bells-and-whistles internet service, but require addresses that work with >1 upstream provider simultaneously or which may be kept should he decide to switch providers in the future, using a PI prefix that his upstream(s) originate into the DFZ on his behalf is a really simple solution that actually works today both for IPv6 *and* IPv4 (if you have them, that is). It's much less complex than any solution I've seen that involves ULAs, NPT/NAT, BGP, multi-prefixes, or anything else, which makes it my preferred way of catering to the customers in question - for now. Tore From nobody Wed May 28 15:05:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C699D1A06CD for ; Wed, 28 May 2014 15:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHA0Bjek4duq for ; Wed, 28 May 2014 15:05:47 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2A7E1A06C2 for ; Wed, 28 May 2014 15:05:46 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1Wplyf-000806-Ut; Wed, 28 May 2014 22:05:42 +0000 Date: Thu, 29 May 2014 07:05:53 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <53864DCB.5070202@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NRlLEjMWfzOLKOOBV1xcYhKFcFc Cc: V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 22:05:49 -0000 > We don't know how to route 10M prefixes in BGP-4. i guess you have not seen large bgp-signaled vpns the point is not whether we know how to. the point is that we may prefer not to. but as in most frog boilings, this is not going to drop on us like a brick next tuesday. but this is a really smelly red herring. you are talking about replacing ula with real global addresses. they should not be globally announced anyway. randy From nobody Wed May 28 15:09:49 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD21A1A06C2 for ; Wed, 28 May 2014 15:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OESRiqGN8eF8 for ; Wed, 28 May 2014 15:09:43 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 543601A06A9 for ; Wed, 28 May 2014 15:09:43 -0700 (PDT) Received: from [2a02:fe0:c410:3310::3] (port=35768 helo=wrath.fud.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Wpm2U-0005D5-9o; Thu, 29 May 2014 00:09:38 +0200 Message-ID: <53865EA2.9000502@fud.no> Date: Thu, 29 May 2014 00:09:38 +0200 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brian E Carpenter References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> In-Reply-To: <53864DCB.5070202@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Z4JhzugnueY-6pwiRUGrrRBd8r0 Cc: V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 22:09:45 -0000 * Brian E Carpenter > Tore, > >> We have a few customers in the same situation. So we obtained a PI >> prefix for them, > > The important words there are "a few". As long as the numbers are > reasonable, this scales. When the numbers cease to be reasonable, > it doesn't scale. The estimate I made some years ago, based on > a little research into statistics in a few countries, was that > there must be about 10 million small or medium enterprises in the > world. We don't know how to route 10M prefixes in BGP-4. So > somewhere between "PI for a few customers" and "PI for every > enterprise", we have to stop. For sure, it is a very small minority of my customers who have this requirement. The vast majority are perfectly happy to be assigned prefixes out of my PA block. This goes for IPv4 too, BTW. I seriously doubt that a significant fraction of those 10M enterprises asking for a PI prefix (or multihoming at all) is a realistic scenario. So I'm not too worried about IPv6 PI to be honest, we survived IPv4 PI so far and I think we'll survive IPv6 PI also, even if adding a few "new" PI holders who in IPv4 multihomed using PA assignments from their upstreams + NAT44 + RFC1918. Especially if homenet comes up with an even more attractive solution than PI for that specific use case soon. Tore From nobody Wed May 28 15:37:48 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 298B21A0272 for ; Wed, 28 May 2014 15:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8AdNaOnCsYO for ; Wed, 28 May 2014 15:37:45 -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 2339F1A06F0 for ; Wed, 28 May 2014 15:37:45 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 3041E3493C3; Wed, 28 May 2014 22:37:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B5AA7160064; Wed, 28 May 2014 22:42:53 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 5357C160044; Wed, 28 May 2014 22:42:53 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 4849316CCFC0; Thu, 29 May 2014 08:30:20 +1000 (EST) To: Owen DeLong From: Mark Andrews References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <6740CB67-2CE3-4F41-A513-971C3307975D@delong.com> In-reply-to: Your message of "Wed, 28 May 2014 08:32:36 -0700." <6740CB67-2CE3-4F41-A513-971C3307975D@delong.com> Date: Thu, 29 May 2014 08:30:20 +1000 Message-Id: <20140528223020.4849316CCFC0@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/WOT51vUXaU4nuIEUorCk_O_WpII Cc: V6 Ops List , Tore Anderson Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 22:37:47 -0000 In message <6740CB67-2CE3-4F41-A513-971C3307975D@delong.com>, Owen DeLong write s: > > On May 28, 2014, at 2:21 AM, Tore Anderson wrote: > > > * Doug Barton > > > >> We have a substantial number of medium-sized enterprises which share > the > >> following characteristics: > >> > >> 1. They are large enough to have some internal resources that need > >> addressing (printers, file servers, maybe a web site or two) > >> > >> 2. They are small enough that PI space and their own ASN are not > practical > > > > You don't need an ASN to use PI space. > > Except possibly in the APNIC region due to previously discussed very high > fees, > I'm not sure why you think PI space is not practical for small > organizations. I've > set up multi homed connections for a number of small businesses, > including even > some one-man operations with gross revenues under US $250,000 annually. Because it is actually more error prone than ULA when you are not able to use the prefix for routing as there is no automatic built in support. Also running two GUA in parallel (PA + non-routeable PI) will be harder to debug. I realise that your PI is being routed. You are the exception here. This will actually encourage more NATPT or traditional NAT than ULA will as the defaults are right for ULA + PA. You are trading off P(collision) of epsilion when merging two ULA domains with a continual debugging and configuration issues. Every time you add a router you need to remember to filter this prefix to get ICMP unreachable returned. If you have multiple sites then you have lots of per site configuration. With ULA I can see fd..... and identify that it is a ULA address so I can easily see when a node is choosing the wrong address when debugging. Remember also homenet is doing SADR. It so there will be even more pressure to not announce yet another prefix as support for that gets added to the very low end CPE devices. If they can do it all the more professional devices will need to support it so there will be no escaping it. If you get to the stage where you can get a PI routed, then sure use that, but until you are at that stage non-routed PI is actually worse. > >> 3. Some of them want to have multiple service providers, either for > >> failover or traffic shaping > >> > > Which makes an ASN and a PI prefix the easiest tactic possible. > (Even easier than NAT, really.) > > >> 4. They don't want to have to renumber all of their internal resources > >> when they change providers > >> > >> What's your solution for them? > > > > We have a few customers in the same situation. So we obtained a PI > > prefix for them, which costs next to nothing in the RIPE region at > > least, and advertise the prefix on their behalf (and in the cases where > > there's a second upstream, the second upstream does the same). Works > > perfectly well, and is much less complex than anything solution > > involving ULA, NAT, multiple prefixes on the hosts, or whatever. The > > customer just gets a bunch of addresses he can use in perpetuity. > > Exactly, but it does have the drawback of black holing traffic in certain > failure modes. If you really want to avoid an ASN (not sure why), it is > possible to do this using a private ASN that is stripped off by the > upstream provider(s), but using a real ASN is much simpler. > > 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 nobody Wed May 28 17:11:56 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4151A06B0 for ; Wed, 28 May 2014 17:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ennexzlACr9d for ; Wed, 28 May 2014 17:11:52 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46B7C1A02AE for ; Wed, 28 May 2014 17:11:52 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1Wpnwc-0008OR-V7; Thu, 29 May 2014 00:11:43 +0000 Date: Thu, 29 May 2014 09:11:54 +0900 Message-ID: From: Randy Bush To: Sander Steffann In-Reply-To: <0ED911FA-D24C-4FC8-9D6A-F38F9711F115@steffann.nl> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> <0ED911FA-D24C-4FC8-9D6A-F38F9711F115@steffann.nl> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5T6a5fErdclvXTai7rlafeLi41M Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 00:11:53 -0000 >> We should spend more time on getting renumbering working >> properly. Having all Enterprise get PI space will make the routing >> system melt down. > Either that, or coming up with a routing protocol that can handle the > number of prefixes.. red herring. global prefixes designed to be used in place of ula should not be in the global routing table randy From nobody Wed May 28 20:33:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E2B1A07C8 for ; Wed, 28 May 2014 20:33:53 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoWkim3HTkRz for ; Wed, 28 May 2014 20:33:52 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB65E1A0729 for ; Wed, 28 May 2014 20:33:50 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id kq14so12046581pab.24 for ; Wed, 28 May 2014 20:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Dzl0Yzc5qU4yywk3pQy9KPg1j8gLvxAv7ZEz/0NR/Lg=; b=OntyOHk/iBHwRkh4Z7dKLA73IeOUCu5cEX+J8VTL8619CUY55QEDozjxfuUaX05pGH Rf2LiC7bOgKvWiRF1GxIY3v/rodfAe7nOoieOeG6v75Z3V21FAPdzs/cwwkRKc+d+udD Ae7SL+jg3PxZiVvCuNW+0Biho9FhOJVNmuGrkCl7TPt0yzOHt994MP3LJ/lA97RdlEBi E4ewwn6YQ5kwIB40BwvBnMYQtb9eCEzXleJGSY4ta9HzemRm+HJuol2s29Qeca3Oum3U i1mg0qJN0FykEj/ynr8soluvbEEKuzUPFwNu0aDDvjUfPN7HyegQ1oTNPP3KjCrDKMFx 7pZA== X-Received: by 10.68.99.194 with SMTP id es2mr5124807pbb.100.1401334427071; Wed, 28 May 2014 20:33:47 -0700 (PDT) Received: from [192.168.178.23] (209.199.69.111.dynamic.snap.net.nz. [111.69.199.209]) by mx.google.com with ESMTPSA id vn13sm21519606pab.8.2014.05.28.20.33.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 20:33:46 -0700 (PDT) Message-ID: <5386AA9F.7000001@gmail.com> Date: Thu, 29 May 2014 15:33:51 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Bush References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> <0ED911FA-D24C-4FC8-9D6A-F38F9711F115@steffann.nl> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/t6k_XO4u-DBGM0agJcAJICmEQRU Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 03:33:53 -0000 On 29/05/2014 12:11, Randy Bush wrote: >>> We should spend more time on getting renumbering working >>> properly. Having all Enterprise get PI space will make the routing >>> system melt down. >> Either that, or coming up with a routing protocol that can handle the >> number of prefixes.. > > red herring. global prefixes designed to be used in place of ula should > not be in the global routing table Indeed they shouldn't, but since everybody should be filtering ULAs (and most people will do so), ULAs won't propagate but routeable GUAs might. Brian From nobody Wed May 28 20:44:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1575A1A0729 for ; Wed, 28 May 2014 20:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-vrK_HsqDEK for ; Wed, 28 May 2014 20:43:58 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB0E11A04D2 for ; Wed, 28 May 2014 20:43:57 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WprFu-0000Wj-2U; Thu, 29 May 2014 03:43:50 +0000 Date: Thu, 29 May 2014 12:44:01 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <5386AA9F.7000001@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> <0ED911FA-D24C-4FC8-9D6A-F38F9711F115@steffann.nl> <5386AA9F.7000001@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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/H19jKqdXRLCoMDnv1rkms_DETo4 Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 03:43:59 -0000 >> red herring. global prefixes designed to be used in place of ula should >> not be in the global routing table > > Indeed they shouldn't, but since everybody should be filtering ULAs > (and most people will do so), ULAs won't propagate but routeable GUAs > might. explain why the two probability distributions will differ From nobody Wed May 28 21:00:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137921A0770 for ; Wed, 28 May 2014 21:00:32 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjV-K30xb0gv for ; Wed, 28 May 2014 21:00:30 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A90A71A02FC for ; Wed, 28 May 2014 21:00:30 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id fa1so12170327pad.39 for ; Wed, 28 May 2014 21:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=MrMNGFNO0Z1OAliQtSmcb+ZtmIQ+1C2h6b/NPLLLrcM=; b=yv1k+T9l0u5qZBwydUWLQzGwzUwsjOMO90Nlq3w15oj6Luzk6rlGW2qEykNCQBNCjO JN3Ll6zek4KLbBKt0NOVTlkkH2LO9UXCjGwGXXLoGBxHhBZDoRuMaep3mfZmhGdY2lDY J44ZDRN5P09VoQx8eeyx9CTGvjtRZIgfvS8CeklZ436s2rL8FFydug8uGGeOi8vZXv3u 0n+q5gOb36oJ55LlTBFs9LPxw1Ow1ConL4b4pi1nIPzwpJh34fCQz9PWhZKuxf1YPDru A57yTKjRoq4yIOmLKHmoCwReULNHXPqYpS1HuC5xRUW+5RgcaDCpGeH3zmesZbvTqEzC xbmg== X-Received: by 10.68.131.227 with SMTP id op3mr4981578pbb.87.1401336026966; Wed, 28 May 2014 21:00:26 -0700 (PDT) Received: from [192.168.178.23] (209.199.69.111.dynamic.snap.net.nz. [111.69.199.209]) by mx.google.com with ESMTPSA id rx10sm97634718pab.48.2014.05.28.21.00.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 21:00:26 -0700 (PDT) Message-ID: <5386B0DF.9060401@gmail.com> Date: Thu, 29 May 2014 16:00:31 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Bush References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> <0ED911FA-D24C-4FC8-9D6A-F38F9711F115@steffann.nl> <5386AA9F.7000001@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wZzUHk1FVEhSjEkyN62Ij8oAJJE Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 04:00:32 -0000 On 29/05/2014 15:44, Randy Bush wrote: >>> red herring. global prefixes designed to be used in place of ula should >>> not be in the global routing table >> Indeed they shouldn't, but since everybody should be filtering ULAs >> (and most people will do so), ULAs won't propagate but routeable GUAs >> might. > > explain why the two probability distributions will differ Because I have considerable confidence that the majority of transit operators will know they need to filter fc00::/7, but the same cannot be said of arbitrary /48s from RIR space. Brian From nobody Thu May 29 01:29:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24E91A0747 for ; Thu, 29 May 2014 01:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tR9uKFLa4qUz for ; Thu, 29 May 2014 01:29:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84AD61A078D for ; Thu, 29 May 2014 01:29:02 -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.7-GA FastPath queued) with ESMTP id BHJ25456; Thu, 29 May 2014 08:28:57 +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.3.158.1; Thu, 29 May 2014 09:28:22 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 09:28:55 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 29 May 2014 16:28:51 +0800 From: "Liubing (Leo)" To: v6ops WG Thread-Topic: ULA #3 NPTv6 Use Case Thread-Index: Ac97GAB2NXqeld5VTvWJRzzv6gdUWA== Date: Thu, 29 May 2014 08:28:50 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@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.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/g2SRiyZka7DKhi_9W8kYra2ZoYI Cc: "v6ops-chairs@tools.ietf.org" Subject: [v6ops] ULA #3 NPTv6 Use Case X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 08:29:04 -0000 Hi, All We're going to update the ULA draft. Before making a new version, I think i= t would be helpful to confirm/discuss several important topics which were d= iscussed in last IETF meeting.=20 I'd like to discuss the topics in different mail threads respectively. (Current draft link: http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-= recommendations-02) ***************************************************************************= *** #3 NPTv6 Use Case In current draft Section 3.2.1, there is an NPTv6 use case: "In some very constrained situations(for example, in the sensors), the network needs ULA as the on-demand and stable addressing which doesn't need much code to support address assignment mechanisms like DHCP or full ND (Note: surely it needs SLAAC). If the network also needs to connect to the outside, then there can be an NPTv6 gateway which is not subject to extreme resource constraints. Especially when a lightweight isolated network needs to add Internet connectivity, this is quite a straightforward and efficient way." This use case is not based on real experience, but an assumption that suppo= rting multiple prefixes might be a heavy burden for some resource-constrain= ed nodes such as sensors. Because it needs to store multiple addresses and = dealing with the address selection problem. Question 1: In last IETF meeting, Lorenzo questioned this assumption whether it is reas= onable. I'd like to hear opinions from you on this issue. If it's unreasona= ble, we'll move the use case out of the draft. Question 2: Besides the resource-constrained use case. There is another case which was = raised by Alex and has been talked a lot in 6man two months ago: one node i= s assigned a /64, and it is the gateway of multi-subnets. This might probab= ly happen in the 3GPP terminals. 3GPP R11 supports DHCP-PD, but former spec= ifications only support /64. Current networks just haven't implemented R11.= =20 Besides DHCP-PD, another solution for the multi-subnets is bridging them at= L2. But it is not feasible in some situations. For example, In a vehicle t= here might be numerous incompatible L2s. I think it is a reasonable use case to be documented. Question 3: This question is derived from Question 2. Current draft only refers NPTv6, = but might been other IPv6 NAT implementations available in the vehicle/IoT = networks. Shall we expand the "ULA+NPTv6" case to a generic "ULA+IPv6 NAT" = ? (Note: NPTv6 is the only standardized IPv6 NAT mechanism so far) . Regards, Bing From nobody Thu May 29 01:31:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E0C1A0747 for ; Thu, 29 May 2014 01:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PsaKw7_ONmL for ; Thu, 29 May 2014 01:31:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357D71A0100 for ; Thu, 29 May 2014 01:31:26 -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.7-GA FastPath queued) with ESMTP id BHJ25661; Thu, 29 May 2014 08:31: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.3.158.1; Thu, 29 May 2014 09:30:44 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 09:31:18 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 29 May 2014 16:31:10 +0800 From: "Liubing (Leo)" To: v6ops WG Thread-Topic: ULA #4 Refering Site-local addresses Thread-Index: Ac97GFDI5kn6NhSAQQSg5krJ9qqmJQ== Date: Thu, 29 May 2014 08:31:10 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7856@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.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/V0l_dkW9djqrdFujDP6BmmXQxdM Cc: "v6ops-chairs@tools.ietf.org" , "dthaler@microsoft.com" , "bill@wjcerveny.com" Subject: [v6ops] ULA #4 Refering Site-local addresses X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 08:31:31 -0000 Hi, All We're going to update the ULA draft. Before making a new version, I think i= t would be helpful to confirm/discuss several important topics which were d= iscussed in last IETF meeting.=20 I'd like to discuss the topics in different mail threads respectively. (Current draft link: http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-= recommendations-02) ***************************************************************************= *** # Refering Site-local addresses Bill and Dave suggested to refer site-local addresses. Because ULAs were in= tended to replace the gap left when site-local addresses were deprecated.=20 Especially, Dave mentioned the site-local address based anycast utilization= in former RFCs (e.g. RFC4339 to use site-local anycast as Recursive DNS di= scovery) and gave a pointer to the relevant stuff.=20 I think it is good to add some texts referring site-local address as a back= ground in the introduction Section. But for the site-local anycast use case, I think of it as out of the scope = of this ULA draft. Because as I understood, since the site-local is depreca= ted, the anycast use cases based on site-local are invalid as well. And it = is not a goal to re-produce these anycast use cases in a ULA form in a v6op= s document, so I just feel like there is nothing to say about it.=20 What are your thoughts? Regards, Bing From nobody Thu May 29 02:02:49 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38101A07DE for ; Thu, 29 May 2014 02:02:42 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsJWS6RYhxeZ for ; Thu, 29 May 2014 02:02:39 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53D41A079D for ; Thu, 29 May 2014 02:02:39 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id hn18so120292igb.6 for ; Thu, 29 May 2014 02:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fwJUr/IHnFAcQJ18RYjhNVE+qnRO1aw3uZESMRqMTN4=; b=aoQnj3GhtK2OHlkcIcBuecuMAn1RVObMyYFYgh/+KpNlUywTE66fZo6gVJN9MTs5Rx qXS8yMAJKiBlhFZu0dZm3w5a2wSCKg9BWBdlNtPcvv2dzfj/FFT1ZTX4fsO/DJ1Bik0t hd/Zb+S++XQURspIN3M0NLZ60smLoCkcFLK51z+A+mcSSmr+3gJBDJZTNazR4paA2OFR tYS8QmW+Kzibu2HxKzv3Rg2pmm0e37cx+O7MFhnXESpoHx3w9DFKSrUj7vdUdZmmNdM3 LYJJctKrNC9zvZ9vdMCGEgGLTTEo3KrHqGJsE8JWPbSdD7EBfaDKMWa2iOr/jbXxGXbb cfow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fwJUr/IHnFAcQJ18RYjhNVE+qnRO1aw3uZESMRqMTN4=; b=V9da13D4fibjEOulCbUQ0Y1JVjybfNSMlWLaFhZbIIUCRMEFSjvjlNl/ZW0W7FAn/u 9PDV4PXz/uuxsV+chwlklVBg421Cs5jt+ENDbBd4blwYyCCIbpcS+GVOifaBP6mvvK0W S+cXuuBnbV9J2jloIgHIfRkNUt3qGQ7UhSeWhK9kOJn9Zzbg3JnG7OHKhJqu5HvOxULH I/Sf5Ff0H7FNjKqIALWWLzdW9V1fleXcb9jte4iz/ad83/Ov9MPPukaBIS5qQBcMt66r fECRuNKgWCnAcPjEjkWsK82zQgljbm24WZMF+nd4BTS6aqRjpIxXvlOkEv7V9Q6m3x6X WTGA== X-Gm-Message-State: ALoCoQnozSgm2gvw/ACgbpJfnaVMLe6YDOu42YlyC8et41465/2CdWuGL5U7aVFAYRFK1Uz5YILj X-Received: by 10.50.129.104 with SMTP id nv8mr8352127igb.45.1401354155586; Thu, 29 May 2014 02:02:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.203 with HTTP; Thu, 29 May 2014 02:02:15 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> From: Lorenzo Colitti Date: Thu, 29 May 2014 18:02:15 +0900 Message-ID: To: "Liubing (Leo)" , "v6ops-chairs@tools.ietf.org" Content-Type: multipart/alternative; boundary=047d7b414174a6540604fa8630ff Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7K5PD5u2F2aV2NmoSwdMul5D4UM Cc: v6ops WG Subject: Re: [v6ops] ULA #3 NPTv6 Use Case X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 09:02:42 -0000 --047d7b414174a6540604fa8630ff Content-Type: text/plain; charset=UTF-8 Leo, Chairs, in March we had a 24-message discussion on this, with, I think, clear lack of consensus: http://www.ietf.org/mail-archive/web/v6ops/current/msg18741.html There was also a comment from then-chair John, pointing out an unresolved technical issue that I don't think was ever resolved: http://www.ietf.org/mail-archive/web/v6ops/current/msg18757.html Do we have to go through that discussion again? Has new information come to light on this issue? Is there reason to believe that the discussion will be any different now that two months have passed? If the answer to those questions is no, then I would like to propose that we avoid debating this issue, because we have already debated it multiple times, the last time quite recently, with - it seems to me - clear lack of consensus. I doubt that things will go any different this time around, and not having the debate and advancing the document would save the working group time. Thanks, Lorenzo On Thu, May 29, 2014 at 5:28 PM, Liubing (Leo) wrote: > Hi, All > > We're going to update the ULA draft. Before making a new version, I think > it would be helpful to confirm/discuss several important topics which were > discussed in last IETF meeting. > > I'd like to discuss the topics in different mail threads respectively. > (Current draft link: > http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02) > > ****************************************************************************** > > #3 NPTv6 Use Case > > In current draft Section 3.2.1, there is an NPTv6 use case: > "In some very constrained situations(for example, in the sensors), the > network needs ULA as the on-demand and stable addressing which > doesn't need much code to support address assignment mechanisms like > DHCP or full ND (Note: surely it needs SLAAC). If the network also > needs to connect to the outside, then there can be an NPTv6 gateway > which is not subject to extreme resource constraints. Especially when > a lightweight isolated network needs to add Internet connectivity, > this is quite a straightforward and efficient way." > > This use case is not based on real experience, but an assumption that > supporting multiple prefixes might be a heavy burden for some > resource-constrained nodes such as sensors. Because it needs to store > multiple addresses and dealing with the address selection problem. > > Question 1: > In last IETF meeting, Lorenzo questioned this assumption whether it is > reasonable. I'd like to hear opinions from you on this issue. If it's > unreasonable, we'll move the use case out of the draft. > > Question 2: > Besides the resource-constrained use case. There is another case which was > raised by Alex and has been talked a lot in 6man two months ago: one node > is assigned a /64, and it is the gateway of multi-subnets. This might > probably happen in the 3GPP terminals. 3GPP R11 supports DHCP-PD, but > former specifications only support /64. Current networks just haven't > implemented R11. > Besides DHCP-PD, another solution for the multi-subnets is bridging them > at L2. But it is not feasible in some situations. For example, In a vehicle > there might be numerous incompatible L2s. > > I think it is a reasonable use case to be documented. > > Question 3: > This question is derived from Question 2. Current draft only refers NPTv6, > but might been other IPv6 NAT implementations available in the vehicle/IoT > networks. Shall we expand the "ULA+NPTv6" case to a generic "ULA+IPv6 NAT" > ? (Note: NPTv6 is the only standardized IPv6 NAT mechanism so far) . > > Regards, > Bing > --047d7b414174a6540604fa8630ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Leo, Chairs,

in March we had a 24-messa= ge discussion on this, with, I think, clear lack of consensus: http://www= .ietf.org/mail-archive/web/v6ops/current/msg18741.html

There was also a comment from then-chair John, pointing= out an unresolved technical issue that I don't think was ever resolved= : http://www.ietf.org/mail-archive/web/v6ops/current/msg18757.html

Do we have to go through that discussion again? Has new= information come to light on this issue? Is there reason to believe that t= he discussion will be any different now that two months have passed?

If the answer to those questions is no, then I would li= ke to propose that we avoid debating this issue, because we have already de= bated it multiple times, the last time quite recently, with - it seems to m= e - clear lack of consensus. I doubt that things will go any different this= time around, and not having the debate and advancing the document would sa= ve the working group time.

Thanks,
Lorenzo


On Thu, May 29, 2014 at 5:28 PM= , Liubing (Leo) <leo.liubing@huawei.com> wrote:
Hi, All

We're going to update the ULA draft. Before making a new version, I thi= nk it would be helpful to confirm/discuss several important topics which we= re discussed in last IETF meeting.

I'd like to discuss the topics in different mail threads respectively.<= br> (Current draft link: http://tools.ietf.org/html= /draft-ietf-v6ops-ula-usage-recommendations-02)
***************************************************************************= ***

#3 NPTv6 Use Case

In current draft Section 3.2.1, there is an NPTv6 use case:
=C2=A0 "In some very constrained situations(for example, in the sensor= s), the
=C2=A0 =C2=A0network needs ULA as the on-demand and stable addressing which=
=C2=A0 =C2=A0doesn't need much code to support address assignment mecha= nisms like
=C2=A0 =C2=A0DHCP or full ND (Note: surely it needs SLAAC). If the network = also
=C2=A0 =C2=A0needs to connect to the outside, then there can be an NPTv6 ga= teway
=C2=A0 =C2=A0which is not subject to extreme resource constraints. Especial= ly when
=C2=A0 =C2=A0a lightweight isolated network needs to add Internet connectiv= ity,
=C2=A0 =C2=A0this is quite a straightforward and efficient way."

This use case is not based on real experience, but an assumption that suppo= rting multiple prefixes might be a heavy burden for some resource-constrain= ed nodes such as sensors. Because it needs to store multiple addresses and = dealing with the address selection problem.

Question 1:
In last IETF meeting, Lorenzo questioned this assumption whether it is reas= onable. I'd like to hear opinions from you on this issue. If it's u= nreasonable, we'll move the use case out of the draft.

Question 2:
Besides the resource-constrained use case. There is another case which was = raised by Alex and has been talked a lot in 6man two months ago: one node i= s assigned a /64, and it is the gateway of multi-subnets. This might probab= ly happen in the 3GPP terminals. 3GPP R11 supports DHCP-PD, but former spec= ifications only support /64. Current networks just haven't implemented = R11.
Besides DHCP-PD, another solution for the multi-subnets is bridging them at= L2. But it is not feasible in some situations. For example, In a vehicle t= here might be numerous incompatible L2s.

I think it is a reasonable use case to be documented.

Question 3:
This question is derived from Question 2. Current draft only refers NPTv6, = but might been other IPv6 NAT implementations available in the vehicle/IoT = networks. Shall we expand the "ULA+NPTv6" case to a generic "= ;ULA+IPv6 NAT" ? =C2=A0(Note: NPTv6 is the only standardized IPv6 NAT = mechanism so far) .

Regards,
Bing

--047d7b414174a6540604fa8630ff-- From nobody Thu May 29 02:32:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66901A0870 for ; Thu, 29 May 2014 02:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTaD9PS4DW55 for ; Thu, 29 May 2014 02:32:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BF171A0273 for ; Thu, 29 May 2014 02:32:30 -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.7-GA FastPath queued) with ESMTP id BHK02152; Thu, 29 May 2014 09:32:26 +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.3.158.1; Thu, 29 May 2014 10:31:51 +0100 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 10:32:25 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Thu, 29 May 2014 17:32:18 +0800 From: "Liubing (Leo)" To: Lorenzo Colitti , "v6ops-chairs@tools.ietf.org" Thread-Topic: ULA #3 NPTv6 Use Case Thread-Index: Ac97GAB2NXqeld5VTvWJRzzv6gdUWP//g0GA//93Q8A= Date: Thu, 29 May 2014 09:32:18 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B79AA@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@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.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B79AAnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/c6Od9loy_cd1MFIIxP9pZiQRsaI Cc: v6ops WG Subject: Re: [v6ops] ULA #3 NPTv6 Use Case X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 09:32:33 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B79AAnkgeml506mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KSSBrbm93IGRpc2N1c3Npb24gb24gUXVlc3Rpb24gMSAodGhlIHJlc291 cmNlLWNvbnN0cmFpbmVkIHVzZSBjYXNlKSB3YXMgY29udHJvdmVyc2lhbC4gSXQgaXMgb2sgZm9y IG1lIHRvIG1vdmUgaXQgb3V0LCBqdXN0IGEgY29uZmlybWF0aW9uIHRvIHRoZSBXRy4NCg0KUXVl c3Rpb24gMiAoM0dQUCB1c2UgY2FzZSkgaXMgYW5vdGhlciBjYXNlIHRoYXQgaGFzbuKAmXQgYmVl biBkaXNjdXNzZWQgaW4gdjZvcHMsIGJ1dCBoYWQgYSBkZWNlbnQgZGlzY3Vzc2lvbiBpbiA2bWFu LiBNeSBwZXJzb25hbCB0aG91Z2h0IGlzIGl0IHdvcnRoIHRvIGJlIGRvY3VtZW50ZWQuIChBZ2Fp biwganVzdCBkb2N1bWVudGluZyBpdCBhcyBhIHZhbGlkIGNhc2UsIG5vdCBwcm9tb3RpbmcgdG8g dXNlIElQdjYgTkFUKQ0KUXVlc3Rpb24gMyBpcyBqdXN0IGRlcml2ZWQgZnJvbSBRMiwgaWYgd2Ug YWdyZWUgdG8gZG9jdW1lbnQgdGhlIDNHUFAgTkFUIGNhc2UsIHRoZW4gaXQgbWlnaHQgYmUgYmV0 dGVyIG5vdCBiaW5kaW5nIHRvIHRoZSBzcGVjaWZpYyBOUFR2NiBtZWNoYW5pc20uDQoNCkkgYWxz byBhZ3JlZSB3ZSBzaG91bGQgZm9jdXMgb24gYWR2YW5jaW5nIHRoZSBkb2N1bWVudC4gVGhhbmsg eW91Lg0KDQoNClJlZ2FyZHMsDQpCaW5nDQoNCkZyb206IExvcmVuem8gQ29saXR0aSBbbWFpbHRv OmxvcmVuem9AZ29vZ2xlLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBNYXkgMjksIDIwMTQgNTowMiBQ TQ0KVG86IExpdWJpbmcgKExlbyk7IHY2b3BzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0KQ2M6IHY2 b3BzIFdHOyBBbGV4YW5kcnUgUGV0cmVzY3U7IEpvaG4gSmFzb24gQnJ6b3pvd3NraQ0KU3ViamVj dDogUmU6IFVMQSAjMyBOUFR2NiBVc2UgQ2FzZQ0KDQpMZW8sIENoYWlycywNCg0KaW4gTWFyY2gg d2UgaGFkIGEgMjQtbWVzc2FnZSBkaXNjdXNzaW9uIG9uIHRoaXMsIHdpdGgsIEkgdGhpbmssIGNs ZWFyIGxhY2sgb2YgY29uc2Vuc3VzOiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvdjZvcHMvY3VycmVudC9tc2cxODc0MS5odG1sDQoNClRoZXJlIHdhcyBhbHNvIGEgY29tbWVu dCBmcm9tIHRoZW4tY2hhaXIgSm9obiwgcG9pbnRpbmcgb3V0IGFuIHVucmVzb2x2ZWQgdGVjaG5p Y2FsIGlzc3VlIHRoYXQgSSBkb24ndCB0aGluayB3YXMgZXZlciByZXNvbHZlZDogaHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Y2b3BzL2N1cnJlbnQvbXNnMTg3NTcuaHRtbA0K DQpEbyB3ZSBoYXZlIHRvIGdvIHRocm91Z2ggdGhhdCBkaXNjdXNzaW9uIGFnYWluPyBIYXMgbmV3 IGluZm9ybWF0aW9uIGNvbWUgdG8gbGlnaHQgb24gdGhpcyBpc3N1ZT8gSXMgdGhlcmUgcmVhc29u IHRvIGJlbGlldmUgdGhhdCB0aGUgZGlzY3Vzc2lvbiB3aWxsIGJlIGFueSBkaWZmZXJlbnQgbm93 IHRoYXQgdHdvIG1vbnRocyBoYXZlIHBhc3NlZD8NCg0KSWYgdGhlIGFuc3dlciB0byB0aG9zZSBx dWVzdGlvbnMgaXMgbm8sIHRoZW4gSSB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgdGhhdCB3ZSBhdm9p ZCBkZWJhdGluZyB0aGlzIGlzc3VlLCBiZWNhdXNlIHdlIGhhdmUgYWxyZWFkeSBkZWJhdGVkIGl0 IG11bHRpcGxlIHRpbWVzLCB0aGUgbGFzdCB0aW1lIHF1aXRlIHJlY2VudGx5LCB3aXRoIC0gaXQg c2VlbXMgdG8gbWUgLSBjbGVhciBsYWNrIG9mIGNvbnNlbnN1cy4gSSBkb3VidCB0aGF0IHRoaW5n cyB3aWxsIGdvIGFueSBkaWZmZXJlbnQgdGhpcyB0aW1lIGFyb3VuZCwgYW5kIG5vdCBoYXZpbmcg dGhlIGRlYmF0ZSBhbmQgYWR2YW5jaW5nIHRoZSBkb2N1bWVudCB3b3VsZCBzYXZlIHRoZSB3b3Jr aW5nIGdyb3VwIHRpbWUuDQoNClRoYW5rcywNCkxvcmVuem8NCg0KT24gVGh1LCBNYXkgMjksIDIw MTQgYXQgNToyOCBQTSwgTGl1YmluZyAoTGVvKSA8bGVvLmxpdWJpbmdAaHVhd2VpLmNvbTxtYWls dG86bGVvLmxpdWJpbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGksIEFsbA0KDQpXZSdyZSBnb2lu ZyB0byB1cGRhdGUgdGhlIFVMQSBkcmFmdC4gQmVmb3JlIG1ha2luZyBhIG5ldyB2ZXJzaW9uLCBJ IHRoaW5rIGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gY29uZmlybS9kaXNjdXNzIHNldmVyYWwgaW1w b3J0YW50IHRvcGljcyB3aGljaCB3ZXJlIGRpc2N1c3NlZCBpbiBsYXN0IElFVEYgbWVldGluZy4N Cg0KSSdkIGxpa2UgdG8gZGlzY3VzcyB0aGUgdG9waWNzIGluIGRpZmZlcmVudCBtYWlsIHRocmVh ZHMgcmVzcGVjdGl2ZWx5Lg0KKEN1cnJlbnQgZHJhZnQgbGluazogaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy11bGEtdXNhZ2UtcmVjb21tZW5kYXRpb25zLTAyKQ0K KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqDQoNCiMzIE5QVHY2IFVzZSBDYXNlDQoNCkluIGN1cnJlbnQg ZHJhZnQgU2VjdGlvbiAzLjIuMSwgdGhlcmUgaXMgYW4gTlBUdjYgdXNlIGNhc2U6DQogICJJbiBz b21lIHZlcnkgY29uc3RyYWluZWQgc2l0dWF0aW9ucyhmb3IgZXhhbXBsZSwgaW4gdGhlIHNlbnNv cnMpLCB0aGUNCiAgIG5ldHdvcmsgbmVlZHMgVUxBIGFzIHRoZSBvbi1kZW1hbmQgYW5kIHN0YWJs ZSBhZGRyZXNzaW5nIHdoaWNoDQogICBkb2Vzbid0IG5lZWQgbXVjaCBjb2RlIHRvIHN1cHBvcnQg YWRkcmVzcyBhc3NpZ25tZW50IG1lY2hhbmlzbXMgbGlrZQ0KICAgREhDUCBvciBmdWxsIE5EIChO b3RlOiBzdXJlbHkgaXQgbmVlZHMgU0xBQUMpLiBJZiB0aGUgbmV0d29yayBhbHNvDQogICBuZWVk cyB0byBjb25uZWN0IHRvIHRoZSBvdXRzaWRlLCB0aGVuIHRoZXJlIGNhbiBiZSBhbiBOUFR2NiBn YXRld2F5DQogICB3aGljaCBpcyBub3Qgc3ViamVjdCB0byBleHRyZW1lIHJlc291cmNlIGNvbnN0 cmFpbnRzLiBFc3BlY2lhbGx5IHdoZW4NCiAgIGEgbGlnaHR3ZWlnaHQgaXNvbGF0ZWQgbmV0d29y ayBuZWVkcyB0byBhZGQgSW50ZXJuZXQgY29ubmVjdGl2aXR5LA0KICAgdGhpcyBpcyBxdWl0ZSBh IHN0cmFpZ2h0Zm9yd2FyZCBhbmQgZWZmaWNpZW50IHdheS4iDQoNClRoaXMgdXNlIGNhc2UgaXMg bm90IGJhc2VkIG9uIHJlYWwgZXhwZXJpZW5jZSwgYnV0IGFuIGFzc3VtcHRpb24gdGhhdCBzdXBw b3J0aW5nIG11bHRpcGxlIHByZWZpeGVzIG1pZ2h0IGJlIGEgaGVhdnkgYnVyZGVuIGZvciBzb21l IHJlc291cmNlLWNvbnN0cmFpbmVkIG5vZGVzIHN1Y2ggYXMgc2Vuc29ycy4gQmVjYXVzZSBpdCBu ZWVkcyB0byBzdG9yZSBtdWx0aXBsZSBhZGRyZXNzZXMgYW5kIGRlYWxpbmcgd2l0aCB0aGUgYWRk cmVzcyBzZWxlY3Rpb24gcHJvYmxlbS4NCg0KUXVlc3Rpb24gMToNCkluIGxhc3QgSUVURiBtZWV0 aW5nLCBMb3JlbnpvIHF1ZXN0aW9uZWQgdGhpcyBhc3N1bXB0aW9uIHdoZXRoZXIgaXQgaXMgcmVh c29uYWJsZS4gSSdkIGxpa2UgdG8gaGVhciBvcGluaW9ucyBmcm9tIHlvdSBvbiB0aGlzIGlzc3Vl LiBJZiBpdCdzIHVucmVhc29uYWJsZSwgd2UnbGwgbW92ZSB0aGUgdXNlIGNhc2Ugb3V0IG9mIHRo ZSBkcmFmdC4NCg0KUXVlc3Rpb24gMjoNCkJlc2lkZXMgdGhlIHJlc291cmNlLWNvbnN0cmFpbmVk IHVzZSBjYXNlLiBUaGVyZSBpcyBhbm90aGVyIGNhc2Ugd2hpY2ggd2FzIHJhaXNlZCBieSBBbGV4 IGFuZCBoYXMgYmVlbiB0YWxrZWQgYSBsb3QgaW4gNm1hbiB0d28gbW9udGhzIGFnbzogb25lIG5v ZGUgaXMgYXNzaWduZWQgYSAvNjQsIGFuZCBpdCBpcyB0aGUgZ2F0ZXdheSBvZiBtdWx0aS1zdWJu ZXRzLiBUaGlzIG1pZ2h0IHByb2JhYmx5IGhhcHBlbiBpbiB0aGUgM0dQUCB0ZXJtaW5hbHMuIDNH UFAgUjExIHN1cHBvcnRzIERIQ1AtUEQsIGJ1dCBmb3JtZXIgc3BlY2lmaWNhdGlvbnMgb25seSBz dXBwb3J0IC82NC4gQ3VycmVudCBuZXR3b3JrcyBqdXN0IGhhdmVuJ3QgaW1wbGVtZW50ZWQgUjEx Lg0KQmVzaWRlcyBESENQLVBELCBhbm90aGVyIHNvbHV0aW9uIGZvciB0aGUgbXVsdGktc3VibmV0 cyBpcyBicmlkZ2luZyB0aGVtIGF0IEwyLiBCdXQgaXQgaXMgbm90IGZlYXNpYmxlIGluIHNvbWUg c2l0dWF0aW9ucy4gRm9yIGV4YW1wbGUsIEluIGEgdmVoaWNsZSB0aGVyZSBtaWdodCBiZSBudW1l cm91cyBpbmNvbXBhdGlibGUgTDJzLg0KDQpJIHRoaW5rIGl0IGlzIGEgcmVhc29uYWJsZSB1c2Ug Y2FzZSB0byBiZSBkb2N1bWVudGVkLg0KDQpRdWVzdGlvbiAzOg0KVGhpcyBxdWVzdGlvbiBpcyBk ZXJpdmVkIGZyb20gUXVlc3Rpb24gMi4gQ3VycmVudCBkcmFmdCBvbmx5IHJlZmVycyBOUFR2Niwg YnV0IG1pZ2h0IGJlZW4gb3RoZXIgSVB2NiBOQVQgaW1wbGVtZW50YXRpb25zIGF2YWlsYWJsZSBp biB0aGUgdmVoaWNsZS9Jb1QgbmV0d29ya3MuIFNoYWxsIHdlIGV4cGFuZCB0aGUgIlVMQStOUFR2 NiIgY2FzZSB0byBhIGdlbmVyaWMgIlVMQStJUHY2IE5BVCIgPyAgKE5vdGU6IE5QVHY2IGlzIHRo ZSBvbmx5IHN0YW5kYXJkaXplZCBJUHY2IE5BVCBtZWNoYW5pc20gc28gZmFyKSAuDQoNClJlZ2Fy ZHMsDQpCaW5nDQoNCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B79AAnkgeml506mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBMb3Jl bnpvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGtub3cgZGlzY3Vzc2lv biBvbiBRdWVzdGlvbiAxICh0aGUgcmVzb3VyY2UtY29uc3RyYWluZWQgdXNlIGNhc2UpIHdhcyBj b250cm92ZXJzaWFsLiBJdCBpcyBvayBmb3IgbWUgdG8gbW92ZSBpdCBvdXQsIGp1c3QgYSBjb25m aXJtYXRpb24gdG8gdGhlDQogV0cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlF1ZXN0aW9uIDIgKDNHUFAgdXNlIGNhc2UpIGlzIGFub3RoZXIgY2FzZSB0aGF0IGhhc27igJl0 IGJlZW4gZGlzY3Vzc2VkIGluIHY2b3BzLCBidXQgaGFkIGEgZGVjZW50IGRpc2N1c3Npb24gaW4g Nm1hbi4gTXkgcGVyc29uYWwgdGhvdWdodCBpcyBpdA0KIHdvcnRoIHRvIGJlIGRvY3VtZW50ZWQu IChBZ2FpbiwganVzdCBkb2N1bWVudGluZyBpdCBhcyBhIHZhbGlkIGNhc2UsIG5vdCBwcm9tb3Rp bmcgdG8gdXNlIElQdjYgTkFUKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+UXVlc3Rpb24gMyBpcyBqdXN0IGRlcml2ZWQgZnJvbSBRMiwgaWYgd2UgYWdyZWUgdG8g ZG9jdW1lbnQgdGhlIDNHUFAgTkFUIGNhc2UsIHRoZW4gaXQgbWlnaHQgYmUgYmV0dGVyIG5vdCBi aW5kaW5nIHRvIHRoZSBzcGVjaWZpYyBOUFR2NiBtZWNoYW5pc20uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWxzbyBhZ3JlZSB3ZSBzaG91bGQgZm9jdXMgb24gYWR2YW5j aW5nIHRoZSBkb2N1bWVudC4gVGhhbmsgeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CaW5n PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVu em9AZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWF5IDI5LCAyMDE0 IDU6MDIgUE08YnI+DQo8Yj5Ubzo8L2I+IExpdWJpbmcgKExlbyk7IHY2b3BzLWNoYWlyc0B0b29s cy5pZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gdjZvcHMgV0c7IEFsZXhhbmRydSBQZXRyZXNjdTsg Sm9obiBKYXNvbiBCcnpvem93c2tpPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBVTEEgIzMgTlBU djYgVXNlIENhc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TGVv LCBDaGFpcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+aW4gTWFy Y2ggd2UgaGFkIGEgMjQtbWVzc2FnZSBkaXNjdXNzaW9uIG9uIHRoaXMsIHdpdGgsIEkgdGhpbmss IGNsZWFyIGxhY2sgb2YgY29uc2Vuc3VzOg0KPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL3Y2b3BzL2N1cnJlbnQvbXNnMTg3NDEuaHRtbCI+aHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Y2b3BzL2N1cnJlbnQvbXNnMTg3NDEuaHRtbDwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZXJlIHdh cyBhbHNvIGEgY29tbWVudCBmcm9tIHRoZW4tY2hhaXIgSm9obiwgcG9pbnRpbmcgb3V0IGFuIHVu cmVzb2x2ZWQgdGVjaG5pY2FsIGlzc3VlIHRoYXQgSSBkb24ndCB0aGluayB3YXMgZXZlciByZXNv bHZlZDoNCjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi92Nm9w cy9jdXJyZW50L21zZzE4NzU3Lmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi92Nm9wcy9jdXJyZW50L21zZzE4NzU3Lmh0bWw8L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5EbyB3ZSBoYXZlIHRvIGdvIHRocm91Z2ggdGhh dCBkaXNjdXNzaW9uIGFnYWluPyBIYXMgbmV3IGluZm9ybWF0aW9uIGNvbWUgdG8gbGlnaHQgb24g dGhpcyBpc3N1ZT8gSXMgdGhlcmUgcmVhc29uIHRvIGJlbGlldmUgdGhhdCB0aGUgZGlzY3Vzc2lv biB3aWxsIGJlIGFueSBkaWZmZXJlbnQgbm93IHRoYXQgdHdvIG1vbnRocyBoYXZlIHBhc3NlZD88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPklmIHRoZSBh bnN3ZXIgdG8gdGhvc2UgcXVlc3Rpb25zIGlzIG5vLCB0aGVuIEkgd291bGQgbGlrZSB0byBwcm9w b3NlIHRoYXQgd2UgYXZvaWQgZGViYXRpbmcgdGhpcyBpc3N1ZSwgYmVjYXVzZSB3ZSBoYXZlIGFs cmVhZHkgZGViYXRlZCBpdCBtdWx0aXBsZSB0aW1lcywgdGhlIGxhc3QgdGltZSBxdWl0ZSByZWNl bnRseSwgd2l0aCAtIGl0IHNlZW1zIHRvIG1lIC0gY2xlYXIgbGFjaw0KIG9mIGNvbnNlbnN1cy4g SSBkb3VidCB0aGF0IHRoaW5ncyB3aWxsIGdvIGFueSBkaWZmZXJlbnQgdGhpcyB0aW1lIGFyb3Vu ZCwgYW5kIG5vdCBoYXZpbmcgdGhlIGRlYmF0ZSBhbmQgYWR2YW5jaW5nIHRoZSBkb2N1bWVudCB3 b3VsZCBzYXZlIHRoZSB3b3JraW5nIGdyb3VwIHRpbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkxv cmVuem88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVGh1LCBNYXkgMjksIDIwMTQgYXQgNToyOCBQ TSwgTGl1YmluZyAoTGVvKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxlby5saXViaW5nQGh1YXdlaS5j b20iIHRhcmdldD0iX2JsYW5rIj5sZW8ubGl1YmluZ0BodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPkhpLCBBbGw8YnI+DQo8YnI+DQpXZSdyZSBnb2luZyB0byB1cGRhdGUgdGhlIFVMQSBk cmFmdC4gQmVmb3JlIG1ha2luZyBhIG5ldyB2ZXJzaW9uLCBJIHRoaW5rIGl0IHdvdWxkIGJlIGhl bHBmdWwgdG8gY29uZmlybS9kaXNjdXNzIHNldmVyYWwgaW1wb3J0YW50IHRvcGljcyB3aGljaCB3 ZXJlIGRpc2N1c3NlZCBpbiBsYXN0IElFVEYgbWVldGluZy48YnI+DQo8YnI+DQpJJ2QgbGlrZSB0 byBkaXNjdXNzIHRoZSB0b3BpY3MgaW4gZGlmZmVyZW50IG1haWwgdGhyZWFkcyByZXNwZWN0aXZl bHkuPGJyPg0KKEN1cnJlbnQgZHJhZnQgbGluazogPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy11bGEtdXNhZ2UtcmVjb21tZW5kYXRpb25zLTAyIiB0 YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXY2 b3BzLXVsYS11c2FnZS1yZWNvbW1lbmRhdGlvbnMtMDI8L2E+KTxicj4NCioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKjxicj4NCjxicj4NCiMzIE5QVHY2IFVzZSBDYXNlPGJyPg0KPGJyPg0KSW4gY3VycmVu dCBkcmFmdCBTZWN0aW9uIDMuMi4xLCB0aGVyZSBpcyBhbiBOUFR2NiB1c2UgY2FzZTo8YnI+DQom bmJzcDsgJnF1b3Q7SW4gc29tZSB2ZXJ5IGNvbnN0cmFpbmVkIHNpdHVhdGlvbnMoZm9yIGV4YW1w bGUsIGluIHRoZSBzZW5zb3JzKSwgdGhlPGJyPg0KJm5ic3A7ICZuYnNwO25ldHdvcmsgbmVlZHMg VUxBIGFzIHRoZSBvbi1kZW1hbmQgYW5kIHN0YWJsZSBhZGRyZXNzaW5nIHdoaWNoPGJyPg0KJm5i c3A7ICZuYnNwO2RvZXNuJ3QgbmVlZCBtdWNoIGNvZGUgdG8gc3VwcG9ydCBhZGRyZXNzIGFzc2ln bm1lbnQgbWVjaGFuaXNtcyBsaWtlPGJyPg0KJm5ic3A7ICZuYnNwO0RIQ1Agb3IgZnVsbCBORCAo Tm90ZTogc3VyZWx5IGl0IG5lZWRzIFNMQUFDKS4gSWYgdGhlIG5ldHdvcmsgYWxzbzxicj4NCiZu YnNwOyAmbmJzcDtuZWVkcyB0byBjb25uZWN0IHRvIHRoZSBvdXRzaWRlLCB0aGVuIHRoZXJlIGNh biBiZSBhbiBOUFR2NiBnYXRld2F5PGJyPg0KJm5ic3A7ICZuYnNwO3doaWNoIGlzIG5vdCBzdWJq ZWN0IHRvIGV4dHJlbWUgcmVzb3VyY2UgY29uc3RyYWludHMuIEVzcGVjaWFsbHkgd2hlbjxicj4N CiZuYnNwOyAmbmJzcDthIGxpZ2h0d2VpZ2h0IGlzb2xhdGVkIG5ldHdvcmsgbmVlZHMgdG8gYWRk IEludGVybmV0IGNvbm5lY3Rpdml0eSw8YnI+DQombmJzcDsgJm5ic3A7dGhpcyBpcyBxdWl0ZSBh IHN0cmFpZ2h0Zm9yd2FyZCBhbmQgZWZmaWNpZW50IHdheS4mcXVvdDs8YnI+DQo8YnI+DQpUaGlz IHVzZSBjYXNlIGlzIG5vdCBiYXNlZCBvbiByZWFsIGV4cGVyaWVuY2UsIGJ1dCBhbiBhc3N1bXB0 aW9uIHRoYXQgc3VwcG9ydGluZyBtdWx0aXBsZSBwcmVmaXhlcyBtaWdodCBiZSBhIGhlYXZ5IGJ1 cmRlbiBmb3Igc29tZSByZXNvdXJjZS1jb25zdHJhaW5lZCBub2RlcyBzdWNoIGFzIHNlbnNvcnMu IEJlY2F1c2UgaXQgbmVlZHMgdG8gc3RvcmUgbXVsdGlwbGUgYWRkcmVzc2VzIGFuZCBkZWFsaW5n IHdpdGggdGhlIGFkZHJlc3Mgc2VsZWN0aW9uDQogcHJvYmxlbS48YnI+DQo8YnI+DQpRdWVzdGlv biAxOjxicj4NCkluIGxhc3QgSUVURiBtZWV0aW5nLCBMb3JlbnpvIHF1ZXN0aW9uZWQgdGhpcyBh c3N1bXB0aW9uIHdoZXRoZXIgaXQgaXMgcmVhc29uYWJsZS4gSSdkIGxpa2UgdG8gaGVhciBvcGlu aW9ucyBmcm9tIHlvdSBvbiB0aGlzIGlzc3VlLiBJZiBpdCdzIHVucmVhc29uYWJsZSwgd2UnbGwg bW92ZSB0aGUgdXNlIGNhc2Ugb3V0IG9mIHRoZSBkcmFmdC48YnI+DQo8YnI+DQpRdWVzdGlvbiAy Ojxicj4NCkJlc2lkZXMgdGhlIHJlc291cmNlLWNvbnN0cmFpbmVkIHVzZSBjYXNlLiBUaGVyZSBp cyBhbm90aGVyIGNhc2Ugd2hpY2ggd2FzIHJhaXNlZCBieSBBbGV4IGFuZCBoYXMgYmVlbiB0YWxr ZWQgYSBsb3QgaW4gNm1hbiB0d28gbW9udGhzIGFnbzogb25lIG5vZGUgaXMgYXNzaWduZWQgYSAv NjQsIGFuZCBpdCBpcyB0aGUgZ2F0ZXdheSBvZiBtdWx0aS1zdWJuZXRzLiBUaGlzIG1pZ2h0IHBy b2JhYmx5IGhhcHBlbiBpbiB0aGUgM0dQUCB0ZXJtaW5hbHMuDQogM0dQUCBSMTEgc3VwcG9ydHMg REhDUC1QRCwgYnV0IGZvcm1lciBzcGVjaWZpY2F0aW9ucyBvbmx5IHN1cHBvcnQgLzY0LiBDdXJy ZW50IG5ldHdvcmtzIGp1c3QgaGF2ZW4ndCBpbXBsZW1lbnRlZCBSMTEuPGJyPg0KQmVzaWRlcyBE SENQLVBELCBhbm90aGVyIHNvbHV0aW9uIGZvciB0aGUgbXVsdGktc3VibmV0cyBpcyBicmlkZ2lu ZyB0aGVtIGF0IEwyLiBCdXQgaXQgaXMgbm90IGZlYXNpYmxlIGluIHNvbWUgc2l0dWF0aW9ucy4g Rm9yIGV4YW1wbGUsIEluIGEgdmVoaWNsZSB0aGVyZSBtaWdodCBiZSBudW1lcm91cyBpbmNvbXBh dGlibGUgTDJzLjxicj4NCjxicj4NCkkgdGhpbmsgaXQgaXMgYSByZWFzb25hYmxlIHVzZSBjYXNl IHRvIGJlIGRvY3VtZW50ZWQuPGJyPg0KPGJyPg0KUXVlc3Rpb24gMzo8YnI+DQpUaGlzIHF1ZXN0 aW9uIGlzIGRlcml2ZWQgZnJvbSBRdWVzdGlvbiAyLiBDdXJyZW50IGRyYWZ0IG9ubHkgcmVmZXJz IE5QVHY2LCBidXQgbWlnaHQgYmVlbiBvdGhlciBJUHY2IE5BVCBpbXBsZW1lbnRhdGlvbnMgYXZh aWxhYmxlIGluIHRoZSB2ZWhpY2xlL0lvVCBuZXR3b3Jrcy4gU2hhbGwgd2UgZXhwYW5kIHRoZSAm cXVvdDtVTEEmIzQzO05QVHY2JnF1b3Q7IGNhc2UgdG8gYSBnZW5lcmljICZxdW90O1VMQSYjNDM7 SVB2NiBOQVQmcXVvdDsgPyAmbmJzcDsoTm90ZTogTlBUdjYgaXMgdGhlIG9ubHkgc3RhbmRhcmRp emVkDQogSVB2NiBOQVQgbWVjaGFuaXNtIHNvIGZhcikgLjxicj4NCjxicj4NClJlZ2FyZHMsPGJy Pg0KQmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B79AAnkgeml506mbxchi_-- From nobody Thu May 29 02:38:15 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6C11A0877 for ; Thu, 29 May 2014 02:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjPj2BDyLA-R for ; Thu, 29 May 2014 02:38:13 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FDCC1A0273 for ; Thu, 29 May 2014 02:38:13 -0700 (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 C4F911B81EB for ; Thu, 29 May 2014 02:38:09 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id B514319005C; Thu, 29 May 2014 02:38:09 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 02:38:09 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B79AA@nkgeml506-mbx.china.huawei.com> Date: Thu, 29 May 2014 05:38:07 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B79AA@nkgeml506-mbx.china.huawei.com> To: "Liubing (Leo)" X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_TCq9n_hXc35hq_q5720lfOH5ok Cc: v6ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] ULA #3 NPTv6 Use Case X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 09:38:15 -0000 On May 29, 2014, at 5:32 AM, Liubing (Leo) = wrote: > Question 2 (3GPP use case) is another case that hasn=92t been = discussed in v6ops, but had a decent discussion in 6man. My personal = thought is it worth to be documented. (Again, just documenting it as a = valid case, not promoting to use IPv6 NAT) > Question 3 is just derived from Q2, if we agree to document the 3GPP = NAT case, then it might be better not binding to the specific NPTv6 = mechanism. This just feels like the camel trying to sneak its nose under the tent = to me. The 3gpp use case is contrived: if a 3gpp operator wants to = support this use case, they should send a shorter prefix. If they only = send a /64, then the node will only be able to support one subnet. = Essentially you are proposing to tweak the IPv6 addressing architecture = here, and I don't think that's appropriate. So I think you really = should not address points 2 and 3. From nobody Thu May 29 04:18:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080161A088D for ; Thu, 29 May 2014 04:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOskMBKaeeO3 for ; Thu, 29 May 2014 04:18:11 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09F251A009E for ; Thu, 29 May 2014 04:18:10 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id db12so189550veb.11 for ; Thu, 29 May 2014 04:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HyIyhQlIoRmlMW+6afaOqPtuOZWnvpaBA9UoVkKtTTc=; b=P1Pgn49AHRSVfa8nhzxNropLUA2FzklOecJ2Vs5FSJtY8AZTu7FXS/0daDwKYYesAj MiF22QEMD5s/7d/ACmWpY2rVWj83qRFKffuzb4jhANVFA6lcpboev9dvs6Exrpxy6mac hYy3hLpT5Tta1G8ONu4KswgVyVXiLpg9ejf+3GhUIiygBE0n4LxqzwO4g+WDRKK8tFYC CJk2l0y7WeCVs19wzf4ZsQ9CQUFuY8HMAI0wgVbGNMQgEpGgyZsgEYmt/QMmb98BV7Hv bOpHdkr2Ml0ALJE9Dqs7tRPOQW8nYKO0y79nS/rCYpP+UDXUX4p6RoMud+Ev2e8/fjnt eZSg== MIME-Version: 1.0 X-Received: by 10.58.243.198 with SMTP id xa6mr70359vec.65.1401362286611; Thu, 29 May 2014 04:18:06 -0700 (PDT) Sender: mpetach@gmail.com Received: by 10.220.173.193 with HTTP; Thu, 29 May 2014 04:18:06 -0700 (PDT) In-Reply-To: <1401312298.99614.YahooMailNeo@web162205.mail.bf1.yahoo.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com> <5383C2CF.6040205@gmail.com> <1401230263.69077.YahooMailNeo@web162206.mail.bf1.yahoo.com> <53854B03.8040702@gmail.com> <1401312298.99614.YahooMailNeo@web162205.mail.bf1.yahoo.com> Date: Thu, 29 May 2014 04:18:06 -0700 X-Google-Sender-Auth: t4jZx0tYb49sVocOzN73Dnsipf0 Message-ID: From: Matthew Petach To: Mark ZZZ Smith Content-Type: multipart/alternative; boundary=047d7b6dc3e44b95fb04fa8815cb Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/edgOT7ql4yoYgLm_p5vJXDQNPcQ Cc: v6ops WG Subject: Re: [v6ops] (re)numbering [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 11:18:12 -0000 --047d7b6dc3e44b95fb04fa8815cb Content-Type: text/plain; charset=UTF-8 On Wed, May 28, 2014 at 2:24 PM, Mark ZZZ Smith wrote: [...] > RFC1918s have provided that internal connectivity robustness to both home > networks and enterprise networks. Of course the drawback is that in IPv4 it > is binary - hosts either have RFC1918s or public addresses, so if you have > RFC1918s you have to use NAT to access external destinations on the > Internet. > Wow...that's news to me. For a decade now, I've been using RFC1918 addresses+global addresses in IPv4 on my home network; each host has an address from each subnet, and uses the 1918 addresses to reach internal-only devices (printers, terminal servers, etc.) which only have RFC1918 addresses, and use the globally routed IPs for reaching non-local destinations. I'm not sure I'd agree with your characterization that IPv4 is different from IPv6 in that regards; there's nothing in the IPv4 world that prevents hosts from having multiple addresses, and making use of them. It's definitely a plus to have internal connectivity stay working regardless of external connectivity, I completely agree with you on that. Matt --047d7b6dc3e44b95fb04fa8815cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, May 28, 2014 at 2:24 PM, Mark ZZZ Smith &= lt;markzzzsm= ith@yahoo.com.au> wrote:
[...]
RFC1918s have provided that internal connectivity robustness to both home n= etworks and enterprise networks. Of course the drawback is that in IPv4 it = is binary - hosts either have RFC1918s or public addresses, so if you have = RFC1918s you have to use NAT to access external destinations on the Interne= t.

Wow...that's news to me.

=
For a decade now, I've been using
RFC1918 addresses+= global addresses
in IPv4 on my home network; each
host has an address= from each subnet,
and uses the 1918 addresses to reach
internal-only devices (p= rinters, terminal
servers, etc.) which only have RFC1918
a= ddresses, and use the globally routed
IPs for reaching non-lo= cal destinations.

I'm not sure I'd agree with your characterizationthat IPv4 is different from IPv6 in that regards;
there's nothing i= n the IPv4 world that prevents
hosts from having multiple add= resses, and
making use of them.

It's definitely a plus to have in= ternal connectivity
stay working regardless of external connectivity,
I completely agree with you on that.

Matt

--047d7b6dc3e44b95fb04fa8815cb-- From nobody Thu May 29 05:24:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA171A08DA for ; Thu, 29 May 2014 05:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SkVViQK_gSe for ; Thu, 29 May 2014 05:24:10 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5C371A08DB for ; Thu, 29 May 2014 05:24:09 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WpzNM-0001qo-CS; Thu, 29 May 2014 12:24:04 +0000 Date: Thu, 29 May 2014 21:24:17 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <5386B0DF.9060401@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> <0ED911FA-D24C-4FC8-9D6A-F38F9711F115@steffann.nl> <5386AA9F.7000001@gmail.com> <5386B0DF.9060401@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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8xZ1ngpgi_-I6Dda_0uIq25A7bM Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 12:24:11 -0000 >>>> red herring. global prefixes designed to be used in place of ula should >>>> not be in the global routing table >>> Indeed they shouldn't, but since everybody should be filtering ULAs >>> (and most people will do so), ULAs won't propagate but routeable GUAs >>> might. >> explain why the two probability distributions will differ > Because I have considerable confidence that the majority of transit > operators will know they need to filter fc00::/7, but the same cannot > be said of arbitrary /48s from RIR space. i know. that's why we see no leaks of rfc1918 and ULA today. oh ... oops! the real measurement i would take is to test the hypothesis that utterly unrealistic fantasies about operations are highest in v6 religious wgs. randy From nobody Thu May 29 05:26:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A5B1A0687 for ; Thu, 29 May 2014 05:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaPH505ucJI9 for ; Thu, 29 May 2014 05:26:43 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA0C51A0403 for ; Thu, 29 May 2014 05:26:43 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 6C34460AF9 for ; Thu, 29 May 2014 14:26:38 +0200 (CEST) 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 483E26042E for ; Thu, 29 May 2014 14:26:38 +0200 (CEST) Received: (qmail 79995 invoked by uid 1007); 29 May 2014 14:26:38 +0200 Date: Thu, 29 May 2014 14:26:38 +0200 From: Gert Doering To: Mikael Abrahamsson Message-ID: <20140529122638.GB46558@Space.Net> References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/lvVeJ-GqPaIxAEQE7HL23vt2psU Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 12:26:46 -0000 hi, On Wed, May 28, 2014 at 07:08:16AM +0200, Mikael Abrahamsson wrote: > We should spend more time on getting renumbering working properly. Having > all Enterprise get PI space will make the routing system melt down. I think this one boils down to "what is 'an Enterprise'" and, subsequently, "how many of those are there". One side of the discussion seems to include barbershops etc. ("SME") in this group - and there are way too many of them, but renumbering those networks is usually trivial ("what is my printer's IP address?" is nicely answered by mDNS, so no need to hard-code IPv6 addresses anywhere where you'd have to renumber them alter on... etc.). The truly big ones are not candidates for renumbering, but we're talking about significantly smaller numbers here :-) (and, interestingly enough, many of them don't *want* Internet in the first place, they want an internal network, a proxy server, and that one can easily renumber if needed...) 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 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu May 29 05:28:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B781A0687 for ; Thu, 29 May 2014 05:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olaoSPC4otRk for ; Thu, 29 May 2014 05:28:45 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F3351A08D0 for ; Thu, 29 May 2014 05:28:45 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WpzRm-0001rf-9c; Thu, 29 May 2014 12:28:38 +0000 Date: Thu, 29 May 2014 21:28:51 +0900 Message-ID: From: Randy Bush To: "Liubing (Leo)" In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7856@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7856@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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xmb-php-eSVeMNlgls_UWc_NR3U Cc: v6ops WG Subject: Re: [v6ops] ULA #4 Refering Site-local addresses X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 12:28:46 -0000 > I think it is good to add some texts referring site-local address as a > background in the introduction Section. definitely. be very clear the site-local whack-a-mole was declared a disaster and deprecated and should never be revived or emulated. randy From nobody Thu May 29 05:42:42 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77CA1A00DD for ; Thu, 29 May 2014 05:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9z0kjIlW0nH for ; Thu, 29 May 2014 05:42:33 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9077E1A0403 for ; Thu, 29 May 2014 05:42:32 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 7E96860AD5 for ; Thu, 29 May 2014 14:42:27 +0200 (CEST) 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 4F2D2602E6 for ; Thu, 29 May 2014 14:42:27 +0200 (CEST) Received: (qmail 82321 invoked by uid 1007); 29 May 2014 14:42:27 +0200 Date: Thu, 29 May 2014 14:42:27 +0200 From: Gert Doering To: Brian E Carpenter Message-ID: <20140529124227.GD46558@Space.Net> References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> <53855130.8040105@gmail.com> <53856628.2070201@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53856628.2070201@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ltMJt8wU0cBC5a5UqYnQPpwLbM8 Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] Routing /48s [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 12:42:39 -0000 Hi, On Wed, May 28, 2014 at 04:29:28PM +1200, Brian E Carpenter wrote: > > You don't need ULA to solve this. homenet is solving this problem using > > source+destination routing. > On the other hand, and I speak from experience, persuading IT departments > to support SADR is harder than persuading them to allow multiple prefixes. It needs to be pointed out again and again that the problem space "network without IT administrator/IT department" and "network with IT department" is sufficiently different that SADR is a tremendously great solution for one of them, and a completely no-go for the other. Which one is which, and why, is left as a trivial excercise for the reader :-) 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 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu May 29 06:15:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F3F1A08FD for ; Thu, 29 May 2014 06:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tezunp5w2ovd for ; Thu, 29 May 2014 06:15:55 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12DD31A08F4 for ; Thu, 29 May 2014 06:15:55 -0700 (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 C0BE11B8204 for ; Thu, 29 May 2014 06:15:50 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id B8F6219005C; Thu, 29 May 2014 06:15:50 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 06:15:50 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B79AA@nkgeml506-mbx.china.huawei.com> Date: Thu, 29 May 2014 09:15:47 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <1DAB3EA9-DDC4-4497-ADA7-9E234B5D17BB@nominum.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B79AA@nkgeml506-mbx.china.huawei.com> To: "Liubing (Leo)" X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/onVYltl22VG96VsURaPqKs0Wdkc Cc: v6ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] ULA #3 NPTv6 Use Case X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:15:57 -0000 On May 29, 2014, at 5:32 AM, Liubing (Leo) = wrote: > I know discussion on Question 1 (the resource-constrained use case) = was controversial. It is ok for me to move it out, just a confirmation = to the WG. I've asked for some review from the IntArea directorate, and so far the = one response I've gotten back, from someone who's implemented an LLN = stack, is that RPL is by far more complicated than supporting multiple = prefixes, and that while they do support ULAs for address stability = during periods of disconnection, they support that alongside global = addressing. It would be useful to hear from more implementors. From nobody Thu May 29 06:47:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4071A0909 for ; Thu, 29 May 2014 06:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfWhhYFiVb47 for ; Thu, 29 May 2014 06:47:50 -0700 (PDT) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 429191A092B for ; Thu, 29 May 2014 06:47:50 -0700 (PDT) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 29 May 2014 08:47:41 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ie0-f174.google.com [209.85.223.174] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ie0-f174.google.com with SMTP id lx4so291102iec.33 for ; Thu, 29 May 2014 06:47:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ifzJ7UWIzYm3PoWSjQsP3yTRtWC4AYuvaKxeh3a271I=; b=Nq//RAe8OT7xqpVDvE4yr0MAjnyO5PaZHHHGweBDji85cc0UKKadN+3FpaBrY5s3bW 7S6wgYZY1PV4+wdg+zyM4bJ/ZaAzYaDOo4MvZP1vIID4lEPzLp3XkODUUQTa8Pvx+ZBG 5v1ku5IQbiOzAVKQv6AD9UzCcGKWZWAjlEWYoSW9nIf1xCw6fhiddzSheeG+x93wOUCy M1BHoe5v2sTRWXT/4R1RBVVnwYqHC8UYhV34pR4VbGPTBN0L/BnKkwU9XNg20o6EU7YX pPOJHkpxbjiZpPstJEGZ5Pov4AdDYFmkjclRDXy6aXBxn4rkTsApzEWted4E1UD3Fnxi +9dg== X-Gm-Message-State: ALoCoQkyG19Wzj65Z3pcqlhzXQv0HMXEbwT/OgySnLN9yRkeQRBHB3aLsWoXdY5diXXkG/7HtVD0tc6PqFbK7DqeYCY7W/K3BJspc3/aiohoSInqlrf7pAU= X-Received: by 10.42.191.202 with SMTP id dn10mr7951434icb.14.1401371260766; Thu, 29 May 2014 06:47:40 -0700 (PDT) X-Received: by 10.42.191.202 with SMTP id dn10mr7951416icb.14.1401371260599; Thu, 29 May 2014 06:47:40 -0700 (PDT) Received: from oit201651646.local ([38.109.32.164]) by mx.google.com with ESMTPSA id fx1sm24011188igd.1.2014.05.29.06.47.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 06:47:39 -0700 (PDT) Message-ID: <53873A35.9090501@umn.edu> Date: Thu, 29 May 2014 08:46:29 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brian E Carpenter , Randy Bush References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> <0ED911FA-D24C-4FC8-9D6A-F38F9711F115@steffann.nl> <5386AA9F.7000001@gmail.com> <5386B0DF.9060401@gmail.com> In-Reply-To: <5386B0DF.9060401@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-R_KqrgxaVKZBJKx5fEU833hd50 Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 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, 29 May 2014 13:47:52 -0000 On 5/28/14, 23:00 , Brian E Carpenter wrote: > On 29/05/2014 15:44, Randy Bush wrote: >>>> red herring. global prefixes designed to be used in place of ula should >>>> not be in the global routing table >>> Indeed they shouldn't, but since everybody should be filtering ULAs >>> (and most people will do so), ULAs won't propagate but routeable GUAs >>> might. >> >> explain why the two probability distributions will differ > > Because I have considerable confidence that the majority of transit > operators will know they need to filter fc00::/7, but the same cannot > be said of arbitrary /48s from RIR space. Here is some data supporting the idea that GUA used as ULA can and will be leaked, leaked a lot in some cases. See slide 20 of the following presentation; https://www.nanog.org/meetings/abstract?id=2289 And this is discussed in more detail in section 5.2 of the full research paper at; http://www.merit.edu/research/pdf/2013/ipv6_darknet_paper_r6098.pdf Yes, I'm sure ULA is leaked too. However, it's a much safer assumption and operationally much easier to filter external ULA sourced traffic. Even if I'm exchanging ULA traffic with other parties, it would seem likely for me to know the ULA prefixes that matter to me. Where as, if someone uses GUA as if it were ULA and it's leaked, it's extremely unlikely that I would know to filter it. The only way I can even think of is for the other entity to publish ROAs sourced to AS0. However, I suspect the security guys would object to that, as I'm now leaking that traffic from that prefix might be interesting. One of those dammed if you do, dammed if you don't kind of situations. Those of you suggesting no one should use ULA and should get GUA and use it as if it's ULA need to write up some recommendations for how to do it safely. It seems many people are following your recommendations but doing it badly. 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 nobody Thu May 29 08:00:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4941D1A6F59 for ; Thu, 29 May 2014 08:00: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=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFiA0rysjBnj for ; Thu, 29 May 2014 08:00:44 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE42C1A073E for ; Thu, 29 May 2014 08:00:44 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id j107so1299112qga.6 for ; Thu, 29 May 2014 08:00:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=e7ijYAPRtP+X+6pv23GAJIe8j0OwH3D3AQSoJZQJA/4=; b=Vco/K7C6xHkisWcPWOtvSbU2x7f/XbvtvIT/hy8LLwm9ABFp1QIJvDDJ1b0SATeRZs 2pz8RwS4GyxInsTmEpigsLmAfu42e4ed5/V6kXR+qAHP6CfgdD8RGyT4EVdH92nNXQ+G l9DUdE+eE9013Yqy9scgaFGtcKuSVu9VHA9n0TRTz7SubufSkDPEh6IzBMnVx29uhZz0 lgilB3HBxnXtQq/7NhDPXZAth/oum4Te9gt8nrnxCT9cVsE/bu9FwRjn2Hdnu3p0bWk0 WSBOqxHI+MtRZ8/1PCVvjK7+WFP9PIP+ujvqzoPptr4TuuyU0C8b9vDTUP7AtjNQGgnD o4YQ== X-Gm-Message-State: ALoCoQlLsYUckVa5QNJ2Bm8u/1cMsywynaS1t2nNNHzJ3hGQ9qjGwdJjSy3rNCXHF0pbi75j6Ghm X-Received: by 10.224.38.204 with SMTP id c12mr11196411qae.1.1401375640281; Thu, 29 May 2014 08:00:40 -0700 (PDT) Received: from Victors-MacBook-Pro.local ([2001:470:b2df:0:20ba:4890:88fc:d228]) by mx.google.com with ESMTPSA id s13sm1330525qay.39.2014.05.29.08.00.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 08:00:39 -0700 (PDT) Message-ID: <53874B95.3060809@jvknet.com> Date: Thu, 29 May 2014 11:00:37 -0400 From: Victor Kuarsingh User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Randy Bush , Brian E Carpenter References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> <0ED911FA-D24C-4FC8-9D6A-F38F9711F115@steffann.nl> <5386AA9F.7000001@gmail.com> <5386B0DF.9060401@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/fkGcZ5h9ZNzLZIZ6zV_rXjPS6kE Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 15:00:49 -0000 On 2014-05-29, 8:24 AM, Randy Bush wrote: >>>>> red herring. global prefixes designed to be used in place of ula should >>>>> not be in the global routing table >>>> Indeed they shouldn't, but since everybody should be filtering ULAs >>>> (and most people will do so), ULAs won't propagate but routeable GUAs >>>> might. >>> explain why the two probability distributions will differ >> Because I have considerable confidence that the majority of transit >> operators will know they need to filter fc00::/7, but the same cannot >> be said of arbitrary /48s from RIR space. > i know. that's why we see no leaks of rfc1918 and ULA today. oh ... > oops! Leaks are there, however they are identifiable without knowing much about why someone is using them. So even if someone leaks it, others can filter. Victor K From nobody Thu May 29 08:32:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248C31A09EC for ; Thu, 29 May 2014 08:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hm6QqncTXmdh for ; Thu, 29 May 2014 08:32:49 -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 4D0371A09BF for ; Thu, 29 May 2014 08:32:49 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id D5E59349415; Thu, 29 May 2014 15:32:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6FEFB160064; Thu, 29 May 2014 15:37:31 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 3F804160054; Thu, 29 May 2014 15:37:31 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id BF69216E83F8; Fri, 30 May 2014 01:32:11 +1000 (EST) To: Matthew Petach From: Mark Andrews References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com> <5383C2CF.6040205@gmail.com> <1401230263.69077.YahooMailNeo@web162206.mail.bf1.yahoo.com> <53854B03.8040702@gmail.com> <1401312298.99614.YahooMailNeo@web162205.mail.bf1.yahoo.com> In-reply-to: Your message of "Thu, 29 May 2014 04:18:06 -0700." Date: Fri, 30 May 2014 01:32:11 +1000 Message-Id: <20140529153211.BF69216E83F8@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kXse_fzrYayhnywuUQAk1-9a3nA Cc: v6ops WG Subject: Re: [v6ops] (re)numbering [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 15:32:51 -0000 In message , Matthew Petach writes: > > On Wed, May 28, 2014 at 2:24 PM, Mark ZZZ Smith > wrote: > [...] > > > RFC1918s have provided that internal connectivity robustness to both home > > networks and enterprise networks. Of course the drawback is that in IPv4 it > > is binary - hosts either have RFC1918s or public addresses, so if you have > > RFC1918s you have to use NAT to access external destinations on the > > Internet. > > Wow...that's news to me. > > For a decade now, I've been using > RFC1918 addresses+global addresses > in IPv4 on my home network; each > host has an address from each subnet, > and uses the 1918 addresses to reach > internal-only devices (printers, terminal > servers, etc.) which only have RFC1918 > addresses, and use the globally routed > IPs for reaching non-local destinations. > > I'm not sure I'd agree with your characterization > that IPv4 is different from IPv6 in that regards; > there's nothing in the IPv4 world that prevents > hosts from having multiple addresses, and > making use of them. > > It's definitely a plus to have internal connectivity > stay working regardless of external connectivity, > I completely agree with you on that. > > Matt It may work with some machine some of the time. It is not guarenteed to work with all machines all of the time. I've definitely used machines which didn't support multiple IPv4 addresses on the same interface. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu May 29 08:46:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999491A043A for ; Thu, 29 May 2014 08:46:48 -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=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRGNaY3PMqls for ; Thu, 29 May 2014 08:46:47 -0700 (PDT) Received: from atl4mhob05.myregisteredsite.com (atl4mhob05.myregisteredsite.com [209.17.115.43]) by ietfa.amsl.com (Postfix) with ESMTP id F1D981A0424 for ; Thu, 29 May 2014 08:46:46 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s4TFkcQl018055 for ; Thu, 29 May 2014 11:46:38 -0400 Received: (qmail 22967 invoked by uid 0); 29 May 2014 15:46:37 -0000 X-TCPREMOTEIP: 204.235.115.161 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?10.71.36.73?) (lee@asgard.org@204.235.115.161) by 0 with ESMTPA; 29 May 2014 15:46:37 -0000 User-Agent: Microsoft-MacOutlook/14.4.1.140326 Date: Thu, 29 May 2014 11:46:36 -0400 From: Lee Howard To: "Liubing (Leo)" , v6ops WG Message-ID: Thread-Topic: [v6ops] ULA #3 NPTv6 Use Case Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/oZ1gxfEc8Pw8YmsxEgzvbp5QTJI Cc: "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] ULA #3 NPTv6 Use Case X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 15:46:48 -0000 On 5/29/14 4:28 AM, "Liubing (Leo)" wrote: > >Question 3: >This question is derived from Question 2. Current draft only refers >NPTv6, but might been other IPv6 NAT implementations available in the >vehicle/IoT networks. Shall we expand the "ULA+NPTv6" case to a generic >"ULA+IPv6 NAT" ? (Note: NPTv6 is the only standardized IPv6 NAT >mechanism so far) . Trying to thread the need between useful and consensus. . . As you note, there's no IPv6 NAT specification other than NPT66. There hasn't been consensus to define it, and I think there is still not consensus to do so. Would it be useful to describe why it hasn't been defined? Or would it help if there were a separate document that this Recommendations document could reference? Lee From nobody Thu May 29 08:56:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0548E1A0441 for ; Thu, 29 May 2014 08:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XU4j9C51Jn2 for ; Thu, 29 May 2014 08:56:15 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AEA51A0985 for ; Thu, 29 May 2014 08:55:53 -0700 (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 340AB1B81EB for ; Thu, 29 May 2014 08:55:49 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 2D82319005C; Thu, 29 May 2014 08:55:49 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 08:55:48 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Thu, 29 May 2014 11:55:47 -0400 Content-Transfer-Encoding: 7bit Message-ID: References: To: Lee Howard X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/FnxC0rQOaEn0hRkGtb7iapviPV8 Cc: v6ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] ULA #3 NPTv6 Use Case X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 15:56:16 -0000 On May 29, 2014, at 11:46 AM, Lee Howard wrote: > As you note, there's no IPv6 NAT specification other than NPT66. There > hasn't been consensus to define it, and I think there is still not > consensus to do so. Would it be useful to describe why it hasn't been > defined? Or would it help if there were a separate document that this > Recommendations document could reference? I would really love it if we could just avoid that entire hot potato. From nobody Thu May 29 10:35:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E541A0254 for ; Thu, 29 May 2014 10:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZQ2yzEYVu8f for ; Thu, 29 May 2014 10:35:54 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9451A0177 for ; Thu, 29 May 2014 10:35:54 -0700 (PDT) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB410.namprd03.prod.outlook.com (10.141.141.16) with Microsoft SMTP Server (TLS) id 15.0.949.11; Thu, 29 May 2014 17:35:48 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0949.001; Thu, 29 May 2014 17:35:48 +0000 From: Dave Thaler To: "Liubing (Leo)" , v6ops WG Thread-Topic: ULA #4 Refering Site-local addresses Thread-Index: Ac97GFDI5kn6NhSAQQSg5krJ9qqmJQASx5KQ Date: Thu, 29 May 2014 17:35:47 +0000 Message-ID: <39f250c48a1d487eb404dc8394eddfe7@BY2PR03MB412.namprd03.prod.outlook.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7856@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7856@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.16.15.87] x-forefront-prvs: 022649CC2C x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(377454003)(51704005)(13464003)(199002)(189002)(85852003)(76482001)(83072002)(31966008)(74316001)(21056001)(74502001)(54356999)(101416001)(74662001)(76176999)(15975445006)(15202345003)(86362001)(2656002)(76576001)(92566001)(66066001)(86612001)(87936001)(46102001)(64706001)(80022001)(20776003)(81342001)(81542001)(77982001)(99396002)(99286001)(77096999)(50986999)(4396001)(83322001)(19580395003)(79102001)(19580405001)(33646001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB410; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/dakCVk1tJyggSzwlLLCB_f-BtvE Cc: "v6ops-chairs@tools.ietf.org" , "bill@wjcerveny.com" Subject: Re: [v6ops] ULA #4 Refering Site-local addresses X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 17:35:56 -0000 > -----Original Message----- > From: Liubing (Leo) [mailto:leo.liubing@huawei.com] > Sent: Thursday, May 29, 2014 1:31 AM > To: v6ops WG > Cc: v6ops-chairs@tools.ietf.org; bill@wjcerveny.com; Dave Thaler > Subject: ULA #4 Refering Site-local addresses >=20 > Hi, All >=20 > We're going to update the ULA draft. Before making a new version, I think= it > would be helpful to confirm/discuss several important topics which were > discussed in last IETF meeting. >=20 > I'd like to discuss the topics in different mail threads respectively. > (Current draft link: http://tools.ietf.org/html/draft-ietf-v6ops-ula-usag= e- > recommendations-02) > ********************************************************** > ******************** >=20 > # Refering Site-local addresses >=20 > Bill and Dave suggested to refer site-local addresses. Because ULAs were > intended to replace the gap left when site-local addresses were deprecate= d. >=20 > Especially, Dave mentioned the site-local address based anycast utilizati= on in > former RFCs (e.g. RFC4339 to use site-local anycast as Recursive DNS > discovery) and gave a pointer to the relevant stuff. >=20 > I think it is good to add some texts referring site-local address as a > background in the introduction Section. > But for the site-local anycast use case, I think of it as out of the scop= e of this > ULA draft. Because as I understood, since the site-local is deprecated, t= he > anycast use cases based on site-local are invalid as well.=20 Yes, that is the current bad state. > And it is not a goal to > re-produce these anycast use cases in a ULA form in a v6ops document, so = I > just feel like there is nothing to say about it. Disagree. > What are your thoughts? I think v6ops needs to say what the replacement is. Deprecating something= =20 useful with no replacement hasn't really helped anything. The situation is very similar to when NAT-PT was deprecated. That didn't stop people from doing NAT-PT because the IETF provided no alternative. It wasn't until we did NAT64/DNS64 in Behave that the problem was really "solved" (to the extent that it's solved). Until then, the IETF largely ignored the proble= m and as a result some people ignored the IETF. (Others would likely point to the NPTv6 example too...) The anycast problem isn't as widespread as the NAT-PT problem, so we've survived this long, but the IETF is still in denial. -Dave From nobody Thu May 29 13:37:57 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDBA1A00EA for ; Thu, 29 May 2014 13:37:54 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgFEKZ7nGTaR for ; Thu, 29 May 2014 13:37:53 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9F0A1A068A for ; Thu, 29 May 2014 13:37:49 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id v10so133679pde.4 for ; Thu, 29 May 2014 13:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dQlGUuLWtTYUuV38GtpOEKV8kddVeUNlLOXqIrbJduk=; b=yq8ywx5Wz8+unFi9W1A8BY+FOW5ubkJvKXxTbCtETwO09shm8pGxdYbxrPOUPd85aR D/OaLWybN1eaxn/OyxfjUhLZyeKn1OuIvNIcROBscRbxx70/7jORMzPFIrtRwdjcQ9cP FH/vQcYM2VCueB6u4maglcTtvu5d/ZlM2cIBUGgSerWe/TPriUa0WVL7t+U7obxOwIko lX3O2QmnOaNfXVvRhkAVnGyXi36UjWOkcZKOFxfEKYrVOZmAG6DvF18rZlDEEn1NMfJc QlBSotbFoNdh/S3be5H2C6ItcJIoHT+H98d7S8L/7MWJG70NT+xtn8f4scOTrtlDHlz7 YUiQ== X-Received: by 10.67.14.231 with SMTP id fj7mr11934248pad.115.1401395865942; Thu, 29 May 2014 13:37:45 -0700 (PDT) Received: from [192.168.178.23] (48.198.69.111.dynamic.snap.net.nz. [111.69.198.48]) by mx.google.com with ESMTPSA id dz4sm7751441pab.47.2014.05.29.13.37.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 13:37:45 -0700 (PDT) Message-ID: <53879AA0.1030202@gmail.com> Date: Fri, 30 May 2014 08:37:52 +1200 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: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Z9odert0U-gfrvaEKcE_oXcPzo0 Cc: "v6ops-chairs@tools.ietf.org" , v6ops WG Subject: Re: [v6ops] ULA #3 NPTv6 Use Case X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 20:37:54 -0000 On 30/05/2014 03:55, Ted Lemon wrote: > On May 29, 2014, at 11:46 AM, Lee Howard wrote: >> As you note, there's no IPv6 NAT specification other than NPT66. There >> hasn't been consensus to define it, and I think there is still not >> consensus to do so. Would it be useful to describe why it hasn't been >> defined? Or would it help if there were a separate document that this >> Recommendations document could reference? > > I would really love it if we could just avoid that entire hot potato. Please. It's just wasted bits. How about just making a very short neutral statement: The experimental proposal for Network Prefix Translation (NPTv6) [RFC6296] observes that ULA prefixes could be translated, but this is not a recommended solution. Brian From nobody Thu May 29 13:47:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188041A05E5 for ; Thu, 29 May 2014 13:47:10 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-bPL5PdFH0n for ; Thu, 29 May 2014 13:47:08 -0700 (PDT) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CDE41A03EA for ; Thu, 29 May 2014 13:47:08 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id jt11so900541pbb.22 for ; Thu, 29 May 2014 13:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=YhVkW7iRlD4DxjtOM5uwoGAUQ68Pfew74iw2e2v+NDI=; b=S0jegySx1zdxeXCA4onCfj6mZn9hBbfxRuPwUAM7Pj/Fm4VLA7YcpvAvtK/pRAiXAz WX3Q/7UvC6q9iK0NFlwsIfwkcYtC58u5op4QFq5o5vz+kSDD/hAgSKv/tZZUld/jJEzd 3KMythxaVfJeO/4Y2Zj9PakPMImju1AQshnMf4jucr2tXqb/hLzGcFVUOBJ1Bco/1qY1 MLZTK+YFAeAOx3V32B7BzwgVA7VOX/x+Mkdx2R5xTGCjw+0WnNjw0+mlW9mTTmRNduar 9VgGV6FrRiYeabBx9gdyXbLGj2vCjNJUj1PIQ06R4bT9gnRpBuBn6Asg2At9BnziJR+I bsFw== X-Received: by 10.66.228.133 with SMTP id si5mr12528578pac.48.1401396424543; Thu, 29 May 2014 13:47:04 -0700 (PDT) Received: from [192.168.178.23] (48.198.69.111.dynamic.snap.net.nz. [111.69.198.48]) by mx.google.com with ESMTPSA id sh5sm2740898pbc.21.2014.05.29.13.47.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 13:47:04 -0700 (PDT) Message-ID: <53879CCF.50204@gmail.com> Date: Fri, 30 May 2014 08:47:11 +1200 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: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7856@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7856@nkgeml506-mbx.china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qQV6nJLbBkvC1GDV_2D5c0KL4Bs Cc: v6ops WG , "v6ops-chairs@tools.ietf.org" , "dthaler@microsoft.com" , "bill@wjcerveny.com" Subject: Re: [v6ops] ULA #4 Refering Site-local addresses X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 20:47:10 -0000 On 29/05/2014 20:31, Liubing (Leo) wrote: > Hi, All > > We're going to update the ULA draft. Before making a new version, I think it would be helpful to confirm/discuss several important topics which were discussed in last IETF meeting. > > I'd like to discuss the topics in different mail threads respectively. > (Current draft link: http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02) > ****************************************************************************** > > # Refering Site-local addresses > > Bill and Dave suggested to refer site-local addresses. Because ULAs were intended to replace the gap left when site-local addresses were deprecated. > > Especially, Dave mentioned the site-local address based anycast utilization in former RFCs (e.g. RFC4339 to use site-local anycast as Recursive DNS discovery) and gave a pointer to the relevant stuff. > > I think it is good to add some texts referring site-local address as a background in the introduction Section. > But for the site-local anycast use case, I think of it as out of the scope of this ULA draft. Yes. If that needs work, it should be a separate document. For this document, why not simply refer to RFC3879? We had this discussion in 2003/2004. (And we said then "Further study is required on the need for anycast addresses with scope between link-local and global.") Brian > Because as I understood, since the site-local is deprecated, the anycast use cases based on site-local are invalid as well. And it is not a goal to re-produce these anycast use cases in a ULA form in a v6ops document, so I just feel like there is nothing to say about it. > > What are your thoughts? > > Regards, > Bing > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > . > From nobody Thu May 29 14:49:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F841A0960 for ; Thu, 29 May 2014 14:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.612 X-Spam-Level: * X-Spam-Status: No, score=1.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H_twu_EBBM5S for ; Thu, 29 May 2014 14:49:56 -0700 (PDT) Received: from nm30-vm0.bullet.mail.bf1.yahoo.com (nm30-vm0.bullet.mail.bf1.yahoo.com [98.139.213.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB2BD1A06B2 for ; Thu, 29 May 2014 14:49:55 -0700 (PDT) Received: from [66.196.81.173] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 29 May 2014 21:49:51 -0000 Received: from [98.139.212.225] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 29 May 2014 21:49:51 -0000 Received: from [127.0.0.1] by omp1034.mail.bf1.yahoo.com with NNFMP; 29 May 2014 21:49:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 166501.91189.bm@omp1034.mail.bf1.yahoo.com Received: (qmail 671 invoked by uid 60001); 29 May 2014 21:49:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1401400190; bh=CvCdF7PSp6f7Zck+QbeK7UlimRcdi7DKtxU7lfX9TWA=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=iOmpa123fFOAtoWHDMAcORRJphy7WLrYe4+oZ2sDlOIDqMgJOIDwgIDmeRwZv8+Q/t1q4sz97FdTVZvgx6yBa57iaCrimjT9hIMlcZPM93z9mQC0b7Ti3V6mSFstlPOjAe9eoVgS1F/tG49B6x6uJxALUaI9dE1R7o3tnH52Epw= X-YMail-OSG: 0JL4BsEVM1mfVbZQge.WCho5u7jlEZZHE2mixEp_dHo7FCr txXJQ9NWAZ9eSkVo8nCQ7ckc9nnRMjOXx9B2A_KyWqjm1aNe9F_BSfKk8UvU FgzLCQtv5CXqGo_61er550kPufSQhV73852WdEE2.8ELQ63VCE5xFrk9iH57 N6z2.H6FIr28L1S6zksAbNyyX02xbBhbdWZ4LdEQMeceVScLCFnhgSKq6ZxF QJwR81h_l9G6sO4JQxzVl6eqcGhxeXrxpWXj5hQ.pCQbEyB.Bwwa14Teklwi mNiJ722gt_Ze6f5h56Em1X1Q2SDrK_.w.mBsAAZI8EwMRlyBgkZfqCCyYAf2 6uq4uto2sECKIHxeuDii8..Lul1oeYjngRl76Gvx.DU2brCjSy5sT73KaFAI y5Y177ATIVLtGLxGxz9FbK5vaORy.wX9seZpOnNBh4iXP8T6oFk1oKkQuuak J8h7nxX.e70Ik4Cwg7Uvj2Y3ifjRV5oT3sHclzqqR9pl9TQ6vqNve3U0rMGJ e3SB6Np_oir06ZXV1TyHI9RkalqjjWjdb8cgCuIHLVMNpQUEIpwma Received: from [150.101.221.237] by web162201.mail.bf1.yahoo.com via HTTP; Thu, 29 May 2014 14:49:50 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBSYW5keSBCdXNoIDxyYW5keUBwc2cuY29tPgo.IFRvOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPgo.IENjOiB2Nm9wcyBXRyA8djZvcHNAaWV0Zi5vcmc.Cj4gU2VudDogVGh1cnNkYXksIDI5IE1heSAyMDE0IDEwOjI0IFBNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gVUxBIGRyYWZ0IHJldmlzaW9uICMyIFJlZ2FyZGluZyBpc29sYXRlZCBuZXR3b3Jrcwo.IAo.Pj4.PiAgcmVkIGhlcnJpbmcuwqABMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> <0ED911FA-D24C-4FC8-9D6A-F38F9711F115@steffann.nl> <5386AA9F.7000001@gmail.com> <538 6B0DF.9060401@gmail.com> Message-ID: <1401400190.16733.YahooMailNeo@web162201.mail.bf1.yahoo.com> Date: Thu, 29 May 2014 14:49:50 -0700 (PDT) From: Mark ZZZ Smith To: Randy Bush , Brian E Carpenter In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mGtLVd_aBAg3-Ee5cdE_h_4NbVg Cc: v6ops WG Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 21:49:57 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Randy Bush =0A> To: Brian E Carpenter =0A> Cc: v6ops WG= =0A> Sent: Thursday, 29 May 2014 10:24 PM=0A> Subject: Re:= [v6ops] ULA draft revision #2 Regarding isolated networks=0A> =0A>>>>> re= d herring.=A0 global prefixes designed to be used in place of =0A> ula shou= ld=0A>>>>> not be in the global routing table=0A>>>> Indeed they shouldn'= t, but since everybody should be filtering =0A> ULAs=0A>>>> (and most peop= le will do so), ULAs won't propagate but =0A> routeable GUAs=0A>>>> might.= =0A>>> explain why the two probability distributions will differ=0A>> Bec= ause I have considerable confidence that the majority of transit=0A>> oper= ators will know they need to filter fc00::/7, but the same cannot=0A>> be = said of arbitrary /48s from RIR space.=0A> =0A> i know.=A0 that's why we se= e no leaks of rfc1918 and ULA today.=A0 oh ...=0A> oops!=0A>=A0=0A=0AIt cer= tainly would be better if it didn't happen, but what significant harm does = it cause if it does? When did the Internet stop because RFC1918s were in th= e DFZ?=0A=0AEven if one AS accepts them, why are that AS's peers also accep= ting them? Isn't that either a statement of how undisciplined a significant= number of operators are being at ingress prefix filtering, or conversely, = a statement that the problem of private address space leaking into the DFZ = isn't as significant as you're saying it is, and operators aren't spending = time on policing it because they've got more significant problems to worry = about?=0A=0AThe origin AS and the AS path it took is available, so it shoul= d be easy to chase down the perpetrator and those who are aiding and abetti= ng.=0A=0A=0A> the real measurement i would take is to test the hypothesis t= hat utterly=0A> unrealistic fantasies about operations are highest in v6 re= ligious wgs.=0A>=A0=0A=0AIf you're worried about these sorts of things, wou= ldn't it be better to chasing people doing far worse damage to the DFZ, lik= e those not aggregating PI when they should be? Going by the latest reports= , there's up to 220K route table slots to be saved.=0A=0A=0A> randy=0A> =0A= > =0A> _______________________________________________=0A> v6ops mailing li= st=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman/listinfo/v6ops=0A> From nobody Thu May 29 16:15:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA7F1A06B7 for ; Thu, 29 May 2014 16:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIZ8ApJ_Bs0J for ; Thu, 29 May 2014 16:15:49 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 308E31A030D for ; Thu, 29 May 2014 16:15:49 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id lj1so1007090pab.3 for ; Thu, 29 May 2014 16:15:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=i/e3h3Inkppgn0QYC5BrD4FGgjL5ns3foHyLacE2I1k=; b=GV/ceMR6DIWNXKEc9aAHYfHzCa7t2cZ7aENo6kSQExs1Qvbq7biwZZksgsvE5j0o67 5kx4qFaY1yplM8qaHz4swnJ28IA7ciCJfvVDO1CpqlLlPYwPozmjR02AudSfdTyyic5N Zm0f4U+jAQMIRFIVgKr9kJgQ3L+M2bap1oVdLsGrrXt0Qv23g4gZqvY3gu0ge1NrLIzV HGXHG+xOpTYl7m/2MnPtnXvu9es/JuN6MnZBRiIPvMJs9TUsdhFXXMS35Wm398tCUBWe IXTJ1YsXaxgjyscNPn1JxFxKAs9iaszQ456pU6bUIJQdvYZ1HbRR0CB47sITDset3khV opcw== X-Gm-Message-State: ALoCoQntW5y9WbMKTSpy5pRJCBGM2FXusnSohNtkJIs7QsNw/bz3Lhyy302+WpOSMZS1zm7m8Emg MIME-Version: 1.0 X-Received: by 10.66.230.193 with SMTP id ta1mr13416261pac.29.1401405345122; Thu, 29 May 2014 16:15:45 -0700 (PDT) Received: by 10.70.37.78 with HTTP; Thu, 29 May 2014 16:15:45 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:a966:17ee:d662:5566] In-Reply-To: <20140529153211.BF69216E83F8@rock.dv.isc.org> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com> <5383C2CF.6040205@gmail.com> <1401230263.69077.YahooMailNeo@web162206.mail.bf1.yahoo.com> <53854B03.8040702@gmail.com> <1401312298.99614.YahooMailNeo@web162205.mail.bf1.yahoo.com> <20140529153211.BF69216E83F8@rock.dv.isc.org> Date: Fri, 30 May 2014 09:15:45 +1000 Message-ID: From: George Michaelson To: Mark Andrews Content-Type: multipart/alternative; boundary=047d7b15abb1c861ed04fa921bb7 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KqBRqgnxLDPsq5DgUty1mC6SgKg Cc: v6ops WG Subject: Re: [v6ops] (re)numbering [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 23:15:51 -0000 --047d7b15abb1c861ed04fa921bb7 Content-Type: text/plain; charset=UTF-8 How long ago Mark. How old, What OS. If this is a UNISYS mainframe which used , to separate the elements of the dotted-quad for instance (yes, that really happened) we'd be entitled to say "so what" if this is a Vista or newer OS, we need to know. On Fri, May 30, 2014 at 1:32 AM, Mark Andrews wrote: > > In message o3adK5a7M5DOFGVa1GnjKxj3bNRq6896nBQGLOTVQ@mail.gmail.com> > , Matthew Petach writes: > > > > On Wed, May 28, 2014 at 2:24 PM, Mark ZZZ Smith < > markzzzsmith@yahoo.com.au> > > wrote: > > [...] > > > > > RFC1918s have provided that internal connectivity robustness to both > home > > > networks and enterprise networks. Of course the drawback is that in > IPv4 it > > > is binary - hosts either have RFC1918s or public addresses, so if you > have > > > RFC1918s you have to use NAT to access external destinations on the > > > Internet. > > > > Wow...that's news to me. > > > > For a decade now, I've been using > > RFC1918 addresses+global addresses > > in IPv4 on my home network; each > > host has an address from each subnet, > > and uses the 1918 addresses to reach > > internal-only devices (printers, terminal > > servers, etc.) which only have RFC1918 > > addresses, and use the globally routed > > IPs for reaching non-local destinations. > > > > I'm not sure I'd agree with your characterization > > that IPv4 is different from IPv6 in that regards; > > there's nothing in the IPv4 world that prevents > > hosts from having multiple addresses, and > > making use of them. > > > > It's definitely a plus to have internal connectivity > > stay working regardless of external connectivity, > > I completely agree with you on that. > > > > Matt > > It may work with some machine some of the time. It is not guarenteed > to work with all machines all of the time. I've definitely used > machines which didn't support multiple IPv4 addresses on the same > interface. > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b15abb1c861ed04fa921bb7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How long ago Mark. How old, What OS.

If= this is a UNISYS mainframe which used , to separate the elements of the do= tted-quad for instance (yes, that really happened) we'd be entitled to = say "so what"

if this is a Vista or newer OS, we need to know.
<= /div>


On Fri, = May 30, 2014 at 1:32 AM, Mark Andrews <marka@isc.org> wrote:

In message <CAEmG1=3Drz=3Do3adK5a7M5DOFGVa1GnjKxj3bNRq6896nBQGLOTVQ@mai= l.gmail.com>
, Matthew Petach writes:
>
> On Wed, May 28, 2014 at 2:24 PM, Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
> wrote:
> [...]
>
> > RFC1918s have provided that internal connectivity robustness to b= oth home
> > networks and enterprise networks. Of course the drawback is that = in IPv4 it
> > is binary - hosts either have RFC1918s or public addresses, so if= you have
> > RFC1918s you have to use NAT to access external destinations on t= he
> > Internet.
>
> Wow...that's news to me.
>
> For a decade now, I've been using
> RFC1918 addresses+global addresses
> in IPv4 on my home network; each
> host has an address from each subnet,
> and uses the 1918 addresses to reach
> internal-only devices (printers, terminal
> servers, etc.) which only have RFC1918
> addresses, and use the globally routed
> IPs for reaching non-local destinations.
>
> I'm not sure I'd agree with your characterization
> that IPv4 is different from IPv6 in that regards;
> there's nothing in the IPv4 world that prevents
> hosts from having multiple addresses, and
> making use of them.
>
> It's definitely a plus to have internal connectivity
> stay working regardless of external connectivity,
> I completely agree with you on that.
>
> Matt

It may work with some machine some of the time. =C2=A0It is not= guarenteed
to work with all machines all of the time. =C2=A0I've definitely used machines which didn't support multiple IPv4 addresses on the same
interface.


--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 INTE= RNET: marka@isc.org

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

--047d7b15abb1c861ed04fa921bb7-- From nobody Thu May 29 17:42:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A7A1A04A4 for ; Thu, 29 May 2014 17:42:04 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1V0Ho76ZE-3Y for ; Thu, 29 May 2014 17:42:01 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043A61A02B5 for ; Thu, 29 May 2014 17:42:00 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id y20so1051547ier.8 for ; Thu, 29 May 2014 17:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pA7Cm5e0d1pHDKx0HOUlRUv6xlL6Tz7SFZYGT8h7CxM=; b=j0mOdaLeoUjGk8J5+6MpfZBNYCNQK34G+BWaw96/MjK6q/SF0VnWM50kMrh0xWZrTW ZG5s1FpiaxwZZ3hqfOCfw6ijCweqZdf6py80cKxyF1pcz1rFldOMx9bevhoTvszEmHQP FDI/ij11SxKrBk1U6jVuCFJ5OkSrK76Sz7vsX5x3IHSx0T1j65nhomOvBUzjshmhhHkp InqX7yiSE8envF9XiR0nb/aEOvCQE5n8oBFovOP716MFFkc386O8ExkcN4EDzenHvNss HmKx1LA1u7+vQqLFuB/q8E7+x/ubcYc3wLpTFLPUyn5yMlcRUPh2fYcqsWlZlcbaHIGN s6dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=pA7Cm5e0d1pHDKx0HOUlRUv6xlL6Tz7SFZYGT8h7CxM=; b=k2eu9Z6VP8+zoqZo/nNKujIDDhQA4AslOd6kyLnkjDq27jez6g/CiB7qBBt2wYGPt5 F1+TTm9Pse5qsw8MFLvhJ7C43ZHuXp89cyZq/yryrlwX9sf/dAdPTpwRdphuyAZ6RhLx s4Lk6kEjAwVoBJdYAbRgxlILUWSduHTiGsgEQDgSSDIPfRCOqBq1cKFD7wyRvJiCYK1j nUcd4aiueZFgH//x1PJoqzKZ/ZkdAVOKgFMIsMrX3mTS2XZ8/GwBIlWOV08wmzWLq1aL VuXWLgUXwnmjd+chLsXYZeqGtHrm8zpg01VefzpxAPt0zzWMWBtiXxB0W8+nJxkdVVpi fiVg== X-Gm-Message-State: ALoCoQl4+ThoPjLesv+Dl7ekbIx0DPwd/Z3ckBDR3+b00wZTTJKkbMjZeRYfdYzj00aaZgsp+5kk X-Received: by 10.50.153.49 with SMTP id vd17mr1089211igb.40.1401410516748; Thu, 29 May 2014 17:41:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.203 with HTTP; Thu, 29 May 2014 17:41:36 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Fri, 30 May 2014 09:41:36 +0900 Message-ID: To: Lee Howard Content-Type: multipart/alternative; boundary=089e014954be0930cf04fa935033 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/V24jQF-I7xVn9I7CUfO5_Unqngg Cc: v6ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] ULA #3 NPTv6 Use Case X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 00:42:05 -0000 --089e014954be0930cf04fa935033 Content-Type: text/plain; charset=UTF-8 On Fri, May 30, 2014 at 12:46 AM, Lee Howard wrote: > As you note, there's no IPv6 NAT specification other than NPT66. There > hasn't been consensus to define it, and I think there is still not > consensus to do so. Would it be useful to describe why it hasn't been > defined? Or would it help if there were a separate document that this > Recommendations document could reference? > It's also relevant to note that NPT66 is experimental, and that we have not seen any reports of its deployment so far. The network that ostensibly "needed it" on a large scale and rushed it through the IETF (the NTT NGN, which needs it to get around complex regulatory issues which I won't bore this thread with), has not yet deployed it because, guess what, it broke their apps. --089e014954be0930cf04fa935033 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, May 30, 2014 at 12:46 AM, Lee Howard <Lee@asgard.org> wrote= :
As you note, there's no IPv6 NAT specification other th= an NPT66. There
hasn't been consensus to define it, and I think there is still not
consensus to do so. =C2=A0Would it be useful to describe why it hasn't = been
defined? =C2=A0Or would it help if there were a separate document that this=
Recommendations document could reference?

It's also relevant to note that NPT66 is experimental, and that we h= ave not seen any reports of its deployment so far. The network that ostensi= bly "needed it" on a large scale and rushed it through the IETF (= the NTT NGN, which needs it to get around complex regulatory issues which I= won't bore this thread with), has not yet deployed it because, guess w= hat, it broke their apps.
--089e014954be0930cf04fa935033-- From nobody Thu May 29 17:45:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0053B1A0722 for ; Thu, 29 May 2014 17:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6TwNXT_9u41 for ; Thu, 29 May 2014 17:45:50 -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 3CC771A02B5 for ; Thu, 29 May 2014 17:45:50 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 704DD349427; Fri, 30 May 2014 00:45:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B4D8C160068; Fri, 30 May 2014 00:51:03 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 56C14160054; Fri, 30 May 2014 00:51:03 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id C4D1616FC229; Fri, 30 May 2014 10:45:41 +1000 (EST) To: George Michaelson From: Mark Andrews References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com> <5383C2CF.6040205@gmail.com> <1401230263.69077.YahooMailNeo@web162206.mail.bf1.yahoo.com> <53854B03.8040702@gmail.com> <1401312298.99614.YahooMailNeo@web162205.mail.bf1.yahoo.com> <20140529153211.BF69216E83F8@rock.dv.isc.org> In-reply-to: Your message of "Fri, 30 May 2014 09:15:45 +1000." Date: Fri, 30 May 2014 10:45:41 +1000 Message-Id: <20140530004541.C4D1616FC229@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8W3F_docbovDfK9JSanwaEW8w_I Cc: v6ops WG Subject: Re: [v6ops] (re)numbering [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 00:45:53 -0000 In message , George Michaelson writes: > > How long ago Mark. How old, What OS. A Brother HL-4040CN printer only supports a single IPv4 address and it has IPv6 support. To be fair only supports configuring a single static IPv6 address but will autoconf multiple ones. It currently 3 IPv6 addresses (PI + ULA + LL). This is the difference between what is required by a host/node for IPv4 and IPv6. Support for multiple prefixes is required for IPv6. It isn't required for IPv4. > If this is a UNISYS mainframe which used , to separate the elements of the > dotted-quad for instance (yes, that really happened) we'd be entitled to > say "so what" > > if this is a Vista or newer OS, we need to know. > > > On Fri, May 30, 2014 at 1:32 AM, Mark Andrews wrote: > > > > > In message > o3adK5a7M5DOFGVa1GnjKxj3bNRq6896nBQGLOTVQ@mail.gmail.com> > > , Matthew Petach writes: > > > > > > On Wed, May 28, 2014 at 2:24 PM, Mark ZZZ Smith < > > markzzzsmith@yahoo.com.au> > > > wrote: > > > [...] > > > > > > > RFC1918s have provided that internal connectivity robustness to both > > home > > > > networks and enterprise networks. Of course the drawback is that in > > IPv4 it > > > > is binary - hosts either have RFC1918s or public addresses, so if you > > have > > > > RFC1918s you have to use NAT to access external destinations on the > > > > Internet. > > > > > > Wow...that's news to me. > > > > > > For a decade now, I've been using > > > RFC1918 addresses+global addresses > > > in IPv4 on my home network; each > > > host has an address from each subnet, > > > and uses the 1918 addresses to reach > > > internal-only devices (printers, terminal > > > servers, etc.) which only have RFC1918 > > > addresses, and use the globally routed > > > IPs for reaching non-local destinations. > > > > > > I'm not sure I'd agree with your characterization > > > that IPv4 is different from IPv6 in that regards; > > > there's nothing in the IPv4 world that prevents > > > hosts from having multiple addresses, and > > > making use of them. > > > > > > It's definitely a plus to have internal connectivity > > > stay working regardless of external connectivity, > > > I completely agree with you on that. > > > > > > Matt > > > > It may work with some machine some of the time. It is not guarenteed > > to work with all machines all of the time. I've definitely used > > machines which didn't support multiple IPv4 addresses on the same > > interface. > > > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > --047d7b15abb1c861ed04fa921bb7 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > >
How long ago Mark. How old, What OS.

If= > this is a UNISYS mainframe which used , to separate the elements of the do= > tted-quad for instance (yes, that really happened) we'd be entitled to = > say "so what"
>

if this is a Vista or newer OS, we need to know.
<= > /div>


On Fri, = > May 30, 2014 at 1:32 AM, Mark Andrews < to:marka@isc.org" target=3D"_blank">marka@isc.org> wrote:
>
x #ccc solid;padding-left:1ex">
> In message <CAEmG1=3Drz=3D 6896nBQGLOTVQ@mail.gmail.com">o3adK5a7M5DOFGVa1GnjKxj3bNRq6896nBQGLOTVQ@mai= > l.gmail.com>
>
, Matthew Petach writes:
> >
> > On Wed, May 28, 2014 at 2:24 PM, Mark ZZZ Smith < markzzzsmith@yahoo.com.au">markzzzsmith@yahoo.com.au>
> > wrote:
> > [...]
> >
> > > RFC1918s have provided that internal connectivity robustness to b= > oth home
> > > networks and enterprise networks. Of course the drawback is that = > in IPv4 it
> > > is binary - hosts either have RFC1918s or public addresses, so if= > you have
> > > RFC1918s you have to use NAT to access external destinations on t= > he
> > > Internet.
> >
> > Wow...that's news to me.
> >
> > For a decade now, I've been using
> > RFC1918 addresses+global addresses
> > in IPv4 on my home network; each
> > host has an address from each subnet,
> > and uses the 1918 addresses to reach
> > internal-only devices (printers, terminal
> > servers, etc.) which only have RFC1918
> > addresses, and use the globally routed
> > IPs for reaching non-local destinations.
> >
> > I'm not sure I'd agree with your characterization
> > that IPv4 is different from IPv6 in that regards;
> > there's nothing in the IPv4 world that prevents
> > hosts from having multiple addresses, and
> > making use of them.
> >
> > It's definitely a plus to have internal connectivity
> > stay working regardless of external connectivity,
> > I completely agree with you on that.
> >
> > Matt
>
>
It may work with some machine some of the time. =C2=A0It is not= > guarenteed
> to work with all machines all of the time. =C2=A0I've definitely used r> > machines which didn't support multiple IPv4 addresses on the same
> interface.
>
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2= > 9871 4742 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 INTE= > RNET: marka@isc.org
>

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

> > --047d7b15abb1c861ed04fa921bb7-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu May 29 17:46:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632271A0756 for ; Thu, 29 May 2014 17:46:51 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFWimbMa0qCT for ; Thu, 29 May 2014 17:46:49 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 101BC1A0734 for ; Thu, 29 May 2014 17:46:49 -0700 (PDT) Received: by mail-ig0-f171.google.com with SMTP id c1so212993igq.10 for ; Thu, 29 May 2014 17:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=k1H5pJK8i9Edhfth+3g6N8u5kVcwHPIiXFM0Y0NBSlI=; b=Nu3GVEoM4MqybOw/LAETEDZrBIdP/b+PcCw458CMhKlnsmfUmAjVorTAYkM3wths8T XhVL0bbhAkV4fwoCHhmGqC+THKb1XCUVOGc7+O4HmBj++XLuRtpKXvUb0pe12JHIUUfs 5jw7UFGYvcMTovzs57by8zWSnd214Mupj1Qpmwv3GlQ4GJjNCMReV5791rq8ZV1dLgqG n5apMNt/eY+Qd915c8fknuZUA5jjPxfMvQFEEagm6/+KfXcsWLkfpMi5V6VbLUFzQQUy C8Z6FU4Sa5J/9ny0HPthV+FwQIuglFBwKYrxcZek35W091OIOJd2+sZELMCXH4TAEOJS 9sag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=k1H5pJK8i9Edhfth+3g6N8u5kVcwHPIiXFM0Y0NBSlI=; b=fC3jfurxPeuaanrUDMfXn1IlDFT29KRru7UgD9eM6+Cs2ED9o20EmU7fW3l1Wpw6Uz wZ2xtxn96N8Mvxx71XMONCH1j7IF1jU2YXxaKrUgFVmQS+3gUbx6ydnqyOJ6dLhb14Si oFE82eNGDxDzWDQUxeTeJyTU2HfPWy/5TNwtR1Mjt5pw/FOxluoZKDZvwx7BbAU9U8YX AWcGkYbUnfLkdZqBS3SlXyOWXHeJCVxv+rKFLrtahNcHxL4OaWE0J+irZLBgwB3yVCce cDDO8tnhZsme504wLpLji2uBJEQ/qj2rzm9abYhP6NcfPTfQ0ptt8t35y9URcDS76eKe 5Row== X-Gm-Message-State: ALoCoQkOV9yJYRo4fNcd094A7mc0sbRNTghtmKMzWZ2VLqp9HZ2V/EDTp2jDfDeSw13ZgLFyEcmF X-Received: by 10.50.26.3 with SMTP id h3mr965320igg.31.1401410804765; Thu, 29 May 2014 17:46:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.203 with HTTP; Thu, 29 May 2014 17:46:24 -0700 (PDT) In-Reply-To: <39f250c48a1d487eb404dc8394eddfe7@BY2PR03MB412.namprd03.prod.outlook.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7856@nkgeml506-mbx.china.huawei.com> <39f250c48a1d487eb404dc8394eddfe7@BY2PR03MB412.namprd03.prod.outlook.com> From: Lorenzo Colitti Date: Fri, 30 May 2014 09:46:24 +0900 Message-ID: To: Dave Thaler Content-Type: multipart/alternative; boundary=047d7bd7697034355c04fa936194 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NguEX3_UnpzfwnosCnMkWCnPTiI Cc: v6ops WG , "v6ops-chairs@tools.ietf.org" , "bill@wjcerveny.com" Subject: Re: [v6ops] ULA #4 Refering Site-local addresses X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 00:46:51 -0000 --047d7bd7697034355c04fa936194 Content-Type: text/plain; charset=UTF-8 On Fri, May 30, 2014 at 2:35 AM, Dave Thaler wrote: > > What are your thoughts? > > I think v6ops needs to say what the replacement is. Deprecating something > useful with no replacement hasn't really helped anything. I agree that deprecating something with no replacement is not useful, but the fact of the matter is that there *is* no replacement, and this infrormational document can't change that - that ship sailed in 2004 with standards track RFC 3879. I agree with Brian that if we need a replacement for this, it would have to be a separate document. An informational about ULA usage is not the right place to create such a replacement. --047d7bd7697034355c04fa936194 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, May 30, 2014 at 2:35 AM, Dave Thaler <dthaler@microsoft.com>= ; wrote:
> What are your thoughts?

I think v6ops needs to say what the replacement is. =C2=A0Deprecating somet= hing
useful with no replacement hasn't really helped anything.
<= div>
I agree that deprecating something with no replacement i= s not useful, but the fact of the matter is that there *is* no replacement,= and this infrormational document can't change that - that ship sailed = in 2004 with standards track RFC=C2=A03879.

I agree with Brian that if we need a replacement for th= is, it would have to be a separate document. An informational about ULA usa= ge is not the right place to create such a replacement.
--047d7bd7697034355c04fa936194-- From nobody Thu May 29 17:59:26 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2441A02BE for ; Thu, 29 May 2014 17:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MVeHpZLC3gR for ; Thu, 29 May 2014 17:59: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 C0E6B1A02B5 for ; Thu, 29 May 2014 17:59:22 -0700 (PDT) Received: from [IPv6:2620::930:0:225:ff:fe44:af17] ([IPv6:2620:0:930:0:225:ff:fe44:af17]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s4U0wZii019840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 29 May 2014 17:58:36 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s4U0wZii019840 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1401411517; bh=jzvSx49uwkLHVSD2Ui4VpfKfrXE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=vA/2Cqzgru4VgbXRwW6QRMMUw3O9HYphjNm6ApT71GOuEOHNMOOwnhHbAcEbWbMRp BbH950jU/UpVGf2/LtOqg4IzYbPkjhogFp+0ENhlb461u2qXrKiK05ETAJ5qNmq/xi j95cB0wLTJ+XRimoB7mI0DE09EnRHeoWADqx119M= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <538649A4.6010103@gmail.com> Date: Thu, 29 May 2014 18:01:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <67F00C7B-0BBB-4E49-8896-193E5ACAC4E4@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <2E2EC822-60EB-4B09-8BB3-D8FB098EB181@delong.com> <4FF6E348-6BB5-473A-8E94-4A3EE8BD32DC@nominum.com> <53855130.8040105@gmail.com> <53856628.2070201@gmail.com> <4042F444-2A43-499C-823E-52BCDEF112CE@nominum.com> <538649A4.60! 10103@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 29 May 2014 17:58:37 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qs8ufRDtWVQsdaPyf5zY_Lzy4sU Cc: Philip Homburg , v6ops WG Subject: Re: [v6ops] Routing /48s [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 00:59:24 -0000 On May 28, 2014, at 1:40 PM, Brian E Carpenter = wrote: > On 29/05/2014 00:21, Ted Lemon wrote: >> On May 28, 2014, at 12:29 AM, Brian E Carpenter = wrote: >>> On the other hand, and I speak from experience, persuading IT = departments >>> to support SADR is harder than persuading them to allow multiple = prefixes. >>=20 >> Do we have implementations we could in theory try to persuade them to = run? >=20 > I was referring to SADR in a site border router that leads to two > different ISPs. That, I understand, is readily available but requires > extra config and extra cycles. Most administrators in the enterprise world refer to this as =93policy = based routing=94 as that=92s what many of the vendors call it, too. It almost always comes with the additional baggage of dropping you out = of fast-path hardware forwarding onto control-plane based forwarding. Owen From nobody Thu May 29 18:28:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7C51A0700 for ; Thu, 29 May 2014 18:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqWlv3fkEYac for ; Thu, 29 May 2014 18:28:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E6E01A0704 for ; Thu, 29 May 2014 18:28:14 -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.7-GA FastPath queued) with ESMTP id BHK58829; Fri, 30 May 2014 01:28:09 +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.3.158.1; Fri, 30 May 2014 02:27:33 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 30 May 2014 02:28:08 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 30 May 2014 09:28:05 +0800 From: "Liubing (Leo)" To: Ted Lemon Thread-Topic: [v6ops] ULA #3 NPTv6 Use Case Thread-Index: Ac97GAB2NXqeld5VTvWJRzzv6gdUWP//g0GA//93Q8CAAM+TgP/+rqMg Date: Fri, 30 May 2014 01:28:04 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7BF9@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B79AA@nkgeml506-mbx.china.huawei.com> <1DAB3EA9-DDC4-4497-ADA7-9E234B5D17BB@nominum.com> In-Reply-To: <1DAB3EA9-DDC4-4497-ADA7-9E234B5D17BB@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.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BpeWAAdErvMfpV9_1-0jxLi2yi0 Cc: v6ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] ULA #3 NPTv6 Use Case X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 01:28:20 -0000 Hi Ted, Thanks much for the information.=20 It seems the assumption of resource-constrained nodes couldn't support mult= i-prefixes is invalid. I'll delete the case in the draft. Regards, Bing > -----Original Message----- > From: Ted Lemon [mailto:ted.lemon@nominum.com] > Sent: Thursday, May 29, 2014 9:16 PM > To: Liubing (Leo) > Cc: Lorenzo Colitti; v6ops-chairs@tools.ietf.org; v6ops WG > Subject: Re: [v6ops] ULA #3 NPTv6 Use Case >=20 > On May 29, 2014, at 5:32 AM, Liubing (Leo) > wrote: > > I know discussion on Question 1 (the resource-constrained use case) was > controversial. It is ok for me to move it out, just a confirmation to the= WG. >=20 > I've asked for some review from the IntArea directorate, and so far the o= ne > response I've gotten back, from someone who's implemented an LLN stack, > is that RPL is by far more complicated than supporting multiple prefixes,= and > that while they do support ULAs for address stability during periods of > disconnection, they support that alongside global addressing. >=20 > It would be useful to hear from more implementors. >=20 From nobody Thu May 29 18:39:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B691A072B for ; Thu, 29 May 2014 18:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZcHENj69nYJ for ; Thu, 29 May 2014 18:39: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 780F21A0726 for ; Thu, 29 May 2014 18:39:07 -0700 (PDT) Received: from [IPv6:2620::930:0:225:ff:fe44:af17] ([IPv6:2620:0:930:0:225:ff:fe44:af17]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s4U1cJ05020495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 29 May 2014 18:38:20 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s4U1cJ05020495 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1401413900; bh=EITs2KgOrPqDAuYjnrLSqOU/ve0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=FoKcaJ2wHRVo8wLYV2ghmJ0xdrc0bXkgXBRPyR8fImtf6ZZXu08ayQaBHEyjuyHMK hJMTg89uMvh+NA1zabqj4fNyoG0NVTOONwQCDCcuX/0Ws3pl9f68xtTvW0/xgda+kx xpgC3AGABkeYBK28suXZ6g4C27R0hPC4TvXPuY9w= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <53865AA6.2080905@fud.no> Date: Thu, 29 May 2014 18:41:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <128B89BC-2EBB-4B9C-94DA-56460E5514C6@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <6740CB67-2CE3-4F41-A513-971C3307975D@delong.com> <53865AA6.2080905@fud.no> To: Tore Anderson X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 29 May 2014 18:38:20 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/fu6I8fytWaRg0joYaOkraHBVbmI Cc: V6 Ops List Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 01:39:09 -0000 On May 28, 2014, at 2:52 PM, Tore Anderson wrote: > * Owen DeLong >=20 >> On May 28, 2014, at 2:21 AM, Tore Anderson wrote: >>=20 >>> We have a few customers in the same situation. So we obtained a PI >>> prefix for them, which costs next to nothing in the RIPE region at >>> least, and advertise the prefix on their behalf (and in the cases=20 >>> where there's a second upstream, the second upstream does the=20 >>> same). Works perfectly well, and is much less complex than >>> anything solution involving ULA, NAT, multiple prefixes on the >>> hosts, or whatever. The customer just gets a bunch of addresses he >>> can use in perpetuity. >>=20 >> Exactly, but it does have the drawback of black holing traffic in=20 >> certain failure modes. >=20 > If the upstream starts blackholing in his core network somewhere and = the > customer is singlehoming, he's toast no matter how he's connected to = the > upstream. If he's multihoming, however, he can just physically pull = the > plug or shut the interface and traffic converges on the remaining good > upstream, in pretty much in the same way it would if he used BGP. If I=E2=80=99m advertising to the upstreams via BGP, then when I drop = the routes to them, they stop advertising them to the world and thus there=E2=80=99s = no black hole. OTOH, when you=E2=80=99re advertising my routes on a static basis = without peering with me, then if I drop my connection to you, your routers don=E2=80=99t = know/don=E2=80=99t care and still keep advertising my routes. > Of course, if the problematic upstream provider doesn't withdraw the = BGP > announcement when the customer shuts his interface then there's still > going to be a problem, but that's equally true both for connections = with > or without BGP between the provider and the customer. Sure, but it=E2=80=99s much more common in the scenario you described = than in the scenario where the customer is sending you BGP announcements and you = don=E2=80=99t know about the customer=E2=80=99s prefix other than when you hear it = from the customer via BGP. > Blackholing of traffic during failure modes is something you can get > with any form of deployment. The way I see it, the use of BGP or = non-use > of BGP doesn't really change the risks of this happening either for = the > worse or the better. So I don=E2=80=99t quite see why you call this a = =C2=ABdrawback=C2=BB. Then you are living in an imaginary world where magic happens without a = routing protocol to prevent continued advertisement of a prefix that no longer = has a feasible successor. In the real world, this usually doesn=E2=80=99t = happen without a routing protocol. >> If you really want to avoid an ASN (not sure why), it is possible to >> do this using a private ASN that is stripped off by the upstream >> provider(s), but using a real ASN is much simpler. >=20 > It's not I who want to avoid it, it's the end user. He doesn't > necessarily know how internet routing works, how to set up or operate > BGP, have equipment that can do so [without extra licences], and so > forth. Even if he does, he might not want the extra bother. So the = point > isn't to avoid an ASN - if the customer is going to use BGP it's = simpler > with an ASN than without - but to avoid requiring BGP. Since I can run sufficient BGP for an end site on a Raspberry PI with a second ethernet, using free software, I have trouble buying that = argument. As to the =E2=80=9Chow to configure=E2=80=9D problem, that=E2=80=99s 2 = hours (max) of some consultants time (any smart ISP offers this as a professional services value add) = and can be pretty much fire and forget for the scenario in question. > Where the end user simply wants plain no bells-and-whistles internet > service, but require addresses that work with >1 upstream provider > simultaneously or which may be kept should he decide to switch = providers > in the future, using a PI prefix that his upstream(s) originate into = the > DFZ on his behalf is a really simple solution that actually works = today > both for IPv6 *and* IPv4 (if you have them, that is). It's much less > complex than any solution I've seen that involves ULAs, NPT/NAT, BGP, > multi-prefixes, or anything else, which makes it my preferred way of > catering to the customers in question - for now. It=E2=80=99s really not less complex than BGP where the customer = advertises his prefix and receives default. Nor does it require particularly expensive hardware. Admittedly, the R-PI is probably a little too low-brow for most situations, but a Juniper SRX-100, <$200 Mikrotik, or a variety of other solutions can be made to work for =E2=89=A4$600 total hardware and = software. Most of them can even take a full IPv6 table, while you get into real = money if you want a full IPv4 table. Owen From nobody Thu May 29 18:44:27 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3B71A076A for ; Thu, 29 May 2014 18:44:17 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOMM9PdBCp0J for ; Thu, 29 May 2014 18:44:02 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B63A1A0763 for ; Thu, 29 May 2014 18:44:02 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id l13so260809iga.16 for ; Thu, 29 May 2014 18:43:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=q4S3jXH7Gv7dZ/LT7Pn0l5pdom9gJeXQCdk80CHkhCM=; b=KTZgDn+VXb1k0DuboYAFfH95z7mO2kCbXC5vep5QMW3HyKcfqqXKMcoW83kVm3DBmJ eSFQS7RXFTu3c+3etlT7y/JTymy2AOeVLFZ6XBM9T9hQdltgNhBrnG23wXRF0RTuHF8+ Djd1aJhz63EuvPkMZ4buF8zV1yBHUTF+ZVbn8CXtwAo9OwC5Gqwd9egd53Z+ivZuoc8+ TeruTXtJXeqZiB86wHfZLFLknClQPVf6GtHPyz/aD+ohfxOn/0IDvWxN9YlmZymX5yyJ 38YuGZjTbjyCAXHKTHy8HsBI5ZP00TSHKeZz+POBjv3GhjuiM21CPHS5A+UViPhaYWVW /aWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=q4S3jXH7Gv7dZ/LT7Pn0l5pdom9gJeXQCdk80CHkhCM=; b=fFI+0oNPjRceqR486ieaVv+yrPWjYbBtHT6Ue9kfY5KKbfWZCsG0dKgCGD7MLiZGmt 2PfmIFMdnHPT6z7QtqnSO3cO9jwk7VnuRRxqTiEjygkgMO3LqhUtZ2u6+2PEtl1W+v8j AaSefJ8KeS7uz4NGi3gq6456CEONe9tbHKfTe7QNZUH5fxW4wRlqQR9ROeVtfYqcvPDc tYNqNfga/5WC5kGvHZQsJq0+ouLlvOHSfTghNp8sURJog38CLgqqyoeGmqcqDnDj+9WA 5H2nHCsdNBlbQFlWGky2Vv+FYtq6SH9TqVqRU/IltXaXP5dwhiWsuTP1rAmd75rEnfFZ ibPg== X-Gm-Message-State: ALoCoQnOXalzdL0djIJTvrmHWBPhFVcJ/4KOGB6Km7qQ5rM5AYGit7Fd5K966zj5U6onCMnN8aRS X-Received: by 10.43.155.16 with SMTP id lg16mr11680343icc.65.1401414238369; Thu, 29 May 2014 18:43:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.203 with HTTP; Thu, 29 May 2014 18:43:38 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7BF9@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B79AA@nkgeml506-mbx.china.huawei.com> <1DAB3EA9-DDC4-4497-ADA7-9E234B5D17BB@nominum.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7BF9@nkgeml506-mbx.china.huawei.com> From: Lorenzo Colitti Date: Fri, 30 May 2014 10:43:38 +0900 Message-ID: To: "v6ops-chairs@tools.ietf.org" Content-Type: multipart/alternative; boundary=001a11c2d950dc9b1204fa942d2d Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qogZlwsyB-I3ZGjYr5lyQ_gOB-Q Cc: v6ops WG Subject: Re: [v6ops] ULA #3 NPTv6 Use Case X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 01:44:17 -0000 --001a11c2d950dc9b1204fa942d2d Content-Type: text/plain; charset=UTF-8 Chairs, It seems that question 1 is now resolved. Before we discuss questions #2 and #3, I have not seen a response to my question about whether you believe the working group should re-engage in this debate or not. Should we consider Question #2 or #3? Or is it your reading that we've discussed this recently with no consensus, that therefore there's no point in discussing that again, and that the document should not cite a ULA+NPT66 use case? Thanks, Lorenzo On Fri, May 30, 2014 at 10:28 AM, Liubing (Leo) wrote: > Hi Ted, > > Thanks much for the information. > It seems the assumption of resource-constrained nodes couldn't support > multi-prefixes is invalid. I'll delete the case in the draft. > > Regards, > Bing > > > -----Original Message----- > > From: Ted Lemon [mailto:ted.lemon@nominum.com] > > Sent: Thursday, May 29, 2014 9:16 PM > > To: Liubing (Leo) > > Cc: Lorenzo Colitti; v6ops-chairs@tools.ietf.org; v6ops WG > > Subject: Re: [v6ops] ULA #3 NPTv6 Use Case > > > > On May 29, 2014, at 5:32 AM, Liubing (Leo) > > wrote: > > > I know discussion on Question 1 (the resource-constrained use case) was > > controversial. It is ok for me to move it out, just a confirmation to > the WG. > > > > I've asked for some review from the IntArea directorate, and so far the > one > > response I've gotten back, from someone who's implemented an LLN stack, > > is that RPL is by far more complicated than supporting multiple > prefixes, and > > that while they do support ULAs for address stability during periods of > > disconnection, they support that alongside global addressing. > > > > It would be useful to hear from more implementors. > > > > --001a11c2d950dc9b1204fa942d2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Chairs,

It seems that question 1 is now= resolved. Before we discuss questions #2 and #3, I have not seen a respons= e to my question about whether you believe the working group should re-enga= ge in this debate or not.

Should we consider Question #2 or #3? Or is it your rea= ding that we've discussed this recently with no consensus, that therefo= re there's no point in discussing that again, and that the document sho= uld not cite a ULA+NPT66 use case?

Thanks,
Lorenzo


On Fri, May 30, 2014 at 10:28 AM, Liubing (Leo) <le= o.liubing@huawei.com> wrote:
Hi Ted,

Thanks much for the information.
It seems the assumption of resource-constrained nodes couldn't support = multi-prefixes is invalid. I'll delete the case in the draft.

Regards,
Bing

> -----Original Message-----
> From: Ted Lemon [mailto:ted.lemon@nominum.com]
> Sent: Thursday, May 29, 2014 9:16 PM
> To: Liubing (Leo)
> Cc: Lorenzo Colitti; v6ops-chairs@tools.ietf.org; v6ops WG
> Subject: Re: [v6ops] ULA #3 NPTv6 Use Case
>
> On May 29, 2014, at 5:32 AM, Liubing (Leo) <leo.liubing@huawei.com>
> wrote:
> > I know discussion on Question 1 (the resource-constrained use cas= e) was
> controversial. It is ok for me to move it out, just a confirmation to = the WG.
>
> I've asked for some review from the IntArea directorate, and so fa= r the one
> response I've gotten back, from someone who's implemented an L= LN stack,
> is that RPL is by far more complicated than supporting multiple prefix= es, and
> that while they do support ULAs for address stability during periods o= f
> disconnection, they support that alongside global addressing.
>
> It would be useful to hear from more implementors.
>


--001a11c2d950dc9b1204fa942d2d-- From nobody Thu May 29 18:44:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D4E1A0776 for ; Thu, 29 May 2014 18:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.041 X-Spam-Level: X-Spam-Status: No, score=-1.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, J_CHICKENPOX_27=0.6, LOTS_OF_MONEY=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uc2zpv4biQQj for ; Thu, 29 May 2014 18:44: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 C83A11A0775 for ; Thu, 29 May 2014 18:44:37 -0700 (PDT) Received: from [IPv6:2620::930:0:225:ff:fe44:af17] ([IPv6:2620:0:930:0:225:ff:fe44:af17]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s4U1fd9e020867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 29 May 2014 18:41:40 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s4U1fd9e020867 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1401414100; bh=i/xM5NujqVX7J/Ze/aXRq5GBAQ8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=HSy7SxMk1S48wAF2INm7s+KbYdnMSC4ZDST0mdDeoX9sGxdiFeppXAf+P1LoNWKhf wcOdcMAYZbWrnuQYcGQkirlBBsiNuvnh+V5oX8v88QU4HL6RGsT6xbWIgeSQ4A5Tpr 6dbNbc24aDpxQLuDJMdZiDt4rnWXWtEmbW/D7oRY= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <20140528223020.4849316CCFC0@rock.dv.isc.org> Date: Thu, 29 May 2014 18:45:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <08B0CED4-DFE3-4993-8343-2388540348E3@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <6740CB67-2CE3-4F41-A513-971C3307975D@delong.com> <20140528223020.4849316CCFC0@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 29 May 2014 18:41:40 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/cv_L8cs8lVLNpkHmIxNzCQbRj08 Cc: V6 Ops List , Tore Anderson Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 01:44:40 -0000 On May 28, 2014, at 3:30 PM, Mark Andrews wrote: >=20 > In message <6740CB67-2CE3-4F41-A513-971C3307975D@delong.com>, Owen = DeLong write > s: >>=20 >> On May 28, 2014, at 2:21 AM, Tore Anderson wrote: >>=20 >>> * Doug Barton >>>=20 >>>> We have a substantial number of medium-sized enterprises which = share >> the >>>> following characteristics: >>>>=20 >>>> 1. They are large enough to have some internal resources that need >>>> addressing (printers, file servers, maybe a web site or two) >>>>=20 >>>> 2. They are small enough that PI space and their own ASN are not >> practical >>>=20 >>> You don't need an ASN to use PI space. >>=20 >> Except possibly in the APNIC region due to previously discussed very = high >> fees, >> I'm not sure why you think PI space is not practical for small >> organizations. I've >> set up multi homed connections for a number of small businesses, >> including even >> some one-man operations with gross revenues under US $250,000 = annually. >=20 > Because it is actually more error prone than ULA when you are not > able to use the prefix for routing as there is no automatic built > in support. Also running two GUA in parallel (PA + non-routeable > PI) will be harder to debug. I realise that your PI is being routed. > You are the exception here. Who says we didn=92t use the prefix for routing. All of the situations I was describing are doing BGP with their upstreams and advertising the prefixes in question. > This will actually encourage more NATPT or traditional NAT than ULA > will as the defaults are right for ULA + PA. They=92re even more right for PI+Routing. > You are trading off P(collision) of epsilion when merging two ULA > domains with a continual debugging and configuration issues. Every > time you add a router you need to remember to filter this prefix > to get ICMP unreachable returned. If you have multiple sites then > you have lots of per site configuration. Only if you=92re not using the prefix for routing. > With ULA I can see fd..... and identify that it is a ULA address > so I can easily see when a node is choosing the wrong address when > debugging. Sure. > Remember also homenet is doing SADR. It so there will be even more > pressure to not announce yet another prefix as support for that > gets added to the very low end CPE devices. If they can do it all > the more professional devices will need to support it so there will > be no escaping it. We=92re not talking about home net here, though I=92d never implement = what home net is currently considering in my home. > If you get to the stage where you can get a PI routed, then sure use > that, but until you are at that stage non-routed PI is actually worse. My point is that the point where that stage occurs is MUCH MUCH lower = than many people appear to think it is. It can be done on very cheap hardware with free software very = effectively for very little cost. Owen From nobody Thu May 29 18:55:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4F91A0756 for ; Thu, 29 May 2014 18:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46_X3zim6L8x for ; Thu, 29 May 2014 18:55:25 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC4F1A0726 for ; Thu, 29 May 2014 18:55:25 -0700 (PDT) Received: from [IPv6:2620::930:0:225:ff:fe44:af17] ([IPv6:2620:0:930:0:225:ff:fe44:af17]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s4U1nWuv020993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 29 May 2014 18:49:33 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s4U1nWuv020993 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1401414573; bh=BRLwl0nlAprlZD3BNzm00nkp6rY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=lbe8AAXljoW3DIgd5EdtcUgl4W+SlUPuZKu6zbAyR4cuVEsOI9FLFgaNDN8y+KXla 2fhfkokzFLX2nCKXsR/ZjiCuHRgSLqB9ef4uh3TtYSa3nHDlW6O+d2xUBNEAxpQm0H AeZoniQaJf/LzArVNqTixN1WpE/E/EO+Za1XW7wc= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Owen DeLong In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> Date: Thu, 29 May 2014 18:52:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7783E833-2188-4993-ADCC-38C67A09553D@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> To: "Liubing (Leo)" X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 29 May 2014 18:49:33 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KI9KhijIQ6xE1_0UGZ_Rp1KK5zo Cc: v6ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] ULA #3 NPTv6 Use Case X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 01:55:26 -0000 I think this use case is absurd. If you need to communicate to outside world, it=92s perfectly reasonable = to use SLAAC with GUA and there=92s no benefit derived from ULA+NPT. Owen On May 29, 2014, at 1:28 AM, Liubing (Leo) = wrote: > Hi, All >=20 > We're going to update the ULA draft. Before making a new version, I = think it would be helpful to confirm/discuss several important topics = which were discussed in last IETF meeting.=20 >=20 > I'd like to discuss the topics in different mail threads respectively. > (Current draft link: = http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02) > = **************************************************************************= **** >=20 > #3 NPTv6 Use Case >=20 > In current draft Section 3.2.1, there is an NPTv6 use case: > "In some very constrained situations(for example, in the sensors), = the > network needs ULA as the on-demand and stable addressing which > doesn't need much code to support address assignment mechanisms like > DHCP or full ND (Note: surely it needs SLAAC). If the network also > needs to connect to the outside, then there can be an NPTv6 gateway > which is not subject to extreme resource constraints. Especially = when > a lightweight isolated network needs to add Internet connectivity, > this is quite a straightforward and efficient way." >=20 > This use case is not based on real experience, but an assumption that = supporting multiple prefixes might be a heavy burden for some = resource-constrained nodes such as sensors. Because it needs to store = multiple addresses and dealing with the address selection problem. >=20 > Question 1: > In last IETF meeting, Lorenzo questioned this assumption whether it is = reasonable. I'd like to hear opinions from you on this issue. If it's = unreasonable, we'll move the use case out of the draft. >=20 > Question 2: > Besides the resource-constrained use case. There is another case which = was raised by Alex and has been talked a lot in 6man two months ago: one = node is assigned a /64, and it is the gateway of multi-subnets. This = might probably happen in the 3GPP terminals. 3GPP R11 supports DHCP-PD, = but former specifications only support /64. Current networks just = haven't implemented R11.=20 > Besides DHCP-PD, another solution for the multi-subnets is bridging = them at L2. But it is not feasible in some situations. For example, In a = vehicle there might be numerous incompatible L2s. >=20 > I think it is a reasonable use case to be documented. >=20 > Question 3: > This question is derived from Question 2. Current draft only refers = NPTv6, but might been other IPv6 NAT implementations available in the = vehicle/IoT networks. Shall we expand the "ULA+NPTv6" case to a generic = "ULA+IPv6 NAT" ? (Note: NPTv6 is the only standardized IPv6 NAT = mechanism so far) . >=20 > Regards, > Bing >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu May 29 18:59:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9B61A077C for ; Thu, 29 May 2014 18:58:59 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJHLJxQCfe5D for ; Thu, 29 May 2014 18:58:57 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DE9A1A0778 for ; Thu, 29 May 2014 18:58:57 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id hl10so267202igb.9 for ; Thu, 29 May 2014 18:58:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bMW1XAfkxLAmVGNEMn+rwBbTqfchqWzdc90dODCHKI0=; b=juGFSHk3ySuPa0Leqr9KOQAIWAGY8nJ6Ig0YgNp3ZY5pi0qk91EM9WOPCH2/b/wgLx YmKuisMDC9ZWs5u2zaVekpan4cdvbJZ03nFWGYSO54loNdJzxwW6lv07QfKtE8G5trQO DoZf86/OubtiHOjjvR5TJZELFE15ZJ1LPlHpwNr8BPbipy/MvpDUBv2eu+1FMMkS/i3y jb2eODtwBxUi7J//wi6v2LHAhj0qdpU/dtgVd8cxdWSCHwfOUqibhvpKJN8eKvuHlBxg KiWumkok0hZwxTvZn2nq2u3BV8RTnI77J5pkWHEc23kmsaF0nyBGFtzk4fj0bA3j0Dx4 sISQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bMW1XAfkxLAmVGNEMn+rwBbTqfchqWzdc90dODCHKI0=; b=QwGi+FUP4Ouz6KsSqTiUAWCGw8mFO/l7TUa/n/eOuK6MsehNaLjjsL1yh4Ll26Z/lY Iv+t+AKcRB0E+YqwKv61HuFGo1B77ScfZZ8R60htpzpQ2dM76NWO0A7SdfbvTkJxyx2s hq56yvNQVaywiGVIb98HtVOVIJTYbK75q0TA9dffOcu7lrrr0CVQxR3o7q3BMVi+gDk8 NDuxx+ixyV+fkSl8P9H1nu/JlPXhMP84ARLTOjQBM2Oa5CInjlXJbEewz6VpbUZ3TAFA U5t+moa3VNIQACkedUBEOJB0AolTShbHfwh/am5+jAC4Npo9NItdTmy0oyK914s+oiQT dkBA== X-Gm-Message-State: ALoCoQkO5MRK9bjN1+ZZEzxp7v4KVdIOmESx2aJZs6+biU5FeRcZsVybQIRRzFj8MNgHC6+u8WsI X-Received: by 10.50.62.148 with SMTP id y20mr1233211igr.45.1401415132852; Thu, 29 May 2014 18:58:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.203 with HTTP; Thu, 29 May 2014 18:58:32 -0700 (PDT) In-Reply-To: <7783E833-2188-4993-ADCC-38C67A09553D@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <7783E833-2188-4993-ADCC-38C67A09553D@delong.com> From: Lorenzo Colitti Date: Fri, 30 May 2014 10:58:32 +0900 Message-ID: To: Owen DeLong Content-Type: multipart/alternative; boundary=047d7bdcab342d54a204fa946344 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3gRcoBfU06XsWd2hBZtuqNZHL_U Cc: v6ops WG , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] ULA #3 NPTv6 Use Case X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 01:58:59 -0000 --047d7bdcab342d54a204fa946344 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Owen, I said "BEFORE we discuss questions #2 and #3". :-) The chairs have expressed concern that this document keeps getting mired in debate. I'm trying to help. One way to avoid that is to avoid this particular debate altogether. Cheers, Lorenzo On Fri, May 30, 2014 at 10:52 AM, Owen DeLong wrote: > I think this use case is absurd. > > If you need to communicate to outside world, it=E2=80=99s perfectly reaso= nable to > use SLAAC with GUA and there=E2=80=99s no benefit derived from ULA+NPT. > > Owen > > On May 29, 2014, at 1:28 AM, Liubing (Leo) wrote= : > > > Hi, All > > > > We're going to update the ULA draft. Before making a new version, I > think it would be helpful to confirm/discuss several important topics whi= ch > were discussed in last IETF meeting. > > > > I'd like to discuss the topics in different mail threads respectively. > > (Current draft link: > http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02) > > > *************************************************************************= ***** > > > > #3 NPTv6 Use Case > > > > In current draft Section 3.2.1, there is an NPTv6 use case: > > "In some very constrained situations(for example, in the sensors), the > > network needs ULA as the on-demand and stable addressing which > > doesn't need much code to support address assignment mechanisms like > > DHCP or full ND (Note: surely it needs SLAAC). If the network also > > needs to connect to the outside, then there can be an NPTv6 gateway > > which is not subject to extreme resource constraints. Especially when > > a lightweight isolated network needs to add Internet connectivity, > > this is quite a straightforward and efficient way." > > > > This use case is not based on real experience, but an assumption that > supporting multiple prefixes might be a heavy burden for some > resource-constrained nodes such as sensors. Because it needs to store > multiple addresses and dealing with the address selection problem. > > > > Question 1: > > In last IETF meeting, Lorenzo questioned this assumption whether it is > reasonable. I'd like to hear opinions from you on this issue. If it's > unreasonable, we'll move the use case out of the draft. > > > > Question 2: > > Besides the resource-constrained use case. There is another case which > was raised by Alex and has been talked a lot in 6man two months ago: one > node is assigned a /64, and it is the gateway of multi-subnets. This migh= t > probably happen in the 3GPP terminals. 3GPP R11 supports DHCP-PD, but > former specifications only support /64. Current networks just haven't > implemented R11. > > Besides DHCP-PD, another solution for the multi-subnets is bridging the= m > at L2. But it is not feasible in some situations. For example, In a vehic= le > there might be numerous incompatible L2s. > > > > I think it is a reasonable use case to be documented. > > > > Question 3: > > This question is derived from Question 2. Current draft only refers > NPTv6, but might been other IPv6 NAT implementations available in the > vehicle/IoT networks. Shall we expand the "ULA+NPTv6" case to a generic > "ULA+IPv6 NAT" ? (Note: NPTv6 is the only standardized IPv6 NAT mechanis= m > so far) . > > > > Regards, > > Bing > > > > _______________________________________________ > > 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 > --047d7bdcab342d54a204fa946344 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Owen,

I said "BEFORE we discuss qu= estions #2 and #3". :-)

The chairs have expre= ssed concern that this document keeps getting mired in debate. I'm tryi= ng to help. One way to avoid that is to avoid this particular debate altoge= ther.

Cheers,
Lorenzo

On Fri, May 30, 2014 at 10:52 AM, Ow= en DeLong <owen@delong.com> wrote:
I think this use case is absurd.

If you need to communicate to outside world, it=E2=80=99s perfectly reasona= ble to use SLAAC with GUA and there=E2=80=99s no benefit derived from ULA+N= PT.

Owen

On May 29, 2014, at 1:28 AM, Liubing (Leo) <leo.liubing@huawei.com> wrote:

> Hi, All
>
> We're going to update the ULA draft. Before making a new version, = I think it would be helpful to confirm/discuss several important topics whi= ch were discussed in last IETF meeting.
>
> I'd like to discuss the topics in different mail threads respectiv= ely.
> (Current draft link: http://tools.ietf.org= /html/draft-ietf-v6ops-ula-usage-recommendations-02)
> **********************************************************************= ********
>
> #3 NPTv6 Use Case
>
> In current draft Section 3.2.1, there is an NPTv6 use case:
> =C2=A0"In some very constrained situations(for example, in the se= nsors), the
> =C2=A0 network needs ULA as the on-demand and stable addressing which<= br> > =C2=A0 doesn't need much code to support address assignment mechan= isms like
> =C2=A0 DHCP or full ND (Note: surely it needs SLAAC). If the network a= lso
> =C2=A0 needs to connect to the outside, then there can be an NPTv6 gat= eway
> =C2=A0 which is not subject to extreme resource constraints. Especiall= y when
> =C2=A0 a lightweight isolated network needs to add Internet connectivi= ty,
> =C2=A0 this is quite a straightforward and efficient way."
>
> This use case is not based on real experience, but an assumption that = supporting multiple prefixes might be a heavy burden for some resource-cons= trained nodes such as sensors. Because it needs to store multiple addresses= and dealing with the address selection problem.
>
> Question 1:
> In last IETF meeting, Lorenzo questioned this assumption whether it is= reasonable. I'd like to hear opinions from you on this issue. If it= 9;s unreasonable, we'll move the use case out of the draft.
>
> Question 2:
> Besides the resource-constrained use case. There is another case which= was raised by Alex and has been talked a lot in 6man two months ago: one n= ode is assigned a /64, and it is the gateway of multi-subnets. This might p= robably happen in the 3GPP terminals. 3GPP R11 supports DHCP-PD, but former= specifications only support /64. Current networks just haven't impleme= nted R11.
> Besides DHCP-PD, another solution for the multi-subnets is bridging th= em at L2. But it is not feasible in some situations. For example, In a vehi= cle there might be numerous incompatible L2s.
>
> I think it is a reasonable use case to be documented.
>
> Question 3:
> This question is derived from Question 2. Current draft only refers NP= Tv6, but might been other IPv6 NAT implementations available in the vehicle= /IoT networks. Shall we expand the "ULA+NPTv6" case to a generic = "ULA+IPv6 NAT" ? =C2=A0(Note: NPTv6 is the only standardized IPv6= NAT mechanism so far) .
>
> Regards,
> Bing
>
> ________________________= _______________________
> 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

--047d7bdcab342d54a204fa946344-- From nobody Fri May 30 03:19:56 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27A41A03F9 for ; Fri, 30 May 2014 03:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rcl3Xb_5V_ii for ; Fri, 30 May 2014 03:19:54 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B19FC1A03E3 for ; Fri, 30 May 2014 03:19:53 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id la4so1814234vcb.21 for ; Fri, 30 May 2014 03:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=S6QeumVtoweJf3DFLpegjcd4jtyR7elFY+mMRxKLhc8=; b=MOsgY9kecW3JH+5SEVZO5bZHOPF5kxfl4q3lXpw9JvD9b7UAzts2zC/CCiedhpdf09 kOpikidivLaiHEuj7uqObkg+zVUdOkJwWr5TA7MvO+laWvM5vrztf4fwi/U8JOIWigOV clat61s3zkjlTGiClRozfm7m99PmlBTLRWi4pOeDy9Ntm6vgQ5F1F96ee4Kh7lIuUSAK yDpj/9ZjGR02sVSv7cdCicukVo8fBT5uQ4U6XG7Ha3NSpCDb13ik2icHdGfxlCEIgAbZ 40YSL9BzX7MS5aU06z6+RBQMUnRN7ePssl3ig6sSSmLdgTtT8McmfOcvviPHZnGfPfd6 nCBw== MIME-Version: 1.0 X-Received: by 10.52.230.34 with SMTP id sv2mr775275vdc.57.1401445189027; Fri, 30 May 2014 03:19:49 -0700 (PDT) Sender: mpetach@gmail.com Received: by 10.220.173.193 with HTTP; Fri, 30 May 2014 03:19:48 -0700 (PDT) In-Reply-To: <20140530004541.C4D1616FC229@rock.dv.isc.org> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com> <5383C2CF.6040205@gmail.com> <1401230263.69077.YahooMailNeo@web162206.mail.bf1.yahoo.com> <53854B03.8040702@gmail.com> <1401312298.99614.YahooMailNeo@web162205.mail.bf1.yahoo.com> <20140529153211.BF69216E83F8@rock.dv.isc.org> <20140530004541.C4D1616FC229@rock.dv.isc.org> Date: Fri, 30 May 2014 03:19:48 -0700 X-Google-Sender-Auth: JixcFxhF9o-mPHz1YkXqvlPbzA4 Message-ID: From: Matthew Petach To: Mark Andrews Content-Type: multipart/alternative; boundary=089e0102f9eaaa0b9c04fa9b62de Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kfRvqJ60ZZodZIy8blXGNcp3r6k Cc: v6ops WG Subject: Re: [v6ops] (re)numbering [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 10:19:55 -0000 --089e0102f9eaaa0b9c04fa9b62de Content-Type: text/plain; charset=UTF-8 On Thu, May 29, 2014 at 5:45 PM, Mark Andrews wrote: > > In message Anx9euA@mail.gmail.com> > , George Michaelson writes: > > > > How long ago Mark. How old, What OS. > > A Brother HL-4040CN printer only supports a single IPv4 address and > it has IPv6 support. To be fair only supports configuring a single > static IPv6 address but will autoconf multiple ones. It currently > 3 IPv6 addresses (PI + ULA + LL). > Hm. OK. In my setup, only the hosts need to support multiple addresses; the peripheral devices are only on the internal network, so there's never been a need for them to support multiple addresses. Thanks for pointing that out. Matt > > This is the difference between what is required by a host/node for > IPv4 and IPv6. Support for multiple prefixes is required for IPv6. > It isn't required for IPv4. > > > If this is a UNISYS mainframe which used , to separate the elements of > the > > dotted-quad for instance (yes, that really happened) we'd be entitled to > > say "so what" > > > > if this is a Vista or newer OS, we need to know. > > > > > > On Fri, May 30, 2014 at 1:32 AM, Mark Andrews wrote: > > > > > > > > In message > > o3adK5a7M5DOFGVa1GnjKxj3bNRq6896nBQGLOTVQ@mail.gmail.com> > > > , Matthew Petach writes: > > > > > > > > On Wed, May 28, 2014 at 2:24 PM, Mark ZZZ Smith < > > > markzzzsmith@yahoo.com.au> > > > > wrote: > > > > [...] > > > > > > > > > RFC1918s have provided that internal connectivity robustness to > both > > > home > > > > > networks and enterprise networks. Of course the drawback is that in > > > IPv4 it > > > > > is binary - hosts either have RFC1918s or public addresses, so if > you > > > have > > > > > RFC1918s you have to use NAT to access external destinations on the > > > > > Internet. > > > > > > > > Wow...that's news to me. > > > > > > > > For a decade now, I've been using > > > > RFC1918 addresses+global addresses > > > > in IPv4 on my home network; each > > > > host has an address from each subnet, > > > > and uses the 1918 addresses to reach > > > > internal-only devices (printers, terminal > > > > servers, etc.) which only have RFC1918 > > > > addresses, and use the globally routed > > > > IPs for reaching non-local destinations. > > > > > > > > I'm not sure I'd agree with your characterization > > > > that IPv4 is different from IPv6 in that regards; > > > > there's nothing in the IPv4 world that prevents > > > > hosts from having multiple addresses, and > > > > making use of them. > > > > > > > > It's definitely a plus to have internal connectivity > > > > stay working regardless of external connectivity, > > > > I completely agree with you on that. > > > > > > > > Matt > > > > > > It may work with some machine some of the time. It is not guarenteed > > > to work with all machines all of the time. I've definitely used > > > machines which didn't support multiple IPv4 addresses on the same > > > interface. > > > > > > > > > -- > > > Mark Andrews, ISC > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > --047d7b15abb1c861ed04fa921bb7 > > Content-Type: text/html; charset=UTF-8 > > Content-Transfer-Encoding: quoted-printable > > > >
How long ago Mark. How old, What > OS.

If= > > this is a UNISYS mainframe which used , to separate the elements of the > do= > > tted-quad for instance (yes, that really happened) we'd be entitled > to = > > say "so what"
> >

if this is a Vista or newer OS, we need to > know.
<= > > /div>


On > Fri, = > > May 30, 2014 at 1:32 AM, Mark Andrews < href=3D"mail= > > to:marka@isc.org" target=3D"_blank">marka@isc.org> > wrote:
> >
.8ex;border-left:1p= > > x #ccc solid;padding-left:1ex">
> > In message <CAEmG1=3Drz=3D o3adK5a7M5DOFGVa1GnjKxj3bNRq= > > 6896nBQGLOTVQ@mail.gmail.com > ">o3adK5a7M5DOFGVa1GnjKxj3bNRq6896nBQGLOTVQ@mai= > > l.gmail.com>
> >
, Matthew Petach writes:
> > >
> > > On Wed, May 28, 2014 at 2:24 PM, Mark ZZZ Smith < href=3D"mailto:= > > markzzzsmith@yahoo.com.au">markzzzsmith@yahoo.com.au>
> > > wrote:
> > > [...]
> > >
> > > > RFC1918s have provided that internal connectivity robustness > to b= > > oth home
> > > > networks and enterprise networks. Of course the drawback is > that = > > in IPv4 it
> > > > is binary - hosts either have RFC1918s or public addresses, so > if= > > you have
> > > > RFC1918s you have to use NAT to access external destinations > on t= > > he
> > > > Internet.
> > >
> > > Wow...that's news to me.
> > >
> > > For a decade now, I've been using
> > > RFC1918 addresses+global addresses
> > > in IPv4 on my home network; each
> > > host has an address from each subnet,
> > > and uses the 1918 addresses to reach
> > > internal-only devices (printers, terminal
> > > servers, etc.) which only have RFC1918
> > > addresses, and use the globally routed
> > > IPs for reaching non-local destinations.
> > >
> > > I'm not sure I'd agree with your characterization
> > > that IPv4 is different from IPv6 in that regards;
> > > there's nothing in the IPv4 world that prevents
> > > hosts from having multiple addresses, and
> > > making use of them.
> > >
> > > It's definitely a plus to have internal connectivity
> > > stay working regardless of external connectivity,
> > > I completely agree with you on that.
> > >
> > > Matt
> >
> >
It may work with some machine some of the time. =C2=A0It is > not= > > guarenteed
> > to work with all machines all of the time. =C2=A0I've definitely > used > r> > > machines which didn't support multiple IPv4 addresses on the same
> > interface.
> >
> >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: value=3D"+61298714742">+61 2= > > 9871 4742 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > INTE= > > RNET: marka@isc.org
> >

> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > target=3D"_blank">h= > > ttps://www.ietf.org/mailman/listinfo/v6ops
> >

> > > > --047d7b15abb1c861ed04fa921bb7-- > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > --089e0102f9eaaa0b9c04fa9b62de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, May 29, 2014 at 5:45 PM, Mark Andrews <= ;marka@isc.org> wrote:

In message <CAKr6gn1DTUnt=3D9UbQjmCSsk9ZHUpVJtwQM2u7xp0-J=3DAnx9euA@mail.gmail.com>
, George Michaelson writes:
>
> How long ago Mark. How old, What OS.

A Brother HL-4040CN printer only supports a single IPv4 address and it has IPv6 support. =C2=A0To be fair only supports configuring a single static IPv6 address but will autoconf multiple ones. =C2=A0It currently
3 IPv6 addresses (PI + ULA + LL).

Hm.= =C2=A0 OK.=C2=A0 In my setup, only the hosts
need to support multiple ad= dresses;
the peripheral devices are only on
the internal = network, so there's
never been a need for them to
support multiple addresses.

Thanks = for pointing that out.=C2=A0

Matt
=C2=A0

This is the difference between what is required by a host/node for
IPv4 and IPv6. =C2=A0Support for multiple prefixes is required for IPv6. It isn't required for IPv4.

> If this is a UNISYS mainframe which used , to separate the elements of= the
> dotted-quad for instance (yes, that really happened) we'd be entit= led to
> say "so what"
>
> if this is a Vista or newer OS, we need to know.
>
>
> On Fri, May 30, 2014 at 1:32 AM, Mark Andrews <marka@isc.org> wrote:
>
> >
> > In message <CAEmG1=3Drz=3D
> > o3adK5a7M5DOFGVa1GnjKxj3bNRq6896nBQGLOTVQ@mail.gmail.com>=
> > , Matthew Petach writes:
> > >
> > > On Wed, May 28, 2014 at 2:24 PM, Mark ZZZ Smith <
> > markzzzsmith@yahoo.c= om.au>
> > > wrote:
> > > [...]
> > >
> > > > RFC1918s have provided that internal connectivity robus= tness to both
> > home
> > > > networks and enterprise networks. Of course the drawbac= k is that in
> > IPv4 it
> > > > is binary - hosts either have RFC1918s or public addres= ses, so if you
> > have
> > > > RFC1918s you have to use NAT to access external destina= tions on the
> > > > Internet.
> > >
> > > Wow...that's news to me.
> > >
> > > For a decade now, I've been using
> > > RFC1918 addresses+global addresses
> > > in IPv4 on my home network; each
> > > host has an address from each subnet,
> > > and uses the 1918 addresses to reach
> > > internal-only devices (printers, terminal
> > > servers, etc.) which only have RFC1918
> > > addresses, and use the globally routed
> > > IPs for reaching non-local destinations.
> > >
> > > I'm not sure I'd agree with your characterization > > > that IPv4 is different from IPv6 in that regards;
> > > there's nothing in the IPv4 world that prevents
> > > hosts from having multiple addresses, and
> > > making use of them.
> > >
> > > It's definitely a plus to have internal connectivity
> > > stay working regardless of external connectivity,
> > > I completely agree with you on that.
> > >
> > > Matt
> >
> > It may work with some machine some of the time. =C2=A0It is not g= uarenteed
> > to work with all machines all of the time. =C2=A0I've definit= ely used
> > machines which didn't support multiple IPv4 addresses on the = same
> > interface.
> >
> >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 INTERNET: marka@isc.org<= br> > >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
>
> --047d7b15abb1c861ed04fa921bb7
> Content-Type: text/html; charset=3DUTF-8
> Content-Transfer-Encoding: quoted-printable
>
> <div dir=3D3D"ltr">How long ago Mark. How old, What OS= .<div><br></div><div>If=3D
> =C2=A0this is a UNISYS mainframe which used , to separate the elements= of the do=3D
> tted-quad for instance (yes, that really happened) we&#39;d be ent= itled to =3D
> say &quot;so what&quot;</div>
> <div><br></div><div>if this is a Vista or newe= r OS, we need to know.</div><=3D
> /div><div class=3D3D"gmail_extra"><br><br&= gt;<div class=3D3D"gmail_quote">On Fri, =3D
> May 30, 2014 at 1:32 AM, Mark Andrews <span dir=3D3D"ltr"= >&lt;<a href=3D3D"mail=3D
> to:marka@isc.org" targe= t=3D3D"_blank">marka@isc.org<= /a></a>&gt;</span> wrote:<br>
> <blockquote class=3D3D"gmail_quote" style=3D3D"margi= n:0 0 0 .8ex;border-left:1p=3D
> x #ccc solid;padding-left:1ex"><br>
> In message &lt;CAEmG1=3D3Drz=3D3D<a href=3D3D"mailto:o3adK5a7M5DOFGVa1GnjKxj3bNRq= =3D
> 6896nBQGLOTVQ@mail.gma= il.com">o3adK5a7M5DOFGVa1GnjKxj3bNRq6896nBQGLOTVQ@mai=3D
> l.gmail.com</a= >&gt;<br>
> <div><div class=3D3D"h5">, Matthew Petach writes= :<br>
> &gt;<br>
> &gt; On Wed, May 28, 2014 at 2:24 PM, Mark ZZZ Smith &lt;<a= href=3D3D"mailto:=3D
> markzzzsmith@yahoo.com.au= ">markzzzsmith@yah= oo.com.au</a>&gt;<br>
> &gt; wrote:<br>
> &gt; [...]<br>
> &gt;<br>
> &gt; &gt; RFC1918s have provided that internal connectivity ro= bustness to b=3D
> oth home<br>
> &gt; &gt; networks and enterprise networks. Of course the draw= back is that =3D
> in IPv4 it<br>
> &gt; &gt; is binary - hosts either have RFC1918s or public add= resses, so if=3D
> =C2=A0you have<br>
> &gt; &gt; RFC1918s you have to use NAT to access external dest= inations on t=3D
> he<br>
> &gt; &gt; Internet.<br>
> &gt;<br>
> &gt; Wow...that&#39;s news to me.<br>
> &gt;<br>
> &gt; For a decade now, I&#39;ve been using<br>
> &gt; RFC1918 addresses+global addresses<br>
> &gt; in IPv4 on my home network; each<br>
> &gt; host has an address from each subnet,<br>
> &gt; and uses the 1918 addresses to reach<br>
> &gt; internal-only devices (printers, terminal<br>
> &gt; servers, etc.) which only have RFC1918<br>
> &gt; addresses, and use the globally routed<br>
> &gt; IPs for reaching non-local destinations.<br>
> &gt;<br>
> &gt; I&#39;m not sure I&#39;d agree with your characteriza= tion<br>
> &gt; that IPv4 is different from IPv6 in that regards;<br> > &gt; there&#39;s nothing in the IPv4 world that prevents<br= >
> &gt; hosts from having multiple addresses, and<br>
> &gt; making use of them.<br>
> &gt;<br>
> &gt; It&#39;s definitely a plus to have internal connectivity&= lt;br>
> &gt; stay working regardless of external connectivity,<br> > &gt; I completely agree with you on that.<br>
> &gt;<br>
> &gt; Matt<br>
> <br>
> </div></div>It may work with some machine some of the time= . =3DC2=3DA0It is not=3D
> =C2=A0guarenteed<br>
> to work with all machines all of the time. =3DC2=3DA0I&#39;ve defi= nitely used<b=3D
> r>
> machines which didn&#39;t support multiple IPv4 addresses on the s= ame<br>
> interface.<br>
> <span class=3D3D"HOEnZb"><font color=3D3D"#888= 888"><br>
> <br>
> --<br>
> Mark Andrews, ISC<br>
> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> PHONE: <a href=3D3D"tel:%2B61%202%209871%204742" value=3D= 3D"+61298714742">+61 2=3D
> =C2=A09871 4742</a> =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 = =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 INTE=3D
> RNET: <a href=3D3D"mailto:mar= ka@isc.org">marka@isc.org&= lt;/a><br>
> </font></span><div class=3D3D"HOEnZb"><= div class=3D3D"h5"><br>
> _______________________________________________<br>
> v6ops mailing list<br>
> <a href=3D3D"mailto:v6ops@ie= tf.org">v6ops@ietf.org<= ;/a><br>
> <a href=3D3D"https://www.ietf.org/mailman/listinfo/v6ops&qu= ot; target=3D3D"_blank">h=3D
> ttps://www.ietf.org/mailman/listinfo/v6ops</a><br>
> </div></div></blockquote></div><br></= div>
>
> --047d7b15abb1c861ed04fa921bb7--
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 INTE= RNET: marka@isc.org


--089e0102f9eaaa0b9c04fa9b62de-- From nobody Fri May 30 03:31:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761201A0851 for ; Fri, 30 May 2014 03:31:23 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7y591kdMslHR for ; Fri, 30 May 2014 03:31:22 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 786AC1A06F7 for ; Fri, 30 May 2014 03:31:22 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id rl12so1541661iec.9 for ; Fri, 30 May 2014 03:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GeYabeG3adjrdf6YUGWc4ary4YCaDDfL1Zdsh3GZKvs=; b=SEO0+ORRUirYoyWJrmGZgPa0slr5YbrG2RkEwf3OEAzveHIxAQb08RmeXPQwcQELra Gvc/YHwlNiY3snDLiyV711s2sP2+n48290e3bpo+VOoGllYCqImzIJL7W9yiAXELcaJo jiLQT+MjH9bK9qoiQqQkoF1/UwAVT9oVhy76rrTzSmDZwkxiS4clun7wApoLW0hfcPnA naRBP87POUR1roJZH3F944Z18Fu7mY5VUBZWa1WoVlOfnKmqPny7iZfwkJeksE8flJfG XcMReiAAw0lTM3UbhRa+UO8mfEQfjNNqUMO82fB1rzG+LIbbMfEGfqIbumuQnNjxNpG0 iIIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=GeYabeG3adjrdf6YUGWc4ary4YCaDDfL1Zdsh3GZKvs=; b=QUX9kReucfr8G1Ol9RrZhsaaz86l8k/bQEjVgEhRBm1upMVt8LwqdoG7mKOevTGIMk oPjtzPjAqhYRAYkse8TOiGvso/N9u0j5nNBmQbBLq5e+gWqsNSWS8Y8DQIwN+aEppzav WX7Z0N2UYyIgeXD9P/HzUIw4Nee4bEAm+QZyfx91+tnT4xvfZilhMX87OQrfiMiVXZ6Z AjUF7oSD/778X8D+TDuwAiVmezZ/kvxIkOM6yqqV3+4wAfInw9vCh7c0MTm650zJM8m2 cAmikd0p1HjXa+mEAIuvj257LsCCteMPFtaRk+4igWgLHqRQOR1DbLagNhX20ZiTIagN k3JA== X-Gm-Message-State: ALoCoQl9h8r7IqyZvhNcn2DLBb4T7PE4QG8bo6nh1PCF0Tg3yUzx4/kzRlalvGSDbMtuTvRWJKxV X-Received: by 10.43.87.200 with SMTP id ax8mr1693509icc.97.1401445878029; Fri, 30 May 2014 03:31:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.203 with HTTP; Fri, 30 May 2014 03:30:57 -0700 (PDT) In-Reply-To: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com> <5383C2CF.6040205@gmail.com> <1401230263.69077.YahooMailNeo@web162206.mail.bf1.yahoo.com> <53854B03.8040702@gmail.com> <1401312298.99614.YahooMailNeo@web162205.mail.bf1.yahoo.com> From: Lorenzo Colitti Date: Fri, 30 May 2014 19:30:57 +0900 Message-ID: To: Matthew Petach Content-Type: multipart/alternative; boundary=001a11c1e5a2bb87b904fa9b8bf1 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xWi1MJkK1BByp0smkXFGNHjPPR8 Cc: v6ops WG Subject: Re: [v6ops] (re)numbering [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 10:31:23 -0000 --001a11c1e5a2bb87b904fa9b8bf1 Content-Type: text/plain; charset=UTF-8 On Thu, May 29, 2014 at 8:18 PM, Matthew Petach wrote: > For a decade now, I've been using > RFC1918 addresses+global addresses > in IPv4 on my home network; each > host has an address from each subnet, > How do you configure the hosts? Manually? Manual configuration would be a non-starter in many situations. --001a11c1e5a2bb87b904fa9b8bf1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
--001a11c1e5a2bb87b904fa9b8bf1-- From nobody Fri May 30 06:01:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FD71A08DE for ; Fri, 30 May 2014 06:01:04 -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=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzEEnI08xtVz for ; Fri, 30 May 2014 06:01:01 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0080.outbound.protection.outlook.com [213.199.154.80]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F7991A08E2 for ; Fri, 30 May 2014 06:01:01 -0700 (PDT) Received: from DBXPRD0510HT003.eurprd05.prod.outlook.com (157.56.252.165) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.0.954.9; Fri, 30 May 2014 13:00:54 +0000 Message-ID: <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> From: t.petch To: Tore Anderson , Brian E Carpenter References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> Date: Fri, 30 May 2014 13:57:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.165] X-ClientProxiedBy: AMXPR07CA006.eurprd07.prod.outlook.com (10.242.64.46) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 02272225C5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(51444003)(13464003)(189002)(199002)(377454003)(51704005)(87286001)(87976001)(74662001)(44736004)(85852003)(4396001)(92726001)(77982001)(74502001)(89996001)(83072002)(92566001)(76482001)(83322001)(50226001)(19580395003)(19580405001)(77156001)(64706001)(81816999)(81686999)(50986999)(76176999)(99396002)(81542001)(102836001)(21056001)(42186004)(81342001)(79102001)(33646001)(47776003)(44716002)(62236002)(20776003)(14496001)(101416001)(15975445006)(84392001)(88136002)(104166001)(46102001)(80022001)(61296002)(62966002)(66066001)(31966008)(23756003)(93916002)(86362001)(50466002)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR07MB054; H:DBXPRD0510HT003.eurprd05.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2ulvZWInQSyWc2JMer-vEWUjF1A Cc: V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 13:01:04 -0000 ----- Original Message ----- From: "Tore Anderson" To: "Brian E Carpenter" Cc: "V6 Ops List" Sent: Wednesday, May 28, 2014 11:09 PM > * Brian E Carpenter > > > Tore, > > > >> We have a few customers in the same situation. So we obtained a PI > >> prefix for them, > > > > The important words there are "a few". As long as the numbers are > > reasonable, this scales. When the numbers cease to be reasonable, > > it doesn't scale. The estimate I made some years ago, based on > > a little research into statistics in a few countries, was that > > there must be about 10 million small or medium enterprises in the > > world. We don't know how to route 10M prefixes in BGP-4. So > > somewhere between "PI for a few customers" and "PI for every > > enterprise", we have to stop. > > For sure, it is a very small minority of my customers who have this > requirement. The vast majority are perfectly happy to be assigned > prefixes out of my PA block. This goes for IPv4 too, BTW. > > I seriously doubt that a significant fraction of those 10M enterprises > asking for a PI prefix (or multihoming at all) is a realistic scenario. > So I'm not too worried about IPv6 PI to be honest, we survived IPv4 PI > so far and I think we'll survive IPv6 PI also, even if adding a few > "new" PI holders who in IPv4 multihomed using PA assignments from their > upstreams + NAT44 + RFC1918. Especially if homenet comes up with an even > more attractive solution than PI for that specific use case soon. Tore The damage done by PI in IPv4 was understood before the RIRs started handing out addresses in large numbers, so while PI exists, it has always been hard to get. The fear with IPv6 is that just because one constraint on PI has been removed, those handing out addresses will not realise that there is another show-stopping constraint in the number of entries a FIB can cope with, 1M being the best estimate (as before, on the RRG list) with the foreseeable improvements to current technology. And I think that every SME who has lost business with the unreliability of their ISP will want multi-homing and will think that with IPv6 and PI the constraints have gone, and the number of such SMEs can only approach 10M over time. So, Brian is spot on, and just as the IETF did little about IPv4 addresses running out until the event loomed large, so I expect history to repeat itself with the growth of PI in IPv6. Tom Petch > > Tore > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri May 30 06:46:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15051A08F3 for ; Fri, 30 May 2014 06:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaNTt9R_eOv0 for ; Fri, 30 May 2014 06:46:32 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2C411A08CF for ; Fri, 30 May 2014 06:46:31 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s4UDjrLb069916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 30 May 2014 14:45:53 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.dyn.netability.ie Message-ID: <53888B90.4030509@foobar.org> Date: Fri, 30 May 2014 14:45:52 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "t.petch" , Tore Anderson , Brian E Carpenter References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> In-Reply-To: <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/P-mWZujyQeT6xSC7N1iEeS8Qyko Cc: V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 13:46:33 -0000 On 30/05/2014 13:57, t.petch wrote: > The fear with IPv6 is that just because one constraint on PI has been > removed, those handing out addresses will not realise that there is > another show-stopping constraint in the number of entries a FIB can cope > with, 1M being the best estimate (as before, on the RRG list) with the > foreseeable improvements to current technology. several varieties of current generation hardware can handle 1m ipv6 fib. We're at 17k ipv6 prefixes now, and the growth rate has been linear since 2011. There is a fear about ipv6 fib size, not fully matched by evidence. Nick From nobody Fri May 30 06:53:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23BC1A7009 for ; Fri, 30 May 2014 06:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FMX18J30FfY for ; Fri, 30 May 2014 06:53:46 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B20C1A08FA for ; Fri, 30 May 2014 06:53:46 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id p10so2050184wes.34 for ; Fri, 30 May 2014 06:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8yq/7K5QTWLzKyHRKU14Hd3HEeKzbYj3qEf5zD5FIjs=; b=E27eP+XwUEUuzluj7uK9iXPlWfQYpLXIAbkh9LQL9pYsaI1s+FneGthMU7xEUxpnkf buAbtGpJpKHPUINyeeUUVt9JSaHLEmClQALKLzwDbtpCJpUd60KY0PvGmgrr4Od0lj0H 9U4SL+mq8qiJ8SVsev7kAvshE/XSDVj2qy6eUjso9wdSjl22Wp2JsP+tyfv46mxTepQ3 fa6/NtrFesIHmeJUiOqdX9azoxgNzjkY2xeN4DzGKUqfkuv+6LLyEMcIkEdbqLFzm4Tj 0JipoxeIKb7cq+J+JnxHDhzgF4V2v37GxWONI0mECUNVgTy8xDCJ/nXO56eFWQckSB1D nweQ== MIME-Version: 1.0 X-Received: by 10.180.20.210 with SMTP id p18mr609425wie.8.1401458021165; Fri, 30 May 2014 06:53:41 -0700 (PDT) Received: by 10.216.39.1 with HTTP; Fri, 30 May 2014 06:53:41 -0700 (PDT) Received: by 10.216.39.1 with HTTP; Fri, 30 May 2014 06:53:41 -0700 (PDT) In-Reply-To: <53888B90.4030509@foobar.org> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <53888B90.4030509@foobar.org> Date: Fri, 30 May 2014 06:53:41 -0700 Message-ID: From: Ca By To: Nick Hilliard Content-Type: multipart/alternative; boundary=bcaec53d5c61850cb204fa9e5fef Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZK3PNeflq4DMcuLxGgmUYB8gUSY Cc: V6 Ops List , Tore Anderson Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 13:53:47 -0000 --bcaec53d5c61850cb204fa9e5fef Content-Type: text/plain; charset=UTF-8 On May 30, 2014 6:46 AM, "Nick Hilliard" wrote: > > On 30/05/2014 13:57, t.petch wrote: > > The fear with IPv6 is that just because one constraint on PI has been > > removed, those handing out addresses will not realise that there is > > another show-stopping constraint in the number of entries a FIB can cope > > with, 1M being the best estimate (as before, on the RRG list) with the > > foreseeable improvements to current technology. > > several varieties of current generation hardware can handle 1m ipv6 fib. > We're at 17k ipv6 prefixes now, and the growth rate has been linear since > 2011. There is a fear about ipv6 fib size, not fully matched by evidence. > > Nick > Not my *new* gear. And not while running a full ipv4 table too. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --bcaec53d5c61850cb204fa9e5fef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On May 30, 2014 6:46 AM, "Nick Hilliard" <nick@foobar.org> wrote:
>
> On 30/05/2014 13:57, t.petch wrote:
> > The fear with IPv6 is that just because one constraint on PI has = been
> > removed, those handing out addresses will not realise that there = is
> > another show-stopping constraint in the number of entries a FIB c= an cope
> > with, 1M being the best estimate (as before, on the RRG list) wit= h the
> > foreseeable improvements to current technology.
>
> several varieties of current generation hardware can handle 1m ipv6 fi= b.
> We're at 17k ipv6 prefixes now, and the growth rate has been linea= r since
> 2011. =C2=A0There is a fear about ipv6 fib size, not fully matched by = evidence.
>
> Nick
>

Not my *new* gear. And not while running a full ipv4 table t= oo.

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

--bcaec53d5c61850cb204fa9e5fef-- From nobody Fri May 30 07:10:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0D51A08F3 for ; Fri, 30 May 2014 07:10:03 -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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUZAveW0xT22 for ; Fri, 30 May 2014 07:10:01 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FB231A08BD for ; Fri, 30 May 2014 07:10:00 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s4UE9VP6070285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 30 May 2014 15:09:31 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.dyn.netability.ie Message-ID: <5388911B.6020007@foobar.org> Date: Fri, 30 May 2014 15:09:31 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ca By References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <53888B90.4030509@foobar.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/U_N3kT-SCrn2vTG-JRptKhEGrZA Cc: V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 14:10:03 -0000 On 30/05/2014 14:53, Ca By wrote: > Not my *new* gear. And not while running a full ipv4 table too. tom specifically mentioned "1M being the best estimate ... with the foreseeable improvements to current technology" but we already have this on e.g. asr9000 typhoon cards. Whether your particular boxes handle a 1m v6 fib is a different issue; the point is that the technology already exists and given the small DFZ and (currently) linear growth rate, there is no short / medium term fear here, and arguably no long term cause of concern either. Nick From nobody Fri May 30 07:14:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4B61A08F6 for ; Fri, 30 May 2014 07:13:59 -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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shJvS-MOBzw5 for ; Fri, 30 May 2014 07:13:58 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5C4D1A08BD for ; Fri, 30 May 2014 07:13:57 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s4UEDUvR070361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 30 May 2014 15:13:30 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.dyn.netability.ie Message-ID: <53889209.7010402@foobar.org> Date: Fri, 30 May 2014 15:13:29 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ca By References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <53888B90.4030509@foobar.org> <5388911B.6020007@foobar.org> In-Reply-To: <5388911B.6020007@foobar.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kxQgI2h-8uNWNXgAzJdzi-hLw9c Cc: V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 14:13:59 -0000 On 30/05/2014 15:09, Nick Hilliard wrote: > e.g. asr9000 typhoon cards. correction: typhoon cards have 4M FIB "credits". ipv4 entries take one credit; ipv6 take two. So assuming no ipv4, a typhoon card will handle 2m ipv6 FIB entries. Nick From nobody Fri May 30 07:21:56 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0377D1A6F50 for ; Fri, 30 May 2014 07:21:50 -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=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z806iFc7BVtw for ; Fri, 30 May 2014 07:21:44 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAD5C1A0916 for ; Fri, 30 May 2014 07:21:44 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.6]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WqNgg-000I7i-TA; Fri, 30 May 2014 14:21:38 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/bgmQb4+FvpwujwzoGocG+ Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John Curran In-Reply-To: <53889209.7010402@foobar.org> Date: Fri, 30 May 2014 10:21:36 -0400 Content-Transfer-Encoding: 7bit Message-Id: <6CA5BF96-1E76-4BD4-A413-84EC7AFC0E1C@istaff.org> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <53888B90.4030509@foobar.org> <5388911B.6020007@foobar.org> <53889209.7010402@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/gk0_Mtd6IFgX-3xT98IsqktB5VI Cc: V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 14:21:50 -0000 On May 30, 2014, at 10:13 AM, Nick Hilliard wrote: > On 30/05/2014 15:09, Nick Hilliard wrote: >> e.g. asr9000 typhoon cards. > > correction: typhoon cards have 4M FIB "credits". ipv4 entries take one > credit; ipv6 take two. So assuming no ipv4, a typhoon card will handle 2m > ipv6 FIB entries. Acceptable end state does not imply viable intermediate states. /John From nobody Fri May 30 07:37:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4641A08FB for ; Fri, 30 May 2014 07:37:32 -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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFyanjm6nbn7 for ; Fri, 30 May 2014 07:37:31 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9D81A08F6 for ; Fri, 30 May 2014 07:37:30 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s4UEbLMI070736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 30 May 2014 15:37:22 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.dyn.netability.ie Message-ID: <538897A1.20909@foobar.org> Date: Fri, 30 May 2014 15:37:21 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Curran References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <53888B90.4030509@foobar.org> <5388911B.6020007@foobar.org> <53889209.7010402@foobar.org> <6CA5BF96-1E76-4BD4-A413-84EC7AFC0E1C@istaf! f.org> In-Reply-To: <6CA5BF96-1E76-4BD4-A413-84EC7AFC0E1C@istaff.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Jidu6xjIxM_hHf0nCXTVhQJUN_g Cc: V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 14:37:32 -0000 On 30/05/2014 15:21, John Curran wrote: > On May 30, 2014, at 10:13 AM, Nick Hilliard wrote: > >> On 30/05/2014 15:09, Nick Hilliard wrote: >>> e.g. asr9000 typhoon cards. >> >> correction: typhoon cards have 4M FIB "credits". ipv4 entries take one >> credit; ipv6 take two. So assuming no ipv4, a typhoon card will handle 2m >> ipv6 FIB entries. > > Acceptable end state does not imply viable intermediate states. itym, "acceptable intermediate states do not imply viable end state". We can all agree to that, but we have 60x overhead on current generation technology and linear growth. There are more pressing problems than this. Let's deal with them instead. Nick From nobody Fri May 30 07:45:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61A11A0942 for ; Fri, 30 May 2014 07:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzTZbGujt6o4 for ; Fri, 30 May 2014 07:45:26 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9361A0933 for ; Fri, 30 May 2014 07:45:26 -0700 (PDT) Received: from [IPv6:2620::930:0:225:ff:fe44:af17] ([IPv6:2620:0:930:0:225:ff:fe44:af17]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s4UEejiN026854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 30 May 2014 07:40:45 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s4UEejiN026854 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1401460846; bh=Rfnk0n1fSVv2G87yGP/WLZ5IFxI=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=jA7cSFfmfrGQzlDo4DsORgF59ranI4MQ2vXCpGyY+NveApUn3HnldQ32CVN28FPOM Ce1McIX8Ez4uYM7B6tVRycXfnxFt3c9OJ9jBvKLnhT80yRNutIfpXBS7gRyU8ealN+ BV3L2FmgN4NrNfMu0wuO0rKz9/7pbH8cEyLEHOw8= Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: text/plain; charset=windows-1252 From: Owen DeLong X-Priority: 3 In-Reply-To: <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> Date: Fri, 30 May 2014 07:44:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3350A387-4F86-4445-A72E-075913E40618@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 30 May 2014 07:40:46 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2yv_nlWpolrJzKYKoW9CDd7E56A Cc: V6 Ops List , Tore Anderson Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 14:45:27 -0000 >=20 > Tore >=20 > The fear with IPv6 is that just because one constraint on PI has been > removed, those handing out addresses will not realise that there is > another show-stopping constraint in the number of entries a FIB can = cope > with, 1M being the best estimate (as before, on the RRG list) with the > foreseeable improvements to current technology. Yes, we need to change the fundamental way we deal with routing and come = up with a more scalable solution than the current everyone knows every = prefix model. However, at any likely growth rate, if we actually start working on the = problem instead of simply inflicting limitations and calling it handled, then we = have time to address the issue in IPv6. Hopefully the RRG will wake up and = start addressing this issue. For now, it is out of scope for v6ops as I = understand the WG charter. > And I think that every SME who has lost business with the = unreliability > of their ISP will want multi-homing and will think that with IPv6 and = PI > the constraints have gone, and the number of such SMEs can only = approach > 10M over time. All the more reason this issue needs to get addressed instead of = ignored. > So, Brian is spot on, and just as the IETF did little about IPv4 > addresses running out until the event loomed large, so I expect = history > to repeat itself with the growth of PI in IPv6. He=92s somewhat right about the problem. He=92s absolutely wrong in = believing that the current limitations are a solution. Owen From nobody Fri May 30 07:49:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAEDF1A08E6 for ; Fri, 30 May 2014 07:49:10 -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=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmTsSWJj6uYE for ; Fri, 30 May 2014 07:49:09 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB2B1A0982 for ; Fri, 30 May 2014 07:49:04 -0700 (PDT) Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.6]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WqO7A-000CB1-51; Fri, 30 May 2014 14:49:00 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 108.56.179.253 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/W0v3DCdOOOViRJ9A1DNrC Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: John Curran In-Reply-To: <538897A1.20909@foobar.org> Date: Fri, 30 May 2014 10:48:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9CF35994-5D4F-4F80-974F-F32307E10917@istaff.org> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <53888B90.4030509@foobar.org> <5388911B.6020007@foobar.org> <53889209.7010402@foobar.org> <6CA5BF96-1E76-4BD4-A413-84EC7AFC0E1C@istaf! f.org> <538897A1.20909@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/zwfyIEkLJ8kXtVAikiWjzIMgzPY Cc: V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 14:49:11 -0000 On May 30, 2014, at 10:37 AM, Nick Hilliard wrote: > On 30/05/2014 15:21, John Curran wrote: >> On May 30, 2014, at 10:13 AM, Nick Hilliard wrote: >>=20 >>> On 30/05/2014 15:09, Nick Hilliard wrote: >>>> e.g. asr9000 typhoon cards.=20 >>>=20 >>> correction: typhoon cards have 4M FIB "credits". ipv4 entries take = one >>> credit; ipv6 take two. So assuming no ipv4, a typhoon card will = handle 2m >>> ipv6 FIB entries. >>=20 >> Acceptable end state does not imply viable intermediate states. >=20 > itym, "acceptable intermediate states do not imply viable end state". No, I mean that the fib capacity _assuming no IPv4_ (end state) is not=20= particularly relevant, since most folks have to deal with IPv4 and IPv6=20= at the same time. While Geoff Huston's graphs show fairly predicable historic IPv4 routing growth, we also have not experienced (yet) the=20 significant pressure to route smaller and smaller IPv4 remnants that=20 is likely to occur as both regional and service provider free pools begin to run out... > We can all agree to that, but we have 60x overhead on current = generation > technology and linear growth. There are more pressing problems than = this. > Let's deal with them instead. I'm not suggesting that there is a imminent crisis (or that any = particular work should be done/not be done with respect to ULA's), but was simply = noting that folks should not presume our current trajectory to be safe and = assured,=20 particularly based on the ability of the latest hardware to cope with an IPv6-only world. FYI, /John From nobody Fri May 30 10:04:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2D71A6F59 for ; Fri, 30 May 2014 10:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBJNy2FMZHMz for ; Fri, 30 May 2014 10:04:17 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0012.outbound.protection.outlook.com [213.199.154.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A34F1A02C9 for ; Fri, 30 May 2014 10:04:16 -0700 (PDT) Received: from DBXPRD0510HT003.eurprd05.prod.outlook.com (157.56.252.165) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.0.954.9; Fri, 30 May 2014 17:04:05 +0000 Message-ID: <053501cf7c28$c53d51e0$4001a8c0@gateway.2wire.net> From: t.petch To: Owen DeLong References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <3350A387-4F86-4445-A72E-075913E40618@delong.com> Date: Fri, 30 May 2014 18:01:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.165] X-ClientProxiedBy: AM3PR07CA003.eurprd07.prod.outlook.com (10.242.16.43) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 02272225C5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(51444003)(13464003)(189002)(199002)(377454003)(51704005)(74662001)(87286001)(89996001)(23746002)(4396001)(44736004)(83072002)(92726001)(77982001)(87976001)(92566001)(74502001)(76482001)(83322001)(50226001)(19580395003)(19580405001)(77156001)(64706001)(81816999)(81686999)(50986999)(76176999)(99396002)(81542001)(21056001)(102836001)(42186004)(81342001)(79102001)(33646001)(47776003)(44716002)(62236002)(20776003)(14496001)(101416001)(84392001)(88136002)(85852003)(46102001)(104166001)(80022001)(61296002)(62966002)(50466002)(66066001)(31966008)(86362001)(93916002)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR07MB054; H:DBXPRD0510HT003.eurprd05.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/zza8ce9zR-yt31LMhQxU7HsVhwA Cc: V6 Ops List , Tore Anderson Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 17:04:21 -0000 ----- Original Message ----- From: "Owen DeLong" To: "t.petch" Cc: "Tore Anderson" ; "Brian E Carpenter" ; "V6 Ops List" Sent: Friday, May 30, 2014 3:44 PM > > Tore > > The fear with IPv6 is that just because one constraint on PI has been > removed, those handing out addresses will not realise that there is > another show-stopping constraint in the number of entries a FIB can cope > with, 1M being the best estimate (as before, on the RRG list) with the > foreseeable improvements to current technology. Yes, we need to change the fundamental way we deal with routing and come up with a more scalable solution than the current everyone knows every prefix model. Owen, yes, and that is what the RRG did. It came up with two solutions and, being an IRTF and not an IETF WG, one solution was declared appropriate while the other (LISP) is being developed by the IETF:-) The key to both is that while the number of prefixes is likely to grow beyond the capacity of routers, the number of locations involved is likely to remain much smaller so that routing will be based on locations, with a mapping from prefix to location prior to routing. All in the RRG archives. Tom Petch However, at any likely growth rate, if we actually start working on the problem instead of simply inflicting limitations and calling it handled, then we have time to address the issue in IPv6. Hopefully the RRG will wake up and start addressing this issue. For now, it is out of scope for v6ops as I understand the WG charter. > And I think that every SME who has lost business with the unreliability > of their ISP will want multi-homing and will think that with IPv6 and PI > the constraints have gone, and the number of such SMEs can only approach > 10M over time. All the more reason this issue needs to get addressed instead of ignored. > So, Brian is spot on, and just as the IETF did little about IPv4 > addresses running out until the event loomed large, so I expect history > to repeat itself with the growth of PI in IPv6. He’s somewhat right about the problem. He’s absolutely wrong in believing that the current limitations are a solution. Owen From nobody Fri May 30 10:20:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F831A6F8D for ; Fri, 30 May 2014 10:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeQvLbstJZhy for ; Fri, 30 May 2014 10:20: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 D9ECF1A6F8C for ; Fri, 30 May 2014 10:20:21 -0700 (PDT) Received: from [IPv6:2620::930:0:225:ff:fe44:af17] ([IPv6:2620:0:930:0:225:ff:fe44:af17]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s4UHFPGh004325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 30 May 2014 10:15:26 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s4UHFPGh004325 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1401470126; bh=KU/nPIU0Mil2lufNVAZuQ8NINbo=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=sVt5FYPKeW0tVwuECirbHKjhkEkIkXVL0MUg2sE1EB22WIwtLF9DflEQ5S7ysBGxw pOU8V+D8nBDHtU70a2jzM+bM0boLFy+hNOXDQ1/Nl0712CbcNjpq43Y0mYVH4Xv5xx I8pGfSVlpWl7dVtp1vT4ojB5d0wtyxf7ZkdaBwXc= Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: text/plain; charset=windows-1252 From: Owen DeLong X-Priority: 3 In-Reply-To: <053501cf7c28$c53d51e0$4001a8c0@gateway.2wire.net> Date: Fri, 30 May 2014 10:18:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <99F0392C-6E88-42E7-850B-5027841B98DD@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <3350A387-4F86-4445-A72E-075913E40618@delong.com> <053501cf7c28$c53d51e0$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 30 May 2014 10:15:26 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/92onlErKvkSE3f_GXSuk8TuRKl0 Cc: V6 Ops List , Tore Anderson Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 17:20:22 -0000 >=20 >> Yes, we need to change the fundamental way we deal with routing and = come >> up >> with a more scalable solution than the current everyone knows every >> prefix >> model. >>=20 > > Owen, >=20 > yes, and that is what the RRG did. It came up with two solutions and, > being an IRTF and not an IETF WG, one solution was declared = appropriate > while the other (LISP) is being developed by the IETF:-) Not sure why your mailer can=92t do quoting correctly, but I=92ve fixed = it here for you. >=20 > The key to both is that while the number of prefixes is likely to grow > beyond the capacity of routers, the number of locations involved is > likely to remain much smaller so that routing will be based on > locations, with a mapping from prefix to location prior to routing. LISP is way over-complicated for the problem space in question, though = it=92s probably the right general idea. In reality, what is needed is a simpler solution probably related to = doing the IDR portion of routing on destination ASN. Unfortunately, we don=92t = have a good way in the current protocol to encode the destination ASN onto = the packet. My thinking is that a revised 44 octet header would do the trick = and that during the transition process, having routers that border between 44-octet header capable zones and non-44-octet header capable zones = would perform the header replacement. Unfortunately, this has PMTU-D issues = which I haven=92t figured out how to address yet. Owen >=20 > All in the RRG archives. >=20 > Tom Petch >=20 > However, at any likely growth rate, if we actually start working on = the > problem > instead of simply inflicting limitations and calling it handled, then = we > have > time to address the issue in IPv6. Hopefully the RRG will wake up and > start > addressing this issue. For now, it is out of scope for v6ops as I > understand > the WG charter. >=20 >> And I think that every SME who has lost business with the > unreliability >> of their ISP will want multi-homing and will think that with IPv6 and > PI >> the constraints have gone, and the number of such SMEs can only > approach >> 10M over time. >=20 > All the more reason this issue needs to get addressed instead of > ignored. >=20 >> So, Brian is spot on, and just as the IETF did little about IPv4 >> addresses running out until the event loomed large, so I expect > history >> to repeat itself with the growth of PI in IPv6. >=20 > He=92s somewhat right about the problem. He=92s absolutely wrong in > believing that > the current limitations are a solution. >=20 > Owen >=20 From nobody Fri May 30 10:23:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35AEF1A6F8C for ; Fri, 30 May 2014 10:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zt_HtUU5Lbgr for ; Fri, 30 May 2014 10:22:58 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0171A09CC for ; Fri, 30 May 2014 10:22:58 -0700 (PDT) Received: from [2a02:fe0:c410:3310::3] (port=46616 helo=wrath.fud.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WqQW3-0001xM-I6; Fri, 30 May 2014 19:22:51 +0200 Message-ID: <5388BE5C.8010809@fud.no> Date: Fri, 30 May 2014 19:22:36 +0200 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "t.petch" , Brian E Carpenter References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> In-Reply-To: <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kNG7LED1AD4HAPgcOetdMW_8C6E Cc: V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 17:23:01 -0000 * t.petch > The damage done by PI in IPv4 was understood before the RIRs > started handing out addresses in large numbers, so while PI exists, > it has always been hard to get. > > The fear with IPv6 is that just because one constraint on PI has > been removed, those handing out addresses will not realise that there > is another show-stopping constraint in the number of entries a FIB > can cope with, 1M being the best estimate (as before, on the RRG > list) with the foreseeable improvements to current technology. > > And I think that every SME who has lost business with the > unreliability of their ISP will want multi-homing and will think that > with IPv6 and PI the constraints have gone, and the number of such > SMEs can only approach 10M over time. I'm only familiar with the RIPE region's policies, but PI certainly wasn't Ğhard to getğ for an SME here that wanted to multi-home (until the point where we stopped completely issuing new blocks of it, that is). It only had to do the following: 1) Pick a sponsoring LIR out of the ~10k available to choose from, and 2) Fill out the appropriate request form, and 3) Be prepared to pay a yearly fee of €50 (+ the LIRs profit margin). The procedure was the same for IPv4 PI as it still is for IPv6 PI. (The only real difference between IPv4 and IPv6 PI was the difficulty in getting a large IPv4 assignment. While in IPv6 you get an enormous /48 with no questions asked, in IPv4 you only get a measly /24 and would have to provide additional documentation if you wanted more. However this difference is moot in a discussion of FIB sizes, as the scarce resource is the routing table entries themselves, and the prefix length of each individual entry is AFAIK irrelevant.) Tore From nobody Fri May 30 13:26:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FC01A046B for ; Fri, 30 May 2014 13:26:08 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bSyT0LetaM5 for ; Fri, 30 May 2014 13:26:07 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E6F1A0115 for ; Fri, 30 May 2014 13:26:07 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id lf10so1846939pab.27 for ; Fri, 30 May 2014 13:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fhvWwdXg0kFuTBZ4vB57ZgdAYLdU5AL4l03HX5Ffvbk=; b=aikQ5VeYKzImy5kXCtUU8ds+ILtTE3zfCtbbg5cMlbLyUsBO5YhIFpqzK/+GiGH3HT 1aQUzREvNznJd01/sbrabEMVN11Q8VFRC3oUMd94hoY3euLAElsJSKg3OxHguG4YGWXq PuT+FtrPCkLsEwg+K1brDb4J3eX276Vg+45q3ZKVvGCYSr3fVgLlPSOy6MglJn02/KFy UT8M3bcjxobFOcGP957MvbHj5Wz5EjmY95axZaXwSSkjeGAS/jKWAbVIX5x210j2MLJU P7AlzajJvtjkip/HTkJfhyicQi2+a/pXwYhEb2jeTmVh9Q0XRVhMiiHSm/iB7nhKyy/f xw1A== X-Received: by 10.66.231.40 with SMTP id td8mr21695227pac.103.1401481562984; Fri, 30 May 2014 13:26:02 -0700 (PDT) Received: from [192.168.178.23] (9.193.69.111.dynamic.snap.net.nz. [111.69.193.9]) by mx.google.com with ESMTPSA id vx10sm23226230pac.17.2014.05.30.13.26.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 May 2014 13:26:02 -0700 (PDT) Message-ID: <5388E963.50809@gmail.com> Date: Sat, 31 May 2014 08:26:11 +1200 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: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <3350A387-4F86-4445-A72E-075913E40618@delong.com> In-Reply-To: <3350A387-4F86-4445-A72E-075913E40618@delong.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3T-sP8n2-8zi5r6Ljq3IZzx1C2A Cc: V6 Ops List , Tore Anderson Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 20:26:08 -0000 On 31/05/2014 02:44, Owen DeLong wrote: =2E.. >> And I think that every SME who has lost business with the unreliabilit= y >> of their ISP will want multi-homing and will think that with IPv6 and = PI >> the constraints have gone, and the number of such SMEs can only approa= ch >> 10M over time. >=20 > All the more reason this issue needs to get addressed instead of ignore= d. We agree on that. >=20 >> So, Brian is spot on, and just as the IETF did little about IPv4 >> addresses running out until the event loomed large, so I expect histor= y >> to repeat itself with the growth of PI in IPv6. >=20 > He=E2=80=99s somewhat right about the problem. He=E2=80=99s absolutely = wrong in believing that > the current limitations are a solution. As far as I can parse that last sentence, I'm not sure I said that. It isn't beyond the bounds of physics to believe that a 10 million entry 128-bit wide FIB would be possible. (After all, we believe that fully portable 10-digit phone numbers are possible.) But I'd rather see a more elegant solution. Whether the RRG has found it yet is another discussion. Brian From nobody Fri May 30 14:50:12 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F2B1A8873 for ; Fri, 30 May 2014 14:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxBK23UODPL6 for ; Fri, 30 May 2014 14:50:10 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 90E221A0660 for ; Fri, 30 May 2014 14:50:08 -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.2) with ESMTP id s4ULjqMU014541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 30 May 2014 14:45:52 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s4ULjqMU014541 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1401486353; bh=a9muNaoAzfz0DA52TH1HIsO2YUQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=PgnekAQaQ1Lr9Gl3siITYZ5iXMfc0Ej/qVFgrDgGQ8frDVtnCjAwux+FhStpsllLe LBGeX3MxZ8vcQ0S9z9jAZMvh0xk6QC7Cg02tD3CQq2X3/s2rFROibWmuljCpLZ1s// T8fx43WKp9PcGWrlyzS0rWrw6IMFDqpcemctGKW8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: <5388E963.50809@gmail.com> Date: Fri, 30 May 2014 14:45:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7E749954-A7A8-4A86-B7EE-E5F649D568EB@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <3350A387-4F86-4445-A72E-075913E40618@delong.com> <5388E963.50809@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 30 May 2014 14:45:53 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/dB7TY_TV92AS8LP2wy0CQeh93Go Cc: V6 Ops List , Tore Anderson Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 21:50:11 -0000 On May 30, 2014, at 13:26 , Brian E Carpenter = wrote: > On 31/05/2014 02:44, Owen DeLong wrote: > ... >>> And I think that every SME who has lost business with the = unreliability >>> of their ISP will want multi-homing and will think that with IPv6 = and PI >>> the constraints have gone, and the number of such SMEs can only = approach >>> 10M over time. >>=20 >> All the more reason this issue needs to get addressed instead of = ignored. >=20 > We agree on that. >=20 >>=20 >>> So, Brian is spot on, and just as the IETF did little about IPv4 >>> addresses running out until the event loomed large, so I expect = history >>> to repeat itself with the growth of PI in IPv6. >>=20 >> He=92s somewhat right about the problem. He=92s absolutely wrong in = believing that >> the current limitations are a solution. >=20 > As far as I can parse that last sentence, I'm not sure I said that. >=20 > It isn't beyond the bounds of physics to believe that a 10 million > entry 128-bit wide FIB would be possible. (After all, we believe that > fully portable 10-digit phone numbers are possible.) But I'd rather > see a more elegant solution. Whether the RRG has found it yet is > another discussion. Agreed. My point is that continuing to reject the idea of quasi-universal PI = utilization and accepting that as a given limitation of the internet as = a whole is an obsolete idea and continuing to treat it as axiomatic only = delays the possibility of a genuine solution. I think we could, actually, learn a little from the phone system here. = They provide number portability by using two separate (but similar = looking) address spaces operated in a process not significantly = dissimilar from DNS. The dialed number is looked up in a map which = provides a connecting address which is topologically based. LISP sort of = looks like this, except that it is much more complicated in its = implementation than I believe is warranted for the actual problem space. It's really too bad we didn't tackle this problem when designing the = IPv4 header. An additional 32 bit wide field for Destination ASN may = have been all we needed. Owen From nobody Fri May 30 16:44:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD241A0450 for ; Fri, 30 May 2014 16:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.552 X-Spam-Level: X-Spam-Status: No, score=-114.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXFVdpOUX0IK for ; Fri, 30 May 2014 16:44:10 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FE071A0274 for ; Fri, 30 May 2014 16:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1371; q=dns/txt; s=iport; t=1401493446; x=1402703046; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=p/JB/ZcwGOwGAQYHs5AjYFjU18TbRdvVl8bbriDF9cc=; b=F9bdJ0P6/NtpUE/Mcl3wrCa7kZLQX83BaJr+EbwPI+Sowgi+6kfYvT5l juui/qe6pC2YWWHkCfZ3F4Q9yBhe1RCrDD/8l94VpGd/8SLJS+XTKBMnT KkQ2+OdtLjTf9ryPnYTMiarywTVMQ4bPyjCVAbAGZgnxlV5uEbQ0Ccspr c=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAFoXiVOtJV2c/2dsb2JhbABZgweBKsI/AYEKFnSCJQEBAQMBeQULAgEIRjIlAgQOBQ6ILAjXHheOUgeDK4EVBJFSgTqGcpMtgziCLw X-IronPort-AV: E=Sophos;i="4.98,944,1392163200"; d="asc'?scan'208";a="329337631" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 30 May 2014 23:44:05 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s4UNi5o2028938 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 May 2014 23:44:05 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.239]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Fri, 30 May 2014 18:44:05 -0500 From: "Fred Baker (fred)" To: "t.petch" Thread-Topic: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] Thread-Index: AQHPfGEKSRxRKrKQZk6XcUf05QQyOA== Date: Fri, 30 May 2014 23:44:04 +0000 Message-ID: <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> In-Reply-To: <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.125] Content-Type: multipart/signed; boundary="Apple-Mail=_9ADD1C8E-875F-41E4-A913-5FD859268A0D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rPaJZLlqrfLMUsQc8Nxzs8ZXZz4 Cc: V6 Ops List , Tore Anderson Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 23:44:12 -0000 --Apple-Mail=_9ADD1C8E-875F-41E4-A913-5FD859268A0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 30, 2014, at 5:57 AM, t.petch wrote: > So, Brian is spot on, and just as the IETF did little about IPv4 > addresses running out until the event loomed large, so I expect = history > to repeat itself with the growth of PI in IPv6. Which is something we have pointed out for quite some time, and tried to = advocate the use of PA prefixes for, but had issues with people saying = =93why, when PI space is $50/prefix?=94 Now, there are multiple problems with PA prefixes, not the least of = which is that 8+8/ILNP/whatever has not been adopted, so PA basically = moves complexity to the edge network without giving it a way to deal = with it. --Apple-Mail=_9ADD1C8E-875F-41E4-A913-5FD859268A0D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTiRfCbjEdbHIsm0MRAidBAJ41ti2Icos69pbbPzTfNMxkwJFt4wCghEaa GcKj/bqMxdmQWFX6XYELMH8= =G9eP -----END PGP SIGNATURE----- --Apple-Mail=_9ADD1C8E-875F-41E4-A913-5FD859268A0D-- From nobody Fri May 30 17:19:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF951A0636 for ; Fri, 30 May 2014 17:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.042 X-Spam-Level: X-Spam-Status: No, score=-1.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pge8uJ2EwdjI for ; Fri, 30 May 2014 17:19:30 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D1B661A04A9 for ; Fri, 30 May 2014 17:19:29 -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.2) with ESMTP id s4V0FmK4019268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 30 May 2014 17:15:49 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s4V0FmK4019268 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1401495349; bh=2hJuvlCigbcZVWQYVLkBGOfbak0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Urz8cwW+XStc8Hn8ZYBfbv/rqQcbZud7JsAdN2xxFecSt4eedLMrdGdfQszQNV2ua PA6hNdu3/L06HV7a1tDNoammgoG3G1onyPXcnf5lSkzty6SLKbq5x9rUHq5tCcuLsQ Pcve8WssQxPv61ehmcCkq9Zq0vOBzUW7GK37rvi4= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> Date: Fri, 30 May 2014 17:15:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 30 May 2014 17:15:49 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wWK2tHmN0Qeqdar8gWs6EEWWZaA Cc: V6 Ops List , Tore Anderson Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 00:19:31 -0000 On May 30, 2014, at 16:44 , Fred Baker (fred) wrote: >=20 > On May 30, 2014, at 5:57 AM, t.petch wrote: >=20 >> So, Brian is spot on, and just as the IETF did little about IPv4 >> addresses running out until the event loomed large, so I expect = history >> to repeat itself with the growth of PI in IPv6. >=20 > Which is something we have pointed out for quite some time, and tried = to advocate the use of PA prefixes for, but had issues with people = saying =93why, when PI space is $50/prefix?=94 Advocating PA is not solving the problem, it's building in limitations = on the end-user instead of solving the problem. > Now, there are multiple problems with PA prefixes, not the least of = which is that 8+8/ILNP/whatever has not been adopted, so PA basically = moves complexity to the edge network without giving it a way to deal = with it. It's more than that. It also creates an unpleasant kind of fate sharing = between end-site and ISP as well as some vendor-lockin problems. Bottom = line, for many end-sites, PA is an acceptable tradeoff, but it is = desirable to none. PI is universally better for the end-site, but = requires an as yet unspecified solution to the scalability of the = routing table. People aren't just adopting PI because it's cheap. They're adopting PI = because it is better suited to their needs than PA. While PA is not nearly as damaging as NAT, it's just as anachronistic at = this point and we really should be trying to find a solution that allows = us to move on. Owen From nobody Fri May 30 20:11:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456871A071A for ; Fri, 30 May 2014 20:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqOECQceSBIT for ; Fri, 30 May 2014 20:11:11 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53E521A0718 for ; Fri, 30 May 2014 20:11:11 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WqZhB-00079c-Et; Sat, 31 May 2014 03:10:57 +0000 Date: Sat, 31 May 2014 12:11:13 +0900 Message-ID: From: Randy Bush To: Nick Hilliard In-Reply-To: <53888B90.4030509@foobar.org> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <53840070.90801@gmail.com> <53840723.8010606@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <53888B90.4030509@foobar.org> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/s-4k3CUWoBuMdXUt-umbbYY2tbE Cc: V6 Ops List , Tore Anderson Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 03:11:18 -0000 > several varieties of current generation hardware can handle 1m ipv6 fib. > We're at 17k ipv6 prefixes now, and the growth rate has been linear since > 2011. There is a fear about ipv6 fib size, not fully matched by evidence. and, to repeat, in this discussion, global fib/rib size is a complete red herring. what is being discussed is globals for INTRANET, a discussion i remember from the early '80s and probably that was a redux. randy From nobody Sat May 31 03:36:42 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD241A08E2 for ; Sat, 31 May 2014 03:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8J4mr-bW2Zqd for ; Sat, 31 May 2014 03:36:38 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E66D31A0884 for ; Sat, 31 May 2014 03:36:37 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 62028604B0 for ; Sat, 31 May 2014 12:36:30 +0200 (CEST) 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 31BB3602AA for ; Sat, 31 May 2014 12:36:30 +0200 (CEST) Received: (qmail 946 invoked by uid 1007); 31 May 2014 12:36:30 +0200 Date: Sat, 31 May 2014 12:36:30 +0200 From: Gert Doering To: Owen DeLong Message-ID: <20140531103630.GP46558@Space.Net> References: <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <3350A387-4F86-4445-A72E-075913E40618@delong.com> <5388E963.50809@gmail.com> <7E749954-A7A8-4A86-B7EE-E5F649D568EB@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7E749954-A7A8-4A86-B7EE-E5F649D568EB@delong.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/p44337k-1hHcAOgu9OhG7JeM9gs Cc: V6 Ops List , Tore Anderson Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 10:36:40 -0000 Hi, On Fri, May 30, 2014 at 02:45:20PM -0700, Owen DeLong wrote: > I think we could, actually, learn a little from the phone system here. Yep. I really like the flexibility of the number porting system in the telephone world. Like, you only have to tell them a few weeks in advance, you can't have multihoming of the same phone number to different carriers (unless you are a carrier yourself and get to sign the *large* stack of paper first), and foremost, for international calls everything usually still goes through the Incumbent. Indeed, there is lots to learn there why not to go there. 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 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Sat May 31 03:41:56 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93FA1A03C2 for ; Sat, 31 May 2014 03:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wL5Kb-9Uj-L7 for ; Sat, 31 May 2014 03:41:51 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63CC01A01F2 for ; Sat, 31 May 2014 03:41:51 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id B0E296042C for ; Sat, 31 May 2014 12:41:45 +0200 (CEST) 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 81C0060183 for ; Sat, 31 May 2014 12:41:45 +0200 (CEST) Received: (qmail 1815 invoked by uid 1007); 31 May 2014 12:41:45 +0200 Date: Sat, 31 May 2014 12:41:45 +0200 From: Gert Doering To: Owen DeLong Message-ID: <20140531104145.GQ46558@Space.Net> References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ccniTAtfHhCrd3Oyy4YDZWas8lo Cc: V6 Ops List , Tore Anderson Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 10:41:52 -0000 Hi, On Fri, May 30, 2014 at 05:15:14PM -0700, Owen DeLong wrote: > It's more than that. It also creates an unpleasant kind of fate > sharing between end-site and ISP as well as some vendor-lockin > problems. Bottom line, for many end-sites, PA is an acceptable > tradeoff, but it is desirable to none. PI is universally better for > the end-site I challenge that. For a end site with no technical understanding (like, *most* of them), PI is not useful. Not at all. PA with automatic network (re-)numbering and multihoming with multiple PA networks already works today, and will really work much more pleasantly than PI *for those networks* as soon as we've sorted out some of the remaining kinks (like source-address selection with SA failover). Maybe you should step down from your "I have PI, I like it, everybody must have PI" soapbox and actually look at what, for example, homenet has achieved in the last years. This stuff looks complicated (and under the hood, it is), but the end user experience "take this box, plug in a number of ISPs, things work, no further configuration is needed(*)" is nothing you can match with a PI network. (*) for the case "there's a cable hanging from the wall with DHCPv6-PD and RA in it". For cases where you need to configure access credentials, homenet cannot automate this, of course. 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 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Sat May 31 14:11:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2201A00BF for ; Sat, 31 May 2014 14:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuceKuNoYLy7 for ; Sat, 31 May 2014 14:11:49 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id D8A941A00BE for ; Sat, 31 May 2014 14:11:48 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1WqqZ4-0000DqC; Sat, 31 May 2014 23:11:42 +0200 Message-Id: To: V6 Ops List From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> In-reply-to: Your message of "Sat, 31 May 2014 12:41:45 +0200 ." <20140531104145.GQ46558@Space.Net> Date: Sat, 31 May 2014 23:11:42 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/RVzpnA9JbRk3-Jx9oW9VdkxjL1k Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 21:11:51 -0000 In your letter dated Sat, 31 May 2014 12:41:45 +0200 you wrote: >PA with automatic network (re-)numbering and multihoming with multiple >PA networks already works today, and will really work much more pleasantly >than PI *for those networks* as soon as we've sorted out some of the >remaining kinks (like source-address selection with SA failover). > >Maybe you should step down from your "I have PI, I like it, everybody must >have PI" soapbox and actually look at what, for example, homenet has >achieved in the last years. This stuff looks complicated (and under the >hood, it is), but the end user experience "take this box, plug in a number >of ISPs, things work, no further configuration is needed(*)" is nothing you >can match with a PI network. I can see how you can do do multiple PA prefixes client side. Done that for years now. Even with different routers providing the upstreams. No problem there. But I have nothing to update my DNS zones. How do I reflect which links are up or down? Is there even a draft for that? What's the BCP for TTL values, DNSSEC, etc? From nobody Sat May 31 14:31:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26F01A00CA for ; Sat, 31 May 2014 14:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvd5Vs3sCmFa for ; Sat, 31 May 2014 14:31:41 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC3091A00C3 for ; Sat, 31 May 2014 14:31:40 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 78CE7602AA for ; Sat, 31 May 2014 23:31:33 +0200 (CEST) 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 47FB16012B for ; Sat, 31 May 2014 23:31:33 +0200 (CEST) Received: (qmail 24923 invoked by uid 1007); 31 May 2014 23:31:33 +0200 Date: Sat, 31 May 2014 23:31:33 +0200 From: Gert Doering To: Philip Homburg Message-ID: <20140531213133.GB46558@Space.Net> References: <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/nLvx8BqdQd6ahktzL4XXqsU9x60 Cc: V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 21:31:44 -0000 Hi, On Sat, May 31, 2014 at 11:11:42PM +0200, Philip Homburg wrote: > >Maybe you should step down from your "I have PI, I like it, everybody must > >have PI" soapbox and actually look at what, for example, homenet has > >achieved in the last years. This stuff looks complicated (and under the > >hood, it is), but the end user experience "take this box, plug in a number > >of ISPs, things work, no further configuration is needed(*)" is nothing you > >can match with a PI network. > > I can see how you can do do multiple PA prefixes client side. Done that > for years now. Even with different routers providing the upstreams. No problem > there. > > But I have nothing to update my DNS zones. How do I reflect which links > are up or down? Is there even a draft for that? What's the BCP for TTL > values, DNSSEC, etc? This is where things get interesting. You, Owen, I are not "the 99% home users out there" - home users don't do DNS zones, because they do not control a DNS server... (they do mDNS because it's automatic and works fine for in-house purposes). Where this falls apart, of course, is when you need to setup some sort of "call me" service, like remote help, access your home disks from abroad, etc. Some router vendors (AVM) have started to offer dyn-dns services that attach the current (dynamic) prefix to a statically known host-id and thus provide DNS to reach "home devices". I'm not aware of specific drafts that govern how IETF thinks this *should* be done, though. 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 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Sat May 31 14:49:18 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5579C1A0109 for ; Sat, 31 May 2014 14:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.252 X-Spam-Level: X-Spam-Status: No, score=-7.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, MANGLED_PRBLMS=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQXQC2qVyEvm for ; Sat, 31 May 2014 14:49:15 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by ietfa.amsl.com (Postfix) with ESMTP id D87191A00DF for ; Sat, 31 May 2014 14:49:15 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 95E7434942E; Sat, 31 May 2014 21:49:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0E7D4160067; Sat, 31 May 2014 21:54:37 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id D1AB916004E; Sat, 31 May 2014 21:54:36 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 10FEE1719BB4; Sun, 1 Jun 2014 07:49:08 +1000 (EST) To: Philip Homburg From: Mark Andrews References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> In-reply-to: Your message of "Sat, 31 May 2014 23:11:42 +0200." Date: Sun, 01 Jun 2014 07:49:08 +1000 Message-Id: <20140531214908.10FEE1719BB4@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YPVMgQqVEQmOICioagD79mocxlM Cc: V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 21:49:17 -0000 In message , Philip Homburg writes: > In your letter dated Sat, 31 May 2014 12:41:45 +0200 you wrote: > >PA with automatic network (re-)numbering and multihoming with multiple > >PA networks already works today, and will really work much more pleasantly > >than PI *for those networks* as soon as we've sorted out some of the > >remaining kinks (like source-address selection with SA failover). > > > >Maybe you should step down from your "I have PI, I like it, everybody must > >have PI" soapbox and actually look at what, for example, homenet has > >achieved in the last years. This stuff looks complicated (and under the > >hood, it is), but the end user experience "take this box, plug in a number > >of ISPs, things work, no further configuration is needed(*)" is nothing you > >can match with a PI network. > > I can see how you can do do multiple PA prefixes client side. Done that > for years now. Even with different routers providing the upstreams. No proble > m > there. > > But I have nothing to update my DNS zones. How do I reflect which links > are up or down? Is there even a draft for that? What's the BCP for TTL > values, DNSSEC, etc? You have UPDATE + TSIG or SIG(0). This is basically what Microsoft do with Active Directory except they use GSS-TSIG for about 15 years now. UPDATE and DNSSEC just work and have for over a decade now. Happy Eyeballs has proved that you don't need change the DNS for link state changes. IPv4 vs IPv6 is no different to PA1 vs PA2. HE is all about the client working around a dead link. > _______________________________________________ > 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 nobody Sat May 31 14:55:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFC81A00F0 for ; Sat, 31 May 2014 14:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VADCTbZfPPjU for ; Sat, 31 May 2014 14:55:27 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 865691A00DF for ; Sat, 31 May 2014 14:55:27 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1WqrFK-0000BHC; Sat, 31 May 2014 23:55:22 +0200 Message-Id: To: V6 Ops List From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> In-reply-to: Your message of "Sun, 01 Jun 2014 07:49:08 +1000 ." <20140531214908.10FEE1719BB4@rock.dv.isc.org> Date: Sat, 31 May 2014 23:55:22 +0200 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/JjkUYMWeIQBuIMh3RHqyeZez_F0 Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 21:55:29 -0000 In your letter dated Sun, 01 Jun 2014 07:49:08 +1000 you wrote: >You have UPDATE + TSIG or SIG(0). This is basically what Microsoft >do with Active Directory except they use GSS-TSIG for about 15 years >now. UPDATE and DNSSEC just work and have for over a decade now. >Happy Eyeballs has proved that you don't need change the DNS for >link state changes. IPv4 vs IPv6 is no different to PA1 vs PA2. >HE is all about the client working around a dead link. My router is going to update DNS using UPDATE + TSIG? How does my router know then names of my servers (or the actual addresses)? Are servers going update themselves? Is any of that spelled out? I have no idea what software you are using, but only a tiny fraction of the software I'm using actually uses happy eyeballs. You suggest that every possible piece of software should implement HE? From nobody Sat May 31 15:24:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1151A0115 for ; Sat, 31 May 2014 15:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.252 X-Spam-Level: X-Spam-Status: No, score=-5.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_PRBLMS=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6RPAhsUlIZj for ; Sat, 31 May 2014 15:23:59 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCA81A0114 for ; Sat, 31 May 2014 15:23:59 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id F38A33493B4; Sat, 31 May 2014 22:23:53 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7E1CF160067; Sat, 31 May 2014 22:28:50 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 1A90316004E; Sat, 31 May 2014 22:28:50 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 8A5D8171A140; Sun, 1 Jun 2014 08:23:21 +1000 (EST) To: Gert Doering From: Mark Andrews References: <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531213133.GB46558@Space.Net> In-reply-to: Your message of "Sat, 31 May 2014 23:31:33 +0200." <20140531213133.GB46558@Space.Net> Date: Sun, 01 Jun 2014 08:23:21 +1000 Message-Id: <20140531222321.8A5D8171A140@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5sAADWn-oovxShNh07ZFtFF--qU Cc: Philip Homburg , V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 22:24:01 -0000 In message <20140531213133.GB46558@Space.Net>, Gert Doering writes: > Hi, > > On Sat, May 31, 2014 at 11:11:42PM +0200, Philip Homburg wrote: > > >Maybe you should step down from your "I have PI, I like it, everybody must > > >have PI" soapbox and actually look at what, for example, homenet has > > >achieved in the last years. This stuff looks complicated (and under the > > >hood, it is), but the end user experience "take this box, plug in a number > > >of ISPs, things work, no further configuration is needed(*)" is nothing yo > u > > >can match with a PI network. > > > > I can see how you can do do multiple PA prefixes client side. Done that > > for years now. Even with different routers providing the upstreams. No prob > lem > > there. > > > > But I have nothing to update my DNS zones. How do I reflect which links > > are up or down? Is there even a draft for that? What's the BCP for TTL > > values, DNSSEC, etc? > > This is where things get interesting. You, Owen, I are not "the 99% home > users out there" - home users don't do DNS zones, because they do not > control a DNS server... (they do mDNS because it's automatic and works > fine for in-house purposes). Where this falls apart, of course, is when > you need to setup some sort of "call me" service, like remote help, > access your home disks from abroad, etc. > > Some router vendors (AVM) have started to offer dyn-dns services that > attach the current (dynamic) prefix to a statically known host-id and > thus provide DNS to reach "home devices". I'm not aware of specific > drafts that govern how IETF thinks this *should* be done, though. The IETF has published exactly one method for updating the DNS (RFC 2136). It has standardized several methods for securing that update. RFC 2136: Dynamic Updates in the Domain Name System (DNS UPDATE) RFC 2845: Secret Key Transaction Authentication for DNS (TSIG) RFC 2931: DNS Request and Transaction Signatures ( SIG(0)s ) RFC 3645: Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG) Now there are some other adhoc methods by various dynamic DNS providers but UPDATE + TSIG and UPDATE + GSS-TSIG have been using by enterprises for over a decade now depending upon whether you are a Microsoft AD Enterprise (UPDATE + GSS-TSIG) or not (UPDATE + TSIG) from the DHCP server. UPDATE + TSIG work fine from a CPE device. UPDATE + TSIG work fine from a node one you have configured shared TSIG keys. TSIG is just username + password and when you present it as username + password it is understood by the average punter. UPDATE + SIG(0) works fine from a node one the administrator has added the KEY record for the node to the zone usually using UPDATE + TSIG. UPDATE + GSS-TSIG work fine for Microsoft AD sites where each node is add to the AD DOMAIN and gets a Kerberos key which it uses with UPDATE to update its own information. All of these method work. All of them can be in ACLs to restrict the updates down to the RRset level. Now if someone wants to write a BCP saying that nodes should support UPDATE. That nodes should add their addresses to the DNS when they change I would be all for it. Apple already do UPDATE + TSIG. Microsoft already do UPDATE + GSS-TSIG. Mark > 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 (0)89/32356-444 USt-IdNr.: DE813185279 > > _______________________________________________ > 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 nobody Sat May 31 15:58:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180801A011C for ; Sat, 31 May 2014 15:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMGfTvC_hOy7 for ; Sat, 31 May 2014 15:58:42 -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 AF45F1A00EC for ; Sat, 31 May 2014 15:58:42 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 3824134945D; Sat, 31 May 2014 22:58:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B0033160067; Sat, 31 May 2014 23:03:33 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 71C7F16004E; Sat, 31 May 2014 23:03:33 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A1E48171A332; Sun, 1 Jun 2014 08:58:03 +1000 (EST) To: Philip Homburg From: Mark Andrews References: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <5384937A.90409@foobar.org> <5385762E.5020901@dougbarton.us> <5385AA97.1050207@fud.no> <53864DCB.5070202@gmail.com> <53865EA2.9000502@fud.no> <02dc01cf7c06$cc6a4bc0$4001a8c0@gateway.2wire.net> <97390E9C-460F-4D08-AFCE-E4A991E2B0E4@cisco.com> <46D22F62-3528-4B9D-9FCF-C9C7466A9ABA@delong.com> <20140531104145.GQ46558@Space.Net> <20140531214908.10FEE1719BB4@rock.dv.isc.org> In-reply-to: Your message of "Sat, 31 May 2014 23:55:22 +0200." Date: Sun, 01 Jun 2014 08:58:03 +1000 Message-Id: <20140531225803.A1E48171A332@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/K4Nazk43rf3woBCLQjW8hfHxzbs Cc: V6 Ops List Subject: Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 22:58:44 -0000 In message , Philip Homburg writes: > In your letter dated Sun, 01 Jun 2014 07:49:08 +1000 you wrote: > >You have UPDATE + TSIG or SIG(0). This is basically what Microsoft > >do with Active Directory except they use GSS-TSIG for about 15 years > >now. UPDATE and DNSSEC just work and have for over a decade now. > >Happy Eyeballs has proved that you don't need change the DNS for > >link state changes. IPv4 vs IPv6 is no different to PA1 vs PA2. > >HE is all about the client working around a dead link. > > My router is going to update DNS using UPDATE + TSIG? How does my router know > then names of my servers (or the actual addresses)? > > Are servers going update themselves? Why not? They know their own addresses. They know their name. If you have a UNIX/Linux based box that shipped in the last 15 years you have the tools to do this. Having this done when the addresses change is a matter of writing a small daemon or integrating it into the DHCP client. % nsupdate -k keyfile update delete AAAA update add 3600 AAAA update add 3600 AAAA update add 3600 AAAA send % This deletes all the AAAA records and then adds in all the current addresses. This is a atomic transaction. The nameserver adds DNSSEC signatures if they are appropriate for the zone. Similar for A records. keyfile could contain a TSIG key or a KEY for SIG(0) You can also do split horizon updates if you want to using multiple TSIG keys to select the zone instance to be updated. > Is any of that spelled out? > > I have no idea what software you are using, but only a tiny fraction of > the software I'm using actually uses happy eyeballs. > > You suggest that every possible piece of software should implement HE? Yes. RFC 1123 told every developer for the last 2 decades to support multi-homed servers. http://users.isc.org/~marka/ has simple example code for how to do this for TCP clients. UDP clients are slightly more complicated as you have to it higher up the stack. The client side of DNS servers has been doing this sort of stuff for multiple decades now but instead of trying to do a single connection they are dealing with thousands of connections. The code is slightly more complicated than that published in the getaddrinfo man page but not much more. > _______________________________________________ > 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