From nobody Mon Dec 1 12:18: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 94A311A9041 for ; Mon, 1 Dec 2014 12:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 5HfOqv2UaSf0 for ; Mon, 1 Dec 2014 12:18:39 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 765DC1A9029 for ; Mon, 1 Dec 2014 12:18:39 -0800 (PST) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id sB1KDdBZ001123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Dec 2014 12:13:40 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com sB1KDdBZ001123 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1417464820; bh=glUkg3tq2j596FIYhvjaDHyP3wE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=BrLfbZe7EBlI7MMrsV9ttQjhgIhwQXq3hd5aYyjJEMzsA878v26oSbZZ+3BTBVlDE aMR/Vw4einOJ1ysC8EnGlwEh2ThTZUqUodFSDMOOoymQIIH51VbWpwifxgpB0qklq+ XDiv8M1bm02QnipS6wzzNuLv9nUmQqsmASgJGB+0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: Date: Mon, 1 Dec 2014 12:13:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6095CE71-467D-4AE0-B58C-BDCBD43D55E7@delong.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 01 Dec 2014 12:13:40 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/llth6cyNYY1Qmr6SslYmnvnrlAg Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? 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, 01 Dec 2014 20:18:41 -0000 > On Nov 12, 2014, at 12:12 PM, Iljitsch van Beijnum = wrote: >=20 > I've been talking to a few people and I think there is potential for a = draft that lets home gateways (and any other system so inclined) have = IPv6 tunneling enabled out of the box (like 6to4) but in a way that = works pretty reliably (unlike 6to4). >=20 > My question to (potential) implementers: >=20 > - Is requiring HTTP digest authentication problematic? Probably > - Is requiring HTTPS problematic? Probably not. > - Is requiring JSON parsing problematic? No. > * Would using plain text similar to HTTP headers to pass parameters = be better? I think this would actually be worse. > - Is requiring DHCPv6 (the prefix delegation client role) problematic? Yes. Making it a should with the option for a mechanism that provides a = statically configured prefix would be preferable, IMHO. Owen From nobody Mon Dec 1 12:28: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 5E5811A8AD1 for ; Mon, 1 Dec 2014 12:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 PNrW8kIEvFvT for ; Mon, 1 Dec 2014 12:28:26 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id F3CCC1A8AC7 for ; Mon, 1 Dec 2014 12:28:25 -0800 (PST) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id sB1KRMdw003258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Dec 2014 12:27:23 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com sB1KRMdw003258 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1417465643; bh=etSLgdsvKWRZu5bBpxe+2ilK9mY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QwWo0Ua6wQfHvIz2OYMxeI3WdMv7ZilFeoLo85ouEvBBQKHUelVfDZE2aZ549btZZ MC+kRz40P6o6YL5F6BhchxkZ2LXmmnyLg7s4BxNn8PcpUHG2p74moHdMdfpEhxf4j2 af9NDot3C7ymealmyZ83e6L8SGfxN+4KOo7BDRA0= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: <546461AB.7060707@dougbarton.us> Date: Mon, 1 Dec 2014 12:27:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <20141112213333.GQ31092@Space.Net> <546461AB.7060707@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 01 Dec 2014 12:27:23 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kH743nCYaUemMldkZzp_IiRHGbw Cc: v6ops@ietf.org Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? 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, 01 Dec 2014 20:28:27 -0000 > On Nov 12, 2014, at 11:45 PM, Doug Barton wrote: >=20 > On 11/12/14 1:33 PM, Gert Doering wrote: >> Hi, >>=20 >> On Wed, Nov 12, 2014 at 10:12:17AM -1000, Iljitsch van Beijnum wrote: >>> I've been talking to a few people and I think there is potential >>> for a draft that lets home gateways (and any other system so = inclined) >>> have IPv6 tunneling enabled out of the box (like 6to4) but in a way >>> that works pretty reliably (unlike 6to4). >>=20 >> I'm not sure where the value of that is. >>=20 >> 10 years ago, I would have agreed that "getting IPv6 out to the = people" >> is a good goal - but when this draft gets to the stage that you'll = see >> devices actually shipping, it's 2016, and we'll have 30-40% native = IPv6 >> in many countries already - which should create enough momentum by = it's >> own... >>=20 >> So, call me sceptic :) >=20 > +1 >=20 > We don't need this, shouldn't develop it, and definitely shouldn't = deploy it. >=20 > Doug I am inclined to agree. Had we developed it 20 years ago and convinced = home gateway manufacturers to deploy it 10 years ago, it would have been = great. Today, it=E2=80=99s just a waste of resources. Owen From nobody Mon Dec 1 12:38: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 414E01A8A81 for ; Mon, 1 Dec 2014 12:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-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 NdNSpwPKxpiU for ; Mon, 1 Dec 2014 12:38:49 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6CA1A1A7E for ; Mon, 1 Dec 2014 12:38:49 -0800 (PST) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id sB1KZP4Q004031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Dec 2014 12:35:26 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com sB1KZP4Q004031 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1417466127; bh=9bM9PYdu5qsCUF2bGS+990ZuhYI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=N/sNny3mgItqUm5p7kGck1YzQsFgvJHy+1nYcw4/BePvhVpDGrm5jfCdv79tpIGnP crAIiPmwW5wFKT6a7/HIKuNLsv5Oo6Pzes++SdGrs/0rLGr/DvTcmb+3ndOrFjl6NQ /bnw7egvQI65rWM0+aEzR+KB5cG9C+BJnweHjSjA= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: <20141113195636.GY31092@Space.Net> Date: Mon, 1 Dec 2014 12:35:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8586C6F3-34C6-4E2C-996E-359393B39FC9@delong.com> References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 01 Dec 2014 12:35:27 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UOV5SC5M0EhGNbsOwIDorp02-8s Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? 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, 01 Dec 2014 20:38:50 -0000 > On Nov 13, 2014, at 11:56 AM, Gert Doering wrote: >=20 > Hi, >=20 > On Thu, Nov 13, 2014 at 09:50:31AM -1000, Iljitsch van Beijnum wrote: >> There's no reason tunnels have to be so-so.=20 >=20 > I'm wondering who would provide these tunnels in the future, and what = would > their business model be. >=20 > This is a real question. Today, you can get tunnels from Sixxs nodes > (enthusiasts, which might eventually consider the IPv6 deployment = issue > to be "solved" and stop running tunnel nodes), HE.NET (it's good = marketing, > but eventually the costs involved might win over the marketing gain?),=20= I=E2=80=99m no longer with HE, but I will say that this is unlikely. = While the cost of supporting the tunnel brokers is not zero, it comes sufficiently close that I=E2=80=99= d be very surprised to see it reach this state at any point prior to ubiquitous native IPv6 = and the deprecation of IPv4 as a common backbone internet protocol. HE has multiple reasons = for providing the tunnelbroker service that go beyond mere marketing. (In other words, there will probably be pockets of IPv4, but =E2=80=9Cthe = internet=E2=80=9D will be an IPv6 internet and IPv4 will exist in islands where it can=E2=80=99t yet = be deprecated, but the hosts that still talk to the internet will do so over IPv6 somehow.) Owen From nobody Mon Dec 1 12:44: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 154761A9080 for ; Mon, 1 Dec 2014 12:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-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 BuZphOAuUte3 for ; Mon, 1 Dec 2014 12:44:00 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDEA1A909D for ; Mon, 1 Dec 2014 12:44:00 -0800 (PST) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id sB1KgL75004627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Dec 2014 12:42:23 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com sB1KgL75004627 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1417466544; bh=fSwKE2MFwgskqxqZhD6OY2jfCvA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=w38I3BGfknbJZ3C4p1fYlXNxkKFL5YwifjSnQvHgyfCSyt9uuosaauiz/39M3JxV+ qdK8QjItm28g3coZhbyfIwy2WmS3jtsEGFGEdczXAAmnG620ZC2Yboh0OcaKaFvkD8 gQmLA66zhyaRUIf71XDf0zs2/Il64W8vbsYILAKA= Content-Type: multipart/alternative; boundary="Apple-Mail=_C08C638D-C0C5-4E9A-9D35-C280105EC6CE" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: Date: Mon, 1 Dec 2014 12:42:16 -0800 Message-Id: <93034721-BA1A-45C5-A3F5-0838DE3DB3FE@delong.com> References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> To: George Michaelson X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 01 Dec 2014 12:42:24 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZV81bZqvPpfvcDmGxqijvQ1YDFI Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? 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, 01 Dec 2014 20:44:02 -0000 --Apple-Mail=_C08C638D-C0C5-4E9A-9D35-C280105EC6CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 13, 2014, at 11:59 AM, George Michaelson = wrote: >=20 > HE.net tunnels cause severe distortion of RTT. They are anything but = local termination for much of the world, and whilst I applaud their role = in promoting V6 adoption, its a poor fit to the money flow of IPv4 = relationships for many people. I should know: I have one in Australia, = and my nearest terminations are SG/HK (which is via the US and = trombones) or the US (which is 200+ms delay from me) Why would SG/HK be via the US from AU? That sounds like your provider = has failed to provide decent connectivity to Asia more than an issue = related directly to tunnelbroker. Of course, if you can find native IPv6 in AU, why not set up your own = tunnelbroker for Aussies or work with one of the existing ones to build = a local node? > I cannot speak to SIXX but I suspect it too distorts the packetflow = and causes a disparate RTT compared to native. Any tunnel or tunnel broker service which involves a detour over a long = distance will create RTT disparity. If you can get native, then native = will always be superior to tunnels. Tunnels are intended for = circumstances where you can=E2=80=99t get native. > 6rd is homed in your own ISP. its almost 1:1 congruent with your = normal RTT for native IPv6 endpoints. Sure, and that=E2=80=99s great if your ISP supports 6rd. Again, that=E2=80= =99s not the target audience for tunnel brokers. > When we say 'tunnels are bad' its not because GRE randomly corrupts = bits: its because the effects on the end-to-end model are bad. The = badness varies, but the consequence of a tunnel is usually not what you = wanted in reality, unless the sole consideration was connectivity per = se, not its quality, compared to V4 Actually, when we say =E2=80=9Ctunnels are bad=E2=80=9D, it=E2=80=99s = because we like to oversimplify and we usually develop some tunnel = vision in the process. I=E2=80=99m running entirely on tunnels for both v4 and v6. They don=E2=80= =99t significantly distort my RTTs vs. native and in many cases, I=E2=80=99= ve discovered that I get better performance over my tunnels that I could = have received natively because my tunnels aren=E2=80=99t subject to some = of the games that get played to try and manipulate financials between = providers to extort payments for access to eyeballs. Tunnels can be good. Tunnels can be bad. They are a tool like any other = tool in the networking toolkit and knowing how to use the tool properly = can greatly improve your user experience with said tool. Owen >=20 > -G >=20 > On Thu, Nov 13, 2014 at 9:56 AM, Gert Doering > wrote: > Hi, >=20 > On Thu, Nov 13, 2014 at 09:50:31AM -1000, Iljitsch van Beijnum wrote: > > There's no reason tunnels have to be so-so. >=20 > I'm wondering who would provide these tunnels in the future, and what = would > their business model be. >=20 > This is a real question. Today, you can get tunnels from Sixxs nodes > (enthusiasts, which might eventually consider the IPv6 deployment = issue > to be "solved" and stop running tunnel nodes), HE.NET = (it's good marketing, > but eventually the costs involved might win over the marketing gain?), > and others that run tunnels for various reasons that might not be = there > in 2-3 years... >=20 > 6rd is a very specific tunnel technology that has answers to that = question > ("I want to roll out IPv6 to my customers but part of my = infrastructure > cannot do it. So I provision my CPEs to do 6rd, and take = responsibility > to run the 6rd relay") - but as with 6to4 relays, what is the = incentive to > run a tunnel broker in 2-3 years from now? You won't get paid (users = do > not pay for IPv6, otherwise they would go and choose ISPs that provide > v6)... >=20 > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. = Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 = USt-IdNr.: DE813185279 >=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 --Apple-Mail=_C08C638D-C0C5-4E9A-9D35-C280105EC6CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 13, 2014, at 11:59 AM, George Michaelson <ggm@algebras.org> = wrote:

HE.net = tunnels cause severe distortion of RTT. They are anything but local = termination for much of the world, and whilst I applaud their role in = promoting V6 adoption, its a poor fit to the money flow of IPv4 = relationships for many people. I should know: I have one in Australia, = and my nearest terminations are SG/HK (which is via the US and = trombones) or the US (which is 200+ms delay from = me)

Why would SG/HK be = via the US from AU? That sounds like your provider has failed to provide = decent connectivity to Asia more than an issue related directly to = tunnelbroker.

Of course, if you can = find native IPv6 in AU, why not set up your own tunnelbroker for Aussies = or work with one of the existing ones to build a local = node?

I cannot speak to SIXX but I = suspect it too distorts the packetflow and causes a disparate RTT = compared to native.

Any = tunnel or tunnel broker service which involves a detour over a long = distance will create RTT disparity. If you can get native, then native = will always be superior to tunnels. Tunnels are intended for = circumstances where you can=E2=80=99t get native.

6rd is homed in your own ISP. its almost 1:1 = congruent with your normal RTT for native IPv6 = endpoints.

Sure, and = that=E2=80=99s great if your ISP supports 6rd. Again, that=E2=80=99s not = the target audience for tunnel brokers.

When we say 'tunnels are bad' its not because = GRE randomly corrupts bits: its because the effects on the end-to-end = model are bad. The badness varies, but the consequence of a tunnel is = usually not what you wanted in reality, unless the sole consideration = was connectivity per se, not its quality, compared to = V4

Actually, when we = say =E2=80=9Ctunnels are bad=E2=80=9D, it=E2=80=99s because we like to = oversimplify and we usually develop some tunnel vision in the = process.

I=E2=80=99m running = entirely on tunnels for both v4 and v6. They don=E2=80=99t significantly = distort my RTTs vs. native and in many cases, I=E2=80=99ve discovered = that I get better performance over my tunnels that I could have received = natively because my tunnels aren=E2=80=99t subject to some of the games = that get played to try and manipulate financials between providers to = extort payments for access to eyeballs.

Tunnels can be good. Tunnels can be bad. They are = a tool like any other tool in the networking toolkit and knowing how to = use the tool properly can greatly improve your user experience with said = tool.

Owen


-G

On Thu, Nov 13, 2014 at 9:56 AM, Gert Doering = <gert@space.net> wrote:
Hi,

On Thu, Nov 13, 2014 at 09:50:31AM -1000, Iljitsch van Beijnum wrote:
> There's no reason tunnels have to be so-so.

I'm wondering who would provide these tunnels in the future, and = what would
their business model be.

This is a real question.  Today, you can get tunnels from Sixxs = nodes
(enthusiasts, which might eventually consider the IPv6 deployment = issue
to be "solved" and stop running tunnel nodes), HE.NET (it's good marketing,
but eventually the costs involved might win over the marketing = gain?),
and others that run tunnels for various reasons that might not be = there
in 2-3 years...

6rd is a very specific tunnel technology that has answers to that = question
("I want to roll out IPv6 to my customers but part of my = infrastructure
cannot do it.  So I provision my CPEs to do 6rd, and take = responsibility
to run the 6rd relay") - but as with 6to4 relays, what is the incentive = to
run a tunnel broker in 2-3 years from now?  You won't get paid = (users do
not pay for IPv6, otherwise they would go and choose ISPs that = provide
v6)...

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

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

= --Apple-Mail=_C08C638D-C0C5-4E9A-9D35-C280105EC6CE-- From nobody Mon Dec 1 12:48: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 19DCA1A90B3 for ; Mon, 1 Dec 2014 12:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-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 XUC6AbjMgkYX for ; Mon, 1 Dec 2014 12:48:50 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C9AC91A90B2 for ; Mon, 1 Dec 2014 12:48:50 -0800 (PST) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id sB1KkYpT005113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Dec 2014 12:46:34 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com sB1KkYpT005113 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1417466797; bh=DU6ED9ozxiyX8AvrACOXxDh0vLc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=O6KUABCvFbsXEedOkisTBxnzKIVKiPyRs8vOtmnHsegyO7HigZDwA7HM3zLKfGwKU xKTZbTTAajqbme4otb1IqwIEUZucScTluMhVM6GOf+r4mFz0IuIHytzsB2unBqOBo0 WImgaKJYZ9/xGSBkCbk5uQLbSA5LphPVLOb1i50U= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: <54652F3F.2090006@gmail.com> Date: Mon, 1 Dec 2014 12:46:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4748584A-5D3F-45FF-BB87-1E6D036AAC71@delong.com> References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <54652728.9040901@massar.ch> <54652F3F.2090006@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 01 Dec 2014 12:46:37 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/itdbM4XZB8j11YPRvIcyJMdhu00 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? 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, 01 Dec 2014 20:48:52 -0000 > On Nov 13, 2014, at 2:22 PM, Alexandru Petrescu = wrote: >=20 > Le 13/11/2014 22:48, Jeroen Massar a =E9crit : >> On 2014-11-13 20:56, Gert Doering wrote: >>> Hi, >>>=20 >>> On Thu, Nov 13, 2014 at 09:50:31AM -1000, Iljitsch van Beijnum = wrote: >>>> There's no reason tunnels have to be so-so. >>>=20 >>> I'm wondering who would provide these tunnels in the future, and = what would >>> their business model be. >>=20 >> These services already exists, they are called "VPN Providers". >>=20 >> Typically used for the more shady reasons, but they can in more >> professional forms be used for what most people tend to use IPv6 for: >> getting connectivity with a public IP address. >>=20 >>=20 >>> This is a real question. Today, you can get tunnels from Sixxs = nodes >>> (enthusiasts, which might eventually consider the IPv6 deployment = issue >>> to be "solved" and stop running tunnel nodes) >>=20 >> That is the end goal indeed :) >>=20 >>=20 >> [..] >>> but as with 6to4 relays, what is the incentive to >>> run a tunnel broker in 2-3 years from now? >>=20 >> Getting IPv6 out there, learning from the problems, letting people = use it. >>=20 >> But as when closing down the 6bone: we are today already long past = the >> point where these experiences are needed. >>=20 >> We know what is broken and we know how to approach it. >>=20 >> Tunnel Brokers, 6rd etc are transition tech. Hopefully everybody will >> have native at one point or another. >=20 > Goal - any new replacement of 6to4 must be future proof: avoid = renumbering when 6to4-replacement dies out. (this is what current = tunnel brokers dont offer, they force one into a lockin going away from = tunnel broker to native IPv6 one has renumber). Depends on the tunnel broker and how you use it. My use of HE tunnelbroker will not require me to renumber out of = 2620:0:930::/48 when I stop using it. Owen >=20 > Alex >=20 >>=20 >>> You won't get paid (users do >>> not pay for IPv6, otherwise they would go and choose ISPs that = provide >>> v6)... >>=20 >> VPN providers are proof that people pay for tunneled connectivity. >>=20 >> Heck, most of those are stuffing users behind NAT and not even giving >> public IP addresses away to "protect the anonymity of the user"... >>=20 >>=20 >> And there are tunnel brokers doing it for fun and free ;) >> It is all magic :) >>=20 >> Greets, >> Jeroen >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Dec 1 13:13: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 05C571A9137; Mon, 1 Dec 2014 13:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-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 RA76KrmB5n0l; Mon, 1 Dec 2014 13:13:22 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D3A7E1A912F; Mon, 1 Dec 2014 13:13:10 -0800 (PST) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id sB1L8hPj007005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Dec 2014 13:08:44 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com sB1L8hPj007005 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1417468124; bh=Rg1OOtUdi6IdPtZK8X17P0DebYg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=sLsqMc11ckcyJ0C90ZGm8Zkk6Kh5uMh+HeiYNQ04b8ta0WO4jGHqB7NCCD7iGNIgr K/CRFuAL8wQKFZ4mvCXdvhUQ9pb9xR95UsOYxtxVBgtH5T2FLWRLZNgf61+/uIKfFi SGwmSuonJ5fe3tzQ2TFSHTr6QdUElqWgrwbbpcpw= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: <54654E47.7090003@massar.ch> Date: Mon, 1 Dec 2014 13:08:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8CF6D851-09E5-4CEF-861A-FF718EE4D542@delong.com> References: <54609418.5030503@massar.ch> <54609A3E.3030106@massar.ch> <54610AA7.6070100@gmail.com> <54610BD4.2070600@massar.ch> <1415745889.58663.YahooMailNeo@web162201.mail.bf1.yahoo.com> <54631E71.60403@massar.ch> <1415923659.92015.YahooMailNeo@web162204.mail.bf1.yahoo.com> <54654E47.7090003@massar.ch> To: Jeroen Massar X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 01 Dec 2014 13:08:44 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4G-ZwphRvvVkUKZVfeVdo_zKOTo Cc: 6man , IPv6 Operations Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-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: Mon, 01 Dec 2014 21:13:24 -0000 > On Nov 13, 2014, at 4:35 PM, Jeroen Massar wrote: >=20 > On 2014-11-14 01:07, Mark ZZZ Smith wrote: > [..] >=20 >> So I'd argue that protocols shouldn't have to be changed in reaction >> to lack of proper product design. I wouldn't support using the flow >> label for this purpose. >=20 > Flow Label cannot work the way that it is defined. >=20 > The reason for having a Flow Label is so that for instance a Load > Balancer does not have to look further than the first 40 bytes of = packet > (thus just the IPv6 Header). When you state it as an absolute, the of course: >=20 > But, as every node MUST look at ICMPv6, that is thus automatically = false. >=20 Becomes true. However, this: > Hence, the Flow Label is useless for the purposes of identifying a = flow. Is not entirely true. Let=E2=80=99s try restating your absolute in a better way: The reason for having a Flow Label is so that for instance a Load = Balancer does not have to look further than the first 40 bytes of packet = (the IPv6 header) in order to make a determination of what to do for = packets that are part of the flow, if the flow is cached for fast = switching. It does not, however, provide any expedited handling of = signaling packets RELATED TO, but NOT PART OF the flow, such as most = ICMPv6 messages like PTB. > Note that an IPv6 'error', thus an ICMPv6 packet, for instance an PTB, > but also "port unreachable" etc is part of the flow as it indicates an > error status that relates to that flow. No, it=E2=80=99s not PART OF the flow=E2=80=A6 It=E2=80=99s RELATED TO = the flow, as you state above. Think of it like a phone call=E2=80=A6 The SS7 messages in the PSTN (or = the SIP messages in VOIP) are messages about the call and/or the = participants in the call that enable the call to occur. However, they = are not part of the call. None of the call participants ever hear them. = In the case of SS7, they are sent over out-of-band signaling channels, = such as the D channels in ISDN. In the case of VOIP, they are sent over = SIP while the call itself is delivered via RTP. > The big problem is that even if the Load Balancer supports parsing the > ICMPv6 PTB and can associate it with the correct "flow" and thus the > right backend host, it won't help as there are a lot of other systems > out there that are on purpose filtering out ICMPv6. I think fixing the ICMPv6 over-filtering problem is going to be = necessary and is likely to occur anyway. I think that isa better = solution that providing an in-band signaling hack to fudge PMTU-D = instead. > By including the MTU in the packet though, it won't be filtered (or at > least set to 1280, which is the minimum which just makes them hurt = their > own performance, but it won't break things). One could make the argument that by including MTU into the packet, you = may introduce the following problems: 1. You now have two potentially conflicting sources of MTU = information. 2. Until this is supported on every router that has = interfaces with disparate MTUs, the potential for =E2=80=9Cinteresting=E2=80= =9D results will persist. 3. You virtually guarantee that the incorrect filtering of = ICMPv6 will never get solved. 4. Routers which modify the header on the fly create = interesting problems for AH packets. There may be other problems, but those are the ones that jump out at me = at the moment. Owen From nobody Mon Dec 1 17:03: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 1F55E1ACDE7 for ; Mon, 1 Dec 2014 17:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 XUczbCTjXgqr for ; Mon, 1 Dec 2014 17:03:05 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 07BF61A1A7A for ; Mon, 1 Dec 2014 17:03:04 -0800 (PST) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id sB20xbHQ007310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Dec 2014 17:00:28 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com sB20xbHQ007310 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1417482028; bh=+Z7OiU8p+3yh3emMTbuZsKsdRa4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nVepOyaGOG4JW51eHQCdhwc1XjaBUY+5mWznvXWOJzPqd4QOO0HSWqjb5CrvEkkah EJQ6HzR+NpyHwmA7Up7NXnRrg1lJRO8PWgkcBnumJteVcSrV5LCYsBgyinlsajq1uN a175X0YNw5Iy75PhS6FdyCfUO3irYQ6BHjkbbGk4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: <546E6FB9.9000500@dougbarton.us> Date: Mon, 1 Dec 2014 17:00:23 -0800 Content-Transfer-Encoding: 7bit Message-Id: <54331E8D-3DCA-4BDB-A5C0-A3D7F20A79D7@delong.com> References: <546E43C2.9010400@gmail.com> <546E48EB.5080405@isi.edu> <546E6FB9.9000500@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 01 Dec 2014 17:00:28 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/bdbWbW34f0hUx-rG4UPWyJoJ1Tk Cc: v6ops@ietf.org Subject: Re: [v6ops] On IPv6 address part naming 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, 02 Dec 2014 01:03:07 -0000 +1 for hextet. Owen > On Nov 20, 2014, at 2:48 PM, Doug Barton wrote: > > Responding to a post at random .... > > I've always been partial to the term 'hextet' for this. > > Doug > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Dec 1 17:23: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 B87EC1ACDDE for ; Mon, 1 Dec 2014 17:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-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 Fda-DNHg0RuS for ; Mon, 1 Dec 2014 17:23:32 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id EEC801ACCC7 for ; Mon, 1 Dec 2014 17:23:31 -0800 (PST) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id sB21KTe7010543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Dec 2014 17:20:29 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com sB21KTe7010543 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1417483230; bh=TP+ugsQMFYOdqEbolm0MRFgJ6DM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=IdJ7Y/Zro+j5Q4rF4qxwbcZL9N9sDtx8NJDv0H8z3UYFCcdej6Js82qUJtypmcwuH Us4s5GP+7hSeY1660PdfEdNls/dVLZb8gGW1OhGd2IbUSOk002zTxRVhkQWYKwcXzy bq1DTK4KfqSl7tEuxAwQuU9L/8P5zXKQSo+a28qw= Content-Type: multipart/alternative; boundary="Apple-Mail=_2810A734-17D3-455E-B12D-8EEA6A81A1E3" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: <546E77FA.8080308@isi.edu> Date: Mon, 1 Dec 2014 17:20:24 -0800 Message-Id: <24FB648F-B953-4D38-8C3A-7A61349F1DE6@delong.com> References: <546E43C2.9010400@gmail.com> <546E48EB.5080405@isi.edu> <546E5E60.8000601@gmail.com> <546E6D16.9000909@isi.edu> <546E77FA.8080308@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 01 Dec 2014 17:20:30 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YDoHdYtQcDU_aEDJWaF-iWeTAGE Cc: IPv6 Operations , "Phillip Remaker \(remaker\)" Subject: Re: [v6ops] On IPv6 address part naming 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, 02 Dec 2014 01:23:33 -0000 --Apple-Mail=_2810A734-17D3-455E-B12D-8EEA6A81A1E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 20, 2014, at 3:23 PM, Joe Touch wrote: >=20 >=20 >=20 > On 11/20/2014 2:51 PM, Richard Hartmann wrote: >> On Thu, Nov 20, 2014 at 11:37 PM, Joe Touch wrote: >>> That said, it depends on whether you're going for Latin accuracy or >>> convenience. >>=20 >> That was a major point of discussion back then and the consensus >> leaned towards convenience. >>=20 >> The technical world is full of plays on words, inside jokes, and = other >> not-quite-serious names. >>=20 >> Given that, I would argue that a (non-funny) name of convenience = would >> be better than a factually correct yet unwieldy name. >=20 > Agreed. To that end, we already have a bunch of name sequences: >=20 > Groups of bits: > bit > nibble > octet/byte octet and byte are not (necessarily) synonymous. A byte may be 8 bits. = An octet is ALWAYS 8 bits. >=20 > Groups of bytes: > octet/byte > halfword > word > double-word > quadword Of which the only deterministic name in the entire group is =E2=80=9Coctet= =E2=80=9D. > IMO, if we're headed towards naming 16-bit things, in the old days > (e.g., when octal was common instead of byte), we'd use hexadecet (not > hexadectet, matching the base name sequence, even though it switches > from Latin to Greek). Octet and byte are often used interchangeably, these days, but you will = find that network engineers usually try to stick with octet in contexts = where exactly 8 bits are intended and reserve byte where =E2=80=9Ca = single addressable memory location=E2=80=9D or =E2=80=9Ca single = character=E2=80=9D is intended. > However, we already have a common term for that - halfword, but that = can > be ambiguous. The only unambiguous terms would be double-byte or > double-octet. double-byte is actually ambiguous because bytes can be many different = lengths. I have seen bytes as short as 5 bits and as long as 12. I = believe there are even longer bytes in historical systems, but my = historical knowledge of computing is limited. > Hextet is a poor choice, IMO. It transliterates to '6', not '16', and > that's misleading at best. At worst, it already has a clear meaning = that > might be accurate for IPv6 specs but not desired: > http://en.wiktionary.org/wiki/hextet = Since that meaning is limited to German (which makes one wonder what it = is doing in the en.wiktionary.com pages). = It=E2=80=99s not listed in Webster=E2=80=99s. I can=E2=80=99t check OED easily at the moment, but if anyone has a = subscription or access to the dead tree edition, feel free. As such, I = don=E2=80=99t think coining it for this purpose is any worse than the = current vernacular (which you have fallen victim to) where bytes are = presumed to be 8 bits in length. > However, I doubt we need a single document to decide such things. = Nobody > declared that "thou shalt refer to 8 bits as an octet" (parodies of > Genesis aside). http://en.wikipedia.org/wiki/Octet_(computing) = Covers this rather well. There may not be an RFC that says =E2=80=9Cthou = shalt call the pieces of an IPv4 address an octet=E2=80=9D, but very = early RFCs do specify that an IPv4 address is comprised of 4 octets. The first RFC I could find that used the term octet was RFC635 (by Vint = Cerf). The definition of IPv4 addresses as 4 octets comes later in = RFC791. Owen --Apple-Mail=_2810A734-17D3-455E-B12D-8EEA6A81A1E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 20, 2014, at 3:23 PM, Joe Touch <touch@isi.edu> = wrote:



On 11/20/2014 2:51 PM, Richard Hartmann = wrote:
On Thu, Nov = 20, 2014 at 11:37 PM, Joe Touch <touch@isi.edu> wrote:
That said, it depends on whether you're going = for Latin accuracy or
convenience.

That was a major point of = discussion back then and the consensus
leaned towards = convenience.

The technical world is full of = plays on words, inside jokes, and other
not-quite-serious = names.

Given that, I would argue that a = (non-funny) name of convenience would
be better than a = factually correct yet unwieldy name.

Agreed. To that end, we already have a bunch of name = sequences:

Groups of bits:
bit
= = nibble
octet/byte

octet and byte = are not (necessarily) synonymous. A byte may be 8 bits. An octet is = ALWAYS 8 bits.


Groups of bytes:
= = octet/byte
halfword
word
= = double-word
quadword

Of which the = only deterministic name in the entire group is = =E2=80=9Coctet=E2=80=9D.

IMO, if we're headed towards = naming 16-bit things, in the old days
(e.g., when octal = was common instead of byte), we'd use hexadecet (not
hexadectet, matching the base name sequence, even though it = switches
from Latin to Greek).

Octet and byte = are often used interchangeably, these days, but you will find that = network engineers usually try to stick with octet in contexts where = exactly 8 bits are intended and reserve byte where =E2=80=9Ca single = addressable memory location=E2=80=9D or =E2=80=9Ca single character=E2=80=9D= is intended.

However, we already have a common term for = that - halfword, but that can
be ambiguous. The only = unambiguous terms would be double-byte or
double-octet.

double-byte is = actually ambiguous because bytes can be many different lengths. I have = seen bytes as short as 5 bits and as long as 12. I believe there are = even longer bytes in historical systems, but my historical knowledge of = computing is limited.

Hextet is a poor choice, IMO. It = transliterates to '6', not '16', and
that's misleading at = best. At worst, it already has a clear meaning that
might = be accurate for IPv6 specs but not desired:
http://en.wiktionary.org/wiki/hextet

Since that = meaning is limited to German (which makes one wonder what it is doing in = the en.wiktionary.com pages). It=E2=80=99s not listed in = Webster=E2=80=99s.
I can=E2=80=99t check OED easily at the = moment, but if anyone has a subscription or access to the dead tree = edition, feel free. As such, I don=E2=80=99t think coining it for this = purpose is any worse than the current vernacular (which you have fallen = victim to) where bytes are presumed to be 8 bits in = length.

However, I doubt we need a single document to decide such = things. Nobody
declared that "thou shalt refer to 8 bits = as an octet" (parodies of
Genesis aside).

Covers this rather well. There may not be an RFC = that says =E2=80=9Cthou shalt call the pieces of an IPv4 address an = octet=E2=80=9D, but very early RFCs do specify that an IPv4 address is = comprised of 4 octets.

The first RFC = I could find that used the term octet was RFC635 (by Vint Cerf). The = definition of IPv4 addresses as 4 octets comes later in = RFC791.

Owen


= --Apple-Mail=_2810A734-17D3-455E-B12D-8EEA6A81A1E3-- From nobody Mon Dec 1 17:38: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 8850F1AC43A for ; Mon, 1 Dec 2014 17:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-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 Ynk3tG-P9lHf for ; Mon, 1 Dec 2014 17:38:21 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5FF1A004B for ; Mon, 1 Dec 2014 17:38:20 -0800 (PST) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id sB21ap5c011751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Dec 2014 17:36:51 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com sB21ap5c011751 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1417484212; bh=zU94dRuN6AMb74LbBktKpAOFDhA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=4pzwONb/JWAqdvE/DqF6edkT59mAXBM2N4ID4FCH0upYMw14urj20LMwydDW5eYbp MpBNcMXB19eR17b148wzubjwTmH/xuUiOptU7T4peQDlvgyByrpdfOO0uIL+4pXPk1 7QWW75SgkGU1eDOSqi9SAjm3RPjuyYMckY/4QTl0= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: Date: Mon, 1 Dec 2014 17:36:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <546E43C2.9010400@gmail.com> <546E48EB.5080405@isi.edu> <546E6FB9.9000500@dougbarton.us> To: Richard Hartmann X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 01 Dec 2014 17:36:52 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BG9y6ARhNi6kjxyyNhkbj7KS2iQ Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] On IPv6 address part naming 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, 02 Dec 2014 01:38:22 -0000 I will also point out that 3 syllables is not likely to persist as a = commonly used term. Further, three syllables that are not necessarily intuitive to spell (is it = saidiset, sedicet, sediset, sedacet, sedacit, =E2=80=A6?) are simply not likely to survive = vernacularization. Most of the terms we tend to use every day tend to get reduced to one or 2 syllable = versions and the majority of the ones in common use tend to have less than ambiguous spelling = (where byte is a notable exception for it=E2=80=99s distinct spelling oddity). nibble byte octet kilo mega giga peta exa milli micro nano pico femto Not one of those is more than 2 syllables and they are all spelled = phonetically and unambiguously. Longer scientific terms tend to get acronymized, such as = Gastrointerologist -> GI, Fiberoptic -> Fiber, etc. I=E2=80=99m not sure what would happen to sedicet if we tried to mandate = it, but I don=E2=80=99t think it would survive to widespread adoption in tact. OTOH, sextet seems to already have substantial following and I think = this is an area where IETF serves the community better by documenting existing terms currently in use. If = possible, we should come to some consensus on a preferred one and document that, but it should, = ideally be chosen from those already in use rather than inventing a new term. Owen > On Nov 20, 2014, at 11:06 PM, Richard Hartmann = wrote: >=20 > On Fri, Nov 21, 2014 at 1:42 AM, Lorenzo Colitti = wrote: >> Hextet seems to be the term most in use among my colleagues, too. >=20 > One more note about this point: back in 2010/2011, there was a > surprising amount of people well into the two figures who contacted > me, asking what the default will be so they could start adoption. The > only sane answer back then was that it would likely be "hextet". It's > quite likely that this usage spread from there and has created a > baseline of a somewhat commonly accepted name. Myself, I have heard > this name used several times in normal conversation without pushing > either way. This was not the case back then so maybe facts have been > created, already. >=20 > Reactions in this thread seem to mirror my observations though we > should let some more time pass before taking a count^Whum. >=20 >=20 >=20 > Richard >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Dec 1 18:53: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 E866F1A0078 for ; Mon, 1 Dec 2014 18:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 Z9SFzfFsihbB for ; Mon, 1 Dec 2014 18:53:28 -0800 (PST) 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 DE6791A0087 for ; Mon, 1 Dec 2014 18:53:27 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id l13so15205403iga.15 for ; Mon, 01 Dec 2014 18:53:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ob+D0DAiOuyGXej+LNInxSf2Fk6Moyjx5Csnmo7GcOs=; b=YR7sI+Kbw9MPMGeD1F8dO0ML1RYgRKYwA3D8uIDFXh+tLQeQa0hOatjPw2VNLXfxIo otfEkqK6xwGU1/39dI8cLWyUAZtNdIAXLAlaU8fSp0g8OqpurCi2e1HwUnlNgBkDGWFp L1cA+DCWIBmElbItcnBQxB1Gu8zi1PqtUAgfnnBwBavB5OnLGQGbDyJTG2LPw9Vs1Lsu i+cyetTeEzP3DxHgp647XoQo/E595rGzN92WZu4r9+1s9IIUlsR/Bl6nZLPjZiiMkL6h K5y+/lIiILcnXgarbtiJom9151YbfeCtUIDwUfuC36CWoauA88asc25NG1lxdxYBabLZ wH7Q== X-Received: by 10.43.79.7 with SMTP id zo7mr877623icb.5.1417488807039; Mon, 01 Dec 2014 18:53:27 -0800 (PST) Received: from [192.168.0.101] ([216.254.164.46]) by mx.google.com with ESMTPSA id 73sm1261945ioz.30.2014.12.01.18.53.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Dec 2014 18:53:26 -0800 (PST) Message-ID: <547D299E.9050403@gmail.com> Date: Mon, 01 Dec 2014 21:53:18 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Owen DeLong , Joe Touch References: <546E43C2.9010400@gmail.com> <546E48EB.5080405@isi.edu> <546E5E60.8000601@gmail.com> <546E6D16.9000909@isi.edu> <546E77FA.8080308@isi.edu> <24FB648F-B953-4D38-8C3A-7A61349F1DE6@delong.com> In-Reply-To: <24FB648F-B953-4D38-8C3A-7A61349F1DE6@delong.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xCzU5Pj6Ija7EnPgY2hVVM_zf8g Cc: IPv6 Operations , "Phillip Remaker \(remaker\)" Subject: Re: [v6ops] On IPv6 address part naming 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, 02 Dec 2014 02:53:30 -0000 On 01/12/2014 8:20 PM, Owen DeLong wrote: > >> On Nov 20, 2014, at 3:23 PM, Joe Touch > > wrote: >> >> >> >> On 11/20/2014 2:51 PM, Richard Hartmann wrote: >>> On Thu, Nov 20, 2014 at 11:37 PM, Joe Touch >> > wrote: >>>> That said, it depends on whether you're going for Latin accuracy or >>>> convenience. >>> >>> That was a major point of discussion back then and the consensus >>> leaned towards convenience. >>> >>> The technical world is full of plays on words, inside jokes, and other >>> not-quite-serious names. >>> >>> Given that, I would argue that a (non-funny) name of convenience would >>> be better than a factually correct yet unwieldy name. >> >> Agreed. To that end, we already have a bunch of name sequences: >> >> Groups of bits: >> bit >> nibble >> octet/byte > > octet and byte are not (necessarily) synonymous. A byte may be 8 bits. > An octet is ALWAYS 8 bits. > >> >> Groups of bytes: >> octet/byte >> halfword >> word >> double-word >> quadword > > Of which the only deterministic name in the entire group is “octet”. > >> IMO, if we're headed towards naming 16-bit things, in the old days >> (e.g., when octal was common instead of byte), we'd use hexadecet (not >> hexadectet, matching the base name sequence, even though it switches >> from Latin to Greek). > > Octet and byte are often used interchangeably, these days, but you will > find that network engineers usually try to stick with octet in contexts > where exactly 8 bits are intended and reserve byte where “a single > addressable memory location” or “a single character” is intended. > >> However, we already have a common term for that - halfword, but that can >> be ambiguous. The only unambiguous terms would be double-byte or >> double-octet. > > double-byte is actually ambiguous because bytes can be many different > lengths. I have seen bytes as short as 5 bits and as long as 12. I > believe there are even longer bytes in historical systems, but my > historical knowledge of computing is limited. > >> Hextet is a poor choice, IMO. It transliterates to '6', not '16', and >> that's misleading at best. At worst, it already has a clear meaning that >> might be accurate for IPv6 specs but not desired: >> http://en.wiktionary.org/wiki/hextet > > Since that meaning is limited to German (which makes one wonder what it > is doing in the en.wiktionary.com pages). > It’s not listed in Webster’s. > I can’t check OED easily at the moment, but if anyone has a subscription > or access to the dead tree edition, feel free. As such, I don’t think > coining it for this purpose is any worse than the current vernacular > (which you have fallen victim to) where bytes are presumed to be 8 bits > in length. > >> However, I doubt we need a single document to decide such things. Nobody >> declared that "thou shalt refer to 8 bits as an octet" (parodies of >> Genesis aside). > > http://en.wikipedia.org/wiki/Octet_(computing) > > Covers this rather well. There may not be an RFC that says “thou shalt > call the pieces of an IPv4 address an octet”, but very early RFCs do > specify that an IPv4 address is comprised of 4 octets. > > The first RFC I could find that used the term octet was RFC635 (by Vint > Cerf). The definition of IPv4 addresses as 4 octets comes later in RFC791. > > Owen > > > I can't resist adding a touch of history. The term "byte" was introduced with the IBM /360, and definitely meant eight bits at that time. I worked on the first one in Canada. The /360 came after the IBM 1401, which emulated punched cards plus a couple of additional bits for parity and word marks. Rummaging through my hardcopy Random House dictionary I find "decade" = "group of ten". I'm not sure if "hexadecade" translates to 16 or 60, but it sounds good. Tom Taylor From nobody Mon Dec 1 19:03: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 2B8B11A006E for ; Mon, 1 Dec 2014 19:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.898 X-Spam-Level: X-Spam-Status: No, score=0.898 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-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 yWjl5Pnp2Fpb for ; Mon, 1 Dec 2014 19:03:29 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE5C1A000E for ; Mon, 1 Dec 2014 19:03:28 -0800 (PST) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id sB231JJV017277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Dec 2014 19:01:20 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com sB231JJV017277 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1417489280; bh=3YGU6Y8mt/KP18wmfoqcTDQoWmM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=f1l26trRsVYpq5j61G2zAbMZL7YGTkKBXk/WhpUepPOaVBizl4V2f22sOi4rk+akB YHEglyyba5R8wzXwNcSZ+29IC71RYIqsC3LnY8NHOboJO8ezpW3cADTZjCK6keJE5x hvqJ7P+pmE9ekZVwLX/IoELID789S+EdyBMCMRaQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: <5470C6B7.4000203@alvarezp.ods.org> Date: Mon, 1 Dec 2014 19:01:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <546FE0A4.10302@alvarezp.ods.org> <547005F9.1070303@dougbarton.us> <5470C6B7.4000203@alvarezp.ods.org> To: Octavio Alvarez X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 01 Dec 2014 19:01:20 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mY49y89a4tA85fXJx_lF56n1p2E Cc: v6ops@ietf.org Subject: Re: [v6ops] On IPv6 address part naming 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, 02 Dec 2014 03:03:30 -0000 hexadectet may be more natural or easier for someone of hispanic = background, but as a native English speaker, I have to tell you that I = find it much easier to say hextet than any of the others. Owen > On Nov 22, 2014, at 9:24 AM, Octavio Alvarez = wrote: >=20 > On 11/21/2014 07:41 PM, Doug Barton wrote: >> On 11/21/14 5:02 PM, Octavio Alvarez wrote: >>> "Hexadecatet". It's correct and even easier than "hextet" >>=20 >> 5 syllables is easier than 2? Seriously? :) >=20 > Yeah, I should clarify. I'm not even sure if I meant "hexdectet" = instead of "hextet" above. >=20 > Anyway: easy !=3D short !=3D natural >=20 > "Natural" implies the muscle use of the mouth and the already-trained = brain used to pronounce a word, mostly as a result of the accent and = culture. The brain and muscles already have many constructs on their = "cache" to (both) say and understand a word. >=20 > 2 is shorter than 5, but not necessarily easier. For example, in = Spain's Spanish "hexteto" is more unnatural pronounce than "hexateto", = even though it is a shorter word. Even further, "hexadecatet" is way = more natural than "hexdectet" although 5 > 3. >=20 > So: >=20 > * hexadecatet, easier than hexadectet > * hexadecatet, definitely easier than hexdectet > * hexatet, easier than hextet > * hex- -dec- -tet, more correct than hex- -tet >=20 > That is why I gave my thumbs up to "hexadecatet": >=20 > * "Hexadecatet" better (not shorter) than "hextet", considering = correctness. >=20 > * "Hexadecatet" better (and easier) than "hexdectet" >=20 > My $2E-2. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Dec 1 19:11: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 DF48E1A0083 for ; Mon, 1 Dec 2014 19:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 abUniXVAWgg7 for ; Mon, 1 Dec 2014 19:11:46 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 42E641A006E for ; Mon, 1 Dec 2014 19:11:46 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 51957DA0112 for ; Tue, 2 Dec 2014 03:11:17 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 1259453E072; Mon, 1 Dec 2014 19:11:16 -0800 (PST) Received: from [192.168.0.10] (72.182.60.179) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 1 Dec 2014 19:11:02 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Mon, 1 Dec 2014 21:10:49 -0600 Content-Transfer-Encoding: quoted-printable Message-ID: References: <546FE0A4.10302@alvarezp.ods.org> <547005F9.1070303@dougbarton.us> <5470C6B7.4000203@alvarezp.ods.org> To: Owen DeLong X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [72.182.60.179] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/urAcFs8XgtvDSeBM9ylGQKePetw Cc: v6ops@ietf.org Subject: Re: [v6ops] On IPv6 address part naming 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, 02 Dec 2014 03:11:53 -0000 On Dec 1, 2014, at 9:01 PM, Owen DeLong wrote: > hexadectet may be more natural or easier for someone of hispanic = background, but as a native English speaker, I have to tell you that I = find it much easier to say hextet than any of the others. It's also shorter to write. And for better or for worse, IETF = documents are written in english. I suspect this general practice is = more of a problem for someone who is not a native english speaker than = the specific english or jargon words that are used in documents... :) From nobody Mon Dec 1 19:32: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 0F9541A0089 for ; Mon, 1 Dec 2014 19:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 Hf_MFtO6VErK for ; Mon, 1 Dec 2014 19:32:19 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DBEE1A0083 for ; Mon, 1 Dec 2014 19:32:19 -0800 (PST) Received: from [192.168.1.7] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id sB23Va8h023578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Dec 2014 19:31:39 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (12B436) In-Reply-To: <547D299E.9050403@gmail.com> Date: Mon, 1 Dec 2014 19:31:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6AACEEC7-ECBB-407E-A359-55DDA53C50F0@isi.edu> References: <546E43C2.9010400@gmail.com> <546E48EB.5080405@isi.edu> <546E5E60.8000601@gmail.com> <546E6D16.9000909@isi.edu> <546E77FA.8080308@isi.edu> <24FB648F-B953-4D38-8C3A-7A61349F1DE6@delong.com> <547D299E.9050403@gmail.com> To: Tom Taylor X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/g83QQOotk2MrXvyVHFv3XH3eHGE Cc: "Phillip Remaker \(remaker\)" , IPv6 Operations Subject: Re: [v6ops] On IPv6 address part naming 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, 02 Dec 2014 03:32:20 -0000 > On Dec 1, 2014, at 6:53 PM, Tom Taylor wrote: >=20 > I can't resist adding a touch of history. The term "byte" was introduced w= ith the IBM /360, It was coined during the design of the IBM Stretch, by Buchholtz, prior to t= he /360. Byte meant 8 bits until that got mixed up with parity memory sizes. Is has m= eant 8 bits got more then long enough at this point to be unambiguous.=20 Joe From nobody Mon Dec 1 22:31: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 492711A0055; Mon, 1 Dec 2014 22:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[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 x2KKXyzdqVOX; Mon, 1 Dec 2014 22:30:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6ED1A0108; Mon, 1 Dec 2014 22:30:53 -0800 (PST) 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.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141202063053.13923.34303.idtracker@ietfa.amsl.com> Date: Mon, 01 Dec 2014 22:30:53 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/fayf889ovKIv2VgND5aK-d9qlzM Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-14.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, 02 Dec 2014 06:30:57 -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 : An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices Authors : David Binet Mohamed Boucadair Ales Vizdal Gang Chen Nick Heatley Ross Chandler Filename : draft-ietf-v6ops-mobile-device-profile-14.txt Pages : 20 Date : 2014-12-01 Abstract: This document defines an IPv6 profile that a number of operators recommend in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). This document defines a different profile than the one for general connection to IPv6 cellular networks defined in the IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts document. In particular, this document identifies also features to deliver IPv4 connectivity service over an IPv6-only transport. Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-14 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 Dec 2 04:35: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 BA3FC1A1B19 for ; Tue, 2 Dec 2014 04:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, 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 rYxz83zqcZty for ; Tue, 2 Dec 2014 04:35:20 -0800 (PST) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE811A1B01 for ; Tue, 2 Dec 2014 04:35:20 -0800 (PST) Received: from mail-qg0-f52.google.com ([209.85.192.52]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKVH2yB6hBqwwgtgRM+9jgrvtXNwomw0Rb@postini.com; Tue, 02 Dec 2014 04:35:20 PST Received: by mail-qg0-f52.google.com with SMTP id a108so8906541qge.25 for ; Tue, 02 Dec 2014 04:35:19 -0800 (PST) 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=cute2ZUfKpAO7GqHchiR30FMaIVhJheqCAJyrOw8OzI=; b=NMVdtPvEasxKaryH+BU4pUqNwpKrXyba9mZ7QN4YHG93mRzEn36VuJdxJ8KVlxNLSG bp5Os9yS3zSay/vDvoad88sKi8WD+LGqVZDqhUN5buhFE5zjGp+dziAcY5JymsTxpVc2 pCEqTElnP62RXO5RlleBHfMI4oq9MaMGmtl3YY2bIom+CzAhyAEV1lyLNK9u/yY4mRoQ hgHOElfnyJFH96l5IR9cM1g56c1M/qlFS2fsJcTvOMMftp/aDQfxJeBL/3aORGcf5tIs vxR1RDkfUcHX3mRVpmQQIFfWCoY6f5lqvpDxMAF5cJBjdyyH86sLRZ0rO3LZQRm7KyZV /47A== X-Gm-Message-State: ALoCoQn5f3zLqy/y0JgiP+NHmi9FdE0hi1gqC1Y52ewl5McZMT39giaJrK+sI9B939pi2rGYrICn7Po465W2eDLUt1uedEVA58+/Y08i30BF5ERzCCpGteZSaAtc28GdnBZEPalTBgzw X-Received: by 10.140.105.164 with SMTP id c33mr91739946qgf.11.1417523719452; Tue, 02 Dec 2014 04:35:19 -0800 (PST) X-Received: by 10.140.105.164 with SMTP id c33mr91739916qgf.11.1417523719228; Tue, 02 Dec 2014 04:35:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.97.136 with HTTP; Tue, 2 Dec 2014 04:34:59 -0800 (PST) In-Reply-To: <93034721-BA1A-45C5-A3F5-0838DE3DB3FE@delong.com> References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <93034721-BA1A-45C5-A3F5-0838DE3DB3FE@delong.com> From: John Mann Date: Tue, 2 Dec 2014 23:34:59 +1100 Message-ID: To: Owen DeLong Content-Type: multipart/alternative; boundary=001a11399f4cbeeeee05093af54e Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-GQCJF9GmI7Gwdvp-7xtrqJmRlg Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? 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, 02 Dec 2014 12:35:24 -0000 --001a11399f4cbeeeee05093af54e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On 2 December 2014 at 07:42, Owen DeLong wrote: > > On Nov 13, 2014, at 11:59 AM, George Michaelson wrote: > > HE.net tunnels cause severe distortion of RTT. They are anything but > local termination for much of the world, and whilst I applaud their role = in > promoting V6 adoption, its a poor fit to the money flow of IPv4 > relationships for many people. I should know: I have one in Australia, an= d > my nearest terminations are SG/HK (which is via the US and trombones) or > the US (which is 200+ms delay from me) > > > Why would SG/HK be via the US from AU? That sounds like your provider has > failed to provide decent connectivity to Asia more than an issue related > directly to tunnelbroker. > Out of interest, I took a look ... Taking an example, looking at https://tunnelbroker.net/status.php we see a tunnel endpoint at tserv19.hkg1 =3D=3D 216.218.221.2 Also, Monash University is AS56132; we get most of our Internet from AARNet AS7575. Looking at http://lg.aarnet.edu.au/cgi-bin/lg 'show bgp ipv4 216.218.221.2' =3D> 216.218.221.0/24 advertised by AS 6969 'trace 216.218.221.2' goes via nsw, pao, lax, tyo, hkg And also http://bgp.he.net/AS56132#_graph4 shows AS56132 -> AS7575 -> AS6939 and also AS7575 -> AS10026 -> AS6939 So, the problem seems to be that AARNet directly peers with HE at PAO and doesn't peer with HE at any other IX (or if it does, that peering is not preferred). AARNet _could_ also directly peer with HE in Singapore http://he.net/HurricaneElectricNetworkMap.pdf https://www.aarnet.edu.au/images/uploads/resources/International_Map_May_20= 14.pdf but care would need to be taken when choosing between the 5 Gbit/s Australia<->Singapore path v. the 120 Gbit/s Sydney<->USA path Looking closer at the traceroute =3D=3D=3D lg.aarnet.edu.au> traceroute 216.218.221.2 traceroute to 216.218.221.2 (216.218.221.2), 30 hops max, 40 byte packets 1 ge-1-0-0.bb1.a.syd.aarnet.net.au (202.158.196.129) 0.390 ms 0.369 ms 0.359 ms 2 ae9.pe2.brwy.nsw.aarnet.net.au (113.197.15.56) 0.335 ms 0.327 ms 0.317 ms 3 ge-4_0_0.bb1.a.pao.aarnet.net.au (202.158.194.177) *155.513* ms 155.508 ms 155.521 ms 4 30gigabitethernet2-1.core1.pao1.he.net (198.32.176.20) *252.462* ms 252.474 ms 252.337 ms 5 10ge11-6.core1.lax1.he.net (72.52.92.22) 252.252 ms 252.247 ms 252.236 ms 6 10ge1-3.core1.lax2.he.net (72.52.92.122) 249.929 ms 249.918 ms 249.912 ms 7 10ge3-2.core1.tyo1.he.net (184.105.223.106) 250.008 ms 10ge6-3.core1.hkg1.he.net (184.105.223.170) 255.574 ms 10ge3-2.core1.tyo1.he.net (184.105.223.106) 250.006 ms 8 10ge5-2.core1.hkg1.he.net (184.105.222.106) 256.108 ms 257.475 ms 257.460 ms 9 tserv1.hkg1.he.net (216.218.221.2) 250.165 ms * * =3D=3D=3D The RTT between hops 3 and 4 increases from 155 ms to 252 ms, even though both routers claim to be in PAO. Perhaps the return traffic is taking some non-optimal path. Indeed, a traceroute run on http://lg.he.net/ from fmt1, hkgq, sin1 to 202.158.196.129 (the hop 1 address from above) has all three traceroutes routing via asianetcom in Singapore, *and* the RTTs being about the same (254 ms, 250 ms, 252 ms). So ... it looks like we have a 250 ms loop for all AARNet <-> HE traffic. 97ms SIN <- PAO 76ms v ^ 77ms AUS This is a lot slower than about 155 ms for the direct return path AUS <-> PAO Thanks, John > Of course, if you can find native IPv6 in AU, why not set up your own > tunnelbroker for Aussies or work with one of the existing ones to build a > local node? > > I cannot speak to SIXX but I suspect it too distorts the packetflow and > causes a disparate RTT compared to native. > > > Any tunnel or tunnel broker service which involves a detour over a long > distance will create RTT disparity. If you can get native, then native wi= ll > always be superior to tunnels. Tunnels are intended for circumstances whe= re > you can=E2=80=99t get native. > > 6rd is homed in your own ISP. its almost 1:1 congruent with your normal > RTT for native IPv6 endpoints. > > > Sure, and that=E2=80=99s great if your ISP supports 6rd. Again, that=E2= =80=99s not the > target audience for tunnel brokers. > > When we say 'tunnels are bad' its not because GRE randomly corrupts bits: > its because the effects on the end-to-end model are bad. The badness > varies, but the consequence of a tunnel is usually not what you wanted in > reality, unless the sole consideration was connectivity per se, not its > quality, compared to V4 > > > Actually, when we say =E2=80=9Ctunnels are bad=E2=80=9D, it=E2=80=99s bec= ause we like to > oversimplify and we usually develop some tunnel vision in the process. > > I=E2=80=99m running entirely on tunnels for both v4 and v6. They don=E2= =80=99t > significantly distort my RTTs vs. native and in many cases, I=E2=80=99ve = discovered > that I get better performance over my tunnels that I could have received > natively because my tunnels aren=E2=80=99t subject to some of the games t= hat get > played to try and manipulate financials between providers to extort > payments for access to eyeballs. > > Tunnels can be good. Tunnels can be bad. They are a tool like any other > tool in the networking toolkit and knowing how to use the tool properly c= an > greatly improve your user experience with said tool. > > Owen > > > -G > > On Thu, Nov 13, 2014 at 9:56 AM, Gert Doering wrote: > >> Hi, >> >> On Thu, Nov 13, 2014 at 09:50:31AM -1000, Iljitsch van Beijnum wrote: >> > There's no reason tunnels have to be so-so. >> >> I'm wondering who would provide these tunnels in the future, and what >> would >> their business model be. >> >> This is a real question. Today, you can get tunnels from Sixxs nodes >> (enthusiasts, which might eventually consider the IPv6 deployment issue >> to be "solved" and stop running tunnel nodes), HE.NET >> (it's good marketing, >> but eventually the costs involved might win over the marketing gain?), >> and others that run tunnels for various reasons that might not be there >> in 2-3 years... >> >> 6rd is a very specific tunnel technology that has answers to that questi= on >> ("I want to roll out IPv6 to my customers but part of my infrastructure >> cannot do it. So I provision my CPEs to do 6rd, and take responsibility >> to run the 6rd relay") - but as with 6to4 relays, what is the incentive = to >> run a tunnel broker in 2-3 years from now? You won't get paid (users do >> not pay for IPv6, otherwise they would go and choose ISPs that provide >> v6)... >> >> 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 >> > > _______________________________________________ > 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 > > --001a11399f4cbeeeee05093af54e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

On 2 December 2014 at 07:42, Owen DeLong <owen@delong.com> wrote:

On Nov 13, 2014, at 11:59 = AM, George Michaelson <ggm@algebras.org> wrote:

HE.net tunnels cause severe distor= tion of RTT. They are anything but local termination for much of the world,= and whilst I applaud their role in promoting V6 adoption, its a poor fit t= o the money flow of IPv4 relationships for many people. I should know: I ha= ve one in Australia, and my nearest terminations are SG/HK (which is via th= e US and trombones) or the US (which is 200+ms delay from me)

Why would SG/HK be via the US from AU? Tha= t sounds like your provider has failed to provide decent connectivity to As= ia more than an issue related directly to tunnelbroker.

Out of interest, I took a look ...

<= /div>
Taking an example, looking at
=C2=A0 https://tunnelbroker.net/status.php
we see = a tunnel endpoint at
=C2=A0 =C2=A0tserv19.hkg1 =3D=3D 216.218.221.2
<= div>
Also, Monash University is AS56132; we get most of our I= nternet from AARNet AS7575.

Looking at
=C2=A0 'show bgp ipv4 216.218.221.2' = =3D> 216.218.221.0/24 advertised= by AS 6969
=C2=A0 'trace 216.218.221.2= ' goes via nsw, pao, lax, tyo, hkg
And = also
=C2=A0=C2=A0http://bgp.he.net/AS56132#_graph4
=C2=A0 shows AS56132 -> AS7575 -> AS6939
=C2=A0 and also =C2=A0AS7575 -> AS10026 -> AS693= 9

So, = the problem seems to be that AARNet directly peers with HE at PAO
and doesn't peer with HE at any other IX (or if = it does, that peering is not preferred).
AA= RNet _could_ also directly peer with HE in Singapore
=C2=A0 =C2=A0http://he.net/HurricaneElectricNetworkMap.pdf
=C2=A0 =C2=A0https://www.aarnet.edu.au/= images/uploads/resources/International_Map_May_2014.pdf
but care would need to be taken when choosing between the = 5 Gbit/s Australia<->Singapore path v. the 120 Gbit/s Sydney<->= USA path

Looking closer at the traceroute
=3D=3D= =3D
lg.aa= rnet.edu.au> traceroute 216.218.221.2
traceroute to 216.218.221.2= (216.218.221.2), 30 hops max, 40 byte packets
=C2=A01 =C2=A0ge-1-0-0.bb1.a.syd.aarnet.net.au (202.158.196.129) =C2=A00.390 ms =C2=A00.369 ms =C2=A00.359 ms
=C2=A0= 2 =C2=A0ae9.pe2.brwy.nsw.= aarnet.net.au (113.197.15.56) =C2=A00.335 ms =C2=A00.327 ms =C2=A00.317= ms
=C2=A03 =C2=A0ge= -4_0_0.bb1.a.pao.aarnet.net.au (202.158.194.177) =C2=A0155.513 m= s =C2=A0155.508 ms =C2=A0155.521 ms
=C2=A04 =C2=A030gigabitethernet2-1.core1.pao1.he.net<= /a> (198.32.176.20) =C2=A0252.462 ms =C2=A0252.474 ms =C2=A0252.337 = ms
=C2=A05 =C2=A010ge11-6.= core1.lax1.he.net (72.52.92.22) =C2=A0252.252 ms =C2=A0252.247 ms =C2= =A0252.236 ms
=C2=A06 =C2=A010ge1-3.core1.lax2.he.net (72.52.92.122) =C2=A0249.929 ms =C2=A0249.91= 8 ms =C2=A0249.912 ms
=C2=A07 =C2=A010ge3-2.core1.tyo1.he.net (184.105.223.106) =C2=A0250.008 ms <= a href=3D"http://10ge6-3.core1.hkg1.he.net">10ge6-3.core1.hkg1.he.net (= 184.105.223.170) =C2=A0255.574 ms 10ge3-2.core1.tyo1.he.net (184.105.223.106) =C2=A0250.006 ms
=C2= =A08 =C2=A010ge5-2.core1.hkg1.= he.net (184.105.222.106) =C2=A0256.108 ms =C2=A0257.475 ms =C2=A0257.46= 0 ms
=C2=A09 =C2=A0tserv1.hkg1.he.= net (216.218.221.2) =C2=A0250.165 ms * *
=3D=3D=3DThe R= TT between hops 3 and 4 increases from 155 ms to 252 ms, even though both r= outers claim to be in PAO.
Perhaps the return traffic is taking some no= n-optimal path.

Indeed, a traceroute run on =C2=A0http://lg.he.net/ =C2=A0from=C2=A0fmt1, hkgq, sin1
to =C2=A0202.158.196.129=C2=A0(the hop 1 address from above)=C2=A0
has all three tracero= utes routing via asianetcom in Singapore, =C2=A0
*and* the RTTs being about the same (254 ms, 250 ms, 252 ms).

So ... it loo= ks like we have a 250 ms loop for all AARNet <-> HE traffic.

=C2=A0 =C2=A0 =C2=A0 =C2=A097ms
=C2=A0 =C2=A0SIN =C2=A0<- =C2=A0PAO
76= ms v =C2=A0 =C2=A0 ^ =C2=A077ms=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0AUS

This is a l= ot slower than about 155 ms for the direct return path

=C2=A0 = =C2=A0 =C2=A0AUS <-> PAO

Thanks,
=C2=A0 =C2=A0 John
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
Of course, if you = can find native IPv6 in AU, why not set up your own tunnelbroker for Aussie= s or work with one of the existing ones to build a local node?

I cannot= speak to SIXX but I suspect it too distorts the packetflow and causes a di= sparate RTT compared to native.

Any tunnel or tunnel broker service which involves a detour over a long = distance will create RTT disparity. If you can get native, then native will= always be superior to tunnels. Tunnels are intended for circumstances wher= e you can=E2=80=99t get native.

6rd is homed in your own ISP. its almos= t 1:1 congruent with your normal RTT for native IPv6 endpoints.
=

Sure, and that=E2=80=99s great if your I= SP supports 6rd. Again, that=E2=80=99s not the target audience for tunnel b= rokers.

When we say 'tunnels are bad' its not because GRE ran= domly corrupts bits: its because the effects on the end-to-end model are ba= d. The badness varies, but the consequence of a tunnel is usually not what = you wanted in reality, unless the sole consideration was connectivity per s= e, not its quality, compared to V4

<= /span>Actually, when we say =E2=80=9Ctunnels are bad=E2=80=9D, it=E2=80=99s= because we like to oversimplify and we usually develop some tunnel vision = in the process.

I=E2=80=99m running entirely on tu= nnels for both v4 and v6. They don=E2=80=99t significantly distort my RTTs = vs. native and in many cases, I=E2=80=99ve discovered that I get better per= formance over my tunnels that I could have received natively because my tun= nels aren=E2=80=99t subject to some of the games that get played to try and= manipulate financials between providers to extort payments for access to e= yeballs.

Tunnels can be good. Tunnels can be bad. = They are a tool like any other tool in the networking toolkit and knowing h= ow to use the tool properly can greatly improve your user experience with s= aid tool.

Owen


-G

On Thu, Nov 13, 2014 at 9:56 AM= , Gert Doering <gert@space.net> wrote:
Hi,<= br>
On Thu, Nov 13, 2014 at 09:50:31AM -1000, Iljitsch van Beijnum wrote:
> There's no reason tunnels have to be so-so.

I'm wondering who would provide these tunnels in the future, and= what would
their business model be.

This is a real question.=C2=A0 Today, you can get tunnels from Sixxs nodes<= br> (enthusiasts, which might eventually consider the IPv6 deployment issue
to be "solved" and stop running tunnel nodes), HE.NET (it's good marketing,
but eventually the costs involved might win over the marketing gain?),
and others that run tunnels for various reasons that might not be there
in 2-3 years...

6rd is a very specific tunnel technology that has answers to that question<= br> ("I want to roll out IPv6 to my customers but part of my infrastructur= e
cannot do it.=C2=A0 So I provision my CPEs to do 6rd, and take responsibili= ty
to run the 6rd relay") - but as with 6to4 relays, what is the incentiv= e to
run a tunnel broker in 2-3 years from now?=C2=A0 You won't get paid (us= ers do
not pay for IPv6, otherwise they would go and choose ISPs that provide
v6)...

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

SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo= rs.: A. Grundner-Culemann
D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0USt-IdNr.: DE813185279

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

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


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


--001a11399f4cbeeeee05093af54e-- From nobody Tue Dec 2 06:21: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 71D951A1B98 for ; Tue, 2 Dec 2014 06:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 egDy51KGWSRr for ; Tue, 2 Dec 2014 06:21:08 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 094CB1A1B96 for ; Tue, 2 Dec 2014 06:21:08 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id CA131DA0136 for ; Tue, 2 Dec 2014 14:20:41 +0000 (UTC) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id BFB0E53E072 for ; Tue, 2 Dec 2014 06:20:37 -0800 (PST) Received: from [192.168.0.10] (72.182.60.179) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 2 Dec 2014 06:20:35 -0800 From: Ted Lemon Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Dec 2014 08:20:20 -0600 References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> To: "v6ops@ietf.org WG" Message-ID: MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [72.182.60.179] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/akGpWSKJiC3Bkfe8iV7Z-aUtZZY Subject: [v6ops] Fwd: Last Call: RFC 6346 successful: moving to Proposed Standard 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, 02 Dec 2014 14:21:09 -0000 RJ Atkinson has pointed out that the proposal to move A+P from = experimental to standard might be of interest to the v6ops working = group. This seems like a reasonable point. I'm not a chair and not = the responsible AD for v6ops, but I certainly would welcome discussion = of this on v6ops. I am on the mailing list, and I think Randy is too, = so if this were discussed on v6ops, we would both see and be able to = participate in the discussion. So, by all means, please discuss! Thanks, Ted Begin forwarded message: > From: The IESG > Subject: Last Call: RFC 6346 successful: moving to Proposed Standard > Date: December 1, 2014 at 4:38:32 PM CST > To: IETF-Announce > Reply-To: ietf@ietf.org >=20 >=20 > The IESG has received a request from an individual participant to make > the following status changes: >=20 > - RFC6346 from Experimental to Proposed Standard > (The Address plus Port (A+P) Approach to the IPv4 Address Shortage) >=20 > The supporting document for this request can be found here: >=20 > = http://datatracker.ietf.org/doc/status-change-address-plus-port-to-propose= d/ >=20 > 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-12-29. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > The affected document can be obtained via > http://datatracker.ietf.org/doc/rfc6346/ >=20 > IESG discussion of this request can be tracked via > = http://datatracker.ietf.org/doc/status-change-address-plus-port-to-propose= d/ballot/ >=20 >=20 From nobody Tue Dec 2 08:26: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 7F6D41A00D8 for ; Mon, 1 Dec 2014 20:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 Z831b9beqGKC for ; Mon, 1 Dec 2014 20:59:51 -0800 (PST) Received: from mail.chartercom.com (mail.chartercom.com [24.217.29.16]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD301A00CA for ; Mon, 1 Dec 2014 20:59:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,498,1413262800"; d="scan'208";a="344468690" Received: from unknown (HELO KSTLMEXHTP01.CORP.CHARTERCOM.COM) ([192.168.31.33]) by mail.chartercom.com with ESMTP; 01 Dec 2014 22:39:02 -0600 Received: from KSTLMEXCP03MBX.CORP.CHARTERCOM.COM ([192.168.31.18]) by KSTLMEXHTP01.CORP.CHARTERCOM.COM ([192.168.31.33]) with mapi; Mon, 1 Dec 2014 22:59:50 -0600 From: "Rampley Jr, Jim F" To: Owen DeLong , Doug Barton Date: Mon, 1 Dec 2014 22:59:48 -0600 Thread-Topic: [v6ops] On IPv6 address part naming Thread-Index: AdAN7M0IzaEn4WHhQc+XSi4oGiUudw== Message-ID: References: <546E43C2.9010400@gmail.com> <546E48EB.5080405@isi.edu> <546E6FB9.9000500@dougbarton.us> <54331E8D-3DCA-4BDB-A5C0-A3D7F20A79D7@delong.com> In-Reply-To: <54331E8D-3DCA-4BDB-A5C0-A3D7F20A79D7@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 acceptlanguage: en-US 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/9Ws3APuCpO3q5Dx7aRoj8uaScZI X-Mailman-Approved-At: Tue, 02 Dec 2014 08:26:28 -0800 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] On IPv6 address part naming 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, 02 Dec 2014 04:59:52 -0000 I agree that hextet sounds right. Jim On 12/1/14, 7:00 PM, "Owen DeLong" wrote: >+1 for hextet. > >Owen > >> On Nov 20, 2014, at 2:48 PM, Doug Barton wrote: >>=20 >> Responding to a post at random .... >>=20 >> I've always been partial to the term 'hextet' for this. >>=20 >> Doug >>=20 >> From nobody Tue Dec 2 10:44: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 60C631A1B21 for ; Tue, 2 Dec 2014 10:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 r0tFT6FN5Li8 for ; Tue, 2 Dec 2014 10:44:24 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 246C51A014D for ; Tue, 2 Dec 2014 10:44:24 -0800 (PST) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:7c34:5ffc:ed:b65a] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sB2Iht5O007329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2014 19:43:56 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Iljitsch van Beijnum In-Reply-To: <546CE0E9.9080101@network-heretics.com> Date: Tue, 2 Dec 2014 19:44:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QCm2tl4eKFY5TK_rvkWVRuozOBI Cc: v6ops@ietf.org Subject: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 02 Dec 2014 18:44:26 -0000 On 19 Nov 2014, at 19:26, Keith Moore = wrote: > If there was actually a bar BOF on a 6to4 replacement, would someone = care to summarize? There was no actual bar BoF. However, I did talk to a number of people individually about this. I'd = say about half of them felt that working on tunnels and/or working on "a = 6to4 replacement" was not a good idea. I couldn't tease out whether that = was an understandable immediate reaction or also a more considered = opinion, and it was also hard to determine whether people mostly = objected to the 6to4 part or to any work on tunnels in general. I explained my proposal to a number of people: "Something that is as easy to use as 6to4 but as reliable as a tunnel = broker tunnel" The short version: - NO ANYCASTING, NO ROUTE OPTIMIZATION - give home gateways a unique login out of the box, such as = @ - user can override this with @ or @ - home gateways connect to servers indicated by the domain part of the = login (through SRV records) and state their capabilities - the server matches their IPv4 address, NAT/CGN status and capabilities = with available tunnel options such as brokers, 6rd, public gateways, = sends back configuration info - (ISPs would have to publish their gateway configurations) - home gateway sets up a tunnel and uses keepalives to make sure it's = up, go back to the server if the tunnel goes down for whatever reason - all of this can of course also be done by individual hosts I got a generally cautiously positive reception from those that gave me = enough time to explain all of this, except that those with skin in the = game of course still prefer their own systems. So I guess I have a draft to write. Iljitsch= From nobody Tue Dec 2 11:15: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 E1A491A6FC9 for ; Tue, 2 Dec 2014 11:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 VxZ3aDMq0Ob1 for ; Tue, 2 Dec 2014 11:15:23 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C76A11A1B37 for ; Tue, 2 Dec 2014 11:15:22 -0800 (PST) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 5626463D9; Tue, 2 Dec 2014 11:15:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=AYnUGf1jcfOmGz9MCOp8vI7X8Wo=; b=V/BT9WR0hv0JXTGtU1 asH6ZGREI3E7FyfAEvulDplWAMXj7ZueuAc2cIi0OZvVboB8rEqawaWRpDpAP0OQ jWX0Fm8if0rK/B5/EbshtQhuXwknTouvQ+4BNJNaM4YzxqNS3mhzHjZSLCyQL/yP GvOIKAYCIGLDzcGss3dMRW2vE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=mxOOC05kfb6/nDJVlMossigYAHvoJcSXNjAW2ZBWRzUROzJC80t 6PrF44rI4+JfGwkowtLem8A2XA9Dg6yb7QzfLigi1EnpNJxEfBz1YNsF5twBtEHc QgHa3OM35HzL9O/O7IeqfdpSutXoKY0E66hHY7Ztt4Tql+rhaH/Ge38g= Received: from gomlefisk.localdomain (unknown [195.159.234.46]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 1136163A8; Tue, 2 Dec 2014 11:15:21 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gomlefisk.localdomain (Postfix) with ESMTP id CC46139F451A; Tue, 2 Dec 2014 20:15:16 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ole Troan In-Reply-To: Date: Tue, 2 Dec 2014 20:15:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/nuIaz-nqqhpgd5_u4ezGu0sG7U0 Cc: v6ops@ietf.org, Keith Moore Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 02 Dec 2014 19:15:25 -0000 >> If there was actually a bar BOF on a 6to4 replacement, would someone = care to summarize? >=20 > There was no actual bar BoF. >=20 > However, I did talk to a number of people individually about this. I'd = say about half of them felt that working on tunnels and/or working on "a = 6to4 replacement" was not a good idea. I couldn't tease out whether that = was an understandable immediate reaction or also a more considered = opinion, and it was also hard to determine whether people mostly = objected to the 6to4 part or to any work on tunnels in general. >=20 > I explained my proposal to a number of people: >=20 > "Something that is as easy to use as 6to4 but as reliable as a tunnel = broker tunnel" >=20 > The short version: >=20 > - NO ANYCASTING, NO ROUTE OPTIMIZATION > - give home gateways a unique login out of the box, such as = @ > - user can override this with @ or @ > - home gateways connect to servers indicated by the domain part of the = login (through SRV records) and state their capabilities > - the server matches their IPv4 address, NAT/CGN status and = capabilities with available tunnel options such as brokers, 6rd, public = gateways, sends back configuration info > - (ISPs would have to publish their gateway configurations) > - home gateway sets up a tunnel and uses keepalives to make sure it's = up, go back to the server if the tunnel goes down for whatever reason > - all of this can of course also be done by individual hosts >=20 > I got a generally cautiously positive reception from those that gave = me enough time to explain all of this, except that those with skin in = the game of course still prefer their own systems. >=20 > So I guess I have a draft to write. done. RFC5571. cheers, Ole From nobody Tue Dec 2 11:18: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 323B21A6EDA for ; Tue, 2 Dec 2014 11:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 9GjjF63nKjdU for ; Tue, 2 Dec 2014 11:18:27 -0800 (PST) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C141A6FED for ; Tue, 2 Dec 2014 11:17:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sB2JHrUE018729; Tue, 2 Dec 2014 13:17:53 -0600 Received: from XCH-BLV-401.nw.nos.boeing.com (xch-blv-401.nw.nos.boeing.com [130.247.25.18]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sB2JHqCw018700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 2 Dec 2014 13:17:52 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-BLV-401.nw.nos.boeing.com ([169.254.1.10]) with mapi id 14.03.0210.002; Tue, 2 Dec 2014 11:17:51 -0800 From: "Templin, Fred L" To: Iljitsch van Beijnum , Keith Moore Thread-Topic: [v6ops] Report: Bar BoF on a 6to4 replacement Thread-Index: AQHQDmAH0I/jfXJhYUW2sj/c/ybqPJx8qrzw Date: Tue, 2 Dec 2014 19:17:51 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.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/w2x0fqAUbsS7-HL7wzL0R0uqSz8 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 02 Dec 2014 19:18:31 -0000 Hi Iljitsch, Any way you do this, the home gateway needs to be enrolled with the tunnel = service provider. Additionally, it needs security keys that it can use to sign its = messages and get the tunnel service provider to accept them. So, "out of the box" means = first handled by the tunnel service provider and not just straight off the assemb= ly line. About this: > - NO ANYCASTING, NO ROUTE OPTIMIZATION I don't mind "no anycasting", but why "no route optimization"? Route optimi= zation will give better performance and avoid single points of congestion. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Iljitsch van Bei= jnum > Sent: Tuesday, December 02, 2014 10:44 AM > To: Keith Moore > Cc: v6ops@ietf.org > Subject: [v6ops] Report: Bar BoF on a 6to4 replacement >=20 > On 19 Nov 2014, at 19:26, Keith Moore wrote: >=20 > > If there was actually a bar BOF on a 6to4 replacement, would someone ca= re to summarize? >=20 > There was no actual bar BoF. >=20 > However, I did talk to a number of people individually about this. I'd sa= y about half of them felt that working on tunnels and/or > working on "a 6to4 replacement" was not a good idea. I couldn't tease out= whether that was an understandable immediate reaction or > also a more considered opinion, and it was also hard to determine whether= people mostly objected to the 6to4 part or to any work on > tunnels in general. >=20 > I explained my proposal to a number of people: >=20 > "Something that is as easy to use as 6to4 but as reliable as a tunnel bro= ker tunnel" >=20 > The short version: >=20 > - NO ANYCASTING, NO ROUTE OPTIMIZATION > - give home gateways a unique login out of the box, such as @= > - user can override this with @ or @ > - home gateways connect to servers indicated by the domain part of the lo= gin (through SRV records) and state their capabilities > - the server matches their IPv4 address, NAT/CGN status and capabilities = with available tunnel options such as brokers, 6rd, public > gateways, sends back configuration info > - (ISPs would have to publish their gateway configurations) > - home gateway sets up a tunnel and uses keepalives to make sure it's up,= go back to the server if the tunnel goes down for whatever > reason > - all of this can of course also be done by individual hosts >=20 > I got a generally cautiously positive reception from those that gave me e= nough time to explain all of this, except that those with skin in > the game of course still prefer their own systems. >=20 > So I guess I have a draft to write. >=20 > Iljitsch > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Dec 2 14: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 A18331A7002 for ; Tue, 2 Dec 2014 14:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 u5lEhahU5zxG for ; Tue, 2 Dec 2014 14:06:17 -0800 (PST) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E0B1A8780 for ; Tue, 2 Dec 2014 14:06:17 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id w10so13952873pde.19 for ; Tue, 02 Dec 2014 14:06:17 -0800 (PST) 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=C5zq9safaV2G9HaFMHdTkmp7b/1O5/xztCRPy2KwhM4=; b=PutukXt3wtK9CxDCEAsvDh/Q73g2uuVijif4oHPIVcX39w46Fs33nsjgiUwFaXVmdx ksiaQ1dWfLiM/MJ1tX2vQJdGpy2gAYCTm9lnw9CComeBsGC7WeWwY9jeHf8Z6EQG01hZ D/7IK8YeiwjBV+r8o8Y3Jk2n2sTRkwtCxPLgoUpX3LSqhgmHFODkcIp1zwxmRRcnoVCT akzDD8T4phF8gMiO48+Oa/X0OrS3v63FUvmrVDAP6czl5wvMSDR9qG615keYA/36cdyW hArmJ5lEtVb6OUVyf17l4eTRz0a3d+B1UDvyybQC3wDUM+GpG6L3eZQBLOlV+LFc94SZ EKRA== X-Gm-Message-State: ALoCoQmojhN2OPIGgfua7nKZiuZkIVpjzogJGBaSkg3W6b3LmGjQAb2HkezJqzf6XYjp5Ly1sMGH MIME-Version: 1.0 X-Received: by 10.70.89.207 with SMTP id bq15mr2803718pdb.68.1417557976988; Tue, 02 Dec 2014 14:06:16 -0800 (PST) Received: by 10.70.34.145 with HTTP; Tue, 2 Dec 2014 14:06:16 -0800 (PST) X-Originating-IP: [2001:dc0:a000:4:68a1:27e9:5cf4:6220] In-Reply-To: References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <93034721-BA1A-45C5-A3F5-0838DE3DB3FE@delong.com> Date: Wed, 3 Dec 2014 08:06:16 +1000 Message-ID: From: George Michaelson To: John Mann Content-Type: multipart/alternative; boundary=e89a8ff1c008aad3cf050942ef2c Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/A94N7kuvdfpMcYW-9xq7nqw2wXA Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? 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, 02 Dec 2014 22:06:21 -0000 --e89a8ff1c008aad3cf050942ef2c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable And.. we just lost SEA-ME-WE3. So there is no direct to SG and there won't be for > 2mo judging by the last delay (Indon doesn't like cable ships operating without a licence) HK? Its reached via Japan. Japan? its reached via Hawaii, Guam, or LA. So these apparent optimal routes by ASN, are sometimes significantly less optimal. I stand by my words: Tunnels are a mechanism which foist unexpected RTT outcomes. -G On Tue, Dec 2, 2014 at 10:34 PM, John Mann wrote: > Hi, > > On 2 December 2014 at 07:42, Owen DeLong wrote: > >> >> On Nov 13, 2014, at 11:59 AM, George Michaelson wrote= : >> >> HE.net tunnels cause severe distortion of RTT. They are anything but >> local termination for much of the world, and whilst I applaud their role= in >> promoting V6 adoption, its a poor fit to the money flow of IPv4 >> relationships for many people. I should know: I have one in Australia, a= nd >> my nearest terminations are SG/HK (which is via the US and trombones) or >> the US (which is 200+ms delay from me) >> >> >> Why would SG/HK be via the US from AU? That sounds like your provider ha= s >> failed to provide decent connectivity to Asia more than an issue related >> directly to tunnelbroker. >> > > Out of interest, I took a look ... > > Taking an example, looking at > https://tunnelbroker.net/status.php > we see a tunnel endpoint at > tserv19.hkg1 =3D=3D 216.218.221.2 > > Also, Monash University is AS56132; we get most of our Internet from > AARNet AS7575. > > Looking at > http://lg.aarnet.edu.au/cgi-bin/lg > 'show bgp ipv4 216.218.221.2' =3D> 216.218.221.0/24 advertised by AS 69= 69 > 'trace 216.218.221.2' goes via nsw, pao, lax, tyo, hkg > And also > http://bgp.he.net/AS56132#_graph4 > shows AS56132 -> AS7575 -> AS6939 > and also AS7575 -> AS10026 -> AS6939 > > So, the problem seems to be that AARNet directly peers with HE at PAO > and doesn't peer with HE at any other IX (or if it does, that peering is > not preferred). > AARNet _could_ also directly peer with HE in Singapore > http://he.net/HurricaneElectricNetworkMap.pdf > > https://www.aarnet.edu.au/images/uploads/resources/International_Map_May_= 2014.pdf > but care would need to be taken when choosing between the 5 Gbit/s > Australia<->Singapore path v. the 120 Gbit/s Sydney<->USA path > > Looking closer at the traceroute > =3D=3D=3D > lg.aarnet.edu.au> traceroute 216.218.221.2 > traceroute to 216.218.221.2 (216.218.221.2), 30 hops max, 40 byte packets > 1 ge-1-0-0.bb1.a.syd.aarnet.net.au (202.158.196.129) 0.390 ms 0.369 > ms 0.359 ms > 2 ae9.pe2.brwy.nsw.aarnet.net.au (113.197.15.56) 0.335 ms 0.327 ms > 0.317 ms > 3 ge-4_0_0.bb1.a.pao.aarnet.net.au (202.158.194.177) *155.513* ms > 155.508 ms 155.521 ms > 4 30gigabitethernet2-1.core1.pao1.he.net (198.32.176.20) *252.462* ms > 252.474 ms 252.337 ms > 5 10ge11-6.core1.lax1.he.net (72.52.92.22) 252.252 ms 252.247 ms > 252.236 ms > 6 10ge1-3.core1.lax2.he.net (72.52.92.122) 249.929 ms 249.918 ms > 249.912 ms > 7 10ge3-2.core1.tyo1.he.net (184.105.223.106) 250.008 ms > 10ge6-3.core1.hkg1.he.net (184.105.223.170) 255.574 ms > 10ge3-2.core1.tyo1.he.net (184.105.223.106) 250.006 ms > 8 10ge5-2.core1.hkg1.he.net (184.105.222.106) 256.108 ms 257.475 ms > 257.460 ms > 9 tserv1.hkg1.he.net (216.218.221.2) 250.165 ms * * > =3D=3D=3D > The RTT between hops 3 and 4 increases from 155 ms to 252 ms, even though > both routers claim to be in PAO. > Perhaps the return traffic is taking some non-optimal path. > > Indeed, a traceroute run on http://lg.he.net/ from fmt1, hkgq, sin1 > to 202.158.196.129 (the hop 1 address from above) > has all three traceroutes routing via asianetcom in Singapore, > *and* the RTTs being about the same (254 ms, 250 ms, 252 ms). > > So ... it looks like we have a 250 ms loop for all AARNet <-> HE traffic. > > 97ms > SIN <- PAO > 76ms v ^ 77ms > AUS > > This is a lot slower than about 155 ms for the direct return path > > AUS <-> PAO > > Thanks, > John > > > >> Of course, if you can find native IPv6 in AU, why not set up your own >> tunnelbroker for Aussies or work with one of the existing ones to build = a >> local node? >> >> I cannot speak to SIXX but I suspect it too distorts the packetflow and >> causes a disparate RTT compared to native. >> >> >> Any tunnel or tunnel broker service which involves a detour over a long >> distance will create RTT disparity. If you can get native, then native w= ill >> always be superior to tunnels. Tunnels are intended for circumstances wh= ere >> you can=E2=80=99t get native. >> >> 6rd is homed in your own ISP. its almost 1:1 congruent with your normal >> RTT for native IPv6 endpoints. >> >> >> Sure, and that=E2=80=99s great if your ISP supports 6rd. Again, that=E2= =80=99s not the >> target audience for tunnel brokers. >> >> When we say 'tunnels are bad' its not because GRE randomly corrupts bits= : >> its because the effects on the end-to-end model are bad. The badness >> varies, but the consequence of a tunnel is usually not what you wanted i= n >> reality, unless the sole consideration was connectivity per se, not its >> quality, compared to V4 >> >> >> Actually, when we say =E2=80=9Ctunnels are bad=E2=80=9D, it=E2=80=99s be= cause we like to >> oversimplify and we usually develop some tunnel vision in the process. >> >> I=E2=80=99m running entirely on tunnels for both v4 and v6. They don=E2= =80=99t >> significantly distort my RTTs vs. native and in many cases, I=E2=80=99ve= discovered >> that I get better performance over my tunnels that I could have received >> natively because my tunnels aren=E2=80=99t subject to some of the games = that get >> played to try and manipulate financials between providers to extort >> payments for access to eyeballs. >> >> Tunnels can be good. Tunnels can be bad. They are a tool like any other >> tool in the networking toolkit and knowing how to use the tool properly = can >> greatly improve your user experience with said tool. >> >> Owen >> >> >> -G >> >> On Thu, Nov 13, 2014 at 9:56 AM, Gert Doering wrote: >> >>> Hi, >>> >>> On Thu, Nov 13, 2014 at 09:50:31AM -1000, Iljitsch van Beijnum wrote: >>> > There's no reason tunnels have to be so-so. >>> >>> I'm wondering who would provide these tunnels in the future, and what >>> would >>> their business model be. >>> >>> This is a real question. Today, you can get tunnels from Sixxs nodes >>> (enthusiasts, which might eventually consider the IPv6 deployment issue >>> to be "solved" and stop running tunnel nodes), HE.NET >>> (it's good marketing, >>> but eventually the costs involved might win over the marketing gain?), >>> and others that run tunnels for various reasons that might not be there >>> in 2-3 years... >>> >>> 6rd is a very specific tunnel technology that has answers to that >>> question >>> ("I want to roll out IPv6 to my customers but part of my infrastructure >>> cannot do it. So I provision my CPEs to do 6rd, and take responsibilit= y >>> to run the 6rd relay") - but as with 6to4 relays, what is the incentive >>> to >>> run a tunnel broker in 2-3 years from now? You won't get paid (users d= o >>> not pay for IPv6, otherwise they would go and choose ISPs that provide >>> v6)... >>> >>> 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 >>> >> >> _______________________________________________ >> 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 >> >> > --e89a8ff1c008aad3cf050942ef2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And.. we just lost SEA-ME-WE3. So there is no direct to SG= and there won't be for > 2mo judging by the last delay (Indon doesn= 't like cable ships operating without a licence)

HK?= Its reached via Japan. Japan? its reached via Hawaii, Guam, or LA.=C2=A0

So these apparent optimal routes by ASN, are someti= mes significantly less optimal.

I stand by my word= s: Tunnels are a mechanism which foist unexpected RTT outcomes.
<= br>
-G

On Tue, Dec 2, 2014 at 10:34 PM, John Mann <= ;john.mann@monash= .edu> wrote:
Hi,

On 2 December 2014 at 07:42, Owen DeLong <owen@delong.com><= /span> wrote:

<= div>
On Nov 13, 2014, at 11:59 AM, Geor= ge Michaelson <ggm= @algebras.org> wrote:

HE.net tunnels cause severe distortion of = RTT. They are anything but local termination for much of the world, and whi= lst I applaud their role in promoting V6 adoption, its a poor fit to the mo= ney flow of IPv4 relationships for many people. I should know: I have one i= n Australia, and my nearest terminations are SG/HK (which is via the US and= trombones) or the US (which is 200+ms delay from me)

Why would SG/HK be via the US from AU? That sounds= like your provider has failed to provide decent connectivity to Asia more = than an issue related directly to tunnelbroker.

Out of interest, I took a look ...

Taking an example, looking at
=C2=A0 https://tunnelbroker.net/status.p= hp
we see a tunnel endpoint at
=C2=A0 =C2=A0tserv19.hkg1 =3D=3D 2= 16.218.221.2

Also, Monash University is AS56132; we = get most of our Internet from AARNet AS7575.

Looki= ng at
=C2=A0 '= show bgp ipv4 216.218.221.2' =3D> 216.218.221.0/24 advertised by AS 6969
=C2=A0 'trace 216.218.221.2' goes via nsw, pao,= lax, tyo, hkg
And also
=C2=A0=C2=A0http://bgp.he.net/AS56132#_graph4
=C2=A0 shows AS56132 -> AS7575 -> AS6939
=C2=A0 and also =C2=A0AS7575 -> AS10026 -> AS6939
<= div class=3D"gmail_quote">
So, the prob= lem seems to be that AARNet directly peers with HE at PAO
and doesn't peer with HE at any other IX (or if it doe= s, that peering is not preferred).
AARNet _= could_ also directly peer with HE in Singapore
=C2=A0 =C2=A0http://he.net/HurricaneElectricNetworkMap.pdf
=C2=A0 =C2=A0https://www.aarnet.edu.au/images/uploads/resources/International_Map_Ma= y_2014.pdf
but care would need to be ta= ken when choosing between the 5 Gbit/s Australia<->Singapore path v. = the 120 Gbit/s Sydney<->USA path

=
Looking closer at the traceroute
=3D=3D=3D
lg.aarnet.edu.au> tracerou= te 216.218.221.2
traceroute to 216.218.221.2 (216.218.221.2), 30 hops ma= x, 40 byte packets
=C2=A01 =C2=A0ge-1-0-0.bb1.a.syd.aarnet.net.au (202.15= 8.196.129) =C2=A00.390 ms =C2=A00.369 ms =C2=A00.359 ms
=C2=A02 =C2=A0ae9.pe2.b= rwy.nsw.aarnet.net.au (113.197.15.56) =C2=A00.335 ms =C2=A00.327 ms =C2= =A00.317 ms
=C2=A03 =C2=A0ge-4_0_0.bb1.a.pao.aarnet.net.au (202.158.194.1= 77) =C2=A0155.513 ms =C2=A0155.508 ms =C2=A0155.521 ms
=C2=A04 = =C2=A030gigabitethernet2-1.core1.pao1.he.net (198.32.176.20) =C2=A0= 252.462 ms =C2=A0252.474 ms =C2=A0252.337 ms
=C2=A05 =C2=A010ge11-6.core1.lax= 1.he.net (72.52.92.22) =C2=A0252.252 ms =C2=A0252.247 ms =C2=A0252.236 = ms
=C2=A06 =C2=A010ge1-3.core1.lax2.he.net (72.52.92.122) =C2=A0249.929 ms =C2= =A0249.918 ms =C2=A0249.912 ms
=C2=A07 =C2=A010ge3-2.core1.tyo1.he.net (184.105.= 223.106) =C2=A0250.008 ms 10ge6-3.core1.hkg1.he.net (184.105.223.170) =C2=A0255.574= ms 10ge3-2.= core1.tyo1.he.net (184.105.223.106) =C2=A0250.006 ms
=C2=A08 =C2=A0<= a href=3D"http://10ge5-2.core1.hkg1.he.net" target=3D"_blank">10ge5-2.core1= .hkg1.he.net (184.105.222.106) =C2=A0256.108 ms =C2=A0257.475 ms =C2=A0= 257.460 ms
=C2=A09 =C2=A0tserv1.hkg1.he.net (216.218.221.2) =C2=A0250.165 ms * *
=3D= =3D=3D
The RTT between hops 3 and 4 increases from 155 ms to 25= 2 ms, even though both routers claim to be in PAO.
Perhaps the return t= raffic is taking some non-optimal path.

Indeed, a traceroute run on =C2= =A0http://lg.he.net/ = =C2=A0from=C2=A0fmt1, hkgq, sin1
to =C2=A0202.158.196.129= =C2=A0(the hop 1 address from above)=C2=A0
has all three traceroutes routing via asianetcom i= n Singapore, =C2=A0
*and* the RTTs being ab= out the same (254 ms, 250 ms, 252 ms).

=
So ... it looks like we have a 250 ms loop= for all AARNet <-> HE traffic.

<= /div>
=C2=A0 =C2=A0 =C2= =A0 =C2=A097ms
=C2=A0 =C2=A0SIN =C2=A0<- =C2=A0PAO
76ms v =C2=A0 =C2=A0 ^ =C2=A07= 7ms=C2=A0
= =C2=A0 =C2=A0 =C2=A0 =C2=A0AUS

This is a lot slower than about 155 ms= for the direct return path

=C2=A0 =C2=A0 =C2=A0AUS <->= PAO

Thanks,
=C2=A0 =C2=A0 John

=C2=A0
Of course, if you can= find native IPv6 in AU, why not set up your own tunnelbroker for Aussies o= r work with one of the existing ones to build a local node?

I cannot speak to SIXX= but I suspect it too distorts the packetflow and causes a disparate RTT co= mpared to native.

Any tunnel = or tunnel broker service which involves a detour over a long distance will = create RTT disparity. If you can get native, then native will always be sup= erior to tunnels. Tunnels are intended for circumstances where you can=E2= =80=99t get native.

6rd is homed in your own ISP. its almost 1:1 congruent with y= our normal RTT for native IPv6 endpoints.

=
Sure, and that=E2=80=99s great if your ISP supports 6rd. Again= , that=E2=80=99s not the target audience for tunnel brokers.

When we say 'tunn= els are bad' its not because GRE randomly corrupts bits: its because th= e effects on the end-to-end model are bad. The badness varies, but the cons= equence of a tunnel is usually not what you wanted in reality, unless the s= ole consideration was connectivity per se, not its quality, compared to V4<= /div>

Actually, when we say =E2=80= =9Ctunnels are bad=E2=80=9D, it=E2=80=99s because we like to oversimplify a= nd we usually develop some tunnel vision in the process.

I=E2=80=99m running entirely on tunnels for both v4 and v6. They don= =E2=80=99t significantly distort my RTTs vs. native and in many cases, I=E2= =80=99ve discovered that I get better performance over my tunnels that I co= uld have received natively because my tunnels aren=E2=80=99t subject to som= e of the games that get played to try and manipulate financials between pro= viders to extort payments for access to eyeballs.

= Tunnels can be good. Tunnels can be bad. They are a tool like any other too= l in the networking toolkit and knowing how to use the tool properly can gr= eatly improve your user experience with said tool.

Owen

-G

On Thu, Nov 13= , 2014 at 9:56 AM, Gert Doering <gert@space.net> wrote:
Hi,

On Thu, Nov 13, 2014 at 09:50:31AM -1000, Iljitsch van Beijnum wrote:
> There's no reason tunnels have to be so-so.

I'm wondering who would provide these tunnels in the future, and= what would
their business model be.

This is a real question.=C2=A0 Today, you can get tunnels from Sixxs nodes<= br> (enthusiasts, which might eventually consider the IPv6 deployment issue
to be "solved" and stop running tunnel nodes), HE.NET (it's good marketing,
but eventually the costs involved might win over the marketing gain?),
and others that run tunnels for various reasons that might not be there
in 2-3 years...

6rd is a very specific tunnel technology that has answers to that question<= br> ("I want to roll out IPv6 to my customers but part of my infrastructur= e
cannot do it.=C2=A0 So I provision my CPEs to do 6rd, and take responsibili= ty
to run the 6rd relay") - but as with 6to4 relays, what is the incentiv= e to
run a tunnel broker in 2-3 years from now?=C2=A0 You won't get paid (us= ers do
not pay for IPv6, otherwise they would go and choose ISPs that provide
v6)...

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

SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo= rs.: A. Grundner-Culemann
D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0USt-IdNr.: DE813185279

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

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


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



--e89a8ff1c008aad3cf050942ef2c-- From nobody Tue Dec 2 15:18: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 49D731A6FDB for ; Tue, 2 Dec 2014 15:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, 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 ua8YClqGRC40 for ; Tue, 2 Dec 2014 15:18:14 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5156E1A701F for ; Tue, 2 Dec 2014 15:18:14 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hl2so17148165igb.4 for ; Tue, 02 Dec 2014 15:18:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8DX3YJakoqkIjoezbvK8EGpQcuSMVXaCgM/Meu4f9CI=; b=XUdpTyc9KVMX8U6Ib0czxjeIcc0d5eRVoGsiKl4RzWMUlVqhDDRdZ/JexY7jjjqoZZ 2G+ryLjNjZk/ZdwzoPb8vnlZc5udA+CLuErpftOlDrFo1dA/wIK+yBZ/sLNNX6EheCSc wBOiZ2pfO0W0D2jUxugWBz0Q5iZmtzchg6cxIrATohSTYkSrvvZIHsRWquZTBjd4gDxP MMuPUYgxFDKjbntBSh8q6wnz6DtWMPMwSkcNBZwLX4fsV/oEAcWEk06eypM1VbG2xJnv 895TGSG2FTOIkxKhBwO8oZEfpZnrNCkkmKj97u6THxYlb3yrU1j1CSI5jOAsYfC1Laid BK6g== MIME-Version: 1.0 X-Received: by 10.50.117.71 with SMTP id kc7mr5764254igb.35.1417562293357; Tue, 02 Dec 2014 15:18:13 -0800 (PST) Received: by 10.107.131.141 with HTTP; Tue, 2 Dec 2014 15:18:13 -0800 (PST) In-Reply-To: References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <93034721-BA1A-45C5-A3F5-0838DE3DB3FE@delong.com> Date: Wed, 3 Dec 2014 00:18:13 +0100 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: George Michaelson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/IgUZTZqRsxa8PKqE_4ZSGNKGsUI Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? 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, 02 Dec 2014 23:18:18 -0000 On 12/2/14, George Michaelson wrote: > And.. we just lost SEA-ME-WE3. So there is no direct to SG and there won'= t > be for > 2mo judging by the last delay (Indon doesn't like cable ships > operating without a licence) > > HK? Its reached via Japan. Japan? its reached via Hawaii, Guam, or LA. > > So these apparent optimal routes by ASN, are sometimes significantly less > optimal. > > I stand by my words: Tunnels are a mechanism which foist unexpected RTT > outcomes. The RTT to my colo server in Germany is 10ms *less* over IPv6 HE tunnel than over the native IPv4 that tunnel runs over. So it looks like we got the opposite ends of the straw. Which confirms your words, somewhat, I guess, but not in the always negative direction :-) --a > > -G > > On Tue, Dec 2, 2014 at 10:34 PM, John Mann wrote: > >> Hi, >> >> On 2 December 2014 at 07:42, Owen DeLong wrote: >> >>> >>> On Nov 13, 2014, at 11:59 AM, George Michaelson >>> wrote: >>> >>> HE.net tunnels cause severe distortion of RTT. They are anything but >>> local termination for much of the world, and whilst I applaud their rol= e >>> in >>> promoting V6 adoption, its a poor fit to the money flow of IPv4 >>> relationships for many people. I should know: I have one in Australia, >>> and >>> my nearest terminations are SG/HK (which is via the US and trombones) o= r >>> the US (which is 200+ms delay from me) >>> >>> >>> Why would SG/HK be via the US from AU? That sounds like your provider >>> has >>> failed to provide decent connectivity to Asia more than an issue relate= d >>> directly to tunnelbroker. >>> >> >> Out of interest, I took a look ... >> >> Taking an example, looking at >> https://tunnelbroker.net/status.php >> we see a tunnel endpoint at >> tserv19.hkg1 =3D=3D 216.218.221.2 >> >> Also, Monash University is AS56132; we get most of our Internet from >> AARNet AS7575. >> >> Looking at >> http://lg.aarnet.edu.au/cgi-bin/lg >> 'show bgp ipv4 216.218.221.2' =3D> 216.218.221.0/24 advertised by AS 6= 969 >> 'trace 216.218.221.2' goes via nsw, pao, lax, tyo, hkg >> And also >> http://bgp.he.net/AS56132#_graph4 >> shows AS56132 -> AS7575 -> AS6939 >> and also AS7575 -> AS10026 -> AS6939 >> >> So, the problem seems to be that AARNet directly peers with HE at PAO >> and doesn't peer with HE at any other IX (or if it does, that peering is >> not preferred). >> AARNet _could_ also directly peer with HE in Singapore >> http://he.net/HurricaneElectricNetworkMap.pdf >> >> https://www.aarnet.edu.au/images/uploads/resources/International_Map_May= _2014.pdf >> but care would need to be taken when choosing between the 5 Gbit/s >> Australia<->Singapore path v. the 120 Gbit/s Sydney<->USA path >> >> Looking closer at the traceroute >> =3D=3D=3D >> lg.aarnet.edu.au> traceroute 216.218.221.2 >> traceroute to 216.218.221.2 (216.218.221.2), 30 hops max, 40 byte packet= s >> 1 ge-1-0-0.bb1.a.syd.aarnet.net.au (202.158.196.129) 0.390 ms 0.369 >> ms 0.359 ms >> 2 ae9.pe2.brwy.nsw.aarnet.net.au (113.197.15.56) 0.335 ms 0.327 ms >> 0.317 ms >> 3 ge-4_0_0.bb1.a.pao.aarnet.net.au (202.158.194.177) *155.513* ms >> 155.508 ms 155.521 ms >> 4 30gigabitethernet2-1.core1.pao1.he.net (198.32.176.20) *252.462* ms >> 252.474 ms 252.337 ms >> 5 10ge11-6.core1.lax1.he.net (72.52.92.22) 252.252 ms 252.247 ms >> 252.236 ms >> 6 10ge1-3.core1.lax2.he.net (72.52.92.122) 249.929 ms 249.918 ms >> 249.912 ms >> 7 10ge3-2.core1.tyo1.he.net (184.105.223.106) 250.008 ms >> 10ge6-3.core1.hkg1.he.net (184.105.223.170) 255.574 ms >> 10ge3-2.core1.tyo1.he.net (184.105.223.106) 250.006 ms >> 8 10ge5-2.core1.hkg1.he.net (184.105.222.106) 256.108 ms 257.475 ms >> 257.460 ms >> 9 tserv1.hkg1.he.net (216.218.221.2) 250.165 ms * * >> =3D=3D=3D >> The RTT between hops 3 and 4 increases from 155 ms to 252 ms, even thoug= h >> both routers claim to be in PAO. >> Perhaps the return traffic is taking some non-optimal path. >> >> Indeed, a traceroute run on http://lg.he.net/ from fmt1, hkgq, sin1 >> to 202.158.196.129 (the hop 1 address from above) >> has all three traceroutes routing via asianetcom in Singapore, >> *and* the RTTs being about the same (254 ms, 250 ms, 252 ms). >> >> So ... it looks like we have a 250 ms loop for all AARNet <-> HE traffic= . >> >> 97ms >> SIN <- PAO >> 76ms v ^ 77ms >> AUS >> >> This is a lot slower than about 155 ms for the direct return path >> >> AUS <-> PAO >> >> Thanks, >> John >> >> >> >>> Of course, if you can find native IPv6 in AU, why not set up your own >>> tunnelbroker for Aussies or work with one of the existing ones to build >>> a >>> local node? >>> >>> I cannot speak to SIXX but I suspect it too distorts the packetflow and >>> causes a disparate RTT compared to native. >>> >>> >>> Any tunnel or tunnel broker service which involves a detour over a long >>> distance will create RTT disparity. If you can get native, then native >>> will >>> always be superior to tunnels. Tunnels are intended for circumstances >>> where >>> you can=E2=80=99t get native. >>> >>> 6rd is homed in your own ISP. its almost 1:1 congruent with your normal >>> RTT for native IPv6 endpoints. >>> >>> >>> Sure, and that=E2=80=99s great if your ISP supports 6rd. Again, that=E2= =80=99s not the >>> target audience for tunnel brokers. >>> >>> When we say 'tunnels are bad' its not because GRE randomly corrupts >>> bits: >>> its because the effects on the end-to-end model are bad. The badness >>> varies, but the consequence of a tunnel is usually not what you wanted >>> in >>> reality, unless the sole consideration was connectivity per se, not its >>> quality, compared to V4 >>> >>> >>> Actually, when we say =E2=80=9Ctunnels are bad=E2=80=9D, it=E2=80=99s b= ecause we like to >>> oversimplify and we usually develop some tunnel vision in the process. >>> >>> I=E2=80=99m running entirely on tunnels for both v4 and v6. They don=E2= =80=99t >>> significantly distort my RTTs vs. native and in many cases, I=E2=80=99v= e >>> discovered >>> that I get better performance over my tunnels that I could have receive= d >>> natively because my tunnels aren=E2=80=99t subject to some of the games= that get >>> played to try and manipulate financials between providers to extort >>> payments for access to eyeballs. >>> >>> Tunnels can be good. Tunnels can be bad. They are a tool like any other >>> tool in the networking toolkit and knowing how to use the tool properly >>> can >>> greatly improve your user experience with said tool. >>> >>> Owen >>> >>> >>> -G >>> >>> On Thu, Nov 13, 2014 at 9:56 AM, Gert Doering wrote: >>> >>>> Hi, >>>> >>>> On Thu, Nov 13, 2014 at 09:50:31AM -1000, Iljitsch van Beijnum wrote: >>>> > There's no reason tunnels have to be so-so. >>>> >>>> I'm wondering who would provide these tunnels in the future, and what >>>> would >>>> their business model be. >>>> >>>> This is a real question. Today, you can get tunnels from Sixxs nodes >>>> (enthusiasts, which might eventually consider the IPv6 deployment issu= e >>>> to be "solved" and stop running tunnel nodes), HE.NET >>>> (it's good marketing, >>>> but eventually the costs involved might win over the marketing gain?), >>>> and others that run tunnels for various reasons that might not be ther= e >>>> in 2-3 years... >>>> >>>> 6rd is a very specific tunnel technology that has answers to that >>>> question >>>> ("I want to roll out IPv6 to my customers but part of my infrastructur= e >>>> cannot do it. So I provision my CPEs to do 6rd, and take >>>> responsibility >>>> to run the 6rd relay") - but as with 6to4 relays, what is the incentiv= e >>>> to >>>> run a tunnel broker in 2-3 years from now? You won't get paid (users >>>> do >>>> not pay for IPv6, otherwise they would go and choose ISPs that provide >>>> v6)... >>>> >>>> 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 >>>> >>> >>> _______________________________________________ >>> 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 Dec 3 00:11: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 ABFE71A00F9 for ; Wed, 3 Dec 2014 00:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 pNteaQWu9eDj for ; Wed, 3 Dec 2014 00:11:27 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C6831A00F0 for ; Wed, 3 Dec 2014 00:11:27 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 3915E10054675; Wed, 3 Dec 2014 08:11:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417594283; bh=O617QBKbTis8uOXqXge4ZSTZt/o35GXxV0C38iJYUio=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=CBYnRwAzd4NHXksam5xhcyl1jMgple820KHzEiiHz13XnDK7E3nmxywUO6ZMLMjHa KBWAsRpboOW/8q6e+ZjuPsIciq3zyoyoSVaSV1IJiIs8UDeWQLNqIdT+nfjIMFjMCY uwNQ3MA2SI5bsUzfLueAgKSsIlgcNJkGniCS77+/E/U0UwdZqHFwBIdjI/Q0syrVkk AVqL1mlFgOePLZEGPjpbvywl0seDGh8Zjbk3Nv4R8wllaQtygC/i0u8Ub8p9WLEBNX pd/XRg9p5ZmQ8BHfTnleyj4uC0h0VaQQj9JWB7wQFEeVZ5KBx8VHMOBb0xP5PGMdgZ Mwl4OqA/4/Nww== Message-ID: <547EC5A9.8010603@massar.ch> Date: Wed, 03 Dec 2014 09:11:21 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: John Mann References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <93034721-BA1A-45C5-A3F5-0838DE3DB3FE@delong.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/a9GLbSMoogmYUPzKkk_ZubKQj_Y Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? 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, 03 Dec 2014 08:11:36 -0000 On 2014-12-02 13:34, John Mann wrote: [..] > Also, Monash University is AS56132; we get most of our Internet from > AARNet AS7575. Congrats, you have access to an ISP who has been providing native IPv6 for many many years (likely a decade at least). Please use the native connectivity :) Greets, Jeroen From nobody Wed Dec 3 02: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 52FD41A0461 for ; Wed, 3 Dec 2014 02:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 JIHsEUw1diyr for ; Wed, 3 Dec 2014 02:11:57 -0800 (PST) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E67641A01FA for ; Wed, 3 Dec 2014 02:11:56 -0800 (PST) Received: from mail-qa0-f48.google.com ([209.85.216.48]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKVH7h7JE/egHIU1GKNXfY4jLDj3eMsVPA@postini.com; Wed, 03 Dec 2014 02:11:57 PST Received: by mail-qa0-f48.google.com with SMTP id v10so10114156qac.21 for ; Wed, 03 Dec 2014 02:11:56 -0800 (PST) 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=gqLd4X2Qh6i/OGair7HS6gmDfBEi9tj5o1L1/o3613U=; b=Wuls5y8E0QeQNyCpWpaT4a7rbWoqO51GswQMsZM644YAfHmT8IMAY01wUfSZN+P384 e+y0ler4EAjRHxcjL8LIWl7ZiQnCkepPshoC7UlyGOT/GwKRS/yJ3/0YEdL3KejSzRLL N4p4Hf4EThw3mIFtXF3EomMQy372/qKiPcT1sJqg0AS63fNrgnLYiQBlPQ288s/TgGe2 o/zAhpHYkXSHB0M9lw2XySF/H3q32W3BDaGYwywtYIDo39g1X/a/OAk+lYwAXLsQci2n TGDyZEp+RS7XbKI8MHkFwtta9A3rMnr2JLv//1XRqCNmKAph6yDJgkUr7fHXU1aGz3lg JS1g== X-Gm-Message-State: ALoCoQlO/lBxvNFJ8q+fXJVnaIYfGUFPz5exWwDpRv6PU8JSpBK6wAmVtl8lKq5QjojR9aBVLG1Sn8OzCCyk9mYhgO1Ns4cYZqdQ8cAy28aRk2cBHk1hbvL0GJqBYvZAP66ak8l+qDUC X-Received: by 10.229.249.68 with SMTP id mj4mr6710914qcb.23.1417601516092; Wed, 03 Dec 2014 02:11:56 -0800 (PST) X-Received: by 10.229.249.68 with SMTP id mj4mr6710903qcb.23.1417601515949; Wed, 03 Dec 2014 02:11:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.97.136 with HTTP; Wed, 3 Dec 2014 02:11:34 -0800 (PST) In-Reply-To: <547EC5A9.8010603@massar.ch> References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <93034721-BA1A-45C5-A3F5-0838DE3DB3FE@delong.com> <547EC5A9.8010603@massar.ch> From: John Mann Date: Wed, 3 Dec 2014 21:11:34 +1100 Message-ID: To: Jeroen Massar Content-Type: multipart/alternative; boundary=001a1133525ccaa89905094d1277 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/V1BuqPYSyEyd6dAPrUjAdyE3pZc Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? 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, 03 Dec 2014 10:11:59 -0000 --001a1133525ccaa89905094d1277 Content-Type: text/plain; charset=UTF-8 Jeroen, On 3 December 2014 at 19:11, Jeroen Massar wrote: > On 2014-12-02 13:34, John Mann wrote: > [..] > > Also, Monash University is AS56132; we get most of our Internet from > > AARNet AS7575. > > Congrats, you have access to an ISP who has been providing native IPv6 > for many many years (likely a decade at least). > > Please use the native connectivity :) > I do use native IPv6 connectivity. WIthin Australia ... see http://labs.apnic.net/ipv6-measurement/Economies/AU click "ASN in this Economy" tab --- (edited) ASN AS Name #samples v6-capable v6-preferred 56132 Monash University 250 63.60% 58.80% 4739 Internode Pty Ltd 3924 6.27% 6.14% ... --- Monash (rank #1) is my work Internet provider, and Internode (rank #2) is my home ISP. The question I was investigating was why a HE tunnel in SG/HK isn't useful to Australians [who don't use an IPv6-capable ISP]. === Back on topic: Monash's "Anycast 6to4 fail moment" was in 2007 or 2008. Non-SOE Windows Vista laptops with ICS enabled were advertising 6to4-derived routes to Mac OSX 10.4 machines and breaking their connectivity to IPv6 sites. We fixed that using a RA-filter on all user network ports. After dual-stack IPv6 was enabled on most subnets, protocol 41 and Teredo were blocked at Monash's Internet border on 15-Jun-2011. I don't recall anyone ever asking for it to be re-enabled. I assert that the time of "experimental" IPv6 has passed. IPv6 should be a "production" service. If the IPv6 network service isn't almost as good (due to reliability or RTTs or whatever) as IPv4, turn it off until you can do it right. Thanks, John --001a1133525ccaa89905094d1277 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jeroen,


On 3 December 2014 at 19:11, Jeroen Massar= <jeroen@massar.ch> wrote:
On 2014-12-02 = 13:34, John Mann wrote:
[..]
> Also, Monash University is AS56132; we get most of ou= r Internet from
> AARNet AS7575.

Congrats, you have access to an ISP who has been providing native IP= v6
for many many years (likely a decade at least).

Please use the native connectivity :)

I= do use native IPv6 connectivity.

WIthin Australia= ... see=C2=A0
=C2=A0 =C2=A0 =C2=A0click =C2=A0 "ASN in this Econom= y" tab
--- (edited)
ASN =C2=A0 A= S Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 #samples=E2=80=83v6-capable=E2=80= =83v6-preferred=E2=80=83
56132 Monash University =C2=A0 250 =C2=A0 =C2= =A0 63.60% =C2=A0 =C2=A0 58.80%
=C2=A04739 Internode Pty Ltd =C2=A03924 = =C2=A0 =C2=A0 =C2=A06.27% =C2=A0 =C2=A0 =C2=A06.14%
...
---
Monash (rank #1) is my work Internet provider, and Internode (rank #2) i= s my home ISP.

The question I was investigating was why a HE tunnel in SG/HK isn&= #39;t useful to Australians [who don't use an IPv6-capable ISP].
<= div class=3D"gmail_extra">
=3D=3D=3D

Back on = topic: =C2=A0Monash's "Anycast 6to4 fail moment" was in 2007 = or 2008.
Non-SOE Windows Vista laptops with= ICS enabled were advertising 6to4-derived routes to Mac OSX 10.4 machines<= /div>
and breaking their connectivity to IPv6 sit= es.=C2=A0 We fixed that using a RA-filter on all user network ports.
<= div class=3D"gmail_extra">
After dual-stack IPv6 was enabled on mo= st subnets, protocol 41 and Teredo were blocked at Monash's Internet bo= rder=C2=A0on 15-Jun-2011.=C2=A0 I don't recall anyone ever asking for i= t to be re-enabled.

I assert that the time of "experimental" IPv6 has p= assed.=C2=A0 IPv6 should be a "production" service.
If the IPv6 network service isn't almost as good (du= e to reliability or RTTs or whatever) as IPv4,
turn it off until you can do it right.
Thanks,
= =C2=A0 =C2=A0 John
--001a1133525ccaa89905094d1277-- From nobody Wed Dec 3 02:54: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 2D22B1A0461 for ; Wed, 3 Dec 2014 02:54:19 -0800 (PST) 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 F1Xg2MfmZRHP for ; Wed, 3 Dec 2014 02:54:10 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::706]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5821A1A3E for ; Wed, 3 Dec 2014 02:54:07 -0800 (PST) Received: from pc6 (86.184.62.161) by DB3PR07MB058.eurprd07.prod.outlook.com (10.242.137.148) with Microsoft SMTP Server (TLS) id 15.1.26.15; Wed, 3 Dec 2014 10:53:43 +0000 Message-ID: <02d801d00ee7$6b811400$4001a8c0@gateway.2wire.net> From: t.petch To: Joe Touch , Tom Taylor References: <546E43C2.9010400@gmail.com> <546E48EB.5080405@isi.edu> <546E5E60.8000601@gmail.com> <546E6D16.9000909@isi.edu> <546E77FA.8080308@isi.edu> <24FB648F-B953-4D38-8C3A-7A61349F1DE6@delong.com> <547D299E.9050403@gmail.com> <6AACEEC7-ECBB-407E-A359-55DDA53C50F0@isi.edu> Date: Wed, 3 Dec 2014 10:48:08 +0000 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: [86.184.62.161] X-ClientProxiedBy: AM3PR01CA051.eurprd01.prod.exchangelabs.com (10.141.191.41) To DB3PR07MB058.eurprd07.prod.outlook.com (10.242.137.148) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB058; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB058; X-Forefront-PRVS: 0414DF926F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(51704005)(24454002)(13464003)(189002)(44736004)(66066001)(120916001)(99396003)(116806002)(46102003)(93886004)(62236002)(87286001)(47776003)(122386002)(97736003)(86362001)(20776003)(89996001)(64706001)(1556002)(93916002)(44716002)(19580395003)(15975445006)(84392001)(40100003)(2171001)(31966008)(87976001)(92726001)(88136002)(19580405001)(92566001)(62966003)(105586002)(77156002)(33646002)(50466002)(106356001)(95666004)(104166001)(21056001)(14496001)(107046002)(81816999)(81686999)(76176999)(61296003)(101416001)(23756003)(42186005)(50986999)(4396001)(50226001)(68736005)(77096005)(102836001)(1456002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB058; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB058; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/JKzAadOSQk2uvNlRa5kaTl9xeHI Cc: IPv6 Operations , "Phillip Remaker \(remaker\)" Subject: Re: [v6ops] On IPv6 address part naming 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, 03 Dec 2014 10:54:20 -0000 ----- Original Message ----- From: "Joe Touch" To: "Tom Taylor" Cc: "Phillip Remaker (remaker)" ; "IPv6 Operations" Sent: Tuesday, December 02, 2014 3:31 AM > > > On Dec 1, 2014, at 6:53 PM, Tom Taylor wrote: > > > > I can't resist adding a touch of history. The term "byte" was introduced with the IBM /360, > > It was coined during the design of the IBM Stretch, by Buchholtz, prior to the /360. > > Byte meant 8 bits until that got mixed up with parity memory sizes. Is has meant 8 bits got more then long enough at this point to be unambiguous. I was a resident technical expert working for a rival organisation in the 1970s which was about to switch from 6 bit storage to 8 bit storage and their market research heard that IBM was about to introduce the concept of the 9 bit byte so I was asked to evaluate what the implications might be. The best I could come up with was a parity bit, but since Hamming codes were all the rage, that seemed a bit limp; it stays in my mind as an unresolved question. Tom Petch > Joe > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Dec 3 03:18: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 983B51A1A54 for ; Wed, 3 Dec 2014 03:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7] 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 itlgo1ltsE_b for ; Wed, 3 Dec 2014 03:18:36 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 755521A1A43 for ; Wed, 3 Dec 2014 03:18:27 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 5B4AF10054675; Wed, 3 Dec 2014 11:18:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417605503; bh=x9wPiNpc6Phi/MaC60P8izBjXZ3uFQdp9ZxEAcVC170=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=lxBktG5oDtRR+GfOVaBJngWArWWRmvo/JPOmdp8tFafecUttJ4728XSskVAkd3F4t 8CukHFyoTnWUbGAoUk7UmhDsaKyDUpQTzBlf/abkLjFbXePFTIs1LS795AwCNoeoO8 0mKokEnv8Z3KF3XWSJhme5dOccf5dxoa2aZ7FFdAb4Vq6nZyaPcliPK8Xlf8vUMrKR mlY6cLSOme0CifaQvWfQVVMKhZjZTSkKY14JZMwpnbVb21Rdeoi3ytqnjNf7J20x27 nByVkxXHasnPGiOG2vWhtpDC+AfatgDpP3JZXgdN50e99ONFFSwHRKCOJl7OlSqfw+ ye8LqFDBhZAUA== Message-ID: <547EF17C.80304@massar.ch> Date: Wed, 03 Dec 2014 12:18:20 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: John Mann References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <93034721-BA1A-45C5-A3F5-0838DE3DB3FE@delong.com> <547EC5A9.8010603@massar.ch> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/MhBfJBR4ttGiZhLARTDLV00O9Iw Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? 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, 03 Dec 2014 11:18:44 -0000 On 2014-12-03 11:11, John Mann wrote: [..] > The question I was investigating was why a HE tunnel in SG/HK isn't > useful to Australians [who don't use an IPv6-capable ISP]. Then doing so from the network they would be using would be a better way to do so as every ISP has their own routing policies... [..] > I assert that the time of "experimental" IPv6 has passed. IPv6 should > be a "production" service. Full ack there. > If the IPv6 network service isn't almost as good (due to reliability or > RTTs or whatever) as IPv4, > turn it off until you can do it right. Or ask help in fixing the problem. There are lots of folks who will help one out. ipv6-ops@lists.cluenet.de is the venue for that (if one is an operator, not meant for end-users...) Little the IETF can do in standardizing more stuff to fix that problem. Greets, Jeroen From nobody Wed Dec 3 03:41: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 514CB1A03A5 for ; Wed, 3 Dec 2014 03:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 TCrOEwsIQR3A for ; Wed, 3 Dec 2014 03:41:45 -0800 (PST) Received: from ITSNT447.iowa.uiowa.edu (itsnt447.iowa.uiowa.edu [128.255.67.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781BB1A1A48 for ; Wed, 3 Dec 2014 03:41:45 -0800 (PST) Received: from ITSNT440.iowa.uiowa.edu ([169.254.2.131]) by ITSNT447.iowa.uiowa.edu ([128.255.67.11]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 05:41:44 -0600 From: "Metzler, Dan J" To: John Mann , Jeroen Massar Thread-Topic: [v6ops] Bar BoF on a 6to4 replacement? Thread-Index: AQHP/rVOnFTRtswitUCE4I8xk3fTI5xeZy2AgADuGQCAAAODAIAABIqAgAABtACAAADagIAcVd8AgAEKL4CAAUitgIAAIZYA//+p4yA= Date: Wed, 3 Dec 2014 11:41:43 +0000 Message-ID: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DF397F1@ITSNT440.iowa.uiowa.edu> References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <93034721-BA1A-45C5-A3F5-0838DE3DB3FE@delong.com> <547EC5A9.8010603@massar.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.255.6.15] Content-Type: multipart/alternative; boundary="_000_9062DD5BB047BF4C96BCE0CB9DA96D1B4DF397F1ITSNT440iowauio_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jvZlDCTHzZVl2iJN9Q3uG1uJnKM Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? 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, 03 Dec 2014 11:41:48 -0000 --_000_9062DD5BB047BF4C96BCE0CB9DA96D1B4DF397F1ITSNT440iowauio_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkEgZmV3IHRob3VnaHRz4oCmDQoNCuKAmEFmdGVyIGR1YWwtc3RhY2sgSVB2NiB3YXMg ZW5hYmxlZCBvbiBtb3N0IHN1Ym5ldHMsIHByb3RvY29sIDQxIGFuZCBUZXJlZG8gd2VyZSBibG9j a2VkIGF0IE1vbmFzaCdzIEludGVybmV0IGJvcmRlciBvbiAxNS1KdW4tMjAxMS4gIEkgZG9uJ3Qg cmVjYWxsIGFueW9uZSBldmVyIGFza2luZyBmb3IgaXQgdG8gYmUgcmUtZW5hYmxlZC7igJkNCg0K LSAgICAgICAgICBOb3QgbmVjZXNzYXJpbHkgYSBwcm9ibGVtLCDigJxJRuKAnSBNb25hc2ggZG9l cyBub3QgcHJvdmlkZSBpbnRlcm5ldCBhY2Nlc3MgdG8gb3RoZXIgSVNQcy4gIElmIGl0IGRvZXMs IHRoZW4gd2VyZSB0aGV5IGFsbCBkdWFsLXN0YWNrIElQdjYgZW5hYmxlZD8gIElmIG5vdCB0aGVu IEkgd291bGQgcG9pbnQgb3V0IHRoYXQgdGhpcyBicm9rZSBJUHY2IHNlcnZpY2UgZm9yIHNvbWUg ZG93bnN0cmVhbSBjdXN0b21lcnMgb2YgdGhvc2UgSVNQcy4gIFRoZSBvbmx5IHJlYXNvbiBmb3Ig YW4gSVNQIHRvIHR1cm4gb2ZmIFRlcmVkbyBhbmQgcHJvdG9jb2wgNDEgaXMgaWYgYWxsIGRvd25z dHJlYW0gY3VzdG9tZXJzIGhhdmUgYWNjZXNzIHRvIG5hdGl2ZSBJUHY2IGNvbm5lY3Rpdml0eSwg YW5kIGV2ZW4gdGhlbiB0aGF0IGRlY2lzaW9uIGlzIHF1ZXN0aW9uYWJsZS4NCg0KLSAgICAgICAg ICBJdCBpcyB1bmxpa2VseSB0aGF0IGFueW9uZSB3b3VsZCBhc2sgZm9yIGl0IHRvIGJlIHJlLWVu YWJsZWQuICBUaGV5IHdvdWxkIG1vcmUgbGlrZWx5IGluY29ycmVjdGx5IGFzc3VtZSB0aGF0IElQ djYgaXMgYnJva2VuIGFuZCBkaXNhYmxlIGl0LiAgVGhlIHJlYXNvbiBmb3IgdGhpcyBpcyB0aGF0 IHRoZSB2YXN0IG1ham9yaXR5IG9mIHBlb3BsZSwgd2hvIHdlcmUgYWZmZWN0ZWQgYnkgdGhpcywg bGlrZWx5IHdvdWxkIG5vdCBoYXZlIGhhZCB0aGUgdGVjaG5pY2FsIHNraWxsIHRvIHRyYWNlIGl0 IGJhY2sgdG8gTW9uYXNoLiAgQmVmb3JlIHRoZXkgZXZlciBnb3QgdG8gdGhhdCBwb2ludCBzb21l b25lIHdvdWxkIGxpa2VseSB0ZWxsIHRoZW0gdG8gZGlzYWJsZSBJUHY2LCBvciBhbGwgdHVubmVs aW5nIHByb3RvY29scyB0aHVzIGNvbXBsZXRpbmcgdGhlIGJyZWFrYWdlIG9mIHRoZWlyIElQdjYg Y29ubmVjdGl2aXR5Lg0KDQrigJhJIGFzc2VydCB0aGF0IHRoZSB0aW1lIG9mICJleHBlcmltZW50 YWwiIElQdjYgaGFzIHBhc3NlZC4gIElQdjYgc2hvdWxkIGJlIGEgInByb2R1Y3Rpb24iIHNlcnZp Y2Uu4oCZDQoNCi0gICAgICAgICAgMTAwJSBhZ3JlZWQhDQoNCuKAmElmIHRoZSBJUHY2IG5ldHdv cmsgc2VydmljZSBpc24ndCBhbG1vc3QgYXMgZ29vZCAoZHVlIHRvIHJlbGlhYmlsaXR5IG9yIFJU VHMgb3Igd2hhdGV2ZXIpIGFzIElQdjQsDQp0dXJuIGl0IG9mZiB1bnRpbCB5b3UgY2FuIGRvIGl0 IHJpZ2h0LuKAmQ0KDQotICAgICAgICAgIE5vb29vb29vb29vb28uDQoNCi0gICAgICAgICAgSWYg dGhlIElQdjYgbmV0d29yayBzZXJ2aWNlIGlzbuKAmXQgYWxtb3N0IGFzIGdvb2QgKGR1ZSB0byBy ZWxpYWJpbGl0eSBvciBSVFRzIG9yIHdoYXRldmVyKSwgYW5kIGl0IGlzIHVuZGVyIHlvdXIgY29u dHJvbCB0byBmaXggaXQsIHRoZW4gcGxlYXNlIGZpeCBpdC4NCg0KLSAgICAgICAgICBJZiBpdCBp c27igJl0IHVuZGVyIHlvdXIgY29udHJvbCwgdGhlbiBjb21tdW5pY2F0ZSBpdCB0byB5b3VyIElT UCBvciB0aGUgb2ZmZW5kaW5nIHBhcnR5IGFuZCBhc2sgdGhlbSB0byBmaXggaXQuDQoNCi0gICAg ICAgICAg4oCcVHVybiBpdCBvZmbigJ0gaXMgdGhlIHdyb25nIGFuc3dlciwgdGhvdWdoIHByb2Jh Ymx5IHRoZSBtb3JlIHBvcHVsYXIgYW5zd2VyLiAgVHVybmluZyBpdCBvZmYgYnJlYWtzIGl0IG1v cmUgY29tcGxldGVseSB0aGFuIGl0IHdhcyB3aXRoIHBvb3IgcGVyZm9ybWFuY2UuDQoNClRoYW5r cywNCg0KICBEYW4NCg0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgSm9obiBNYW5uDQpTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDMsIDIw MTQgNDoxMiBBTQ0KVG86IEplcm9lbiBNYXNzYXINCkNjOiB2Nm9wc0BpZXRmLm9yZyBXRw0KU3Vi amVjdDogUmU6IFt2Nm9wc10gQmFyIEJvRiBvbiBhIDZ0bzQgcmVwbGFjZW1lbnQ/DQoNCkplcm9l biwNCg0KDQpPbiAzIERlY2VtYmVyIDIwMTQgYXQgMTk6MTEsIEplcm9lbiBNYXNzYXIgPGplcm9l bkBtYXNzYXIuY2g8bWFpbHRvOmplcm9lbkBtYXNzYXIuY2g+PiB3cm90ZToNCk9uIDIwMTQtMTIt MDIgMTM6MzQsIEpvaG4gTWFubiB3cm90ZToNClsuLl0NCj4gQWxzbywgTW9uYXNoIFVuaXZlcnNp dHkgaXMgQVM1NjEzMjsgd2UgZ2V0IG1vc3Qgb2Ygb3VyIEludGVybmV0IGZyb20NCj4gQUFSTmV0 IEFTNzU3NS4NCg0KQ29uZ3JhdHMsIHlvdSBoYXZlIGFjY2VzcyB0byBhbiBJU1Agd2hvIGhhcyBi ZWVuIHByb3ZpZGluZyBuYXRpdmUgSVB2Ng0KZm9yIG1hbnkgbWFueSB5ZWFycyAobGlrZWx5IGEg ZGVjYWRlIGF0IGxlYXN0KS4NCg0KUGxlYXNlIHVzZSB0aGUgbmF0aXZlIGNvbm5lY3Rpdml0eSA6 KQ0KDQpJIGRvIHVzZSBuYXRpdmUgSVB2NiBjb25uZWN0aXZpdHkuDQoNCldJdGhpbiBBdXN0cmFs aWEgLi4uIHNlZQ0KICAgaHR0cDovL2xhYnMuYXBuaWMubmV0L2lwdjYtbWVhc3VyZW1lbnQvRWNv bm9taWVzL0FVDQogICAgIGNsaWNrICAgIkFTTiBpbiB0aGlzIEVjb25vbXkiIHRhYg0KLS0tIChl ZGl0ZWQpDQpBU04gICBBUyBOYW1lICAgICAgICAgICAjc2FtcGxlc+KAg3Y2LWNhcGFibGXigIN2 Ni1wcmVmZXJyZWTigIMNCjU2MTMyIE1vbmFzaCBVbml2ZXJzaXR5ICAgMjUwICAgICA2My42MCUg ICAgIDU4LjgwJQ0KIDQ3MzkgSW50ZXJub2RlIFB0eSBMdGQgIDM5MjQgICAgICA2LjI3JSAgICAg IDYuMTQlDQoNCi4uLg0KLS0tDQpNb25hc2ggKHJhbmsgIzEpIGlzIG15IHdvcmsgSW50ZXJuZXQg cHJvdmlkZXIsIGFuZCBJbnRlcm5vZGUgKHJhbmsgIzIpIGlzIG15IGhvbWUgSVNQLg0KDQpUaGUg cXVlc3Rpb24gSSB3YXMgaW52ZXN0aWdhdGluZyB3YXMgd2h5IGEgSEUgdHVubmVsIGluIFNHL0hL IGlzbid0IHVzZWZ1bCB0byBBdXN0cmFsaWFucyBbd2hvIGRvbid0IHVzZSBhbiBJUHY2LWNhcGFi bGUgSVNQXS4NCg0KPT09DQoNCkJhY2sgb24gdG9waWM6ICBNb25hc2gncyAiQW55Y2FzdCA2dG80 IGZhaWwgbW9tZW50IiB3YXMgaW4gMjAwNyBvciAyMDA4Lg0KTm9uLVNPRSBXaW5kb3dzIFZpc3Rh IGxhcHRvcHMgd2l0aCBJQ1MgZW5hYmxlZCB3ZXJlIGFkdmVydGlzaW5nIDZ0bzQtZGVyaXZlZCBy b3V0ZXMgdG8gTWFjIE9TWCAxMC40IG1hY2hpbmVzDQphbmQgYnJlYWtpbmcgdGhlaXIgY29ubmVj dGl2aXR5IHRvIElQdjYgc2l0ZXMuICBXZSBmaXhlZCB0aGF0IHVzaW5nIGEgUkEtZmlsdGVyIG9u IGFsbCB1c2VyIG5ldHdvcmsgcG9ydHMuDQoNCkFmdGVyIGR1YWwtc3RhY2sgSVB2NiB3YXMgZW5h YmxlZCBvbiBtb3N0IHN1Ym5ldHMsIHByb3RvY29sIDQxIGFuZCBUZXJlZG8gd2VyZSBibG9ja2Vk IGF0IE1vbmFzaCdzIEludGVybmV0IGJvcmRlciBvbiAxNS1KdW4tMjAxMS4gIEkgZG9uJ3QgcmVj YWxsIGFueW9uZSBldmVyIGFza2luZyBmb3IgaXQgdG8gYmUgcmUtZW5hYmxlZC4NCg0KSSBhc3Nl cnQgdGhhdCB0aGUgdGltZSBvZiAiZXhwZXJpbWVudGFsIiBJUHY2IGhhcyBwYXNzZWQuICBJUHY2 IHNob3VsZCBiZSBhICJwcm9kdWN0aW9uIiBzZXJ2aWNlLg0KSWYgdGhlIElQdjYgbmV0d29yayBz ZXJ2aWNlIGlzbid0IGFsbW9zdCBhcyBnb29kIChkdWUgdG8gcmVsaWFiaWxpdHkgb3IgUlRUcyBv ciB3aGF0ZXZlcikgYXMgSVB2NCwNCnR1cm4gaXQgb2ZmIHVudGlsIHlvdSBjYW4gZG8gaXQgcmln aHQuDQoNClRoYW5rcywNCiAgICBKb2huDQo= --_000_9062DD5BB047BF4C96BCE0CB9DA96D1B4DF397F1ITSNT440iowauio_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo5NTQ3NTYwMjE7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi02NjE0NjA5NjAgLTMwMTI5Mzk0 MCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGkt Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJY29sb3I6IzFGNDk3RDt9DQpAbGlzdCBs MDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhp LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QSBmZXcgdGhvdWdo dHPigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPuKAmDwvc3Bh bj5BZnRlciBkdWFsLXN0YWNrIElQdjYgd2FzIGVuYWJsZWQgb24gbW9zdCBzdWJuZXRzLCBwcm90 b2NvbCA0MSBhbmQgVGVyZWRvIHdlcmUgYmxvY2tlZCBhdCBNb25hc2gncyBJbnRlcm5ldCBib3Jk ZXImbmJzcDtvbiAxNS1KdW4tMjAxMS4mbmJzcDsgSSBkb24ndCByZWNhbGwgYW55b25lDQogZXZl ciBhc2tpbmcgZm9yIGl0IHRvIGJlIHJlLWVuYWJsZWQuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPuKAmTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+Tm90IG5l Y2Vzc2FyaWx5IGEgcHJvYmxlbSwg4oCcSUbigJ0gTW9uYXNoIGRvZXMgbm90IHByb3ZpZGUgaW50 ZXJuZXQgYWNjZXNzIHRvIG90aGVyIElTUHMuJm5ic3A7IElmIGl0IGRvZXMsIHRoZW4gd2VyZSB0 aGV5IGFsbCBkdWFsLXN0YWNrIElQdjYgZW5hYmxlZD8mbmJzcDsgSWYgbm90IHRoZW4gSSB3b3Vs ZCBwb2ludCBvdXQgdGhhdCB0aGlzIGJyb2tlIElQdjYgc2VydmljZSBmb3Igc29tZSBkb3duc3Ry ZWFtIGN1c3RvbWVycw0KIG9mIHRob3NlIElTUHMuJm5ic3A7IFRoZSBvbmx5IHJlYXNvbiBmb3Ig YW4gSVNQIHRvIHR1cm4gb2ZmIFRlcmVkbyBhbmQgcHJvdG9jb2wgNDEgaXMgaWYgYWxsIGRvd25z dHJlYW0gY3VzdG9tZXJzIGhhdmUgYWNjZXNzIHRvIG5hdGl2ZSBJUHY2IGNvbm5lY3Rpdml0eSwg YW5kIGV2ZW4gdGhlbiB0aGF0IGRlY2lzaW9uIGlzIHF1ZXN0aW9uYWJsZS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWlu O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+SXQgaXMgdW5saWtlbHkgdGhhdCBhbnlvbmUgd291bGQgYXNr IGZvciBpdCB0byBiZSByZS1lbmFibGVkLiZuYnNwOyBUaGV5IHdvdWxkIG1vcmUgbGlrZWx5IGlu Y29ycmVjdGx5IGFzc3VtZSB0aGF0IElQdjYgaXMgYnJva2VuIGFuZCBkaXNhYmxlIGl0LiZuYnNw OyBUaGUgcmVhc29uIGZvciB0aGlzIGlzIHRoYXQgdGhlIHZhc3QgbWFqb3JpdHkgb2YgcGVvcGxl LCB3aG8gd2VyZSBhZmZlY3RlZCBieSB0aGlzLA0KIGxpa2VseSB3b3VsZCBub3QgaGF2ZSBoYWQg dGhlIHRlY2huaWNhbCBza2lsbCB0byB0cmFjZSBpdCBiYWNrIHRvIE1vbmFzaC4mbmJzcDsgQmVm b3JlIHRoZXkgZXZlciBnb3QgdG8gdGhhdCBwb2ludCBzb21lb25lIHdvdWxkIGxpa2VseSB0ZWxs IHRoZW0gdG8gZGlzYWJsZSBJUHY2LCBvciBhbGwgdHVubmVsaW5nIHByb3RvY29scyB0aHVzIGNv bXBsZXRpbmcgdGhlIGJyZWFrYWdlIG9mIHRoZWlyIElQdjYgY29ubmVjdGl2aXR5LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj7igJhJIGFzc2VydCB0aGF0IHRoZSB0aW1lIG9mICZxdW90O2V4cGVy aW1lbnRhbCZxdW90OyBJUHY2IGhhcyBwYXNzZWQuJm5ic3A7IElQdjYgc2hvdWxkIGJlIGEgJnF1 b3Q7cHJvZHVjdGlvbiZxdW90OyBzZXJ2aWNlLuKAmTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT4xMDAlIGFncmVlZCE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCYSWYgdGhlIElQ djYgbmV0d29yayBzZXJ2aWNlIGlzbid0IGFsbW9zdCBhcyBnb29kIChkdWUgdG8gcmVsaWFiaWxp dHkgb3IgUlRUcyBvciB3aGF0ZXZlcikgYXMgSVB2NCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPnR1cm4gaXQgb2ZmIHVudGlsIHlvdSBjYW4gZG8gaXQgcmlnaHQu4oCZPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPk5vb29vb29vb29vb28uJm5ic3A7IDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVu dDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5JZiB0aGUgSVB2NiBuZXR3b3JrIHNlcnZpY2Ug aXNu4oCZdCBhbG1vc3QgYXMgZ29vZCAoZHVlIHRvIHJlbGlhYmlsaXR5IG9yIFJUVHMgb3Igd2hh dGV2ZXIpLCBhbmQgaXQgaXMgdW5kZXIgeW91ciBjb250cm9sIHRvIGZpeCBpdCwgdGhlbiBwbGVh c2UgZml4IGl0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5JZiBpdCBpc27igJl0 IHVuZGVyIHlvdXIgY29udHJvbCwgdGhlbiBjb21tdW5pY2F0ZSBpdCB0byB5b3VyIElTUCBvciB0 aGUgb2ZmZW5kaW5nIHBhcnR5IGFuZCBhc2sgdGhlbSB0byBmaXggaXQuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPuKAnFR1cm4gaXQgb2Zm4oCdIGlzIHRoZSB3cm9uZyBhbnN3ZXIs IHRob3VnaCBwcm9iYWJseSB0aGUgbW9yZSBwb3B1bGFyIGFuc3dlci4mbmJzcDsgVHVybmluZyBp dCBvZmYgYnJlYWtzIGl0IG1vcmUgY29tcGxldGVseSB0aGFuIGl0IHdhcyB3aXRoIHBvb3IgcGVy Zm9ybWFuY2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7IERhbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gdjZv cHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5K b2huIE1hbm48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBEZWNlbWJlciAzLCAyMDE0IDQ6 MTIgQU08YnI+DQo8Yj5Ubzo8L2I+IEplcm9lbiBNYXNzYXI8YnI+DQo8Yj5DYzo8L2I+IHY2b3Bz QGlldGYub3JnIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIEJhciBCb0Ygb24g YSA2dG80IHJlcGxhY2VtZW50PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5KZXJvZW4sPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAzIERlY2VtYmVyIDIwMTQgYXQgMTk6MTEsIEplcm9l biBNYXNzYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqZXJvZW5AbWFzc2FyLmNoIiB0YXJnZXQ9Il9i bGFuayI+amVyb2VuQG1hc3Nhci5jaDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIwMTQtMTItMDIgMTM6MzQsIEpvaG4g TWFubiB3cm90ZTo8YnI+DQpbLi5dPGJyPg0KJmd0OyBBbHNvLCBNb25hc2ggVW5pdmVyc2l0eSBp cyBBUzU2MTMyOyB3ZSBnZXQgbW9zdCBvZiBvdXIgSW50ZXJuZXQgZnJvbTxicj4NCiZndDsgQUFS TmV0IEFTNzU3NS48YnI+DQo8YnI+DQpDb25ncmF0cywgeW91IGhhdmUgYWNjZXNzIHRvIGFuIElT UCB3aG8gaGFzIGJlZW4gcHJvdmlkaW5nIG5hdGl2ZSBJUHY2PGJyPg0KZm9yIG1hbnkgbWFueSB5 ZWFycyAobGlrZWx5IGEgZGVjYWRlIGF0IGxlYXN0KS48YnI+DQo8YnI+DQpQbGVhc2UgdXNlIHRo ZSBuYXRpdmUgY29ubmVjdGl2aXR5IDopPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvIHVzZSBuYXRpdmUgSVB2NiBjb25uZWN0 aXZpdHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPldJdGhpbiBBdXN0cmFsaWEgLi4uIHNlZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHA6 Ly9sYWJzLmFwbmljLm5ldC9pcHY2LW1lYXN1cmVtZW50L0Vjb25vbWllcy9BVSI+aHR0cDovL2xh YnMuYXBuaWMubmV0L2lwdjYtbWVhc3VyZW1lbnQvRWNvbm9taWVzL0FVPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAm bmJzcDtjbGljayAmbmJzcDsgJnF1b3Q7QVNOIGluIHRoaXMgRWNvbm9teSZxdW90OyB0YWI8YnI+ DQotLS0gKGVkaXRlZCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+QVNOICZuYnNwOyBBUyBOYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg I3NhbXBsZXPigIN2Ni1jYXBhYmxl4oCDdjYtcHJlZmVycmVk4oCDPGJyPg0KNTYxMzIgTW9uYXNo IFVuaXZlcnNpdHkgJm5ic3A7IDI1MCAmbmJzcDsgJm5ic3A7IDYzLjYwJSAmbmJzcDsgJm5ic3A7 IDU4LjgwJTxicj4NCiZuYnNwOzQ3MzkgSW50ZXJub2RlIFB0eSBMdGQgJm5ic3A7MzkyNCAmbmJz cDsgJm5ic3A7ICZuYnNwOzYuMjclICZuYnNwOyAmbmJzcDsgJm5ic3A7Ni4xNCU8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxl IiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjE2NjUi IHN0eWxlPSJ3aWR0aDo4MzIuNXB0O2JvcmRlci1jb2xsYXBzZTpjb2xsYXBzZTttYXgtd2lkdGg6 MTAwJTtib3JkZXItc3BhY2luZzowcHg7YmFja2dyb3VuZC1pbWFnZTppbml0aWFsO2JhY2tncm91 bmQtcmVwZWF0OmluaXRpYWwiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43 NXB0IC43NXB0IC43NXB0IC43NXB0Ij48L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Li4uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS08bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1vbmFzaCAocmFuayAjMSkgaXMgbXkg d29yayBJbnRlcm5ldCBwcm92aWRlciwgYW5kIEludGVybm9kZSAocmFuayAjMikgaXMgbXkgaG9t ZSBJU1AuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZSBxdWVzdGlvbiBJIHdhcyBpbnZlc3RpZ2F0aW5nIHdhcyB3aHkgYSBIRSB0dW5uZWwg aW4gU0cvSEsgaXNuJ3QgdXNlZnVsIHRvIEF1c3RyYWxpYW5zIFt3aG8gZG9uJ3QgdXNlIGFuIElQ djYtY2FwYWJsZSBJU1BdLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj49PT08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QmFjayBvbiB0b3BpYzogJm5ic3A7TW9uYXNoJ3MgJnF1b3Q7QW55Y2Fz dCA2dG80IGZhaWwgbW9tZW50JnF1b3Q7IHdhcyBpbiAyMDA3IG9yIDIwMDguPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob24tU09FIFdpbmRvd3Mg VmlzdGEgbGFwdG9wcyB3aXRoIElDUyBlbmFibGVkIHdlcmUgYWR2ZXJ0aXNpbmcgNnRvNC1kZXJp dmVkIHJvdXRlcyB0byBNYWMgT1NYIDEwLjQgbWFjaGluZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuZCBicmVha2luZyB0aGVpciBjb25uZWN0 aXZpdHkgdG8gSVB2NiBzaXRlcy4mbmJzcDsgV2UgZml4ZWQgdGhhdCB1c2luZyBhIFJBLWZpbHRl ciBvbiBhbGwgdXNlciBuZXR3b3JrIHBvcnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFmdGVyIGR1YWwtc3RhY2sgSVB2NiB3YXMgZW5hYmxlZCBvbiBt b3N0IHN1Ym5ldHMsIHByb3RvY29sIDQxIGFuZCBUZXJlZG8gd2VyZSBibG9ja2VkIGF0IE1vbmFz aCdzIEludGVybmV0IGJvcmRlciZuYnNwO29uIDE1LUp1bi0yMDExLiZuYnNwOyBJIGRvbid0IHJl Y2FsbCBhbnlvbmUgZXZlciBhc2tpbmcgZm9yIGl0IHRvIGJlIHJlLWVuYWJsZWQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYXNzZXJ0IHRo YXQgdGhlIHRpbWUgb2YgJnF1b3Q7ZXhwZXJpbWVudGFsJnF1b3Q7IElQdjYgaGFzIHBhc3NlZC4m bmJzcDsgSVB2NiBzaG91bGQgYmUgYSAmcXVvdDtwcm9kdWN0aW9uJnF1b3Q7IHNlcnZpY2UuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGUg SVB2NiBuZXR3b3JrIHNlcnZpY2UgaXNuJ3QgYWxtb3N0IGFzIGdvb2QgKGR1ZSB0byByZWxpYWJp bGl0eSBvciBSVFRzIG9yIHdoYXRldmVyKSBhcyBJUHY0LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dHVybiBpdCBvZmYgdW50aWwgeW91IGNhbiBk byBpdCByaWdodC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAmbmJzcDsgSm9objxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9062DD5BB047BF4C96BCE0CB9DA96D1B4DF397F1ITSNT440iowauio_-- From nobody Wed Dec 3 04:31: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 CF48B1A1AC6 for ; Wed, 3 Dec 2014 04:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 RptGeB_kuTh3 for ; Wed, 3 Dec 2014 04:30:59 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40D491A1A93 for ; Wed, 3 Dec 2014 04:30:59 -0800 (PST) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:dd3e:fec4:32df:4dd0] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sB3CUT9J014303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Dec 2014 13:30:30 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Iljitsch van Beijnum In-Reply-To: Date: Wed, 3 Dec 2014 13:30:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> To: Ole Troan X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Z9rjo34S_hqXvm6rj471nLusiL8 Cc: IPv6 Operations Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 12:31:01 -0000 On 02 Dec 2014, at 20:15, Ole Troan wrote: >> - the server matches their IPv4 address, NAT/CGN status and = capabilities with available tunnel options such as brokers, 6rd, public = gateways, sends back configuration info >> - home gateway sets up a tunnel and uses keepalives to make sure it's = up, go back to the server if the tunnel goes down for whatever reason > done. RFC5571. I guess L2TP would be a way to handle tunneling towards a gateway = operated by an ISP or third parties, but it doesn't solve the entire = problem, where a home gateway can set up tunnel to an appropriate = gateway (i.e., the topologically closest one available) without any = configuration. Also, isn't RFC 5571 about IPv4-over-IPv6 tunneling = rather than the other way around? And the extra PPP layer could be an = unwanted complication. Iljitsch= From nobody Wed Dec 3 04:41: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 DE8C21A1A99 for ; Wed, 3 Dec 2014 04:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 uAxMymrhB0iD for ; Wed, 3 Dec 2014 04:41:50 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 846681A0174 for ; Wed, 3 Dec 2014 04:41:50 -0800 (PST) Received: from [192.168.178.22] (5356AD6E.cm-6-7c.dynamic.ziggo.nl [83.86.173.110]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sB3CfJQ6014352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Dec 2014 13:41:20 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Iljitsch van Beijnum In-Reply-To: <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> Date: Wed, 3 Dec 2014 13:41:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qSMQ7R-VPDf-JqZaVz5lTiwBvP0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 12:41:52 -0000 Hi Fred, On 02 Dec 2014, at 20:17, Templin, Fred L = wrote: > Any way you do this, the home gateway needs to be enrolled with the = tunnel service > provider. Why? That's not necessary to use public 6to4 gateways. By having an = out-of-the-box unique login, there is still the possibility to blacklist = misbehaving devices. Black/whitelisting based on IP address is also = appropriate in many cases, for instance by an ISP providing a tunnel = service towards its customers. >> - NO ANYCASTING, NO ROUTE OPTIMIZATION > I don't mind "no anycasting", but why "no route optimization"? Route = optimization > will give better performance and avoid single points of congestion. Experience with Teredo shows that this can easily backfire: the setup = takes long and often fails. The main issue that I have with route = optimization is that it renders the whole system non-deterministic. With = a tunnel broker tunnel you know with 99%+ certainty that if you can ping = the gateway you can reach the entire IPv6 internet. That's an important = feature. However, my goal is not so much to create the final tunneling system = that can replace all others, but rather, to allow devices to discover = their available tunneling options with very little, if any, user = involvement. If some of those options do support route optimization, = they could be included, but only if there are sufficient mechanisms in = place to make sure that when the route optimization fails, this doesn't = break connectivity. Iljitsch= From nobody Wed Dec 3 05: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 332291A1AE0 for ; Wed, 3 Dec 2014 05:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, 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 cYqOAbJ_9VyX for ; Wed, 3 Dec 2014 05:15:50 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B69311A1AA3 for ; Wed, 3 Dec 2014 05:15:49 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id y20so13757694ier.0 for ; Wed, 03 Dec 2014 05:15:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qh//AG+J4Gf+JKjmd0sp+qmZWNaOcw9szbLG2rl7Q9A=; b=J5mDKu6rkc6HujFjwc/g9PpKvqhk44LoVWJq2ptAzn7LyL4z65ey2uMYN0+5MgC/8x FecByKB1jgIrkvBHcVFIaMXjlBCoc65J2OQbj4yjD7YHuwLkQ4qng4KnMksGfl6ImPl1 J6YLnVaHC+yeeOlHRnpFRF55zhftGAgrzj8M5VMoEuhrCozLGiirKsfMrA0Yr3uCGzcm 7xHYXy50HpyzSSmJyfmit18QtAcQ1FLGXI1vikALIiNsZCd6amPs5TZGYUP9POW/wplD YTXw4gxGtlkWnjRybwr27au3StFbIOMp+YFyP3muR3IM6qS0gCIrax24MSyvxmpR6Xpz htHw== MIME-Version: 1.0 X-Received: by 10.50.30.202 with SMTP id u10mr56645130igh.35.1417612548694; Wed, 03 Dec 2014 05:15:48 -0800 (PST) Received: by 10.107.131.141 with HTTP; Wed, 3 Dec 2014 05:15:48 -0800 (PST) In-Reply-To: References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> Date: Wed, 3 Dec 2014 14:15:48 +0100 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: Iljitsch van Beijnum Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KJq1KD0LiYReC7PErTfkVBOoyeg Cc: IPv6 Operations Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 13:15:51 -0000 On 12/3/14, Iljitsch van Beijnum wrote: > On 02 Dec 2014, at 20:15, Ole Troan wrote: > >>> - the server matches their IPv4 address, NAT/CGN status and capabilities >>> with available tunnel options such as brokers, 6rd, public gateways, >>> sends back configuration info >>> - home gateway sets up a tunnel and uses keepalives to make sure it's up, >>> go back to the server if the tunnel goes down for whatever reason > >> done. RFC5571. > > I guess L2TP would be a way to handle tunneling towards a gateway operated > by an ISP or third parties, but it doesn't solve the entire problem, where a > home gateway can set up tunnel to an appropriate gateway (i.e., the > topologically closest one available) without any configuration. Just run the LNS on 192.88.99.1. > Also, isn't > RFC 5571 about IPv4-over-IPv6 tunneling rather than the other way around? > And the extra PPP layer could be an unwanted complication. Designing, implementing, debugging and deploying a completely new protocol on billions of devices is simpler ? --a > > Iljitsch > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Dec 3 05:16: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 87B0D1A1AFB for ; Wed, 3 Dec 2014 05:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 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_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 noOovvYz0na4 for ; Wed, 3 Dec 2014 05:16:05 -0800 (PST) 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 231291A1AF4 for ; Wed, 3 Dec 2014 05:16:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 1D49E56; Wed, 3 Dec 2014 14:16:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1417612561; bh=44IW5OcAFNXta+9zo0kCcSfmedY5ff0M2Fc5qr5pl9E=; b=c ICxzVY08yESZMknN8XOABj1nkmS8tCgnjxByDmRrpYe0qBEUy4qcsGEwXeIXvxSZ 0f51KwzgwtTIQq3UB0tenJdFV2XBWFk9um9PrqKMIn10Tq8PRHjBKFFvcq2ON/eM IzP42Jc9vnBoyWKHydxJi12pJhl5loxHnSaZfbE2Yg= 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 10026) with ESMTP id IyuXqintC2CN; Wed, 3 Dec 2014 14:16:01 +0100 (CET) Received: from [IPv6:2a00:8640:1::8d33:9886:bb65:df11] (unknown [IPv6:2a00:8640:1:0:8d33:9886:bb65:df11]) by mail.sintact.nl (Postfix) with ESMTPSA id B8AA045; Wed, 3 Dec 2014 14:16:00 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2058.2\)) From: Sander Steffann In-Reply-To: Date: Wed, 3 Dec 2014 14:15:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> To: Ted Lemon X-Mailer: Apple Mail (2.2058.2) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4zDEAFtHOKEDACGVxZGMt7RSua0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 03 Dec 2014 13:16:06 -0000 Hi, > Op 2 dec. 2014, om 15:20 heeft Ted Lemon het = volgende geschreven: >=20 > RJ Atkinson has pointed out that the proposal to move A+P from = experimental to standard might be of interest to the v6ops working = group. This seems like a reasonable point. I'm not a chair and not = the responsible AD for v6ops, but I certainly would welcome discussion = of this on v6ops. I am on the mailing list, and I think Randy is too, = so if this were discussed on v6ops, we would both see and be able to = participate in the discussion. So, by all means, please discuss! Not much discussion from me, it just seems to make sense :) Cheers, Sander From nobody Wed Dec 3 05:25: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 CD0A01A1B17 for ; Wed, 3 Dec 2014 05:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 wqeWJeEYF0oG for ; Wed, 3 Dec 2014 05:25:40 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B637A1A1AE3 for ; Wed, 3 Dec 2014 05:25:40 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 5D9EF10054675; Wed, 3 Dec 2014 13:25:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417613137; bh=U8IbTPUCkDWMoeh1Ha7ck1Oze4qxiLzVWeEPhIG3+7w=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=XbR+mQY1tl4dOxE5htPiSxGpKyUnaitIQeVQpohDCFvM75aMJSv3J7B01dgj6DjhK ukvkEv3VR6oykOt6/d0DRQABqNFvc6fisyphZPUhVLnUw/izXdancCR7bFSZLQ8Sat opHgZGMDJsOxAYsKsBdr0tt3p2qeaYkyDjL/PqewkovvX44ddFPieTTuo9NCyKVLMe l40xMkWoYm7RzGj1YFC/HKKb6bbNnl6hhbNaE0j4Fi05+hacu3iSVAu6FA91djunUP K/kPUoTh1GFVOItbJQh4gkiIKxKzjPZbV1BtD8Pgo/yt/vtP3KcQ7qXw9o0VvuvBN2 sD0mCXQMGiI3w== Message-ID: <547F0F4F.90107@massar.ch> Date: Wed, 03 Dec 2014 14:25:35 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Iljitsch van Beijnum References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/GxRL_20W6qR1dfxUH-Lom37Ejpc Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 13:25:43 -0000 On 2014-12-03 13:41, Iljitsch van Beijnum wrote: [..] > However, my goal is not so much to create the final tunneling system that can replace > all others, but rather, to allow devices to discover their available tunneling options > with very little, if any, user involvement. Which demographic of users need this? Please provide a list of requirements and how current solutions do not match those requirements or how those requirements could be met. Noting also that an ISP that is willing to provide any kind of tunnel service can do so perfectly with 6rd, the discovery being solved with a mere DHCP option. Greets, Jeroen From nobody Wed Dec 3 07:47: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 243071A1B81 for ; Wed, 3 Dec 2014 07:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 LgDnMiEPXO-f for ; Wed, 3 Dec 2014 07:47:00 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCE201A1B3F for ; Wed, 3 Dec 2014 07:47:00 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 3275B210E7 for ; Wed, 3 Dec 2014 10:47:00 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 03 Dec 2014 10:47:00 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=8n7iCx+394vxcowIVlQlxs KOkTM=; b=mwlKC78UtMiPBXEjj2/SVxhdT6MZapR+MfygDDjtQJOaRia4w1JE57 cZAgkNA9eEyojzn/0mt90kKSZpL/Eay5Eza2Y7mnvb8piRE3935H4qC1s8Lj502x K20MkcKdJeZajWFDGkU8KXJgXF2hPz/MHXc5vSC+9+6/q8wyNCmbs= X-Sasl-enc: J8TGz212KFBepIj0kWbFTpyK9lJht58tUE2DSco61g3y 1417621619 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id C6C436801B4; Wed, 3 Dec 2014 10:46:59 -0500 (EST) Message-ID: <547F3067.2030908@network-heretics.com> Date: Wed, 03 Dec 2014 10:46:47 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <93034721-BA1A-45C5-A3F5-0838DE3DB3FE@delong.com> <547EC5A9.8010603@massar.ch> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2Nm7r6VgnfetlPYqgyOEDAavdkc Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? 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, 03 Dec 2014 15:47:02 -0000 On 12/03/2014 05:11 AM, John Mann wrote: > I assert that the time of "experimental" IPv6 has passed. IPv6 should > be a "production" service. > If the IPv6 network service isn't almost as good (due to reliability > or RTTs or whatever) as IPv4, > turn it off until you can do it right. The problem with that statement is that IPv4 is rapidly getting more and more "experimental", and less and less predictable and robust, as providers install more and more middleboxes (including LSNs) that implement more and more kludges, more and more layering violations, etc. There seems to be a strong tendency for providers to say "if the web works and email works, that's good enough for most people; anything else is a special case, but by default it's okay to screw those users". Which just makes IPv4 more and more hostile to applications. >From the point of view of some kinds of applications developers, IPv6 is starting to look much saner than IPv4, even if the IPv6 access often relies on some tunneling mechanism. Keith From nobody Wed Dec 3 07:50: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 B85221A1B9B for ; Wed, 3 Dec 2014 07:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 V8sKNzcgUkqy for ; Wed, 3 Dec 2014 07:50:22 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DE0D1A1B86 for ; Wed, 3 Dec 2014 07:50:22 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id B9AF420344 for ; Wed, 3 Dec 2014 10:50:21 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 03 Dec 2014 10:50:21 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=KWIxlqEEgE3/m1SH5nyQ17 XDO6w=; b=kVRPhVfW3m05bvxYx/QoEzO2wwlQ0Ir6u/s8iRT9/uBEcAxQ00/v/A 5PUnLMQtWaaChACYYa3D6NMxrvt8BYfxKz5QAbIBIfVFEadBXiTkQiM+kNrC20jv nC52ihdaC+oe4pCdM6LFgRuozm5U/fs5aJhw/Qk+NuxdAn3Y2ozPA= X-Sasl-enc: PeK97X3N4VhF6jSQnPKXKSxBZbM3v9WSJrT6bQthz9xq 1417621821 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 538DCC00283; Wed, 3 Dec 2014 10:50:21 -0500 (EST) Message-ID: <547F3130.5030607@network-heretics.com> Date: Wed, 03 Dec 2014 10:50:08 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/cgHYyjcegCzDdIWK8Z2yiHVlXnE Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 15:50:23 -0000 On 12/03/2014 07:30 AM, Iljitsch van Beijnum wrote: > On 02 Dec 2014, at 20:15, Ole Troan wrote: > >>> - the server matches their IPv4 address, NAT/CGN status and capabilities with available tunnel options such as brokers, 6rd, public gateways, sends back configuration info >>> - home gateway sets up a tunnel and uses keepalives to make sure it's up, go back to the server if the tunnel goes down for whatever reason >> done. RFC5571. > I guess L2TP would be a way to handle tunneling towards a gateway operated by an ISP or third parties, but it doesn't solve the entire problem, where a home gateway can set up tunnel to an appropriate gateway (i.e., the topologically closest one available) without any configuration. Also, isn't RFC 5571 about IPv4-over-IPv6 tunneling rather than the other way around? And the extra PPP layer could be an unwanted complication. I haven't evaluated RFC 5571 specifically yet. But every other L2TP solution I've looked at has been a disaster, precisely because of too many protocol layers, too many protocol headers with too much overhead. Layering things over PPP just to leverage its authentication is horrendous. Keith From nobody Wed Dec 3 07:54: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 922CA1A1B9C for ; Wed, 3 Dec 2014 07:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 q68sI5bm4YOX for ; Wed, 3 Dec 2014 07:54:14 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E076B1A1B48 for ; Wed, 3 Dec 2014 07:54:13 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3ABD820AA4 for ; Wed, 3 Dec 2014 10:54:13 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 03 Dec 2014 10:54:13 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=bEVoOLf5LhUdQUg7KhBHb/ JII0Q=; b=WhxSzi9qLZtyylqU/nk2frm/wnGCUQoxRMgxXCmAuRqG1j79r2LQNn JarzRg7hzGBgaZOCl/hKC8q0S6r/r38H8AeG6cMcyxjYmQO/nAKeKiiQensj/Xty /cU8jQcrGhKYO4L+g9tmK59/Bc5DNsVj1HhJY8agsj3UKBIChKvs0= X-Sasl-enc: kLE9fWZX4wrfTwitcx2lC+PaK0SVzipVshPI6IWCv96J 1417622052 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id CF610C0028C; Wed, 3 Dec 2014 10:54:12 -0500 (EST) Message-ID: <547F3218.4060101@network-heretics.com> Date: Wed, 03 Dec 2014 10:54:00 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> In-Reply-To: <547F0F4F.90107@massar.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Rv0HcqmQFqAn7BmX0sKtQUhm74c Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 15:54:21 -0000 On 12/03/2014 08:25 AM, Jeroen Massar wrote: > > Which demographic of users need this? Every user who doesn't have native IPv6 access at every one of the locations from which he accesses the Internet. Because IPv6 won't be a viable replacement for IPv4 until users can access it everywhere. And in the near term, that means being able to access it from anywhere that currently has IPv4. Keith From nobody Wed Dec 3 08:02: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 7853F1A1BBE for ; Wed, 3 Dec 2014 08:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 y55G0QCQD9Bt for ; Wed, 3 Dec 2014 08:02:28 -0800 (PST) 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 157D81A6F87 for ; Wed, 3 Dec 2014 08:01:31 -0800 (PST) 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 sB3G1UWI008237; Wed, 3 Dec 2014 10:01:30 -0600 Received: from XCH-PHX-210.sw.nos.boeing.com (xch-phx-210.sw.nos.boeing.com [130.247.25.65]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sB3G1JUu008149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 3 Dec 2014 10:01:20 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-PHX-210.sw.nos.boeing.com ([169.254.10.233]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 08:01:18 -0800 From: "Templin, Fred L" To: Iljitsch van Beijnum Thread-Topic: [v6ops] Report: Bar BoF on a 6to4 replacement Thread-Index: AQHQDmAH0I/jfXJhYUW2sj/c/ybqPJx8qrzwgAGrlID//64HQA== Date: Wed, 3 Dec 2014 16:01:18 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DA990C@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.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/1qKNUvBsmLbOgFa9QIlynMIzi9U Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 16:02:30 -0000 Hi Iljitsch, > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Wednesday, December 03, 2014 4:42 AM > To: Templin, Fred L > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement >=20 > Hi Fred, >=20 > On 02 Dec 2014, at 20:17, Templin, Fred L wro= te: >=20 > > Any way you do this, the home gateway needs to be enrolled with the tun= nel service > > provider. >=20 > Why? That's not necessary to use public 6to4 gateways. By having an out-o= f-the-box unique login, there is still the possibility to > blacklist misbehaving devices. Black/whitelisting based on IP address is = also appropriate in many cases, for instance by an ISP providing > a tunnel service towards its customers. I am interested in an ISP-independent tunnel service solution. So, the tunn= el service would accept tunneled packets coming from an arbitrary ISP even though it i= s not in any way associated with that ISP. For that, the device needs to be enrolled= with the tunnel service provider. That said, AERO can certainly be used in an ISP-specific deployment as well= that does not accept tunneled packets from other ISPs. In that case, I guess you are = right that an out-of-the-box solution is OK. > >> - NO ANYCASTING, NO ROUTE OPTIMIZATION >=20 > > I don't mind "no anycasting", but why "no route optimization"? Route op= timization > > will give better performance and avoid single points of congestion. >=20 > Experience with Teredo shows that this can easily backfire: the setup tak= es long and often fails. The main issue that I have with route > optimization is that it renders the whole system non-deterministic. With = a tunnel broker tunnel you know with 99%+ certainty that if > you can ping the gateway you can reach the entire IPv6 internet. That's a= n important feature. With AERO, the route optimization setup is conducted in parallel with actua= l data packet transmissions and without diverting to the route optimized path until everything has been verified to be working correctly. So, if route optimization fails data packet transmissions continue without disruptions v= ia the dogleg path. And, after route optimization is completed the system can always fall back to using the dogleg path in case something breaks. > However, my goal is not so much to create the final tunneling system that= can replace all others, but rather, to allow devices to > discover their available tunneling options with very little, if any, user= involvement. If some of those options do support route > optimization, they could be included, but only if there are sufficient me= chanisms in place to make sure that when the route > optimization fails, this doesn't break connectivity. Right; AERO provides that. And, it can be seen as a final tunneling system that can replace all others. Thanks for bringing up the concept of an ISP specific AERO deployment, which I guess could be used instead of 6rd and others. Thanks - Fred fred.l.templin@boeing.com > Iljitsch From nobody Wed Dec 3 08:04: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 B28B11A1B9B for ; Wed, 3 Dec 2014 08:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 tFof--bLXOLl for ; Wed, 3 Dec 2014 08:04:12 -0800 (PST) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E964F1A1B48 for ; Wed, 3 Dec 2014 08:04:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sB3G4Biw016771; Wed, 3 Dec 2014 08:04:11 -0800 Received: from XCH-PHX-211.sw.nos.boeing.com (xch-phx-211.sw.nos.boeing.com [130.247.25.140]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sB3G45bt016525 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 3 Dec 2014 08:04:06 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-PHX-211.sw.nos.boeing.com ([169.254.11.133]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 08:04:04 -0800 From: "Templin, Fred L" To: Jeroen Massar , Iljitsch van Beijnum Thread-Topic: [v6ops] Report: Bar BoF on a 6to4 replacement Thread-Index: AQHQDmAH0I/jfXJhYUW2sj/c/ybqPJx8qrzwgAGrlICAAAxJgP//pYdA Date: Wed, 3 Dec 2014 16:04:01 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DA992F@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> In-Reply-To: <547F0F4F.90107@massar.ch> 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/jrKki62kImPf69zOX0nT1G861Cc Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 16:04:14 -0000 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Jeroen Massar > Sent: Wednesday, December 03, 2014 5:26 AM > To: Iljitsch van Beijnum > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement >=20 > On 2014-12-03 13:41, Iljitsch van Beijnum wrote: > [..] > > However, my goal is not so much to create the final tunneling system th= at can replace > > all others, but rather, to allow devices to discover their available > tunneling options > > with very little, if any, user involvement. >=20 > Which demographic of users need this? >=20 > Please provide a list of requirements and how current solutions do not > match those requirements or how those requirements could be met. >=20 > Noting also that an ISP that is willing to provide any kind of tunnel > service can do so perfectly with 6rd, the discovery being solved with a > mere DHCP option. 6rd is not perfect, because it clamps the MTU to something less than 1500. Tunnels should not clamp the MTU, such that 1500s make it through deterministically and 1501+ are allowed to sink or swim on their own. Thanks - Fred fred.l.templin@boeing.com > Greets, > Jeroen >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Dec 3 08:05: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 92D4E1A1B8D for ; Wed, 3 Dec 2014 08:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-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 N3jbO5uRGg6t for ; Wed, 3 Dec 2014 08:05:41 -0800 (PST) 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 995501A1BBE for ; Wed, 3 Dec 2014 08:05:41 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id sB3G5XvQ025994; Wed, 3 Dec 2014 16:05:33 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk sB3G5XvQ025994 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1417622734; bh=gtA+nBsPKTEmM6SCFAs26YDaZVg=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=l8go5y2mJ7G+AJlbaB8pv6326YpRDqjxK8Zzmxd2CYNgAJea5Ft1bLIbHS+VQCAkW Dbpk3K0nbxUCbX8TQky5eHt8Wjwe7CbTiDk8nlPD5Bq80221BoBPOhMNTi5nE688w/ EdIcQQu4iVLucP0MSsAxoBPIz3Ts3ZfSJePf9XT8= 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 qB2G5X2405507279UK ret-id none; Wed, 03 Dec 2014 16:05:34 +0000 Received: from [10.9.54.161] (b54gafwc1n1-ext.net.soton.ac.uk [152.78.0.25]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id sB3G5RT0028022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Dec 2014 16:05:28 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Chown In-Reply-To: <2134F8430051B64F815C691A62D9831832DA990C@XCH-BLV-504.nw.nos.boeing.com> Date: Wed, 3 Dec 2014 16:05:27 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832DA990C@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1878.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=qB2G5X240550727900; tid=qB2G5X2405507279UK; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: sB3G5XvQ025994 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/C8PM_YIOcaWfu6jSoN9_izDpslE Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 16:05:43 -0000 On 3 Dec 2014, at 16:01, Templin, Fred L = wrote: >=20 > I am interested in an ISP-independent tunnel service solution. So, the = tunnel service > would accept tunneled packets coming from an arbitrary ISP even though = it is not in > any way associated with that ISP. For that, the device needs to be = enrolled with the > tunnel service provider. What will this give functionally that a tunnel broker does not? Tim= From nobody Wed Dec 3 08:12: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 A95D81A1B9B for ; Wed, 3 Dec 2014 08:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 OhxzUv2XkEAz for ; Wed, 3 Dec 2014 08:12:43 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 78EE01A6FEC for ; Wed, 3 Dec 2014 08:11:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 86356871652; Wed, 3 Dec 2014 17:11:31 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCGO-BuOJ2DI; Wed, 3 Dec 2014 17:11:31 +0100 (CET) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 5DF4B87153B; Wed, 3 Dec 2014 17:11:31 +0100 (CET) Message-ID: <547F3631.7060606@globis.net> Date: Wed, 03 Dec 2014 17:11:29 +0100 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Sander Steffann References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> In-Reply-To: <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BwR8MwNwOgUMVly12KO8G2zovx0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 03 Dec 2014 16:12:50 -0000 Sander Steffann wrote: > Hi, > >> Op 2 dec. 2014, om 15:20 heeft Ted Lemon het volgende geschreven: >> >> RJ Atkinson has pointed out that the proposal to move A+P from experimental to standard might be of interest to the v6ops working group. This seems like a reasonable point. I'm not a chair and not the responsible AD for v6ops, but I certainly would welcome discussion of this on v6ops. I am on the mailing list, and I think Randy is too, so if this were discussed on v6ops, we would both see and be able to participate in the discussion. So, by all means, please discuss! > > Not much discussion from me, it just seems to make sense :) > > Cheers, > Sander > Why would the IETF want to put an approved "standard track" marking on what is a very clever but horrible kludge? > Of course, a provider might charge more for giving a customer the well-known port range, 0..1024, thus allowing the customer to provide externally available services. Would I be happy as a consumer to have this service sold to me as "standard internet" ? I don't think so. It works perfectly well as "Experimental" for me. -- Regards, RayH From nobody Wed Dec 3 08:14: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 891631A6FBA for ; Wed, 3 Dec 2014 08:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 ghl4lqSboLO5 for ; Wed, 3 Dec 2014 08:14:21 -0800 (PST) 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 6E4531A6FD4 for ; Wed, 3 Dec 2014 08:13:44 -0800 (PST) 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 sB3GDirD016289; Wed, 3 Dec 2014 08:13:44 -0800 Received: from XCH-PHX-410.sw.nos.boeing.com (xch-phx-410.sw.nos.boeing.com [10.57.37.41]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sB3GDeVw016246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 3 Dec 2014 08:13:40 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-PHX-410.sw.nos.boeing.com ([169.254.10.179]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 08:13:40 -0800 From: "Templin, Fred L" To: Tim Chown Thread-Topic: [v6ops] Report: Bar BoF on a 6to4 replacement Thread-Index: AQHQDmAH0I/jfXJhYUW2sj/c/ybqPJx8qrzwgAGrlID//64HQIAAiu2A//97WLA= Date: Wed, 3 Dec 2014 16:13:39 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DA99B0@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832DA990C@XCH-BLV-504.nw.nos.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/Drv6tE-F-l_V9dKEyuziRspSsmA Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 16:14:32 -0000 Hi Tim, > -----Original Message----- > From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] > Sent: Wednesday, December 03, 2014 8:05 AM > To: Templin, Fred L > Cc: Iljitsch van Beijnum; v6ops@ietf.org > Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement >=20 > On 3 Dec 2014, at 16:01, Templin, Fred L wrot= e: > > > > I am interested in an ISP-independent tunnel service solution. So, the = tunnel service > > would accept tunneled packets coming from an arbitrary ISP even though = it is not in > > any way associated with that ISP. For that, the device needs to be enro= lled with the > > tunnel service provider. >=20 > What will this give functionally that a tunnel broker does not? Route optimization, distributed mobility management, traffic engineering, s= ecurity, multi-access handovers (e.g., WiFi/Cellular), routing control, etc. Thanks - Fred fred.l.templin@boeing.com > Tim From nobody Wed Dec 3 08:15: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 9AAC21A1BC8 for ; Wed, 3 Dec 2014 08:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7] 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 Yt-hSoZ8o4E0 for ; Wed, 3 Dec 2014 08:15:18 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3178A1A6F11 for ; Wed, 3 Dec 2014 08:15:18 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 3E9A3100AB8BE; Wed, 3 Dec 2014 16:15:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417623314; bh=HorlR4T34TgZPC79UMSwsHLc83GR3f+2WBB+AZuzPss=; h=Date:From:To:Subject:References:In-Reply-To; b=Cm1YmxI6homtsPAaRhUle9VYnqpEZW4TZs2H5KG/nb4r4fqwvy2mQ2KluAMIy0/pt 6H6vs07+dWTGs9QhJIqGgPYY/QyKDJe9Boz+Gs4prrlmZaBdzvHngExZV/x7AcPpDM /liTH1FEjnniW+MZBaZopj33KtKGbKO1gs8Yydp1XV8gbUcntn2oLWkAbQUILUybTb IDEhwIs/EA1u1dOeNAmVIvZQeUVSYLWth6HG53mKmafG1k8u8JNilh+W0ZJuBBHEIP bFZoOqJuWTmMZFrtr6Jlq9YSg1rW71z4C31aRhkwnqbHdWBqPG0tuWjaTHZYAUQOo3 Dj62nTQgSMNrQ== Message-ID: <547F3710.50106@massar.ch> Date: Wed, 03 Dec 2014 17:15:12 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Keith Moore , v6ops@ietf.org References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <547F3218.4060101@network-heretics.com> In-Reply-To: <547F3218.4060101@network-heretics.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_eE-hVK81S6lxvdCnbzTuL3uw-A Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 16:15:28 -0000 On 2014-12-03 16:54, Keith Moore wrote: > On 12/03/2014 08:25 AM, Jeroen Massar wrote: >> >> Which demographic of users need this? > > Every user who doesn't have native IPv6 access at every one of the > locations from which he accesses the Internet. > > Because IPv6 won't be a viable replacement for IPv4 until users can > access it everywhere. And in the near term, that means being able to > access it from anywhere that currently has IPv4. That demographic of users are signing up to tunnel brokers and VPN providers. As such, I still do not see a need for any other service where those folks cannot use this solution that is in place for years already. One of the many reasons we (SixXS) ask for a "signup reason" is to measure the reason why people sign up. Number one for the last year and a bit: My ISP put me behind DSLite and I cannot access my home network anymore, getting an IPv6 tunnel solves that. That solution works and clearly is not too complicated. Note that a lot of folks seems to deploy both TSP tunnels and AYIYA tunnels on their Android devices using the android clients for that platform. As such, please list the requirements that those folks need and how these requirements are not being met with existing solutions. Greets, Jeroen From nobody Wed Dec 3 08:16: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 CFDB31A1B48 for ; Wed, 3 Dec 2014 08:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 k1vW90Z3gZ7J for ; Wed, 3 Dec 2014 08:16:34 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 740A21A1B7E for ; Wed, 3 Dec 2014 08:16:31 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 06AF7100AB8BE; Wed, 3 Dec 2014 16:16:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417623389; bh=HwItwVLctsz3S0QfAHbaiKQW63iNb270EfHnjsOFM+A=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=THqrvOiV7IZplSBsFJhCyAv5Ig6LM09xtmC5lwBYDtZ+PJ0mYktlZVzqPL+qMclp2 4ww1M8pXDjMS4xMzaLC7gNUQLhBOuUadTGbhRR9xPH1HcXyvRNIkMukjygH8EDuuhU gYxmo9zOdepSmBVmgCGrgKPyYSn7s8do+wYtMl8NynNZJhdKO3X5C4ib+ypkVgvc0u dm/RURtdpmL09S9gh1F4CRi/TCoFBDvEoowlnL9nAZIW9WrrQHm+z2/+kVi0+ngPUA mmrAVNGSXMMCgykU0iP45lrmmU3exWlDSIl3il6Ytev9lXmQXCHVdASaqoUjXys9Kl 4ocFB2j9NNABw== Message-ID: <547F375B.7060802@massar.ch> Date: Wed, 03 Dec 2014 17:16:27 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: "Templin, Fred L" References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832DA990C@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832DA990C@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/j0TM_u4scxBnrfquibDKgbxiD2s Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 16:16:37 -0000 On 2014-12-03 17:01, Templin, Fred L wrote: [..] > I am interested in an ISP-independent tunnel service solution. So, the tunnel service > would accept tunneled packets coming from an arbitrary ISP even though it is not in > any way associated with that ISP. The tunnel service becomes the ISP. And no ISP should ever accept 'arbitrary' packets. Something about source filtering and somebody needs to pay for those packets... Greets, Jeroen From nobody Wed Dec 3 08:17: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 44B171A1BA9 for ; Wed, 3 Dec 2014 08:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 39jblwYybshH for ; Wed, 3 Dec 2014 08:16:47 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C6371A1BDA for ; Wed, 3 Dec 2014 08:16:47 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id D615C211DC for ; Wed, 3 Dec 2014 11:16:46 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 03 Dec 2014 11:16:46 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=26mEukUsC9PmkQZM9M0wAg 86KsU=; b=t7oYA2fvqQ4CSLKY/UPybb1iPmDbcHInk4Q4YtyLT2YzzzVMrat001 NSoqPyEJRzR3hLGfEtCCBOnOLrNPq2Q5/AjNB9QLJo9/82dYjvTbRkCl74niToF6 xl1hBHIrgkpixKZ50/q45UiRQKYieELJv3jSaMzDGVR9t41uvvEQ8= X-Sasl-enc: sfdgYN6W3Pplrf78vX6hNOrRnjXlMip+jkIs64B+Xk7Q 1417623406 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 63052C0027D; Wed, 3 Dec 2014 11:16:46 -0500 (EST) Message-ID: <547F3761.4040506@network-heretics.com> Date: Wed, 03 Dec 2014 11:16:33 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> In-Reply-To: <547F3631.7060606@globis.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Y8YWm0qajmopLKpMOIVX7Cs2g9o Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 03 Dec 2014 16:16:54 -0000 On 12/03/2014 11:11 AM, Ray Hunter wrote: > > Why would the IETF want to put an approved "standard track" marking on > what is a very clever but horrible kludge? My question exactly. We need to stop pretending that adding kludge after kludge to IPv4 is in any way meeting proposed standard criteria. Instead of standardizing more and more kludges to IPv4, we should be working toward moving IPv4 to Historic. Keith From nobody Wed Dec 3 08:17: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 5D0D11A1BCC for ; Wed, 3 Dec 2014 08:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-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 QN3xT0lqEMvq for ; Wed, 3 Dec 2014 08:17:46 -0800 (PST) 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 2E6781A1BEA for ; Wed, 3 Dec 2014 08:17:41 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id sB3GHZIe032332; Wed, 3 Dec 2014 16:17:35 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk sB3GHZIe032332 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1417623455; bh=HLRTO+kxV1xpdc64RRCh6Lvi5OM=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=EYKf4Gj/gUdrykaL/0D+nB/QmlbqYBzE8VvARCSB62rAoDz6skaqfOcg7WR8JHq+k eBw+PYHRli+Q0yYk7rUkrs3QFBzykuI/VWdsrsjcujv8o2KMgNpWXXzVmKgKQxV81T fA2v4+uMXu7yjNjnlwysTfgYlPm1d0aavrhQciDQ= 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 qB2GHZ2405507598lK ret-id none; Wed, 03 Dec 2014 16:17:35 +0000 Received: from [10.9.54.161] (b54gafwc1n1-ext.net.soton.ac.uk [152.78.0.25]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id sB3GHVgM000882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Dec 2014 16:17:31 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Chown In-Reply-To: <2134F8430051B64F815C691A62D9831832DA99B0@XCH-BLV-504.nw.nos.boeing.com> Date: Wed, 3 Dec 2014 16:17:30 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832DA990C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832DA99B0@XCH-BLV-504.nw.nos.boeing.com> <1C337B0C-5949-401D-AB65-9AD750ED8C9C@ecs.soton.ac.uk> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1878.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=qB2GHZ240550759800; tid=qB2GHZ2405507598lK; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: sB3GHZIe032332 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hf1fE3BGKHDZl_q4lyoJCXOXbOg Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 16:17:47 -0000 On 3 Dec 2014, at 16:13, Templin, Fred L = wrote: > Hi Tim, >=20 >> -----Original Message----- >> From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] >> Sent: Wednesday, December 03, 2014 8:05 AM >> To: Templin, Fred L >> Cc: Iljitsch van Beijnum; v6ops@ietf.org >> Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement >>=20 >> On 3 Dec 2014, at 16:01, Templin, Fred L = wrote: >>>=20 >>> I am interested in an ISP-independent tunnel service solution. So, = the tunnel service >>> would accept tunneled packets coming from an arbitrary ISP even = though it is not in >>> any way associated with that ISP. For that, the device needs to be = enrolled with the >>> tunnel service provider. >>=20 >> What will this give functionally that a tunnel broker does not? >=20 > Route optimization, distributed mobility management, traffic = engineering, security, > multi-access handovers (e.g., WiFi/Cellular), routing control, etc. Seems to be a plan to cure all ills with one pill :) Is this proposal also including 6-in-6? Tim= From nobody Wed Dec 3 08:18: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 4C42F1A6EF0 for ; Wed, 3 Dec 2014 08:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7] 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 72T7TfMNjgDl for ; Wed, 3 Dec 2014 08:18:09 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FE481A6F3F for ; Wed, 3 Dec 2014 08:18:01 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 82E71100AB8BE; Wed, 3 Dec 2014 16:17:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417623478; bh=p27jGmJ2TqYmuaV84xHvBkaW7akYiOuOSyjHP5vZyPc=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=G+7rR3cNDCACfsSbK9WR23qyTWTepxsBTbTS7iI8fnHau+QaBqiTB01F14jBwC9lg WRP9hweVkRAK2WXZ6dgL7V7riC9vv41XxBb9CZXJRgYLcLRuqXx0bopYPHbOnItUmf t8s2RVVcHH1xTH0WQQoTOXwhlYLaLGf2/jsFC2Oew/ET737RTsO28tj/R6nEToaOgU 8B+CWGh/LtkPeQN83dywLjyTyYDw7KxqSxJGLy3+Nj/mWRMyY/hV+i7AktlySvUoqw J/kkA5ipQzhxBYxIBtwNyXvjo+wYrsQpfWqBcJQFbVPC2JMLQGYiPxh1aoP9uF7bFR EhqkCuXI4YG5Q== Message-ID: <547F37B4.8050509@massar.ch> Date: Wed, 03 Dec 2014 17:17:56 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: "Templin, Fred L" References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <2134F8430051B64F815C691A62D9831832DA992F@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832DA992F@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/zQA1XtCfbeNSvXIZ3hFy8MBZyHE Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 16:18:12 -0000 On 2014-12-03 17:04, Templin, Fred L wrote: [..] > 6rd is not perfect, because it clamps the MTU to something less than 1500. > Tunnels should not clamp the MTU, such that 1500s make it through > deterministically and 1501+ are allowed to sink or swim on their own. I do still do not see why that a MTU of < 1500 but >1280 is a limitation in any way. Note that most 6rd deployments have a MTU of 1480 (just the IPv4 overhead) and thus even if you would have 10 layers of IPv6 tunneling happening you would be completely fine. Greets, Jeroen From nobody Wed Dec 3 08:20: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 631BD1A6FF2 for ; Wed, 3 Dec 2014 08:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 OfL6OPjvQwep for ; Wed, 3 Dec 2014 08:20:23 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974981A6FAD for ; Wed, 3 Dec 2014 08:20:15 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 05AD320E4D for ; Wed, 3 Dec 2014 11:20:14 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 03 Dec 2014 11:20:15 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=Hrxp6Ur7zmKTsI6t7j37I0 jIw1k=; b=PZ8AQrdVM2oP3baqEGUsaje0UCCvHh3yq5NYXjj14P9lgXFifCwr6D m9q6sQnftrFWL9frQQ1movcTcrVypz49b2YOBNrbfW9XMQtnhvbQ8bO9PD8xhD51 OFohvT2Slx715fIXRCOdRuWPPGEnw07Z4eE6lzlLOCMgJXz+MzVl0= X-Sasl-enc: odxehASpQBPD9LHroZQm8O6Smxwdhi3nDmrezBMZY2Os 1417623614 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 9509CC0027D; Wed, 3 Dec 2014 11:20:14 -0500 (EST) Message-ID: <547F3831.50408@network-heretics.com> Date: Wed, 03 Dec 2014 11:20:01 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Jeroen Massar , v6ops@ietf.org References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <547F3218.4060101@network-heretics.com> <547F3710.50106@massar.ch> In-Reply-To: <547F3710.50106@massar.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HrpKSC_ce9pKVVmHJQmlL41Jdwk Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 16:20:27 -0000 On 12/03/2014 11:15 AM, Jeroen Massar wrote: > On 2014-12-03 16:54, Keith Moore wrote: >> On 12/03/2014 08:25 AM, Jeroen Massar wrote: >>> Which demographic of users need this? >> Every user who doesn't have native IPv6 access at every one of the >> locations from which he accesses the Internet. >> >> Because IPv6 won't be a viable replacement for IPv4 until users can >> access it everywhere. And in the near term, that means being able to >> access it from anywhere that currently has IPv4. > That demographic of users are signing up to tunnel brokers and VPN > providers. No, they're not, because it's just too obscure and painful for most people. We need something that can be easily configured, that OS vendors can ship as part of their products, that works with the local ISP when it provides that service. In short we need something that ordinary users can have enabled by default and it "just works". Adding additional hoops that users have to jump through is effectively just a form of hostility to IPv6 deployment. Keith From nobody Wed Dec 3 08:21: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 5410E1A6FFD for ; Wed, 3 Dec 2014 08:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 bJZeslq5l709 for ; Wed, 3 Dec 2014 08:21:09 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC9C01A70FE for ; Wed, 3 Dec 2014 08:20:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sB3GKsEm013409; Wed, 3 Dec 2014 08:20:54 -0800 Received: from XCH-PHX-311.sw.nos.boeing.com (xch-phx-311.sw.nos.boeing.com [130.247.25.171]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sB3GKoox013366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 3 Dec 2014 08:20:50 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-PHX-311.sw.nos.boeing.com ([169.254.11.161]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 08:20:49 -0800 From: "Templin, Fred L" To: Tim Chown Thread-Topic: [v6ops] Report: Bar BoF on a 6to4 replacement Thread-Index: AQHQDmAH0I/jfXJhYUW2sj/c/ybqPJx8qrzwgAGrlID//64HQIAAiu2A//97WLCAAIgFAP//eo8g Date: Wed, 3 Dec 2014 16:20:49 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DA9A1D@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832DA990C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832DA99B0@XCH-BLV-504.nw.nos.boeing.com> <1C337B0C-5949-401D-AB65-9AD750ED8C9C@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/0p8dLBkG1UuRddGuMo3zELd8DsY Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 16:21:13 -0000 Hi Tim, > -----Original Message----- > From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] > Sent: Wednesday, December 03, 2014 8:18 AM > To: Templin, Fred L > Cc: Iljitsch van Beijnum; v6ops@ietf.org > Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement >=20 > On 3 Dec 2014, at 16:13, Templin, Fred L wrot= e: >=20 > > Hi Tim, > > > >> -----Original Message----- > >> From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] > >> Sent: Wednesday, December 03, 2014 8:05 AM > >> To: Templin, Fred L > >> Cc: Iljitsch van Beijnum; v6ops@ietf.org > >> Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement > >> > >> On 3 Dec 2014, at 16:01, Templin, Fred L w= rote: > >>> > >>> I am interested in an ISP-independent tunnel service solution. So, th= e tunnel service > >>> would accept tunneled packets coming from an arbitrary ISP even thoug= h it is not in > >>> any way associated with that ISP. For that, the device needs to be en= rolled with the > >>> tunnel service provider. > >> > >> What will this give functionally that a tunnel broker does not? > > > > Route optimization, distributed mobility management, traffic engineerin= g, security, > > multi-access handovers (e.g., WiFi/Cellular), routing control, etc. >=20 >=20 > Seems to be a plan to cure all ills with one pill :) Yes. > Is this proposal also including 6-in-6? Yes. Any IP-in-IP protocol version combination is fine. Thanks - Fred fred.l.templin@boeing.com > Tim From nobody Wed Dec 3 08:23: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 4DD281A1BAA for ; Wed, 3 Dec 2014 08:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 hcuzr_YhmtjB for ; Wed, 3 Dec 2014 08:23:37 -0800 (PST) Received: from na6sys009bog037.obsmtp.com (na6sys009bog037.obsmtp.com [74.125.150.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75C61A89A4 for ; Wed, 3 Dec 2014 08:21:37 -0800 (PST) Received: from mail-qc0-f182.google.com ([209.85.216.182]) (using TLSv1) by na6sys009bob037.postini.com ([74.125.148.12]) with SMTP ID DSNKVH84kI1E6bMKIgEbwJ2NLR7t0da5ri9V@postini.com; Wed, 03 Dec 2014 08:21:37 PST Received: by mail-qc0-f182.google.com with SMTP id r5so11146997qcx.41 for ; Wed, 03 Dec 2014 08:21:36 -0800 (PST) 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=4aSncLxO697zm8Gl9XbRc4L4lezTdURtmeZ8ytx4UIc=; b=iASISWcEVdeZbm4/Qv6Bm5YCtEQIg5qHw9Mb5iEPwHwLaHMe4zRI+s+QNSKwAaj0cH 1+NzHWE3PC/H2xankFE0KIgke4Gs+xkuRYi5CUxE98hKmEkPNVGzocdcH0I6VTRdeHoA lkKYVfhrsKgk7mlyiWhkV9sd3NGGnSdlq0489ehSfaVa85Lka+5w88keZFgM9vbsdK1e btNH92KvGUNRFl68U5jKNEH1ABCjXRAbPXoIcGbwWiaTYFfYcByEBeTpWus276CcyGrM oti10gO84ZrY3I6IP/gBitIoqOef9hrbYaDMXHgGwlL3jL9Ci0Qxhe+pT83M/KlrKd6Y tXew== X-Gm-Message-State: ALoCoQmjiQcGR/BXfL9mTN2VBuX62wklysG1622tv9MvCtevCAusKBT+m7AD3SXkSZ8QdgfWVIfvVtRZbsNN3l9xX67H6a0NCPVaHtzIy3bxMJil/xyuXu3cyQzu81e183ij59iJiexS X-Received: by 10.229.190.71 with SMTP id dh7mr9037721qcb.5.1417623696678; Wed, 03 Dec 2014 08:21:36 -0800 (PST) X-Received: by 10.229.190.71 with SMTP id dh7mr9037708qcb.5.1417623696562; Wed, 03 Dec 2014 08:21:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.97.136 with HTTP; Wed, 3 Dec 2014 08:21:16 -0800 (PST) In-Reply-To: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DF397F1@ITSNT440.iowa.uiowa.edu> References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <93034721-BA1A-45C5-A3F5-0838DE3DB3FE@delong.com> <547EC5A9.8010603@massar.ch> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DF397F1@ITSNT440.iowa.uiowa.edu> From: John Mann Date: Thu, 4 Dec 2014 03:21:16 +1100 Message-ID: To: "Metzler, Dan J" Content-Type: multipart/alternative; boundary=001a11336ab6dbf53a0509523ce4 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/EI5jy8g3O7w7q8P1mx6IhwYAQ5Q Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? 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, 03 Dec 2014 16:23:42 -0000 --001a11336ab6dbf53a0509523ce4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On 3 December 2014 at 22:41, Metzler, Dan J wrote: > Hi, > > > > A few thoughts=E2=80=A6 > > > > =E2=80=98After dual-stack IPv6 was enabled on most subnets, protocol 41 a= nd > Teredo were blocked at Monash's Internet border on 15-Jun-2011. I don't > recall anyone ever asking for it to be re-enabled.=E2=80=99 > > - Not necessarily a problem, =E2=80=9CIF=E2=80=9D Monash does no= t provide > internet access to other ISPs. If it does, then were they all dual-stack > IPv6 enabled? If not then I would point out that this broke IPv6 service > for some downstream customers of those ISPs. The only reason for an ISP = to > turn off Teredo and protocol 41 is if all downstream customers have acces= s > to native IPv6 connectivity, and even then that decision is questionable. > Yes, you are right. Monash does provide Internet transit for some downstream organisations. I only blocked protocol 41 and Teredo for Monash's IP address ranges. - It is unlikely that anyone would ask for it to be re-enabled. > They would more likely incorrectly assume that IPv6 is broken and disable > it. The reason for this is that the vast majority of people, who were > affected by this, likely would not have had the technical skill to trace = it > back to Monash. Before they ever got to that point someone would likely > tell them to disable IPv6, or all tunneling protocols thus completing the > breakage of their IPv6 connectivity. > I don't see how blocking tunnel protocols at Monash's border impacts any user or server outside Monash ... Users/servers outside Monash can still use 6to4 or Teredo tunnels -- if those tunnels terminate outside Monash somewhere. Monash users with native IPv6 and would not have needed any tunneling for general Internet access. Only Monash users could have been affected by the block, called our Helpdesk with "The Internet is slow", been triaged, and got through to people with technical skills. The people who could have wanted tunnels re-enabled might be e.g. - a student with a NAT home router in their dorm room who wants to get to some IPv6 service (over Teredo) [ Mind you, a PC at Monash behind NAT -> Teredo gateway in Seattle -> Web server at Monash on public IPv6 and back was about 400ms RTT. ] > =E2=80=98I assert that the time of "experimental" IPv6 has passed. IPv6= should > be a "production" service.=E2=80=99 > > - 100% agreed! > > > > =E2=80=98If the IPv6 network service isn't almost as good (due to reliabi= lity or > RTTs or whatever) as IPv4, > > turn it off until you can do it right.=E2=80=99 > > - Noooooooooooo. > > - If the IPv6 network service isn=E2=80=99t almost as good (due = to > reliability or RTTs or whatever), and it is under your control to fix it, > then please fix it. > > - If it isn=E2=80=99t under your control, then communicate it to= your > ISP or the offending party and ask them to fix it. > > - =E2=80=9CTurn it off=E2=80=9D is the wrong answer, though prob= ably the more > popular answer. Turning it off breaks it more completely than it was wit= h > poor performance. > Perhaps I wasn't clear. I was talking as the operator of the network service. By "turn it off" I meant "disable IPv6 on their local subnet router interface; don't let IPv6 RAs get to the user's devices". We do actively work on fixing IPv6 problems. But some vendors can take many years and many attempts before they get IPv6 support up to approximate feature and performance parity with IPv4. In the meantime, we disable the "IPv6 network service" so that users don't have a bad network experience and then have to disable IPv6 in their devices to get stuff done. And the users never learn that disabling IPv6 can sometimes fix problems. Thanks, John --001a11336ab6dbf53a0509523ce4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

On 3 December 2014 at 22:41, Metzler, Dan J <dan-metzler@uiowa.= edu> wrote:

Hi,

=C2=A0

A few thoughts=E2=80=A6=

=C2=A0

=E2=80=98After dual-stack IPv6 was en= abled on most subnets, protocol 41 and Teredo were blocked at Monash's = Internet border=C2=A0on 15-Jun-2011.=C2=A0 I don't recall anyone ever asking for it to be re-enabled.=E2=80=99=

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Not necessarily a problem, =E2=80=9CIF=E2=80=9D= Monash does not provide internet access to other ISPs.=C2=A0 If it does, t= hen were they all dual-stack IPv6 enabled?=C2=A0 If not then I would point = out that this broke IPv6 service for some downstream customers of those ISPs.=C2=A0 The only reason for an ISP to turn off Teredo and pro= tocol 41 is if all downstream customers have access to native IPv6 connecti= vity, and even then that decision is questionable.


Yes, you are right.=C2=A0 Monash does provide Inter= net transit for some downstream organisations.
I only blocked pro= tocol 41 and Teredo for Monash's IP address ranges.

<= p>

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 It is unlikely that anyone would ask for it to = be re-enabled.=C2=A0 They would more likely incorrectly assume that IPv6 is= broken and disable it.=C2=A0 The reason for this is that the vast majority= of people, who were affected by this, likely would not have had the technical skill to trace it back to Monash.= =C2=A0 Before they ever got to that point someone would likely tell them to= disable IPv6, or all tunneling protocols thus completing the breakage of t= heir IPv6 connectivity.


I don't see how blocking tunnel protocols at Monash's border impa= cts any user or server outside Monash ...
Users/servers out= side Monash can still use 6to4 or Teredo tunnels -- if those tunnels termin= ate outside Monash somewhere.

Monash users with na= tive IPv6 and would not have needed any tunneling for general Internet acce= ss.
Only Monash users could have been affected by the block, call= ed our Helpdesk with "The Internet is slow",
been triag= ed, and got through to people with technical skills.

The people who could have wanted tunnels re-enabled might be e.g.
<= div>- a student with a NAT home router in their dorm room who wants to get = to some IPv6 service (over Teredo)
=C2=A0 [ Mind you, a PC at Mon= ash behind NAT -> Teredo gateway in Seattle -> Web server at Monash o= n public IPv6 and back =C2=A0was about 400ms RTT. ]
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">

=E2=80=98I assert that the time of "experimenta= l" IPv6 has passed.=C2=A0 IPv6 should be a "production" serv= ice.=E2=80=99

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 100% agreed!

=C2=A0

=E2=80=98If the IPv6 network service isn't almos= t as good (due to reliability or RTTs or whatever) as IPv4,

turn it off until you can do it right.=E2=80=99

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Noooooooooooo.=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 If the IPv6 network service isn=E2=80=99t almos= t as good (due to reliability or RTTs or whatever), and it is under your co= ntrol to fix it, then please fix it.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 If it isn=E2=80=99t under your control, then co= mmunicate it to your ISP or the offending party and ask them to fix it.<= /u>

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =E2=80=9CTurn it off=E2=80=9D is the wrong answ= er, though probably the more popular answer.=C2=A0 Turning it off breaks it= more completely than it was with poor performance.


Perhaps I wasn't clear.=C2=A0 I was talking as= the operator of the network service.=C2=A0
By "turn it off&= quot; I meant "disable IPv6 on their local subnet router interface; do= n't let IPv6 RAs get to the user's devices".

We do actively work on fixing IPv6 problems.
But some ven= dors can take many years and many attempts before they get IPv6 support up = to approximate feature and performance parity with IPv4.

In the meantime, we disable the "IPv6 network service" so = that users don't have a bad network experience and then have to disable= IPv6 in their devices to get stuff done.=C2=A0 And the users never learn t= hat disabling IPv6 can sometimes fix problems.

Tha= nks,
=C2=A0 =C2=A0 John
--001a11336ab6dbf53a0509523ce4-- From nobody Wed Dec 3 08:25: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 610F01A89B3 for ; Wed, 3 Dec 2014 08:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 qEFv-l0dRWPK for ; Wed, 3 Dec 2014 08:25:43 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2A51A889F for ; Wed, 3 Dec 2014 08:24:04 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 38BBC100AB8BE; Wed, 3 Dec 2014 16:24:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417623842; bh=kxfZLdSfUHJOnocwFx/wH9Md0vj8DUo+bdiaHsV+av4=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=AJyybpi/tT+B4LGHBoEtJ7Dmua5Qp94aFLAGcUy0LdVTyVsBfaHa4VsBcv5+7MC+0 OiCjv6GggGPSybdG1rZAY1CS4y7RmAOzsDp8KH8zdb2ehIqc8W7KMMva5ydA1MdLF+ JkjVHv3asU1w7rfCj8Wyn2vpVyVJzHg9uiifjnjaVizY5bMeFcD21Ja3CE/Ox255qY 1XPa8i4qdmgFpUGIgprxTQjdQQysADP82SeHS/gwEqJZrK7aEP43ZSw7fh5Vlq083g xjoh8bDSC+rQNFxu3NuG7Com7R2t51zKDm0U4Z1z8ixFKNY0m5BVQTyKAgn6twRyM0 cOA571WemJMQQ== Message-ID: <547F3920.4060304@massar.ch> Date: Wed, 03 Dec 2014 17:24:00 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: "Templin, Fred L" , Tim Chown References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832DA990C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832DA99B0@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832DA99B0@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/gIIrTvOrmE5lhk8Wd0BxQ9mO-zw Cc: "v6ops@ietf.org" Subject: [v6ops] AERO again (Was: Report: Bar BoF on a 6to4 replacement) 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, 03 Dec 2014 16:25:48 -0000 On 2014-12-03 17:13, Templin, Fred L wrote: > Hi Tim, > >> -----Original Message----- >> From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] >> Sent: Wednesday, December 03, 2014 8:05 AM >> To: Templin, Fred L >> Cc: Iljitsch van Beijnum; v6ops@ietf.org >> Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement >> >> On 3 Dec 2014, at 16:01, Templin, Fred L wrote: >>> >>> I am interested in an ISP-independent tunnel service solution. So, the tunnel service >>> would accept tunneled packets coming from an arbitrary ISP even though it is not in >>> any way associated with that ISP. For that, the device needs to be enrolled with the >>> tunnel service provider. >> >> What will this give functionally that a tunnel broker does not? > > Route optimization, This seems to be listed, but your "AERO" documents do not describe it at all how this could ever work in practice let alone what the positive outcome would be. If any type of it will work, it will still be limited to the single ASN unless you convince other ASNs to be part of your network policy, at which point that is a single ASN. > distributed mobility management, As every node in such a network would need to know about it, when will this collapse? Something about scalability, which also goes for the previous point. > traffic engineering But you also have "route optimization", who controls this then? > security, What kind of "security"? > multi-access handovers (e.g., WiFi/Cellular) Most VPN protocols handle this perfectly already. > routing control, etc. Is that not the same or in contrast to your "Route optimization" point? Greets, Jeroen From nobody Wed Dec 3 08:26: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 B87E31A1BAA for ; Wed, 3 Dec 2014 08:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 sh3H6kFbVNZN for ; Wed, 3 Dec 2014 08:25:48 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B8E1A6FD7 for ; Wed, 3 Dec 2014 08:24:06 -0800 (PST) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:dd3e:fec4:32df:4dd0] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sB3GNe9V015705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Dec 2014 17:23:40 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Iljitsch van Beijnum In-Reply-To: <547F3710.50106@massar.ch> Date: Wed, 3 Dec 2014 17:23:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6232201E-04E1-484E-A21D-F20A44FD5AAC@muada.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <547F3218.4060101@network-heretics.com> <547F3710.50106@massar.ch> To: Jeroen Massar X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/W4ppxGzzHwpLw6XUlPidAXzIvIU Cc: IPv6 Operations Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 16:25:55 -0000 On 03 Dec 2014, at 17:15, Jeroen Massar wrote: > My ISP put me behind DSLite and I cannot access my home network > anymore, getting an IPv6 tunnel solves that. ??? DS-lite is IPv4 over IPv6, so DS-lite users would already have native = IPv6... > As such, please list the requirements that those folks need and how > these requirements are not being met with existing solutions. Anyone who is behind a (CG) NAT that doesn't allow for incoming = connections for peer-to-peer applications such as VoIP and video chat. Yes, those users could use an existing tunnel broker. But most of those = users have no idea how to install a tun0 device.= From nobody Wed Dec 3 08: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 7AC6D1A1B3F for ; Wed, 3 Dec 2014 08:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 IppAju-GuP-1 for ; Wed, 3 Dec 2014 08:29:00 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AAEE1A1DBD for ; Wed, 3 Dec 2014 08:28:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sB3GSFbL003356; Wed, 3 Dec 2014 08:28:15 -0800 Received: from XCH-BLV-508.nw.nos.boeing.com (xch-blv-508.nw.nos.boeing.com [130.247.25.198]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sB3GSBIp003307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 3 Dec 2014 08:28:11 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-BLV-508.nw.nos.boeing.com ([169.254.8.240]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 08:28:11 -0800 From: "Templin, Fred L" To: Jeroen Massar Thread-Topic: [v6ops] Report: Bar BoF on a 6to4 replacement Thread-Index: AQHQDmAH0I/jfXJhYUW2sj/c/ybqPJx8qrzwgAGrlICAAAxJgP//pYdAgACKoAD//3rOUA== Date: Wed, 3 Dec 2014 16:28:10 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <2134F8430051B64F815C691A62D9831832DA992F@XCH-BLV-504.nw.nos.boeing.com> <547F37B4.8050509@massar.ch> In-Reply-To: <547F37B4.8050509@massar.ch> 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/sYop2KN8Q4gkck4vTcALRGpHZas Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 16:29:02 -0000 Hi Jeroen, > -----Original Message----- > From: Jeroen Massar [mailto:jeroen@massar.ch] > Sent: Wednesday, December 03, 2014 8:18 AM > To: Templin, Fred L > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement >=20 > On 2014-12-03 17:04, Templin, Fred L wrote: > [..] > > 6rd is not perfect, because it clamps the MTU to something less than 15= 00. > > Tunnels should not clamp the MTU, such that 1500s make it through > > deterministically and 1501+ are allowed to sink or swim on their own. >=20 > I do still do not see why that a MTU of < 1500 but >1280 is a limitation > in any way. Hosts have become conditioned to expect 1500. So, if they send a 1500 and it gets dropped but no ICMP PTB message comes back it black holes. > Note that most 6rd deployments have a MTU of 1480 (just the IPv4 > overhead) and thus even if you would have 10 layers of IPv6 tunneling > happening you would be completely fine. How do the other layers of tunnels know what to clamp their MTUs to? Since it would be tunnels over IPv6, the first inner tunnel would have to know that it needs to clamp is MTU to 1440. Then, the next inner tunnel would have to know that it needs to clamp its MTU to 1400, etc. How can nested tunnels so carefully clamp their MTUs when ICMPs may be lost? Unless some single administrative authority is very carefully managing each tunnel, I think they can't. On the other hand, tunnels that always provide an assured 1500 recurse indefinitely. Those that clamp the MTU cannot. Thanks - Fred fred.l.templin@boeing.com > Greets, > Jeroen From nobody Wed Dec 3 08:34: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 96E411A1BDF for ; Wed, 3 Dec 2014 08:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 LoIyAdZyFSn3 for ; Wed, 3 Dec 2014 08:34:23 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF5D1A1B7B for ; Wed, 3 Dec 2014 08:34:21 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 504C21007CD28; Wed, 3 Dec 2014 16:34:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417624459; bh=/UJ5N1mVXNIetVatHoO4zMYFsJGBagU2KxTujm2EmVc=; h=Date:From:To:Subject:References:In-Reply-To; b=G6z0c/9mT/bijdhiwXEJK0SwI42TsbmyjRr/AGt2OgzM/RJFiOwaGeMv9i/C2pvXi 2wAL4k1DxthYQqJoss9INihawbvP9LqnDWCBDPh+x7B4RTcbzj+IrxuwnfOY2sMweM w/Tx5/uxTUn4sEZFBI6xDRJ19mSZcJ9aKQfPWarBBVaehx80K8GIhzohJAgZCTO2nU Baou0dFJOGE82BgP2OZCLwuRlrFVXPhOG6Zp99DlAEza2U29/g87RqINOSPjFbxpx6 W7VtPQETEIL9f9xOkkR8s3Wj78XJfWVs9h42ZOU6nLMO14609RPpdtjAkysT9hBBCu 1QEDzLhfQ4cog== Message-ID: <547F3B8A.3020805@massar.ch> Date: Wed, 03 Dec 2014 17:34:18 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Keith Moore , v6ops@ietf.org References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <547F3218.4060101@network-heretics.com> <547F3710.50106@massar.ch> <547F3831.50408@network-heretics.com> In-Reply-To: <547F3831.50408@network-heretics.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BrDLCUzyC3avB2gW9PGEC6Cmlz0 Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 16:34:27 -0000 On 2014-12-03 17:20, Keith Moore wrote: > On 12/03/2014 11:15 AM, Jeroen Massar wrote: >> On 2014-12-03 16:54, Keith Moore wrote: >>> On 12/03/2014 08:25 AM, Jeroen Massar wrote: >>>> Which demographic of users need this? >>> Every user who doesn't have native IPv6 access at every one of the >>> locations from which he accesses the Internet. >>> >>> Because IPv6 won't be a viable replacement for IPv4 until users can >>> access it everywhere. And in the near term, that means being able to >>> access it from anywhere that currently has IPv4. >> That demographic of users are signing up to tunnel brokers and VPN >> providers. > No, they're not, because it's just too obscure and painful for most > people. "Most people". Interesting choice of words. Please note that in a lot of countries due to 'legal restrictions' and other paranoia a lot of people are signing up for VPN services. It happens a lot and they just click them together. Also please describe in detail how tunnel brokers are "obscure". google(I want IPv6) gives you a LOT of details. Even http://cs.brown.edu/~adf/cerf/ pops up ;) and of course https://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers Also note that most of the better tech magazines have detailed point by point instructions on how to get IPv6 connectivity for well over a decade. I have a stack of copies of these kind of articles where SixXS was featured in and where other Tunnel Brokers where described in too. And describe how they are "painful" for most people. If you actually want to resolve those points, you'll have to come with a lot more detail for anybody to be able to look at your problem. > We need something that can be easily configured, that OS > vendors can ship as part of their products, that works with the local > ISP when it provides that service. That is called native IPv6. And otherwise IPv6 over PPP(oE) or things like 6rd. Anything else would require further cooperation. If those ISPs wanted to deliver IPv6 they would be doing so. As they are obviously not, choose with your money and go elsewhere if you want it from them. > In short we need something that > ordinary users can have enabled by default and it "just works". Please also note that "just works" does not exist. > Adding > additional hoops that users have to jump through is effectively just a > form of hostility to IPv6 deployment. Simple question: how did you sign up for your IPv4 service? Indeed, you needed to sign up for that, likely sign some paper work, get a device installed etc. Oh, and remember the hell that was to get it all working when it was still Trumpet Winsock over a modem connection? :) As that ISP is not providing your with IPv6, you will need to do the same if you want IPv6 from another service provider. Greets, Jeroen (who did do a IPv6 tunnel over 28k8 back then ;) From nobody Wed Dec 3 08:36: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 5A38B1A1B6A for ; Wed, 3 Dec 2014 08:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 SlIzcYm3ZIjV for ; Wed, 3 Dec 2014 08:36:41 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 7D60B1A1BA4 for ; Wed, 3 Dec 2014 08:36:33 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 19C7660288 for ; Wed, 3 Dec 2014 17:36:31 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id D7206600AD for ; Wed, 3 Dec 2014 17:36:30 +0100 (CET) Received: (qmail 68899 invoked by uid 1007); 3 Dec 2014 17:36:30 +0100 Date: Wed, 3 Dec 2014 17:36:30 +0100 From: Gert Doering To: Keith Moore Message-ID: <20141203163630.GA28745@Space.Net> References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F3761.4040506@network-heretics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <547F3761.4040506@network-heretics.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HttBGW7EeFiA9xR0n6s-Qz7iVVc Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 03 Dec 2014 16:36:47 -0000 Hi, On Wed, Dec 03, 2014 at 11:16:33AM -0500, Keith Moore wrote: > Instead of standardizing more and more kludges to IPv4, we should be > working toward moving IPv4 to Historic. Wouldn't that break 6to4? 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 Dec 3 08:37: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 C05861A6F11 for ; Wed, 3 Dec 2014 08:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 ICXQyuP-rcWU for ; Wed, 3 Dec 2014 08:37:55 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2208B1A1B70 for ; Wed, 3 Dec 2014 08:37:55 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id D5287100AB8BE; Wed, 3 Dec 2014 16:37:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417624672; bh=w8pc/4RSvIhysQZ5Oyw2ZumfZXxEQBhYGoGQifrBHYY=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=Yr7nvz0FWDmpoWwZnkxoa0JPkrGS2HBMg4U8bFiit0yKfVWF6YebHnw2jzUMZdb3a Q2Vsm3c1xdm4S6gIlvZDknGDGvC2AINjZUFacV0ggnakmw5qpjzAw54Ha/MCrfRqVN GjIyb1eIxJhfCE/KLfcKvTU6/Ftt2pZ2uLakUVaORHE6C7115BcIpSz3k1za5CfqLY w5LRiSl3PhhDZW2BhXjvnCUqsUpdwzJwAzimCR4MVgvlWysCpqKJ7WukCWwWtG57H7 ZWbpAoPzzqX12vJSqu3gB21bW1eZkDpeL9f2+1saLW9CfTVc3QLLc8mUVtJcuJe5yL +mzqs9rKLhXyQ== Message-ID: <547F3C5F.7070403@massar.ch> Date: Wed, 03 Dec 2014 17:37:51 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Iljitsch van Beijnum References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <547F3218.4060101@network-heretics.com> <547F3710.50106@massar.ch> <6232201E-04E1-484E-A21D-F20A44FD5AAC@muada.com> In-Reply-To: <6232201E-04E1-484E-A21D-F20A44FD5AAC@muada.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VRqPlyqnxnjnlsna-OsHku0zFQ0 Cc: IPv6 Operations Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 16:37:56 -0000 On 2014-12-03 17:23, Iljitsch van Beijnum wrote: > On 03 Dec 2014, at 17:15, Jeroen Massar wrote: > >> My ISP put me behind DSLite and I cannot access my home network >> anymore, getting an IPv6 tunnel solves that. > > ??? > > DS-lite is IPv4 over IPv6, so DS-lite users would already have native > IPv6... Yes. Exactly why I recently had to write: https://www.sixxs.net/news/2014/#tunnelsanddslite-1008 to explain the nice misconceptions a lot of folks have. (they think they get IPv4 back with an IPv6 tunnel...) Note that people want an IPv6 tunnel for *OTHER* locations. Eg their parents who do have IPv4-only (possibly behind (CG)NAT) or their Android phone. >> As such, please list the requirements that those folks need and >> how these requirements are not being met with existing solutions. > > Anyone who is behind a (CG) NAT that doesn't allow for incoming > connections for peer-to-peer applications such as VoIP and video > chat. > > Yes, those users could use an existing tunnel broker. But most of > those users have no idea how to install a tun0 device. They do not need to know about that... apt-get install aiccu ? or: https://play.google.com/store/apps/details?id=de.flyingsnail.ipv6droid Greets, Jeroen (yes, the windows edition does suck installer wise...) From nobody Wed Dec 3 08:39: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 B73B11A1EF3 for ; Wed, 3 Dec 2014 08:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 QupyfuUbX_lx for ; Wed, 3 Dec 2014 08:39:50 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 6C0251A1BEC for ; Wed, 3 Dec 2014 08:39:50 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 570D560352 for ; Wed, 3 Dec 2014 17:39:48 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id E6B37600BD for ; Wed, 3 Dec 2014 17:39:47 +0100 (CET) Received: (qmail 69050 invoked by uid 1007); 3 Dec 2014 17:39:47 +0100 Date: Wed, 3 Dec 2014 17:39:47 +0100 From: Gert Doering To: "Templin, Fred L" Message-ID: <20141203163947.GB28745@Space.Net> References: <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <2134F8430051B64F815C691A62D9831832DA992F@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2134F8430051B64F815C691A62D9831832DA992F@XCH-BLV-504.nw.nos.boeing.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/p856VjJezZTiveQOHXPxRJlcSrc Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 16:39:51 -0000 Hi, On Wed, Dec 03, 2014 at 04:04:01PM +0000, Templin, Fred L wrote: > 6rd is not perfect, because it clamps the MTU to something less than 1500. It doesn't have to. If the transport network providing the 6rd service (remember that this is inside a well-controlled ISP network, not "arbitrary Internet") provides larger-than-1500 MTU, there is no reason why 6rd cannot have 1500. 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 Dec 3 08:40: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 208A21A8734 for ; Wed, 3 Dec 2014 08:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7] 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 QvI5V_wzbjFg for ; Wed, 3 Dec 2014 08:40:12 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D3A71A1B47 for ; Wed, 3 Dec 2014 08:40:12 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id DEBC8100AB8BE; Wed, 3 Dec 2014 16:40:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417624809; bh=CzPfTS6i+vq+Xp4qNwvXsr+7Jm9nt/+CNDr5o8iWCCk=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=j2ODMArBPDVC5W2pW72lVfX8aGrSXmJd5pm1tspLob1Nym4V1mQAVV0t4rdDUG1DG qaUUwCSyhHbDjmaClRhHNCnrQjPNAdQUd7Wtr6m/nUnlLAZrnU879wOGMkdnNCZuXt pX8FG2R/5ncV0ennw6y4gdkn9k9wUtrPPI63+r+v5VMyg+yhhT//esU+6D8Ss+I1FS CSnvZRUEltkf5QuPIi0NVNnRhucdbdxYNqb/O+smjDlLAa6le1oqCt3ISEIE+U2eSS JQBBREuNpcGD8Ljb8vDIpoh06pf2H3h9QEik/S4EWUDXhoIMWtzuKggbteWZgOJFlr af1YW76X96tYQ== Message-ID: <547F3CE8.4090302@massar.ch> Date: Wed, 03 Dec 2014 17:40:08 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: "Templin, Fred L" References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <2134F8430051B64F815C691A62D9831832DA992F@XCH-BLV-504.nw.nos.boeing.com> <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/F_Fqbm90R-rCUJaASePG5B--XMI Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 16:40:14 -0000 On 2014-12-03 17:28, Templin, Fred L wrote: > Hi Jeroen, > >> -----Original Message----- >> From: Jeroen Massar [mailto:jeroen@massar.ch] >> Sent: Wednesday, December 03, 2014 8:18 AM >> To: Templin, Fred L >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement >> >> On 2014-12-03 17:04, Templin, Fred L wrote: >> [..] >>> 6rd is not perfect, because it clamps the MTU to something less than 1500. >>> Tunnels should not clamp the MTU, such that 1500s make it through >>> deterministically and 1501+ are allowed to sink or swim on their own. >> >> I do still do not see why that a MTU of < 1500 but >1280 is a limitation >> in any way. > > Hosts have become conditioned to expect 1500. Which hosts? Most IPv4 nodes are connected with a LOT less... > So, if they send a > 1500 and it gets dropped but no ICMP PTB message comes back it > black holes. Then configure your network properly. Also, do not create tunnels over paths that do not pass the packet size your are sending. I think I mentioned that in another thread before... >> Note that most 6rd deployments have a MTU of 1480 (just the IPv4 >> overhead) and thus even if you would have 10 layers of IPv6 tunneling >> happening you would be completely fine. > > How do the other layers of tunnels know what to clamp their MTUs > to? By configuring them properly? > Since it would be tunnels over IPv6, the first inner tunnel would > have to know that it needs to clamp is MTU to 1440. Then, the next > inner tunnel would have to know that it needs to clamp its MTU to > 1400, etc. How can nested tunnels so carefully clamp their MTUs when > ICMPs may be lost? Unless some single administrative authority is very > carefully managing each tunnel, I think they can't. As you are so set on having tunnels inside tunnels, you are creating that problem for yourself. Word of advise: do not do that... Greets, Jeroen From nobody Wed Dec 3 08:40: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 B45D41A1B47 for ; Wed, 3 Dec 2014 08:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 Z9T-e4ZQG53D for ; Wed, 3 Dec 2014 08:40:40 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1F61A88C4 for ; Wed, 3 Dec 2014 08:40:40 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id F0E72100AB8BE; Wed, 3 Dec 2014 16:40:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417624838; bh=rJgVI8X7lid1zkjdS3KxYDHPMeTeEY8LNgaIaW/ryb4=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=dyV56A7GR2n3A2C7vy06QFFafVIf0BurNggN2IHkn8HdiZmQD1NqxQLOgwPG6/oPK nMhi4xNwIwYj7/3WIZbLsiKwtd/27G7H/HEp+Zp/qPZGuuYq18L2y1+dqvdr3hPDIX 7hNLDHEIHUPITpeGFamF/EBY+gs5YC+QKE/UrWpB6GIDwWuV1N6odJBAILh7sxw86P uEwBDSggSF8BdjXUTDKoH6N1OtmR8H3//v9Tw9UXhURbFuzwL1tXSN7bwjshTfm682 6rUn0oXzD+sypZYsaCqgc6VObFkDxQ81BrD5dZhW4y+zkZ4GfOyRlGB06Rp31S+byD 6oNoAheNyvMCg== Message-ID: <547F3D04.703@massar.ch> Date: Wed, 03 Dec 2014 17:40:36 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Gert Doering References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F3761.4040506@network-heretics.com> <20141203163630.GA28745@Space.Net> In-Reply-To: <20141203163630.GA28745@Space.Net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/utWqkCuSdoyjMZoxkFHxh0g7DDQ Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 03 Dec 2014 16:40:44 -0000 On 2014-12-03 17:36, Gert Doering wrote: > Hi, > > On Wed, Dec 03, 2014 at 11:16:33AM -0500, Keith Moore wrote: >> Instead of standardizing more and more kludges to IPv4, we should be >> working toward moving IPv4 to Historic. > > Wouldn't that break 6to4? Oeh, that was an open door ;) Greets, Jeroen From nobody Wed Dec 3 08:43: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 1CC391A1BA4 for ; Wed, 3 Dec 2014 08:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 KgQjTIA8cyrT for ; Wed, 3 Dec 2014 08:43:56 -0800 (PST) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34E5F1A1B47 for ; Wed, 3 Dec 2014 08:43:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sB3GhtIx025147; Wed, 3 Dec 2014 08:43:55 -0800 Received: from XCH-BLV-303.nw.nos.boeing.com (xch-blv-303.nw.nos.boeing.com [130.247.25.215]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sB3GhjGR024974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 3 Dec 2014 08:43:45 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-BLV-303.nw.nos.boeing.com ([169.254.3.145]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 08:43:45 -0800 From: "Templin, Fred L" To: Jeroen Massar , Tim Chown Thread-Topic: AERO again (Was: Report: Bar BoF on a 6to4 replacement) Thread-Index: AQHQDxhNpETdbxj1gkOr9KAwwnJvQg== Date: Wed, 3 Dec 2014 16:43:44 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DA9B64@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832DA990C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832DA99B0@XCH-BLV-504.nw.nos.boeing.com> <547F3920.4060304@massar.ch> In-Reply-To: <547F3920.4060304@massar.ch> 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/9bREVCt8jF1EJzlJ3-Sun5-SPOQ Cc: "v6ops@ietf.org" Subject: Re: [v6ops] AERO again (Was: Report: Bar BoF on a 6to4 replacement) 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, 03 Dec 2014 16:43:58 -0000 Hi Jeroen, > -----Original Message----- > From: Jeroen Massar [mailto:jeroen@massar.ch] > Sent: Wednesday, December 03, 2014 8:24 AM > To: Templin, Fred L; Tim Chown > Cc: v6ops@ietf.org > Subject: AERO again (Was: Report: Bar BoF on a 6to4 replacement) >=20 > On 2014-12-03 17:13, Templin, Fred L wrote: > > Hi Tim, > > > >> -----Original Message----- > >> From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] > >> Sent: Wednesday, December 03, 2014 8:05 AM > >> To: Templin, Fred L > >> Cc: Iljitsch van Beijnum; v6ops@ietf.org > >> Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement > >> > >> On 3 Dec 2014, at 16:01, Templin, Fred L w= rote: > >>> > >>> I am interested in an ISP-independent tunnel service solution. So, th= e tunnel service > >>> would accept tunneled packets coming from an arbitrary ISP even thoug= h it is not in > >>> any way associated with that ISP. For that, the device needs to be en= rolled with the > >>> tunnel service provider. > >> > >> What will this give functionally that a tunnel broker does not? > > > > Route optimization, >=20 > This seems to be listed, but your "AERO" documents do not describe it at > all how this could ever work in practice let alone what the positive > outcome would be. You must not be reading the documents I am writing. "Route Optimization" is hard-coded in the name AERO, and well specified in the spec. > If any type of it will work, it will still be limited to the single ASN > unless you convince other ASNs to be part of your network policy, at > which point that is a single ASN. The ASN for intra-ASN route optimization is the tunnel serve provider's ASN; not the ASN (or ASNs) from which the node receives its basic Internet services. But, AERO also supports inter-ASN route optimization such that an AERO node associated with ASN1 can perform route optimization to talk directly to an AERO node associated with ASN2.=20 > > distributed mobility management, >=20 > As every node in such a network would need to know about it, when will > this collapse? Something about scalability, which also goes for the > previous point. The AERO tunnel service provider can deploy hundreds or even thousands of AERO Servers, and AERO Clients will receive the same service whichever Server they associate with. But, with mobility always comes deaggregation, and the AERO Relays (running an ASN-internal instance of BGP) can handle probably up to about 1M deaggregated prefixes. That is a lot of mobile node= s.=20 > > traffic engineering >=20 > But you also have "route optimization", who controls this then? AERO Clients can register multiple underlying ISP connections with their AERO Servers. So, the AERO Server can accept packets coming from more than one of the Client's ISPs. The Client can then do outbound traffic engineering by sending certain packet types over certain ISP connections, and it can tell the Server how to do inbound route optimization over the multiple ISP connections. > > security, >=20 > What kind of "security"? Many kinds. Data origin authentication is all that is needed for nodes with= in the same enterprise network trust domain. Authenticated route optimizations in the same spirit as MIPv6 return routability. Cryptographic signatures fo= r environments where such are required. IPsec where we need really strong security, etc. > > multi-access handovers (e.g., WiFi/Cellular) >=20 > Most VPN protocols handle this perfectly already. While still retaining a single, stable mobile network prefix for the Client= ?=20 > > routing control, etc. >=20 > Is that not the same or in contrast to your "Route optimization" point? Routing control in order to facilitate Route optimization. Routing control = is needed by route optimization, but the converse is not true. Thanks - Fred fred.l.templin@boeing.com > Greets, > Jeroen From nobody Wed Dec 3 08:48: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 5F72C1A8999 for ; Wed, 3 Dec 2014 08:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 CXD5ksO5DmGI for ; Wed, 3 Dec 2014 08:48:25 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8259C1A895A for ; Wed, 3 Dec 2014 08:48:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sB3GmDXY028132; Wed, 3 Dec 2014 08:48:13 -0800 Received: from XCH-BLV-106.nw.nos.boeing.com (xch-blv-106.nw.nos.boeing.com [130.247.25.122]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sB3Gm3Je027588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 3 Dec 2014 08:48:04 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-BLV-106.nw.nos.boeing.com ([169.254.6.176]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 08:48:03 -0800 From: "Templin, Fred L" To: Gert Doering Thread-Topic: [v6ops] Report: Bar BoF on a 6to4 replacement Thread-Index: AQHQDmAH0I/jfXJhYUW2sj/c/ybqPJx8qrzwgAGrlICAAAxJgP//pYdAgACQu4D//3s9QA== Date: Wed, 3 Dec 2014 16:48:02 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DA9B81@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <2134F8430051B64F815C691A62D9831832DA992F@XCH-BLV-504.nw.nos.boeing.com> <20141203163947.GB28745@Space.Net> In-Reply-To: <20141203163947.GB28745@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/lCtAX9L44YHX1u5ToMgDGYLecoA Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 16:48:29 -0000 Hi Gert, > -----Original Message----- > From: Gert Doering [mailto:gert@Space.Net] > Sent: Wednesday, December 03, 2014 8:40 AM > To: Templin, Fred L > Cc: Jeroen Massar; Iljitsch van Beijnum; v6ops@ietf.org > Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement >=20 > Hi, >=20 > On Wed, Dec 03, 2014 at 04:04:01PM +0000, Templin, Fred L wrote: > > 6rd is not perfect, because it clamps the MTU to something less than 15= 00. >=20 > It doesn't have to. If the transport network providing the 6rd service > (remember that this is inside a well-controlled ISP network, not > "arbitrary Internet") provides larger-than-1500 MTU, there is no reason > why 6rd cannot have 1500. We are now talking about IPv4 link MTUs being perfectly managed. If they are, then great. But, all it takes is one mis-configured link MTU to bring down the whole house of cards. And, anything that can be configured can be mis-configured. thanks - Fred fred.l.templin@boeing.com =20 > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Dec 3 08:54: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 B9FC51A89A3 for ; Wed, 3 Dec 2014 08:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 m-d4DygF-F1E for ; Wed, 3 Dec 2014 08:54:05 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 473D11A899B for ; Wed, 3 Dec 2014 08:54:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sB3Gs4N9006012; Wed, 3 Dec 2014 08:54:05 -0800 Received: from XCH-PHX-113.sw.nos.boeing.com (xch-phx-113.sw.nos.boeing.com [130.247.25.136]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sB3GrsRi005883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 3 Dec 2014 08:53:54 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-PHX-113.sw.nos.boeing.com ([169.254.13.175]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 08:53:54 -0800 From: "Templin, Fred L" To: Jeroen Massar Thread-Topic: [v6ops] Report: Bar BoF on a 6to4 replacement Thread-Index: AQHQDmAH0I/jfXJhYUW2sj/c/ybqPJx8qrzwgAGrlICAAAxJgP//pYdAgACKoAD//3rOUIAAi2YA//98S8A= Date: Wed, 3 Dec 2014 16:53:53 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DA9BBB@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <2134F8430051B64F815C691A62D9831832DA992F@XCH-BLV-504.nw.nos.boeing.com> <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> In-Reply-To: <547F3CE8.4090302@massar.ch> 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/i7MbTFGC54mQXOBwUD-Ar-pR4Do Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 16:54:09 -0000 Hi Jeroen, > -----Original Message----- > From: Jeroen Massar [mailto:jeroen@massar.ch] > Sent: Wednesday, December 03, 2014 8:40 AM > To: Templin, Fred L > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement >=20 > On 2014-12-03 17:28, Templin, Fred L wrote: > > Hi Jeroen, > > > >> -----Original Message----- > >> From: Jeroen Massar [mailto:jeroen@massar.ch] > >> Sent: Wednesday, December 03, 2014 8:18 AM > >> To: Templin, Fred L > >> Cc: v6ops@ietf.org > >> Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement > >> > >> On 2014-12-03 17:04, Templin, Fred L wrote: > >> [..] > >>> 6rd is not perfect, because it clamps the MTU to something less than = 1500. > >>> Tunnels should not clamp the MTU, such that 1500s make it through > >>> deterministically and 1501+ are allowed to sink or swim on their own. > >> > >> I do still do not see why that a MTU of < 1500 but >1280 is a limitati= on > >> in any way. > > > > Hosts have become conditioned to expect 1500. >=20 > Which hosts? Most IPv4 nodes are connected with a LOT less... Not on my networks they aren't. Go to any host on WiFi or Ethernet and you will see 1500 (either IPv4 or IPv6). > > So, if they send a > > 1500 and it gets dropped but no ICMP PTB message comes back it > > black holes. >=20 > Then configure your network properly. Again, a house of cards. > Also, do not create tunnels over paths that do not pass the packet size > your are sending. You create tunnels over whatever path with no pre-conceived notion of what MTUs the links in those paths support. All you can be reasonably assured of is 1280 bytes for IPv6 and 68 bytes for IPv4. > I think I mentioned that in another thread before... >=20 >=20 >=20 > >> Note that most 6rd deployments have a MTU of 1480 (just the IPv4 > >> overhead) and thus even if you would have 10 layers of IPv6 tunneling > >> happening you would be completely fine. > > > > How do the other layers of tunnels know what to clamp their MTUs > > to? >=20 > By configuring them properly? See below. > > Since it would be tunnels over IPv6, the first inner tunnel would > > have to know that it needs to clamp is MTU to 1440. Then, the next > > inner tunnel would have to know that it needs to clamp its MTU to > > 1400, etc. How can nested tunnels so carefully clamp their MTUs when > > ICMPs may be lost? Unless some single administrative authority is very > > carefully managing each tunnel, I think they can't. >=20 > As you are so set on having tunnels inside tunnels, you are creating > that problem for yourself. >=20 > Word of advise: do not do that... Nested mobile networks need tunnels-within-tunnels. Anyone who VPNs into their corporate network from their home network (supported by a tunnel) needs tunnels-within-tunnels. We need support for tunnels that recurse indefinitely, because sure as dawn breaking someone is going to do it. Thanks - Fred fred.l.templin@boeing.com > Greets, > Jeroen From nobody Wed Dec 3 08:57: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 011F41A1B72 for ; Wed, 3 Dec 2014 08:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 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_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 oOl_zZsnPhOj for ; Wed, 3 Dec 2014 08:57:54 -0800 (PST) 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 5DA571A1B3A for ; Wed, 3 Dec 2014 08:57:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 72C3C56; Wed, 3 Dec 2014 17:57:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= references:message-id:content-transfer-encoding:date:date :in-reply-to:x-mailer:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1417625866; bh=yeg3W2e92Skksejv/vmMjbp+wl/kEFuBnZ+wO3irrnE=; b=N MGvKezSwGzE4D0eazBjK7LqBJ5VA3neWPcHCj1iISMd5UQjAuhMejHnS5cF77+Qa kEPu2G7F+KLkEvp7d2laejl9Vufp9AaeVTegDlzj4AaH3gE6FIiGmgGQS6kNrkvw N90TTJ3/Ir7B9DfkzG1wBLNK3ywmMcwQOHnnE365dE= 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 10026) with ESMTP id SYLiFEakD7di; Wed, 3 Dec 2014 17:57:46 +0100 (CET) Received: from [100.71.0.52] (unknown [188.207.64.0]) by mail.sintact.nl (Postfix) with ESMTPSA id 5707F45; Wed, 3 Dec 2014 17:57:46 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Sander Steffann X-Mailer: iPhone Mail (12B436) In-Reply-To: <547F3631.7060606@globis.net> Date: Wed, 3 Dec 2014 17:57:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> To: Ray Hunter Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/pCukLE5yNWggQJmflzBmkrUZe44 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 03 Dec 2014 16:57:56 -0000 Hi, > Why would the IETF want to put an approved "standard track" marking on wha= t is a very clever but horrible kludge? Because with the IPv4 addresses running out horrible kludges are unfortunate= ly necessary and putting the best of them on standards track is the best ava= ilable option. Cheers, Sander From nobody Wed Dec 3 08:59: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 A108B1A1BAA for ; Wed, 3 Dec 2014 08:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 uQqoKquFoEEl for ; Wed, 3 Dec 2014 08:59:03 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 E2D481A1B81 for ; Wed, 3 Dec 2014 08:59:02 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 221BE60755 for ; Wed, 3 Dec 2014 17:59:01 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id D20D460288 for ; Wed, 3 Dec 2014 17:59:00 +0100 (CET) Received: (qmail 72424 invoked by uid 1007); 3 Dec 2014 17:59:00 +0100 Date: Wed, 3 Dec 2014 17:59:00 +0100 From: Gert Doering To: "Templin, Fred L" Message-ID: <20141203165900.GE28745@Space.Net> References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <2134F8430051B64F815C691A62D9831832DA992F@XCH-BLV-504.nw.nos.boeing.com> <20141203163947.GB28745@Space.Net> <2134F8430051B64F815C691A62D9831832DA9B81@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mLbp0C4cUABvzcHb" Content-Disposition: inline In-Reply-To: <2134F8430051B64F815C691A62D9831832DA9B81@XCH-BLV-504.nw.nos.boeing.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Un-UE5H78Ghkveofi_v3zViLaOs Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 16:59:04 -0000 --mLbp0C4cUABvzcHb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Dec 03, 2014 at 04:48:02PM +0000, Templin, Fred L wrote: > > On Wed, Dec 03, 2014 at 04:04:01PM +0000, Templin, Fred L wrote: > > > 6rd is not perfect, because it clamps the MTU to something less than = 1500. > >=20 > > It doesn't have to. If the transport network providing the 6rd service > > (remember that this is inside a well-controlled ISP network, not > > "arbitrary Internet") provides larger-than-1500 MTU, there is no reason > > why 6rd cannot have 1500. >=20 > We are now talking about IPv4 link MTUs being perfectly managed. If they > are, then great. But, all it takes is one mis-configured link MTU to bring > down the whole house of cards. And, anything that can be configured > can be mis-configured. Different can of worms. Of course misconfiguration happens, but that doesn= 't make the statement "6rd clamps the MTU to something less than 1500" any more valid. It doesn't. =20 "6rd over infrastructure with IPv4 MTU smaller than 1520 clamps the MTU to= =20 less than 1500", that is obviously true, but a very different statement. 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 --mLbp0C4cUABvzcHb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVH9BVN9WwGXkzn/FAQI44g//cG8PCr9rnF2ZBVIVxXGkY02hOkMUVws7 zSadywpYYQ7nRVXhMnlsTz8TzDWLatUm9dI40VBiys6Eo8ipmESKc707Og4ArpTJ eq88s6fswcalwxmKHfIACCNiF1KcMEbipxHM20j2WBkCPmcd2yycAbTOWtZRKffQ kYaAiySu+mxtBd2gJlryLPgyj2Dd/OWBkw6b+q1gEhMrw13cZtSWixYA5a8/Xbqq tPf+9zo+9FqxnzxGOdOXo99fnsr9jz83SdKoqVqqu1yUEL/eqHpZXqarJ5hPUqPq OBycTXzGjuAzc3seo70NdQKq997pgT8kvcb5OPPasxZ6Dkl6ZjPXWYbAfaTKBqQV Y1QigfvImzgCGI078SUUOeFFV+RSGmV5pRD54voWkq5Z6daXEC5p9RiSHAOxg/PV QPYABNfPH9PoxFoX/UJ9PiJJ1WNJqcAhMbO3cLUtczfMFRK2HOxDVbynqAHKfM0Z 2lQ7AyvFyhubVO7OBO/J2hzPZpzwgstHLsxWAqAUuPyu0w5g/z5fVxH+Xd+S4m3x hkIgE0aIzf6sAY10N8VGkjcWBNgMEonpr+U70e3ewXq+z5Xnc0qrwszfgrV+KuXH sJszA7IHQXk4m1P1LMCenoFZGQHo85pjmXRgmKzYIM6Puerfq//JwzLAdnvtp+8B Qm5cdYchero= =7lDU -----END PGP SIGNATURE----- --mLbp0C4cUABvzcHb-- From nobody Wed Dec 3 09:01: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 F201C1A89C6 for ; Wed, 3 Dec 2014 09:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 NIbd5eiOmdvt for ; Wed, 3 Dec 2014 09:01:41 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3566B1A8954 for ; Wed, 3 Dec 2014 09:01:35 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 4884B21383 for ; Wed, 3 Dec 2014 12:01:34 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 03 Dec 2014 12:01:34 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type; s= smtpout; bh=ObeiTRyVJNLHXLLJZ3dqGWN+Bmo=; b=hClie4bXZgetnoTVNIIX 0dF8c1L8cOqZTor+SpkG1aS3FSVXgtl14FdlssWei/cU3sHEtbr7dF3PPnLty1n/ vVPoejMlcgjzB6ZOCZKhrXXpaRp/kpccaO4zDo+lGeyu9XBOIgs6z8xNoRT7PucX 0k1ZR6FCkkrKZuj1urUssI0= X-Sasl-enc: iW84aHHn1zhWrL2bMUBOY2ip1/WbxkS+QW3+bOznqJqh 1417626093 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 71112C00286; Wed, 3 Dec 2014 12:01:33 -0500 (EST) Message-ID: <547F41E0.1090303@network-heretics.com> Date: Wed, 03 Dec 2014 12:01:20 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Jeroen Massar , v6ops@ietf.org References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <547F3218.4060101@network-heretics.com> <547F3710.50106@massar.ch> <547F3831.50408@network-heretics.com> <547F3B8A.3020805@massar.ch> In-Reply-To: <547F3B8A.3020805@massar.ch> Content-Type: multipart/alternative; boundary="------------020004050401090606060908" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HBhh5BlrNTmfbmyEf_zmcvHubGE Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 17:01:44 -0000 This is a multi-part message in MIME format. --------------020004050401090606060908 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 12/03/2014 11:34 AM, Jeroen Massar wrote: > On 2014-12-03 17:20, Keith Moore wrote: >> On 12/03/2014 11:15 AM, Jeroen Massar wrote: >>> On 2014-12-03 16:54, Keith Moore wrote: >>>> On 12/03/2014 08:25 AM, Jeroen Massar wrote: >>>>> Which demographic of users need this? >>>> Every user who doesn't have native IPv6 access at every one of the >>>> locations from which he accesses the Internet. >>>> >>>> Because IPv6 won't be a viable replacement for IPv4 until users can >>>> access it everywhere. And in the near term, that means being able to >>>> access it from anywhere that currently has IPv4. >>> That demographic of users are signing up to tunnel brokers and VPN >>> providers. >> No, they're not, because it's just too obscure and painful for most >> people. > "Most people". Interesting choice of words. It's only interesting because the solutions you seem to propose are not suitable for most people, even though we want everyone (not just "most people") to migrate to IPv6. > Also please describe in detail how tunnel brokers are "obscure". I'm not going to play that game. But if you want to collect data yourself, poll N randomly selected Internet users and ask them if they understand what "tunnel broker" means or how to set one up. > Also note that most of the better tech magazines have detailed point by > point instructions on how to get IPv6 connectivity for well over a > decade. Most users do not read "better tech magazines". You seem to have this strange idea that IPv6 is for techies only. > And describe how they are "painful" for most people. If the option to enable v6 connectivity doesn't appear in the user's computer's or router's Settings / Control Panel / whatever screen, and it can't be automatically configured using information from PPP or DHCP, it's too painful for most people. Current options other than 6to4 typically require users to install new software and learn new things, perhaps multiple layers of new things, in order to use them. > > If you actually want to resolve those points, you'll have to come with a > lot more detail for anybody to be able to look at your problem. I don't need to get other people to look at "my" problem. (which is the Internet's problem even if some people don't realize it) I'm quite capable of doing the protocol design work or assisting with it and willing to make that effort. What I'm looking for now is just assistance in defining the problem. >> We need something that can be easily configured, that OS >> vendors can ship as part of their products, that works with the local >> ISP when it provides that service. > That is called native IPv6. Native IPv6 is the desired end point. But the idea that people are going to use IPv6 on a widespread basis before it's effectively available /everywhere/ is just delusional. So your presumed deployment model assumes that all providers of IP service will just upgrade to IPv6 voluntarily. Even if most ISPs do that, I don't think most hotels, coffee shops, airports, etc. that provide wifi access are going to eagerly do that. What's much more likely is that they'll just replace their equipment as it fails, and if the new equipment supports IPv6, and their ISP supports IPv6, it will work. And these are vital parts of Internet infrastructure. And until IPv6 access is ubiquitous via some means, applications will still be stuck using the same extremely dysfunctional (and constantly getting worse) IPv4 Internet. > >> In short we need something that >> ordinary users can have enabled by default and it "just works". > Please also note that "just works" does not exist. Nope. It only results from good design, good network implementation, good operation, etc. "just works" is only a user perception, but it's absolutely the perception that users should have. >> Adding >> additional hoops that users have to jump through is effectively just a >> form of hostility to IPv6 deployment. > Simple question: how did you sign up for your IPv4 service? On the most recent occasion, I spent weeks trying to find a provider that would give me a static IP address and not filter my traffic, more weeks trying to get the link and their router configured properly to deliver the service that they promised me. Why do you ask? > Oh, and remember the hell that was to get it all working when it was > still Trumpet Winsock over a modem connection? :) Even then I knew better than to use Windows, but I do remember those days. What is your point? That getting Internet service is supposed to be painful? Or that users should have to go through every bit as much pain to enable IPv6 as they did to get IPv4 access? Keith --------------020004050401090606060908 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 12/03/2014 11:34 AM, Jeroen Massar wrote:
On 2014-12-03 17:20, Keith Moore wrote:

On 12/03/2014 11:15 AM, Jeroen Massar wrote:

On 2014-12-03 16:54, Keith Moore wrote:

On 12/03/2014 08:25 AM, Jeroen Massar wrote:

Which demographic of users need this?

Every user who doesn't have native IPv6 access at every one of the
locations from which he accesses the Internet.

Because IPv6 won't be a viable replacement for IPv4 until users can
access it everywhere.   And in the near term, that means being able to
access it from anywhere that currently has IPv4.

That demographic of users are signing up to tunnel brokers and VPN
providers.

No, they're not, because it's just too obscure and painful for most
people.

"Most people". Interesting choice of words.

It's only interesting because the solutions you seem to propose are not suitable for most people, even though we want everyone (not just "most people") to migrate to IPv6.

Also please describe in detail how tunnel brokers are "obscure".

I'm not going to play that game.   But if you want to collect data yourself, poll N randomly selected Internet users and ask them if they understand what "tunnel broker" means or how to set one up.  

Also note that most of the better tech magazines have detailed point by
point instructions on how to get IPv6 connectivity for well over a
decade.

Most users do not read "better tech magazines".

You seem to have this strange idea that IPv6 is for techies only.  

And describe how they are "painful" for most people.

If the option to enable v6 connectivity doesn't appear in the user's computer's or router's Settings / Control Panel / whatever screen, and it can't be automatically configured using information from PPP or DHCP, it's too painful for most people.   Current options other than 6to4 typically require users to install new software and learn new things, perhaps multiple layers of new things, in order to use them.


If you actually want to resolve those points, you'll have to come with a
lot more detail for anybody to be able to look at your problem.

I don't need to get other people to look at "my" problem.   (which is the Internet's problem even if some people don't realize it)    I'm quite capable of doing the protocol design work or assisting with it and willing to make that effort.   What I'm looking for now is just assistance in defining the problem.

We need something that can be easily configured, that OS
vendors can ship as part of their products, that works with the local
ISP when it provides that service.

That is called native IPv6.

Native IPv6 is the desired end point.   But the idea that people are going to use IPv6 on a widespread basis before it's effectively available everywhere is just delusional.   So your presumed deployment model assumes that all providers of IP service will just upgrade to IPv6 voluntarily.   Even if most ISPs do that, I don't think most hotels, coffee shops, airports, etc. that provide wifi access are going to eagerly do that.   What's much more likely is that they'll just replace their equipment as it fails, and if the new equipment supports IPv6, and their ISP supports IPv6, it will work.   And these are vital parts of Internet infrastructure.  And until IPv6 access is ubiquitous via some means, applications will still be stuck using the same extremely dysfunctional (and constantly getting worse) IPv4 Internet. 



In short we need something that
ordinary users can have enabled by default and it "just works".

Please also note that "just works" does not exist.

Nope.  It only results from good design, good network implementation, good operation, etc.   "just works" is only a user perception, but it's absolutely the perception that users should have.
Adding
additional hoops that users have to jump through is effectively just a
form of hostility to IPv6 deployment.

Simple question: how did you sign up for your IPv4 service?

On the most recent occasion, I spent weeks trying to find a provider that would give me a static IP address and not filter my traffic, more weeks trying to get the link and their router configured properly to deliver the service that they promised me.   Why do you ask?

Oh, and remember the hell that was to get it all working when it was
still Trumpet Winsock over a modem connection? :)

Even then I knew better than to use Windows, but I do remember those days.  What is your point?   That getting Internet service is supposed to be painful?   Or that users should have to go through every bit as much pain to enable IPv6 as they did to get IPv4 access?  

Keith

--------------020004050401090606060908-- From nobody Wed Dec 3 09:02: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 A63881A89B3 for ; Wed, 3 Dec 2014 09:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 JeWFVieG_-Gq for ; Wed, 3 Dec 2014 09:02:05 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59CF21A89F9 for ; Wed, 3 Dec 2014 09:01:58 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id BDA24213A6 for ; Wed, 3 Dec 2014 12:01:57 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 03 Dec 2014 12:01:57 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=kBsUyrtz8UYjPq3fQ7FyOk xLqn8=; b=u6onjd/b2FqXPXCU7T+H6HmZijdYxUVnFAAM8LsawgF8zkI3YvdNZn aQ2je+EA7+TO1EwQfBPCXwGeIXax1bUJbc+WTDlaFCr5/5AhSnHHiJ9y4Pttm7XF 5zSNSE7Gq3ueQBwQ4YmM7NA1FarEJRb0uDm2WTDt7UyUEZ8LzEyPk= X-Sasl-enc: C2Xfp0StYkotYhpVcA/HPTqabBJj7cUhd79kIezsNcNT 1417626117 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 54AC1C00285; Wed, 3 Dec 2014 12:01:57 -0500 (EST) Message-ID: <547F41F8.8010607@network-heretics.com> Date: Wed, 03 Dec 2014 12:01:44 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Gert Doering References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F3761.4040506@network-heretics.com> <20141203163630.GA28745@Space.Net> In-Reply-To: <20141203163630.GA28745@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-ds4K4G4Hq59ZCUBB1-5exninUI Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 03 Dec 2014 17:02:10 -0000 On 12/03/2014 11:36 AM, Gert Doering wrote: > Hi, > > On Wed, Dec 03, 2014 at 11:16:33AM -0500, Keith Moore wrote: >> Instead of standardizing more and more kludges to IPv4, we should be >> working toward moving IPv4 to Historic. > Wouldn't that break 6to4? Yes. In the best possible way. Keith From nobody Wed Dec 3 09:03: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 EFA7A1A89FC for ; Wed, 3 Dec 2014 09:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 yobGJvLWkOlM for ; Wed, 3 Dec 2014 09:03:38 -0800 (PST) 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 6F6371A89F0 for ; Wed, 3 Dec 2014 09:03:38 -0800 (PST) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=60802 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1XwDKt-0000Lc-EU; Wed, 03 Dec 2014 18:03:31 +0100 Date: Wed, 3 Dec 2014 18:03:30 +0100 From: Tore Anderson To: Gert Doering Message-ID: <20141203180330.0989438a@envy.fud.no> In-Reply-To: <20141203163947.GB28745@Space.Net> References: <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <2134F8430051B64F815C691A62D9831832DA992F@XCH-BLV-504.nw.nos.boeing.com> <20141203163947.GB28745@Space.Net> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wVI_AZ_ejnYIK1zudn-TZnd1Ag0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 17:03:41 -0000 * Gert Doering > On Wed, Dec 03, 2014 at 04:04:01PM +0000, Templin, Fred L wrote: > > 6rd is not perfect, because it clamps the MTU to something less > > than 1500. > > It doesn't have to. If the transport network providing the 6rd > service (remember that this is inside a well-controlled ISP network, > not "arbitrary Internet") provides larger-than-1500 MTU, there is no > reason why 6rd cannot have 1500. Actually, since 6RD is stateless, the BRs have no way of knowing if any given CE will support 1520 octets long mini-jumbos. So unless the ISP somehow forbinds the user from bringing his own CE, it pretty much has to assume 1500 bytes is the largest that can be relied upon to work. In any case, the use case for 6RD is typically an ISP with a bunch of rusty old DSLAMs or whatever that just can't support IPv6, and those probably don't support mini-jumbos any better... FWIW, the only ISP in Norway that has 6RD does TCP MSS clamping at the BR as well as ensuring their own CEs advertise a LAN MTU of 1480 to limit the inevitable PMTUD problems. That makes it work sufficiently well. Tore From nobody Wed Dec 3 09:06: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 E99E41A8A42 for ; Wed, 3 Dec 2014 09:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7] 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 au81sSHbcQaI for ; Wed, 3 Dec 2014 09:05:55 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 718771A8A49 for ; Wed, 3 Dec 2014 09:05:43 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 738B01007F627; Wed, 3 Dec 2014 17:05:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417626340; bh=HvDgjh0nlbY5TczI5H/RInUWUqnYtL5ipAwhgWBmcmQ=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=AY/OP64eScTAokW8CQD8nw2ndNzO0c4VAZj/EcW1+4lpCUcwipTC4cdtwI0Idk6Fg qcQHwtUnoJiwzvB/7goqA5qIGqCuGQF3Ji2XAwe0i+qqSmfGHnT5tbh4tCEETLJuze BPsSvQO2ITzYPgkrmaRZn8oYGU7tN7Ue9Z//s6uBVrGp1ewm7SVFUnEuT/thdnc5QU EMf5Kr9VsFywkgbXfCMh+2OxgQYYtKjMQqYLk70ZUOB8TssVzo0dUtNrKUt4cle4ZW RBtTY6EF/DxE3Izv4V0lPT7xAnY0HUgIzNCO6A4h3IhUpX6THfyB1cwe23ECCsvmiZ lkKL1AtZOjc6A== Message-ID: <547F42E3.3080508@massar.ch> Date: Wed, 03 Dec 2014 18:05:39 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: "Templin, Fred L" References: <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <2134F8430051B64F815C691A62D9831832DA992F@XCH-BLV-504.nw.nos.boeing.com> <20141203163947.GB28745@Space.Net> <2134F8430051B64F815C691A62D9831832DA9B81@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832DA9B81@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2UScyTGg-rypp3PbmjIOBK3iask Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 17:06:00 -0000 On 2014-12-03 17:48, Templin, Fred L wrote: [..] >> On Wed, Dec 03, 2014 at 04:04:01PM +0000, Templin, Fred L wrote: >>> 6rd is not perfect, because it clamps the MTU to something less than 1500. >> >> It doesn't have to. If the transport network providing the 6rd service >> (remember that this is inside a well-controlled ISP network, not >> "arbitrary Internet") provides larger-than-1500 MTU, there is no reason >> why 6rd cannot have 1500. > > We are now talking about IPv4 link MTUs being perfectly managed. If they > are, then great. In a provider network this is the case. There is no other case where 6rd can be deployed. > But, all it takes is one mis-configured link MTU to bring > down the whole house of cards. And, anything that can be configured > can be mis-configured. There is no magic bullet for those situations unless you do probing. And if you on misconfigure things then even probing will not solve that problem. On 2014-12-03 17:53, Templin, Fred L wrote: > Hi Jeroen, [..] >>> Hosts have become conditioned to expect 1500. >> >> Which hosts? Most IPv4 nodes are connected with a LOT less... > > Not on my networks they aren't. Go to any host on WiFi or Ethernet > and you will see 1500 (either IPv4 or IPv6). And then check one hop further and the hop behind that and bingo, not 1500 any more, the reason why it is called Path MTU. But lets take an actual number from what SixXS users configure by looking at the MTU statistics: https://www.sixxs.net/misc/mtu/ Note that most people (94.78%) do not bother to change it as 1280 works perfectly fine for them. The rest has a range of anything in between with 47.70% of the folks who do change it forcing it to 1480, which is the maximum they can as they indeed have a 1500 MTU link. The 1472 is likely all the tunnels with AYIYA overhead. As shown though some people chose to set it as low as 1281; no idea why they do that. We even have a nice FAQ article about how to determine the MTU: https://www.sixxs.net/faq/connectivity/?faq=mtu Note that this is indeed manual, but as the numbers show, only few people see a big need to change their MTU. >>> So, if they send a >>> 1500 and it gets dropped but no ICMP PTB message comes back it >>> black holes. >> >> Then configure your network properly. > > Again, a house of cards. Well, your network. And really, stating "house of cards" but wanting to do multiple tunnels inside tunnels, ouch... >> Also, do not create tunnels over paths that do not pass the packet size >> your are sending. > > You create tunnels over whatever path with no pre-conceived notion > of what MTUs the links in those paths support. All you can be reasonably > assured of is 1280 bytes for IPv6 and 68 bytes for IPv4. But that is the fun thing with Tunnel Brokers. They default at 1280 and allow users to configure them higher when the path allows. And 1280 always works it seems: never heard anybody complain in the near 15 years that we got SixXS (+IPng.nl) up and running about that. [..] > Nested mobile networks need tunnels-within-tunnels. They only need them because you are chosing that. I can only suggest to chose something different that is a better solution. > Anyone who VPNs > into their corporate network from their home network (supported by a > tunnel) needs tunnels-within-tunnels. No. They only need 1 tunnel over their existing IPv4 infrastructure. I really do not see a second tunnel there. Though you could do a IPv6 tunnel over that of course if your VPN still does not support IPv6 "natively" in the tunnel. > We need support for tunnels that recurse indefinitely, because sure as > dawn breaking someone is going to do it. It seems you are determined to do so. My position remains though: avoid it! Something about a house of cards and especially the fun of debugging all of that. Greets, Jeroen From nobody Wed Dec 3 09:08: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 0B3111A1BE6 for ; Wed, 3 Dec 2014 09:08:38 -0800 (PST) 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 EwIkni7GugY0 for ; Wed, 3 Dec 2014 09:08:33 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E807B1A1E0B for ; Wed, 3 Dec 2014 09:08:04 -0800 (PST) Received: by mail-qg0-f49.google.com with SMTP id a108so11171993qge.22 for ; Wed, 03 Dec 2014 09:08:04 -0800 (PST) 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=6ihuVTppPxmKlaXDXMbmr3PlnQTd2nNJo7jS89uJrn4=; b=o/ldKMmEz/QMBpzNrVj1RJFdE8ignRjfMXu25CQNmHItJScAP6ByvlDd4CNzr7B+WF WdQ7kCHBWFlF29OYl3Ol4BsiObvRW+KWQ7WFhp12KyefLMt8XMXjnE5gDiVjmUb2CAR5 RHWSm/UKQl/wU6rg1c9uyDlBMtD59gnvaTH8J0LrmfT1PULpDjomjkCGDBhEqYvvGY8B lJyJ8/FABK4FIgQW+sNRR4AcXC+6NDS0JCsILw5+fSskPQYOwLMZJ43CIhvjsPcQ9xZ5 piHuOM5a7kfUzHqedfNwofHX5GFclI10lpL6LbJ1NUvm+4NNYP5S9XRzPvPZbIPU3Dj5 DomA== X-Received: by 10.229.106.71 with SMTP id w7mr9350347qco.11.1417626484067; Wed, 03 Dec 2014 09:08:04 -0800 (PST) Received: from ?IPv6:2001:13c7:7001:7000:81f5:9d1c:201b:65dc? ([2001:13c7:7001:7000:81f5:9d1c:201b:65dc]) by mx.google.com with ESMTPSA id 9sm7025437qah.46.2014.12.03.09.08.01 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Dec 2014 09:08:02 -0800 (PST) Message-ID: <547F436C.6030901@gmail.com> Date: Wed, 03 Dec 2014 15:07:56 -0200 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Keith Moore , Jeroen Massar , v6ops@ietf.org References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <547F3218.4060101@network-heretics.com> <547F3710.50106@massar.ch> <547F3831.50408@network-heretics.com> <547F3B8A.3020805@massar.ch> <547F41E0.1090303@network-heretics.com> In-Reply-To: <547F41E0.1090303@network-heretics.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mb_sVDB839xgT4TqqfEZr3NsAJI Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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: Wed, 03 Dec 2014 17:08:38 -0000 Apologies for top posting, but I don't think the demographics is limited to those who are using tunnel brokers. It's offering operators who are stuck with non-IPv6 compliant equipment in their networks an alternative with basically the strengths of 6rd and addresses its weaknesses. regards Carlos. On 12/3/2014 3:01 PM, Keith Moore wrote: > On 12/03/2014 11:34 AM, Jeroen Massar wrote: >> On 2014-12-03 17:20, Keith Moore wrote: >>> On 12/03/2014 11:15 AM, Jeroen Massar wrote: >>>> On 2014-12-03 16:54, Keith Moore wrote: >>>>> On 12/03/2014 08:25 AM, Jeroen Massar wrote: >>>>>> Which demographic of users need this? >>>>> Every user who doesn't have native IPv6 access at every one of the >>>>> locations from which he accesses the Internet. >>>>> >>>>> Because IPv6 won't be a viable replacement for IPv4 until users can >>>>> access it everywhere. And in the near term, that means being able to >>>>> access it from anywhere that currently has IPv4. >>>> That demographic of users are signing up to tunnel brokers and VPN >>>> providers. >>> No, they're not, because it's just too obscure and painful for most >>> people. >> "Most people". Interesting choice of words. > > It's only interesting because the solutions you seem to propose are not > suitable for most people, even though we want everyone (not just "most > people") to migrate to IPv6. > >> Also please describe in detail how tunnel brokers are "obscure". > > I'm not going to play that game. But if you want to collect data > yourself, poll N randomly selected Internet users and ask them if they > understand what "tunnel broker" means or how to set one up. > >> Also note that most of the better tech magazines have detailed point by >> point instructions on how to get IPv6 connectivity for well over a >> decade. > > Most users do not read "better tech magazines". > > You seem to have this strange idea that IPv6 is for techies only. > >> And describe how they are "painful" for most people. > > If the option to enable v6 connectivity doesn't appear in the user's > computer's or router's Settings / Control Panel / whatever screen, and > it can't be automatically configured using information from PPP or DHCP, > it's too painful for most people. Current options other than 6to4 > typically require users to install new software and learn new things, > perhaps multiple layers of new things, in order to use them. > >> >> If you actually want to resolve those points, you'll have to come with a >> lot more detail for anybody to be able to look at your problem. > > I don't need to get other people to look at "my" problem. (which is > the Internet's problem even if some people don't realize it) I'm > quite capable of doing the protocol design work or assisting with it and > willing to make that effort. What I'm looking for now is just > assistance in defining the problem. > >>> We need something that can be easily configured, that OS >>> vendors can ship as part of their products, that works with the local >>> ISP when it provides that service. >> That is called native IPv6. > > Native IPv6 is the desired end point. But the idea that people are > going to use IPv6 on a widespread basis before it's effectively > available /everywhere/ is just delusional. So your presumed deployment > model assumes that all providers of IP service will just upgrade to IPv6 > voluntarily. Even if most ISPs do that, I don't think most hotels, > coffee shops, airports, etc. that provide wifi access are going to > eagerly do that. What's much more likely is that they'll just replace > their equipment as it fails, and if the new equipment supports IPv6, and > their ISP supports IPv6, it will work. And these are vital parts of > Internet infrastructure. And until IPv6 access is ubiquitous via some > means, applications will still be stuck using the same extremely > dysfunctional (and constantly getting worse) IPv4 Internet. > >> >>> In short we need something that >>> ordinary users can have enabled by default and it "just works". >> Please also note that "just works" does not exist. > > Nope. It only results from good design, good network implementation, > good operation, etc. "just works" is only a user perception, but it's > absolutely the perception that users should have. >>> Adding >>> additional hoops that users have to jump through is effectively just a >>> form of hostility to IPv6 deployment. >> Simple question: how did you sign up for your IPv4 service? > > On the most recent occasion, I spent weeks trying to find a provider > that would give me a static IP address and not filter my traffic, more > weeks trying to get the link and their router configured properly to > deliver the service that they promised me. Why do you ask? > >> Oh, and remember the hell that was to get it all working when it was >> still Trumpet Winsock over a modem connection? :) > > Even then I knew better than to use Windows, but I do remember those > days. What is your point? That getting Internet service is supposed > to be painful? Or that users should have to go through every bit as > much pain to enable IPv6 as they did to get IPv4 access? > > Keith > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Dec 3 09:21: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 4834C1A6FF2 for ; Wed, 3 Dec 2014 09:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7] 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 20PNBBThAHxS for ; Wed, 3 Dec 2014 09:21:19 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F59C1A8A57 for ; Wed, 3 Dec 2014 09:21:12 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 02287100AB8BE; Wed, 3 Dec 2014 17:21:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417627270; bh=APPvZnxzDXXlViTkrFr7n8n+HmPx8qMqrAF/xyNDwHg=; h=Date:From:To:Subject:References:In-Reply-To; b=npw1oLQ1aLy2vLLBxDyQtm7g2LlfyLJvh6ESKEMZD/q840kl4zMRwsvPWtgDlc5tn LQw1FiNcqe/SXjMmFmlo+5nmx3Od1dYo4HQ/914Zna6rFqoCtd9Bh47wH33/yb+xca 8k6lkESrix1SZNjFNsDs7IMFIOVj/EWnANkETac18MMZFIqYK+RMoQ96QoBCu9jtK6 vEOTFnehLi4L9wkoseG7qh37BbfGfDxxKQOF6qzGkXN62RcufrMpwUDgWm1FOfOOtl 2z8tWJimEVgoWalt63tX+nlW1zAT1fiEXMDe1zFpWSQ+jOG+MW9SbBk9DEo/DnbJQj trfj4eN1Dholw== Message-ID: <547F4684.7010505@massar.ch> Date: Wed, 03 Dec 2014 18:21:08 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Keith Moore , v6ops@ietf.org References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <547F3218.4060101@network-heretics.com> <547F3710.50106@massar.ch> <547F3831.50408@network-heretics.com> <547F3B8A.3020805@massar.ch> <547F41E0.1090303@network-heretics.com> In-Reply-To: <547F41E0.1090303@network-heretics.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/becp8tmiSSNJsspCImBNmQZrdGc Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 17:21:35 -0000 On 2014-12-03 18:01, Keith Moore wrote: > On 12/03/2014 11:34 AM, Jeroen Massar wrote: >> On 2014-12-03 17:20, Keith Moore wrote: >>> On 12/03/2014 11:15 AM, Jeroen Massar wrote: >>>> On 2014-12-03 16:54, Keith Moore wrote: >>>>> On 12/03/2014 08:25 AM, Jeroen Massar wrote: >>>>>> Which demographic of users need this? >>>>> Every user who doesn't have native IPv6 access at every one of the >>>>> locations from which he accesses the Internet. >>>>> >>>>> Because IPv6 won't be a viable replacement for IPv4 until users can >>>>> access it everywhere. And in the near term, that means being able to >>>>> access it from anywhere that currently has IPv4. >>>> That demographic of users are signing up to tunnel brokers and VPN >>>> providers. >>> No, they're not, because it's just too obscure and painful for most >>> people. >> "Most people". Interesting choice of words. > > It's only interesting because the solutions you seem to propose are not > suitable for most people, even though we want everyone (not just "most > people") to migrate to IPv6. These folks will move when they need to. They do not care if their "Internet" is IPv4 or IPv6 as they just use port 80/443, that is they just use "Facebook" and "Google". >> Also please describe in detail how tunnel brokers are "obscure". > > I'm not going to play that game. Which "game"? The "no answer to a statement you are making" one? > But if you want to collect data > yourself, poll N randomly selected Internet users and ask them if they > understand what "tunnel broker" means or how to set one up. I can state that 99% of the users of SixXS will not know how to set up a Tunnel Broker. Even though 100% of them clearly know how to create a tunnel; and this funnily while a tunnel broker is just the automated version of that ;) The "normal internet users" you are speaking of do not care about IPv4/IPv6, they care about "cat pictures"... Hence, they will not "need IPv6". >> Also note that most of the better tech magazines have detailed point by >> point instructions on how to get IPv6 connectivity for well over a >> decade. > > Most users do not read "better tech magazines". And thus that demographic is not interested in getting IPv6 either. There is a big reason why I asked for the demographic you are talking about. Clearly you are talking about people who Google for Facebook. These folks really can't care less about this whole IP thing or whatever we do in the IETF. They will love these kind of threads though, wondering why we waste our time discussing them. > You seem to have this strange idea that IPv6 is for techies only. I for sure do not seem to think that, having helped close to 45.000 people getting IPv6 at locations they do not have it. Most who definitely are not 'techies' but just normal users at home who did something fun to get to learn something new./ >> And describe how they are "painful" for most people. > > If the option to enable v6 connectivity doesn't appear in the user's > computer's or router's Settings / Control Panel / whatever screen, and > it can't be automatically configured using information from PPP or DHCP, > it's too painful for most people. IPv6 is enabled per default on most (unfortunately by far all) devices being kicked out of the door today. > Current options other than 6to4 > typically require users to install new software and learn new things, > perhaps multiple layers of new things, in order to use them. Your demographic of users do not care about these things and thus will not bother with them. >> If you actually want to resolve those points, you'll have to come with a >> lot more detail for anybody to be able to look at your problem. > > I don't need to get other people to look at "my" problem. Then why are you discussing it here and are you so opposed to deprecation of 6to4? > (which is > the Internet's problem even if some people don't realize it) I'm > quite capable of doing the protocol design work or assisting with it and > willing to make that effort. What I'm looking for now is just > assistance in defining the problem. But you have that definition of the problem (which is far from clearly described). Unfortunately it seems the demographic for your problem does not care about your problem. >>> We need something that can be easily configured, that OS >>> vendors can ship as part of their products, that works with the local >>> ISP when it provides that service. >> That is called native IPv6. > > Native IPv6 is the desired end point. But the idea that people are > going to use IPv6 on a widespread basis before it's effectively > available /everywhere/ is just delusional. Nobody is going that route. 6bone and tunnel brokers where a great way of bootstrapping IPv6 and getting it in the hands of the people who needed/wanted to test and play with it. 6bone was decommissioned when we knew it worked. Tunnel Brokers are still there to let people actually use IPv6 for the situations where the user wants it. > So your presumed deployment > model assumes that all providers of IP service will just upgrade to IPv6 > voluntarily. They will over the next 50 years. > Even if most ISPs do that, I don't think most hotels, > coffee shops, airports, etc. that provide wifi access are going to > eagerly do that. Those are restricted environments that will not easily allow tunneling anyway. Thus you won't be able to bolt IPv6 there even if your life depends on it (though AYIYA typically works great, heck even worked from many hotels in China and even the subway :) > What's much more likely is that they'll just replace > their equipment as it fails, and if the new equipment supports IPv6, and > their ISP supports IPv6, it will work. And these are vital parts of > Internet infrastructure. And until IPv6 access is ubiquitous via some > means, applications will still be stuck using the same extremely > dysfunctional (and constantly getting worse) IPv4 Internet. Absolutely. But what can the IETF do about that? >>> In short we need something that >>> ordinary users can have enabled by default and it "just works". >> Please also note that "just works" does not exist. > > Nope. It only results from good design, good network implementation, > good operation, etc. "just works" is only a user perception, but it's > absolutely the perception that users should have. That is a fairy dream outcome. Not even IPv4 works in that way. >>> Adding >>> additional hoops that users have to jump through is effectively just a >>> form of hostility to IPv6 deployment. >> Simple question: how did you sign up for your IPv4 service? > > On the most recent occasion, I spent weeks trying to find a provider > that would give me a static IP address and not filter my traffic, more > weeks trying to get the link and their router configured properly to > deliver the service that they promised me. Why do you ask? Because it answers the point completely: Do not expect IPv6 yo magically 'just work'. Also, as you spent weeks on it, did you get IPv6 with that? :) >> Oh, and remember the hell that was to get it all working when it was >> still Trumpet Winsock over a modem connection? :) > > Even then I knew better than to use Windows, but I do remember those > days. What is your point? That getting Internet service is supposed > to be painful? Or that users should have to go through every bit as > much pain to enable IPv6 as they did to get IPv4 access? That it *IS* painful and that you should not expect magic from something that is going to run above it. Greets, Jeroen From nobody Wed Dec 3 09:23: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 4BBE91A1BD9 for ; Wed, 3 Dec 2014 09:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 Vrx_PdBnrgUI for ; Wed, 3 Dec 2014 09:23:38 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D36701A1B32 for ; Wed, 3 Dec 2014 09:23:37 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 7F54F100AB8BE; Wed, 3 Dec 2014 17:23:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417627415; bh=H1jcEiNKkQbd11eDHP4ktb81faQjCJSQxoQhb628F54=; h=Date:From:To:Subject:References:In-Reply-To; b=PLuGRZlw/xfuxLuaLX+ZNG1qvjDAGn8KCIkV8xlKWQH6gwEu5SbJpSCcvZyWM0UWP bjrE/3Vi7mnh4cceZAliVPlLC0caDZCospz7AWx5rmLq44gsRNDqJHK5FEHyEmSj+S LJlu6VAPOwBwgxWPjf9V7s8vSoKqTRFLZcrZczmQlyleInibKmeOm2WN8euIEwZ2+y cirxb6M29gzvm+lBJY8mDqPQHBNWe8trXb+NXviRwfsbWc5dvbww56jjdPwrshbsDi TeFYlOJ2WEZZ1FSRRDW7ji/nAw1hsHZwufifVhtFI8OkpduCd4PskPpnVlLHClAsnZ gl9CTjF0LHStw== Message-ID: <547F4716.3000208@massar.ch> Date: Wed, 03 Dec 2014 18:23:34 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: carlos@lacnic.net, v6ops@ietf.org References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <547F3218.4060101@network-heretics.com> <547F3710.50106@massar.ch> <547F3831.50408@network-heretics.com> <547F3B8A.3020805@massar.ch> <547F41E0.1090303@network-heretics.com> <547F436C.6030901@gmail.com> In-Reply-To: <547F436C.6030901@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Nz2VeLjyMDN2KVzXHVv_Zj_RteM Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 17:23:44 -0000 On 2014-12-03 18:07, Carlos M. Martinez wrote: > Apologies for top posting, but > > I don't think the demographics is limited to those who are using tunnel > brokers. Please define the exact demographics that you are talking about. As they are not at all matching with Keith's edition of "everybody" > It's offering operators who are stuck with non-IPv6 compliant > equipment in their networks As "operators" knew that this little IPv6 thing was coming over the last 20 years. How did they end up there? How did they not upgrade their network over time and prepared for this? > an alternative with basically the strengths > of 6rd and addresses its weaknesses. Which 'weaknesses'? Please define. Greets, Jeroen From nobody Wed Dec 3 09:51: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 CCD6A1A8AF7 for ; Wed, 3 Dec 2014 09:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 Z90h01zUkSYM for ; Wed, 3 Dec 2014 09:51:37 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id DE2D71A8AFB for ; Wed, 3 Dec 2014 09:51:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 75E6F871652; Wed, 3 Dec 2014 18:51:20 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7l2PRTblF65; Wed, 3 Dec 2014 18:51:20 +0100 (CET) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 50139871650; Wed, 3 Dec 2014 18:51:20 +0100 (CET) Message-ID: <547F4D95.7030706@globis.net> Date: Wed, 03 Dec 2014 18:51:17 +0100 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Sander Steffann References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> 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/BWAtFMdZYdMtmFl3nCt9OHsEgnw Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 03 Dec 2014 17:51:39 -0000 Sander Steffann wrote: > Hi, > >> Why would the IETF want to put an approved "standard track" marking on what is a very clever but horrible kludge? > > Because with the IPv4 addresses running out horrible kludges are unfortunately necessary and putting the best of them on standards track is the best available option. > > Cheers, > Sander > > What difference would that "Standards Track" stamp make to operations? ISPs can already deploy A+P today if they want. An "Experimental" protocol has a very low requirement for WG review before publication. Changing A+P to "Standards Track" is a very big step IMHO, especially considering what A+P breaks, and would likely be a drag on future protocol developments. When do you think we can expect the first "No, you can't publish that because it will break A+P, which is Standards Track" comment? -- Regards, RayH From nobody Wed Dec 3 10:10: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 9FC1C1A9031 for ; Wed, 3 Dec 2014 10:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[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 diOYjewT_2Wp for ; Wed, 3 Dec 2014 10:10:18 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [200.7.84.8]) by ietfa.amsl.com (Postfix) with ESMTP id C48F71A902B for ; Wed, 3 Dec 2014 10:10:10 -0800 (PST) Received: from hermes.lacnic.net.uy (localhost [127.0.0.1]) by mail.lacnic.net.uy (Postfix) with ESMTP id 12B5816B40BFC; Wed, 3 Dec 2014 16:10:09 -0200 (UYST) X-Virus-Scanned: amavisd-new at lacnic.net.uy Received: from mail.lacnic.net.uy ([127.0.0.1]) by hermes.lacnic.net.uy (mail.lacnic.net.uy [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkSS4a_dTyQ9; Wed, 3 Dec 2014 16:10:08 -0200 (UYST) Received: from [IPv6:2001:13c7:7001:7000:81f5:9d1c:201b:65dc] (unknown [IPv6:2001:13c7:7001:7000:81f5:9d1c:201b:65dc]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.lacnic.net.uy (Postfix) with ESMTPSA id A1CE716B40BEE; Wed, 3 Dec 2014 16:10:08 -0200 (UYST) Message-ID: <547F51FF.1060601@lacnic.net> Date: Wed, 03 Dec 2014 16:10:07 -0200 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Jeroen Massar , v6ops@ietf.org References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <547F3218.4060101@network-heretics.com> <547F3710.50106@massar.ch> <547F3831.50408@network-heretics.com> <547F3B8A.3020805@massar.ch> <547F41E0.1090303@network-heretics.com> <547F436C.6030901@gmail.com> <547F4716.3000208@massar.ch> In-Reply-To: <547F4716.3000208@massar.ch> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yrn4o9BRFK-3tisV2jN75A-REP0 Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 18:10:20 -0000 Hello Jeroen, On 12/3/2014 3:23 PM, Jeroen Massar wrote: > On 2014-12-03 18:07, Carlos M. Martinez wrote: >> Apologies for top posting, but >> >> I don't think the demographics is limited to those who are using tunne= l >> brokers. > Please define the exact demographics that you are talking about. > As they are not at all matching with Keith's edition of "everybody" It's definitely not everybody, but it's certainly bigger than just the guys who know what tunnel broker means. >> It's offering operators who are stuck with non-IPv6 compliant >> equipment in their networks > As "operators" knew that this little IPv6 thing was coming over the las= t > 20 years. How did they end up there? How did they not upgrade their > network over time and prepared for this? We can talk for hours how they ended up in this situation. But its true. I know first hand examples of FTTH deployments done in 2013 who are stuck with OTNs that have hardware bugs that prevent them from transporting native IPv6 (if you want the details, the OTNs blindly drop anything multicast). This particular ISP has close to a million users, and they are willing to do IPv6, but they are, well, stuck. These are just a few examples, but i'm pretty sure that there are many mo= re. > >> an alternative with basically the strengths >> of 6rd and addresses its weaknesses. > Which 'weaknesses'? Please define. OAM, mostly. Carlos From nobody Wed Dec 3 10:15: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 B4ED51A1BE7 for ; Wed, 3 Dec 2014 10:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 EyeWJMttSsmn for ; Wed, 3 Dec 2014 10:15:12 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BC5F1A0385 for ; Wed, 3 Dec 2014 10:15:12 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 4DBAC2283D for ; Wed, 3 Dec 2014 13:15:11 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 03 Dec 2014 13:15:11 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=efmzXgLkVcZGGBf4iuich5 wRZRY=; b=XFC7SeBAQzWCEs8KElnKV+aeR+0TaXUdQah0nbSJeCp9iuzF3xD4RS pzRXoRE0VirbW9+XZqmGvNK0303eMKrTjnQikh5OU/Voe/BNOsuDoWOvwK4pUTGQ /rs9jBlXttc/kVsX79ERd85V7/PmYwJ95PqhW6PsRMBzoGKNSh9Zo= X-Sasl-enc: RACWRlEAal5gKTiHR6jMnyxIvDrXhESKgtsCPnp8mrU4 1417630511 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id E59DA6803A1; Wed, 3 Dec 2014 13:15:10 -0500 (EST) Message-ID: <547F5322.70804@network-heretics.com> Date: Wed, 03 Dec 2014 13:14:58 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <547F3218.4060101@network-heretics.com> <547F3710.50106@massar.ch> <547F3831.50408@network-heretics.com> <547F3B8A.3020805@massar.ch> <547F41E0.1090303@network-heretics.com> <547F4684.7010505@massar.ch> In-Reply-To: <547F4684.7010505@massar.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/q_BdIBFlmcm2QjuML_w6XuMl1p8 Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 18:15:14 -0000 I followed up to Jeroen in detail in private mail. Executive summary: He seems to think there's no need for an easy-to-configure way to enable v6 connectivity for arbitrary hosts or consumer networks because those people who can't be bothered to install and configure SixXS just want to look at pictures of cats anyway. I disagree, and think that large numbers of ordinary users benefit from availability of applications other than the web, which run better over v6 than with ad hoc mechanisms for NAT traversal. I also think that the widespread support of anycast 6to4 in hosts and consumer routers was evidence of at least a perception of a need for easy v6 connectivity over v4. Since anycast 6to4 has been demonstrated to not work well and 6to4 with an explicitly configured router still has other problems, I want to define a different mechanism that works better but still has 6to4's ease of configuration. I am however happy if all we need for that mechanism is a way that networks can advertise, and hosts and consumer routers can discover, available mechanisms for tunneling v6 over v4, and if the hosts/routers can be configured to use a fallback tunnel service if no other means is available. The advertising mechanism should be able to advertise 6rd, AYIYA, and anything else that works well. Keith From nobody Wed Dec 3 10:19: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 CE6AE1A1B1B for ; Wed, 3 Dec 2014 10:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 HezRdX0AUxBn for ; Wed, 3 Dec 2014 10:19:01 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 270E51A6F49 for ; Wed, 3 Dec 2014 10:18:26 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id D52B6100AB8BE; Wed, 3 Dec 2014 18:18:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417630702; bh=AldASapcfmXaQ/AHOWPxUoSxeQg+UZ4UHQUJf71IY9g=; h=Date:From:To:Subject:References:In-Reply-To; b=O+M+6JHCsnq1kG1Abdgy+N7y2fpRP4u2xIeLOtnybC0nbX0ssJ5tTR/UiWtOQjTzj oPBkJA7eTBXxmwyiDT+LpDf4bc8eFH3xkDcbOgRjq0rNe4n++fK45PtYtZMej+g1Z7 ZaMP3aTa+LHFnXZ70BuZLnqjJ+ZdR8T010htQzUTZ39GxbEg5qiBNPzj0JT6Thu2au 6X4cpycbx6Y57fLMc5tn37Blxh1WzWTooJ+g5Rlgs3g/aRSQMPcAfQxcHc4mINupd0 aFu9m0h+jhzVmHGvUQXl+RicGW/AjyKhg8V41xdawgtyRirMlcNcpFLp68sYmvvY2w T2b3XPUJe8X/g== Message-ID: <547F53EC.5010300@massar.ch> Date: Wed, 03 Dec 2014 19:18:20 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: "Carlos M. Martinez" , v6ops@ietf.org References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <547F3218.4060101@network-heretics.com> <547F3710.50106@massar.ch> <547F3831.50408@network-heretics.com> <547F3B8A.3020805@massar.ch> <547F41E0.1090303@network-heretics.com> <547F436C.6030901@gmail.com> <547F4716.3000208@massar.ch> <547F51FF.1060601@lacnic.net> In-Reply-To: <547F51FF.1060601@lacnic.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1S0_-xbq8-gcUGsCn_LMzwQuv6k Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 18:19:07 -0000 On 2014-12-03 19:10, Carlos M. Martinez wrote: > Hello Jeroen, > > On 12/3/2014 3:23 PM, Jeroen Massar wrote: >> On 2014-12-03 18:07, Carlos M. Martinez wrote: >>> Apologies for top posting, but >>> >>> I don't think the demographics is limited to those who are using tunnel >>> brokers. >> Please define the exact demographics that you are talking about. >> As they are not at all matching with Keith's edition of "everybody" > It's definitely not everybody, but it's certainly bigger than just the > guys who know what tunnel broker means. That is not very specific at all. >>> It's offering operators who are stuck with non-IPv6 compliant >>> equipment in their networks >> As "operators" knew that this little IPv6 thing was coming over the last >> 20 years. How did they end up there? How did they not upgrade their >> network over time and prepared for this? > > We can talk for hours how they ended up in this situation. But its true. > I know first hand examples of FTTH deployments done in 2013 who are > stuck with OTNs that have hardware bugs that prevent them from > transporting native IPv6 (if you want the details, the OTNs blindly drop > anything multicast). Clearly they need to ask their money back from that vendor... > This particular ISP has close to a million users, > and they are willing to do IPv6, but they are, well, stuck. 6rd does not rely on multicast, hence there is one solution that is very well tested. > These are just a few examples, but i'm pretty sure that there are many more. >> >>> an alternative with basically the strengths >>> of 6rd and addresses its weaknesses. >> Which 'weaknesses'? Please define. > OAM, mostly. Please be a lot more specific. Greets, Jeroen From nobody Wed Dec 3 10:41: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 42D4C1A9037 for ; Wed, 3 Dec 2014 10:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7] 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 FZHJWLmsGnC0 for ; Wed, 3 Dec 2014 10:40:59 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7B81A8AD7 for ; Wed, 3 Dec 2014 10:40:59 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 78509100AB8BE; Wed, 3 Dec 2014 18:40:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417632056; bh=IK82TXvhEaSqfNB1Lrzskc80PFseBTrxdd6fIwq2rlc=; h=Date:From:To:Subject:References:In-Reply-To; b=opVD2zK2R+M1W2Gb/WnCBDrOWBnIK5tdIAExK+P83zpJJFkYHo/2QhJwCVjtxSFWi mLu1U0pIYeNvAkJT39lAS8qQcZwKi3b3U8oy88GPyyYpMclU6KOY9cQY9AIIDStjVJ kYq2JTE3gGWsuPSqlmeBE0TWBo/CUVXBlBXKS88SeHtL34MEZm3GmEPpBNa3e5aU56 6soSx3hcOJDto6i2tVH4hV8Zbwmih+SmS6LSEzHjSW9hPorwSTJpZvpWqVn6Vh3peI 7T+djVo7Lvpt0GaZiKHvgpvWq99YQAmtGLRxXnJkZK+/hnMtGGNOiciuyRYo2QOUic kLEczBR4w8VPg== Message-ID: <547F5935.40704@massar.ch> Date: Wed, 03 Dec 2014 19:40:53 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Keith Moore , v6ops@ietf.org References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <547F3218.4060101@network-heretics.com> <547F3710.50106@massar.ch> <547F3831.50408@network-heretics.com> <547F3B8A.3020805@massar.ch> <547F41E0.1090303@network-heretics.com> <547F4684.7010505@massar.ch> <547F5322.70804@network-heretics.com> In-Reply-To: <547F5322.70804@network-heretics.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5a_pnChwNFT9I9aYpdAOutWt7n8 Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 18:41:02 -0000 On 2014-12-03 19:14, Keith Moore wrote: > I followed up to Jeroen in detail in private mail. Why not keep it on list? > Executive summary: He seems to think there's no need for an > easy-to-configure way to enable v6 connectivity for arbitrary hosts or > consumer networks because those people who can't be bothered to install > and configure SixXS just want to look at pictures of cats anyway. Clearly that is what you interpreting from what I am trying to get out of you. But that is not what I have stated at all and is actually gross misrepresentation. First of all, I do not limit to SixXS (which is just an implementation to solve a particilar set of problem with a specific demographic audience), let alone to Tunnel Brokers for finding a solution for the problem. One of the major problems with your mails is that the demographic that you want is completely unclear. As you say "most people", the only answer can be "folks using HTTP" (thus watching cats, facebook, gmail and the like). These folks do not even care about SMTP as their email is a website and they do not know better. Those people really do not care about IPv4/IPv6 etc as for them "The Internet" (as they know it) just works fine, even if they are behind fifty layers of NATs or heck are getting native IPv6-only already. Hence, please define your demographic and then define the problem they are having and where they are having that problem. As only then will we be able to determine where the problems are and then go for a solution to solve that problem. > I disagree, and think that large numbers of ordinary users benefit from > availability of applications other than the web, which run better over > v6 than with ad hoc mechanisms for NAT traversal. Like you I love and want that people can use the FULL Internet even though most people will never know the full possibilities that it offers. Hence, why I have been deploying IPv6 for so long already: to get people to be able to deploy things. (of course I wanted to do that myself too, just happened to end up doing it for others too ;) But the people who specifically need these kind of setups either read magazines like the paper editions of www.heise.de/ct/ and www.heise.de/ix/ or PC Magazin etc who have been covering IPv6 for years already; or those people google/yahoo/bing and find a solution to their problem, typically not even a IPv6 tunnel or other form of connectivity but things like getting a VPS, TeamViewer, Hamachi or a form of a peer-to-peer network (and then I mean bittorrent not true p2p which is what one gets with unfirewalled IPv6). Any other demographic simply does not care about IP. If you have examples of situations of people who do care about having proper connectivity to the Internet, then please name them and let us define them and then see what kind of problems these people have. > I also think that the > widespread support of anycast 6to4 in hosts and consumer routers was > evidence of at least a perception of a need for easy v6 connectivity > over v4. Yes, there was this. But we learned that Anycast 6to4 causes problems that we cannot solve as there are too many layers of operation involved. Also, since 6to4 came out there have been better solutions that solve that problem much better. Remember that when 6to4 was developed the only NAT that existed was the one in the computer of the user, not in the network of the ISP. There where no mobile networks either and most folks had dial-up. > Since anycast 6to4 has been demonstrated to not work well and > 6to4 with an explicitly configured router still has other problems, I > want to define a different mechanism that works better but still has > 6to4's ease of configuration. But why define something if you cannot even define who will be using it let alone the problems they currently have? I'll ask again: Which exact gap are you trying to solve that existing methods do not solve? And of course, please do specify the demographic. > I am however happy if all we need for > that mechanism is a way that networks can advertise, and hosts and > consumer routers can discover, available mechanisms for tunneling v6 > over v4, and if the hosts/routers can be configured to use a fallback > tunnel service if no other means is available. 6rd uses DHCP for 'advertising', this works great on the local media to which an ISP has access. Anything else will require somebody to run a service where possibly millions of people can get coordinated access to that service. That system will not happen as that has the same problem as 6to4 anycast: other entities are paying for that service. Note that the 'advertising' of tunnel brokers happens in printed media / blogs and maybe strangely more importantly in the devices that people buy. Signup reasons that I see regularly when going through the SixXS signup queue prove this: "My Sophos UTM pointed out to this" "UnityMedia helpdesk sent me here" "My ZyXEL supports SixXS" "I saw AICCU support in OpenWRT" "I installed the aiccu package" etc (Oh, fun side-note: SixXS is just a hobby project that takes too much time.... hence no real advertising in any way) > The advertising > mechanism should be able to advertise 6rd, AYIYA, and anything else that > works well. Any such "advertising" mechanism would require central coordination, such a mechanism does not exist on the Internet and cannot be distributed easily around the Internet in a scalable method. Somebody has to run it, there is no way to make something run unattended and unmanaged and without it costing anybody anything. Greets, Jeroen From nobody Wed Dec 3 10:42: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 1A9611A8BC2 for ; Wed, 3 Dec 2014 10:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 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_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 11dtFVxxYwoa for ; Wed, 3 Dec 2014 10:42:24 -0800 (PST) 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 159071A88CA for ; Wed, 3 Dec 2014 10:42:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 78C8645; Wed, 3 Dec 2014 19:42:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= references:message-id:content-transfer-encoding:date:date :in-reply-to:x-mailer:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1417632140; bh=PXqQ7Mlr3SABz/R0xvfsyxD43Yram8ODlh7lbIEVLgM=; b=E ab47zJYdEhcgys3vo5bLYQ+jAUZz9s8wf6EigfeaFZz6Eu1d8P7RY8ojYEU0sqUx A98n886RU6aXzZc9ljEpJVSd8BRv21Y5LOTUVNZLZARfw5XDvSGyuo2/13fUceIg 6i7vt0W/j3UvvSEX4FH2L4FmWGGfeT7oZrPqZKZuzc= 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 10026) with ESMTP id KE-X8Tk5Wg9H; Wed, 3 Dec 2014 19:42:20 +0100 (CET) Received: from [IPv6:2a00:8640:1::45ce:fa52:e0d8:63c3] (unknown [IPv6:2a00:8640:1:0:45ce:fa52:e0d8:63c3]) by mail.sintact.nl (Postfix) with ESMTPSA id 9DF7665; Wed, 3 Dec 2014 19:42:20 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Sander Steffann X-Mailer: iPhone Mail (12B436) In-Reply-To: <547F4D95.7030706@globis.net> Date: Wed, 3 Dec 2014 19:42:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7A0C8862-3239-4094-A134-9076E03B2297@steffann.nl> References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> To: Ray Hunter Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/JlNI8ACmLYdR4x_5XtIreGEVgRQ Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 03 Dec 2014 18:42:25 -0000 Hi, > Changing A+P to "Standards Track" is a very big step IMHO, especially cons= idering what A+P breaks, and would likely be a drag on future protocol devel= opments. For IPv4 development: yep. There are not enough IPv4 addresses so they have to be shared. Using NAT in I= SP networks for address sharing needs lots of state. A+P gives us the option= to do that in a stateless way, which is good for scalability and stability.= If A+P is the best we can do for IPv4 at this time then that's what we need t= o design for. I don't like it either and I long for the day that we can run I= Pv6-only and get rid of IPv4. Until then I think this is the best way forwar= d. > When do you think we can expect the first "No, you can't publish that beca= use it will break A+P, which is Standards Track" comment? When it's necessary :( Sander From nobody Wed Dec 3 10:48: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 2574C1A9098 for ; Wed, 3 Dec 2014 10:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 7KtaSY1mavGi for ; Wed, 3 Dec 2014 10:48:06 -0800 (PST) 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 C98451A9094 for ; Wed, 3 Dec 2014 10:48:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2091; q=dns/txt; s=iport; t=1417632487; x=1418842087; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=87+ccMK4XRQwgKJ4/WerJrj0DcDrcAWQe0haHBLDbU0=; b=IpDUbIPvjjXXN89t/nC/g3aX6lXVFX7b3saMlhb3JRoDSoy+QoDNzHey 0YkUxYpcEA/C/8gs+qqWNzRg1oJpf3K6bAihkkhAmS7S7KMAmc8fbor03 /psfG0DPjPIdyeq0UTmR2wOD2UFVQz2wWzIe1zJcYh2xffD157dqJYHRy 8=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAHlaf1StJV2d/2dsb2JhbABagwaBKgS4b5NvAoEUFgEBAQEBfYQDAQEEeRACAQgYLjIlAgQOBQ6IMNZ2AQEBAQEBAQEBAQEBAQEBAQEBAQEBF40Eg2IHgySBHgEEhGGLLoF2gUCHFJQWg3hvgUWBAAEBAQ X-IronPort-AV: E=Sophos;i="5.07,509,1413244800"; d="asc'?scan'208";a="374180438" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 03 Dec 2014 18:47:59 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sB3Ilwe5021591 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Dec 2014 18:47:58 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 12:47:58 -0600 From: "Fred Baker (fred)" To: Iljitsch van Beijnum Thread-Topic: [v6ops] Report: Bar BoF on a 6to4 replacement Thread-Index: AQHQDymnOAc7LSxK9Uep2CSjmGR68w== Date: Wed, 3 Dec 2014 18:47:57 +0000 Message-ID: <923DB180-59C6-4167-83FB-16AC788D0635@cisco.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.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.121] Content-Type: multipart/signed; boundary="Apple-Mail=_49EF7FDE-FCED-4365-8E84-C32A6916B6F9"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2AlGiKiwipT3f5BTH6LWiC3pS3U Cc: "v6ops@ietf.org" , Keith Moore Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 18:48:08 -0000 --Apple-Mail=_49EF7FDE-FCED-4365-8E84-C32A6916B6F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 2, 2014, at 10:44 AM, Iljitsch van Beijnum = wrote: > I got a generally cautiously positive reception from those that gave = me enough time to explain all of this, except that those with skin in = the game of course still prefer their own systems. >=20 > So I guess I have a draft to write. You and I didn't have that conversation. Yes, I would agree that you = have a draft to write. The big question I would ask is about diversion of effort. It's not like = 6to4 is universally deployed in any real sense, or for that matter = Teredo (it's in many, perhaps all, Microsoft products, but not = everything comes from Microsoft). With actual use plummeting (Brian = indicates that worldwide statistics suggest a grand total of 100K people = are using 6to4 anycast and that number is falling), I'm not sure there = is a market for a replacement. Software is typically updated when the = underlying hardware is changed; the deployment model becomes "when = product X is replaced, the user simultaneously gets IPv6 and 6to4bis". = If a given operator has to do something to deploy 6to4bis, why would = they not enable IPv6 instead? If the choice is to spend $$$ to deploy = IPv6 xor 6to4bis, do we want to encourage them to choose 6to4bis? I think I see where you're going, and if you want to do it I=92m not = going to object, but to me it's a dead end. --Apple-Mail=_49EF7FDE-FCED-4365-8E84-C32A6916B6F9 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 iD8DBQFUf1rObjEdbHIsm0MRAg2EAJ0Ye9DL9nqJDYLzAos4IM2VEuNn6QCfcvC7 7PZY/JZbK2wN4909LLtPBl0= =PDQd -----END PGP SIGNATURE----- --Apple-Mail=_49EF7FDE-FCED-4365-8E84-C32A6916B6F9-- From nobody Wed Dec 3 10:53: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 78A311A90AB for ; Wed, 3 Dec 2014 10:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 tl7k5Ec5RdNb for ; Wed, 3 Dec 2014 10:53:25 -0800 (PST) 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 F08131A1B6A for ; Wed, 3 Dec 2014 10:53:24 -0800 (PST) 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 sB3IrO6L020693; Wed, 3 Dec 2014 12:53:24 -0600 Received: from XCH-BLV-301.nw.nos.boeing.com (xch-blv-301.nw.nos.boeing.com [130.247.25.213]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sB3IrIcK020643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 3 Dec 2014 12:53:19 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-BLV-301.nw.nos.boeing.com ([169.254.1.55]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 10:53:18 -0800 From: "Templin, Fred L" To: Gert Doering Thread-Topic: [v6ops] Report: Bar BoF on a 6to4 replacement Thread-Index: AQHQDmAH0I/jfXJhYUW2sj/c/ybqPJx8qrzwgAGrlICAAAxJgP//pYdAgACQu4D//3s9QIAAiiIA//+WLYA= Date: Wed, 3 Dec 2014 18:53:17 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DA9FFA@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <2134F8430051B64F815C691A62D9831832DA992F@XCH-BLV-504.nw.nos.boeing.com> <20141203163947.GB28745@Space.Net> <2134F8430051B64F815C691A62D9831832DA9B81@XCH-BLV-504.nw.nos.boeing.com> <20141203165900.GE28745@Space.Net> In-Reply-To: <20141203165900.GE28745@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QE2ZS1AgM0pUPYomNoIo4CfnbHg Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 18:53:26 -0000 Hi Gert, > -----Original Message----- > From: Gert Doering [mailto:gert@Space.Net] > Sent: Wednesday, December 03, 2014 8:59 AM > To: Templin, Fred L > Cc: Gert Doering; Jeroen Massar; Iljitsch van Beijnum; v6ops@ietf.org > Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement >=20 > Hi, >=20 > On Wed, Dec 03, 2014 at 04:48:02PM +0000, Templin, Fred L wrote: > > > On Wed, Dec 03, 2014 at 04:04:01PM +0000, Templin, Fred L wrote: > > > > 6rd is not perfect, because it clamps the MTU to something less tha= n 1500. > > > > > > It doesn't have to. If the transport network providing the 6rd servi= ce > > > (remember that this is inside a well-controlled ISP network, not > > > "arbitrary Internet") provides larger-than-1500 MTU, there is no reas= on > > > why 6rd cannot have 1500. > > > > We are now talking about IPv4 link MTUs being perfectly managed. If the= y > > are, then great. But, all it takes is one mis-configured link MTU to br= ing > > down the whole house of cards. And, anything that can be configured > > can be mis-configured. >=20 > Different can of worms. Of course misconfiguration happens, but that doe= sn't > make the statement "6rd clamps the MTU to something less than 1500" any > more valid. It doesn't. >=20 > "6rd over infrastructure with IPv4 MTU smaller than 1520 clamps the MTU t= o > less than 1500", that is obviously true, but a very different statement. 6rd says: "If the MTU is well-managed such that the IPv4 MTU on the CE WAN side interface is set so that no fragmentation occurs within the boundary of the SP, then the 6rd Tunnel MTU should be set to the known IPv4 MTU minus the size of the encapsulating IPv4 header (20 bytes). For example, if the IPv4 MTU is known to be 1500 bytes, the 6rd Tunnel MTU might be set to 1480 bytes. Absent more specific information, the 6rd Tunnel MTU SHOULD default to 1280 bytes." I do not know, but I suspect many 6rd installations clamp the tunnel MTU to 1480 because "1500 everywhere" is assumed and for the most part that assumption would be valid. To get packets between 1480-1500 through, though, 6rd would need to use fragmentation unless and until the path tests positive for passing unfragmented 1500 byte packets. Then, the fragmentation can be turned off. So yes, hope for well-managed large link MTUs. But, test for them first before blindly assuming they are well managed. Thanks - Fred fred.l.templin@boeing.com >=20 > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Dec 3 10:57: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 96ED41A1EEC for ; Wed, 3 Dec 2014 10:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[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 8hFSC6wL9NfY for ; Wed, 3 Dec 2014 10:57:46 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 945821A6F63 for ; Wed, 3 Dec 2014 10:57:30 -0800 (PST) X-Envelope-To: Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::1d9]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.9) with ESMTP id sB3IvOjA008387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Dec 2014 18:57:25 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::1d9] claimed to be cupcake.foobar.org Message-ID: <547F5D14.5070401@foobar.org> Date: Wed, 03 Dec 2014 18:57:24 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <547F3218.4060101@network-heretics.com> <547F3710.50106@massar.ch> <547F3831.50408@network-heretics.com> <547F3B8A.3020805@massar.ch> <547F41E0.1090303@network-heretics.com> <547F4684.7010505@massar.ch> <547F5322.70804@network-heretics.com> In-Reply-To: <547F5322.70804@network-heretics.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/WmiGVK90RxZDS_FgaLz1N96jmN4 Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 18:57:51 -0000 On 03/12/2014 18:14, Keith Moore wrote: > He seems to think there's no need for an easy-to-configure way to enable v6 > connectivity for arbitrary hosts or consumer networks because those people > who can't be bothered to install and configure SixXS just want to look at > pictures of cats anyway. that is largely true, but maybe he missed an important point: if you want to define a new tunnelling mechanism, you could begin to expect real world deployment 5-8 years down the road, assuming you get vendors on board. So the question is not whether we should to start discussing new transition / tunnelling mechanisms, but whether the IETF think it's more appropriate to aim to start pushing yet another new tunnelling mechanism 5-8 years from now, or whether it would be more useful to push for more native v6 now. > I want to define a different mechanism that works better but still has > 6to4's ease of configuration. This is a monumental waste of time. Nick From nobody Wed Dec 3 11:11: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 10BE81A90F3 for ; Wed, 3 Dec 2014 11:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 CGHaRK5IcWm2 for ; Wed, 3 Dec 2014 11:10:52 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B1581A90EA for ; Wed, 3 Dec 2014 11:10:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sB3JAfG3017291; Wed, 3 Dec 2014 11:10:41 -0800 Received: from XCH-BLV-203.nw.nos.boeing.com (xch-blv-203.nw.nos.boeing.com [10.57.37.65]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sB3JAWiq017175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 3 Dec 2014 11:10:32 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-BLV-203.nw.nos.boeing.com ([169.254.3.22]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 11:10:31 -0800 From: "Templin, Fred L" To: Jeroen Massar Thread-Topic: [v6ops] Report: Bar BoF on a 6to4 replacement Thread-Index: AQHQDmAH0I/jfXJhYUW2sj/c/ybqPJx8qrzwgAGrlICAAAxJgP//pYdAgACQu4D//3s9QIAAi/2A//+YwJA= Date: Wed, 3 Dec 2014 19:10:31 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DAA05B@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <2134F8430051B64F815C691A62D9831832DA992F@XCH-BLV-504.nw.nos.boeing.com> <20141203163947.GB28745@Space.Net> <2134F8430051B64F815C691A62D9831832DA9B81@XCH-BLV-504.nw.nos.boeing.com> <547F42E3.3080508@massar.ch> In-Reply-To: <547F42E3.3080508@massar.ch> 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/esLX3iUrZa6_1ccDmHEGWgyVFLQ Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 19:11:01 -0000 Hi Jeroen, > -----Original Message----- > From: Jeroen Massar [mailto:jeroen@massar.ch] > Sent: Wednesday, December 03, 2014 9:06 AM > To: Templin, Fred L > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement >=20 > On 2014-12-03 17:48, Templin, Fred L wrote: > [..] > >> On Wed, Dec 03, 2014 at 04:04:01PM +0000, Templin, Fred L wrote: > >>> 6rd is not perfect, because it clamps the MTU to something less than = 1500. > >> > >> It doesn't have to. If the transport network providing the 6rd servic= e > >> (remember that this is inside a well-controlled ISP network, not > >> "arbitrary Internet") provides larger-than-1500 MTU, there is no reaso= n > >> why 6rd cannot have 1500. > > > > We are now talking about IPv4 link MTUs being perfectly managed. If the= y > > are, then great. >=20 > In a provider network this is the case. > There is no other case where 6rd can be deployed. Even in a provider network, well-managed link MTUs still need to be tested. > > But, all it takes is one mis-configured link MTU to bring > > down the whole house of cards. And, anything that can be configured > > can be mis-configured. >=20 > There is no magic bullet for those situations unless you do probing. Probing to test, yes. > And if you on misconfigure things then even probing will not solve that > problem. No, the probing I am talking about only returns success if things are not misconfigured. If they are misconfigured, then you need to do a little bit of fragmentation to get the 1500's through. > On 2014-12-03 17:53, Templin, Fred L wrote: > > Hi Jeroen, > [..] > >>> Hosts have become conditioned to expect 1500. > >> > >> Which hosts? Most IPv4 nodes are connected with a LOT less... > > > > Not on my networks they aren't. Go to any host on WiFi or Ethernet > > and you will see 1500 (either IPv4 or IPv6). >=20 > And then check one hop further and the hop behind that and bingo, not > 1500 any more, the reason why it is called Path MTU. Most networks I am aware of pass 1500's. > But lets take an actual number from what SixXS users configure by > looking at the MTU statistics: >=20 > https://www.sixxs.net/misc/mtu/ >=20 > Note that most people (94.78%) do not bother to change it as 1280 works > perfectly fine for them. The rest has a range of anything in between > with 47.70% of the folks who do change it forcing it to 1480, which is > the maximum they can as they indeed have a 1500 MTU link. The 1472 is > likely all the tunnels with AYIYA overhead. >=20 > As shown though some people chose to set it as low as 1281; no idea why > they do that. If you set a 1280 MTU on the AYIYA tunnel, then there is no way to run an IPv6 VPN from within the end user site since the IPv6 layer inside the VPN will only see 1240 minus the IPsec overhead (while it needs to see 1280). I see plenty of use cases for wanting to create an IPsec tunnel that rides within the AYIYA tunnel, but they won't work if they can't get a 1280 MTU to the inner IPv6 layer. > We even have a nice FAQ article about how to determine the MTU: > https://www.sixxs.net/faq/connectivity/?faq=3Dmtu >=20 >=20 > Note that this is indeed manual, but as the numbers show, only few > people see a big need to change their MTU. >=20 >=20 > >>> So, if they send a > >>> 1500 and it gets dropped but no ICMP PTB message comes back it > >>> black holes. > >> > >> Then configure your network properly. > > > > Again, a house of cards. >=20 > Well, your network. >=20 > And really, stating "house of cards" but wanting to do multiple tunnels > inside tunnels, ouch... No, the AERO handling of nested tunnels plows through any path MTU limitations. That is because AERO tunnel MTUs recurse indefinitely. > >> Also, do not create tunnels over paths that do not pass the packet siz= e > >> your are sending. > > > > You create tunnels over whatever path with no pre-conceived notion > > of what MTUs the links in those paths support. All you can be reasonabl= y > > assured of is 1280 bytes for IPv6 and 68 bytes for IPv4. >=20 > But that is the fun thing with Tunnel Brokers. >=20 > They default at 1280 and allow users to configure them higher when the > path allows. And when the path changes due to a routing change? > And 1280 always works it seems: never heard anybody complain in the near > 15 years that we got SixXS (+IPng.nl) up and running about that. Again, 1280 for the AYIYA tunnel means 1240 or less for other nested IPv6 tunnels, which doesn't work. =20 > [..] > > Nested mobile networks need tunnels-within-tunnels. >=20 > They only need them because you are chosing that. >=20 > I can only suggest to chose something different that is a better solution= . When a mobile router A comes onto a link offered by a mobile router B, which comes onto a link offered by a mobile router C, you have nested tunnels within tunnels. Not an avoidable situation. > > Anyone who VPNs > > into their corporate network from their home network (supported by a > > tunnel) needs tunnels-within-tunnels. >=20 > No. They only need 1 tunnel over their existing IPv4 infrastructure. One tunnel over the existing IPv4 infrastructure to provide IPv6 access to the site. A second tunnel over the IPv6 site to get to the VPN gateway. Means an IPv6-in-(foo)-in-IPv6 tunnel within an IPv6-in-IPv4 tunnel. > I really do not see a second tunnel there. See above. > Though you could do a IPv6 tunnel over that of course if your VPN still > does not support IPv6 "natively" in the tunnel. >=20 >=20 > > We need support for tunnels that recurse indefinitely, because sure as > > dawn breaking someone is going to do it. >=20 > It seems you are determined to do so. >=20 > My position remains though: avoid it! Can't. Not without loss of generality, and not without excluding real use c= ases. > Something about a house of cards and especially the fun of debugging all > of that. I don't know what that means. There is nothing to "debug" with AERO tunnel MTU handling, and it all just works. Thanks - Fred fred.l.templin@boeing.com > Greets, > Jeroen From nobody Wed Dec 3 11:35: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 F1ECC1A89B0 for ; Wed, 3 Dec 2014 11:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 4nK5OSJrVnwr for ; Wed, 3 Dec 2014 11:35:10 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8F701A89A9 for ; Wed, 3 Dec 2014 11:35:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sB3JZAFR026467; Wed, 3 Dec 2014 11:35:10 -0800 Received: from XCH-PHX-409.sw.nos.boeing.com (xch-phx-409.sw.nos.boeing.com [10.57.37.40]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sB3JZ73C026335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Wed, 3 Dec 2014 11:35:07 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-PHX-409.sw.nos.boeing.com ([169.254.9.89]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 11:35:07 -0800 From: "Templin, Fred L" To: "v6ops@ietf.org" Thread-Topic: [v6ops] Report: Bar BoF on a 6to4 replacement Thread-Index: AQHQDmAH0I/jfXJhYUW2sj/c/ybqPJx8qrzwgAGrlICAAAxJgP//pYdAgACQu4D//3s9QIAAi/2A//+YwJAAARVvUA== Date: Wed, 3 Dec 2014 19:35:06 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DAA09E@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <2134F8430051B64F815C691A62D9831832DA992F@XCH-BLV-504.nw.nos.boeing.com> <20141203163947.GB28745@Space.Net> <2134F8430051B64F815C691A62D9831832DA9B81@XCH-BLV-504.nw.nos.boeing.com> <547F42E3.3080508@massar.ch> <2134F8430051B64F815C691A62D9831832DAA05B@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832DAA05B@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/F4jO72QMbtNuM_GeLPTfGrM-4dg Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 19:35:12 -0000 More on tunnel MTU clamping. Tunnels should be able to pass any IP packet s= ize up to the IP protocol maximum (minus encapsulation overhead) as long as the underlying path MTU is sufficient. Clamping the tunnel MTU to any size smal= ler than that will preclude moving to larger sizes (e.g., 8KB or larger). Thanks - Fred fred.l.templin@boeing.com From nobody Wed Dec 3 11: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 7690D1A8AF2 for ; Wed, 3 Dec 2014 11:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 1_Ja0wAOR2qp for ; Wed, 3 Dec 2014 11:36:59 -0800 (PST) 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 B13271A89A7 for ; Wed, 3 Dec 2014 11:36:59 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id et14so16430545pad.29 for ; Wed, 03 Dec 2014 11:36:59 -0800 (PST) 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=IZ/cIk1LMQs/PFsJeR9QX7yp7hEzjMBJFM3af3bTJ5M=; b=A/vm4YGxoTefz+VFn4KVgXoSz/OGKp2GvOxtKPjadaYqPuPEQllBO18axcmb/+80q9 EH6OBgn+XIP4ai6UcA/XFzQXwvxkc9z5pG2oy9AbmTf4KviKg8TtckRLuX9pHiPXi7b0 XzRxnlBS8/TJ4GgWAKK3d9iJMq2+IYQH6hsc48p+00Qjj9upt/rnuxC6XZxoIJ3Q3AHQ Ji7IJXE/4Dkp5XF78MX+TNZI9w7gZBSmuVkvLasNGSzl6c9zoLNTiHn+ps+2BGYo8Y/H 5zLxH4mxPTbMUj8cBi5hDkmK2/X5gNkXfRpCoNo9Dys83oRgqApm0dTi5WR/U0ApHxRY MtVA== X-Received: by 10.70.50.102 with SMTP id b6mr12126704pdo.38.1417635418934; Wed, 03 Dec 2014 11:36:58 -0800 (PST) Received: from [192.168.178.26] (217.197.69.111.dynamic.snap.net.nz. [111.69.197.217]) by mx.google.com with ESMTPSA id b16sm23852174pdj.76.2014.12.03.11.36.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 11:36:57 -0800 (PST) Message-ID: <547F665E.2070804@gmail.com> Date: Thu, 04 Dec 2014 08:37:02 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Hunter References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> In-Reply-To: <547F4D95.7030706@globis.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/fLZ7VDTiD2wgcgYcxk-1DHLUJ7Y Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 03 Dec 2014 19:37:01 -0000 On 04/12/2014 06:51, Ray Hunter wrote: > Sander Steffann wrote: >> Hi, >> >>> Why would the IETF want to put an approved "standard track" marking >>> on what is a very clever but horrible kludge? >> >> Because with the IPv4 addresses running out horrible kludges are >> unfortunately necessary and putting the best of them on standards >> track is the best available option. >> >> Cheers, >> Sander >> >> > What difference would that "Standards Track" stamp make to operations? > ISPs can already deploy A+P today if they want. > > An "Experimental" protocol has a very low requirement for WG review > before publication. > > Changing A+P to "Standards Track" is a very big step IMHO, especially > considering what A+P breaks, and would likely be a drag on future > protocol developments. I'm with Ray on this. We've done our duty by documenting this kludge and tagging it as 'experimental'. I didn't object too much to that, since there are operators who have been forced into this solution by circumstances. But we shouldn't be upgrading it so that it could be understood to be a recommended practice. I also have a technical question. The RFC says, on the subject of user logging: " A+P offers a better set of trade-offs. All that needs to be logged is the allocation of a range of port numbers to a customer. By design, this will be done rarely, improving scalability." With the growth in legally mandated logging around the world, what is the practical experience on this? Has A+P logging proved to be scalable at reasonable cost, or has it become a burden? Which raises a wider question. The writeup simply asserts that "several mechanisms for deploying A+P have been documented and implemented, and are now seeing commercial deployment." I think we need a much more substantive report on the experiment than that. For example, there were concerns that users who need hundreds of open ports (BitTorrent users, for example) would be penalised by A+P. Any data on that? Brian > > When do you think we can expect the first "No, you can't publish that > because it will break A+P, which is Standards Track" comment? > From nobody Wed Dec 3 11:58: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 014C71A9128 for ; Wed, 3 Dec 2014 11:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 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_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 ZaXHzCfFHgUj for ; Wed, 3 Dec 2014 11:58:27 -0800 (PST) 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 3C7371A1BDA for ; Wed, 3 Dec 2014 11:58:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 9606C65; Wed, 3 Dec 2014 20:58:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= references:message-id:content-transfer-encoding:date:date :in-reply-to:x-mailer:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1417636696; bh=zBTWTo1dJbBLaeeEhXwvkY+9xhZmNIQDHKznIQnfbuc=; b=q RpzpNiaUFlcpEEr7RVolM3WId2Ah45uBCHoBqxOicfveAZXpimE7bxUI7tF8s6xR J8Gz0Ch2zzHliEBR0PIRj4LKjLj81hov1UymuLhusLEazEeO4FcljM6UnhP7uGG2 7bw30YW2xf4QXXIbSmvY0zScyfX5kenTKgPPY9eNfU= 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 10026) with ESMTP id ff58hgoXTwDZ; Wed, 3 Dec 2014 20:58:16 +0100 (CET) Received: from [10.10.27.103] (unknown [46.249.45.125]) by mail.sintact.nl (Postfix) with ESMTPSA id E3D0D45; Wed, 3 Dec 2014 20:58:16 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Sander Steffann X-Mailer: iPhone Mail (12B436) In-Reply-To: <547F665E.2070804@gmail.com> Date: Wed, 3 Dec 2014 20:58:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5478E4C2-D709-4EFD-BC86-A5068576DAE3@steffann.nl> References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> <547F665E.2070804@gmail.com> To: Brian E Carpenter Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hB4NtxsMJ_X_3p6qIlj2gkKCCiA Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 03 Dec 2014 19:58:29 -0000 Hi, > I'm with Ray on this. We've done our duty by documenting this kludge > and tagging it as 'experimental'. I didn't object too much to that, > since there are operators who have been forced into this solution by > circumstances. But we shouldn't be upgrading it so that it could be > understood to be a recommended practice. Do then what *is* the recommended practice to deal with a shortage of IPv4 a= ddresses for ISPs? Big NAT boxes? We can't pretend the problem doesn't exist= ... > I also have a technical question. The RFC says, on the subject of > user logging: >=20 > " A+P offers a better set of trade-offs. All that needs to be logged > is the allocation of a range of port numbers to a customer. By > design, this will be done rarely, improving scalability." >=20 > With the growth in legally mandated logging around the world, what is > the practical experience on this? Has A+P logging proved to be scalable > at reasonable cost, or has it become a burden? A+P logging is doable. NAT transaction living is a huge burden. Besides that= : it might be legal to log the assigned A+P port range and it might not be l= egal to log NAT transactions (privacy issues). The Netherlands is a jurisdic= tion where this is the case. I checked that with the local regulator and law= enforcement a few years ago. > Which raises a wider question. The writeup simply asserts that "several > mechanisms for deploying A+P have been documented and implemented, and > are now seeing commercial deployment." I think we need a much more > substantive report on the experiment than that. For example, there were > concerns that users who need hundreds of open ports (BitTorrent users, > for example) would be penalised by A+P. Any data on that? Well, connections are 4-tuples so usually this depends on if the client's NA= T implementation will reuse a port number our not. Technically it can be sol= ved. CGN implementations have the same issue. The number of available address and= port combinations is much larger, but so is the number of sessions. If each= NAT session requires a unique local 2-tuple instead of a unique full 4-tupl= e then that will be a limiting factor... Cheers, Sander From nobody Wed Dec 3 12: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 8DA6A1A914B for ; Wed, 3 Dec 2014 12:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, T_RP_MATCHES_RCVD=-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 s5vyxyJmyOz2 for ; Wed, 3 Dec 2014 12:20:21 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id AE9241A923A for ; Wed, 3 Dec 2014 12:20:17 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Wed, 3 Dec 2014 14:20:11 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f172.google.com [209.85.223.172] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ie0-f172.google.com with SMTP id tr6so14466125ieb.31 for ; Wed, 03 Dec 2014 12:20:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cAGDnujPX29f5+VfsSpiNk1FZIfofj+/30YiqYMYQow=; b=TOTh2MZli4MoHhxcJw+8S+MiKvnLBNQa0HaifDx4z6sjm2vOUVdad0Nsr9tuoo5ZpI xmV4QCcXfFtMUYC9oh/324NB1IAFd4aEl1ah2EY2ino8o0GkL9vm0fcrGYbtm71prktB 6jnrjS82w3wpNjnIY971/Dhdqe72mxd4oDJqM= 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=cAGDnujPX29f5+VfsSpiNk1FZIfofj+/30YiqYMYQow=; b=Kq5FvOU4VkU7j0TOYuuCXzAkk4ZdU/xH1m/jliNFg+u5ZRNNCGM/+1irmvmahuv6l4 S86VRNnNJct1umLCE75HNQpJ/L9weJoYLbfKFq1KiuyDga6LBOrfS2MRQNjKkqzL4UGC hY9OlsqS+wqESM79jmnrP51DCHH/FiAx4coE75YooBCiGuPdKJRhROA4ImEFKgyy7QZj M4dWm51ghJcr9oKfsoOUu6advd7RYZei/ByhdgfdKYswpunTMDBlMF+UXVfSrcl8/Efn h/Wilgu/OZWMI+HRFkLmGgxW23/0f1x/WMDp9R6Nw0vQ5RRtGMnuEf2u5Wuzg1wG1blX T5gw== X-Gm-Message-State: ALoCoQkPEnx1GnOSaIJ5NR014hd3bhM9FIlbfxsXnpB9okXTGSUPq51wUYPWq9+VopPL4nhfOVTEB4DJrZOTuLR68JQz35vP1Q75rsKEghCAWRMTN4+ndyFkvEk1/jYU37EvkR72Y1zM X-Received: by 10.51.17.107 with SMTP id gd11mr10408105igd.45.1417638010804; Wed, 03 Dec 2014 12:20:10 -0800 (PST) X-Received: by 10.51.17.107 with SMTP id gd11mr10408089igd.45.1417638010637; Wed, 03 Dec 2014 12:20:10 -0800 (PST) Received: from x-160-94-246-232.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:6c79:d70f:7940:363c]) by mx.google.com with ESMTPSA id qc7sm8009638igb.5.2014.12.03.12.20.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 12:20:09 -0800 (PST) Message-ID: <547F7076.2080907@umn.edu> Date: Wed, 03 Dec 2014 14:20:06 -0600 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.6.0 MIME-Version: 1.0 To: "v6ops@ietf.org WG" References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <93034721-BA1A-45C5-A3F5-0838DE3DB3FE@delong.com> <547EC5A9.8010603@massar.ch> 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/-80CORGquH1zGenFpiWXm10aRd8 Subject: [v6ops] Filtering 6to4 (Was: Bar BoF on a 6to4 replacement?) 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: Wed, 03 Dec 2014 20:20:22 -0000 On 12/3/14, 04:11 , John Mann wrote: ... > After dual-stack IPv6 was enabled on most subnets, protocol 41 and > Teredo were blocked at Monash's Internet border on 15-Jun-2011. I don't > recall anyone ever asking for it to be re-enabled. ... I like to bring us back to the discussion of of filtering the route for 192.88.99.0/24 relating to draft-ietf-v6ops-6to4-to-historic; I would like to see some discussion around this in the draft, is it BCP, or at least acceptable, to block 6to4 once dual stack is deployed to end user? What is the best and least destructive way to do so? What of the trade-offs for the available options? Security implications? Block protocol 41? Filter route to 192.88.99.0/24? Many security people are twitchy and would like to filter protocol 41 for security reasons. Finally, filtering Teredo is an interesting question too, but out of scope for the draft in question, IMHO. 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 Wed Dec 3 12:53: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 049FC1AC3E1 for ; Wed, 3 Dec 2014 12:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 IxX-0A88M_it for ; Wed, 3 Dec 2014 12:53:40 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40A5A1A7008 for ; Wed, 3 Dec 2014 12:53:28 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-2) over TLS secured channel with ESMTP id 5487f745.0.6080489.00-2017.16984785.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 03 Dec 2014 20:53:28 +0000 (UTC) X-MXL-Hash: 547f784823cc8943-347deef1984cfe256db749f28cd6448e791ee2da Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id sB3KrOvG001822; Wed, 3 Dec 2014 15:53:25 -0500 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id sB3KrIQ4001769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 3 Dec 2014 15:53:19 -0500 Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (GAALPA1MSGHUBAA.itservices.sbc.com [130.8.218.150]) by alpi131.aldc.att.com (RSA Interceptor); Wed, 3 Dec 2014 20:53:00 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.168]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 15:53:00 -0500 From: "STARK, BARBARA H" To: Keith Moore , "v6ops@ietf.org" Thread-Topic: [v6ops] Report: Bar BoF on a 6to4 replacement Thread-Index: AQHQDmAKknrolJVBiE6d1BADldbYJ5x9AGaAgAEjoICAAAxIgIAAKXgAgAAF7ACAAAFZgIAAA/0AgAAHjgCAAAWIAIAADwsA//+57BA= Date: Wed, 3 Dec 2014 20:52:58 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130ED2052@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <547F3218.4060101@network-heretics.com> <547F3710.50106@massar.ch> <547F3831.50408@network-heretics.com> <547F3B8A.3020805@massar.ch> <547F41E0.1090303@network-heretics.com> <547F4684.7010505@massar.ch> <547F5322.70804@network-heretics.com> In-Reply-To: <547F5322.70804@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.107.127] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=AoRZKpBP c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=w_APKFFe6OcA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=A92cGCtB03wA:10 a=vggBfdFIA] X-AnalysisOut: [AAA:8 a=l8qhrVYNAAAA:8 a=GCBo63dGTwxVX_YKGkwA:9 a=CjuIK1q_] X-AnalysisOut: [8ugA:10 a=hkODgbchuuYA:10 a=AdBcZHYdx-BJ1UQm:21 a=Qx_oG3lG] X-AnalysisOut: [1n0FVW4Y:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Xna6I_gVgcmSB0A-NedVxH7n2cg Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 20:53:44 -0000 > I also think that the > widespread support of anycast 6to4 in hosts and consumer routers was > evidence of at least a perception of a need for easy v6 connectivity > over v4. =20 Thankfully, support of 6to4 and Teredo directly in consumer routers was not= widespread.=20 For grins and giggles I went on amazon.com and looked at the "network route= rs" with sort on "new and popular". Looking at just the first 9 listed to m= e, 4 indicated support for "IPv6". Of those 4, it looks like 2 do 6rd (and = 1 does 6to4), but that was really hard to figure out. This is 3.5 years aft= er the publication of RFC 6204 and a year after RFC 7084 (which didn't chan= ge much from 6204 related to native IPv6 and added optional 6rd requirement= s). And figuring this out was like pulling teeth. It's buried way down in t= he gory technical details of what's supported on these routers -- not in th= e top list of features that are prominently advertised. For more laughs, I went looking at IPv6 usage on Comcast and AT&T. Comcast = has stated that 100% of its network is IPv6 (native) enabled, and AT&T has = a lot of native out there, but all customers have access to 6rd. According = to http://www.worldipv6launch.org/measurements/, both are around 28% of tra= ffic to IPv6-enabled sites using IPv6. What accounts for the difference bet= ween 100% and 28% is the number of customers who don't have IPv6-enabled (o= r 6rd-enabled and configured) CE routers. And I'd be willing to bet the *va= st* majority of the 28% is using ISP-provided CE routers -- not retail ones= . As another example, Charter Communications (who I use as one of my 2 ISPs= ) has a 6rd service that any of their customers can use; but almost no-one = uses it.=20 I have 6rd working for both my AT&T and Charter ISP connections. For both I= had to get my own router and manually configure 6rd (no DHCP config from e= ither ISP). Finding the right router was really hard and painful. Getting c= onfiguration info and inputting it (once I got the right router) was easy. = Both connections work great -- no complaints from anyone in my family. IMO 1. The only proven way to get truly widespread IPv6 usage is through ISP de= ployments and ISP mechanisms that upgrade ISP-provided routers in a free-to= -the-user and user-does-nothing manner. Beyond upgrades to ISP-provided rou= ters, you're depending on CE router churn to replace the embedded base. 2. We need for the "new and popular" CE routers being shipped today all to = support native IPv6. Distracting the manufacturers with yet another tunnel = protocol (hey, wait, vendors -- don't do IPv6 yet because we're not done wi= th IPv6 standards!) will not be helpful in reaching this goal. 3. 4 years after publication of a new tunnel standard, you might be lucky e= nough to get maybe 20% of newly shipping CE routers to include support of i= t; and discovering which CE routers have that support is likely to be reall= y hard.=20 4. ISPs won't be upgrading the routers they provide to support the new stan= dard (because ISPs won't be the ones deploying it since they can do 6rd if = not native). You would be depending totally on users buying new CE routers = who happen to stumble across one with support (since it sounds like the tar= get demographic is people who can't spell "IPv6"). 5. I was talking to one of the people at IETF from Nigeria. The concern she= expressed to me about IPv6 was how to get the embedded base of CE routers = (in Nigeria) replaced. Most can't be upgraded. The cost will be considerabl= e, and there's no-one offering to pay for it. Please don't create yet-another-tunnel protocol. Please do whatever you can= to convince CE router vendors to implement native IPv6 and 6rd today. Barbara From nobody Wed Dec 3 13:50: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 34D271A877B for ; Wed, 3 Dec 2014 13:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 iVOYLMahMlOV for ; Wed, 3 Dec 2014 13:50:31 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57ACC1A7031 for ; Wed, 3 Dec 2014 13:50:31 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 55D82100AB8BE; Wed, 3 Dec 2014 21:50:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417643428; bh=fbTe2j7mZ9JFbqUpHvHB2KoE2CJuPRR9WQtL0kVlOrc=; h=Date:From:To:Subject:References:In-Reply-To; b=k1jk9MrDDZLTO53hPGhV3QbCZKXFLPjO6Cdr7ohuoYIMSSMNKHOkvaiKjZ2Bbkyl/ oRL6jTB23qUWwAuMFH1RaUa7QWryEuxwMiXQ3d2MneaMJFzRGkimu0ErQuG46pWKu5 11XM8wcj/zScVqtewl3YnFONegoCbI6rYBN29GdoyucWwVaSBJ5LIqNQaU7BXAn3CX IvSh0fa5pxaSef42ZiW10f0ykUL8ZUm7FB82SAzzdo9OBcNfpH+5tVGuzIZOOgM++C o5OrMQan43+f5zG3SZoMEQbDabTYm8CYOMOtcRjDIOY0E+P6/Gw6tsUsvl5whVzOn4 FYcDP63R2ZmgQ== Message-ID: <547F85A3.9000800@massar.ch> Date: Wed, 03 Dec 2014 22:50:27 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: David Farmer , "v6ops@ietf.org WG" References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <93034721-BA1A-45C5-A3F5-0838DE3DB3FE@delong.com> <547EC5A9.8010603@massar.ch> <547F7076.2080907@umn.edu> In-Reply-To: <547F7076.2080907@umn.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/TxqljGl15lktb_fvib73W2sxuig Subject: Re: [v6ops] Filtering 6to4 (Was: Bar BoF on a 6to4 replacement?) 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, 03 Dec 2014 21:50:34 -0000 On 2014-12-03 21:20, David Farmer wrote: > On 12/3/14, 04:11 , John Mann wrote: > ... >> After dual-stack IPv6 was enabled on most subnets, protocol 41 and >> Teredo were blocked at Monash's Internet border on 15-Jun-2011. I don't >> recall anyone ever asking for it to be re-enabled. > ... > > I like to bring us back to the discussion of of filtering the route for > 192.88.99.0/24 relating to draft-ietf-v6ops-6to4-to-historic; > > I would like to see some discussion around this in the draft, is it BCP, > or at least acceptable, to block 6to4 once dual stack is deployed to end > user? IMHO one should never block anything in a network that is supposed to give "Internet access". > What is the best and least destructive way to do so? What of the > trade-offs for the available options? Security implications? > > Block protocol 41? > Filter route to 192.88.99.0/24? Filtering the anycast route might be a reasonable thing to do. But the primary reason for doing so will be to avoid helpdesk calls and by filtering it you might actually generate them. Though !N is a pretty good indicator that there is no route and most stacks will disable 6to4 based on that. > Many security people are twitchy and would like to filter protocol 41 > for security reasons. Please do not call such people "security people". Just put them in the 'paranoia consultants' corner. These folks will also filter anything not 80/443 because all of it is evil and drop ICMPv6. Their network, let them mess it up. There are several RFCs out there covering this. > Finally, filtering Teredo is an interesting question too, but out of > scope for the draft in question, IMHO. Why would you want to filter it? Teredo is a last-resort and in current Windows editions not even enabled. Also Teredo is required for Xbox One, thus better not touch it, their sales department has it hard enough already with that PS4 that just does IPv4. (guess we'll have to wait another 20 years for PS6 there; this while there where PS2s that did IPv6...). Greets, Jeroen From nobody Wed Dec 3 13:50: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 203711A8786 for ; Wed, 3 Dec 2014 13:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 PS1NtISxinmH for ; Wed, 3 Dec 2014 13:50:42 -0800 (PST) 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 598641A8788 for ; Wed, 3 Dec 2014 13:50:42 -0800 (PST) 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 sB3LofE9005887; Wed, 3 Dec 2014 15:50:41 -0600 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 sB3Lodvc005711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 3 Dec 2014 15:50:39 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-PHX-310.sw.nos.boeing.com ([169.254.10.69]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 13:50:38 -0800 From: "Templin, Fred L" To: "STARK, BARBARA H" , Keith Moore , "v6ops@ietf.org" Thread-Topic: [v6ops] Report: Bar BoF on a 6to4 replacement Thread-Index: AQHQDmAH0I/jfXJhYUW2sj/c/ybqPJx9AGaAgAEjoICAAAxIgIAAKXgAgAAF7ACAAAFZgIAAA/0AgAAHjgCAAAWIAIAADwsA//+57BCAACxB0A== Date: Wed, 3 Dec 2014 21:50:38 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DAA2EB@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <686FABB5-9A9E-4D0C-BD1A-19CA02A9C247@muada.com> <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <546CE0E9.9080101@network-heretics.com> <2134F8430051B64F815C691A62D9831832DA7B35@XCH-BLV-504.nw.nos.boeing.com> <547F0F4F.90107@massar.ch> <547F3218.4060101@network-heretics.com> <547F3710.50106@massar.ch> <547F3831.50408@network-heretics.com> <547F3B8A.3020805@massar.ch> <547F41E0.1090303@network-heretics.com> <547F4684.7010505@massar.ch> <547F5322.70804@network-heretics.com> <2D09D61DDFA73D4C884805CC7865E61130ED2052@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130ED2052@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DY7ay-PppNqw257_cYC3_L3LlNY Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 03 Dec 2014 21:50:46 -0000 > Please don't create yet-another-tunnel protocol. Just so this comment is not taken out of context, please note that AERO is = about much more than just IPv6-over-IPv4 tunneling in ISP networks. That would be only one domain of applicability; AERO applies across many other domains. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of STARK, BARBARA H > Sent: Wednesday, December 03, 2014 12:53 PM > To: Keith Moore; v6ops@ietf.org > Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement >=20 > > I also think that the > > widespread support of anycast 6to4 in hosts and consumer routers was > > evidence of at least a perception of a need for easy v6 connectivity > > over v4. >=20 > Thankfully, support of 6to4 and Teredo directly in consumer routers was n= ot widespread. >=20 > For grins and giggles I went on amazon.com and looked at the "network rou= ters" with sort on "new and popular". Looking at just the > first 9 listed to me, 4 indicated support for "IPv6". Of those 4, it look= s like 2 do 6rd (and 1 does 6to4), but that was really hard to figure > out. This is 3.5 years after the publication of RFC 6204 and a year after= RFC 7084 (which didn't change much from 6204 related to native > IPv6 and added optional 6rd requirements). And figuring this out was like= pulling teeth. It's buried way down in the gory technical > details of what's supported on these routers -- not in the top list of fe= atures that are prominently advertised. >=20 > For more laughs, I went looking at IPv6 usage on Comcast and AT&T. Comcas= t has stated that 100% of its network is IPv6 (native) > enabled, and AT&T has a lot of native out there, but all customers have a= ccess to 6rd. According to > http://www.worldipv6launch.org/measurements/, both are around 28% of traf= fic to IPv6-enabled sites using IPv6. What accounts for > the difference between 100% and 28% is the number of customers who don't = have IPv6-enabled (or 6rd-enabled and configured) CE > routers. And I'd be willing to bet the *vast* majority of the 28% is usin= g ISP-provided CE routers -- not retail ones. As another > example, Charter Communications (who I use as one of my 2 ISPs) has a 6rd= service that any of their customers can use; but almost > no-one uses it. >=20 > I have 6rd working for both my AT&T and Charter ISP connections. For both= I had to get my own router and manually configure 6rd (no > DHCP config from either ISP). Finding the right router was really hard an= d painful. Getting configuration info and inputting it (once I got > the right router) was easy. Both connections work great -- no complaints = from anyone in my family. >=20 > IMO > 1. The only proven way to get truly widespread IPv6 usage is through ISP = deployments and ISP mechanisms that upgrade ISP-provided > routers in a free-to-the-user and user-does-nothing manner. Beyond upgrad= es to ISP-provided routers, you're depending on CE > router churn to replace the embedded base. > 2. We need for the "new and popular" CE routers being shipped today all t= o support native IPv6. Distracting the manufacturers with > yet another tunnel protocol (hey, wait, vendors -- don't do IPv6 yet beca= use we're not done with IPv6 standards!) will not be helpful > in reaching this goal. > 3. 4 years after publication of a new tunnel standard, you might be lucky= enough to get maybe 20% of newly shipping CE routers to > include support of it; and discovering which CE routers have that support= is likely to be really hard. > 4. ISPs won't be upgrading the routers they provide to support the new st= andard (because ISPs won't be the ones deploying it since > they can do 6rd if not native). You would be depending totally on users b= uying new CE routers who happen to stumble across one > with support (since it sounds like the target demographic is people who c= an't spell "IPv6"). > 5. I was talking to one of the people at IETF from Nigeria. The concern s= he expressed to me about IPv6 was how to get the embedded > base of CE routers (in Nigeria) replaced. Most can't be upgraded. The cos= t will be considerable, and there's no-one offering to pay for > it. >=20 > Please don't create yet-another-tunnel protocol. Please do whatever you c= an to convince CE router vendors to implement native IPv6 > and 6rd today. >=20 > Barbara >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Dec 3 13:52: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 777EE1A1A78 for ; Wed, 3 Dec 2014 13:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 I_hTNHNaA5im for ; Wed, 3 Dec 2014 13:52:07 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E67741A7003 for ; Wed, 3 Dec 2014 13:52:06 -0800 (PST) Received: from [192.168.178.22] (5356AD6E.cm-6-7c.dynamic.ziggo.nl [83.86.173.110]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sB3LpdhO017465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Dec 2014 22:51:39 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Iljitsch van Beijnum In-Reply-To: <547F7076.2080907@umn.edu> Date: Wed, 3 Dec 2014 22:51:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <20DDFCD1-0CD6-4820-A358-CC4419B8B53C@muada.com> References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <93034721-BA1A-45C5-A3F5-0838DE3DB3FE@delong.com> <547EC5A9.8010603@massar.ch> <547F7076.2080907@umn.edu> To: David Farmer X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XYsHe1F9zhIO4MwnTKSzVfpwWbU Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Filtering 6to4 (Was: Bar BoF on a 6to4 replacement?) 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, 03 Dec 2014 21:52:12 -0000 On 03 Dec 2014, at 21:20, David Farmer wrote: > is it BCP, or at least acceptable, to block 6to4 once dual stack is = deployed to end user? I find it completely unacceptable. ISPs have no business filtering = legitimate packets. > What is the best and least destructive way to do so? What of the = trade-offs for the available options? Security implications? > Block protocol 41? This would be the worst way to do it because it also blocks "manual" = (non-6to4) tunnels. > Filter route to 192.88.99.0/24? This is also a bad way to do it because now 6to4 systems send packets = into a black hole. The best way to handle 6to4 is simply to let it do it = do whatever it's going to do and succeed or fail accordingly. But if you = want to filter it then the least destructive way would be to run a 6to4 = gateway on 192.88.99.1 for your users and have that gateway return = ICMPv6 unreachables to those users. > Many security people are twitchy and would like to filter protocol 41 = for security reasons. That's nice, but ISPs have no business making those decisions for their = customers.= From nobody Wed Dec 3 13:58: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 C1DEF1ACD54 for ; Wed, 3 Dec 2014 13:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 a6mlFUXOImdj for ; Wed, 3 Dec 2014 13:58:17 -0800 (PST) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF3CC1ACD52 for ; Wed, 3 Dec 2014 13:58:16 -0800 (PST) Received: by mail-pd0-f170.google.com with SMTP id v10so1142940pde.29 for ; Wed, 03 Dec 2014 13:58:16 -0800 (PST) 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=wd/m4ti3UGCMnyQ+cEUilcHQSj8qKvlFolLv/vozG/4=; b=aXT1XZqWkKe4JqA7CKYAixZ6HJigo5guG8t+i+lToAPpbQBaImrOMcbPR0QnMcuSey i4E51oXZuq61JJfDtPJJOAUr0ciiGZUYSNLau8nB2OYqIVVfS2WvD8VTuosCqMRt2HLb 2X9Dtj//6aCUfl5no2+y2fgqkrzHKMZZcr/5PuBbaSExRX9ueMt3bCMEknZzCdJTnk1Y 6qOhrKPZe+wdfCP0STzO3V2CNHy1tShILqXZQhxozRFJD0AxVO8JTGyzYQqUvj64YJuh Ghc5UkJ8U1NGOttijvuzyGpiZ64tM+BVqNEF04bfgaRaoUw5Sc5XKSZkWzK4jZpFpI54 W3OQ== X-Received: by 10.68.189.195 with SMTP id gk3mr19818350pbc.17.1417643895972; Wed, 03 Dec 2014 13:58:15 -0800 (PST) Received: from [192.168.178.26] (217.197.69.111.dynamic.snap.net.nz. [111.69.197.217]) by mx.google.com with ESMTPSA id o17sm24060406pdn.33.2014.12.03.13.58.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 13:58:15 -0800 (PST) Message-ID: <547F877C.5090306@gmail.com> Date: Thu, 04 Dec 2014 10:58:20 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David Farmer References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <93034721-BA1A-45C5-A3F5-0838DE3DB3FE@delong.com> <547EC5A9.8010603@massar.ch> <547F7076.2080907@umn.edu> In-Reply-To: <547F7076.2080907@umn.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6QORtd7jTOAKvgCGPL2Ywp8fEsU Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Filtering 6to4 (Was: Bar BoF on a 6to4 replacement?) 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, 03 Dec 2014 21:58:19 -0000 David, The WGLC just concluded, and I need to update the draft accordingly. It's clear to me (and I think to the WG Chairs) that the recommendation to filter the anycast root does not have consenses and will be removed. I suggest waiting until we get a new draft out before resuming the debate. Brian On 04/12/2014 09:20, David Farmer wrote: > On 12/3/14, 04:11 , John Mann wrote: > ... >> After dual-stack IPv6 was enabled on most subnets, protocol 41 and >> Teredo were blocked at Monash's Internet border on 15-Jun-2011. I don't >> recall anyone ever asking for it to be re-enabled. > ... > > I like to bring us back to the discussion of of filtering the route for > 192.88.99.0/24 relating to draft-ietf-v6ops-6to4-to-historic; > > I would like to see some discussion around this in the draft, is it BCP, > or at least acceptable, to block 6to4 once dual stack is deployed to end > user? > > What is the best and least destructive way to do so? What of the > trade-offs for the available options? Security implications? > > Block protocol 41? > Filter route to 192.88.99.0/24? > > Many security people are twitchy and would like to filter protocol 41 > for security reasons. > > Finally, filtering Teredo is an interesting question too, but out of > scope for the draft in question, IMHO. > > Thanks. > From nobody Wed Dec 3 14:00: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 A6CE01ACD56 for ; Wed, 3 Dec 2014 13:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 5DY3Y1VV5M66 for ; Wed, 3 Dec 2014 13:59:56 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ECFA1ACD54 for ; Wed, 3 Dec 2014 13:59:56 -0800 (PST) Received: by mail-pa0-f41.google.com with SMTP id rd3so16555985pab.14 for ; Wed, 03 Dec 2014 13:59:55 -0800 (PST) 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=kQYbF/Hvx0T3qyTDR6nHWN4VyIHbhN75Fs816UBVtDg=; b=D/OHELSyKFqTJ2HuOE2pDEzuD6S6wumzhS0J3wMVpomPPU1mSGDk6rTMLxn3yWeTJF NTGBRrC5DozLAEhk+emJ6AiwUfn8L02n2JKqJVSgOZwIHBB6s4FHenINe4AZY8mmDjsy 4Y/waQVIKdb1yJ36jnigyde5JxPBmB56XAF4pXi8j8jP+lx8A80NnCZeAHvNk8E5LHMq +CB3g0S1Mu+88S0JYa/jVGiXEaIDXj8m8c4qrzbpOdaTTv0wI34yDT3Voq2sOATWPZAl tc3yCrMhNdOHImuKv9H2Hi50l3gl6o3o4nh6ZZTEiY1kFHXA8f01pa/NGC0ryanYA9PS +7Vg== X-Received: by 10.70.87.173 with SMTP id az13mr12743770pdb.134.1417643995749; Wed, 03 Dec 2014 13:59:55 -0800 (PST) Received: from [192.168.178.26] (217.197.69.111.dynamic.snap.net.nz. [111.69.197.217]) by mx.google.com with ESMTPSA id av8sm13168427pbd.80.2014.12.03.13.59.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 13:59:54 -0800 (PST) Message-ID: <547F87E0.7070000@gmail.com> Date: Thu, 04 Dec 2014 11:00:00 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "v6ops@ietf.org WG" References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <93034721-BA1A-45C5-A3F5-0838DE3DB3FE@delong.com> <547EC5A9.8010603@massar.ch> <547F7076.2080907@umn.edu> <547F877C.5090306@gmail.com> In-Reply-To: <547F877C.5090306@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/gbGma1Zav4hdd2THmLboBuRAPCo Subject: Re: [v6ops] Filtering 6to4 (Was: Bar BoF on a 6to4 replacement?) 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, 03 Dec 2014 21:59:58 -0000 OK, I typed too fast but I guess the typos are obvious... Regards Brian On 04/12/2014 10:58, Brian E Carpenter wrote: > David, > > The WGLC just concluded, and I need to update the draft accordingly. > It's clear to me (and I think to the WG Chairs) that the recommendation > to filter the anycast root does not have consenses and will be removed. > I suggest waiting until we get a new draft out before resuming the > debate. > > Brian > > On 04/12/2014 09:20, David Farmer wrote: >> On 12/3/14, 04:11 , John Mann wrote: >> ... >>> After dual-stack IPv6 was enabled on most subnets, protocol 41 and >>> Teredo were blocked at Monash's Internet border on 15-Jun-2011. I don't >>> recall anyone ever asking for it to be re-enabled. >> ... >> >> I like to bring us back to the discussion of of filtering the route for >> 192.88.99.0/24 relating to draft-ietf-v6ops-6to4-to-historic; >> >> I would like to see some discussion around this in the draft, is it BCP, >> or at least acceptable, to block 6to4 once dual stack is deployed to end >> user? >> >> What is the best and least destructive way to do so? What of the >> trade-offs for the available options? Security implications? >> >> Block protocol 41? >> Filter route to 192.88.99.0/24? >> >> Many security people are twitchy and would like to filter protocol 41 >> for security reasons. >> >> Finally, filtering Teredo is an interesting question too, but out of >> scope for the draft in question, IMHO. >> >> Thanks. >> > From nobody Wed Dec 3 14:24: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 40C991A6FC7 for ; Wed, 3 Dec 2014 14:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 xM2JR4N7GgUW for ; Wed, 3 Dec 2014 14:24:25 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e: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 5CAA11A1EF8 for ; Wed, 3 Dec 2014 14:24:25 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id eu11so16548091pac.22 for ; Wed, 03 Dec 2014 14:24:24 -0800 (PST) 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=306G4j6FL8tNAfBlO+3La1rstPmkzl77na1w45ihk8M=; b=xkW9+koaqcAXWQ1nP+vx336ar3NOpSKAAwLLzA36HhkGS4QibLdB3/5rdr6zHpgZHT lutFtcfRN5l4HkneYq7xKwlAHDLKCKFOT7twdmOHMo4CsiI13SotJ7DUNGB4WmbJwsZh kBFmpbBoqj6tCDOWE95RjbeyMeGuWFI+FuNAqood4DxHukmg5SiYk+ApQ0Jk/A0VN/Kh 5oa+nxcM9lqfVVAgeXNgDw4aHU85pjrdfRhwz4VMyq/e07SrO+mHFasFiYMkNQd+l5ZY pljERMy8Vv080wI/LYkOcffb/eqols90BXNoH+qkIsSknOcqif05STKchgiqT3ySC2dB Zhmw== X-Received: by 10.70.35.104 with SMTP id g8mr12971617pdj.122.1417645464612; Wed, 03 Dec 2014 14:24:24 -0800 (PST) Received: from [192.168.178.26] (217.197.69.111.dynamic.snap.net.nz. [111.69.197.217]) by mx.google.com with ESMTPSA id nr15sm8460485pdb.73.2014.12.03.14.24.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 14:24:23 -0800 (PST) Message-ID: <547F8D9C.80608@gmail.com> Date: Thu, 04 Dec 2014 11:24:28 +1300 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: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> <547F665E.2070804@gmail.com> <5478E4C2-D709-4EFD-BC86-A5068576DAE3@steffann.nl> In-Reply-To: <5478E4C2-D709-4EFD-BC86-A5068576DAE3@steffann.nl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yWOuc-eBetTK4SjMXNjicGdQvFU Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 03 Dec 2014 22:24:27 -0000 Sander, On 04/12/2014 08:58, Sander Steffann wrote: > Hi, > >> I'm with Ray on this. We've done our duty by documenting this kludge >> and tagging it as 'experimental'. I didn't object too much to that, >> since there are operators who have been forced into this solution by >> circumstances. But we shouldn't be upgrading it so that it could be >> understood to be a recommended practice. > > Do then what *is* the recommended practice to deal with a shortage of IPv4 addresses for ISPs? Big NAT boxes? We can't pretend the problem doesn't exist... I personally have been investing effort in this problem since 1992, and have co-authored a number of RFCs since then. I suppose the recommended practice is (a) support customers primarily with IPv6 and (b) use the kludge of your choice to provide access to legacy IPv4-only sites. RFC 6877 seems to be growing fast, for example. Or you could use the approach described in RFC 6264 (and as far as I can see, you could embed RFC 6436 in that). We are stuck with kludges until the IPv4-only sites go away, but IMHO we should be encouraging kludges that bring IPv6 into play. >> I also have a technical question. The RFC says, on the subject of >> user logging: >> >> " A+P offers a better set of trade-offs. All that needs to be logged >> is the allocation of a range of port numbers to a customer. By >> design, this will be done rarely, improving scalability." >> >> With the growth in legally mandated logging around the world, what is >> the practical experience on this? Has A+P logging proved to be scalable >> at reasonable cost, or has it become a burden? > > A+P logging is doable. NAT transaction living is a huge burden. Besides that: it might be legal to log the assigned A+P port range and it might not be legal to log NAT transactions (privacy issues). The Netherlands is a jurisdiction where this is the case. I checked that with the local regulator and law enforcement a few years ago. Yes, transaction logging is obviously unreasonable, but I was asking for actual experience with A+P logging. >> Which raises a wider question. The writeup simply asserts that "several >> mechanisms for deploying A+P have been documented and implemented, and >> are now seeing commercial deployment." I think we need a much more >> substantive report on the experiment than that. For example, there were >> concerns that users who need hundreds of open ports (BitTorrent users, >> for example) would be penalised by A+P. Any data on that? > > Well, connections are 4-tuples so usually this depends on if the client's NAT implementation will reuse a port number our not. Technically it can be solved. Actual data were presented showing clients opening hundreds of simultaneous ports on their CPE. I'm asking whether that has been experimentally proved to work with A+P boxes. > CGN implementations have the same issue. The number of available address and port combinations is much larger, but so is the number of sessions. If each NAT session requires a unique local 2-tuple instead of a unique full 4-tuple then that will be a limiting factor... Yes, but I'm not asking about CGN. Brian From nobody Wed Dec 3 17:55: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 2C2FA1A6FCD for ; Wed, 3 Dec 2014 17:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.411 X-Spam-Level: X-Spam-Status: No, score=-1.411 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_16=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 z3ARPOJhGZnP for ; Wed, 3 Dec 2014 17:53:38 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 637201A6F8C for ; Wed, 3 Dec 2014 17:53:37 -0800 (PST) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id sB41mWUm025912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Dec 2014 17:48:43 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com sB41mWUm025912 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1417657724; bh=bSfaUqSO7MAie931QY9JV50sSu0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=inRCqR/cAr1sfPo61CO3kdkV5iAMzmQc90OrwGSGHN9zFTVqNb5h8yFkOWW2XJyMC OtQV8uWe2bes6NBG2pm4MFfMltvWDuJxq1PLJsaxKpMkhaf1XevdnJLNrvAOZDabUz ayUpYZ4w9An39j+IVBoViuJQbt/rVhg0NnGHFC24= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: <547F3761.4040506@network-heretics.com> Date: Wed, 3 Dec 2014 17:48:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F3761.4040506@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 03 Dec 2014 17:48:44 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sZzkTq-gz9ayt3uC08JaLl3sEQw Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 04 Dec 2014 01:53:39 -0000 > On Dec 3, 2014, at 8:16 AM, Keith Moore = wrote: >=20 > On 12/03/2014 11:11 AM, Ray Hunter wrote: >>=20 >> Why would the IETF want to put an approved "standard track" marking = on what is a very clever but horrible kludge? >=20 > My question exactly. >=20 > We need to stop pretending that adding kludge after kludge to IPv4 is = in any way meeting proposed standard criteria. >=20 > Instead of standardizing more and more kludges to IPv4, we should be = working toward moving IPv4 to Historic. >=20 > Keith Agreed, but I think that work is in v4sunset rather than v6ops. Owen From nobody Wed Dec 3 17:57: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 C9E4C1A6F8C for ; Wed, 3 Dec 2014 17:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-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 uZTmorR1XTRM for ; Wed, 3 Dec 2014 17:53:44 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 8199B1A00D8 for ; Wed, 3 Dec 2014 17:53:44 -0800 (PST) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id sB41qOQh026102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Dec 2014 17:52:26 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com sB41qOQh026102 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1417657946; bh=ASYJqo2SEc66usiuI29mnUW5SW4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=KiskR+Qv2c/F2h0cfyxCaP5m4H4m5adZvKA7t1ilUIlMMzum5f70jhh79Vpe+OSg0 Q10uRCTEV3q1TDmtmrigfu19iBfHVq3ndD/uq7AcezsZM+8sLwi2AcVKr8OHVH4voN owBptphOUDao7gphraM8yjqKZNuRmBbf1slsIIJE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: Date: Wed, 3 Dec 2014 17:52:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5525C713-5C7E-4BCB-8FEE-A7F36208E33E@delong.com> References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> To: Sander Steffann X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 03 Dec 2014 17:52:26 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VNky_h1RamRl6WSKCkRjo4Y5Ejc Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 04 Dec 2014 01:53:46 -0000 > On Dec 3, 2014, at 8:57 AM, Sander Steffann = wrote: >=20 > Hi, >=20 >> Why would the IETF want to put an approved "standard track" marking = on what is a very clever but horrible kludge? >=20 > Because with the IPv4 addresses running out horrible kludges are = unfortunately necessary and putting the best of them on standards track = is the best available option. No, pointing out that the increasing pain you are feeling using IPv4 is = an increasing reason to move to IPv6 belongs on the standards track. Pretending that the best of the worst, the cream of the crap of = increasingly painful kludges should be standardized just fuels the = mistaken impression that IPv6 can be further procrastinated. Owen From nobody Wed Dec 3 18:05: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 024841A6FFD for ; Wed, 3 Dec 2014 18:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-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 NcQyRZzvbDfe for ; Wed, 3 Dec 2014 18:03:40 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8F11A1A3C for ; Wed, 3 Dec 2014 18:03:40 -0800 (PST) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id sB41xoU4026669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Dec 2014 17:59:50 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com sB41xoU4026669 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1417658391; bh=zKZMXXwJkBuJFp39SKJseDIMO0c=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=OShdPV4hCLTCYTnvfLl4wyDS81ETxj4flT9zfGckb/1KKuRWbzYyyiRP43DnCkBwN Ox+1lzNsGhvYyZu2xnCEB89o5VZCLuxLz/5yBNQppIV5BlqwCoTie8vz4DSeKXga0U +/mHwLJQx9FQs13N6VZnGnuYrtfox87kJLjQuOBU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: <7A0C8862-3239-4094-A134-9076E03B2297@steffann.nl> Date: Wed, 3 Dec 2014 17:59:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> <7A0C8862-3239-4094-A134-9076E03B2297@steffann.nl> To: Sander Steffann X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 03 Dec 2014 17:59:51 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NK0ZuWm2FgsFPe3-xC75ist1E90 Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 04 Dec 2014 02:03:42 -0000 I think the need for A+P is adequately addressed in its current state. I = do not think moving it to proposed standard is a good idea. Owen > On Dec 3, 2014, at 10:42 AM, Sander Steffann = wrote: >=20 > Hi, >=20 >> Changing A+P to "Standards Track" is a very big step IMHO, especially = considering what A+P breaks, and would likely be a drag on future = protocol developments. >=20 > For IPv4 development: yep. >=20 > There are not enough IPv4 addresses so they have to be shared. Using = NAT in ISP networks for address sharing needs lots of state. A+P gives = us the option to do that in a stateless way, which is good for = scalability and stability. >=20 > If A+P is the best we can do for IPv4 at this time then that's what we = need to design for. I don't like it either and I long for the day that = we can run IPv6-only and get rid of IPv4. Until then I think this is the = best way forward. >=20 >> When do you think we can expect the first "No, you can't publish that = because it will break A+P, which is Standards Track" comment? >=20 > When it's necessary :( > Sander >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Dec 3 21:10: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 CAE881A0056 for ; Wed, 3 Dec 2014 21:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 q_Ubbh1etX3V for ; Wed, 3 Dec 2014 21:10:41 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0118D1A0073 for ; Wed, 3 Dec 2014 21:10:41 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1XwOgY-0007UK-CH; Thu, 04 Dec 2014 05:10:38 +0000 Date: Thu, 04 Dec 2014 14:10:37 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <547F8D9C.80608@gmail.com> References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> <547F665E.2070804@gmail.com> <5478E4C2-D709-4EFD-BC86-A5068576DAE3@steffann.nl> <547F8D9C.80608@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/AfJQMUvcVb_cDCQhKyVznJnMvuw Cc: V6 Ops List Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 04 Dec 2014 05:10:43 -0000 > We are stuck with kludges until the IPv4-only sites go away, but > IMHO we should be encouraging kludges that bring IPv6 into play. you may want to actually read 6346, say 3.1.7, 4.1, ... and, in fact, 6346 was written specifically to offer alternatives to cgn, e.g. see 1.1. randy From nobody Thu Dec 4 00:58: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 B51751A8948 for ; Thu, 4 Dec 2014 00:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 BybolFPny5ur for ; Thu, 4 Dec 2014 00:58:12 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id A78A81A00EB for ; Thu, 4 Dec 2014 00:58:11 -0800 (PST) Received: (qmail 32592 invoked from network); 4 Dec 2014 08:58:09 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 4 Dec 2014 08:58:09 -0000 Date: Thu, 04 Dec 2014 09:58:09 +0100 (CET) Message-Id: <20141204.095809.74726281.sthaug@nethelp.no> To: jeroen@massar.ch From: sthaug@nethelp.no In-Reply-To: <547F3CE8.4090302@massar.ch> References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> 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/eY6f7LXTANNR5xEoP6ymGJMjRuA Cc: v6ops@ietf.org Subject: Re: [v6ops] Report: Bar BoF on a 6to4 replacement 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, 04 Dec 2014 08:58:15 -0000 > >> I do still do not see why that a MTU of < 1500 but >1280 is a limitation > >> in any way. > > > > Hosts have become conditioned to expect 1500. > > Which hosts? Most IPv4 nodes are connected with a LOT less... I would actually like to see some statistics on this. I'm afraid I regard the SixXS user base (and MTU info) as somewhat skewed in comparison to the general public. As a counterexample, I work for one of the larger ISPs in Norway. We offer full 1500 byte MTU to all customers, including residential/DSL, and also for IPv6. Business customers can get larger MTU on request. Steinar Haug, AS 2116 From nobody Thu Dec 4 01:02: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 374831A8968 for ; Thu, 4 Dec 2014 01:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 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_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 Xi3cJ0UkI3tk for ; Thu, 4 Dec 2014 01:02:39 -0800 (PST) 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 520181A8966 for ; Thu, 4 Dec 2014 01:02:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 9463467; Thu, 4 Dec 2014 10:02:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= references:message-id:content-transfer-encoding:date:date :in-reply-to:x-mailer:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1417683755; bh=W8ddseudLSIWI68cgy0zkwDgUiZArHYY8vVBoLUUrCA=; b=E DeVOAnZZem91XrivYOFF4Q3Tef0goUNmucF2bvdUsydEyQpvfN15gP4xA8GuXo7p rjxa9qnz98CrF4fdIk0KfvRREWevsWITMK2LjWfkZInmGkTAJYHsI7pDaKXTBk5i YCdKGmKG47Il1PtxcscgI79MKEKJsIQJgaJ3atc/tY= 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 10026) with ESMTP id eFnwbn2tmmiw; Thu, 4 Dec 2014 10:02:35 +0100 (CET) Received: from [IPv6:2a00:8640:1::586e:8e68:2a3d:a5c5] (unknown [IPv6:2a00:8640:1:0:586e:8e68:2a3d:a5c5]) by mail.sintact.nl (Postfix) with ESMTPSA id 6D9DA36; Thu, 4 Dec 2014 10:02:35 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Sander Steffann X-Mailer: iPhone Mail (12B436) In-Reply-To: <547F8D9C.80608@gmail.com> Date: Thu, 4 Dec 2014 10:02:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> <547F665E.2070804@gmail.com> <5478E4C2-D709-4EFD-BC86-A5068576DAE3@steffann.nl> <547F8D9C.80608@gmail.com> To: Brian E Carpenter Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jjGagvVcI3fIDmBEao3jfxnDpRY Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 04 Dec 2014 09:02:41 -0000 Hi Brian, > I personally have been investing effort in this problem since 1992, and > have co-authored a number of RFCs since then. I know. Sorry, didn't mean to imply that you didn't know what you were talki= ng about our something like that. > I suppose the recommended > practice is (a) support customers primarily with IPv6 and (b) use > the kludge of your choice to provide access to legacy IPv4-only sites. > RFC 6877 seems to be growing fast, for example. Or you could use the > approach described in RFC 6264 (and as far as I can see, you could > embed RFC 6436 in that). >=20 > We are stuck with kludges until the IPv4-only sites go away, but > IMHO we should be encouraging kludges that bring IPv6 into play. The RFC recommends that: A+P-in-IPv6. All the other RFCs you mention require= a stateful central device. I think that that's a bad practice, even if wide= ly deployed. >>> I also have a technical question. The RFC says, on the subject of >>> user logging: >>>=20 >>> " A+P offers a better set of trade-offs. All that needs to be logged >>> is the allocation of a range of port numbers to a customer. By >>> design, this will be done rarely, improving scalability." >>>=20 >>> With the growth in legally mandated logging around the world, what is >>> the practical experience on this? Has A+P logging proved to be scalable >>> at reasonable cost, or has it become a burden? >>=20 >> A+P logging is doable. NAT transaction living is a huge burden. Besides t= hat: it might be legal to log the assigned A+P port range and it might not b= e legal to log NAT transactions (privacy issues). The Netherlands is a juris= diction where this is the case. I checked that with the local regulator and l= aw enforcement a few years ago. >=20 > Yes, transaction logging is obviously unreasonable, but I was asking > for actual experience with A+P logging. I don't have any. What exactly do you want to log anyway? There isn't that m= uch to log from a stateless device except how the stateless mapping algorith= m is configured... >>> Which raises a wider question. The writeup simply asserts that "several >>> mechanisms for deploying A+P have been documented and implemented, and >>> are now seeing commercial deployment." I think we need a much more >>> substantive report on the experiment than that. For example, there were >>> concerns that users who need hundreds of open ports (BitTorrent users, >>> for example) would be penalised by A+P. Any data on that? >>=20 >> Well, connections are 4-tuples so usually this depends on if the client's= NAT implementation will reuse a port number our not. Technically it can be s= olved. >=20 > Actual data were presented showing clients opening hundreds of > simultaneous ports on their CPE. I'm asking whether that has > been experimentally proved to work with A+P boxes. >=20 >> CGN implementations have the same issue. The number of available address a= nd port combinations is much larger, but so is the number of sessions. If ea= ch NAT session requires a unique local 2-tuple instead of a unique full 4-tu= ple then that will be a limiting factor... >=20 > Yes, but I'm not asking about CGN. Sorry, I think you're asking the wrong questions then :) The problem areas y= ou point out are real, but not specific to A+P. We know we can't find a perfect solution to the IPv4 address shortage proble= m so of course A+P had its problems. We should compare them to the problems o= f the alternatives to determine if A+P is the best we can do and deserves to= be on the standards track. Cheers, Sander From nobody Thu Dec 4 01:49: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 9BA7E1A0120 for ; Thu, 4 Dec 2014 01:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 JIUhtSSwYnUy for ; Thu, 4 Dec 2014 01:49:24 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7121A0117 for ; Thu, 4 Dec 2014 01:49:23 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id C8374100A228B; Thu, 4 Dec 2014 09:49:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417686559; bh=3cE+JShPqNShuhLKm/jppNj4AAOs+xCxAz1g9sMcRGs=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=vREBzkNkvgh1RDwJQfVVnyYJNKHebepFMP0Sb2seuwKMWv+x2Ld/DYOBD0xwP+vt0 YZAaQ1XfSaN8apGWHxejctAq+PJLGkM6hhQGD3wYDXBZdFu1g8JrCr8WghY70KF/AA EyS1HPdWsbW38DbjQyh/qr/9XrvzWznKOsTQFKvksHeEiZpJBWdpvAnA5NHz+v3FX0 WBYmtFy8oErK6pDYh0FiwQrApnzenx80+nrt9oTm+IbBm5kz9hPmByXQKIKN5V7a35 wGCCrWbhLE0TrGCy6grBXA79eqx+MhGzfHCU4MtMeqImwdO6GtmKY/oRxOJm8hdbmn h6naVQOH49GxA== Message-ID: <54802E1D.9070401@massar.ch> Date: Thu, 04 Dec 2014 10:49:17 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: sthaug@nethelp.no References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> In-Reply-To: <20141204.095809.74726281.sthaug@nethelp.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-cbsMXKSo7EmiJ9uRicb-Oalbj4 Cc: v6ops@ietf.org Subject: [v6ops] MTUs on the general Internet (Was: Report: Bar BoF on a 6to4 replacement) 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, 04 Dec 2014 09:49:26 -0000 [Geoff, any measurements you know of?] On 2014-12-04 09:58, sthaug@nethelp.no wrote: >>>> I do still do not see why that a MTU of < 1500 but >1280 is a limitation >>>> in any way. >>> >>> Hosts have become conditioned to expect 1500. >> >> Which hosts? Most IPv4 nodes are connected with a LOT less... > > I would actually like to see some statistics on this. I'm afraid I > regard the SixXS user base (and MTU info) as somewhat skewed in > comparison to the general public. Yes, it is a quite limited view. Though at least it covers hundreds of different ISPs where the endusers are. The primary thing I think though that one can take away from those numbers is that people do not really care about MTU and that they are mostly fine with 1280. There is then also no real perceived benefit for them as long as their stuff is 'fast'. I don't even think a speedtest will show the difference too much between 1280 and the 1480 that a proto-41 tunnel could do, though in theory it is a lot of overhead. As such shoving the people who kept it to 1280 as in a "do not care" category, only few actual changers remain. Possibly this is a better report to look at: https://labs.ripe.net/Members/emileaben/ripe-atlas-packet-size-matters at least takes data from where Atlas probes are located, but those tend to be reasonably managed networks again. Those numbers are for ICMP. It is hard to get a good estimate of this as it involves people to provide the data or doing some kind of magic probing around the world; There is ISI's tr-643.pdf but unfortunately ftp.isi.edu is down and can't seem to find a cached copy anywhere else (except for mackeeper malware spreading sites it seems...) Geoff wrote this a few years back: http://www.potaroo.net/ispcol/2009-02/mtu.pdf but that does not cover the general MTU sizes available. Of course on the IPv6 level we do not care there it is a minimum of 1280 or pMTU. > As a counterexample, I work for one of the larger ISPs in Norway. We > offer full 1500 byte MTU to all customers, including residential/DSL, > and also for IPv6. Most networks that I am aware of do indeed do 1500. Though quite a few do deploy PPPoE or similar systems and end up with 1480 there already unless they use a larger size for the Ethernet that that runs over (trick also employed by 6rd folks). > Business customers can get larger MTU on request. That is great, but are they able to use it in a meaningful way? I know a couple of networks that run at a MTU of 9000 in the core, but it is rare to see that intra-AS. Similar to this mystical Multicast thing. Though I think there is an actual business case to be made for larger MTUs unlike the business case for intra-AS-Multicast. Greets, Jeroen From nobody Thu Dec 4 01:53: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 BC1251A0130 for ; Thu, 4 Dec 2014 01:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 dKEp9lTT6u0G for ; Thu, 4 Dec 2014 01:53:19 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2431A0117 for ; Thu, 4 Dec 2014 01:53:19 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1XwT61-0000tZ-TX; Thu, 04 Dec 2014 09:53:14 +0000 Date: Thu, 04 Dec 2014 18:53:12 +0900 Message-ID: From: Randy Bush To: Sander Steffann In-Reply-To: References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> <547F665E.2070804@gmail.com> <5478E4C2-D709-4EFD-BC86-A5068576DAE3@steffann.nl> <547F8D9C.80608@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/s2RK1DP_KSoY2TUmgGk_XFj_Ug8 Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 04 Dec 2014 09:53:20 -0000 > The RFC recommends that: A+P-in-IPv6. All the other RFCs you mention > require a stateful central device. I think that that's a bad practice, > even if widely deployed. > ... > We know we can't find a perfect solution to the IPv4 address shortage > problem so of course A+P had its problems. We should compare them to > the problems of the alternatives to determine if A+P is the best we > can do and deserves to be on the standards track. https://mailarchive.ietf.org/arch/msg/ietf/e7zp6v0ihm2_F47bQO5GpDu708Y From nobody Thu Dec 4 02:07: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 E25E51A0149 for ; Thu, 4 Dec 2014 02:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 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_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 45Ty3xRJJlSd for ; Thu, 4 Dec 2014 02:07:37 -0800 (PST) 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 004941A0126 for ; Thu, 4 Dec 2014 02:07:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 0B2A867; Thu, 4 Dec 2014 11:07:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= references:message-id:content-transfer-encoding:date:date :in-reply-to:x-mailer:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1417687652; bh=S92L6s6PmPPehaK+SruVY57ADqakz+KRP4BndjjusYA=; b=I qk8spF2J71Kbe26CVjNgUWyv5M9iZ/0/wd15ZWg0R0uYclumM6M0Mr4Y3h3R0fAt QnAdhDPTWaErorikzIyCJQJHj3dlW304NZvZhSMLpZPltyGomY4mXHYo2LK6VAdY dIHGyRKQ/7SYcMFRY4Yfy19az5sH+5EA2ZXl40qfyY= 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 10026) with ESMTP id eMJTvVhnfD40; Thu, 4 Dec 2014 11:07:32 +0100 (CET) Received: from [IPv6:2a00:8640:1::586e:8e68:2a3d:a5c5] (unknown [IPv6:2a00:8640:1:0:586e:8e68:2a3d:a5c5]) by mail.sintact.nl (Postfix) with ESMTPSA id DA2C436; Thu, 4 Dec 2014 11:07:32 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Sander Steffann X-Mailer: iPhone Mail (12B436) In-Reply-To: Date: Thu, 4 Dec 2014 11:07:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> <547F665E.2070804@gmail.com> <5478E4C2-D709-4EFD-BC86-A5068576DAE3@steffann.nl> <547F8D9C.80608@gmail.com> To: Randy Bush Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/C7xQG2ng3wSmi92eqqGZ76k7Mnw Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 04 Dec 2014 10:07:43 -0000 Hi Randy, Op 4 dec. 2014 om 10:53 heeft Randy Bush het volgende geschr= even: >> The RFC recommends that: A+P-in-IPv6. All the other RFCs you mention >> require a stateful central device. I think that that's a bad practice, >> even if widely deployed. >> ... >> We know we can't find a perfect solution to the IPv4 address shortage >> problem so of course A+P had its problems. We should compare them to >> the problems of the alternatives to determine if A+P is the best we >> can do and deserves to be on the standards track. >=20 > https://mailarchive.ietf.org/arch/msg/ietf/e7zp6v0ihm2_F47bQO5GpDu708Y Ah, that's where that deja-vu came from. Thanks for the pointer. Cheers, Sander From nobody Thu Dec 4 02: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 17BC91A0119 for ; Thu, 4 Dec 2014 02:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 HHtKKTZtD-7n for ; Thu, 4 Dec 2014 02:18:22 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 5AD8A1A0146 for ; Thu, 4 Dec 2014 02:18:20 -0800 (PST) Received: (qmail 35297 invoked from network); 4 Dec 2014 10:18:20 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 4 Dec 2014 10:18:20 -0000 Date: Thu, 04 Dec 2014 11:18:20 +0100 (CET) Message-Id: <20141204.111820.41660320.sthaug@nethelp.no> To: jeroen@massar.ch From: sthaug@nethelp.no In-Reply-To: <54802E1D.9070401@massar.ch> References: <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> 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/sfh1k1BXZyblnJMViZ0TwfvuObk Cc: v6ops@ietf.org Subject: Re: [v6ops] MTUs on the general Internet 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, 04 Dec 2014 10:18:24 -0000 > The primary thing I think though that one can take away from those > numbers is that people do not really care about MTU and that they are > mostly fine with 1280. There is then also no real perceived benefit for > them as long as their stuff is 'fast'. "People" as in residential users may not really care about MTU as long as their Facebook and Youtube works. I can assure you that our business users *do* care: 1500 byte MTU (or more) is a *hard* requirement for a lot of the contracts we bid on ("hard" meaning: If we didn't offer at least 1500 byte MTU, we would automatically be excluded from that bid). Thus we have concluded that it's far simpler to just offer 1500 bytes to all customers. Note that we don't use PPPoE except for a few limited circumstances. Steinar Haug, AS 2116 From nobody Thu Dec 4 02:36: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 79DB81A0146 for ; Thu, 4 Dec 2014 02:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 EpQyVIXbFzYX for ; Thu, 4 Dec 2014 02:36:20 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DCBE1A0183 for ; Thu, 4 Dec 2014 02:36:20 -0800 (PST) Received: from kami.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 01DCC100A2269; Thu, 4 Dec 2014 10:36:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417689378; bh=1zzjRxLFF7iI9eFYULMU0vrXlzwCC7P0bB54aOMf6wc=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=IY4o5SAwg4SQKTx294ZZkMpHpp+NxhCgOACEnvhgNZFiJ/XGq6ut80e5r63jK5S8H Yw77RFsILumpViGE+Xhy5hNBmrl4gXqZ7xqHISq1XGyfe4le6x1WXyyPYRXNi0oBPX 5oyT36Nxdv4gt9bTLRtoya0FEJKZ8vHRF5+WZHU8LX+EDpSNPnieLhpnSlEKUVqL5E cLdJCoLh8kpekr/kW+Pqvz/pt5Ufh5RhJr/NuEhFqmQW+5FUhbbM3oN+BGVzfHKhb8 5DtNa0qMD87Hco1abjnOEUAp9O/vhz3t+9bys8yPjcIJWelELDNxOyY1DiKNL4dsEV RCnguQrFSl0CQ== Message-ID: <5480391F.9040902@massar.ch> Date: Thu, 04 Dec 2014 11:36:15 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: sthaug@nethelp.no References: <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141204.111820.41660320.sthaug@nethelp.no> In-Reply-To: <20141204.111820.41660320.sthaug@nethelp.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_9_6VXhb42chOSZCLG8U8T2noCQ Cc: v6ops@ietf.org Subject: Re: [v6ops] MTUs on the general Internet 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, 04 Dec 2014 10:36:23 -0000 On 2014-12-04 11:18, sthaug@nethelp.no wrote: >> The primary thing I think though that one can take away from those >> numbers is that people do not really care about MTU and that they are >> mostly fine with 1280. There is then also no real perceived benefit for >> them as long as their stuff is 'fast'. > > "People" as in residential users may not really care about MTU as long > as their Facebook and Youtube works. I cannot disagree at all ;) > I can assure you that our business users *do* care: 1500 byte MTU (or > more) is a *hard* requirement for a lot of the contracts we bid on > ("hard" meaning: If we didn't offer at least 1500 byte MTU, we would > automatically be excluded from that bid). Interesting. Any background on why they have that requirement? Though likely likely don't want to rely on pMTU for at least the cases close to home (as one cannot control that for the rest of the Internet). > Thus we have concluded that it's far simpler to just offer 1500 bytes > to all customers. Note that we don't use PPPoE except for a few limited > circumstances. I don't see why one would offer anything else actually unless the tech really does not support it. Greets, Jeroen From nobody Thu Dec 4 04:15: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 BF1291A0302 for ; Thu, 4 Dec 2014 04:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 I1uRGHquaqVj for ; Thu, 4 Dec 2014 04:15:36 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001: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 624541A0276 for ; Thu, 4 Dec 2014 04:15:36 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id rp18so15662514iec.38 for ; Thu, 04 Dec 2014 04:15:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hFVGisEaB7e2SzZnePF6/HTkRIXGwHWYzpXuiEOcmbQ=; b=BJ8mqm/Y4T+ElydfvPSSISVSz7DDs7T9ie3x8Gba8FQwJBkivL4o8RPpslbX9jrhg7 85+sfIj+o2a5TQ0jdv+7FS4ki3dHyNeG5xvDTAvOD1iorVu3JdCLcBD50WiP7SdRjKiI HSQIAF4ahyYc8LYq6UbgyyLJETfMnHFhc2CSKsg4Ft6KkU/n0u3EKPRCe2CRUSvnuP0w VKh3M5HgIWZjtkdUlnxjfUTLxC4hGWir3oTejXIu5njrSLHYhbvK4OyFRlH8cDk9IQOH uQ19UUxKeMay+3AizbcQsOSAkZuikETdUdBr3Mw+eNwoEVcJnQ53M6BMF89QtrX2e/rz hLug== 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=hFVGisEaB7e2SzZnePF6/HTkRIXGwHWYzpXuiEOcmbQ=; b=cKrD23PF9OPXZsusMjV3MU1Kz29iMJNpBpHZ7gd8kSR2hRHSh9l9695TXry3UmUbdQ YgEfTPoHbGWHIg1m1GzC8KTCYz8cD67DqAttUuJ4+b8wAkRxANWkB22qkzJBFIglnsjZ Jz46+FYv/p8bGdarAmz4UZ/H+A8n6DPGZGmojqeDNvtqiZqDGy9LbcEEVhzYQVWtSBRc N2XmdrDXkX63G2ZMotlHXgGwbnNGf8zK/baE/HWnlf9i8TFei5DH/4SVqaG0tYHUz5EE OccdkG29OjUEOJEX60XaXVkfd70pRfuKft2w+Ifly7XA95ZrcTgwCP6eHNVpTBzKTxAb VMuQ== X-Gm-Message-State: ALoCoQkgHhSdCw8d2v3C0bEuvrhtS3DUdnkwmYfzeo7x2Wex1n3zFw/S4+O4L/k53iLjv9sDfisz X-Received: by 10.107.170.162 with SMTP id g34mr9599310ioj.2.1417695334305; Thu, 04 Dec 2014 04:15:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.130.167 with HTTP; Thu, 4 Dec 2014 04:15:14 -0800 (PST) In-Reply-To: References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> <547F665E.2070804@gmail.com> <5478E4C2-D709-4EFD-BC86-A5068576DAE3@steffann.nl> <547F8D9C.80608@gmail.com> From: Lorenzo Colitti Date: Thu, 4 Dec 2014 21:15:14 +0900 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=001a11426c3ccd43a8050962ea62 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vkyIlw45gQEjFHhGVv8i3_CKGhw Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 04 Dec 2014 12:15:38 -0000 --001a11426c3ccd43a8050962ea62 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 4, 2014 at 6:53 PM, Randy Bush wrote: > > We know we can't find a perfect solution to the IPv4 address shortage > > problem so of course A+P had its problems. We should compare them to > > the problems of the alternatives to determine if A+P is the best we > > can do and deserves to be on the standards track. > > https://mailarchive.ietf.org/arch/msg/ietf/e7zp6v0ihm2_F47bQO5GpDu708Y I thought A+P basically ended up becoming MAP. Do I misunderstand? --001a11426c3ccd43a8050962ea62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 4, 2014 at 6:53 PM, Randy Bush <randy@psg.com> wrote:
> We know we can't = find a perfect solution to the IPv4 address shortage
> problem so of course A+P had its problems. We should compare them to > the problems of the alternatives to determine if A+P is the best we > can do and deserves to be on the standards track.

https://mailarchive.ietf.org/arch/msg/ietf= /e7zp6v0ihm2_F47bQO5GpDu708Y

I thought = A+P basically ended up becoming MAP. Do I misunderstand?=C2=A0
<= /div>
--001a11426c3ccd43a8050962ea62-- From nobody Thu Dec 4 04:18: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 BD0301A0276 for ; Thu, 4 Dec 2014 04:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 mRhvKGh3Plb0 for ; Thu, 4 Dec 2014 04:18:01 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8611A026E for ; Thu, 4 Dec 2014 04:18:01 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1XwVM8-0001hI-0K; Thu, 04 Dec 2014 12:18:00 +0000 Date: Thu, 04 Dec 2014 21:17:58 +0900 Message-ID: From: Randy Bush To: Lorenzo Colitti In-Reply-To: References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> <547F665E.2070804@gmail.com> <5478E4C2-D709-4EFD-BC86-A5068576DAE3@steffann.nl> <547F8D9C.80608@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/vSdZp4d0T1WiL3PJUlgCuPVvO0w Cc: V6 Ops List Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 04 Dec 2014 12:18:03 -0000 >>> We know we can't find a perfect solution to the IPv4 address shortage >>> problem so of course A+P had its problems. We should compare them to >>> the problems of the alternatives to determine if A+P is the best we >>> can do and deserves to be on the standards track. >> >> https://mailarchive.ietf.org/arch/msg/ietf/e7zp6v0ihm2_F47bQO5GpDu708Y > > I thought A+P basically ended up becoming MAP. Do I misunderstand? you are talking about ipv6 transition mechanisms, right? there can never be enough of them. :) map-?, 4rd, 6rd (but inversely), ... are a+p varieties. the list goes on. randy From nobody Thu Dec 4 04:26: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 215261A0364 for ; Thu, 4 Dec 2014 04:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 l7Esu0X0b8Em for ; Thu, 4 Dec 2014 04:26:09 -0800 (PST) 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 E07491A0248 for ; Thu, 4 Dec 2014 04:26:08 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id h15so18613423igd.2 for ; Thu, 04 Dec 2014 04:26:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5QbzLwZd9fni/mOU/mvxjjT03PBp0bBPBuZIzfPtWqI=; b=C/i1bCW1lXTJi2LxbA2VsKgfFLwffAxeQWdNIHww1b22GOQayG8pk2w4zD1dfuEzZV 6yQwA1HQa4Cn0gN69W/h2BPvOiPGLiDdJkLhiObY33n1c69gBvAb0PAeUNAxjjkC++2M qCpEjDQw8h6rsiaNe1JpxacMgYwdXv6ikiRSxuqELnofGveLtp2TofV9OEpTSGr5UIla 5WTgPbPj3/TUMaotJrbl9XUDxM8Sx8gBZ2QQMLTuiCEhlcHI3SdHme2wHAEht1L8in6G uGelTmyC0vEmYx0+G7SAkY/jSXoLKi3utYUm4rZlt7r2grHeJjU2VIllFFzc4dhEuQUX vbLg== 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=5QbzLwZd9fni/mOU/mvxjjT03PBp0bBPBuZIzfPtWqI=; b=K+yO6qanFXSO05zKR+pkFbqgR9YmOKR0V3FtcDkOr0McPNzfelQIn0qgTfdg0IzsfD r4/aGbyn30nuXB91zTDIJAuxZsmzVyR6AFJ3QUde6De0lvhba+3eDsb0nanznn4wx5+F FJbkD4ia/PTZ7V9q5plMY+kGdEZFr30JsQchy/b5h0I7Lx619qZBLlJJIvbvhYbcnR9e pdY+3WU88dy8IKQbaLdlBb0y8bIVkhAjv8ioSbnQ0midHbvd/+zBtX70k+d2N7Z+w20m 9wlkEiA9WCi3wJTxMuFX6SjxDJdJzAS5rO7lbrit4fhBlIeEfaOeSc5gMi70O5cvRqEz 1C2A== X-Gm-Message-State: ALoCoQmoOVZcfWA8VD3RnEmEZJm9IkwVn688AS4rjMasGt+oaWs3wj3l1dz4l2pVd1q21l54IVDk X-Received: by 10.42.207.76 with SMTP id fx12mr10767076icb.17.1417695967823; Thu, 04 Dec 2014 04:26:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.130.167 with HTTP; Thu, 4 Dec 2014 04:25:47 -0800 (PST) In-Reply-To: References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> <547F665E.2070804@gmail.com> <5478E4C2-D709-4EFD-BC86-A5068576DAE3@steffann.nl> <547F8D9C.80608@gmail.com> From: Lorenzo Colitti Date: Thu, 4 Dec 2014 21:25:47 +0900 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=20cf303bfd048fec0c0509631005 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/tWnCAyY1asvkRfCwag2igc9ni6E Cc: V6 Ops List Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 04 Dec 2014 12:26:10 -0000 --20cf303bfd048fec0c0509631005 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 4, 2014 at 9:17 PM, Randy Bush wrote: > > I thought A+P basically ended up becoming MAP. Do I misunderstand? > > you are talking about ipv6 transition mechanisms, right? there can > never be enough of them. :) > > map-?, 4rd, 6rd (but inversely), ... are a+p varieties. the list goes > on. > Right. So yes, A+P was successful, and spawned a series of transition mechanisms. Whether that means we need to issue a new Proposed Standard RFC I don't know. It doesn't really contain anything to standardize, right? --20cf303bfd048fec0c0509631005 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 4, 2014 at 9:17 PM, Randy Bush <randy@psg.com> wrote:
> I thought A+P basical= ly ended up becoming MAP. Do I misunderstand?

you are talking about ipv6 transition mechanisms, right?=C2=A0 there= can
never be enough of them.=C2=A0 :)

map-?, 4rd, 6rd (but inversely), ...=C2=A0 are a+p varieties.=C2=A0 the lis= t goes
on.

Right. So yes, A+P was successful, = and spawned a series of transition mechanisms. Whether that means we need t= o issue a new Proposed Standard RFC I don't know. It doesn't really= contain anything to standardize, right?
--20cf303bfd048fec0c0509631005-- From nobody Thu Dec 4 04:26: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 2CA9A1A026E for ; Thu, 4 Dec 2014 04:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 FuK-RiYod0Bw for ; Thu, 4 Dec 2014 04:26:47 -0800 (PST) Received: from samstag.members.selfnet.de (samstag.members.selfnet.de [IPv6:2001:7c0:e701:800::199]) by ietfa.amsl.com (Postfix) with ESMTP id 51A0E1A0377 for ; Thu, 4 Dec 2014 04:26:39 -0800 (PST) Received: from [IPv6:2001:7c0:0:f1b::1004] (unknown [IPv6:2001:7c0:0:f1b::1004]) by samstag.members.selfnet.de (Postfix) with ESMTPSA id 77BDA21C3DA for ; Thu, 4 Dec 2014 13:26:36 +0100 (CET) Message-ID: <548052FB.1080605@haitabu.net> Date: Thu, 04 Dec 2014 13:26:35 +0100 From: Tim Kleefass User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20141122083347.GA1033@Space.Net> In-Reply-To: <20141122083347.GA1033@Space.Net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mAuRL75Nd-xHPJLF662zK4ndHNQ Subject: Re: [v6ops] On IPv6 address part naming 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, 04 Dec 2014 12:26:49 -0000 On 22.11.2014 9:33 AM, Gert Doering wrote: > On Thu, Nov 20, 2014 at 07:03:13PM +0100, Richard Hartmann wrote: >> as you may remember, I tried to push a draft on IPv6 address naming[1] >> back in 2010 on both v6ops [2] and 6man [3]. >> >> As I finally have enough spare cycles again I want to try and push >> this as a WG item within v6ops one last time. > > "Hextet" sounds good to me, even if not fully pedantically correct - but > it's short, easy to pronounce (at least for german speakers) and to remember. > > As for "shall the WG adopt the draft" - well, this is operational, and > it helps if people talking about "things" use the same terminology, so > I'd support that. Good summary, I'd like to second that. Cheers, Tim From nobody Thu Dec 4 05:04: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 64D861A19EC for ; Thu, 4 Dec 2014 05:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 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_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 aQCFY2-p9384 for ; Thu, 4 Dec 2014 05:04:02 -0800 (PST) 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 844761A0163 for ; Thu, 4 Dec 2014 05:04:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 6634267; Thu, 4 Dec 2014 14:04:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= references:message-id:content-transfer-encoding:date:date :in-reply-to:x-mailer:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1417698234; bh=zoVs12xw8BaCkAiiEYSrHZD0u5foRqBld6YYHULRyGk=; b=i 9fO8Tzdb8AoomTppwiL5hhuqrSAumsG5+hfLFLPpyNcHHFR9NIxiEqBCF43o3JLo mNbW9ML0vfi1N8IYf5kvvN615gF3EZ7vF/D0VXpLI+YPsdIjzk67KmlRs5FpNAnt invUTWT5dMV2M2Nn5ZtTiTVvW7/CzYwOB24L7xfmwg= 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 10026) with ESMTP id tMdYAQkMxybt; Thu, 4 Dec 2014 14:03:54 +0100 (CET) Received: from [37.77.56.86] (temp86.10ww.steffann.nl [37.77.56.86]) by mail.sintact.nl (Postfix) with ESMTPSA id CA0CB36; Thu, 4 Dec 2014 14:03:54 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Sander Steffann X-Mailer: iPhone Mail (12B436) In-Reply-To: Date: Thu, 4 Dec 2014 14:03:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> <547F665E.2070804@gmail.com> <5478E4C2-D709-4EFD-BC86-A5068576DAE3@steffann.nl> <547F8D9C.80608@gmail.com> To: Lorenzo Colitti Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/aNEkzbd3hx0dbSYy1ilRdZs2DJI Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 04 Dec 2014 13:04:07 -0000 Hi Lorenzo, > I thought A+P basically ended up becoming MAP. Do I misunderstand?=20 MAP is indeed the most common implementation of the A+P architecture. For ma= ny practical purposes they are kind of equivalent these days. Cheers, Sander From nobody Thu Dec 4 05:14: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 5F6FD1A1A33 for ; Thu, 4 Dec 2014 05:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 m9nnPnHKkvjf for ; Thu, 4 Dec 2014 05:14:19 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BFF21A19F4 for ; Thu, 4 Dec 2014 05:14:18 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sB4DEF7b003462 for ; Thu, 4 Dec 2014 14:14:15 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4AC432025B3 for ; Thu, 4 Dec 2014 14:14:18 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 394F3202412 for ; Thu, 4 Dec 2014 14:14:18 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sB4DEEwp015866 for ; Thu, 4 Dec 2014 14:14:15 +0100 Message-ID: <54805E26.4040709@gmail.com> Date: Thu, 04 Dec 2014 14:14:14 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20141122083347.GA1033@Space.Net> <548052FB.1080605@haitabu.net> In-Reply-To: <548052FB.1080605@haitabu.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Zc8WAqH7TPcaBgrT3w6b-LlVnOc Subject: Re: [v6ops] On IPv6 address part naming 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, 04 Dec 2014 13:14:22 -0000 Le 04/12/2014 13:26, Tim Kleefass a écrit : > On 22.11.2014 9:33 AM, Gert Doering wrote: >> On Thu, Nov 20, 2014 at 07:03:13PM +0100, Richard Hartmann wrote: >>> as you may remember, I tried to push a draft on IPv6 address naming[1] >>> back in 2010 on both v6ops [2] and 6man [3]. >>> >>> As I finally have enough spare cycles again I want to try and push >>> this as a WG item within v6ops one last time. >> >> "Hextet" sounds good to me, even if not fully pedantically correct - but >> it's short, easy to pronounce (at least for german speakers) and to remember. >> >> As for "shall the WG adopt the draft" - well, this is operational, and >> it helps if people talking about "things" use the same terminology, so >> I'd support that. > > Good summary, I'd like to second that. I third adoption, but wonder about coherence of this particular naming at other SDOs. Alex > > Cheers, > Tim > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Dec 4 05:36: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 3E1BC1A8969 for ; Thu, 4 Dec 2014 05:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 KJxpMtw7OOaa for ; Thu, 4 Dec 2014 05:36:13 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5382D1A1A70 for ; Thu, 4 Dec 2014 05:36:11 -0800 (PST) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:5586:9946:45c2:b54d] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sB4DZgK5042017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Dec 2014 14:35:43 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Iljitsch van Beijnum In-Reply-To: <5480391F.9040902@massar.ch> Date: Thu, 4 Dec 2014 14:36:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141204.111820.41660320.sthaug@nethelp.no> <5480391F.9040902@massar.ch> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Cj8pj6MDDUbJ2nUIpEkEY3-O1Wc Subject: [v6ops] Quick measurement: MTUs on the general Internet 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, 04 Dec 2014 13:36:18 -0000 I did some tcpdumping on my server. It's not a very busy server, so I = got 927 incoming TCP SYNs in two hours, mostly on port 80. 866 of them = included the maximum segment size (MSS) option, 584 IPv4 and 282 IPv6. I also looked at ICMP(v6) too bigs. I got 4 for IPv6, which looks like = they were all for my own stuff (they are from the HE tunnel broker) and = not a single one for IPv4. The MSS size distribution is: IPv6 (MSS =3D MTU - 60 (sizeof(IPv6) + sizeof(TCP)): 1440: 47 1420: 207 1386: 1 1220: 27 Three of these sizes make total sense: native ethernet (1440), ethernet = with IPv6-in-IPv4 (1420) and the minimum IPv6 MTU (1220). The only = surprising thing is that tunneled is so much more than native. Note that = in these cases, either the source host terminates the tunnel, the router = terminating the tunnel advertises the reduced tunnel MTU or a device = along the way rewrites the MSS (which is common with IPv4 but not AFAIK = with IPv6). IPv4 is a different story: IPv4 (MSS =3D MTU - 40 (sizeof(IPv4) + sizeof(TCP)): 1460: 364 1452: 36 1448: 1 1440: 53 1430: 19 1420: 11 1414: 13 1410: 3 1400: 11 1392: 2 1380: 43 1360: 18 1260: 5 1240: 5 "Native IPv4" over ethernet is only 62%. Another 6% must be PPPoE. 1440 = and 1240 could be IPv4-in-IPv6, which seems a lot at 10%. And then = there's a whole bunch of strange values, probably numbers people picked = manually. (Note that I didn't de-duplicate IP addresses, so 10% could be 60 = sessions from the same IP address.) Note that in both cases there was nothing below an MTU of 1280 and = nothing above an MTU of 1500. From nobody Thu Dec 4 07:47: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 774E81AD3A1 for ; Thu, 4 Dec 2014 07:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 xrf8XoXW8Oyp for ; Thu, 4 Dec 2014 07:47:36 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92DA41AD45C for ; Thu, 4 Dec 2014 07:46:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sB4FkVgh021676; Thu, 4 Dec 2014 07:46:31 -0800 Received: from XCH-BLV-102.nw.nos.boeing.com (xch-blv-102.nw.nos.boeing.com [130.247.25.117]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sB4FkONV021626 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 4 Dec 2014 07:46:24 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-BLV-102.nw.nos.boeing.com ([169.254.2.137]) with mapi id 14.03.0210.002; Thu, 4 Dec 2014 07:46:23 -0800 From: "Templin, Fred L" To: Jeroen Massar , "sthaug@nethelp.no" Thread-Topic: [v6ops] MTUs on the general Internet Thread-Index: AQHQD6uoIDjpKa4sE0iLXup+XU1oGpx/wweA///PamA= Date: Thu, 4 Dec 2014 15:46:23 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DAACF7@XCH-BLV-504.nw.nos.boeing.com> References: <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141204.111820.41660320.sthaug@nethelp.no> <5480391F.9040902@massar.ch> In-Reply-To: <5480391F.9040902@massar.ch> 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/QbxqOM5zyuafvi1UnBm8gchgZqc Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MTUs on the general Internet 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, 04 Dec 2014 15:47:38 -0000 Hi Jeroen, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Jeroen Massar > Sent: Thursday, December 04, 2014 2:36 AM > To: sthaug@nethelp.no > Cc: v6ops@ietf.org > Subject: Re: [v6ops] MTUs on the general Internet >=20 > On 2014-12-04 11:18, sthaug@nethelp.no wrote: > >> The primary thing I think though that one can take away from those > >> numbers is that people do not really care about MTU and that they are > >> mostly fine with 1280. There is then also no real perceived benefit fo= r > >> them as long as their stuff is 'fast'. > > > > "People" as in residential users may not really care about MTU as long > > as their Facebook and Youtube works. >=20 > I cannot disagree at all ;) >=20 > > I can assure you that our business users *do* care: 1500 byte MTU (or > > more) is a *hard* requirement for a lot of the contracts we bid on > > ("hard" meaning: If we didn't offer at least 1500 byte MTU, we would > > automatically be excluded from that bid). >=20 > Interesting. Any background on why they have that requirement? Principal of least surprise? 1500 has become the "Internet Cell Size" that hosts have come to expect will always succeed. > Though likely likely don't want to rely on pMTU for at least the cases > close to home (as one cannot control that for the rest of the Internet). >=20 > > Thus we have concluded that it's far simpler to just offer 1500 bytes > > to all customers. Note that we don't use PPPoE except for a few limited > > circumstances. >=20 > I don't see why one would offer anything else actually unless the tech > really does not support it. A minimum 1500 is required, whether tunneled or non-tunneled. Thanks - Fred fred.l.templin@boeing.com > Greets, > Jeroen >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Dec 4 07:51: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 46CD01AD394 for ; Thu, 4 Dec 2014 07:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 Esy51U1OaEyr for ; Thu, 4 Dec 2014 07:51:06 -0800 (PST) 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 13EC31AD3BB for ; Thu, 4 Dec 2014 07:49:52 -0800 (PST) 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 sB4FnpgN022549; Thu, 4 Dec 2014 09:49:51 -0600 Received: from XCH-PHX-111.sw.nos.boeing.com (xch-phx-111.sw.nos.boeing.com [130.247.25.132]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sB4FngOn022506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 4 Dec 2014 09:49:42 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-PHX-111.sw.nos.boeing.com ([169.254.11.32]) with mapi id 14.03.0210.002; Thu, 4 Dec 2014 07:49:41 -0800 From: "Templin, Fred L" To: Iljitsch van Beijnum , "v6ops@ietf.org WG" Thread-Topic: [v6ops] Quick measurement: MTUs on the general Internet Thread-Index: AQHQD8dTnaG6oDT/fUuW3SdjusL6epx/k6Mw Date: Thu, 4 Dec 2014 15:49:40 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DAAD20@XCH-BLV-504.nw.nos.boeing.com> References: <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141204.111820.41660320.sthaug@nethelp.no> <5480391F.9040902@massar.ch> 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/_AfVOHONfyWQnQJZll_hshr-23o Subject: Re: [v6ops] Quick measurement: MTUs on the general Internet 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, 04 Dec 2014 15:51:08 -0000 Hi Iljitsch, Nice analysis. You are making a good case for the existence of the 1500 Internet Cell Size as well as MTU diversity. Now we just need to fix the tunnels that can't do 1500. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Iljitsch van Bei= jnum > Sent: Thursday, December 04, 2014 5:36 AM > To: v6ops@ietf.org WG > Subject: [v6ops] Quick measurement: MTUs on the general Internet >=20 > I did some tcpdumping on my server. It's not a very busy server, so I got= 927 incoming TCP SYNs in two hours, mostly on port 80. 866 of > them included the maximum segment size (MSS) option, 584 IPv4 and 282 IPv= 6. >=20 > I also looked at ICMP(v6) too bigs. I got 4 for IPv6, which looks like th= ey were all for my own stuff (they are from the HE tunnel broker) > and not a single one for IPv4. The MSS size distribution is: >=20 > IPv6 (MSS =3D MTU - 60 (sizeof(IPv6) + sizeof(TCP)): >=20 > 1440: 47 > 1420: 207 > 1386: 1 > 1220: 27 >=20 > Three of these sizes make total sense: native ethernet (1440), ethernet w= ith IPv6-in-IPv4 (1420) and the minimum IPv6 MTU (1220). > The only surprising thing is that tunneled is so much more than native. N= ote that in these cases, either the source host terminates the > tunnel, the router terminating the tunnel advertises the reduced tunnel M= TU or a device along the way rewrites the MSS (which is > common with IPv4 but not AFAIK with IPv6). >=20 > IPv4 is a different story: >=20 > IPv4 (MSS =3D MTU - 40 (sizeof(IPv4) + sizeof(TCP)): >=20 > 1460: 364 > 1452: 36 > 1448: 1 > 1440: 53 > 1430: 19 > 1420: 11 > 1414: 13 > 1410: 3 > 1400: 11 > 1392: 2 > 1380: 43 > 1360: 18 > 1260: 5 > 1240: 5 >=20 > "Native IPv4" over ethernet is only 62%. Another 6% must be PPPoE. 1440 a= nd 1240 could be IPv4-in-IPv6, which seems a lot at 10%. > And then there's a whole bunch of strange values, probably numbers people= picked manually. >=20 > (Note that I didn't de-duplicate IP addresses, so 10% could be 60 session= s from the same IP address.) >=20 > Note that in both cases there was nothing below an MTU of 1280 and nothin= g above an MTU of 1500. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Dec 4 08:59: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 6684A1AD4B1 for ; Thu, 4 Dec 2014 08:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 VKukRLlZizqK for ; Thu, 4 Dec 2014 08:59:40 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17CC21A1EFC for ; Thu, 4 Dec 2014 08:59:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5695; q=dns/txt; s=iport; t=1417712380; x=1418921980; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tqddtpEf4MeNm6Bw4UjlPWHEcN2XvgaW0iWexkORbGQ=; b=HufdKzro7uXTcBgNmR6I0tMzER6Rf7nfyiYKKB9fv1SBdwyjZJp8aHW5 vNanSlE323RCebBrqBNTnFvYEeyOwsYr6GgBCo3nL9ST8K+33n7pyNH3r OcEIznc0BJVgaWFV0nXBAXeM7tCgdlmjUjCdr3qVgtllleNtdoxuM5AZ/ U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAPCRgFStJV2Z/2dsb2JhbABZgwZSUwUEuHmNU4YaAoEdFgEBAQEBfYQDAQEEaQEECxACAQgOCi4hESUCBA4FDogbAxII0TgNhV4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXilqDVoI2B4MkgR4FhGECiy2BdoFAYIRCgXKBIziMIAOCMYNpg3lvCwGBOYEAAQEB X-IronPort-AV: E=Sophos;i="5.07,516,1413244800"; d="asc'?scan'208";a="377661919" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 04 Dec 2014 16:59:39 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sB4GxdbT010104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Dec 2014 16:59:39 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 10:59:39 -0600 From: "Fred Baker (fred)" To: Richard Hartmann Thread-Topic: [v6ops] On IPv6 address part naming Thread-Index: AQHQD+OwKIM2/AWxYEW1iqy4uJ6+AA== Date: Thu, 4 Dec 2014 16:59:38 +0000 Message-ID: <1F14A9C3-E5D0-4F6B-BA70-C342F26E7098@cisco.com> References: <20141122083347.GA1033@Space.Net> In-Reply-To: <20141122083347.GA1033@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_46DF1473-2BF3-431A-BF08-0BD651638ADC"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xUupsdIF6LwYS9xMERO-Y89-gvY Cc: IPv6 Operations Subject: Re: [v6ops] On IPv6 address part naming 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, 04 Dec 2014 16:59:43 -0000 --Apple-Mail=_46DF1473-2BF3-431A-BF08-0BD651638ADC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 22, 2014, at 12:33 AM, Gert Doering wrote: > As for "shall the WG adopt the draft" - well, this is operational, and > it helps if people talking about "things" use the same terminology, so > I'd support that. I'm intrigued by the discussion of the word "octet". As of this morning, = 2667 RFCs and 581 posted Internet Drafts use the term, from RFC 635 (as = Owen notes) to RFC 7411 and = draft-hu-softwire-multicast-radius-ext-07.txt, which was probably posted = on today=92s date China Standard Time. RFC 635, which uses the word six = times and talks about "a line control envelope consisting of 48 bits of = control octets and a 24 bit cyclic checksum" among other things, uses it = pretty much the same way we use the term "byte"; it's a basic unit of = information used to describe all sorts of things, but is specifically = about things found in or relevant to messages.=20 RFC 7411's example of the usage is Mobility Header messages exchanged in HI/HAck and FBU/FBack dialogs impose length restrictions on multicast context records due to the 8-bit Length field. The maximal payload length available in FBU/ FBack messages is 4 octets (Mobility Option header line) + 1024 octets (MLD Report Payload).=20 draft-hu-softwire-multicast-radius-ext-07.txt octet mentions IPv6 = multicast addresses, but uses the term =93octet=94 to discuss "the total = length in octets of [an] attribute=94 - it=92s a measure of the size of = a container, not the data in the container. That usage (a basic unit of measure comprised of identifiable eight bit = chunks) is consistent from April 1974 through today. Various folks kicked around various words. An experiment that you may = find amusing: google the word =93hexadectet=94. = http://tinyurl.com/k3aqckb uses the term, there is a Java class by the = name with the intended meaning of a sixteen bit unsigned number, and = there are other hits. The word is in fact out there. Then google the = word =93hextet=94; It is in the Wikipedia and the Urban Dictionary as a = 16 bit quantum of information specifically relevant to an IPv6 address. = It is also (youtube) used to refer to an ensemble of six instruments... If I may ask a silly question: are we inventing or appropriating a word = for a sixteen bit chunk of an IPv6 address, which might have = applicability in RFC 4291bis if and when it gets written and a couple of = other RFCs, or are we inventing a word that is likely to find its way = into 2667 of the next 7400 RFCs over the next 40 years as a basic unit = of measurement? If we're not doing the latter, how valuable is the = definition? Also: are we creating a term, or taking note of one in common usage? = When RFC 635 referred to "48 bits of control octets", it didn't pause to = say "which is to say units of 8 bits in a message as transmitted or as = stored in memory"; the term had to have already been in common use and = presumed to be understood by the readers. I think I can make an argument = that hexadectet and hextet (which my spell checker insists on rewriting = as "sextet") are common enough to be found in a search; I'm not sure a = "gulp" is. Coming back to your initial comment: On Nov 20, 2014, at 10:03 AM, Richard Hartmann = wrote: > If this proves to be too controversial I will go the route of > Informational Independent Submission, but I would really prefer to do > this within this WG. I'm not sure I would describe the effort or conclusion as = "controversial", but I *would* assert that it hasn't yet led to a = consensus or (better) documented an existing consensus. I'm looking for = a sense of "OK, let's all call it a gulp" or whatever, followed by = everyone calling it that. Absent the consensus, wherever and however it = is achieved, were I in Nevil's shoes, I'm not sure I would do much with = it, and I certainly can't. In this WG, I have a charter question. If I heard a thundering sense of = "The sky is falling! We have an operational problem! We need a word for = a 16 bit unit of information!" I might be OK with sending the draft to = may favorite AD. What I hear is a lot more like "this is a fun weekend = diversion" and "if we were to establish such word, the reasonable = derivation of such a word, and therefore the word, might be..." from one = of several european languages and other forms of (often technically = incorrect, as in "hextet") common usage. It seems to me that whatever working group works on this needs to be in = the General Area if it isn=92t specifically operational and specifically = about IPv6 Operations. I=92m not trying to put a damper on the discussion - it has been = diverting - but trying to let you know what I=92m looking for as a = chair. I=92m looking for usefulness in operational and standards = documentation, and consensus, and ideally documentation of an = already-existing consensus. --Apple-Mail=_46DF1473-2BF3-431A-BF08-0BD651638ADC 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 iD8DBQFUgJLlbjEdbHIsm0MRAh0OAKDSf7e6WsANMnQVkKZKrCZZrvSaNwCeO/Vb ryeQr0MdUbX1sKEgOvGUrbo= =a5Ku -----END PGP SIGNATURE----- --Apple-Mail=_46DF1473-2BF3-431A-BF08-0BD651638ADC-- From nobody Thu Dec 4 10:36: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 16E571A6ED8 for ; Thu, 4 Dec 2014 10:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 qLAfHruR4luE for ; Thu, 4 Dec 2014 10:36:51 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C914C1A1B7E for ; Thu, 4 Dec 2014 10:36:51 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1XwbGi-0003xN-Ou; Thu, 04 Dec 2014 18:36:49 +0000 Date: Fri, 05 Dec 2014 03:36:47 +0900 Message-ID: From: Randy Bush To: Lorenzo Colitti In-Reply-To: References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> <547F665E.2070804@gmail.com> <5478E4C2-D709-4EFD-BC86-A5068576DAE3@steffann.nl> <547F8D9C.80608@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/wG-wJKSt82N1M6mQRwmIJ5V81vw Cc: V6 Ops List Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 04 Dec 2014 18:36:53 -0000 > Right. So yes, A+P was successful, and spawned a series of transition > mechanisms. Whether that means we need to issue a new Proposed > Standard RFC I don't know. no one is proposing a new ps. 6346 was mis-classified due to an iesg member's politics of denial of the shared address approach, including sabatoging two shara bofs (s'holm and hiroshima). this merely tries to correct this historical error. randy From nobody Thu Dec 4 11:08: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 C45771A008C for ; Thu, 4 Dec 2014 11:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-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 ao6pQV5Vi_90 for ; Thu, 4 Dec 2014 11:08:32 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 04EBE1A008F for ; Thu, 4 Dec 2014 11:08:30 -0800 (PST) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id sB4J3Sep010038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Dec 2014 11:03:29 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com sB4J3Sep010038 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1417719809; bh=fPERkFeulNegQthoB5sbGNLfC90=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=NC9QPQe/5FzogIjf8xAI4mXU8L0wyJlsvfqYmLmXHPF7urhXsHE29ClldDtMwcoVt +y3bZhm1f8LMoNLs72rphGuc8g1U9himRc9b3GuiuMe4rvDW5SDE4mPgi5YnCbERMP VKRIRz6DiE7iUaYATZfg4ppf3VIYZFkXQeVqH+9I= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: <1F14A9C3-E5D0-4F6B-BA70-C342F26E7098@cisco.com> Date: Thu, 4 Dec 2014 11:03:23 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <15C39DE8-9880-42F4-AA97-540B853EBC7B@delong.com> References: <20141122083347.GA1033@Space.Net> <1F14A9C3-E5D0-4F6B-BA70-C342F26E7098@cisco.com> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 04 Dec 2014 11:03:29 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Qmk4c3yAoFEeMwxm9dTgkX2H_RU Cc: IPv6 Operations Subject: Re: [v6ops] On IPv6 address part naming 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, 04 Dec 2014 19:08:34 -0000 > If I may ask a silly question: are we inventing or appropriating a = word for a sixteen bit chunk of an IPv6 address, which might have = applicability in RFC 4291bis if and when it gets written and a couple of = other RFCs, or are we inventing a word that is likely to find its way = into 2667 of the next 7400 RFCs over the next 40 years as a basic unit = of measurement? If we're not doing the latter, how valuable is the = definition? It=92s not a silly question, but the answer depends on a subtle = distinction you failed to provide. If you are asking what is our intent, then I would say that at least in = my case, the intent is to have a term which can be viable for 2667 (or = however many it turns out to be) of the next 7400 (or however many it = turns out to be) RFCs over the next however many years. If you=92re asking what is the {probable, intended, predicted, expected} = outcome, then I would say it is difficult to predict any but the = intended outcome which I think I clarified in the previous paragraph. If = history has shown us anything over the past 40+ years of standards and = protocol development, it=92s that the expected or predicted outcomes = often bear little or no resemblance to the actual outcomes and that = precisely correct terms which are awkward, lengthy, or difficult to = spell will almost always lose out to simplified terms that are easier to = pronounce. Look at the strong pull which remains to attempt to use the = word byte to define an 8-bit chunk instead of octet. Admittedly, IETF = terminology has remained relatively resolute, but in my every-day life, = I am routinely criticized for sticking to the term octet instead of just = saying byte even though the latter is technically not necessarily = accurate. How many people on this list now the difference between a gibibit and a = gigabit? I=92ll note that Yosemite considers gibibit to be a spelling = error while gigabit is readily accepted. How many people use the term = gibibit? How many use the term gigabit interchangeably for both = meanings? [For those that are now wondering WTF? What s a gibibit and how is it = different, a gigabit is 1,000,000,000 bits (1000*1000*1000) while a = gibibit is 1024*1024*1024 bits (1,073,741,824 bits)]. > Also: are we creating a term, or taking note of one in common usage? = When RFC 635 referred to "48 bits of control octets", it didn't pause to = say "which is to say units of 8 bits in a message as transmitted or as = stored in memory"; the term had to have already been in common use and = presumed to be understood by the readers. I think I can make an argument = that hexadectet and hextet (which my spell checker insists on rewriting = as "sextet") are common enough to be found in a search; I'm not sure a = "gulp" is. I think if we are writing an RFC, then we should be attempting to take = one of the terms in reasonably common usage and express it as the = officially preferred terminology for that particular thing. Such an RFC = should probably include a list of the other terms in previous common = usage and perhaps even a summary of the reasons those terms were not = selected. Owen From nobody Thu Dec 4 11:29: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 EF2D61A010C for ; Thu, 4 Dec 2014 11:29:37 -0800 (PST) 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 LIR1WmNJhNbW for ; Thu, 4 Dec 2014 11:29:35 -0800 (PST) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA3C1A0174 for ; Thu, 4 Dec 2014 11:29:33 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id le20so8173742vcb.40 for ; Thu, 04 Dec 2014 11:29:32 -0800 (PST) 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:content-type; bh=JUgWNtk6s12wRNPn21pts1jLBoLXbZyPRxUWblCFSjQ=; b=PQS7IxYL5AMT8yULzrPKz9tSqGrdwB2aTA6jsatkqZveiIVujdjYSqxyx+H3cSJoSB wf3rvor90SRZmCcdVvrPOmlJRSHqJhUhMvGr8Luosb5e5zt+gBQlhkjSr0hbuCZL9nOD 7PqnrmSHJVSWJ4caxmY5UjCoUqOUGvOkFnn+Hphs+H90V0A9o3ugLQ37eT8Dm7jG+gnx KkUe2KArOyUIx2MIfUDPyL3lmxxRSVxVDA8qguNnjSKAnLCh0hUbHNhhvBXMhc24BNRE jcW2X/cWW9yISf5K/tx7497TYcma+SKV2hwOCiAfoOHGle5r3GMccxvj05+35Y/3c4WT VdIA== X-Gm-Message-State: ALoCoQnvHrmxeay6EQ0x7kHzNcgE1OD5cpAX6IlQIikQYdAVENS0Ccz4WgrfX/NAy756MnD/6cwa MIME-Version: 1.0 X-Received: by 10.221.4.73 with SMTP id ob9mr6485910vcb.13.1417721372219; Thu, 04 Dec 2014 11:29:32 -0800 (PST) Received: by 10.31.10.65 with HTTP; Thu, 4 Dec 2014 11:29:32 -0800 (PST) In-Reply-To: <15C39DE8-9880-42F4-AA97-540B853EBC7B@delong.com> References: <20141122083347.GA1033@Space.Net> <1F14A9C3-E5D0-4F6B-BA70-C342F26E7098@cisco.com> <15C39DE8-9880-42F4-AA97-540B853EBC7B@delong.com> Date: Thu, 4 Dec 2014 11:29:32 -0800 Message-ID: From: James Woodyatt To: IPv6 Operations Content-Type: multipart/alternative; boundary=089e01160524c83439050968faaf Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XNSrgER5xpx4qif4HI389DNwu3M Subject: Re: [v6ops] On IPv6 address part naming 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, 04 Dec 2014 19:29:38 -0000 --089e01160524c83439050968faaf Content-Type: text/plain; charset=UTF-8 On Thu, Dec 4, 2014 at 11:03 AM, Owen DeLong wrote: > > If I may ask a silly question: are we inventing or appropriating a word > for a sixteen bit chunk of an IPv6 address, which might have applicability > in RFC 4291bis if and when it gets written and a couple of other RFCs, or > are we inventing a word that is likely to find its way into 2667 of the > next 7400 RFCs over the next 40 years as a basic unit of measurement? If > we're not doing the latter, how valuable is the definition? > > [...] If you are asking what is our intent, then I would say that at least > in my case, the intent is to have a term which can be viable for 2667 (or > however many it turns out to be) of the next 7400 (or however many it turns > out to be) RFCs over the next however many years. [...] > I don't think that would be in the scope of the V6OPS charter. Maybe IETF would like to attempt coining a good term for data structures comprising precisely two sequential octets, but as the chair notes, V6OPS is absolutely the wrong working group to take up that effort. Maybe we could coin a term for the limited purpose of naming the eight 16-bit fields comprising an IPv6 address, but I'd object to the working group spending any temporal resources attempting to standardize it. Especially if the awful "hextet" is the best we can do. Let's revisit this closer to April 1. -- james woodyatt Nest Labs, Communications Engineering --089e01160524c83439050968faaf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 4, 2014 at 11:03 AM, Owen DeLong <owen@delong.com> wro= te:
> If I may ask a = silly question: are we inventing or appropriating a word for a sixteen bit = chunk of an IPv6 address, which might have applicability in RFC 4291bis if = and when it gets written and a couple of other RFCs, or are we inventing a = word that is likely to find its way into 2667 of the next 7400 RFCs over th= e next 40 years as a basic unit of measurement? If we're not doing the = latter, how valuable is the definition?

[...] If you are aski= ng what is our intent, then I would say that at least in my case, the inten= t is to have a term which can be viable for 2667 (or however many it turns = out to be) of the next 7400 (or however many it turns out to be) RFCs over = the next however many years. [...]

I don't think that would = be in the scope of the V6OPS charter. Maybe IETF would like to attempt coin= ing a good term for data structures comprising precisely two sequential oct= ets, but as the chair notes, V6OPS is absolutely the wrong working group to= take up that effort. Maybe we could coin a term for the limited purpose of= naming the eight 16-bit fields comprising an IPv6 address, but I'd obj= ect to the working group spending any temporal resources attempting to stan= dardize it. Especially if the awful "hextet" is the best we can d= o.

Let= 's revisit this closer to April 1.

--
james woodyatt <jhw@nestlabs.com>
Nest Labs= , Communications Engineering
--089e01160524c83439050968faaf-- From nobody Thu Dec 4 11:32: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 5165D1A0174 for ; Thu, 4 Dec 2014 11:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 mD-e8ZM2HXWC for ; Thu, 4 Dec 2014 11:32:52 -0800 (PST) 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 B323C1A0173 for ; Thu, 4 Dec 2014 11:32:52 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id et14so18630398pad.1 for ; Thu, 04 Dec 2014 11:32:52 -0800 (PST) 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=YwzmlBDVmdBudTn3q6YXuP/oRI99UxnLN2Q5KKtmAus=; b=n2TSeDgMZtdftxSQGxs7V1OKPQhyXnJwN4MO79lLa66nQjtwlj8UNJc7Xsy+Sb5QeU OGODDyWR2aFXLu3GFbfYmVp1RVEeg+gPL2xMovSoZEcP0o2aTRXBjHuKsVRoStgdD4OW M/GvUhXYC0MwdFb+uYeO0tppeQOj6N+3kmfH3jiXBEgOnwTqeSrtQ1Coyhod9nJm9nCJ HmT2L/JkVoA7aKXQ6T9WutkZb7Z3fM3CyYE73CO1YlRl95wG+/e3Uk6WSfEQj0pLWPpZ 4RDxGlVcBsOaltlImgcdsp0nBq6uPsjIgdhEjkUvrOVuGhjmwnT3PgTDu0Xv8O7QhzXL JNpg== X-Received: by 10.70.128.80 with SMTP id nm16mr8404675pdb.1.1417721572033; Thu, 04 Dec 2014 11:32:52 -0800 (PST) Received: from [192.168.178.26] (125.228.69.111.dynamic.snap.net.nz. [111.69.228.125]) by mx.google.com with ESMTPSA id ip2sm26666350pbb.61.2014.12.04.11.32.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 11:32:51 -0800 (PST) Message-ID: <5480B6EA.1060305@gmail.com> Date: Fri, 05 Dec 2014 08:32:58 +1300 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: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> <547F665E.2070804@gmail.com> <5478E4C2-D709-4EFD-BC86-A5068576DAE3@steffann.nl> <547F8D9C.80608@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/uCk4i8Mm2xRv4hHJX9tzNdtgT0A Cc: V6 Ops List Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 04 Dec 2014 19:32:54 -0000 On 04/12/2014 18:10, Randy Bush wrote: >> We are stuck with kludges until the IPv4-only sites go away, but >> IMHO we should be encouraging kludges that bring IPv6 into play. > > you may want to actually read 6346, say 3.1.7, 4.1, ... I apologise, I had indeed forgotten the SMAP stuff. Probably the last time I actually read the whole thing was when draft-ymbk-aplusp was in Last Call. > and, in fact, 6346 was written specifically to offer alternatives to > cgn, e.g. see 1.1. Sure. I understand that. Brian From nobody Thu Dec 4 11:45: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 9E7511A0673 for ; Thu, 4 Dec 2014 11:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 9L0Asz9Sgx3Q for ; Thu, 4 Dec 2014 11:45:43 -0800 (PST) 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 739A41A038F for ; Thu, 4 Dec 2014 11:45:43 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id eu11so18588746pac.11 for ; Thu, 04 Dec 2014 11:45:42 -0800 (PST) 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=qS8OQqrfcFVwlWM9zWZWV781TE26xgqZJKQ9TeUbabU=; b=X3R0DHSaK8NBt8JDI5958HIrLS26/AI53Li6IHEclMzBOa8JVtJjTiQKw5zF6AdCW0 c4oEUyKv9W63lU55eu6xhX5Gx13uexAahaq8ym7Hm3REoC56n/eMHxxRem87SHE3exRa wxv1BCcMbtCAr4XkRJ7ah6ubQYIpWpLc8LRFVI1ES/9I0G+QY7qufYUK6D+czC9anUsM edgK56mvZzG7GYQ7MY/6nlj4MzNYdfgKXCTrnJFhr7QNahGQDf5BcoZb15JLe8qx7w5p U0iaLSGnfy/4By05OR9w5zl6TJOaU8pTJ3y//3oCA+oz008cLyk9LTSAlR0ehm9tldG+ 9VrA== X-Received: by 10.66.235.74 with SMTP id uk10mr22133530pac.16.1417722342661; Thu, 04 Dec 2014 11:45:42 -0800 (PST) Received: from [192.168.178.26] (125.228.69.111.dynamic.snap.net.nz. [111.69.228.125]) by mx.google.com with ESMTPSA id ir2sm26692290pbc.57.2014.12.04.11.45.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 11:45:41 -0800 (PST) Message-ID: <5480B9EC.9010009@gmail.com> Date: Fri, 05 Dec 2014 08:45:48 +1300 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: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> <547F665E.2070804@gmail.com> <5478E4C2-D709-4EFD-BC86-A5068576DAE3@steffann.nl> <547F8D9C.80608@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/eRt_vbn7HQwqeBqztGye2aretmg Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 04 Dec 2014 19:45:47 -0000 On 04/12/2014 22:02, Sander Steffann wrote: > Hi Brian, > >> I personally have been investing effort in this problem since 1992, and >> have co-authored a number of RFCs since then. > > I know. Sorry, didn't mean to imply that you didn't know what you were talking about our something like that. > >> I suppose the recommended >> practice is (a) support customers primarily with IPv6 and (b) use >> the kludge of your choice to provide access to legacy IPv4-only sites. >> RFC 6877 seems to be growing fast, for example. Or you could use the >> approach described in RFC 6264 (and as far as I can see, you could >> embed RFC 6436 in that). >> >> We are stuck with kludges until the IPv4-only sites go away, but >> IMHO we should be encouraging kludges that bring IPv6 into play. > > The RFC recommends that: A+P-in-IPv6. Yes, Randy has set me straight on that. > All the other RFCs you mention require a stateful central device. I think that that's a bad practice, even if widely deployed. We agree on that. > >>>> I also have a technical question. The RFC says, on the subject of >>>> user logging: >>>> >>>> " A+P offers a better set of trade-offs. All that needs to be logged >>>> is the allocation of a range of port numbers to a customer. By >>>> design, this will be done rarely, improving scalability." >>>> >>>> With the growth in legally mandated logging around the world, what is >>>> the practical experience on this? Has A+P logging proved to be scalable >>>> at reasonable cost, or has it become a burden? >>> A+P logging is doable. NAT transaction living is a huge burden. Besides that: it might be legal to log the assigned A+P port range and it might not be legal to log NAT transactions (privacy issues). The Netherlands is a jurisdiction where this is the case. I checked that with the local regulator and law enforcement a few years ago. >> Yes, transaction logging is obviously unreasonable, but I was asking >> for actual experience with A+P logging. > > I don't have any. What exactly do you want to log anyway? There isn't that much to log from a stateless device except how the stateless mapping algorithm is configured... Well, if you are under a legal mandate to log who is using which IP address at any given time, with A+P you also have to log who is using each port range. No choice about that, whether the underlying mechanism is stateful or not. The question is whether that aggravates the scaling problem (compared to CGN or XLAT464 or other approaches). >>>> Which raises a wider question. The writeup simply asserts that "several >>>> mechanisms for deploying A+P have been documented and implemented, and >>>> are now seeing commercial deployment." I think we need a much more >>>> substantive report on the experiment than that. For example, there were >>>> concerns that users who need hundreds of open ports (BitTorrent users, >>>> for example) would be penalised by A+P. Any data on that? >>> Well, connections are 4-tuples so usually this depends on if the client's NAT implementation will reuse a port number our not. Technically it can be solved. >> Actual data were presented showing clients opening hundreds of >> simultaneous ports on their CPE. I'm asking whether that has >> been experimentally proved to work with A+P boxes. >> >>> CGN implementations have the same issue. The number of available address and port combinations is much larger, but so is the number of sessions. If each NAT session requires a unique local 2-tuple instead of a unique full 4-tuple then that will be a limiting factor... >> Yes, but I'm not asking about CGN. > > Sorry, I think you're asking the wrong questions then :) The problem areas you point out are real, but not specific to A+P. Right, but today's question is whether A+P is appropriate for the standards track. (Like there was a question whether RFC 4787/6888 were appropriate for BCP.) We disagree on the answer... Brian > We know we can't find a perfect solution to the IPv4 address shortage problem so of course A+P had its problems. We should compare them to the problems of the alternatives to determine if A+P is the best we can do and deserves to be on the standards track. > > Cheers, > Sander > > From nobody Thu Dec 4 12:15: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 1C2501A1A92 for ; Thu, 4 Dec 2014 12:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-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 LrYRPjNIK3Iz for ; Thu, 4 Dec 2014 12:15:38 -0800 (PST) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (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 3678A1A1ABB for ; Thu, 4 Dec 2014 12:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path: x-originating-ip; bh=hZWxfKmXuTnFZ7XCsj8J0peePs/OXCZAjDyiHH0YOHo=; b=KK3WgqHZNELNV7xg3Lv9HBkfK3TSEeQP9qC2V9Ej30nmkYhYlkTKZThthMozTIDXyYDNa+G+wG/Mz qr3AB7O1bONvQmOTICZKwFwvBMaAMo0iD3mCTw69E15ulZpXXBxfZ0/Jl2qKxRxzb3ueqrpKsEkA7d 8vYs99fCuFhlBJ4w= Received: from NXMDA2.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS; Fri, 5 Dec 2014 06:16:33 +1000 (AEST) Received: from [192.168.1.8] (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.1.218.12; Fri, 5 Dec 2014 06:15:06 +1000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Geoff Huston In-Reply-To: <54802E1D.9070401@massar.ch> Date: Fri, 5 Dec 2014 07:15:00 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> To: Jeroen Massar X-Mailer: Apple Mail (2.1993) X-Originating-IP: [203.119.101.249] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-S6kd5NCSTjODgmpQprcjH0MLEs Cc: v6ops@ietf.org Subject: Re: [v6ops] MTUs on the general Internet (Was: Report: Bar BoF on a 6to4 replacement) 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, 04 Dec 2014 20:15:40 -0000 On 4 Dec 2014, at 8:49 pm, Jeroen Massar wrote: [Geoff, any measurements you know of?] Measurement exercises for Path MTU in IPv6? I'm aware of work by Matthew = Luckie and Ben Stasiewicz some years ago = (http://www.caida.org/~mjl/pubs/measuring-pmtud.pdf). In IPv6 the problem is at its worst in a situation where the large = packet sender is using a 1500 octet MTU and close to the sender is a = packet filter that discards IPv6 packet too big massages. If there is = some form of encapsulating tunnel on the path to the receiver and the = tunnel operates with an effective MTU of less than 1500 then its = possible to encounter a wedged TCP session: the sender sends a 1500 octet packet the tunnel ingress cannot accept the packet and passes back IPv6 ICMP = PTB message toward the sender the packet filter discards the IPv6 ICMP PTB message the sender times out and retransmits the 1500 octet rinse and repeat forever This is not a receiver-side problem but an outcome of path MTU-adjusting = tunnels and aggressive ICMP packet filters As Luckie and Stasiewicz comment "A third strategy, which is arguably = the most challenging, is to educate system administrators about the = necessity of forwarding PTB messages" A simpler approach is for the sender to take the marginal hit of peak = throughput rate and use an initial MTU that is lower that 1500. 1280 is = an obvious choice, and 1400 is probably safe as well. regards, Geoff From nobody Thu Dec 4 12:33: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 936D11A1BB8 for ; Thu, 4 Dec 2014 12:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 tlRwEQ38ppPM for ; Thu, 4 Dec 2014 12:33:29 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF4C1A1B6B for ; Thu, 4 Dec 2014 12:32:56 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id y20so16842845ier.28 for ; Thu, 04 Dec 2014 12:32:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=HBPNzD3f/3/e1OeGm92AiV4ocs2txUhU8BrGGSclPeo=; b=0zhCVVBZ9KCJu37e4TAftYPq8pWrUuPGeYxHwQ7cibQxsTwEU/WZX9MgLfe45oofXF xFMRqS9PauE5RXVZjlP9XEyuvU/oyyTEAfdU5bTErWndgzvLQtBr+d6DVww6T5OIMcKs sE8hMwRKfiVKJWJnaiQHvHKETOGA9IZtyyWxVB5qwGUNTYIowqgZ0NhqZQpVgSjbE/Ls OIwdcLQq/Gk8ej9xSR/vUx23KGfnf5cQ/Z0q4XsmwYfEJsJt8gNcHirQoRrfGo2zeOgv DZyTlDqem2YizRTXhhzgB9gGkxFIL8oSTfV6mYxOiIyrYerxQa2nslyTM7HVsngOhvVO WPgg== X-Received: by 10.107.136.146 with SMTP id s18mr11681050ioi.36.1417725175765; Thu, 04 Dec 2014 12:32:55 -0800 (PST) Received: from [192.168.0.101] ([216.254.164.46]) by mx.google.com with ESMTPSA id o8sm15807226igh.18.2014.12.04.12.32.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 12:32:55 -0800 (PST) Message-ID: <5480C4F1.60402@gmail.com> Date: Thu, 04 Dec 2014 15:32:49 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian E Carpenter , Sander Steffann References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> <547F665E.2070804@gmail.com> <5478E4C2-D709-4EFD-BC86-A5068576DAE3@steffann.nl> <547F8D9C.80608@gmail.com> <5480B9EC.9010009@gmail.com> In-Reply-To: <5480B9EC.9010009@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/C0gKYSCIwfYFxy4awnciSKyouHs Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 04 Dec 2014 20:33:32 -0000 On 04/12/2014 2:45 PM, Brian E Carpenter wrote: > On 04/12/2014 22:02, Sander Steffann wrote: >> Hi Brian, >> ... >> >>>>> I also have a technical question. The RFC says, on the subject of >>>>> user logging: >>>>> >>>>> " A+P offers a better set of trade-offs. All that needs to be logged >>>>> is the allocation of a range of port numbers to a customer. By >>>>> design, this will be done rarely, improving scalability." >>>>> >>>>> With the growth in legally mandated logging around the world, what is >>>>> the practical experience on this? Has A+P logging proved to be scalable >>>>> at reasonable cost, or has it become a burden? >>>> A+P logging is doable. NAT transaction living is a huge burden. Besides that: it might be legal to log the assigned A+P port range and it might not be legal to log NAT transactions (privacy issues). The Netherlands is a jurisdiction where this is the case. I checked that with the local regulator and law enforcement a few years ago. >>> Yes, transaction logging is obviously unreasonable, but I was asking >>> for actual experience with A+P logging. >> >> I don't have any. What exactly do you want to log anyway? There isn't that much to log from a stateless device except how the stateless mapping algorithm is configured... > > Well, if you are under a legal mandate to log who is using which IP > address at any given time, with A+P you also have to log who is using > each port range. No choice about that, whether the underlying mechanism > is stateful or not. The question is whether that aggravates the scaling > problem (compared to CGN or XLAT464 or other approaches). > ... draft-ietf-behave-syslog-nat-logging is basically theoretical, but it does give information on logging volumes. Look particularly at the Applicability section. There is also information in draft-chen-sunset4-cgn-port-allocation and draft-donley-behave-deterministic-cgn. Tom Taylor From nobody Thu Dec 4 12:34: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 74D8F1A1C00 for ; Thu, 4 Dec 2014 12:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 u96aIYBzv1Lf for ; Thu, 4 Dec 2014 12:34:45 -0800 (PST) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B9771A1BBC for ; Thu, 4 Dec 2014 12:34:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sB4KOwH6001975; Thu, 4 Dec 2014 14:24:58 -0600 Received: from XCH-BLV-501.nw.nos.boeing.com (xch-blv-501.nw.nos.boeing.com [130.247.25.190]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sB4KOlAp001586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 4 Dec 2014 14:24:48 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-BLV-501.nw.nos.boeing.com ([169.254.1.28]) with mapi id 14.03.0210.002; Thu, 4 Dec 2014 12:24:46 -0800 From: "Templin, Fred L" To: Geoff Huston , Jeroen Massar Thread-Topic: [v6ops] MTUs on the general Internet (Was: Report: Bar BoF on a 6to4 replacement) Thread-Index: AQHQEABYxRLp0ZvfbE+loOoAGQtq9w== Date: Thu, 4 Dec 2014 20:24:46 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DAB4D0@XCH-BLV-504.nw.nos.boeing.com> References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> 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/fQD66r7Rb1pjNcP-x7kVLVI4oWM Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MTUs on the general Internet (Was: Report: Bar BoF on a 6to4 replacement) 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, 04 Dec 2014 20:34:50 -0000 Hi Geoff, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Geoff Huston > Sent: Thursday, December 04, 2014 12:15 PM > To: Jeroen Massar > Cc: v6ops@ietf.org > Subject: Re: [v6ops] MTUs on the general Internet (Was: Report: Bar BoF o= n a 6to4 replacement) >=20 > On 4 Dec 2014, at 8:49 pm, Jeroen Massar wrote: >=20 > [Geoff, any measurements you know of?] >=20 >=20 > Measurement exercises for Path MTU in IPv6? I'm aware of work by Matthew = Luckie and Ben Stasiewicz some years ago > (http://www.caida.org/~mjl/pubs/measuring-pmtud.pdf). >=20 > In IPv6 the problem is at its worst in a situation where the large packet= sender is using a 1500 octet MTU and close to the sender is a > packet filter that discards IPv6 packet too big massages. If there is som= e form of encapsulating tunnel on the path to the receiver and > the tunnel operates with an effective MTU of less than 1500 then its poss= ible to encounter a wedged TCP session: >=20 > the sender sends a 1500 octet packet > the tunnel ingress cannot accept the packet and passes back IPv6 ICMP = PTB message toward the sender > the packet filter discards the IPv6 ICMP PTB message > the sender times out and retransmits the 1500 octet >=20 > rinse and repeat forever >=20 >=20 > This is not a receiver-side problem but an outcome of path MTU-adjusting = tunnels and aggressive ICMP packet filters >=20 > As Luckie and Stasiewicz comment "A third strategy, which is arguably the= most challenging, is to educate system administrators about > the necessity of forwarding PTB messages" >=20 > A simpler approach is for the sender to take the marginal hit of peak thr= oughput rate and use an initial MTU that is lower that 1500. > 1280 is an obvious choice, and 1400 is probably safe as well. Or (since tunnels seem to be the culprit) make tunnels pass packets of at l= east 1500 bytes. That can be done independently of getting hosts to do something= . Thanks - Fred fred.l.templin@boeing.com =20 > regards, >=20 > Geoff >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Dec 4 12: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 F3C731A1A55 for ; Thu, 4 Dec 2014 12:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 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_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 uT6nHwIAe8qx for ; Thu, 4 Dec 2014 12:52:05 -0800 (PST) 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 2B4C01A1A7E for ; Thu, 4 Dec 2014 12:52:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 3725E68; Thu, 4 Dec 2014 21:52:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1417726313; bh=CQ6+tue8T0WbjcNrlRxTJCgaByzlS2FQ15LC2kdzGU4=; b=f ja1KXMqhlVGyUEKxUMUGZzKYGpuRAesrucMhftCxQMk2XKOw7uXQLjTsrnIxRP6k v8N8OK1gR6YrZENASCW3AXr0sw9T0z9KlxzZEFTHMSdvnTLCUfoqFWL1Shpl8Uaz 3gq/qbAaTzKcDiHz7wFexNNssViyZ+PIayZ3PTKG7U= 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 10026) with ESMTP id rB8SZeWZr08Y; Thu, 4 Dec 2014 21:51:53 +0100 (CET) Received: from [IPv6:2a00:8640:1::1de0:dbe2:7538:c415] (unknown [IPv6:2a00:8640:1:0:1de0:dbe2:7538:c415]) by mail.sintact.nl (Postfix) with ESMTPSA id 6043736; Thu, 4 Dec 2014 21:51:53 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2058.2\)) From: Sander Steffann In-Reply-To: <5480B9EC.9010009@gmail.com> Date: Thu, 4 Dec 2014 21:51:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> <547F665E.2070804@gmail.com> <5478E4C2-D709-4EFD-BC86-A5068576DAE3@steffann.nl> <547F8D9C.80608@gmail.com> <5480B9EC.9010009@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.2058.2) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/cSKgBXIZEpYamS_2rgwsya2Feag Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 04 Dec 2014 20:52:07 -0000 Hi Brian, > Well, if you are under a legal mandate to log who is using which IP > address at any given time, with A+P you also have to log who is using > each port range. No choice about that, whether the underlying = mechanism > is stateful or not. The question is whether that aggravates the = scaling > problem (compared to CGN or XLAT464 or other approaches). I don't think I understand your question. Best-case re logging the CGN (thinking of NAT444/NAT64/DS-Lite based. = 464XLAT is built on top of NAT64) is when the CGN implements per-client = port ranges so that only the assignment of ports to users needs to be = logged. Worst case for logging is full dynamic NAT where every = transaction needs to be logged. How could logging A+P port ranges be = worse than any of that? Cheers, Sander From nobody Thu Dec 4 13:01: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 3D0FB1A1BDA for ; Thu, 4 Dec 2014 13:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 AYQaHuOkF11a for ; Thu, 4 Dec 2014 13:00:56 -0800 (PST) Received: from itsnt427.iowa.uiowa.edu (itsnt427.iowa.uiowa.edu [128.255.6.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140201A0385 for ; Thu, 4 Dec 2014 13:00:56 -0800 (PST) Received: from ITSNT440.iowa.uiowa.edu ([169.254.2.131]) by itsnt427.iowa.uiowa.edu ([128.255.6.109]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 15:00:54 -0600 From: "Metzler, Dan J" To: Geoff Huston , Jeroen Massar Thread-Topic: [v6ops] MTUs on the general Internet (Was: Report: Bar BoF on a 6to4 replacement) Thread-Index: AQHQD/8Y79eJsGuBsEm2+o2f2C1chZx/6JKg Date: Thu, 4 Dec 2014 21:00:53 +0000 Message-ID: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DF401A2@ITSNT440.iowa.uiowa.edu> References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.255.6.15] 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/a55AN2FKytz2_JRJMRzIf23osGY Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MTUs on the general Internet (Was: Report: Bar BoF on a 6to4 replacement) 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, 04 Dec 2014 21:00:58 -0000 Hi, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Geoff Huston > Sent: Thursday, December 4, 2014 2:15 PM > To: Jeroen Massar > Cc: v6ops@ietf.org > Subject: Re: [v6ops] MTUs on the general Internet (Was: Report: Bar BoF o= n a > 6to4 replacement) >=20 > On 4 Dec 2014, at 8:49 pm, Jeroen Massar wrote: >=20 > [Geoff, any measurements you know of?] >=20 >=20 > Measurement exercises for Path MTU in IPv6? I'm aware of work by Matthew > Luckie and Ben Stasiewicz some years ago > (http://www.caida.org/~mjl/pubs/measuring-pmtud.pdf). >=20 > In IPv6 the problem is at its worst in a situation where the large packet= sender > is using a 1500 octet MTU and close to the sender is a packet filter that > discards IPv6 packet too big massages. If there is some form of encapsula= ting > tunnel on the path to the receiver and the tunnel operates with an effect= ive > MTU of less than 1500 then its possible to encounter a wedged TCP session= : >=20 > the sender sends a 1500 octet packet > the tunnel ingress cannot accept the packet and passes back IPv6 ICMP = PTB > message toward the sender > the packet filter discards the IPv6 ICMP PTB message > the sender times out and retransmits the 1500 octet >=20 > rinse and repeat forever Wouldn't this be working as designed? As it stands now we can even probe for this by sending a purposely large pa= cket, and monitor for the response or PTB reply. If it doesn't come back, = that network is broken. Is it really worth masking the problem? >=20 >=20 > This is not a receiver-side problem but an outcome of path MTU-adjusting > tunnels and aggressive ICMP packet filters >=20 > As Luckie and Stasiewicz comment "A third strategy, which is arguably the > most challenging, is to educate system administrators about the necessity= of > forwarding PTB messages" >=20 > A simpler approach is for the sender to take the marginal hit of peak > throughput rate and use an initial MTU that is lower that 1500. 1280 is a= n > obvious choice, and 1400 is probably safe as well. >=20 > regards, >=20 > Geoff >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Dec 4 13:18: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 6128C1A1BFE for ; Thu, 4 Dec 2014 13:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 uRseWT9xmFTn for ; Thu, 4 Dec 2014 13:18:08 -0800 (PST) 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 BEBEE1A1A55 for ; Thu, 4 Dec 2014 13:17:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2316; q=dns/txt; s=iport; t=1417727872; x=1418937472; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tP90qVZAuW4STCUcm/4TESw5weZDRleukR79O+xjoOU=; b=Q0dsR6rbi4nF4DNvx5df0+cttlaHpCM07NhISpnKqzYCaHnTI5FezHNb vSgmNMVKVqxDNOkgeC/W9POqAc0Qw7dCdkrrjzqNEPA1kBj981JbYXEwK Op92Fidxa5etcnPyhThuQ4MGyC50VPvF2R13EL5GMYgPXc9qdtOirnrVZ s=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkFAGXOgFStJV2Q/2dsb2JhbABZgwaBKgS4eZNtAoEiFgEBAQEBfYQDAQEEeRACAQhGMiUCBAoEBQ6IMNciAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5BmB4MkgR4FhGGLL4F2gUAEhxCUGIIAIIFZb4FFgQABAQE X-IronPort-AV: E=Sophos;i="5.07,518,1413244800"; d="asc'?scan'208";a="374553627" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP; 04 Dec 2014 21:17:52 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id sB4LHqUX006297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Dec 2014 21:17:52 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 15:17:51 -0600 From: "Fred Baker (fred)" To: "sthaug@nethelp.no" Thread-Topic: [v6ops] MTUs on the general Internet Thread-Index: AQHQEAfC79UzGOVOck6tS4a8Ul5d2g== Date: Thu, 4 Dec 2014 21:17:50 +0000 Message-ID: <1DB77209-5AF8-4876-894E-63F5EF2B3C75@cisco.com> References: <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141204.111820.41660320.sthaug@nethelp.no> In-Reply-To: <20141204.111820.41660320.sthaug@nethelp.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_59B39BA7-B768-4586-851F-B17107D699E6"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UEm3h5-NfMi6p9mduDuHrU-gYyI Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MTUs on the general Internet 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, 04 Dec 2014 21:18:11 -0000 --Apple-Mail=_59B39BA7-B768-4586-851F-B17107D699E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 4, 2014, at 2:18 AM, sthaug@nethelp.no wrote: > "People" as in residential users may not really care about MTU as long = as their Facebook and Youtube works. More to the point, it=92s going to be about delivery rate using a = protocol such as TCP, and the total time to deliver a quantum of = information like a page or the initial load of a video file. The = difference between a TCP transfer of a median-sized file (about 20 data = packets) using IPv4 and IPv6 is 20 bytes per packet, which means that = the last segment might be 19*20=3D380 bytes longer, or there might be = one additional segment. If RFC 6928 (initial window =3D 10 segments) is = in force, that=92s not even an additional RTT. The difference for a long = file is an additional segment every 76 segments. I should think a change in MTU has a similar effect. We send a few more = segments. The question is not about the size of a segment, its the rate = of segment flow in a protocol that keeps a number of segments = simultaneously in flight. There is a hill of beans; it=92s not very = tall. The way you say that implies =93for people that aren=92t very = knowledgeable=94. Honestly, the places that PMTU materially affects have = to do with the interrupt rate to computers moving large files across = direct multi-gigabit interconnects. Using RFC 5690 to reduce the = interrupts from every-other-segment to every-twelfth-segment, or = equivalently using 9K MTUs, reportedly materially changes the behavior = of such a file transfer, or so the researchers tell me. At 1G or below, = it makes a lot less of a difference. --Apple-Mail=_59B39BA7-B768-4586-851F-B17107D699E6 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 iD8DBQFUgM9qbjEdbHIsm0MRApleAKCCeFLwru7oZDgh0dT79wtYlVHCtgCfa+bx Ttdq2ZZzBodTWQ7s8kZeuKY= =+T+A -----END PGP SIGNATURE----- --Apple-Mail=_59B39BA7-B768-4586-851F-B17107D699E6-- From nobody Thu Dec 4 13:23: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 C6C281A1EED for ; Thu, 4 Dec 2014 13:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 djwYJ-un3r47 for ; Thu, 4 Dec 2014 13:22:48 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D54011A1AA7 for ; Thu, 4 Dec 2014 13:22:47 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 9DEEB1FCB11; Thu, 4 Dec 2014 21:22:41 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9F8F9160067; Thu, 4 Dec 2014 21:26:43 +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 69F9216004A; Thu, 4 Dec 2014 21:26:43 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 8FCA024E090A; Fri, 5 Dec 2014 08:22:38 +1100 (EST) To: Geoff Huston From: Mark Andrews References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> In-reply-to: Your message of "Fri, 05 Dec 2014 07:15:00 +1100." Date: Fri, 05 Dec 2014 08:22:38 +1100 Message-Id: <20141204212238.8FCA024E090A@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/PLxHPNnp4uYvOqwVDYm8UCo_HGQ Cc: v6ops@ietf.org Subject: Re: [v6ops] MTUs on the general Internet (Was: Report: Bar BoF on a 6to4 replacement) 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, 04 Dec 2014 21:22:54 -0000 In message , Geoff Huston write s: > On 4 Dec 2014, at 8:49 pm, Jeroen Massar wrote: > > [Geoff, any measurements you know of?] > > > Measurement exercises for Path MTU in IPv6? I'm aware of work by Matthew Luck > ie and Ben Stasiewicz some years ago (http://www.caida.org/~mjl/pubs/measurin > g-pmtud.pdf). > > In IPv6 the problem is at its worst in a situation where the large packet sen > der is using a 1500 octet MTU and close to the sender is a packet filter that > discards IPv6 packet too big massages. If there is some form of encapsulatin > g tunnel on the path to the receiver and the tunnel operates with an effectiv > e MTU of less than 1500 then its possible to encounter a wedged TCP session: > > the sender sends a 1500 octet packet > the tunnel ingress cannot accept the packet and passes back IPv6 ICMP PTB > message toward the sender > the packet filter discards the IPv6 ICMP PTB message > the sender times out and retransmits the 1500 octet > > rinse and repeat forever > > > This is not a receiver-side problem but an outcome of path MTU-adjusting tunn > els and aggressive ICMP packet filters > > As Luckie and Stasiewicz comment "A third strategy, which is arguably the mos > t challenging, is to educate system administrators about the necessity of for > warding PTB messages" > > A simpler approach is for the sender to take the marginal hit of peak through > put rate and use an initial MTU that is lower that 1500. 1280 is an obvious c > hoice, and 1400 is probably safe as well. > > regards, > > Geoff Which is why named sets IPV6_USE_MIN_MTU to 1 on all IPv6 sockets. Yes, this results in fragmented TCP packets on some platforms despite it being set before connect/accept due to the TCP layer not paying attention to it. It should cause the MSS negotiation to be adjusted down (yes the MTU for the socket is 1280 not 1500 so do the MSS calculation based on 1280). > _______________________________________________ > 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 Thu Dec 4 13:52: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 B87541A1F02 for ; Thu, 4 Dec 2014 13:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 PRzBslq2CDkl for ; Thu, 4 Dec 2014 13:52:18 -0800 (PST) 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 748E71A1AA0 for ; Thu, 4 Dec 2014 13:52:18 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id ey11so18928427pad.10 for ; Thu, 04 Dec 2014 13:52:17 -0800 (PST) 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=VrJuKtp6mVY7bC1gPB7+QLYzkC35J0TEeHREcMcSK4E=; b=hF2U1xoylyWnrgdwYbWXol6daa/m2E+j6J37TDgevTN44pSSfa3My8VGxjTAd+9OcU sfQOqCmqTvW77uEjQXB2MPjK6S2BL29lW4UZl/wgOEBkDWMtJtvY4gGoD3JbudC2GqUC TyCFnta008nBAbh45RZVGY+5aM53Ei/82hJ6WUbu2Azgkk7JREZMXipa+2Pf6f/r1V5U ru1ee/dgLUtP/FbSHlH1KcH9rdsdXfUtdxFhdqbtAbom/Frr2DMWxvwOpbwEFRc7bMr/ cKFqg4Tfu4k5y7fU4BaLnxTS718DCJ5jn2BUgNKGT/Y7EXMnE92aQmsnLJsJKh9L1Lgi bUqg== X-Received: by 10.68.238.6 with SMTP id vg6mr17758054pbc.109.1417729937727; Thu, 04 Dec 2014 13:52:17 -0800 (PST) Received: from [192.168.178.26] (125.228.69.111.dynamic.snap.net.nz. [111.69.228.125]) by mx.google.com with ESMTPSA id m3sm26393675pda.75.2014.12.04.13.52.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 13:52:16 -0800 (PST) Message-ID: <5480D797.70501@gmail.com> Date: Fri, 05 Dec 2014 10:52:23 +1300 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: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> <547F665E.2070804@gmail.com> <5478E4C2-D709-4EFD-BC86-A5068576DAE3@steffann.nl> <547F8D9C.80608@gmail.com> <5480B9EC.9010009@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/3BBe0YdxVsSTjrrR7ZMsQI6npzk Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 04 Dec 2014 21:52:20 -0000 On 05/12/2014 09:51, Sander Steffann wrote: > Hi Brian, > >> Well, if you are under a legal mandate to log who is using which IP >> address at any given time, with A+P you also have to log who is using >> each port range. No choice about that, whether the underlying mechanism >> is stateful or not. The question is whether that aggravates the scaling >> problem (compared to CGN or XLAT464 or other approaches). > > I don't think I understand your question. > > Best-case re logging the CGN (thinking of NAT444/NAT64/DS-Lite based. 464XLAT is built on top of NAT64) is when the CGN implements per-client port ranges so that only the assignment of ports to users needs to be logged. Worst case for logging is full dynamic NAT where every transaction needs to be logged. How could logging A+P port ranges be worse than any of that? That makes sense and is consistent with the discussion in http://tools.ietf.org/html/rfc6346#section-6. But I think you're missing my question, which is about *practical experience*. Moving a document from Experimental to the standards track is a moment when we can legitimately ask what the practical results of the experiment were. http://tools.ietf.org/html/rfc7127#section-3.1 certainly allows the IESG to consider this aspect. Brian From nobody Thu Dec 4 13:56: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 6C7DA1A6F0A for ; Thu, 4 Dec 2014 13:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 Td177lpO_yWd for ; Thu, 4 Dec 2014 13:56:06 -0800 (PST) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1D4B1A6FA3 for ; Thu, 4 Dec 2014 13:56:04 -0800 (PST) Received: by mail-pd0-f178.google.com with SMTP id g10so18634827pdj.9 for ; Thu, 04 Dec 2014 13:56:04 -0800 (PST) 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=9kgqW1DGIoAfOqGZlVlZFLlpi6wOhoLD/TIbVXb8L9I=; b=TA4dh5EJpWyUOp7PRmhAZsiB/GApBEYqcLAR1tLJBahNzWL9E6rhAk0UyCTxqfthhs F2YkMXWzbpTsXh4BoZBqe54vOw9c1YTEOyzwWgrnWS1AQ0TntyTqT8Qw3/zf0Dq//ngg BUVuyA6xSyIQO2e6/2910WvyKlBXhixJPx3ATQnzKYIGlyEwgpnPEQ/krpiqUhAp5cyo 2EL7VEnumAWf8kiOt9xtvC6OROmnd2/wNnkRGdwn1OthpjkG1AzzOyzrRmY2JGNBPLY6 BtHEFwKG3gPMX7lOESCtwoIkRHv3PshfGBiL+acfoUtYO9umO6NHC1XjdmRkblccGdZ4 R9bg== X-Received: by 10.70.20.129 with SMTP id n1mr22385084pde.135.1417730164102; Thu, 04 Dec 2014 13:56:04 -0800 (PST) Received: from [192.168.178.26] (125.228.69.111.dynamic.snap.net.nz. [111.69.228.125]) by mx.google.com with ESMTPSA id z15sm27063452pdi.6.2014.12.04.13.56.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 13:56:03 -0800 (PST) Message-ID: <5480D879.5090207@gmail.com> Date: Fri, 05 Dec 2014 10:56:09 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tom Taylor References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> <547F665E.2070804@gmail.com> <5478E4C2-D709-4EFD-BC86-A5068576DAE3@steffann.nl> <547F8D9C.80608@gmail.com> <5480B9EC.9010009@gmail.com> <5480C4F1.60402@gmail.com> In-Reply-To: <5480C4F1.60402@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/y6Ssrtyg843BfWZr6DqioKdrtDw Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 04 Dec 2014 21:56:08 -0000 On 05/12/2014 09:32, Tom Taylor wrote: > On 04/12/2014 2:45 PM, Brian E Carpenter wrote: >> On 04/12/2014 22:02, Sander Steffann wrote: >>> Hi Brian, >>> > ... > >>> >>>>>> I also have a technical question. The RFC says, on the subject of >>>>>> user logging: >>>>>> >>>>>> " A+P offers a better set of trade-offs. All that needs to be >>>>>> logged >>>>>> is the allocation of a range of port numbers to a customer. By >>>>>> design, this will be done rarely, improving scalability." >>>>>> >>>>>> With the growth in legally mandated logging around the world, what is >>>>>> the practical experience on this? Has A+P logging proved to be >>>>>> scalable >>>>>> at reasonable cost, or has it become a burden? >>>>> A+P logging is doable. NAT transaction living is a huge burden. >>>>> Besides that: it might be legal to log the assigned A+P port range >>>>> and it might not be legal to log NAT transactions (privacy issues). >>>>> The Netherlands is a jurisdiction where this is the case. I checked >>>>> that with the local regulator and law enforcement a few years ago. >>>> Yes, transaction logging is obviously unreasonable, but I was asking >>>> for actual experience with A+P logging. >>> >>> I don't have any. What exactly do you want to log anyway? There isn't >>> that much to log from a stateless device except how the stateless >>> mapping algorithm is configured... >> >> Well, if you are under a legal mandate to log who is using which IP >> address at any given time, with A+P you also have to log who is using >> each port range. No choice about that, whether the underlying mechanism >> is stateful or not. The question is whether that aggravates the scaling >> problem (compared to CGN or XLAT464 or other approaches). >> > ... > draft-ietf-behave-syslog-nat-logging is basically theoretical, but it > does give information on logging volumes. Look particularly at the > Applicability section. Thanks Tom. So for a CGN, the order of magnitude is "150,000 call detail records per second, varying in length from 500 to 1500 bytes." Equivalent data for A+P would be very informative. Brian > > There is also information in draft-chen-sunset4-cgn-port-allocation and > draft-donley-behave-deterministic-cgn. > > Tom Taylor > From nobody Thu Dec 4 14:07: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 B59741A1BAA for ; Thu, 4 Dec 2014 14:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 Nx1nDyuYBQuw for ; Thu, 4 Dec 2014 14:07:33 -0800 (PST) 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 7E0F21A1EEA for ; Thu, 4 Dec 2014 14:07:30 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id ft15so18505475pdb.4 for ; Thu, 04 Dec 2014 14:07:29 -0800 (PST) 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=NOHzdlovdZrjqI+xN1H/VSaFhydsW8I3GpMqJhz8sj0=; b=IHcY41ZqBeK0U1rRffH6YWeYNG7DWpoC3Ve2qrhV4trh13ZwT5/YNmN4O6u0VO4EzD VZYaNnPgNJUUzj0zEincJqTNw9p2K+ETThA9+1wMDWdBRfGoke9aTzd7nSn9n2BsVtG8 Wex1nKcZ4M6dUUblr5q2esKFciA+Ldk2rkuyqThNlJvs+Oz/vUdiu3GN+VKbiOrufvJU 28idXAAMi07Nq0g30pWRbcRG+LoueChyzuN4Rj5xJrdRk7qbdNtrgQ6RRAg/FDOYkqt6 XKMTlkNsWVVqavuuc2W1dLexQKf+JqsZCLoj+bCifrMy0SQtK9W3U9Sdyl3H1FlrFpiZ 8/6Q== X-Received: by 10.70.89.129 with SMTP id bo1mr22926883pdb.23.1417730849762; Thu, 04 Dec 2014 14:07:29 -0800 (PST) Received: from [192.168.178.26] (125.228.69.111.dynamic.snap.net.nz. [111.69.228.125]) by mx.google.com with ESMTPSA id pg9sm27021474pdb.71.2014.12.04.14.07.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 14:07:28 -0800 (PST) Message-ID: <5480DB27.3000507@gmail.com> Date: Fri, 05 Dec 2014 11:07:35 +1300 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: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> <547F665E.2070804@gmail.com> <5478E4C2-D709-4EFD-BC86-A5068576DAE3@steffann.nl> <547F8D9C.80608@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/6yo4i5w2HnNbUB928ZZ65HXJGAs Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 04 Dec 2014 22:07:34 -0000 On 05/12/2014 02:03, Sander Steffann wrote: > Hi Lorenzo, > >> I thought A+P basically ended up becoming MAP. Do I misunderstand? > > MAP is indeed the most common implementation of the A+P architecture. For many practical purposes they are kind of equivalent these days. One more thought. I don't see RFC 6346 in the downref registry, which presumably means than none of the subsequent standards track documents have needed it as a normative reference. So I wonder if it actually needs to be on the standards track at all. If it was moved to Informational, with very light editing, that would remove the Experimental tag that Randy objects to. We have a long tradition of Informational documents that record known practice or serve as background for standards. Brian From nobody Thu Dec 4 14:33: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 A87471A6FEA for ; Thu, 4 Dec 2014 14:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 Iz88gIK64c6G for ; Thu, 4 Dec 2014 14:33:34 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6F5B1A7010 for ; Thu, 4 Dec 2014 14:33:34 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 23A40206C0 for ; Thu, 4 Dec 2014 17:33:34 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 04 Dec 2014 17:33:34 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=jaIdBzX7c8RQ082x0OPgKu wcV4U=; b=Q1ZDTQd2BhAlBqdwEiE5BJVOTjS/3A+pjbP5rzErEXKd5cC9x2LpOI Q9nELPn+Yx7Z9tulzSX7VhHUVYyVcmftREQh69YVllDKBd2KAFXWmfri7lUcfbUp yGw9kRd0rfKDvUcyMgfIHJvm1iVJnWtpEssbNFp60FSZQdssV7ORs= X-Sasl-enc: WkLpEj3xLWYr6dKjGbX9ciGf2JnSIPFJdlcv3Xwbb1dW 1417732413 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id BF2BA6801E0; Thu, 4 Dec 2014 17:33:33 -0500 (EST) Message-ID: <5480E12D.7050002@network-heretics.com> Date: Thu, 04 Dec 2014 17:33:17 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> <547F665E.2070804@gmail.com> <5478E4C2-D709-4EFD-BC86-A5068576DAE3@steffann.nl> <547F8D9C.80608@gmail.com> <5480DB27.3000507@gmail.com> In-Reply-To: <5480DB27.3000507@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4xjnv5Ni5uS5Ar9XHegDJSdWJLw Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 04 Dec 2014 22:33:36 -0000 On 12/04/2014 05:07 PM, Brian E Carpenter wrote: > One more thought. I don't see RFC 6346 in the downref registry, which > presumably means than none of the subsequent standards track documents > have needed it as a normative reference. So I wonder if it actually > needs to be on the standards track at all. If it was moved to > Informational, with very light editing, that would remove the > Experimental tag that Randy objects to. We have a long tradition of > Informational documents that record known practice or serve as > background for standards. I would be a lot more comfortable with that. Keith From nobody Thu Dec 4 14:54: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 CA3EC1A8710 for ; Thu, 4 Dec 2014 14:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 FKCpB03ncome for ; Thu, 4 Dec 2014 14:54:48 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20921A86F9 for ; Thu, 4 Dec 2014 14:54:48 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 08AF120BD1 for ; Thu, 4 Dec 2014 17:54:48 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Thu, 04 Dec 2014 17:54:48 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=Cr3R7zns8THEQjO4QendtD Ux1u4=; b=qcaO7jtRBawOtQl1gSMjVDfWUeFT5BSfgZwPTUuWa+bffnTgIofuZb oFFA6phZLudsizXHzmtWYO0JH9ZEUm0R4DRNaOqtuzVMdpEC1JdIPd9422DR8+zs MQw1XKvEz1aoEEmpJHn15YVW4oWN8aQWPvGjdezAE2yD0P6Yqz0zY= X-Sasl-enc: BQ90r9dQoFkPFiHuZBWiJe1FVE5nf2aElyhUYah0mYZX 1417733687 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id A0115C0027E; Thu, 4 Dec 2014 17:54:47 -0500 (EST) Message-ID: <5480E627.8060108@network-heretics.com> Date: Thu, 04 Dec 2014 17:54:31 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <2134F8430051B64F815C691A62D9831832D76378@XCH-BLV-504.nw.nos.boeing.com> <4C77BAB8-38FD-4830-B779-E24586EB9275@delong.com> <5458294D.9000502@massar.ch> <64F92F49-4A31-4268-99D3-8A482E95735F@delong.com> <54643D0B.4070208@gmail.com> <88329C76-8C09-42D1-A0F7-9A65B98E1D44@muada.com> <20141113195636.GY31092@Space.Net> <93034721-BA1A-45C5-A3F5-0838DE3DB3FE@delong.com> <547EC5A9.8010603@massar.ch> <547F7076.2080907@umn.edu> <20DDFCD1-0CD6-4820-A358-CC4419B8B53C@muada.com> In-Reply-To: <20DDFCD1-0CD6-4820-A358-CC4419B8B53C@muada.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kA7KubU1xw6Mf4yvVGtuYy9GP9c Subject: Re: [v6ops] Filtering 6to4 (Was: Bar BoF on a 6to4 replacement?) 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, 04 Dec 2014 22:54:49 -0000 On 12/03/2014 04:51 PM, Iljitsch van Beijnum wrote: >> is it BCP, or at least acceptable, to block 6to4 once dual stack is deployed to end user? > I find it completely unacceptable. ISPs have no business filtering legitimate packets. > +1. Keith From nobody Thu Dec 4 17:51: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 106A41A8ACE for ; Thu, 4 Dec 2014 17:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-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 KOz8sDWTzNnJ for ; Thu, 4 Dec 2014 17:51:28 -0800 (PST) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (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 0EE181A8ACC for ; Thu, 4 Dec 2014 17:51:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path: x-originating-ip; bh=XEVZmouZo9oN6xujP6GeZLiF7Cy9IKxDZbLHid9URnA=; b=YQ98zvPxEZcZaUcey8i3His6AN2DuadSYlD1lopJE663FwdsjAvWlnRIlC0ZyddDc6K9MoPYRYHg9 JhLnKVOwDaxLokp/C0cg8G2vVMwmfPrIY0JK9QlY3dWPsZEWgvEEvdKPgj4IzyGh/yDfYTpomHDI1t 5yFQrxC3R7zZJVyo= Received: from NXMDA2.org.apnic.net (unknown [IPv6:2001:dd8:9:2::101:249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS; Fri, 5 Dec 2014 11:52:55 +1000 (AEST) Received: from [192.168.1.8] (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.1.218.12; Fri, 5 Dec 2014 11:51:29 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Geoff Huston In-Reply-To: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DF401A2@ITSNT440.iowa.uiowa.edu> Date: Fri, 5 Dec 2014 12:51:22 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DF401A2@ITSNT440.iowa.uiowa.edu> To: "Metzler, Dan J" X-Mailer: Apple Mail (2.1993) X-Originating-IP: [203.119.101.249] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/I7U-dTZtdoJsAvAnDHWxi_BZsHI Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MTUs on the general Internet (Was: Report: Bar BoF on a 6to4 replacement) 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, 05 Dec 2014 01:51:30 -0000 > On 5 Dec 2014, at 8:00 am, Metzler, Dan J = wrote: >=20 >>=20 >> In IPv6 the problem is at its worst in a situation where the large = packet sender >> is using a 1500 octet MTU and close to the sender is a packet filter = that >> discards IPv6 packet too big massages. If there is some form of = encapsulating >> tunnel on the path to the receiver and the tunnel operates with an = effective >> MTU of less than 1500 then its possible to encounter a wedged TCP = session: >>=20 >> the sender sends a 1500 octet packet >> the tunnel ingress cannot accept the packet and passes back IPv6 = ICMP PTB >> message toward the sender >> the packet filter discards the IPv6 ICMP PTB message >> the sender times out and retransmits the 1500 octet >>=20 >> rinse and repeat forever >=20 > Wouldn't this be working as designed? > As it stands now we can even probe for this by sending a purposely = large packet, and monitor for the response or PTB reply. If it doesn't = come back, that network is broken. >=20 > Is it really worth masking the problem? The problem is here that there is potentially no single "network" that = is broken. At one point on the path from the sender to the receiver = there is a constrained MTU. At one point on the path from the = constrained MTU to the sender (which is not necessarily the same path as = the forward path) there is an ICMP filter. So who is "broken"? The tunnel ingress that is performing IP-over-IP and = needs to down-adjust the MTU to factor in the additional header? Or the = filter rule set that is saying that it is unprepared to admit ICMP = packets from arbitrary sources? Its not necessarily a single point of = "failure" here, but the interaction of two different items of = middleware, and they may not be located within a single locus of = admin/operational control. Geoff From nobody Thu Dec 4 18: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 219221A87E1 for ; Thu, 4 Dec 2014 18:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 1HYZp1LIWsxH for ; Thu, 4 Dec 2014 18:19:47 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B711A6EE5 for ; Thu, 4 Dec 2014 18:19:46 -0800 (PST) Received: by mail-ig0-f170.google.com with SMTP id r2so104984igi.3 for ; Thu, 04 Dec 2014 18:19:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fbMFxpMUQKRtUyhuoyv2j0bH/nGfyu6XoGFED9bs4e0=; b=JiMBJKIpz1hYuUooV73+h+RqRWeZ4WHsAABC7TjgFdH4IaXCKxb42OoBCdkR6tesLd gx6QYvDvE83Z2paPaIvJCMsulEZoxPwfFjpy26M9A775v9kMeBadYSAZaZmgmHVO8o6F 8fljIOxrWgoyNbJ0Q0vrGv4jDVxVldm9FIgwKhKrCMU7XEaweZiYRZ2dXYNbtuiEzLgE 0qfA72k5L0qkxBBLAS/HIhIf9LLYR5kSiQiOAn+LxDfxL26KOYzOwJ/payqsKqF8TRWS lm7R0hIfsDTZ76hFnqzWDsWk7p0AgDhhQEShIcev7ZePzrz2xvzUFoWs5lDgyS61Jaqj tQRA== 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=fbMFxpMUQKRtUyhuoyv2j0bH/nGfyu6XoGFED9bs4e0=; b=CjFmjOKX8T61M7zoofTzzppQk0dAfL3iGDsnv9daXboaji/nWDxa9L0J4mCfcwRQMX nLnQFVNiypkOGwW+jHRxgDYKhvLhjdEAw3yFdEm5sBujbCIst/e2u94VtpHM1iBG/pUu pvJh5kLKLgyYiwXOLKmWaxwq4jt1/+SAZgIdPWTfKwvpKruuWVvXr7Ex8/wp/Qe3m/9M CUmFUtEYxkTO3Bo15Jin4QCspWq+6PRsJaC9sqtkf+/HhlCdCHMfAnGO8o88w38RNxiS XJbJ/XiuxK9NsL2UpsTLUikDen2IUVC43CNddM4KL7UWrSNGoKHfEjeScz4CvCUdkbQ/ VKgQ== X-Gm-Message-State: ALoCoQlI6iKzt/yBc1U3xNf/TrYqnaEE0zFkNsm2rvtgWcN0fr1XHuSvrT6C0T7D0Jexfvk8HaNc MIME-Version: 1.0 X-Received: by 10.107.168.216 with SMTP id e85mr12383880ioj.89.1417745985738; Thu, 04 Dec 2014 18:19:45 -0800 (PST) Received: by 10.64.130.167 with HTTP; Thu, 4 Dec 2014 18:19:45 -0800 (PST) Received: by 10.64.130.167 with HTTP; Thu, 4 Dec 2014 18:19:45 -0800 (PST) In-Reply-To: <5480DB27.3000507@gmail.com> References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> <547F665E.2070804@gmail.com> <5478E4C2-D709-4EFD-BC86-A5068576DAE3@steffann.nl> <547F8D9C.80608@gmail.com> <5480DB27.3000507@gmail.com> Date: Fri, 5 Dec 2014 11:19:45 +0900 Message-ID: From: Lorenzo Colitti To: "Brian E. Carpenter" Content-Type: multipart/alternative; boundary=001a1142e704dcbd9b05096eb58e Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qM64pGQHSMGpzC4WY1EnerJ3LCU Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 05 Dec 2014 02:19:48 -0000 --001a1142e704dcbd9b05096eb58e Content-Type: text/plain; charset=UTF-8 On 5 Dec 2014 7:07 am, "Brian E Carpenter" wrote: > to be on the standards track at all. If it was moved to Informational, > with very light editing, that would remove the Experimental tag that > Randy objects to. We have a long tradition of Informational documents > that record known practice or serve as background for standards. Randy, would that work for you? --001a1142e704dcbd9b05096eb58e Content-Type: text/html; charset=UTF-8


On 5 Dec 2014 7:07 am, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
> to be on the standards track at all. If it was moved to Informational,
> with very light editing, that would remove the Experimental tag that
> Randy objects to. We have a long tradition of Informational documents
> that record known practice or serve as background for standards.

Randy, would that work for you?

--001a1142e704dcbd9b05096eb58e-- From nobody Thu Dec 4 22:52: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 212451AC436 for ; Thu, 4 Dec 2014 22:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 py980L1YSCVK for ; Thu, 4 Dec 2014 22:52:18 -0800 (PST) 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 0CD101AC434 for ; Thu, 4 Dec 2014 22:52:17 -0800 (PST) Received: from [2a02:c0:2:4:6666:17:0:1001] (port=42364 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1XwmkR-0005P4-1M; Fri, 05 Dec 2014 07:52:15 +0100 Date: Fri, 5 Dec 2014 07:52:03 +0100 From: Tore Anderson To: v6ops@ietf.org Message-ID: <20141205075203.54ed9ea4@echo.ms.redpill-linpro.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.24; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2BC-1hb-TzoUg6Ljf_TOgDeSIqQ Subject: [v6ops] New Version Notification for draft-anderson-v6ops-siit-eam-01.txt 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, 05 Dec 2014 06:52:20 -0000 Good morning, I've uploaded a new version of draft-anderson-v6ops-siit-eam. The changes are: - Add missing "Updates: 6145 (if approved)" (thanks, Brian Carpenter) - Improve clarity of some sections (thanks, Alberto Leiva) - Editorial fixes and formatting improvements (thanks, Cameron Byrne) Please read the draft (it's short!), and send any feedback to the list. In any case, I would like to have your "+1" on which approach you prefer of these alternatives: A) Remove all the normative RFC6145 protocol update language from draft-anderson-siit-dc, taking this document off the standards track, and have it describe the data centre use case only. Instead contain the required protocol update in a separate document dedicated to that purpose, i.e., draft-anderson-v6ops-siit-eam. B) Drop draft-anderson-v6ops-siit-eam, keeping the required protocol update as it currently is in draft-ietf-v6ops-siit-dc section 5 and keeping it on the standards track. C) Something else? Please elaborate... :-) Tore Forwarded message: A new version of I-D, draft-anderson-v6ops-siit-eam-01.txt has been successfully submitted by Tore Anderson and posted to the IETF repository. Name: draft-anderson-v6ops-siit-eam Revision: 01 Title: Explicit Address Mappings for Stateless IP/ICMP Translation Document date: 2014-12-04 Group: Individual Submission Pages: 9 URL: http://www.ietf.org/internet-drafts/draft-anderson-v6ops-siit-eam-01.txt Status: https://datatracker.ietf.org/doc/draft-anderson-v6ops-siit-eam/ Htmlized: http://tools.ietf.org/html/draft-anderson-v6ops-siit-eam-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-anderson-v6ops-siit-eam-01 Abstract: This document extends the Stateless IP/ICMP Translation Algorithm (SIIT) with an Explicit Address Mapping algorithm. This algorithm facilitates stateless IP/ICMP translation between arbitrary (non- IPv4-translatable) IPv6 endpoints and IPv4. From nobody Fri Dec 5 00:03: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 BC9E81AC44E for ; Fri, 5 Dec 2014 00:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 UlZFCXp4DE1i for ; Fri, 5 Dec 2014 00:03:50 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 945631AC44D for ; Fri, 5 Dec 2014 00:03:50 -0800 (PST) Received: from [192.168.178.22] (5356AD6E.cm-6-7c.dynamic.ziggo.nl [83.86.173.110]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sB583FmR051158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2014 09:03:16 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Iljitsch van Beijnum In-Reply-To: Date: Fri, 5 Dec 2014 09:03:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7BA18F71-6AF2-4263-97F3-17423AFB0A7B@muada.com> References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DF401A2@ITSNT440.iowa.uiowa.edu> To: Geoff Huston X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/OHZva9NltjAz5EdHswIxdH5IaLg Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MTUs on the general Internet (Was: Report: Bar BoF on a 6to4 replacement) 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, 05 Dec 2014 08:03:53 -0000 On 05 Dec 2014, at 2:51, Geoff Huston wrote: > The problem is here that there is potentially no single "network" that = is broken. At one point on the path from the sender to the receiver = there is a constrained MTU. At one point on the path from the = constrained MTU to the sender (which is not necessarily the same path as = the forward path) there is an ICMP filter. > So who is "broken"? It doesn't say so explicitly in RFC 2460, but you can't filter ICMP too = bigs _and_ expect to send packets larger than 1280 bytes. So any network that wants to filter ICMP too bigs (which I see no = legitimate reason for) needs ot make sure that it only accepts 1280-byte = packets, so PMTUD or MSS advertisement of 1220 happens before the = packets enter the non-PMTUD-capable stretch of network. Anyone who suggests otherwise is not part of the solution but part of = the problem.= From nobody Fri Dec 5 00:12: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 4E9A51AC44E for ; Fri, 5 Dec 2014 00:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 szbrXNLjnViZ for ; Fri, 5 Dec 2014 00:12:18 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02D7D1A00F0 for ; Fri, 5 Dec 2014 00:12:17 -0800 (PST) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:1997:4d59:a2a7:b5b0] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sB58Bifx051213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2014 09:11:45 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Iljitsch van Beijnum In-Reply-To: Date: Fri, 5 Dec 2014 09:03:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7BA18F71-6AF2-4263-97F3-17423AFB0A7B@muada.com> References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DF401A2@ITSNT440.iowa.uiowa.edu> To: Geoff Huston X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/OHZva9NltjAz5EdHswIxdH5IaLg Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MTUs on the general Internet (Was: Report: Bar BoF on a 6to4 replacement) 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, 05 Dec 2014 08:12:19 -0000 On 05 Dec 2014, at 2:51, Geoff Huston wrote: > The problem is here that there is potentially no single "network" that = is broken. At one point on the path from the sender to the receiver = there is a constrained MTU. At one point on the path from the = constrained MTU to the sender (which is not necessarily the same path as = the forward path) there is an ICMP filter. > So who is "broken"? It doesn't say so explicitly in RFC 2460, but you can't filter ICMP too = bigs _and_ expect to send packets larger than 1280 bytes. So any network that wants to filter ICMP too bigs (which I see no = legitimate reason for) needs ot make sure that it only accepts 1280-byte = packets, so PMTUD or MSS advertisement of 1220 happens before the = packets enter the non-PMTUD-capable stretch of network. Anyone who suggests otherwise is not part of the solution but part of = the problem.= From nobody Fri Dec 5 00: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 D6DCC1A88EF for ; Fri, 5 Dec 2014 00:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 3J_o80WAJfSP for ; Fri, 5 Dec 2014 00:18:31 -0800 (PST) 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 D69EA1A0121 for ; Fri, 5 Dec 2014 00:18:30 -0800 (PST) Received: from [2a02:c0:2:4:6666:17:0:1001] (port=45461 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Xwo5o-0007Xi-4S; Fri, 05 Dec 2014 09:18:24 +0100 Date: Fri, 5 Dec 2014 09:18:12 +0100 From: Tore Anderson To: Geoff Huston Message-ID: <20141205091812.39854739@echo.ms.redpill-linpro.com> In-Reply-To: References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.24; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/O8roafL9YyPfdFUAch_9OAZt1rY Cc: v6ops@ietf.org Subject: Re: [v6ops] MTUs on the general Internet (Was: Report: Bar BoF on a 6to4 replacement) 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, 05 Dec 2014 08:18:34 -0000 * Geoff Huston > the tunnel ingress cannot accept the packet and passes back IPv6 > ICMP PTB message toward the sender I would add to this that a number of very common router implementations will rate-limit their local ICMP error generation (or at least not give it very high priority), and this isn't always user-configurable. That means that once the tunnel ingress router are receiving sufficient amounts of packets sized 1481 or larger, PMTUD starts breaking down. Clients will then start retransmitting their large packets, which obviously just exacerbates the problem. This is a fairly common problem with IPv6 tunnels, in my experience. TCP MSS clamping seems to be the most pragmatic way to deal with it (at least if you don't have control of all the CPEs and can set the LAN RA MTU), as reduces the amount of too-large packets to a managable level that's more unlikely to trip any rate-limiter. Tore From nobody Fri Dec 5 00:30: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 4E00F1AC529 for ; Fri, 5 Dec 2014 00:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 g73HIQHhS5i5 for ; Fri, 5 Dec 2014 00:29:58 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F8EE1A894B for ; Fri, 5 Dec 2014 00:29:57 -0800 (PST) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:1997:4d59:a2a7:b5b0] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sB58TQM4051269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2014 09:29:27 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Iljitsch van Beijnum In-Reply-To: <20141205091812.39854739@echo.ms.redpill-linpro.com> Date: Fri, 5 Dec 2014 09:29:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> To: Tore Anderson X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4oRmiChEAW_ymwQu8R_Mh1WefEw Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] MTUs on the general Internet (Was: Report: Bar BoF on a 6to4 replacement) 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, 05 Dec 2014 08:30:00 -0000 On 05 Dec 2014, at 9:18, Tore Anderson wrote: > I would add to this that a number of very common router = implementations > will rate-limit their local ICMP error generation (or at least not = give > it very high priority), and this isn't always user-configurable. That > means that once the tunnel ingress router are receiving sufficient > amounts of packets sized 1481 or larger, PMTUD starts breaking down. I've never seen this. And in measurements using a traceroute = implementation that sends 10 packets at line rate I usually get ICMPs = for all all 10 packets, so it seems rate limiting isn't as common as we = are lead to believe. Rewriting the MSS seems more resource intensive than returning too bigs, = so I don't see how that is a pragmatic choice. Also, it's architectually = problematic: boxes in the middle of the network have no business = modifying layer 4. I hope we can stay away from this in IPv6. Despite the discussion here there doesn't seem to be a widespread PMTUD = black hole problem in IPv6 like there is in IPv4, let's keep it that way = by keeping the message very clear that you MUST either generate/accept = too bigs OR stick to an MTU of 1280. Don't forget that unlike in IPv4, in IPv6 a router that connects to an = MTU-limited hop can easily advertise a reduced MTU to local hosts in = RAs, so the case where MSS clamping is used in IPv4 can be solved more = cleanly in IPv6.= From nobody Fri Dec 5 00:43: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 37D4D1A0140 for ; Fri, 5 Dec 2014 00:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 x6BE7-0dAXnv for ; Fri, 5 Dec 2014 00:43:56 -0800 (PST) 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 DD5751ACD99 for ; Fri, 5 Dec 2014 00:43:55 -0800 (PST) Received: from [2a02:c0:2:4:6666:17:0:1001] (port=46085 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1XwoUT-0008AX-NB; Fri, 05 Dec 2014 09:43:53 +0100 Date: Fri, 5 Dec 2014 09:43:41 +0100 From: Tore Anderson To: Iljitsch van Beijnum Message-ID: <20141205094341.799a12ad@echo.ms.redpill-linpro.com> In-Reply-To: References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.24; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Fpsho9ZFrLVfmvqy5NAVJpSH4ys Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] MTUs on the general Internet (Was: Report: Bar BoF on a 6to4 replacement) 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, 05 Dec 2014 08:43:57 -0000 * Iljitsch van Beijnum > I've never seen this. And in measurements using a traceroute > implementation that sends 10 packets at line rate I usually get ICMPs > for all all 10 packets, so it seems rate limiting isn't as common as > we are lead to believe. 10 packets is nothing. Try 1M or so. Anyway, perhaps you find RAS more trustworthy than me, see slides 35-36: https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf This presentation discusses traceroutes so it focuses on TTL/HLIM exceeded, but PTB is ICMP too. Tore From nobody Fri Dec 5 00:53: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 61C2B1ACDBF for ; Fri, 5 Dec 2014 00:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 iqw5I1FlznKi for ; Fri, 5 Dec 2014 00:53:13 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960BA1ACE10 for ; Fri, 5 Dec 2014 00:53:13 -0800 (PST) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:1997:4d59:a2a7:b5b0] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sB58qhKl051374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2014 09:52:43 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Iljitsch van Beijnum In-Reply-To: <20141205094341.799a12ad@echo.ms.redpill-linpro.com> Date: Fri, 5 Dec 2014 09:53:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> To: Tore Anderson X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_NbZ44eRhPgM5Hu0Ewndk-MqJVY Cc: "v6ops@ietf.org WG" Subject: [v6ops] PMTUD forever, was: MTUs on the general Internet (Was: Report: Bar BoF on a 6to4 replacement) 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, 05 Dec 2014 08:53:16 -0000 On 05 Dec 2014, at 9:43, Tore Anderson wrote: > 10 packets is nothing. Try 1M or so. Are you saying that there are rate limiting implementations that don't = kick in until the 9 millionth packet?? Observations of TTL exceeded rate limiting also don't tell us much about = too big rate limiting as ALL routers are in the position to generate TTL = too bigs and not doing so is only a minor inconvenience (stars in = traceroute) while only routers that sit at the border between two links = with different MTUs need to generate too bigs and failing to do so has = serious connectivity implications. But please let's keep our eyes on the ball here: with IPv4, PMTUD is = dead because there is too much ICMP filtering. With IPv6, PMTUD on the = whole works, so we shouldn't give up on it and deploy ugly hacks or = hardcode 1400 and be stuck with that for the next few decades.= From nobody Fri Dec 5 01:05: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 7EEE01ACE0B for ; Fri, 5 Dec 2014 01:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 21QfnEuGyXgi for ; Fri, 5 Dec 2014 01:05:08 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 78A151ACE1A for ; Fri, 5 Dec 2014 01:05:05 -0800 (PST) Received: (qmail 62523 invoked from network); 5 Dec 2014 09:05:02 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 5 Dec 2014 09:05:02 -0000 Date: Fri, 05 Dec 2014 10:05:02 +0100 (CET) Message-Id: <20141205.100502.74698082.sthaug@nethelp.no> To: tore@fud.no, iljitsch@muada.com From: sthaug@nethelp.no In-Reply-To: <20141205094341.799a12ad@echo.ms.redpill-linpro.com> References: <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XAPt8v9XD5Q22YnwAYoeDZmjTxY Cc: v6ops@ietf.org Subject: Re: [v6ops] MTUs on the general Internet 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, 05 Dec 2014 09:05:22 -0000 > > I've never seen this. And in measurements using a traceroute > > implementation that sends 10 packets at line rate I usually get ICMPs > > for all all 10 packets, so it seems rate limiting isn't as common as > > we are lead to believe. > > 10 packets is nothing. Try 1M or so. Anyway, perhaps you find RAS more > trustworthy than me, see slides 35-36: > > https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf > > This presentation discusses traceroutes so it focuses on TTL/HLIM > exceeded, but PTB is ICMP too. I can confirm that such rate limiting exists, and some of us like to run it with stricter policing (lower limits) than the vendor defaults. Steinar Haug, AS 2116 From nobody Fri Dec 5 01:12: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 642381ACE21 for ; Fri, 5 Dec 2014 01:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 04MoKOP0gwTv for ; Fri, 5 Dec 2014 01:12:53 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id CAE091ACE24 for ; Fri, 5 Dec 2014 01:12:52 -0800 (PST) Received: (qmail 62564 invoked from network); 5 Dec 2014 09:12:51 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 5 Dec 2014 09:12:51 -0000 Date: Fri, 05 Dec 2014 10:12:51 +0100 (CET) Message-Id: <20141205.101251.41689453.sthaug@nethelp.no> To: iljitsch@muada.com From: sthaug@nethelp.no In-Reply-To: References: <20141205094341.799a12ad@echo.ms.redpill-linpro.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/RG4p1Y3wufueE23rQ_tUVxZkLYo Cc: v6ops@ietf.org, tore@fud.no Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 09:12:54 -0000 > > 10 packets is nothing. Try 1M or so. > > Are you saying that there are rate limiting implementations that don't kick in until the 9 millionth packet?? The ratelimiting is often of the type "max X Mbps of Internet traffic is allowed to hit the control plane". It is irrelevant whether this traffic is explit ping of one of the router addresses, or for instance TTL expired or packet too big. Thus if you send 10 packets you may not hit the rate limiting. If you (really: all senders aggregated) send a sufficient number of packets in a sufficiently small time interval, you will hit the rate limiting and packets will be dropped. There is nothing magic about this... Steinar Haug, AS 2116 From nobody Fri Dec 5 01:18: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 9326A1ACE2B for ; Fri, 5 Dec 2014 01:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7] 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 FEBaUf2lE5Tx for ; Fri, 5 Dec 2014 01:18:06 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1A6E1ACE18 for ; Fri, 5 Dec 2014 01:18:05 -0800 (PST) Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id A2ADF100982A5; Fri, 5 Dec 2014 09:18:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417771082; bh=beetSX46H4lR0fSwOrOrNH2Q6/1ehXAxG15zFLJkfCs=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=PJXZP0fVoLVROxWm2b6P3V4ZHq3rwfZu8ooR69ztsPMf5V2kQAAcvJFpjjZEm1T/G twyIBZPqDLSyilMe0+pA0qx8xk7+U9o35Fz05amihW4cjCC/TU/WIz78sWuOHFGwgz theOC7k2tC4raWVI4lRgUct0scucPoqxaLUXOOosAkOaiIaKNdK7TtIQoXj+mQEZk1 BacQzs1F1ZnnFtlcN1G4EzdHftNnBskJsk7N/BOhZ9UgG9nz9iRXbicLZiGnskg/lF zMsvRio3rLnI36nY/rQbr8Djon1QMImULb9bqIqPu5sL+6Z5V9jjwIKLukl2iszSQ3 ann91IXAZW8bQ== Message-ID: <54817847.7050903@massar.ch> Date: Fri, 05 Dec 2014 10:17:59 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: sthaug@nethelp.no, iljitsch@muada.com References: <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205.101251.41689453.sthaug@nethelp.no> In-Reply-To: <20141205.101251.41689453.sthaug@nethelp.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BvUBaRGug_9YUvEdIZ_W-JZjnEY Cc: v6ops@ietf.org, tore@fud.no Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 09:18:09 -0000 On 2014-12-05 10:12, sthaug@nethelp.no wrote: >>> 10 packets is nothing. Try 1M or so. >> >> Are you saying that there are rate limiting implementations that don't kick in until the 9 millionth packet?? > > The ratelimiting is often of the type "max X Mbps of Internet traffic > is allowed to hit the control plane". It is irrelevant whether this > traffic is explit ping of one of the router addresses, or for instance > TTL expired or packet too big. > > Thus if you send 10 packets you may not hit the rate limiting. If you > (really: all senders aggregated) send a sufficient number of packets > in a sufficiently small time interval, you will hit the rate limiting > and packets will be dropped. There is nothing magic about this... Indeed. And whatever the magic event is that causes that to happen: That ICMP PTB is gone. And that is just one of many reasons why they might go missing and why PMTUD is not reliable; though it mostly does just work. Note that with TCP the packet will be resent a bit later and thus there is a chance in such a scenario that that ICMP PTB does come back for the next packet. but there is then already a weird delay which happened. And that is ignoring the networks that just filter or the hardware that ignores ICMPv6 parsing at all. (eg those line-rate loadbalancers that started this thread)... Greets, Jeroen From nobody Fri Dec 5 01:19: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 8CD581ACE1A for ; Fri, 5 Dec 2014 01:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 viM4jzg-KQQZ for ; Fri, 5 Dec 2014 01:19:03 -0800 (PST) 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 BC9B21ACE1F for ; Fri, 5 Dec 2014 01:19:03 -0800 (PST) Received: from [2a02:c0:2:4:6666:17:0:1001] (port=46566 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Xwp2T-0000mJ-Oz; Fri, 05 Dec 2014 10:19:01 +0100 Date: Fri, 5 Dec 2014 10:18:50 +0100 From: Tore Anderson To: Iljitsch van Beijnum Message-ID: <20141205101850.6e58b351@echo.ms.redpill-linpro.com> In-Reply-To: References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.24; x86_64-redhat-linux-gnu) 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/qtr5yxWfpdeP0uvU9qyS-Ddpc0c Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet (Was: Report: Bar BoF on a 6to4 replacement) 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, 05 Dec 2014 09:19:05 -0000 * Iljitsch van Beijnum >>On 05 Dec 2014, at 9:43, Tore Anderson wrote: >> >> 10 packets is nothing. Try 1M or so.=20 > > Are you saying that there are rate limiting implementations that > don't kick in until the 9 millionth packet?? Obviously not, but that a burst of 10 packets are extremely unlikely to trip any ICMP rate-limiter on its own, unless the router is operating close to the rate-limiter's upper limit to begin with. As you'll see in the presentation, most of those rate-limiters cap the ICMP generation rate at a few hundred pps. That's hardly enough for real traffic levels (just a measly 1Gb of traffic is *at least* 83Kpps, and a fair chunk of those packets are going to be >1480). That's why I said =C2=ABtry 1M=C2=BB, because if you are planning on provid= ing internet service over IPv6 tunnels, you had better prepare for dealing with *M*pps of oversized packets, or if that's too much for your tunnel ingress routers, do something else like TCP MSS clamping and/or reduced RA MTUs to get the too-big rate down to manageable levels. > Observations of TTL exceeded rate limiting also don't tell us much > about too big rate limiting as ALL routers are in the position to > generate TTL too bigs and not doing so is only a minor inconvenience > (stars in traceroute) while only routers that sit at the border > between two links with different MTUs need to generate too bigs and > failing to do so has serious connectivity implications. The thing is, both HLIM exceed and PTB are both ICMPv6 errors the router has to generate locally. So both types typically end up in the same rate-limiter or being downprioritised in the same way. You should really read the presentation that I linked to, and actually don't limit yourself to pages 35-36, start at 31 and continue to 37. Most of the information applies equally well to PTB generation as it does to TTL/HLIM exceeded. Tore From nobody Fri Dec 5 01: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 D5B321ACE35 for ; Fri, 5 Dec 2014 01:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 sq39fOXO9g4C for ; Fri, 5 Dec 2014 01:19:32 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E1151ACE2E for ; Fri, 5 Dec 2014 01:19:31 -0800 (PST) Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id AAE72100982A5; Fri, 5 Dec 2014 09:19:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417771169; bh=TXhXtkbCmkMu4sBi3tYHEkx0BaM1OazfPrYCVjvunq8=; h=Date:From:To:Subject:References:In-Reply-To; b=WUQP6+QOXnazYQTgKto5ZCYq9DdQ2246GDUIi6l7iruuUbbPjlr4B1Bs25OnSJ5BY z9DSq63Zt6qJrd8EIoKSP4fcRN59yDwYo5Fuj2wKCSJj/3vczMpN0Pk1F59K9gCbEY 1cXrv3NdwMFcryQL7fYG1q21pcNtaOB5GIf5BRQ5VXpKIEVs9XbL7vV7g3CRMnXkfG ddg8XTzR5JZW5Ax/G4oMJQORPPUDDpxOy5qDPMQPuDscocJDFB9PB5domWeaFSQjk0 wOFtcIetM/VF3f+1I8ZiKduxmewikRNMS9MjU4Qhqp6bsc+4k1bPeW15XrR4XLFCdy NiofHH6hwMZvw== Message-ID: <5481789E.1030207@massar.ch> Date: Fri, 05 Dec 2014 10:19:26 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: "Templin, Fred L" , Iljitsch van Beijnum , "v6ops@ietf.org WG" References: <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141204.111820.41660320.sthaug@nethelp.no> <5480391F.9040902@massar.ch> <2134F8430051B64F815C691A62D9831832DAAD20@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832DAAD20@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/k88OtfDSGJ0Ys2wqVtYl7tJ-sSU Subject: Re: [v6ops] Quick measurement: MTUs on the general Internet 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, 05 Dec 2014 09:19:35 -0000 On 2014-12-04 16:49, Templin, Fred L wrote: > Hi Iljitsch, > > Nice analysis. You are making a good case for the existence of the > 1500 Internet Cell Size as well as MTU diversity. Now we just need > to fix the tunnels that can't do 1500. As Iljitsch stated " It's not a very busy server, so I got 927 incoming TCP SYNs in two hours" Might want to check a larger network... before making any big statement. Let say looking at at least a million packets from several thousand sources and not 927 packets possibly all from the same source. Greets, Jeroen > Thanks - Fred > fred.l.templin@boeing.com > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Iljitsch van Beijnum >> Sent: Thursday, December 04, 2014 5:36 AM >> To: v6ops@ietf.org WG >> Subject: [v6ops] Quick measurement: MTUs on the general Internet >> >> I did some tcpdumping on my server. It's not a very busy server, so I got 927 incoming TCP SYNs in two hours, mostly on port 80. 866 of >> them included the maximum segment size (MSS) option, 584 IPv4 and 282 IPv6. >> >> I also looked at ICMP(v6) too bigs. I got 4 for IPv6, which looks like they were all for my own stuff (they are from the HE tunnel broker) >> and not a single one for IPv4. The MSS size distribution is: >> >> IPv6 (MSS = MTU - 60 (sizeof(IPv6) + sizeof(TCP)): >> >> 1440: 47 >> 1420: 207 >> 1386: 1 >> 1220: 27 >> >> Three of these sizes make total sense: native ethernet (1440), ethernet with IPv6-in-IPv4 (1420) and the minimum IPv6 MTU (1220). >> The only surprising thing is that tunneled is so much more than native. Note that in these cases, either the source host terminates the >> tunnel, the router terminating the tunnel advertises the reduced tunnel MTU or a device along the way rewrites the MSS (which is >> common with IPv4 but not AFAIK with IPv6). >> >> IPv4 is a different story: >> >> IPv4 (MSS = MTU - 40 (sizeof(IPv4) + sizeof(TCP)): >> >> 1460: 364 >> 1452: 36 >> 1448: 1 >> 1440: 53 >> 1430: 19 >> 1420: 11 >> 1414: 13 >> 1410: 3 >> 1400: 11 >> 1392: 2 >> 1380: 43 >> 1360: 18 >> 1260: 5 >> 1240: 5 >> >> "Native IPv4" over ethernet is only 62%. Another 6% must be PPPoE. 1440 and 1240 could be IPv4-in-IPv6, which seems a lot at 10%. >> And then there's a whole bunch of strange values, probably numbers people picked manually. >> >> (Note that I didn't de-duplicate IP addresses, so 10% could be 60 sessions from the same IP address.) >> >> Note that in both cases there was nothing below an MTU of 1280 and nothing above an MTU of 1500. >> >> _______________________________________________ >> 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 Fri Dec 5 01: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 4FD941ACE2E for ; Fri, 5 Dec 2014 01:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7] 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 nqOxxRy0BrX9 for ; Fri, 5 Dec 2014 01:22:47 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA0851A00FF for ; Fri, 5 Dec 2014 01:22:47 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 7100C100982A5; Fri, 5 Dec 2014 09:22:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417771365; bh=YTDWKbC4+6h0m86ljMwoAExhmoJZ4hJEF8Bm+wF3BYY=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=czZdcSMW+QLr9uEeopqqQwtYe+mhPmclm7UZ9ENLMtkB+VbpiPICbf4xQ9PAcJ2uf M3QhQN+JSlRVWoxWanmH4hCQ8WFRwVDomkJn+hhrjGMIeZKKbwXazFDyoaEhNszsBt gvGR6lWZwB8bQPXasRNvRywl0yghlGywcVyCbKVvl7HVA5CE2Mwan5X7iEnLr5PhHP WLl4mliIr9ydt/cY/8KvxBFV4tP7nkPWvfUQuhWEN0zkWjRk03JIyyOzJPkBd2mmy6 wnwfveHmcSDj8nF4dVRERxNvyPZPRrzv99K2fmYtCBT1xUUjz7RkeQTUNvoatvXExk MZDa4QszdH1qw== Message-ID: <54817964.6030901@massar.ch> Date: Fri, 05 Dec 2014 10:22:44 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Tore Anderson , Iljitsch van Beijnum References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> In-Reply-To: <20141205101850.6e58b351@echo.ms.redpill-linpro.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0lJRnAH1KbZt8zZEaij41rO6z8w Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet (Was: Report: Bar BoF on a 6to4 replacement) 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, 05 Dec 2014 09:22:57 -0000 On 2014-12-05 10:18, Tore Anderson wrote: [..] > That's why I said «try 1M», because if you are planning on providing > internet service over IPv6 tunnels, you had better prepare for dealing > with *M*pps of oversized packets, or if that's too much for your tunnel > ingress routers, do something else like TCP MSS clamping and/or reduced > RA MTUs to get the too-big rate down to manageable levels. Indeed. The defaults on for instance Linux & BSD used to/still have ICMP ratelimits configured too. And even turning those up to high numbers will cause ICMP packets (be that echo/request/pt/etcb) to be dropped all the time. Disabling them is one of the ways to resolve it, the other is to not use Linux/BSD kernel itself for doing the handing of the tunnels. Greets, Jeroen From nobody Fri Dec 5 01: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 A97681ACE10 for ; Fri, 5 Dec 2014 01:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 PGMDf-yOxkmL for ; Fri, 5 Dec 2014 01:37:57 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918761ACE0E for ; Fri, 5 Dec 2014 01:37:57 -0800 (PST) Received: from [192.168.178.22] (5356AD6E.cm-6-7c.dynamic.ziggo.nl [83.86.173.110]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sB59bRwL051680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2014 10:37:27 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Iljitsch van Beijnum In-Reply-To: <20141205101850.6e58b351@echo.ms.redpill-linpro.com> Date: Fri, 5 Dec 2014 10:37:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> To: Tore Anderson X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/TtPOuReLKlQW4uTM3kSgazmWm6U Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 09:37:59 -0000 On 05 Dec 2014, at 10:18, Tore Anderson wrote: > As you'll see in the presentation, most of those rate-limiters cap the > ICMP generation rate at a few hundred pps. That's hardly enough for > real traffic levels (just a measly 1Gb of traffic is *at least* = 83Kpps, > and a fair chunk of those packets are going to be >1480). No. If a router sits behind a link with an MTU < 1500 (and especially < = 1480) then obviously it will see many TCP sessions that will attempt to = send packets that are too large to pass and thus too bigs need to be = generated. But due to TCP's congestion control mechanisms, such a router = is never going to see those packets at line rate or anything close to = it. Sure, it's possible that if the factory defaults for ICMP load balancing = are too tight or the operator lowers the limit that some fraction of = those full size packets early in the TCP session are going to be = dropped, but that doesn't mean there's a PMTUD black hole, only that = there will be some number of TCP retransmits before a too big is = returned and the session continues at the lower packet size. Also, hopefully the operators in question will realize there is a = problem and start using a bigger MTU and/or get rid of that restrictive = rate limiting. I don't see the possibility of this scenario as a reason for the IETF or = the operator community to start implementing ugly hacks. I know it's = always tempting to try to engineer something new that can handle a = corner case that the existing stuff doesn't handle, but life is so much = easier if we just consistently implement best practices rather than try = to make our protocols completely foolproof. Those fools are just so damn = ingenious. > if you are planning on providing > internet service over IPv6 tunnels, you had better prepare for dealing > with *M*pps of oversized packets I'd be interested to hear from tunnel operators on how many oversized = packets they receive as a fraction of total packets / 1480 byte packets = / line capacity.= From nobody Fri Dec 5 02:06: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 3E6381ACE24 for ; Fri, 5 Dec 2014 02:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 U5pQ-3NvaPh5 for ; Fri, 5 Dec 2014 02:06:00 -0800 (PST) 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 7A6351ACE20 for ; Fri, 5 Dec 2014 02:06:00 -0800 (PST) Received: from [2a02:c0:2:4:6666:17:0:1001] (port=47216 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Xwplu-0002Cz-Gy; Fri, 05 Dec 2014 11:05:58 +0100 Date: Fri, 5 Dec 2014 11:05:46 +0100 From: Tore Anderson To: Iljitsch van Beijnum Message-ID: <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> In-Reply-To: References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.24; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-_3f4ipBdcWWWCdMrgf7vuKIKBU Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 10:06:02 -0000 * Iljitsch van Beijnum > No. If a router sits behind a link with an MTU < 1500 (and especially > < 1480) then obviously it will see many TCP sessions that will > attempt to send packets that are too large to pass and thus too bigs > need to be generated. But due to TCP's congestion control mechanisms, > such a router is never going to see those packets at line rate or > anything close to it. > > Sure, it's possible that if the factory defaults for ICMP load > balancing are too tight or the operator lowers the limit that some > fraction of those full size packets early in the TCP session are > going to be dropped, but that doesn't mean there's a PMTUD black > hole, only that there will be some number of TCP retransmits before a > too big is returned and the session continues at the lower packet > size. Unless we're talking about your own single-user personal tunnel here, you're not dealing with "the session" singular, you're probably dealing with tens of thousands of new sessions being created every second. And unless there is TCP MSS clamping in effect, a majority of those will have an initial burst of oversized (1500 octets) packets right after the three-way handshake, which require PTBs to be generated. So yes, you *will* end up with a PMTUD black hole, as the continued influx of new sessions that require PTBs will keep the rate-limiter permanently clogged (and the existing sessions will sit there retransmitting their too-big packets, clogging it up even further). Only a few very sessions will get the required PTB; most of them will just time out before a single byte of application data has been successfully transmitted. > Also, hopefully the operators in question will realize there is a > problem and start using a bigger MTU and/or get rid of that > restrictive rate limiting. Easier said than done, considering that the ratelimiters often aren't tunable or possible to disable. (Again, read RAS' presentation.) Also, increasing the outer MTU to 1520+ is impossible in most cases, because you have to be certain that *every* device in the network (including any user-owned/managed HGWs) supports mini-jumbos. Tore From nobody Fri Dec 5 02:19: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 922A11ACE20 for ; Fri, 5 Dec 2014 02:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7] 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 NSZxqcWH6nD2 for ; Fri, 5 Dec 2014 02:19:49 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 71A021A0115 for ; Fri, 5 Dec 2014 02:19:48 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1XwpyX-0000BgC; Fri, 5 Dec 2014 11:19:01 +0100 Message-Id: To: Tore Anderson From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> In-reply-to: Your message of "Fri, 5 Dec 2014 11:05:46 +0100 ." <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> Date: Fri, 05 Dec 2014 11:19:00 +0100 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KpkLKwN6cicLRO3z0n3Lla10yiE Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 10:19:51 -0000 In your letter dated Fri, 5 Dec 2014 11:05:46 +0100 you wrote: >Unless we're talking about your own single-user personal tunnel here, >you're not dealing with "the session" singular, you're probably dealing >with tens of thousands of new sessions being created every second. >And unless there is TCP MSS clamping in effect, a majority of those will >have an initial burst of oversized (1500 octets) packets right after the >three-way handshake, which require PTBs to be generated. > >So yes, you *will* end up with a PMTUD black hole, as the continued >influx of new sessions that require PTBs will keep the rate-limiter >permanently clogged (and the existing sessions will sit there >retransmitting their too-big packets, clogging it up even further). Only >a few very sessions will get the required PTB; most of them will just >time out before a single byte of application data has been successfully >transmitted. There are two things surprising here (well not really we know how it works), one is that people design and deploy devices that basically just don't work in the context where they are deployed. I.e. a tunnel endpoint will have to be able to send loads of packet too big ICMPs. That's part of the required feature set. Same thing for loadbalancers that can't deliver ICMPs to the right hosts. The other confusing part is that commonly used operating systems still ship with PMTU blackhole detection disabled. From nobody Fri Dec 5 02:38: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 3FFA21ACE24 for ; Fri, 5 Dec 2014 02:38:08 -0800 (PST) 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 4ZH5Rs7sOaYi for ; Fri, 5 Dec 2014 02:38:07 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id C19291ACE20 for ; Fri, 5 Dec 2014 02:38:06 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1XwqGy-0000ChC; Fri, 5 Dec 2014 11:38:04 +0100 Message-Id: To: "v6ops@ietf.org WG" From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> In-reply-to: Your message of "Fri, 5 Dec 2014 11:05:46 +0100 ." <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> Date: Fri, 05 Dec 2014 11:38:04 +0100 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9bHPVT9FzJGZbpnKtWgYXhXGDzM Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 10:38:08 -0000 In your letter dated Fri, 5 Dec 2014 11:05:46 +0100 you wrote: >Also, increasing the outer MTU to 1520+ is impossible in most cases, >because you have to be certain that *every* device in the network >(including any user-owned/managed HGWs) supports mini-jumbos. Another way forward is to have to 'internet facing' side of the tunnel forward large packets fragmented. Assuming that the 'small' other endpoint can reassemble them. Traffic toward 'the internet' can be considered local and can be fixed to properly deal with PMTU detection. From nobody Fri Dec 5 02:56: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 519F91ACE3A for ; Fri, 5 Dec 2014 02:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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, RCVD_IN_DNSWL_LOW=-0.7] 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 cczWSZk7D6mE for ; Fri, 5 Dec 2014 02:56:06 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B4841ACE36 for ; Fri, 5 Dec 2014 02:56:06 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id ED0D3100982C6; Fri, 5 Dec 2014 10:56:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417776963; bh=fc1CMgbhLGKJulRXFUoTHNdoR6uY9i85CK9H9hNxyQE=; h=Date:From:To:Subject:References:In-Reply-To; b=fzY73cEJzJakW+pNId5bAUJAjNtxrJDEwHZZp95a0C9RHxsJM/e9yAT5b+PCT5spF NBNK8eop2TcVlJ5V/k/oDIiKegwpPyTuGJ0wf+WQwHThgrLRyFDNuagdUWeDNsv4ln naOgAY/2H73g+aUFdOJDNwVqYpcMsVn5labBKIz7TqaomdZP1ahPgma3QWeWP/JkNz teapZ/ZJF/IfqDykz0epYPgvXfZ01zFMpaRFz/cCtmG9BTkn9o24HUr9n4FRYtyIc7 9Wcl1wGi6/V3f9mdMUYiqCBuC4aAq5fiLazIfNEBKGAf8BVoiBvMxgE5DEL7txGas3 K37lWJ/HE+M3g== Message-ID: <54818F41.9090802@massar.ch> Date: Fri, 05 Dec 2014 11:56:01 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Philip Homburg , "v6ops@ietf.org WG" References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/C6VQL8yFWMC4FFnqxrIJHBd5llU Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 10:56:09 -0000 On 2014-12-05 11:38, Philip Homburg wrote: > In your letter dated Fri, 5 Dec 2014 11:05:46 +0100 you wrote: >> Also, increasing the outer MTU to 1520+ is impossible in most cases, >> because you have to be certain that *every* device in the network >> (including any user-owned/managed HGWs) supports mini-jumbos. > > Another way forward is to have to 'internet facing' side of the tunnel forward > large packets fragmented. Only end hosts do fragmentation in IPv6. Also, hosts that are causing these problems are not going to perform an even heavier task. Greets, Jeroen From nobody Fri Dec 5 03:00: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 136D01ACE3D for ; Fri, 5 Dec 2014 03:00:53 -0800 (PST) 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 Ytjos0mZyUpz for ; Fri, 5 Dec 2014 03:00:52 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id D51551ACE27 for ; Fri, 5 Dec 2014 03:00:51 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1Xwqd1-0000DzC; Fri, 5 Dec 2014 12:00:51 +0100 Message-Id: To: Jeroen Massar From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> <54818F41.9090802@massar.ch> In-reply-to: Your message of "Fri, 05 Dec 2014 11:56:01 +0100 ." <54818F41.9090802@massar.ch> Date: Fri, 05 Dec 2014 12:00:50 +0100 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KpSn8DfGSOkNj42Ta7edecy1gxA Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 11:00:53 -0000 In your letter dated Fri, 05 Dec 2014 11:56:01 +0100 you wrote: >On 2014-12-05 11:38, Philip Homburg wrote: >> Another way forward is to have to 'internet facing' side of the tunnel forward >> large packets fragmented. > >Only end hosts do fragmentation in IPv6. I was talking about tunnels. In general, tunnel endpoints are hosts. In case it wasn't clear, I meant fragmenting the outer (IPv4) packet, not the inner (IPv6) packet. From nobody Fri Dec 5 03:47: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 207F21ACE30 for ; Fri, 5 Dec 2014 03:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 9zd7Fw3x72VB for ; Fri, 5 Dec 2014 03:46:58 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 580171A01CB for ; Fri, 5 Dec 2014 03:46:58 -0800 (PST) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:1997:4d59:a2a7:b5b0] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sB5BkSBA052362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2014 12:46:29 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Iljitsch van Beijnum In-Reply-To: Date: Fri, 5 Dec 2014 12:45:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <100130B5-A9B3-4FB5-ABA4-35AFC5D62861@muada.com> References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> <54818F41.9090802@massar.ch> To: Philip Homburg X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7ANaGkMYACplMnpbh43_U6H47p0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 11:47:00 -0000 On 05 Dec 2014, at 12:00, Philip Homburg = wrote: >> Only end hosts do fragmentation in IPv6. > I was talking about tunnels. In general, tunnel endpoints are hosts. Not sure if that's true. But if it is, there's no problem anyway, as the = host will advertise an MSS that reflects the path MTU. I.e., tunnel on = host: IPv4 MTU =3D 1500, IPv6 MTU =3D 1480, IPv6 MSS =3D 1480 - 60 =3D = 1420 and no too bigs are required.= From nobody Fri Dec 5 04:14: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 B17091AC43A for ; Fri, 5 Dec 2014 04:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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, RCVD_IN_DNSWL_LOW=-0.7] 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 vazLHNfEZwoz for ; Fri, 5 Dec 2014 04:14:47 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4AA61A8AD2 for ; Fri, 5 Dec 2014 04:14:46 -0800 (PST) Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id CA842100982C6; Fri, 5 Dec 2014 12:14:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417781684; bh=VkACEKyPAISZeL6KmKKzsx9ljybbqbYbYzoTY7JC0TY=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=v22bHKf939YePtxmuwNDC95tj85T7Lsn3zAevwGl5dh15VqvoeHE+LUien61AT1f5 GtfC6FacZHD0RdXDlgVKkdUwvtTZSiltOwnkwWM19U7xNzwxRwhviVb/Pv5XzbQk5z 1Ms30oZoc6wcYsknq+RC7mbUzNr09vEShD4bFTIUIgxhAaeu1IR13ttuu9CQI4bFWf EsEYankaARlhZaUeFWn2bNAy/yZyamYGI8EwVN0iBP0GrFfMfCSJ9ixkQrS3IK8i3D fD9G8Ht8CsxmWvvJppv5XfxSilZ0aqpeUOxCOLzEb+ndARf0lrJFjBM4u2pfXmIt7H f8Ft6Cf8UTCuw== Message-ID: <5481A1B0.3080804@massar.ch> Date: Fri, 05 Dec 2014 13:14:40 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Philip Homburg References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> <54818F41.9090802@massar.ch> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0eXxl191fJZ53rYWDm5P4xzQLcE Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 12:14:50 -0000 On 2014-12-05 12:00, Philip Homburg wrote: > In your letter dated Fri, 05 Dec 2014 11:56:01 +0100 you wrote: >> On 2014-12-05 11:38, Philip Homburg wrote: >>> Another way forward is to have to 'internet facing' side of the tunnel forward >>> large packets fragmented. >> >> Only end hosts do fragmentation in IPv6. > > I was talking about tunnels. In general, tunnel endpoints are hosts. > > In case it wasn't clear, I meant fragmenting the outer (IPv4) packet, > not the inner (IPv6) packet. Not only tunnels have a lower MTU. Just adding an extension header somewhere and you already lower the payload size. Doing fragmentation means sending at least two packets, maybe one gets lost, what to do, resend, wait? Note that most tunneling protocols do not resend data (unless they run over TCP and then TCP handles it). It also pushes the burden of refragmentation towards the receiver of the packet, which suddenly becomes open to a fragmentation attack, which is likely not what they will want to see happening (enough crap gets send to those boxes already because someone is misbehaving on IRC). Remember that the minimum MTU for IPv6 is 1280 for a reason: very safe to use for tunneling and other constructs where one does not have a full Ethernet MTU. Just sticking everywhere to 1500 is not a solution. Unless one wants to define the minimum MTU for IPv6 as 1500. It is still a minimum and there are speakers out there that do 9000 with ease, just not intra-AS, and intra-AS is where these kind of PTB and ICMP ratelimiting problems exist: in somebody elses network. As for implementations doing fragging of tunneled packets, check: http://backreference.org/2013/07/23/gre-bridging-ipsec-and-nfqueue/ Which gives a nice overview why that further is a bad idea and why it typically will not work anyway unless getting very hacky. Oh, and do apply that to every deployed host on the Internet please. Search also for frag/mtu/df/PMTUDISC in: https://github.com/torvalds/linux/blob/master/net/ipv6/sit.c yes there is a magic 'pmtudisc' option for tunnels, but not enabled per default and it does not work as expected. For some fun reason, only custom TTLs get a frag_off filled and thus possibility to not frag. Thus if one does not specify a TTL at creation time (advised anyway as the default used to be 255 or actually 'TTL from the tunnel device') the DF flag does not get set... Also check how often the MTU is forced to the IPv6 minimum MTU. Fun also that that code is so well commented on why certain pieces of code are there let alone what they do. These: https://github.com/freebsd/freebsd/blob/master/sys/netinet/in_gif.c https://github.com/freebsd/freebsd/blob/master/sys/netinet/ip_output.c read sooo much better than the Linux equivalent... comments, what a useful mechanism for documenting why things are done. As gif does not set ip_off, DF is not set and thus ip_output will fragment here. Or summary on those two platforms: FreeBSD fragments packets (DF not set) Linux fragments normally (DF not set), but most configs define TTL and thus DF gets set and packets get dropped need to optionally add hack to drop DF bit. I am quite sure that at least in the SixXS userbase nobody uses this feature, as sixxsd does not do reassembly for proto-41 packets... (and the default MTU is 1280 as mentioned before). Greets, Jeroen From nobody Fri Dec 5 04:19: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 DB5FA1A01D6 for ; Fri, 5 Dec 2014 04:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, T_RP_MATCHES_RCVD=-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 qjnUPKgN7hav for ; Fri, 5 Dec 2014 04:19:49 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 AB6B61A01CB for ; Fri, 5 Dec 2014 04:19:49 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0B1B862D5A for ; Fri, 5 Dec 2014 13:19:48 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id BC34662D56 for ; Fri, 5 Dec 2014 13:19:47 +0100 (CET) Received: (qmail 16122 invoked by uid 1007); 5 Dec 2014 13:19:47 +0100 Date: Fri, 5 Dec 2014 13:19:47 +0100 From: Gert Doering To: Jeroen Massar Message-ID: <20141205121947.GU28745@Space.Net> References: <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> <54818F41.9090802@massar.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54818F41.9090802@massar.ch> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/laYTQIf_vvxioag1UHRuokppJRA Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 12:19:52 -0000 Hi, On Fri, Dec 05, 2014 at 11:56:01AM +0100, Jeroen Massar wrote: > On 2014-12-05 11:38, Philip Homburg wrote: > > In your letter dated Fri, 5 Dec 2014 11:05:46 +0100 you wrote: > >> Also, increasing the outer MTU to 1520+ is impossible in most cases, > >> because you have to be certain that *every* device in the network > >> (including any user-owned/managed HGWs) supports mini-jumbos. > > > > Another way forward is to have to 'internet facing' side of the tunnel forward > > large packets fragmented. > > Only end hosts do fragmentation in IPv6. A tunnel ingress *is* an end-host as far as the outer packet is concerned. 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 Fri Dec 5 04:20: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 A9C1D1A8AD2 for ; Fri, 5 Dec 2014 04:20:45 -0800 (PST) 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 fXexFIIeOqni for ; Fri, 5 Dec 2014 04:20:43 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAEA1A01CB for ; Fri, 5 Dec 2014 04:20:43 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1XwrsI-0000CbC; Fri, 5 Dec 2014 13:20:42 +0100 Message-Id: To: Iljitsch van Beijnum From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> <54818F41.9090802@massar.ch> <100130B5-A9B3-4FB5-ABA4-35AFC5D62861@muada.com> In-reply-to: Your message of "Fri, 5 Dec 2014 12:45:47 +0100 ." <100130B5-A9B3-4FB5-ABA4-35AFC5D62861@muada.com> Date: Fri, 05 Dec 2014 13:20:41 +0100 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xDjznat65a7FPBcq6r5gBnfAlrE Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 12:20:45 -0000 In your letter dated Fri, 5 Dec 2014 12:45:47 +0100 you wrote: >> I was talking about tunnels. In general, tunnel endpoints are hosts. > >Not sure if that's true. But if it is, there's no problem anyway, as the >host will advertise an MSS that reflects the path MTU. I.e., tunnel on >host: IPv4 MTU =3D 1500, IPv6 MTU =3D 1480, IPv6 MSS =3D 1480 - 60 = >1420 and no too bigs are required. The host? My local tunnel endpoint is in the CPE. All IPv6 hosts are connected over ethernet. So those hosts will advertise an MSS based on a 1500 MTU. When a remote host sends a 1500 octet IPv6 packet then the tunnel endpoint I normally use will just send a fragmented IPv4 packet, so my tunnel link has an MTU of 1500 avoiding an PTMU problems. One other tunnel only forwards IPv6 packets where the resulting IPv4 packet is 1500 octets or less, so this has a potential for PMTU problems. Yet another tunnel seems to limit IPv6 packets to 1280 for some non-obvious reason. From nobody Fri Dec 5 04:22: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 66AE41ACE52 for ; Fri, 5 Dec 2014 04:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 RqFgiCocxMXD for ; Fri, 5 Dec 2014 04:22:27 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5341ACE51 for ; Fri, 5 Dec 2014 04:22:26 -0800 (PST) Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 89CD3100982C6; Fri, 5 Dec 2014 12:22:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417782143; bh=xyEXJUU3AF2TD6XZZxKituQ42vLKxPzgxLyqk4NOnao=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=yXytYiwB8R2FednBL4WvtL5Pmb6KWqJzAZa92LWZ+vhwpPPqvFjZeMvhf3Owbv6Fh +bvkvHJxCFUc/nCU89gYAFBYY4ODQI40tNMg6ttPH9Wazw09jz44sitrezmDZZFcpt LisFmV3U9xptqNep9OL5Dc902ZIfXMHJnbHEiClSZEv9ZjgQE6Y1IlKVn/PcpwNOb6 qLSriylUbbMsEj6JDjvRTsgJC60/IOQRQ9RThbdKi/KqMN8ZufHimFXSQx21GAAaGz VmvswPP+8ZhgkQRUhwVWIZzWBv4FEEe7vB1gw6ZtEYe+0hE757EuxwWFl2JMWxKHbG e9UDmI1B+fL9A== Message-ID: <5481A37D.2070006@massar.ch> Date: Fri, 05 Dec 2014 13:22:21 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Iljitsch van Beijnum , Philip Homburg References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> <54818F41.9090802@massar.ch> <100130B5-A9B3-4FB5-ABA4-35AFC5D62861@muada.com> In-Reply-To: <100130B5-A9B3-4FB5-ABA4-35AFC5D62861@muada.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/74ek8vblgsoxx4pCMlicOdnKBoc Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 12:22:28 -0000 On 2014-12-05 12:45, Iljitsch van Beijnum wrote: > On 05 Dec 2014, at 12:00, Philip Homburg wrote: > >>> Only end hosts do fragmentation in IPv6. > >> I was talking about tunnels. In general, tunnel endpoints are hosts. > > Not sure if that's true. But if it is, there's no problem anyway, as the host will > > advertise an MSS that reflects the path MTU. psst... MSS only applies to TCP. We need a new term likely though for what you want to say: MPL = Max Payload Length As that is what we are talking about, not the MTU. > I.e., tunnel on host: IPv4 MTU = 1500, IPv6 MTU = 1480, > IPv6 MSS = 1480 - 60 = 1420 and no too bigs are required. Yep, you definitely mean MPL there. (which might match MSS, but is not MSS) The problem some folks in this discussion seem to want to avoid though is that tunneled MTU deviates off 1500. And they thus want to force tunnels to always have a MTU of 1500 and thus force the lower layer to fragment packets instead. While indeed then for that section you might not have any PMTU issues anymore, you will create a whole bunch of overhead by fragmenting packets (multiple packets, more possible packet loss, more traffic needs to be sent etc). Next to the deployed base not support it anyway (see other mail checking Linux code that is currently on github, not the stuff that is even out on the Internet which can be ancient)... Greets, Jeroen From nobody Fri Dec 5 04:31: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 B3E931ACE51 for ; Fri, 5 Dec 2014 04:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 kwHQPvQOa7zf for ; Fri, 5 Dec 2014 04:31:28 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8AC1ACE52 for ; Fri, 5 Dec 2014 04:31:28 -0800 (PST) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:1997:4d59:a2a7:b5b0] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sB5CV0Rt052591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2014 13:31:00 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Iljitsch van Beijnum In-Reply-To: Date: Fri, 5 Dec 2014 13:31:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> <54818F41.9090802@massar.ch> <100130B5-A9B3-4FB5-ABA4-35AFC5D62861@muada.com> To: Philip Homburg X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/iiYEmu5jkPWol_pGD4UakF3unNI Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 12:31:29 -0000 On 05 Dec 2014, at 13:20, Philip Homburg = wrote: >>> In general, tunnel endpoints are hosts. > My local tunnel endpoint is in the CPE. Ok, so which is it? > IPv6 hosts are connected over > ethernet. So those hosts will advertise an MSS based on a 1500 MTU. Yes. So here you need PMTUD (unless the tunnel supports 1500-byte inner = packets).= From nobody Fri Dec 5 04:39: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 88DA71ACE5E for ; Fri, 5 Dec 2014 04:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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, RCVD_IN_DNSWL_LOW=-0.7] 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 UH6JfJ6VoX4K for ; Fri, 5 Dec 2014 04:39:25 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B755F1ACE57 for ; Fri, 5 Dec 2014 04:39:24 -0800 (PST) Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 1FEB4100982C6; Fri, 5 Dec 2014 12:39:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417783162; bh=HtjeTRVYyyuSshJ5ULbChW1+4XvEtTxdmzckuzsDI6g=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=iFeKCIUqsQSjZ3/Db1UMEC++5bsACpNHHM1kUfgSmzHGFwK7jZsS5cwZXyNAWje5O CUWVq3rRCZ2RM1oZWnUdXee4u0owRTBd1IYog1hmmAL5+bihxbAKjaPST/wnp9wRny X2hUKORGK3TZEYqVNU6WWdeZUC30RWEOHJWXlOI7GR26QLORzJnpyyYYIIgcgrl0FT uv9crJwlWnIY2BgzTA4ihtHjALmIDlek1zpCNBPiT6VKS0LQcm9s+05VCgI/uHfSeO baIdB6/dNhjGaXCESApr7nugf0MTG8hyjK3UeUfnXbQd109WiFQmxRtW5uXDM5aEG/ wuw8Z5xD2aZpA== Message-ID: <5481A778.8090702@massar.ch> Date: Fri, 05 Dec 2014 13:39:20 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Philip Homburg , Iljitsch van Beijnum References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> <54818F41.9090802@massar.ch> <100130B5-A9B3-4FB5-ABA4-35AFC5D62861@muada.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xtiYyk99m-27LIp65o1GJfyJNbQ Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 12:39:26 -0000 On 2014-12-05 13:20, Philip Homburg wrote: > In your letter dated Fri, 5 Dec 2014 12:45:47 +0100 you wrote: >>> I was talking about tunnels. In general, tunnel endpoints are hosts. >> >> Not sure if that's true. But if it is, there's no problem anyway, as the >> host will advertise an MSS that reflects the path MTU. I.e., tunnel on >> host: IPv4 MTU =3D 1500, IPv6 MTU =3D 1480, IPv6 MSS =3D 1480 - 60 = >> 1420 and no too bigs are required. > > The host? My local tunnel endpoint is in the CPE. A node terminating a tunnel is also a host, but on IPv4. While it is a forwarding node in IPv6. > All IPv6 hosts are connected over > ethernet. So those hosts will advertise an MSS based on a 1500 MTU. Which means you need proper PMTUD or for TCP clamp the MSS. Though MSS-clamping does not solve any non-TCP problems. (or have google etc force a guessed low MSS) > When a remote host sends a 1500 octet IPv6 packet then the tunnel endpoint I > normally use You mean the remote side of the tunnel (thus the other end of your CPE). > will just send a fragmented IPv4 packet, so my tunnel link has an > MTU of 1500 avoiding an PTMU problems. And in sending 1 Gig of traffic you end up sending a lot more than that. Let alone the extra latency you get (at least double) for full packets. But if one can live/work with that, fine of course. Latency might be 4x the norm if you are sending full packets in both directions, fun(tm). While it is an interesting 'solution' (fragging on a lower level and thus having a 1500 MTU path). The overhead/latency and attacks that are then possible on the infrastructure kind of removes the positive side: that a few nodes on the Internet have broken ICMPv6 handling. > One other tunnel only forwards IPv6 packets where the resulting IPv4 packet is > 1500 octets or less, so this has a potential for PMTU problems. > > Yet another tunnel seems to limit IPv6 packets to 1280 for some non-obvious reason. Which "another tunnel" Note that 1280 is the minimum IPv6 MTU which is likely why that is chosen. Most tunnel protocols allow changing MTU though. Greets, Jeroen From nobody Fri Dec 5 04:44: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 8F5141ACE5B for ; Fri, 5 Dec 2014 04:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7] 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 uCxPCkWsX96O for ; Fri, 5 Dec 2014 04:44:20 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7E51ACE57 for ; Fri, 5 Dec 2014 04:44:20 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1XwsF9-0000BcC; Fri, 5 Dec 2014 13:44:19 +0100 Message-Id: To: Iljitsch van Beijnum From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> <54818F41.9090802@massar.ch> <100130B5-A9B3-4FB5-ABA4-35AFC5D62861@muada.com> In-reply-to: Your message of "Fri, 5 Dec 2014 13:31:19 +0100 ." Date: Fri, 05 Dec 2014 13:44:18 +0100 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/up4INm0NbPCynRmZEJA-upXtooI Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 12:44:21 -0000 In your letter dated Fri, 5 Dec 2014 13:31:19 +0100 you wrote: >On 05 Dec 2014, at 13:20, Philip Homburg = >wrote: > >>>> In general, tunnel endpoints are hosts. > >> My local tunnel endpoint is in the CPE. > >Ok, so which is it? For the outer (IPv4) packet, the CPE is a host. For the inner (IPv6) packet, the CPE is a router. >> IPv6 hosts are connected over >> ethernet. So those hosts will advertise an MSS based on a 1500 MTU. > >Yes. So here you need PMTUD (unless the tunnel supports 1500-byte inner >packets). So, make the tunnel support 1500 octet inner packets until PMTU is actually fixed. Of course, as a content provider you can just restrict the link MTU on your hosts and have happy users. Essentially to avoid problems, you want to receive packets as big as possible and send packets that are smaller than commonly used paths. From nobody Fri Dec 5 05:01: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 8476C1ACE74 for ; Fri, 5 Dec 2014 05:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 HUXvzDyJPIul for ; Fri, 5 Dec 2014 05:01:52 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12A51A0248 for ; Fri, 5 Dec 2014 05:01:51 -0800 (PST) Received: from [192.168.178.22] (5356AD6E.cm-6-7c.dynamic.ziggo.nl [83.86.173.110]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sB5D1Nlr052766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2014 14:01:24 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Iljitsch van Beijnum In-Reply-To: Date: Fri, 5 Dec 2014 14:01:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> <54818F41.9090802@massar.ch> <100130B5-A9B3-4FB5-ABA4-35AFC5D62861@muada.com> To: Philip Homburg X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7d0yagnbbMKbujCZMlW4Lj8doak Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 13:01:53 -0000 On 05 Dec 2014, at 13:44, Philip Homburg = wrote: > For the outer (IPv4) packet, the CPE is a host. For the inner (IPv6) = packet, the=20 > CPE is a router.=20 Please don't (ab)use terminology like that. A host is a host, a CPE is = not a host in normal conversation.= From nobody Fri Dec 5 05:09: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 01C6D1ACE7F for ; Fri, 5 Dec 2014 05:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 HZhss487cbRL for ; Fri, 5 Dec 2014 05:08:43 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066B41ACE56 for ; Fri, 5 Dec 2014 05:08:43 -0800 (PST) Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 49282100982A5; Fri, 5 Dec 2014 13:08:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417784919; bh=VaFGsUzWqXzgKrLywLbUUs85DFYH578nCFC22VfEDI4=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=jmSl3C69ZCTUZINunuNvTw3u6MKclrLm57fSVNG4s0f613LeSk6cnjRzKXIvPJUxO BiBz66iNg3ddiGrakk9pN7WDbrvq75gKK0yUACUhXECa3jeq4hJ/hASBJnQ7foL82j rQDj7c2Ln1wWoR5QCqoZxWwWCOcqJtv+VzzjMaX6U6bDeoZjKhk9kwJl/3s9jt2AEg om/O6D0vLRs7qAGTPLNMQWFpGNpFdZwG2EkZfseSGcAMSvvwzku50bAw1U2Kp056Ky hTAEOdzrZiG3S4Qlfxg04n8M2goHhlYGhJeQgbsRJjzHnXrhAZgYBVSPxic3fmk2TH rUiGGTdkZIa/Q== Message-ID: <5481AE53.9020906@massar.ch> Date: Fri, 05 Dec 2014 14:08:35 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Iljitsch van Beijnum , Philip Homburg References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> <54818F41.9090802@massar.ch> <100130B5-A9B3-4FB5-ABA4-35AFC5D62861@muada.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZuF_8g1PxUOv3_TaDbdieQ7-eJo Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 13:08:45 -0000 On 2014-12-05 14:01, Iljitsch van Beijnum wrote: > On 05 Dec 2014, at 13:44, Philip Homburg wrote: > >> For the outer (IPv4) packet, the CPE is a host. For the inner (IPv6) packet, the >> CPE is a router. > > Please don't (ab)use terminology like that. A host is a host, a CPE is not a host in normal conversation. While the terms used in his previous message where indeed a bit confusing, I see nothing wrong with the above. Every[1] IP capable node is a host[2]. It is just that some nodes are also forwarding packets and thus become routers. CPEs definitely are hosts for most people, be that normal users (they go to http://myrouter/ and for sysadmins: they admin those hosts. And in the above sentence that CPE is definitely a host acting as one side of a tunnel endpoint. Greets, Jeroen [1] = do unmanageable forward-only nodes exist? the moment a packet is sent to the IP address configured though it is acting as a host. Thus I don't think this is possible unless they do not comply with IP and are effectively L2 bridges. [2] Even https://en.wikipedia.org/wiki/Host_%28network%29 states: "A network host is a computer or other device connected to a computer network." From nobody Fri Dec 5 05:32: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 E37AB1A026E for ; Fri, 5 Dec 2014 05:32:28 -0800 (PST) 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 uWnqDibHHZdE for ; Fri, 5 Dec 2014 05:32:26 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id A097A1A016B for ; Fri, 5 Dec 2014 05:32:25 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1Xwszg-0000DzC; Fri, 5 Dec 2014 14:32:24 +0100 Message-Id: To: Jeroen Massar From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> <54818F41.9090802@massar.ch> <5481A1B0.3080804@massar.ch> In-reply-to: Your message of "Fri, 05 Dec 2014 13:14:40 +0100 ." <5481A1B0.3080804@massar.ch> Date: Fri, 05 Dec 2014 14:32:24 +0100 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yaRdVHm7qLyY7zbJ760lESTkE-M Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 13:32:29 -0000 In your letter dated Fri, 05 Dec 2014 13:14:40 +0100 you wrote: >On 2014-12-05 12:00, Philip Homburg wrote: >> In case it wasn't clear, I meant fragmenting the outer (IPv4) packet, >> not the inner (IPv6) packet. > >Not only tunnels have a lower MTU. Just adding an extension header >somewhere and you already lower the payload size. In the current internet, PMTU is quite broken. Not completely broken, but enough to be noticeable. Extension headers are also routinely filtered. So if you don't want to much pain, you avoid PMTU and extension headers. >Doing fragmentation means sending at least two packets, maybe one gets >lost, what to do, resend, wait? Note that most tunneling protocols do >not resend data (unless they run over TCP and then TCP handles it). Locally, i.e. between my CPE and my tunnel endpoints the loss rate of IPv4 packets in general is way lower than losses caused by PMTU discovery. So this is good trade off. By the time PMTU discovery is essentially perfect it may be time to reconsider. >It also pushes the burden of refragmentation towards the receiver of the >packet, which suddenly becomes open to a fragmentation attack, which is >likely not what they will want to see happening (enough crap gets send >to those boxes already because someone is misbehaving on IRC). If somebody wants to DoS my CPE, they can just do that. No need to try a fragmentation attack. >Remember that the minimum MTU for IPv6 is 1280 for a reason: very safe >to use for tunneling and other constructs where one does not have a full >Ethernet MTU. And then somebody starts a VPN that goes over a tunnel somewhere and we are back at square one. Furthermore, unless you can somehow get all hosts on the internet to use a 1280 MTU, your tunnel will cause PMTU problems. Way more than a decade after ethernet devices first started supporting jumbograms, most ethernets are still at 1500. So the most sane way to avoid PMTU problems is to run all links at a 1500 octet MTU. >Just sticking everywhere to 1500 is not a solution. Unless one wants to >define the minimum MTU for IPv6 as 1500. It is still a minimum and there >are speakers out there that do 9000 with ease, just not intra-AS, and >intra-AS is where these kind of PTB and ICMP ratelimiting problems >exist: in somebody elses network. The only practical MTU on the internet is currently 1500. Locally you can go higher or lower. From nobody Fri Dec 5 05: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 B105C1A01F6 for ; Fri, 5 Dec 2014 05:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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, RCVD_IN_DNSWL_LOW=-0.7] 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 a5nDb63KbN-f for ; Fri, 5 Dec 2014 05:40:30 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AD3B1A0372 for ; Fri, 5 Dec 2014 05:40:30 -0800 (PST) Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 8F5FE100982CD; Fri, 5 Dec 2014 13:40:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417786826; bh=3Uh8Hk8z+QNO3DB6UZk3aiijFJaD8kVUrTm/pWlQOpo=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=OmbkonKDoBN+UGo/tAzEIDOP6wLvzaVezGyfNNaLfvIzzoJvIzpJs+TlX6E2r1VHZ Ge9bV4bCsH64jPokyr72QOi12kZ042cdyq+RrTY3vMNgQQqAVmaP1dAksgm5O2MmrM HlaRZVOQ5jBJC0uVTgPPJAY39oHF3xQ5yp22JvIkknttn3QrkgdQaQVre0mCYlaR7w F8eMlqhQf4tz4YEG0RyRGaTGcw6icc7oEntYTm4HbpWJVzN882Hx/aVrd1EqjADJPf DeixYMgrBQ468dRe7cAGeUzepPvJvcb6k2iu8gMAgoMYfXiK6rmCn5XnhrpdHM3hHj EFNLRbP+uwwQA== Message-ID: <5481B5C8.6030501@massar.ch> Date: Fri, 05 Dec 2014 14:40:24 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Philip Homburg References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> <54818F41.9090802@massar.ch> <5481A1B0.3080804@massar.ch> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/eala7NOcyvmS6HUdMXMUIokplKs Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 13:40:32 -0000 Please doc this 'frag on the layer below' idea with the pros and cons it has, would be a good informational document; but likely that will see little global/large deployment due to the cons. On 2014-12-05 14:32, Philip Homburg wrote: > In your letter dated Fri, 05 Dec 2014 13:14:40 +0100 you wrote: >> On 2014-12-05 12:00, Philip Homburg wrote: >>> In case it wasn't clear, I meant fragmenting the outer (IPv4) packet, >>> not the inner (IPv6) packet. >> >> Not only tunnels have a lower MTU. Just adding an extension header >> somewhere and you already lower the payload size. > > In the current internet, PMTU is quite broken. Not completely broken, but enough > to be noticeable. Extension headers are also routinely filtered. > > So if you don't want to much pain, you avoid PMTU and extension headers. I've been using PMTU successfuly for over 15 years. Only recently there where two events where a middle box was broken as they do not comply to the IPv6 specification (they ignore ICMPv6). All other instances of PMTU issues are easily classified as either: - misconfigurations - rate limitting Yes. These are problematic. Not much one can do about as these involve people and physical limits. >> Doing fragmentation means sending at least two packets, maybe one gets >> lost, what to do, resend, wait? Note that most tunneling protocols do >> not resend data (unless they run over TCP and then TCP handles it). > > Locally, i.e. between my CPE and my tunnel endpoints the loss rate of IPv4 packets > in general is way lower than losses caused by PMTU discovery. > > So this is good trade off. By the time PMTU discovery is essentially perfect > it may be time to reconsider. PMTU will never be 'perfect' as well, humans... >> It also pushes the burden of refragmentation towards the receiver of the >> packet, which suddenly becomes open to a fragmentation attack, which is >> likely not what they will want to see happening (enough crap gets send >> to those boxes already because someone is misbehaving on IRC). > > If somebody wants to DoS my CPE, they can just do that. No need to try a > fragmentation attack. The CPE is not the typical target, but the endpoint where your tunnel terminates likely is. And of course we are not talking about a single user setup here, or even 10 people using the same setup. Scale up to a few thousand. >> Remember that the minimum MTU for IPv6 is 1280 for a reason: very safe >> to use for tunneling and other constructs where one does not have a full >> Ethernet MTU. > > And then somebody starts a VPN that goes over a tunnel somewhere and we are back at > square one. Then they should not do that or let that VPN support the fragmentation. > Furthermore, unless you can somehow get all hosts on the internet to use a 1280 MTU, > your tunnel will cause PMTU problems. Forcing a singular MTU is not a proper solution. Your proposal forces everybody to 1500. And re-read your sentence above "then somebody starts a VPN that goes over a tunnel"... ;) > Way more than a decade after ethernet devices first started supporting jumbograms, > most ethernets are still at 1500. So the most sane way to avoid PMTU problems is > to run all links at a 1500 octet MTU. Exactly a major reason for not having a fixed MTU: you will fix the whole network to that MTU and it will never be able to change. Thus while your proposal is a reasonable solution it does not solve anything, it just avoids it (and with big penalties at that). >> Just sticking everywhere to 1500 is not a solution. Unless one wants to >> define the minimum MTU for IPv6 as 1500. It is still a minimum and there >> are speakers out there that do 9000 with ease, just not intra-AS, and >> intra-AS is where these kind of PTB and ICMP ratelimiting problems >> exist: in somebody elses network. > > The only practical MTU on the internet is currently 1500. Locally you can go > higher or lower. By fixing the MTU like you propose we will be stuck with an 1500 MTU forever. Lets not go there. Greets, Jeroen From nobody Fri Dec 5 06:20: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 ADDBB1A1B60 for ; Fri, 5 Dec 2014 06:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 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_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 IowySEiiYSUR for ; Fri, 5 Dec 2014 06:20:18 -0800 (PST) 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 0B2D61A1A9F for ; Fri, 5 Dec 2014 06:20:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 48AE438; Fri, 5 Dec 2014 15:19:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1417789190; bh=eT8rJKWvpUe3k84skp4PtTaG5knqVFPFH5Fr41Mnw2I=; b=s HL4dgZjACTaezy1AFo+ltQOPpsYxPLMwYHcrL6yvmTCBGbZc6h4588lYgfwUz3MS YX1NcHyGG6xPoMHBnxUkp6Lad52evhjFwkGlwdawRIvbTXI6UW7bNM5M1TG6eBn1 nkaldtdesZl0bKl36Xj7zsPtZnDwd1YLbIoZFhMyPM= 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 10026) with ESMTP id vBaxido5KXXL; Fri, 5 Dec 2014 15:19:50 +0100 (CET) Received: from [IPv6:2a00:8640:1::90c4:ab4b:40fb:1ced] (unknown [IPv6:2a00:8640:1:0:90c4:ab4b:40fb:1ced]) by mail.sintact.nl (Postfix) with ESMTPSA id C4C5336; Fri, 5 Dec 2014 15:19:50 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2058.2\)) From: Sander Steffann In-Reply-To: <20141205075203.54ed9ea4@echo.ms.redpill-linpro.com> Date: Fri, 5 Dec 2014 15:19:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141205075203.54ed9ea4@echo.ms.redpill-linpro.com> To: Tore Anderson X-Mailer: Apple Mail (2.2058.2) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HG4qm9fPhQTtMj0s4CXR48BwyCo Cc: v6ops@ietf.org Subject: Re: [v6ops] New Version Notification for draft-anderson-v6ops-siit-eam-01.txt 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, 05 Dec 2014 14:20:19 -0000 Hi, > In any case, I would like to have your "+1" on which approach you > prefer of these alternatives: >=20 > A) Remove all the normative RFC6145 protocol update language from > draft-anderson-siit-dc, taking this document off the standards > track, and have it describe the data centre use case only. Instead > contain the required protocol update in a separate document dedicated > to that purpose, i.e., draft-anderson-v6ops-siit-eam. +1 I'd like to see the protocol stuff in a separate -eam doc and leave the = application description in -dc. That way future work can easily = reference the -eam work even if its use case is outside of -dc. Cheers, Sander From nobody Fri Dec 5 06:42: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 EAEC91A0149 for ; Fri, 5 Dec 2014 06:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 5IcNUrr6dRRF for ; Fri, 5 Dec 2014 06:42:32 -0800 (PST) Received: from ITSNT447.iowa.uiowa.edu (itsnt447.iowa.uiowa.edu [128.255.67.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F036F1A01F2 for ; Fri, 5 Dec 2014 06:42:31 -0800 (PST) Received: from ITSNT440.iowa.uiowa.edu ([169.254.2.131]) by ITSNT447.iowa.uiowa.edu ([128.255.67.11]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 08:42:30 -0600 From: "Metzler, Dan J" To: Geoff Huston Thread-Topic: [v6ops] MTUs on the general Internet (Was: Report: Bar BoF on a 6to4 replacement) Thread-Index: AQHQD/8Y79eJsGuBsEm2+o2f2C1chZx/6JKggAC39QCAAGMIQA== Date: Fri, 5 Dec 2014 14:42:30 +0000 Message-ID: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DF42387@ITSNT440.iowa.uiowa.edu> References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DF401A2@ITSNT440.iowa.uiowa.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.255.6.15] 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/iwZb011-McbTwy8sI9Xxf4b4Sv0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MTUs on the general Internet (Was: Report: Bar BoF on a 6to4 replacement) 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, 05 Dec 2014 14:42:34 -0000 Hi Geoff, > -----Original Message----- > From: Geoff Huston [mailto:gih@apnic.net] > Sent: Thursday, December 4, 2014 7:51 PM > To: Metzler, Dan J > Cc: Jeroen Massar; v6ops@ietf.org > Subject: Re: [v6ops] MTUs on the general Internet (Was: Report: Bar BoF o= n a > 6to4 replacement) >=20 >=20 > > On 5 Dec 2014, at 8:00 am, Metzler, Dan J wrote= : > > > >> > >> In IPv6 the problem is at its worst in a situation where the large > >> packet sender is using a 1500 octet MTU and close to the sender is a > >> packet filter that discards IPv6 packet too big massages. If there is > >> some form of encapsulating tunnel on the path to the receiver and the > >> tunnel operates with an effective MTU of less than 1500 then its possi= ble to > encounter a wedged TCP session: > >> > >> the sender sends a 1500 octet packet > >> the tunnel ingress cannot accept the packet and passes back IPv6 > >> ICMP PTB message toward the sender > >> the packet filter discards the IPv6 ICMP PTB message > >> the sender times out and retransmits the 1500 octet > >> > >> rinse and repeat forever > > > > Wouldn't this be working as designed? > > As it stands now we can even probe for this by sending a purposely larg= e > packet, and monitor for the response or PTB reply. If it doesn't come ba= ck, > that network is broken. > > > > Is it really worth masking the problem? >=20 >=20 > The problem is here that there is potentially no single "network" that is > broken.=20 I respectfully disagree. :-) > At one point on the path from the sender to the receiver there is a > constrained MTU.=20 Yes there generally is an MTU constraint of some type. It's broken if belo= w 1280. I know of no requirement that MTU be below 1500, 4000, or even 900= 0. It must be above 1280 which will allow the ICMPv6 error messages to pas= s. > At one point on the path from the constrained MTU to the > sender (which is not necessarily the same path as the forward path) there= is an > ICMP filter. That's the one that is broken. >=20 > So who is "broken"? The tunnel ingress that is performing IP-over-IP and = needs > to down-adjust the MTU to factor in the additional header? Or the filter = rule > set that is saying that it is unprepared to admit ICMP packets from arbit= rary > sources? Its not necessarily a single point of "failure" here, but the in= teraction > of two different items of middleware, and they may not be located within = a > single locus of admin/operational control. The network that is filtering Packet Too Big is broken. The owner of the n= etwork should be pointed at RFC 4890 (Filtering Recommendations). There ar= e a number of error messages that Must not be dropped. (Packet Too Big is = one of them.) Perhaps this would be better stated in RFC 2463, or RFC 2460. In any case, don't we at some point just have to tell people, "hey your net= work is broken". Some ICMPv6 are required for proper functioning of IPv6. There will always be people who do things wrong. Some people mistakenly bl= ock port 80 to a web server, but we don't go recommending that the standard= http port move to something else. Even though IPv6 has been around for a = long time, many are not yet even thinking about it, or are in the early sta= ges. Consequently, people do dumb things; like block all ICMPv6 traffic be= cause what they really want to do is stop IPv4 style ping probes (echo). (= The problem is not MTU size, but inadequate knowledge.) >=20 >=20 > Geoff >=20 >=20 >=20 >=20 >=20 >=20 >=20 From nobody Fri Dec 5 06:45: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 6A9D51ACDD7 for ; Fri, 5 Dec 2014 06:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 KjcM0HxPB8ZJ for ; Fri, 5 Dec 2014 06:45:00 -0800 (PST) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD86F1ACDD2 for ; Fri, 5 Dec 2014 06:45:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sB5Ej0sm027973; Fri, 5 Dec 2014 06:45:00 -0800 Received: from XCH-BLV-106.nw.nos.boeing.com (xch-blv-106.nw.nos.boeing.com [130.247.25.122]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sB5Eioes027188 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 5 Dec 2014 06:44:51 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-BLV-106.nw.nos.boeing.com ([169.254.6.176]) with mapi id 14.03.0210.002; Fri, 5 Dec 2014 06:44:49 -0800 From: "Templin, Fred L" To: Philip Homburg , Iljitsch van Beijnum Thread-Topic: [v6ops] PMTUD forever, was: MTUs on the general Internet Thread-Index: AQHQEJoFezK6rAo+FEGROyfana4N7A== Date: Fri, 5 Dec 2014 14:44:49 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DAC0EB@XCH-BLV-504.nw.nos.boeing.com> References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> <54818F41.9090802@massar.ch> <100130B5-A9B3-4FB5-ABA4-35AFC5D62861@muada.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/flASfKcq9joo87imbL6RWAOt3KQ Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 14:45:02 -0000 Hi Philip, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Philip Homburg > Sent: Friday, December 05, 2014 4:44 AM > To: Iljitsch van Beijnum > Cc: v6ops@ietf.org WG > Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet >=20 > In your letter dated Fri, 5 Dec 2014 13:31:19 +0100 you wrote: > >On 05 Dec 2014, at 13:20, Philip Homburg = =3D > >wrote: > > > >>>> In general, tunnel endpoints are hosts. > > > >> My local tunnel endpoint is in the CPE. > > > >Ok, so which is it? >=20 > For the outer (IPv4) packet, the CPE is a host. For the inner (IPv6) pack= et, the > CPE is a router. >=20 > >> IPv6 hosts are connected over > >> ethernet. So those hosts will advertise an MSS based on a 1500 MTU. > > > >Yes. So here you need PMTUD (unless the tunnel supports 1500-byte inner > >packets). >=20 > So, make the tunnel support 1500 octet inner packets until PMTU is actual= ly fixed. Correct, but remember that 1500 is the minimum size all tunnels should supp= ort. Tunnels should not place any hard-coded limits on the maximum size, i.e., t= hey should not clamp the MTU. Thanks - Fred fred.l.templin@boeing.com > Of course, as a content provider you can just restrict the link MTU on yo= ur hosts > and have happy users. Essentially to avoid problems, you want to receive = packets > as big as possible and send packets that are smaller than commonly used p= aths. >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Dec 5 06:49: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 34F051A897F for ; Fri, 5 Dec 2014 06:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 NpjeBmLIZHn1 for ; Fri, 5 Dec 2014 06:49:37 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D5FA1A897E for ; Fri, 5 Dec 2014 06:49:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sB5Enbk9022895; Fri, 5 Dec 2014 06:49:37 -0800 Received: from XCH-BLV-402.nw.nos.boeing.com (xch-blv-402.nw.nos.boeing.com [130.247.25.31]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sB5EnPje022729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 5 Dec 2014 06:49:26 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-BLV-402.nw.nos.boeing.com ([169.254.2.91]) with mapi id 14.03.0210.002; Fri, 5 Dec 2014 06:49:25 -0800 From: "Templin, Fred L" To: Philip Homburg , Jeroen Massar Thread-Topic: [v6ops] PMTUD forever, was: MTUs on the general Internet Thread-Index: AQHQEJqpy0emG6ply0aHqzM79Db67A== Date: Fri, 5 Dec 2014 14:49:24 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DAC111@XCH-BLV-504.nw.nos.boeing.com> References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> <54818F41.9090802@massar.ch> <5481A1B0.3080804@massar.ch> 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/IqUqGPt3JG_9yoitAj837_rJZaI Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 14:49:39 -0000 Hi Philip, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Philip Homburg > Sent: Friday, December 05, 2014 5:32 AM > To: Jeroen Massar > Cc: v6ops@ietf.org WG > Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet >=20 > In your letter dated Fri, 05 Dec 2014 13:14:40 +0100 you wrote: > >On 2014-12-05 12:00, Philip Homburg wrote: > >> In case it wasn't clear, I meant fragmenting the outer (IPv4) packet, > >> not the inner (IPv6) packet. > > > >Not only tunnels have a lower MTU. Just adding an extension header > >somewhere and you already lower the payload size. >=20 > In the current internet, PMTU is quite broken. Not completely broken, but= enough > to be noticeable. Extension headers are also routinely filtered. >=20 > So if you don't want to much pain, you avoid PMTU and extension headers. >=20 > >Doing fragmentation means sending at least two packets, maybe one gets > >lost, what to do, resend, wait? Note that most tunneling protocols do > >not resend data (unless they run over TCP and then TCP handles it). >=20 > Locally, i.e. between my CPE and my tunnel endpoints the loss rate of IPv= 4 packets > in general is way lower than losses caused by PMTU discovery. >=20 > So this is good trade off. By the time PMTU discovery is essentially perf= ect > it may be time to reconsider. >=20 > >It also pushes the burden of refragmentation towards the receiver of the > >packet, which suddenly becomes open to a fragmentation attack, which is > >likely not what they will want to see happening (enough crap gets send > >to those boxes already because someone is misbehaving on IRC). >=20 > If somebody wants to DoS my CPE, they can just do that. No need to try a > fragmentation attack. >=20 > >Remember that the minimum MTU for IPv6 is 1280 for a reason: very safe > >to use for tunneling and other constructs where one does not have a full > >Ethernet MTU. >=20 > And then somebody starts a VPN that goes over a tunnel somewhere and we a= re back at > square one. >=20 > Furthermore, unless you can somehow get all hosts on the internet to use = a 1280 MTU, > your tunnel will cause PMTU problems. >=20 > Way more than a decade after ethernet devices first started supporting ju= mbograms, > most ethernets are still at 1500. So the most sane way to avoid PMTU prob= lems is > to run all links at a 1500 octet MTU. Right, but I would say a 1500 octet MTU *or larger*. Then in a BCP we say: "Hosts that send packets larger than 1500 bytes SHOULD use RFC4821." At the same time, let's do away with tunnel MTU clamping so we can get out of this jam we're in. Thanks - Fred fred.l.templin@boeing.com > >Just sticking everywhere to 1500 is not a solution. Unless one wants to > >define the minimum MTU for IPv6 as 1500. It is still a minimum and there > >are speakers out there that do 9000 with ease, just not intra-AS, and > >intra-AS is where these kind of PTB and ICMP ratelimiting problems > >exist: in somebody elses network. >=20 > The only practical MTU on the internet is currently 1500. Locally you can= go > higher or lower. >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Dec 5 06:59: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 933281ACEAF for ; Fri, 5 Dec 2014 06:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 ehiP2QqIUVIc for ; Fri, 5 Dec 2014 06:59:19 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C20E1ACEA6 for ; Fri, 5 Dec 2014 06:59:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sB5ExJ1U007225; Fri, 5 Dec 2014 06:59:19 -0800 Received: from XCH-PHX-312.sw.nos.boeing.com (xch-phx-312.sw.nos.boeing.com [130.247.25.173]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sB5Ex9T4006631 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 5 Dec 2014 06:59:10 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-PHX-312.sw.nos.boeing.com ([169.254.12.151]) with mapi id 14.03.0210.002; Fri, 5 Dec 2014 06:59:09 -0800 From: "Templin, Fred L" To: Jeroen Massar , Philip Homburg Thread-Topic: [v6ops] PMTUD forever, was: MTUs on the general Internet Thread-Index: AQHQEJwFpAeu1cDlMEapgQ1gXobqjg== Date: Fri, 5 Dec 2014 14:59:09 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DAC16A@XCH-BLV-504.nw.nos.boeing.com> References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> <54818F41.9090802@massar.ch> <5481A1B0.3080804@massar.ch> <5481B5C8.6030501@massar.ch> In-Reply-To: <5481B5C8.6030501@massar.ch> 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/FcJh-K-BE2YFoEvcPrU1hL-Ndv4 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 14:59:21 -0000 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Jeroen Massar > Sent: Friday, December 05, 2014 5:40 AM > To: Philip Homburg > Cc: v6ops@ietf.org WG > Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet >=20 >=20 > Please doc this 'frag on the layer below' idea with the pros and cons it > has, would be a good informational document; but likely that will see > little global/large deployment due to the cons. You are misunderstaing; we are talking about a little bit of fragmentation that should be turned off as soon as possible. That will happen as more and more links set MTUs larger than 1500. > On 2014-12-05 14:32, Philip Homburg wrote: > > In your letter dated Fri, 05 Dec 2014 13:14:40 +0100 you wrote: > >> On 2014-12-05 12:00, Philip Homburg wrote: > >>> In case it wasn't clear, I meant fragmenting the outer (IPv4) packet, > >>> not the inner (IPv6) packet. > >> > >> Not only tunnels have a lower MTU. Just adding an extension header > >> somewhere and you already lower the payload size. > > > > In the current internet, PMTU is quite broken. Not completely broken, b= ut enough > > to be noticeable. Extension headers are also routinely filtered. > > > > So if you don't want to much pain, you avoid PMTU and extension headers= . >=20 > I've been using PMTU successfuly for over 15 years. I'm surprised no one has mentioned this yet, but any node on the Internet can send a forged PTB message; it doesn't even need to spoof the source address. Fernando Gont raises this concern in his "atomic fragments" doc. > Only recently there where two events where a middle box was broken as > they do not comply to the IPv6 specification (they ignore ICMPv6). >=20 > All other instances of PMTU issues are easily classified as either: > - misconfigurations > - rate limitting >=20 > Yes. These are problematic. Not much one can do about as these involve > people and physical limits. >=20 > >> Doing fragmentation means sending at least two packets, maybe one gets > >> lost, what to do, resend, wait? Note that most tunneling protocols do > >> not resend data (unless they run over TCP and then TCP handles it). > > > > Locally, i.e. between my CPE and my tunnel endpoints the loss rate of I= Pv4 packets > > in general is way lower than losses caused by PMTU discovery. > > > > So this is good trade off. By the time PMTU discovery is essentially pe= rfect > > it may be time to reconsider. >=20 > PMTU will never be 'perfect' as well, humans... >=20 > >> It also pushes the burden of refragmentation towards the receiver of t= he > >> packet, which suddenly becomes open to a fragmentation attack, which i= s > >> likely not what they will want to see happening (enough crap gets send > >> to those boxes already because someone is misbehaving on IRC). > > > > If somebody wants to DoS my CPE, they can just do that. No need to try = a > > fragmentation attack. >=20 > The CPE is not the typical target, but the endpoint where your tunnel > terminates likely is. >=20 > And of course we are not talking about a single user setup here, or even > 10 people using the same setup. Scale up to a few thousand. >=20 > >> Remember that the minimum MTU for IPv6 is 1280 for a reason: very safe > >> to use for tunneling and other constructs where one does not have a fu= ll > >> Ethernet MTU. > > > > And then somebody starts a VPN that goes over a tunnel somewhere and we= are back at > > square one. >=20 > Then they should not do that or let that VPN support the fragmentation. >=20 > > Furthermore, unless you can somehow get all hosts on the internet to us= e a 1280 MTU, > > your tunnel will cause PMTU problems. >=20 > Forcing a singular MTU is not a proper solution. Your proposal forces > everybody to 1500. No, the idea is to make sure *all* 1500s get through while at the same time allowing larger packets through as long as they can make it without any fragmentation. No more tunnel MTU clamping. > And re-read your sentence above "then somebody starts a VPN that goes > over a tunnel"... ;) Tunnels within tunnels, yes. That is why the solution needs to work recursi= vely. > > Way more than a decade after ethernet devices first started supporting = jumbograms, > > most ethernets are still at 1500. So the most sane way to avoid PMTU pr= oblems is > > to run all links at a 1500 octet MTU. >=20 > Exactly a major reason for not having a fixed MTU: you will fix the > whole network to that MTU and it will never be able to change. Correct - no fixed upper bound. But, a 1500 lower bound. > Thus while your proposal is a reasonable solution it does not solve > anything, it just avoids it (and with big penalties at that). >=20 > >> Just sticking everywhere to 1500 is not a solution. Unless one wants t= o > >> define the minimum MTU for IPv6 as 1500. It is still a minimum and the= re > >> are speakers out there that do 9000 with ease, just not intra-AS, and > >> intra-AS is where these kind of PTB and ICMP ratelimiting problems > >> exist: in somebody elses network. > > > > The only practical MTU on the internet is currently 1500. Locally you c= an go > > higher or lower. >=20 > By fixing the MTU like you propose we will be stuck with an 1500 MTU > forever. Lets not go there. No more tunnel MTU clamping, as above. 1500 is only the *minimum*. Thanks - Fred fred.l.templin@boeing.com > Greets, > Jeroen >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Dec 5 07:32: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 DF2661ACEB8 for ; Fri, 5 Dec 2014 07:32:24 -0800 (PST) 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 UYdtc04dUHRZ for ; Fri, 5 Dec 2014 07:32:23 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBD01A899D for ; Fri, 5 Dec 2014 07:32:22 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1Xwuri-0000CCC; Fri, 5 Dec 2014 16:32:18 +0100 Message-Id: To: "Templin, Fred L" From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> <54818F41.9090802@massar.ch> <5481A1B0.3080804@massar.ch> <2134F8430051B64F815C691A62D9831832DAC111@XCH-BLV-504.nw.nos.boeing.com> In-reply-to: Your message of "Fri, 5 Dec 2014 14:49:24 +0000 ." <2134F8430051B64F815C691A62D9831832DAC111@XCH-BLV-504.nw.nos.boeing.com> Date: Fri, 05 Dec 2014 16:32:14 +0100 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sjjypv0xeknHMnLsVwsIEVm9mUo Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 15:32:25 -0000 In your letter dated Fri, 5 Dec 2014 14:49:24 +0000 you wrote: >Right, but I would say a 1500 octet MTU *or larger*. Then in a BCP we say: > > "Hosts that send packets larger than 1500 bytes SHOULD use RFC4821." > >At the same time, let's do away with tunnel MTU clamping so we can get out of this jam we're in. I think RFC 4821 tries to be too general. Implementing some kind of PMTU blackhole detection is relatively easy for TCP. But the way forward is to have clear RFC that details how exactly it should be done for TCP. Not a relatively vague description of all possibilities. One important choice that needs to be made is whether to deprecate packet too big ICMPs or not. Going beyond TCP, I don't think these techniques would work at all for a root DNS server (or any other big DNS service). But maybe it is sufficient to say that any protocol that cannot reliably do PMTU blackhole detection should assume a link MTU of 1280. From nobody Fri Dec 5 07: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 AC9981ACEDA for ; Fri, 5 Dec 2014 07:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 XFLl2CmwQTXD for ; Fri, 5 Dec 2014 07:43:24 -0800 (PST) Received: from ITSNT447.iowa.uiowa.edu (itsnt447.iowa.uiowa.edu [128.255.67.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14981ACECC for ; Fri, 5 Dec 2014 07:43:22 -0800 (PST) Received: from ITSNT440.iowa.uiowa.edu ([169.254.2.131]) by ITSNT447.iowa.uiowa.edu ([128.255.67.11]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 09:43:21 -0600 From: "Metzler, Dan J" To: "Templin, Fred L" , Jeroen Massar , Philip Homburg Thread-Topic: [v6ops] PMTUD forever, was: MTUs on the general Internet Thread-Index: AQHQEG8rUe5pf4ePi0iUlr5M0I0WpZyBKckA//+kfumAAGmMgP//n7UDgAB2RQD//7ExCQAM2HMAAALAFIAACzBOkA== Date: Fri, 5 Dec 2014 15:43:20 +0000 Message-ID: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DF425F5@ITSNT440.iowa.uiowa.edu> References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> <54818F41.9090802@massar.ch> <5481A1B0.3080804@massar.ch> <5481B5C8.6030501@massar.ch> <2134F8430051B64F815C691A62D9831832DAC16A@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832DAC16A@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.255.6.15] 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/_VCYfKypSG7-8CyrSPmHJhFhLrA Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 15:43:27 -0000 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Friday, December 5, 2014 8:59 AM > To: Jeroen Massar; Philip Homburg > Cc: v6ops@ietf.org WG > Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet >=20 >=20 >=20 > > -----Original Message----- > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Jeroen Massar > > Sent: Friday, December 05, 2014 5:40 AM > > To: Philip Homburg > > Cc: v6ops@ietf.org WG > > Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet > > > > > > Please doc this 'frag on the layer below' idea with the pros and cons > > it has, would be a good informational document; but likely that will > > see little global/large deployment due to the cons. >=20 > You are misunderstaing; we are talking about a little bit of fragmentatio= n that > should be turned off as soon as possible. That will happen as more and mo= re > links set MTUs larger than 1500. >=20 > > On 2014-12-05 14:32, Philip Homburg wrote: > > > In your letter dated Fri, 05 Dec 2014 13:14:40 +0100 you wrote: > > >> On 2014-12-05 12:00, Philip Homburg wrote: > > >>> In case it wasn't clear, I meant fragmenting the outer (IPv4) > > >>> packet, not the inner (IPv6) packet. > > >> > > >> Not only tunnels have a lower MTU. Just adding an extension header > > >> somewhere and you already lower the payload size. > > > > > > In the current internet, PMTU is quite broken. Not completely > > > broken, but enough to be noticeable. Extension headers are also routi= nely > filtered. > > > > > > So if you don't want to much pain, you avoid PMTU and extension heade= rs. > > > > I've been using PMTU successfuly for over 15 years. >=20 > I'm surprised no one has mentioned this yet, but any node on the Internet= can > send a forged PTB message; it doesn't even need to spoof the source addre= ss. > Fernando Gont raises this concern in his "atomic fragments" doc. So the point being that somebody might be able to spoof you down to 1280, i= f the timing is right, and they target the right address? From nobody Fri Dec 5 07:51: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 A6CEA1ACEB9 for ; Fri, 5 Dec 2014 07:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 HJnUFYHNuCna for ; Fri, 5 Dec 2014 07:51:34 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCC991ACEC2 for ; Fri, 5 Dec 2014 07:51:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1276; q=dns/txt; s=iport; t=1417794693; x=1419004293; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2eIu7n39lkFVgw0KK4LGuJumppLQ8xjpWZzc+nVAuY8=; b=juF0f6adEM5SgI2Tg49Zc54FbxCqMgvbfgQILA+7VOYBAcWD6JWiTwoE ECxZHTmQs5bT73yLLjSLRR1lNQstF5ZUMNPAOQIy+mkh0f7hNjpa6Xw28 fC5FUUneR1+HJblsWF+nOyjgjgjj2xPB25THQTeWa16n0izyCkhGTMbk7 0=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAODTgVStJA2B/2dsb2JhbABZgwaBKgTMXwKBHhYBAQEBAX2EAwEBAwF5BQsCAQhGMiUCBA4FDgaIHgnXGwEBAQEBAQEBAQEBAQEBAQEBAQEBAReQTweDIYEVAQSPRoFvgTWGdZM/g29vgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="asc'?scan'208";a="374762575" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP; 05 Dec 2014 15:51:33 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sB5FpX8H014831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Dec 2014 15:51:33 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 09:51:33 -0600 From: "Fred Baker (fred)" To: Iljitsch van Beijnum Thread-Topic: [v6ops] PMTUD forever, was: MTUs on the general Internet Thread-Index: AQHQEKNWLqZy7VBgOEGe83k4xuXEWw== Date: Fri, 5 Dec 2014 15:51:31 +0000 Message-ID: References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.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.121] Content-Type: multipart/signed; boundary="Apple-Mail=_1E877D32-5F44-49DC-A36D-8BBA300C72D8"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wuDr-YYSAQKhC8rEttpLoMrF1W4 Cc: "v6ops@ietf.org WG" , Tore Anderson Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 15:51:35 -0000 --Apple-Mail=_1E877D32-5F44-49DC-A36D-8BBA300C72D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 5, 2014, at 1:37 AM, Iljitsch van Beijnum = wrote: > I don't see the possibility of this scenario as a reason for the IETF = or the operator community to start implementing ugly hacks.=20 For the record, I live behind an IPsec tunnel, and it solves the problem = another way. Since it can see traffic in the clear (it is adding the = IPsec ESP), it can see the TCP MSS option, and set it to a smaller = value. That=92s usually 1400, not 1280, but it could be 1280. I might be tempted to refer to that as an "ugly hack". It does = predictably work. --Apple-Mail=_1E877D32-5F44-49DC-A36D-8BBA300C72D8 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 iD8DBQFUgdRobjEdbHIsm0MRAh6nAKDdQWWEh8UKLR/xP2RLByzOb0WsbQCgnHc1 WU7C30iJFXfi4GNuYSK8/xo= =bNYG -----END PGP SIGNATURE----- --Apple-Mail=_1E877D32-5F44-49DC-A36D-8BBA300C72D8-- From nobody Fri Dec 5 10:02: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 E8B171A6EE2 for ; Fri, 5 Dec 2014 10:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 J3tMN5RkLGUo for ; Fri, 5 Dec 2014 10:01:59 -0800 (PST) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF5B1A0BE8 for ; Fri, 5 Dec 2014 10:01:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sB5I1wvb019070; Fri, 5 Dec 2014 10:01:58 -0800 Received: from XCH-PHX-413.sw.nos.boeing.com (xch-phx-413.sw.nos.boeing.com [10.57.37.45]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sB5I1uPB019051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 5 Dec 2014 10:01:57 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-PHX-413.sw.nos.boeing.com ([169.254.13.86]) with mapi id 14.03.0210.002; Fri, 5 Dec 2014 10:01:56 -0800 From: "Templin, Fred L" To: Philip Homburg Thread-Topic: [v6ops] PMTUD forever, was: MTUs on the general Internet Thread-Index: AQHQELWOlmmKhestj0W63tBNbe3wWg== Date: Fri, 5 Dec 2014 18:01:56 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DAC736@XCH-BLV-504.nw.nos.boeing.com> References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> <54818F41.9090802@massar.ch> <5481A1B0.3080804@massar.ch> <2134F8430051B64F815C691A62D9831832DAC111@XCH-BLV-504.nw.nos.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/L_pc-3gv9sawkpfbeml7Ct19-i4 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 18:02:01 -0000 Hi Philip, > -----Original Message----- > From: pch-bBB316E3E@u-1.phicoh.com [mailto:pch-bBB316E3E@u-1.phicoh.com] = On Behalf Of Philip Homburg > Sent: Friday, December 05, 2014 7:32 AM > To: Templin, Fred L > Cc: v6ops@ietf.org WG > Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet >=20 > In your letter dated Fri, 5 Dec 2014 14:49:24 +0000 you wrote: > >Right, but I would say a 1500 octet MTU *or larger*. Then in a BCP we sa= y: > > > > "Hosts that send packets larger than 1500 bytes SHOULD use RFC4821." > > > >At the same time, let's do away with tunnel MTU clamping so we can get > out of this jam we're in. >=20 > I think RFC 4821 tries to be too general. Implementing some kind of PMTU > blackhole detection is relatively easy for TCP. But the way forward is to= have > clear RFC that details how exactly it should be done for TCP. Not a relat= ively > vague description of all possibilities. One important choice that needs t= o be made > is whether to deprecate packet too big ICMPs or not. Indeed. IMHO, PTBs are nice to have when you can get them and *if* they can somehow be authenticated as originating at an on-path router. Otherwise, th= e best course of action may be to ignore them. > Going beyond TCP, I don't think these techniques would work at all for a = root DNS > server (or any other big DNS service). OK. > But maybe it is sufficient to say that any protocol that cannot reliably = do PMTU > blackhole detection should assume a link MTU of 1280. That is a slightly different statement than the one I have been contemplati= ng, which is "hosts that send packets larger than 1500 bytes MUST use RFC4821 (or something else very much like it)". That said, most hosts expect 1500 t= o work but the only real guarantee of course is 1280. Thanks - Fred fred.l.templin@boeing.com From nobody Fri Dec 5 10: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 3102F1AD4B1 for ; Fri, 5 Dec 2014 10:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 gqpv-XB2hmTu for ; Fri, 5 Dec 2014 10:05:47 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 314201ACEF2 for ; Fri, 5 Dec 2014 10:05:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sB5I5kkp031272; Fri, 5 Dec 2014 10:05:46 -0800 Received: from XCH-BLV-207.nw.nos.boeing.com (xch-blv-207.nw.nos.boeing.com [10.57.37.63]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sB5I5do3030884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 5 Dec 2014 10:05:40 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-BLV-207.nw.nos.boeing.com ([169.254.7.73]) with mapi id 14.03.0210.002; Fri, 5 Dec 2014 10:05:39 -0800 From: "Templin, Fred L" To: "Metzler, Dan J" , Jeroen Massar , Philip Homburg Thread-Topic: [v6ops] PMTUD forever, was: MTUs on the general Internet Thread-Index: AQHQEJwFpAeu1cDlMEapgQ1gXobqjpyBqUcA//+grzA= Date: Fri, 5 Dec 2014 18:05:39 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DAC77A@XCH-BLV-504.nw.nos.boeing.com> References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> <54818F41.9090802@massar.ch> <5481A1B0.3080804@massar.ch> <5481B5C8.6030501@massar.ch> <2134F8430051B64F815C691A62D9831832DAC16A@XCH-BLV-504.nw.nos.boeing.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DF425F5@ITSNT440.iowa.uiowa.edu> In-Reply-To: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DF425F5@ITSNT440.iowa.uiowa.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/s9gXjBWkGZUMLuLyZ6mAt1xZS0E Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 18:05:50 -0000 > > I'm surprised no one has mentioned this yet, but any node on the Intern= et can > > send a forged PTB message; it doesn't even need to spoof the source add= ress. > > Fernando Gont raises this concern in his "atomic fragments" doc. >=20 > So the point being that somebody might be able to spoof you down to 1280,= if the timing is right, and they target the right address? Yes, but Fernando took it one step further and said that a bogus PTB that r= eports a size smaller than 1280 might cause the recipient to start including a Fra= gment Header in future IPv6 packets, where they might be clobbered if the network is configured to drop fragments. Thanks - Fred fred.l.templin@boeing.com From nobody Fri Dec 5 10:18: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 36BD81A1EFC for ; Fri, 5 Dec 2014 10:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 e_3iWsm9HTWp for ; Fri, 5 Dec 2014 10:17:56 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 567C81ACEC4 for ; Fri, 5 Dec 2014 10:17:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6537; q=dns/txt; s=iport; t=1417803476; x=1419013076; h=from:to:subject:date:message-id:mime-version; bh=cxzyP2xNRq6s4XEQ6q3FseG1DuGPXHADTzQ0SfaXEpQ=; b=eJrG5QqaA2OD4Vlr9A0R2GlSP1HJxq0sWUPLjgJC4ZwWd8g7r/kDGsok vwMX+9shMTFxZmbzdeH5DLCGA2r9eTk3Bm57s1JRvX9Z639//KPgRvWht 9wH90X6h2Cfw8N2L3PgFKvnT0xbiIynujQ1jyPZImuLsHnUY0LnuYwfPT A=; X-Files: v6ops-wg-drafts.txt, signature.asc : 1594, 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAKT2gVStJA2G/2dsb2JhbABZgwZSWATGT4cxFgEBAQEBfYQJDFkmAYEAFBMEEw6ILQ2wMqYlAQEBBwEBAQEBHZN3gRUFj0aBb4E1WoYbgSI0gl6LKYNig29vgQMiIH4BAQE X-IronPort-AV: E=Sophos;i="5.07,523,1413244800"; d="asc'?txt'?scan'208";a="377990797" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP; 05 Dec 2014 18:17:39 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sB5IHdah029768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 5 Dec 2014 18:17:39 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 12:17:39 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: Working Group Administrivia Thread-Index: AQHQELfApl0OmdTiikqs9ZO27DRlMg== Date: Fri, 5 Dec 2014 18:17:38 +0000 Message-ID: <08DA982D-6605-434B-B815-C69B8A97FA4C@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.121] Content-Type: multipart/signed; boundary="Apple-Mail=_0DC2493D-10A2-49F8-BDC1-280521245584"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ygTxoVPDEb7C5ktdbcbrTevPO9A Subject: [v6ops] Working Group 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: Fri, 05 Dec 2014 18:17:59 -0000 --Apple-Mail=_0DC2493D-10A2-49F8-BDC1-280521245584 Content-Type: multipart/mixed; boundary="Apple-Mail=_621326FC-D285-4446-A9DC-8C46D06B9AF0" --Apple-Mail=_621326FC-D285-4446-A9DC-8C46D06B9AF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Joel, Lee, and I spoke this morning about the status of the working = group and various drafts in it. I=92d like to gauge working group = consensus on the status of a number of working group drafts that have = either expired or otherwise should no longer be considered working group = drafts. Your opinions, pro or con (such as =93I=92m fine with all that = but think we should still be considering draft-whatever=94), please: We think that the following can be safely set aside, by having the = secretariat record (and show in the data tracker) that they are no = longer working group drafts. They have expired, and are not currently = being pursued: 2003-01-13 draft-ietf-v6ops-ipv4survey = http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv4survey/ 2003-02-14 draft-ietf-v6ops-ipv4survey-gen = http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv4survey-gen/ 2004-07-20 draft-ietf-v6ops-v6onbydefault = http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6onbydefault/ 2007-02-27 draft-ietf-v6ops-routing-guidelines = http://datatracker.ietf.org/doc/draft-ietf-v6ops-routing-guidelines/ 2007-03-28 draft-ietf-v6ops-campus-transition = http://datatracker.ietf.org/doc/draft-ietf-v6ops-campus-transition/ 2008-05-13 draft-ietf-v6ops-nat64-pb-statement-req = http://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-pb-statement-req/ 2011-07-26 draft-ietf-v6ops-v4v6tran-framework = http://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6tran-framework/ 2013-08-14 draft-ietf-v6ops-monitor-ds-ipv6 = http://datatracker.ietf.org/doc/draft-ietf-v6ops-monitor-ds-ipv6/ We think that draft-ietf-v6ops-balanced-ipv6-security, in its current = state, is a deployment report, primarily from Swisscom. While the = working group expressed interest in guidance on firewall configuration, = this isn=92t it. We think it should no longer be a working group draft, = and invite the authors to submit it to the independent stream as a = deployment report (-- or individual submissions to the IETF, = draft--. It would be good if the authors would send a = note to internet-drafts@ietf.org indicating that the old draft name were = replaced by the new draft name, so that the revision history is tracked = appropriately. Opinions? --Apple-Mail=_621326FC-D285-4446-A9DC-8C46D06B9AF0 Content-Disposition: attachment; filename=v6ops-wg-drafts.txt Content-Type: text/plain; name="v6ops-wg-drafts.txt" Content-Transfer-Encoding: quoted-printable 2003-01-13 draft-ietf-v6ops-ipv4survey = http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv4survey/ 2003-02-14 draft-ietf-v6ops-ipv4survey-gen = http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv4survey-gen/ 2004-07-20 draft-ietf-v6ops-v6onbydefault = http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6onbydefault/ 2007-02-27 draft-ietf-v6ops-routing-guidelines = http://datatracker.ietf.org/doc/draft-ietf-v6ops-routing-guidelines/ 2007-03-28 draft-ietf-v6ops-campus-transition = http://datatracker.ietf.org/doc/draft-ietf-v6ops-campus-transition/ 2008-05-13 draft-ietf-v6ops-nat64-pb-statement-req = http://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-pb-statement-req/ 2011-07-26 draft-ietf-v6ops-v4v6tran-framework = http://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6tran-framework/ 2013-08-14 draft-ietf-v6ops-monitor-ds-ipv6 = http://datatracker.ietf.org/doc/draft-ietf-v6ops-monitor-ds-ipv6/ 2013-12-06 draft-ietf-v6ops-balanced-ipv6-security = http://datatracker.ietf.org/doc/draft-ietf-v6ops-balanced-ipv6-security/ 2014-09-18 draft-ietf-v6ops-design-choices = http://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ 2014-09-22 draft-ietf-v6ops-mobile-device-profile = http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ 2014-10-27 draft-ietf-v6ops-dhcpv6-slaac-problem = http://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ 2014-10-27 draft-ietf-v6ops-ula-usage-recommendations = http://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommendations= / --Apple-Mail=_621326FC-D285-4446-A9DC-8C46D06B9AF0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_621326FC-D285-4446-A9DC-8C46D06B9AF0-- --Apple-Mail=_0DC2493D-10A2-49F8-BDC1-280521245584 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 iD8DBQFUgfaobjEdbHIsm0MRAnuRAJ0cgbp17pFt/fXdlxyB5gchn/hcAACgstH9 0y65ABorPASDF3n8/QlgbVw= =i8nH -----END PGP SIGNATURE----- --Apple-Mail=_0DC2493D-10A2-49F8-BDC1-280521245584-- From nobody Fri Dec 5 10:55: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 811391AD56E for ; Fri, 5 Dec 2014 10:55:14 -0800 (PST) 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 Wb9NvKzL-zPF for ; Fri, 5 Dec 2014 10:55:10 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id BBA271AD55C for ; Fri, 5 Dec 2014 10:55:01 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1Xwy1p-0000BfC; Fri, 5 Dec 2014 19:54:57 +0100 Message-Id: To: "Templin, Fred L" From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> <54818F41.9090802@massar.ch> <5481A1B0.3080804@massar.ch> <2134F8430051B64F815C691A62D9831832DAC111@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832DAC736@XCH-BLV-504.nw.nos.boeing.com> In-reply-to: Your message of "Fri, 5 Dec 2014 18:01:56 +0000 ." <2134F8430051B64F815C691A62D9831832DAC736@XCH-BLV-504.nw.nos.boeing.com> Date: Fri, 05 Dec 2014 19:54:52 +0100 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sjkooasug0CMmKD4vE0XqoVn4vo Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 18:55:15 -0000 In your letter dated Fri, 5 Dec 2014 18:01:56 +0000 you wrote: >> But maybe it is sufficient to say that any protocol that cannot reliably >do PMTU >> blackhole detection should assume a link MTU of 1280. > >That is a slightly different statement than the one I have been contemplati= >ng, >which is "hosts that send packets larger than 1500 bytes MUST use RFC4821 >(or something else very much like it)". That said, most hosts expect 1500 t= >o >work but the only real guarantee of course is 1280. There are many links with an MTU lower than 1500. So on the current Internet, any protocol that cannot do PMTU blackhole detection should default to 1280. (This of course results in a catch 22 for most tunnels) Implementations that do support PMTU blackhole detection can start at the interface MTU, though for TCP you would also limit yourself to the MSS. From nobody Fri Dec 5 11:10: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 3C6D41AD585 for ; Fri, 5 Dec 2014 11:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 4TOMZwovh223 for ; Fri, 5 Dec 2014 11:09:53 -0800 (PST) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16CAA1AD581 for ; Fri, 5 Dec 2014 11:09:53 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id r10so1203746pdi.41 for ; Fri, 05 Dec 2014 11:09:52 -0800 (PST) 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=7iOZ9Rw5cGQwwl4bxQcSiioDdhR634Un3LOqn1a4V3s=; b=ZA3c8CauhBeE7U91NHnAoIisykw6hfzmqh629pAOKduyJ5pysxZcX4+w+w9fNNg90H 1x1atZ62DgIKkyNFWTGix4pDh6C3Q1CUEwDENDxeh59dmOx2wODpHPj7iAZ0abUyVILQ dTYXGi7lInv6HwuWCVea3pdn3myItmr75knDzVSNtkqWqDpY1mo729sYuaPGNJKrZLJE 5N1a+keyN6xBOfkw8qFrB6pzfoMwoVEYKc4yaxnSW4fq0UuEoKtqZvvpRbHkXMeY6pcf ETAl5GXxJ4ErlobX663GHtp45q0ycchEa5lSS95sUT1c3XFQ5fFNawUrGsDqumpzZW6I N7Bw== X-Received: by 10.66.66.196 with SMTP id h4mr30396170pat.127.1417806592313; Fri, 05 Dec 2014 11:09:52 -0800 (PST) Received: from [192.168.178.26] (66.231.69.111.dynamic.snap.net.nz. [111.69.231.66]) by mx.google.com with ESMTPSA id nb5sm29594896pbc.25.2014.12.05.11.09.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Dec 2014 11:09:51 -0800 (PST) Message-ID: <54820304.9020201@gmail.com> Date: Sat, 06 Dec 2014 08:09:56 +1300 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: <20141205075203.54ed9ea4@echo.ms.redpill-linpro.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NXNUGPQT60-Z9FII4wuIv2_R_5I Cc: v6ops@ietf.org, Tore Anderson Subject: Re: [v6ops] New Version Notification for draft-anderson-v6ops-siit-eam-01.txt 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, 05 Dec 2014 19:09:55 -0000 On 06/12/2014 03:19, Sander Steffann wrote: > Hi, > >> In any case, I would like to have your "+1" on which approach you >> prefer of these alternatives: >> >> A) Remove all the normative RFC6145 protocol update language from >> draft-anderson-siit-dc, taking this document off the standards >> track, and have it describe the data centre use case only. Instead >> contain the required protocol update in a separate document dedicated >> to that purpose, i.e., draft-anderson-v6ops-siit-eam. > > +1 > > I'd like to see the protocol stuff in a separate -eam doc and leave the application description in -dc. That way future work can easily reference the -eam work even if its use case is outside of -dc. Agreed. Brian From nobody Fri Dec 5 11: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 EBB511AD603 for ; Fri, 5 Dec 2014 11:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 8eWClIzH9CDO for ; Fri, 5 Dec 2014 11:21:52 -0800 (PST) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88D291AD5DD for ; Fri, 5 Dec 2014 11:21:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sB5JLqSx032408; Fri, 5 Dec 2014 11:21:52 -0800 Received: from XCH-BLV-103.nw.nos.boeing.com (xch-blv-103.nw.nos.boeing.com [130.247.25.118]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sB5JLkjx032392 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 5 Dec 2014 11:21:48 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-BLV-103.nw.nos.boeing.com ([169.254.3.28]) with mapi id 14.03.0210.002; Fri, 5 Dec 2014 11:21:46 -0800 From: "Templin, Fred L" To: Philip Homburg Thread-Topic: [v6ops] PMTUD forever, was: MTUs on the general Internet Thread-Index: AQHQELWOlmmKhestj0W63tBNbe3wWpyBWJM/gAAFfOA= Date: Fri, 5 Dec 2014 19:21:46 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DAC8FB@XCH-BLV-504.nw.nos.boeing.com> References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> <54818F41.9090802@massar.ch> <5481A1B0.3080804@massar.ch> <2134F8430051B64F815C691A62D9831832DAC111@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832DAC736@XCH-BLV-504.nw.nos.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/H_XKFcEkpslKl_VVe-Z7IXJG468 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 05 Dec 2014 19:21:55 -0000 Hi Philip, > -----Original Message----- > From: pch-bBB316E3E@u-1.phicoh.com [mailto:pch-bBB316E3E@u-1.phicoh.com] = On Behalf Of Philip Homburg > Sent: Friday, December 05, 2014 10:55 AM > To: Templin, Fred L > Cc: v6ops@ietf.org WG > Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet >=20 > In your letter dated Fri, 5 Dec 2014 18:01:56 +0000 you wrote: > >> But maybe it is sufficient to say that any protocol that cannot reliab= ly > >do PMTU > >> blackhole detection should assume a link MTU of 1280. > > > >That is a slightly different statement than the one I have been contempl= ati=3D > >ng, > >which is "hosts that send packets larger than 1500 bytes MUST use RFC482= 1 > >(or something else very much like it)". That said, most hosts expect 150= 0 t=3D > >o > >work but the only real guarantee of course is 1280. >=20 > There are many links with an MTU lower than 1500. Yes, I am aware of that. > So on the current Internet, > any protocol that cannot do PMTU blackhole detection should default to 12= 80. Regardless of what they should do, many try for 1500. > (This of course results in a catch 22 for most tunnels) Why catch 22? Tunnels should simply do what they need to do to get 1500s through and should not clamp the MTU so that even larger packets can be admitted. Thanks - Fred fred.l.templin@boeing.com > Implementations that do support PMTU blackhole detection can start at the= interface > MTU, though for TCP you would also limit yourself to the MSS. From nobody Fri Dec 5 11: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 7CA281AD640 for ; Fri, 5 Dec 2014 11:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 0-hYc6RZebXn for ; Fri, 5 Dec 2014 11:37:20 -0800 (PST) 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 0152B1A002A for ; Fri, 5 Dec 2014 11:37:20 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id ey11so1268564pad.38 for ; Fri, 05 Dec 2014 11:37:19 -0800 (PST) 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=m87XAhnLYLAcB+RAomAmyEOzsRQkOQBssQ809MU5lPA=; b=pCRkTxlFCAynwSJtDZZT5YvCvUpkouvsBFcW/xmASm+qf5fB6u2rzTCsx+MEWVUbCn gfI3dr0EvLjYKUodwCmc8+D9y5hlNdM18pUELeBr9qHQOvu8XvbjhuSlY/icZdWjrwcL GxBLlai6GrqqCX6ly/4UM8VMBKlzhfyNBNLvzfHF695ADUKxrZBzzWaL7ZkyVeXkx7Df BovxPClDRIcyWYEZlCgM4NuwZCdoPmw9+5oUMLtS1uEbFdKNO05TMIY8u3onwcsim0J8 psN4lErHWJICCDgLWNXe0XgsOOUGm97GNP8iOowJOetBVVVjvpZXSnOuIhVSadxG5m8d /0nA== X-Received: by 10.70.47.37 with SMTP id a5mr31364660pdn.93.1417808239241; Fri, 05 Dec 2014 11:37:19 -0800 (PST) Received: from [192.168.178.26] (66.231.69.111.dynamic.snap.net.nz. [111.69.231.66]) by mx.google.com with ESMTPSA id ws4sm25988928pbc.53.2014.12.05.11.37.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Dec 2014 11:37:18 -0800 (PST) Message-ID: <54820977.4060904@gmail.com> Date: Sat, 06 Dec 2014 08:37:27 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <08DA982D-6605-434B-B815-C69B8A97FA4C@cisco.com> In-Reply-To: <08DA982D-6605-434B-B815-C69B8A97FA4C@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7jlxqa95sN4soamklZiQJwpqVQs Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Working Group 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: Fri, 05 Dec 2014 19:37:23 -0000 Personal opinion: I agree with most of the assessments, but: On 06/12/2014 07:17, Fred Baker (fred) wrote: ... > Although the working group expressed interest in the following and the authors have been working hard on them, we think the working group is no longer interested in these, and so they should be returned to the authors and not recorded or treated as working group drafts. > > 2014-09-18 draft-ietf-v6ops-design-choices http://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ I think it's a real shame if we can't produce some collective wisdom in this area. Admittedly, there is an alternative for the authors - turn it into a book. But it seems like it should be mainstream work for this WG. If I haven't commented much on it, that's because I think it is competent work that should go forward. My preferred next step for this draft would be one more update (see below) and a WG Last Call. > 2014-10-27 draft-ietf-v6ops-dhcpv6-slaac-problem http://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ I'm of the party that believes that there is a defect in the IPv6 specifications in this area that needs to be fixed. I don't care whether this draft becomes an RFC, but I do care about the fix. As long as there's no sign of somebody fixing the specs, I like having this draft around. > 2014-10-27 draft-ietf-v6ops-ula-usage-recommendations http://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommendations/ I'm surprised by the assertion that the WG isn't interested, given the amount of email this topic has generated. But now I have a suggestion. draft-ietf-v6ops-design-choices says "this document serves both to document the reasoning behind best current practices for IPv6, and to allow a designer to make an intelligent choice where no such consensus exists." However, it doesn't have a section on choices for addressing. It needs that, and the ULA recommendations and considerations belong there rather than in a separate draft. Brian From nobody Fri Dec 5 12:10: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 20FFA1A0151 for ; Fri, 5 Dec 2014 12:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 S7moGB8VIMhg for ; Fri, 5 Dec 2014 12:10:41 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59D391A00F0 for ; Fri, 5 Dec 2014 12:10:41 -0800 (PST) Received: from [192.168.178.22] (5356AD6E.cm-6-7c.dynamic.ziggo.nl [83.86.173.110]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sB5KADeH060771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Dec 2014 21:10:13 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Iljitsch van Beijnum In-Reply-To: Date: Fri, 5 Dec 2014 21:10:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141204.111820.41660320.sthaug@nethelp.no> <5480391F.9040902@massar.ch> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/GywJ3navI2F3S4VyceUaXe21IZQ Subject: Re: [v6ops] Quick measurement: MTUs on the general Internet 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, 05 Dec 2014 20:10:43 -0000 On 04 Dec 2014, at 14:36, Iljitsch van Beijnum = wrote: > Note that in both cases there was nothing below an MTU of 1280 and = nothing above an MTU of 1500. I've kept this running for the past 30 hours, and now I have some 9k = (MSS =3D 8960) MTUs. But I have no idea what on earth is going on inside Amazon's = datacenters. Maybe they love prime numbers? 17:11:24.578439 IP 54.174.148.205.41221 > 83.149.65.1.80: S = 2882684603:2882684603(0) win 26883 18:15:40.824912 IP 54.173.217.66.50098 > 83.149.65.1.80: S = 3904598406:3904598406(0) win 26883 18:34:22.194809 IP 54.172.213.42.49088 > 83.149.65.1.80: S = 1482929797:1482929797(0) win 26883 18:40:09.912631 IP 54.86.224.246.46138 > 83.149.65.1.80: S = 2156593579:2156593579(0) win 26883 20:05:47.713870 IP 54.174.140.22.36348 > 83.149.65.1.80: S = 3029198432:3029198432(0) win 26883 Still not a single IPv4 ICMP too big.= From nobody Sat Dec 6 02:34: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 EA13C1A902B for ; Sat, 6 Dec 2014 02:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7] 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 4mggsUoQLoZg for ; Sat, 6 Dec 2014 02:34:07 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96B071A902A for ; Sat, 6 Dec 2014 02:34:07 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 4B04B10054675; Sat, 6 Dec 2014 10:34:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417862043; bh=LrrxXpS1VQOl38EoxLmrBiLcDiy39Czwt3ms2aKKRE0=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=W6GciS8ay5QXz1xUGAwVLOMUrA3SdGu1RXwVseUd7dh0D86KlQxaP5Ka1MeQZfb0B VgI/T0B69VIbFVv0FiEJ/ViefCyNIMhjSS/Wwvc50OQ3eAndQvaHdLRfk2Bl0nIAo5 7TZLVOeQHNs4lxFHePN3HdOfaaZRlWBQAt7oPVnUZIjlk90oQDzh5ogFrsBV3ub8Rm J0JqVZP+4KilkyEF92sTjAaBWq3KV2dQhGgHSAMoQ3PE3YjasggSLgMns4PQ7ZGO4t Y6VIR/VZq15UKI4AkkYi+8w6eEt5eMO5K8K0LX05mk8IS5bUChVoT0PrVjdyc9VgqZ 1fW9wvmWJXXXA== Message-ID: <5482DB99.7050802@massar.ch> Date: Sat, 06 Dec 2014 11:34:01 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: "Fred Baker (fred)" References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/z4-vkhQ9tpo3c_y2mI-4S4VSOEQ Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 06 Dec 2014 10:34:10 -0000 On 2014-12-05 16:51, Fred Baker (fred) wrote: > > On Dec 5, 2014, at 1:37 AM, Iljitsch van Beijnum wrote: > >> I don't see the possibility of this scenario as a reason for the IETF or the operator community to start implementing ugly hacks. > > For the record, I live behind an IPsec tunnel, and it solves the problem another way. Since it can see traffic in the clear (it is adding the IPsec ESP), it can see the TCP MSS option, and set it to a smaller value. That’s usually 1400, not 1280, but it could be 1280. > > I might be tempted to refer to that as an "ugly hack". It does predictably work. And then you send something that is not TCP.... Greets, Jeroen From nobody Sat Dec 6 03:04: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 A71A31A902F for ; Sat, 6 Dec 2014 03:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 MUrJjVIkYIsi for ; Sat, 6 Dec 2014 03:03:59 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3911B1A902C for ; Sat, 6 Dec 2014 03:03:59 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 8E59D10054675; Sat, 6 Dec 2014 11:03:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417863836; bh=D5l4d33rFmAuqUBAYEm7s+4WSTK/l4z28z8+kNHGarE=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=jqCZ9MNIglX2ze+1AHB0VIf26npWVnHllVFbtalOEkxEQ09rTFFki21UrnuPKyuj9 KeX0eTnNfnOdpaH+fdxdszY3hVad065Cz/9YRmWDyArrdiUUvyM8BvT74UbRnNm1rK EoStWG7HEiIY0WeBKsoecPoAeIsOMnjhKO+508HVa6IOvCAnxIQAV/2hJY0y004EYq YyWFnR3VfxEnxD1RnAMPxER7U1JmJzkdInl6lD/wZGtSGbSRaDe2LIK2DOQEd2rsh5 pS4DnBhbkI3rsiXZ+dmdLymjFgyvtLVDXvouNV1EGR3GX+u94maiasBLkL6/ARha2a Q1GLeiSvAd/jQ== Message-ID: <5482E29A.1070802@massar.ch> Date: Sat, 06 Dec 2014 12:03:54 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: "Templin, Fred L" References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141205091812.39854739@echo.ms.redpill-linpro.com> <20141205094341.799a12ad@echo.ms.redpill-linpro.com> <20141205101850.6e58b351@echo.ms.redpill-linpro.com> <20141205110546.2ef6ebf1@echo.ms.redpill-linpro.com> <54818F41.9090802@massar.ch> <5481A1B0.3080804@massar.ch> <5481B5C8.6030501@massar.ch> <2134F8430051B64F815C691A62D9831832DAC16A@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832DAC16A@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7PgK6geWwKQWSGTyg1P2bPQv_5k Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 06 Dec 2014 11:04:01 -0000 On 2014-12-05 15:59, Templin, Fred L wrote: > > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Jeroen Massar >> Sent: Friday, December 05, 2014 5:40 AM >> To: Philip Homburg >> Cc: v6ops@ietf.org WG >> Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet >> >> >> Please doc this 'frag on the layer below' idea with the pros and cons it >> has, would be a good informational document; but likely that will see >> little global/large deployment due to the cons. > > You are misunderstaing; we are talking about a little bit of fragmentation A little bit indeed, but because of that you are sending 2 packets instead of one, and that happens in both directions. > that should be turned off as soon as possible. That will happen as more > and more links set MTUs larger than 1500. IPv6 should also have been deployed globally as soon as possible... And ICMPv6 MUST not be dropped, but that is happening too. Greets, Jeroen From nobody Sat Dec 6 03:20: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 CC7E41A9033 for ; Sat, 6 Dec 2014 03:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 LJCmabXNspL6 for ; Sat, 6 Dec 2014 03:20:42 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id BD4271A9031 for ; Sat, 6 Dec 2014 03:20:41 -0800 (PST) Received: (qmail 98402 invoked from network); 6 Dec 2014 11:20:39 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 6 Dec 2014 11:20:39 -0000 Date: Sat, 06 Dec 2014 12:20:39 +0100 (CET) Message-Id: <20141206.122039.74658588.sthaug@nethelp.no> To: jeroen@massar.ch From: sthaug@nethelp.no In-Reply-To: <5482E29A.1070802@massar.ch> References: <5481B5C8.6030501@massar.ch> <2134F8430051B64F815C691A62D9831832DAC16A@XCH-BLV-504.nw.nos.boeing.com> <5482E29A.1070802@massar.ch> 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/yNceJdPe2Bioz1Oqwvd4PJk7FBY Cc: v6ops@ietf.org Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 06 Dec 2014 11:20:48 -0000 > > that should be turned off as soon as possible. That will happen as more > > and more links set MTUs larger than 1500. > > IPv6 should also have been deployed globally as soon as possible... Speaking only for myself: We run with a suitable jumbo MTU on most links *within our AS*. I see no sign of such an increased MTU becoming more available on peering and transit links. Steinar Haug, AS 2116 From nobody Sat Dec 6 04:26: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 4AC961A8A0E for ; Sat, 6 Dec 2014 04:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 WUvxb08JwhQI for ; Sat, 6 Dec 2014 04:26:31 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 477871A8ABE for ; Sat, 6 Dec 2014 04:26:30 -0800 (PST) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 6E09810054675; Sat, 6 Dec 2014 12:26:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417868787; bh=4jCT8QihtTQz282PpHs9fushAMlmLnnR0uW+44/r+OY=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=jGmJJvGNgIH32OahWSS1uFYET0cSP5gMOlTt+6/1zHNOhvHUDFoHxDtXzmFOhxx57 ZhL/xMUyHZFMV/4gS078xaywUyGTjDJCkYUBHsi/I2cCrg8Ii3+UByEYJASLyrUmIt q5YANsHviEXp/Zv31ltNbTrdnwKm/sHvOnUCpbOkhMI5L89fSfD3g61kTSwcb4awye ohjmw3CrnDKzMsLO20y2VzaSgui1Cii1/fyDA95Mck6d6eVpo66V2nzVkws3dyv+So vlLpXCEZ9hBWjsmFdZptzUHOWYM2oZ4aAOkbWZLOZ/UlBrEIvsLpkKHPujaOzeGHyV X+F7JCFbMINAQ== Message-ID: <5482F5F1.8000907@massar.ch> Date: Sat, 06 Dec 2014 13:26:25 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: sthaug@nethelp.no References: <5481B5C8.6030501@massar.ch> <2134F8430051B64F815C691A62D9831832DAC16A@XCH-BLV-504.nw.nos.boeing.com> <5482E29A.1070802@massar.ch> <20141206.122039.74658588.sthaug@nethelp.no> In-Reply-To: <20141206.122039.74658588.sthaug@nethelp.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/adJUH3mG_5P2tKP97X5-60WPsA4 Cc: v6ops@ietf.org Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 06 Dec 2014 12:26:33 -0000 On 2014-12-06 12:20, sthaug@nethelp.no wrote: >>> that should be turned off as soon as possible. That will happen as more >>> and more links set MTUs larger than 1500. >> >> IPv6 should also have been deployed globally as soon as possible... > > Speaking only for myself: We run with a suitable jumbo MTU on most > links *within our AS*. I see no sign of such an increased MTU becoming > more available on peering and transit links. Agreed. IMHO one big reason of which is that there are cases where PMTU does not work 100% and thus there is no real benefit of enabling larger MTUs as it will only give problems (as it is something not well known) and thus higher support cost, than creating faster transfers. Hence, a status quo. Greets, Jeroen From nobody Sat Dec 6 04:50: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 109C61A8AD2 for ; Sat, 6 Dec 2014 04:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 tMCA4TRjBNyV for ; Sat, 6 Dec 2014 04:50:39 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1045C1A903A for ; Sat, 6 Dec 2014 04:50:38 -0800 (PST) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:b193:76dc:5080:563e] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sB6Co7Y7071534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Dec 2014 13:50:08 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Iljitsch van Beijnum In-Reply-To: <5482F5F1.8000907@massar.ch> Date: Sat, 6 Dec 2014 13:50:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5481B5C8.6030501@massar.ch> <2134F8430051B64F815C691A62D9831832DAC16A@XCH-BLV-504.nw.nos.boeing.com> <5482E29A.1070802@massar.ch> <20141206.122039.74658588.sthaug@nethelp.no> <5482F5F1.8000907@massar.ch> To: Jeroen Massar X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1nZGX3jwUZ1O5Y6wCL74Y2Uuehw Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 06 Dec 2014 12:50:44 -0000 On 06 Dec 2014, at 13:26, Jeroen Massar wrote: > there are cases where PMTU does not > work 100% and thus there is no real benefit of enabling larger MTUs as > it will only give problems (as it is something not well known) and = thus > higher support cost, than creating faster transfers. You are assuming that if PMTUD fails to detect the correct path MTU on = paths with a < 1500 MTU that PMTUD will also fail to detect the correct = path MTU on paths with a >=3D 1500 MTU. These are very different cases, = so that is an incorrect conclusion. In the one case, you are shorter = than everyone else, in the other case you're taller than everyone else. = That's not the same experience. It's too bad that my home gateway doesn't support an IP MTU above 1500 = (although its LAN ports will forward packets as large as 1982 bytes) so = I can't try this myself at home... But as I've said several times now: IPv4 is a lost cause, but with IPv6 = PMTUD works well enough that we don't have to write it off. We just need = to educate people that not generating / excessively rate limiting / = filtering too bigs is incompatible with running IPv6 properly.= From nobody Sat Dec 6 08:18: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 AE3AD1A8968 for ; Sat, 6 Dec 2014 08:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 k6oCFTUlm2FU for ; Sat, 6 Dec 2014 08:17:57 -0800 (PST) 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 00B631A1BC2 for ; Sat, 6 Dec 2014 08:17:56 -0800 (PST) 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 sB6GHtkU027775; Sat, 6 Dec 2014 08:17:55 -0800 Received: from XCH-PHX-509.sw.nos.boeing.com (xch-phx-509.sw.nos.boeing.com [10.57.37.31]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sB6GHlgb027709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Sat, 6 Dec 2014 08:17:48 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-PHX-509.sw.nos.boeing.com ([169.254.9.70]) with mapi id 14.03.0210.002; Sat, 6 Dec 2014 08:17:47 -0800 From: "Templin, Fred L" To: Jeroen Massar , "sthaug@nethelp.no" Thread-Topic: [v6ops] PMTUD forever, was: MTUs on the general Internet Thread-Index: AQHQEJwFpAeu1cDlMEapgQ1gXobqjpyC7YoAgAAEroCAABJggP//uZRw Date: Sat, 6 Dec 2014 16:17:46 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DAD225@XCH-BLV-504.nw.nos.boeing.com> References: <5481B5C8.6030501@massar.ch> <2134F8430051B64F815C691A62D9831832DAC16A@XCH-BLV-504.nw.nos.boeing.com> <5482E29A.1070802@massar.ch> <20141206.122039.74658588.sthaug@nethelp.no> <5482F5F1.8000907@massar.ch> In-Reply-To: <5482F5F1.8000907@massar.ch> 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/45HclMAUWsItEvKzRj9dra5MBI4 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 06 Dec 2014 16:17:58 -0000 Hi Jeroen, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Jeroen Massar > Sent: Saturday, December 06, 2014 4:26 AM > To: sthaug@nethelp.no > Cc: v6ops@ietf.org > Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet >=20 > On 2014-12-06 12:20, sthaug@nethelp.no wrote: > >>> that should be turned off as soon as possible. That will happen as mo= re > >>> and more links set MTUs larger than 1500. > >> > >> IPv6 should also have been deployed globally as soon as possible... > > > > Speaking only for myself: We run with a suitable jumbo MTU on most > > links *within our AS*. I see no sign of such an increased MTU becoming > > more available on peering and transit links. >=20 > Agreed. >=20 > IMHO one big reason of which is that there are cases where PMTU does not > work 100% and thus there is no real benefit of enabling larger MTUs as > it will only give problems (as it is something not well known) and thus > higher support cost, than creating faster transfers. >=20 > Hence, a status quo. Yes, the status has been quo for a long time, but we now have an opportunit= y to move beyond that. If tunnels stop clamping the MTU and end hosts start using RFC4821 larger MTUs will be possible. The good news is that fixing th= e tunnels and fixing the end hosts can be done independently of one another. Thanks - Fred fred.l.templin@boeing.com > Greets, > Jeroen >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun Dec 7 01:37: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 472881A1BCA for ; Sun, 7 Dec 2014 01:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 bsseVGg0K5a8 for ; Sun, 7 Dec 2014 01:37:50 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C421A1AD3 for ; Sun, 7 Dec 2014 01:37:50 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id n3so2277258wiv.7 for ; Sun, 07 Dec 2014 01:37:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=MOmB1JZT09IzOL7Bk195W0LVTqGdbml7TuMqXKpdZHQ=; b=NVc0dI6un/N2kJZfCs3N+qKsM3xRcbfjTuAtyDL0LdZOJbW86io24jr2TmqqALSC9f ZZpa3kR/EUXPClRmJLYZAlgPU5HMlCi2cB09GXkKGCQ5zigvzoq+UifjwTvxW048CrAh 6D3OA8rmWHaJPS9rYnDN9qlex+BoF25/pt2ru5AT5gFAA/XZweHqi2kE5RqjH2pUyo+M GMTbknAPt1/wTvn2Yio/THkF45N9mmVwICBPMsPSvWwlsiRkI+Fpuu/1xDcYHQ2KzJbN uaCgRK7k66haep3av6H0PCc74T8afh8h8j0cpjHLoDKewm3VMUrzEI3F9XucAQ8ZRdRl bxtg== X-Received: by 10.180.103.229 with SMTP id fz5mr16665308wib.31.1417945068975; Sun, 07 Dec 2014 01:37:48 -0800 (PST) Received: from [10.59.2.210] ([217.130.250.140]) by mx.google.com with ESMTPSA id eu8sm5055993wib.21.2014.12.07.01.37.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Dec 2014 01:37:47 -0800 (PST) References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <9BF7829A-C434-434F-9E23-838B2CD906F7@steffann.nl> <547F3631.7060606@globis.net> <547F4D95.7030706@globis.net> <547F665E.2070804@gmail.com> <5478E4C2-D709-4EFD-BC86-A5068576DAE3@steffann.nl> <547F8D9C.80608@gmail.com> <5480B9EC.9010009@gmail.com> <5480C4F1.60402@gmail.com> <5480D879.5090207@gmail.com> In-Reply-To: <5480D879.5090207@gmail.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (12B435) From: Andrew Yourtchenko Date: Sun, 7 Dec 2014 09:37:42 +0000 To: Brian E Carpenter Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/n-4SJfoOUuOTPoRZx_nRhcKNXxI Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: RFC 6346 successful: moving to Proposed Standard 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, 07 Dec 2014 09:37:52 -0000 Brian, Inline ... >> On 04 Dec 2014, at 21:56, Brian E Carpenter = wrote: >>=20 >>> On 05/12/2014 09:32, Tom Taylor wrote: >>>> On 04/12/2014 2:45 PM, Brian E Carpenter wrote: >>>> On 04/12/2014 22:02, Sander Steffann wrote: >>>> Hi Brian, >> ... >>=20 >>>>=20 >>>>>>> I also have a technical question. The RFC says, on the subject of >>>>>>> user logging: >>>>>>>=20 >>>>>>> " A+P offers a better set of trade-offs. All that needs to be >>>>>>> logged >>>>>>> is the allocation of a range of port numbers to a customer. By >>>>>>> design, this will be done rarely, improving scalability." >>>>>>>=20 >>>>>>> With the growth in legally mandated logging around the world, what i= s >>>>>>> the practical experience on this? Has A+P logging proved to be >>>>>>> scalable >>>>>>> at reasonable cost, or has it become a burden? >>>>>> A+P logging is doable. NAT transaction living is a huge burden. >>>>>> Besides that: it might be legal to log the assigned A+P port range >>>>>> and it might not be legal to log NAT transactions (privacy issues). >>>>>> The Netherlands is a jurisdiction where this is the case. I checked >>>>>> that with the local regulator and law enforcement a few years ago. >>>>> Yes, transaction logging is obviously unreasonable, but I was asking >>>>> for actual experience with A+P logging. >>>>=20 >>>> I don't have any. What exactly do you want to log anyway? There isn't >>>> that much to log from a stateless device except how the stateless >>>> mapping algorithm is configured... >>>=20 >>> Well, if you are under a legal mandate to log who is using which IP >>> address at any given time, with A+P you also have to log who is using >>> each port range. No choice about that, whether the underlying mechanism >>> is stateful or not. The question is whether that aggravates the scaling >>> problem (compared to CGN or XLAT464 or other approaches). >> ... >> draft-ietf-behave-syslog-nat-logging is basically theoretical, but it >> does give information on logging volumes. Look particularly at the >> Applicability section. >=20 > Thanks Tom. So for a CGN, the order of magnitude is "150,000 call detail > records per second, varying in length from 500 to 1500 bytes." > Equivalent data for A+P would be very informative. For MAP, the exact answer is "zero assuming the current configuration and IP= v6 assignment are logged elsewhere", because one can always algorithmically f= ind the IPv4 addresses and port range from allocated IPv6 prefix and domain c= onfig. http://6lab.cisco.com/map/MAPnew.php?eyJydWxlcyI6W1siVGVzdCIsIjIwMDE6ZGI4OmZ= mZmY6ZjAwMC81MiIsIjE5Mi4wLjIuMC8zMSIsOCw2LDBdXSwibWFwdHlwZSI6IlQiLCJkbXJiciI= 6IjIwMDE6REI4OkNBRkU6Q0FGRTo6LzY0In0=3D if you like to see this process in action (you will see a mock config using= 2 IPv4 addresses for domain). --a >=20 > Brian >=20 >>=20 >> There is also information in draft-chen-sunset4-cgn-port-allocation and >> draft-donley-behave-deterministic-cgn. >>=20 >> Tom Taylor >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun Dec 7 02:14: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 32BC01A8737 for ; Sun, 7 Dec 2014 02:14:07 -0800 (PST) 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_05=-0.5, 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 nZx0TcgLt4W3 for ; Sun, 7 Dec 2014 02:14:02 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0713.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::713]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF7E1A8736 for ; Sun, 7 Dec 2014 02:14:02 -0800 (PST) Received: from pc6 (86.184.62.161) by DB3PR07MB058.eurprd07.prod.outlook.com (10.242.137.148) with Microsoft SMTP Server (TLS) id 15.1.26.15; Sun, 7 Dec 2014 10:01:08 +0000 Message-ID: <010701d01204$b8e18160$4001a8c0@gateway.2wire.net> From: t.petch To: "Fred Baker (fred)" , References: <08DA982D-6605-434B-B815-C69B8A97FA4C@cisco.com> Date: Sun, 7 Dec 2014 10:01:02 +0000 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: [86.184.62.161] X-ClientProxiedBy: AM3PR01CA033.eurprd01.prod.exchangelabs.com (10.141.191.23) To DB3PR07MB058.eurprd07.prod.outlook.com (10.242.137.148) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB058; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB058; X-Forefront-PRVS: 04180B6720 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(199003)(189002)(13464003)(377424004)(377454003)(40100003)(99396003)(120916001)(61296003)(50466002)(81816999)(46102003)(1556002)(89996001)(97736003)(19580405001)(31966008)(19580395003)(122386002)(107886001)(1720100001)(15975445007)(107046002)(33646002)(50986999)(77156002)(68736005)(76176999)(77096005)(81686999)(42186005)(62966003)(21056001)(14496001)(116806002)(44736004)(101416001)(86362001)(23746002)(20776003)(105586002)(66066001)(87976001)(47776003)(84392001)(62236002)(64706001)(92566001)(106356001)(4396001)(50226001)(44716002)(1456002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB058; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB058; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ni7VDqRzLYFNxXIrSgiBn4CLG_8 Subject: Re: [v6ops] Working Group 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: Sun, 07 Dec 2014 10:14:07 -0000 Fred As Brian says in his note, 2014-10-27 draft-ietf-v6ops-dhcpv6-slaac-problem http://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ addresses a known problem and I think it would be remiss of the IETF not to have this documented Tom Petch ----- Original Message ----- From: "Fred Baker (fred)" To: Sent: Friday, December 05, 2014 6:17 PM Subject: [v6ops] Working Group Administrivia Joel, Lee, and I spoke this morning about the status of the working group and various drafts in it. I’d like to gauge working group consensus on the status of a number of working group drafts that have either expired or otherwise should no longer be considered working group drafts. Your opinions, pro or con (such as “I’m fine with all that but think we should still be considering draft-whatever”), please: We think that the following can be safely set aside, by having the secretariat record (and show in the data tracker) that they are no longer working group drafts. They have expired, and are not currently being pursued: 2003-01-13 draft-ietf-v6ops-ipv4survey http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv4survey/ 2003-02-14 draft-ietf-v6ops-ipv4survey-gen http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv4survey-gen/ 2004-07-20 draft-ietf-v6ops-v6onbydefault http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6onbydefault/ 2007-02-27 draft-ietf-v6ops-routing-guidelines http://datatracker.ietf.org/doc/draft-ietf-v6ops-routing-guidelines/ 2007-03-28 draft-ietf-v6ops-campus-transition http://datatracker.ietf.org/doc/draft-ietf-v6ops-campus-transition/ 2008-05-13 draft-ietf-v6ops-nat64-pb-statement-req http://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-pb-statement-req/ 2011-07-26 draft-ietf-v6ops-v4v6tran-framework http://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6tran-framework/ 2013-08-14 draft-ietf-v6ops-monitor-ds-ipv6 http://datatracker.ietf.org/doc/draft-ietf-v6ops-monitor-ds-ipv6/ We think that draft-ietf-v6ops-balanced-ipv6-security, in its current state, is a deployment report, primarily from Swisscom. While the working group expressed interest in guidance on firewall configuration, this isn’t it. We think it should no longer be a working group draft, and invite the authors to submit it to the independent stream as a deployment report (-- or individual submissions to the IETF, draft--. It would be good if the authors would send a note to internet-drafts@ietf.org indicating that the old draft name were replaced by the new draft name, so that the revision history is tracked appropriately. Opinions? ------------------------------------------------------------------------ -------- > > ------------------------------------------------------------------------ -------- > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Sun Dec 7 13:29: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 CDE101A8976 for ; Sun, 7 Dec 2014 13:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 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, 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 0x-1P20nizzX for ; Sun, 7 Dec 2014 13:29:10 -0800 (PST) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BB2D1A8978 for ; Sun, 7 Dec 2014 13:29:10 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id x12so2282809wgg.25 for ; Sun, 07 Dec 2014 13:29:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=scCr1c2NDRArwgDOPKjz5Jj9PABZ+hncYNdZoObIeXM=; b=wyM+ozaU9hicSaI17kFRv8O6rSdajPquxc3MWave69DqOkkfYiY6CG+gGVF+Kg6xd+ e4NeXShvjf657RzbHcg/JmT4AW+ZJGYFyI1I4CXAdv2vqLv/TKF7PpKHy64J9W8s/y7u nv5qDZfgGA0FN/z/5jOs6P21qST0SM6odI6+qCgafeWwUSWJ81P6p6Y31ps/HT5Re/vt UBp1TozVW057OPcRYR5MvkUEydXJNuJFbFQqgRAA7+n1++VBCR9j9KZr7hBtDlLUO7MO VHA1q2UHiZ8g/C4Vdu2l9YdHVPXXnQ3u3L6gruijy0ZRuNO2Pb2fDweX6brLvOezWavX iJyA== MIME-Version: 1.0 X-Received: by 10.180.90.206 with SMTP id by14mr19626161wib.67.1417987749241; Sun, 07 Dec 2014 13:29:09 -0800 (PST) Sender: mpetach@gmail.com Received: by 10.27.89.1 with HTTP; Sun, 7 Dec 2014 13:29:09 -0800 (PST) In-Reply-To: <010701d01204$b8e18160$4001a8c0@gateway.2wire.net> References: <08DA982D-6605-434B-B815-C69B8A97FA4C@cisco.com> <010701d01204$b8e18160$4001a8c0@gateway.2wire.net> Date: Sun, 7 Dec 2014 13:29:09 -0800 X-Google-Sender-Auth: Knm57VvPJ5Yc4_TwLLQNMnN4MBo Message-ID: From: Matthew Petach To: "t.petch" Content-Type: multipart/alternative; boundary=f46d043c80ec16e8810509a7002c Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Byn85ErxVAD2JGfj0E4rqnbqIw8 Cc: v6ops@ietf.org Subject: Re: [v6ops] Working Group 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: Sun, 07 Dec 2014 21:29:13 -0000 --f46d043c80ec16e8810509a7002c Content-Type: text/plain; charset=UTF-8 On Sun, Dec 7, 2014 at 2:01 AM, t.petch wrote: > Fred > > As Brian says in his note, > > 2014-10-27 draft-ietf-v6ops-dhcpv6-slaac-problem > http://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ > > addresses a known problem and I think it would be remiss of the IETF not > to have this documented > > Tom Petch > Completely concur; we can't leave the current situation as it is, where the behaviours are decided ad-hoc by different sets of developers, and upgrading your OS may suddenly change how your network behaves. This needs to be documented, and hopefully fixed at some point. Thanks! Matt --f46d043c80ec16e8810509a7002c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Dec 7, 2014 at 2:01 AM, t.petch <ietfc@btconnect.com&g= t; wrote:
Fred

As Brian says in his note,

2014-10-27=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-v6ops-dhcpv6-= slaac-problem
http://datatracker.ietf.org/doc/draft-ietf-v6ops-= dhcpv6-slaac-problem/

addresses a known problem and I think it would be remiss of the IETF not to have this documented

Tom Petch


Completely concur; we can= 't leave the
current situation as it is, where the
beh= aviours are decided ad-hoc by
different sets of developers, and
upgra= ding your OS may suddenly
change how your network behaves.
This needs to be documented, and
hopefully fixed at some poi= nt.

Thanks!

Matt
=C2=A0
--f46d043c80ec16e8810509a7002c-- From nobody Sun Dec 7 18: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 016621A1B49 for ; Sun, 7 Dec 2014 18:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 HM5MriWQqs5H for ; Sun, 7 Dec 2014 18:18:21 -0800 (PST) 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 B1B711A1B40 for ; Sun, 7 Dec 2014 18:18:19 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMO61018; Mon, 08 Dec 2014 02:18:18 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 8 Dec 2014 02:18:17 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.128]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 8 Dec 2014 10:18:11 +0800 From: Sheng Jiang To: "t.petch" , "Fred Baker (fred)" , "v6ops@ietf.org" Thread-Topic: [v6ops] Working Group Administrivia Thread-Index: AQHQELfApl0OmdTiikqs9ZO27DRlMpyD67olgAEAGMA= Date: Mon, 8 Dec 2014 02:18:11 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AFDB427@nkgeml512-mbx.china.huawei.com> References: <08DA982D-6605-434B-B815-C69B8A97FA4C@cisco.com> <010701d01204$b8e18160$4001a8c0@gateway.2wire.net> In-Reply-To: <010701d01204$b8e18160$4001a8c0@gateway.2wire.net> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yNOy0TBHF9JBKxjObsgPM47u1IA Subject: Re: [v6ops] Working Group 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: Mon, 08 Dec 2014 02:18:23 -0000 PkFzIEJyaWFuIHNheXMgaW4gaGlzIG5vdGUsDQo+DQo+MjAxNC0xMC0yNyAgICAgICAgICAgZHJh ZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbQ0KPmh0dHA6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbS8NCj4NCj5h ZGRyZXNzZXMgYSBrbm93biBwcm9ibGVtIGFuZCBJIHRoaW5rIGl0IHdvdWxkIGJlIHJlbWlzcyBv ZiB0aGUgSUVURiBub3QNCj50byBoYXZlIHRoaXMgZG9jdW1lbnRlZA0KDQpGdWxseSBhZ3JlZWQu IE15IHJlYWQgZnJvbSB0aGUgbGF0ZXN0IG1lZXRpbmcgcmVzcG9uc2UgaXMgdGhlIHByb2JsZW0g c2hvdWxkIGJlIGRvY3VtZW50IGFuZCBrbm93IGJ5IG9wZXJhdG9ycyBhbmQgaW1wbGVtZW50b3Jz LiBUaGUgY29udHJvdmVyc2lhbCBwYXJ0IGlzIG5vdCB0aGlzIGRyYWZ0LCBidXQgdGhlIGZvbGxv dyB1cCBvZiB0aGlzIGRyYWZ0Og0KDQoxKSBUaGUgc29sdXRpb24gKHByb3RvY29sIGxldmVsKSBp cyBub3QgYmVsb25nIHRvIHY2b3BzIFdHLiANCg0KMikgVGhlIHJlYWwgZGViYXRlIGlzIFdoZXRo ZXIgdjZvcHMgc2hvdWxkIHByb2R1Y2UgYW4gb3BlcmF0aW9uYWwgZ3VpZGVsaW5lcyBmb3Igb3Bl cmF0b3JzIHRvIGF2b2lkIHRoaXMgaXNzdWUuIFBlcnNvbmFsbHksIEkgdGhpbmsgaXQgaXMgaGVs cGZ1bCBhbmQgYmVsb25nIHRvIHRoaXMgV0csIGJ1dCBpdCBzZWVtcyB0aGUgV0cgZG9lcyBub3Qg cmVhY2ggY29uc2Vuc3VzIG9uIHRoaXMuDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPlRv bSBQZXRjaA0KPg0KPg0KPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj5Gcm9tOiAiRnJl ZCBCYWtlciAoZnJlZCkiIDxmcmVkQGNpc2NvLmNvbT4NCj5UbzogPHY2b3BzQGlldGYub3JnPg0K PlNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMDUsIDIwMTQgNjoxNyBQTQ0KPlN1YmplY3Q6IFt2Nm9w c10gV29ya2luZyBHcm91cCBBZG1pbmlzdHJpdmlhDQo+DQo+DQo+Sm9lbCwgTGVlLCBhbmQgSSBz cG9rZSB0aGlzIG1vcm5pbmcgYWJvdXQgdGhlIHN0YXR1cyBvZiB0aGUgd29ya2luZw0KPmdyb3Vw IGFuZCB2YXJpb3VzIGRyYWZ0cyBpbiBpdC4gSeKAmWQgbGlrZSB0byBnYXVnZSB3b3JraW5nIGdy b3VwDQo+Y29uc2Vuc3VzIG9uIHRoZSBzdGF0dXMgb2YgYSBudW1iZXIgb2Ygd29ya2luZyBncm91 cCBkcmFmdHMgdGhhdCBoYXZlDQo+ZWl0aGVyIGV4cGlyZWQgb3Igb3RoZXJ3aXNlIHNob3VsZCBu byBsb25nZXIgYmUgY29uc2lkZXJlZCB3b3JraW5nIGdyb3VwDQo+ZHJhZnRzLiBZb3VyIG9waW5p b25zLCBwcm8gb3IgY29uIChzdWNoIGFzIOKAnEnigJltIGZpbmUgd2l0aCBhbGwgdGhhdCBidXQN Cj50aGluayB3ZSBzaG91bGQgc3RpbGwgYmUgY29uc2lkZXJpbmcgZHJhZnQtd2hhdGV2ZXLigJ0p LCBwbGVhc2U6DQo+DQo+V2UgdGhpbmsgdGhhdCB0aGUgZm9sbG93aW5nIGNhbiBiZSBzYWZlbHkg c2V0IGFzaWRlLCBieSBoYXZpbmcgdGhlDQo+c2VjcmV0YXJpYXQgcmVjb3JkIChhbmQgc2hvdyBp biB0aGUgZGF0YSB0cmFja2VyKSB0aGF0IHRoZXkgYXJlIG5vDQo+bG9uZ2VyIHdvcmtpbmcgZ3Jv dXAgZHJhZnRzLiBUaGV5IGhhdmUgZXhwaXJlZCwgYW5kIGFyZSBub3QgY3VycmVudGx5DQo+YmVp bmcgcHVyc3VlZDoNCj4NCj4yMDAzLTAxLTEzICAgICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0 Zi12Nm9wcy1pcHY0c3VydmV5DQo+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLXY2b3BzLWlwdjRzdXJ2ZXkvDQo+MjAwMy0wMi0xNCAgICAgICAgICAgICAgICAgZHJh ZnQtaWV0Zi12Nm9wcy1pcHY0c3VydmV5LWdlbg0KPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy1pcHY0c3VydmV5LWdlbi8NCj4yMDA0LTA3LTIwICAgICAg ICAgICAgICAgICAgZHJhZnQtaWV0Zi12Nm9wcy12Nm9uYnlkZWZhdWx0DQo+aHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLXY2b25ieWRlZmF1bHQvDQo+MjAw Ny0wMi0yNyAgICAgICAgICAgICBkcmFmdC1pZXRmLXY2b3BzLXJvdXRpbmctZ3VpZGVsaW5lcw0K Pmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy1yb3V0aW5n LWd1aWRlbGluZXMvDQo+MjAwNy0wMy0yOCAgICAgICAgICAgICAgZHJhZnQtaWV0Zi12Nm9wcy1j YW1wdXMtdHJhbnNpdGlvbg0KPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi12Nm9wcy1jYW1wdXMtdHJhbnNpdGlvbi8NCj4yMDA4LTA1LTEzICAgICAgICAgZHJhZnQt aWV0Zi12Nm9wcy1uYXQ2NC1wYi1zdGF0ZW1lbnQtcmVxDQo+aHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLW5hdDY0LXBiLXN0YXRlbWVudC1yZXEvDQo+MjAx MS0wNy0yNiAgICAgICAgICAgICBkcmFmdC1pZXRmLXY2b3BzLXY0djZ0cmFuLWZyYW1ld29yaw0K Pmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy12NHY2dHJh bi1mcmFtZXdvcmsvDQo+MjAxMy0wOC0xNCAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLXY2b3Bz LW1vbml0b3ItZHMtaXB2Ng0KPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi12Nm9wcy1tb25pdG9yLWRzLWlwdjYvDQo+DQo+V2UgdGhpbmsgdGhhdCBkcmFmdC1pZXRm LXY2b3BzLWJhbGFuY2VkLWlwdjYtc2VjdXJpdHksIGluIGl0cyBjdXJyZW50DQo+c3RhdGUsIGlz IGEgZGVwbG95bWVudCByZXBvcnQsIHByaW1hcmlseSBmcm9tIFN3aXNzY29tLiBXaGlsZSB0aGUN Cj53b3JraW5nIGdyb3VwIGV4cHJlc3NlZCBpbnRlcmVzdCBpbiBndWlkYW5jZSBvbiBmaXJld2Fs bCBjb25maWd1cmF0aW9uLA0KPnRoaXMgaXNu4oCZdCBpdC4gV2UgdGhpbmsgaXQgc2hvdWxkIG5v IGxvbmdlciBiZSBhIHdvcmtpbmcgZ3JvdXAgZHJhZnQsDQo+YW5kIGludml0ZSB0aGUgYXV0aG9y cyB0byBzdWJtaXQgaXQgdG8gdGhlIGluZGVwZW5kZW50IHN0cmVhbSBhcyBhDQo+ZGVwbG95bWVu dCByZXBvcnQgKDxyZmMtaXNlQHJmYy1lZGl0b3Iub3JnKS4NCj4NCj4yMDEzLTEyLTA2ICAgICAg ICAgZHJhZnQtaWV0Zi12Nm9wcy1iYWxhbmNlZC1pcHY2LXNlY3VyaXR5DQo+aHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLWJhbGFuY2VkLWlwdjYtc2VjdXJp dHkvDQo+DQo+QWx0aG91Z2ggdGhlIHdvcmtpbmcgZ3JvdXAgZXhwcmVzc2VkIGludGVyZXN0IGlu IHRoZSBmb2xsb3dpbmcgYW5kIHRoZQ0KPmF1dGhvcnMgaGF2ZSBiZWVuIHdvcmtpbmcgaGFyZCBv biB0aGVtLCB3ZSB0aGluayB0aGUgd29ya2luZyBncm91cCBpcyBubw0KPmxvbmdlciBpbnRlcmVz dGVkIGluIHRoZXNlLCBhbmQgc28gdGhleSBzaG91bGQgYmUgcmV0dXJuZWQgdG8gdGhlDQo+YXV0 aG9ycyBhbmQgbm90IHJlY29yZGVkIG9yIHRyZWF0ZWQgYXMgd29ya2luZyBncm91cCBkcmFmdHMu DQo+DQo+MjAxNC0wOS0xOCAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi12Nm9wcy1kZXNpZ24t Y2hvaWNlcw0KPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9w cy1kZXNpZ24tY2hvaWNlcy8NCj4yMDE0LTEwLTI3ICAgICAgICAgICBkcmFmdC1pZXRmLXY2b3Bz LWRoY3B2Ni1zbGFhYy1wcm9ibGVtDQo+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtLw0KPjIwMTQtMTAtMjcgICAgICBk cmFmdC1pZXRmLXY2b3BzLXVsYS11c2FnZS1yZWNvbW1lbmRhdGlvbnMNCj5odHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtdWxhLXVzYWdlLXJlY29tbWVuZGF0 aW8NCj5ucy8NCj4NCj5TcGVha2luZyBmb3IgbXlzZWxmLCBpZiBJIGhhdmUgYW55IHF1ZXN0aW9u IG9mIHRoZSBhYm92ZSwgaXQgaXMgb24gb25seQ0KPm9uZSBvZiB0aGVzZS4NCj4NCj5JZiBhbnkg ZHJhZnQgaGFzIGl0cyAiV0cgRHJhZnQiIHN0YXR1cyByZXZva2VkLCBpdCB3aWxsIHN0aWxsIGJl DQo+YXZhaWxhYmxlIGZyb20gdGhlIElFVEYgd2Vic2l0ZSBhcyBmYXIgYXMgSSBrbm93LCBidXQg c3Vic2VxdWVudA0KPnJldmlzaW9ucyBzaG91bGQgYmUgbmFtZWQgYXMgaW5kaXZpZHVhbCBzdWJt aXNzaW9ucyB0byBhIHdvcmtpbmcgZ3JvdXAsDQo+ZHJhZnQtPGF1dGhvcj4tPHdnPi08c3ViamVj dD4gb3IgaW5kaXZpZHVhbCBzdWJtaXNzaW9ucyB0byB0aGUgSUVURiwNCj5kcmFmdC08YXV0aG9y Pi08c3ViamVjdD4uIEl0IHdvdWxkIGJlIGdvb2QgaWYgdGhlIGF1dGhvcnMgd291bGQgc2VuZCBh DQo+bm90ZSB0byBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgaW5kaWNhdGluZyB0aGF0IHRoZSBv bGQgZHJhZnQgbmFtZSB3ZXJlDQo+cmVwbGFjZWQgYnkgdGhlIG5ldyBkcmFmdCBuYW1lLCBzbyB0 aGF0IHRoZSByZXZpc2lvbiBoaXN0b3J5IGlzIHRyYWNrZWQNCj5hcHByb3ByaWF0ZWx5Lg0KPg0K Pk9waW5pb25zPw0KPg0KPg0KPg0KPg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPi0tLS0tLS0tDQo+DQo+ DQo+Pg0KPj4NCj4NCj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4tLS0tLS0tLQ0KPg0KPg0KPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHY2b3BzIG1h aWxpbmcgbGlzdA0KPj4gdjZvcHNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdjZvcHMNCj4+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj52Nm9wcyBtYWlsaW5nIGxpc3QNCj52Nm9wc0BpZXRmLm9y Zw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From nobody Sun Dec 7 21:02: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 A02541A6ED8 for ; Sun, 7 Dec 2014 21:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[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, 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 HHBVdH-T6yEh for ; Sun, 7 Dec 2014 21:02:53 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07B421A3BA7 for ; Sun, 7 Dec 2014 21:02:53 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id n12so5289549wgh.20 for ; Sun, 07 Dec 2014 21:02:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j/DqOH7jg2D3GSCzlE8KMYLgwvOMGJdBLhSL9+TOKvg=; b=bX3CUlri4/fxJcMazAcM2eOyHn6tkgJrYzG8O5dYnfoytwu8fqss6Qe/GCTiIxt3Aj qdPV9KDyimVgedq41HXbIDAiFs9J7/AmvyAndqkHFA6lZJ3vzLlHLUEUC9SInApJcyDE g0vJu7HcRSxq62M5j6FrWQ62oWxzGbFovNHhmNFQPGv/3ZklS06wPZdzswArQ4CYDTAE /r+E04UpSg+GRgIHhNY19CXqF3V6JVU1yKsxZVE5AC/qB/hB3grVhJLKbggrEQhFcknQ A6uEZz4uZUOBHh0L7C2fXrVVcKyDGe5PFt/yoBfWkt3IldGxh/kFVps883EnnYp8PWFx 6Zwg== MIME-Version: 1.0 X-Received: by 10.180.102.135 with SMTP id fo7mr21615674wib.79.1418014971783; Sun, 07 Dec 2014 21:02:51 -0800 (PST) Received: by 10.216.78.5 with HTTP; Sun, 7 Dec 2014 21:02:51 -0800 (PST) In-Reply-To: <54820304.9020201@gmail.com> References: <20141205075203.54ed9ea4@echo.ms.redpill-linpro.com> <54820304.9020201@gmail.com> Date: Sun, 7 Dec 2014 21:02:51 -0800 Message-ID: From: Ca By To: Brian E Carpenter Content-Type: multipart/alternative; boundary=f46d0444728fadf2660509ad56fe Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hmo1C2ZUnN8mGAjenAXbdELaJAQ Cc: IPv6 Ops WG , Tore Anderson Subject: Re: [v6ops] New Version Notification for draft-anderson-v6ops-siit-eam-01.txt 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, 08 Dec 2014 05:02:55 -0000 --f46d0444728fadf2660509ad56fe Content-Type: text/plain; charset=UTF-8 On Fri, Dec 5, 2014 at 11:09 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 06/12/2014 03:19, Sander Steffann wrote: > > Hi, > > > >> In any case, I would like to have your "+1" on which approach you > >> prefer of these alternatives: > >> > >> A) Remove all the normative RFC6145 protocol update language from > >> draft-anderson-siit-dc, taking this document off the standards > >> track, and have it describe the data centre use case only. Instead > >> contain the required protocol update in a separate document dedicated > >> to that purpose, i.e., draft-anderson-v6ops-siit-eam. > > > > +1 > > > > I'd like to see the protocol stuff in a separate -eam doc and leave the > application description in -dc. That way future work can easily reference > the -eam work even if its use case is outside of -dc. > > Agreed. > > Brian > > +1 for moving the protocol modification work to -eam so that it will provide a cleaner reference to any other non-data center document. CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f46d0444728fadf2660509ad56fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Dec 5, 2014 at 11:09 AM, Brian E Carpenter &l= t;brian.e.= carpenter@gmail.com> wrote:
On 06/12/2014 03:19, Sander Steffann wrote:
> Hi,
>
>> In any case, I would like to have your "+1" on which app= roach you
>> prefer of these alternatives:
>>
>> A) Remove all the normative RFC6145 protocol update language from<= br> >> draft-anderson-siit-dc, taking this document off the standards
>> track, and have it describe the data centre use case only. Instead=
>> contain the required protocol update in a separate document dedica= ted
>> to that purpose, i.e., draft-anderson-v6ops-siit-eam.
>
> +1
>
> I'd like to see the protocol stuff in a separate -eam doc and leav= e the application description in -dc. That way future work can easily refer= ence the -eam work even if its use case is outside of -dc.

Agreed.

=C2=A0 =C2=A0Brian


+1 for moving the protocol modification work to= -eam so that it will provide a cleaner reference to any other non-data cen= ter =C2=A0document.

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

--f46d0444728fadf2660509ad56fe-- From nobody Sun Dec 7 21:43: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 6499A1A6F0B for ; Sun, 7 Dec 2014 21:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[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, 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 GGdRbwn1SAwE for ; Sun, 7 Dec 2014 21:43:48 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3342B1A6EFB for ; Sun, 7 Dec 2014 21:43:48 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x13so2823568wgg.33 for ; Sun, 07 Dec 2014 21:43:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=REop1QpsTseHX3+W525Xai0zO11tPtKTUVUg1NDZe+s=; b=YcfrtPGHyrTqtlth71obVd8ehCW7XszfQUmaL9Yfquz9HZ11oJwT0e8E8VvpgGpiuQ IMSHZ/+jMzJ0IqF+qMiO5LXmMR5tpmU5d/h5kBuhNvrji6FrST7u58iKpwagd8F3p3SH tiWd1OctpkLCYPelEJwqLoQXE3BbasCGWadoCSsYsnbE4Nr8rF84aG6Nwm8PrMxYs84+ bibaznN+dBxdNJAV+BetR1PbU1TJrV2h06IPJ9p6MInvERqLNPMLYK0JZ7Kx6mGYd3h8 sUpZzaMTQEUch/89SQ+sY67o9QTYLXdDz8fUD4pFVUANGvCyO0gRpl3Z30UrrXN0X9RR JeOA== MIME-Version: 1.0 X-Received: by 10.180.13.7 with SMTP id d7mr21831497wic.57.1418017426979; Sun, 07 Dec 2014 21:43:46 -0800 (PST) Received: by 10.216.78.5 with HTTP; Sun, 7 Dec 2014 21:43:46 -0800 (PST) Date: Sun, 7 Dec 2014 21:43:46 -0800 Message-ID: From: Ca By To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=001a11c2ac4e053fbd0509ade991 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QtO1HcAxx0kj8ruyGFT7vybIFvY Subject: [v6ops] draft-anderson-v6ops-siit-eam-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: Mon, 08 Dec 2014 05:43:49 -0000 --001a11c2ac4e053fbd0509ade991 Content-Type: text/plain; charset=UTF-8 I have read draft-anderson-v6ops-siit-eam-01 I support the working group adopting this document, this is helpful and meaningful work. I have a few comments that are mostly editorial in nature, i believe the document is technically sound as written today. Purely editorial, i suggest locally adding the definitions for IPv4-converted IPv6 addresses and IPv4-translatable IPv6 addresses. If you are taking up space to define them, then go ahead and do the reader the favor of defining them. In section 3.2 there is this sentence: "If a matching EAM entry is found, the address MUST be translated to IPv6 by substituting its IPv4 Prefix value for the corresponding IPv6 Prefix from the EAM entry." I don't like the word "substituting" since a reader my believe that one simply does a substitution of the IPv4 address for the IPv6. It would be more precises to continuing using the term translate which explicitly references the packet treatment procedure in SIIT. Perhaps rephrase to "... MUST be translated to IPv6 in accordance with the EAMT..." Regards, Cameron Byrne --001a11c2ac4e053fbd0509ade991 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have read=C2=A0draft-anderson-v6ops-siit-eam-01

=
I support the working group adopting this document, this is help= ful and meaningful work.

I have a few comments tha= t are mostly editorial in nature, i believe the document is technically sou= nd as written today. =C2=A0

Purely editorial, i su= ggest locally adding the definitions for=C2=A0IPv4-converted IPv6 addresses= and=C2=A0IPv4-translatable IPv6 addresses.=C2=A0 If you are taking up spac= e to define them, then go ahead and do the reader the favor of defining the= m.

In section 3.2 there is this sentence: =C2=A0&q= uot;If a matching
=C2=A0 =C2=A0 =C2=A0 EAM entry is found, the ad= dress MUST be translated to IPv6 by
=C2=A0 =C2=A0 =C2=A0 substitu= ting its IPv4 Prefix value for the corresponding IPv6
=C2=A0 =C2= =A0 =C2=A0 Prefix from the EAM entry."

I don&= #39;t like the word "substituting" since a reader my believe that= one simply does =C2=A0a substitution of the IPv4 address for the IPv6.=C2= =A0 It would be more precises to continuing using the term translate which = explicitly references the packet treatment procedure in SIIT.=C2=A0 Perhaps= rephrase to "...=C2=A0MUST be translated to IPv6 in accordance with t= he EAMT..."

Regards,

Cameron By= rne


--001a11c2ac4e053fbd0509ade991-- From nobody Sun Dec 7 22:35: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 AB8831A6F64 for ; Sun, 7 Dec 2014 22:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[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, 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 Mox-YBCRYx0a for ; Sun, 7 Dec 2014 22:35:28 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388171A6F61 for ; Sun, 7 Dec 2014 22:35:28 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id r20so3758527wiv.6 for ; Sun, 07 Dec 2014 22:35:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=HFD2s3QImX3FmeMR12iXqs8VLQccLAmU6WEdA2myEZo=; b=Q3SMWZ8JisEhZJIe8fp2sHOuSHs+6+hkcVqP5cqqd+K6sKMLa6ZiH88u5aNGELLfqc fUUCoUtR4uFYjA7fhNzPJLhAUjYqxMaaBWxoO2ed60YYiE7qDp4XWf67NdaEl2enVw5Y Gd9Xb8UQl7HbFjzjLxdiDEFZlEtanZe9/YjTwx+tByyk9mZsnNIAo/YJHGtdWxvjnRpj Uwy5ripf7jFYFXVT3jPMrK8K6imr5TMTRPnH2E7H8QWtUHs87av5jH57v2sOMiRSLC6G rZsIquYN96tNqUQ4TqObYMKibHIjcoBdA7HQRF0CpyPwpkP3eOsNfqWA1Wfc3LxwTmlN NwMw== MIME-Version: 1.0 X-Received: by 10.180.90.16 with SMTP id bs16mr13511781wib.4.1418020527015; Sun, 07 Dec 2014 22:35:27 -0800 (PST) Received: by 10.216.78.5 with HTTP; Sun, 7 Dec 2014 22:35:26 -0800 (PST) Date: Sun, 7 Dec 2014 22:35:26 -0800 Message-ID: From: Ca By To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=f46d043c7e20cc0bca0509aea124 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/IOqVmr3T9jsZ0v06dsyiY7-sNoc Subject: [v6ops] draft-anderson-v6ops-siit-dc-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: Mon, 08 Dec 2014 06:35:29 -0000 --f46d043c7e20cc0bca0509aea124 Content-Type: text/plain; charset=UTF-8 I have read draft-anderson-v6ops-siit-dc-01. I support the document to be republished as a WG informational document with the RFC6145 changes moved into a new document. I have a one minor comments about draft-anderson-v6ops-siit-dc-01. The I-D identifies a real network scaling problem where dual-stack is not an acceptable solution since it does not allow network operators to decouple IPv4 addresses from nodes deployed, thus nodes deployed cannot scale beyond IPv4 address holdings with dual-stack. The IETF needs to provide better guidance than "dual-stack everything". But, the I-D does not address the simplest solution of simply having IPv4 nodes for IPv4 traffic and IPv6 nodes for IPv6 traffic. This allows a data center operator to get the most usage out of scarce IPv4 nodes since they pick up the IPv4-only users (excluding Apple happy eyeballs!!!) while the IPv6 nodes pickup the IPv6 capable users. Now, this approach of IPv4-only nodes and IPv6-only nodes works great when you are Facebook and your smallest unit of provisioning is a fully packed rack of gear. If you are a smaller operator, you may not have enough traffic to justify an IPv6-only node, yet you still have to scale nodes beyond IPv4 holdings. There is also the case where uniformity of provisioning is seen as being a higher value than having 2 flavor: v4 and v6... thus draft-anderson-v6ops-siit-dc-01 certainly fits a need, but it should be context of dual-stack and single stack v4 and v6. --f46d043c7e20cc0bca0509aea124 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have read=C2=A0=C2=A0draft-anderson-v6ops-siit-dc-01.
I support the document to be republished as a WG informati= onal document with =C2=A0the RFC6145 changes =C2=A0moved into a new documen= t.

I have a one minor comments about=C2=A0draft-an= derson-v6ops-siit-dc-01.

The I-D identifies a real= network scaling problem where dual-stack is not an acceptable solution sin= ce it does not allow network operators to decouple IPv4 addresses from node= s deployed, thus nodes deployed cannot scale beyond IPv4 address holdings w= ith dual-stack.=C2=A0 The IETF needs to provide better guidance than =C2=A0= "dual-stack everything".=C2=A0 But, the I-D does not address the = simplest solution of simply having IPv4 nodes for IPv4 traffic and IPv6 nod= es for IPv6 traffic.=C2=A0 This allows a data center operator to get the mo= st usage out of scarce IPv4 nodes since they pick up the IPv4-only users (e= xcluding Apple happy eyeballs!!!) while the IPv6 nodes pickup the IPv6 capa= ble users.=C2=A0 Now, this approach of IPv4-only nodes and IPv6-only nodes = works great when you are Facebook and your smallest unit of provisioning is= a fully packed rack of gear.=C2=A0 If you are a smaller operator, you may = not have enough traffic to justify an IPv6-only node, yet you still have to= scale nodes beyond IPv4 holdings.=C2=A0 There is also the case where unifo= rmity of provisioning is seen as being a higher value than having 2 flavor:= v4 and v6... thus=C2=A0draft-anderson-v6ops-siit-dc-01 certainly fits a ne= ed, but it should be context of dual-stack and single stack v4 and v6.









--f46d043c7e20cc0bca0509aea124-- From nobody Mon Dec 8 00:28: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 D44811A701C for ; Mon, 8 Dec 2014 00:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-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 ysn0tOCLt0gE for ; Mon, 8 Dec 2014 00:28:01 -0800 (PST) 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 B1D071A700D for ; Mon, 8 Dec 2014 00:28:01 -0800 (PST) Received: from [2a02:c0:2:4:6666:17:0:1001] (port=56148 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Xxtfi-0007le-Vu; Mon, 08 Dec 2014 09:27:59 +0100 Date: Mon, 8 Dec 2014 09:27:46 +0100 From: Tore Anderson To: Ca By Message-ID: <20141208092746.05889c92@echo.ms.redpill-linpro.com> In-Reply-To: References: X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.24; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9F8MXRGWrT-ilkP7PQXnoG9h9Uk Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-anderson-v6ops-siit-eam-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: Mon, 08 Dec 2014 08:28:04 -0000 Hi Cameron, > I have read draft-anderson-v6ops-siit-eam-01 > > I support the working group adopting this document, this is helpful and > meaningful work. > > I have a few comments that are mostly editorial in nature, i believe the > document is technically sound as written today. Thank you! > Purely editorial, i suggest locally adding the definitions > for IPv4-converted IPv6 addresses and IPv4-translatable IPv6 addresses. If > you are taking up space to define them, then go ahead and do the reader the > favor of defining them. > > In section 3.2 there is this sentence: "If a matching > EAM entry is found, the address MUST be translated to IPv6 by > substituting its IPv4 Prefix value for the corresponding IPv6 > Prefix from the EAM entry." > > I don't like the word "substituting" since a reader my believe that one > simply does a substitution of the IPv4 address for the IPv6. It would be > more precises to continuing using the term translate which explicitly > references the packet treatment procedure in SIIT. Perhaps rephrase to > "... MUST be translated to IPv6 in accordance with the EAMT..." This text has undergone a lot of back and forth between myself and another reviewer (Alberto Leiva). The problem he identified with saying something like what you propose, is that it fails to say *exactly* what should happen. Say you have $addr="192.0.2.123", $eam4="192.0.2.0/24", $eam6="2001:db8::/112". Now what? You have those three pieces of information, but nothing saying how those should be combined or manipulated to form a new IPv6 address. You could certainly say that it goes without saying and needs no further explanation, but Alberto thought it was best if it was explicit and as clear as possible. That's why we landed on "substitute", the reasoning is that if you start out with $addr="192.0.2.123", then you first take away the prefix bits found in $eam4, temporarily leaving you with $addr=".123" (i.e., "0x7b"), and then putting in the $eam6 prefix bits instead, leaving you with $addr="2001:db8::7b", and you're done. So what you do, essentially, is to substitute the EAM4 prefix for the EAM6 prefix. (If you're familiar with Perl, the pseudocode would go something like "$addr =~ s/^$eam4/$eam6/".) That said, I'm not terribly happy with the current text either. If you or anyone else have any suggestions on how to make it better and clearer, while still remaining explicit about the procedure/algorithm, that would be much appreciated. Tore From nobody Mon Dec 8 00:43: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 B1B621A1B4F for ; Mon, 8 Dec 2014 00:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 c8TglslJ0gbR for ; Mon, 8 Dec 2014 00:43:07 -0800 (PST) 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 8A27F1A0100 for ; Mon, 8 Dec 2014 00:43:07 -0800 (PST) Received: from [2a02:c0:2:4:6666:17:0:1001] (port=56452 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1XxtuL-00088p-TP; Mon, 08 Dec 2014 09:43:05 +0100 Date: Mon, 8 Dec 2014 09:42:53 +0100 From: Tore Anderson To: Ca By Message-ID: <20141208094253.308df787@echo.ms.redpill-linpro.com> In-Reply-To: References: X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.24; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/c79lb0dZzCGaJJnnR-1auwU10sM Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-anderson-v6ops-siit-dc-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: Mon, 08 Dec 2014 08:43:08 -0000 * Ca By > I have read draft-anderson-v6ops-siit-dc-01. > > I support the document to be republished as a WG informational document > with the RFC6145 changes moved into a new document. Thank you! > I have a one minor comments about draft-anderson-v6ops-siit-dc-01. > > The I-D identifies a real network scaling problem where dual-stack is not > an acceptable solution since it does not allow network operators to > decouple IPv4 addresses from nodes deployed, thus nodes deployed cannot > scale beyond IPv4 address holdings with dual-stack. The IETF needs to > provide better guidance than "dual-stack everything". But, the I-D does > not address the simplest solution of simply having IPv4 nodes for IPv4 > traffic and IPv6 nodes for IPv6 traffic. This allows a data center > operator to get the most usage out of scarce IPv4 nodes since they pick up > the IPv4-only users (excluding Apple happy eyeballs!!!) while the IPv6 > nodes pickup the IPv6 capable users. Now, this approach of IPv4-only nodes > and IPv6-only nodes works great when you are Facebook and your smallest > unit of provisioning is a fully packed rack of gear. If you are a smaller > operator, you may not have enough traffic to justify an IPv6-only node, yet > you still have to scale nodes beyond IPv4 holdings. There is also the case > where uniformity of provisioning is seen as being a higher value than > having 2 flavor: v4 and v6... thus draft-anderson-v6ops-siit-dc-01 > certainly fits a need, but it should be context of dual-stack and single > stack v4 and v6. I'm not so sure about having separate IPv4-only and IPv6-only infrastructures solves anything, actually... To continue the Facebook analogy with a rack of IPv4-only frontend nodes and another rack of IPv6-only frontend nodes that serve IPv4-only and IPv6-capable users: Presumably all those users need to be shown the same content, regardless of which IP version they used to request it. So those IPv4/IPv6-only frontend racks necessarily share a common set of backend servers - and if they're to be reachable from both the IPv4-only and the IPv6-only frontend nodes, then the backend nodes must necessarily be dual-stack. So we're back to IPv4 being a limiting factor for scaling, and in my experience the number of backend nodes usually greatly outnumber the number of frontend nodes so really this is where you primarily would want to avoid dual-stack. (If we're talking about Facebook or someone of similar size, dual-stack using RFC1918 for IPv4 in the backend doesn't necessarily scale well enough either.) Tore From nobody Mon Dec 8 02:06: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 9D99D1A89F1 for ; Mon, 8 Dec 2014 02:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 1ZjiJn-ZRowl for ; Mon, 8 Dec 2014 02:06:28 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4C51A89E9 for ; Mon, 8 Dec 2014 02:06:28 -0800 (PST) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 993A0614B; Mon, 8 Dec 2014 02:06:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=pJJnm+ycx3sktdis7HYlHouBKX8=; b=FNIXF+jstWD3+MHdVJ xKjn2BpIbMbwF+hfmJF+YLmQ7tKeNtsYHW2okjQ94Z7xKd0xCb+RctCoRZtOaKE5 DXts19NOzZ0gG2emCdBncKwgGjEouZ/leGFC3h8tdoOPkT/Q6c25LPa7/ytTX6/H aaFLCfXcZGXNIlMAUTMdCuUMg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=MwBygjKFZTRZ1KrDzv3FaOrJ/UcCbI5SmENnw2Cof98guYsjxBN FAHGDTG9/B18BxQ1Dlv3fnxP2ACrL42ntm9eVqRvWwEp8mL8sQrgaV0hBYfCRkMe B6wNucg6ev37e4Sddhrd4iCKEjOGU43yEtiyQXcayfoly5iBoxjVe88s= Received: from gomlefisk.localdomain (173-38-208-170.cisco.com [173.38.208.170]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 4844F6146; Mon, 8 Dec 2014 02:06:27 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gomlefisk.localdomain (Postfix) with ESMTP id 156DE3A8E5B4; Mon, 8 Dec 2014 11:06:25 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ole Troan In-Reply-To: <54820977.4060904@gmail.com> Date: Mon, 8 Dec 2014 11:06:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08DA982D-6605-434B-B815-C69B8A97FA4C@cisco.com> <54820977.4060904@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rj-NW0DLvc8BDKXiYTLFnhjY8wk Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Working Group 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: Mon, 08 Dec 2014 10:06:30 -0000 >>=20 >> 2014-10-27 draft-ietf-v6ops-dhcpv6-slaac-problem = http://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ >=20 > I'm of the party that believes that there is a defect in the IPv6 > specifications in this area that needs to be fixed. I don't care = whether > this draft becomes an RFC, but I do care about the fix. As long as > there's no sign of somebody fixing the specs, I like having this > draft around. since we haven't been able to agree on a fix over the last decade, I = would not recommend for you to hold your breath waiting for one. I do think it is useful to have the implementation report that this = document is around. cheers, Ole= From nobody Mon Dec 8 07:33: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 EF53B1A8769 for ; Mon, 8 Dec 2014 07:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[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, 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 NqIetmdKtA8j for ; Mon, 8 Dec 2014 07:33:21 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c: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 1226F1A1BD1 for ; Mon, 8 Dec 2014 07:33:21 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id bs8so5043769wib.4 for ; Mon, 08 Dec 2014 07:33:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IhZ/qxqeitbl7BV72Ezx1vbR7og1N+Q22Bawe8kzwmw=; b=sx8M5ioM5P3U+6uZ1oTBYCRV7edKKuRWt9j8/jDkY/2+2Dy41y8wfQ1QH4g5uF3GAu esC7iU9zRz5vlvaoyKRbskwpks2VvDO0V/ezdUR6hp5MbyWPd7UcLZjrES73tly+2yEq zcRV7s0NkznsIl//6cIC1p59xKNndJ+oZ1vxoQ7XLiXmWUqKJxSCFtbjASFpgHRSFngi 3K+OiJwD7GKJ9UYdqryoO82C9mEcqEY//bjGmn2vwz9XWlqJLKerCYwP7sJljjzycSQM GkUCtBZfL7+rL3irpbfVJcgJi7xr3VKf/A/E/d3gM9ytVjhVe4FBr1duWF05SCqnCdw3 wlUg== MIME-Version: 1.0 X-Received: by 10.194.185.115 with SMTP id fb19mr46573473wjc.121.1418052799818; Mon, 08 Dec 2014 07:33:19 -0800 (PST) Received: by 10.216.78.5 with HTTP; Mon, 8 Dec 2014 07:33:19 -0800 (PST) In-Reply-To: <20141208094253.308df787@echo.ms.redpill-linpro.com> References: <20141208094253.308df787@echo.ms.redpill-linpro.com> Date: Mon, 8 Dec 2014 07:33:19 -0800 Message-ID: From: Ca By To: Tore Anderson Content-Type: multipart/alternative; boundary=047d7bb70c2a67f3700509b6252d Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Ubh2cfUfSsFbBTobQjWyjlcCnXQ Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-anderson-v6ops-siit-dc-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: Mon, 08 Dec 2014 15:33:23 -0000 --047d7bb70c2a67f3700509b6252d Content-Type: text/plain; charset=UTF-8 On Monday, December 8, 2014, Tore Anderson wrote: > * Ca By > > > > I have read draft-anderson-v6ops-siit-dc-01. > > > > I support the document to be republished as a WG informational document > > with the RFC6145 changes moved into a new document. > > Thank you! > > > I have a one minor comments about draft-anderson-v6ops-siit-dc-01. > > > > The I-D identifies a real network scaling problem where dual-stack is not > > an acceptable solution since it does not allow network operators to > > decouple IPv4 addresses from nodes deployed, thus nodes deployed cannot > > scale beyond IPv4 address holdings with dual-stack. The IETF needs to > > provide better guidance than "dual-stack everything". But, the I-D does > > not address the simplest solution of simply having IPv4 nodes for IPv4 > > traffic and IPv6 nodes for IPv6 traffic. This allows a data center > > operator to get the most usage out of scarce IPv4 nodes since they pick > up > > the IPv4-only users (excluding Apple happy eyeballs!!!) while the IPv6 > > nodes pickup the IPv6 capable users. Now, this approach of IPv4-only > nodes > > and IPv6-only nodes works great when you are Facebook and your smallest > > unit of provisioning is a fully packed rack of gear. If you are a > smaller > > operator, you may not have enough traffic to justify an IPv6-only node, > yet > > you still have to scale nodes beyond IPv4 holdings. There is also the > case > > where uniformity of provisioning is seen as being a higher value than > > having 2 flavor: v4 and v6... thus draft-anderson-v6ops-siit-dc-01 > > certainly fits a need, but it should be context of dual-stack and single > > stack v4 and v6. > > I'm not so sure about having separate IPv4-only and IPv6-only > infrastructures solves anything, actually... > > To continue the Facebook analogy with a rack of IPv4-only frontend > nodes and another rack of IPv6-only frontend nodes that serve IPv4-only > and IPv6-capable users: Presumably all those users need to be shown the > same content, regardless of which IP version they used to request it. > So those IPv4/IPv6-only frontend racks necessarily share a common set > of backend servers - and if they're to be reachable from both the > IPv4-only and the IPv6-only frontend nodes, then the backend nodes must > necessarily be dual-stack. > > Let's assume the backend is ipv6-only. The ipv4-only front-end is in-fact dual stack but it has public v4 in public dns to be reached by clients but no public dns entry on the ipv6 side. This is what allows for the separation of ipv4 and v6 users So we're back to IPv4 being a limiting factor for scaling, and in my > experience the number of backend nodes usually greatly outnumber the > number of frontend nodes so really this is where you primarily would > want to avoid dual-stack. (If we're talking about Facebook or someone > of similar size, dual-stack using RFC1918 for IPv4 in the backend > doesn't necessarily scale well enough either.) > > Tore > --047d7bb70c2a67f3700509b6252d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Monday, December 8, 2014, Tore Anderson <tore@fud.no> wrote:
* C= a By <cb.list6@gmail.com>

> I have read=C2=A0 draft-anderson-v6ops-siit-dc-01.
>
> I support the document to be republished as a WG informational documen= t
> with=C2=A0 the RFC6145 changes=C2=A0 moved into a new document.

Thank you!

> I have a one minor comments about draft-anderson-v6ops-siit-dc-01.
>
> The I-D identifies a real network scaling problem where dual-stack is = not
> an acceptable solution since it does not allow network operators to > decouple IPv4 addresses from nodes deployed, thus nodes deployed canno= t
> scale beyond IPv4 address holdings with dual-stack.=C2=A0 The IETF nee= ds to
> provide better guidance than=C2=A0 "dual-stack everything".= =C2=A0 But, the I-D does
> not address the simplest solution of simply having IPv4 nodes for IPv4=
> traffic and IPv6 nodes for IPv6 traffic.=C2=A0 This allows a data cent= er
> operator to get the most usage out of scarce IPv4 nodes since they pic= k up
> the IPv4-only users (excluding Apple happy eyeballs!!!) while the IPv6=
> nodes pickup the IPv6 capable users.=C2=A0 Now, this approach of IPv4-= only nodes
> and IPv6-only nodes works great when you are Facebook and your smalles= t
> unit of provisioning is a fully packed rack of gear.=C2=A0 If you are = a smaller
> operator, you may not have enough traffic to justify an IPv6-only node= , yet
> you still have to scale nodes beyond IPv4 holdings.=C2=A0 There is als= o the case
> where uniformity of provisioning is seen as being a higher value than<= br> > having 2 flavor: v4 and v6... thus draft-anderson-v6ops-siit-dc-01
> certainly fits a need, but it should be context of dual-stack and sing= le
> stack v4 and v6.

I'm not so sure about having separate IPv4-only and IPv6-only
infrastructures solves anything, actually...

To continue the Facebook analogy with a rack of IPv4-only frontend
nodes and another rack of IPv6-only frontend nodes that serve IPv4-only
and IPv6-capable users: Presumably all those users need to be shown the
same content, regardless of which IP version they used to request it.
So those IPv4/IPv6-only frontend racks necessarily share a common set
of backend servers - and if they're to be reachable from both the
IPv4-only and the IPv6-only frontend nodes, then the backend nodes must
necessarily be dual-stack.


Let's assume the backend is ipv6-o= nly.=C2=A0

The ipv4-only front-end is in-fact dual= stack but it has=C2=A0public v4 in public dns=C2=A0to be reached by client= s but no public dns entry on the ipv6 side.=C2=A0 This is what allows for t= he separation of ipv4 and v6 users=C2=A0


So we're back to IPv4 being a limiting factor for scaling, and in my experience the number of backend nodes usually greatly outnumber the
number of frontend nodes so really this is where you primarily would
want to avoid dual-stack. (If we're talking about Facebook or someone of similar size, dual-stack using RFC1918 for IPv4 in the backend
doesn't necessarily scale well enough either.)

Tore
--047d7bb70c2a67f3700509b6252d-- From nobody Mon Dec 8 08:24: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 A00C01A914B for ; Mon, 8 Dec 2014 08:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 C9o3ODEu2WwO for ; Mon, 8 Dec 2014 08:23:57 -0800 (PST) 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 C8F371A9144 for ; Mon, 8 Dec 2014 08:23:57 -0800 (PST) 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 sB8GNuoT000396; Mon, 8 Dec 2014 10:23:56 -0600 Received: from XCH-BLV-406.nw.nos.boeing.com (xch-blv-406.nw.nos.boeing.com [130.247.25.162]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sB8GNsSl000380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 8 Dec 2014 10:23:55 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-BLV-406.nw.nos.boeing.com ([169.254.6.247]) with mapi id 14.03.0210.002; Mon, 8 Dec 2014 08:23:54 -0800 From: "Templin, Fred L" To: Jeroen Massar , "sthaug@nethelp.no" Thread-Topic: [v6ops] PMTUD forever, was: MTUs on the general Internet Thread-Index: AQHQEJwFpAeu1cDlMEapgQ1gXobqjpyC7YoAgAAEroCAABJggP//uZRwgAMmA/A= Date: Mon, 8 Dec 2014 16:23:53 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DAE093@XCH-BLV-504.nw.nos.boeing.com> References: <5481B5C8.6030501@massar.ch> <2134F8430051B64F815C691A62D9831832DAC16A@XCH-BLV-504.nw.nos.boeing.com> <5482E29A.1070802@massar.ch> <20141206.122039.74658588.sthaug@nethelp.no> <5482F5F1.8000907@massar.ch> <2134F8430051B64F815C691A62D9831832DAD225@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832DAD225@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4zqyd6-G3OxDAZHZdccm0v_UCGM Cc: "v6ops@ietf.org" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 08 Dec 2014 16:23:59 -0000 More on what I said the other day, there are two magic numbers that tunnels need to concern themselves with: 1280 and 1500. Accommodating all packets within that size range while placing no explicit upper bound for accommodat= ing larger packets is what is being proposed. In other words, no MTU clamping. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Saturday, December 06, 2014 8:18 AM > To: Jeroen Massar; sthaug@nethelp.no > Cc: v6ops@ietf.org > Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet >=20 > Hi Jeroen, >=20 > > -----Original Message----- > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Jeroen Massar > > Sent: Saturday, December 06, 2014 4:26 AM > > To: sthaug@nethelp.no > > Cc: v6ops@ietf.org > > Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet > > > > On 2014-12-06 12:20, sthaug@nethelp.no wrote: > > >>> that should be turned off as soon as possible. That will happen as = more > > >>> and more links set MTUs larger than 1500. > > >> > > >> IPv6 should also have been deployed globally as soon as possible... > > > > > > Speaking only for myself: We run with a suitable jumbo MTU on most > > > links *within our AS*. I see no sign of such an increased MTU becomin= g > > > more available on peering and transit links. > > > > Agreed. > > > > IMHO one big reason of which is that there are cases where PMTU does no= t > > work 100% and thus there is no real benefit of enabling larger MTUs as > > it will only give problems (as it is something not well known) and thus > > higher support cost, than creating faster transfers. > > > > Hence, a status quo. >=20 > Yes, the status has been quo for a long time, but we now have an opportun= ity > to move beyond that. If tunnels stop clamping the MTU and end hosts start > using RFC4821 larger MTUs will be possible. The good news is that fixing = the > tunnels and fixing the end hosts can be done independently of one another= . >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > Greets, > > Jeroen > > > > > > _______________________________________________ > > 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 Mon Dec 8 09:47: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 A30941A878A; Mon, 8 Dec 2014 09:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[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 RBketZkhfBB4; Mon, 8 Dec 2014 09:47:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB2A1A8793; Mon, 8 Dec 2014 09:46:59 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141208174659.31462.63459.idtracker@ietfa.amsl.com> Date: Mon, 08 Dec 2014 09:46:59 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4E3EQ6Ez9wNDxvyKdOjR038umhM Cc: v6ops mailing list , v6ops chair , RFC Editor Subject: [v6ops] Document Action: 'Analysis of Failure Cases in IPv6 Roaming Scenarios' to Informational RFC (draft-ietf-v6ops-ipv6-roaming-analysis-07.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, 08 Dec 2014 17:47:05 -0000 The IESG has approved the following document: - 'Analysis of Failure Cases in IPv6 Roaming Scenarios' (draft-ietf-v6ops-ipv6-roaming-analysis-07.txt) as Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Joel Jaeggli and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-roaming-analysis/ Technical Summary This document identifies a set of failure cases that may be encountered by IPv6-enabled mobile customers in roaming scenarios. The analysis reveals that the failure causes include improper configurations, incomplete functionality support in equipment, and inconsistent IPv6 deployment strategies between the home and the visited networks. Working Group Summary China Mobile has been pretty openly discussing what they call "IPv6 Bearer Network Trials" starting at IETF 81. As one might imagine, they had various problems with routing (OSPF issues due to variable MTU, for example) and other operational aspects. They started discussing their issues in roaming at IETF 87, and other operators experimenting with the technology chimed in. This was accepted as a working group draft and discussed at IETF 89, and is now being filed. There has been active discussion on technical points, but little real dispute. Document Quality This is operational experience, and the author list reflects the set of companies reporting experience with it - Deutsche Telekom AG, Rogers, China Mobile, and Orange. Given the range of comments made, the document appears to cover the bases. Note that while the document specifically addresses 3GPP networks, it also comments on 2G and 4G, and by extension LTE. Personnel Document Shepherd: Fred Baker Area Director: Joel Jaeggli From nobody Mon Dec 8 10:13: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 F05181A87B2 for ; Mon, 8 Dec 2014 10:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 RBS-YN8MayXB for ; Mon, 8 Dec 2014 10:13:34 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3C61A879D for ; Mon, 8 Dec 2014 10:13:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2230; q=dns/txt; s=iport; t=1418062414; x=1419272014; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7VMkwF8D7InVl77LA5a6KR8Q463xOaFz8lYW123Dlng=; b=bhNdFJ3nzqfWQFlP1hCVAlYr8mqpKN1bdcKv7vIZ2EhVtKW/Gjz7/Ovn DfZkqUD+EYj2jvSYaicB3zRspRuYbLyWvS+R9tAFku07Lssx2fYDn/g+B JaUXpKRQBv654M4c/1rAkIx83KrbbkUbmo8U57s1HLdjCceczScS/K35N Q=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAPrphVStJA2B/2dsb2JhbABagkNDgS7LeAKBMBYBAQEBAX2DeQoBAQMBeQULAgEIAwEKOCERJQIEDgUOiBYDCQjQRg2FXwEBAQEBAQEBAQEBAQEBAQEBAQEBAReOD4ItB4MhgRUBBI4NgWKBKIRDgUiLcoV4g25vgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,539,1413244800"; d="asc'?scan'208,217";a="378521622" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP; 08 Dec 2014 18:13:16 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sB8IDGLN029616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Dec 2014 18:13:16 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 12:13:16 -0600 From: "Fred Baker (fred)" To: Ca By Thread-Topic: [v6ops] draft-anderson-v6ops-siit-eam-01 Thread-Index: AQHQExKi8mnkC1SXkEiqJSZP0Ohmgg== Date: Mon, 8 Dec 2014 18:13:15 +0000 Message-ID: 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.117] Content-Type: multipart/signed; boundary="Apple-Mail=_3B653D61-C486-47D8-AB0D-191B9AFD8F8F"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8t6pdSPHi_3lSivSo57fFP7sypw Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-anderson-v6ops-siit-eam-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: Mon, 08 Dec 2014 18:13:36 -0000 --Apple-Mail=_3B653D61-C486-47D8-AB0D-191B9AFD8F8F Content-Type: multipart/alternative; boundary="Apple-Mail=_5BD57589-6409-4284-AA9A-7FE747E1A424" --Apple-Mail=_5BD57589-6409-4284-AA9A-7FE747E1A424 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 7, 2014, at 9:43 PM, Ca By wrote: > adding the definitions for IPv4-converted IPv6 addresses and = IPv4-translatable IPv6 addresses.=20 Why would RFC 6052, or a reference to it, not be adequate? --Apple-Mail=_5BD57589-6409-4284-AA9A-7FE747E1A424 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Dec 7, 2014, at 9:43 PM, Ca By <cb.list6@gmail.com> wrote:

adding the definitions for IPv4-converted IPv6 addresses and IPv4-translatable IPv6 addresses. 

Why would RFC 6052, or a reference to it, not be adequate?
--Apple-Mail=_5BD57589-6409-4284-AA9A-7FE747E1A424-- --Apple-Mail=_3B653D61-C486-47D8-AB0D-191B9AFD8F8F 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 iD8DBQFUheo6bjEdbHIsm0MRAshXAKCwd2RCxEI0EnkBfrpUtk9dudEicQCfdgBz x1KKXIgRyxjQV32Ig+osxKg= =6/Rg -----END PGP SIGNATURE----- --Apple-Mail=_3B653D61-C486-47D8-AB0D-191B9AFD8F8F-- From nobody Mon Dec 8 10:18: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 DEFDE1A877E for ; Mon, 8 Dec 2014 10:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 XcghVQNp8AUL for ; Mon, 8 Dec 2014 10:18:51 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDCB11ACD65 for ; Mon, 8 Dec 2014 10:18:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3897; q=dns/txt; s=iport; t=1418062720; x=1419272320; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1HCJjaL9gs2N0M6Farxhn1Plyls+Pf/O4oYOtWQ5UmY=; b=VwCZvMDRfLdGVdPcI3PcmnyzTNEi/aM5WRtTsPm0CxHc2AgbNF4OK706 hO1MIyaun7Mo/6zQwteo/rv2+iCItnZlEmhIVtYoGeDPcJRalqYZq0Wsj a+JJBtbW4kTFtBYPiLRcubOgWJLHNb5Ejt2h3V2aE9nnz2uxtoNm4JcDb M=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFALDqhVStJA2G/2dsb2JhbABagkNDgS7LeAKBMRYBAQEBAX2EAwEBAwF5BQsCAQgECjghESUCBA4FDogWAwkI0E4NhV8BAQEBAQEBAQEBAQEBAQEBAQEBAQEXjg+CLQeDIYEVAQSODYFigSiEQ4FIi3KFeINub4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,539,1413244800"; d="asc'?scan'208,217";a="103737637" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP; 08 Dec 2014 18:18:39 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sB8IIdLt019278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Dec 2014 18:18:39 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 12:18:38 -0600 From: "Fred Baker (fred)" To: Ca By Thread-Topic: [v6ops] draft-anderson-v6ops-siit-eam-01 Thread-Index: AQHQExNiO16xnSUTkkeJpUKGW6r6mw== Date: Mon, 8 Dec 2014 18:18:37 +0000 Message-ID: <7E5C6A8D-A7E5-4B2A-9865-CE73E207AF76@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.117] Content-Type: multipart/signed; boundary="Apple-Mail=_10EBFA27-9E44-4910-8F52-6CF9DD4FB33C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/iz0ociEVyz_rGol2U5EfjEB3WHk Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-anderson-v6ops-siit-eam-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: Mon, 08 Dec 2014 18:18:54 -0000 --Apple-Mail=_10EBFA27-9E44-4910-8F52-6CF9DD4FB33C Content-Type: multipart/alternative; boundary="Apple-Mail=_CDFD1DD2-EE72-4D77-8040-948776ABCFEC" --Apple-Mail=_CDFD1DD2-EE72-4D77-8040-948776ABCFEC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 7, 2014, at 9:43 PM, Ca By wrote: > I don't like the word "substituting" since a reader my believe that = one simply does a substitution of the IPv4 address for the IPv6. It = would be more precises to continuing using the term translate which = explicitly references the packet treatment procedure in SIIT. Perhaps = rephrase to "... MUST be translated to IPv6 in accordance with the = EAMT=85" As I understand it, Tore is *not* translating in the sense of embedding = the IPv4 address into an IPv6 prefix as described in RFCs 6052 and 6145. = Rather, he is doing a table lookup as described in RFC 6146 and using = the IPv6 address found in the table. The differences between this and = RFC 6146 are: - 6146 describes translation of TCP/UDP sessions, including their = ports. This is at the IP layer. - 6146 describes the possibility of pre-defining a static mapping = between an IPv4 and an IPv6 address, but doesn=92t say much about it. = This depends on it. --Apple-Mail=_CDFD1DD2-EE72-4D77-8040-948776ABCFEC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Dec 7, 2014, at 9:43 PM, Ca By = <cb.list6@gmail.com> = wrote:

I = don't like the word "substituting" since a reader my believe that one = simply does  a substitution of the IPv4 address for the IPv6.  = It would be more precises to continuing using the term translate which = explicitly references the packet treatment procedure in SIIT.  = Perhaps rephrase to "... MUST be translated to IPv6 in accordance = with the EAMT=85"

As I understand it, = Tore is *not* translating in the sense of embedding the IPv4 address = into an IPv6 prefix as described in RFCs 6052 and 6145. Rather, he is = doing a table lookup as described in RFC 6146 and using the IPv6 address = found in the table. The differences between this and RFC 6146 = are:

  - 6146 describes translation of = TCP/UDP sessions, including their ports. This is at the IP = layer.
  - 6146 describes the possibility of pre-defining = a static mapping between an IPv4 and an IPv6 address, but doesn=92t say = much about it. This depends on it.

= --Apple-Mail=_CDFD1DD2-EE72-4D77-8040-948776ABCFEC-- --Apple-Mail=_10EBFA27-9E44-4910-8F52-6CF9DD4FB33C 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 iD8DBQFUhet8bjEdbHIsm0MRAmHgAJ0XWcqAT7hEeM+AhwGWWMwT3/g8PgCg7Py1 fJbZQ+uo0R+27gvTFdK3/Hk= =OP6f -----END PGP SIGNATURE----- --Apple-Mail=_10EBFA27-9E44-4910-8F52-6CF9DD4FB33C-- From nobody Mon Dec 8 11:28: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 A626C1ACDDD for ; Mon, 8 Dec 2014 11:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 yPTkBAiLlhi2 for ; Mon, 8 Dec 2014 11:28:36 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c: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 548B91ACDB9 for ; Mon, 8 Dec 2014 11:28:36 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id bs8so5690595wib.10 for ; Mon, 08 Dec 2014 11:28:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=c3lzZ8BEzYT3U5RCMIEC5wIwvxiTUhlqs96lJukPL9o=; b=WgxXOWwVjk57WIWVbpSPbaLZpdvoDsbxvKE5AEZKZ8lZUOoQFaTsftXDCxeMqp3O5o zYCuFvfrd0WatTj+NON8k+d9YW1fh7fkHjgjtBd0otS8r4a3X0Yd8CRjbLBqF1WoRxZo kRlBW8ulCHBVTgL+l2EybK5wBKdFmjdfxr7dtwFObmKtKlGO2XduMifuyvR9OVlDnoa0 kgHiZJH61Xb/V5juFDwu3twm/wrJJqIMGR8/nt8lH7RBVBOjXIogZuFmD2bAwYOZIoj1 4RoTEPq4oGDzhV+yKWqYaJwM9OOiCWgnpvDTCmU4LCYCKrRjN+X3C9AopV/E8cbpXIiG Qu4w== X-Received: by 10.180.182.226 with SMTP id eh2mr19057566wic.9.1418066915187; Mon, 08 Dec 2014 11:28:35 -0800 (PST) Received: from [127.0.0.1] (mry91-1-82-229-156-225.fbx.proxad.net. [82.229.156.225]) by mx.google.com with ESMTPSA id bs2sm40570070wjc.43.2014.12.08.11.28.33 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Dec 2014 11:28:34 -0800 (PST) Message-ID: <5485FBD7.6050807@gmail.com> Date: Mon, 08 Dec 2014 20:28:23 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: v6ops@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 141207-2, 07/12/2014), Outbound message X-Antivirus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/TOXferkmbuHTrJdd2N604elhJ0M Subject: Re: [v6ops] On IPv6 address part naming 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, 08 Dec 2014 19:28:41 -0000 netgear user manual calls it a "quartet": "IPv6 addresses are denoted by eight groups of hexadecimal quartets separated by colons" Alex --- L'absence de virus dans ce courrier =C3=A9lectronique a =C3=A9t=C3=A9 v=C3= =A9rifi=C3=A9e par le logiciel antivirus Avast. http://www.avast.com From nobody Tue Dec 9 01: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 1DC4B1A1AA5 for ; Tue, 9 Dec 2014 01:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 33CgdJOCQlrr for ; Tue, 9 Dec 2014 01:37:22 -0800 (PST) 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 19C4C1A00BB for ; Tue, 9 Dec 2014 01:37:22 -0800 (PST) Received: from [2a02:c0:2:4:6666:17:0:1001] (port=48664 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1XyHEN-0001pN-GQ; Tue, 09 Dec 2014 10:37:19 +0100 Date: Tue, 9 Dec 2014 10:37:06 +0100 From: Tore Anderson To: Ca By Message-ID: <20141209103706.2beb9c9a@echo.ms.redpill-linpro.com> In-Reply-To: References: <20141208094253.308df787@echo.ms.redpill-linpro.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.24; x86_64-redhat-linux-gnu) 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/7EgDZXeoo9amVghOdUWld1NLehs Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-anderson-v6ops-siit-dc-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: Tue, 09 Dec 2014 09:37:24 -0000 * Ca By > On Monday, December 8, 2014, Tore Anderson wrote: >=20 > > * Ca By > > > > > > I have a one minor comments about draft-anderson-v6ops-siit-dc-01. > > > > > > The I-D identifies a real network scaling problem where > > > dual-stack is not an acceptable solution since it does not allow > > > network operators to decouple IPv4 addresses from nodes deployed, > > > thus nodes deployed cannot scale beyond IPv4 address holdings > > > with dual-stack. The IETF needs to provide better guidance than > > > "dual-stack everything". But, the I-D does not address the > > > simplest solution of simply having IPv4 nodes for IPv4 traffic > > > and IPv6 nodes for IPv6 traffic. This allows a data center > > > operator to get the most usage out of scarce IPv4 nodes since > > > they pick up the IPv4-only users (excluding Apple happy > > > eyeballs!!!) while the IPv6 nodes pickup the IPv6 capable users. > > > Now, this approach of IPv4-only nodes and IPv6-only nodes works > > > great when you are Facebook and your smallest unit of > > > provisioning is a fully packed rack of gear. If you are a > > > smaller operator, you may not have enough traffic to justify an > > > IPv6-only node, yet you still have to scale nodes beyond IPv4 > > > holdings. There is also the case where uniformity of > > > provisioning is seen as being a higher value than having 2 > > > flavor: v4 and v6... thus draft-anderson-v6ops-siit-dc-01 > > > certainly fits a need, but it should be context of dual-stack and > > > single stack v4 and v6. > > > > I'm not so sure about having separate IPv4-only and IPv6-only > > infrastructures solves anything, actually... > > > > To continue the Facebook analogy with a rack of IPv4-only frontend > > nodes and another rack of IPv6-only frontend nodes that serve > > IPv4-only and IPv6-capable users: Presumably all those users need > > to be shown the same content, regardless of which IP version they > > used to request it. So those IPv4/IPv6-only frontend racks > > necessarily share a common set of backend servers - and if they're > > to be reachable from both the IPv4-only and the IPv6-only frontend > > nodes, then the backend nodes must necessarily be dual-stack. > > > > > Let's assume the backend is ipv6-only. >=20 > The ipv4-only front-end is in-fact dual stack but it has public v4 in > public dns to be reached by clients but no public dns entry on the > ipv6 side. This is what allows for the separation of ipv4 and v6 > users I see. I think I'd call this =C2=ABPartial dual-stack=C2=BB or somthing lik= e it. I don't think there is a material difference between having a single set of dual-stacked frontends, or two separate sets of frontends (one IPv6-only serving IPv6 users and the other dual-stack serving IPv4 users). The properties of such a solution remains the same, essentially: The Good: * No translation, so end-to-end principle remains intact.. * Compatible with all application protocols * Alleviates IPv4 address scarcity to almost the same extent as SIIT-DC but not quite (as IPv4 addresses are still required for non-service purposes like the DC network infrastrucuture and some might go to wast due to subnets being rounded up to the next CIDR boundary). The Bad: * You still dual-stack in places, resulting in increased complexity. Apart from the frontend servers themselves and the applications running on them, this also applies to the DC network infrastructure, including any firewalls, ACLs, load balancers, etc. * Can't support any IPv4-only application software, application protocols, or devices in the backend. I'm thinking I could write up a separate appendix B.5 to describe this. Tore From nobody Tue Dec 9 02:35: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 DA9551A1AE5 for ; Tue, 9 Dec 2014 02:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 KEycGcGUv-Q5 for ; Tue, 9 Dec 2014 02:35:14 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1F6B1A1ADB for ; Tue, 9 Dec 2014 02:35:13 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id f15so242407lbj.41 for ; Tue, 09 Dec 2014 02:35:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=vXbkf7UDi7XMJNFH2E4DjHBBwyddQLCgTsvs+/QAa/Q=; b=wQShg0MMgLA0ff882dX0katMvTeNOa2Jq3lotanRzhaoSyxa+eR4+zlSr2GYRNv+7R ZB58hmheGu1N1BLHXlRk5jh+awlhG5Zr1uDJ/XWUfMZlml9JfGqa9DKKCLPVSRARiSzC lQziMMjLH6uKuTnhqYtDHNVYnPTt1ljWBqxT4wTCetChJPd0L4nM6UadSM9n3IaCTqCG J1HPDDyG+KE9OMWSkVRCQqf6IENORg4uoFYjaFybpGMhGOQLa95b2IGs52PJp67Jn8f0 Vl/lg3RWEKzOTQfsYFisH4788ZeslLZ5fO14Sy6NVuHa+QcfjjDW0s2o1WgG7vhZsagR Qeqw== MIME-Version: 1.0 X-Received: by 10.152.205.11 with SMTP id lc11mr21131798lac.34.1418121312140; Tue, 09 Dec 2014 02:35:12 -0800 (PST) Received: by 10.114.4.132 with HTTP; Tue, 9 Dec 2014 02:35:12 -0800 (PST) In-Reply-To: References: Date: Tue, 9 Dec 2014 15:35:12 +0500 Message-ID: From: Tariq Saraj To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=001a1133a8180f05870509c61981 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/AyhHKTGN_jbs6EM5C_7uEVgP09w Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 34 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, 09 Dec 2014 10:35:21 -0000 --001a1133a8180f05870509c61981 Content-Type: text/plain; charset=UTF-8 I don't understand the reason for discussion on SIIT when IVI is there. The flaws are addressed and mitigated in IVI. On Mon, Dec 8, 2014 at 10:47 PM, 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: draft-anderson-v6ops-siit-eam-01 (Tore Anderson) > 2. Re: draft-anderson-v6ops-siit-dc-01 (Tore Anderson) > 3. Re: Working Group Administrivia (Ole Troan) > 4. Re: draft-anderson-v6ops-siit-dc-01 (Ca By) > 5. Re: PMTUD forever, was: MTUs on the general Internet > (Templin, Fred L) > 6. Document Action: 'Analysis of Failure Cases in IPv6 Roaming > Scenarios' to Informational RFC > (draft-ietf-v6ops-ipv6-roaming-analysis-07.txt) (The IESG) > > > ---------- Forwarded message ---------- > From: Tore Anderson > To: Ca By > Cc: IPv6 Ops WG > Date: Mon, 8 Dec 2014 09:27:46 +0100 > Subject: Re: [v6ops] draft-anderson-v6ops-siit-eam-01 > Hi Cameron, > > > I have read draft-anderson-v6ops-siit-eam-01 > > > > I support the working group adopting this document, this is helpful and > > meaningful work. > > > > I have a few comments that are mostly editorial in nature, i believe the > > document is technically sound as written today. > > Thank you! > > > Purely editorial, i suggest locally adding the definitions > > for IPv4-converted IPv6 addresses and IPv4-translatable IPv6 addresses. > If > > you are taking up space to define them, then go ahead and do the reader > the > > favor of defining them. > > > > In section 3.2 there is this sentence: "If a matching > > EAM entry is found, the address MUST be translated to IPv6 by > > substituting its IPv4 Prefix value for the corresponding IPv6 > > Prefix from the EAM entry." > > > > I don't like the word "substituting" since a reader my believe that one > > simply does a substitution of the IPv4 address for the IPv6. It would > be > > more precises to continuing using the term translate which explicitly > > references the packet treatment procedure in SIIT. Perhaps rephrase to > > "... MUST be translated to IPv6 in accordance with the EAMT..." > > This text has undergone a lot of back and forth between myself and > another reviewer (Alberto Leiva). The problem he identified with saying > something like what you propose, is that it fails to say *exactly* what > should happen. Say you have $addr="192.0.2.123", $eam4="192.0.2.0/24", > $eam6="2001:db8::/112". Now what? You have those three pieces of > information, but nothing saying how those should be combined or > manipulated to form a new IPv6 address. > > You could certainly say that it goes without saying and needs no further > explanation, but Alberto thought it was best if it was explicit and as > clear as possible. That's why we landed on "substitute", the reasoning > is that if you start out with $addr="192.0.2.123", then you first take > away the prefix bits found in $eam4, temporarily leaving you with > $addr=".123" (i.e., "0x7b"), and then putting in the $eam6 prefix bits > instead, leaving you with $addr="2001:db8::7b", and you're done. So > what you do, essentially, is to substitute the EAM4 prefix for the EAM6 > prefix. (If you're familiar with Perl, the pseudocode would go something > like "$addr =~ s/^$eam4/$eam6/".) > > That said, I'm not terribly happy with the current text either. If you > or anyone else have any suggestions on how to make it better and > clearer, while still remaining explicit about the procedure/algorithm, > that would be much appreciated. > > Tore > > > > > ---------- Forwarded message ---------- > From: Tore Anderson > To: Ca By > Cc: IPv6 Ops WG > Date: Mon, 8 Dec 2014 09:42:53 +0100 > Subject: Re: [v6ops] draft-anderson-v6ops-siit-dc-01 > * Ca By > > > I have read draft-anderson-v6ops-siit-dc-01. > > > > I support the document to be republished as a WG informational document > > with the RFC6145 changes moved into a new document. > > Thank you! > > > I have a one minor comments about draft-anderson-v6ops-siit-dc-01. > > > > The I-D identifies a real network scaling problem where dual-stack is not > > an acceptable solution since it does not allow network operators to > > decouple IPv4 addresses from nodes deployed, thus nodes deployed cannot > > scale beyond IPv4 address holdings with dual-stack. The IETF needs to > > provide better guidance than "dual-stack everything". But, the I-D does > > not address the simplest solution of simply having IPv4 nodes for IPv4 > > traffic and IPv6 nodes for IPv6 traffic. This allows a data center > > operator to get the most usage out of scarce IPv4 nodes since they pick > up > > the IPv4-only users (excluding Apple happy eyeballs!!!) while the IPv6 > > nodes pickup the IPv6 capable users. Now, this approach of IPv4-only > nodes > > and IPv6-only nodes works great when you are Facebook and your smallest > > unit of provisioning is a fully packed rack of gear. If you are a > smaller > > operator, you may not have enough traffic to justify an IPv6-only node, > yet > > you still have to scale nodes beyond IPv4 holdings. There is also the > case > > where uniformity of provisioning is seen as being a higher value than > > having 2 flavor: v4 and v6... thus draft-anderson-v6ops-siit-dc-01 > > certainly fits a need, but it should be context of dual-stack and single > > stack v4 and v6. > > I'm not so sure about having separate IPv4-only and IPv6-only > infrastructures solves anything, actually... > > To continue the Facebook analogy with a rack of IPv4-only frontend > nodes and another rack of IPv6-only frontend nodes that serve IPv4-only > and IPv6-capable users: Presumably all those users need to be shown the > same content, regardless of which IP version they used to request it. > So those IPv4/IPv6-only frontend racks necessarily share a common set > of backend servers - and if they're to be reachable from both the > IPv4-only and the IPv6-only frontend nodes, then the backend nodes must > necessarily be dual-stack. > > So we're back to IPv4 being a limiting factor for scaling, and in my > experience the number of backend nodes usually greatly outnumber the > number of frontend nodes so really this is where you primarily would > want to avoid dual-stack. (If we're talking about Facebook or someone > of similar size, dual-stack using RFC1918 for IPv4 in the backend > doesn't necessarily scale well enough either.) > > Tore > > > > > ---------- Forwarded message ---------- > From: Ole Troan > To: Brian E Carpenter > Cc: "v6ops@ietf.org WG" > Date: Mon, 8 Dec 2014 11:06:24 +0100 > Subject: Re: [v6ops] Working Group Administrivia > >> > >> 2014-10-27 draft-ietf-v6ops-dhcpv6-slaac-problem > http://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ > > > > I'm of the party that believes that there is a defect in the IPv6 > > specifications in this area that needs to be fixed. I don't care whether > > this draft becomes an RFC, but I do care about the fix. As long as > > there's no sign of somebody fixing the specs, I like having this > > draft around. > > since we haven't been able to agree on a fix over the last decade, I would > not recommend for you to hold your breath waiting for one. > > I do think it is useful to have the implementation report that this > document is around. > > cheers, > Ole > > > > ---------- Forwarded message ---------- > From: Ca By > To: Tore Anderson > Cc: IPv6 Ops WG > Date: Mon, 8 Dec 2014 07:33:19 -0800 > Subject: Re: [v6ops] draft-anderson-v6ops-siit-dc-01 > > > On Monday, December 8, 2014, Tore Anderson wrote: > >> * Ca By >> >> > I have read draft-anderson-v6ops-siit-dc-01. >> > >> > I support the document to be republished as a WG informational document >> > with the RFC6145 changes moved into a new document. >> >> Thank you! >> >> > I have a one minor comments about draft-anderson-v6ops-siit-dc-01. >> > >> > The I-D identifies a real network scaling problem where dual-stack is >> not >> > an acceptable solution since it does not allow network operators to >> > decouple IPv4 addresses from nodes deployed, thus nodes deployed cannot >> > scale beyond IPv4 address holdings with dual-stack. The IETF needs to >> > provide better guidance than "dual-stack everything". But, the I-D >> does >> > not address the simplest solution of simply having IPv4 nodes for IPv4 >> > traffic and IPv6 nodes for IPv6 traffic. This allows a data center >> > operator to get the most usage out of scarce IPv4 nodes since they pick >> up >> > the IPv4-only users (excluding Apple happy eyeballs!!!) while the IPv6 >> > nodes pickup the IPv6 capable users. Now, this approach of IPv4-only >> nodes >> > and IPv6-only nodes works great when you are Facebook and your smallest >> > unit of provisioning is a fully packed rack of gear. If you are a >> smaller >> > operator, you may not have enough traffic to justify an IPv6-only node, >> yet >> > you still have to scale nodes beyond IPv4 holdings. There is also the >> case >> > where uniformity of provisioning is seen as being a higher value than >> > having 2 flavor: v4 and v6... thus draft-anderson-v6ops-siit-dc-01 >> > certainly fits a need, but it should be context of dual-stack and single >> > stack v4 and v6. >> >> I'm not so sure about having separate IPv4-only and IPv6-only >> infrastructures solves anything, actually... >> >> To continue the Facebook analogy with a rack of IPv4-only frontend >> nodes and another rack of IPv6-only frontend nodes that serve IPv4-only >> and IPv6-capable users: Presumably all those users need to be shown the >> same content, regardless of which IP version they used to request it. >> So those IPv4/IPv6-only frontend racks necessarily share a common set >> of backend servers - and if they're to be reachable from both the >> IPv4-only and the IPv6-only frontend nodes, then the backend nodes must >> necessarily be dual-stack. >> >> > Let's assume the backend is ipv6-only. > > The ipv4-only front-end is in-fact dual stack but it has public v4 in > public dns to be reached by clients but no public dns entry on the ipv6 > side. This is what allows for the separation of ipv4 and v6 users > > > So we're back to IPv4 being a limiting factor for scaling, and in my >> experience the number of backend nodes usually greatly outnumber the >> number of frontend nodes so really this is where you primarily would >> want to avoid dual-stack. (If we're talking about Facebook or someone >> of similar size, dual-stack using RFC1918 for IPv4 in the backend >> doesn't necessarily scale well enough either.) >> >> Tore >> > > > ---------- Forwarded message ---------- > From: "Templin, Fred L" > To: Jeroen Massar , "sthaug@nethelp.no" < > sthaug@nethelp.no> > Cc: "v6ops@ietf.org" > Date: Mon, 8 Dec 2014 16:23:53 +0000 > Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet > More on what I said the other day, there are two magic numbers that tunnels > need to concern themselves with: 1280 and 1500. Accommodating all packets > within that size range while placing no explicit upper bound for > accommodating > larger packets is what is being proposed. In other words, no MTU clamping. > > Thanks - Fred > fred.l.templin@boeing.com > > > > -----Original Message----- > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L > > Sent: Saturday, December 06, 2014 8:18 AM > > To: Jeroen Massar; sthaug@nethelp.no > > Cc: v6ops@ietf.org > > Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet > > > > Hi Jeroen, > > > > > -----Original Message----- > > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Jeroen Massar > > > Sent: Saturday, December 06, 2014 4:26 AM > > > To: sthaug@nethelp.no > > > Cc: v6ops@ietf.org > > > Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet > > > > > > On 2014-12-06 12:20, sthaug@nethelp.no wrote: > > > >>> that should be turned off as soon as possible. That will happen as > more > > > >>> and more links set MTUs larger than 1500. > > > >> > > > >> IPv6 should also have been deployed globally as soon as possible... > > > > > > > > Speaking only for myself: We run with a suitable jumbo MTU on most > > > > links *within our AS*. I see no sign of such an increased MTU > becoming > > > > more available on peering and transit links. > > > > > > Agreed. > > > > > > IMHO one big reason of which is that there are cases where PMTU does > not > > > work 100% and thus there is no real benefit of enabling larger MTUs as > > > it will only give problems (as it is something not well known) and thus > > > higher support cost, than creating faster transfers. > > > > > > Hence, a status quo. > > > > Yes, the status has been quo for a long time, but we now have an > opportunity > > to move beyond that. If tunnels stop clamping the MTU and end hosts start > > using RFC4821 larger MTUs will be possible. The good news is that fixing > the > > tunnels and fixing the end hosts can be done independently of one > another. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > Greets, > > > Jeroen > > > > > > > > > _______________________________________________ > > > 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 > > > > > ---------- Forwarded message ---------- > From: The IESG > To: IETF-Announce > Cc: v6ops mailing list , v6ops chair < > v6ops-chairs@tools.ietf.org>, RFC Editor > Date: Mon, 08 Dec 2014 09:46:59 -0800 > Subject: [v6ops] Document Action: 'Analysis of Failure Cases in IPv6 > Roaming Scenarios' to Informational RFC > (draft-ietf-v6ops-ipv6-roaming-analysis-07.txt) > The IESG has approved the following document: > - 'Analysis of Failure Cases in IPv6 Roaming Scenarios' > (draft-ietf-v6ops-ipv6-roaming-analysis-07.txt) as Informational RFC > > This document is the product of the IPv6 Operations Working Group. > > The IESG contact persons are Joel Jaeggli and Benoit Claise. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-roaming-analysis/ > > > > > > Technical Summary > > This document identifies a set of failure cases that may be > encountered by IPv6-enabled mobile customers in roaming scenarios. > The analysis reveals that the failure causes include improper > configurations, incomplete functionality support in equipment, and > inconsistent IPv6 deployment strategies between the home and the > visited networks. > > Working Group Summary > > China Mobile has been pretty openly discussing what they call "IPv6 > Bearer Network Trials" starting at IETF 81. As one might imagine, they > had various problems with routing (OSPF issues due to variable MTU, > for example) and other operational aspects. They started discussing > their issues in roaming at IETF 87, and other operators experimenting > with the technology chimed in. This was accepted as a working group > draft and discussed at IETF 89, and is now being filed. There has been > active discussion on technical points, but little real dispute. > > Document Quality > > This is operational experience, and the author list reflects the set > of companies reporting experience with it - Deutsche Telekom AG, > Rogers, China Mobile, and Orange. Given the range of comments made, > the document appears to cover the bases. > > Note that while the document specifically addresses 3GPP networks, it > also comments on 2G and 4G, and by extension LTE. > > Personnel > > Document Shepherd: Fred Baker Area Director: Joel Jaeggli > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > -- Regards Tariq Saraj Center for Research in Networks and Telecom (*CoReNeT*) --001a1133a8180f05870509c61981 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't understand the reason for discussion on SIIT w= hen IVI is there. The flaws are addressed and mitigated in IVI.=C2=A0
=

On Mon, Dec 8, 20= 14 at 10:47 PM, <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: draft-anderson-v6ops-siit-eam-01 (Tore Anderson)
=C2=A0 =C2=A02. Re: draft-anderson-v6ops-siit-dc-01 (Tore Anderson)
=C2=A0 =C2=A03. Re: Working Group Administrivia (Ole Troan)
=C2=A0 =C2=A04. Re: draft-anderson-v6ops-siit-dc-01 (Ca By)
=C2=A0 =C2=A05. Re: PMTUD forever, was: MTUs on the general Internet
=C2=A0 =C2=A0 =C2=A0 (Templin, Fred L)
=C2=A0 =C2=A06. Document Action: 'Analysis of Failure Cases in IPv6 Roa= ming
=C2=A0 =C2=A0 =C2=A0 Scenarios' to Informational RFC
=C2=A0 =C2=A0 =C2=A0 (draft-ietf-v6ops-ipv6-roaming-analysis-07.txt) (The I= ESG)


---------- Forwarded message ----------
From:=C2=A0Tore Anderson= <tore@fud.no>
To:=C2=A0Ca By &= lt;cb.list6@gmail.com>
Cc:= =C2=A0IPv6 Ops WG <v6ops@ietf.org&= gt;
Date:=C2=A0Mon, 8 Dec 2014 09:27:46 +0100
Subject:=C2=A0Re: [v6op= s] draft-anderson-v6ops-siit-eam-01
Hi Cameron,

> I have read draft-anderson-v6ops-siit-eam-01
>
> I support the working group adopting this document, this is helpful an= d
> meaningful work.
>
> I have a few comments that are mostly editorial in nature, i believe t= he
> document is technically sound as written today.

Thank you!

> Purely editorial, i suggest locally adding the definitions
> for IPv4-converted IPv6 addresses and IPv4-translatable IPv6 addresses= .=C2=A0 If
> you are taking up space to define them, then go ahead and do the reade= r the
> favor of defining them.
>
> In section 3.2 there is this sentence:=C2=A0 "If a matching
>=C2=A0 =C2=A0 =C2=A0 =C2=A0EAM entry is found, the address MUST be tran= slated to IPv6 by
>=C2=A0 =C2=A0 =C2=A0 =C2=A0substituting its IPv4 Prefix value for the c= orresponding IPv6
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Prefix from the EAM entry."
>
> I don't like the word "substituting" since a reader my b= elieve that one
> simply does=C2=A0 a substitution of the IPv4 address for the IPv6.=C2= =A0 It would be
> more precises to continuing using the term translate which explicitly<= br> > references the packet treatment procedure in SIIT.=C2=A0 Perhaps rephr= ase to
> "... MUST be translated to IPv6 in accordance with the EAMT...&qu= ot;

This text has undergone a lot of back and forth between myself and
another reviewer (Alberto Leiva). The problem he identified with saying
something like what you propose, is that it fails to say *exactly* what
should happen. Say you have $addr=3D"192.0.2.123", $eam4=3D"= 192.0.2.0/24", $eam6=3D"2001:db8::/112". Now what? You have those three pieces o= f
information, but nothing saying how those should be combined or
manipulated to form a new IPv6 address.

You could certainly say that it goes without saying and needs no further explanation, but Alberto thought it was best if it was explicit and as
clear as possible. That's why we landed on "substitute", the = reasoning
is that if you start out with $addr=3D"192.0.2.123", then you fir= st take
away the prefix bits found in $eam4, temporarily leaving you with
$addr=3D".123" (i.e., "0x7b"), and then putting in the = $eam6 prefix bits
instead, leaving you with $addr=3D"2001:db8::7b", and you're = done. So
what you do, essentially, is to substitute the EAM4 prefix for the EAM6
prefix. (If you're familiar with Perl, the pseudocode would go somethin= g
like "$addr =3D~ s/^$eam4/$eam6/".)

That said, I'm not terribly happy with the current text either. If you<= br> or anyone else have any suggestions on how to make it better and
clearer, while still remaining explicit about the procedure/algorithm,
that would be much appreciated.

Tore




---------- Forwarded message ----------
From:=C2=A0Tore Anderson= <tore@fud.no>
To:=C2=A0Ca By &= lt;cb.list6@gmail.com>
Cc:= =C2=A0IPv6 Ops WG <v6ops@ietf.org&= gt;
Date:=C2=A0Mon, 8 Dec 2014 09:42:53 +0100
Subject:=C2=A0Re: [v6op= s] draft-anderson-v6ops-siit-dc-01
* Ca By <cb.list6@gmail.com>

> I have read=C2=A0 draft-anderson-v6ops-siit-dc-01.
>
> I support the document to be republished as a WG informational documen= t
> with=C2=A0 the RFC6145 changes=C2=A0 moved into a new document.

Thank you!

> I have a one minor comments about draft-anderson-v6ops-siit-dc-01.
>
> The I-D identifies a real network scaling problem where dual-stack is = not
> an acceptable solution since it does not allow network operators to > decouple IPv4 addresses from nodes deployed, thus nodes deployed canno= t
> scale beyond IPv4 address holdings with dual-stack.=C2=A0 The IETF nee= ds to
> provide better guidance than=C2=A0 "dual-stack everything".= =C2=A0 But, the I-D does
> not address the simplest solution of simply having IPv4 nodes for IPv4=
> traffic and IPv6 nodes for IPv6 traffic.=C2=A0 This allows a data cent= er
> operator to get the most usage out of scarce IPv4 nodes since they pic= k up
> the IPv4-only users (excluding Apple happy eyeballs!!!) while the IPv6=
> nodes pickup the IPv6 capable users.=C2=A0 Now, this approach of IPv4-= only nodes
> and IPv6-only nodes works great when you are Facebook and your smalles= t
> unit of provisioning is a fully packed rack of gear.=C2=A0 If you are = a smaller
> operator, you may not have enough traffic to justify an IPv6-only node= , yet
> you still have to scale nodes beyond IPv4 holdings.=C2=A0 There is als= o the case
> where uniformity of provisioning is seen as being a higher value than<= br> > having 2 flavor: v4 and v6... thus draft-anderson-v6ops-siit-dc-01
> certainly fits a need, but it should be context of dual-stack and sing= le
> stack v4 and v6.

I'm not so sure about having separate IPv4-only and IPv6-only
infrastructures solves anything, actually...

To continue the Facebook analogy with a rack of IPv4-only frontend
nodes and another rack of IPv6-only frontend nodes that serve IPv4-only
and IPv6-capable users: Presumably all those users need to be shown the
same content, regardless of which IP version they used to request it.
So those IPv4/IPv6-only frontend racks necessarily share a common set
of backend servers - and if they're to be reachable from both the
IPv4-only and the IPv6-only frontend nodes, then the backend nodes must
necessarily be dual-stack.

So we're back to IPv4 being a limiting factor for scaling, and in my experience the number of backend nodes usually greatly outnumber the
number of frontend nodes so really this is where you primarily would
want to avoid dual-stack. (If we're talking about Facebook or someone of similar size, dual-stack using RFC1918 for IPv4 in the backend
doesn't necessarily scale well enough either.)

Tore




---------- Forwarded message ----------
From:=C2=A0Ole Troan <= ;otroan@employees.org>
To= :=C2=A0Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc:=C2=A0"v6ops@ietf.org WG" <v6ops@ietf.org>
Date:=C2=A0Mon, 8 Dec 2014 11:06:24 +0100Subject:=C2=A0Re: [v6ops] Working Group Administrivia
>>
>> 2014-10-27=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-v6op= s-dhcpv6-slaac-problem=C2=A0 =C2=A0 =C2=A0 http:/= /datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/
>
> I'm of the party that believes that there is a defect in the IPv6<= br> > specifications in this area that needs to be fixed. I don't care w= hether
> this draft becomes an RFC, but I do care about the fix. As long as
> there's no sign of somebody fixing the specs, I like having this > draft around.

since we haven't been able to agree on a fix over the last decade, I wo= uld not recommend for you to hold your breath waiting for one.

I do think it is useful to have the implementation report that this documen= t is around.

cheers,
Ole



---------- Forwarded message ----------
From:=C2=A0Ca By <cb.list6@gmail.com>
To:=C2=A0T= ore Anderson <tore@fud.no>
Cc:= =C2=A0IPv6 Ops WG <v6ops@ietf.org&= gt;
Date:=C2=A0Mon, 8 Dec 2014 07:33:19 -0800
Subject:=C2=A0Re: [v6op= s] draft-anderson-v6ops-siit-dc-01


On Monday, December 8, 2014, = Tore Anderson <tore@fud= .no> wrote:
* Ca By <cb.list= 6@gmail.com>

> I have read=C2=A0 draft-anderson-v6ops-siit-dc-01.
>
> I support the document to be republished as a WG informational documen= t
> with=C2=A0 the RFC6145 changes=C2=A0 moved into a new document.

Thank you!

> I have a one minor comments about draft-anderson-v6ops-siit-dc-01.
>
> The I-D identifies a real network scaling problem where dual-stack is = not
> an acceptable solution since it does not allow network operators to > decouple IPv4 addresses from nodes deployed, thus nodes deployed canno= t
> scale beyond IPv4 address holdings with dual-stack.=C2=A0 The IETF nee= ds to
> provide better guidance than=C2=A0 "dual-stack everything".= =C2=A0 But, the I-D does
> not address the simplest solution of simply having IPv4 nodes for IPv4=
> traffic and IPv6 nodes for IPv6 traffic.=C2=A0 This allows a data cent= er
> operator to get the most usage out of scarce IPv4 nodes since they pic= k up
> the IPv4-only users (excluding Apple happy eyeballs!!!) while the IPv6=
> nodes pickup the IPv6 capable users.=C2=A0 Now, this approach of IPv4-= only nodes
> and IPv6-only nodes works great when you are Facebook and your smalles= t
> unit of provisioning is a fully packed rack of gear.=C2=A0 If you are = a smaller
> operator, you may not have enough traffic to justify an IPv6-only node= , yet
> you still have to scale nodes beyond IPv4 holdings.=C2=A0 There is als= o the case
> where uniformity of provisioning is seen as being a higher value than<= br> > having 2 flavor: v4 and v6... thus draft-anderson-v6ops-siit-dc-01
> certainly fits a need, but it should be context of dual-stack and sing= le
> stack v4 and v6.

I'm not so sure about having separate IPv4-only and IPv6-only
infrastructures solves anything, actually...

To continue the Facebook analogy with a rack of IPv4-only frontend
nodes and another rack of IPv6-only frontend nodes that serve IPv4-only
and IPv6-capable users: Presumably all those users need to be shown the
same content, regardless of which IP version they used to request it.
So those IPv4/IPv6-only frontend racks necessarily share a common set
of backend servers - and if they're to be reachable from both the
IPv4-only and the IPv6-only frontend nodes, then the backend nodes must
necessarily be dual-stack.


Let's assume the backend is ipv6-o= nly.=C2=A0

The ipv4-only front-end is in-fact dual= stack but it has=C2=A0public v4 in public dns=C2=A0to be reached by client= s but no public dns entry on the ipv6 side.=C2=A0 This is what allows for t= he separation of ipv4 and v6 users=C2=A0


So we're back to IPv4 being a limiting factor for scaling, and in my experience the number of backend nodes usually greatly outnumber the
number of frontend nodes so really this is where you primarily would
want to avoid dual-stack. (If we're talking about Facebook or someone of similar size, dual-stack using RFC1918 for IPv4 in the backend
doesn't necessarily scale well enough either.)

Tore


---------- Forwarded message ----------
From:=C2=A0"Templin= , Fred L" <Fred.L.Temp= lin@boeing.com>
To:=C2=A0Jeroen Massar <jeroen@massar.ch>, "sthaug@nethelp.no" <sthaug@nethelp.no>
Cc:=C2=A0"v6ops@ietf.org" <v6ops@i= etf.org>
Date:=C2=A0Mon, 8 Dec 2014 16:23:53 +0000
Subject:=C2= =A0Re: [v6ops] PMTUD forever, was: MTUs on the general Internet
More on = what I said the other day, there are two magic numbers that tunnels
need to concern themselves with: 1280 and 1500. Accommodating all packets within that size range while placing no explicit upper bound for accommodat= ing
larger packets is what is being proposed. In other words, no MTU clamping.<= br>
Thanks - Fred
fred.l.templin@boeing.com<= br>

> -----Original Message-----
> From: v6ops [mailto:v6ops-bo= unces@ietf.org] On Behalf Of Templin, Fred L
> Sent: Saturday, December 06, 2014 8:18 AM
> To: Jeroen Massar; sthaug@nethelp= .no
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet<= br> >
> Hi Jeroen,
>
> > -----Original Message-----
> > From: v6ops [mailto:v6o= ps-bounces@ietf.org] On Behalf Of Jeroen Massar
> > Sent: Saturday, December 06, 2014 4:26 AM
> > To: sthaug@nethelp.no > > Cc: v6ops@ietf.org
> > Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Inte= rnet
> >
> > On 2014-12-06 12:20, sthaug@= nethelp.no wrote:
> > >>> that should be turned off as soon as possible. That = will happen as more
> > >>> and more links set MTUs larger than 1500.
> > >>
> > >> IPv6 should also have been deployed globally as soon as = possible...
> > >
> > > Speaking only for myself: We run with a suitable jumbo MTU o= n most
> > > links *within our AS*. I see no sign of such an increased MT= U becoming
> > > more available on peering and transit links.
> >
> > Agreed.
> >
> > IMHO one big reason of which is that there are cases where PMTU d= oes not
> > work 100% and thus there is no real benefit of enabling larger MT= Us as
> > it will only give problems (as it is something not well known) an= d thus
> > higher support cost, than creating faster transfers.
> >
> > Hence, a status quo.
>
> Yes, the status has been quo for a long time, but we now have an oppor= tunity
> to move beyond that. If tunnels stop clamping the MTU and end hosts st= art
> using RFC4821 larger MTUs will be possible. The good news is that fixi= ng the
> tunnels and fixing the end hosts can be done independently of one anot= her.
>
> Thanks - Fred
> fred.l.templin@boeing.com=
>
> > Greets,
> >=C2=A0 Jeroen
> >
> >
> > _______________________________________________
> > 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




---------- Forwarded message ----------
From:=C2=A0The IESG <= iesg-secretary@ietf.org><= br>To:=C2=A0IETF-Announce <iet= f-announce@ietf.org>
Cc:=C2=A0v6ops mailing list <v6ops@ietf.org>, v6ops chair <v6ops-chairs@tools.ietf.org>, RFC = Editor <rfc-editor@rfc-edit= or.org>
Date:=C2=A0Mon, 08 Dec 2014 09:46:59 -0800
Subject:=C2= =A0[v6ops] Document Action: 'Analysis of Failure Cases in IPv6 Roaming = Scenarios' to Informational RFC (draft-ietf-v6ops-ipv6-roaming-analysis= -07.txt)
The IESG has approved the following document:
- 'Analysis of Failure Cases in IPv6 Roaming Scenarios'
=C2=A0 (draft-ietf-v6ops-ipv6-roaming-analysis-07.txt) as Informational RFC=

This document is the product of the IPv6 Operations Working Group.

The IESG contact persons are Joel Jaeggli and Benoit Claise.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-v6ops= -ipv6-roaming-analysis/





Technical Summary

=C2=A0 =C2=A0This document identifies a set of failure cases that may be =C2=A0 =C2=A0encountered by IPv6-enabled mobile customers in roaming scenar= ios.
=C2=A0 =C2=A0The analysis reveals that the failure causes include improper<= br> =C2=A0 =C2=A0configurations, incomplete functionality support in equipment,= and
=C2=A0 =C2=A0inconsistent IPv6 deployment strategies between the home and t= he
=C2=A0 =C2=A0visited networks.

Working Group Summary

China Mobile has been pretty openly discussing what they call "IPv6 Bearer Network Trials" starting at IETF 81. As one might imagine, they=
had various problems with routing (OSPF issues due to variable MTU,
for example) and other operational aspects. They started discussing
their issues in roaming at IETF 87, and other operators experimenting
with the technology chimed in. This was accepted as a working group
draft and discussed at IETF 89, and is now being filed. There has been
active discussion on technical points, but little real dispute.

Document Quality

This is operational experience, and the author list reflects the set
of companies reporting experience with it - Deutsche Telekom AG,
Rogers, China Mobile, and Orange. Given the range of comments made,
the document appears to cover the bases.

Note that while the document specifically addresses 3GPP networks, it
also comments on 2G and 4G, and by extension LTE.

Personnel

Document Shepherd: Fred Baker Area Director: Joel Jaeggli



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




--
Regards
Tariq Saraj=
Center for <= /span>Research in Networks and Telecom (CoReNeT)
--001a1133a8180f05870509c61981-- From nobody Tue Dec 9 03: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 F34241A1BB1 for ; Tue, 9 Dec 2014 03:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 6Prf7EmFzyyf for ; Tue, 9 Dec 2014 03:24:00 -0800 (PST) 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 899FC1A1BC3 for ; Tue, 9 Dec 2014 03:23:59 -0800 (PST) Received: from [2a02:c0:2:4:6666:17:0:1001] (port=51507 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1XyItZ-0004iN-FA; Tue, 09 Dec 2014 12:23:57 +0100 Date: Tue, 9 Dec 2014 12:23:45 +0100 From: Tore Anderson To: Tariq Saraj Message-ID: <20141209122345.4f277dcb@echo.ms.redpill-linpro.com> In-Reply-To: References: X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.24; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/J990ZP6MpEh65VBgTUfq2fAlRJo Cc: v6ops@ietf.org Subject: Re: [v6ops] siit-eam/siit-dc vs IVI 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, 09 Dec 2014 11:24:02 -0000 Hi Tariq, (I changed the subject so that I can easily find this message later.) * Tariq Saraj > I don't understand the reason for discussion on SIIT when IVI is > there. The flaws are addressed and mitigated in IVI. See the Problem Statement section in SIIT-EAM: http://tools.ietf.org/html/draft-anderson-v6ops-siit-eam-01#section-2 While IVI doesn't use IPv4-translatable IPv6 addresses, it uses its own address format which share all the disadvantages of IPv4-translatable IPv6 addresses. As specified in RFC 6219 section 3.1: | 0 |32 |40 |72 127| ------------------------------------------------------------------ | |ff | | | ------------------------------------------------------------------ |<- PREFIX ->|<- IPv4 address ->| <- SUFFIX -> | The key problem with inflexible formats such as this one is that it require that the operator must design and number his IPv6 infrastructure specifically in order to facilitate IVI translation. This makes IVI simple at the expense of making the IPv6 infrastructure complex. SIIT-EAM (and by extension SIIT-DC) allows for mapping between arbitrary IPv4 and IPv6 addresses; no particular address format is mandated. So with SIIT-EAM you could have an IPv4 address 192.0.2.1 map to the IPv6 address 2001:db8::f00. That is, as far as I can tell, impossible to accomplish with IVI (in IVI, 192.0.2.1 would map to 2001:db8:ffc0:2:100:: as I understand it). Another key point is that IVI (RFC6219) isn't a proposed standard, so you can't implement IVI with a standard SIIT implementation. That's true for SIIT-DC as well, and it is something I attempt to fix with SIIT-EAM. That said, SIIT-EAM in its current form cannot be used to implement IVI, because it forbids the use of differing suffix lengths: An EAM's IPv4 Prefix and IPv6 Prefix MUST have identical suffix lengths. Any suffix bits MUST be kept intact during translation. This conflicts with IVI, which allows for different suffix lengths (and fixing up any discrepancy by padding any missing suffix bits with zero): Note that based on the IVI mapping mechanism, an IPv4 /24 is mapped to an IPv6 /64, and an IPv4 /32 is mapped to an IPv6 /72. It should be possible to change SIIT-EAM such that it would be possible to express IVI mappings with it too. Would you find that valuable? Tore From nobody Tue Dec 9 07:27: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 3EA781A00B7 for ; Tue, 9 Dec 2014 07:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 vo3e0u8CwaSy for ; Tue, 9 Dec 2014 07:27:02 -0800 (PST) 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 B99F71A0222 for ; Tue, 9 Dec 2014 07:27:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1286; q=dns/txt; s=iport; t=1418138822; x=1419348422; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4ldYoMfXJjO/0gH2qQ6Gf6CiM1nXW3aOoybuQ/yKtSA=; b=XNWim0deDYUeOJpJsasdTv9pNVVUABLG8VJMrTC/C33LO1lL6EGnVuZK NYXD6ZbFAax1ZuRsJzq+f/3GyTEvzP1pYNeqEyd9Ki7ULUhzJ30TfS4EU v0375NgbyRK3oaHHA62O/7qz6EPzezQSXT/wutXUZ4loW6EYKAA7mA/CG k=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAIoTh1StJA2H/2dsb2JhbABZgwaBKgTMJgKBIxYBAQEBAX2EAwEBAwF5BQsCAQhGMiUCBAENBQ6IIgjXOQEBAQEBAQEBAQEBAQEBAQEBAQEBAReQPAeDIYEVAQSODYFigSiGC5Fqg25vgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="asc'?scan'208";a="104061371" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-8.cisco.com with ESMTP; 09 Dec 2014 15:27:02 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sB9FR1Nv026849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 15:27:02 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 09:27:01 -0600 From: "Fred Baker (fred)" To: Tore Anderson , Ca By Thread-Topic: [v6ops] draft-anderson-v6ops-siit-dc-01 Thread-Index: AQHQE8ST/H+52M+VBkKaVHnICYF0eQ== Date: Tue, 9 Dec 2014 15:27:00 +0000 Message-ID: <4609D998-6831-4C23-A009-FFD4409EBE5E@cisco.com> References: <20141208094253.308df787@echo.ms.redpill-linpro.com> <20141209103706.2beb9c9a@echo.ms.redpill-linpro.com> In-Reply-To: <20141209103706.2beb9c9a@echo.ms.redpill-linpro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_46120FFE-E0CD-43A5-A302-3F223BB44B2B"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VXUpI2zMMuYl7jrUVkqnxGxiD8U Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-anderson-v6ops-siit-dc-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: Tue, 09 Dec 2014 15:27:08 -0000 --Apple-Mail=_46120FFE-E0CD-43A5-A302-3F223BB44B2B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 9, 2014, at 1:37 AM, Tore Anderson wrote: > I think I'd call this =ABPartial dual-stack=BB or somthing like it. I suspect you=92re both right, but in different ways. The particular = machine(s) are dual stack (they have two stacks), but they have only = IPv6 addresses on at least one interface (they might also have only IPv4 = addresses on another interface, but that=92s not a requirement). As a = result, a message passing through is IPv4 on one side and IPv6 on = another. But nothing else has to be dual stack. So the *network* is only = partially dual stacked. --Apple-Mail=_46120FFE-E0CD-43A5-A302-3F223BB44B2B 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 iD8DBQFUhxTEbjEdbHIsm0MRAhYmAKDVlkVZ+wpF2rI3IgLAQiFK8IPgSgCeLNJ7 Cq0fKxdoUnDglxagFKRY/5A= =rVIS -----END PGP SIGNATURE----- --Apple-Mail=_46120FFE-E0CD-43A5-A302-3F223BB44B2B-- From nobody Tue Dec 9 07:34: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 E8CCB1A8747 for ; Tue, 9 Dec 2014 07:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 Oft5LLMYPZMZ for ; Tue, 9 Dec 2014 07:34:04 -0800 (PST) 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 B4E591A1EF6 for ; Tue, 9 Dec 2014 07:33:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1939; q=dns/txt; s=iport; t=1418139230; x=1419348830; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=NV/+xIPJftRRSg7bFFBN9iCsysblx3ysj3zb6zrxKIA=; b=f5XQKfq2P1q+8KaENlAHLY/CMwj/BJvFkC4UuhU0E05hdQZFpdNr0De0 2OirTMEpaqlQSifHiDxY8k70JxYszgEz08m3GzQmd3Olq6mdaVHtvxEc1 b+cWxUI5smf90WVqESjlRNnNRFpXhJhmEIlCBko/gvAv3mWG9j6NwKY0z o=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAEgVh1StJV2Y/2dsb2JhbABZgwZSWATGH4YHAoEjFgEBAQEBfYQDAQEDAX4LAgEIRjIlAgQTDogiCA3XEQEBAQEBAQEDAQEBAQEBAQEBGZBDgyGBFQWODYFigShPhTyBPZAtg25vgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="asc'?scan'208";a="104065531" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP; 09 Dec 2014 15:33:49 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sB9FXn3A013560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 9 Dec 2014 15:33:49 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 09:33:49 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: [v6ops] Working Group Administrivia Thread-Index: AQHQE8WHeTJhcVCoK0e1pBcXcx916Q== Date: Tue, 9 Dec 2014 15:33:49 +0000 Message-ID: <154FBC4D-2FCE-4AC0-9881-3CB34924B6ED@cisco.com> References: <08DA982D-6605-434B-B815-C69B8A97FA4C@cisco.com> In-Reply-To: <08DA982D-6605-434B-B815-C69B8A97FA4C@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.117] Content-Type: multipart/signed; boundary="Apple-Mail=_C3831F6B-5478-499D-9592-EB7D501A613B"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yCt8zH2ixRFQI7scNK4-PeZizig Subject: Re: [v6ops] Working Group 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, 09 Dec 2014 15:34:06 -0000 --Apple-Mail=_C3831F6B-5478-499D-9592-EB7D501A613B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 So what I get out of this so far is that folks are OK with the clean-up = of the expired drafts, but feel that there is a place for a WG document = documenting (but not making recommendations about) the SLAAC/DHCP = problem. Let me ask specifically about the =93ULA=94 and =93Design Choices=94 = documents. They have not expired and their authors are still working on = them. Brian has commented; others have not. Do we want to keep working = on them? On Dec 5, 2014, at 10:17 AM, Fred Baker (fred) wrote: > Although the working group expressed interest in the following and the = authors have been working hard on them, we think the working group is no = longer interested in these, and so they should be returned to the = authors and not recorded or treated as working group drafts.=20 >=20 > 2014-09-18 draft-ietf-v6ops-design-choices = http://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ > 2014-10-27 draft-ietf-v6ops-dhcpv6-slaac-problem = http://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ > 2014-10-27 draft-ietf-v6ops-ula-usage-recommendations = http://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommendations= / --Apple-Mail=_C3831F6B-5478-499D-9592-EB7D501A613B 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 iD8DBQFUhxZbbjEdbHIsm0MRAk6EAKDO1QKReP/R3Jeium6AARSCjhK4xwCgrjG4 Roxtta5oT1X+9yN5X54Jzzw= =bmGB -----END PGP SIGNATURE----- --Apple-Mail=_C3831F6B-5478-499D-9592-EB7D501A613B-- From nobody Tue Dec 9 07:42: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 98F221A1A40 for ; Tue, 9 Dec 2014 07:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 KmTHyjr6rTzN for ; Tue, 9 Dec 2014 07:42:39 -0800 (PST) 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 DAC0E1A03B3 for ; Tue, 9 Dec 2014 07:42:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4421; q=dns/txt; s=iport; t=1418139758; x=1419349358; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dTBloPR5AR5Y8kEcaw6ZehCjgcZS6Q4LdyWEnobYZnY=; b=Qs5F2h2a7uNaswELMTSMa54HeP+S7ZPBgWuJ1SYnMve5DBfvBKPaiOMF yRDNqyLyZl+p8F7huvMNAnwiePxjfAqm8A/Ybx3RSyl+dvX4Lk/ODtaWb a10tSIo4Jl+qFu/tROZMb1fCj3HKs2Vs9yfvjmMYHtgfPVbrl5CieKmuj M=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAKAXh1StJV2P/2dsb2JhbABZgkNDgSoEzCYCgSMWAQEBAQF9hAMBAQMBeQULAgEIBEIhESUCBA4FDogWAwkI0S4NhVsBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjg+CLQeDIYEVAQSODYFigSiEQ4FIi3KFeINub4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,545,1413244800"; d="asc'?scan'208,217";a="104068300" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP; 09 Dec 2014 15:42:38 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sB9Fgbjq009006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 15:42:37 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 09:42:37 -0600 From: "Fred Baker (fred)" To: Tariq Saraj Thread-Topic: [v6ops] v6ops Digest, Vol 52, Issue 34 Thread-Index: AQHQE8bB7nDM0OUNHEWWR91tzh8XZw== Date: Tue, 9 Dec 2014 15:42:37 +0000 Message-ID: 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.117] Content-Type: multipart/signed; boundary="Apple-Mail=_F50F9C39-984F-4704-80D3-4DB140AA6BAD"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XN283aNeYb4kdkZLRLVAzjTjxSo Cc: "v6ops@ietf.org" Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 34 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, 09 Dec 2014 15:42:40 -0000 --Apple-Mail=_F50F9C39-984F-4704-80D3-4DB140AA6BAD Content-Type: multipart/alternative; boundary="Apple-Mail=_6B8D8875-5F9D-4CC8-A5D3-F14268A02109" --Apple-Mail=_6B8D8875-5F9D-4CC8-A5D3-F14268A02109 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 9, 2014, at 2:35 AM, Tariq Saraj wrote: > I don't understand the reason for discussion on SIIT when IVI is = there.=20 The issue is one of coupling to IPv4. In RFC 6145 (SIIT aka IVI), at = least one of the addresses on a given machine has to be an RFC 6052 = IPv4-embedded address, and that address (or a subnet containing it) has = to be somewhere in routing. When IPv4 finally falls to the wayside, = there is a remaining clean-up activity in the subject network, and until = then, there is a slightly unnatural act in the IPv6 network due to the = coupling. In Tore=92s model, IPv6 is IPv6, IPv4 is IPv4, and the only = coupling is a manual configuration in the translator.=20 When he first ran the idea by the IETF, my viewpoint was that he was = implementing what 6146 calls a =93static translation=94, and so was = simply using RFC 6146. That=92s not quite true, as 6146 is really a = TCP/UDP session translator, not an IPv6/IPv4 translator. So, Tore is = documenting an IPv6/IPv4 translator. Translation is the ply =93unnatural = act=94 in the deployment, and when IPv4 eventually falls to the wayside, = the translator becomes out of date or disappears entirely, and nobody = notices. --Apple-Mail=_6B8D8875-5F9D-4CC8-A5D3-F14268A02109 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Dec 9, 2014, at 2:35 AM, Tariq = Saraj <tariqsaraj@gmail.com> = wrote:

I don't understand the reason for = discussion on SIIT when IVI is there. 

The issue is one of coupling to IPv4. In RFC 6145 (SIIT aka = IVI), at least one of the addresses on a given machine has to be an RFC = 6052 IPv4-embedded address, and that address (or a subnet containing it) = has to be somewhere in routing. When IPv4 finally falls to the wayside, = there is a remaining clean-up activity in the subject network, and until = then, there is a slightly unnatural act in the IPv6 network due to the = coupling. In Tore=92s model, IPv6 is IPv6, IPv4 is IPv4, and the only = coupling is a manual configuration in the = translator. 

When he first ran the idea by = the IETF, my viewpoint was that he was implementing what 6146 calls a = =93static translation=94, and so was simply using RFC 6146. That=92s not = quite true, as 6146 is really a TCP/UDP session translator, not an = IPv6/IPv4 translator. So, Tore is documenting an IPv6/IPv4 translator. = Translation is the ply =93unnatural act=94 in the deployment, and when = IPv4 eventually falls to the wayside, the translator becomes out of date = or disappears entirely, and nobody notices.
= --Apple-Mail=_6B8D8875-5F9D-4CC8-A5D3-F14268A02109-- --Apple-Mail=_F50F9C39-984F-4704-80D3-4DB140AA6BAD 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 iD8DBQFUhxhrbjEdbHIsm0MRAokUAJ9+3VQGZZxe/Z704hI6oizcMKyt+gCeMJCO xc4wtVxe2Z8hGceG40IqmrQ= =nhI2 -----END PGP SIGNATURE----- --Apple-Mail=_F50F9C39-984F-4704-80D3-4DB140AA6BAD-- From nobody Tue Dec 9 08:21: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 9757E1A8880 for ; Tue, 9 Dec 2014 08:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 xXJzeKOI08oN for ; Tue, 9 Dec 2014 08:21:10 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C8C01A7000 for ; Tue, 9 Dec 2014 08:21:09 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sB9GL4xk013709 for ; Tue, 9 Dec 2014 17:21:04 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BAAEB208A1C for ; Tue, 9 Dec 2014 17:21:15 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B34D32089F5 for ; Tue, 9 Dec 2014 17:21:15 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sB9GKk7U000872 for ; Tue, 9 Dec 2014 17:21:04 +0100 Message-ID: <5487215E.1060108@gmail.com> Date: Tue, 09 Dec 2014 17:20:46 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <08DA982D-6605-434B-B815-C69B8A97FA4C@cisco.com> <154FBC4D-2FCE-4AC0-9881-3CB34924B6ED@cisco.com> In-Reply-To: <154FBC4D-2FCE-4AC0-9881-3CB34924B6ED@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yb1lNKT3E79HptxfjlBlswWfveU Subject: Re: [v6ops] Working Group 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, 09 Dec 2014 16:21:12 -0000 Le 09/12/2014 16:33, Fred Baker (fred) a écrit : > So what I get out of this so far is that folks are OK with the > clean-up of the expired drafts, but feel that there is a place for a > WG document documenting (but not making recommendations about) the > SLAAC/DHCP problem. > > Let me ask specifically about the “ULA” and “Design Choices” > documents. They have not expired and their authors are still working > on them. Brian has commented; others have not. Do we want to keep > working on them? There is one thing I noticed in other ULA-related discussions (e.g. homenet WG) that often new methods of generating ULAs are alluded to. It would be better to first refer to the existing methods of generating ULAs (the ULA RFC) and maybe select among those. I am not sure whether the current ULA draft recommends when and how to select among the 3 ULA generation methods already in the ULA RFC, but otherwise it may be good to. Alex > > On Dec 5, 2014, at 10:17 AM, Fred Baker (fred) > wrote: > >> Although the working group expressed interest in the following and >> the authors have been working hard on them, we think the working >> group is no longer interested in these, and so they should be >> returned to the authors and not recorded or treated as working >> group drafts. >> >> 2014-09-18 draft-ietf-v6ops-design-choices >> http://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >> 2014-10-27 draft-ietf-v6ops-dhcpv6-slaac-problem >> http://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ >> >> 2014-10-27 draft-ietf-v6ops-ula-usage-recommendations http://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommendations/ > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Dec 9 08: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 19FB51A888F for ; Tue, 9 Dec 2014 08:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 FMIImvSEdAxv for ; Tue, 9 Dec 2014 08:45:19 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A561A8794 for ; Tue, 9 Dec 2014 08:45:18 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sB9GjGaw009781 for ; Tue, 9 Dec 2014 17:45:16 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0EAB1208A8F for ; Tue, 9 Dec 2014 17:45:27 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id EF31B2069F9 for ; Tue, 9 Dec 2014 17:45:26 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sB9Gimd8017223 for ; Tue, 9 Dec 2014 17:45:15 +0100 Message-ID: <54872700.8030409@gmail.com> Date: Tue, 09 Dec 2014 17:44:48 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <5485FBD7.6050807@gmail.com> In-Reply-To: <5485FBD7.6050807@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DHWrxyyL6St-jgDEbhvUmq_ptd8 Subject: Re: [v6ops] On IPv6 address part naming 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, 09 Dec 2014 16:45:21 -0000 Sorry, following up on my own post, about other SDOs: It is called a "16-bit piece of the address" by the Single Unix Specification 2013 of the Open Group https://www2.opengroup.org/ogsys/catalog/t101 inet_pton () [...] > The preferred form is "x:x:x:x:x:x:x:x", where the 'x' s are the > hexadecimal values of the eight 16-bit pieces of the address. > [...] > > "x:x:x:x:x:x:d.d.d.d", where the 'x' s are the hexadecimal values of > the six high-order 16-bit pieces of the address, and the 'd' s are > the decimal values of the four low-order 8-bit pieces of the address > (standard IPv4 representation). Alex Le 08/12/2014 20:28, Alexandru Petrescu a Ă©crit : > netgear user manual calls it a "quartet": > > "IPv6 addresses are denoted by eight groups of hexadecimal quartets > separated by colons" > > Alex > > --- L'absence de virus dans ce courrier Ă©lectronique a Ă©tĂ© vĂ©rifiĂ©e > par le logiciel antivirus Avast. http://www.avast.com > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Dec 9 11:42: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 4FAF21A1A50 for ; Tue, 9 Dec 2014 11:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 b1Kx97N9snlO for ; Tue, 9 Dec 2014 11:42:47 -0800 (PST) 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 B33401A0032 for ; Tue, 9 Dec 2014 11:42:47 -0800 (PST) Received: by mail-pa0-f43.google.com with SMTP id kx10so1179688pab.30 for ; Tue, 09 Dec 2014 11:42:47 -0800 (PST) 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=UaYchjJKeC+3BOf/E5gHxkPPMtJKfs2HFhB2z6aqJRA=; b=b99OKoe8sot8ol5Y0ELb6tmFG9tFQUni8yo30YsiLz/OimeQCtb44Lrtdy6kaFBMvi 4h4HRSo4BpcBjBMU5YMIpP3GHVddmpPz1D1GfPQ/SeYaGQ67IOLfeQ0gAwDzlATrguiG cfj6KMjeCUzHhNH+WrqEsUcac4VDTNch6FNVLC8MgPcBEPxT5krNZUou41f3uuw/SWlk JxyXnU5/lXm+9yZFnLLoQrx7UmVudmLM7ERW7YBjggh/ObrweEmoiEJQ+tqqZnYWtVgL sNktPTiqDGgsnJ0shQ9qnv3wdwSlOdXEi+5nks5qknGJDM6LmzwCrA79mPEg2Oq6b1u0 GaqA== X-Received: by 10.68.165.100 with SMTP id yx4mr8490083pbb.79.1418154166933; Tue, 09 Dec 2014 11:42:46 -0800 (PST) Received: from [192.168.178.26] (101.230.69.111.dynamic.snap.net.nz. [111.69.230.101]) by mx.google.com with ESMTPSA id b1sm2238016pat.2.2014.12.09.11.42.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Dec 2014 11:42:45 -0800 (PST) Message-ID: <548750B9.90203@gmail.com> Date: Wed, 10 Dec 2014 08:42:49 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu References: <5485FBD7.6050807@gmail.com> <54872700.8030409@gmail.com> In-Reply-To: <54872700.8030409@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/cBWMzKnTtTbXv5XfqMO8jEo9gK8 Cc: v6ops@ietf.org Subject: Re: [v6ops] On IPv6 address part naming 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, 09 Dec 2014 19:42:49 -0000 On 10/12/2014 05:44, Alexandru Petrescu wrote: > Sorry, following up on my own post, about other SDOs: >=20 > It is called a "16-bit piece of the address" by > the Single Unix Specification 2013 of the Open Group > https://www2.opengroup.org/ogsys/catalog/t101 How sensible. Brian >=20 > inet_pton () > [...] >> The preferred form is "x:x:x:x:x:x:x:x", where the 'x' s are the >> hexadecimal values of the eight 16-bit pieces of the address. >> > [...] >> >> "x:x:x:x:x:x:d.d.d.d", where the 'x' s are the hexadecimal values of >> the six high-order 16-bit pieces of the address, and the 'd' s are >> the decimal values of the four low-order 8-bit pieces of the address >> (standard IPv4 representation). >=20 > Alex >=20 >=20 > Le 08/12/2014 20:28, Alexandru Petrescu a =C3=A9crit : >> netgear user manual calls it a "quartet": >> >> "IPv6 addresses are denoted by eight groups of hexadecimal quartets >> separated by colons" >> >> Alex >> >> --- L'absence de virus dans ce courrier =C3=A9lectronique a =C3=A9t=C3= =A9 v=C3=A9rifi=C3=A9e >> par le logiciel antivirus Avast. http://www.avast.com >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Dec 9 13:50: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 937391A0318 for ; Tue, 9 Dec 2014 13:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-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 SsXPUNQIui18 for ; Tue, 9 Dec 2014 13:50:27 -0800 (PST) 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 82D3A1A0092 for ; Tue, 9 Dec 2014 13:50:27 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id sB9Lo5fp016794; Tue, 9 Dec 2014 21:50:05 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk sB9Lo5fp016794 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1418161805; bh=P+cvcfkkT/321wEJ00DSEhxm2LA=; h=Subject:Mime-Version:From:In-Reply-To:Date:Cc:References:To; b=NZyTmCflrx413vHteFklRy/4tzVnbUtJWDEbWKW26VMljia/AyAGwHMvg4yhksiwa nO436XE6axrF2nVI+u1KWnOTAPnToHK5PV0YTOdDJRrF18/u8ZyrjmuUlSvkXheU80 NxFiL6Qw8ujRrn1l3lWjruYp6CXkXOrgXMjfNbdU= 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 qB8Lo52688710801rN ret-id none; Tue, 09 Dec 2014 21:50:05 +0000 Received: from [192.168.1.108] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id sB9Lngi0020717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2014 21:49:43 GMT Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9A6CD5A5-0629-4200-ACFF-57A73BE42AF7"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Tim Chown In-Reply-To: <154FBC4D-2FCE-4AC0-9881-3CB34924B6ED@cisco.com> Date: Tue, 9 Dec 2014 21:49:41 +0000 Message-ID: References: <08DA982D-6605-434B-B815-C69B8A97FA4C@cisco.com> <154FBC4D-2FCE-4AC0-9881-3CB34924B6ED@cisco.com> <5D2CD422-3911-407B-9D71-2753A996CE5B@ecs.soton.ac.uk> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.1993) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=qB8Lo5268871080100; tid=qB8Lo52688710801rN; 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: sB9Lo5fp016794 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HlMLK5uk7apvgMRYS32MGcd_1yo Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Working Group 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, 09 Dec 2014 21:50:38 -0000 --Apple-Mail=_9A6CD5A5-0629-4200-ACFF-57A73BE42AF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, > On 9 Dec 2014, at 15:33, Fred Baker (fred) wrote: >=20 > So what I get out of this so far is that folks are OK with the = clean-up of the expired drafts, but feel that there is a place for a WG = document documenting (but not making recommendations about) the = SLAAC/DHCP problem. I would like to see these that one progressed, as it came out of the = 6renum WG as a gap, and it would be very appropriate to close that gap = off, as best as we can. > Let me ask specifically about the =93ULA=94 and =93Design Choices=94 = documents. They have not expired and their authors are still working on = them. Brian has commented; others have not. Do we want to keep working = on them? I think both are useful. There were certainly other documents that = =91punted=92 guidance on ULA usage to that ULA draft, so it would seem = reasonable to complete it, so long as its just Informational and not = BCP. And I=92ve seen references to the design choices document in = various places, so people are clearly using it, and finding it useful to = point others at, so again closing it off would seem worthwhile. The old enterprise IPv6 draft of mine you dug up was of course obsoleted = by the enterprise-incremental document, so is certainly dead. Tim >=20 > On Dec 5, 2014, at 10:17 AM, Fred Baker (fred) wrote: >=20 >> Although the working group expressed interest in the following and = the authors have been working hard on them, we think the working group = is no longer interested in these, and so they should be returned to the = authors and not recorded or treated as working group drafts. >>=20 >> 2014-09-18 draft-ietf-v6ops-design-choices = http://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ >> 2014-10-27 draft-ietf-v6ops-dhcpv6-slaac-problem = http://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ >> 2014-10-27 draft-ietf-v6ops-ula-usage-recommendations = http://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommendations= / >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_9A6CD5A5-0629-4200-ACFF-57A73BE42AF7 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 - https://gpgtools.org iQEcBAEBCgAGBQJUh251AAoJEFoq8u2GfpfeQpgH/jhxN50f9YQfUGhAULQMlmCN 5xVE2hQPPntH4vwWlhivOD8CmJNgOXd/yyfjPbU0J5oJ1EvQu5r9zRHtXNToUK4W AT2OAzIho4BhCMdiSPihjSVeY/rpIijIkpGeSB4u39O/3nJsaxOfM4YwEqcXBmCT 5smqXybhYRbEu39xmbdZcrOJX7Y0+7gmkybwZ4iiyuTnnJLd5sggnyt0H8GNVX5L mCSrvt1Qg1H7DivLCT5r9x/5SR5EUP/thD7BSXWAQsVMoOEEi3lbnGM85cHIc4KY 190cqq75PrV6JsfY6SIn+RmNDT50jfAD0dtW6HqfMtbO6nG6Q6vPOmArg8jsJws= =ejU2 -----END PGP SIGNATURE----- --Apple-Mail=_9A6CD5A5-0629-4200-ACFF-57A73BE42AF7-- From nobody Tue Dec 9 13:51: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 2B99C1A0318 for ; Tue, 9 Dec 2014 13:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-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 pU5l8TaFEI9x for ; Tue, 9 Dec 2014 13:51:30 -0800 (PST) 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 E1ED61A0399 for ; Tue, 9 Dec 2014 13:51:29 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id sB9LpPrw017190; Tue, 9 Dec 2014 21:51:25 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk sB9LpPrw017190 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1418161885; bh=XNEmtWEK+COuP5j59sOZgyLcDg8=; h=Subject:Mime-Version:From:In-Reply-To:Date:Cc:References:To; b=hlUPOPPjxZeFRXNtxE819QvTuHKeEPYXNaifNITB+iJNUsTlzMD3Ei369ezAacUqB baY05rQkG1v4ysLHw8AZMZE8iRZLJPr18Okph9YUP9vLu5O2+6bjpWCKZSTvDpa7n0 Eoo68FW0j4KH3C0o3EvDYNObaHY5Fk8F9VrgQrI0= 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 qB8LpP2688710810Re ret-id none; Tue, 09 Dec 2014 21:51:25 +0000 Received: from [192.168.1.108] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id sB9LpC4E021484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2014 21:51:14 GMT Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0ECB0AD1-E5AA-4038-86D0-EBBC654F82FE"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Tim Chown In-Reply-To: <154FBC4D-2FCE-4AC0-9881-3CB34924B6ED@cisco.com> Date: Tue, 9 Dec 2014 21:51:12 +0000 Message-ID: References: <08DA982D-6605-434B-B815-C69B8A97FA4C@cisco.com> <154FBC4D-2FCE-4AC0-9881-3CB34924B6ED@cisco.com> <084DAEC3-CB44-4E13-AF03-BA08ED660F13@ecs.soton.ac.uk> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.1993) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=qB8LpP268871081000; tid=qB8LpP2688710810Re; 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: sB9LpPrw017190 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XohLCrv88cZeoMTpRzhhqVbGTRY Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Working Group 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, 09 Dec 2014 21:51:40 -0000 --Apple-Mail=_0ECB0AD1-E5AA-4038-86D0-EBBC654F82FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 9 Dec 2014, at 15:33, Fred Baker (fred) wrote: >=20 > Let me ask specifically about the =93ULA=94 and =93Design Choices=94 = documents. They have not expired and their authors are still working on = them. Brian has commented; others have not. Do we want to keep working = on them? Oh, and I=92d also support Brian=92s proposal to move the ULA =91guidance'= (rather than =91recommendations=92) to the design choices document, = which is an appropriate place to discuss the tradeoffs with their use in = different contexts. Tim --Apple-Mail=_0ECB0AD1-E5AA-4038-86D0-EBBC654F82FE 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 - https://gpgtools.org iQEcBAEBCgAGBQJUh27QAAoJEFoq8u2Gfpfem0cIAIf/wkQrvEoU1/OR7bucfG2+ OVKoVZkjIlrScPtR8EiU3Mkpt7Q9yzbZi442y2LUhwBtH9yLj2HUbvCiwtMuGNYy eAxhbrYcgC8AOYh+m1Re8m5wj+lDvLsgr1LRHLBLhfqVxRgxGJh97+8mhBXUtL78 VYb2UPDaZrY+Rk2UylqNbh9b5WoSKcOA1EUX5f4V9klCJSK8u5SenhoevE6EhNkK mlCBxhuBDRnd7iUc/jYJtbZVImtPia8bjiD+Isoc5Vlxs/dFkJBXM7ml8CknPAZO ZzWWie5Acvo1dlPlCLrL9Rhyv3RZmA4bSJQnEzAWt+et+zeM4REdEplxEOTPWc8= =ehHM -----END PGP SIGNATURE----- --Apple-Mail=_0ECB0AD1-E5AA-4038-86D0-EBBC654F82FE-- From nobody Tue Dec 9 17:34: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 48F481A1B79 for ; Tue, 9 Dec 2014 17:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 5U4fV0udGTMn for ; Tue, 9 Dec 2014 17:34:08 -0800 (PST) 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 A1FDD1A6ED9 for ; Tue, 9 Dec 2014 17:34:07 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMR29809; Wed, 10 Dec 2014 01:34:06 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 10 Dec 2014 01:34:05 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.128]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Wed, 10 Dec 2014 09:34:00 +0800 From: Sheng Jiang To: "Fred Baker (fred)" , "v6ops@ietf.org WG" Thread-Topic: [v6ops] Working Group Administrivia Thread-Index: AQHQELfApl0OmdTiikqs9ZO27DRlMpyG44KAgAErHyA= Date: Wed, 10 Dec 2014 01:33:59 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AFEA5F3@nkgeml512-mbx.china.huawei.com> References: <08DA982D-6605-434B-B815-C69B8A97FA4C@cisco.com> <154FBC4D-2FCE-4AC0-9881-3CB34924B6ED@cisco.com> In-Reply-To: <154FBC4D-2FCE-4AC0-9881-3CB34924B6ED@cisco.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/uC7kCITKrFRuKd4e_DhFiWQLqBA Subject: Re: [v6ops] Working Group 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: Wed, 10 Dec 2014 01:34:09 -0000 PkxldCBtZSBhc2sgc3BlY2lmaWNhbGx5IGFib3V0IHRoZSDigJxVTEHigJ0gYW5kIOKAnERlc2ln biBDaG9pY2Vz4oCdIGRvY3VtZW50cy4NCj5UaGV5IGhhdmUgbm90IGV4cGlyZWQgYW5kIHRoZWly IGF1dGhvcnMgYXJlIHN0aWxsIHdvcmtpbmcgb24gdGhlbS4gQnJpYW4gaGFzDQo+Y29tbWVudGVk OyBvdGhlcnMgaGF2ZSBub3QuIERvIHdlIHdhbnQgdG8ga2VlcCB3b3JraW5nIG9uIHRoZW0/DQoN ClRoZSBXRyBjZXJ0YWlubHkgc2hvd2VkIGludGVyZXN0cyB3aGVuIHRoZXNlIGRvY3VtZW50cyB3 ZXJlIGFkb3B0ZWQuIFRoZSB0b3BpY3MgYXJlIHVzZWZ1bC4gVGhlbiwgbWF5YmUgbG9uZyBwcm9j ZXNzIGFuZCB3aWRlIGRpc2N1c3Npb24gKHNvbWUgZGlzY3Vzc2lvbiBtYXkgYmUgcmVsZXZhbnQs IGJ1dCBub3QgZXNzZW50aWFsIGZvciB0aGUgY29yZSBjb250ZW50cyBvZiB0aGVzZSBkb2N1bWVu dHMpIGhhdmUgZGlzdHJhY3RlZCBwZW9wbGUncyBpbnRlcmVzdHMuIExldCdzIGdldCBiYWNrIHRv IHRoZSBvcmlnaW5hbCBtb3RpdmF0aW9ucywgZm9jdXMgb24gdGhlIGNvcmUgY29udGVudHMsIGFu ZCBjb21wbGV0ZSB0aGVtIGFzIHF1aWNrIGFzIHBvc3NpYmxlLg0KDQpCZXN0IHJlZ2FyZHMsDQoN ClNoZW5nDQoNCj5PbiBEZWMgNSwgMjAxNCwgYXQgMTA6MTcgQU0sIEZyZWQgQmFrZXIgKGZyZWQp IDxmcmVkQGNpc2NvLmNvbT4gd3JvdGU6DQo+DQo+PiBBbHRob3VnaCB0aGUgd29ya2luZyBncm91 cCBleHByZXNzZWQgaW50ZXJlc3QgaW4gdGhlIGZvbGxvd2luZyBhbmQgdGhlDQo+YXV0aG9ycyBo YXZlIGJlZW4gd29ya2luZyBoYXJkIG9uIHRoZW0sIHdlIHRoaW5rIHRoZSB3b3JraW5nIGdyb3Vw IGlzIG5vDQo+bG9uZ2VyIGludGVyZXN0ZWQgaW4gdGhlc2UsIGFuZCBzbyB0aGV5IHNob3VsZCBi ZSByZXR1cm5lZCB0byB0aGUgYXV0aG9ycyBhbmQNCj5ub3QgcmVjb3JkZWQgb3IgdHJlYXRlZCBh cyB3b3JraW5nIGdyb3VwIGRyYWZ0cy4NCj4+DQo+PiAyMDE0LTA5LTE4ICAgICAgICAgICAgICAg ICBkcmFmdC1pZXRmLXY2b3BzLWRlc2lnbi1jaG9pY2VzDQo+aHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLWRlc2lnbi1jaG9pY2VzLw0KPj4gMjAxNC0xMC0y NyAgICAgICAgICAgZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbQ0KPmh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMt cHJvYmxlbS8NCj4+IDIwMTQtMTAtMjcgICAgICBkcmFmdC1pZXRmLXY2b3BzLXVsYS11c2FnZS1y ZWNvbW1lbmRhdGlvbnMNCj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtdjZvcHMtdWxhLXVzYWdlLXJlY29tbWVuZGF0aW9ucw0KPi8NCg0K From nobody Tue Dec 9 23:25: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 0F5A21A1A80 for ; Tue, 9 Dec 2014 23:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 gIHnwB-5zKM2 for ; Tue, 9 Dec 2014 23:25:27 -0800 (PST) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D7A31A1A8D for ; Tue, 9 Dec 2014 23:25:27 -0800 (PST) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail11.telekom.de with ESMTP; 10 Dec 2014 08:25:25 +0100 X-IronPort-AV: E=Sophos;i="5.07,551,1413237600"; d="scan'208";a="581878892" Received: from he113415.emea1.cds.t-internal.com ([10.125.65.81]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 10 Dec 2014 08:25:24 +0100 Received: from HE113605.emea1.cds.t-internal.com ([10.125.65.122]) by HE113415.emea1.cds.t-internal.com ([2002:7cd:4151::7cd:4151]) with mapi; Wed, 10 Dec 2014 08:25:24 +0100 From: To: Date: Wed, 10 Dec 2014 08:25:23 +0100 Thread-Topic: [v6ops] Working Group Administrivia Thread-Index: AQHQELfApl0OmdTiikqs9ZO27DRlMpyG44KAgAErHyCAAGTHcA== Message-ID: References: <08DA982D-6605-434B-B815-C69B8A97FA4C@cisco.com> <154FBC4D-2FCE-4AC0-9881-3CB34924B6ED@cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AFEA5F3@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AFEA5F3@nkgeml512-mbx.china.huawei.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/fL-COibdcWX0wiRRpHHHzLvNwsI Subject: Re: [v6ops] Working Group 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: Wed, 10 Dec 2014 07:25:33 -0000 KzEgDQoJT2xhZg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdjZvcHMgW21h aWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU2hlbmcgSmlhbmcNClNl bnQ6IE1pdHR3b2NoLCAxMC4gRGV6ZW1iZXIgMjAxNCAwMjozNA0KVG86IEZyZWQgQmFrZXIgKGZy ZWQpOyB2Nm9wc0BpZXRmLm9yZyBXRw0KU3ViamVjdDogUmU6IFt2Nm9wc10gV29ya2luZyBHcm91 cCBBZG1pbmlzdHJpdmlhDQoNCj5MZXQgbWUgYXNrIHNwZWNpZmljYWxseSBhYm91dCB0aGUg4oCc VUxB4oCdIGFuZCDigJxEZXNpZ24gQ2hvaWNlc+KAnSBkb2N1bWVudHMuDQo+VGhleSBoYXZlIG5v dCBleHBpcmVkIGFuZCB0aGVpciBhdXRob3JzIGFyZSBzdGlsbCB3b3JraW5nIG9uIHRoZW0uIA0K PkJyaWFuIGhhcyBjb21tZW50ZWQ7IG90aGVycyBoYXZlIG5vdC4gRG8gd2Ugd2FudCB0byBrZWVw IHdvcmtpbmcgb24gdGhlbT8NCg0KVGhlIFdHIGNlcnRhaW5seSBzaG93ZWQgaW50ZXJlc3RzIHdo ZW4gdGhlc2UgZG9jdW1lbnRzIHdlcmUgYWRvcHRlZC4gVGhlIHRvcGljcyBhcmUgdXNlZnVsLiBU aGVuLCBtYXliZSBsb25nIHByb2Nlc3MgYW5kIHdpZGUgZGlzY3Vzc2lvbiAoc29tZSBkaXNjdXNz aW9uIG1heSBiZSByZWxldmFudCwgYnV0IG5vdCBlc3NlbnRpYWwgZm9yIHRoZSBjb3JlIGNvbnRl bnRzIG9mIHRoZXNlIGRvY3VtZW50cykgaGF2ZSBkaXN0cmFjdGVkIHBlb3BsZSdzIGludGVyZXN0 cy4gTGV0J3MgZ2V0IGJhY2sgdG8gdGhlIG9yaWdpbmFsIG1vdGl2YXRpb25zLCBmb2N1cyBvbiB0 aGUgY29yZSBjb250ZW50cywgYW5kIGNvbXBsZXRlIHRoZW0gYXMgcXVpY2sgYXMgcG9zc2libGUu DQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPk9uIERlYyA1LCAyMDE0LCBhdCAxMDoxNyBB TSwgRnJlZCBCYWtlciAoZnJlZCkgPGZyZWRAY2lzY28uY29tPiB3cm90ZToNCj4NCj4+IEFsdGhv dWdoIHRoZSB3b3JraW5nIGdyb3VwIGV4cHJlc3NlZCBpbnRlcmVzdCBpbiB0aGUgZm9sbG93aW5n IGFuZCANCj4+IHRoZQ0KPmF1dGhvcnMgaGF2ZSBiZWVuIHdvcmtpbmcgaGFyZCBvbiB0aGVtLCB3 ZSB0aGluayB0aGUgd29ya2luZyBncm91cCBpcyANCj5ubyBsb25nZXIgaW50ZXJlc3RlZCBpbiB0 aGVzZSwgYW5kIHNvIHRoZXkgc2hvdWxkIGJlIHJldHVybmVkIHRvIHRoZSANCj5hdXRob3JzIGFu ZCBub3QgcmVjb3JkZWQgb3IgdHJlYXRlZCBhcyB3b3JraW5nIGdyb3VwIGRyYWZ0cy4NCj4+DQo+ PiAyMDE0LTA5LTE4ICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLXY2b3BzLWRlc2lnbi1jaG9p Y2VzDQo+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLWRl c2lnbi1jaG9pY2VzLw0KPj4gMjAxNC0xMC0yNyAgICAgICAgICAgZHJhZnQtaWV0Zi12Nm9wcy1k aGNwdjYtc2xhYWMtcHJvYmxlbQ0KPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbS8NCj4+IDIwMTQtMTAtMjcgICAgICBk cmFmdC1pZXRmLXY2b3BzLXVsYS11c2FnZS1yZWNvbW1lbmRhdGlvbnMNCj5odHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtdWxhLXVzYWdlLXJlY29tbWVuZGF0 aQ0KPm9ucw0KPi8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From nobody Wed Dec 10 08:18: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 39DC31A7030 for ; Wed, 10 Dec 2014 08:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 0E91RT7Itg4z for ; Wed, 10 Dec 2014 08:18:28 -0800 (PST) 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 EA2241A1A10 for ; Wed, 10 Dec 2014 08:18:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1171; q=dns/txt; s=iport; t=1418228309; x=1419437909; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gXSQeH5nj0nrUUOi8Fpmm4IAijfqjJFATOLrNZ7rcuI=; b=VOaGmb/07HdcApiKO7eFjp9j9CbRTrnwuUwq9ogQmdZy3gtz/z6Znu16 iNsMPyNaNmk42XsAAMYwNe+TLLIUmTTHt+Cb24zfvnZoKC8MP7n+XxV+I a8jr3FfGDuctpZsWe4ZlMYAkX+fMsc15gAj0mXl5/oufMcPCZTtBGKWpV w=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgFAP1xiFStJA2E/2dsb2JhbABZgwaBKgTDUYgrAoEYFgEBAQEBfYQNAQEDAXkFCwIBCEYyJQIEDgUOiCII2D4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXkAMHgyGBFQWOAoFLgSeFf5Fag25ugUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,553,1413244800"; d="asc'?scan'208";a="104460336" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP; 10 Dec 2014 16:18:27 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sBAGIQTt025039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Dec 2014 16:18:26 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 10:18:26 -0600 From: "Fred Baker (fred)" To: Sheng Jiang Thread-Topic: [v6ops] Working Group Administrivia Thread-Index: AQHQFJTsKIUVJmDXqEiAyWz/Bjwiqw== Date: Wed, 10 Dec 2014 16:18:25 +0000 Message-ID: References: <08DA982D-6605-434B-B815-C69B8A97FA4C@cisco.com> <154FBC4D-2FCE-4AC0-9881-3CB34924B6ED@cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AFEA5F3@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AFEA5F3@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_6F0E304E-188B-4EF8-8BF1-06AAA083918D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KQ2gOOD0Tflfx1Z7tEdF4qt6MGo Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Working Group 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: Wed, 10 Dec 2014 16:18:30 -0000 --Apple-Mail=_6F0E304E-188B-4EF8-8BF1-06AAA083918D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 9, 2014, at 5:33 PM, Sheng Jiang wrote: > The WG certainly showed interests when these documents were adopted. = The topics are useful. Then, maybe long process and wide discussion = (some discussion may be relevant, but not essential for the core = contents of these documents) have distracted people's interests. Let's = get back to the original motivations, focus on the core contents, and = complete them as quick as possible. Works for me.=20 --Apple-Mail=_6F0E304E-188B-4EF8-8BF1-06AAA083918D 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 iD8DBQFUiHJQbjEdbHIsm0MRAhVQAJ0TPm98kTwFfjL4jULTx7ryeVXotgCglwAu FQjcxAjsbm8CvJjtBZXzbPU= =Kbmk -----END PGP SIGNATURE----- --Apple-Mail=_6F0E304E-188B-4EF8-8BF1-06AAA083918D-- From nobody Wed Dec 10 09:48: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 575261A7017 for ; Wed, 10 Dec 2014 09:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 TurcxnAXpmVE for ; Wed, 10 Dec 2014 09:48:17 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017551A87D2 for ; Wed, 10 Dec 2014 09:48:03 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id gm9so2912865lab.12 for ; Wed, 10 Dec 2014 09:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lgFvh268TntaKc1C+qWUmM23pRQt8rhI/UnnERakDkk=; b=dGGb9VnIEdqe9yP2fLQrQwsAv4l72T9bDGTeNp7lPBsrmP9g/cKITiUUFLKxpLjq0F ONOejUImjp+4g8SsCLQzbKlahogU9vBNN18uuZlXPwliv3g+G+TOF5gMBrR59m8L1wq3 AfoUTnrZH6afxtUoEiauPIezXTetjaAbZtX3Vt+6UY27pSXHSi4wCFGKG/CHKbAjE6Rd 2/ztchusu83QaHsMv6qZJsFzvcN0ExTuqxwOeJFVtGNCmpUB51HEQqd4wmARG2ex/kXe vV00PzzH9Jyd9GaLYY1ZGXZGU6DUm2FU0o3e7ramW8CbzK2thRrfOAVD94M4yHnkG2JX 7tnw== MIME-Version: 1.0 X-Received: by 10.112.159.229 with SMTP id xf5mr5310313lbb.64.1418233681151; Wed, 10 Dec 2014 09:48:01 -0800 (PST) Received: by 10.112.35.100 with HTTP; Wed, 10 Dec 2014 09:48:01 -0800 (PST) Date: Wed, 10 Dec 2014 11:48:01 -0600 Message-ID: From: Alberto Leiva To: v6ops@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0E70O1ieB-oFSR3LeVDTIGSA7E4 Subject: Re: [v6ops] draft-anderson-v6ops-siit-eam-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: Wed, 10 Dec 2014 17:48:18 -0000 >>> A) Remove all the normative RFC6145 protocol update language from >>> draft-anderson-siit-dc, taking this document off the standards >>> track, and have it describe the data centre use case only. Instead >>> contain the required protocol update in a separate document dedicated >>> to that purpose, i.e., draft-anderson-v6ops-siit-eam. >> >> +1 >> >> I'd like to see the protocol stuff in a separate -eam doc and leave the application description in -dc. That way future work can easily reference the -eam work even if its use case is outside of -dc. > >Agreed. > > Brian +1 :) -dc sounds a little too low level, while -eam sounds like something users would benefit from reading. It's a lot easier to convince users and co-workers to read simpler/shorter documents. Sorry for being silly. Also sorry if this doesn't appear threaded. From nobody Wed Dec 10 09:58: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 A961A1A00BD for ; Wed, 10 Dec 2014 09:58:22 -0800 (PST) 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 yKj4UsdMdgaH for ; Wed, 10 Dec 2014 09:58:18 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::722]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C8AF1A1B12 for ; Wed, 10 Dec 2014 09:58:18 -0800 (PST) Received: from pc6 (81.151.166.145) by AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) with Microsoft SMTP Server (TLS) id 15.1.31.17; Wed, 10 Dec 2014 17:39:42 +0000 Message-ID: <05aa01d014a0$43c5be20$4001a8c0@gateway.2wire.net> From: t.petch To: Sheng Jiang , "Fred Baker (fred)" , References: <08DA982D-6605-434B-B815-C69B8A97FA4C@cisco.com> <010701d01204$b8e18160$4001a8c0@gateway.2wire.net> <5D36713D8A4E7348A7E10DF7437A4B923AFDB427@nkgeml512-mbx.china.huawei.com> Date: Wed, 10 Dec 2014 17:39:29 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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: [81.151.166.145] X-ClientProxiedBy: DB3PR05CA0052.eurprd05.prod.outlook.com (25.160.41.180) To AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB055; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB055; X-Forefront-PRVS: 0421BF7135 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(377424004)(199003)(377454003)(189002)(40100003)(20776003)(64706001)(47776003)(68736005)(81816999)(120916001)(62236002)(99396003)(44716002)(97736003)(50226001)(4396001)(122386002)(66066001)(31966008)(46102003)(50466002)(1720100001)(50986999)(15975445007)(1456003)(81686999)(84392001)(76176999)(23676002)(77096005)(61296003)(19580405001)(21056001)(14496001)(1556002)(42186005)(19580395003)(87976001)(92566001)(105586002)(62966003)(86362001)(106356001)(107886001)(107046002)(77156002)(89996001)(33646002)(101416001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB055; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB055; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Vz4XVj8LrKJkQTByz-eyG7y3Lj4 Subject: Re: [v6ops] Working Group 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: Wed, 10 Dec 2014 17:58:22 -0000 Sheng If I read the e-mail addresses aright, you are the editor of draft-ietf-v6ops-dhcpv6-slaac-problem What do you want (that I might be able to do) bofore this is ready for WG Last Call? Tom Petch ----- Original Message ----- From: "Sheng Jiang" To: "t.petch" ; "Fred Baker (fred)" ; Sent: Monday, December 08, 2014 2:18 AM Subject: RE: [v6ops] Working Group Administrivia > >As Brian says in his note, > > > >2014-10-27 draft-ietf-v6ops-dhcpv6-slaac-problem > >http://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ > > > >addresses a known problem and I think it would be remiss of the IETF not > >to have this documented > > Fully agreed. My read from the latest meeting response is the problem should be document and know by operators and implementors. The controversial part is not this draft, but the follow up of this draft: > > 1) The solution (protocol level) is not belong to v6ops WG. > > 2) The real debate is Whether v6ops should produce an operational guidelines for operators to avoid this issue. Personally, I think it is helpful and belong to this WG, but it seems the WG does not reach consensus on this. > > Best regards, > > Sheng > > >Tom Petch > > > > > >----- Original Message ----- > >From: "Fred Baker (fred)" > >To: > >Sent: Friday, December 05, 2014 6:17 PM > >Subject: [v6ops] Working Group Administrivia > > > > > >Joel, Lee, and I spoke this morning about the status of the working > >group and various drafts in it. I’d like to gauge working group > >consensus on the status of a number of working group drafts that have > >either expired or otherwise should no longer be considered working group > >drafts. Your opinions, pro or con (such as “I’m fine with all that but > >think we should still be considering draft-whateverâ€), please: > > > >We think that the following can be safely set aside, by having the > >secretariat record (and show in the data tracker) that they are no > >longer working group drafts. They have expired, and are not currently > >being pursued: > > > >2003-01-13 draft-ietf-v6ops-ipv4survey > >http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv4survey/ > >2003-02-14 draft-ietf-v6ops-ipv4survey-gen > >http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv4survey-gen/ > >2004-07-20 draft-ietf-v6ops-v6onbydefault > >http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6onbydefault/ > >2007-02-27 draft-ietf-v6ops-routing-guidelines > >http://datatracker.ietf.org/doc/draft-ietf-v6ops-routing-guidelines/ > >2007-03-28 draft-ietf-v6ops-campus-transition > >http://datatracker.ietf.org/doc/draft-ietf-v6ops-campus-transition/ > >2008-05-13 draft-ietf-v6ops-nat64-pb-statement-req > >http://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-pb-statement-req / > >2011-07-26 draft-ietf-v6ops-v4v6tran-framework > >http://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6tran-framework/ > >2013-08-14 draft-ietf-v6ops-monitor-ds-ipv6 > >http://datatracker.ietf.org/doc/draft-ietf-v6ops-monitor-ds-ipv6/ > > > >We think that draft-ietf-v6ops-balanced-ipv6-security, in its current > >state, is a deployment report, primarily from Swisscom. While the > >working group expressed interest in guidance on firewall configuration, > >this isn’t it. We think it should no longer be a working group draft, > >and invite the authors to submit it to the independent stream as a > >deployment report ( > > >2013-12-06 draft-ietf-v6ops-balanced-ipv6-security > >http://datatracker.ietf.org/doc/draft-ietf-v6ops-balanced-ipv6-security / > > > >Although the working group expressed interest in the following and the > >authors have been working hard on them, we think the working group is no > >longer interested in these, and so they should be returned to the > >authors and not recorded or treated as working group drafts. > > > >2014-09-18 draft-ietf-v6ops-design-choices > >http://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ > >2014-10-27 draft-ietf-v6ops-dhcpv6-slaac-problem > >http://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ > >2014-10-27 draft-ietf-v6ops-ula-usage-recommendations > >http://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommendati o > >ns/ > > > >Speaking for myself, if I have any question of the above, it is on only > >one of these. > > > >If any draft has its "WG Draft" status revoked, it will still be > >available from the IETF website as far as I know, but subsequent > >revisions should be named as individual submissions to a working group, > >draft--- or individual submissions to the IETF, > >draft--. It would be good if the authors would send a > >note to internet-drafts@ietf.org indicating that the old draft name were > >replaced by the new draft name, so that the revision history is tracked > >appropriately. > > > >Opinions? > > > > > > > > > >----------------------------------------------------------------------- - > >-------- > > > > > >> > >> > > > > > >----------------------------------------------------------------------- - > >-------- > > > > > >> _______________________________________________ > >> 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 Dec 10 10:51: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 63EE81A8984; Wed, 10 Dec 2014 10:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[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 lOBkdLTdrLVy; Wed, 10 Dec 2014 10:51:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7701A88A6; Wed, 10 Dec 2014 10:50:53 -0800 (PST) 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.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141210185053.32277.17868.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 10:50:53 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-dpIaEuriRgmWlv758q6i4kryKM Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-09.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: Wed, 10 Dec 2014 18:51:08 -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 : Deprecating Anycast Prefix for 6to4 Relay Routers Authors : Ole Troan Brian Carpenter Filename : draft-ietf-v6ops-6to4-to-historic-09.txt Pages : 8 Date : 2014-12-10 Abstract: Experience with the "Connection of IPv6 Domains via IPv4 Clouds (6to4)" IPv6 transition mechanism defined in RFC 3056 has shown that when used in its anycast mode, the mechanism is unsuitable for widespread deployment and use in the Internet. This document therefore requests that RFC 3068, "An Anycast Prefix for 6to4 Relay Routers", be made obsolete and moved to historic status. It also obsoletes RFC 6732 "6to4 Provider Managed Tunnels". It recommends that future products should not support 6to4 anycast and that existing deployments should be reviewed. This complements the guidelines in RFC 6343. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6to4-to-historic-09 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 Wed Dec 10 10: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 8286A1A8A7F for ; Wed, 10 Dec 2014 10:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 8epYQFSEG6zq for ; Wed, 10 Dec 2014 10:57:03 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e: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 A36AA1A1AA7 for ; Wed, 10 Dec 2014 10:57:03 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id rd3so3356028pab.7 for ; Wed, 10 Dec 2014 10:57:03 -0800 (PST) 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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/aa0Rn6Ifu95PwWIute7ZMHlcVnwCUejf5mqvaIBPB0=; b=rjjS26zJHHaqoVFz1K5E1H8hhi98LUQkQXt4AxeJn+MNDJSjSwiD1YTqNjxmd46OjK JCLYFCQQM61hcdCsxzDpzFo/WFv4KKi1zkPDslqpzb2s/N2NhSQCw2irp97eV++DQ3/P y/y+icZ8serUTSFJY4jlXBNEsMsgw8j8IlEaSy393sfbVCLOBOWRi4hkbMN810A+qQdL gnsPtX+CGNapt3PmfitEF9ogFiEBSO7Afw83LB1DMAT/c9Z0IXo/OR19eH1JtzKdwS5g 44uyK+Rfgq4rZgIbnT+0ec4lbXLRX5+PIQh0dA8RvGcF/Uqw15YBiyAjwPD0O7wu0UOU I2fA== X-Received: by 10.68.193.2 with SMTP id hk2mr8982155pbc.90.1418237822917; Wed, 10 Dec 2014 10:57:02 -0800 (PST) Received: from [192.168.178.26] (92.230.69.111.dynamic.snap.net.nz. [111.69.230.92]) by mx.google.com with ESMTPSA id bu4sm4866245pdb.80.2014.12.10.10.57.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Dec 2014 10:57:01 -0800 (PST) Message-ID: <5488977E.3010007@gmail.com> Date: Thu, 11 Dec 2014 07:57:02 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: v6ops@ietf.org References: <20141210185053.32277.17868.idtracker@ietfa.amsl.com> In-Reply-To: <20141210185053.32277.17868.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5kIuOt1YBu8wRiSB5x0NnKZwog0 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt 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, 10 Dec 2014 18:57:09 -0000 Hi, This version has been updated after re-reading the long thread generated by the WGLC. The major change reflects the fact that there was obviously no consensus for the recommendation to filter the anycast route. The other changes reflect other points that came up in the discussion. One extra comment. With the removal of the filtering recommendation, there is (the editor believes) no substantive change to the guidelines in RFC 6343, so "Updates: 6343" has been removed. Regards Brian Carpenter On 11/12/2014 07:50, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : Deprecating Anycast Prefix for 6to4 Relay Routers > Authors : Ole Troan > Brian Carpenter > Filename : draft-ietf-v6ops-6to4-to-historic-09.txt > Pages : 8 > Date : 2014-12-10 > > Abstract: > Experience with the "Connection of IPv6 Domains via IPv4 Clouds > (6to4)" IPv6 transition mechanism defined in RFC 3056 has shown that > when used in its anycast mode, the mechanism is unsuitable for > widespread deployment and use in the Internet. This document > therefore requests that RFC 3068, "An Anycast Prefix for 6to4 Relay > Routers", be made obsolete and moved to historic status. It also > obsoletes RFC 6732 "6to4 Provider Managed Tunnels". It recommends > that future products should not support 6to4 anycast and that > existing deployments should be reviewed. This complements the > guidelines in RFC 6343. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6to4-to-historic-09 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Wed Dec 10 18:24: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 4FEBB1A1A91 for ; Wed, 10 Dec 2014 18:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 EdUnsh1FQ-PZ for ; Wed, 10 Dec 2014 18:24:35 -0800 (PST) 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 E44751A1A4E for ; Wed, 10 Dec 2014 18:24:33 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPX49692; Thu, 11 Dec 2014 02:24:32 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 11 Dec 2014 02:24:31 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.128]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Thu, 11 Dec 2014 10:24:25 +0800 From: Sheng Jiang To: "t.petch" , "Fred Baker (fred)" , "v6ops@ietf.org" Thread-Topic: [v6ops] Working Group Administrivia Thread-Index: AQHQELfApl0OmdTiikqs9ZO27DRlMpyD67olgAEAGMCABDNY1YAAiuIQ Date: Thu, 11 Dec 2014 02:24:24 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AFEBEB2@nkgeml512-mbx.china.huawei.com> References: <08DA982D-6605-434B-B815-C69B8A97FA4C@cisco.com> <010701d01204$b8e18160$4001a8c0@gateway.2wire.net> <5D36713D8A4E7348A7E10DF7437A4B923AFDB427@nkgeml512-mbx.china.huawei.com> <05aa01d014a0$43c5be20$4001a8c0@gateway.2wire.net> In-Reply-To: <05aa01d014a0$43c5be20$4001a8c0@gateway.2wire.net> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/O5aLb_qvIQqr7mNKscVArCyrdP4 Subject: Re: [v6ops] Working Group 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: Thu, 11 Dec 2014 02:24:37 -0000 SGksIFRvbSwNCg0KVGhhbmtzIGZvciB5b3VyIG9mZmVyLg0KDQpSZXZpZXcgYW5kIGNvbW1lbnRz IHdvdWxkIGJlIHZlcnkgaGVscGZ1bCBmb3IgdXMgdG8gaW1wcm92ZS4gRm9sbG93aW5nIHRoZSBs YXRlc3QgZGlzY3Vzc2lvbiwgdGhlcmUgYXJlIHR3byBhY3Rpb25zIHdlIGFyZSBwbGFubmluZzog QSkgZm9jdXMgb24gdGhlIGltcGxlbWVudGF0aW9uIGRpdmVyZ2VuY2UgcmF0aGVyIHRoYW4gYSBw cm90b2NvbCBkZWZpbml0aW9uIHByb2JsZW0gc3RhdGVtZW50LiBUaGUgbW9zdCBvZiBjb250ZW50 cyBhcmUgYWxyZWFkeSBpbiB0aGUgY3VycmVudCBkb2N1bWVudC4gSXQganVzdCBuZWVkcyBhIGxp dHRsZSBiaXQgcmVvcmdhbml6aW5nIGFuZCByZXdvcmRpbmcuIEIpIHNvbWUgYWRkaXRpb24gaW52 ZXN0aWdhdGlvbiBvciBleHBlcmltZW50cywgZS5nLiBib3RoIERIQ1B2NiBhbmQgTkQgaGF2ZSBE TlMgY29uZmlndXJhdGlvbi4NCg0KSWYgeW91IGFyZSBpbnRlcmVzdGVkIHRvIGNvbnRyaWJ1dGUs IHlvdSBhcmUgY2VydGFpbmx5IHdlbGNvbWUuDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0K Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogdC5wZXRjaCBbbWFpbHRvOmlldGZj QGJ0Y29ubmVjdC5jb21dDQo+U2VudDogVGh1cnNkYXksIERlY2VtYmVyIDExLCAyMDE0IDE6Mzkg QU0NCj5UbzogU2hlbmcgSmlhbmc7IEZyZWQgQmFrZXIgKGZyZWQpOyB2Nm9wc0BpZXRmLm9yZw0K PlN1YmplY3Q6IFJlOiBbdjZvcHNdIFdvcmtpbmcgR3JvdXAgQWRtaW5pc3RyaXZpYQ0KPg0KPlNo ZW5nDQo+DQo+SWYgSSByZWFkIHRoZSBlLW1haWwgYWRkcmVzc2VzIGFyaWdodCwgeW91IGFyZSB0 aGUgZWRpdG9yIG9mDQo+ZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbQ0KPldo YXQgZG8geW91IHdhbnQgKHRoYXQgSSBtaWdodCBiZSBhYmxlIHRvIGRvKSBib2ZvcmUgdGhpcyBp cyByZWFkeSBmb3INCj5XRyBMYXN0IENhbGw/DQo+DQo+VG9tIFBldGNoDQo+DQo+DQo+LS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPkZyb206ICJTaGVuZyBKaWFuZyIgPGppYW5nc2hlbmdA aHVhd2VpLmNvbT4NCj5UbzogInQucGV0Y2giIDxpZXRmY0BidGNvbm5lY3QuY29tPjsgIkZyZWQg QmFrZXIgKGZyZWQpIg0KPjxmcmVkQGNpc2NvLmNvbT47IDx2Nm9wc0BpZXRmLm9yZz4NCj5TZW50 OiBNb25kYXksIERlY2VtYmVyIDA4LCAyMDE0IDI6MTggQU0NCj5TdWJqZWN0OiBSRTogW3Y2b3Bz XSBXb3JraW5nIEdyb3VwIEFkbWluaXN0cml2aWENCj4NCj4NCj4+ID5BcyBCcmlhbiBzYXlzIGlu IGhpcyBub3RlLA0KPj4gPg0KPj4gPjIwMTQtMTAtMjcgICAgICAgICAgIGRyYWZ0LWlldGYtdjZv cHMtZGhjcHY2LXNsYWFjLXByb2JsZW0NCj4+DQo+Pmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbS8NCj4+ID4NCj4+ID5h ZGRyZXNzZXMgYSBrbm93biBwcm9ibGVtIGFuZCBJIHRoaW5rIGl0IHdvdWxkIGJlIHJlbWlzcyBv ZiB0aGUgSUVURg0KPm5vdA0KPj4gPnRvIGhhdmUgdGhpcyBkb2N1bWVudGVkDQo+Pg0KPj4gRnVs bHkgYWdyZWVkLiBNeSByZWFkIGZyb20gdGhlIGxhdGVzdCBtZWV0aW5nIHJlc3BvbnNlIGlzIHRo ZSBwcm9ibGVtDQo+c2hvdWxkIGJlIGRvY3VtZW50IGFuZCBrbm93IGJ5IG9wZXJhdG9ycyBhbmQg aW1wbGVtZW50b3JzLiBUaGUNCj5jb250cm92ZXJzaWFsIHBhcnQgaXMgbm90IHRoaXMgZHJhZnQs IGJ1dCB0aGUgZm9sbG93IHVwIG9mIHRoaXMgZHJhZnQ6DQo+Pg0KPj4gMSkgVGhlIHNvbHV0aW9u IChwcm90b2NvbCBsZXZlbCkgaXMgbm90IGJlbG9uZyB0byB2Nm9wcyBXRy4NCj4+DQo+PiAyKSBU aGUgcmVhbCBkZWJhdGUgaXMgV2hldGhlciB2Nm9wcyBzaG91bGQgcHJvZHVjZSBhbiBvcGVyYXRp b25hbA0KPmd1aWRlbGluZXMgZm9yIG9wZXJhdG9ycyB0byBhdm9pZCB0aGlzIGlzc3VlLiBQZXJz b25hbGx5LCBJIHRoaW5rIGl0IGlzDQo+aGVscGZ1bCBhbmQgYmVsb25nIHRvIHRoaXMgV0csIGJ1 dCBpdCBzZWVtcyB0aGUgV0cgZG9lcyBub3QgcmVhY2gNCj5jb25zZW5zdXMgb24gdGhpcy4NCj4+ DQo+PiBCZXN0IHJlZ2FyZHMsDQo+Pg0KPj4gU2hlbmcNCj4+DQo+PiA+VG9tIFBldGNoDQo+PiA+ DQo+PiA+DQo+PiA+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPj4gPkZyb206ICJGcmVk IEJha2VyIChmcmVkKSIgPGZyZWRAY2lzY28uY29tPg0KPj4gPlRvOiA8djZvcHNAaWV0Zi5vcmc+ DQo+PiA+U2VudDogRnJpZGF5LCBEZWNlbWJlciAwNSwgMjAxNCA2OjE3IFBNDQo+PiA+U3ViamVj dDogW3Y2b3BzXSBXb3JraW5nIEdyb3VwIEFkbWluaXN0cml2aWENCj4+ID4NCj4+ID4NCj4+ID5K b2VsLCBMZWUsIGFuZCBJIHNwb2tlIHRoaXMgbW9ybmluZyBhYm91dCB0aGUgc3RhdHVzIG9mIHRo ZSB3b3JraW5nDQo+PiA+Z3JvdXAgYW5kIHZhcmlvdXMgZHJhZnRzIGluIGl0LiBJ4oCZZCBsaWtl IHRvIGdhdWdlIHdvcmtpbmcgZ3JvdXANCj4+ID5jb25zZW5zdXMgb24gdGhlIHN0YXR1cyBvZiBh IG51bWJlciBvZiB3b3JraW5nIGdyb3VwIGRyYWZ0cyB0aGF0IGhhdmUNCj4+ID5laXRoZXIgZXhw aXJlZCBvciBvdGhlcndpc2Ugc2hvdWxkIG5vIGxvbmdlciBiZSBjb25zaWRlcmVkIHdvcmtpbmcN Cj5ncm91cA0KPj4gPmRyYWZ0cy4gWW91ciBvcGluaW9ucywgcHJvIG9yIGNvbiAoc3VjaCBhcyDi gJxJ4oCZbSBmaW5lIHdpdGggYWxsIHRoYXQNCj5idXQNCj4+ID50aGluayB3ZSBzaG91bGQgc3Rp bGwgYmUgY29uc2lkZXJpbmcgZHJhZnQtd2hhdGV2ZXLigJ0pLCBwbGVhc2U6DQo+PiA+DQo+PiA+ V2UgdGhpbmsgdGhhdCB0aGUgZm9sbG93aW5nIGNhbiBiZSBzYWZlbHkgc2V0IGFzaWRlLCBieSBo YXZpbmcgdGhlDQo+PiA+c2VjcmV0YXJpYXQgcmVjb3JkIChhbmQgc2hvdyBpbiB0aGUgZGF0YSB0 cmFja2VyKSB0aGF0IHRoZXkgYXJlIG5vDQo+PiA+bG9uZ2VyIHdvcmtpbmcgZ3JvdXAgZHJhZnRz LiBUaGV5IGhhdmUgZXhwaXJlZCwgYW5kIGFyZSBub3QgY3VycmVudGx5DQo+PiA+YmVpbmcgcHVy c3VlZDoNCj4+ID4NCj4+ID4yMDAzLTAxLTEzICAgICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0 Zi12Nm9wcy1pcHY0c3VydmV5DQo+PiA+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLXY2b3BzLWlwdjRzdXJ2ZXkvDQo+PiA+MjAwMy0wMi0xNCAgICAgICAgICAgICAg ICAgZHJhZnQtaWV0Zi12Nm9wcy1pcHY0c3VydmV5LWdlbg0KPj4gPmh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy1pcHY0c3VydmV5LWdlbi8NCj4+ID4yMDA0 LTA3LTIwICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi12Nm9wcy12Nm9uYnlkZWZhdWx0DQo+ PiA+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLXY2b25i eWRlZmF1bHQvDQo+PiA+MjAwNy0wMi0yNyAgICAgICAgICAgICBkcmFmdC1pZXRmLXY2b3BzLXJv dXRpbmctZ3VpZGVsaW5lcw0KPj4gPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi12Nm9wcy1yb3V0aW5nLWd1aWRlbGluZXMvDQo+PiA+MjAwNy0wMy0yOCAgICAgICAg ICAgICAgZHJhZnQtaWV0Zi12Nm9wcy1jYW1wdXMtdHJhbnNpdGlvbg0KPj4gPmh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy1jYW1wdXMtdHJhbnNpdGlvbi8N Cj4+ID4yMDA4LTA1LTEzICAgICAgICAgZHJhZnQtaWV0Zi12Nm9wcy1uYXQ2NC1wYi1zdGF0ZW1l bnQtcmVxDQo+Pg0KPj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt djZvcHMtbmF0NjQtcGItc3RhdGVtZW50LXJlcQ0KPi8NCj4+ID4yMDExLTA3LTI2ICAgICAgICAg ICAgIGRyYWZ0LWlldGYtdjZvcHMtdjR2NnRyYW4tZnJhbWV3b3JrDQo+PiA+aHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLXY0djZ0cmFuLWZyYW1ld29yay8N Cj4+ID4yMDEzLTA4LTE0ICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtdjZvcHMtbW9uaXRvci1k cy1pcHY2DQo+PiA+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2 b3BzLW1vbml0b3ItZHMtaXB2Ni8NCj4+ID4NCj4+ID5XZSB0aGluayB0aGF0IGRyYWZ0LWlldGYt djZvcHMtYmFsYW5jZWQtaXB2Ni1zZWN1cml0eSwgaW4gaXRzIGN1cnJlbnQNCj4+ID5zdGF0ZSwg aXMgYSBkZXBsb3ltZW50IHJlcG9ydCwgcHJpbWFyaWx5IGZyb20gU3dpc3Njb20uIFdoaWxlIHRo ZQ0KPj4gPndvcmtpbmcgZ3JvdXAgZXhwcmVzc2VkIGludGVyZXN0IGluIGd1aWRhbmNlIG9uIGZp cmV3YWxsDQo+Y29uZmlndXJhdGlvbiwNCj4+ID50aGlzIGlzbuKAmXQgaXQuIFdlIHRoaW5rIGl0 IHNob3VsZCBubyBsb25nZXIgYmUgYSB3b3JraW5nIGdyb3VwIGRyYWZ0LA0KPj4gPmFuZCBpbnZp dGUgdGhlIGF1dGhvcnMgdG8gc3VibWl0IGl0IHRvIHRoZSBpbmRlcGVuZGVudCBzdHJlYW0gYXMg YQ0KPj4gPmRlcGxveW1lbnQgcmVwb3J0ICg8cmZjLWlzZUByZmMtZWRpdG9yLm9yZykuDQo+PiA+ DQo+PiA+MjAxMy0xMi0wNiAgICAgICAgIGRyYWZ0LWlldGYtdjZvcHMtYmFsYW5jZWQtaXB2Ni1z ZWN1cml0eQ0KPj4NCj4+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LXY2b3BzLWJhbGFuY2VkLWlwdjYtc2VjdXJpdHkNCj4vDQo+PiA+DQo+PiA+QWx0aG91Z2ggdGhl IHdvcmtpbmcgZ3JvdXAgZXhwcmVzc2VkIGludGVyZXN0IGluIHRoZSBmb2xsb3dpbmcgYW5kDQo+ dGhlDQo+PiA+YXV0aG9ycyBoYXZlIGJlZW4gd29ya2luZyBoYXJkIG9uIHRoZW0sIHdlIHRoaW5r IHRoZSB3b3JraW5nIGdyb3VwIGlzDQo+bm8NCj4+ID5sb25nZXIgaW50ZXJlc3RlZCBpbiB0aGVz ZSwgYW5kIHNvIHRoZXkgc2hvdWxkIGJlIHJldHVybmVkIHRvIHRoZQ0KPj4gPmF1dGhvcnMgYW5k IG5vdCByZWNvcmRlZCBvciB0cmVhdGVkIGFzIHdvcmtpbmcgZ3JvdXAgZHJhZnRzLg0KPj4gPg0K Pj4gPjIwMTQtMDktMTggICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtdjZvcHMtZGVzaWduLWNo b2ljZXMNCj4+ID5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZv cHMtZGVzaWduLWNob2ljZXMvDQo+PiA+MjAxNC0xMC0yNyAgICAgICAgICAgZHJhZnQtaWV0Zi12 Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbQ0KPj4NCj4+aHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtLw0KPj4gPjIwMTQt MTAtMjcgICAgICBkcmFmdC1pZXRmLXY2b3BzLXVsYS11c2FnZS1yZWNvbW1lbmRhdGlvbnMNCj4+ DQo+Pmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy11bGEt dXNhZ2UtcmVjb21tZW5kYXRpDQo+bw0KPj4gPm5zLw0KPj4gPg0KPj4gPlNwZWFraW5nIGZvciBt eXNlbGYsIGlmIEkgaGF2ZSBhbnkgcXVlc3Rpb24gb2YgdGhlIGFib3ZlLCBpdCBpcyBvbg0KPm9u bHkNCj4+ID5vbmUgb2YgdGhlc2UuDQo+PiA+DQo+PiA+SWYgYW55IGRyYWZ0IGhhcyBpdHMgIldH IERyYWZ0IiBzdGF0dXMgcmV2b2tlZCwgaXQgd2lsbCBzdGlsbCBiZQ0KPj4gPmF2YWlsYWJsZSBm cm9tIHRoZSBJRVRGIHdlYnNpdGUgYXMgZmFyIGFzIEkga25vdywgYnV0IHN1YnNlcXVlbnQNCj4+ ID5yZXZpc2lvbnMgc2hvdWxkIGJlIG5hbWVkIGFzIGluZGl2aWR1YWwgc3VibWlzc2lvbnMgdG8g YSB3b3JraW5nDQo+Z3JvdXAsDQo+PiA+ZHJhZnQtPGF1dGhvcj4tPHdnPi08c3ViamVjdD4gb3Ig aW5kaXZpZHVhbCBzdWJtaXNzaW9ucyB0byB0aGUgSUVURiwNCj4+ID5kcmFmdC08YXV0aG9yPi08 c3ViamVjdD4uIEl0IHdvdWxkIGJlIGdvb2QgaWYgdGhlIGF1dGhvcnMgd291bGQgc2VuZA0KPmEN Cj4+ID5ub3RlIHRvIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBpbmRpY2F0aW5nIHRoYXQgdGhl IG9sZCBkcmFmdCBuYW1lDQo+d2VyZQ0KPj4gPnJlcGxhY2VkIGJ5IHRoZSBuZXcgZHJhZnQgbmFt ZSwgc28gdGhhdCB0aGUgcmV2aXNpb24gaGlzdG9yeSBpcw0KPnRyYWNrZWQNCj4+ID5hcHByb3By aWF0ZWx5Lg0KPj4gPg0KPj4gPk9waW5pb25zPw0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4N Cj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4tDQo+PiA+LS0tLS0tLS0NCj4+ID4NCj4+ID4NCj4+ID4+DQo+ PiA+Pg0KPj4gPg0KPj4gPg0KPj4NCj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4tDQo+PiA+LS0tLS0tLS0N Cj4+ID4NCj4+ID4NCj4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiA+PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4+ID4+IHY2b3BzQGlldGYub3Jn DQo+PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+PiA+ Pg0KPj4gPg0KPj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiA+djZvcHMgbWFpbGluZyBsaXN0DQo+PiA+djZvcHNAaWV0Zi5vcmcNCj4+ID5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+Pg0KDQo= From nobody Thu Dec 11 07:43: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 8D4341A6F99 for ; Thu, 11 Dec 2014 07:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 Ko_mYQUKFyKn for ; Thu, 11 Dec 2014 07:43:32 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CFB31A1BC2 for ; Thu, 11 Dec 2014 07:43:32 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id CC3EF20BED for ; Thu, 11 Dec 2014 10:43:31 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 11 Dec 2014 10:43:31 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=0JyYHrZxjUU7N0EKCV16+/ iX69Q=; b=honbl9K5D6KE7wsn/Pe4D9A4W8OgyfTozvGaRsjnb/+KNTalWoEBzv VJkLIeAdBV7PzMQsKfny+sjMePUHe96MyKAj9KsCV+03RQUeIXhfko02ODnwiCPN fqhnUDUV/qgr0DKOvl2GY2LL8Vgui2KkTKPi+REz0nq2pzngqIPI0= X-Sasl-enc: cZWmkZO25jCIgtUOepr9YFdQWykr3FsOS/9vqNZKj4j2 1418312611 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 6CA8C6801BD; Thu, 11 Dec 2014 10:43:31 -0500 (EST) Message-ID: <5489BB7E.9030309@network-heretics.com> Date: Thu, 11 Dec 2014 10:42:54 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20141210185053.32277.17868.idtracker@ietfa.amsl.com> In-Reply-To: <20141210185053.32277.17868.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/bOzcnqcaFToJO7KgPCa_L7GrU_4 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt 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, 11 Dec 2014 15:43:33 -0000 Mumble. I support the deprecation of 192.88.99.1 as a means to find 6to4 relays. But this document still contains so many inaccurate and misleading statements beyond that, including perhaps some statements that were not present in earlier versions (though I haven't taken the time to check yet), that I don't believe it should be published in its current form. Again, this is a document quality issue, not an issue with the basic underlying recommendation. Most of the problems with this document are things that I have already mentioned in connection with earlier versions of this document. Keith From nobody Thu Dec 11 08:11: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 9460C1A00C2 for ; Thu, 11 Dec 2014 08:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 P9-AyYvlI5pO for ; Thu, 11 Dec 2014 08:10:48 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7931A0392 for ; Thu, 11 Dec 2014 08:10:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sBBGAmCk002560; Thu, 11 Dec 2014 08:10:48 -0800 Received: from XCH-PHX-513.sw.nos.boeing.com (xch-phx-513.sw.nos.boeing.com [10.57.37.30]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sBBGAjnT002539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 11 Dec 2014 08:10:45 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-PHX-513.sw.nos.boeing.com ([169.254.13.79]) with mapi id 14.03.0210.002; Thu, 11 Dec 2014 08:10:44 -0800 From: "Templin, Fred L" To: Jeroen Massar , "sthaug@nethelp.no" Thread-Topic: [v6ops] PMTUD forever, was: MTUs on the general Internet Thread-Index: AQHQEJwFpAeu1cDlMEapgQ1gXobqjpyC7YoAgAAEroCAABJggP//uZRwgAMmA/CABK/UIA== Date: Thu, 11 Dec 2014 16:10:44 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DB3502@XCH-BLV-504.nw.nos.boeing.com> References: <5481B5C8.6030501@massar.ch> <2134F8430051B64F815C691A62D9831832DAC16A@XCH-BLV-504.nw.nos.boeing.com> <5482E29A.1070802@massar.ch> <20141206.122039.74658588.sthaug@nethelp.no> <5482F5F1.8000907@massar.ch> <2134F8430051B64F815C691A62D9831832DAD225@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832DAE093@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832DAE093@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/iQaiaDUpmd2XNmHb5ITCyIJr5wE Cc: "v6ops@ietf.org" Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet 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, 11 Dec 2014 16:10:56 -0000 > More on what I said the other day, there are two magic numbers that tunne= ls > need to concern themselves with: 1280 and 1500. Accommodating all packets > within that size range while placing no explicit upper bound for accommod= ating > larger packets is what is being proposed. In other words, no MTU clamping= . Have we reached conclusion on this, and can it now be considered "case clos= ed"? Remember - "take care of the smalls, and let the bigs take care of themselv= es": https://datatracker.ietf.org/doc/draft-templin-aerolink/ https://datatracker.ietf.org/doc/draft-templin-aeromin/ Thanks - Fred fred.l.templin@boeing.com From nobody Thu Dec 11 11:23: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 E3EA11A870D for ; Thu, 11 Dec 2014 11:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 jPI4cC_aeoFu for ; Thu, 11 Dec 2014 11:23:14 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 129291A875A for ; Thu, 11 Dec 2014 11:23:05 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id lf10so4982130pab.5 for ; Thu, 11 Dec 2014 11:23:04 -0800 (PST) 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=Pu0q2hYFpcx9EQ7BQfzyYegAOGl6t6jZ6/vlnLUKTIU=; b=fZWs/E+8JJQhHNXFBQj9a0hSqv1C6Ob+rlZUlBli2wEULLKNh/MvrYouGj1XJ7WwwC qnTVV2mPS2n7rL9haB0QMdjTnRjUnhQ6uyqn1euDe0+p/NbwT9AgRhOSaAAEpNUyGolX uoJYzZv9zoLuMK9XDkqbbw3n/0bKKAJzj+GQEDfFKUAjkWD0jbiHG5RaKuym6CckbwgQ w0K8hzEfT1irBMMfs+TnJGkZACHboQHy5GmkLJU/0eFDs3RsYtKftNqnbYCeNRazwS1Y ynATAIZdZB926exm3RGhuY9IZR6WC6WGlkoE3HlAT0B3KOZCUo2QGaAY9ELu7Es4phNJ eh1Q== X-Received: by 10.68.197.194 with SMTP id iw2mr19623970pbc.73.1418325784296; Thu, 11 Dec 2014 11:23:04 -0800 (PST) Received: from [192.168.178.26] (54.229.69.111.dynamic.snap.net.nz. [111.69.229.54]) by mx.google.com with ESMTPSA id ud7sm2099763pbc.11.2014.12.11.11.23.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Dec 2014 11:23:03 -0800 (PST) Message-ID: <5489EF20.3050204@gmail.com> Date: Fri, 12 Dec 2014 08:23:12 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Keith Moore References: <20141210185053.32277.17868.idtracker@ietfa.amsl.com> <5489BB7E.9030309@network-heretics.com> In-Reply-To: <5489BB7E.9030309@network-heretics.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Rvc9iK2CcpYdObhxgJDaYxg7ngw Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt 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, 11 Dec 2014 19:23:18 -0000 Keith, please, you need to be specific about what you think is inaccurate or misleading, line by line, in this version. There's nothing we can do with a general criticism like that. We have made numerous changes, some of them in response to your comments, but of course in some cases your comments were at variance with other peoples' comments. Of course, there were a lot of messages, many of them completely orthogonal to the text of the draft, so we may well have missed some of the relevant ones. Regards Brian On 12/12/2014 04:42, Keith Moore wrote: > Mumble. I support the deprecation of 192.88.99.1 as a means to find > 6to4 relays. But this document still contains so many inaccurate and > misleading statements beyond that, including perhaps some statements > that were not present in earlier versions (though I haven't taken the > time to check yet), that I don't believe it should be published in its > current form. Again, this is a document quality issue, not an issue with > the basic underlying recommendation. > > Most of the problems with this document are things that I have already > mentioned in connection with earlier versions of this document. > > Keith > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Dec 11 23: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 6E5981AC3FD for ; Thu, 11 Dec 2014 23:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 yliC1Bx0zJGV for ; Thu, 11 Dec 2014 23:11:50 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A39791A9129 for ; Thu, 11 Dec 2014 23:11:50 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 19F23100B422F; Fri, 12 Dec 2014 07:11:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1418368307; bh=TMCM781e12wgOlXNbiNf+zYSBO69qgRiPd7IpGxFGjA=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=Ymj9SQZlNPF8MOpjM1FfPKlfR429SUt5GQ14Uh2gQoKk476tlmFjCwDSU6eAQAHUD hqZcPnCFHwJMQ6vAAqwwotdzx/Av2Pv5QFXL9b15BFRMgLknhgLRw7zHCGWEO2SH8f Mh1WtqC0x8E05xYdSNyb9kP6LzJgi38njhYPqb30t08jFd5pne18/PbRGonzo69Jsw KBtUsKpj3hSA9mUjT2NMXFLJWSlSTgpDAYhUtaQVS3abNYpoF25MdP1zdxbJYi/3Kr OC+gjgH5YazzE83aoZcJ88SZG+Z415biXdGzj0AwJZ34nnvFvaqUA7o3fAvL3OhCXf OFa7hPbfQs0+g== Message-ID: <548A9531.90300@massar.ch> Date: Fri, 12 Dec 2014 08:11:45 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Brian E Carpenter References: <54663F67.5080603@gmail.com> <546927A0.8030201@inex.ie> <546BAC1F.5020401@umn.edu> <20141118.223012.41712464.sthaug@nethelp.no> <546C4D41.2030406@massar.ch> <546CEF7D.2070504@gmail.com> In-Reply-To: <546CEF7D.2070504@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/GrsE6JiQILm5L9dsn-F6nBVOn_E Cc: v6ops@ietf.org Subject: Re: [v6ops] Who is stilll running 6to4 relays (Was: I-D Action: draft-ietf-v6ops-6to4-to-historic-08.txt) 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, 12 Dec 2014 07:11:53 -0000 On 2014-11-19 20:29, Brian E Carpenter wrote: > With the same Bcc: > >> Internet service >> providers SHOULD filter out routes to 192.88.99.1. > > It is pretty clear enough to me (as document editor) that there > is no consensus in the v6ops WG for this sentence, which was > added after some earlier discussion in the WG. The final > consensus has to be judged by the WG chairs, but my guess is > that we'll delete that sentence and leave the decision up to > individual operators. Indeed. from my readings indeed most peoples arguments have stated to NOT filter it. Hence removing that sentence would match most people's thoughts/arguments. Greets, Jeroen From nobody Fri Dec 12 03:09: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 A37D71ACCF8 for ; Fri, 12 Dec 2014 03:08:57 -0800 (PST) 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_15=0.6, SPF_HELO_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 jZ7-7nQKmVit for ; Fri, 12 Dec 2014 03:08:54 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0788.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::788]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A987A1ACCE4 for ; Fri, 12 Dec 2014 03:08:53 -0800 (PST) Received: from pc6 (81.151.166.145) by AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) with Microsoft SMTP Server (TLS) id 15.1.31.17; Fri, 12 Dec 2014 11:08:29 +0000 Message-ID: <047201d015fb$f040d660$4001a8c0@gateway.2wire.net> From: t.petch To: Sheng Jiang , "Fred Baker (fred)" , References: <08DA982D-6605-434B-B815-C69B8A97FA4C@cisco.com> <010701d01204$b8e18160$4001a8c0@gateway.2wire.net> <5D36713D8A4E7348A7E10DF7437A4B923AFDB427@nkgeml512-mbx.china.huawei.com> <05aa01d014a0$43c5be20$4001a8c0@gateway.2wire.net> <5D36713D8A4E7348A7E10DF7437A4B923AFEBEB2@nkgeml512-mbx.china.huawei.com> Date: Fri, 12 Dec 2014 11:08:13 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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: [81.151.166.145] X-ClientProxiedBy: DB4PR05CA0013.eurprd05.prod.outlook.com (25.160.40.23) To AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB049; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601003); SRVR:AMSPR07MB049; X-Forefront-PRVS: 04238CD941 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(189002)(377424004)(52044002)(13464003)(199003)(19580395003)(68736005)(15975445007)(64706001)(107046002)(61296003)(81816999)(84392001)(122386002)(62966003)(77156002)(1720100001)(77096005)(1456003)(19580405001)(42186005)(21056001)(44716002)(47776003)(62236002)(20776003)(1556002)(87976001)(31966008)(40100003)(66066001)(107886001)(106356001)(97736003)(105586002)(50226001)(33646002)(4396001)(23676002)(14496001)(46102003)(86362001)(101416001)(120916001)(50986999)(89996001)(92566001)(99396003)(50466002)(93886004)(81686999)(76176999)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB049; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB049; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1Nf9yXJZqgUtDfAirFWJ0UuXNJ0 Subject: Re: [v6ops] Working Group 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: Fri, 12 Dec 2014 11:08:58 -0000 Sheng I am aware of " From: fred at cisco.com To: v6ops at ietf.org Date: Sun, 19 Oct 2014 11:00:02 -0700 This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem. " as well as "From: fred at cisco.com To: v6ops at ietf.org Date: Sun, 26 Oct 2014 11:00:03 -0700 The working group last call for this draft announced last week continues for another week. Please feel free to comment on it. " so my last post, while wishing to see this advance, was also slightly tongue-in-cheek. I think it unfortunate that a new version then appeared the day after Fred's post, a version, which, for me, was a step backwards. (The WG then went off into another of its canard, 6to4, IMO). I think it wrong to try and document all the (common) variations in behaviour. Rather, I want something which could be summarised as 1) M and O is a mess 2) It will always be a mess 3) Tough with the evidence to support this in the form of variant implementations, enough to show that it is a mess without attempting to be a comprehensive survey. I see Fred's message, the one which started this thread as an implicit statement by the WG Chair that the WGLC resulted in a consensus that the WG should not proceed with this I-D - a view which I, and a few others, have stated their disagreement with. Perhaps the IETF process now reflects the state of M and O :-) Tom Petch ----- Original Message ----- From: "Sheng Jiang" To: "t.petch" ; "Fred Baker (fred)" ; Sent: Thursday, December 11, 2014 2:24 AM > Hi, Tom, > > Thanks for your offer. > > Review and comments would be very helpful for us to improve. Following the latest discussion, there are two actions we are planning: A) focus on the implementation divergence rather than a protocol definition problem statement. The most of contents are already in the current document. It just needs a little bit reorganizing and rewording. B) some addition investigation or experiments, e.g. both DHCPv6 and ND have DNS configuration. > > If you are interested to contribute, you are certainly welcome. > > Best regards, > > Sheng > > >-----Original Message----- > >From: t.petch [mailto:ietfc@btconnect.com] > >Sent: Thursday, December 11, 2014 1:39 AM > >To: Sheng Jiang; Fred Baker (fred); v6ops@ietf.org > >Subject: Re: [v6ops] Working Group Administrivia > > > >Sheng > > > >If I read the e-mail addresses aright, you are the editor of > >draft-ietf-v6ops-dhcpv6-slaac-problem > >What do you want (that I might be able to do) bofore this is ready for > >WG Last Call? > > > >Tom Petch > > > > > >----- Original Message ----- > >From: "Sheng Jiang" > >To: "t.petch" ; "Fred Baker (fred)" > >; > >Sent: Monday, December 08, 2014 2:18 AM > >Subject: RE: [v6ops] Working Group Administrivia > > > > > >> >As Brian says in his note, > >> > > >> >2014-10-27 draft-ietf-v6ops-dhcpv6-slaac-problem > >> > >>http://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ > >> > > >> >addresses a known problem and I think it would be remiss of the IETF > >not > >> >to have this documented > >> > >> Fully agreed. My read from the latest meeting response is the problem > >should be document and know by operators and implementors. The > >controversial part is not this draft, but the follow up of this draft: > >> > >> 1) The solution (protocol level) is not belong to v6ops WG. > >> > >> 2) The real debate is Whether v6ops should produce an operational > >guidelines for operators to avoid this issue. Personally, I think it is > >helpful and belong to this WG, but it seems the WG does not reach > >consensus on this. > >> > >> Best regards, > >> > >> Sheng > >> > >> >Tom Petch > >> > > >> > > >> >----- Original Message ----- > >> >From: "Fred Baker (fred)" > >> >To: > >> >Sent: Friday, December 05, 2014 6:17 PM > >> >Subject: [v6ops] Working Group Administrivia > >> > > >> > > >> >Joel, Lee, and I spoke this morning about the status of the working > >> >group and various drafts in it. I’d like to gauge working group > >> >consensus on the status of a number of working group drafts that have > >> >either expired or otherwise should no longer be considered working > >group > >> >drafts. Your opinions, pro or con (such as “I’m fine with all that > >but > >> >think we should still be considering draft-whateverâ€), please: > >> > > >> >We think that the following can be safely set aside, by having the > >> >secretariat record (and show in the data tracker) that they are no > >> >longer working group drafts. They have expired, and are not currently > >> >being pursued: > >> > > >> >2003-01-13 draft-ietf-v6ops-ipv4survey > >> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv4survey/ > >> >2003-02-14 draft-ietf-v6ops-ipv4survey-gen > >> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv4survey-gen/ > >> >2004-07-20 draft-ietf-v6ops-v6onbydefault > >> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6onbydefault/ > >> >2007-02-27 draft-ietf-v6ops-routing-guidelines > >> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-routing-guidelines/ > >> >2007-03-28 draft-ietf-v6ops-campus-transition > >> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-campus-transition/ > >> >2008-05-13 draft-ietf-v6ops-nat64-pb-statement-req > >> > >>http://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-pb-statement-re q > >/ > >> >2011-07-26 draft-ietf-v6ops-v4v6tran-framework > >> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6tran-framework/ > >> >2013-08-14 draft-ietf-v6ops-monitor-ds-ipv6 > >> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-monitor-ds-ipv6/ > >> > > >> >We think that draft-ietf-v6ops-balanced-ipv6-security, in its current > >> >state, is a deployment report, primarily from Swisscom. While the > >> >working group expressed interest in guidance on firewall > >configuration, > >> >this isn’t it. We think it should no longer be a working group draft, > >> >and invite the authors to submit it to the independent stream as a > >> >deployment report ( >> > > >> >2013-12-06 draft-ietf-v6ops-balanced-ipv6-security > >> > >>http://datatracker.ietf.org/doc/draft-ietf-v6ops-balanced-ipv6-securit y > >/ > >> > > >> >Although the working group expressed interest in the following and > >the > >> >authors have been working hard on them, we think the working group is > >no > >> >longer interested in these, and so they should be returned to the > >> >authors and not recorded or treated as working group drafts. > >> > > >> >2014-09-18 draft-ietf-v6ops-design-choices > >> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ > >> >2014-10-27 draft-ietf-v6ops-dhcpv6-slaac-problem > >> > >>http://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ > >> >2014-10-27 draft-ietf-v6ops-ula-usage-recommendations > >> > >>http://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommendat i > >o > >> >ns/ > >> > > >> >Speaking for myself, if I have any question of the above, it is on > >only > >> >one of these. > >> > > >> >If any draft has its "WG Draft" status revoked, it will still be > >> >available from the IETF website as far as I know, but subsequent > >> >revisions should be named as individual submissions to a working > >group, > >> >draft--- or individual submissions to the IETF, > >> >draft--. It would be good if the authors would send > >a > >> >note to internet-drafts@ietf.org indicating that the old draft name > >were > >> >replaced by the new draft name, so that the revision history is > >tracked > >> >appropriately. > >> > > >> >Opinions? > >> > > >> > > >> > > >> > > >> > >>---------------------------------------------------------------------- - > >- > >> >-------- > >> > > >> > > >> >> > >> >> > >> > > >> > > >> > >>---------------------------------------------------------------------- - > >- > >> >-------- > >> > > >> > > >> >> _______________________________________________ > >> >> 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 Fri Dec 12 04:23: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 700F71A1A25 for ; Fri, 12 Dec 2014 04:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 BCvKCZ4TBc7s for ; Fri, 12 Dec 2014 04:23:25 -0800 (PST) Received: from itsnt427.iowa.uiowa.edu (itsnt427.iowa.uiowa.edu [128.255.6.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60D8B1A1A06 for ; Fri, 12 Dec 2014 04:23:25 -0800 (PST) Received: from ITSNT440.iowa.uiowa.edu ([169.254.2.251]) by itsnt427.iowa.uiowa.edu ([128.255.6.109]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 06:23:23 -0600 From: "Metzler, Dan J" To: Jeroen Massar , Brian E Carpenter Thread-Topic: [v6ops] Who is stilll running 6to4 relays (Was: I-D Action: draft-ietf-v6ops-6to4-to-historic-08.txt) Thread-Index: AQHQFdrsIaOfFs7sDUqBx32pg9uYLpyL3cTg Date: Fri, 12 Dec 2014 12:23:23 +0000 Message-ID: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DF5ADFA@ITSNT440.iowa.uiowa.edu> References: <54663F67.5080603@gmail.com> <546927A0.8030201@inex.ie> <546BAC1F.5020401@umn.edu> <20141118.223012.41712464.sthaug@nethelp.no> <546C4D41.2030406@massar.ch> <546CEF7D.2070504@gmail.com> <548A9531.90300@massar.ch> In-Reply-To: <548A9531.90300@massar.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.255.6.15] 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/8ryMRVsslDgKRvmTi7anoj9KmXo Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Who is stilll running 6to4 relays (Was: I-D Action: draft-ietf-v6ops-6to4-to-historic-08.txt) 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, 12 Dec 2014 12:23:27 -0000 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Jeroen Massar > Sent: Friday, December 12, 2014 1:12 AM > To: Brian E Carpenter > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Who is stilll running 6to4 relays (Was: I-D Action: = draft- > ietf-v6ops-6to4-to-historic-08.txt) >=20 > On 2014-11-19 20:29, Brian E Carpenter wrote: > > With the same Bcc: > > > >> Internet service > >> providers SHOULD filter out routes to 192.88.99.1. > > > > It is pretty clear enough to me (as document editor) that there is no > > consensus in the v6ops WG for this sentence, which was added after > > some earlier discussion in the WG. The final consensus has to be > > judged by the WG chairs, but my guess is that we'll delete that > > sentence and leave the decision up to individual operators. >=20 > Indeed. from my readings indeed most peoples arguments have stated to > NOT filter it. Hence removing that sentence would match most people's > thoughts/arguments. Actually, if that statement is true, then that suggests a statement that re= commends "it should NOT be filtered by any ISP" should replace the statemen= t in question. "Leaving it up to the operators", is a different message entirely. (Does n= ot advocate breakage of customer IPv6 connectivity, but does not discourage= breakage of customer IPv6 connectivity.) Thanks, - Dan >=20 > Greets, > Jeroen >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Dec 12 08:06: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 AD21F1ACE6C for ; Fri, 12 Dec 2014 08:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -113.911 X-Spam-Level: X-Spam-Status: No, score=-113.911 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 aDVjtL9G7ZF0 for ; Fri, 12 Dec 2014 08:05:58 -0800 (PST) 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 76BE41ACE71 for ; Fri, 12 Dec 2014 08:05:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1586; q=dns/txt; s=iport; t=1418400354; x=1419609954; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uovtxjqPkyJv9gkuj/22ZGIli8s9w6D4vFSeThJuJQA=; b=EBl2EYR9qYnvpDj2LJOT3Za7fFeAV4vB9Ph+4ZwwV7RKNql1qGJMUb+6 4vV62sb4r6fvWO2RSLneDXPBF/5VrFuqPKzXsSKq8W+aeHPIFOx1tFORI NfMjlrVy6QmW7uc8bMakly7bTFY6TZyO/MqYpSdGfp9x3gVEjwXoCQ7oq U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFALMRi1StJV2S/2dsb2JhbABZgwaBKgTLagKBFRYBAQEBAX2EDQEBAwF5BQsCAQhGMiUCBA4FDogWCNhaAQEBAQEBAQEBAQEBAQEBAQEBAQEBF49yB4MWgRMBBI1/gUqBJ4V+gQuFD4sdIoNsboFFfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,564,1413244800"; d="asc'?scan'208";a="105147788" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-1.cisco.com with ESMTP; 12 Dec 2014 16:05:53 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sBCG5rRL021504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Dec 2014 16:05:53 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 10:05:53 -0600 From: "Fred Baker (fred)" To: "t.petch" Thread-Topic: [v6ops] Working Group Administrivia Thread-Index: AQHQFiWA3bqxrdIjNEuLtgfgs2r+rg== Date: Fri, 12 Dec 2014 16:05:52 +0000 Message-ID: <9F0F40BF-C408-4067-BB4C-4A0E948F1FC7@cisco.com> References: <08DA982D-6605-434B-B815-C69B8A97FA4C@cisco.com> <010701d01204$b8e18160$4001a8c0@gateway.2wire.net> <5D36713D8A4E7348A7E10DF7437A4B923AFDB427@nkgeml512-mbx.china.huawei.com> <05aa01d014a0$43c5be20$4001a8c0@gateway.2wire.net> <5D36713D8A4E7348A7E10DF7437A4B923AFEBEB2@nkgeml512-mbx.china.huawei.com> <047201d015fb$f040d660$4001a8c0@gateway.2wire.net> In-Reply-To: <047201d015fb$f040d660$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.117] Content-Type: multipart/signed; boundary="Apple-Mail=_267803EF-35F8-44A7-88E2-0D98DF437283"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HTLWlpUJynfeyGnpyIc3pgC4c-I Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Working Group 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: Fri, 12 Dec 2014 16:06:00 -0000 --Apple-Mail=_267803EF-35F8-44A7-88E2-0D98DF437283 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 12, 2014, at 3:08 AM, t.petch wrote: > I see Fred's message, the one which started this thread as an implicit > statement by the WG Chair that the WGLC resulted in a consensus that = the > WG should not proceed with this I-D - a view which I, and a few = others, > have stated their disagreement with. Perhaps the IETF process now > reflects the state of M and O :-) No, it was not a statement of consensus. It was a statement that I=92m = wondering whether we have a consensus, and whether I=92m reading it = correctly. My read of the subsequent discussion is that the working = group would like the SLAAC document to be a SLAAC problem statement, and = wants to work on it, that the ULA draft should continue (with the = preferred outcome to be to document use cases known to be deployed), and = the =93design considerations=94 document to continue. --Apple-Mail=_267803EF-35F8-44A7-88E2-0D98DF437283 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 iD8DBQFUixJdbjEdbHIsm0MRAnr7AJ9ppBLampqOM0VBXN3Eh2xCwlLv4wCfaOnR m2rAK+wy39m2KRLSddWlcKE= =NOlC -----END PGP SIGNATURE----- --Apple-Mail=_267803EF-35F8-44A7-88E2-0D98DF437283-- From nobody Fri Dec 12 09: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 379AB1A1BAA for ; Fri, 12 Dec 2014 09:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 76h3rZXdjk1L for ; Fri, 12 Dec 2014 09:17:12 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E4C91A009E for ; Fri, 12 Dec 2014 09:17:12 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sBCHH9K4017210; Fri, 12 Dec 2014 18:17:09 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3B305203CE4; Fri, 12 Dec 2014 18:17:25 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2E697203BF1; Fri, 12 Dec 2014 18:17:25 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sBCHGlTo026192; Fri, 12 Dec 2014 18:17:09 +0100 Message-ID: <548B22FF.5070405@gmail.com> Date: Fri, 12 Dec 2014 18:16:47 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Brian E Carpenter References: <5485FBD7.6050807@gmail.com> <54872700.8030409@gmail.com> <548750B9.90203@gmail.com> In-Reply-To: <548750B9.90203@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HsWMKywqk_pUF0fxHZ_QJaN3mWY Cc: v6ops@ietf.org Subject: Re: [v6ops] On IPv6 address part naming 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, 12 Dec 2014 17:17:15 -0000 The D-Link users manual is confused about how to name this 16-bit: "Note: Stateful DHCPv6 is supported after the IPv6 address 16-bit. For example: Interface ID range from 1 to ffff, IPv6 address range from 2111:123:123:123::1 to 2111:123:123:123::ffff". 'Tetragrammaton' and 'quadriliteral' may have helped better than '16-bit'. Alex Le 09/12/2014 20:42, Brian E Carpenter a Ă©crit : > On 10/12/2014 05:44, Alexandru Petrescu wrote: >> Sorry, following up on my own post, about other SDOs: >> >> It is called a "16-bit piece of the address" by >> the Single Unix Specification 2013 of the Open Group >> https://www2.opengroup.org/ogsys/catalog/t101 > > How sensible. > > Brian > >> >> inet_pton () >> [...] >>> The preferred form is "x:x:x:x:x:x:x:x", where the 'x' s are the >>> hexadecimal values of the eight 16-bit pieces of the address. >>> >> [...] >>> >>> "x:x:x:x:x:x:d.d.d.d", where the 'x' s are the hexadecimal values of >>> the six high-order 16-bit pieces of the address, and the 'd' s are >>> the decimal values of the four low-order 8-bit pieces of the address >>> (standard IPv4 representation). >> >> Alex >> >> >> Le 08/12/2014 20:28, Alexandru Petrescu a Ă©crit : >>> netgear user manual calls it a "quartet": >>> >>> "IPv6 addresses are denoted by eight groups of hexadecimal quartets >>> separated by colons" >>> >>> Alex >>> >>> --- L'absence de virus dans ce courrier Ă©lectronique a Ă©tĂ© vĂ©rifiĂ©e >>> par le logiciel antivirus Avast. http://www.avast.com >>> >>> _______________________________________________ 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 Fri Dec 12 10: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 E36811A0451 for ; Fri, 12 Dec 2014 10:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-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 acy4Ctl_d_Jw for ; Fri, 12 Dec 2014 10:49:13 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id C3EE01A00B7 for ; Fri, 12 Dec 2014 10:49:13 -0800 (PST) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Fri, 12 Dec 2014 12:49:01 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f175.google.com [209.85.223.175] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ie0-f175.google.com with SMTP id x19so7482876ier.20 for ; Fri, 12 Dec 2014 10:49:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fG1VH/ZB4T/xxHY16Q78LyYMJIhBJ6KvA2lOgHCAvGg=; b=kLAJtaMBr70PdJHTU6S0wCZuS9Z93lD74SqwsMlyg6tdewNw1Zv61DCC/fDlQ056wn TPUV8q89elsSVaU3JQaJuwdUnKLsdwfayHXyi7i2b5fwIp4zY7dFxb+3F8GGHoYlTMBv SKwjccZ0RVfHQCjz6TcyqfVHGH+wC3cfFjY0I= 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=fG1VH/ZB4T/xxHY16Q78LyYMJIhBJ6KvA2lOgHCAvGg=; b=GVZ/Qbjs6Y6lZgI0pUaoGhKOtLp1F5aV8OBMszpsQY/WDhNdY0nfQd7hIg48iSbkpC 5sT58aQwgh/fgJvPQzWut/6RWabA4kEJ9hPjiF84aJrrrIPBZZsym1fw+ToT8sFubPHO nZAUeEF5IbFWZ5f/q5AurTpob1MnQyU1kPrxZ5FGIKbRhKgtyJFkUMoO54aoV1jK2kak oqbBFLSJqww5xt9wi5vWvECOgAsFjXnyLzNnSXv6PyCeiXBKit67Rq9fL07L8BZ9O7OJ i1W3EvgXnkUa2DFSx97vgHoUAcmVoZ3UNwLjLwcDjHAnTdM9bs/EnFKU9yXBOfSBWHi7 DTlQ== X-Gm-Message-State: ALoCoQnGcqjX2s1jn0DuwXXijNZDjltbEnJiyBWtED+sxpM4sdHjqWDZJfubGBZnhEgamYKNzD/IW0JwbS9jyAg6GMfpfNMwifgPS3ERyogmcCKE55Q42hl0m7a0yxumOzN2lPEmRt1D X-Received: by 10.107.158.11 with SMTP id h11mr17305513ioe.37.1418410140599; Fri, 12 Dec 2014 10:49:00 -0800 (PST) X-Received: by 10.107.158.11 with SMTP id h11mr17305493ioe.37.1418410140433; Fri, 12 Dec 2014 10:49:00 -0800 (PST) Received: from x-134-84-88-69.nts.umn.edu ([2607:ea00:101:2001:bcca:e006:e194:ea2d]) by mx.google.com with ESMTPSA id g5sm993998iod.25.2014.12.12.10.48.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Dec 2014 10:48:59 -0800 (PST) Message-ID: <548B3899.5080805@umn.edu> Date: Fri, 12 Dec 2014 12:48:57 -0600 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.6.0 MIME-Version: 1.0 To: Brian E Carpenter , v6ops@ietf.org References: <20141210185053.32277.17868.idtracker@ietfa.amsl.com> <5488977E.3010007@gmail.com> In-Reply-To: <5488977E.3010007@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/J0dIfr9o4S6Dl_jeUx3jcIfvb3M Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt 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: Fri, 12 Dec 2014 18:49:16 -0000 I support the changes made in this version, in particular the removal of the general recommendation to filter 192.88.99.0/24. However, people do filter 6to4 and the route for 192.88.99.0/24, and I don't think the issue can and should be ignored. I would prefer some discussion of when it is and is not appropriate to filter the route for 192.88.99.0/24. Filtering of 6to4 or even 192.88.99.0/24 as part of the deprecation of anycast 6to4 relays within Internet in general is most definitely NOT appropriate. However, the deprecation of anycast 6to4 relays combined with local security consideration seems like an appropriate reason to filter the route for 192.88.99.0/24 within an administrative domain. If such filtering is implemented, it is much preferred that native IPv6 is provided within the administrative domain in question and the security policy not impact another administrative domain's access to an anycast 6to4 relay. Personally, I'd prefer a more detailed discussion as outlined in the paragraph above. However, I would find adding a general reference to RFC 7123 or possibly a more specific reference to Section 3.4 of RFC 7123 in the security considerations section of the draft an acceptable alternative. Thanks. On 12/10/14, 12:57 , Brian E Carpenter wrote: > Hi, > > This version has been updated after re-reading the long thread generated > by the WGLC. The major change reflects the fact that there was > obviously no consensus for the recommendation to filter the anycast > route. The other changes reflect other points that came up in the > discussion. > > One extra comment. With the removal of the filtering recommendation, > there is (the editor believes) no substantive change to the guidelines > in RFC 6343, so "Updates: 6343" has been removed. > > Regards > Brian Carpenter > > On 11/12/2014 07:50, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the IPv6 Operations Working Group of the IETF. >> >> Title : Deprecating Anycast Prefix for 6to4 Relay Routers >> Authors : Ole Troan >> Brian Carpenter >> Filename : draft-ietf-v6ops-6to4-to-historic-09.txt >> Pages : 8 >> Date : 2014-12-10 >> >> Abstract: >> Experience with the "Connection of IPv6 Domains via IPv4 Clouds >> (6to4)" IPv6 transition mechanism defined in RFC 3056 has shown that >> when used in its anycast mode, the mechanism is unsuitable for >> widespread deployment and use in the Internet. This document >> therefore requests that RFC 3068, "An Anycast Prefix for 6to4 Relay >> Routers", be made obsolete and moved to historic status. It also >> obsoletes RFC 6732 "6to4 Provider Managed Tunnels". It recommends >> that future products should not support 6to4 anycast and that >> existing deployments should be reviewed. This complements the >> guidelines in RFC 6343. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-09 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6to4-to-historic-09 >> >> >> 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/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- ================================================ 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 Fri Dec 12 11:23: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 2BA721ACD86 for ; Fri, 12 Dec 2014 11:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 NMv0DC9SUZhs for ; Fri, 12 Dec 2014 11:23:35 -0800 (PST) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E77CA1ACC8A for ; Fri, 12 Dec 2014 11:23:34 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id p10so7729863pdj.27 for ; Fri, 12 Dec 2014 11:23:34 -0800 (PST) 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=AxnakWVWkpe56JQYvliDekURSSGViIrVAJUU9kc3aUM=; b=IxNArzjwGWYBeCqOjjlABus0YuJj2iit6R86RM52VP0gDH4m3y98K4lKSS22NcIMah b9NWxBqkTKhSeVspGWb7SEJuVFbLA/j00bmIlf6xrorJdk92XT2B7JX7DHG4UgJiytYe llFMdaNjYsa9/q6mmwRtijlYprnYcnrv4fOCTRAUdQjY12MQWnjBTtBRb+kfa+HGiNnp eKs0QW0vsQzxlLy2FGRuqIIArF2mz+BMb9clfuY9cV2u41FQzlDpofHKqXBrreIuf3XI hyys9NABAEvO5BuDTvRHntJKqmhXIneDPIaVW/lddIc0eYPE3Xw2Bw4oy+ubXgVIYZ6m dcOA== X-Received: by 10.67.14.231 with SMTP id fj7mr29297203pad.80.1418412214137; Fri, 12 Dec 2014 11:23:34 -0800 (PST) Received: from [192.168.178.26] (235.231.69.111.dynamic.snap.net.nz. [111.69.231.235]) by mx.google.com with ESMTPSA id yo1sm2237412pab.27.2014.12.12.11.23.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Dec 2014 11:23:33 -0800 (PST) Message-ID: <548B40BF.3070307@gmail.com> Date: Sat, 13 Dec 2014 08:23:43 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Metzler, Dan J" References: <54663F67.5080603@gmail.com> <546927A0.8030201@inex.ie> <546BAC1F.5020401@umn.edu> <20141118.223012.41712464.sthaug@nethelp.no> <546C4D41.2030406@massar.ch> <546CEF7D.2070504@gmail.com> <548A9531.90300@massar.ch> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DF5ADFA@ITSNT440.iowa.uiowa.edu> In-Reply-To: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DF5ADFA@ITSNT440.iowa.uiowa.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/WeBg9pjZknM7XABvyA5DuJUhQdk Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Who is stilll running 6to4 relays (Was: I-D Action: draft-ietf-v6ops-6to4-to-historic-08.txt) 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, 12 Dec 2014 19:23:36 -0000 On 13/12/2014 01:23, Metzler, Dan J wrote: > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Jeroen Massar >> Sent: Friday, December 12, 2014 1:12 AM >> To: Brian E Carpenter >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] Who is stilll running 6to4 relays (Was: I-D Action: draft- >> ietf-v6ops-6to4-to-historic-08.txt) >> >> On 2014-11-19 20:29, Brian E Carpenter wrote: >>> With the same Bcc: >>> >>>> Internet service >>>> providers SHOULD filter out routes to 192.88.99.1. >>> It is pretty clear enough to me (as document editor) that there is no >>> consensus in the v6ops WG for this sentence, which was added after >>> some earlier discussion in the WG. The final consensus has to be >>> judged by the WG chairs, but my guess is that we'll delete that >>> sentence and leave the decision up to individual operators. >> Indeed. from my readings indeed most peoples arguments have stated to >> NOT filter it. Hence removing that sentence would match most people's >> thoughts/arguments. > > Actually, if that statement is true, then that suggests a statement that recommends "it should NOT be filtered by any ISP" should replace the statement in question. > "Leaving it up to the operators", is a different message entirely. (Does not advocate breakage of customer IPv6 connectivity, but does not discourage breakage of customer IPv6 connectivity.) Not quite. If an operator is aware that a given route to 192.88.99.1 leads to a faulty relay, they might legitimately decide that it's better for their customers to filter the route. I don't think the IETF can really say anything definitive. Brian From nobody Fri Dec 12 22:57: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 28A371AC3E7 for ; Fri, 12 Dec 2014 22:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.51 X-Spam-Level: X-Spam-Status: No, score=-114.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 X1Bx5R_ffu2I for ; Fri, 12 Dec 2014 22:57:03 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3630D1AC3DF for ; Fri, 12 Dec 2014 22:57:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33172; q=dns/txt; s=iport; t=1418453823; x=1419663423; h=from:to:subject:date:message-id:references:mime-version; bh=uz+kJQMi/ZsUUiOWTpopJ07JlZlp8uzI1wQcrp3RffQ=; b=KcvhQJtZhcMIAWH6m2jesQ+AwlebLGLBS7xKrO+AuLuE/a7JBFjfIzmx V4+gVKEEjO9KP96hRcLDBCNy+Mcf1y/Qb22dMHdEQOK1IZKCysqFBLBxC A+zh5Lyt5lyDHcoYuj9bGOwKhr6JUnyg85OGB5HfIxA1B2QI7eY2s8rng Q=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFANrii1StJA2M/2dsb2JhbABZgwZSWATEJYFphXICgRMWAQEBAQF9hAwBAQEDARoNQAUGDAsCARkBAgECIQ4hERcEAggCBBMODYd9AwkIDdFJDYVNAQEBAQYBAQEBAQEcigqDQIE8FEcegxCBEwWFTIZggVaBSoEnTYNugUOBCzCKK4IZgzgig2xuAQGBAQcCFyJ+AQEB X-IronPort-AV: E=Sophos;i="5.07,570,1413244800"; d="asc'?scan'208,217";a="380112495" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP; 13 Dec 2014 06:57:00 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sBD6uxli009188 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 13 Dec 2014 06:57:00 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Sat, 13 Dec 2014 00:56:59 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt Thread-Index: AQHQFY2O5bYhwOsHm0Wx7ru7cmou2w== Date: Sat, 13 Dec 2014 06:56:58 +0000 Message-ID: <4DDC3299-2A1F-4E9C-8B25-4D1C47E08FFE@cisco.com> References: <548B8EBA.7000200@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_4D745DAE-3B7D-44A7-AF09-FF455577B4ED"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/crKGR24hrHY9laBCSxpJjGcIbQY Subject: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt 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, 13 Dec 2014 06:57:09 -0000 --Apple-Mail=_4D745DAE-3B7D-44A7-AF09-FF455577B4ED Content-Type: multipart/alternative; boundary="Apple-Mail=_9FDE39A2-88C6-401D-91FB-893A9385A137" --Apple-Mail=_9FDE39A2-88C6-401D-91FB-893A9385A137 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: Keith Moore > Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-6to4-to-historic-09.txt > Date: December 12, 2014 at 4:56:26 PM PST > To: Brian E Carpenter > Cc: "Fred Baker (fred)" , = "draft-ietf-v6ops-6to4-to-historic.all@tools.ietf.org" = >=20 > Section 1: > There would appear to be little evidence of substantial active use = of > the original form of 6to4 described in [RFC3056].=20 >=20 > This statement is unsupported, and I believe, superfluous. Such a = statement might be supportable via traffic measurements, depending on = how the measurements were done. But traffic measurements are often = misinterpreted, and without a reference describing actual methods and = results there's no way for the reader to assess the validity of the = statement. Whether it's a defensible statement also depends on what = "substantial" means. Anyway, the document would be stronger without = it, as the document shouldn't really be about RFC 3056. >=20 > Recommendation: delete this sentence. >=20 > [RFC6343] analyses the known operational issues in detail and > describes a set of suggestions to improve 6to4 reliability, given = the > widespread presence of hosts and customer premises equipment that > support it. However, experience shows that operational failures = have > continued despite this advice being available. Fortunately the > advice to disable 6to4 by default has been widely adopted in recent > operating systems, and the failure modes have been largely hidden > from users by many browsers adopting the "Happy Eyeballs" approach > [RFC6555]. Nevertheless, a substantial amount of 6to4 traffic is > still observed and the operational problems caused by 6to4 still > occur. >=20 > Although facts are hard to obtain, the remaining successful users = of > anycast 6to4 are likely to be on hosts using the obsolete policy > table [RFC3484] (which prefers 6to4 above IPv4), without Happy > Eyeballs, with a route to an operational anycast relay, and = accessing > sites that have a route to an operational return relay. > Taken together these statements seem confusing at best. Here's my = attempt to sort things out: =20 >=20 > Measures that have been taken in the past (recommending disabling 6to4 = by default, use of happy eyeballs) have had some useful effect. =20 > However some hosts are still observed (again, without any reference to = the observations) to use 6to4 and have operational problems doing so. =20= > Presumably the hosts that are still having operational problems are = those that have, for whatever reason, failed to implement those measures = (perhaps because they are running obsolete code, perhaps because they = are behind routers that implement 6to4). (Perhaps it is believed that = publishing additional RFCs discouraging 6to4 use will help reduce those = problems, as if somehow users will upgrade their systems and/or routers = because we publish more RFCs.) >=20 > Much of the latter paragraph seems completely unsupportable. The = RFC3484 prefix selection table doesn't affect address selection for = applications requiring or deliberately preferring IPv6 (say to = circumvent NAT) and having only a single IPv6 address. (Perhaps the = authors are under the impression that the only hosts anyone wishes to = communicate with using anycast 6to4 are those which also have IPv4 = addresses, or the only apps using IPv6 are those which could work = equally well through IPv4 NAT?) Happy Eyeballs isn't generally = applicable to all applications using IPv6, and even when it's useful = only helps if there are multiple source/destination address pairs from = which to choose. Again, it's not correct to assume that either end of = traffic using 6to4 has an IPv4 address that would work better for that = application. Just to pick one example, I've seen bittorrent use IPv6 = addresses, including 6to4 addresses, when doing so would circumvent NAT = brain-damage. >=20 > Of course successful use of 6to4 does require routes to working relays = in both directions. >=20 > Recommendation: reword the former paragraph and (especially) delete = the latter one. >=20 > IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [RFC5969] > explicitly builds on the 6to4 mechanism, and could be viewed as a > superset of 6to4, using a service provider prefix instead of > 2002::/16. However, the deployment model is based on service = povider > support, such that 6rd can avoid the problems described here. In > this sense, 6rd can be viewed as superseding 6to4 as described in > section 4.2.4 of [RFC2026]. > =20 > While 6rd is indeed useful, and it seems like a good solution for = access providers wishing to provide their customers with an interim IPv6 = solution until they deploy native IPv6, it is misleading to call it a = "superset" of 6to4 or to claim that it supersedes it. 6rd would be = better described as a subset, since it's potentially applicable in fewer = situations than 6to4 is. Or perhaps it would be better to say that 6rd = and 6to4 have different use cases. In particular, 6rd doesn't provide = any help to a user needing to reach IPv6 hosts if the ISP to which he's = currently connected doesn't support it. >=20 > Recommendation: delete the paragraph. 6rd is irrelevant to this = document. >=20 > Given that native IPv6 support and various reliable transition > mechanisms are now becoming common, the IETF sees no evolutionary > future for the 6to4 mechanism. >=20 > Whether native IPv4 support or reliable transition mechanisms are = "becoming common" depends on your definition of "common", but we're = still a long way from a point where such mechanisms are generally = available and applicable to ordinary users. The main reason that = there's no evolutionary future for the 6to4 mechanism is exhaustion of = IPv4 address space and widespread deployment of NAT including = carrier-side NAT. (The problems with use of anycast could be fixed if = there were much to be gained by fixing them, but the = inevitably-increasing use of carrier-side NAT means there's really no = point in doing so.) Also, the paragraph could be taken to mean that = these "reliable transition mechanisms" are good substitutes for 6to4, = when reality is that there is currently no good replacement for 6to4. >=20 > Recommendation: reword to say "Given that due to exhaustion of IPv4 = address space carrier-side NAT is now becoming common, the IETF sees no = evolutionary future for the 6to4 mechanism" >=20 > Section 3: >=20 > With the increased deployment of IPv6, the > mechanism has been shown to have a number of fundamental > shortcomings. >=20 > Some of these shortcomings are not specifically shortcomings with = 6to4, but rather shortcomings of original address selection rules (which = incorrectly assumed that any v6 path would work at least as well as any = v4 path), the Internet architecture itself (poor support for multihomed = hosts which manifests in several ways and persists to this day)=20 >=20 > o Use of relays. 6to4 depends on an unknown third party to operate > the relays between the 6to4 cloud and the native IPv6 Internet. >=20 > I think this is redundant with the 3rd bullet, and the 3rd bullet = states it better. > o The placement of the relay can lead to increased latency, and in > the case the relay is overloaded, packet loss. >=20 > While this statement is true on its face, it's sort of meaningless or = misleading. It begs the question "increased latency as compared to = what?" 6to4 actually did a fairly good job of finding nearby relays in = both directions if they were available - often providing lower latency = better than configured tunnels except those provided by one's own ISP. =20= >=20 > The real problem was with the original address prefix selection = algorithm and its implicit assumption that any IPv6 path would be better = than any IPv4 path. If ISPs around the world had deployed native IPv6 = 15 years ago but initially with suboptimal routing, the same problem of = decreased latency would have appeared due to hosts' blind preference of = v6 over v4. =20 >=20 > For that matter, the intended purpose of 6to4 (or for that matter = IPv6) never was to facilitate communications between hosts or = application peers that could just as well use IPv4. > o There is generally no customer relationship between the end-user > and the relay operator, or even a way for the end-user to know = who > the relay operator is, so no support is possible. >=20 > Agreed. > o A 6to4 relay for the reverse path and an anycast 6to4 relay used > for the forward path, are openly accessible, limited only by the > scope of routing. 6to4 relays can be used to anonymize traffic = and > inject attacks into IPv6 that are very difficult to trace. >=20 > Two things: The first statement is true but as far as I can tell only = half of it is relevant - the "reverse" (6->4) path relay doesn't permit = anonymizing traffic as far as I can tell. The "forward" (4->6) path = relay permits anonymizing traffic if the relay doesn't check that the = IPv4 source address on the inbound packet is consistent with the IPv6 = source address on the inbound packet. Otherwise, the degree of = anonymizing possible is about the same as with NAT44 - the rest of the = network can't tell which host the traffic came from but it can tell = which network it came from. >=20 > o 6to4 may silently discard traffic in the case where protocol = (41) > is blocked in intermediate firewalls. Even if a firewall sent = an > ICMP message unreachable back, an IPv4 ICMP message rarely > contains enough of the original IPv6 packet so that it can be > relayed back to the IPv6 sender. That makes this problem hard = to > detect and react upon by the sender of the packet. >=20 > Well, of course it's not 6to4 discarding the traffic, it's the = firewalls. Place the blame where it belongs. And these problems = exist with protocol 41 tunnels in general, including 6rd tunnels, not = just 6to4 tunnels. (It seems especially odd for this document > to be recommending 6rd as a replacement of sorts for 6to4 while at the = same time > citing 6to4 for shortcomings that are also present with 6rd.) >=20 > There are really two issues here: > - "accidental" blocking of 6to4 by firewalls (i.e. because of naivete = or misconfiguration rather than because of explicit policy) > - hosts/apps not coping well with blocking of 6to4 by firewalls >=20 > Recommendation: separate into two bullets: >=20 > - 6to4 traffic was sometimes silently discarded by firewalls, either = because they blocked > protocol 41 indiscriminately, or because they blocked incoming traffic = flows that weren't initiated by outgoing traffic flows, and were not = configured to recognize outgoing flows over protocol 41. Sometimes = this blocking was deliberate, sometimes accidental due to underspecified = configuration. >=20 > - Whether or not by accident, when encapsulated traffic was blocked by = a IPv4-only firewall, an ICMPv4 response from the firewall was unlikely = to be useful to the sender's IPv6 stack, and an IPv4-only firewall = generally wouldn't know how to send ICMPv6 responses encapsulated in = IPv4, to the sending host. =20 >=20 >=20 >=20 > o As 6to4 tunnels across the Internet, the IPv4 addresses used = must > be globally reachable. RFC 3056 states that a private address > [RFC1918] MUST NOT be used. 6to4 will not work in networks that > employ other addresses with limited topological span. In > particular it will predictably fail in the case of double = network > address translation (NAT444). >=20 > This bullet seems very muddy.=20 >=20 > "As 6to4 tunnels across the Internet" should say "the IPv4 Internet". = The Internet isn't just IPv4. >=20 > The second sentence seems out of place. It's not immediately clear = what RFC 3056's statement about RFC 1918 addresses has to do with the = argument that's being made. >=20 > - The general issue is that 6to4 doesn't work to provide IPv6 access = to hosts or routers lacking a globally-scoped and globally-reachable = IPv4 address. This in combination with widespread use of NAT made 6to4 = much less useful than it would otherwise have been, and is perhaps the = biggest single problem with 6to4. >=20 > - A related problem was that it wasn't clear from the 6to4 = specifications that hosts and routers supporting 6to4 needed a reliable = way to detect that they had globally-scoped and globally-reachable IPv4 = addresses. RFC 1918 addresses were excluded by RFC 3056, but other = unsuitable IPv4 addresses were not as easily recognized. =20 >=20 > - Some 6to4 implementations were once known to enable 6to4 by default = for any non-RFC1918 address, having the effect of enabling a IPv6 = address and interface that would never work, and (in the absence of = modern address selection rules or happy eyeballs) causing traffic to be = blackholed. However this problem has largely been fixed. >=20 > As far as I can tell, the problem with double NAT is just one example = of the general problem. Even a single layer of NAT breaks 6to4. >=20 > Recommendation: reword the above bullet into two separate bullets, = along the lines above. >=20 >=20 --Apple-Mail=_9FDE39A2-88C6-401D-91FB-893A9385A137 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Begin forwarded = message:

From: = Keith Moore <moore@network-heretics.com&= gt;
Subject: = Re: [v6ops] I-D = Action: = draft-ietf-v6ops-6to4-to-historic-09.txt
Date: December 12, 2014 at 4:56:26 PM = PST
To: = Brian E Carpenter = <brian.e.carpenter@gmail.com>
=20
Section 1:
   There would appear to be little evidence of substantial =
active use of
   the original form of 6to4 described in [RFC3056].

This statement is unsupported, and I believe, = superfluous.    Such a statement might be supportable via traffic measurements, depending on how the measurements were done.   But traffic = measurements are often misinterpreted, and without a reference describing actual methods and results there's no way for the reader to assess the validity of the statement.   Whether it's a defensible = statement also depends on what "substantial" means.    Anyway, = the document would be stronger without it, as the document shouldn't really be about RFC 3056.

Recommendation: delete this sentence.

   [RFC6343] analyses the known operational issues in =
detail and
   describes a set of suggestions to improve 6to4 reliability, given the
   widespread presence of hosts and customer premises equipment that
   support it.  However, experience shows that operational failures have
   continued despite this advice being available.  Fortunately the
   advice to disable 6to4 by default has been widely adopted in recent
   operating systems, and the failure modes have been largely hidden
   from users by many browsers adopting the "Happy Eyeballs" approach
   [RFC6555].  =
Nevertheless, a substantial amount of 6to4 traffic is
   still observed and the operational problems caused by 6to4 still
   occur.

   Although facts are hard to obtain, the remaining successful users of
   anycast 6to4 are likely to be on hosts using the obsolete policy
   table [RFC3484] (which prefers 6to4 above IPv4), without =
Happy
   Eyeballs, with a route to an operational anycast relay, and accessing
   sites that have a route to an operational return relay.
Taken together these statements seem confusing at best.   = Here's my attempt to sort things out:  

  • Measures that have been taken in the past (recommending disabling 6to4 by default, use of happy eyeballs) have had some useful effect. 
  • However some hosts are still observed (again, without any reference to the observations) to use 6to4 and have operational problems doing so.  
  • Presumably the hosts that are still having operational problems are those that have, for whatever reason, failed to implement those measures (perhaps because they are running obsolete code, perhaps because they are behind routers that implement 6to4).   (Perhaps it is believed that = publishing additional RFCs discouraging 6to4 use will help reduce those problems, as if somehow users will upgrade their systems and/or routers because we publish more RFCs.)

Much of the latter paragraph seems completely = unsupportable.   The RFC3484 prefix selection table doesn't affect address selection for applications requiring or deliberately preferring IPv6 (say to circumvent NAT) and having only a single IPv6 address.  = (Perhaps the authors are under the impression that the only hosts anyone wishes to communicate with using anycast 6to4 are those which also have IPv4 addresses, or the only apps using IPv6 are those which could work equally well through IPv4 NAT?)   Happy Eyeballs = isn't generally applicable to all applications using IPv6, and even when it's useful only helps if there are multiple source/destination address pairs from which to choose.   Again, it's not = correct to assume that either end of traffic using 6to4 has an IPv4 address that would work better for that application.  Just to pick one example, I've seen bittorrent use IPv6 addresses, including 6to4 addresses, when doing so would circumvent NAT brain-damage.

Of course successful use of 6to4 does require routes to working relays in both directions.

Recommendation: reword the former paragraph and (especially) delete the latter one.

   IPv6 Rapid Deployment on IPv4 =
Infrastructures (6rd) [RFC5969]
   explicitly builds on the 6to4 mechanism, and could be viewed as a
   superset of 6to4, using a service provider prefix instead of
   2002::/16.  However, the deployment model is based on service povider
   support, such that 6rd can avoid the problems described here.  In
   this sense, 6rd can be viewed as superseding 6to4 as described in
   section 4.2=
.4 of [RFC2026].
 
While 6rd is indeed useful, and it seems like a good solution for access providers wishing to provide their customers with an interim IPv6 solution until they deploy native IPv6, it is  misleading = to call it a "superset" of 6to4 or to claim that it supersedes = it.  6rd would be better described as a subset, since it's potentially applicable in fewer situations than 6to4 is.   Or perhaps = it would be better to say that 6rd and 6to4 have different use = cases.   In particular, 6rd doesn't provide any help to a user needing to reach IPv6 hosts if the ISP to which he's currently connected doesn't support it.

Recommendation: delete the paragraph.  6rd is irrelevant to = this document.

   Given that native IPv6 support and various =
reliable transition
   mechanisms are now becoming common, the IETF sees no evolutionary
   future for the 6to4 mechanism.
Whether native IPv4 support or reliable transition mechanisms are "becoming common" depends on your definition of "common", but we're still a long way from a point where such mechanisms are generally available and applicable to ordinary users.   The main = reason that there's no evolutionary future for the 6to4 mechanism is exhaustion of IPv4 address space and widespread deployment of NAT including carrier-side NAT.    (The problems with use of = anycast could be fixed if there were much to be gained by fixing them, but the inevitably-increasing use of carrier-side NAT means there's really no point in doing so.)   Also, the paragraph could be = taken to mean that these "reliable transition mechanisms" are good substitutes for 6to4, when reality is that there is currently no good replacement for 6to4.

Recommendation: reword to say "Given that due to exhaustion of IPv4 address space carrier-side NAT is now becoming common, the IETF sees no evolutionary future for the 6to4 mechanism"

Section 3:

                          With the increased =
deployment of IPv6, the
   mechanism has been shown to have a number of fundamental
   shortcomings.

Some of these shortcomings are not specifically shortcomings with 6to4, but rather shortcomings of original address selection rules (which incorrectly assumed that any v6 path would work at least as well as any v4 path), the Internet architecture itself (poor support for multihomed hosts which manifests in several ways and persists to this day) 

   o  Use of relays. 6to4 depends on an =
unknown third party to operate
      the relays between the 6to4 cloud and the native IPv6 Internet.
I think this is redundant with the 3rd bullet, and the 3rd bullet states it better.
   o  The placement of the relay can =
lead to increased latency, and in
      the case the relay is overloaded, packet loss.
While this statement is true on its face, it's sort of meaningless or misleading.    It begs the question "increased = latency as compared to what?"   6to4 actually did a fairly good job = of finding nearby relays in both directions if they were available - often providing lower latency better than configured tunnels except those provided by one's own ISP.  

The real problem was with the original address prefix selection algorithm and its implicit assumption that any IPv6 path would be better than any IPv4 path.    If ISPs around the = world had deployed native IPv6 15 years ago but initially with suboptimal routing, the same problem of decreased latency would have appeared due to hosts' blind preference of v6 over v4.  

For that matter, the intended purpose of 6to4 (or for that matter IPv6) never was to facilitate communications between hosts or application peers that could just as well use IPv4.
   o  There is generally no customer =
relationship between the end-user
      and the relay operator, or even a way for the end-user to know who
      the relay operator is, so no support is possible.
Agreed.
   o  A 6to4 relay for the reverse path and =
an anycast 6to4 relay used
      for the forward path, are openly accessible, limited only by the
      scope of routing. 6to4 relays can be used to anonymize traffic and
      inject attacks into IPv6 that are very difficult to trace.
Two things: The first statement is true but as far as I can tell only half of it is relevant - the "reverse" (6->4) path relay doesn't permit anonymizing traffic as far as I can tell.  The "forward" (4->6) path relay permits anonymizing traffic if the relay doesn't check that the IPv4 source address on the inbound packet is consistent with the IPv6 source address on the inbound packet.   Otherwise, the degree of anonymizing possible is = about the same as with NAT44 - the rest of the network can't tell which host the traffic came from but it can tell which network it came = from.

   o  6to4 may silently discard traffic in =
the case where protocol (41)
      is blocked in intermediate firewalls.  Even if a firewall sent an
      ICMP message unreachable back, an IPv4 ICMP message rarely
      contains enough of the original IPv6 packet so that it can be
      relayed back to the IPv6 sender.  That makes this problem hard to
      detect and react upon by the sender of the packet.
Well, of course it's not 6to4 discarding the traffic, it's the firewalls.   Place the blame where it belongs.   = And these problems exist with protocol 41 tunnels in general, including 6rd tunnels, not just 6to4 tunnels.   (It seems especially odd for this = document
to be recommending 6rd as a replacement of sorts for 6to4 while at the same time
citing 6to4 for shortcomings that are also present with 6rd.)

There are really two issues here:
- "accidental" blocking of 6to4 by firewalls (i.e. because of naivete or misconfiguration rather than because of explicit = policy)
- hosts/apps not coping well with blocking of 6to4 by firewalls

Recommendation: separate into two bullets:

- 6to4 traffic was sometimes silently discarded by firewalls, either because they blocked
protocol 41 indiscriminately, or because they blocked incoming traffic flows that weren't initiated by outgoing traffic flows, and were not configured to recognize outgoing flows over protocol = 41.   Sometimes this blocking was deliberate, sometimes accidental due to underspecified configuration.

- Whether or not by accident, when encapsulated traffic was blocked by a IPv4-only firewall, an ICMPv4 response from the firewall was unlikely to be useful to the sender's IPv6 stack, and an IPv4-only firewall generally wouldn't know how to send ICMPv6 responses encapsulated in IPv4, to the sending host.   



   o  As 6to4 tunnels across the Internet, =
the IPv4 addresses used must
      be globally reachable.  RFC 3056 states that a =
private address
      [RFC1918] MUST NOT be used. 6to4 will not work in =
networks that
      employ other addresses with limited topological span.  In
      particular it will predictably fail in the case of double network
      address translation (NAT444).

This bullet seems very muddy.

"As 6to4 tunnels across the Internet"  should say "the IPv4 Internet".   The Internet isn't just IPv4.

The second sentence seems out of place.   It's not = immediately clear what RFC 3056's statement about RFC 1918 addresses has to do with the argument that's being made.

- The general issue is that 6to4 doesn't work to provide IPv6 access to hosts or routers lacking a globally-scoped and globally-reachable IPv4 address.   This in combination with widespread use of = NAT made 6to4 much less useful than it would otherwise have been, and is perhaps the biggest single problem with 6to4.

- A related problem was that it wasn't clear from the 6to4 specifications that hosts and routers supporting 6to4 needed a reliable way to detect that they had globally-scoped and globally-reachable IPv4 addresses.  RFC 1918 addresses were = excluded by RFC 3056, but other unsuitable IPv4 addresses were not as easily recognized.  

- Some 6to4 implementations were once known to enable 6to4 by default for any non-RFC1918 address, having the effect of enabling a IPv6 address and interface that would never work, and (in the absence of modern address selection rules or happy eyeballs) causing traffic to be blackholed.   However this problem has = largely been fixed.

As far as I can tell, the problem with double NAT is just one example of the general problem.   Even a single layer of = NAT breaks 6to4.

Recommendation: reword the above bullet into two separate bullets, along the lines above.



= --Apple-Mail=_9FDE39A2-88C6-401D-91FB-893A9385A137-- --Apple-Mail=_4D745DAE-3B7D-44A7-AF09-FF455577B4ED 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 iD8DBQFUi+M4bjEdbHIsm0MRAnxfAKC+N4rEoaj1y/SLb1QWe/2QLHi/cACeNu5S tP2i3xmHi4MYlDO+H2+VBLo= =GAtT -----END PGP SIGNATURE----- --Apple-Mail=_4D745DAE-3B7D-44A7-AF09-FF455577B4ED-- From nobody Sat Dec 13 08:10: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 23D691A0282 for ; Sat, 13 Dec 2014 08:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 F4FFKNhBFWzg for ; Sat, 13 Dec 2014 08:10:38 -0800 (PST) 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 E6E4D1A0250 for ; Sat, 13 Dec 2014 08:10:37 -0800 (PST) Received: from [2a02:fe0:c410:c430::1] (port=56957 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1XzpH9-00089Y-AG; Sat, 13 Dec 2014 17:10:35 +0100 Date: Sat, 13 Dec 2014 17:10:34 +0100 From: Tore Anderson To: v6ops@ietf.org Message-ID: <20141213171034.158b5ecf@envy.fud.no> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KV93WhEwF4gg5qB8SneiriZWQfY Subject: [v6ops] New Version Notification for draft-anderson-v6ops-siit-eam-02.txt 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, 13 Dec 2014 16:10:40 -0000 Hello, I've uploaded a new version of draft-anderson-v6ops-siit-eam. The significant changes are: - Describe the address translation algorithm as detailed step-by-step procedure, one section for IPv4->IPv6 and another for IPv6->IPv4. I hope this addresses Cameron's misgivings about the language in -01. - Allow EAM entries to have longer IPv6 suffixes than IPv4. This is required to support IVI address mappings. When translating from IPv4 to IPv6, the missing suffix bits are zero padded; when translating from IPv6 to IPv4, the superfluous suffix bits are discarded. - Include a section in the appendix that describes the IVI use case. - Include a section in the appendix that shows the outcome of the algorithm for various example addresses using a number of example EAMs. Tore Forwarded message: A new version of I-D, draft-anderson-v6ops-siit-eam-02.txt has been successfully submitted by Tore Anderson and posted to the IETF repository. Name: draft-anderson-v6ops-siit-eam Revision: 02 Title: Explicit Address Mappings for Stateless IP/ICMP Translation Document date: 2014-12-13 Group: Individual Submission Pages: 12 URL: http://www.ietf.org/internet-drafts/draft-anderson-v6ops-siit-eam-02.txt Status: https://datatracker.ietf.org/doc/draft-anderson-v6ops-siit-eam/ Htmlized: http://tools.ietf.org/html/draft-anderson-v6ops-siit-eam-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-anderson-v6ops-siit-eam-02 Abstract: This document extends the Stateless IP/ICMP Translation Algorithm (SIIT) with an Explicit Address Mapping (EAM) algorithm, and formally updates RFC 6145. The EAM algorithm facilitates stateless IP/ICMP translation between arbitrary (non-IPv4-translatable) IPv6 endpoints and IPv4. From nobody Sat Dec 13 11:18: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 C65E21A1B39 for ; Sat, 13 Dec 2014 11:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, 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 4MDuRQMKMMwf for ; Sat, 13 Dec 2014 11:18:02 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D84ED1A1A03 for ; Sat, 13 Dec 2014 11:18:01 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id hv19so7642903lab.0 for ; Sat, 13 Dec 2014 11:18:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=9TR9sXsTo4Rm980flADZft7yfvsXyOla4RafZ7cRd6c=; b=buJmZuGN9CQcHK0HRei0zb/JFKG8UnYgN9DTmISFGWnsyUIDh3YHJ8H71WR5SeMJWI 9YvpPlDHx2QEd7sr6PC+hmoTWvVWYYSmFd4z2GwQ0eYMO1JdbMesuT74Zl4SlZiBNOlQ L6XLIqVjoEocTGOEzn26lm96odPrndgMHVc52KtR4vVWuKqbDRQB6NNW6GGEWe8HFMNz acF5jNZiAjExnrTt076ZlVMOGonDxmMpuQHXPsfPJzcL3oAQoG/fhg4lfIur4KJM91um 6LWH9D1S2oGYhVfwC+SEbDGL4d96jlPQUifAlqO28xO6wAlECuad+vEbC+6MRZBPwuD2 8bKg== MIME-Version: 1.0 X-Received: by 10.152.28.227 with SMTP id e3mr22164624lah.54.1418498280187; Sat, 13 Dec 2014 11:18:00 -0800 (PST) Received: by 10.114.4.132 with HTTP; Sat, 13 Dec 2014 11:18:00 -0800 (PST) In-Reply-To: References: Date: Sun, 14 Dec 2014 00:18:00 +0500 Message-ID: From: Tariq Saraj To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=089e0160b7ce1aeb4e050a1dde83 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7TSjZAJtbtlckngaAToxhAw8RgE Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 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, 13 Dec 2014 19:18:06 -0000 --089e0160b7ce1aeb4e050a1dde83 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There are some issues with 6rd as well, IPv6 with all its powerful features is still under critical objections in academia just because of the urgency shown by IETF in standardizing protocols like 6to4 and 6rd. 6to4 clearly mentioned that it cannot support multicast at layer-3, on the other end 6rd claimed that multicast can be provided, my question is that while standardizing 6rd which at that time was just supporting unicast traffic traversing across IPv4 network and its still not matured enough to provide multicast support yet in its functionality other than using some proxy support for multicast traffic. why It was standardized ? a common university level student is considering IPv6 nothing more than just a large address space. The support for multicast traffic is increasing every day at application level. My request at this forum is to consider 6rd along with the 6to4 so that in future both of these protocols not to become a part of any network device. I personally feels that instead of supporting to promote the IPv6 both of these protocols are becoming obstacles in this regards. I prefer using GRE over these automatic tunneling mechanisms at least GRE supports multicast on network layer and let the application program to design his/her application in more different ways. On Fri, Dec 12, 2014 at 1: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: Working Group Administrivia (Sheng Jiang) > 2. Re: I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt > (Keith Moore) > 3. Re: PMTUD forever, was: MTUs on the general Internet > (Templin, Fred L) > 4. Re: I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt > (Brian E Carpenter) > > > ---------- Forwarded message ---------- > From: Sheng Jiang > To: "t.petch" , "Fred Baker (fred)" = , > "v6ops@ietf.org" > Cc: > Date: Thu, 11 Dec 2014 02:24:24 +0000 > Subject: Re: [v6ops] Working Group Administrivia > Hi, Tom, > > Thanks for your offer. > > Review and comments would be very helpful for us to improve. Following th= e > latest discussion, there are two actions we are planning: A) focus on the > implementation divergence rather than a protocol definition problem > statement. The most of contents are already in the current document. It > just needs a little bit reorganizing and rewording. B) some addition > investigation or experiments, e.g. both DHCPv6 and ND have DNS > configuration. > > If you are interested to contribute, you are certainly welcome. > > Best regards, > > Sheng > > >-----Original Message----- > >From: t.petch [mailto:ietfc@btconnect.com] > >Sent: Thursday, December 11, 2014 1:39 AM > >To: Sheng Jiang; Fred Baker (fred); v6ops@ietf.org > >Subject: Re: [v6ops] Working Group Administrivia > > > >Sheng > > > >If I read the e-mail addresses aright, you are the editor of > >draft-ietf-v6ops-dhcpv6-slaac-problem > >What do you want (that I might be able to do) bofore this is ready for > >WG Last Call? > > > >Tom Petch > > > > > >----- Original Message ----- > >From: "Sheng Jiang" > >To: "t.petch" ; "Fred Baker (fred)" > >; > >Sent: Monday, December 08, 2014 2:18 AM > >Subject: RE: [v6ops] Working Group Administrivia > > > > > >> >As Brian says in his note, > >> > > >> >2014-10-27 draft-ietf-v6ops-dhcpv6-slaac-problem > >> > >>http://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ > >> > > >> >addresses a known problem and I think it would be remiss of the IETF > >not > >> >to have this documented > >> > >> Fully agreed. My read from the latest meeting response is the problem > >should be document and know by operators and implementors. The > >controversial part is not this draft, but the follow up of this draft: > >> > >> 1) The solution (protocol level) is not belong to v6ops WG. > >> > >> 2) The real debate is Whether v6ops should produce an operational > >guidelines for operators to avoid this issue. Personally, I think it is > >helpful and belong to this WG, but it seems the WG does not reach > >consensus on this. > >> > >> Best regards, > >> > >> Sheng > >> > >> >Tom Petch > >> > > >> > > >> >----- Original Message ----- > >> >From: "Fred Baker (fred)" > >> >To: > >> >Sent: Friday, December 05, 2014 6:17 PM > >> >Subject: [v6ops] Working Group Administrivia > >> > > >> > > >> >Joel, Lee, and I spoke this morning about the status of the working > >> >group and various drafts in it. I=E2=80=99d like to gauge working gro= up > >> >consensus on the status of a number of working group drafts that have > >> >either expired or otherwise should no longer be considered working > >group > >> >drafts. Your opinions, pro or con (such as =E2=80=9CI=E2=80=99m fine = with all that > >but > >> >think we should still be considering draft-whatever=E2=80=9D), please= : > >> > > >> >We think that the following can be safely set aside, by having the > >> >secretariat record (and show in the data tracker) that they are no > >> >longer working group drafts. They have expired, and are not currently > >> >being pursued: > >> > > >> >2003-01-13 draft-ietf-v6ops-ipv4survey > >> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv4survey/ > >> >2003-02-14 draft-ietf-v6ops-ipv4survey-gen > >> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv4survey-gen/ > >> >2004-07-20 draft-ietf-v6ops-v6onbydefault > >> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6onbydefault/ > >> >2007-02-27 draft-ietf-v6ops-routing-guidelines > >> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-routing-guidelines/ > >> >2007-03-28 draft-ietf-v6ops-campus-transition > >> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-campus-transition/ > >> >2008-05-13 draft-ietf-v6ops-nat64-pb-statement-req > >> > >>http://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-pb-statement-req > >/ > >> >2011-07-26 draft-ietf-v6ops-v4v6tran-framework > >> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6tran-framework/ > >> >2013-08-14 draft-ietf-v6ops-monitor-ds-ipv6 > >> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-monitor-ds-ipv6/ > >> > > >> >We think that draft-ietf-v6ops-balanced-ipv6-security, in its current > >> >state, is a deployment report, primarily from Swisscom. While the > >> >working group expressed interest in guidance on firewall > >configuration, > >> >this isn=E2=80=99t it. We think it should no longer be a working grou= p draft, > >> >and invite the authors to submit it to the independent stream as a > >> >deployment report ( >> > > >> >2013-12-06 draft-ietf-v6ops-balanced-ipv6-security > >> > >>http://datatracker.ietf.org/doc/draft-ietf-v6ops-balanced-ipv6-security > >/ > >> > > >> >Although the working group expressed interest in the following and > >the > >> >authors have been working hard on them, we think the working group is > >no > >> >longer interested in these, and so they should be returned to the > >> >authors and not recorded or treated as working group drafts. > >> > > >> >2014-09-18 draft-ietf-v6ops-design-choices > >> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ > >> >2014-10-27 draft-ietf-v6ops-dhcpv6-slaac-problem > >> > >>http://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ > >> >2014-10-27 draft-ietf-v6ops-ula-usage-recommendations > >> > >>http://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommendati > >o > >> >ns/ > >> > > >> >Speaking for myself, if I have any question of the above, it is on > >only > >> >one of these. > >> > > >> >If any draft has its "WG Draft" status revoked, it will still be > >> >available from the IETF website as far as I know, but subsequent > >> >revisions should be named as individual submissions to a working > >group, > >> >draft--- or individual submissions to the IETF, > >> >draft--. It would be good if the authors would send > >a > >> >note to internet-drafts@ietf.org indicating that the old draft name > >were > >> >replaced by the new draft name, so that the revision history is > >tracked > >> >appropriately. > >> > > >> >Opinions? > >> > > >> > > >> > > >> > > >> > >>----------------------------------------------------------------------- > >- > >> >-------- > >> > > >> > > >> >> > >> >> > >> > > >> > > >> > >>----------------------------------------------------------------------- > >- > >> >-------- > >> > > >> > > >> >> _______________________________________________ > >> >> 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 > >> > > > > ---------- Forwarded message ---------- > From: Keith Moore > To: v6ops@ietf.org > Cc: > Date: Thu, 11 Dec 2014 10:42:54 -0500 > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt > Mumble. I support the deprecation of 192.88.99.1 as a means to find 6to4 > relays. But this document still contains so many inaccurate and > misleading statements beyond that, including perhaps some statements that > were not present in earlier versions (though I haven't taken the time to > check yet), that I don't believe it should be published in its current > form. Again, this is a document quality issue, not an issue with the basi= c > underlying recommendation. > > Most of the problems with this document are things that I have already > mentioned in connection with earlier versions of this document. > > Keith > > > > > ---------- Forwarded message ---------- > From: "Templin, Fred L" > To: Jeroen Massar , "sthaug@nethelp.no" < > sthaug@nethelp.no> > Cc: "v6ops@ietf.org" > Date: Thu, 11 Dec 2014 16:10:44 +0000 > Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet > > More on what I said the other day, there are two magic numbers that > tunnels > > need to concern themselves with: 1280 and 1500. Accommodating all packe= ts > > within that size range while placing no explicit upper bound for > accommodating > > larger packets is what is being proposed. In other words, no MTU > clamping. > > Have we reached conclusion on this, and can it now be considered "case > closed"? > > Remember - "take care of the smalls, and let the bigs take care of > themselves": > > https://datatracker.ietf.org/doc/draft-templin-aerolink/ > https://datatracker.ietf.org/doc/draft-templin-aeromin/ > > Thanks - Fred > fred.l.templin@boeing.com > > > > > ---------- Forwarded message ---------- > From: Brian E Carpenter > To: Keith Moore > Cc: v6ops@ietf.org > Date: Fri, 12 Dec 2014 08:23:12 +1300 > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt > Keith, please, you need to be specific about what you think is > inaccurate or misleading, line by line, in this version. There's > nothing we can do with a general criticism like that. > > We have made numerous changes, some of them in response to your > comments, but of course in some cases your comments were at > variance with other peoples' comments. Of course, there were a > lot of messages, many of them completely orthogonal to the text > of the draft, so we may well have missed some of the relevant ones. > > Regards > Brian > > On 12/12/2014 04:42, Keith Moore wrote: > > Mumble. I support the deprecation of 192.88.99.1 as a means to find > > 6to4 relays. But this document still contains so many inaccurate and > > misleading statements beyond that, including perhaps some statements > > that were not present in earlier versions (though I haven't taken the > > time to check yet), that I don't believe it should be published in its > > current form. Again, this is a document quality issue, not an issue wit= h > > the basic underlying recommendation. > > > > Most of the problems with this document are things that I have already > > mentioned in connection with earlier versions of this document. > > > > Keith > > > > _______________________________________________ > > 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 Regards Tariq Saraj Center for Research in Networks and Telecom (*CoReNeT*) --089e0160b7ce1aeb4e050a1dde83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There are some issues with 6rd as well, IPv6 with all its = powerful features is still under critical objections in academia just becau= se of the urgency shown by IETF in standardizing protocols like 6to4 and 6r= d. 6to4 clearly mentioned that it cannot support multicast at layer-3, on t= he other end 6rd claimed that multicast can be provided, my question is tha= t while standardizing 6rd which at that time was just supporting unicast tr= affic traversing across IPv4 network and its still not matured enough to pr= ovide multicast support yet in its functionality other than using some prox= y support for multicast traffic. why It was standardized ? a common univers= ity level student is considering IPv6 nothing more than just a large addres= s space. The support for multicast traffic is increasing every day at appli= cation level. My request at this forum is to consider 6rd along with the 6t= o4 so that in future both of these protocols not to become a part of any ne= twork device. I personally feels that instead of supporting to promote the = IPv6 both of these protocols are becoming obstacles in this regards. I pref= er using GRE over these automatic tunneling mechanisms at least GRE support= s multicast on network layer and let the application program to design his/= her application in more different ways. =C2=A0 =C2=A0

On Fri, Dec 12, 2014 at 1:0= 0 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: Working Group Administrivia (Sheng Jiang)
=C2=A0 =C2=A02. Re: I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt =C2=A0 =C2=A0 =C2=A0 (Keith Moore)
=C2=A0 =C2=A03. Re: PMTUD forever, was: MTUs on the general Internet
=C2=A0 =C2=A0 =C2=A0 (Templin, Fred L)
=C2=A0 =C2=A04. Re: I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt =C2=A0 =C2=A0 =C2=A0 (Brian E Carpenter)


---------- Forwarded message ----------
From:=C2=A0Sheng Jiang &= lt;jiangsheng@huawei.com>To:=C2=A0"t.petch" <i= etfc@btconnect.com>, "Fred Baker (fred)" <fred@cisco.com>, "v6ops@ietf.org" <v6= ops@ietf.org>
Cc:=C2=A0
Date:=C2=A0Thu, 11 Dec 2014 02:24:24 += 0000
Subject:=C2=A0Re: [v6ops] Working Group Administrivia
Hi, Tom,
Thanks for your offer.

Review and comments would be very helpful for us to improve. Following the = latest discussion, there are two actions we are planning: A) focus on the i= mplementation divergence rather than a protocol definition problem statemen= t. The most of contents are already in the current document. It just needs = a little bit reorganizing and rewording. B) some addition investigation or = experiments, e.g. both DHCPv6 and ND have DNS configuration.

If you are interested to contribute, you are certainly welcome.

Best regards,

Sheng

>-----Original Message-----
>From: t.petch [mailto:ietfc@btco= nnect.com]
>Sent: Thursday, December 11, 2014 1:39 AM
>To: Sheng Jiang; Fred Baker (fred); v= 6ops@ietf.org
>Subject: Re: [v6ops] Working Group Administrivia
>
>Sheng
>
>If I read the e-mail addresses aright, you are the editor of
>draft-ietf-v6ops-dhcpv6-slaac-problem
>What do you want (that I might be able to do) bofore this is ready for<= br> >WG Last Call?
>
>Tom Petch
>
>
>----- Original Message -----
>From: "Sheng Jiang" <jiangsheng@huawei.com>
>To: "t.petch" <ietf= c@btconnect.com>; "Fred Baker (fred)"
><fred@cisco.com>; <v6ops@ietf.org>
>Sent: Monday, December 08, 2014 2:18 AM
>Subject: RE: [v6ops] Working Group Administrivia
>
>
>> >As Brian says in his note,
>> >
>> >2014-10-27=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-= v6ops-dhcpv6-slaac-problem
>>
>>http://datatracker.ietf.org/doc/draft-iet= f-v6ops-dhcpv6-slaac-problem/
>> >
>> >addresses a known problem and I think it would be remiss of th= e IETF
>not
>> >to have this documented
>>
>> Fully agreed. My read from the latest meeting response is the prob= lem
>should be document and know by operators and implementors. The
>controversial part is not this draft, but the follow up of this draft:<= br> >>
>> 1) The solution (protocol level) is not belong to v6ops WG.
>>
>> 2) The real debate is Whether v6ops should produce an operational<= br> >guidelines for operators to avoid this issue. Personally, I think it is=
>helpful and belong to this WG, but it seems the WG does not reach
>consensus on this.
>>
>> Best regards,
>>
>> Sheng
>>
>> >Tom Petch
>> >
>> >
>> >----- Original Message -----
>> >From: "Fred Baker (fred)" <fred@cisco.com>
>> >To: <v6ops@ietf.org&g= t;
>> >Sent: Friday, December 05, 2014 6:17 PM
>> >Subject: [v6ops] Working Group Administrivia
>> >
>> >
>> >Joel, Lee, and I spoke this morning about the status of the wo= rking
>> >group and various drafts in it. I=E2=80=99d like to gauge work= ing group
>> >consensus on the status of a number of working group drafts th= at have
>> >either expired or otherwise should no longer be considered wor= king
>group
>> >drafts. Your opinions, pro or con (such as =E2=80=9CI=E2=80=99= m fine with all that
>but
>> >think we should still be considering draft-whatever=E2=80=9D),= please:
>> >
>> >We think that the following can be safely set aside, by having= the
>> >secretariat record (and show in the data tracker) that they ar= e no
>> >longer working group drafts. They have expired, and are not cu= rrently
>> >being pursued:
>> >
>> >2003-01-13=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-v6ops-ipv4survey
>> >http://datatracker.ietf.org/doc/draft-ietf-v6o= ps-ipv4survey/
>> >2003-02-14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0draft-ietf-v6ops-ipv4survey-gen
>> >http://datatracker.ietf.org/doc/draft-ietf= -v6ops-ipv4survey-gen/
>> >2004-07-20=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 draft-ietf-v6ops-v6onbydefault
>> >http://datatracker.ietf.org/doc/draft-ietf-= v6ops-v6onbydefault/
>> >2007-02-27=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draf= t-ietf-v6ops-routing-guidelines
>> >http://datatracker.ietf.org/doc/draft-= ietf-v6ops-routing-guidelines/
>> >2007-03-28=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dra= ft-ietf-v6ops-campus-transition
>> >http://datatracker.ietf.org/doc/draft-i= etf-v6ops-campus-transition/
>> >2008-05-13=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-v6ops-n= at64-pb-statement-req
>>
>>http://datatracker.ietf.org/doc/draft-ie= tf-v6ops-nat64-pb-statement-req
>/
>> >2011-07-26=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draf= t-ietf-v6ops-v4v6tran-framework
>> >http://datatracker.ietf.org/doc/draft-= ietf-v6ops-v4v6tran-framework/
>> >2013-08-14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 draft-ietf-v6ops-monitor-ds-ipv6
>> >http://datatracker.ietf.org/doc/draft-iet= f-v6ops-monitor-ds-ipv6/
>> >
>> >We think that draft-ietf-v6ops-balanced-ipv6-security, in its = current
>> >state, is a deployment report, primarily from Swisscom. While = the
>> >working group expressed interest in guidance on firewall
>configuration,
>> >this isn=E2=80=99t it. We think it should no longer be a worki= ng group draft,
>> >and invite the authors to submit it to the independent stream = as a
>> >deployment report (<rfc-ise@rfc-editor.org).
>> >
>> >2013-12-06=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-v6ops-b= alanced-ipv6-security
>>
>>http://datatracker.ietf.org/doc/draft-ie= tf-v6ops-balanced-ipv6-security
>/
>> >
>> >Although the working group expressed interest in the following= and
>the
>> >authors have been working hard on them, we think the working g= roup is
>no
>> >longer interested in these, and so they should be returned to = the
>> >authors and not recorded or treated as working group drafts. >> >
>> >2014-09-18=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0draft-ietf-v6ops-design-choices
>> >http://datatracker.ietf.org/doc/draft-ietf= -v6ops-design-choices/
>> >2014-10-27=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-= v6ops-dhcpv6-slaac-problem
>>
>>http://datatracker.ietf.org/doc/draft-iet= f-v6ops-dhcpv6-slaac-problem/
>> >2014-10-27=C2=A0 =C2=A0 =C2=A0 draft-ietf-v6ops-ula-usage-reco= mmendations
>>
>>http://datatracker.ietf.org/doc/draft-ie= tf-v6ops-ula-usage-recommendati
>o
>> >ns/
>> >
>> >Speaking for myself, if I have any question of the above, it i= s on
>only
>> >one of these.
>> >
>> >If any draft has its "WG Draft" status revoked, it w= ill still be
>> >available from the IETF website as far as I know, but subseque= nt
>> >revisions should be named as individual submissions to a worki= ng
>group,
>> >draft-<author>-<wg>-<subject> or individual = submissions to the IETF,
>> >draft-<author>-<subject>. It would be good if the = authors would send
>a
>> >note to internet-d= rafts@ietf.org indicating that the old draft name
>were
>> >replaced by the new draft name, so that the revision history i= s
>tracked
>> >appropriately.
>> >
>> >Opinions?
>> >
>> >
>> >
>> >
>>
>>-------------------------------------------------------------------= ----
>-
>> >--------
>> >
>> >
>> >>
>> >>
>> >
>> >
>>
>>-------------------------------------------------------------------= ----
>-
>> >--------
>> >
>> >
>> >> _______________________________________________
>> >> 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
>>



---------- Forwarded message ----------
From:=C2=A0Keith Moore &= lt;moore@network-heretics.com= >
To:=C2=A0v6ops@ietf.orgCc:=C2=A0
Date:=C2=A0Thu, 11 Dec 2014 10:42:54 -0500
Subject:=C2=A0= Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt
Mumble.= =C2=A0 I support the deprecation of 192.88.99.1 as a means to find 6to4 rel= ays.=C2=A0 =C2=A0But this document still contains so many inaccurate and mi= sleading statements beyond that, including perhaps some statements that wer= e not present in earlier versions (though I haven't taken the time to c= heck yet), that I don't believe it should be published in its current f= orm. Again, this is a document quality issue, not an issue with the basic u= nderlying recommendation.

Most of the problems with this document are things that I have already ment= ioned in connection with earlier versions of this document.

Keith




---------- Forwarded message ----------
From:=C2=A0"Templin= , Fred L" <Fred.L.Temp= lin@boeing.com>
To:=C2=A0Jeroen Massar <jeroen@massar.ch>, "sthaug@nethelp.no" <sthaug@nethelp.no>
Cc:=C2=A0"v6ops@ietf.org" <v6ops@i= etf.org>
Date:=C2=A0Thu, 11 Dec 2014 16:10:44 +0000
Subject:= =C2=A0Re: [v6ops] PMTUD forever, was: MTUs on the general Internet
> = More on what I said the other day, there are two magic numbers that tunnels=
> need to concern themselves with: 1280 and 1500. Accommodating all pack= ets
> within that size range while placing no explicit upper bound for accom= modating
> larger packets is what is being proposed. In other words, no MTU clamp= ing.

Have we reached conclusion on this, and can it now be considered "case= closed"?

Remember - "take care of the smalls, and let the bigs take care of the= mselves":

https://datatracker.ietf.org/doc/draft-templin-aerolink/ https://datatracker.ietf.org/doc/draft-templin-aeromin/

Thanks - Fred
fred.l.templin@boeing.com<= br>



---------- Forwarded message ----------
From:=C2=A0Brian E Carpe= nter <brian.e.carpenter@g= mail.com>
To:=C2=A0Keith Moore <moore@network-heretics.com>
Cc:=C2=A0v6ops@ietf.org
Date:=C2=A0Fri, 12 Dec 2014 08:= 23:12 +1300
Subject:=C2=A0Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-= to-historic-09.txt
Keith, please, you need to be specific about what you= think is
inaccurate or misleading, line by line, in this version. There's
nothing we can do with a general criticism like that.

We have made numerous changes, some of them in response to your
comments, but of course in some cases your comments were at
variance with other peoples' comments. Of course, there were a
lot of messages, many of them completely orthogonal to the text
of the draft, so we may well have missed some of the relevant ones.

Regards
=C2=A0 =C2=A0Brian

On 12/12/2014 04:42, Keith Moore wrote:
> Mumble.=C2=A0 I support the deprecation of 192.88.99.1 as a means to f= ind
> 6to4 relays.=C2=A0 =C2=A0But this document still contains so many inac= curate and
> misleading statements beyond that, including perhaps some statements > that were not present in earlier versions (though I haven't taken = the
> time to check yet), that I don't believe it should be published in= its
> current form. Again, this is a document quality issue, not an issue wi= th
> the basic underlying recommendation.
>
> Most of the problems with this document are things that I have already=
> mentioned in connection with earlier versions of this document.
>
> Keith
>
> _______________________________________________
> 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 <= /span>(CoReNeT)
--089e0160b7ce1aeb4e050a1dde83-- From nobody Sat Dec 13 12:08: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 883C61A00BD for ; Sat, 13 Dec 2014 12:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 qn_je-xtcCxr for ; Sat, 13 Dec 2014 12:08:37 -0800 (PST) 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 3D82D1A1B48 for ; Sat, 13 Dec 2014 12:08:37 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id ey11so9346945pad.38 for ; Sat, 13 Dec 2014 12:08:36 -0800 (PST) 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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hCzhJOXAB1zf9nW13Ds37we85kxR1Ct1+N4NZHBg00k=; b=ucT/2dViLBwkmEQrjo8xgMrZ86yj0o+4ZSkmq1o8LFE+ppW0KiTriv5G6PmgTo/0fe lR0t1lIQHyqmF2ECnGQtXjs5H9F3ldRZLQPkrG6LzUZ4SdpDfplPoVSo4RYHGziqJpvT rCI9Hal5fFijAQPl6RESSzIn5ppVYtCqGx9lwUpccd76OIsGgmuPLnDTgOFSFVEsDG5G 16ZFEY0lRg3ipNtR9DVZJ67WjwXnmvLkWV+P3MCzHYrwB3j7/WKI63b9MiBFLUXPKbo4 eglL6R2Ii0X6TpaXghj2G/eJfK4j2Gv6axRWYizGSZ8X9PuvfZ1cSitpNQ7xAjjXc1Db Oz/Q== X-Received: by 10.66.253.197 with SMTP id ac5mr35236762pad.152.1418501316351; Sat, 13 Dec 2014 12:08:36 -0800 (PST) Received: from [192.168.178.26] (9.229.69.111.dynamic.snap.net.nz. [111.69.229.9]) by mx.google.com with ESMTPSA id v5sm4955191pdn.20.2014.12.13.12.08.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Dec 2014 12:08:35 -0800 (PST) Message-ID: <548C9CBF.4000407@gmail.com> Date: Sun, 14 Dec 2014 09:08:31 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "v6ops@ietf.org WG" References: <548B8EBA.7000200@network-heretics.com> <4DDC3299-2A1F-4E9C-8B25-4D1C47E08FFE@cisco.com> In-Reply-To: <4DDC3299-2A1F-4E9C-8B25-4D1C47E08FFE@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/iO1CdEJgjHYLpbhM-lXFaiYE_B4 Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt 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, 13 Dec 2014 20:08:43 -0000 Hi Keith, Document editor hat off: On 13/12/2014 19:56, Fred Baker (fred) wrote: > > Begin forwarded message: > >> From: Keith Moore >> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt >> Date: December 12, 2014 at 4:56:26 PM PST >> To: Brian E Carpenter >> Cc: "Fred Baker (fred)" , "draft-ietf-v6ops-6to4-to-historic.all@tools.ietf.org" >> >> Section 1: >> There would appear to be little evidence of substantial active use of >> the original form of 6to4 described in [RFC3056]. >> >> This statement is unsupported, Well, proving a negative is always hard. I personally have seen no evidence of any usage whatsoever of the pure RFC 3056 mechanism. I used my contacts in the IP trace collecting world to see if any trace files from ISPs or IXPs are available that would allow 6to4 usage to be measured, and failed. I have also never seen any information suggesting the existence of the type of operator agreements needed for routing according to sections 5.2.2.1 or 5.2.2.2 of RFC 3056. > and I believe, superfluous. That's defensible. But some kind of introductory sentence is needed. Any suggestion? > Such a statement might be supportable via traffic measurements, depending on how the measurements were done. But traffic measurements are often misinterpreted, and without a reference describing actual methods and results there's no way for the reader to assess the validity of the statement. Whether it's a defensible statement also depends on what "substantial" means. Anyway, the document would be stronger without it, as the document shouldn't really be about RFC 3056. >> >> Recommendation: delete this sentence. >> >> [RFC6343] analyses the known operational issues in detail and >> describes a set of suggestions to improve 6to4 reliability, given the >> widespread presence of hosts and customer premises equipment that >> support it. However, experience shows that operational failures have >> continued despite this advice being available. Fortunately the >> advice to disable 6to4 by default has been widely adopted in recent >> operating systems, and the failure modes have been largely hidden >> from users by many browsers adopting the "Happy Eyeballs" approach >> [RFC6555]. Nevertheless, a substantial amount of 6to4 traffic is >> still observed and the operational problems caused by 6to4 still >> occur. >> >> Although facts are hard to obtain, the remaining successful users of >> anycast 6to4 are likely to be on hosts using the obsolete policy >> table [RFC3484] (which prefers 6to4 above IPv4), without Happy >> Eyeballs, with a route to an operational anycast relay, and accessing >> sites that have a route to an operational return relay. >> Taken together these statements seem confusing at best. Well, it's a matter of judgment of course, but I disagree. I don't see any confusion. > Here's my attempt to sort things out: >> >> Measures that have been taken in the past (recommending disabling 6to4 by default, use of happy eyeballs) have had some useful effect. >> However some hosts are still observed (again, without any reference to the observations) to use 6to4 We have observations from a couple of sources (Google, which whether you like it or not, sees traffic from a very large proportion of ordinary users, and Geoff Huston's work, which obviously sees a much more restricted cross-section of users). It's above my pay grade to decide, but this document doesn't seem like the place for a detailed report on those observations. > and have operational problems doing so. Actually, the operational problems that we know about are reported indirectly by operators, via help desk hassles, not by users. >> Presumably the hosts that are still having operational problems are those that have, for whatever reason, failed to implement those measures (perhaps because they are running obsolete code, perhaps because they are behind routers that implement 6to4). Undoubtedly. I'm big-headed enough to believe that if RFC 6343 had been universally and completely implemented, there would be no more problems ;-). But we know, for example, that ~10% of the Windows market is still Windows XP, which means RFC 3484. > (Perhaps it is believed that publishing additional RFCs discouraging 6to4 use will help reduce those problems, as if somehow users will upgrade their systems and/or routers because we publish more RFCs.) No, of course not, from one day to the next. It will still take years for this to work through the network as a whole. >> >> Much of the latter paragraph seems completely unsupportable. The RFC3484 prefix selection table doesn't affect address selection for applications requiring or deliberately preferring IPv6 (say to circumvent NAT) and having only a single IPv6 address. No. It affects ordinary users with ordinary applications. > (Perhaps the authors are under the impression that the only hosts anyone wishes to communicate with using anycast 6to4 are those which also have IPv4 addresses, or the only apps using IPv6 are those which could work equally well through IPv4 NAT?) I am under that impression as far as the large majority of users goes, yes. > Happy Eyeballs isn't generally applicable to all applications using IPv6, and even when it's useful only helps if there are multiple source/destination address pairs from which to choose. Again, it's not correct to assume that either end of traffic using 6to4 has an IPv4 address that would work better for that application. I only make that assumption for the large majority of users, who do most things through an HTTP browser. > Just to pick one example, I've seen bittorrent use IPv6 addresses, including 6to4 addresses, when doing so would circumvent NAT brain-damage. Definitely. That's the largest known use case for peer-to-peer 6to4. afaik, the draft does nothing to damage that use case. >> >> Of course successful use of 6to4 does require routes to working relays in both directions. >> >> Recommendation: reword the former paragraph and (especially) delete the latter one. I disagree. >> IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [RFC5969] >> explicitly builds on the 6to4 mechanism, and could be viewed as a >> superset of 6to4, using a service provider prefix instead of >> 2002::/16. However, the deployment model is based on service povider >> support, such that 6rd can avoid the problems described here. In >> this sense, 6rd can be viewed as superseding 6to4 as described in >> section 4.2.4 of [RFC2026]. >> >> While 6rd is indeed useful, and it seems like a good solution for access providers wishing to provide their customers with an interim IPv6 solution until they deploy native IPv6, it is misleading to call it a "superset" of 6to4 or to claim that it supersedes it. 6rd would be better described as a subset, since it's potentially applicable in fewer situations than 6to4 is. Or perhaps it would be better to say that 6rd and 6to4 have different use cases. In particular, 6rd doesn't provide any help to a user needing to reach IPv6 hosts if the ISP to which he's currently connected doesn't support it. I agree that the word "superset" is slightly off target. But it is an objective fact that 6rd builds on 6to4; I could root out early email from 6rd's designer to justify that. The 6rd use case is (and always has been) to get the benefits of 6to4 without the problems, by relying on ISP support. However, I also agree that the last sentence "In this sense..." is a bit OTT. >> >> Recommendation: delete the paragraph. 6rd is irrelevant to this document. >> >> Given that native IPv6 support and various reliable transition >> mechanisms are now becoming common, the IETF sees no evolutionary >> future for the 6to4 mechanism. >> >> Whether native IPv4 support or reliable transition mechanisms are "becoming common" depends on your definition of "common", but we're still a long way from a point where such mechanisms are generally available and applicable to ordinary users. The main reason that there's no evolutionary future for the 6to4 mechanism is exhaustion of IPv4 address space and widespread deployment of NAT including carrier-side NAT. (The problems with use of anycast could be fixed if there were much to be gained by fixing them, but the inevitably-increasing use of carrier-side NAT means there's really no point in doing so.) Also, the paragraph could be taken to mean that these "reliable transition mechanisms" are good substitutes for 6to4, when reality is that there is currently no good replacement for 6to4. >> >> Recommendation: reword to say "Given that due to exhaustion of IPv4 address space carrier-side NAT is now becoming common, the IETF sees no evolutionary future for the 6to4 mechanism" That's a judgment call. I'm like "shrug". >> Section 3: >> >> With the increased deployment of IPv6, the >> mechanism has been shown to have a number of fundamental >> shortcomings. I have an alternative proposal for all the bullet points. Just replace the whole list with this: With the increased deployment of IPv6, the mechanism has been shown to have a number of fundamental shortcomings that are fully described in [RFC6343]. Anyway, with my document editor hat on: I await instructions from the WG Chairs and AD. Brian >> >> Some of these shortcomings are not specifically shortcomings with 6to4, but rather shortcomings of original address selection rules (which incorrectly assumed that any v6 path would work at least as well as any v4 path), the Internet architecture itself (poor support for multihomed hosts which manifests in several ways and persists to this day) >> >> o Use of relays. 6to4 depends on an unknown third party to operate >> the relays between the 6to4 cloud and the native IPv6 Internet. >> >> I think this is redundant with the 3rd bullet, and the 3rd bullet states it better. >> o The placement of the relay can lead to increased latency, and in >> the case the relay is overloaded, packet loss. >> >> While this statement is true on its face, it's sort of meaningless or misleading. It begs the question "increased latency as compared to what?" 6to4 actually did a fairly good job of finding nearby relays in both directions if they were available - often providing lower latency better than configured tunnels except those provided by one's own ISP. >> >> The real problem was with the original address prefix selection algorithm and its implicit assumption that any IPv6 path would be better than any IPv4 path. If ISPs around the world had deployed native IPv6 15 years ago but initially with suboptimal routing, the same problem of decreased latency would have appeared due to hosts' blind preference of v6 over v4. >> >> For that matter, the intended purpose of 6to4 (or for that matter IPv6) never was to facilitate communications between hosts or application peers that could just as well use IPv4. >> o There is generally no customer relationship between the end-user >> and the relay operator, or even a way for the end-user to know who >> the relay operator is, so no support is possible. >> >> Agreed. >> o A 6to4 relay for the reverse path and an anycast 6to4 relay used >> for the forward path, are openly accessible, limited only by the >> scope of routing. 6to4 relays can be used to anonymize traffic and >> inject attacks into IPv6 that are very difficult to trace. >> >> Two things: The first statement is true but as far as I can tell only half of it is relevant - the "reverse" (6->4) path relay doesn't permit anonymizing traffic as far as I can tell. The "forward" (4->6) path relay permits anonymizing traffic if the relay doesn't check that the IPv4 source address on the inbound packet is consistent with the IPv6 source address on the inbound packet. Otherwise, the degree of anonymizing possible is about the same as with NAT44 - the rest of the network can't tell which host the traffic came from but it can tell which network it came from. >> >> o 6to4 may silently discard traffic in the case where protocol (41) >> is blocked in intermediate firewalls. Even if a firewall sent an >> ICMP message unreachable back, an IPv4 ICMP message rarely >> contains enough of the original IPv6 packet so that it can be >> relayed back to the IPv6 sender. That makes this problem hard to >> detect and react upon by the sender of the packet. >> >> Well, of course it's not 6to4 discarding the traffic, it's the firewalls. Place the blame where it belongs. And these problems exist with protocol 41 tunnels in general, including 6rd tunnels, not just 6to4 tunnels. (It seems especially odd for this document >> to be recommending 6rd as a replacement of sorts for 6to4 while at the same time >> citing 6to4 for shortcomings that are also present with 6rd.) >> >> There are really two issues here: >> - "accidental" blocking of 6to4 by firewalls (i.e. because of naivete or misconfiguration rather than because of explicit policy) >> - hosts/apps not coping well with blocking of 6to4 by firewalls >> >> Recommendation: separate into two bullets: >> >> - 6to4 traffic was sometimes silently discarded by firewalls, either because they blocked >> protocol 41 indiscriminately, or because they blocked incoming traffic flows that weren't initiated by outgoing traffic flows, and were not configured to recognize outgoing flows over protocol 41. Sometimes this blocking was deliberate, sometimes accidental due to underspecified configuration. >> >> - Whether or not by accident, when encapsulated traffic was blocked by a IPv4-only firewall, an ICMPv4 response from the firewall was unlikely to be useful to the sender's IPv6 stack, and an IPv4-only firewall generally wouldn't know how to send ICMPv6 responses encapsulated in IPv4, to the sending host. >> >> >> >> o As 6to4 tunnels across the Internet, the IPv4 addresses used must >> be globally reachable. RFC 3056 states that a private address >> [RFC1918] MUST NOT be used. 6to4 will not work in networks that >> employ other addresses with limited topological span. In >> particular it will predictably fail in the case of double network >> address translation (NAT444). >> >> This bullet seems very muddy. >> >> "As 6to4 tunnels across the Internet" should say "the IPv4 Internet". The Internet isn't just IPv4. >> >> The second sentence seems out of place. It's not immediately clear what RFC 3056's statement about RFC 1918 addresses has to do with the argument that's being made. >> >> - The general issue is that 6to4 doesn't work to provide IPv6 access to hosts or routers lacking a globally-scoped and globally-reachable IPv4 address. This in combination with widespread use of NAT made 6to4 much less useful than it would otherwise have been, and is perhaps the biggest single problem with 6to4. >> >> - A related problem was that it wasn't clear from the 6to4 specifications that hosts and routers supporting 6to4 needed a reliable way to detect that they had globally-scoped and globally-reachable IPv4 addresses. RFC 1918 addresses were excluded by RFC 3056, but other unsuitable IPv4 addresses were not as easily recognized. >> >> - Some 6to4 implementations were once known to enable 6to4 by default for any non-RFC1918 address, having the effect of enabling a IPv6 address and interface that would never work, and (in the absence of modern address selection rules or happy eyeballs) causing traffic to be blackholed. However this problem has largely been fixed. >> >> As far as I can tell, the problem with double NAT is just one example of the general problem. Even a single layer of NAT breaks 6to4. >> >> Recommendation: reword the above bullet into two separate bullets, along the lines above. >> >> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sat Dec 13 14:04: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 567E41A03B3 for ; Sat, 13 Dec 2014 14:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 Dss24hGXZS2f for ; Sat, 13 Dec 2014 14:04:12 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3445E1A1B36 for ; Sat, 13 Dec 2014 14:04:12 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id B3E891FCAB7; Sat, 13 Dec 2014 22:04:08 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C2F1A160067; Sat, 13 Dec 2014 22:08:49 +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 8E82A160066; Sat, 13 Dec 2014 22:08:49 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7E1E6255FECF; Sun, 14 Dec 2014 09:04:05 +1100 (EST) To: Tariq Saraj From: Mark Andrews References: In-reply-to: Your message of "Sun, 14 Dec 2014 00:18:00 +0500." Date: Sun, 14 Dec 2014 09:04:05 +1100 Message-Id: <20141213220405.7E1E6255FECF@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rx_Moc9__ZPL0iD1A_Jkxru66uU Cc: v6ops@ietf.org Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 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, 13 Dec 2014 22:04:14 -0000 In message , Tariq Saraj writes: > > There are some issues with 6rd as well, IPv6 with all its powerful features > is still under critical objections in academia just because of the urgency > shown by IETF in standardizing protocols like 6to4 and 6rd. 6to4 clearly > mentioned that it cannot support multicast at layer-3, on the other end 6rd > claimed that multicast can be provided, my question is that while > standardizing 6rd which at that time was just supporting unicast traffic > traversing across IPv4 network and its still not matured enough to provide > multicast support yet in its functionality other than using some proxy > support for multicast traffic. why It was standardized ? 6to4 and 6rd are interim solutions for delivering IPv6 over IPv4. They were standardized so that manufactures could ship products that interoperate. Engineering is all about trade offs. With 6to4 and 6rd it is about delivering IPv6 unicast in a timely manner while waiting for the intermediate network components to be upgraded to support IPv6. If you need IPv6 multicast then you need to arrange for it to be delivered. You can still run multicast tunnels over 6to4 and 6rd if you need to. They just don't supply multicast natively. I suspect you will find you will need to do this even with native IPv6 as many ISP's are in the business of delivering global multicast traffic. > a common > university level student is considering IPv6 nothing more than just a large > address space. The support for multicast traffic is increasing every day at > application level. My request at this forum is to consider 6rd along with > the 6to4 so that in future both of these protocols not to become a part of > any network device. I personally feels that instead of supporting to > promote the IPv6 both of these protocols are becoming obstacles in this > regards. I prefer using GRE over these automatic tunneling mechanisms at > least GRE supports multicast on network layer and let the application > program to design his/her application in more different ways. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sat Dec 13 14:15: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 DBC331A03A7 for ; Sat, 13 Dec 2014 14:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.89 X-Spam-Level: X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 RC7nCgGiQq45 for ; Sat, 13 Dec 2014 14:15:07 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D10C51A1A58 for ; Sat, 13 Dec 2014 14:15:06 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id B67AF349633; Sat, 13 Dec 2014 22:15:04 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 59585160067; Sat, 13 Dec 2014 22:19:46 +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 22CEB160066; Sat, 13 Dec 2014 22:19:46 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id CDB2E2560155; Sun, 14 Dec 2014 09:15:01 +1100 (EST) From: Mark Andrews In-reply-to: Your message of "Sun, 14 Dec 2014 09:04:05 +1100." Date: Sun, 14 Dec 2014 09:15:01 +1100 Message-Id: <20141213221501.CDB2E2560155@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/y8jkw9qGaJLpB0nDkwJgb8UxF3Y Cc: Tariq Saraj , v6ops@ietf.org Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 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, 13 Dec 2014 22:15:09 -0000 Mark Andrews writes: > > In message m> > , Tariq Saraj writes: > > > > There are some issues with 6rd as well, IPv6 with all its powerful features > > is still under critical objections in academia just because of the urgency > > shown by IETF in standardizing protocols like 6to4 and 6rd. 6to4 clearly > > mentioned that it cannot support multicast at layer-3, on the other end 6rd > > claimed that multicast can be provided, my question is that while > > standardizing 6rd which at that time was just supporting unicast traffic > > traversing across IPv4 network and its still not matured enough to provide > > multicast support yet in its functionality other than using some proxy > > support for multicast traffic. why It was standardized ? > > 6to4 and 6rd are interim solutions for delivering IPv6 over IPv4. > They were standardized so that manufactures could ship products > that interoperate. > > Engineering is all about trade offs. With 6to4 and 6rd it is about > delivering IPv6 unicast in a timely manner while waiting for the > intermediate network components to be upgraded to support IPv6. > > If you need IPv6 multicast then you need to arrange for it to be > delivered. You can still run multicast tunnels over 6to4 and 6rd > if you need to. They just don't supply multicast natively. > > I suspect you will find you will need to do this even with native > IPv6 as many ISP's are in the business of delivering global multicast Missed the key word "not" are *not* in the business of delivering global multicast > traffic. > > > a common > > university level student is considering IPv6 nothing more than just a large > > address space. The support for multicast traffic is increasing every day at > > application level. My request at this forum is to consider 6rd along with > > the 6to4 so that in future both of these protocols not to become a part of > > any network device. I personally feels that instead of supporting to > > promote the IPv6 both of these protocols are becoming obstacles in this > > regards. I prefer using GRE over these automatic tunneling mechanisms at > > least GRE supports multicast on network layer and let the application > > program to design his/her application in more different ways. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sat Dec 13 16:48: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 EBFDA1A0392 for ; Sat, 13 Dec 2014 16:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 bfp-k0sc_UKH for ; Sat, 13 Dec 2014 16:48:15 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40E2B1A01E1 for ; Sat, 13 Dec 2014 16:48:15 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 940C52031D for ; Sat, 13 Dec 2014 19:48:13 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sat, 13 Dec 2014 19:48:13 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=3YKyZRCCuuCkHtXaIHf8Ck AO5q8=; b=YbtGky1zyN/4pi6JKA7HDpU42UNTj1jXF65E0I5TKgUuCFt1WHfhjq 5KFOMOhsc8oOLFj2fHVG4ZpSvN58Zo7OhQFx9duVFWMG2HwAk6IR+ZkIE2Nirvnb z7DD2Y0sfvyjBfXUvTksW9tHwVgVs4XM0MQSavXqR7s6eQU8jjMl4= X-Sasl-enc: 2nJC7TCMr3ml1jw1G5m1Ee1HRfiEOn38FMQrm6eMbUIs 1418518093 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 1811BC0029C; Sat, 13 Dec 2014 19:48:13 -0500 (EST) Message-ID: <548CDE48.5090009@network-heretics.com> Date: Sat, 13 Dec 2014 19:48:08 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Brian E Carpenter , "v6ops@ietf.org WG" References: <548B8EBA.7000200@network-heretics.com> <4DDC3299-2A1F-4E9C-8B25-4D1C47E08FFE@cisco.com> <548C9CBF.4000407@gmail.com> In-Reply-To: <548C9CBF.4000407@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/K5ZKZcCf_438icg6qK1SbZ_bW-Q Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt 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, 14 Dec 2014 00:48:19 -0000 On 12/13/2014 03:08 PM, Brian E Carpenter wrote: > Section 1: > There would appear to be little evidence of substantial active use of > the original form of 6to4 described in [RFC3056]. > > This statement is unsupported, > Well, proving a negative is always hard. I personally have seen no > evidence of any usage whatsoever of the pure RFC 3056 mechanism. I've certainly used it, I think before RFC 3056 was even published. Before NAT became commonplace, it was a great way to facilitate remote access to my hosts at home. Even after NAT became the norm while roaming, it was useful to communicate between individual hosts residing on networks that each had 6to4-capable routers. Of course, that's not evidence of substantial use. I think it would be hard to establish evidence of substantial use (or lack thereof), because that would require measurement of not only the number of IPv4 protocol 41 packets, but also the number of such packets where both source and destination IPv6 addresses in the IPv4 payload had 2002: prefixes. And you'd need to measure it at several well-chosen and geographically dispersed points to have confidence in the conclusion. > I used my contacts in the IP trace collecting world to see if any > trace files from ISPs or IXPs are available that would allow 6to4 > usage to be measured, and failed. I have also never seen any > information suggesting the existence of the type of operator > agreements needed for routing according to sections 5.2.2.1 or > 5.2.2.2 of RFC 3056. > >> and I believe, superfluous. > That's defensible. But some kind of introductory sentence is needed. > Any suggestion? My understanding is that the things that motivated writing this document were that: (a) anycast 6to4 was observed to be often unreliable, and (b) this had the effect of discouraging deployment of IPv6 access to services already accessible via IPv4, and perhaps discouraging user acceptance of IPv6 in general. Something along those lines seems like an appropriate introduction to this document. > >> >> [RFC6343] analyses the known operational issues in detail and >> describes a set of suggestions to improve 6to4 reliability, given the >> widespread presence of hosts and customer premises equipment that >> support it. However, experience shows that operational failures have >> continued despite this advice being available. Fortunately the >> advice to disable 6to4 by default has been widely adopted in recent >> operating systems, and the failure modes have been largely hidden >> from users by many browsers adopting the "Happy Eyeballs" approach >> [RFC6555]. Nevertheless, a substantial amount of 6to4 traffic is >> still observed and the operational problems caused by 6to4 still >> occur. >> >> Although facts are hard to obtain, the remaining successful users of >> anycast 6to4 are likely to be on hosts using the obsolete policy >> table [RFC3484] (which prefers 6to4 above IPv4), without Happy >> Eyeballs, with a route to an operational anycast relay, and accessing >> sites that have a route to an operational return relay. >>> Taken together these statements seem confusing at best. > Well, it's a matter of judgment of course, but I disagree. I don't see > any confusion. > >> Here's my attempt to sort things out: >>> Measures that have been taken in the past (recommending disabling 6to4 by default, use of happy eyeballs) have had some useful effect. >>> However some hosts are still observed (again, without any reference to the observations) to use 6to4 > We have observations from a couple of sources (Google, which > whether you like it or not, sees traffic from a very large > proportion of ordinary users, and Geoff Huston's work, which > obviously sees a much more restricted cross-section of users). > It's above my pay grade to decide, but this document doesn't seem > like the place for a detailed report on those observations. I am presuming that Google most sees traffic exchanged with Google's servers, which are mostly accessible via either IPv4 and IPv6. That's just one kind of use of 6to4, it's not an indication of overall "success" using anycast 6to4. Again, the justification / use case for 6to4 isn't to facilitate communication that could just as easily be done using IPv4, it is to facilitate communication that could not be done using IPv4, or for which using IPv4 would be suboptimal in some way. So if we're trying to measure "success" of 6to4, what needs to be measured is communications between peers that don't both have IPv4 addresses, and/or communications that would be adversely affected by v4 NAT. HTTP and SMTP aren't examples of that kind of traffic. (Google might be in a good position to see how well 6to4 works with webrtc, but that would have to be done by looking at things like how often a webrtc connection "fell back" to a STUN/TURN path when there was a v6 path available using 6to4 on one or both ends. ) > >> Presumably the hosts that are still having operational problems are those that have, for whatever reason, failed to implement those measures (perhaps because they are running obsolete code, perhaps because they are behind routers that implement 6to4). > Undoubtedly. I'm big-headed enough to believe that if RFC 6343 had > been universally and completely implemented, there would be no more > problems ;-). But we know, for example, that ~10% of the Windows market > is still Windows XP, which means RFC 3484. Aside: it's really unfortunate that updating old versions of several operating systems often cannot be done without one or more of of: hardware upgrade, significant service disruption, significant harm to usability, user training, admin training, changes in administrative procedures, and sometimes tremendous expense due to the need to qualify the new hardware/software combination in certain environments (e.g. medical, aviation). There needs to be a way to fix serious defects, with minimal disruption, even in older software. Obviously IETF can't fix this, but IETF might actually be able to have some influence over this. (end of rant) > >>> Much of the latter paragraph seems completely unsupportable. The RFC3484 prefix selection table doesn't affect address selection for applications requiring or deliberately preferring IPv6 (say to circumvent NAT) and having only a single IPv6 address. > No. It affects ordinary users with ordinary applications. There's a widespread, strong, and unfortunate tendency to think that "ordinary users with ordinary applications" means pretty much web and email, or only client-server apps where the servers are in the "cloud", and I don't think that's valid at all. Ordinary users play distributed games, chat, use audio and video telephony, exchange files in various ways, all of which benefit from availability of direct peer-to-peer communications between users' hosts. Ordinary users install arbitrary apps, with a broad spectrum of uses and communications patterns, on their computers and phones. Moreover, the Internet isn't supposed to be only a client-server network. It is designed to allow arbitrary hosts to exchange data with other arbitrary hosts, and we need to defend the Internet architecture from attempts to characterize it as, or constrain it to be, client-server. There's also the problem that we've suffered through use of a NAT-impaired IPv4 network for so long that we've come to accept as "ordinary" applications that suffer from NAT-impairment. But we shouldn't be assuming that IPv6 usage patterns will resemble what is "normal" in the NATted IPv4 world. > >> (Perhaps the authors are under the impression that the only hosts anyone wishes to communicate with using anycast 6to4 are those which also have IPv4 addresses, or the only apps using IPv6 are those which could work equally well through IPv4 NAT?) > I am under that impression as far as the large majority of users goes, yes. Obviously, I do not share that impression. > >> Happy Eyeballs isn't generally applicable to all applications using IPv6, and even when it's useful only helps if there are multiple source/destination address pairs from which to choose. Again, it's not correct to assume that either end of traffic using 6to4 has an IPv4 address that would work better for that application. > I only make that assumption for the large majority of users, who do > most things through an HTTP browser. The Internet doesn't just exist to support HTTP, or client-server apps. And relative traffic measurements are not a good proxy for the importance of particular applications or protocols. > >> Just to pick one example, I've seen bittorrent use IPv6 addresses, including 6to4 addresses, when doing so would circumvent NAT brain-damage. > Definitely. That's the largest known use case for peer-to-peer 6to4. > afaik, the draft does nothing to damage that use case. You might notice that I didn't actually object to any of the specific recommendations made in the current draft, just to the way that the situation with 6to4 is characterized. > >> IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [RFC5969] >> explicitly builds on the 6to4 mechanism, and could be viewed as a >> superset of 6to4, using a service provider prefix instead of >> 2002::/16. However, the deployment model is based on service povider >> support, such that 6rd can avoid the problems described here. In >> this sense, 6rd can be viewed as superseding 6to4 as described in >> section 4.2.4 of [RFC2026]. >> >> While 6rd is indeed useful, and it seems like a good solution for access providers wishing to provide their customers with an interim IPv6 solution until they deploy native IPv6, it is misleading to call it a "superset" of 6to4 or to claim that it supersedes it. 6rd would be better described as a subset, since it's potentially applicable in fewer situations than 6to4 is. Or perhaps it would be better to say that 6rd and 6to4 have different use cases. In particular, 6rd doesn't provide any help to a user needing to reach IPv6 hosts if the ISP to which he's currently connected doesn't support it. > I agree that the word "superset" is slightly off target. But it is an > objective fact that 6rd builds on 6to4; I could root out early email > from 6rd's designer to justify that. No argument there. > > The 6rd use case is (and always has been) to get the benefits of 6to4 > without the problems, by relying on ISP support. However, I also > agree that the last sentence "In this sense..." is a bit OTT. I just think that this paragraph inaccurately conveys the notion that 6rd is an adequate substitute/replacement for all uses of 6to4, when it's not. However, 6rd is generally a good substitute/replacement for 6to4 for users whose ISP is providing the 6rd service *, and I have no problem with this document saying that. * presuming that the hardware that they supply to customers actually supports that service, unlike one of my current ISPs. > >>> Recommendation: delete the paragraph. 6rd is irrelevant to this document. >>> >>> Given that native IPv6 support and various reliable transition >>> mechanisms are now becoming common, the IETF sees no evolutionary >>> future for the 6to4 mechanism. >>> >>> Whether native IPv4 support or reliable transition mechanisms are "becoming common" depends on your definition of "common", but we're still a long way from a point where such mechanisms are generally available and applicable to ordinary users. The main reason that there's no evolutionary future for the 6to4 mechanism is exhaustion of IPv4 address space and widespread deployment of NAT including carrier-side NAT. (The problems with use of anycast could be fixed if there were much to be gained by fixing them, but the inevitably-increasing use of carrier-side NAT means there's really no point in doing so.) Also, the paragraph could be taken to mean that these "reliable transition mechanisms" are good substitutes for 6to4, when reality is that there is currently no good replacement for 6to4. >>> >>> Recommendation: reword to say "Given that due to exhaustion of IPv4 address space carrier-side NAT is now becoming common, the IETF sees no evolutionary future for the 6to4 mechanism" > That's a judgment call. I'm like "shrug". This sentence could give the reader the impression that there are commonly available replacements/substitutes available for 6to4, and that's simply not the case at the present time. And why not place the blame where it belongs? The main reason that 6to4 isn't more widely applicable, and is not worth fixing, is that the IPv4 Internet has become so dysfunctional that you can't even count on it to carry packets intact from source to destination anymore. We had an opportunity to facilitate a much easier transition to native v6, and we blew it by not insisting that all v4 NATs (especially carrier-side NATs) support a well-engineered, standard, v6 transition mechanism. > >>> Section 3: >>> >>> With the increased deployment of IPv6, the >>> mechanism has been shown to have a number of fundamental >>> shortcomings. > I have an alternative proposal for all the bullet points. Just replace the > whole list with this: > > With the increased deployment of IPv6, the > mechanism has been shown to have a number of fundamental > shortcomings that are fully described in [RFC6343]. While I might quibble with the word "fully", overall that seems like a reasonable approach. In general I find the RFC6343 discussion of 6to4 issues more readable, more comprehensive, and more objective than those in 6to4-to-historic. Not rehashing those issues in the context of this draft makes good sense to me. Keith From nobody Sun Dec 14 19:33: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 946381A0390 for ; Sun, 14 Dec 2014 19:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 6oICotfFySwo for ; Sun, 14 Dec 2014 19:33:28 -0800 (PST) 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 11C731A037B for ; Sun, 14 Dec 2014 19:33:27 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMV67483; Mon, 15 Dec 2014 03:33:26 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 15 Dec 2014 03:33:26 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.128]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Mon, 15 Dec 2014 11:33:20 +0800 From: Sheng Jiang To: "Fred Baker (fred)" , "Howard, Lee" Thread-Topic: [v6ops] Working Group Administrivia Thread-Index: AQHQELfApl0OmdTiikqs9ZO27DRlMpyD67olgAEAGMCABDNY1YAAiuIQgAIt9FH//8t1AIAEaBnQ Date: Mon, 15 Dec 2014 03:33:18 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AFF0B22@nkgeml512-mbx.china.huawei.com> References: <08DA982D-6605-434B-B815-C69B8A97FA4C@cisco.com> <010701d01204$b8e18160$4001a8c0@gateway.2wire.net> <5D36713D8A4E7348A7E10DF7437A4B923AFDB427@nkgeml512-mbx.china.huawei.com> <05aa01d014a0$43c5be20$4001a8c0@gateway.2wire.net> <5D36713D8A4E7348A7E10DF7437A4B923AFEBEB2@nkgeml512-mbx.china.huawei.com> <047201d015fb$f040d660$4001a8c0@gateway.2wire.net> <9F0F40BF-C408-4067-BB4C-4A0E948F1FC7@cisco.com> In-Reply-To: <9F0F40BF-C408-4067-BB4C-4A0E948F1FC7@cisco.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_Np9OFmqqh5xsSOZC1wjG62RGIc Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Working Group 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: Mon, 15 Dec 2014 03:33:29 -0000 PkZyb206IEZyZWQgQmFrZXIgKGZyZWQpIFttYWlsdG86ZnJlZEBjaXNjby5jb21dDQo+U2VudDog U2F0dXJkYXksIERlY2VtYmVyIDEzLCAyMDE0IDEyOjA2IEFNDQo+DQo+dGhlIFVMQSBkcmFmdCBz aG91bGQgY29udGludWUgKHdpdGggdGhlIHByZWZlcnJlZCBvdXRjb21lDQo+dG8gYmUgdG8gZG9j dW1lbnQgdXNlIGNhc2VzIGtub3duIHRvIGJlIGRlcGxveWVkKQ0KDQpIaSwgRnJlZCAmIEhvd2Fy ZCwNCg0KV2UgYXJlIHdvcmtpbmcgdG93YXJkcyB0aGF0IGRpcmVjdGlvbi4gV2Ugd2lsbCBldmVu IGNoYW5nZSB0aGUgZG9jdW1lbnQgdGl0bGUuIEhvd2V2ZXIsIHRoZSBkb2N1bWVudCBuYW1lIChk cmFmdC1pZXRmLXY2b3BzLXVsYS11c2FnZS1yZWNvbW1lbmRhdGlvbnMpIGlzIHN0aWxsIG1pc2xl YWRpbmcuIEZvciBuZXh0IHZlcnNpb24sIGNhbiB3ZSByZXN1Ym1pdCBpdCBhcyBkcmFmdC1pZXRm LXY2b3BzLXVsYS11c2UtY2FzZXMgb3Igc29tZXRoaW5nIHlvdSB0aGluayBwcm9wZXIuIFRoZW4g eW91IGNhbiB0YWcgaXMgYXMgcmVwbGFjZW1lbnQgb2YgZHJhZnQtaWV0Zi12Nm9wcy11bGEtdXNh Z2UtcmVjb21tZW5kYXRpb25zLiBEb2VzIGl0IHdvcmsgZm9yIHlvdT8NCg0KQmVzdCByZWdhcmRz LA0KDQpTaGVuZw0K From nobody Mon Dec 15 08:15: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 9AB9C1A7D85 for ; Mon, 15 Dec 2014 08:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 k1DU09zGddSY for ; Mon, 15 Dec 2014 08:15:21 -0800 (PST) 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 143281A7033 for ; Mon, 15 Dec 2014 08:15:20 -0800 (PST) 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 sBFGFKdO020533; Mon, 15 Dec 2014 08:15:20 -0800 Received: from XCH-PHX-110.sw.nos.boeing.com (xch-phx-110.sw.nos.boeing.com [130.247.25.39]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sBFGFHAX020506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 15 Dec 2014 08:15:18 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-PHX-110.sw.nos.boeing.com ([169.254.10.45]) with mapi id 14.03.0210.002; Mon, 15 Dec 2014 08:15:17 -0800 From: "Templin, Fred L" To: Tariq Saraj , "v6ops@ietf.org" Thread-Topic: [v6ops] v6ops Digest, Vol 52, Issue 41 Thread-Index: AQHQFwmRs8qPWksXhECub0mFNvQ4xZyQ1X9Q Date: Mon, 15 Dec 2014 16:15:16 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DB6AA1@XCH-BLV-504.nw.nos.boeing.com> References: 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: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D9831832DB6AA1XCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DDPsdBN_ppP2Vxr25ktvp-ERvrU Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 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, 15 Dec 2014 16:15:26 -0000 --_000_2134F8430051B64F815C691A62D9831832DB6AA1XCHBLV504nwnosb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGFyaXEsDQoNCkFsdGhvdWdoIHRoZSBkb2N1bWVudCB1c2VzIHRoZSB0ZXJtIOKAnE5CTUHi gJ0sIEFFUk8gZG9lcyBpbmNsdWRlIHByb3Zpc2lvbnMNCmZvciBtdWx0aWNhc3Rpbmc6DQoNCmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRlbXBsaW4tYWVyb2xpbmsvDQoN CkFFUk8gY2FuIHNlcnZlIGFzIGEgcmVwbGFjZW1lbnQgZm9yIGJvdGggNnRvNCBhbmQgNnJkLg0K DQpUaGFua3Mg4oCTIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0KRnJvbTogdjZv cHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGFyaXEgU2Fy YWoNClNlbnQ6IFNhdHVyZGF5LCBEZWNlbWJlciAxMywgMjAxNCAxMToxOCBBTQ0KVG86IHY2b3Bz QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSB2Nm9wcyBEaWdlc3QsIFZvbCA1MiwgSXNz dWUgNDENCg0KVGhlcmUgYXJlIHNvbWUgaXNzdWVzIHdpdGggNnJkIGFzIHdlbGwsIElQdjYgd2l0 aCBhbGwgaXRzIHBvd2VyZnVsIGZlYXR1cmVzIGlzIHN0aWxsIHVuZGVyIGNyaXRpY2FsIG9iamVj dGlvbnMgaW4gYWNhZGVtaWEganVzdCBiZWNhdXNlIG9mIHRoZSB1cmdlbmN5IHNob3duIGJ5IElF VEYgaW4gc3RhbmRhcmRpemluZyBwcm90b2NvbHMgbGlrZSA2dG80IGFuZCA2cmQuIDZ0bzQgY2xl YXJseSBtZW50aW9uZWQgdGhhdCBpdCBjYW5ub3Qgc3VwcG9ydCBtdWx0aWNhc3QgYXQgbGF5ZXIt Mywgb24gdGhlIG90aGVyIGVuZCA2cmQgY2xhaW1lZCB0aGF0IG11bHRpY2FzdCBjYW4gYmUgcHJv dmlkZWQsIG15IHF1ZXN0aW9uIGlzIHRoYXQgd2hpbGUgc3RhbmRhcmRpemluZyA2cmQgd2hpY2gg YXQgdGhhdCB0aW1lIHdhcyBqdXN0IHN1cHBvcnRpbmcgdW5pY2FzdCB0cmFmZmljIHRyYXZlcnNp bmcgYWNyb3NzIElQdjQgbmV0d29yayBhbmQgaXRzIHN0aWxsIG5vdCBtYXR1cmVkIGVub3VnaCB0 byBwcm92aWRlIG11bHRpY2FzdCBzdXBwb3J0IHlldCBpbiBpdHMgZnVuY3Rpb25hbGl0eSBvdGhl ciB0aGFuIHVzaW5nIHNvbWUgcHJveHkgc3VwcG9ydCBmb3IgbXVsdGljYXN0IHRyYWZmaWMuIHdo eSBJdCB3YXMgc3RhbmRhcmRpemVkID8gYSBjb21tb24gdW5pdmVyc2l0eSBsZXZlbCBzdHVkZW50 IGlzIGNvbnNpZGVyaW5nIElQdjYgbm90aGluZyBtb3JlIHRoYW4ganVzdCBhIGxhcmdlIGFkZHJl c3Mgc3BhY2UuIFRoZSBzdXBwb3J0IGZvciBtdWx0aWNhc3QgdHJhZmZpYyBpcyBpbmNyZWFzaW5n IGV2ZXJ5IGRheSBhdCBhcHBsaWNhdGlvbiBsZXZlbC4gTXkgcmVxdWVzdCBhdCB0aGlzIGZvcnVt IGlzIHRvIGNvbnNpZGVyIDZyZCBhbG9uZyB3aXRoIHRoZSA2dG80IHNvIHRoYXQgaW4gZnV0dXJl IGJvdGggb2YgdGhlc2UgcHJvdG9jb2xzIG5vdCB0byBiZWNvbWUgYSBwYXJ0IG9mIGFueSBuZXR3 b3JrIGRldmljZS4gSSBwZXJzb25hbGx5IGZlZWxzIHRoYXQgaW5zdGVhZCBvZiBzdXBwb3J0aW5n IHRvIHByb21vdGUgdGhlIElQdjYgYm90aCBvZiB0aGVzZSBwcm90b2NvbHMgYXJlIGJlY29taW5n IG9ic3RhY2xlcyBpbiB0aGlzIHJlZ2FyZHMuIEkgcHJlZmVyIHVzaW5nIEdSRSBvdmVyIHRoZXNl IGF1dG9tYXRpYyB0dW5uZWxpbmcgbWVjaGFuaXNtcyBhdCBsZWFzdCBHUkUgc3VwcG9ydHMgbXVs dGljYXN0IG9uIG5ldHdvcmsgbGF5ZXIgYW5kIGxldCB0aGUgYXBwbGljYXRpb24gcHJvZ3JhbSB0 byBkZXNpZ24gaGlzL2hlciBhcHBsaWNhdGlvbiBpbiBtb3JlIGRpZmZlcmVudCB3YXlzLg0KDQpP biBGcmksIERlYyAxMiwgMjAxNCBhdCAxOjAwIEFNLCA8djZvcHMtcmVxdWVzdEBpZXRmLm9yZzxt YWlsdG86djZvcHMtcmVxdWVzdEBpZXRmLm9yZz4+IHdyb3RlOg0KU2VuZCB2Nm9wcyBtYWlsaW5n IGxpc3Qgc3VibWlzc2lvbnMgdG8NCiAgICAgICAgdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3Bz QGlldGYub3JnPg0KDQpUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBX aWRlIFdlYiwgdmlzaXQNCiAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby92Nm9wcw0Kb3IsIHZpYSBlbWFpbCwgc2VuZCBhIG1lc3NhZ2Ugd2l0aCBzdWJqZWN0IG9y IGJvZHkgJ2hlbHAnIHRvDQogICAgICAgIHY2b3BzLXJlcXVlc3RAaWV0Zi5vcmc8bWFpbHRvOnY2 b3BzLXJlcXVlc3RAaWV0Zi5vcmc+DQoNCllvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2lu ZyB0aGUgbGlzdCBhdA0KICAgICAgICB2Nm9wcy1vd25lckBpZXRmLm9yZzxtYWlsdG86djZvcHMt b3duZXJAaWV0Zi5vcmc+DQoNCldoZW4gcmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlvdXIgU3ViamVj dCBsaW5lIHNvIGl0IGlzIG1vcmUgc3BlY2lmaWMNCnRoYW4gIlJlOiBDb250ZW50cyBvZiB2Nm9w cyBkaWdlc3QuLi4iDQoNClRvZGF5J3MgVG9waWNzOg0KDQogICAxLiBSZTogV29ya2luZyBHcm91 cCBBZG1pbmlzdHJpdmlhIChTaGVuZyBKaWFuZykNCiAgIDIuIFJlOiBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLXY2b3BzLTZ0bzQtdG8taGlzdG9yaWMtMDkudHh0DQogICAgICAoS2VpdGggTW9vcmUp DQogICAzLiBSZTogUE1UVUQgZm9yZXZlciwgd2FzOiBNVFVzIG9uIHRoZSBnZW5lcmFsIEludGVy bmV0DQogICAgICAoVGVtcGxpbiwgRnJlZCBMKQ0KICAgNC4gUmU6IEktRCBBY3Rpb246IGRyYWZ0 LWlldGYtdjZvcHMtNnRvNC10by1oaXN0b3JpYy0wOS50eHQNCiAgICAgIChCcmlhbiBFIENhcnBl bnRlcikNCg0KDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0NCkZyb206 IFNoZW5nIEppYW5nIDxqaWFuZ3NoZW5nQGh1YXdlaS5jb208bWFpbHRvOmppYW5nc2hlbmdAaHVh d2VpLmNvbT4+DQpUbzogInQucGV0Y2giIDxpZXRmY0BidGNvbm5lY3QuY29tPG1haWx0bzppZXRm Y0BidGNvbm5lY3QuY29tPj4sICJGcmVkIEJha2VyIChmcmVkKSIgPGZyZWRAY2lzY28uY29tPG1h aWx0bzpmcmVkQGNpc2NvLmNvbT4+LCAidjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYu b3JnPiIgPHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4+DQpDYzoNCkRhdGU6 IFRodSwgMTEgRGVjIDIwMTQgMDI6MjQ6MjQgKzAwMDANClN1YmplY3Q6IFJlOiBbdjZvcHNdIFdv cmtpbmcgR3JvdXAgQWRtaW5pc3RyaXZpYQ0KSGksIFRvbSwNCg0KVGhhbmtzIGZvciB5b3VyIG9m ZmVyLg0KDQpSZXZpZXcgYW5kIGNvbW1lbnRzIHdvdWxkIGJlIHZlcnkgaGVscGZ1bCBmb3IgdXMg dG8gaW1wcm92ZS4gRm9sbG93aW5nIHRoZSBsYXRlc3QgZGlzY3Vzc2lvbiwgdGhlcmUgYXJlIHR3 byBhY3Rpb25zIHdlIGFyZSBwbGFubmluZzogQSkgZm9jdXMgb24gdGhlIGltcGxlbWVudGF0aW9u IGRpdmVyZ2VuY2UgcmF0aGVyIHRoYW4gYSBwcm90b2NvbCBkZWZpbml0aW9uIHByb2JsZW0gc3Rh dGVtZW50LiBUaGUgbW9zdCBvZiBjb250ZW50cyBhcmUgYWxyZWFkeSBpbiB0aGUgY3VycmVudCBk b2N1bWVudC4gSXQganVzdCBuZWVkcyBhIGxpdHRsZSBiaXQgcmVvcmdhbml6aW5nIGFuZCByZXdv cmRpbmcuIEIpIHNvbWUgYWRkaXRpb24gaW52ZXN0aWdhdGlvbiBvciBleHBlcmltZW50cywgZS5n LiBib3RoIERIQ1B2NiBhbmQgTkQgaGF2ZSBETlMgY29uZmlndXJhdGlvbi4NCg0KSWYgeW91IGFy ZSBpbnRlcmVzdGVkIHRvIGNvbnRyaWJ1dGUsIHlvdSBhcmUgY2VydGFpbmx5IHdlbGNvbWUuDQoN CkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ RnJvbTogdC5wZXRjaCBbbWFpbHRvOmlldGZjQGJ0Y29ubmVjdC5jb208bWFpbHRvOmlldGZjQGJ0 Y29ubmVjdC5jb20+XQ0KPlNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAxMSwgMjAxNCAxOjM5IEFN DQo+VG86IFNoZW5nIEppYW5nOyBGcmVkIEJha2VyIChmcmVkKTsgdjZvcHNAaWV0Zi5vcmc8bWFp bHRvOnY2b3BzQGlldGYub3JnPg0KPlN1YmplY3Q6IFJlOiBbdjZvcHNdIFdvcmtpbmcgR3JvdXAg QWRtaW5pc3RyaXZpYQ0KPg0KPlNoZW5nDQo+DQo+SWYgSSByZWFkIHRoZSBlLW1haWwgYWRkcmVz c2VzIGFyaWdodCwgeW91IGFyZSB0aGUgZWRpdG9yIG9mDQo+ZHJhZnQtaWV0Zi12Nm9wcy1kaGNw djYtc2xhYWMtcHJvYmxlbQ0KPldoYXQgZG8geW91IHdhbnQgKHRoYXQgSSBtaWdodCBiZSBhYmxl IHRvIGRvKSBib2ZvcmUgdGhpcyBpcyByZWFkeSBmb3INCj5XRyBMYXN0IENhbGw/DQo+DQo+VG9t IFBldGNoDQo+DQo+DQo+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPkZyb206ICJTaGVu ZyBKaWFuZyIgPGppYW5nc2hlbmdAaHVhd2VpLmNvbTxtYWlsdG86amlhbmdzaGVuZ0BodWF3ZWku Y29tPj4NCj5UbzogInQucGV0Y2giIDxpZXRmY0BidGNvbm5lY3QuY29tPG1haWx0bzppZXRmY0Bi dGNvbm5lY3QuY29tPj47ICJGcmVkIEJha2VyIChmcmVkKSINCj48ZnJlZEBjaXNjby5jb208bWFp bHRvOmZyZWRAY2lzY28uY29tPj47IDx2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5v cmc+Pg0KPlNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMDgsIDIwMTQgMjoxOCBBTQ0KPlN1YmplY3Q6 IFJFOiBbdjZvcHNdIFdvcmtpbmcgR3JvdXAgQWRtaW5pc3RyaXZpYQ0KPg0KPg0KPj4gPkFzIEJy aWFuIHNheXMgaW4gaGlzIG5vdGUsDQo+PiA+DQo+PiA+MjAxNC0xMC0yNyAgICAgICAgICAgZHJh ZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbQ0KPj4NCj4+aHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtLw0K Pj4gPg0KPj4gPmFkZHJlc3NlcyBhIGtub3duIHByb2JsZW0gYW5kIEkgdGhpbmsgaXQgd291bGQg YmUgcmVtaXNzIG9mIHRoZSBJRVRGDQo+bm90DQo+PiA+dG8gaGF2ZSB0aGlzIGRvY3VtZW50ZWQN Cj4+DQo+PiBGdWxseSBhZ3JlZWQuIE15IHJlYWQgZnJvbSB0aGUgbGF0ZXN0IG1lZXRpbmcgcmVz cG9uc2UgaXMgdGhlIHByb2JsZW0NCj5zaG91bGQgYmUgZG9jdW1lbnQgYW5kIGtub3cgYnkgb3Bl cmF0b3JzIGFuZCBpbXBsZW1lbnRvcnMuIFRoZQ0KPmNvbnRyb3ZlcnNpYWwgcGFydCBpcyBub3Qg dGhpcyBkcmFmdCwgYnV0IHRoZSBmb2xsb3cgdXAgb2YgdGhpcyBkcmFmdDoNCj4+DQo+PiAxKSBU aGUgc29sdXRpb24gKHByb3RvY29sIGxldmVsKSBpcyBub3QgYmVsb25nIHRvIHY2b3BzIFdHLg0K Pj4NCj4+IDIpIFRoZSByZWFsIGRlYmF0ZSBpcyBXaGV0aGVyIHY2b3BzIHNob3VsZCBwcm9kdWNl IGFuIG9wZXJhdGlvbmFsDQo+Z3VpZGVsaW5lcyBmb3Igb3BlcmF0b3JzIHRvIGF2b2lkIHRoaXMg aXNzdWUuIFBlcnNvbmFsbHksIEkgdGhpbmsgaXQgaXMNCj5oZWxwZnVsIGFuZCBiZWxvbmcgdG8g dGhpcyBXRywgYnV0IGl0IHNlZW1zIHRoZSBXRyBkb2VzIG5vdCByZWFjaA0KPmNvbnNlbnN1cyBv biB0aGlzLg0KPj4NCj4+IEJlc3QgcmVnYXJkcywNCj4+DQo+PiBTaGVuZw0KPj4NCj4+ID5Ub20g UGV0Y2gNCj4+ID4NCj4+ID4NCj4+ID4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+PiA+ RnJvbTogIkZyZWQgQmFrZXIgKGZyZWQpIiA8ZnJlZEBjaXNjby5jb208bWFpbHRvOmZyZWRAY2lz Y28uY29tPj4NCj4+ID5UbzogPHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4+ DQo+PiA+U2VudDogRnJpZGF5LCBEZWNlbWJlciAwNSwgMjAxNCA2OjE3IFBNDQo+PiA+U3ViamVj dDogW3Y2b3BzXSBXb3JraW5nIEdyb3VwIEFkbWluaXN0cml2aWENCj4+ID4NCj4+ID4NCj4+ID5K b2VsLCBMZWUsIGFuZCBJIHNwb2tlIHRoaXMgbW9ybmluZyBhYm91dCB0aGUgc3RhdHVzIG9mIHRo ZSB3b3JraW5nDQo+PiA+Z3JvdXAgYW5kIHZhcmlvdXMgZHJhZnRzIGluIGl0LiBJ4oCZZCBsaWtl IHRvIGdhdWdlIHdvcmtpbmcgZ3JvdXANCj4+ID5jb25zZW5zdXMgb24gdGhlIHN0YXR1cyBvZiBh IG51bWJlciBvZiB3b3JraW5nIGdyb3VwIGRyYWZ0cyB0aGF0IGhhdmUNCj4+ID5laXRoZXIgZXhw aXJlZCBvciBvdGhlcndpc2Ugc2hvdWxkIG5vIGxvbmdlciBiZSBjb25zaWRlcmVkIHdvcmtpbmcN Cj5ncm91cA0KPj4gPmRyYWZ0cy4gWW91ciBvcGluaW9ucywgcHJvIG9yIGNvbiAoc3VjaCBhcyDi gJxJ4oCZbSBmaW5lIHdpdGggYWxsIHRoYXQNCj5idXQNCj4+ID50aGluayB3ZSBzaG91bGQgc3Rp bGwgYmUgY29uc2lkZXJpbmcgZHJhZnQtd2hhdGV2ZXLigJ0pLCBwbGVhc2U6DQo+PiA+DQo+PiA+ V2UgdGhpbmsgdGhhdCB0aGUgZm9sbG93aW5nIGNhbiBiZSBzYWZlbHkgc2V0IGFzaWRlLCBieSBo YXZpbmcgdGhlDQo+PiA+c2VjcmV0YXJpYXQgcmVjb3JkIChhbmQgc2hvdyBpbiB0aGUgZGF0YSB0 cmFja2VyKSB0aGF0IHRoZXkgYXJlIG5vDQo+PiA+bG9uZ2VyIHdvcmtpbmcgZ3JvdXAgZHJhZnRz LiBUaGV5IGhhdmUgZXhwaXJlZCwgYW5kIGFyZSBub3QgY3VycmVudGx5DQo+PiA+YmVpbmcgcHVy c3VlZDoNCj4+ID4NCj4+ID4yMDAzLTAxLTEzICAgICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0 Zi12Nm9wcy1pcHY0c3VydmV5DQo+PiA+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLXY2b3BzLWlwdjRzdXJ2ZXkvDQo+PiA+MjAwMy0wMi0xNCAgICAgICAgICAgICAg ICAgZHJhZnQtaWV0Zi12Nm9wcy1pcHY0c3VydmV5LWdlbg0KPj4gPmh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy1pcHY0c3VydmV5LWdlbi8NCj4+ID4yMDA0 LTA3LTIwICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi12Nm9wcy12Nm9uYnlkZWZhdWx0DQo+ PiA+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLXY2b25i eWRlZmF1bHQvDQo+PiA+MjAwNy0wMi0yNyAgICAgICAgICAgICBkcmFmdC1pZXRmLXY2b3BzLXJv dXRpbmctZ3VpZGVsaW5lcw0KPj4gPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi12Nm9wcy1yb3V0aW5nLWd1aWRlbGluZXMvDQo+PiA+MjAwNy0wMy0yOCAgICAgICAg ICAgICAgZHJhZnQtaWV0Zi12Nm9wcy1jYW1wdXMtdHJhbnNpdGlvbg0KPj4gPmh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy1jYW1wdXMtdHJhbnNpdGlvbi8N Cj4+ID4yMDA4LTA1LTEzICAgICAgICAgZHJhZnQtaWV0Zi12Nm9wcy1uYXQ2NC1wYi1zdGF0ZW1l bnQtcmVxDQo+Pg0KPj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt djZvcHMtbmF0NjQtcGItc3RhdGVtZW50LXJlcQ0KPi8NCj4+ID4yMDExLTA3LTI2ICAgICAgICAg ICAgIGRyYWZ0LWlldGYtdjZvcHMtdjR2NnRyYW4tZnJhbWV3b3JrDQo+PiA+aHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLXY0djZ0cmFuLWZyYW1ld29yay8N Cj4+ID4yMDEzLTA4LTE0ICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtdjZvcHMtbW9uaXRvci1k cy1pcHY2DQo+PiA+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2 b3BzLW1vbml0b3ItZHMtaXB2Ni8NCj4+ID4NCj4+ID5XZSB0aGluayB0aGF0IGRyYWZ0LWlldGYt djZvcHMtYmFsYW5jZWQtaXB2Ni1zZWN1cml0eSwgaW4gaXRzIGN1cnJlbnQNCj4+ID5zdGF0ZSwg aXMgYSBkZXBsb3ltZW50IHJlcG9ydCwgcHJpbWFyaWx5IGZyb20gU3dpc3Njb20uIFdoaWxlIHRo ZQ0KPj4gPndvcmtpbmcgZ3JvdXAgZXhwcmVzc2VkIGludGVyZXN0IGluIGd1aWRhbmNlIG9uIGZp cmV3YWxsDQo+Y29uZmlndXJhdGlvbiwNCj4+ID50aGlzIGlzbuKAmXQgaXQuIFdlIHRoaW5rIGl0 IHNob3VsZCBubyBsb25nZXIgYmUgYSB3b3JraW5nIGdyb3VwIGRyYWZ0LA0KPj4gPmFuZCBpbnZp dGUgdGhlIGF1dGhvcnMgdG8gc3VibWl0IGl0IHRvIHRoZSBpbmRlcGVuZGVudCBzdHJlYW0gYXMg YQ0KPj4gPmRlcGxveW1lbnQgcmVwb3J0ICg8cmZjLWlzZUByZmMtZWRpdG9yLm9yZzxtYWlsdG86 cmZjLWlzZUByZmMtZWRpdG9yLm9yZz4pLg0KPj4gPg0KPj4gPjIwMTMtMTItMDYgICAgICAgICBk cmFmdC1pZXRmLXY2b3BzLWJhbGFuY2VkLWlwdjYtc2VjdXJpdHkNCj4+DQo+Pmh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy1iYWxhbmNlZC1pcHY2LXNlY3Vy aXR5DQo+Lw0KPj4gPg0KPj4gPkFsdGhvdWdoIHRoZSB3b3JraW5nIGdyb3VwIGV4cHJlc3NlZCBp bnRlcmVzdCBpbiB0aGUgZm9sbG93aW5nIGFuZA0KPnRoZQ0KPj4gPmF1dGhvcnMgaGF2ZSBiZWVu IHdvcmtpbmcgaGFyZCBvbiB0aGVtLCB3ZSB0aGluayB0aGUgd29ya2luZyBncm91cCBpcw0KPm5v DQo+PiA+bG9uZ2VyIGludGVyZXN0ZWQgaW4gdGhlc2UsIGFuZCBzbyB0aGV5IHNob3VsZCBiZSBy ZXR1cm5lZCB0byB0aGUNCj4+ID5hdXRob3JzIGFuZCBub3QgcmVjb3JkZWQgb3IgdHJlYXRlZCBh cyB3b3JraW5nIGdyb3VwIGRyYWZ0cy4NCj4+ID4NCj4+ID4yMDE0LTA5LTE4ICAgICAgICAgICAg ICAgICBkcmFmdC1pZXRmLXY2b3BzLWRlc2lnbi1jaG9pY2VzDQo+PiA+aHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLWRlc2lnbi1jaG9pY2VzLw0KPj4gPjIw MTQtMTAtMjcgICAgICAgICAgIGRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW0N Cj4+DQo+Pmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy1k aGNwdjYtc2xhYWMtcHJvYmxlbS8NCj4+ID4yMDE0LTEwLTI3ICAgICAgZHJhZnQtaWV0Zi12Nm9w cy11bGEtdXNhZ2UtcmVjb21tZW5kYXRpb25zDQo+Pg0KPj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtdWxhLXVzYWdlLXJlY29tbWVuZGF0aQ0KPm8NCj4+ ID5ucy8NCj4+ID4NCj4+ID5TcGVha2luZyBmb3IgbXlzZWxmLCBpZiBJIGhhdmUgYW55IHF1ZXN0 aW9uIG9mIHRoZSBhYm92ZSwgaXQgaXMgb24NCj5vbmx5DQo+PiA+b25lIG9mIHRoZXNlLg0KPj4g Pg0KPj4gPklmIGFueSBkcmFmdCBoYXMgaXRzICJXRyBEcmFmdCIgc3RhdHVzIHJldm9rZWQsIGl0 IHdpbGwgc3RpbGwgYmUNCj4+ID5hdmFpbGFibGUgZnJvbSB0aGUgSUVURiB3ZWJzaXRlIGFzIGZh ciBhcyBJIGtub3csIGJ1dCBzdWJzZXF1ZW50DQo+PiA+cmV2aXNpb25zIHNob3VsZCBiZSBuYW1l ZCBhcyBpbmRpdmlkdWFsIHN1Ym1pc3Npb25zIHRvIGEgd29ya2luZw0KPmdyb3VwLA0KPj4gPmRy YWZ0LTxhdXRob3I+LTx3Zz4tPHN1YmplY3Q+IG9yIGluZGl2aWR1YWwgc3VibWlzc2lvbnMgdG8g dGhlIElFVEYsDQo+PiA+ZHJhZnQtPGF1dGhvcj4tPHN1YmplY3Q+LiBJdCB3b3VsZCBiZSBnb29k IGlmIHRoZSBhdXRob3JzIHdvdWxkIHNlbmQNCj5hDQo+PiA+bm90ZSB0byBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gaW5kaWNhdGluZyB0 aGF0IHRoZSBvbGQgZHJhZnQgbmFtZQ0KPndlcmUNCj4+ID5yZXBsYWNlZCBieSB0aGUgbmV3IGRy YWZ0IG5hbWUsIHNvIHRoYXQgdGhlIHJldmlzaW9uIGhpc3RvcnkgaXMNCj50cmFja2VkDQo+PiA+ YXBwcm9wcmlhdGVseS4NCj4+ID4NCj4+ID5PcGluaW9ucz8NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ ID4NCj4+DQo+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+LQ0KPj4gPi0tLS0tLS0tDQo+PiA+DQo+PiA+DQo+ PiA+Pg0KPj4gPj4NCj4+ID4NCj4+ID4NCj4+DQo+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+LQ0KPj4gPi0t LS0tLS0tDQo+PiA+DQo+PiA+DQo+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4gPj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+PiA+PiB2Nm9wc0Bp ZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQo+PiA+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+PiA+Pg0KPj4gPg0KPj4gPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+djZvcHMgbWFpbGluZyBsaXN0 DQo+PiA+djZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KPj4gPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4+DQoNCg0KDQotLS0tLS0tLS0t IEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0NCkZyb206IEtlaXRoIE1vb3JlIDxtb29yZUBu ZXR3b3JrLWhlcmV0aWNzLmNvbTxtYWlsdG86bW9vcmVAbmV0d29yay1oZXJldGljcy5jb20+Pg0K VG86IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCkNjOg0KRGF0ZTogVGh1 LCAxMSBEZWMgMjAxNCAxMDo0Mjo1NCAtMDUwMA0KU3ViamVjdDogUmU6IFt2Nm9wc10gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi12Nm9wcy02dG80LXRvLWhpc3RvcmljLTA5LnR4dA0KTXVtYmxlLiAg SSBzdXBwb3J0IHRoZSBkZXByZWNhdGlvbiBvZiAxOTIuODguOTkuMSBhcyBhIG1lYW5zIHRvIGZp bmQgNnRvNCByZWxheXMuICAgQnV0IHRoaXMgZG9jdW1lbnQgc3RpbGwgY29udGFpbnMgc28gbWFu eSBpbmFjY3VyYXRlIGFuZCBtaXNsZWFkaW5nIHN0YXRlbWVudHMgYmV5b25kIHRoYXQsIGluY2x1 ZGluZyBwZXJoYXBzIHNvbWUgc3RhdGVtZW50cyB0aGF0IHdlcmUgbm90IHByZXNlbnQgaW4gZWFy bGllciB2ZXJzaW9ucyAodGhvdWdoIEkgaGF2ZW4ndCB0YWtlbiB0aGUgdGltZSB0byBjaGVjayB5 ZXQpLCB0aGF0IEkgZG9uJ3QgYmVsaWV2ZSBpdCBzaG91bGQgYmUgcHVibGlzaGVkIGluIGl0cyBj dXJyZW50IGZvcm0uIEFnYWluLCB0aGlzIGlzIGEgZG9jdW1lbnQgcXVhbGl0eSBpc3N1ZSwgbm90 IGFuIGlzc3VlIHdpdGggdGhlIGJhc2ljIHVuZGVybHlpbmcgcmVjb21tZW5kYXRpb24uDQoNCk1v c3Qgb2YgdGhlIHByb2JsZW1zIHdpdGggdGhpcyBkb2N1bWVudCBhcmUgdGhpbmdzIHRoYXQgSSBo YXZlIGFscmVhZHkgbWVudGlvbmVkIGluIGNvbm5lY3Rpb24gd2l0aCBlYXJsaWVyIHZlcnNpb25z IG9mIHRoaXMgZG9jdW1lbnQuDQoNCktlaXRoDQoNCg0KDQoNCi0tLS0tLS0tLS0gRm9yd2FyZGVk IG1lc3NhZ2UgLS0tLS0tLS0tLQ0KRnJvbTogIlRlbXBsaW4sIEZyZWQgTCIgPEZyZWQuTC5UZW1w bGluQGJvZWluZy5jb208bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+Pg0KVG86IEpl cm9lbiBNYXNzYXIgPGplcm9lbkBtYXNzYXIuY2g8bWFpbHRvOmplcm9lbkBtYXNzYXIuY2g+Piwg InN0aGF1Z0BuZXRoZWxwLm5vPG1haWx0bzpzdGhhdWdAbmV0aGVscC5ubz4iIDxzdGhhdWdAbmV0 aGVscC5ubzxtYWlsdG86c3RoYXVnQG5ldGhlbHAubm8+Pg0KQ2M6ICJ2Nm9wc0BpZXRmLm9yZzxt YWlsdG86djZvcHNAaWV0Zi5vcmc+IiA8djZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYu b3JnPj4NCkRhdGU6IFRodSwgMTEgRGVjIDIwMTQgMTY6MTA6NDQgKzAwMDANClN1YmplY3Q6IFJl OiBbdjZvcHNdIFBNVFVEIGZvcmV2ZXIsIHdhczogTVRVcyBvbiB0aGUgZ2VuZXJhbCBJbnRlcm5l dA0KPiBNb3JlIG9uIHdoYXQgSSBzYWlkIHRoZSBvdGhlciBkYXksIHRoZXJlIGFyZSB0d28gbWFn aWMgbnVtYmVycyB0aGF0IHR1bm5lbHMNCj4gbmVlZCB0byBjb25jZXJuIHRoZW1zZWx2ZXMgd2l0 aDogMTI4MCBhbmQgMTUwMC4gQWNjb21tb2RhdGluZyBhbGwgcGFja2V0cw0KPiB3aXRoaW4gdGhh dCBzaXplIHJhbmdlIHdoaWxlIHBsYWNpbmcgbm8gZXhwbGljaXQgdXBwZXIgYm91bmQgZm9yIGFj Y29tbW9kYXRpbmcNCj4gbGFyZ2VyIHBhY2tldHMgaXMgd2hhdCBpcyBiZWluZyBwcm9wb3NlZC4g SW4gb3RoZXIgd29yZHMsIG5vIE1UVSBjbGFtcGluZy4NCg0KSGF2ZSB3ZSByZWFjaGVkIGNvbmNs dXNpb24gb24gdGhpcywgYW5kIGNhbiBpdCBub3cgYmUgY29uc2lkZXJlZCAiY2FzZSBjbG9zZWQi Pw0KDQpSZW1lbWJlciAtICJ0YWtlIGNhcmUgb2YgdGhlIHNtYWxscywgYW5kIGxldCB0aGUgYmln cyB0YWtlIGNhcmUgb2YgdGhlbXNlbHZlcyI6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LXRlbXBsaW4tYWVyb2xpbmsvDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC10ZW1wbGluLWFlcm9taW4vDQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50 ZW1wbGluQGJvZWluZy5jb208bWFpbHRvOmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20+DQoNCg0K DQoNCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQ0KRnJvbTogQnJpYW4g RSBDYXJwZW50ZXIgPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbTxtYWlsdG86YnJpYW4uZS5j YXJwZW50ZXJAZ21haWwuY29tPj4NClRvOiBLZWl0aCBNb29yZSA8bW9vcmVAbmV0d29yay1oZXJl dGljcy5jb208bWFpbHRvOm1vb3JlQG5ldHdvcmstaGVyZXRpY3MuY29tPj4NCkNjOiB2Nm9wc0Bp ZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQpEYXRlOiBGcmksIDEyIERlYyAyMDE0IDA4 OjIzOjEyICsxMzAwDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRm LXY2b3BzLTZ0bzQtdG8taGlzdG9yaWMtMDkudHh0DQpLZWl0aCwgcGxlYXNlLCB5b3UgbmVlZCB0 byBiZSBzcGVjaWZpYyBhYm91dCB3aGF0IHlvdSB0aGluayBpcw0KaW5hY2N1cmF0ZSBvciBtaXNs ZWFkaW5nLCBsaW5lIGJ5IGxpbmUsIGluIHRoaXMgdmVyc2lvbi4gVGhlcmUncw0Kbm90aGluZyB3 ZSBjYW4gZG8gd2l0aCBhIGdlbmVyYWwgY3JpdGljaXNtIGxpa2UgdGhhdC4NCg0KV2UgaGF2ZSBt YWRlIG51bWVyb3VzIGNoYW5nZXMsIHNvbWUgb2YgdGhlbSBpbiByZXNwb25zZSB0byB5b3VyDQpj b21tZW50cywgYnV0IG9mIGNvdXJzZSBpbiBzb21lIGNhc2VzIHlvdXIgY29tbWVudHMgd2VyZSBh dA0KdmFyaWFuY2Ugd2l0aCBvdGhlciBwZW9wbGVzJyBjb21tZW50cy4gT2YgY291cnNlLCB0aGVy ZSB3ZXJlIGENCmxvdCBvZiBtZXNzYWdlcywgbWFueSBvZiB0aGVtIGNvbXBsZXRlbHkgb3J0aG9n b25hbCB0byB0aGUgdGV4dA0Kb2YgdGhlIGRyYWZ0LCBzbyB3ZSBtYXkgd2VsbCBoYXZlIG1pc3Nl ZCBzb21lIG9mIHRoZSByZWxldmFudCBvbmVzLg0KDQpSZWdhcmRzDQogICBCcmlhbg0KDQpPbiAx Mi8xMi8yMDE0IDA0OjQyLCBLZWl0aCBNb29yZSB3cm90ZToNCj4gTXVtYmxlLiAgSSBzdXBwb3J0 IHRoZSBkZXByZWNhdGlvbiBvZiAxOTIuODguOTkuMSBhcyBhIG1lYW5zIHRvIGZpbmQNCj4gNnRv NCByZWxheXMuICAgQnV0IHRoaXMgZG9jdW1lbnQgc3RpbGwgY29udGFpbnMgc28gbWFueSBpbmFj Y3VyYXRlIGFuZA0KPiBtaXNsZWFkaW5nIHN0YXRlbWVudHMgYmV5b25kIHRoYXQsIGluY2x1ZGlu ZyBwZXJoYXBzIHNvbWUgc3RhdGVtZW50cw0KPiB0aGF0IHdlcmUgbm90IHByZXNlbnQgaW4gZWFy bGllciB2ZXJzaW9ucyAodGhvdWdoIEkgaGF2ZW4ndCB0YWtlbiB0aGUNCj4gdGltZSB0byBjaGVj ayB5ZXQpLCB0aGF0IEkgZG9uJ3QgYmVsaWV2ZSBpdCBzaG91bGQgYmUgcHVibGlzaGVkIGluIGl0 cw0KPiBjdXJyZW50IGZvcm0uIEFnYWluLCB0aGlzIGlzIGEgZG9jdW1lbnQgcXVhbGl0eSBpc3N1 ZSwgbm90IGFuIGlzc3VlIHdpdGgNCj4gdGhlIGJhc2ljIHVuZGVybHlpbmcgcmVjb21tZW5kYXRp b24uDQo+DQo+IE1vc3Qgb2YgdGhlIHByb2JsZW1zIHdpdGggdGhpcyBkb2N1bWVudCBhcmUgdGhp bmdzIHRoYXQgSSBoYXZlIGFscmVhZHkNCj4gbWVudGlvbmVkIGluIGNvbm5lY3Rpb24gd2l0aCBl YXJsaWVyIHZlcnNpb25zIG9mIHRoaXMgZG9jdW1lbnQuDQo+DQo+IEtlaXRoDQo+DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2b3BzIG1haWxp bmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4NCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp2Nm9wcyBtYWlsaW5nIGxp c3QNCnY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0KDQotLQ0KUmVnYXJkcw0KVGFyaXEgU2Fy YWoNCkNlbnRlciBmb3IgUmVzZWFyY2ggaW4gTmV0d29ya3MgYW5kIFRlbGVjb20gKENvUmVOZVQp DQo= --_000_2134F8430051B64F815C691A62D9831832DB6AA1XCHBLV504nwnosb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ29taWMgU2FucyBNUyI7DQoJcGFub3Nl LTE6MyAxNSA3IDIgMyAzIDIgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpIFRhcmlxLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWx0aG91Z2ggdGhlIGRvY3VtZW50IHVz ZXMgdGhlIHRlcm0g4oCcTkJNQeKAnSwgQUVSTyBkb2VzIGluY2x1ZGUgcHJvdmlzaW9uczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5mb3IgbXVsdGljYXN0aW5nOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGVtcGxpbi1hZXJv bGluay8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRlbXBsaW4tYWVy b2xpbmsvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+QUVSTyBjYW4gc2VydmUgYXMgYSByZXBsYWNlbWVudCBmb3Ig Ym90aCA2dG80IGFuZCA2cmQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3Mg4oCTIEZyZWQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdjZvcHMgW21haWx0bzp2Nm9wcy1i b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5UYXJpcSBTYXJhajxicj4NCjxi PlNlbnQ6PC9iPiBTYXR1cmRheSwgRGVjZW1iZXIgMTMsIDIwMTQgMTE6MTggQU08YnI+DQo8Yj5U bzo8L2I+IHY2b3BzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIHY2 b3BzIERpZ2VzdCwgVm9sIDUyLCBJc3N1ZSA0MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBhcmUgc29tZSBpc3N1ZXMgd2l0aCA2cmQg YXMgd2VsbCwgSVB2NiB3aXRoIGFsbCBpdHMgcG93ZXJmdWwgZmVhdHVyZXMgaXMgc3RpbGwgdW5k ZXIgY3JpdGljYWwgb2JqZWN0aW9ucyBpbiBhY2FkZW1pYSBqdXN0IGJlY2F1c2Ugb2YgdGhlIHVy Z2VuY3kgc2hvd24gYnkgSUVURiBpbiBzdGFuZGFyZGl6aW5nIHByb3RvY29scyBsaWtlIDZ0bzQg YW5kIDZyZC4gNnRvNCBjbGVhcmx5IG1lbnRpb25lZCB0aGF0DQogaXQgY2Fubm90IHN1cHBvcnQg bXVsdGljYXN0IGF0IGxheWVyLTMsIG9uIHRoZSBvdGhlciBlbmQgNnJkIGNsYWltZWQgdGhhdCBt dWx0aWNhc3QgY2FuIGJlIHByb3ZpZGVkLCBteSBxdWVzdGlvbiBpcyB0aGF0IHdoaWxlIHN0YW5k YXJkaXppbmcgNnJkIHdoaWNoIGF0IHRoYXQgdGltZSB3YXMganVzdCBzdXBwb3J0aW5nIHVuaWNh c3QgdHJhZmZpYyB0cmF2ZXJzaW5nIGFjcm9zcyBJUHY0IG5ldHdvcmsgYW5kIGl0cyBzdGlsbCBu b3QgbWF0dXJlZA0KIGVub3VnaCB0byBwcm92aWRlIG11bHRpY2FzdCBzdXBwb3J0IHlldCBpbiBp dHMgZnVuY3Rpb25hbGl0eSBvdGhlciB0aGFuIHVzaW5nIHNvbWUgcHJveHkgc3VwcG9ydCBmb3Ig bXVsdGljYXN0IHRyYWZmaWMuIHdoeSBJdCB3YXMgc3RhbmRhcmRpemVkID8gYSBjb21tb24gdW5p dmVyc2l0eSBsZXZlbCBzdHVkZW50IGlzIGNvbnNpZGVyaW5nIElQdjYgbm90aGluZyBtb3JlIHRo YW4ganVzdCBhIGxhcmdlIGFkZHJlc3Mgc3BhY2UuIFRoZSBzdXBwb3J0DQogZm9yIG11bHRpY2Fz dCB0cmFmZmljIGlzIGluY3JlYXNpbmcgZXZlcnkgZGF5IGF0IGFwcGxpY2F0aW9uIGxldmVsLiBN eSByZXF1ZXN0IGF0IHRoaXMgZm9ydW0gaXMgdG8gY29uc2lkZXIgNnJkIGFsb25nIHdpdGggdGhl IDZ0bzQgc28gdGhhdCBpbiBmdXR1cmUgYm90aCBvZiB0aGVzZSBwcm90b2NvbHMgbm90IHRvIGJl Y29tZSBhIHBhcnQgb2YgYW55IG5ldHdvcmsgZGV2aWNlLiBJIHBlcnNvbmFsbHkgZmVlbHMgdGhh dCBpbnN0ZWFkIG9mIHN1cHBvcnRpbmcNCiB0byBwcm9tb3RlIHRoZSBJUHY2IGJvdGggb2YgdGhl c2UgcHJvdG9jb2xzIGFyZSBiZWNvbWluZyBvYnN0YWNsZXMgaW4gdGhpcyByZWdhcmRzLiBJIHBy ZWZlciB1c2luZyBHUkUgb3ZlciB0aGVzZSBhdXRvbWF0aWMgdHVubmVsaW5nIG1lY2hhbmlzbXMg YXQgbGVhc3QgR1JFIHN1cHBvcnRzIG11bHRpY2FzdCBvbiBuZXR3b3JrIGxheWVyIGFuZCBsZXQg dGhlIGFwcGxpY2F0aW9uIHByb2dyYW0gdG8gZGVzaWduIGhpcy9oZXIgYXBwbGljYXRpb24NCiBp biBtb3JlIGRpZmZlcmVudCB3YXlzLiAmbmJzcDsgJm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBEZWMgMTIsIDIwMTQgYXQgMTowMCBB TSwgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wcy1yZXF1ZXN0QGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+djZvcHMtcmVxdWVzdEBpZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+U2VuZCB2Nm9wcyBtYWlsaW5nIGxpc3Qgc3VibWlzc2lvbnMgdG88YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52 Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQo8YnI+DQpUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUg dmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwgdmlzaXQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9w cyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v djZvcHM8L2E+PGJyPg0Kb3IsIHZpYSBlbWFpbCwgc2VuZCBhIG1lc3NhZ2Ugd2l0aCBzdWJqZWN0 IG9yIGJvZHkgJ2hlbHAnIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhy ZWY9Im1haWx0bzp2Nm9wcy1yZXF1ZXN0QGlldGYub3JnIj52Nm9wcy1yZXF1ZXN0QGlldGYub3Jn PC9hPjxicj4NCjxicj4NCllvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlz dCBhdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJtYWlsdG86djZv cHMtb3duZXJAaWV0Zi5vcmciPnY2b3BzLW93bmVyQGlldGYub3JnPC9hPjxicj4NCjxicj4NCldo ZW4gcmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlvdXIgU3ViamVjdCBsaW5lIHNvIGl0IGlzIG1vcmUg c3BlY2lmaWM8YnI+DQp0aGFuICZxdW90O1JlOiBDb250ZW50cyBvZiB2Nm9wcyBkaWdlc3QuLi4m cXVvdDs8YnI+DQo8YnI+DQpUb2RheSdzIFRvcGljczo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 MS4gUmU6IFdvcmtpbmcgR3JvdXAgQWRtaW5pc3RyaXZpYSAoU2hlbmcgSmlhbmcpPGJyPg0KJm5i c3A7ICZuYnNwOzIuIFJlOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLTZ0bzQtdG8taGlz dG9yaWMtMDkudHh0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgKEtlaXRoIE1vb3JlKTxicj4N CiZuYnNwOyAmbmJzcDszLiBSZTogUE1UVUQgZm9yZXZlciwgd2FzOiBNVFVzIG9uIHRoZSBnZW5l cmFsIEludGVybmV0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgKFRlbXBsaW4sIEZyZWQgTCk8 YnI+DQombmJzcDsgJm5ic3A7NC4gUmU6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtNnRv NC10by1oaXN0b3JpYy0wOS50eHQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAoQnJpYW4gRSBD YXJwZW50ZXIpPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAt LS0tLS0tLS0tPGJyPg0KRnJvbTombmJzcDtTaGVuZyBKaWFuZyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmppYW5nc2hlbmdAaHVhd2VpLmNvbSI+amlhbmdzaGVuZ0BodWF3ZWkuY29tPC9hPiZndDs8YnI+ DQpUbzombmJzcDsmcXVvdDt0LnBldGNoJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZmNA YnRjb25uZWN0LmNvbSI+aWV0ZmNAYnRjb25uZWN0LmNvbTwvYT4mZ3Q7LCAmcXVvdDtGcmVkIEJh a2VyIChmcmVkKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZyZWRAY2lzY28uY29tIj5mcmVk QGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmci PnY2b3BzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYu b3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KQ2M6Jm5ic3A7PGJyPg0KRGF0ZTombmJz cDtUaHUsIDExIERlYyAyMDE0IDAyOjI0OjI0ICYjNDM7MDAwMDxicj4NClN1YmplY3Q6Jm5ic3A7 UmU6IFt2Nm9wc10gV29ya2luZyBHcm91cCBBZG1pbmlzdHJpdmlhPGJyPg0KSGksIFRvbSw8YnI+ DQo8YnI+DQpUaGFua3MgZm9yIHlvdXIgb2ZmZXIuPGJyPg0KPGJyPg0KUmV2aWV3IGFuZCBjb21t ZW50cyB3b3VsZCBiZSB2ZXJ5IGhlbHBmdWwgZm9yIHVzIHRvIGltcHJvdmUuIEZvbGxvd2luZyB0 aGUgbGF0ZXN0IGRpc2N1c3Npb24sIHRoZXJlIGFyZSB0d28gYWN0aW9ucyB3ZSBhcmUgcGxhbm5p bmc6IEEpIGZvY3VzIG9uIHRoZSBpbXBsZW1lbnRhdGlvbiBkaXZlcmdlbmNlIHJhdGhlciB0aGFu IGEgcHJvdG9jb2wgZGVmaW5pdGlvbiBwcm9ibGVtIHN0YXRlbWVudC4gVGhlIG1vc3Qgb2YgY29u dGVudHMgYXJlIGFscmVhZHkNCiBpbiB0aGUgY3VycmVudCBkb2N1bWVudC4gSXQganVzdCBuZWVk cyBhIGxpdHRsZSBiaXQgcmVvcmdhbml6aW5nIGFuZCByZXdvcmRpbmcuIEIpIHNvbWUgYWRkaXRp b24gaW52ZXN0aWdhdGlvbiBvciBleHBlcmltZW50cywgZS5nLiBib3RoIERIQ1B2NiBhbmQgTkQg aGF2ZSBETlMgY29uZmlndXJhdGlvbi48YnI+DQo8YnI+DQpJZiB5b3UgYXJlIGludGVyZXN0ZWQg dG8gY29udHJpYnV0ZSwgeW91IGFyZSBjZXJ0YWlubHkgd2VsY29tZS48YnI+DQo8YnI+DQpCZXN0 IHJlZ2FyZHMsPGJyPg0KPGJyPg0KU2hlbmc8YnI+DQo8YnI+DQomZ3Q7LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS08YnI+DQomZ3Q7RnJvbTogdC5wZXRjaCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0 bzppZXRmY0BidGNvbm5lY3QuY29tIj5pZXRmY0BidGNvbm5lY3QuY29tPC9hPl08YnI+DQomZ3Q7 U2VudDogVGh1cnNkYXksIERlY2VtYmVyIDExLCAyMDE0IDE6MzkgQU08YnI+DQomZ3Q7VG86IFNo ZW5nIEppYW5nOyBGcmVkIEJha2VyIChmcmVkKTsgPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYu b3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7U3ViamVjdDogUmU6IFt2Nm9wc10gV29y a2luZyBHcm91cCBBZG1pbmlzdHJpdmlhPGJyPg0KJmd0Ozxicj4NCiZndDtTaGVuZzxicj4NCiZn dDs8YnI+DQomZ3Q7SWYgSSByZWFkIHRoZSBlLW1haWwgYWRkcmVzc2VzIGFyaWdodCwgeW91IGFy ZSB0aGUgZWRpdG9yIG9mPGJyPg0KJmd0O2RyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFjLXBy b2JsZW08YnI+DQomZ3Q7V2hhdCBkbyB5b3Ugd2FudCAodGhhdCBJIG1pZ2h0IGJlIGFibGUgdG8g ZG8pIGJvZm9yZSB0aGlzIGlzIHJlYWR5IGZvcjxicj4NCiZndDtXRyBMYXN0IENhbGw/PGJyPg0K Jmd0Ozxicj4NCiZndDtUb20gUGV0Y2g8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDstLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPGJyPg0KJmd0O0Zyb206ICZxdW90O1NoZW5nIEppYW5n JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86amlhbmdzaGVuZ0BodWF3ZWkuY29tIj5qaWFuZ3No ZW5nQGh1YXdlaS5jb208L2E+Jmd0Ozxicj4NCiZndDtUbzogJnF1b3Q7dC5wZXRjaCZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZjQGJ0Y29ubmVjdC5jb20iPmlldGZjQGJ0Y29ubmVjdC5j b208L2E+Jmd0OzsgJnF1b3Q7RnJlZCBCYWtlciAoZnJlZCkmcXVvdDs8YnI+DQomZ3Q7Jmx0Ozxh IGhyZWY9Im1haWx0bzpmcmVkQGNpc2NvLmNvbSI+ZnJlZEBjaXNjby5jb208L2E+Jmd0OzsgJmx0 OzxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+Jmd0Ozxi cj4NCiZndDtTZW50OiBNb25kYXksIERlY2VtYmVyIDA4LCAyMDE0IDI6MTggQU08YnI+DQomZ3Q7 U3ViamVjdDogUkU6IFt2Nm9wc10gV29ya2luZyBHcm91cCBBZG1pbmlzdHJpdmlhPGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7QXMgQnJpYW4gc2F5cyBpbiBoaXMgbm90ZSw8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OzIwMTQtMTAtMjcmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNs YWFjLXByb2JsZW08YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGEgaHJlZj0iaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9i bGVtLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbS88L2E+PGJyPg0KJmd0OyZndDsgJmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDthZGRyZXNzZXMgYSBrbm93biBwcm9ibGVtIGFuZCBJIHRoaW5r IGl0IHdvdWxkIGJlIHJlbWlzcyBvZiB0aGUgSUVURjxicj4NCiZndDtub3Q8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7dG8gaGF2ZSB0aGlzIGRvY3VtZW50ZWQ8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IEZ1bGx5IGFncmVlZC4gTXkgcmVhZCBmcm9tIHRoZSBsYXRlc3QgbWVldGluZyByZXNwb25zZSBp cyB0aGUgcHJvYmxlbTxicj4NCiZndDtzaG91bGQgYmUgZG9jdW1lbnQgYW5kIGtub3cgYnkgb3Bl cmF0b3JzIGFuZCBpbXBsZW1lbnRvcnMuIFRoZTxicj4NCiZndDtjb250cm92ZXJzaWFsIHBhcnQg aXMgbm90IHRoaXMgZHJhZnQsIGJ1dCB0aGUgZm9sbG93IHVwIG9mIHRoaXMgZHJhZnQ6PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAxKSBUaGUgc29sdXRpb24gKHByb3RvY29sIGxldmVsKSBp cyBub3QgYmVsb25nIHRvIHY2b3BzIFdHLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgMikg VGhlIHJlYWwgZGViYXRlIGlzIFdoZXRoZXIgdjZvcHMgc2hvdWxkIHByb2R1Y2UgYW4gb3BlcmF0 aW9uYWw8YnI+DQomZ3Q7Z3VpZGVsaW5lcyBmb3Igb3BlcmF0b3JzIHRvIGF2b2lkIHRoaXMgaXNz dWUuIFBlcnNvbmFsbHksIEkgdGhpbmsgaXQgaXM8YnI+DQomZ3Q7aGVscGZ1bCBhbmQgYmVsb25n IHRvIHRoaXMgV0csIGJ1dCBpdCBzZWVtcyB0aGUgV0cgZG9lcyBub3QgcmVhY2g8YnI+DQomZ3Q7 Y29uc2Vuc3VzIG9uIHRoaXMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBCZXN0IHJlZ2Fy ZHMsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBTaGVuZzxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0O1RvbSBQZXRjaDxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0Oy0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08YnI+DQom Z3Q7Jmd0OyAmZ3Q7RnJvbTogJnF1b3Q7RnJlZCBCYWtlciAoZnJlZCkmcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpmcmVkQGNpc2NvLmNvbSI+ZnJlZEBjaXNjby5jb208L2E+Jmd0Ozxicj4NCiZn dDsmZ3Q7ICZndDtUbzogJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDtTZW50OiBGcmlkYXksIERlY2VtYmVy IDA1LCAyMDE0IDY6MTcgUE08YnI+DQomZ3Q7Jmd0OyAmZ3Q7U3ViamVjdDogW3Y2b3BzXSBXb3Jr aW5nIEdyb3VwIEFkbWluaXN0cml2aWE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDtKb2VsLCBMZWUsIGFuZCBJIHNwb2tlIHRoaXMgbW9ybmlu ZyBhYm91dCB0aGUgc3RhdHVzIG9mIHRoZSB3b3JraW5nPGJyPg0KJmd0OyZndDsgJmd0O2dyb3Vw IGFuZCB2YXJpb3VzIGRyYWZ0cyBpbiBpdC4gSeKAmWQgbGlrZSB0byBnYXVnZSB3b3JraW5nIGdy b3VwPGJyPg0KJmd0OyZndDsgJmd0O2NvbnNlbnN1cyBvbiB0aGUgc3RhdHVzIG9mIGEgbnVtYmVy IG9mIHdvcmtpbmcgZ3JvdXAgZHJhZnRzIHRoYXQgaGF2ZTxicj4NCiZndDsmZ3Q7ICZndDtlaXRo ZXIgZXhwaXJlZCBvciBvdGhlcndpc2Ugc2hvdWxkIG5vIGxvbmdlciBiZSBjb25zaWRlcmVkIHdv cmtpbmc8YnI+DQomZ3Q7Z3JvdXA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ZHJhZnRzLiBZb3VyIG9waW5p b25zLCBwcm8gb3IgY29uIChzdWNoIGFzIOKAnEnigJltIGZpbmUgd2l0aCBhbGwgdGhhdDxicj4N CiZndDtidXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7dGhpbmsgd2Ugc2hvdWxkIHN0aWxsIGJlIGNvbnNp ZGVyaW5nIGRyYWZ0LXdoYXRldmVy4oCdKSwgcGxlYXNlOjxicj4NCiZndDsmZ3Q7ICZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7V2UgdGhpbmsgdGhhdCB0aGUgZm9sbG93aW5nIGNhbiBiZSBzYWZlbHkg c2V0IGFzaWRlLCBieSBoYXZpbmcgdGhlPGJyPg0KJmd0OyZndDsgJmd0O3NlY3JldGFyaWF0IHJl Y29yZCAoYW5kIHNob3cgaW4gdGhlIGRhdGEgdHJhY2tlcikgdGhhdCB0aGV5IGFyZSBubzxicj4N CiZndDsmZ3Q7ICZndDtsb25nZXIgd29ya2luZyBncm91cCBkcmFmdHMuIFRoZXkgaGF2ZSBleHBp cmVkLCBhbmQgYXJlIG5vdCBjdXJyZW50bHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7YmVpbmcgcHVyc3Vl ZDo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OzIwMDMtMDEtMTMmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ZHJhZnQtaWV0Zi12Nm9wcy1pcHY0c3VydmV5PGJyPg0KJmd0OyZndDsgJmd0 OzxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9w cy1pcHY0c3VydmV5LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy1pcHY0c3VydmV5LzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 MjAwMy0wMi0xNCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ZHJhZnQtaWV0Zi12Nm9wcy1pcHY0c3VydmV5LWdlbjxicj4NCiZndDsm Z3Q7ICZndDs8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtdjZvcHMtaXB2NHN1cnZleS1nZW4vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLWlwdjRzdXJ2ZXktZ2VuLzwvYT48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7MjAwNC0wNy0yMCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRyYWZ0LWlldGYtdjZvcHMtdjZvbmJ5ZGVm YXVsdDxicj4NCiZndDsmZ3Q7ICZndDs8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtdjZvbmJ5ZGVmYXVsdC8iIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtdjZvbmJ5ZGVm YXVsdC88L2E+PGJyPg0KJmd0OyZndDsgJmd0OzIwMDctMDItMjcmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1pZXRmLXY2b3BzLXJvdXRpbmctZ3Vp ZGVsaW5lczxicj4NCiZndDsmZ3Q7ICZndDs8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtcm91dGluZy1ndWlkZWxpbmVzLyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy1y b3V0aW5nLWd1aWRlbGluZXMvPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsyMDA3LTAzLTI4Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRyYWZ0LWlldGYtdjZv cHMtY2FtcHVzLXRyYW5zaXRpb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGEgaHJlZj0iaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLWNhbXB1cy10cmFuc2l0aW9u LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi12Nm9wcy1jYW1wdXMtdHJhbnNpdGlvbi88L2E+PGJyPg0KJmd0OyZndDsgJmd0OzIwMDgt MDUtMTMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtaWV0Zi12Nm9wcy1u YXQ2NC1wYi1zdGF0ZW1lbnQtcmVxPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OzxhIGhyZWY9 Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy1uYXQ2NC1w Yi1zdGF0ZW1lbnQtcmVxIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLW5hdDY0LXBiLXN0YXRlbWVudC1yZXE8L2E+PGJyPg0K Jmd0Oy88YnI+DQomZ3Q7Jmd0OyAmZ3Q7MjAxMS0wNy0yNiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LWlldGYtdjZvcHMtdjR2NnRyYW4tZnJhbWV3 b3JrPGJyPg0KJmd0OyZndDsgJmd0OzxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy12NHY2dHJhbi1mcmFtZXdvcmsvIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLXY0djZ0 cmFuLWZyYW1ld29yay88L2E+PGJyPg0KJmd0OyZndDsgJmd0OzIwMTMtMDgtMTQmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRyYWZ0LWlldGYt djZvcHMtbW9uaXRvci1kcy1pcHY2PGJyPg0KJmd0OyZndDsgJmd0OzxhIGhyZWY9Imh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy1tb25pdG9yLWRzLWlwdjYv IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLXY2b3BzLW1vbml0b3ItZHMtaXB2Ni88L2E+PGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZn dDsmZ3Q7ICZndDtXZSB0aGluayB0aGF0IGRyYWZ0LWlldGYtdjZvcHMtYmFsYW5jZWQtaXB2Ni1z ZWN1cml0eSwgaW4gaXRzIGN1cnJlbnQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7c3RhdGUsIGlzIGEgZGVw bG95bWVudCByZXBvcnQsIHByaW1hcmlseSBmcm9tIFN3aXNzY29tLiBXaGlsZSB0aGU8YnI+DQom Z3Q7Jmd0OyAmZ3Q7d29ya2luZyBncm91cCBleHByZXNzZWQgaW50ZXJlc3QgaW4gZ3VpZGFuY2Ug b24gZmlyZXdhbGw8YnI+DQomZ3Q7Y29uZmlndXJhdGlvbiw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7dGhp cyBpc27igJl0IGl0LiBXZSB0aGluayBpdCBzaG91bGQgbm8gbG9uZ2VyIGJlIGEgd29ya2luZyBn cm91cCBkcmFmdCw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7YW5kIGludml0ZSB0aGUgYXV0aG9ycyB0byBz dWJtaXQgaXQgdG8gdGhlIGluZGVwZW5kZW50IHN0cmVhbSBhcyBhPGJyPg0KJmd0OyZndDsgJmd0 O2RlcGxveW1lbnQgcmVwb3J0ICgmbHQ7PGEgaHJlZj0ibWFpbHRvOnJmYy1pc2VAcmZjLWVkaXRv ci5vcmciPnJmYy1pc2VAcmZjLWVkaXRvci5vcmc8L2E+KS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OzIwMTMtMTItMDYmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ZHJhZnQtaWV0Zi12Nm9wcy1iYWxhbmNlZC1pcHY2LXNlY3VyaXR5PGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OzxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi12Nm9wcy1iYWxhbmNlZC1pcHY2LXNlY3VyaXR5IiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLWJhbGFuY2VkLWlw djYtc2VjdXJpdHk8L2E+PGJyPg0KJmd0Oy88YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0O0FsdGhvdWdoIHRoZSB3b3JraW5nIGdyb3VwIGV4cHJlc3NlZCBpbnRlcmVzdCBpbiB0 aGUgZm9sbG93aW5nIGFuZDxicj4NCiZndDt0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7YXV0aG9ycyBo YXZlIGJlZW4gd29ya2luZyBoYXJkIG9uIHRoZW0sIHdlIHRoaW5rIHRoZSB3b3JraW5nIGdyb3Vw IGlzPGJyPg0KJmd0O25vPGJyPg0KJmd0OyZndDsgJmd0O2xvbmdlciBpbnRlcmVzdGVkIGluIHRo ZXNlLCBhbmQgc28gdGhleSBzaG91bGQgYmUgcmV0dXJuZWQgdG8gdGhlPGJyPg0KJmd0OyZndDsg Jmd0O2F1dGhvcnMgYW5kIG5vdCByZWNvcmRlZCBvciB0cmVhdGVkIGFzIHdvcmtpbmcgZ3JvdXAg ZHJhZnRzLjxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7MjAxNC0wOS0xOCZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ZHJhZnQtaWV0Zi12Nm9wcy1kZXNpZ24tY2hvaWNlczxicj4NCiZndDsmZ3Q7ICZndDs8YSBo cmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtZGVz aWduLWNob2ljZXMvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLXY2b3BzLWRlc2lnbi1jaG9pY2VzLzwvYT48YnI+DQomZ3Q7Jmd0OyAm Z3Q7MjAxNC0xMC0yNyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJh ZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDs8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt djZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW0vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVt LzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7MjAxNC0xMC0yNyZuYnNwOyAmbmJzcDsgJm5ic3A7IGRy YWZ0LWlldGYtdjZvcHMtdWxhLXVzYWdlLXJlY29tbWVuZGF0aW9uczxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDs8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtdjZvcHMtdWxhLXVzYWdlLXJlY29tbWVuZGF0aSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy11bGEtdXNhZ2UtcmVj b21tZW5kYXRpPC9hPjxicj4NCiZndDtvPGJyPg0KJmd0OyZndDsgJmd0O25zLzxicj4NCiZndDsm Z3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7U3BlYWtpbmcgZm9yIG15c2VsZiwgaWYgSSBoYXZl IGFueSBxdWVzdGlvbiBvZiB0aGUgYWJvdmUsIGl0IGlzIG9uPGJyPg0KJmd0O29ubHk8YnI+DQom Z3Q7Jmd0OyAmZ3Q7b25lIG9mIHRoZXNlLjxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7SWYgYW55IGRyYWZ0IGhhcyBpdHMgJnF1b3Q7V0cgRHJhZnQmcXVvdDsgc3RhdHVzIHJl dm9rZWQsIGl0IHdpbGwgc3RpbGwgYmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7YXZhaWxhYmxlIGZyb20g dGhlIElFVEYgd2Vic2l0ZSBhcyBmYXIgYXMgSSBrbm93LCBidXQgc3Vic2VxdWVudDxicj4NCiZn dDsmZ3Q7ICZndDtyZXZpc2lvbnMgc2hvdWxkIGJlIG5hbWVkIGFzIGluZGl2aWR1YWwgc3VibWlz c2lvbnMgdG8gYSB3b3JraW5nPGJyPg0KJmd0O2dyb3VwLDxicj4NCiZndDsmZ3Q7ICZndDtkcmFm dC0mbHQ7YXV0aG9yJmd0Oy0mbHQ7d2cmZ3Q7LSZsdDtzdWJqZWN0Jmd0OyBvciBpbmRpdmlkdWFs IHN1Ym1pc3Npb25zIHRvIHRoZSBJRVRGLDxicj4NCiZndDsmZ3Q7ICZndDtkcmFmdC0mbHQ7YXV0 aG9yJmd0Oy0mbHQ7c3ViamVjdCZndDsuIEl0IHdvdWxkIGJlIGdvb2QgaWYgdGhlIGF1dGhvcnMg d291bGQgc2VuZDxicj4NCiZndDthPGJyPg0KJmd0OyZndDsgJmd0O25vdGUgdG8gPGEgaHJlZj0i bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn PC9hPiBpbmRpY2F0aW5nIHRoYXQgdGhlIG9sZCBkcmFmdCBuYW1lPGJyPg0KJmd0O3dlcmU8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7cmVwbGFjZWQgYnkgdGhlIG5ldyBkcmFmdCBuYW1lLCBzbyB0aGF0IHRo ZSByZXZpc2lvbiBoaXN0b3J5IGlzPGJyPg0KJmd0O3RyYWNrZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 YXBwcm9wcmlhdGVseS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0O09waW5p b25zPzxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+DQomZ3Q7LTxicj4NCiZndDsmZ3Q7ICZndDstLS0tLS0tLTxicj4NCiZndDsm Z3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0Oy08YnI+DQom Z3Q7Jmd0OyAmZ3Q7LS0tLS0tLS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgdjZvcHMgbWFpbGluZyBsaXN0 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52 Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyAmZ3Q7 djZvcHMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsgJmd0OzxhIGhyZWY9Im1haWx0bzp2Nm9w c0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0OzxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxicj4N CiZndDsmZ3Q7PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVz c2FnZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTombmJzcDtLZWl0aCBNb29yZSAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1vb3JlQG5ldHdvcmstaGVyZXRpY3MuY29tIj5tb29yZUBuZXR3b3JrLWhlcmV0aWNz LmNvbTwvYT4mZ3Q7PGJyPg0KVG86Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3Jn Ij52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQpDYzombmJzcDs8YnI+DQpEYXRlOiZuYnNwO1RodSwg MTEgRGVjIDIwMTQgMTA6NDI6NTQgLTA1MDA8YnI+DQpTdWJqZWN0OiZuYnNwO1JlOiBbdjZvcHNd IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtNnRvNC10by1oaXN0b3JpYy0wOS50eHQ8YnI+ DQpNdW1ibGUuJm5ic3A7IEkgc3VwcG9ydCB0aGUgZGVwcmVjYXRpb24gb2YgMTkyLjg4Ljk5LjEg YXMgYSBtZWFucyB0byBmaW5kIDZ0bzQgcmVsYXlzLiZuYnNwOyAmbmJzcDtCdXQgdGhpcyBkb2N1 bWVudCBzdGlsbCBjb250YWlucyBzbyBtYW55IGluYWNjdXJhdGUgYW5kIG1pc2xlYWRpbmcgc3Rh dGVtZW50cyBiZXlvbmQgdGhhdCwgaW5jbHVkaW5nIHBlcmhhcHMgc29tZSBzdGF0ZW1lbnRzIHRo YXQgd2VyZSBub3QgcHJlc2VudCBpbiBlYXJsaWVyIHZlcnNpb25zICh0aG91Z2gNCiBJIGhhdmVu J3QgdGFrZW4gdGhlIHRpbWUgdG8gY2hlY2sgeWV0KSwgdGhhdCBJIGRvbid0IGJlbGlldmUgaXQg c2hvdWxkIGJlIHB1Ymxpc2hlZCBpbiBpdHMgY3VycmVudCBmb3JtLiBBZ2FpbiwgdGhpcyBpcyBh IGRvY3VtZW50IHF1YWxpdHkgaXNzdWUsIG5vdCBhbiBpc3N1ZSB3aXRoIHRoZSBiYXNpYyB1bmRl cmx5aW5nIHJlY29tbWVuZGF0aW9uLjxicj4NCjxicj4NCk1vc3Qgb2YgdGhlIHByb2JsZW1zIHdp dGggdGhpcyBkb2N1bWVudCBhcmUgdGhpbmdzIHRoYXQgSSBoYXZlIGFscmVhZHkgbWVudGlvbmVk IGluIGNvbm5lY3Rpb24gd2l0aCBlYXJsaWVyIHZlcnNpb25zIG9mIHRoaXMgZG9jdW1lbnQuPGJy Pg0KPGJyPg0KS2VpdGg8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLS0tLS0tLS0tIEZv cndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS08YnI+DQpGcm9tOiZuYnNwOyZxdW90O1RlbXBsaW4s IEZyZWQgTCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5j b20iPkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208L2E+Jmd0Ozxicj4NClRvOiZuYnNwO0plcm9l biBNYXNzYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqZXJvZW5AbWFzc2FyLmNoIj5qZXJvZW5AbWFz c2FyLmNoPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpzdGhhdWdAbmV0aGVscC5ubyI+ c3RoYXVnQG5ldGhlbHAubm88L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3RoYXVnQG5l dGhlbHAubm8iPnN0aGF1Z0BuZXRoZWxwLm5vPC9hPiZndDs8YnI+DQpDYzombmJzcDsmcXVvdDs8 YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KRGF0ZTombmJzcDtUaHUsIDExIERlYyAyMDE0IDE2OjEwOjQ0ICYjNDM7MDAwMDxicj4N ClN1YmplY3Q6Jm5ic3A7UmU6IFt2Nm9wc10gUE1UVUQgZm9yZXZlciwgd2FzOiBNVFVzIG9uIHRo ZSBnZW5lcmFsIEludGVybmV0PGJyPg0KJmd0OyBNb3JlIG9uIHdoYXQgSSBzYWlkIHRoZSBvdGhl ciBkYXksIHRoZXJlIGFyZSB0d28gbWFnaWMgbnVtYmVycyB0aGF0IHR1bm5lbHM8YnI+DQomZ3Q7 IG5lZWQgdG8gY29uY2VybiB0aGVtc2VsdmVzIHdpdGg6IDEyODAgYW5kIDE1MDAuIEFjY29tbW9k YXRpbmcgYWxsIHBhY2tldHM8YnI+DQomZ3Q7IHdpdGhpbiB0aGF0IHNpemUgcmFuZ2Ugd2hpbGUg cGxhY2luZyBubyBleHBsaWNpdCB1cHBlciBib3VuZCBmb3IgYWNjb21tb2RhdGluZzxicj4NCiZn dDsgbGFyZ2VyIHBhY2tldHMgaXMgd2hhdCBpcyBiZWluZyBwcm9wb3NlZC4gSW4gb3RoZXIgd29y ZHMsIG5vIE1UVSBjbGFtcGluZy48YnI+DQo8YnI+DQpIYXZlIHdlIHJlYWNoZWQgY29uY2x1c2lv biBvbiB0aGlzLCBhbmQgY2FuIGl0IG5vdyBiZSBjb25zaWRlcmVkICZxdW90O2Nhc2UgY2xvc2Vk JnF1b3Q7Pzxicj4NCjxicj4NClJlbWVtYmVyIC0gJnF1b3Q7dGFrZSBjYXJlIG9mIHRoZSBzbWFs bHMsIGFuZCBsZXQgdGhlIGJpZ3MgdGFrZSBjYXJlIG9mIHRoZW1zZWx2ZXMmcXVvdDs6PGJyPg0K PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGVt cGxpbi1hZXJvbGluay8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC10ZW1wbGluLWFlcm9saW5rLzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10ZW1wbGluLWFlcm9taW4vIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGVtcGxpbi1h ZXJvbWluLzwvYT48YnI+DQo8YnI+DQpUaGFua3MgLSBGcmVkPGJyPg0KPGEgaHJlZj0ibWFpbHRv OmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20iPmZyZWQubC50ZW1wbGluQGJvZWluZy5jb208L2E+ PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2Fn ZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTombmJzcDtCcmlhbiBFIENhcnBlbnRlciAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbSI+YnJpYW4uZS5jYXJwZW50ZXJA Z21haWwuY29tPC9hPiZndDs8YnI+DQpUbzombmJzcDtLZWl0aCBNb29yZSAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1vb3JlQG5ldHdvcmstaGVyZXRpY3MuY29tIj5tb29yZUBuZXR3b3JrLWhlcmV0aWNz LmNvbTwvYT4mZ3Q7PGJyPg0KQ2M6Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3Jn Ij52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQpEYXRlOiZuYnNwO0ZyaSwgMTIgRGVjIDIwMTQgMDg6 MjM6MTIgJiM0MzsxMzAwPGJyPg0KU3ViamVjdDombmJzcDtSZTogW3Y2b3BzXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLXY2b3BzLTZ0bzQtdG8taGlzdG9yaWMtMDkudHh0PGJyPg0KS2VpdGgsIHBs ZWFzZSwgeW91IG5lZWQgdG8gYmUgc3BlY2lmaWMgYWJvdXQgd2hhdCB5b3UgdGhpbmsgaXM8YnI+ DQppbmFjY3VyYXRlIG9yIG1pc2xlYWRpbmcsIGxpbmUgYnkgbGluZSwgaW4gdGhpcyB2ZXJzaW9u LiBUaGVyZSdzPGJyPg0Kbm90aGluZyB3ZSBjYW4gZG8gd2l0aCBhIGdlbmVyYWwgY3JpdGljaXNt IGxpa2UgdGhhdC48YnI+DQo8YnI+DQpXZSBoYXZlIG1hZGUgbnVtZXJvdXMgY2hhbmdlcywgc29t ZSBvZiB0aGVtIGluIHJlc3BvbnNlIHRvIHlvdXI8YnI+DQpjb21tZW50cywgYnV0IG9mIGNvdXJz ZSBpbiBzb21lIGNhc2VzIHlvdXIgY29tbWVudHMgd2VyZSBhdDxicj4NCnZhcmlhbmNlIHdpdGgg b3RoZXIgcGVvcGxlcycgY29tbWVudHMuIE9mIGNvdXJzZSwgdGhlcmUgd2VyZSBhPGJyPg0KbG90 IG9mIG1lc3NhZ2VzLCBtYW55IG9mIHRoZW0gY29tcGxldGVseSBvcnRob2dvbmFsIHRvIHRoZSB0 ZXh0PGJyPg0Kb2YgdGhlIGRyYWZ0LCBzbyB3ZSBtYXkgd2VsbCBoYXZlIG1pc3NlZCBzb21lIG9m IHRoZSByZWxldmFudCBvbmVzLjxicj4NCjxicj4NClJlZ2FyZHM8YnI+DQombmJzcDsgJm5ic3A7 QnJpYW48YnI+DQo8YnI+DQpPbiAxMi8xMi8yMDE0IDA0OjQyLCBLZWl0aCBNb29yZSB3cm90ZTo8 YnI+DQomZ3Q7IE11bWJsZS4mbmJzcDsgSSBzdXBwb3J0IHRoZSBkZXByZWNhdGlvbiBvZiAxOTIu ODguOTkuMSBhcyBhIG1lYW5zIHRvIGZpbmQ8YnI+DQomZ3Q7IDZ0bzQgcmVsYXlzLiZuYnNwOyAm bmJzcDtCdXQgdGhpcyBkb2N1bWVudCBzdGlsbCBjb250YWlucyBzbyBtYW55IGluYWNjdXJhdGUg YW5kPGJyPg0KJmd0OyBtaXNsZWFkaW5nIHN0YXRlbWVudHMgYmV5b25kIHRoYXQsIGluY2x1ZGlu ZyBwZXJoYXBzIHNvbWUgc3RhdGVtZW50czxicj4NCiZndDsgdGhhdCB3ZXJlIG5vdCBwcmVzZW50 IGluIGVhcmxpZXIgdmVyc2lvbnMgKHRob3VnaCBJIGhhdmVuJ3QgdGFrZW4gdGhlPGJyPg0KJmd0 OyB0aW1lIHRvIGNoZWNrIHlldCksIHRoYXQgSSBkb24ndCBiZWxpZXZlIGl0IHNob3VsZCBiZSBw dWJsaXNoZWQgaW4gaXRzPGJyPg0KJmd0OyBjdXJyZW50IGZvcm0uIEFnYWluLCB0aGlzIGlzIGEg ZG9jdW1lbnQgcXVhbGl0eSBpc3N1ZSwgbm90IGFuIGlzc3VlIHdpdGg8YnI+DQomZ3Q7IHRoZSBi YXNpYyB1bmRlcmx5aW5nIHJlY29tbWVuZGF0aW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7IE1vc3Qg b2YgdGhlIHByb2JsZW1zIHdpdGggdGhpcyBkb2N1bWVudCBhcmUgdGhpbmdzIHRoYXQgSSBoYXZl IGFscmVhZHk8YnI+DQomZ3Q7IG1lbnRpb25lZCBpbiBjb25uZWN0aW9uIHdpdGggZWFybGllciB2 ZXJzaW9ucyBvZiB0aGlzIGRvY3VtZW50Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEtlaXRoPGJyPg0K Jmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7IHY2b3BzIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFp bHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxicj4N CiZndDs8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCnY2b3BzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi ciBjbGVhcj0iYWxsIj4NCjxicj4NCi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb21pYyBTYW5zIE1TJnF1b3Q7Ij5SZWdhcmRzPGJyPg0KPHNwYW4gc3R5bGU9ImNv bG9yOiMyMDEyNEQ7YmFja2dyb3VuZDp3aGl0ZSI+VGFyaXEgU2FyYWo8L3NwYW4+PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q29taWMgU2FucyBNUyZxdW90Oztjb2xvcjojQ0MwMDAwIj5DZW50 ZXI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvbWljIFNhbnMgTVMmcXVv dDsiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiNFMDY2NjYiPmZvciA8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOiM2NjAwMDAiPlJlc2VhcmNoPC9zcGFuPiBpbg0KPHNwYW4gc3R5bGU9ImNvbG9yOiNG MUMyMzIiPk5ldHdvcmtzPC9zcGFuPiBhbmQgPHNwYW4gc3R5bGU9ImNvbG9yOiMzRDg1QzYiPlRl bGVjb20NCjwvc3Bhbj4oPGI+PHNwYW4gc3R5bGU9ImNvbG9yOiM2NjY2NjYiPkNvUmVOZVQ8L3Nw YW4+PC9iPik8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2134F8430051B64F815C691A62D9831832DB6AA1XCHBLV504nwnosb_-- From nobody Mon Dec 15 10:01: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 F13DD1A8712 for ; Mon, 15 Dec 2014 10:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 xvJqxgi9YUuR for ; Mon, 15 Dec 2014 10:01:18 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 CC1C81A871D for ; Mon, 15 Dec 2014 10:01:17 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 8A52C60A02 for ; Mon, 15 Dec 2014 19:01:13 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 4A5F1600DF for ; Mon, 15 Dec 2014 19:01:13 +0100 (CET) Received: (qmail 33861 invoked by uid 1007); 15 Dec 2014 19:01:13 +0100 Date: Mon, 15 Dec 2014 19:01:13 +0100 From: Gert Doering To: Tariq Saraj Message-ID: <20141215180113.GK28745@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.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KRvMQWFzdNwtK8JwGDWeRuxxYFk Cc: v6ops@ietf.org Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 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, 15 Dec 2014 18:01:20 -0000 Hi, On Sun, Dec 14, 2014 at 12:18:00AM +0500, Tariq Saraj wrote: > There are some issues with 6rd as well, IPv6 with all its powerful features > is still under critical objections in academia just because of the urgency > shown by IETF in standardizing protocols like 6to4 and 6rd. 6to4 clearly > mentioned that it cannot support multicast at layer-3, on the other end 6rd > claimed that multicast can be provided, my question is that while > standardizing 6rd which at that time was just supporting unicast traffic > traversing across IPv4 network and its still not matured enough to provide > multicast support yet in its functionality other than using some proxy > support for multicast traffic. why It was standardized ? There is no wide-area multicast anyway. So why bother if a closed user group decides to deploy a stopgap technology to enable IPv6 access. And, when speaking about academia: do they have a "how to not write e-mail" class there? Like, "take a full digest with lots of unrelated mail in it, and write a top posting on top of it"? 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 Mon Dec 15 11:38: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 1E6A81A8781 for ; Mon, 15 Dec 2014 11:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 qlNY5Hl5bIQr for ; Mon, 15 Dec 2014 11:38:21 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70DF01A8759 for ; Mon, 15 Dec 2014 11:38:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sBFJcH8w003914; Mon, 15 Dec 2014 11:38:17 -0800 Received: from XCH-BLV-403.nw.nos.boeing.com (xch-blv-403.nw.nos.boeing.com [130.247.25.62]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sBFJc61W003729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 15 Dec 2014 11:38:07 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-BLV-403.nw.nos.boeing.com ([169.254.3.123]) with mapi id 14.03.0210.002; Mon, 15 Dec 2014 11:38:06 -0800 From: "Templin, Fred L" To: Gert Doering , Tariq Saraj Thread-Topic: IPv6 multicast and tunnels (RE: [v6ops] v6ops Digest, Vol 52, Issue 41) Thread-Index: AdAYneoY82Wv53sUQ/ibKUllM+RwhA== Date: Mon, 15 Dec 2014 19:38:05 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DB6F84@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4_WLnbxB2BSVYvKKIPTxqy6Y5DA Cc: "v6ops@ietf.org" Subject: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41) 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, 15 Dec 2014 19:38:23 -0000 Hi Gert, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Gert Doering > Sent: Monday, December 15, 2014 10:01 AM > To: Tariq Saraj > Cc: v6ops@ietf.org > Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 >=20 > Hi, >=20 > On Sun, Dec 14, 2014 at 12:18:00AM +0500, Tariq Saraj wrote: > > There are some issues with 6rd as well, IPv6 with all its powerful feat= ures > > is still under critical objections in academia just because of the urge= ncy > > shown by IETF in standardizing protocols like 6to4 and 6rd. 6to4 clearl= y > > mentioned that it cannot support multicast at layer-3, on the other end= 6rd > > claimed that multicast can be provided, my question is that while > > standardizing 6rd which at that time was just supporting unicast traffi= c > > traversing across IPv4 network and its still not matured enough to prov= ide > > multicast support yet in its functionality other than using some proxy > > support for multicast traffic. why It was standardized ? >=20 > There is no wide-area multicast anyway. I don't know about that, but it does not hurt to be prepared to accommodate= such. > So why bother if a closed user > group decides to deploy a stopgap technology to enable IPv6 access. Link- and site-scoped multicast might still be very beneficial, e.g., an op= erator sending a bulletin to all customers, etc. So, the ability to support IPv6 m= ulticast within the operator network may be useful. > And, when speaking about academia: do they have a "how to not write e-mai= l" > class there? Like, "take a full digest with lots of unrelated mail in it= , > and write a top posting on top of it"? Please be gentle in providing guidance. Thanks - Fred fred.l.templin@boeing.com > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Dec 15 12:01: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 6F7021A886F for ; Mon, 15 Dec 2014 12:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 Drldebq9fhSN for ; Mon, 15 Dec 2014 12:01:23 -0800 (PST) Received: from cookiemonster.nysernet.org (cookiemonster.nysernet.org [199.109.32.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9C01A886E for ; Mon, 15 Dec 2014 12:01:23 -0800 (PST) Received: by cookiemonster.nysernet.org (Postfix, from userid 501) id 972BC1A04947; Mon, 15 Dec 2014 15:01:22 -0500 (EST) Date: Mon, 15 Dec 2014 15:01:21 -0500 From: Bill Owens To: "Templin, Fred L" Message-ID: <20141215200121.GA34418@nysernet.org> References: <2134F8430051B64F815C691A62D9831832DB6F84@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2134F8430051B64F815C691A62D9831832DB6F84@XCH-BLV-504.nw.nos.boeing.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yKkHD0iPLoPG_tLZSCcjZXuJ5a8 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: owens@nysernet.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 20:01:27 -0000 On Mon, Dec 15, 2014 at 07:38:05PM +0000, Templin, Fred L wrote: > Hi Gert, > > > -----Original Message----- > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Gert Doering > > Sent: Monday, December 15, 2014 10:01 AM > > To: Tariq Saraj > > Cc: v6ops@ietf.org > > Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 > > > > Hi, > > > > On Sun, Dec 14, 2014 at 12:18:00AM +0500, Tariq Saraj wrote: > > > There are some issues with 6rd as well, IPv6 with all its powerful features > > > is still under critical objections in academia just because of the urgency > > > shown by IETF in standardizing protocols like 6to4 and 6rd. 6to4 clearly > > > mentioned that it cannot support multicast at layer-3, on the other end 6rd > > > claimed that multicast can be provided, my question is that while > > > standardizing 6rd which at that time was just supporting unicast traffic > > > traversing across IPv4 network and its still not matured enough to provide > > > multicast support yet in its functionality other than using some proxy > > > support for multicast traffic. why It was standardized ? > > > > There is no wide-area multicast anyway. > > I don't know about that, but it does not hurt to be prepared to accommodate such. As of this afternoon, we see 20655 v6 unicast networks and 66 multicast, with paths that include a total of 50 ASes. We have both commercial and R&E v6 paths, but there are just thirteen peers that carry multicast; all of them are R&E networks. So there is *some* wide-area IPv6 multicast, but not *much*. Certainly not enough to be worth using except in extremely limited circumstances. We continue to support it simply because of inertia; it would be more work to remove it from our configurations than to keep it in. Bill. From nobody Mon Dec 15 13:10: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 5DCCE1A8A90 for ; Mon, 15 Dec 2014 13:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 XNj5Q257jUWB for ; Mon, 15 Dec 2014 13:10:23 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B7351A8A99 for ; Mon, 15 Dec 2014 13:10:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sBFLAJiJ001092; Mon, 15 Dec 2014 13:10:19 -0800 Received: from XCH-BLV-202.nw.nos.boeing.com (xch-blv-202.nw.nos.boeing.com [10.57.37.69]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sBFLAIKb001080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 15 Dec 2014 13:10:18 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-BLV-202.nw.nos.boeing.com ([169.254.2.152]) with mapi id 14.03.0210.002; Mon, 15 Dec 2014 13:10:17 -0800 From: "Templin, Fred L" To: "owens@nysernet.org" Thread-Topic: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41) Thread-Index: AQHQGKuGG9salvinE0WXixCACR3twg== Date: Mon, 15 Dec 2014 21:10:17 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DB70A4@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832DB6F84@XCH-BLV-504.nw.nos.boeing.com> <20141215200121.GA34418@nysernet.org> In-Reply-To: <20141215200121.GA34418@nysernet.org> 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/Xyx2Sm03l8FkOyHVm-I3I0GM6J8 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41) 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, 15 Dec 2014 21:10:28 -0000 Hi Bill, > -----Original Message----- > From: Bill Owens [mailto:owens@nysernet.org] > Sent: Monday, December 15, 2014 12:01 PM > To: Templin, Fred L > Cc: v6ops@ietf.org > Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52= , Issue 41) >=20 > On Mon, Dec 15, 2014 at 07:38:05PM +0000, Templin, Fred L wrote: > > Hi Gert, > > > > > -----Original Message----- > > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Gert Doering > > > Sent: Monday, December 15, 2014 10:01 AM > > > To: Tariq Saraj > > > Cc: v6ops@ietf.org > > > Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 > > > > > > Hi, > > > > > > On Sun, Dec 14, 2014 at 12:18:00AM +0500, Tariq Saraj wrote: > > > > There are some issues with 6rd as well, IPv6 with all its powerful = features > > > > is still under critical objections in academia just because of the = urgency > > > > shown by IETF in standardizing protocols like 6to4 and 6rd. 6to4 cl= early > > > > mentioned that it cannot support multicast at layer-3, on the other= end 6rd > > > > claimed that multicast can be provided, my question is that while > > > > standardizing 6rd which at that time was just supporting unicast tr= affic > > > > traversing across IPv4 network and its still not matured enough to = provide > > > > multicast support yet in its functionality other than using some pr= oxy > > > > support for multicast traffic. why It was standardized ? > > > > > > There is no wide-area multicast anyway. > > > > I don't know about that, but it does not hurt to be prepared to accommo= date such. >=20 > As of this afternoon, we see 20655 v6 unicast networks and 66 multicast, = with paths that include a total of 50 ASes. We have both > commercial and R&E v6 paths, but there are just thirteen peers that carry= multicast; all of them are R&E networks. So there is *some* > wide-area IPv6 multicast, but not *much*. Certainly not enough to be wort= h using except in extremely limited circumstances. We > continue to support it simply because of inertia; it would be more work t= o remove it from our configurations than to keep it in. That is great data, but is a bigger picture concern for IPv6 in general and not for the use of tunnels inside of IPv6 sites right? Inside of the site, there may be a need for IPv6 link- and site-scoped multicasts, e.g., for service discovery, public bulletins, media simulcasts= , etc. In that case, it might be good if the tunnels handled multicast. Thanks - Fred fred.l.templimn@boeing.com=20 > Bill. From nobody Mon Dec 15 13:54: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 CAD921A00A7 for ; Mon, 15 Dec 2014 13:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 SeSzlXoXgWcw for ; Mon, 15 Dec 2014 13:54:11 -0800 (PST) Received: from cookiemonster.nysernet.org (cookiemonster.nysernet.org [IPv6:2620:f:1:1201:12dd:b1ff:feaa:b6b8]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1C61A0077 for ; Mon, 15 Dec 2014 13:54:06 -0800 (PST) Received: by cookiemonster.nysernet.org (Postfix, from userid 501) id A42EE1A08D8C; Mon, 15 Dec 2014 16:54:05 -0500 (EST) Date: Mon, 15 Dec 2014 16:54:04 -0500 From: Bill Owens To: "Templin, Fred L" Message-ID: <20141215215404.GR33073@nysernet.org> References: <2134F8430051B64F815C691A62D9831832DB6F84@XCH-BLV-504.nw.nos.boeing.com> <20141215200121.GA34418@nysernet.org> <2134F8430051B64F815C691A62D9831832DB70A4@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2134F8430051B64F815C691A62D9831832DB70A4@XCH-BLV-504.nw.nos.boeing.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wxGp-sOHzCwNRHYMaPnTIjagLoQ Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: owens@nysernet.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 21:54:13 -0000 On Mon, Dec 15, 2014 at 09:10:17PM +0000, Templin, Fred L wrote: > Hi Bill, > > > -----Original Message----- > > From: Bill Owens [mailto:owens@nysernet.org] > > As of this afternoon, we see 20655 v6 unicast networks and 66 multicast, with paths that include a total of 50 ASes. We have both > > commercial and R&E v6 paths, but there are just thirteen peers that carry multicast; all of them are R&E networks. So there is *some* > > wide-area IPv6 multicast, but not *much*. Certainly not enough to be worth using except in extremely limited circumstances. We > > continue to support it simply because of inertia; it would be more work to remove it from our configurations than to keep it in. > > That is great data, but is a bigger picture concern for IPv6 in general and > not for the use of tunnels inside of IPv6 sites right? > > Inside of the site, there may be a need for IPv6 link- and site-scoped > multicasts, e.g., for service discovery, public bulletins, media simulcasts, > etc. In that case, it might be good if the tunnels handled multicast. I suppose it might be useful to have site-scoped multicast, though if tunnels were needed to accomplish that I think it would be more likely that they'd be hand-configured tunnels between routers, rather than some part of a transition mechanism. I honestly have never paid any attention to the prospect of using any of the transition schemes within a site; it always seemed to me that they would be between a site and its provider. And although I used to be a strong advocate of multicast both in the wide and local networks, its use cases have faded to the point where I no longer recommend that anyone make the effort of deploying it. Bill. From nobody Mon Dec 15 14:43: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 D65B51A1EED for ; Mon, 15 Dec 2014 14:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 8r48Qxyn2gW0 for ; Mon, 15 Dec 2014 14:43:20 -0800 (PST) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E99C1A1EEA for ; Mon, 15 Dec 2014 14:43:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sBFMhJq1003706; Mon, 15 Dec 2014 16:43:19 -0600 Received: from XCH-PHX-413.sw.nos.boeing.com (xch-phx-413.sw.nos.boeing.com [10.57.37.45]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sBFMhA0l003159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 15 Dec 2014 16:43:11 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-PHX-413.sw.nos.boeing.com ([169.254.13.86]) with mapi id 14.03.0210.002; Mon, 15 Dec 2014 14:43:09 -0800 From: "Templin, Fred L" To: "owens@nysernet.org" Thread-Topic: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41) Thread-Index: AQHQGKuGG9salvinE0WXixCACR3twpyRuA4A//96RHA= Date: Mon, 15 Dec 2014 22:43:09 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DB719B@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832DB6F84@XCH-BLV-504.nw.nos.boeing.com> <20141215200121.GA34418@nysernet.org> <2134F8430051B64F815C691A62D9831832DB70A4@XCH-BLV-504.nw.nos.boeing.com> <20141215215404.GR33073@nysernet.org> In-Reply-To: <20141215215404.GR33073@nysernet.org> 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/ZoCDYVpyrBAl860760V0WlSY29k Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41) 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, 15 Dec 2014 22:43:22 -0000 Hi Bill, > -----Original Message----- > From: Bill Owens [mailto:owens@nysernet.org] > Sent: Monday, December 15, 2014 1:54 PM > To: Templin, Fred L > Cc: v6ops@ietf.org > Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52= , Issue 41) >=20 > On Mon, Dec 15, 2014 at 09:10:17PM +0000, Templin, Fred L wrote: > > Hi Bill, > > > > > -----Original Message----- > > > From: Bill Owens [mailto:owens@nysernet.org] > > > As of this afternoon, we see 20655 v6 unicast networks and 66 multica= st, with paths that include a total of 50 ASes. We have both > > > commercial and R&E v6 paths, but there are just thirteen peers that c= arry multicast; all of them are R&E networks. So there is > *some* > > > wide-area IPv6 multicast, but not *much*. Certainly not enough to be = worth using except in extremely limited circumstances. We > > > continue to support it simply because of inertia; it would be more wo= rk to remove it from our configurations than to keep it in. > > > > That is great data, but is a bigger picture concern for IPv6 in general= and > > not for the use of tunnels inside of IPv6 sites right? > > > > Inside of the site, there may be a need for IPv6 link- and site-scoped > > multicasts, e.g., for service discovery, public bulletins, media simulc= asts, > > etc. In that case, it might be good if the tunnels handled multicast. >=20 > I suppose it might be useful to have site-scoped multicast, Two that come to mind are LLMNR and mDNS. But really, any site-scoped or link-scoped multicast application should work. > though if tunnels were needed to accomplish that I think it would be more > likely that they'd be hand-configured tunnels between routers, Automatic tunnels without explicit configurations are also possible (see AE= RO). > rather than some part of a transition mechanism. Tunneling is about more than just transition. Also useful for mobility, rou= ting control, security, traffic engineering, etc. regardless of transition or no= t. > I honestly have > never paid any attention to the prospect of using any of the transition s= chemes within a site; it always seemed to me that they would > be between a site and its provider. Just to be clear, I am considering the entire ISP network as a "site" when I talk about link- and site-scoped multicast. And the tunnel provides a "link" that spans the site. > And although I used to be a strong advocate of multicast both in the wide= and local networks, its > use cases have faded to the point where I no longer recommend that anyone= make the effort of deploying it. Well, there are already RFC4795, RFC6762, RFC6763, etc. Thanks - Fred fred.l.templin@boeing.com > Bill. From nobody Mon Dec 15 14:47: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 71DDD1A1B4A for ; Mon, 15 Dec 2014 14:47:25 -0800 (PST) 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_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 GI1Cq0p6WKoc for ; Mon, 15 Dec 2014 14:47:23 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95EFF1A0078 for ; Mon, 15 Dec 2014 14:47:23 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::1d9]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.9) with ESMTP id sBFMlD0v011887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2014 22:47:16 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::1d9] claimed to be cupcake.foobar.org Message-ID: <548F64F1.8090103@foobar.org> Date: Mon, 15 Dec 2014 22:47:13 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Templin, Fred L" , "owens@nysernet.org" References: <2134F8430051B64F815C691A62D9831832DB6F84@XCH-BLV-504.nw.nos.boeing.com> <20141215200121.GA34418@nysernet.org> <2134F8430051B64F815C691A62D9831832DB70A4@XCH-BLV-504.nw.nos.boeing.com> <20141215215404.GR33073@nysernet.org> <2134F8430051B64F815C691A62D9831832DB719B@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832DB719B@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/fYHg0Zep4PvAMTcAZ0JcnV47ZQg Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41) 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, 15 Dec 2014 22:47:25 -0000 On 15/12/2014 22:43, Templin, Fred L wrote: > Well, there are already RFC4795, RFC6762, RFC6763, etc. Probably Bill is referring to routed multicast or worse still, interdomain multicast (obligatory shudder). LAN-local multicast is normally fine. Nick From nobody Mon Dec 15 14:54: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 835761A036B for ; Mon, 15 Dec 2014 14:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 nxFdNFrHglgK for ; Mon, 15 Dec 2014 14:54:04 -0800 (PST) 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 82CD81A039B for ; Mon, 15 Dec 2014 14:54:04 -0800 (PST) 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 sBFMs4Wt027259; Mon, 15 Dec 2014 14:54:04 -0800 Received: from XCH-PHX-112.sw.nos.boeing.com (xch-phx-112.sw.nos.boeing.com [130.247.25.134]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sBFMrtru027208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 15 Dec 2014 14:53:56 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-PHX-112.sw.nos.boeing.com ([169.254.12.251]) with mapi id 14.03.0210.002; Mon, 15 Dec 2014 14:53:54 -0800 From: "Templin, Fred L" To: Nick Hilliard , "owens@nysernet.org" Thread-Topic: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41) Thread-Index: AQHQGKuGG9salvinE0WXixCACR3twpyRuA4A//96RHCAAJSVgP//et6g Date: Mon, 15 Dec 2014 22:53:54 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DB71DE@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832DB6F84@XCH-BLV-504.nw.nos.boeing.com> <20141215200121.GA34418@nysernet.org> <2134F8430051B64F815C691A62D9831832DB70A4@XCH-BLV-504.nw.nos.boeing.com> <20141215215404.GR33073@nysernet.org> <2134F8430051B64F815C691A62D9831832DB719B@XCH-BLV-504.nw.nos.boeing.com> <548F64F1.8090103@foobar.org> In-Reply-To: <548F64F1.8090103@foobar.org> 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/3PXsGv2w9tJuUUZOIKKO4s0tkSY Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41) 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, 15 Dec 2014 22:54:05 -0000 Hi Nick, > -----Original Message----- > From: Nick Hilliard [mailto:nick@foobar.org] > Sent: Monday, December 15, 2014 2:47 PM > To: Templin, Fred L; owens@nysernet.org > Cc: v6ops@ietf.org > Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52= , Issue 41) >=20 > On 15/12/2014 22:43, Templin, Fred L wrote: > > Well, there are already RFC4795, RFC6762, RFC6763, etc. >=20 > Probably Bill is referring to routed multicast or worse still, interdomai= n > multicast (obligatory shudder). LAN-local multicast is normally fine. OK. In this case, however, the "LAN" is the entire ISP network since the tu= nnel provides a virtual link over underlying ISP network. So really, LLMNR, mDNS= , etc. would be a link-scoped service over the tunnel but a site-scoped service wi= thin the ISP network. Thanks - Fred fred.l.templin@boeing.com From nobody Mon Dec 15 17:19: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 E89141A0074 for ; Mon, 15 Dec 2014 17:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 9f1O0gOpBS-A for ; Mon, 15 Dec 2014 17:19:08 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB7151A0140 for ; Mon, 15 Dec 2014 17:19:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1854; q=dns/txt; s=iport; t=1418692749; x=1419902349; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=4KpT7FFTOG8x/pN31WlzsseGLYkulBczSX9BBGayb3w=; b=IAAyaY514nmO6HXFKLBfANMR9RsLt7a9KJELVvp4F/mcrmFOgDXI2+kD UdU/CpS7r8nlB7yoBcCtq3yStL0aHoDIK4SnBVlCYlloir7liM7lvA9K/ B+5uxloVAYhwip/WvI/1pHAd9OPZrDJcPH+tiBkzDPL5wf/0u5UTjTvr9 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIFAOCHj1StJV2U/2dsb2JhbABagwaBKoMGyFYCgSIWAQEBAQF9hAwBAQEDASNWBQsLGAICJgICITYGExuHfQMJCL4hkR4NhTIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGMKYF1MweCaC6BEwWJPotwgUOBC4RuhW2CGYM4IoQNHTCCQwEBAQ X-IronPort-AV: E=Sophos;i="5.07,583,1413244800"; d="scan'208";a="377418051" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-1.cisco.com with ESMTP; 16 Dec 2014 01:19:08 +0000 Received: from [10.24.10.191] ([10.24.10.191]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sBG1J5ga024482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2014 01:19:06 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Fred Baker In-Reply-To: Date: Mon, 15 Dec 2014 17:19:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7A220AB3-E269-4B41-8C82-75BB5A962732@cisco.com> References: To: Tariq Saraj X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_uDxPtoU6Ja8eE2qKrWImFcxMdw Cc: v6ops@ietf.org Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 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, 16 Dec 2014 01:19:11 -0000 > On Dec 13, 2014, at 11:18 AM, Tariq Saraj = wrote: >=20 > There are some issues with 6rd as well, IPv6 with all its powerful = features is still under critical objections in academia just because of = the urgency shown by IETF in standardizing protocols like 6to4 and 6rd. = 6to4 clearly mentioned that it cannot support multicast at layer-3, on = the other end 6rd claimed that multicast can be provided, my question is = that while standardizing 6rd which at that time was just supporting = unicast traffic traversing across IPv4 network and its still not matured = enough to provide multicast support yet in its functionality other than = using some proxy support for multicast traffic. why It was standardized = ?=20 Without detracting from Gerd and other=E2=80=99s comments, the primary = issue that 6rd addressed was a deployment issue. Suppose, if you will, = that everything in your network is IPv6-capable and has IPv6 turned up, = with the exception of one kind of equipment such as a BRAS. What you = might like to do is configure (easily, for some definition of that term) = an IPv4 tunnel to jump over that device to your customer, enabling you = to give the customer an IPv6 *service* even though you can=E2=80=99t = today given him *native*service*. ISATAP and 6to4 similarly were = intended to provide a way to deploy IPv6 as a service before native IPv6 = was feasible. Where we are at today, there isn=E2=80=99t really a lot of equipment = that one would have to =E2=80=9Cjump over=E2=80=9D. Hence, patience with = those solutions is becoming a little frayed. If they present a = limitation, such as lack of multicast service, improving the bandaid is = throwing good money after bad. Folks today would suggest that you take = the next step, of deploying native IPv6 service. From nobody Tue Dec 16 01:58: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 EB3091A1A88 for ; Tue, 16 Dec 2014 01:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-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 l0vRsA0ghvFU for ; Tue, 16 Dec 2014 01:58:28 -0800 (PST) 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 E006D1A1A6F for ; Tue, 16 Dec 2014 01:58:27 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id sBG9wGFs020625; Tue, 16 Dec 2014 09:58:16 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk sBG9wGFs020625 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1418723897; bh=CpL4KAhM/EwEyTHXtLmd6BejqLo=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=UA3uK9xkw2TOk7Bin4RKMvfrlcoOD6UmFHd3+k+daUgkWgfwTe7WRYOuRtoTkzvCQ O8qwsogvRcdLMo6cJaHUkVwAz9Rd9ZCUadzrJpMP4bpFSXv9qfQ++jVb2128/exuLP tk/xWbqPZdPk7EBEIuqwkhFhvEa18Pk4zXGuPz/g= 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 qBF9wG2351201821ny ret-id none; Tue, 16 Dec 2014 09:58:17 +0000 Received: from dhcp-55-177.wireless.soton.ac.uk ([10.9.55.177]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id sBG9uv9Q024179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2014 09:56:57 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Tim Chown In-Reply-To: <2134F8430051B64F815C691A62D9831832DB6F84@XCH-BLV-504.nw.nos.boeing.com> Date: Tue, 16 Dec 2014 09:56:56 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <2134F8430051B64F815C691A62D9831832DB6F84@XCH-BLV-504.nw.nos.boeing.com> <0DA14EC4-AE66-4CEC-8E85-48692E13B92C@ecs.soton.ac.uk> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1993) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=qBF9wG235120182100; tid=qBF9wG2351201821ny; 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: sBG9wGFs020625 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8flU1xpC40kdXNo1T_tiMC76SEY Cc: Tariq Saraj , "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41) 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, 16 Dec 2014 09:58:30 -0000 On 15 Dec 2014, at 19:38, Templin, Fred L = wrote: >=20 > Hi Gert, >=20 >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Gert Doering >> Sent: Monday, December 15, 2014 10:01 AM >> To: Tariq Saraj >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 >>=20 >> Hi, >>=20 >> On Sun, Dec 14, 2014 at 12:18:00AM +0500, Tariq Saraj wrote: >>> There are some issues with 6rd as well, IPv6 with all its powerful = features >>> is still under critical objections in academia just because of the = urgency >>> shown by IETF in standardizing protocols like 6to4 and 6rd. 6to4 = clearly >>> mentioned that it cannot support multicast at layer-3, on the other = end 6rd >>> claimed that multicast can be provided, my question is that while >>> standardizing 6rd which at that time was just supporting unicast = traffic >>> traversing across IPv4 network and its still not matured enough to = provide >>> multicast support yet in its functionality other than using some = proxy >>> support for multicast traffic. why It was standardized ? >>=20 >> There is no wide-area multicast anyway. >=20 > I don't know about that, but it does not hurt to be prepared to = accommodate such. Well, there is Embedded-RP, which is used inter-site. I believe it=E2=80=99= s supported around much of the academic/NREN networks.=20 Or of course SSM. But yes, the usage levels are =E2=80=98light=E2=80=99. All our multicast streams used Embedded-RP, even though most are = intra-site. >> So why bother if a closed user >> group decides to deploy a stopgap technology to enable IPv6 access. >=20 > Link- and site-scoped multicast might still be very beneficial, e.g., = an operator > sending a bulletin to all customers, etc. So, the ability to support = IPv6 multicast > within the operator network may be useful. >=20 >> And, when speaking about academia: do they have a "how to not write = e-mail" >> class there? Like, "take a full digest with lots of unrelated mail = in it, >> and write a top posting on top of it"? >=20 > Please be gentle in providing guidance. Well yes, top/tail is a personal preference. But let=E2=80=99s discuss = multicast... Tim= From nobody Tue Dec 16 02:52: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 2D2D11A1A97 for ; Tue, 16 Dec 2014 02:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-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 4wHf0tA4AFsW for ; Tue, 16 Dec 2014 02:52:16 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 D5ECE1A1A92 for ; Tue, 16 Dec 2014 02:52:15 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 9767260A3F for ; Tue, 16 Dec 2014 11:52:13 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id CB1DE60A12 for ; Tue, 16 Dec 2014 11:52:12 +0100 (CET) Received: (qmail 1375 invoked by uid 1007); 16 Dec 2014 11:52:12 +0100 Date: Tue, 16 Dec 2014 11:52:12 +0100 From: Gert Doering To: "Templin, Fred L" Message-ID: <20141216105212.GQ28745@Space.Net> References: <2134F8430051B64F815C691A62D9831832DB6F84@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uSEi0Sb8iS/xI+Dv" Content-Disposition: inline In-Reply-To: <2134F8430051B64F815C691A62D9831832DB6F84@XCH-BLV-504.nw.nos.boeing.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/99ri95Szd895WxulyHnay1ap7LA Cc: Tariq Saraj , "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41) 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, 16 Dec 2014 10:52:18 -0000 --uSEi0Sb8iS/xI+Dv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Dec 15, 2014 at 07:38:05PM +0000, Templin, Fred L wrote: > > There is no wide-area multicast anyway. >=20 > I don't know about that, but it does not hurt to be prepared to=20 > accommodate such. 6rd etc. are short-term solutions that will go away as soon as the infrastructure can support native, and people start turning off IPv4. So "we need to support something that nobody is using on a migration technology, just in case someone might want to use it a few years down the road, when the migration technology is going away anyway" is just not a convincing argument. > > So why bother if a closed user > > group decides to deploy a stopgap technology to enable IPv6 access. >=20 > Link- and site-scoped multicast might still be very beneficial, e.g., an = operator > sending a bulletin to all customers, etc. So, the ability to support IPv6= multicast > within the operator network may be useful. Uh, right. I'd dearly love to see such an application out in the real world - there is no application that can "send bulletins via multicast" today, and if there were, it would not be installed on a customer's machine by default. We're not talking about niche markets where multicast is deployed today, like "financial industry in a very controlled environment" but about areas where 6rd is used - which is "out in the wild Internet". Different world. No multicast there, no multicast capable applications, no use case. (TV streaming is a valid use case and uses multicast, but that's normally done inside the Telco's network, so they will ensure that whatever=20 technology they use to provide IPv6 will nicely live side by side with whatever technology they use to provide their TV offerings) > > And, when speaking about academia: do they have a "how to not write e-m= ail" > > class there? Like, "take a full digest with lots of unrelated mail in = it, > > and write a top posting on top of it"? >=20 > Please be gentle in providing guidance. Would that work? 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 --uSEi0Sb8iS/xI+Dv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVJAO3N9WwGXkzn/FAQJOjRAAkYMKmrq4T2wwZMHTFDq0E4jGsb69q7sK gvMrxaaPyqiYk34dQfL1giy3VQzQeq9F0Z5obdCDiJfZfRxAamxGHPeWenUPDJ1I 4V6XTUzza4rnT0gg4kAh4qborjFHs7Jy4S0biU5tCmuk9dF1r4YoaO70A+YXR1wx 6IPoOn4LTzPTuI4GI+gHXWqDo6pfFm6o0BBdIOf8BJufFP/TpN1hXdPOkZhjU4Li DMa8He5NeoZismBkK5nJWABJxsXFFvDteC3ueiAcY81GjyJ2JZNIzPNM5z/T+0cX +rAdgT+d9Sj8opjZ0IcGGH8iJtnnbjFoDH/MtrhY81UPhHOtO6I7mkqgDJs0zcu4 FcHcuFa7if/7JhUsEU9tVa71tuDtk8D+wOg2h+gkdNjL72UXWPykznGtpt8L31tl WMvll9Yf7aRVaVzPFpKhLV4t0XoidfZfTwe1/MH02JhCwJSU107U8Zj7k0lxeHuF HvIrQXWGaM2iar6FjGmUVfeiyMrAnLn77sCclSSzxZ7Lk8+cPQqEil7q4FtZ1l+2 pZt/oSPO85QSh7iUVSv8iHAUbKuNWGlfeqLKs5cMKl/AkgmzBNFQlPzLl5xYc+ee PlBXlEJ5blYNCcwc6EqW3aw7nm+AGIykJn8DJ5t/Yj+rIfud5GDr1OxS6IAGy/jb /LIi2RI8w28= =U1SH -----END PGP SIGNATURE----- --uSEi0Sb8iS/xI+Dv-- From nobody Tue Dec 16 04:52: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 4DF721A1B37 for ; Tue, 16 Dec 2014 04:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 MPDcJBShhC25 for ; Tue, 16 Dec 2014 04:52:35 -0800 (PST) Received: from cookiemonster.nysernet.org (cookiemonster.nysernet.org [IPv6:2620:f:1:1201:12dd:b1ff:feaa:b6b8]) by ietfa.amsl.com (Postfix) with ESMTP id 07D2E1A70E1 for ; Tue, 16 Dec 2014 04:52:31 -0800 (PST) Received: by cookiemonster.nysernet.org (Postfix, from userid 501) id E30161A0EEC7; Tue, 16 Dec 2014 07:52:30 -0500 (EST) Date: Tue, 16 Dec 2014 07:52:30 -0500 From: Bill Owens To: Tim Chown Message-ID: <20141216125230.GA59754@nysernet.org> References: <2134F8430051B64F815C691A62D9831832DB6F84@XCH-BLV-504.nw.nos.boeing.com> <0DA14EC4-AE66-4CEC-8E85-48692E13B92C@ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/dZPdjIGNostIxTgDpdKXFRuu4Aw Cc: Tariq Saraj , "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: owens@nysernet.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 12:52:46 -0000 On Tue, Dec 16, 2014 at 09:56:56AM +0000, Tim Chown wrote: > Well, there is Embedded-RP, which is used inter-site. I believe it’s supported around much of the academic/NREN networks. > Or of course SSM. "Supported" in the sense that the configuration is in place and if you want to use it nobody will stop you, yes. And "networks" being backbones for the most part, along with a very small list of end sites. But "supported" as in "considered a production grade service that is documented, monitored and actively tested, with technical staff able to assist with deployment and troubleshooting"? No, I don't think so. And this isn't a situation that makes me happy; I would rather see people using native multicast where it is appropriate, but I think it is clear that in the wide-area, interdomain case that will not happen. Bill. From nobody Tue Dec 16 04:57: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 922451A854B for ; Tue, 16 Dec 2014 04:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 AiZsi-W7LuRe for ; Tue, 16 Dec 2014 04:57:30 -0800 (PST) Received: from cookiemonster.nysernet.org (cookiemonster.nysernet.org [IPv6:2620:f:1:1201:12dd:b1ff:feaa:b6b8]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2671A1B37 for ; Tue, 16 Dec 2014 04:57:30 -0800 (PST) Received: by cookiemonster.nysernet.org (Postfix, from userid 501) id CF6E61A0F00D; Tue, 16 Dec 2014 07:57:20 -0500 (EST) Date: Tue, 16 Dec 2014 07:57:20 -0500 From: Bill Owens To: "Templin, Fred L" Message-ID: <20141216125720.GB59754@nysernet.org> References: <2134F8430051B64F815C691A62D9831832DB6F84@XCH-BLV-504.nw.nos.boeing.com> <20141215200121.GA34418@nysernet.org> <2134F8430051B64F815C691A62D9831832DB70A4@XCH-BLV-504.nw.nos.boeing.com> <20141215215404.GR33073@nysernet.org> <2134F8430051B64F815C691A62D9831832DB719B@XCH-BLV-504.nw.nos.boeing.com> <548F64F1.8090103@foobar.org> <2134F8430051B64F815C691A62D9831832DB71DE@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2134F8430051B64F815C691A62D9831832DB71DE@XCH-BLV-504.nw.nos.boeing.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VepaB6eFViJ6ILrPhBXsizKVbD4 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: owens@nysernet.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 12:57:31 -0000 On Mon, Dec 15, 2014 at 10:53:54PM +0000, Templin, Fred L wrote: > Hi Nick, > > > -----Original Message----- > > From: Nick Hilliard [mailto:nick@foobar.org] > > Sent: Monday, December 15, 2014 2:47 PM > > To: Templin, Fred L; owens@nysernet.org > > Cc: v6ops@ietf.org > > Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41) > > > > On 15/12/2014 22:43, Templin, Fred L wrote: > > > Well, there are already RFC4795, RFC6762, RFC6763, etc. > > > > Probably Bill is referring to routed multicast or worse still, interdomain > > multicast (obligatory shudder). LAN-local multicast is normally fine. I was, and I'm aware of the applications for LAN multicast, but confused when Fred says: > OK. In this case, however, the "LAN" is the entire ISP network since the tunnel > provides a virtual link over underlying ISP network. So really, LLMNR, mDNS, etc. > would be a link-scoped service over the tunnel but a site-scoped service within > the ISP network. What's the use case for LLMNR or mDNS over an ISP network? You want to be able to do DNS lookups or service discovery for services that the ISP offers, but that they don't want to configure into conventional DNS? You want people to be able to see each others' LAN devices (probably not!) If the tunnel is spanning an ISP and linking two sites that belong to the same administrative domain, I could see a desire for it to carry multicast, but that's also a scenario in which I think it is very likely that the user would want a manually-configured and probably encrypted tunnel rather than an automatically generated one. What am I missing? Bill. From nobody Tue Dec 16 08:10: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 1ECA21A1B49 for ; Tue, 16 Dec 2014 08:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 yEBETuFlHHzm for ; Tue, 16 Dec 2014 08:10:01 -0800 (PST) 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 16F581A1BB4 for ; Tue, 16 Dec 2014 08:09:43 -0800 (PST) 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 sBGG9gf5018707; Tue, 16 Dec 2014 08:09:42 -0800 Received: from XCH-BLV-206.nw.nos.boeing.com (xch-blv-206.nw.nos.boeing.com [10.57.37.16]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sBGG9VdQ018529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 16 Dec 2014 08:09:32 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-BLV-206.nw.nos.boeing.com ([169.254.6.200]) with mapi id 14.03.0210.002; Tue, 16 Dec 2014 08:09:31 -0800 From: "Templin, Fred L" To: Gert Doering Thread-Topic: IPv6 multicast and tunnels (RE: [v6ops] v6ops Digest, Vol 52, Issue 41) Thread-Index: AdAYneoY82Wv53sUQ/ibKUllM+RwhAAw3ykAAAX3+dA= Date: Tue, 16 Dec 2014 16:09:30 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DB77EA@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832DB6F84@XCH-BLV-504.nw.nos.boeing.com> <20141216105212.GQ28745@Space.Net> In-Reply-To: <20141216105212.GQ28745@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/j65GRuyqyrCf6y9wgywqcf2RdFM Cc: Tariq Saraj , "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41) 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, 16 Dec 2014 16:10:05 -0000 Hi Gert, > -----Original Message----- > From: Gert Doering [mailto:gert@Space.Net] > Sent: Tuesday, December 16, 2014 2:52 AM > To: Templin, Fred L > Cc: Gert Doering; Tariq Saraj; v6ops@ietf.org > Subject: Re: IPv6 multicast and tunnels (RE: [v6ops] v6ops Digest, Vol 52= , Issue 41) >=20 > Hi, >=20 > On Mon, Dec 15, 2014 at 07:38:05PM +0000, Templin, Fred L wrote: > > > There is no wide-area multicast anyway. > > > > I don't know about that, but it does not hurt to be prepared to > > accommodate such. >=20 > 6rd etc. are short-term solutions that will go away as soon as the > infrastructure can support native, and people start turning off IPv4. I am not talking about extending 6rd, but rather about a long-term solution that addresses much more than just IPv6-over-IPv4 transition. > So "we need to support something that nobody is using on a migration > technology, just in case someone might want to use it a few years down > the road, when the migration technology is going away anyway" is just > not a convincing argument. It is not only about migration. > > > So why bother if a closed user > > > group decides to deploy a stopgap technology to enable IPv6 access. > > > > Link- and site-scoped multicast might still be very beneficial, e.g., a= n operator > > sending a bulletin to all customers, etc. So, the ability to support IP= v6 multicast > > within the operator network may be useful. >=20 > Uh, right. I'd dearly love to see such an application out in the real > world - there is no application that can "send bulletins via multicast" > today, and if there were, it would not be installed on a customer's > machine by default. Link- and/or site-scoped multicast are useful. > We're not talking about niche markets where multicast is deployed today, > like "financial industry in a very controlled environment" but about > areas where 6rd is used - which is "out in the wild Internet". Different > world. No multicast there, no multicast capable applications, no use > case. I thought 6rd was within an operator network, and not "out in the wild Internet"? But again, I am not restricting to that one specific use case; I want one tunneling solution that applies everywhere and for uses more than just transition. And, multicast support is a part of that. > (TV streaming is a valid use case and uses multicast, but that's normally > done inside the Telco's network, so they will ensure that whatever > technology they use to provide IPv6 will nicely live side by side with > whatever technology they use to provide their TV offerings) Any link- or site-scoped multicast is a valid use case, keeping an open min= d about possibilities. Thanks - Fred fred.l.templin@boeing.com > > > And, when speaking about academia: do they have a "how to not write e= -mail" > > > class there? Like, "take a full digest with lots of unrelated mail i= n it, > > > and write a top posting on top of it"? > > > > Please be gentle in providing guidance. >=20 > Would that work? >=20 > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue Dec 16 08:22: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 A60501A1B44 for ; Tue, 16 Dec 2014 08:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 X2N27Y4IbwC9 for ; Tue, 16 Dec 2014 08:22:44 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CBBB1A1BC8 for ; Tue, 16 Dec 2014 08:22:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sBGGMhnA000789; Tue, 16 Dec 2014 08:22:44 -0800 Received: from XCH-PHX-313.sw.nos.boeing.com (xch-phx-313.sw.nos.boeing.com [130.247.25.175]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sBGGMbPe032628 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 16 Dec 2014 08:22:38 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-PHX-313.sw.nos.boeing.com ([169.254.13.131]) with mapi id 14.03.0210.002; Tue, 16 Dec 2014 08:22:37 -0800 From: "Templin, Fred L" To: "owens@nysernet.org" Thread-Topic: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41) Thread-Index: AQHQGKuGG9salvinE0WXixCACR3twpyRuA4A//96RHCAAJSVgP//et6ggAFypwD//6+wcA== Date: Tue, 16 Dec 2014 16:22:36 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DB782E@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832DB6F84@XCH-BLV-504.nw.nos.boeing.com> <20141215200121.GA34418@nysernet.org> <2134F8430051B64F815C691A62D9831832DB70A4@XCH-BLV-504.nw.nos.boeing.com> <20141215215404.GR33073@nysernet.org> <2134F8430051B64F815C691A62D9831832DB719B@XCH-BLV-504.nw.nos.boeing.com> <548F64F1.8090103@foobar.org> <2134F8430051B64F815C691A62D9831832DB71DE@XCH-BLV-504.nw.nos.boeing.com> <20141216125720.GB59754@nysernet.org> In-Reply-To: <20141216125720.GB59754@nysernet.org> 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/NJ9-UQ5Tia1wov3QDwqLe4iqX80 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41) 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, 16 Dec 2014 16:22:49 -0000 Hi Bill, > -----Original Message----- > From: Bill Owens [mailto:owens@nysernet.org] > Sent: Tuesday, December 16, 2014 4:57 AM > To: Templin, Fred L > Cc: Nick Hilliard; v6ops@ietf.org > Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52= , Issue 41) >=20 > On Mon, Dec 15, 2014 at 10:53:54PM +0000, Templin, Fred L wrote: > > Hi Nick, > > > > > -----Original Message----- > > > From: Nick Hilliard [mailto:nick@foobar.org] > > > Sent: Monday, December 15, 2014 2:47 PM > > > To: Templin, Fred L; owens@nysernet.org > > > Cc: v6ops@ietf.org > > > Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vo= l 52, Issue 41) > > > > > > On 15/12/2014 22:43, Templin, Fred L wrote: > > > > Well, there are already RFC4795, RFC6762, RFC6763, etc. > > > > > > Probably Bill is referring to routed multicast or worse still, interd= omain > > > multicast (obligatory shudder). LAN-local multicast is normally fine= . >=20 > I was, and I'm aware of the applications for LAN multicast, but confused = when Fred says: >=20 > > OK. In this case, however, the "LAN" is the entire ISP network since th= e tunnel > > provides a virtual link over underlying ISP network. So really, LLMNR, = mDNS, etc. > > would be a link-scoped service over the tunnel but a site-scoped servic= e within > > the ISP network. >=20 > What's the use case for LLMNR or mDNS over an ISP network? The same as for any link. > You want to be able to do DNS lookups or service discovery for services > that the ISP offers, but that they don't want to configure into conventio= nal DNS? I am naming just two examples of link- and site-scoped multicast services. > You want people to be able to see each others' LAN > devices (probably not!) I want people to receive link- and site-scoped multicast services provided by the ISP, enterprise network or whatever other form of network that provides a tunneled service. > If the tunnel is spanning an ISP and linking two sites that belong to the= same administrative domain, I could > see a desire for it to carry multicast, but that's also a scenario in whi= ch I think it is very likely that the user would want a manually- > configured and probably encrypted tunnel rather than an automatically gen= erated one. What am I missing? The peer-to-peer tunnel setup would be automatically generated based on a common trust anchor in the provider network. So, if trust anchor A trusts clients B and C, then B and C have the foundations for trusting one another= . In some environments, just verifying the peer's source address may be all that is needed. In other environments, there may be a need for a security association and encryption. But again, the tunnel is established dynamicall= y and not manually configured. Thanks - Fred fred.l.templin@boeing.com > Bill. From nobody Tue Dec 16 08:26: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 193AB1A1B5B for ; Tue, 16 Dec 2014 08:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 nlBEs7fGzYw0 for ; Tue, 16 Dec 2014 08:26:29 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 0ADED1A1B30 for ; Tue, 16 Dec 2014 08:26:29 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 8DD7560A16 for ; Tue, 16 Dec 2014 17:26:27 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 5DB5C60274 for ; Tue, 16 Dec 2014 17:26:27 +0100 (CET) Received: (qmail 65376 invoked by uid 1007); 16 Dec 2014 17:26:27 +0100 Date: Tue, 16 Dec 2014 17:26:27 +0100 From: Gert Doering To: "Templin, Fred L" Message-ID: <20141216162627.GB28745@Space.Net> References: <2134F8430051B64F815C691A62D9831832DB6F84@XCH-BLV-504.nw.nos.boeing.com> <20141216105212.GQ28745@Space.Net> <2134F8430051B64F815C691A62D9831832DB77EA@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LEoNChPhgCOFDK0K" Content-Disposition: inline In-Reply-To: <2134F8430051B64F815C691A62D9831832DB77EA@XCH-BLV-504.nw.nos.boeing.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/V82JeIgp8bFvhc9Jgko5S69DD_0 Cc: Tariq Saraj , "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41) 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, 16 Dec 2014 16:26:31 -0000 --LEoNChPhgCOFDK0K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Dec 16, 2014 at 04:09:30PM +0000, Templin, Fred L wrote: > Any link- or site-scoped multicast is a valid use case, keeping an open m= ind > about possibilities. "valid use case" is nice and shiny, but if people don't actually *use* it, I don't see the issue why one would need to complain that a certain (temporary) technology doesn't support it. Please stick to the general topic the thread started with: a complaint from academia that certain migration technologies have been pushed out into operations without taking care to support multicast. 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 --LEoNChPhgCOFDK0K Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVJBdM99WwGXkzn/FAQLZNg/5ASN7V56sYEnc19ZBqiEdJMAyikbypgbJ b5i7ojJ+uO0KqRVP4XAMZUXbTaJ9Tkep8eUfo7r1ySF+DEh+ZlUJDaOsbgS97z+i 6MgZlDEbH48mmnKgLGEn+Gk8E97a79Zcsgbu6FV5ZS3DG26n89JNHd3SR6rD8a8d Z5T1DR+TKNWXWshYQu7K/Ey8Lks4FkuqpjWjAdQIaF+LRJ4dxiEY1gLYwvcpo9Pu IysFDtAhnu+8Y9Zo+QFgnOQc1u6VdZk9H3NBFBmuTfVcvNF0zmHzofawofWHvWms K8BHnEw27WXBpWthm+zz9iRkYvF8dn1BjC1UW50zHX8fKESOZtYWYTsqgBfjCyrK v1tdsUyomouyh4ot//PZVHA94yKBuYz3AcWUM80gBMc1dTlyXbqyTlelHEenOfvT 8mnDF0w1QtN2K0yGep16pjefAdypsb5M4t0aHmn/niYKhnugIOSTtuT/B0sy567l iEw0Rd9o/YGn+Z/GY12Da/d4U7OcYIrLqipx9fqD0WtDC9XDKnjrddxxCMQpWWgW PEPfuad2yQOlBcOLPLBwG6918yK0cUfvnRkoF/HdOo0lohPOoNf8nXp+Fgt/2T8j 1GoObDzn9kP8vVLHNVmNDu5/3C/qvEd6WvdGAAGlLsNHrWkzcT/VVxinHVnMywTR 6ZrhQrVYJaI= =oO4D -----END PGP SIGNATURE----- --LEoNChPhgCOFDK0K-- From nobody Tue Dec 16 08:36: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 EF4351A3B9F for ; Tue, 16 Dec 2014 08:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 RkyU2Um6G3w6 for ; Tue, 16 Dec 2014 08:36:02 -0800 (PST) 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 4FF731A1F73 for ; Tue, 16 Dec 2014 08:36:02 -0800 (PST) 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 sBGGa1QS031739; Tue, 16 Dec 2014 08:36:02 -0800 Received: from XCH-BLV-102.nw.nos.boeing.com (xch-blv-102.nw.nos.boeing.com [130.247.25.117]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sBGGZtaQ031689 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 16 Dec 2014 08:35:55 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-BLV-102.nw.nos.boeing.com ([169.254.2.137]) with mapi id 14.03.0210.002; Tue, 16 Dec 2014 08:35:54 -0800 From: "Templin, Fred L" To: Gert Doering Thread-Topic: IPv6 multicast and tunnels (RE: [v6ops] v6ops Digest, Vol 52, Issue 41) Thread-Index: AdAYneoY82Wv53sUQ/ibKUllM+RwhAAw3ykAAAX3+dAABbR1gAAQjJlA Date: Tue, 16 Dec 2014 16:35:53 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DB7891@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832DB6F84@XCH-BLV-504.nw.nos.boeing.com> <20141216105212.GQ28745@Space.Net> <2134F8430051B64F815C691A62D9831832DB77EA@XCH-BLV-504.nw.nos.boeing.com> <20141216162627.GB28745@Space.Net> In-Reply-To: <20141216162627.GB28745@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DYW-h_qmrFWdj9tIez5VCPKuGoM Cc: Tariq Saraj , "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41) 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, 16 Dec 2014 16:36:04 -0000 Hi Gert, > -----Original Message----- > From: Gert Doering [mailto:gert@Space.Net] > Sent: Tuesday, December 16, 2014 8:26 AM > To: Templin, Fred L > Cc: Gert Doering; Tariq Saraj; v6ops@ietf.org > Subject: Re: IPv6 multicast and tunnels (RE: [v6ops] v6ops Digest, Vol 52= , Issue 41) >=20 > Hi, >=20 > On Tue, Dec 16, 2014 at 04:09:30PM +0000, Templin, Fred L wrote: > > Any link- or site-scoped multicast is a valid use case, keeping an open= mind > > about possibilities. >=20 > "valid use case" is nice and shiny, but if people don't actually *use* it= , > I don't see the issue why one would need to complain that a certain > (temporary) technology doesn't support it. There is a certain "if we build it, they will come" aspect to this. IPv6 li= nks should support multicast if possible. And, for tunnels, the underlying network is the "link". =20 > Please stick to the general topic the thread started with: a complaint fr= om > academia that certain migration technologies have been pushed out into > operations without taking care to support multicast. Huh? This is v6ops, and we are discussing IPv6 operational considerations. That being multicast support for IPv6 tunnels in whatever context. Thanks - Fred fred.l.templin@boeing.com > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue Dec 16 08:44: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 2DF7F1A1BD6 for ; Tue, 16 Dec 2014 08:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-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 8i_nPmjnb4js for ; Tue, 16 Dec 2014 08:44:46 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 64F811A1B5B for ; Tue, 16 Dec 2014 08:44:45 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id BBE2160A14 for ; Tue, 16 Dec 2014 17:44:42 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 7676E60736 for ; Tue, 16 Dec 2014 17:44:42 +0100 (CET) Received: (qmail 69129 invoked by uid 1007); 16 Dec 2014 17:44:42 +0100 Date: Tue, 16 Dec 2014 17:44:42 +0100 From: Gert Doering To: "Templin, Fred L" Message-ID: <20141216164442.GC28745@Space.Net> References: <2134F8430051B64F815C691A62D9831832DB6F84@XCH-BLV-504.nw.nos.boeing.com> <20141216105212.GQ28745@Space.Net> <2134F8430051B64F815C691A62D9831832DB77EA@XCH-BLV-504.nw.nos.boeing.com> <20141216162627.GB28745@Space.Net> <2134F8430051B64F815C691A62D9831832DB7891@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kv+YhDt3mPDK4YZd" Content-Disposition: inline In-Reply-To: <2134F8430051B64F815C691A62D9831832DB7891@XCH-BLV-504.nw.nos.boeing.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZPusADvneIkO-XFb86JOtN5hZs0 Cc: Tariq Saraj , "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41) 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, 16 Dec 2014 16:44:51 -0000 --kv+YhDt3mPDK4YZd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Dec 16, 2014 at 04:35:53PM +0000, Templin, Fred L wrote: > > "valid use case" is nice and shiny, but if people don't actually *use* = it, > > I don't see the issue why one would need to complain that a certain > > (temporary) technology doesn't support it. >=20 > There is a certain "if we build it, they will come" aspect to this.=20 Yeah, I used to believe that. 10+ years ago, and built a nice and shiny IPv4 multicast network, with MBGP, MSDP, and you name it. And got our upstream providers to support it as well, etc. Guess what? It didn't. Disabled all of it about 3 years ago, because it was a nuisance to maintain, and the single user had long left. > IPv6 links > should support multicast if possible. And, for tunnels, the underlying > network is the "link". This is a particular model for a tunnel - other tunnels are just plain point to point. They could support multicast, but link local multicast doesn't go very far then ("to the other end") and routed multicast just doesn't exist out there, except certain niche applications. =46rom an operational perspective, supporting routed multicast means "being able to debug user problems", and *this* usually means "look at every single router on the SPF tree if it doesn't work", and *that* means "it's just not sustainable if it passes administrative boundaries". Bang, dead. Except for niches like stock market delivery (very well=20 controlled closed environment) and TV streaming (local to the ISP, very well controlled environment)... > > Please stick to the general topic the thread started with: a complaint = =66rom > > academia that certain migration technologies have been pushed out into > > operations without taking care to support multicast. >=20 > Huh? This is v6ops, and we are discussing IPv6 operational considerations. > That being multicast support for IPv6 tunnels in whatever context. Yes, totally so. Just discuss anything in any thread, that really helps people to follow a discussion. 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 --kv+YhDt3mPDK4YZd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVJBhet9WwGXkzn/FAQLm+w/9HWbeKHuCUUSzVp6ZqG5n+kbc7m3m7ar9 SwOLGK6qSGiKNnOJlFpZw6MGTxqu7FBaeKaQcQIciupYqeaG+V3ZwXyQnauHpNox qGczePGRSdQgQEH/VCfocB71jFS4j8BsiMzDL8CojCZNsxCXT141lLRxSj4i+wjN GxPQgodzYGU1I+8uvJA4KEKv7YHy6ROnhCiNcxFF53LspetHNhoxgVRxO/NbpUnl 664d/tU45RX5PpXe2ikOhXHrYxlMSP1dHvACkPp686yK1vi3eQv13H2xdHq/0iMn r5yJtphyDDKwPib9QM+VtMn6Sq/3vKP0ZMY8jTl22xjDEfuAJwdaw+jorarVne4W 1smkhj57Gs6vVEdw00LISAOthfeh2bcqiTZsOiacm4oSUxRWiZE5InZxIEGoB5Zp CjrjrKONoOSSG7GFtHmZaiUWCveENycgnKJ4BBMQ/1pDluOyOkLzxkm4ToW4nD5v VruXD1UI4mcA/zHAvfxcGbFENgR9FgjCEd3S/NkdBhj/LZOnA7rtsiqKuOpVNo8y NlGzEJAVsR5gN8Bhh6UJ5X0i8pdUzo2rsY8mzUxb/+b+LJ0rcn1O/uZiuTg9Cvrp g/lZQq1NGerqKxJd/yFTtFyflKwKKME8Log+ampiPbR21eY6GJknsR/wyDoq+9qF 6sdN4VKSq9A= =LO17 -----END PGP SIGNATURE----- --kv+YhDt3mPDK4YZd-- From nobody Tue Dec 16 08:56: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 623AA1A1EE8 for ; Tue, 16 Dec 2014 08:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 o3pnC-R9lKkJ for ; Tue, 16 Dec 2014 08:56:19 -0800 (PST) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 921CC1A1B05 for ; Tue, 16 Dec 2014 08:56:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sBGGuI31006710; Tue, 16 Dec 2014 10:56:18 -0600 Received: from XCH-PHX-413.sw.nos.boeing.com (xch-phx-413.sw.nos.boeing.com [10.57.37.45]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sBGGuFZP006688 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 16 Dec 2014 10:56:16 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-PHX-413.sw.nos.boeing.com ([169.254.13.86]) with mapi id 14.03.0210.002; Tue, 16 Dec 2014 08:56:15 -0800 From: "Templin, Fred L" To: Gert Doering Thread-Topic: IPv6 multicast and tunnels (RE: [v6ops] v6ops Digest, Vol 52, Issue 41) Thread-Index: AdAYneoY82Wv53sUQ/ibKUllM+RwhAAw3ykAAAX3+dAABbR1gAAQjJlA//+AtACAAIR7oA== Date: Tue, 16 Dec 2014 16:56:14 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DB791A@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832DB6F84@XCH-BLV-504.nw.nos.boeing.com> <20141216105212.GQ28745@Space.Net> <2134F8430051B64F815C691A62D9831832DB77EA@XCH-BLV-504.nw.nos.boeing.com> <20141216162627.GB28745@Space.Net> <2134F8430051B64F815C691A62D9831832DB7891@XCH-BLV-504.nw.nos.boeing.com> <20141216164442.GC28745@Space.Net> In-Reply-To: <20141216164442.GC28745@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qRfY52wSvO91BIlkPfp7KWVAfNo Cc: Tariq Saraj , "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41) 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, 16 Dec 2014 16:56:21 -0000 Hi Gert, > -----Original Message----- > From: Gert Doering [mailto:gert@Space.Net] > Sent: Tuesday, December 16, 2014 8:45 AM > To: Templin, Fred L > Cc: Gert Doering; Tariq Saraj; v6ops@ietf.org > Subject: Re: IPv6 multicast and tunnels (RE: [v6ops] v6ops Digest, Vol 52= , Issue 41) >=20 > Hi, >=20 > On Tue, Dec 16, 2014 at 04:35:53PM +0000, Templin, Fred L wrote: > > > "valid use case" is nice and shiny, but if people don't actually *use= * it, > > > I don't see the issue why one would need to complain that a certain > > > (temporary) technology doesn't support it. > > > > There is a certain "if we build it, they will come" aspect to this. >=20 > Yeah, I used to believe that. 10+ years ago, and built a nice and shiny > IPv4 multicast network, with MBGP, MSDP, and you name it. And got our > upstream providers to support it as well, etc. >=20 > Guess what? It didn't. Disabled all of it about 3 years ago, because it > was a nuisance to maintain, and the single user had long left. Now you are needing to speak of specific use cases where multicast is or is not present. And, I know of use cases where multicast traffic is more prevalent than unicast (and routed multicast in particular). > > IPv6 links > > should support multicast if possible. And, for tunnels, the underlying > > network is the "link". >=20 > This is a particular model for a tunnel - other tunnels are just plain > point to point. They could support multicast, but link local multicast > doesn't go very far then ("to the other end") and routed multicast just > doesn't exist out there, except certain niche applications. I am interested in all domains of applicability. > From an operational perspective, supporting routed multicast means "being > able to debug user problems", and *this* usually means "look at every sin= gle > router on the SPF tree if it doesn't work", and *that* means "it's just > not sustainable if it passes administrative boundaries". >=20 > Bang, dead. Except for niches like stock market delivery (very well > controlled closed environment) and TV streaming (local to the ISP, very > well controlled environment)... You are considering only a very limited class of uses then. I am looking at the bigger picture - one solution that fits all uses. While at the same time providing support for a service that can be turned on at a later time if it is not currently being used. > > > Please stick to the general topic the thread started with: a complain= t from > > > academia that certain migration technologies have been pushed out int= o > > > operations without taking care to support multicast. > > > > Huh? This is v6ops, and we are discussing IPv6 operational consideratio= ns. > > That being multicast support for IPv6 tunnels in whatever context. >=20 > Yes, totally so. Just discuss anything in any thread, that really helps > people to follow a discussion. Right, so let's then say we are discussion multicast support for IPv6 tunne= ls wherever they happen to be deployed. And, we have one solution that fits all use cases. Thanks - Fred fred.l.templin@boeing.com > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue Dec 16 08:58: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 D9FA11A1BED for ; Tue, 16 Dec 2014 08:58:46 -0800 (PST) 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_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 PWf4-jYzTzsE for ; Tue, 16 Dec 2014 08:58:45 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7941A1B05 for ; Tue, 16 Dec 2014 08:58:44 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.9) with ESMTP id sBGGwZRK018563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2014 16:58:36 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <549064BB.3050007@inex.ie> Date: Tue, 16 Dec 2014 16:58:35 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Gert Doering , "Templin, Fred L" References: <2134F8430051B64F815C691A62D9831832DB6F84@XCH-BLV-504.nw.nos.boeing.com> <20141216105212.GQ28745@Space.Net> <2134F8430051B64F815C691A62D9831832DB77EA@XCH-BLV-504.nw.nos.boeing.com> <20141216162627.GB28745@Space.Net> <2134F8430051B64F815C691A62D9831832DB7891@XCH-BLV-504.nw.nos.boeing.com> <20141216164442.GC28745@Space.Net> In-Reply-To: <20141216164442.GC28745@Space.Net> X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/dXusxPEuyIMAKIgTJzFZWqt9Z_s Cc: Tariq Saraj , "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41) 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, 16 Dec 2014 16:58:47 -0000 On 16/12/2014 16:44, Gert Doering wrote: > Guess what? It didn't. Disabled all of it about 3 years ago, because it > was a nuisance to maintain, and the single user had long left. I just canned inter-domain multicast on INEX yesterday. Good times. Nick From nobody Wed Dec 17 02:48: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 5F0C51A8894 for ; Wed, 17 Dec 2014 02:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.428 X-Spam-Level: X-Spam-Status: No, score=0.428 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, 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 zUJ9Fx0ReyKc for ; Wed, 17 Dec 2014 02:48:49 -0800 (PST) Received: from smtp06.msg.oleane.net (smtp06.msg.oleane.net [62.161.4.6]) by ietfa.amsl.com (Postfix) with ESMTP id 11FF31A1BBB for ; Wed, 17 Dec 2014 02:48:48 -0800 (PST) Received: from MGosseDellM6800 ([46.218.58.213]) (authenticated) by smtp06.msg.oleane.net (MSA) with ESMTP id sBHAiqqm005723 for ; Wed, 17 Dec 2014 11:44:52 +0100 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Wed, 17 Dec 2014 11:48:47 +0100 Message-ID: <003e01d019e7$0922cdc0$1b686940$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01D019EF.6AEBC9A0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdAZ5wS0GsnzJbaqQLy7Y1xXrNQyOg== Content-Language: fr X-Backend: vm-smtp-sophos17v3 X-PMX-Spam: Probability=9% X-PFSI-Info: PMX 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.17.102721 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/loRHrHvvlRxqan_S_z_FZBb-soc Subject: [v6ops] V6 World Congress Paris March 2015 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, 17 Dec 2014 10:48:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003F_01D019EF.6AEBC9A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 2015 edition of V6 World will focus on IPv6 centric, country deployment status and measurement. The agenda will also place particular emphasis on open source issues. Other sessions will cover in detail SDN, NFV and IoT challenges. More info: http://www.uppersideconferences.com/ipv6/v6_world_2015_agenda_conference_day _1.html ------=_NextPart_000_003F_01D019EF.6AEBC9A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 2015 edition of = V6 World will focus on IPv6 centric, country deployment status and = measurement.

The agenda will also place particular emphasis on = open source issues. Other sessions will cover in detail SDN, NFV and = IoT = challenges. 

 

More info: http://www.uppersideconferences.com/ipv6/v6_world_201= 5_agenda_conference_day_1.html

 

 

------=_NextPart_000_003F_01D019EF.6AEBC9A0-- From nobody Thu Dec 18 01:28: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 8182B1A6F8A for ; Thu, 18 Dec 2014 01:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 yrHsBwn0pT7w for ; Thu, 18 Dec 2014 01:28:08 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 747121A6F68 for ; Thu, 18 Dec 2014 01:28:08 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sBI9S6MF031295 for ; Thu, 18 Dec 2014 10:28:06 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 91AEE2019AF for ; Thu, 18 Dec 2014 10:28:30 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 74B2C200B3C for ; Thu, 18 Dec 2014 10:28:30 +0100 (CET) Received: from [127.0.0.1] ([132.166.86.24]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sBI9S3Vs024682 for ; Thu, 18 Dec 2014 10:28:05 +0100 Message-ID: <54929E23.1040608@gmail.com> Date: Thu, 18 Dec 2014 10:28:03 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <548B8EBA.7000200@network-heretics.com> <4DDC3299-2A1F-4E9C-8B25-4D1C47E08FFE@cisco.com> <548C9CBF.4000407@gmail.com> In-Reply-To: <548C9CBF.4000407@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/O9m02rBtDkquccUnpjd69LTUV7k Subject: Re: [v6ops] stats on 6to4 use (was: Fwd: I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt) 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, 18 Dec 2014 09:28:10 -0000 Le 13/12/2014 21:08, Brian E Carpenter a écrit : [...] > We have observations from a couple of sources (Google, which > whether you like it or not, sees traffic from a very large > proportion of ordinary users, and Geoff Huston's work, which > obviously sees a much more restricted cross-section of users). When people say google stats, do they mean IPv6 or 6to4 use? I am still looking for relevant and recent statistics about the use of 6to4[*]. Because the earlier 6to4 statistics (vyncke, potaroo and others [**]) show a fair share of 6to4 use in IPv6. Alex [**] https://labs.ripe.net/Members/mirjam/content-ipv6-measurement-compilation [*]I am aware of the following IPv6 stats, but cant see 6to4 in there: http://v6demon.ipv6observatory.eu/ http://labs.apnic.net/ipv6-measurement/ http://6lab.cisco.com/index.php http://www.google.com/intl/en/ipv6/statistics.html http://www.worldipv6launch.org/measurements/ http://v6launch.ripe.net/ http://www.ipv6actnow.org/info/statistics/ http://www.akamai.com/ipv6 http://www.arbornetworks.com/asert/category/ipv6/ (there is an additional set of per-country efforts to show IPv6 statistics for Brazil, US, France and maybe others). From nobody Thu Dec 18 02:48: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 A92B01A3B9B for ; Thu, 18 Dec 2014 02:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 Ifv7Z2Xi41hY for ; Thu, 18 Dec 2014 02:48:00 -0800 (PST) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d: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 6691F1A1BBF for ; Thu, 18 Dec 2014 02:48:00 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id b13so700539qcw.34 for ; Thu, 18 Dec 2014 02:47:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=oI08YAwLUjDby4h0GTFnW2l05tQmqe+ri9vmIUlghD0=; b=KITugakNFPEXltdTfZ0+PDyO/QVUhC8xyWxYCDMImQtVeF0BS2e3a4fOzxpxQ/jJaf O9Aq1QUJtOMY5N+iXEmdRjjxDZjru4lVsqaWJPOEO+mJGdZByEu44fGIw7wAZmOfRgRa Q+l2gpUzP73Uu9h0rIQC0zorDz84TBndNWT1RC4g3LQ0JYUbyS1cD4c3f5vok5Bk3Fnu LoXU8VruSn6VnWZGNEk7pjHUJfnJJolwjXt0cSsUkj8RqNNDPZumhLSpgS621a3/vIuY RYjQL4sDur2hvzkQ4oG1Oc5Wl9yK2n09NhpR6fkTd3V+Q1gb+Dwtq4mmGDnSQAKo3D8q DzzQ== 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=oI08YAwLUjDby4h0GTFnW2l05tQmqe+ri9vmIUlghD0=; b=VW9e8Q86Aax/m1ubQCP/nkKzGm7iqp4gNjQwgUmgUa5O5OEY2EVbal5PAQAT5oFxhk m7ZbyJF9PR9TMpIXLuL8XLUIAGlacdH5L7NkXyGD2TudeYFXO2DrrlDL7XWTFznSenyj MRDRIzLI+1TFJWHSF2wykwR7JzLflJULPA/enLxkzP9DY/0FSqMIz+s3osw9AqSm8shq Ix1ymuNsU+sP/YiUCR1TnW+H/VfxUbi9o8GoQuAQAIB/NgRl6v8goPA//BMruRqdsaUG 5/JULv/fB4GwU09nZjTQl790lojcOOjZvtTGNm2xni5CIjEJK49Sca7mV7NemXFeOiVW Yt8A== X-Gm-Message-State: ALoCoQnFtbHoqTAnM/IFFWlZE5fwhe86ol/nxoZTt/wg99AZqq1Kqhim2mfZ/IseU3oHHYCXg8tD X-Received: by 10.224.128.129 with SMTP id k1mr2278960qas.14.1418899679439; Thu, 18 Dec 2014 02:47:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.29.7 with HTTP; Thu, 18 Dec 2014 02:47:39 -0800 (PST) In-Reply-To: <54929E23.1040608@gmail.com> References: <548B8EBA.7000200@network-heretics.com> <4DDC3299-2A1F-4E9C-8B25-4D1C47E08FFE@cisco.com> <548C9CBF.4000407@gmail.com> <54929E23.1040608@gmail.com> From: Erik Kline Date: Thu, 18 Dec 2014 19:47:39 +0900 Message-ID: To: Alexandru Petrescu Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3d1bD5uPmlQ--H3swqcwW3rnUrM Cc: "v6ops@ietf.org" Subject: Re: [v6ops] stats on 6to4 use (was: Fwd: I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt) 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, 18 Dec 2014 10:48:04 -0000 They're probably referring to the data available at https://ipv6.google.com/ipv6/statistics . From nobody Thu Dec 18 06:57: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 09C081A8A27 for ; Thu, 18 Dec 2014 06:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-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 tc9ANcqlccwv for ; Thu, 18 Dec 2014 06:57:14 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9A411A8A1C for ; Thu, 18 Dec 2014 06:57:13 -0800 (PST) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:6986:91fa:62a6:cb51] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sBIEuZRB084226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 18 Dec 2014 15:56:35 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Iljitsch van Beijnum In-Reply-To: Date: Thu, 18 Dec 2014 15:57:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5D24B2D2-AE08-49DF-8324-36C3754D77E1@muada.com> References: <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141204.111820.41660320.sthaug@nethelp.no> <5480391F.9040902@massar.ch> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NCZnUa8bo5P6nszKc-JqCE8foaA Subject: Re: [v6ops] Quick measurement: MTUs on the general Internet 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, 18 Dec 2014 14:57:16 -0000 I left the tcpdumps running for almost a week and did a more thorough = analysis of the results, see: Maximum packet sizes on the internet=20 http://www.bgpexpert.com/article.php?article=3D151 Internet packet sizes part 2: IPv4 path MTU discovery is dead http://www.bgpexpert.com/article.php?article=3D152 Quick summary: all IPv6 hosts and 99.7% of IPv4 hosts advertise they can = handle at least 1280 bytes in their TCP MSS and about 65% can handle = 1500. In almost a week, I didn't get a single IPv4 too big, so it seems that = in practice, IPv4 PMTUD is no longer used. (Please confirm with a larger = dataset before taking any actions based on this!) However, depending on = PMTUD doesn't lead to obvious problems with IPv6.= From nobody Thu Dec 18 07:29: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 2074A1A1B6B for ; Thu, 18 Dec 2014 07:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 uqexN234PcaL for ; Thu, 18 Dec 2014 07:28:52 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4E241A1B39 for ; Thu, 18 Dec 2014 07:28:51 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id EE62F100BF6F6; Thu, 18 Dec 2014 15:28:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1418916528; bh=mw9rYQx2cmP0YhPl69Gg9Rjv4E0a6bhBqXgey/+p+5Q=; h=Date:From:To:Subject:References:In-Reply-To; b=dIAFwGq5WNAR23urHzJlasYxQ69TPjQ8RQxoCHwuNuRqzOFdFYUTd2Q6JrmU3HKLP bp/OP4dJyawK85lfsv3erH+eOh88QeLQoDockX3cl35kJtLkXlGPX2yUhk4d0zcJJJ Sgrju0PoL2C14IaWRuBs9JOtnxEUYql1i7kG9jkpTTmsQqsVUTFrSysXmtPb4aszd5 VyNLKYC8JsoBn8fj3ooghFsQUBIohNUGu/Op9YomA3xZZujd4onjR69g0WPjB1uf65 ugLFNVfmGv0sNvJSe3/B9ZibfeMQZR+u1Njlq8r4lNYbXR9t6asLqTc+F2wbRU3m/J lCv2XWyc0Dj+g== Message-ID: <5492F2AC.4060908@massar.ch> Date: Thu, 18 Dec 2014 16:28:44 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Iljitsch van Beijnum , "v6ops@ietf.org WG" References: <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141204.111820.41660320.sthaug@nethelp.no> <5480391F.9040902@massar.ch> <5D24B2D2-AE08-49DF-8324-36C3754D77E1@muada.com> In-Reply-To: <5D24B2D2-AE08-49DF-8324-36C3754D77E1@muada.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/EVTXAx3USGYD2MliDnGNq4u_6Ec Subject: Re: [v6ops] Quick measurement: MTUs on the general Internet 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, 18 Dec 2014 15:28:55 -0000 On 2014-12-18 15:57, Iljitsch van Beijnum wrote: > I left the tcpdumps running for almost a week and did a more thorough analysis of the results, see: > > Maximum packet sizes on the internet > http://www.bgpexpert.com/article.php?article=151 "my server received 41753 incoming TCP SYN" .. "Turns out, most of the IPv6 traffic on my server is from bots that check " Sample size too small to represent the Internet which also does not consists out of bots.... ... "1280 and 1480 are probably IPv6-in-IPv4 tunnels and 1428 AYIYA tunnels." If you have the addresses I can tell you exactly what type of tunnels they are if coming from SixXS space[1], though likely it does not matter too much what type it is. As you are looking at MSS, most clients are configured that the tunnel has a MTU of 1280 while the local network announces a MTU of 1500 and thus a MSS of 1500-overhead. Hence, you will see an MSS for 1500 and then get a PTB from the PoP the tunnel terminates on for the first reply packet. MSS clamping on tunnel PoPs is not being done as that would hide problems with any other protocol than TCP and thus would make debugging a real hell "TCP works, but hey, UDP does not WTF!" etc... Greets, Jeroen [1] https://www.sixxs.net/pops/prefixes/ From nobody Thu Dec 18 07:30: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 E99CC1A1B42 for ; Thu, 18 Dec 2014 07:30:26 -0800 (PST) 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 M6FsODxvN3CY for ; Thu, 18 Dec 2014 07:30:25 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id D6D381A8A15 for ; Thu, 18 Dec 2014 07:30:24 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1Y1d1y-0000BkC; Thu, 18 Dec 2014 16:30:22 +0100 Message-Id: To: Alexandru Petrescu From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <548B8EBA.7000200@network-heretics.com> <4DDC3299-2A1F-4E9C-8B25-4D1C47E08FFE@cisco.com> <548C9CBF.4000407@gmail.com> <54929E23.1040608@gmail.com> In-reply-to: Your message of "Thu, 18 Dec 2014 10:28:03 +0100 ." <54929E23.1040608@gmail.com> Date: Thu, 18 Dec 2014 16:30:21 +0100 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/MTLUFiyFCgnQI74WBC1qamakG3Y Cc: v6ops@ietf.org Subject: Re: [v6ops] stats on 6to4 use (was: Fwd: I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt) 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, 18 Dec 2014 15:30:27 -0000 In your letter dated Thu, 18 Dec 2014 10:28:03 +0100 you wrote: >Because the earlier 6to4 statistics (vyncke, potaroo and others [**]) = > >show a fair share of 6to4 use in IPv6. I got some statistics for one of our websites. It shows around 30 6to4 addresses out of around 10000 unique IPv6 addresses. Per month. Based on browser strings, this seems mostly Vista installs. Though there is also some MacOS. From nobody Thu Dec 18 07:36: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 EBF851A8BC4 for ; Thu, 18 Dec 2014 07:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.4 X-Spam-Level: X-Spam-Status: No, score=-3.4 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, J_CHICKENPOX_34=0.6] 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 TqXOF3ICUJxU for ; Thu, 18 Dec 2014 07:36:39 -0800 (PST) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55F4C1A8FD6 for ; Thu, 18 Dec 2014 07:36:15 -0800 (PST) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:1620:f42:42:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 159F3100389C1; Thu, 18 Dec 2014 15:36:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1418916973; bh=hNZ6EDRzccbKvNhQHzjQuA5CsSL/1v39hYQRohsBVPM=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=u2XXVU8rGt5gbUadakB35T+fUhP+BZjNYrm7wHUORUraW9uk8Z0mMqHpX7fZ83SaB bN9fQuRzsiUl5FEALN3RU9vos86CJg5Y8NwSPdZ9HgOVbLI5nE3tnzO5VPm8aBp1+7 PtJPUF7DzvYAdcRN3m8CgBqTfIKKC6o5X+BsGENQ8ckEk0wODgtcO5uI+Jk36N2yAf foVpM9R0BCf83BhSpfo6iACZ4p0aOydxO9x0nAhW5MAVZntHSmSLEMRo3Z3mNXBkIa rVN7IcFzuwaB/aqAhSzhVSOXK14QOjuAFBHze3UPw9UmSx7rJhey17W/lppjahMhJC p6ZBrzq8wpMyg== Message-ID: <5492F46B.3070007@massar.ch> Date: Thu, 18 Dec 2014 16:36:11 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Philip Homburg , Alexandru Petrescu References: <548B8EBA.7000200@network-heretics.com> <4DDC3299-2A1F-4E9C-8B25-4D1C47E08FFE@cisco.com> <548C9CBF.4000407@gmail.com> <54929E23.1040608@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Do6Gvx17YoBbtmZSsQxZEMCJ5mE Cc: v6ops@ietf.org Subject: Re: [v6ops] stats on 6to4 use 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, 18 Dec 2014 15:36:41 -0000 On 2014-12-18 16:30, Philip Homburg wrote: > In your letter dated Thu, 18 Dec 2014 10:28:03 +0100 you wrote: >> Because the earlier 6to4 statistics (vyncke, potaroo and others [**]) = >> >> show a fair share of 6to4 use in IPv6. > > I got some statistics for one of our websites. It shows around 30 6to4 > addresses out of around 10000 unique IPv6 addresses. Per month. > > Based on browser strings, this seems mostly Vista installs. Though there > is also some MacOS. I checked the IPv6Gate logs earlier today and found both 6to4 and Teredo at small quantities compared to other requests coming in from almost any kind of combination of OS, including OSX, Ubuntu and various kinds of Windows, including "Windows NT 6.3" which thus means that people on purpose turn 6to4 and Teredo on to get access to *.sixxs.org and apparently what a lot of naughty (oh, shocker) things they can't get behind their firewalls... Greets, Jeroen From nobody Thu Dec 18 07:55: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 194D11A90B4; Thu, 18 Dec 2014 07:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[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 fxp8vAbaidPt; Thu, 18 Dec 2014 07:55:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D99031A8ABF; Thu, 18 Dec 2014 07:55:29 -0800 (PST) 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.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141218155529.3673.11223.idtracker@ietfa.amsl.com> Date: Thu, 18 Dec 2014 07:55:29 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/o6nxanr6yxwYH83U0H5LgCKFdRc Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-siit-dc-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: Thu, 18 Dec 2014 15:55:31 -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 : SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments Author : Tore Anderson Filename : draft-ietf-v6ops-siit-dc-00.txt Pages : 31 Date : 2014-12-18 Abstract: This document describes SIIT-DC, an extension to the Stateless IP/ ICMP Translation (SIIT) algorithm, that makes it ideally suited for use in IPv6 data centre environments. SIIT-DC simultaneously facilitates IPv6 deployment and IPv4 address conservation. The overall SIIT-DC architecture is described, as well as guidelines for operators. Finally, the normative implementation requirements are described, as a list of additions and changes to SIIT. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-siit-dc-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 Thu Dec 18 08:06: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 775191A8AD1 for ; Thu, 18 Dec 2014 08:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 BWlb0Ed8hZkP for ; Thu, 18 Dec 2014 08:06:21 -0800 (PST) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50E741A1B22 for ; Thu, 18 Dec 2014 08:05:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sBIG50ib016020; Thu, 18 Dec 2014 10:05:00 -0600 Received: from XCH-PHX-209.sw.nos.boeing.com (xch-phx-209.sw.nos.boeing.com [130.247.25.29]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sBIG4o1J015472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 18 Dec 2014 10:04:51 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-PHX-209.sw.nos.boeing.com ([169.254.9.31]) with mapi id 14.03.0210.002; Thu, 18 Dec 2014 08:04:50 -0800 From: "Templin, Fred L" To: Iljitsch van Beijnum , "v6ops@ietf.org WG" Thread-Topic: [v6ops] Quick measurement: MTUs on the general Internet Thread-Index: AQHQGtLx0OxIm2STQkGhRLLhm8v1b5yVgUyg Date: Thu, 18 Dec 2014 16:04:49 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DB901F@XCH-BLV-504.nw.nos.boeing.com> References: <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no> <54802E1D.9070401@massar.ch> <20141204.111820.41660320.sthaug@nethelp.no> <5480391F.9040902@massar.ch> <5D24B2D2-AE08-49DF-8324-36C3754D77E1@muada.com> In-Reply-To: <5D24B2D2-AE08-49DF-8324-36C3754D77E1@muada.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/dX2qRR26-PrXYKB-fuIIXVcvMK4 Subject: Re: [v6ops] Quick measurement: MTUs on the general Internet 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, 18 Dec 2014 16:06:25 -0000 Hi Iljitsch, Thanks for this analysis - it correlates with what I have been saying all a= long. There are two magic numbers in the Internet today: 1280 and 1500. For all sizes in between, it is likely attributed to tunnels that clamp the MTU to some degenerate size. Take care of the smalls, and let the bigs take care of themselves: https://datatracker.ietf.org/doc/draft-templin-aerolink/ Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Iljitsch van Bei= jnum > Sent: Thursday, December 18, 2014 6:57 AM > To: v6ops@ietf.org WG > Subject: Re: [v6ops] Quick measurement: MTUs on the general Internet >=20 > I left the tcpdumps running for almost a week and did a more thorough ana= lysis of the results, see: >=20 > Maximum packet sizes on the internet > http://www.bgpexpert.com/article.php?article=3D151 >=20 > Internet packet sizes part 2: IPv4 path MTU discovery is dead > http://www.bgpexpert.com/article.php?article=3D152 >=20 > Quick summary: all IPv6 hosts and 99.7% of IPv4 hosts advertise they can = handle at least 1280 bytes in their TCP MSS and about 65% > can handle 1500. >=20 > In almost a week, I didn't get a single IPv4 too big, so it seems that in= practice, IPv4 PMTUD is no longer used. (Please confirm with a > larger dataset before taking any actions based on this!) However, dependi= ng on PMTUD doesn't lead to obvious problems with IPv6. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Dec 18 08:45: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 19A8D1A1B81 for ; Thu, 18 Dec 2014 08:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 5WbesZekUawX for ; Thu, 18 Dec 2014 08:45:31 -0800 (PST) Received: from ITSNT447.iowa.uiowa.edu (itsnt447.iowa.uiowa.edu [128.255.67.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05AFD1A1B8A for ; Thu, 18 Dec 2014 08:45:30 -0800 (PST) Received: from ITSNT440.iowa.uiowa.edu ([169.254.2.251]) by ITSNT447.iowa.uiowa.edu ([128.255.67.11]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 10:45:29 -0600 From: "Metzler, Dan J" To: Alexandru Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] stats on 6to4 use (was: Fwd: I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt) Thread-Index: AQHQGqT0yxdfdUPqukiQADcJWP1Xc5yVY2qQ Date: Thu, 18 Dec 2014 16:45:28 +0000 Message-ID: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DF6DCDF@ITSNT440.iowa.uiowa.edu> References: <548B8EBA.7000200@network-heretics.com> <4DDC3299-2A1F-4E9C-8B25-4D1C47E08FFE@cisco.com> <548C9CBF.4000407@gmail.com> <54929E23.1040608@gmail.com> In-Reply-To: <54929E23.1040608@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.255.6.15] 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/t14f0WSMCnnvNNV-oc_06vF9iDg Subject: Re: [v6ops] stats on 6to4 use (was: Fwd: I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt) 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, 18 Dec 2014 16:45:42 -0000 Hi Alex, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru > Petrescu > Sent: Thursday, December 18, 2014 3:28 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] stats on 6to4 use (was: Fwd: I-D Action: draft-ietf-= v6ops- > 6to4-to-historic-09.txt) >=20 > Le 13/12/2014 21:08, Brian E Carpenter a =E9crit : > [...] > > We have observations from a couple of sources (Google, which whether > > you like it or not, sees traffic from a very large proportion of > > ordinary users, and Geoff Huston's work, which obviously sees a much > > more restricted cross-section of users). >=20 > When people say google stats, do they mean IPv6 or 6to4 use? I am still > looking for relevant and recent statistics about the use of 6to4[*]. I don't see how you're going to find any meaningful statistics in the near = future. The problem with using Google for 6to4 stats, to represent internet usage, = is that 6to4 is decentralized. Any stats that anyone posts are a snapshot = in time, of one small portion of the internet. (Even if it is Google.) 1) Since 6to4 is a transition technology, it will likely have its ups and d= owns anyway. There is constant pressure for the number to go up as people i= mplement 6to4 enabled systems. There is also constant pressure for it to g= o down as people implement native IPv6 or other transition technologies. T= he result is use may be up one day, down the next, and up again the next. 2) In order for a company like Google to become a reliable indicator of 6to= 4 usage on the internet, Google would have to become the central hub of the= internet. As much as Google fans may like to think so, it isn't really th= at. 3) And, in order for a company like Google to become a reliable indicator o= f 6to4, they would need to implement IPv6 only. (Get rid of their IPv4 inf= rastructure.) This is necessary to force 6to4 hosts to actually use the 6t= o4 connection, and to my knowledge it is not that either. Keep in mind that properly configured modern hosts will prefer IPv4 over 6t= o4 in most cases, even if 6to4 is used for access to IPv6 only sites. (Some older hosts like Windows Vista, might prefer 6to4 over IPv4, but thes= e would be pretty sparse, and are likely the kind of hosts that show up in = reports from dual stack networks.) That means you can measure a given location, and get use of 6to4 at that lo= cation, at that point in time, but that limits the usefulness of such a mea= surement. >=20 > Because the earlier 6to4 statistics (vyncke, potaroo and others [**]) sho= w a > fair share of 6to4 use in IPv6. >=20 While this indicates that 6to4 is in use, it is likely a conservative estim= ate. If a site like Google would entirely shut off their IPv4 connectivity, and = advertise only IPv6 for a while, that would provide more interesting statis= tics. - Dan From nobody Thu Dec 18 08:54: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 1B0101A1B06 for ; Thu, 18 Dec 2014 08:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 amWBX-D4-kMg for ; Thu, 18 Dec 2014 08:54:24 -0800 (PST) Received: from ITSNT447.iowa.uiowa.edu (itsnt447.iowa.uiowa.edu [128.255.67.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75CA91A8AE8 for ; Thu, 18 Dec 2014 08:54:16 -0800 (PST) Received: from ITSNT440.iowa.uiowa.edu ([169.254.2.251]) by ITSNT447.iowa.uiowa.edu ([128.255.67.11]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 10:54:15 -0600 From: "Metzler, Dan J" To: Philip Homburg , Alexandru Petrescu Thread-Topic: [v6ops] stats on 6to4 use (was: Fwd: I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt) Thread-Index: AQHQGqT0yxdfdUPqukiQADcJWP1Xc5yVedRCgAAWUoA= Date: Thu, 18 Dec 2014 16:54:15 +0000 Message-ID: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DF6DD38@ITSNT440.iowa.uiowa.edu> References: <548B8EBA.7000200@network-heretics.com> <4DDC3299-2A1F-4E9C-8B25-4D1C47E08FFE@cisco.com> <548C9CBF.4000407@gmail.com> <54929E23.1040608@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.255.6.15] 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/zJoujjc5_kXOSq_efzqDmsXf-As Cc: "v6ops@ietf.org" Subject: Re: [v6ops] stats on 6to4 use (was: Fwd: I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt) 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, 18 Dec 2014 16:54:26 -0000 Hi Philip, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Philip Homburg > Sent: Thursday, December 18, 2014 9:30 AM > To: Alexandru Petrescu > Cc: v6ops@ietf.org > Subject: Re: [v6ops] stats on 6to4 use (was: Fwd: I-D Action: draft-ietf-= v6ops- > 6to4-to-historic-09.txt) >=20 > In your letter dated Thu, 18 Dec 2014 10:28:03 +0100 you wrote: > >Because the earlier 6to4 statistics (vyncke, potaroo and others [**]) = =3D > > > >show a fair share of 6to4 use in IPv6. >=20 > I got some statistics for one of our websites. It shows around 30 6to4 > addresses out of around 10000 unique IPv6 addresses. Per month. >=20 > Based on browser strings, this seems mostly Vista installs. Though there = is > also some MacOS. If your websites are dual stack, then this is more an indicator of hosts th= at are configured with 6to4 preferred over IPv4. In that case, it does not really say anything about 6to4 usage as a whole. If your websites are IPv6 only, then the numbers are more meaningful. >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Dec 18 09:45: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 878FD1A1BD4 for ; Thu, 18 Dec 2014 09:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7] 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 4eMplAGaMzBr for ; Thu, 18 Dec 2014 09:45:27 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 328BE1A1B8E for ; Thu, 18 Dec 2014 09:45:26 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1Y1f8e-0000BBC; Thu, 18 Dec 2014 18:45:24 +0100 Message-Id: To: "Metzler, Dan J" From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <548B8EBA.7000200@network-heretics.com> <4DDC3299-2A1F-4E9C-8B25-4D1C47E08FFE@cisco.com> <548C9CBF.4000407@gmail.com> <54929E23.1040608@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DF6DD38@ITSNT440.iowa.uiowa.edu> In-reply-to: Your message of "Thu, 18 Dec 2014 16:54:15 +0000 ." <9062DD5BB047BF4C96BCE0CB9DA96D1B4DF6DD38@ITSNT440.iowa.uiowa.edu> Date: Thu, 18 Dec 2014 18:45:17 +0100 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/GYtUFOQmpdF47UB4sxqI-ZEOo2w Cc: "v6ops@ietf.org" Subject: Re: [v6ops] stats on 6to4 use (was: Fwd: I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt) 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, 18 Dec 2014 17:45:30 -0000 In your letter dated Thu, 18 Dec 2014 16:54:15 +0000 you wrote: >If your websites are dual stack, then this is more an indicator of hosts that >are configured with 6to4 preferred over IPv4. >In that case, it does not really say anything about 6to4 usage as a whole. > >If your websites are IPv6 only, then the numbers are more meaningful. They are dual stacked. Of course, you can try to extrapolate, what's the percentage of Vista in overall web clients, ... The main thing is, there is some use. So it is unwise to actively break 6to4 for those people. At the same time, it is such a small percentage. It is probably not worth optimising for those people either. Personally, I was mostly curious about the browser stats. From nobody Thu Dec 18 14:07: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 3BA451A9088 for ; Thu, 18 Dec 2014 14:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.536 X-Spam-Level: ** X-Spam-Status: No, score=2.536 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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, IP_NOT_FRIENDLY=0.334, 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 u5kVADK8lRlN for ; Thu, 18 Dec 2014 14:06:41 -0800 (PST) Received: from nm50-vm10.bullet.mail.gq1.yahoo.com (nm50-vm10.bullet.mail.gq1.yahoo.com [67.195.87.250]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 823F81A908C for ; Thu, 18 Dec 2014 14:06:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1418940400; bh=Xey2D5vhpb9CTehcIhepHxp00nKsNiEKPhiN5eMFkyw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=B640kRDrn6ivcbOWaA5yTiKaI2mtD7fcVs/Atx065PNJ2WR2Tp24UHmUiSH0LMpfe677uX9m1KHZUFADkG+d0co8/n2Xte0J4GPUuMGnn0jjdoJsaMmTzAw02Iu1z0Kt5ott2ZQ/ok4n+YZJGAp2rGJgW2ZWt4Ps9Y7py6dZXP48p8xHH4H6SKdTFE7ziyoE5gEeMmG4LunQ7ZCfW6ZvgqXA7ayC31x/9MRrnwRmbSexrP9n0+9J373cO5pvH2F+A+kIGWnDh3OXFd3OqCPS6TUTxqSDgcoIpOR33H6sBjI61/shDiLTS1OEHZms8OhFyU3XAC8TgupUtrNp6oOVng== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com.au; b=GcvVDdQ25mQV50Qaxcw25vBK9W35LHZpfSa7W+z52IXofefaIUzfxx7rfndiKsgbnV1lOPhpNiNwF6QHeClQbCbnLcQIKm3miDtaJffcQyq/bXw87mq2Z4hCjiBpGpbpVFmfBZrVstCP+ShB2fwMR8j2svye+bfNIiFLmpbGIqnVZh8VNW+P8fcC4Ns80o4RX0W3Dls2U4mrq6l7XYIhyz0Uall/ui6LcHgk7l3nvaLEO1JsBZP9s0T41kWIgHXcXqO5zUoYNIGdgD4RMCYbs0ED7WlunCsQZztyZCXXeh1naq230wRRgInTwLawR1KNwQaw5RoCO92UiUW4UkEezg==; Received: from [127.0.0.1] by nm50.bullet.mail.gq1.yahoo.com with NNFMP; 18 Dec 2014 22:06:40 -0000 Received: from [98.137.12.189] by nm50.bullet.mail.gq1.yahoo.com with NNFMP; 18 Dec 2014 22:03:41 -0000 Received: from [98.139.215.143] by tm10.bullet.mail.gq1.yahoo.com with NNFMP; 18 Dec 2014 22:03:41 -0000 Received: from [98.139.212.244] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 18 Dec 2014 22:03:41 -0000 Received: from [127.0.0.1] by omp1053.mail.bf1.yahoo.com with NNFMP; 18 Dec 2014 22:03:41 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 34684.70857.bm@omp1053.mail.bf1.yahoo.com X-YMail-OSG: MKuNPaAVM1mvCPv0rQl3LIEj8XICnJvoDR7EFryS_B86YDAHpGpokvYyro.CsKv pSi0maQxxhG_xNLiQFVSN_wD0AEgEvXb75waeCx4qOp8A2ufJtL00JCtMLK7KtIoFsWMiGv96sMV suTYsQBcakq.qra3aQiNW4FFNrGyKfUEyJy8dXsetGCu9xKTKTqZrr_WzjTybKlnHKjtg8f4LtQ3 dgq9Q5nq0w8MehcO0IW1D2QdinEbpK4rp6pbLI2GYhsve9cypliTE_OEzy0Cbmj3TXrpKzELkFv8 9xZsVmzJs_WZ49Tu8RdYfEzCE6AdPmF2bi_vIoeeden5Fhfa2kDYDslhMoIwAcyyrBSAymmaCVKI DM2vbnjR4Wq3qieCGlA6DSG9gwPLS0HP0BH_TxMNWBJqxYLcEy3W63454jgXjK3J89xWIp35Wjlw IU8NIMwBb50ho6QhOgmeKglWr.4Szn2IfvGnItq7jWRNFrzFSzzaj2AoOzLwkQAame7evlrY6xkK dcIFFF34OzWclfo7r_T9xoca0 Received: by 66.196.80.112; Thu, 18 Dec 2014 22:03:40 +0000 Date: Thu, 18 Dec 2014 22:03:32 +0000 (UTC) From: Mark ZZZ Smith To: Gert Doering , Tariq Saraj Message-ID: <1268459925.1012661.1418940212755.JavaMail.yahoo@jws106146.mail.bf1.yahoo.com> In-Reply-To: <20141215180113.GK28745@Space.Net> References: <20141215180113.GK28745@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DE2sgrd04i-4OcxWwZmaSKQ9zoE Cc: "v6ops@ietf.org" Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 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, 18 Dec 2014 22:06:43 -0000 ----- Original Message ----- > From: Gert Doering > To: Tariq Saraj > Cc: v6ops@ietf.org > Sent: Tuesday, 16 December 2014, 5:01 > Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 > > Hi, > > On Sun, Dec 14, 2014 at 12:18:00AM +0500, Tariq Saraj wrote: >> There are some issues with 6rd as well, IPv6 with all its powerful features >> is still under critical objections in academia just because of the urgency >> shown by IETF in standardizing protocols like 6to4 and 6rd. 6to4 clearly >> mentioned that it cannot support multicast at layer-3, on the other end 6rd >> claimed that multicast can be provided, my question is that while >> standardizing 6rd which at that time was just supporting unicast traffic >> traversing across IPv4 network and its still not matured enough to provide >> multicast support yet in its functionality other than using some proxy >> support for multicast traffic. why It was standardized ? > > There is no wide-area multicast anyway. Technically it should be universal, as DAD uses multicast and DAD is mandatory (except for anycast addresses), which should include tunnels. Links are supposed to provide multicast capability or emulate it to support Neighbor Discovery: RFC4861: "2.2. Link Types Different link layers have different properties. The ones of concern to Neighbor Discovery are: multicast capable - a link that supports a native mechanism at the link layer for sending packets to all (i.e., broadcast) or a subset of all neighbors. point-to-point - a link that connects exactly two interfaces. A point-to-point link is assumed to have multicast capability and a link-local address. non-broadcast multi-access (NBMA) - a link to which more than two interfaces can attach, but that does not support a native form of multicast or broadcast (e.g., X.25, ATM, frame relay, etc.). Note that all link types (including NBMA) are expected to provide multicast service for applications that need it (e.g., using multicast servers). However, it is an issue for further study whether ND should use such facilities or an alternate mechanism that provides the equivalent multicast capability for ND." > So why bother if a closed user > group decides to deploy a stopgap technology to enable IPv6 access. > > And, when speaking about academia: do they have a "how to not write > e-mail" > class there? Like, "take a full digest with lots of unrelated mail in it, > and write a top posting on top of it"? > > 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 > From nobody Thu Dec 18 14:09: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 EC3621A8789 for ; Thu, 18 Dec 2014 14:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 QcZST5ZlOo9C for ; Thu, 18 Dec 2014 14:09:18 -0800 (PST) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9D3F1A8780 for ; Thu, 18 Dec 2014 14:09:17 -0800 (PST) Received: by mail-pd0-f170.google.com with SMTP id v10so2270210pde.1 for ; Thu, 18 Dec 2014 14:09:17 -0800 (PST) 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=p5hjFk/7c3JI/Tw7+aY/T2sKUijXjJyr1Xcu1xURYEg=; b=XPHUULLAUSXxlvbCrLPCM2PB7azeYW+I3iUc/XcGDGPee3LwnfEh3twfklraOt4Bpq 4i2Li7FpcVlRFjoFSKRfOmNd+Aaq4OJIIUYt+WB8soaYdfD5fccPo5Vf5ne1elDC8jZx HvI04/MxzdfD8xxifv+dIkI9KdHwin2n8Mxaegnv5dh5RhLCbOkeYyYPJXkwuJhR90uQ Nk+YxET2Z8G4jfQdX+0kT/wj8Q3Ym1vFXWi9dkp2UlDT3H/deqo3xaK33BZvSxYkRR8V v/lIHFJ/5TWeemYZO6AHNOc/xhEqc9PRKixLMWCzbFDDIzfH8AO1p4R0atUJ8UUtkKlb K+sQ== X-Received: by 10.66.220.134 with SMTP id pw6mr6954704pac.91.1418940557290; Thu, 18 Dec 2014 14:09:17 -0800 (PST) Received: from ?IPv6:2406:e007:74cb:1:28cc:dc4c:9703:6781? ([2406:e007:74cb:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id by8sm5488666pab.25.2014.12.18.14.09.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 14:09:16 -0800 (PST) Message-ID: <54935094.9070706@gmail.com> Date: Fri, 19 Dec 2014 11:09:24 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Erik Kline References: <548B8EBA.7000200@network-heretics.com> <4DDC3299-2A1F-4E9C-8B25-4D1C47E08FFE@cisco.com> <548C9CBF.4000407@gmail.com> <54929E23.1040608@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/bUfjxc4Ql-4iRb0oZivDJEqozr4 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] stats on 6to4 use 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, 18 Dec 2014 22:09:20 -0000 On 18/12/2014 23:47, Erik Kline wrote: > They're probably referring to the data available at > https://ipv6.google.com/ipv6/statistics . > Yes, and Lorenzo confirmed on this list that the traffic identified there as 6to4/Teredo is overwhelmingly 6to4 today. Brian From nobody Thu Dec 18 23:34: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 066E71A1B12 for ; Thu, 18 Dec 2014 23:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.202 X-Spam-Level: ** X-Spam-Status: No, score=2.202 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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, 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 h8Y1Mv8oa8q5 for ; Thu, 18 Dec 2014 23:34:20 -0800 (PST) Received: from nm25-vm1.bullet.mail.bf1.yahoo.com (nm25-vm1.bullet.mail.bf1.yahoo.com [98.139.212.155]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5781A00DF for ; Thu, 18 Dec 2014 23:34:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1418974458; bh=pCokxak5TG47u3sIcaZNr9aSo6pz8wv3reoyhJxVo7w=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=svrz4+7XBeGeWAKtXmgYAa2u5iu7nuGFAXZY2iZ8pNQgQFjbhjmbLPTwI33wqdZMsnCM/1fo75hCYj/+RlN8HkSxUm4A59Y1BX4sOqLIwEHi7VIKy9W0grPELfpCVNk6ltcuejec3ziGJ0fMONHmnCoTD4u2rTZ2JzoyynOdU+jFHN1Iti3vJVqd4hh/7jtj57LOFHy0YvdKBkD24O88jS9s83+fpt7MmIrYmmmomCQNQ/3I0T635jBSKoIwyVnxvKUTQNHFG9LIHOyCgEG0/tHQhTVOnH0cs7Dyup5Fk3LjxM23aUVeqB06A9NU8q51qnp3VHCVA1o6j+UV2OIV3w== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com.au; b=KaeqAVXxHoCXhJadNM3xZyPCF6qGaGh+5T0T+akJrnTukvqC9JD2vqAk3SCbt8+dPraQkFqTa7aCH1lQH+xNtiodmqj4ozyw7damT29fF8KvLISyDZQCniS17g+8VUjzA5IaLYqqWHDofCGUEI4GDTPpGYBP2J8ZwA4CHGImM5+xLoMLqxblwZn9itDHbrtz/NmJPLlRWsWu8RTfFu2M5J8M6LCVcx7UYvIGW1ZUNECmz0NgwdRGpFOa3rlCpep+Bmex3xy+F2d0vqu9saAIkPIWrn+r5dtfhkApOA0ba7L4cUMIOnwxhP7HEuFHOVdMilbwz2A/zK0nB3xgvDIrPg==; Received: from [66.196.81.171] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 19 Dec 2014 07:34:18 -0000 Received: from [98.139.212.245] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 19 Dec 2014 07:34:18 -0000 Received: from [127.0.0.1] by omp1054.mail.bf1.yahoo.com with NNFMP; 19 Dec 2014 07:34:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 951546.83145.bm@omp1054.mail.bf1.yahoo.com X-YMail-OSG: NtJ2tQIVM1mKzpKwmH9oGAchpfuw7ooO5oQzlBZcvDfjXmKJeFnBIIL9RgwunXh G8_G3HUlfdcLHehqnZeIu2QQIMTkbvUppMgvue4XstK.MIpfda4EF3u5WyTunT5k7FY60peonFxQ aLV5DDjkmPRcSlJ6HYIxoxx1vglfJblw5rfYqAHa5cb1ME2mtBvLnjPitB5REtRfHcf8IS_wwQ57 XPCFnN3_qhU2Bpv4jLxVPqcGeRCOv_uMHJYZ7uOl7dYtj2LJ0CtfvsHXQvtoohEbXkk6vphQ173l ikKl457p8U78QdXyJ_zJX4puXYfSncpfT1w1LoKWOfwDi4MIu1q07QL22QEUF2zuNeSJWk8L_pT9 yxn5_YH1iwl..h2g0u3PLhBpaA1wkUdA.bAEykdvbJnvSLEi_ch8N.NvaVteSnhwIjG5nwMEjA1s zLyQ4CuQgD8NwbDHdLq1Pd1mKdDaWEl2xaxzj881AueXX1bEZfNRUyS6rnbOOsJISYCPbD1n7Dli Etvrm2ytxeZv_Wbj1QwWODrM78vF7QR4uU6I7i3TLgVyqDBG3QVIjcu9L7pIWBa_KNch8ybd5M7n h9VA0I5Z.mvWGJBnuUU3hDVkrkgE- Received: by 66.196.81.113; Fri, 19 Dec 2014 07:34:18 +0000 Date: Fri, 19 Dec 2014 07:34:11 +0000 (UTC) From: Mark ZZZ Smith To: Iljitsch van Beijnum , "v6ops@ietf.org WG" Message-ID: <1932458376.1179497.1418974451055.JavaMail.yahoo@jws10608.mail.bf1.yahoo.com> In-Reply-To: <5D24B2D2-AE08-49DF-8324-36C3754D77E1@muada.com> References: <5D24B2D2-AE08-49DF-8324-36C3754D77E1@muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Yi4O5YfF_WF6lSBwMOulLlNfC6k Subject: Re: [v6ops] Quick measurement: MTUs on the general Internet 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: Fri, 19 Dec 2014 07:34:21 -0000 ----- Original Message ----- > From: Iljitsch van Beijnum > To: "v6ops@ietf.org WG" > Cc: > Sent: Friday, 19 December 2014, 1:57 > Subject: Re: [v6ops] Quick measurement: MTUs on the general Internet > > I left the tcpdumps running for almost a week and did a more thorough analysis > of the results, see: > > Maximum packet sizes on the internet > http://www.bgpexpert.com/article.php?article=151 > > Internet packet sizes part 2: IPv4 path MTU discovery is dead > http://www.bgpexpert.com/article.php?article=152 > > Quick summary: all IPv6 hosts and 99.7% of IPv4 hosts advertise they can handle > at least 1280 bytes in their TCP MSS and about 65% can handle 1500. > > In almost a week, I didn't get a single IPv4 too big, so it seems that in > practice, IPv4 PMTUD is no longer used. (Please confirm with a larger dataset > before taking any actions based on this!) I wonder if RFC4821 'probing' based PMTUD is being used instead. A number of years ago I know Windows both supported and enabled it under certain circumstances, so perhaps in more recent versions of Windows it has been enabled by default or in more situatins. > However, depending on PMTUD > doesn't lead to obvious problems with IPv6. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Dec 19 00:25: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 90AD01A1EF5 for ; Fri, 19 Dec 2014 00:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 dLN9SCrimTLo for ; Fri, 19 Dec 2014 00:25:11 -0800 (PST) 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 4C40D1A040B for ; Fri, 19 Dec 2014 00:25:11 -0800 (PST) Received: from [2a02:fe0:c410:c430::1] (port=49793 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Y1ss1-0000TJ-NN; Fri, 19 Dec 2014 09:25:09 +0100 Date: Fri, 19 Dec 2014 09:25:09 +0100 From: Tore Anderson To: v6ops@ietf.org Message-ID: <20141219092509.182717de@envy.fud.no> In-Reply-To: <20141218155529.3673.11223.idtracker@ietfa.amsl.com> References: <20141218155529.3673.11223.idtracker@ietfa.amsl.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Qu57kJkiaoIhzxCgzaZglKv5_d8 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-siit-dc-00.txt 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, 19 Dec 2014 08:25:13 -0000 Hi WG, Changes from the previous version include: - New document name to reflect the WG adoption from Honolulu (thanks, everyone) - Better describe the scenario of gradual migration from dual-stack to SIIT-DC using DNS round robin (thanks, Andrew Yourtchenko) - Note that the IPv4 Identification value will be lost during translation if IPv6 Atomic Fragments are disabled (thanks, Andrew Yourtchenko) - Add a new appendix comparing SIIT-DC to a "partial" dual stack w/IPv6-only back-end infrastructure (thanks, Cameron Byrne) - Various editorial fixes and improvements (idnits/idspell/etc) I have not yet removed the normative language. I intend do so as soon as draft-anderson-siit-eam is adopted as a WG document. Tore * internet-drafts@ietf.org > > 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 : SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments > Author : Tore Anderson > Filename : draft-ietf-v6ops-siit-dc-00.txt > Pages : 31 > Date : 2014-12-18 > > Abstract: > This document describes SIIT-DC, an extension to the Stateless IP/ > ICMP Translation (SIIT) algorithm, that makes it ideally suited for > use in IPv6 data centre environments. SIIT-DC simultaneously > facilitates IPv6 deployment and IPv4 address conservation. The > overall SIIT-DC architecture is described, as well as guidelines for > operators. Finally, the normative implementation requirements are > described, as a list of additions and changes to SIIT. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-siit-dc-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/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Dec 19 02:42: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 860761A8778 for ; Fri, 19 Dec 2014 02:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 E2P2ViIyjfbM for ; Fri, 19 Dec 2014 02:42:10 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDF401A87AF for ; Fri, 19 Dec 2014 02:42:09 -0800 (PST) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:b80c:cb2:6019:b78e] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id sBJAfUOk095512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Dec 2014 11:41:31 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Iljitsch van Beijnum In-Reply-To: <1932458376.1179497.1418974451055.JavaMail.yahoo@jws10608.mail.bf1.yahoo.com> Date: Fri, 19 Dec 2014 11:42:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D24B2D2-AE08-49DF-8324-36C3754D77E1@muada.com> <1932458376.1179497.1418974451055.JavaMail.yahoo@jws10608.mail.bf1.yahoo.com> To: Mark ZZZ Smith X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LfXf1Gk1SR6-1ZKTZNAyc16X-Qk Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Quick measurement: MTUs on the general Internet 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, 19 Dec 2014 10:42:11 -0000 On 19 Dec 2014, at 8:34, Mark ZZZ Smith = wrote: >> In almost a week, I didn't get a single IPv4 too big, so it seems = that in=20 >> practice, IPv4 PMTUD is no longer used. (Please confirm with a larger = dataset=20 >> before taking any actions based on this!) > I wonder if RFC4821 'probing' based PMTUD is being used instead. A = number of years ago I know Windows both supported and enabled it under = certain circumstances I believe RFC 4821 is used for blackhole detection in Windows and = possibly other OSes. My measurements were on a FreeBSD machine, though. However, from the point of view of the network there is no difference = between RFC 1191 style or RFC 4821 style PMTUD: in both cases packets as = large as the MSS are sent with DF set, so if the path MTU is smaller = than the MSS value, there should be too bigs. The only difference is = that if no too bigs make it back to the sending host, RFC 1191 is dead = in the water while RFC 4821 recovers. From nobody Fri Dec 19 03: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 9AB271A902E for ; Fri, 19 Dec 2014 03:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 CB0zAIEljoOh for ; Fri, 19 Dec 2014 03:18:28 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840121A8AE0 for ; Fri, 19 Dec 2014 03:18:25 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sBJBIN21007211 for ; Fri, 19 Dec 2014 12:18:23 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 34C80202284 for ; Fri, 19 Dec 2014 12:18:49 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 22565201B64 for ; Fri, 19 Dec 2014 12:18:49 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sBJBIJ35026239 for ; Fri, 19 Dec 2014 12:18:22 +0100 Message-ID: <5494097B.30207@gmail.com> Date: Fri, 19 Dec 2014 12:18:19 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "v6ops@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/tOvyCI7BXNkRzNnY9LnCqvlX3xE Subject: [v6ops] 6man offspring - draft on prefix length recommendation for forwarding 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, 19 Dec 2014 11:18:33 -0000 Hello, draft-boucadair-6man-prefix-routing-reco-03 is a new draft telling that forwarding processes should work with _arbitrary_ prefix lengths, and not be bound by particular limits, as an autoconfig process like SLAAC/Ethernet is bound by a prefix len max 64. The draft was presented in 6MAN WG at the last IETF meeting in Honolulu[*]. The recommendation was to bring it to v6ops WG. A glimpse to some topics discussed: - worth or not having an RFC, since Internet acted this way since ever. - cheaper searches below 64 and trends. - Interface ID length vs. forwarding recommendation. What do you think? Alex [*] the slides are at http://www.ietf.org/proceedings/91/slides/slides-91-6man-6.pdf Minutes are at: http://www.ietf.org/proceedings/91/minutes/minutes-91-6man (search for 'prefix') From nobody Fri Dec 19 03:38: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 4F09A1A909A for ; Fri, 19 Dec 2014 03:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 Ifen0iwA3xO2 for ; Fri, 19 Dec 2014 03:38:15 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 3659C1A8A96 for ; Fri, 19 Dec 2014 03:38:14 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0642160836 for ; Fri, 19 Dec 2014 12:38:13 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id B66C360A16 for ; Fri, 19 Dec 2014 12:38:12 +0100 (CET) Received: (qmail 63934 invoked by uid 1007); 19 Dec 2014 12:38:12 +0100 Date: Fri, 19 Dec 2014 12:38:12 +0100 From: Gert Doering To: Mark ZZZ Smith Message-ID: <20141219113812.GV28745@Space.Net> References: <20141215180113.GK28745@Space.Net> <1268459925.1012661.1418940212755.JavaMail.yahoo@jws106146.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RtjgDG3y8/gHUPWB" Content-Disposition: inline In-Reply-To: <1268459925.1012661.1418940212755.JavaMail.yahoo@jws106146.mail.bf1.yahoo.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/PKaDAytHzryPDfggIH-2ozkS7rQ Cc: Tariq Saraj , "v6ops@ietf.org" Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 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, 19 Dec 2014 11:38:17 -0000 --RtjgDG3y8/gHUPWB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Dec 18, 2014 at 10:03:32PM +0000, Mark ZZZ Smith wrote: > > There is no wide-area multicast anyway. >=20 > Technically it should be universal, as DAD uses multicast and DAD is mand= atory (except for anycast addresses), which should include tunnels. This is not *wide-area* multicast, but link-local. Slight difference. 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 --RtjgDG3y8/gHUPWB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVJQOJN9WwGXkzn/FAQKDfA//XgTGeSLqZ2HnBH/3edqQ1/okK+Hqqlm8 e3QUkPa8Sj3FjurnwI5lkxMuCQDIc/9MVBFJ3PEHtWlGnW+nv4zduk+IXONhI0Im uAdQlNUdLnwDnwx1bNNGmUzT/02dORHp7gRt62eLorVJ35oACp66+LrXB8/agpxj mprucV0dXmjKS3lh0EmevbX1VKeSw+/iDlp1DflhN/0OpLpinUoyI+N1FeJr7rOV R083nZV25rD3cRO+AzmK3iNV9LEocm0PPud+o7qtUUjyLNEoGipG5dXB7/0Jm0Oy GPFSsexOJ+pnSGpJpcqA2xk7nk7MquRXhAo+15DhE8xhNNrEK1CnjvVf/wZ2Nd4Q b5A81grT6Gmt80lWCKshfFzcnHicLn+pwG/pKbCw7Nr+C7uaSG7PQ95lsY1U2uW0 TDdToPxDzmZQx79x7Ct93u909PlF4Md6q0PWSBjBjX8Ok1Xlq/vQkYcEgP1m4zLZ iAEXSvrcILWH4T79jUcvuszZzyEVW9uEVZWR7QY3QUqHRX5qDxLgBT2RvCUh1BiL gbLXjZGYHW2sUwb9HUQYDhocgITRhP0KSmYUM+8ZxYqDBDlMeWlEejngrCApRahx 7n0isF8QaB7Rzgy6+WqhcLFj7Af2k/+HO0f2BhbPE4Xwt8ETbEFPW+p5MEEiqT3a 9UOQapsr1tM= =FKea -----END PGP SIGNATURE----- --RtjgDG3y8/gHUPWB-- From nobody Fri Dec 19 04:47: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 E5E5D1A876C for ; Fri, 19 Dec 2014 04:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 PN7Z3t1d5ly2 for ; Fri, 19 Dec 2014 04:47:04 -0800 (PST) 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 7756B1A8755 for ; Fri, 19 Dec 2014 04:47:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=124; q=dns/txt; s=iport; t=1418993224; x=1420202824; h=date:from:message-id:to:subject:cc; bh=LBO1knLYG75lp6tmTXEm5TSmvyNKCQy9gfIe/4rvZdg=; b=GCu3WfN9QemO0QS3ck8oGv/vtQbMag/QJqvJnceNxcexw0s03aCqxrdP KwX1xvUF5ak8M2UA9z5yAgVS9pNrrgvpPyGgHa44cgGZdF+y38+1tQ96u SIy/9rooQT4/UkWNguoOtYTTAtfE18olBh8Qy3W93kSjfF2/6xdqBfEe2 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngIAIcdlFStJV2a/2dsb2JhbABagwZSWbcIAY8ahWgJgR0WAQEBAQF9hQw8NIkMAQ3PcgELAR+Pch2EEwWJRYgFhj8wgjKNWSKEDYMRAQEB X-IronPort-AV: E=Sophos;i="5.07,606,1413244800"; d="scan'208";a="106851773" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP; 19 Dec 2014 12:47:04 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBJCl3CY018822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Dec 2014 12:47:03 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id sBJCl24h018827; Fri, 19 Dec 2014 04:47:02 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id sBJCl2NQ018826; Fri, 19 Dec 2014 04:47:02 -0800 Date: Fri, 19 Dec 2014 04:47:02 -0800 From: fred@cisco.com Message-Id: <201412191247.sBJCl2NQ018826@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mv0_ljOmWJqWRyetKYZn6JtXA5w Cc: draft-ietf-v6ops-siit-dc@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-siit-dc 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, 19 Dec 2014 12:47:06 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-siit-dc. Please take a look at it and comment. From nobody Fri Dec 19 06:36: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 309FA1A8935 for ; Fri, 19 Dec 2014 06:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-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 njn0ch5xp9sS for ; Fri, 19 Dec 2014 06:36:40 -0800 (PST) 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 66F3D1A88C8 for ; Fri, 19 Dec 2014 06:36:39 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id hz20so954780lab.34 for ; Fri, 19 Dec 2014 06:36:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=/3i3qLVnipcLlo34ECVWu8nHMgtf4u5crmFj7zwcR8g=; b=oP+RhDzmApyZOpv0pDsfReUv38madpBHjcEtzfilAxrix47CnYro5JpWvIKNEmgpB2 EkRPQtLsBvvAVhamHSIOANyD3mlge15lbXMqLjN//Y0lB6YUvxGMFk2NP5IbzyKyqWCL U/h0h0Mec8n/VV4eEXYmWgIbKE5sCMGmqPRgKR+TKcv/V0joi1cv8UzhkClvdQZ+Nrhw lfYFwy6wkIjLKsLurtKHKm14hNrbrzgQrawBiwMQjJpBuRQpivVb8taSWNIqOqch3Z3C U1VDnmJQc15JUiXETRBVlwftAV4RvUuH1k8ZyU0ohhK081OZDCpj6XjxABDuGROH0WuH 2DVg== MIME-Version: 1.0 X-Received: by 10.152.25.194 with SMTP id e2mr8217901lag.22.1418999797778; Fri, 19 Dec 2014 06:36:37 -0800 (PST) Received: by 10.114.4.132 with HTTP; Fri, 19 Dec 2014 06:36:37 -0800 (PST) In-Reply-To: <1268459925.1012661.1418940212755.JavaMail.yahoo@jws106146.mail.bf1.yahoo.com> References: <20141215180113.GK28745@Space.Net> <1268459925.1012661.1418940212755.JavaMail.yahoo@jws106146.mail.bf1.yahoo.com> Date: Fri, 19 Dec 2014 19:36:37 +0500 Message-ID: From: Tariq Saraj To: Mark ZZZ Smith , v6ops@ietf.org Content-Type: multipart/alternative; boundary=047d7b5db77ae20fe6050a92a20c Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/nv5BKLaA6Q2UvAVXAs2oyIseJaA Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 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, 19 Dec 2014 14:36:43 -0000 --047d7b5db77ae20fe6050a92a20c Content-Type: text/plain; charset=UTF-8 Smith what you are pointing is all at link level and purely related to IPv6, Discussion is related Multicast support in Hybrid IPv4-IPv6 Internet at IP layer (i.e. IPvX-IPvY-IPvX) On Fri, Dec 19, 2014 at 3:03 AM, Mark ZZZ Smith wrote: > > > > > > ----- Original Message ----- > > From: Gert Doering > > To: Tariq Saraj > > Cc: v6ops@ietf.org > > Sent: Tuesday, 16 December 2014, 5:01 > > Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 > > > > Hi, > > > > On Sun, Dec 14, 2014 at 12:18:00AM +0500, Tariq Saraj wrote: > >> There are some issues with 6rd as well, IPv6 with all its powerful > features > >> is still under critical objections in academia just because of the > urgency > >> shown by IETF in standardizing protocols like 6to4 and 6rd. 6to4 > clearly > >> mentioned that it cannot support multicast at layer-3, on the other > end 6rd > >> claimed that multicast can be provided, my question is that while > >> standardizing 6rd which at that time was just supporting unicast > traffic > >> traversing across IPv4 network and its still not matured enough to > provide > >> multicast support yet in its functionality other than using some proxy > >> support for multicast traffic. why It was standardized ? > > > > There is no wide-area multicast anyway. > > Technically it should be universal, as DAD uses multicast and DAD is > mandatory (except for anycast addresses), which should include tunnels. > > Links are supposed to provide multicast capability or emulate it to > support Neighbor Discovery: > > RFC4861: > > "2.2. Link Types > > Different link layers have different properties. The ones of concern > to Neighbor Discovery are: > > multicast capable > - a link that supports a native mechanism at the link > layer for sending packets to all (i.e., broadcast) > or a subset of all neighbors. > > point-to-point - a link that connects exactly two interfaces. A > point-to-point link is assumed to have multicast > capability and a link-local address. > > non-broadcast multi-access (NBMA) > - a link to which more than two interfaces can attach, > but that does not support a native form of multicast > or broadcast (e.g., X.25, ATM, frame relay, etc.). > Note that all link types (including NBMA) are > expected to provide multicast service for > applications that need it (e.g., using multicast > servers). However, it is an issue for further study > whether ND should use such facilities or an > alternate mechanism that provides the equivalent > multicast capability for ND." > > > > > So why bother if a closed user > > group decides to deploy a stopgap technology to enable IPv6 access. > > > > And, when speaking about academia: do they have a "how to not write > > e-mail" > > class there? Like, "take a full digest with lots of unrelated mail in > it, > > and write a top posting on top of it"? > > > > 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 > > > -- Regards Tariq Saraj Center for Research in Networks and Telecom (*CoReNeT*) --047d7b5db77ae20fe6050a92a20c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Smith what you are pointing is all at link level and purel= y related to IPv6, Discussion is related Multicast support in Hybrid IPv4-I= Pv6 Internet at IP layer (i.e. IPvX-IPvY-IPvX) =C2=A0

On Fri, Dec 19, 2014 at 3:03 AM, = Mark ZZZ Smith <markzzzsmith@yahoo.com.au> wrote:



----- Original Message -----
> From: Gert Doering <gert@space.ne= t>
> To: Tariq Saraj <tariqsaraj= @gmail.com>
> Cc: v6ops@ietf.org
> Sent: Tuesday, 16 December 2014, 5:01
> Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41
>
> Hi,
>
> On Sun, Dec 14, 2014 at 12:18:00AM +0500, Tariq Saraj wrote:
>>=C2=A0 There are some issues with 6rd as well, IPv6 with all its po= werful features
>>=C2=A0 is still under critical objections in academia just because = of the urgency
>>=C2=A0 shown by IETF in standardizing protocols like 6to4 and 6rd. = 6to4 clearly
>>=C2=A0 mentioned that it cannot support multicast at layer-3, on th= e other end 6rd
>>=C2=A0 claimed that multicast can be provided, my question is that = while
>>=C2=A0 standardizing 6rd which at that time was just supporting uni= cast traffic
>>=C2=A0 traversing across IPv4 network and its still not matured eno= ugh to provide
>>=C2=A0 multicast support yet in its functionality other than using = some proxy
>>=C2=A0 support for multicast traffic. why It was standardized ?
>
> There is no wide-area multicast anyway.

Technically it should be universal, as DAD uses multicast and DAD is= mandatory (except for anycast addresses), which should include tunnels.
Links are supposed to provide multicast capability or emulate it to support= Neighbor Discovery:

RFC4861:

"2.2.=C2=A0 Link Types

Different link layers have different properties.=C2=A0 The ones of concern<= br> to Neighbor Discovery are:

multicast capable
- a link that supports a native mechanism at the link
layer for sending packets to all (i.e., broadcast)
or a subset of all neighbors.

point-to-point - a link that connects exactly two interfaces.=C2=A0 A
point-to-point link is assumed to have multicast
capability and a link-local address.

non-broadcast multi-access (NBMA)
- a link to which more than two interfaces can attach,
but that does not support a native form of multicast
or broadcast (e.g., X.25, ATM, frame relay, etc.).
Note that all link types (including NBMA) are
expected to provide multicast service for
applications that need it (e.g., using multicast
servers).=C2=A0 However, it is an issue for further study
whether ND should use such facilities or an
alternate mechanism that provides the equivalent
multicast capability for ND."



>=C2=A0 So why bother if a closed user
> group decides to deploy a stopgap technology to enable IPv6 access. >
> And, when speaking about academia: do they have a "how to not wri= te
> e-mail"
> class there?=C2=A0 Like, "take a full digest with lots of unrelat= ed mail in it,
> and write a top posting on top of it"?
>
> Gert Doering
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsr= atsvors.: A. Grundner-Culemann
> D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-Id= Nr.: DE813185279
>
>
> _______________________= ________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>


--
Regards
Tariq Saraj
Center f= or Research in Networks and Telecom (CoReNeT= )
--047d7b5db77ae20fe6050a92a20c-- From nobody Fri Dec 19 17:22: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 9EAA61ACC80 for ; Fri, 19 Dec 2014 17:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.401 X-Spam-Level: * X-Spam-Status: No, score=1.401 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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, 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 amGqxf2y24jb for ; Fri, 19 Dec 2014 17:22:41 -0800 (PST) Received: from nm35.bullet.mail.bf1.yahoo.com (nm35.bullet.mail.bf1.yahoo.com [72.30.238.197]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771841AC435 for ; Fri, 19 Dec 2014 17:22:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1419038560; bh=MF+he5OIBSjphtb9K/4NKUJWnDh5IPqX+134+kkIXAU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=V+wyDpqEd1XqxQPksNlndl3cy569/g1ZATAzMTxYqtYvk2tf9aLWAt9GMu52RrQkQf/Kyr5RZ6I1FkiytyL1w/xdcfzNvIcEJKggRGznq0HbPsVHE1r81aPw9sYPFg68mu02YVaNPe7iTp44wFx2YnyML0IV+LM+NqTcwlt2nbh/WeRjjln7rEIW47B2ds1mwR/fuzIXCHmtXdkozAOW2TkQeuNnQUXbQh/mlQpznZQonJ+Eeobo1TcczxDcrDfCr0h+uCJ1Zg6zM8HYtq6iuhrZUjODv43ATe4jAdoY++I5rEFpgtz8xNt5IGpFGTgFjgZOf9/RzVmb9TNFGFWbJw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com.au; b=D5gd2xMims/ZN+crU12U8u8bXzom21OAOxkbGNJQjarexEX5TrrzeRNDx02dF4ECU6d8nPzv5joruRY0oR+8aJOIQCRDbOvnLGgDdos6tSN5UNNtX1KbngfTL5kJsx3NPgC3hKbRsqPsH8Rx223Wha69LPyaiRjecZGfRpsmgIEpN5UCILeRmjsIm37+wPsuH88pniLiZIGcwZrKSGogJVUmeq+Yje4GYhMjYlQT+IccxkZ3eCs853gHashG7xdvARrHHhP6+QWl4Fvm8IwKARRndDjbhVcp98TLvm9uVjGDKJbY4DCp9i71nNaHBtKlkWa0iU06kt1xWqsBJ5QeHw==; Received: from [98.139.212.150] by nm35.bullet.mail.bf1.yahoo.com with NNFMP; 20 Dec 2014 01:22:40 -0000 Received: from [98.139.212.200] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 20 Dec 2014 01:22:40 -0000 Received: from [127.0.0.1] by omp1009.mail.bf1.yahoo.com with NNFMP; 20 Dec 2014 01:22:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 615814.95930.bm@omp1009.mail.bf1.yahoo.com X-YMail-OSG: 6r0pet4VM1k3.D5VUzID3rRPqL4I0XxK2svkMFAdv3C4fkxWExXEhW2EqtmP13t TTcmS70YFQQ.Wfrq4KEy6VdabzIYedTYFt0XTdB0oRN1ndOdPpg_RwRrbH5.VxJMaxqCoIYRFLUW _j.d.EOhNjg96idAI7SvcSkYSdtH7FBgxYY4Tw8P4HgxJwJSGLX9E8vza66fh_wNcXL2fMxp8iES GRoma.OifQ7hQCR09Uf.LKAyeTEGbTtWjAgSEoTqJDy65tGrqHfaC4yuzqGu3UewFYm4Ohi.Xpyk zkXqSzcazFaljxA5POlCI72zF92WV5KcFVK6IBXcDEXHvgf3gGe2ylZW05aFAnIiQE_LVQMptf2z H0WzWicXhSiehqE1JhGKOCukW2zq9aBD2X_hxTWwYVFznB0nH8w8XAX4ZG36Gc1PU9iAb5KzSUwB 0lT5aUgNxGNoXwk7YsAbg10TahANQpEGHj4xmxXjpfPtKXICILSiMy4YNTBkHdn2Ml7xu4KxtLq_ BYst3xsuPhqfRPg-- Received: by 66.196.80.147; Sat, 20 Dec 2014 01:22:40 +0000 Date: Sat, 20 Dec 2014 01:21:45 +0000 (UTC) From: Mark ZZZ Smith To: Gert Doering Message-ID: <646115130.1536896.1419038505933.JavaMail.yahoo@jws106114.mail.bf1.yahoo.com> In-Reply-To: <20141219113812.GV28745@Space.Net> References: <20141219113812.GV28745@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/j-tlvbI6TL1ctYFnOKo-57c58qU Cc: Tariq Saraj , "v6ops@ietf.org" Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 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: Sat, 20 Dec 2014 01:22:43 -0000 ----- Original Message ----- > From: Gert Doering > To: Mark ZZZ Smith > Cc: Gert Doering ; Tariq Saraj ; "v6ops@ietf.org" > Sent: Friday, 19 December 2014, 22:38 > Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 > > Hi, > > On Thu, Dec 18, 2014 at 10:03:32PM +0000, Mark ZZZ Smith wrote: >> > There is no wide-area multicast anyway. >> >> Technically it should be universal, as DAD uses multicast and DAD is > mandatory (except for anycast addresses), which should include tunnels. > > This is not *wide-area* multicast, but link-local. > > Slight difference. > Perhaps I'm misunderstanding what you're saying, however 6to4 creates a single NBMA link. As per the RFC4861 text I referenced, NBMA links should emulate a multicast capability. An Internet search found the following draft that seems to specify how multicast was to be emulated over 6to4: "Support for Multicast over 6to4 Networks" https://tools.ietf.org/html/draft-thaler-ngtrans-6to4-multicast-01 There seems to be a fairly common belief that the ability to IPv6 multicast across a link is optional, because I think in IPv4 it was. It seems to me that the IPv6 approach is that the minimum characteristics IPv6 expects of links is to be able to unicast and multicast across them. If a link doesn't support multicast then multicast capability is expected to be emulated below or within the lower part of the IPv6 layer - which is what the text I quoted from RFC4861 says about emulating multicast on point-to-point and NBMA links. I think the advantage of the IPv6 approach is that there doesn't have to be link capability specific handling with IPv6 itself - all links appear to have the same set of unicast and multicast capabilities. Consequently, any of the standard IPv6 mechanisms, such as Neighbor Discovery DAD or Neighbor Discovery Address Resolution, should work and work the same way over all link types, rather than being different depending on whether the link natively supports multicast or not. Applications that use multicast of any scope should also just work regardless of the underlying link type. So, for example, Multicast DNS, using link-local multicasts, should work over 6to4 NBMA links as seamlessly as it does over 802.3 or 802.11 links. Regards, 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 > From nobody Fri Dec 19 17: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 081041ACC85 for ; Fri, 19 Dec 2014 17:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 dDLij6Ipv_ll for ; Fri, 19 Dec 2014 17:35:37 -0800 (PST) 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 6BDB11ACC80 for ; Fri, 19 Dec 2014 17:35:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3002; q=dns/txt; s=iport; t=1419039337; x=1420248937; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=a0IytOIS4aXFUJkB55630nL+MqrSj5Na1VUwj/30U2Q=; b=SYLnLYxtcoAxLj96bNVoCuH4pK29RFo6r2/OvhbhZ+iwaOU8eY4HPklh GvVR3HLNSiwcBxA45zu5I2z58chzPneyJdG5Sj4JPjxiQYWydhZxc0VbU gmOH84JM+IAZqVNx5IgMvh+AGNZ71K2Jp3+VuGgWqHfTBlmz76zXunGtt E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIFAHbRlFStJV2U/2dsb2JhbABagwZSWASDAMMgCoVxAhx7FgEBAQEBfYQMAQEBAgEBAQEBIBE6CwULAgEIGAICJgICAh8GCxUQAgQOBQmIDwMJCA26XZA9DYU/AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhjCmBdTMHgmgugRMFjg2HLoFEi3SFVCKCMoE8bwGBRH4BAQE X-IronPort-AV: E=Sophos;i="5.07,610,1413244800"; d="scan'208";a="381465489" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP; 20 Dec 2014 01:35:36 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sBK1ZaDS018196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 20 Dec 2014 01:35:36 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.66]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 19:35:36 -0600 From: "Fred Baker (fred)" To: Alexandru Petrescu Thread-Topic: [v6ops] 6man offspring - draft on prefix length recommendation for forwarding Thread-Index: AQHQG/VAgeUTSxQKYE2d6ETES4fdjg== Date: Sat, 20 Dec 2014 01:35:35 +0000 Message-ID: References: <5494097B.30207@gmail.com> In-Reply-To: <5494097B.30207@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.124] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jM2k2GdvT2-mq0WnjerwCl9xIXo Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6man offspring - draft on prefix length recommendation for forwarding 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, 20 Dec 2014 01:35:39 -0000 PC9jaGFpcj4NCldoYXQgSSB0aGluaywgIzEsIGlzIHRoYXQgYW55IGFzc3VtcHRpb25zIGFib3V0 IGxpbmsgbGF5ZXIgYWRkcmVzc2VzIGFuZCB0aGVpciBlZmZlY3Qgb24gdGhlIElJRCBzaG91bGQg YmUgcmVsYXRlZCBmaXJzdCB0byB0aGUgbGluayBsYXllciBpbiB1c2UsIGFuZCBpdHMgYWRkcmVz cy4gSWYgaXTigJlzIGEgZml2ZS1hbmQtYS1oYWxmIGJpdCBhZGRyZXNzLCBTTEFBQy1vci13aGF0 ZXZlciBzaG91bGQgcHJlc3VtZSBhIGZpdmUtYW5kLWEtaGFsZiBiaXQgYWRkcmVzcy4gVGhlIGZh Y3QgdGhhdCBzb21lb25lIGdsb2JhbGx5IHRoaW5rcyBpbiB0ZXJtcyBvZiBhIGNlcnRhaW4gbGVu Z3RoIG9mIHByZWZpeCBvciBJSUQgZGlzam9pbnQgZnJvbSB0aGUgdW5kZXJseWluZyBNQUMgYWRk cmVzcyB0aGUgSUlEIGlzIGRlcml2ZWQgZnJvbSBtb3N0bHkgd2FzdGVzIGJpdHMgd2l0aCBubyBv YnZpb3VzIFJPSS4NCg0KPGNoYWlyPg0KIzIsIHY2b3Bz4oCZIGNoYXJ0ZXIgYWxsb3dzIGl0IHRv IGdlbmVyYXRlIEJDUHMgYW5kIGluZm9ybWF0aW9uYWwgZG9jdW1lbnRzLCBhbmQgZ2l2ZSBhZHZp Y2UgdG8gb3RoZXIgd29ya2luZyBncm91cHMgLSBvZiB3aGljaCA2bWFuIGlzIG1lbnRpb25lZCBz cGVjaWZpY2FsbHkuIA0KDQo8L2NoYWlyPg0KSSBoYXZlIG5vIHByb2JsZW0gd2l0aCB0aGUgSUlE IGJlaW5nIGEgcmFuZG9tIG51bWJlciBvciBkZXJpdmVkIGZyb20gc29tZXRoaW5nIGZ1bmRhbWVu dGFsIHN1Y2ggYXMgdGhlIE1BQyBBZGRyZXNzLiBXaGF0IGlzIG5lY2Vzc2FyeSBmb3IgU0xBQUMt YmlzIGlzIHRoYXQgdGhlIFJBIGNvbnRhaW4gdGhlIGxlbmd0aCBvZiB0aGUgcHJlZml4LCBnaXZp bmcgdGhlIHN5c3RlbSB0aGUgcmVtYWluZGVyIHRvIGZpbGwgYXMgaXQgc2VlcyBmaXQuDQoNCjxj aGFpcj4NCknigJltIG5vdCBlbnRpcmVseSBzdXJlIHdoeSA2bWFuIHdvdWxkIHJlZmVyIHRoaXMg dG8gdjZvcHMsIGdpdmVuIHRoYXQgdjZvcHMgaXMgbm90IGFsbG93ZWQgYnkgY2hhcnRlciB0byBz b2x2ZSB0aGUgcHJvYmxlbSwgYW5kIHRoZSBzcGVjaWZpY2F0aW9uIGluIHF1ZXN0aW9uIGNhbWUg ZnJvbSA2bWFuLi4uDQoNCj4gT24gRGVjIDE5LCAyMDE0LCBhdCAzOjE4IEFNLCBBbGV4YW5kcnUg UGV0cmVzY3UgPGFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gSGVs bG8sDQo+IA0KPiBkcmFmdC1ib3VjYWRhaXItNm1hbi1wcmVmaXgtcm91dGluZy1yZWNvLTAzIGlz IGEgbmV3IGRyYWZ0IHRlbGxpbmcgdGhhdCBmb3J3YXJkaW5nIHByb2Nlc3NlcyBzaG91bGQgd29y ayB3aXRoIF9hcmJpdHJhcnlfIHByZWZpeCBsZW5ndGhzLCBhbmQgbm90IGJlIGJvdW5kIGJ5IHBh cnRpY3VsYXIgbGltaXRzLCBhcyBhbiBhdXRvY29uZmlnIHByb2Nlc3MgbGlrZSBTTEFBQy9FdGhl cm5ldCBpcyBib3VuZCBieSBhIHByZWZpeCBsZW4gbWF4IDY0Lg0KPiANCj4gVGhlIGRyYWZ0IHdh cyBwcmVzZW50ZWQgaW4gNk1BTiBXRyBhdCB0aGUgbGFzdCBJRVRGIG1lZXRpbmcgaW4gSG9ub2x1 bHVbKl0uICBUaGUgcmVjb21tZW5kYXRpb24gd2FzIHRvIGJyaW5nIGl0IHRvIHY2b3BzIFdHLg0K PiANCj4gQSBnbGltcHNlIHRvIHNvbWUgdG9waWNzIGRpc2N1c3NlZDoNCj4gLSB3b3J0aCBvciBu b3QgaGF2aW5nIGFuIFJGQywgc2luY2UgSW50ZXJuZXQgYWN0ZWQgdGhpcyB3YXkgc2luY2UgZXZl ci4NCj4gLSBjaGVhcGVyIHNlYXJjaGVzIGJlbG93IDY0IGFuZCB0cmVuZHMuDQo+IC0gSW50ZXJm YWNlIElEIGxlbmd0aCB2cy4gZm9yd2FyZGluZyByZWNvbW1lbmRhdGlvbi4NCj4gDQo+IFdoYXQg ZG8geW91IHRoaW5rPw0KPiANCj4gQWxleA0KPiBbKl0gdGhlIHNsaWRlcyBhcmUgYXQNCj4gaHR0 cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85MS9zbGlkZXMvc2xpZGVzLTkxLTZtYW4tNi5w ZGYNCj4gTWludXRlcyBhcmUgYXQ6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv OTEvbWludXRlcy9taW51dGVzLTkxLTZtYW4NCj4gKHNlYXJjaCBmb3IgJ3ByZWZpeCcpDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9w cyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQo= From nobody Fri Dec 19 17:58: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 54E1F1ACC85 for ; Fri, 19 Dec 2014 17:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.401 X-Spam-Level: * X-Spam-Status: No, score=1.401 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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, 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 TIV1nN0qK1Ne for ; Fri, 19 Dec 2014 17:58:21 -0800 (PST) Received: from nm1-vm1.bullet.mail.bf1.yahoo.com (nm1-vm1.bullet.mail.bf1.yahoo.com [98.139.213.163]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F3331A0045 for ; Fri, 19 Dec 2014 17:58:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1419040700; bh=3h7W8YDUKGCVPnNPJuKXr+d1xRvcOQbm8TIx6S+9eyA=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=GJQbetf1wAauY0fQ6FC1bE8MHvDkesRC5z8ICGQaVKaRDP9gr1aChMp61t82jIt5DCZVum0iNaHt95Y4XcjsDJJxuWguaQZ12A0FlqSGUZy05+AN1jSaCa+rSy0nkrzXCqCUl0hGJc4QmrYgXv5kEkNYbah9Kw6Ok7xK5TViK+aZWJYnwXumghKaOPjSomvGPwGlOelZScRTCtraF1mI40SJScEXjRlXhPba8yktBYRT1Ohd0tWGALXpJt3MSk1R1FHvbnHN8dFw4IAaPcOqFpOb5/BKM4eKGf7NkbfeyrBb9N95l0Q78rXkaHopRC9UGOiRJFALZZnDB3e6woirGw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com.au; b=K7jMUJ3f5Y0cCdBqtYaH7KYvXMuLv6iN6cOZk0VYJEHlGD2XS46tVYCU9t5hy/NePEq3QTg2u7dXmhVTVjP8NxkoFzXWYx7wqYgRTbwyLKSI2WDoQNJFu4j8oXwe5loXCouLZD0qXegOHv0ZTSuN59mmRPxZR0kBMq0Tnb0CNfemR9PXdeZUpsfkIc5Wy3UwpdKA8vRmPYOS4TWSigtpYSzEB35R0EVvjfpLBz1xCxJDtbNYuxXXOVJxvhNnR7B6oBM9ienIW7Q+D3InsvnXsarTMYh0fXPMg0NjOYmA5HWcuBLKvOmsxZxuzVP9PgH7cqTIdzE0P1knsXWXa3VW8w==; Received: from [66.196.81.172] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 20 Dec 2014 01:58:20 -0000 Received: from [98.139.212.205] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 20 Dec 2014 01:58:20 -0000 Received: from [127.0.0.1] by omp1014.mail.bf1.yahoo.com with NNFMP; 20 Dec 2014 01:58:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 674617.27315.bm@omp1014.mail.bf1.yahoo.com X-YMail-OSG: KN.R33EVM1m57UAWL3Jn5Db745RCEPRbuHyAzEjK7w9kvBklZsSMFkXbpvHlaBQ LAUJnnBGG.qtuEs.Mt9s6vTEVbdIPBLU49ZrG6.S1aOURg90hOBavEtUY1byRbgVGK_Mnz7qgyQ1 M4.paCSdrUnPwswM00.INBDV8ZHaLSome039ZE_fY0oLMEbbYaihZf0WWvR.foRsddSjxpL.mP.I DwYOzm0LLmYwDAAsJdOjt0NrFmV_HFYu5jJJPRB4KSSiNby7rNrXCpy.q6hffjY06U2aIPjJr6nZ bmuD5_efZyh69q3IpVAh_Av_KEF1Zbsm5gixzqxSSm.ddDsoIw9PyKHEEXMJkk5zrcF3XADwU9oT IdHXt9G6NFBHNVx26Evnx0QwiKm3aMoCKStUK2uOsNaIy_CFoWSpNoPJ.Vm2aZV4EFCXuqsAI0Mo dDTUEN3jtywFrodHjo5pcUjjfXFWd_VN33KnxRIC7rjBgCkIvfXUkbu5P6svNpNM9nkhZXZrjV6p d3FnR05dpOnUV6w-- Received: by 76.13.26.107; Sat, 20 Dec 2014 01:58:20 +0000 Date: Sat, 20 Dec 2014 01:56:36 +0000 (UTC) From: Mark ZZZ Smith To: Tariq Saraj , "v6ops@ietf.org" Message-ID: <864357186.1538477.1419040596962.JavaMail.yahoo@jws10630.mail.bf1.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/g2qbe2Rnu4F9Q8dH5FiS8ZkM-7w Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 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: Sat, 20 Dec 2014 01:58:23 -0000 >________________________________ > From: Tariq Saraj >To: Mark ZZZ Smith ; v6ops@ietf.org >Sent: Saturday, 20 December 2014, 1:36 >Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 > > > >Smith what you are pointing is all at link level and purely related to IPv6, Discussion is related Multicast support in Hybrid IPv4-IPv6 Internet at IP layer (i.e. IPvX-IPvY-IPvX) > So the layer below the network layer is the link-layer. IPv6 is the network layer protocol, and therefore any protocols directly below it from the IPv6 point of view are either literally or conceptually link-layer protocols. IPv6 encapsulated in IPv4 means that IPv4 is being used as by IPv6 as a link-layer protocol, and is constructing a single link-layer link for IPv6 to operate over. IPv6 expects link-layers to provide or emulate unicast and multicast capabilities. If IPv4 is being used to construct a link-layer for IPv6 to operate over, then it should provide or emulate a link-layer unicast and multicast capability. Once the (IPv4 constructed) link-layer provides or emulates both a unicast and multicast capability, there is nothing special about it from the IPv6 point of view, and I don't think there needs to be any IPv6-specific handling of this situation. If the link-layer IPv4 is further encapsulated in other IP encapsulations ("i.e. IPvX-IPvY-IPvX"), that is all hidden within the link-layer or below it and not visible or relevant to IPv6 operation at the network layer. Making IPv6 aware of that would be a layer violation. More broadly, what has been missing from 6to4 was the emulation of a multicast capability, meaning that 6to4 currently doesn't really meet IPv6's minimum link-layer link capability requirements. It seems some work was done on emulating it in the following draft, but it didn't advance for some reason or another: Support for Multicast over 6to4 Networks https://tools.ietf.org/html/draft-thaler-ngtrans-6to4-multicast-01 > >On Fri, Dec 19, 2014 at 3:03 AM, Mark ZZZ Smith wrote: > >> >> >> >>----- Original Message ----- >>> From: Gert Doering >>> To: Tariq Saraj >>> Cc: v6ops@ietf.org >>> Sent: Tuesday, 16 December 2014, 5:01 >>> Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 >>> >>> Hi, >>> >>> On Sun, Dec 14, 2014 at 12:18:00AM +0500, Tariq Saraj wrote: >>>> There are some issues with 6rd as well, IPv6 with all its powerful features >>>> is still under critical objections in academia just because of the urgency >>>> shown by IETF in standardizing protocols like 6to4 and 6rd. 6to4 clearly >>>> mentioned that it cannot support multicast at layer-3, on the other end 6rd >>>> claimed that multicast can be provided, my question is that while >>>> standardizing 6rd which at that time was just supporting unicast traffic >>>> traversing across IPv4 network and its still not matured enough to provide >>>> multicast support yet in its functionality other than using some proxy >>>> support for multicast traffic. why It was standardized ? >>> >>> There is no wide-area multicast anyway. >> >>Technically it should be universal, as DAD uses multicast and DAD is mandatory (except for anycast addresses), which should include tunnels. >> >>Links are supposed to provide multicast capability or emulate it to support Neighbor Discovery: >> >>RFC4861: >> >>"2.2. Link Types >> >>Different link layers have different properties. The ones of concern >>to Neighbor Discovery are: >> >>multicast capable >>- a link that supports a native mechanism at the link >>layer for sending packets to all (i.e., broadcast) >>or a subset of all neighbors. >> >>point-to-point - a link that connects exactly two interfaces. A >>point-to-point link is assumed to have multicast >>capability and a link-local address. >> >>non-broadcast multi-access (NBMA) >>- a link to which more than two interfaces can attach, >>but that does not support a native form of multicast >>or broadcast (e.g., X.25, ATM, frame relay, etc.). >>Note that all link types (including NBMA) are >>expected to provide multicast service for >>applications that need it (e.g., using multicast >>servers). However, it is an issue for further study >>whether ND should use such facilities or an >>alternate mechanism that provides the equivalent >>multicast capability for ND." >> >> >> >>> So why bother if a closed user >>> group decides to deploy a stopgap technology to enable IPv6 access. >>> >>> And, when speaking about academia: do they have a "how to not write >>> e-mail" >>> class there? Like, "take a full digest with lots of unrelated mail in it, >>> and write a top posting on top of it"? >>> >>> 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 >>> >> > > >-- > >Regards >Tariq Saraj >Center for Research in Networks and Telecom (CoReNeT) > > > > > > > From nobody Fri Dec 19 18:57: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 B2EE71A90F1 for ; Fri, 19 Dec 2014 18:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 V3jXkXNn0eOH for ; Fri, 19 Dec 2014 18:57:53 -0800 (PST) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219491A8BB0 for ; Fri, 19 Dec 2014 18:57:53 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id fp1so2327857pdb.38 for ; Fri, 19 Dec 2014 18:57:52 -0800 (PST) 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=ANhSu2wxBbFz3ktD/DsLrVEz9YvGc4XNCJq4O1Qnbds=; b=FGJKIW2IxhJTZQiKfN+W4thnh30Ku+j5Wzy9VkiIPixOQrKF8/ViCzxTxuT0xOI91n /Fm38yOFJ2iYTiCy1h7aXoVUxoL7/Nsp9HdtmMFDK9AKKefzN67SnQIGjGVvHfY5hclo qvHry7EOpOW6Sq3/NdHi2ebHgbXIKzMskegkH3Veo3Ta1xDuuPQdW2TTLkU+bsUagZFm RU8TBd+NKA2dwiopWTAAanYTFEMcOokmEWipA2H69HgbBaqYHHEbUEi0pkrdc/BpxaFd SGnUUj/TbeTX/TXsb4VmbwqftBgmPPEN0zeRkDzan0/GrKeHq8Xy4i8JqlWLxPAR81ZZ s51w== X-Received: by 10.68.68.130 with SMTP id w2mr17202883pbt.167.1419044272205; Fri, 19 Dec 2014 18:57:52 -0800 (PST) Received: from ?IPv6:2406:e007:7cab:1:28cc:dc4c:9703:6781? ([2406:e007:7cab:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id oz7sm10897438pbb.14.2014.12.19.18.57.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Dec 2014 18:57:51 -0800 (PST) Message-ID: <5494E5BA.9020901@gmail.com> Date: Sat, 20 Dec 2014 15:58:02 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mark ZZZ Smith References: <864357186.1538477.1419040596962.JavaMail.yahoo@jws10630.mail.bf1.yahoo.com> In-Reply-To: <864357186.1538477.1419040596962.JavaMail.yahoo@jws10630.mail.bf1.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4RMFgchyY2lUyUA22tnd4xxpFik Cc: Tariq Saraj , "v6ops@ietf.org" Subject: [v6ops] Multicast support [was: v6ops Digest, Vol 52, Issue 41] 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, 20 Dec 2014 02:57:55 -0000 On 20/12/2014 14:56, Mark ZZZ Smith wrote: > >> ________________________________ >> From: Tariq Saraj >> To: Mark ZZZ Smith ; v6ops@ietf.org >> Sent: Saturday, 20 December 2014, 1:36 >> Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 >> >> Smith what you are pointing is all at link level and purely related to IPv6, Discussion is related Multicast support in Hybrid IPv4-IPv6 Internet at IP layer (i.e. IPvX-IPvY-IPvX) > >> > > So the layer below the network layer is the link-layer. > > IPv6 is the network layer protocol, and therefore any protocols directly below it from the IPv6 point of view are either literally or conceptually link-layer protocols. > > IPv6 encapsulated in IPv4 means that IPv4 is being used as by IPv6 as a link-layer protocol, and is constructing a single link-layer link for IPv6 to operate over. > > IPv6 expects link-layers to provide or emulate unicast and multicast capabilities. If IPv4 is being used to construct a link-layer for IPv6 to operate over, then it should provide or emulate a link-layer unicast and multicast capability. This was of course exactly the basis for 6over4 (http://tools.ietf.org/html/rfc2529). That was intended for single administrative domains, where IPv4 multicast was a not unreasonable but rather optimistic assumption in 1999. > > Once the (IPv4 constructed) link-layer provides or emulates both a unicast and multicast capability, there is nothing special about it from the IPv6 point of view, and I don't think there needs to be any IPv6-specific handling of this situation. If the link-layer IPv4 is further encapsulated in other IP encapsulations ("i.e. IPvX-IPvY-IPvX"), that is all hidden within the link-layer or below it and not visible or relevant to IPv6 operation at the network layer. Making IPv6 aware of that would be a layer violation. > > > More broadly, what has been missing from 6to4 was the emulation of a multicast capability, meaning that 6to4 currently doesn't really meet IPv6's minimum link-layer link capability requirements. It seems some work was done on emulating it in the following draft, but it didn't advance for some reason or another: > > Support for Multicast over 6to4 Networks > https://tools.ietf.org/html/draft-thaler-ngtrans-6to4-multicast-01 14 years ago, multicast deployment was low on the list of IPv6 priorities. Brian > > >> >> On Fri, Dec 19, 2014 at 3:03 AM, Mark ZZZ Smith wrote: >> >>> >>> >>> >>> ----- Original Message ----- >>>> From: Gert Doering >>>> To: Tariq Saraj >>>> Cc: v6ops@ietf.org >>>> Sent: Tuesday, 16 December 2014, 5:01 >>>> Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 >>>> >>>> Hi, >>>> >>>> On Sun, Dec 14, 2014 at 12:18:00AM +0500, Tariq Saraj wrote: >>>>> There are some issues with 6rd as well, IPv6 with all its powerful features >>>>> is still under critical objections in academia just because of the urgency >>>>> shown by IETF in standardizing protocols like 6to4 and 6rd. 6to4 clearly >>>>> mentioned that it cannot support multicast at layer-3, on the other end 6rd >>>>> claimed that multicast can be provided, my question is that while >>>>> standardizing 6rd which at that time was just supporting unicast traffic >>>>> traversing across IPv4 network and its still not matured enough to provide >>>>> multicast support yet in its functionality other than using some proxy >>>>> support for multicast traffic. why It was standardized ? >>>> >>>> There is no wide-area multicast anyway. >>> >>> Technically it should be universal, as DAD uses multicast and DAD is mandatory (except for anycast addresses), which should include tunnels. >>> >>> Links are supposed to provide multicast capability or emulate it to support Neighbor Discovery: >>> >>> RFC4861: >>> >>> "2.2. Link Types >>> >>> Different link layers have different properties. The ones of concern >>> to Neighbor Discovery are: >>> >>> multicast capable >>> - a link that supports a native mechanism at the link >>> layer for sending packets to all (i.e., broadcast) >>> or a subset of all neighbors. >>> >>> point-to-point - a link that connects exactly two interfaces. A >>> point-to-point link is assumed to have multicast >>> capability and a link-local address. >>> >>> non-broadcast multi-access (NBMA) >>> - a link to which more than two interfaces can attach, >>> but that does not support a native form of multicast >>> or broadcast (e.g., X.25, ATM, frame relay, etc.). >>> Note that all link types (including NBMA) are >>> expected to provide multicast service for >>> applications that need it (e.g., using multicast >>> servers). However, it is an issue for further study >>> whether ND should use such facilities or an >>> alternate mechanism that provides the equivalent >>> multicast capability for ND." >>> >>> >>> >>>> So why bother if a closed user >>>> group decides to deploy a stopgap technology to enable IPv6 access. >>>> >>>> And, when speaking about academia: do they have a "how to not write >>>> e-mail" >>>> class there? Like, "take a full digest with lots of unrelated mail in it, >>>> and write a top posting on top of it"? >>>> >>>> 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 >>>> >>> >> >> >> -- >> >> Regards >> Tariq Saraj >> Center for Research in Networks and Telecom (CoReNeT) >> >> >> >> >> >> >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Dec 19 19:48: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 70D7B1A9105 for ; Fri, 19 Dec 2014 19:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 YobeYXG9Hp21 for ; Fri, 19 Dec 2014 19:47:57 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AE8D1A701E for ; Fri, 19 Dec 2014 19:47:57 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id h15so1678669igd.13 for ; Fri, 19 Dec 2014 19:47:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qp9WVZdl49h21CdCKlxTG1IuLJQ5+pufVphYZJ84EBY=; b=TkVj/414qffy3y/rNKXov2rT5L3YqJVw3X9ToeD3uBLam0qfCTVlcIuc7lpXyeA7VB g9bvkGMcQgzh41WGARdSGVNsT7dVjL83mbUdFmEshl5GBFxwm/VoRIS6jkclP8GP9kVs qQxkMOIo3FWL6mBLzzSuiZZKdx5JeUCYhZsXXXI7/21ElEBlkv1zmOeB3Fk70peKdTtr scvp56D7FBdiDphRqoGBGBPVV6y2J/0lINHlwidhmGDTXhN3lg/unStBUm9KRMs0qMLn 5YV1V62kR8mLFV04LN2OMzvy7cXJs8N55KlQHAI3Cs2FDgrQVOxNqJBBOzl3Hhuu+UPo gP9w== 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=qp9WVZdl49h21CdCKlxTG1IuLJQ5+pufVphYZJ84EBY=; b=HDtp7RvOoNMcg0iCYRugd4La/a4GPeowTWLhQjXb64Q6jQVbbMPiwp6xMTh8q4U2E+ vVkgxRlppeZ6O/UWbOiJsyWYEML/hPoVf+zx5Qwu15wCQVC/q6j6KLj4DmqzcpStvIJA LnGzKZxDrA8xWMIzcOEeXIpJ2Mg8q5mnOtDLdSkaRFhHtGBZ8jteO135Kr6fO8PcJ1dA oWRhLv1VMEcy2dDUoyjgLuv8uv9mgcPr567gp9qDnExbqsCYmqE3JbZkeFKiwtgb+gae VhtJK4/EJ8thesj6Z2sXGQ8afdleCeNOUo7oD4LrtY2Wcnp/sDrSTHfObfoVhLkQdJjQ gI3w== X-Gm-Message-State: ALoCoQl5kmtsaamChjeleZTdnHxxNFegMoKgxREMf1BQyaTrHCfpyzRfoFQXsxzZyyjJhEbmgwhF X-Received: by 10.50.109.164 with SMTP id ht4mr6613921igb.4.1419047276372; Fri, 19 Dec 2014 19:47:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.130.167 with HTTP; Fri, 19 Dec 2014 19:47:36 -0800 (PST) In-Reply-To: References: <5494097B.30207@gmail.com> From: Lorenzo Colitti Date: Sat, 20 Dec 2014 12:47:36 +0900 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=089e0122f024d40da4050a9db03d Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8qDy58_hBjhPcEscG42LaAkeufA Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6man offspring - draft on prefix length recommendation for forwarding 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, 20 Dec 2014 03:47:58 -0000 --089e0122f024d40da4050a9db03d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Dec 20, 2014 at 10:35 AM, Fred Baker (fred) wrote: > > I=E2=80=99m not entirely sure why 6man would refer this to v6ops, given t= hat v6ops > is not allowed by charter to solve the problem, and the specification in > question came from 6man... AIUI the intent of this document is not to redefine SLAAC, the IPv6 addressing architecture, or anything of the sort. I believe this is just intended to be guidance to router implementors that just because the IID length is 64 bits does not mean that routers can restrict themselves to supporting only prefix lengths of /0-/64 and /127 (a MUST in RFC6164), but must also support forwarding to prefixes of arbitrary other lengths such as /93. --089e0122f024d40da4050a9db03d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Dec 20, 2014 at 10:35 AM, Fred Baker (fred) <fred@cisco.com> wrote:
I=E2=80=99m not entirely sure why 6m= an would refer this to v6ops, given that v6ops is not allowed by charter to= solve the problem, and the specification in question came from 6man...

AIUI the intent of this document is not to red= efine SLAAC, the IPv6 addressing architecture, or anything of the sort.

I believe this is just intended to be guidance to rou= ter implementors that just because the IID length is 64 bits does not mean = that routers can restrict themselves to supporting only prefix lengths of /= 0-/64 and /127 (a MUST in RFC6164), but must also support forwarding to pre= fixes of arbitrary other lengths such as /93.
--089e0122f024d40da4050a9db03d-- From nobody Fri Dec 19 22:38: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 6B1491A90E0 for ; Fri, 19 Dec 2014 22:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 2AOZnYvFTY0E for ; Fri, 19 Dec 2014 22:38:23 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490661A9083 for ; Fri, 19 Dec 2014 22:38:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=161; q=dns/txt; s=iport; t=1419057505; x=1420267105; h=date:from:message-id:to:subject:cc; bh=ifRYWS9v7l4GavFXWzKu/FazduYCUuJdrNoxy75q3D0=; b=FLlS760xig3IKIAnLpNK+WEaXTGlUfVARf9JpmLwNcswhHKhNnQoyOv+ a1E+Ay+gag3TwFgpnfefuQPeQzAend/8vs9Z+AZLj/bSMZp7R0vKSK8LW HR/s/G7SglbmRqb4qFFLWnesxCUJdYBpgt9vnrOoarst3E+jygzm5LHF0 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEHABgZlVStJA2H/2dsb2JhbABagwa4PgGVC4ETFgEBAQEBfYQwXDw0iQwB0DkBAQEBAQUBAQEBAQEcj3IdhBMFiUWfAiKED4MRAQEB X-IronPort-AV: E=Sophos;i="5.07,612,1413244800"; d="scan'208";a="381606851" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP; 20 Dec 2014 06:38:21 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sBK6cIk0028670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Dec 2014 06:38:19 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id sBK6cIKg005386; Fri, 19 Dec 2014 22:38:18 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id sBK6cHx7005385; Fri, 19 Dec 2014 22:38:17 -0800 Date: Fri, 19 Dec 2014 22:38:17 -0800 From: fred@cisco.com Message-Id: <201412200638.sBK6cHx7005385@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/saZ3L9mbC59SZO0l6u8R5zMdce4 Subject: [v6ops] Adoption call for draft-boucadair-6man-prefix-routing-reco 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, 20 Dec 2014 06:38:24 -0000 Are we agreed that draft-boucadair-6man-prefix-routing-reco should be adopted as a working group document in v6ops, and renamed draft-ietf-v6ops-cidr-prefix? From nobody Fri Dec 19 22:50: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 9F3851A9103 for ; Fri, 19 Dec 2014 22:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 T7as4xkVzleO for ; Fri, 19 Dec 2014 22:50:13 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995851A90F2 for ; Fri, 19 Dec 2014 22:50:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8568; q=dns/txt; s=iport; t=1419058214; x=1420267814; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=d7VSCnBHG0LCktCysgEg/IARGvuOOJ1kRpBBMPqPS2U=; b=lfsKA9B4y5/3G0I3IhS86w0qCwwpsQvMHMFirujQVe/MzKviSOitkaMo ZC/YpqYiroXXN6S3rCEX1ws6aDLFoZYUZPBqZW1bd1cyN7fG6YEGuAoKN B3iiA8o0TkdaYeFJD/5BB8Wixov2sc5ztNNRN9VnBaFuDb3QfzXcDgewV 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFAOYalVStJV2P/2dsb2JhbABagwZSWASDAMMthW8CHHUWAQEBAQF9hAwBAQEDASMRRQULAgEIEgYCAiYCAgIwFQIOAgQOBYgkCA26OZV0AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIY1vEQFQB4JoLoETBYQrAolggz6BQYNzgQ2KLYYOIoIygTxvgQMJFwQefgEBAQ X-IronPort-AV: E=Sophos;i="5.07,612,1413244800"; d="scan'208";a="107133505" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP; 20 Dec 2014 06:50:13 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sBK6oCVj031988 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 20 Dec 2014 06:50:12 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.66]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Sat, 20 Dec 2014 00:50:12 -0600 From: "Fred Baker (fred)" To: Lorenzo Colitti Thread-Topic: [v6ops] 6man offspring - draft on prefix length recommendation for forwarding Thread-Index: AQHQHCEzcY9s3lLwtU6EFOoadh5QEQ== Date: Sat, 20 Dec 2014 06:50:11 +0000 Message-ID: <7B968136-C705-49A9-87DA-5B338DCE0FF3@cisco.com> References: <5494097B.30207@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.124] Content-Type: text/plain; charset="utf-8" Content-ID: <2C045FB08FFC2E47B6577ACC5600C22F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/F1oCwEJItP7S0DTk8WZu9_AGVZE Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6man offspring - draft on prefix length recommendation for forwarding 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, 20 Dec 2014 06:50:16 -0000 DQo+IE9uIERlYyAxOSwgMjAxNCwgYXQgNzo0NyBQTSwgTG9yZW56byBDb2xpdHRpIDxsb3Jlbnpv QGdvb2dsZS5jb20+IHdyb3RlOg0KPiANCj4gT24gU2F0LCBEZWMgMjAsIDIwMTQgYXQgMTA6MzUg QU0sIEZyZWQgQmFrZXIgKGZyZWQpIDxmcmVkQGNpc2NvLmNvbT4gd3JvdGU6DQo+PiBJ4oCZbSBu b3QgZW50aXJlbHkgc3VyZSB3aHkgNm1hbiB3b3VsZCByZWZlciB0aGlzIHRvIHY2b3BzLCBnaXZl biB0aGF0IHY2b3BzIGlzIG5vdCBhbGxvd2VkIGJ5IGNoYXJ0ZXIgdG8gc29sdmUgdGhlIHByb2Js ZW0sIGFuZCB0aGUgc3BlY2lmaWNhdGlvbiBpbiBxdWVzdGlvbiBjYW1lIGZyb20gNm1hbi4uLg0K PiANCj4gQUlVSSB0aGUgaW50ZW50IG9mIHRoaXMgZG9jdW1lbnQgaXMgbm90IHRvIHJlZGVmaW5l IFNMQUFDLCB0aGUgSVB2NiBhZGRyZXNzaW5nIGFyY2hpdGVjdHVyZSwgb3IgYW55dGhpbmcgb2Yg dGhlIHNvcnQuDQo+IA0KPiBJIGJlbGlldmUgdGhpcyBpcyBqdXN0IGludGVuZGVkIHRvIGJlIGd1 aWRhbmNlIHRvIHJvdXRlciBpbXBsZW1lbnRvcnMgdGhhdCBqdXN0IGJlY2F1c2UgdGhlIElJRCBs ZW5ndGggaXMgNjQgYml0cyBkb2VzIG5vdCBtZWFuIHRoYXQgcm91dGVycyBjYW4gcmVzdHJpY3Qg dGhlbXNlbHZlcyB0byBzdXBwb3J0aW5nIG9ubHkgcHJlZml4IGxlbmd0aHMgb2YgLzAtLzY0IGFu ZCAvMTI3IChhIE1VU1QgaW4gUkZDNjE2NCksIGJ1dCBtdXN0IGFsc28gc3VwcG9ydCBmb3J3YXJk aW5nIHRvIHByZWZpeGVzIG9mIGFyYml0cmFyeSBvdGhlciBsZW5ndGhzIHN1Y2ggYXMgLzkzLg0K DQpObyBkb3VidC4gQnV0IDI0NjAsIDQyOTEsIGFuZCBhbGwgdGhlIHJlc3QgY2FtZSBmcm9tIElQ djYgb3IgNm1hbi4gV2h5IG9uIGVhcnRoIHdvdWxkIHRoZXkgYXNrICp1cyogdG8gc2F5IHRoYXQ/ DQoNCldoZW4gSSByZWZlciB0byB0aGUgY2hhcnRlciwgb3VyIGNoYXJ0ZXIgYWxsb3dzIHVzIHRv IGRvIHRocmVlIHRoaW5nczogcHVibGlzaCBhcyBpbmZvcm1hdGlvbmFsLCBwdWJsaXNoIGFzIEJD UCwgb3IgcmVmZXIgdG8gc29tZSBvdGhlciB3b3JraW5nIGdyb3VwIHdpdGggb3VyIGNvbW1lbnRz LiBUaGlzIGRyYWZ0IGFza3MgZm9yIFByb3Bvc2VkIFN0YW5kYXJkIHN0YXR1cy4NCg0KaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm91Y2FkYWlyLTZtYW4tcHJlZml4LXJv dXRpbmctcmVjbw0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvdWNhZGFpci02 bWFuLXByZWZpeC1yb3V0aW5nLXJlY28NCiAgIklQdjYgUHJlZml4IExlbmd0aCBSZWNvbW1lbmRh dGlvbiBmb3IgRm9yd2FyZGluZyIsIE1vaGFtZWQgQm91Y2FkYWlyLA0KICBBbGV4IFBldHJlc2N1 LCAyMDE0LTA5LTI0LA0KDQpUaGUgdGV4dCwgaWYgc2hvcnRlbmVkIGF0IGFsbCwgd291bGQgYmUg bGl0ZXJhbGx5IHRoZSB3b3JkcyB5b3Ugc3Bva2UuIEnigJlsbCByZXBlYXQgaXQgaW4gdGhpcyBl bWFpbC4NCg0KVGVsbCB5b3Ugd2hhdC4gQmV0d2VlbiBub3cgYW5kIDEyLzMxLCBtYW55IG9mIHVz IGFyZSBnb2luZyB0byBiZSBvdXQgb2Ygc2lnaHQgYW5kIG91dCBvZiBtaW5kLiBJ4oCZbGwgcnVu IGEgV0dMQywgc3RhcnRpbmcgMS80LzIwMTUgYW5kIHJ1bm5pbmcgZm9yIHR3byB3ZWVrcy4gSWYg d2UgaGF2ZSBhbnkgZGlzYWdyZWVtZW50IGJleW9uZCBuaXRzLCBJ4oCZbGwgZXhwcmVzcyBhbWF6 ZW1lbnQsIGFuZCBpZiB3ZSBkb27igJl0LCBJ4oCZbGwgZG8gd2hhdCBJIHRoaW5rIHRoZSA2bWFu IGNoYWlycyBzaG91bGQgaGF2ZSBkb25lLCB3aGljaCBpcyBzZW5kIGl0IHRvIG15IGZhdm9yaXRl IEFEIGZvciBwdWJsaWNhdGlvbi4gSW4gdGhlIHNhbWUgY2FsbCwgSeKAmWxsIGFzayB3aGV0aGVy IGl0IHNob3VsZCBiZSBhZG9wdGVkIGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudCwgYW5kIGlm IChhcyBJIGV4cGVjdCkgd2XigJlyZSBhbGwgT0sgd2l0aCB0aGF0LCBJ4oCZbGwgYXNrIE1vaGFt ZWQgdG8gZmlsZSB0aGUgdXBkYXRlLXRvLXBpY2stdXAtY29tbWVudHMgYXMgZHJhZnQtaWV0Zi12 Nm9wcy1jaWRyLXByZWZpeC4NCg0KPHJhbnQgIzE+DQpXZSBoYXZlIGEgY29udmVudGlvbiB0aGF0 IGNhbGxzIGZvciBhIDY0IGJpdCBJSUQgb24gdW5pY2FzdCBhZGRyZXNzZXMsIGJ1dCBhcmUgcXVp dGUgaGFwcHkgdG8gdXNlLCB0byBwaWNrIG9uZSBkb2N1bWVudGVkIGV4YW1wbGUsIDEyNyBiaXQg cHJlZml4ZXMgYW1vbmcgY29uc2VudGluZyBhZHVsdHMuIElmIHNvbWVvbmUgdXNlZCBESENQIHRv IGFzc2lnbiBhZGRyZXNzZXMgYW5kIGNob3NlIHRvIHVzZSBhIDc5IGJpdCBwcmVmaXgsIHdvdWxk IHdlIGtub3c/IFdvdWxkIHdlIGNhcmU/IEl04oCZcyBhIENJRFIgcHJlZml4LCBmb3IgY3J5aW5n IG91dCBsb3VkLiANCjwvcmFudD4NCg0KPHJhbnQgIzI+DQpPZiBjb3Vyc2UsIEkgaGF2ZSB0aGUg c2FtZSBxdWVzdGlvbiBhYm91dCBiaXQgNzAgYW5kIDcxIG9mIHRoZSBhZGRyZXNzIChiaXTigJlz IDYgYW5kIDcgb2YgdGhlIFJGQyA0MjkxIElJRCkuIEluIHdoYXQgY2FzZSwgc3BlY2lmaWVkIGlu IHdoYXQgUkZDIGFuZC9vciBpbXBsZW1lbnRlZCBpbiB3aGF0IGhhcmR3YXJlIG9yIHNvZnR3YXJl LCBkbyB3ZSBleHRyYWN0IGFuIEVVSS02NCBvciBFVUktNDggZnJvbSB0aGUgSUlEPyBJZiBpdCB3 YXMgYSBQcml2YWN5L1RlbXBvcmFyeSBhZGRyZXNzLCBvciBhIFNFTkQgQ0dBIEFkZHJlc3MsIG9y IHNvbWV0aGluZyBvdXQgb2YgUkZDIDYwNTIsIHdoYXQgd291bGQgd2UgZ2V0IGlmIHdlIGRpZD8g V2h5LCBvaCB3aHksIGRvZXMgaXQgbWF0dGVyLCBhbmQgd2hvIGFjdHVhbGx5IGNhcmVzLCB3aGV0 aGVyIHRoZSBJSUQgaXMgYSBsb2NhbGx5LXNpZ25pZmljYW50IG9yIGdsb2JhbGx5IHNpZ25pZmlj YW50IHZhbHVlLCBvciB3aGV0aGVyIHNvbWVvbmUgdGhvdWdodCBpdCBjYW1lIGZyb20gYSBtdWx0 aWNhc3QgTUFDIGFkZHJlc3M/DQo8L3JhbnQ+DQoNCg0KT0ssIHNhbml0eSBzbG93bHkgcmV0dXJu aW5nLi4uDQoNCknigJlsbCBzdGF0ZSB0d28gbml0cyBoZXJlOiANCg0KMSkgSSBkb27igJl0IGtu b3cgd2h5IHRoaXMgaXNu4oCZdCBhIEJDUCAtIGEgb25lLXNob3Qgc3RhbmRhcmQuIEl04oCZcyBu b3QgbGlrZSB3ZeKAmXJlIGdvaW5nIHRvIGRlbW9uc3RyYXRlIGludGVyb3BlcmFibGUgaW1wbGVt ZW50YXRpb25zIGFuZCBidW1wIGl0IGZyb20gUHJvcG9zZWQgU3RhbmRhcmQgdG8gU3RhbmRhcmQu IFRoYXTigJlzIG5vdCBhIHN0cm9uZ2x5IGhlbGQgb3BpbmlvbiwgYnV0IGl0IGlzIGEgcXVlc3Rp b24sIGFuZCBpdOKAmXMgbWluZS4NCjIpICAgPT0gT3V0ZGF0ZWQgcmVmZXJlbmNlOiBBIGxhdGVy IHZlcnNpb24gKC0wOCkgZXhpc3RzIG9mIGRyYWZ0LWlldGYtNm1hbi13aHk2NC0wNQ0KDQpBYnN0 cmFjdA0KDQogICBUaGUgbGVuZ3RoIG9mIElQIHByZWZpeGVzIGlzIGFuIGluZm9ybWF0aW9uIHVz ZWQgYnkgZm9yd2FyZGluZyBhbmQNCiAgIHJvdXRpbmcgcHJvY2Vzc2VzIGlzIHBvbGljeS1iYXNl ZC4gIEFzIHN1Y2gsIG5vIG1heGltdW0gbGVuZ3RoIG11c3QNCiAgIGJlIGFzc3VtZWQgYnkgZGVz aWduLg0KDQogICBEaXNjdXNzaW9ucyBvbiB0aGUgNjQtYml0IGJvdW5kYXJ5IGluIElQdjYgYWRk cmVzc2luZyByZXZlYWxlZCBhIG5lZWQNCiAgIGZvciBhIGNsZWFyIHJlY29tbWVuZGF0aW9uIG9u IHdoaWNoIGJpdHMgbXVzdCBiZSB1c2VkIGJ5IGZvcndhcmRpbmcNCiAgIGRlY2lzaW9uLW1ha2lu ZyBwcm9jZXNzZXMuICBUaGlzIGRvY3VtZW50IHNrZXRjaGVzIGEgcmVjb21tZW5kYXRpb24NCiAg IHRvIGJlIGZvbGxvd2VkIGJ5IGZvcndhcmRpbmcgYW5kIHJvdXRpbmcgZGVzaWducyB3aXRoIHJl Z2FyZHMgdG8gdGhlDQogICBwcmVmaXggbGVuZ3RoLiAgVGhlIGFpbSBpcyB0byBhdm9pZCBoYXJk LWNvZGVkIHJvdXRpbmcgYW5kIGZvcndhcmRpbmcNCiAgIGRlc2lnbnMgdGhhdCBleGNsdWRlIHNv bWUgSVAgcHJlZml4IGxlbmd0aHMuDQoNClJlcXVpcmVtZW50cyBMYW5ndWFnZQ0KDQpbc25pcF0N Cg0KMS4gIEludHJvZHVjdGlvbg0KDQogICBSZWNlbnQgZGlzY3Vzc2lvbnMgb24gdGhlIDY0LWJp dCBib3VuZGFyeSBpbiBJUHY2IGFkZHJlc3NpbmcNCiAgIChbSS1ELmlldGYtNm1hbi13aHk2NF0p IHJldmVhbGVkIGEgbmVlZCBmb3IgYSBjbGVhciByZWNvbW1lbmRhdGlvbiBvbg0KICAgd2hpY2gg Yml0cyBtdXN0IGJlIHVzZWQgYnkgZm9yd2FyZGluZyBkZWNpc2lvbi1tYWtpbmcgcHJvY2Vzc2Vz Lg0KDQogICBBIGRldGFpbGVkIGFuYWx5c2lzIG9mIHRoZSA2NC1iaXQgYm91bmRhcnkgaW4gSVB2 NiBhZGRyZXNzaW5nLCBhbmQNCiAgIHRoZSBpbXBsaWNhdGlvbiBmb3IgZW5kLXNpdGUgcHJlZml4 IGFzc2lnbm1lbnQsIGlzIGRvY3VtZW50ZWQgaW4NCiAgIFtJLUQuaWV0Zi02bWFuLXdoeTY0XS4g IE5vIHJlY29tbWVuZGF0aW9uIGlzIGluY2x1ZGVkIGluDQogICBbSS1ELmlldGYtNm1hbi13aHk2 NF0uDQoNCiAgIEl0IGlzIGZ1bmRhbWVudGFsIHRvIG5vdCBsaW5rIHJvdXRpbmcgYW5kIGZvcndh cmRpbmcgdG8gdGhlIElQdjYNCiAgIHByZWZpeC9hZGRyZXNzIHNlbWFudGljcyBbUkZDNDI5MV0u ICBUaGlzIGRvY3VtZW50IGluY2x1ZGVzIGENCiAgIHJlY29tbWVuZGF0aW9uIGZvciB0aGF0IGFp bS4NCg0KICAgRm9yd2FyZGluZyBkZWNpc2lvbnMgbWFkZSBieSByb3V0ZXJzIHByaW1hcmlseSBy ZWx5IHVwb24gYSBsb25nZXN0DQogICBwcmVmaXgtbWF0Y2ggYWxnb3JpdGhtLiAgTGlrZSBpbiBJ UHY0LCB0aGUgSVB2NiBwcmVmaXgtbWF0Y2gNCiAgIGFsZ29yaXRobXMgaW52b2x2ZSBvbmUgY3Jp dGljYWwgb3BlcmF0aW9uIHdoaWNoIGlzIHRoZSBjb21wYXJpc29uIG9mDQogICBhIGRlc3RpbmF0 aW9uIGFkZHJlc3Mgd2l0aCBhIHByZWZpeCBwcmVzZW50IGluIGEgcm91dGluZyB0YWJsZSAoZS5n LiwNCiAgIGNvbXBhcmUgdGhlIDIwMDE6ZGI4OjoxIGFkZHJlc3Mgd2l0aCB0aGUgMjAwMTpkYjg6 Oi82NCBwcmVmaXgpLiAgVGhlDQogICByZWNvbW1lbmRhdGlvbiBvZiB0aGlzIGRvY3VtZW50IGlz IHRvIGJlIGZvbGxvd2VkIGJ5IHRoYXQgY3JpdGljYWwNCiAgIG9wZXJhdGlvbi4NCg0KICAgSXQg aXMgaW1wb3J0YW50IHRoYXQgdGhlIGNvbXBhcmUgb3BlcmF0aW9uIGJlIGEgYml0LXdpc2UgY29t cGFyaXNvbiwNCiAgIGFuZCBub3QgYSBieXRlLXdpc2UgY29tcGFyaXNvbi4NCg0KMi4gIFJlY29t bWVuZGF0aW9uDQoNCiAgIEZvcndhcmRpbmcgZGVjaXNpb24tbWFraW5nIHByb2Nlc3NlcyBNVVNU IE5PVCByZXN0cmljdCBieSBkZXNpZ24gdGhlDQogICBsZW5ndGggb2YgSVB2NiBwcmVmaXhlcy4g IEluIHBhcnRpY3VsYXIsIGZvcndhcmRpbmcgcHJvY2Vzc2VzIE1VU1QgYmUNCiAgIGRlc2lnbmVk IHRvIHByb2Nlc3MgcHJlZml4ZXMgb2YgYW55IGxlbmd0aCB1cCB0byAvMTI4LCBieSBpbmNyZW1l bnRzDQogICBvZiAxLg0KDQogICBPYnZpb3VzbHksIHBvbGljaWVzIGNhbiBiZSBlbmZvcmNlZCB0 byByZXN0cmljdCB0aGUgbGVuZ3RoIG9mIElQDQogICBwcmVmaXhlcyBhZHZlcnRpc2VkIHdpdGhp biBhIGdpdmVuIGRvbWFpbiBvciBpbiBhIGdpdmVuDQogICBpbnRlcmNvbm5lY3Rpb24gbGluay4g IFRoZXNlIHBvbGljaWVzIGFyZSBkZXBsb3ltZW50LXNwZWNpZmljIGFuZC9vcg0KICAgZHJpdmVu IGJ5IGFkbWluaXN0cmF0aXZlIChpbnRlcmNvbm5lY3Rpb24pIGNvbnNpZGVyYXRpb25zLg0KDQog ICBUaGlzIHJlY29tbWVuZGF0aW9uIGRvZXMgbm90IGNvbmZsaWN0IHdpdGggdGhlIDY0LWJpdCBi b3VuZGFyeQ0KICAgaW52b2x2ZWQgd2hlbiBJUHY2IHN0YXRlbGVzcyBhZGRyZXNzIGF1dG9jb25m aWd1cmF0aW9uIChTTEFBQywNCiAgIFtSRkM0ODYyXSkgaXMgdXNlZCBvbiBsaW5rcyBzdWNoIGFz IEV0aGVybmV0IFtSRkMyNDY0XS4NCg0KICAgU29tZSBsb29rdXAgYWxnb3JpdGhtIGltcGxlbWVu dGF0aW9ucyAoZmluZCB0aGUgcHJlZml4IG1hdGNoaW5nIGENCiAgIGdpdmVuIGRlc3RpbmF0aW9u IGFkZHJlc3MpIG1heSBiZSBhZmZlY3RlZCBieSB0aGlzIHJlY29tbWVuZGF0aW9uLA0KICAgZXZl biBtb3JlIHNvIGZvciBJUHY2IHRoYW4gSVB2NC4gIFRoZSBwZXJmb3JtYW5jZSBvZiBzb21lDQog ICBpbXBsZW1lbnRhdGlvbnMgbWF5IGJlIGRlZ3JhZGVkIHdoZW4gcHJlZml4IGxlbmd0aHMgYXJl IGxvbmdlciB0aGFuDQogICAvNjQuDQoNCjMuICBJQU5BIENvbnNpZGVyYXRpb25z From nobody Sat Dec 20 11:15: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 66C281A89A8 for ; Sat, 20 Dec 2014 11:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 49jmVNHeilgT for ; Sat, 20 Dec 2014 11:15:33 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C99191A878A for ; Sat, 20 Dec 2014 11:15:32 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id kq14so3296526pab.12 for ; Sat, 20 Dec 2014 11:15:32 -0800 (PST) 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=b9Lrwh+MuE6NoORUVHOOOKc8GHjn2bfYZuCdIyJUy6A=; b=GbgPm2lKbtzVFBd9czYtEsnSgks2A4JWTvzeXyYEnO0nX/V988ututpAxoNTLfSCWd V7vG1a8fQ92zzmznMclDHILrNKguIZhiISpwGVlahvFEb6iXKKUSJKUNOymP4eGsN6Nq oJXVrIqXoCvdLqc2kk9Wa8jhAUxILjjYMXzVtoV3Js/mt6aVfyM6eaSmv0NE0ebJNaqT VYwRoaxrXLFv5GhsMxiYUqa8q2ud/9pa9LijuofdGeXC6ZqhFOffdroV43otj1iC3OeZ UaVBCPMdN3sty5aPPUloND1PN6t78/Ez4eKy9cRU+qAd3Vy0069YQoH3kxWhgtiYXVvs W3mQ== X-Received: by 10.68.211.193 with SMTP id ne1mr22567796pbc.49.1419102932005; Sat, 20 Dec 2014 11:15:32 -0800 (PST) Received: from ?IPv6:2406:e007:4628:1:28cc:dc4c:9703:6781? ([2406:e007:4628:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id x10sm13179264pas.18.2014.12.20.11.15.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 20 Dec 2014 11:15:30 -0800 (PST) Message-ID: <5495CADF.10709@gmail.com> Date: Sun, 21 Dec 2014 08:15:43 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <5494097B.30207@gmail.com> <7B968136-C705-49A9-87DA-5B338DCE0FF3@cisco.com> In-Reply-To: <7B968136-C705-49A9-87DA-5B338DCE0FF3@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ROMCE3RGq6PajV1GZ_mtacNO4OE Cc: IPv6 Operations Subject: Re: [v6ops] 6man offspring - draft on prefix length recommendation for forwarding 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, 20 Dec 2014 19:15:35 -0000 On 20/12/2014 19:50, Fred Baker (fred) wrote: >=20 >> On Dec 19, 2014, at 7:47 PM, Lorenzo Colitti wrot= e: >> >> On Sat, Dec 20, 2014 at 10:35 AM, Fred Baker (fred) w= rote: >>> I=E2=80=99m not entirely sure why 6man would refer this to v6ops, giv= en that v6ops is not allowed by charter to solve the problem, and the spe= cification in question came from 6man... >> >> AIUI the intent of this document is not to redefine SLAAC, the IPv6 ad= dressing architecture, or anything of the sort. >> >> I believe this is just intended to be guidance to router implementors = that just because the IID length is 64 bits does not mean that routers ca= n restrict themselves to supporting only prefix lengths of /0-/64 and /12= 7 (a MUST in RFC6164), but must also support forwarding to prefixes of ar= bitrary other lengths such as /93. >=20 > No doubt. But 2460, 4291, and all the rest came from IPv6 or 6man. Why = on earth would they ask *us* to say that? Because, I think, there was a feeling that there's nothing wrong with the= standards track documents, but something wrong with the way some parts of the industry have interpreted them. It's been clear to me since 1994 that IPv6 shares the CIDR/VLSM model with IPv4 and therefore any length prefix is routeable. But I must say that when we drafted RFC-to-be draft-ietf-6man-why64 (which has just reached AUTH48), we didn't find anywhere that this is stated in detail. There is this in RFC 4291: "2.5. Unicast Addresses IPv6 unicast addresses are aggregatable with prefixes of arbitrary bit-length, similar to IPv4 addresses under Classless Inter-Domain Routing." We state it more extensively in the first paragraph of draft-ietf-6man-why64, but that's Informational. >=20 > When I refer to the charter, our charter allows us to do three things: = publish as informational, publish as BCP, or refer to some other working = group with our comments. This draft asks for Proposed Standard status. >=20 > https://datatracker.ietf.org/doc/draft-boucadair-6man-prefix-routing-re= co > https://tools.ietf.org/html/draft-boucadair-6man-prefix-routing-reco > "IPv6 Prefix Length Recommendation for Forwarding", Mohamed Boucadair= , > Alex Petrescu, 2014-09-24, >=20 > The text, if shortened at all, would be literally the words you spoke. = I=E2=80=99ll repeat it in this email. >=20 > Tell you what. Between now and 12/31, many of us are going to be out of= sight and out of mind. I=E2=80=99ll run a WGLC, starting 1/4/2015 Being European, I read that as 1st of April but maybe that's not what you mean ;-) > and running for two weeks. If we have any disagreement beyond nits, I=E2= =80=99ll express amazement, and if we don=E2=80=99t, I=E2=80=99ll do what= I think the 6man chairs should have done, which is send it to my favorit= e AD for publication. In the same call, I=E2=80=99ll ask whether it shoul= d be adopted as a working group document, and if (as I expect) we=E2=80=99= re all OK with that, I=E2=80=99ll ask Mohamed to file the update-to-pick-= up-comments as draft-ietf-v6ops-cidr-prefix. >=20 > > We have a convention that calls for a 64 bit IID on unicast addresses, = but are quite happy to use, to pick one documented example, 127 bit prefi= xes among consenting adults. If someone used DHCP to assign addresses and= chose to use a 79 bit prefix, would we know? Would we care? It=E2=80=99s= a CIDR prefix, for crying out loud.=20 > Read draft-ietf-6man-why64, which may even be RFC7xxx before the holidays= =2E There is breakage in some scenarios (but *not* routing protocol breakage)= =2E >=20 > > Of course, I have the same question about bit 70 and 71 of the address = (bit=E2=80=99s 6 and 7 of the RFC 4291 IID). In what case, specified in w= hat RFC and/or implemented in what hardware or software, do we extract an= EUI-64 or EUI-48 from the IID? If it was a Privacy/Temporary address, or= a SEND CGA Address, or something out of RFC 6052, what would we get if w= e did? Why, oh why, does it matter, and who actually cares, whether the I= ID is a locally-significant or globally significant value, or whether som= eone thought it came from a multicast MAC address? > Read RFC 7136. The answer: you're right, nobody should care. >=20 > OK, sanity slowly returning... >=20 > I=E2=80=99ll state two nits here:=20 >=20 > 1) I don=E2=80=99t know why this isn=E2=80=99t a BCP - a one-shot stand= ard. It=E2=80=99s not like we=E2=80=99re going to demonstrate interoperab= le implementations and bump it from Proposed Standard to Standard. That=E2= =80=99s not a strongly held opinion, but it is a question, and it=E2=80=99= s mine. I agree. I think this is addressed mainly to implementers and BCP would be appropriate. The sentence I quoted from RFC 4291 is the standards-track backing for the correct implementation practice. > 2) =3D=3D Outdated reference: A later version (-08) exists of draft-i= etf-6man-why64-05 And it will be RFC7xxx well before this draft is done. Brian From nobody Sat Dec 20 11:19: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 0FC031A1BD9 for ; Sat, 20 Dec 2014 11:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 whN4rHBFx2BW for ; Sat, 20 Dec 2014 11:19:06 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e: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 AF8481A88CF for ; Sat, 20 Dec 2014 11:19:06 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id eu11so3281355pac.22 for ; Sat, 20 Dec 2014 11:19:06 -0800 (PST) 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=KFT2a6M5aBrDOpYiCSWW0K3GuyuvpJuDJAeIVvIW/fc=; b=T0jSzUUS3sKMJ6WYsSGtw5QJTsn/G+9MSr6kIeDImWoBGRDavQVzC87u3eNimNB/RD 9o6CYsrsNEijBpD0klQOGItIgbtD1asAyhyL2TSWcO15z/hiMyT2Foijo4oQOOxBCGok LZ9OXpQZDFdX+CZoPXerUQ5jEoeAeLLVo2a/2cRN/XNIIWhibDvuTmXNzWtPQub4T97j 5wPWEOYlbz3r+R1DTGGe9FvxFtYY1ex0SczaXgcpskCH2/v0wGaBXAbFO2AknSNavmLK QJX2iM31CC58iB7ZH6feMHjXKeu90H1H+afiE+eX3QivLvedj6PikzIU3jYYMnCeawV7 GLMw== X-Received: by 10.66.182.200 with SMTP id eg8mr22472631pac.53.1419103145935; Sat, 20 Dec 2014 11:19:05 -0800 (PST) Received: from ?IPv6:2406:e007:4628:1:28cc:dc4c:9703:6781? ([2406:e007:4628:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id b16sm13063808pdj.76.2014.12.20.11.19.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 20 Dec 2014 11:19:04 -0800 (PST) Message-ID: <5495CBB5.5030407@gmail.com> Date: Sun, 21 Dec 2014 08:19:17 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: fred@cisco.com References: <201412200638.sBK6cHx7005385@irp-lnx1.cisco.com> In-Reply-To: <201412200638.sBK6cHx7005385@irp-lnx1.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/POyrhBD1d51SF6co-11pD6sSnWg Cc: v6ops@ietf.org Subject: Re: [v6ops] Adoption call for draft-boucadair-6man-prefix-routing-reco 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, 20 Dec 2014 19:19:08 -0000 I agree. I believe the text needs quite a lot of work, and the proposed status should be BCP. (I will develop detailed comments on the text, but not unless we reach consensus to adopt it in principle.) Regards Brian On 20/12/2014 19:38, fred@cisco.com wrote: > Are we agreed that draft-boucadair-6man-prefix-routing-reco should > be adopted as a working group document in v6ops, and renamed > draft-ietf-v6ops-cidr-prefix? > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Sun Dec 21 04:10: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 E688E1A039C for ; Sun, 21 Dec 2014 04:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-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 V82KOM5dX7ad for ; Sun, 21 Dec 2014 04:10:46 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 ED6981A03A1 for ; Sun, 21 Dec 2014 04:10:45 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 7536060134 for ; Sun, 21 Dec 2014 13:10:42 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 371EC60A11 for ; Sun, 21 Dec 2014 13:10:42 +0100 (CET) Received: (qmail 13617 invoked by uid 1007); 21 Dec 2014 13:10:42 +0100 Date: Sun, 21 Dec 2014 13:10:42 +0100 From: Gert Doering To: Mark ZZZ Smith Message-ID: <20141221121042.GK28745@Space.Net> References: <864357186.1538477.1419040596962.JavaMail.yahoo@jws10630.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <864357186.1538477.1419040596962.JavaMail.yahoo@jws10630.mail.bf1.yahoo.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vhF1-yX3ufnmYhsglpuGa7NozzY Cc: Tariq Saraj , "v6ops@ietf.org" Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 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, 21 Dec 2014 12:10:48 -0000 Hi, On Sat, Dec 20, 2014 at 01:56:36AM +0000, Mark ZZZ Smith wrote: > More broadly, what has been missing from 6to4 was the emulation > of a multicast capability, meaning that 6to4 currently doesn't > really meet IPv6's minimum link-layer link capability requirements. So should we deprecate 6to4, then? 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 Sun Dec 21 10:37: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 C978C1A6EFB for ; Sun, 21 Dec 2014 10:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 dSv351lgRPZj for ; Sun, 21 Dec 2014 10:37:50 -0800 (PST) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674031A6EF2 for ; Sun, 21 Dec 2014 10:37:50 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id y13so4469637pdi.3 for ; Sun, 21 Dec 2014 10:37:49 -0800 (PST) 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=8PmnbcOmsHqDNghhfXQIsImNMVdZSGzI28XlA8a1cz8=; b=qDrJnlp8y6JIR7jQ/kgR5N8f3PwuMk9becfEkgFMOQkifkhU+dzEMhy4RqQdP9Qowm 26MbkWvruE7Phh0sNUJIylOx5HkisQ/Mr2YQuHIdwWCMi98yigMLNbha2yzngeqzB+Gq GTWflTi5s+v1jNe+ymFIta4EpGmdijr6v8AlY6YNsj7AZL6CQpfDbhaSE/dOng0qSlis iJIq8fGOE2n90pmn3zlZr9qJYepaVhFYE+7xbnezW2PuDtyJnZutiH1OYNWsMwJdxVAl THXZRiKCdwCjeVOkol9zm1ZOgsnnGWorXnK1rj5DvoHzm8wk6FmRn/xoEO2P/te8FcFx 5JmQ== X-Received: by 10.66.169.209 with SMTP id ag17mr28962691pac.62.1419187069670; Sun, 21 Dec 2014 10:37:49 -0800 (PST) Received: from ?IPv6:2406:e007:4f6a:1:28cc:dc4c:9703:6781? ([2406:e007:4f6a:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id v8sm15098500pdp.94.2014.12.21.10.37.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Dec 2014 10:37:48 -0800 (PST) Message-ID: <54971372.7070101@gmail.com> Date: Mon, 22 Dec 2014 07:37:38 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Gert Doering References: <864357186.1538477.1419040596962.JavaMail.yahoo@jws10630.mail.bf1.yahoo.com> <20141221121042.GK28745@Space.Net> In-Reply-To: <20141221121042.GK28745@Space.Net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_XT6FBCZZCgmjUhdxglPTFp4a0Y Cc: Tariq Saraj , "v6ops@ietf.org" Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 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, 21 Dec 2014 18:37:52 -0000 On 22/12/2014 01:10, Gert Doering wrote: > Hi, > > On Sat, Dec 20, 2014 at 01:56:36AM +0000, Mark ZZZ Smith wrote: >> More broadly, what has been missing from 6to4 was the emulation >> of a multicast capability, meaning that 6to4 currently doesn't >> really meet IPv6's minimum link-layer link capability requirements. > > So should we deprecate 6to4, then? I would agree to that only if we deprecate RFC 6214 for the same reason. Bian From nobody Sun Dec 21 10:52: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 8C9201A6F67 for ; Sun, 21 Dec 2014 10:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 MgLwxykMr-wb for ; Sun, 21 Dec 2014 10:52:54 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 D42551A6F66 for ; Sun, 21 Dec 2014 10:52:53 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id B166E60A11 for ; Sun, 21 Dec 2014 19:52:51 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 7A1DA60736 for ; Sun, 21 Dec 2014 19:52:51 +0100 (CET) Received: (qmail 69542 invoked by uid 1007); 21 Dec 2014 19:52:51 +0100 Date: Sun, 21 Dec 2014 19:52:51 +0100 From: Gert Doering To: Brian E Carpenter Message-ID: <20141221185251.GN28745@Space.Net> References: <864357186.1538477.1419040596962.JavaMail.yahoo@jws10630.mail.bf1.yahoo.com> <20141221121042.GK28745@Space.Net> <54971372.7070101@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fE5EVoWPQ9dukZ79" Content-Disposition: inline In-Reply-To: <54971372.7070101@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/D0gpDqdB9jJWR_mov4SW2BFqEkk Cc: Tariq Saraj , "v6ops@ietf.org" Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 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, 21 Dec 2014 18:52:55 -0000 --fE5EVoWPQ9dukZ79 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Dec 22, 2014 at 07:37:38AM +1300, Brian E Carpenter wrote: > I would agree to that only if we deprecate RFC 6214 for the same reason. Which, amazingly, has a section on Multicast! 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 --fE5EVoWPQ9dukZ79 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVJcXA99WwGXkzn/FAQIEOxAAm+CEPW/3Mi/XFAfeRJMZh55yxPyTUA9K 9tO+G6TN++ZONdwaoAYkKgvWZaz2/BiKY4ifQZGqQ0COyYZTUkUHXqP+1vQX5fnP 4hIYsFqDHOA4yeZCwtPWtvEuLGScoAwdes4IELU8b7N0SJILUtwjtREza5/DySm+ 7NMOcC0ZAWcaHqviA8UTBRdhJfZ/n9p6sRNgNNTSYAflDnGb+xajiwlqH4e26sjM URORMMkUg7WfSTyod3ME/PNOP1XMQT+Pgl9BxpQe4imnXtpvk+Ls3NXguudm3bWi peDdoY7/pLG97swUDHFV7ydqKFsShQ+n54RGDltYtVXvtRt/VQ7/YXQVCIlle2Sk Vdpt2RFjW4IuB6MFyF6xKu1XO4cmgU0Itxo1bKw5clF7W0cgFjjRJs8TtttQEg3m K55yoCUmwsNeUy9yOZ/Vhz9dVLdF8HU5JVQZI2E7rqn6+KRLTvKsvNeGohVZGq+M +OhSA5X6HpHhfPWJ32bOVovk7zk9d4lTqm9bU5US82Bqm9O6iAOUA6k6CNdfMqsw 8saQoxhXp/3zycF3lRP1VVTAZac5F8JM37ckQPm7hS5CNo0XmKfoojxQOlyo2js6 O74SJ2o6ExL/HLqh19ZdkxwWqRsdd5+Ps+kWX8UuvqheEU9FqGfZc1n9PrSLXWSW /dUnF8gpFU4= =eYua -----END PGP SIGNATURE----- --fE5EVoWPQ9dukZ79-- From nobody Mon Dec 22 08:47: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 5C3BD1A1A67 for ; Mon, 22 Dec 2014 08:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 56Ryz3nOCCtS for ; Mon, 22 Dec 2014 08:47:49 -0800 (PST) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADA121A1A66 for ; Mon, 22 Dec 2014 08:47:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sBMGlm8h001889; Mon, 22 Dec 2014 10:47:48 -0600 Received: from XCH-BLV-107.nw.nos.boeing.com (xch-blv-107.nw.nos.boeing.com [130.247.25.123]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sBMGleCR001545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 22 Dec 2014 10:47:41 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-BLV-107.nw.nos.boeing.com ([169.254.7.206]) with mapi id 14.03.0210.002; Mon, 22 Dec 2014 08:47:40 -0800 From: "Templin, Fred L" To: Brian E Carpenter , Gert Doering Thread-Topic: [v6ops] v6ops Digest, Vol 52, Issue 41 Thread-Index: AQHQG/gvaeyYDXkk2UGnwo0Azb1fEpyafHQAgABsGwCAAO1MoA== Date: Mon, 22 Dec 2014 16:47:39 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DBC30E@XCH-BLV-504.nw.nos.boeing.com> References: <864357186.1538477.1419040596962.JavaMail.yahoo@jws10630.mail.bf1.yahoo.com> <20141221121042.GK28745@Space.Net> <54971372.7070101@gmail.com> In-Reply-To: <54971372.7070101@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/MjLogG13NHY9v-E03a9do6lbmxY Cc: Tariq Saraj , "v6ops@ietf.org" Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 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, 22 Dec 2014 16:47:51 -0000 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpente= r > Sent: Sunday, December 21, 2014 10:38 AM > To: Gert Doering > Cc: Tariq Saraj; v6ops@ietf.org > Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 >=20 > On 22/12/2014 01:10, Gert Doering wrote: > > Hi, > > > > On Sat, Dec 20, 2014 at 01:56:36AM +0000, Mark ZZZ Smith wrote: > >> More broadly, what has been missing from 6to4 was the emulation > >> of a multicast capability, meaning that 6to4 currently doesn't > >> really meet IPv6's minimum link-layer link capability requirements. > > > > So should we deprecate 6to4, then? >=20 > I would agree to that only if we deprecate RFC 6214 for the same reason. Or even RFC5214, for that matter... Thanks - Fred fred.l.templin@boeing.com > Bian >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Dec 22 08:52: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 7EE651A1A8A for ; Mon, 22 Dec 2014 08:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 FkbZhiLx0lrm for ; Mon, 22 Dec 2014 08:52:09 -0800 (PST) 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 976781A1A7E for ; Mon, 22 Dec 2014 08:52:08 -0800 (PST) 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 sBMGq7Jh029990; Mon, 22 Dec 2014 10:52:07 -0600 Received: from XCH-BLV-204.nw.nos.boeing.com (xch-blv-204.nw.nos.boeing.com [10.57.37.58]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sBMGq1Xr029946 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 22 Dec 2014 10:52:02 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-BLV-204.nw.nos.boeing.com ([169.254.4.177]) with mapi id 14.03.0210.002; Mon, 22 Dec 2014 08:52:00 -0800 From: "Templin, Fred L" To: Brian E Carpenter , Mark ZZZ Smith Thread-Topic: [v6ops] Multicast support [was: v6ops Digest, Vol 52, Issue 41] Thread-Index: AQHQHADMX/hg/A4MW0G5PK5E8ysMkJyb1uVQ Date: Mon, 22 Dec 2014 16:51:59 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DBC334@XCH-BLV-504.nw.nos.boeing.com> References: <864357186.1538477.1419040596962.JavaMail.yahoo@jws10630.mail.bf1.yahoo.com> <5494E5BA.9020901@gmail.com> In-Reply-To: <5494E5BA.9020901@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/M4TktxApiHkFDeXW1Le66177rj8 Cc: Tariq Saraj , "v6ops@ietf.org" Subject: Re: [v6ops] Multicast support [was: v6ops Digest, Vol 52, Issue 41] 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, 22 Dec 2014 16:52:12 -0000 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpente= r > Sent: Friday, December 19, 2014 6:58 PM > To: Mark ZZZ Smith > Cc: Tariq Saraj; v6ops@ietf.org > Subject: [v6ops] Multicast support [was: v6ops Digest, Vol 52, Issue 41] >=20 > On 20/12/2014 14:56, Mark ZZZ Smith wrote: > > > >> ________________________________ > >> From: Tariq Saraj > >> To: Mark ZZZ Smith ; v6ops@ietf.org > >> Sent: Saturday, 20 December 2014, 1:36 > >> Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 > >> > >> Smith what you are pointing is all at link level and purely related to= IPv6, Discussion is related Multicast support in Hybrid IPv4-IPv6 > Internet at IP layer (i.e. IPvX-IPvY-IPvX) > > > >> > > > > So the layer below the network layer is the link-layer. > > > > IPv6 is the network layer protocol, and therefore any protocols directl= y below it from the IPv6 point of view are either literally or > conceptually link-layer protocols. > > > > IPv6 encapsulated in IPv4 means that IPv4 is being used as by IPv6 as a= link-layer protocol, and is constructing a single link-layer link > for IPv6 to operate over. > > > > IPv6 expects link-layers to provide or emulate unicast and multicast ca= pabilities. If IPv4 is being used to construct a link-layer for IPv6 > to operate over, then it should provide or emulate a link-layer unicast a= nd multicast capability. >=20 > This was of course exactly the basis for 6over4 > (http://tools.ietf.org/html/rfc2529). BTW, this approach is adopted also for AERO. Thanks - Fred fred.l.templin@boeing.com > That was intended for single administrative domains, where IPv4 > multicast was a not > unreasonable but rather optimistic assumption in 1999. >=20 > > > > Once the (IPv4 constructed) link-layer provides or emulates both a unic= ast and multicast capability, there is nothing special about it > from the IPv6 point of view, and I don't think there needs to be any IPv6= -specific handling of this situation. If the link-layer IPv4 is > further encapsulated in other IP encapsulations ("i.e. IPvX-IPvY-IPvX"), = that is all hidden within the link-layer or below it and not visible > or relevant to IPv6 operation at the network layer. Making IPv6 aware of = that would be a layer violation. > > > > > > More broadly, what has been missing from 6to4 was the emulation of a mu= lticast capability, meaning that 6to4 currently doesn't > really meet IPv6's minimum link-layer link capability requirements. It se= ems some work was done on emulating it in the following > draft, but it didn't advance for some reason or another: > > > > Support for Multicast over 6to4 Networks > > https://tools.ietf.org/html/draft-thaler-ngtrans-6to4-multicast-01 >=20 > 14 years ago, multicast deployment was low on the list of IPv6 priorities= . >=20 > Brian >=20 > > > > > >> > >> On Fri, Dec 19, 2014 at 3:03 AM, Mark ZZZ Smith wrote: > >> > >>> > >>> > >>> > >>> ----- Original Message ----- > >>>> From: Gert Doering > >>>> To: Tariq Saraj > >>>> Cc: v6ops@ietf.org > >>>> Sent: Tuesday, 16 December 2014, 5:01 > >>>> Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41 > >>>> > >>>> Hi, > >>>> > >>>> On Sun, Dec 14, 2014 at 12:18:00AM +0500, Tariq Saraj wrote: > >>>>> There are some issues with 6rd as well, IPv6 with all its powerful= features > >>>>> is still under critical objections in academia just because of the= urgency > >>>>> shown by IETF in standardizing protocols like 6to4 and 6rd. 6to4 c= learly > >>>>> mentioned that it cannot support multicast at layer-3, on the othe= r end 6rd > >>>>> claimed that multicast can be provided, my question is that while > >>>>> standardizing 6rd which at that time was just supporting unicast t= raffic > >>>>> traversing across IPv4 network and its still not matured enough to= provide > >>>>> multicast support yet in its functionality other than using some p= roxy > >>>>> support for multicast traffic. why It was standardized ? > >>>> > >>>> There is no wide-area multicast anyway. > >>> > >>> Technically it should be universal, as DAD uses multicast and DAD is = mandatory (except for anycast addresses), which should > include tunnels. > >>> > >>> Links are supposed to provide multicast capability or emulate it to s= upport Neighbor Discovery: > >>> > >>> RFC4861: > >>> > >>> "2.2. Link Types > >>> > >>> Different link layers have different properties. The ones of concern > >>> to Neighbor Discovery are: > >>> > >>> multicast capable > >>> - a link that supports a native mechanism at the link > >>> layer for sending packets to all (i.e., broadcast) > >>> or a subset of all neighbors. > >>> > >>> point-to-point - a link that connects exactly two interfaces. A > >>> point-to-point link is assumed to have multicast > >>> capability and a link-local address. > >>> > >>> non-broadcast multi-access (NBMA) > >>> - a link to which more than two interfaces can attach, > >>> but that does not support a native form of multicast > >>> or broadcast (e.g., X.25, ATM, frame relay, etc.). > >>> Note that all link types (including NBMA) are > >>> expected to provide multicast service for > >>> applications that need it (e.g., using multicast > >>> servers). However, it is an issue for further study > >>> whether ND should use such facilities or an > >>> alternate mechanism that provides the equivalent > >>> multicast capability for ND." > >>> > >>> > >>> > >>>> So why bother if a closed user > >>>> group decides to deploy a stopgap technology to enable IPv6 access. > >>>> > >>>> And, when speaking about academia: do they have a "how to not write > >>>> e-mail" > >>>> class there? Like, "take a full digest with lots of unrelated mail = in it, > >>>> and write a top posting on top of it"? > >>>> > >>>> Gert Doering > >>>> -- NetMaster > >>>> -- > >>>> have you enabled IPv6 on something today...? > >>>> > >>>> SpaceNet AG Vorstand: Sebastian v. Bomhard > >>>> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-C= ulemann > >>>> 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 > >>>> > >>> > >> > >> > >> -- > >> > >> Regards > >> Tariq Saraj > >> Center for Research in Networks and Telecom (CoReNeT) > >> > >> > >> > >> > >> > >> > >> > > > > _______________________________________________ > > 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 Mon Dec 22 11:09: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 A6FD01A3B9B for ; Mon, 22 Dec 2014 11:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 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, MIME_8BIT_HEADER=0.3, 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 TTnTjhDYz0QI for ; Mon, 22 Dec 2014 11:09:13 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C0EE1A1E0E for ; Mon, 22 Dec 2014 11:08:57 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id n3so8926166wiv.5 for ; Mon, 22 Dec 2014 11:08:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nijzw1QT2hCHPxo8Ehl3BiT5dteVxC1kzSo5pxSX4rI=; b=p7ecXlNMDbscwFXMf8bh5J2hiUf69JJ2adMzNpXg2nyJzMqsj/1NSnrD+WHECyAEot RXFDxnG5uQQl0jPC6VKrrTmi/yCP8GW4RzwiyKWdZ0z+Q4e7u0kJR7MjfRr13MLV23eZ 3XZQUhij8VMdTWIHwsAkUVsK1YXLrC5Y48UbNxmTr5M1PDTibvEGZe3rjeyQG+MRmMcL M+q735hA0Wp6x9se1D5PSDsVpe1OQnVzja3OHxBXHBAxj+uK3+Mxn1ZrOXHN6YMD78Or W0X8AmeVPEy+Tx+o7Cqih4RmM3i2YjiSg2yZxMKP/smU/sAzR/DdxjcnlsTz2zZbvys1 3arQ== MIME-Version: 1.0 X-Received: by 10.181.12.100 with SMTP id ep4mr33382621wid.62.1419275336411; Mon, 22 Dec 2014 11:08:56 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.194.44.66 with HTTP; Mon, 22 Dec 2014 11:08:56 -0800 (PST) In-Reply-To: <201412200638.sBK6cHx7005385@irp-lnx1.cisco.com> References: <201412200638.sBK6cHx7005385@irp-lnx1.cisco.com> Date: Mon, 22 Dec 2014 11:08:56 -0800 X-Google-Sender-Auth: QnoSnaUZhKQpcUwNU2ot2b8_l0w Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6tf2knDq5nAp5ZZLu5bzeugL09E Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Adoption call for draft-boucadair-6man-prefix-routing-reco 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, 22 Dec 2014 19:09:15 -0000 At Fri, 19 Dec 2014 22:38:17 -0800, fred@cisco.com wrote: > Are we agreed that draft-boucadair-6man-prefix-routing-reco should > be adopted as a working group document in v6ops, and renamed > draft-ietf-v6ops-cidr-prefix? I agree. -- JINMEI, Tatuya From nobody Mon Dec 22 15:00: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 060071A88AF for ; Mon, 22 Dec 2014 14:59:54 -0800 (PST) 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, 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 tysJBocY9oCP for ; Mon, 22 Dec 2014 14:59:51 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 74E611A8546 for ; Mon, 22 Dec 2014 14:59:51 -0800 (PST) Received: from cl-1071.udi-01.br.sixxs.net ([2001:1291:200:42e::2]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Y3Bx7-000606-OA; Mon, 22 Dec 2014 23:59:50 +0100 Message-ID: <5498A23D.4080208@gont.com.ar> Date: Mon, 22 Dec 2014 19:59:09 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Brian E Carpenter , fred@cisco.com References: <201412200638.sBK6cHx7005385@irp-lnx1.cisco.com> <5495CBB5.5030407@gmail.com> In-Reply-To: <5495CBB5.5030407@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-gpGnab0Bq4k32WjVfjAJPYFQcQ Cc: v6ops@ietf.org Subject: Re: [v6ops] Adoption call for draft-boucadair-6man-prefix-routing-reco 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, 22 Dec 2014 22:59:54 -0000 On 12/20/2014 04:19 PM, Brian E Carpenter wrote: > I agree. I believe the text needs quite a lot of work, and the proposed > status should be BCP. (I will develop detailed comments on the text, but > not unless we reach consensus to adopt it in principle.) Isn't this part of the standard (i.e., std track) rather than BCP? -- i.e., this is not really a "practice". That said, IMHO the high order bit is that we convey the message, regardless of the specific track that we choose to do so. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Mon Dec 22 15:00: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 A8AA91A8546 for ; Mon, 22 Dec 2014 14:59:54 -0800 (PST) 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, 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 HmnYvVeBd5eZ for ; Mon, 22 Dec 2014 14:59:51 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 74E371A6FF1 for ; Mon, 22 Dec 2014 14:59:51 -0800 (PST) Received: from cl-1071.udi-01.br.sixxs.net ([2001:1291:200:42e::2]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Y3Bx1-000603-S5; Mon, 22 Dec 2014 23:59:44 +0100 Message-ID: <5498A1E3.8020808@gont.com.ar> Date: Mon, 22 Dec 2014 19:57:39 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , Lorenzo Colitti References: <5494097B.30207@gmail.com> <7B968136-C705-49A9-87DA-5B338DCE0FF3@cisco.com> In-Reply-To: <7B968136-C705-49A9-87DA-5B338DCE0FF3@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ILmExYuG_ENjBqPmzPCeWM8ejOc Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6man offspring - draft on prefix length recommendation for forwarding 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, 22 Dec 2014 22:59:54 -0000 Fred, On 12/20/2014 03:50 AM, Fred Baker (fred) wrote: > No doubt. But 2460, 4291, and all the rest came from IPv6 or 6man. > Why on earth would they ask *us* to say that? IMO, this should really be considered a clarification of the standard, and done in 6man. But, at the end of the day, it's better to do it wherever than bouncing the doc back and forth from one wg to another. > We have a convention that calls for a 64 bit IID on unicast > addresses, but are quite happy to use, to pick one documented > example, 127 bit prefixes among consenting adults. Some see the /127 thing as a kludge to mitigate a bug in router implementations (namely, NCE). > Of course, I have the same question about bit 70 and 71 of > the address (bit’s 6 and 7 of the RFC 4291 IID). In what case, > specified in what RFC and/or implemented in what hardware or > software, do we extract an EUI-64 or EUI-48 from the IID? Some people reportedly use this for trouble-shooting. -- IMO, they shouldn't, but... > If it was a > Privacy/Temporary address, or a SEND CGA Address, or something out of > RFC 6052, what would we get if we did? Garbage. But is' even simpler than that. MS Windows does not use the traditional SLAAC scheme (i.e. "embed the MAC address") for the stable addresses. -- so you don't even need to think of CGAs or temp addresses. > Why, oh why, does it matter, > and who actually cares, whether the IID is a locally-significant or > globally significant value, or whether someone thought it came from a > multicast MAC address? FWIW, while arguing the same thing that you're arguing (i.e., I'm with you here), some people have argued that MAC addresses are printed in boxes, and that they like to "predict" the IPv6 addresses that will be employed by these boxes. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Mon Dec 22 15:37: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 BA13F1A6FFC for ; Mon, 22 Dec 2014 15:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 RfJJdlKtLZox for ; Mon, 22 Dec 2014 15:37:34 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B501B1A6FF1 for ; Mon, 22 Dec 2014 15:37:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=772; q=dns/txt; s=iport; t=1419291454; x=1420501054; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=M9jzqxltaJ5XsaWGTsqOdMnejzlrj6LP52C/EAnBGHo=; b=bZgeaTdumql99nNTAGsnlEQwELbX1YauH+ycJrHCP+Nn4rCKu3Hsf+WF uqiiv/UCQ7sNKgAX9zBN4yllRrJpmKbXaM53Uo0yVnAwORAkOETsNt/Q5 i4VEjj/p0BKv/k2l+f89jQrjrhqyO/DC8JF1bV+/wWdI6ssiK+KEPmfFD w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUFAOeqmFStJA2J/2dsb2JhbABbgwaBKgTMPQKBFhYBAQEBAX2EDAEBAQMBHVwFCwIBCBguMiUCBA4FiCQI0CIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjz8zB4MWgRMBBIw6gVeFPYM1kUsig25vgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,627,1413244800"; d="scan'208";a="382057260" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-6.cisco.com with ESMTP; 22 Dec 2014 23:37:23 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sBMNbNgM031304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Dec 2014 23:37:23 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.66]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Mon, 22 Dec 2014 17:37:23 -0600 From: "Fred Baker (fred)" To: Fernando Gont Thread-Topic: [v6ops] Adoption call for draft-boucadair-6man-prefix-routing-reco Thread-Index: AQHQHkA7lQQaWWwWoka6q07S6fQGww== Date: Mon, 22 Dec 2014 23:37:22 +0000 Message-ID: <18A7D346-4F4B-48C6-BE9F-7D2EC071DE6D@cisco.com> References: <201412200638.sBK6cHx7005385@irp-lnx1.cisco.com> <5495CBB5.5030407@gmail.com> <5498A23D.4080208@gont.com.ar> In-Reply-To: <5498A23D.4080208@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.124] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ehBG-Jbbd5WKjEndQG7Fclsj1Z8 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Adoption call for draft-boucadair-6man-prefix-routing-reco 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, 22 Dec 2014 23:37:35 -0000 > On Dec 22, 2014, at 2:59 PM, Fernando Gont wrote: >=20 > On 12/20/2014 04:19 PM, Brian E Carpenter wrote: >> I agree. I believe the text needs quite a lot of work, and the proposed >> status should be BCP. (I will develop detailed comments on the text, but >> not unless we reach consensus to adopt it in principle.) >=20 > Isn't this part of the standard (i.e., std track) rather than BCP? -- > i.e., this is not really a "practice". If it=92s part of the standard, it shall come from the working group that w= rote the standard. If it=92s operational practice, it=92s a BCP. > That said, IMHO the high order bit is that we convey the message, > regardless of the specific track that we choose to do so. Kind of the point.= From nobody Mon Dec 22 15:42: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 9C44B1A88CC for ; Mon, 22 Dec 2014 15:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.51 X-Spam-Level: X-Spam-Status: No, score=-5.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 FO5NxNT990MB for ; Mon, 22 Dec 2014 15:42:43 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C75B1A88A3 for ; Mon, 22 Dec 2014 15:42:43 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Y3Ccb-0004g8-CX; Mon, 22 Dec 2014 23:42:41 +0000 Date: Mon, 22 Dec 2014 18:42:41 -0500 Message-ID: From: Randy Bush To: Fred Baker In-Reply-To: References: <5494097B.30207@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/q3CCiD58Ec3ttYDQYrCwoxYiJN8 Cc: V6 Ops List Subject: Re: [v6ops] 6man offspring - draft on prefix length recommendation for forwarding 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, 22 Dec 2014 23:42:44 -0000 i think i have already voiced my strong support of this draft. but it seems to be bouncing around wgs, so i'll give it a shot here. this is a no-brainer, but i am confident we can make it a religious war. randy From nobody Mon Dec 22 16:09: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 01A921A88DD for ; Mon, 22 Dec 2014 16:09:57 -0800 (PST) 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, 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 RjkGYw4dAxqf for ; Mon, 22 Dec 2014 16:09:55 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 EB15C1A1B8B for ; Mon, 22 Dec 2014 16:09:54 -0800 (PST) Received: from cl-1071.udi-01.br.sixxs.net ([2001:1291:200:42e::2]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Y3D2t-0007Yq-S2; Tue, 23 Dec 2014 01:09:52 +0100 Message-ID: <5498A721.20800@gont.com.ar> Date: Mon, 22 Dec 2014 20:20:01 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: fred@cisco.com, v6ops@ietf.org References: <201412200638.sBK6cHx7005385@irp-lnx1.cisco.com> In-Reply-To: <201412200638.sBK6cHx7005385@irp-lnx1.cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Kok7gTgkPh2NDOyFbYfPGiPzKSw Subject: Re: [v6ops] Adoption call for draft-boucadair-6man-prefix-routing-reco 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, 23 Dec 2014 00:09:57 -0000 On 12/20/2014 03:38 AM, fred@cisco.com wrote: > Are we agreed that draft-boucadair-6man-prefix-routing-reco should > be adopted as a working group document in v6ops, and renamed > draft-ietf-v6ops-cidr-prefix? Yes. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Mon Dec 22 17: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 0B84A1AC443 for ; Mon, 22 Dec 2014 17:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-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 x0Q6caunY4PZ for ; Mon, 22 Dec 2014 17:31:21 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1EB1AC437 for ; Mon, 22 Dec 2014 17:31:20 -0800 (PST) Received: from [10.1.17.19] ([40.140.6.50]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id sBN2P5it018635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Dec 2014 18:25:58 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com sBN2P5it018635 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1419301559; bh=bZPZs1KkzYamb12w3WmeSOXE26k=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nflC5Z+mp4aDg+m6cHLtypLYe7hnNLoTPB3gkMCBz+kTsl2b2FazAD2+3WBhnVyd3 hMgBrjXT2McLVKjBKerN7KGJPMrGNBJQUTd3MMjcUcybzyU8cvf70ELLg88rv8U97I n3TOe0CnO4BM6jnd8v5+GEHEf4A6nB1Av+eXXUw0= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Owen DeLong In-Reply-To: <5498A721.20800@gont.com.ar> Date: Mon, 22 Dec 2014 17:25:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201412200638.sBK6cHx7005385@irp-lnx1.cisco.com> <5498A721.20800@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1993) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 22 Dec 2014 18:25:59 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1-9KArHN7PksR-1rQOpa2tHh7h0 Cc: v6ops@ietf.org Subject: Re: [v6ops] Adoption call for draft-boucadair-6man-prefix-routing-reco 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, 23 Dec 2014 01:31:24 -0000 I=E2=80=99d rather see it on the STD track in the appropriate working = group, but if 6man is, for some reason, throwing it over the wall, then I=E2=80=99d say adopting it here as a = BCP is better than not doing so. Owen > On Dec 22, 2014, at 3:20 PM, Fernando Gont = wrote: >=20 > On 12/20/2014 03:38 AM, fred@cisco.com wrote: >> Are we agreed that draft-boucadair-6man-prefix-routing-reco should >> be adopted as a working group document in v6ops, and renamed >> draft-ietf-v6ops-cidr-prefix? >=20 > Yes. >=20 > Thanks, > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops