From markzzzsmith@yahoo.com.au Sat Jun 1 01:21:18 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F14B21F881C for ; Sat, 1 Jun 2013 01:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sph-7W6K1P6 for ; Sat, 1 Jun 2013 01:21:12 -0700 (PDT) Received: from nm43-vm10.bullet.mail.bf1.yahoo.com (nm43-vm10.bullet.mail.bf1.yahoo.com [216.109.114.171]) by ietfa.amsl.com (Postfix) with ESMTP id CB27A21F85C9 for ; Sat, 1 Jun 2013 01:21:08 -0700 (PDT) Received: from [98.139.212.148] by nm43.bullet.mail.bf1.yahoo.com with NNFMP; 01 Jun 2013 08:21:08 -0000 Received: from [98.139.212.218] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 01 Jun 2013 08:21:08 -0000 Received: from [127.0.0.1] by omp1027.mail.bf1.yahoo.com with NNFMP; 01 Jun 2013 08:21:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 174479.48450.bm@omp1027.mail.bf1.yahoo.com Received: (qmail 24031 invoked by uid 60001); 1 Jun 2013 08:21:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1370074867; bh=E24b9aq082/R5Wrhq79UcjsZqMhqnWtSLqC28OEfuv0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=B1VTBXiJsKn1UYzh5aO1etlCX/PJ2Iapdt1/y3ZBVrgZrrv8W0c0rvcRpZw1KT0/tMH0HmmCnOrSe4RtFUDF1ekWCCvRPxD544E/0VYoTrrcXpElC/x59QzwbQBoFhFGYzBVK4C3dtvxKoCbL6EJoV0MakA56InME/hLgjlROwY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZtS3YvQMJH3Kk7vgxZrfwVq0RknI6tLRoJUOtTBg8oQgHWyhSifRBwwzKwZYzjdRmCyzPyiAMtuxicJTcxBdwlYEPspNcpLefji0EhcfJcyQfDqz+b7CVeqm1x4UK5GdzrUktwZ3CBvjXXcXEBHCz+P2yKtSyQXacVvuBMobv6c=; X-YMail-OSG: m.b.Qj8VM1knNQTVJEBIzYOfa8mrYqDbJ06DrGVZBsMhGiE _hAB83TxrVOVuRDrmXq7OZesCyjS9YTLVzQgBSc8q4.0IA2mK5Do48a4EQt3 UJy9gU58DXlHrN7ykLbz8oewN8fc4UbyITsoPOJ1rnAAAmPI07ve2Z3F0Xw2 baWnE1Dl8gEI4QQRDkC5zlO4kPyCXm.adV1bsJoLgfOM9mbFiFgAmLaKWlZQ pddouIaKu90LLjD9ONbi9ajiZgdtGTgejgowr50t0MFiMvWHZ9Zx_wEkERAg HU7N3WlY486vWk.bPAoGiScfO5.klVB.8q7giuwhYNom3ymubGbrfiI4uu0H mPwxGBcFGcL1sZYq2WFgV56_QV7O9893OWAFlUb5lOTOFUEA4sWUKpoMfgVt 1S69RtLOqTi_sKoZ_LmgGazDf4akNoEVqfuzB0c66QD5B5aCAXLHI6Ip1zat MsJ04ULfBdrFd4Q3D0FlpcXUako459PklrC47KC4rRAVYuFD_oEStVhFQdh1 lokYc_Ss_I4pwL4rubaq76_QIqV_yT0muQGNLetalOWfm0HmfDvWdClWIb8B JTjClsw-- Received: from [150.101.221.237] by web142504.mail.bf1.yahoo.com via HTTP; Sat, 01 Jun 2013 01:21:07 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBTaGFuZSBBbWFudGUgPHNoYW5lQGNhc3RsZXBvaW50Lm5ldD4KPiBUbzogUmF5IEh1bnRlciA8djZvcHNAZ2xvYmlzLm5ldD4KPiBDYzogIjx2Nm9wc0BpZXRmLm9yZz4iIDx2Nm9wc0BpZXRmLm9yZz47ICJkcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXhAdG9vbHMuaWV0Zi5vcmciIDxkcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXhAdG9vbHMuaWV0Zi5vcmc.OyAiaXB2NkBpZXRmLm9yZyIgPGlwdjZAaWV0Zi5vcmcBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <51A71ACA.3000608@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> <51A733E1.7040008@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99A07@nkgeml512-mbx.china.huawei.com> <51A841B5.3010805@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99CF4@nkgeml512-mbx.china.huawei.com> <6B838546-4FB3-4EDB-9F84-D8CF0AF3080D@millnert.se> <51A87174.3080204@globis.net> <708D821F-0EA0-44EE-AA5E-6321C7E73910@castlepoint.net> Message-ID: <1370074867.19423.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Sat, 1 Jun 2013 01:21:07 -0700 (PDT) From: Mark Smith Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 To: Shane Amante , Ray Hunter In-Reply-To: <708D821F-0EA0-44EE-AA5E-6321C7E73910@castlepoint.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 08:21:18 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Shane Amante =0A> To: Ray Hunter =0A> Cc: "" ; "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" ; "ipv6@ietf.org" =0A> Sent: Saturday, 1 June 2013 1:20 PM=0A> Subject: Re: [v6ops] Coul= d IPv6 address be more than=0A=09locator?//draft-jiang-v6ops-semantic-prefi= x-03=0A> =0A> Hi Sheng, Ray,=0A> =0A> On May 31, 2013, at 3:46 AM, Ray Hunt= er wrote:=0A> [--snip--]=0A>> But why are people coming= up with these schemes for encoding semantics=0A>> in the address prefixes= in the first place? That's what I'd like to=0A>> understand first and for= emost: what lack of functionality is=0A>> motivating/forcing these people = to adopt such schemes?=0A> =0A> +1.=A0 =0A> =0A> In one part of the draft, = Section 2.1, it appears to suggest that packets coming =0A> in to the borde= r of an SP boundary are "untrusted", therefore existing =0A> packet header = fields (e.g.: IPv6 TC) cannot be trusted.=A0 If incoming packets are =0A> u= ntrusted:=0A> - why doesn't the SP deploy unicast RPF to drop incoming pack= ets with an =0A> illegitimate source IP address/prefix?=0A> - more importan= tly, how is an SP able to _trust_ and somehow enforce that the =0A> prefixe= s that it is handing out (dynamically via DHCP?) are being properly =0A> as= signed according the policies governing the mapping of semantic prefix =0A>= <-> user-type/application/security-domain/etc.?=0A>=0A=0AI suppose if the = SP is assigning individual addresses to individual hosts, if they hosts "do= n't like" the policy, they don't get an address to use at all. Delegating t= he prefix for assignment means delegating the enforcement of the prefix ass= ociated policy.=0A=0A=A0 =0ARegards,=0AMark. From Ted.Lemon@nominum.com Sat Jun 1 03:59:07 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AB921F86DC; Sat, 1 Jun 2013 03:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mx+1g6Z0aSA; Sat, 1 Jun 2013 03:59:01 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id D6E7B21F8956; Sat, 1 Jun 2013 03:58:56 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUanT7/UpvlX24gX9aF1IQeiULAAjHKpo@postini.com; Sat, 01 Jun 2013 03:58:56 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 34F6F1B81D4; Sat, 1 Jun 2013 03:58:55 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2A023190052; Sat, 1 Jun 2013 03:58:55 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Sat, 1 Jun 2013 03:58:55 -0700 From: Ted Lemon To: Owen DeLong Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogA== Date: Sat, 1 Jun 2013 10:58:54 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C0209mbx01winnominum_" MIME-Version: 1.0 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 10:59:07 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C0209mbx01winnominum_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On May 31, 2013, at 10:47 PM, Owen DeLong > wrote: What solutions exist today that provide for the home of the future where th= ere are, in fact, multiple levels of routers many of which are managing rou= ters underneath them with multiple links attached? There's a fairly ugly DHCPv6 PD binary splitting solution that's actually b= een implemented, which is not efficient because it does sub-delegations of = >/64 prefixes to internal routers. There's the better PD solution that le= ts the router that got the initial delegation sub-delegate /64s throughout = the home, which results in efficient use of the initial prefix. And there= 's delegation over ZOSPF, for which there is running code that the implemen= tors seem to think works, and which is also efficient in its use of prefixe= s. This is a solved problem. --_000_8D23D4052ABE7A4490E77B1A012B6307751C0209mbx01winnominum_ Content-Type: text/html; charset="us-ascii" Content-ID: <3F9E915BDEE32A4BA7EA2C33A7BDD2F1@nominum.com> Content-Transfer-Encoding: quoted-printable
On May 31, 2013, at 10:47 PM, Owen DeLong <owen@delong.com> wrote:
What solutions exist today that provide for the home of the future where there = are, in fact, multiple levels of routers many of which are managing routers= underneath them with multiple links attached?

There's a fairly ugly DHCPv6 PD binary splitting solution that's actua= lly been implemented, which is not efficient because it does sub-delegation= s of >/64 prefixes to internal routers.   There's the better PD sol= ution that lets the router that got the initial delegation sub-delegate /64s throughout the home, which results in= efficient use of the initial prefix.   And there's delegation over ZO= SPF, for which there is running code that the implementors seem to think wo= rks, and which is also efficient in its use of prefixes.   This is a solved problem.

--_000_8D23D4052ABE7A4490E77B1A012B6307751C0209mbx01winnominum_-- From owen@delong.com Sat Jun 1 05:43:10 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9593B21F9AB1; Sat, 1 Jun 2013 05:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ti2qjGGEvziQ; Sat, 1 Jun 2013 05:43:09 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C7A5121F9ABA; Sat, 1 Jun 2013 05:43:00 -0700 (PDT) Received: from [192.168.6.83] (ip-64-134-24-48.public.wayport.net [64.134.24.48]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r51Cg8tq020976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 1 Jun 2013 05:42:09 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r51Cg8tq020976 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370090531; bh=8LX8KVzSG2A581M4xXdl2U/Rk4Y=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=l5X+OiunHohtoXLGaVo+hV6I8PGOS4+36auQZIxke/0PDZ4oGuRDEIxUa+hoDlBYK OtFn561SlhdwSq/AdwduZygNs7MbnPeHQVf87tS+QblgsJwFmSnOBeuJ8h88wREDFL ij2rfn0WzeEvIckhrnZM24AEmCPaWvYZDPX4GnAM= Content-Type: multipart/alternative; boundary="Apple-Mail=_C423C76B-B6EC-4BAD-BE5E-A60051421214" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Owen DeLong In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> Date: Sat, 1 Jun 2013 07:42:08 -0500 Message-Id: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Sat, 01 Jun 2013 05:42:11 -0700 (PDT) Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 12:43:10 -0000 --Apple-Mail=_C423C76B-B6EC-4BAD-BE5E-A60051421214 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 1, 2013, at 5:58 AM, Ted Lemon wrote: > On May 31, 2013, at 10:47 PM, Owen DeLong wrote: >> What solutions exist today that provide for the home of the future = where there are, in fact, multiple levels of routers many of which are = managing routers underneath them with multiple links attached? >=20 > There's a fairly ugly DHCPv6 PD binary splitting solution that's = actually been implemented, which is not efficient because it does = sub-delegations of >/64 prefixes to internal routers. There's the = better PD solution that lets the router that got the initial delegation = sub-delegate /64s throughout the home, which results in efficient use of = the initial prefix. And there's delegation over ZOSPF, for which there = is running code that the implementors seem to think works, and which is = also efficient in its use of prefixes. This is a solved problem. >=20 URLs to documentation of any/all of the above? The only one I was aware of was the first one you mentioned, which, = while running is fairly primitive in its capabilities. The second one sounds like it gets pretty dysfunctional if you have = downstream routers with downstream routers. I haven't even heard of the third one, so absent some reference, I can't = really comment. Owen --Apple-Mail=_C423C76B-B6EC-4BAD-BE5E-A60051421214 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jun 1, 2013, at 5:58 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On May 31, 2013, at 10:47 PM, Owen DeLong <owen@delong.com> wrote:
What solutions exist today that provide for the home of the future where there are, in fact, multiple levels of routers many of which are managing routers underneath them with multiple links attached?

There's a fairly ugly DHCPv6 PD binary splitting solution that's actually been implemented, which is not efficient because it does sub-delegations of >/64 prefixes to internal routers.   There's the better PD solution that lets the router that got the initial delegation sub-delegate /64s throughout the home, which results in efficient use of the initial prefix.   And there's delegation over ZOSPF, for which there is running code that the implementors seem to think works, and which is also efficient in its use of prefixes.   This is a solved problem.


URLs to documentation of any/all of the above?

The only one I was aware of was the first one you mentioned, which, while running is fairly primitive in its capabilities.

The second one sounds like it gets pretty dysfunctional if you have downstream routers with downstream routers.

I haven't even heard of the third one, so absent some reference, I can't really comment.

Owen

--Apple-Mail=_C423C76B-B6EC-4BAD-BE5E-A60051421214-- From Ted.Lemon@nominum.com Sat Jun 1 09:14:48 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2536B21F9C6B; Sat, 1 Jun 2013 09:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a36dqMiXrRIM; Sat, 1 Jun 2013 09:14:41 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id E4A7F21F9C76; Sat, 1 Jun 2013 09:14:39 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUaod7lDx+m9/OzSxu6lvHxMjrF5IBtBp@postini.com; Sat, 01 Jun 2013 09:14:40 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6FCE51B81BE; Sat, 1 Jun 2013 09:14:38 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 61BCC190052; Sat, 1 Jun 2013 09:14:38 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Sat, 1 Jun 2013 09:14:38 -0700 From: Ted Lemon To: Owen DeLong Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoA= Date: Sat, 1 Jun 2013 16:14:37 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C05FEmbx01winnominum_" MIME-Version: 1.0 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 16:14:48 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C05FEmbx01winnominum_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jun 1, 2013, at 8:42 AM, Owen DeLong > wrote: The second one sounds like it gets pretty dysfunctional if you have downstr= eam routers with downstream routers. There's no such thing, unless you think home nets are transit nets. If yo= u mean what if the network is multihomed, and the edge routers for the two = providers are topologically separated, that's no problem at all, because th= e prefix distribution trees are independent. I explained this in a messag= e to the homenet mailing list a while back=97nobody's written it up in a dr= aft because the homenet guys are more keen on ZOSPF, for which I'm pretty s= ure there's a draft either with Jari's or Ole's name on it. --_000_8D23D4052ABE7A4490E77B1A012B6307751C05FEmbx01winnominum_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jun 1, 2013, at 8:42 AM, Owen DeLong <owen@delong.com> wrote:
The second one sounds like it gets pretty dysfunctional if you have downstr= eam routers with downstream routers.

There's no such thing, unless you think home nets are transit nets. &n= bsp; If you mean what if the network is multihomed, and the edge routers fo= r the two providers are topologically separated, that's no problem at all, = because the prefix distribution trees are independent.   I explained this in a message to the homenet maili= ng list a while back=97nobody's written it up in a draft because the homene= t guys are more keen on ZOSPF, for which I'm pretty sure there's a draft ei= ther with Jari's or Ole's name on it.

--_000_8D23D4052ABE7A4490E77B1A012B6307751C05FEmbx01winnominum_-- From tjc@ecs.soton.ac.uk Sat Jun 1 12:06:21 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4963E21F9D58; Sat, 1 Jun 2013 12:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlP-Fi8QMTGD; Sat, 1 Jun 2013 12:06:20 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 28CDD21F9CAA; Sat, 1 Jun 2013 12:06:16 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r51J61tR017349; Sat, 1 Jun 2013 20:06:01 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r51J61tR017349 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1370113562; bh=kgCpTkylLRqeYpTx56wDLan0R9U=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=eicHj9d+YVN3P+jU5uXNyt85YApo5BkGwR3UpJvOG2OtAdYsxhkk3Ck/Lr1iqW33/ Jk632TAsHD73+EfFluqi+H/Fa0YT8k8F4PkU6vN/w8bHGq+c3jBkYmpRTLuyk92e5r E+N8kkmD52DhDkZR6hxr0gyqTdGVdqYDisy6Ty54= 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 p50K610430649660b7 ret-id none; Sat, 01 Jun 2013 20:06:02 +0100 Received: from [192.168.1.103] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r51J5XDD004991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 1 Jun 2013 20:05:34 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_18CFA72D-FE29-4E03-A49A-570EBEA57B56" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Tim Chown In-Reply-To: Date: Sat, 1 Jun 2013 20:05:37 +0100 Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> To: Owen DeLong X-Mailer: Apple Mail (2.1503) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p50K61043064966000; tid=p50K610430649660b7; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r51J61tR017349 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 19:06:21 -0000 --Apple-Mail=_18CFA72D-FE29-4E03-A49A-570EBEA57B56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 1 Jun 2013, at 13:42, Owen DeLong wrote: >=20 > On Jun 1, 2013, at 5:58 AM, Ted Lemon wrote: >=20 >> On May 31, 2013, at 10:47 PM, Owen DeLong wrote: >>> What solutions exist today that provide for the home of the future = where there are, in fact, multiple levels of routers many of which are = managing routers underneath them with multiple links attached? >>=20 >> There's a fairly ugly DHCPv6 PD binary splitting solution that's = actually been implemented, which is not efficient because it does = sub-delegations of >/64 prefixes to internal routers. There's the = better PD solution that lets the router that got the initial delegation = sub-delegate /64s throughout the home, which results in efficient use of = the initial prefix. And there's delegation over ZOSPF, for which there = is running code that the implementors seem to think works, and which is = also efficient in its use of prefixes. This is a solved problem. >>=20 >=20 > URLs to documentation of any/all of the above? >=20 > The only one I was aware of was the first one you mentioned, which, = while running is fairly primitive in its capabilities. >=20 > The second one sounds like it gets pretty dysfunctional if you have = downstream routers with downstream routers. >=20 > I haven't even heard of the third one, so absent some reference, I = can't really comment. zOSPF-based: http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-autoconfig-00 http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-04 DHCP-based: http://tools.ietf.org/html/draft-grundemann-homenet-hipnet-01 http://tools.ietf.org/html/draft-baker-homenet-prefix-assignment-01 See also http://tools.ietf.org/html/draft-ietf-homenet-arch-08#page-25 There are at least two interoperable implementations of the zOSPF = solution using different platforms (bird and quagga) Tim --Apple-Mail=_18CFA72D-FE29-4E03-A49A-570EBEA57B56 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii owen@delong.com> wrote:

On Jun 1, 2013, = at 5:58 AM, Ted Lemon <Ted.Lemon@nominum.com> = wrote:

On May 31, 2013, at 10:47 PM, Owen DeLong <owen@delong.com> wrote:
h= ttp://tools.ietf.org/html/draft-ietf-ospf-ospfv3-autoconfig-00
http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-04=

DHCP-based:
<= a = href=3D"http://tools.ietf.org/html/draft-baker-homenet-prefix-assignment-0= 1">http://tools.ietf.org/html/draft-baker-homenet-prefix-assignment-01=

See also
<= br>
There are at least two interoperable implementations of = the zOSPF solution using different platforms (bird and = quagga)

Tim

= --Apple-Mail=_18CFA72D-FE29-4E03-A49A-570EBEA57B56-- From owen@delong.com Sat Jun 1 22:23:00 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6388F21F9F81; Sat, 1 Jun 2013 22:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjaUii1X81Rt; Sat, 1 Jun 2013 22:22:59 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id DC71421F9F7E; Sat, 1 Jun 2013 22:22:58 -0700 (PDT) Received: from [192.168.6.83] (ip-64-134-24-48.public.wayport.net [64.134.24.48]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r525M0hV025264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 1 Jun 2013 22:22:01 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r525M0hV025264 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370150524; bh=lSEBdwd1zC9Ha0jrHBcbg3IVIYs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=yoW86XH+2ow1WriMyEaY128BUgtSES8yfBRN1S0G2DoQU73lunKyHNz2uMDQaAYlr kx3L0L5m2YyiJdmeI9WJz+66W7y0JeLtuFbeh4E+1X0HGVZM6oK4MFEkok3Y7aiumK vXkzh1nzvg5qjTOLskd/eewxYunM5uZtiOuGjYqE= Content-Type: multipart/alternative; boundary="Apple-Mail=_1F996DA9-FB2B-4A0B-AC97-C606DB725621" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Owen DeLong In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> Date: Sun, 2 Jun 2013 00:22:02 -0500 Message-Id: <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Sat, 01 Jun 2013 22:22:04 -0700 (PDT) Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 05:23:00 -0000 --Apple-Mail=_1F996DA9-FB2B-4A0B-AC97-C606DB725621 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 1, 2013, at 11:14 AM, Ted Lemon wrote: > On Jun 1, 2013, at 8:42 AM, Owen DeLong wrote: >> The second one sounds like it gets pretty dysfunctional if you have = downstream routers with downstream routers. >=20 > There's no such thing, unless you think home nets are transit nets. = If you mean what if the network is multihomed, and the edge routers for = the two providers are topologically separated, that's no problem at all, = because the prefix distribution trees are independent. I explained = this in a message to the homenet mailing list a while back=97nobody's = written it up in a draft because the homenet guys are more keen on = ZOSPF, for which I'm pretty sure there's a draft either with Jari's or = Ole's name on it. >=20 Uh=85 {ISP Connection} -> Router -> multiple segments each of which contains = one or more routers, some of which have multiple segments which contain = additional routers. All of the routers below the second tier are downstream from the routers = at the second tier which are downstream from the first tier router. You may not see this very much in homes today, but there is no reason = whatsoever to believe that it will not be commonplace in the future. Owen --Apple-Mail=_1F996DA9-FB2B-4A0B-AC97-C606DB725621 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Ted.Lemon@nominum.com> = wrote:

On Jun 1, 2013, at 8:42 AM, Owen DeLong <owen@delong.com> wrote:
The second one sounds like it gets pretty dysfunctional if you have = downstream routers with downstream routers.

There's no such thing, unless you think home nets are transit nets. =   If you mean what if the network is multihomed, and the edge = routers for the two providers are topologically separated, that's no = problem at all, because the prefix distribution trees are independent.   I explained this in a message to the homenet = mailing list a while back=97nobody's written it up in a draft because = the homenet guys are more keen on ZOSPF, for which I'm pretty sure = there's a draft either with Jari's or Ole's name on it.


Uh=85

{ISP = Connection} -> Router -> multiple segments each of which contains = one or more routers, some of which have multiple segments which contain = additional routers.

All of the routers below = the second tier are downstream from the routers at the second tier which = are downstream from the first tier router.

You = may not see this very much in homes today, but there is no reason = whatsoever to believe that it will not be commonplace in the = future.

Owen

= --Apple-Mail=_1F996DA9-FB2B-4A0B-AC97-C606DB725621-- From Ted.Lemon@nominum.com Sat Jun 1 23:52:05 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5C521F9F9C; Sat, 1 Jun 2013 23:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrPYmkjWcDdG; Sat, 1 Jun 2013 23:51:58 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3E90E21F9F93; Sat, 1 Jun 2013 23:51:58 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUarrja0k2iw8xjTun2ABEO3t9IGH1POi@postini.com; Sat, 01 Jun 2013 23:51:58 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C3C631B818D; Sat, 1 Jun 2013 23:51:57 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B42AB190052; Sat, 1 Jun 2013 23:51:57 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sat, 1 Jun 2013 23:51:51 -0700 From: Ted Lemon To: Owen DeLong Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcA Date: Sun, 2 Jun 2013 06:51:50 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> In-Reply-To: <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C1363mbx01winnominum_" MIME-Version: 1.0 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 06:52:05 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C1363mbx01winnominum_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jun 2, 2013, at 1:22 AM, Owen DeLong > wrote: {ISP Connection} -> Router -> multiple segments each of which contains one = or more routers, some of which have multiple segments which contain additio= nal routers. All of the routers below the second tier are downstream from the routers at= the second tier which are downstream from the first tier router. This is trivially solved with PD at the PE router that gets the delegation = from the ISP. I thought you were talking about a multi-homed topology. = Also trivially solved, but might involve two edge routers each with their o= wn set of prefixes to delegate. --_000_8D23D4052ABE7A4490E77B1A012B6307751C1363mbx01winnominum_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jun 2, 2013, at 1:22 AM, Owen DeLong <owen@delong.com> wrote:
{ISP Connection} -> Router -> multiple segments each of which contain= s one or more routers, some of which have multiple segments which contain a= dditional routers.
All of the routers below the second tier are downstream from the routers at= the second tier which are downstream from the first tier router.

This is trivially solved with PD at the PE router that gets the delega= tion from the ISP.   I thought you were talking about a multi-homed to= pology.   Also trivially solved, but might involve two edge routers ea= ch with their own set of prefixes to delegate.

--_000_8D23D4052ABE7A4490E77B1A012B6307751C1363mbx01winnominum_-- From owen@delong.com Sun Jun 2 09:02:52 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B6B21F9021; Sun, 2 Jun 2013 09:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXrGLaYAnZHZ; Sun, 2 Jun 2013 09:02:51 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C701821F901B; Sun, 2 Jun 2013 09:02:51 -0700 (PDT) Received: from [192.168.6.83] (ip-64-134-24-48.public.wayport.net [64.134.24.48]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r52FxegN002864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 2 Jun 2013 08:59:41 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r52FxegN002864 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370188785; bh=rsfIxHkAdiFdSyeCNKnJTUaFPOk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=JtOzQJ8m8ocvFsep0mYBu2PVl0xPiiUl7saBim2nUPfxiSGt9UT+b/8iRj8WUqJea JLV9L1g6cZ0L4BRuRzBZ8fhDopRdcb5PhP3fIHNfLW+R+XMrl1QIYBENHcJrA98Tqg fmWG8TfvCg6cgyVRGONGTYjNFEXTHNw5JK59y0nY= Content-Type: multipart/alternative; boundary="Apple-Mail=_78C6A41F-CC97-4F76-B3D3-7D3B0EFED5CF" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Owen DeLong In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> Date: Sun, 2 Jun 2013 10:59:40 -0500 Message-Id: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Sun, 02 Jun 2013 08:59:45 -0700 (PDT) Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 16:02:52 -0000 --Apple-Mail=_78C6A41F-CC97-4F76-B3D3-7D3B0EFED5CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 2, 2013, at 1:51 AM, Ted Lemon wrote: > On Jun 2, 2013, at 1:22 AM, Owen DeLong wrote: >> {ISP Connection} -> Router -> multiple segments each of which = contains one or more routers, some of which have multiple segments which = contain additional routers. >> All of the routers below the second tier are downstream from the = routers at the second tier which are downstream from the first tier = router. >=20 > This is trivially solved with PD at the PE router that gets the = delegation from the ISP. I thought you were talking about a = multi-homed topology. Also trivially solved, but might involve two = edge routers each with their own set of prefixes to delegate. >=20 You are assuming that all of the subordinate routers will act as DHCP = relays rather than doing PD. That is certainly one possible solution, but, not necessarily ideal in = all cases. In cases where the subordinate routers should receive delegations and = perform their own PD for their subordinate routers, having a larger bit = field can be useful for greater flexibility. Thus, providing 16 bits to the end site is, IMHO, worth while. Owen --Apple-Mail=_78C6A41F-CC97-4F76-B3D3-7D3B0EFED5CF Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=windows-1252
On Jun 2, 2013, at 1:51 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Jun 2, 2013, at 1:22 AM, Owen DeLong <owen@delong.com> wrote:
{ISP Connection} -> Router -> multiple segments each of which contains one or more routers, some of which have multiple segments which contain additional routers.
All of the routers below the second tier are downstream from the routers at the second tier which are downstream from the first tier router.

This is trivially solved with PD at the PE router that gets the delegation from the ISP.   I thought you were talking about a multi-homed topology.   Also trivially solved, but might involve two edge routers each with their own set of prefixes to delegate.


You are assuming that all of the subordinate routers will act as DHCP relays rather than doing PD.

That is certainly one possible solution, but, not necessarily ideal in all cases.

In cases where the subordinate routers should receive delegations and perform their own PD for their subordinate routers, having a larger bit field can be useful for greater flexibility.

Thus, providing 16 bits to the end site is, IMHO, worth while.

Owen

--Apple-Mail=_78C6A41F-CC97-4F76-B3D3-7D3B0EFED5CF-- From Ted.Lemon@nominum.com Sun Jun 2 09:10:38 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7E121F9007; Sun, 2 Jun 2013 09:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wg91mwxYRL4b; Sun, 2 Jun 2013 09:10:31 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id ACDBB21F84B2; Sun, 2 Jun 2013 09:10:30 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUatudnYLQiQQ9qvF93TasFCJcWP/Uw2X@postini.com; Sun, 02 Jun 2013 09:10:30 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id F111C1B81A9; Sun, 2 Jun 2013 09:10:29 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E2829190052; Sun, 2 Jun 2013 09:10:29 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 2 Jun 2013 09:10:23 -0700 From: Ted Lemon To: Owen DeLong Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAAL+AA== Date: Sun, 2 Jun 2013 16:10:22 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C1603mbx01winnominum_" MIME-Version: 1.0 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 16:10:38 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C1603mbx01winnominum_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jun 2, 2013, at 11:59 AM, Owen DeLong > wrote: You are assuming that all of the subordinate routers will act as DHCP relay= s rather than doing PD. That is certainly one possible solution, but, not necessarily ideal in all = cases. In cases where the subordinate routers should receive delegations and perfo= rm their own PD for their subordinate routers, having a larger bit field ca= n be useful for greater flexibility. No, there is no use case where this is better than doing the delegations fr= om the router that received the initial delegation (since we're apparently = just arguing by vigorous assertion). Thus, providing 16 bits to the end site is, IMHO, worth while. And hence, this conclusion is not supported. You are welcome, of course, to contradict me by stating such a use case, bu= t bear in mind that when you delegate prefixes for further sub-delegation, = topology changes in the homenet become impossible. So your use case for d= oing this would have to enable some pretty awesome functionality before it = would be worth doing. Also make sure you think about how it would work du= ring a renumbering event, with sub-delegations and sub-sub-delegations all = having different lifetimes. (I've got nothing against delegating /48's to the home, but the reason we d= id that was to maintain flexibility, not because we really expect a typical= homenet to have 65,536 subnets. At least for most reasonable values of "= we.") --_000_8D23D4052ABE7A4490E77B1A012B6307751C1603mbx01winnominum_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0B01DC0D38E1C245A8BCD61B4E06490B@nominum.com> Content-Transfer-Encoding: quoted-printable
On Jun 2, 2013, at 11:59 AM, Owen DeLong <owen@delong.com> wrote:
You are assuming that all of the subordinate routers will act as DHCP relay= s rather than doing PD.
That is certainly one possible solution, but, not necessarily ideal in all = cases.
In cases where the subordinate routers should receive delegations and perfo= rm their own PD for their subordinate routers, having a larger bit field ca= n be useful for greater flexibility.

No, there is no use case where this is better than doing the delegations fr= om the router that received the initial delegation (since we're apparently = just arguing by vigorous assertion).

Thus, providing 16 bits to the end site is, IMHO, worth while.

And hence, this conclusion is not supported.

You are welcome, of course, to contradict me by stating such a use cas= e, but bear in mind that when you delegate prefixes for further sub-delegat= ion, topology changes in the homenet become impossible.   So your use = case for doing this would have to enable some pretty awesome functionality before it would be worth doing.   A= lso make sure you think about how it would work during a renumbering event,= with sub-delegations and sub-sub-delegations all having different lifetime= s.

(I've got nothing against delegating /48's to the home, but the reason= we did that was to maintain flexibility, not because we really expect a ty= pical homenet to have 65,536 subnets.   At least for most reasonable v= alues of "we.")

--_000_8D23D4052ABE7A4490E77B1A012B6307751C1603mbx01winnominum_-- From tjc@ecs.soton.ac.uk Sun Jun 2 09:29:58 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376F421F8C08; Sun, 2 Jun 2013 09:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TDJIrAiQIXC; Sun, 2 Jun 2013 09:29:57 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id EDD5721F8B60; Sun, 2 Jun 2013 09:29:56 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r52GTp5w014649; Sun, 2 Jun 2013 17:29:51 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r52GTp5w014649 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1370190592; bh=6oaI7X5fsnTL2zFvPiAnqVRowkQ=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=BqyrspNpW+ri9Tav4CICNhfECk8KBPCk6eEMn8ycfMg/cF1UZrn2ZzFLRSA1BPT+8 xZrZXbGpoKbxzZc4U6j448EHPwz5jEAbA5zkcbNxD2TMHxzdfckrygimFbbzslRh+a fBmVzzQh39lxBuaELAMY/BjVPJtysBRHz9Q4UFkM= 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 p51HYp0430655735oZ ret-id none; Sun, 02 Jun 2013 17:29:52 +0100 Received: from [192.168.1.110] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r52GTisP023940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 2 Jun 2013 17:29:45 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_3BB6B2CD-B05D-4763-B3BF-EED572A5A2DF" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Tim Chown In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> Date: Sun, 2 Jun 2013 17:29:48 +0100 Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p51HYp043065573500; tid=p51HYp0430655735oZ; client=relay,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r52GTp5w014649 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 16:29:58 -0000 --Apple-Mail=_3BB6B2CD-B05D-4763-B3BF-EED572A5A2DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 2 Jun 2013, at 17:10, Ted Lemon wrote: > On Jun 2, 2013, at 11:59 AM, Owen DeLong wrote: >> You are assuming that all of the subordinate routers will act as DHCP = relays rather than doing PD. >> That is certainly one possible solution, but, not necessarily ideal = in all cases. >> In cases where the subordinate routers should receive delegations and = perform their own PD for their subordinate routers, having a larger bit = field can be useful for greater flexibility. >=20 > No, there is no use case where this is better than doing the = delegations from the router that received the initial delegation (since = we're apparently just arguing by vigorous assertion). >=20 >> Thus, providing 16 bits to the end site is, IMHO, worth while. >=20 > And hence, this conclusion is not supported. >=20 > You are welcome, of course, to contradict me by stating such a use = case, but bear in mind that when you delegate prefixes for further = sub-delegation, topology changes in the homenet become impossible. So = your use case for doing this would have to enable some pretty awesome = functionality before it would be worth doing. Also make sure you think = about how it would work during a renumbering event, with sub-delegations = and sub-sub-delegations all having different lifetimes. >=20 > (I've got nothing against delegating /48's to the home, but the reason = we did that was to maintain flexibility, not because we really expect a = typical homenet to have 65,536 subnets. At least for most reasonable = values of "we.") Well, this is why the homenet arch says that prefix delegation should be = efficient. Using DHCP-PD forces a structure to the delegations, and = thus potential inefficiency. The OSPF-based solution doesn't have that = limitation, but then has to handle potential clashes.=20 In terms of allocations, the homenet arch simply points to RFC6177. Tim --Apple-Mail=_3BB6B2CD-B05D-4763-B3BF-EED572A5A2DF Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=windows-1252
On 2 Jun 2013, at 17:10, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Jun 2, 2013, at 11:59 AM, Owen DeLong <owen@delong.com> wrote:
You are assuming that all of the subordinate routers will act as DHCP relays rather than doing PD.
That is certainly one possible solution, but, not necessarily ideal in all cases.
In cases where the subordinate routers should receive delegations and perform their own PD for their subordinate routers, having a larger bit field can be useful for greater flexibility.

No, there is no use case where this is better than doing the delegations from the router that received the initial delegation (since we're apparently just arguing by vigorous assertion).

Thus, providing 16 bits to the end site is, IMHO, worth while.

And hence, this conclusion is not supported.

You are welcome, of course, to contradict me by stating such a use case, but bear in mind that when you delegate prefixes for further sub-delegation, topology changes in the homenet become impossible.   So your use case for doing this would have to enable some pretty awesome functionality before it would be worth doing.   Also make sure you think about how it would work during a renumbering event, with sub-delegations and sub-sub-delegations all having different lifetimes.

(I've got nothing against delegating /48's to the home, but the reason we did that was to maintain flexibility, not because we really expect a typical homenet to have 65,536 subnets.   At least for most reasonable values of "we.")

Well, this is why the homenet arch says that prefix delegation should be efficient.  Using DHCP-PD forces a structure to the delegations, and thus potential inefficiency. The OSPF-based solution doesn't have that limitation, but then has to handle potential clashes. 

In terms of allocations, the homenet arch simply points to RFC6177.

Tim

--Apple-Mail=_3BB6B2CD-B05D-4763-B3BF-EED572A5A2DF-- From Ted.Lemon@nominum.com Sun Jun 2 09:31:59 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3D221F9007; Sun, 2 Jun 2013 09:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnG92z5clf5M; Sun, 2 Jun 2013 09:31:52 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0E921F8FDD; Sun, 2 Jun 2013 09:31:52 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUatzeBIuzSY2tZWeL7xuEB1UZDGY6a7x@postini.com; Sun, 02 Jun 2013 09:31:52 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D84631B8183; Sun, 2 Jun 2013 09:31:51 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id CEFB6190052; Sun, 2 Jun 2013 09:31:51 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 2 Jun 2013 09:31:51 -0700 From: Ted Lemon To: Tim Chown Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAAL+AIAABW4AgAAAkQA= Date: Sun, 2 Jun 2013 16:31:51 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C16A4@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C16A4mbx01winnominum_" MIME-Version: 1.0 Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 16:31:59 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C16A4mbx01winnominum_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jun 2, 2013, at 12:29 PM, Tim Chown > wrote: Well, this is why the homenet arch says that prefix delegation should be ef= ficient. Using DHCP-PD forces a structure to the delegations, and thus pot= ential inefficiency. The OSPF-based solution doesn't have that limitation, = but then has to handle potential clashes. No it _doesn't_. There is no reason for DHCP-PD to be inefficient. Why = do you think it has to be inefficient? --_000_8D23D4052ABE7A4490E77B1A012B6307751C16A4mbx01winnominum_ Content-Type: text/html; charset="Windows-1252" Content-ID: <400718DE7B496640BBABD21BCCA7A856@nominum.com> Content-Transfer-Encoding: quoted-printable
On Jun 2, 2013, at 12:29 PM, Tim Chown <tjc@ecs.soton.ac.uk> wrote:
Well, this is why the homenet arch says that prefix delegation should be efficie= nt.  Using DHCP-PD forces a structure to the delegations, and thus pot= ential inefficiency. The OSPF-based solution doesn't have that limitation, = but then has to handle potential clashes. 

No it _doesn't_.   There is no reason for DHCP-PD to be inefficie= nt.   Why do you think it has to be inefficient?

--_000_8D23D4052ABE7A4490E77B1A012B6307751C16A4mbx01winnominum_-- From owen@delong.com Sun Jun 2 09:43:18 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E47021F90CC; Sun, 2 Jun 2013 09:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBSmqdhlvnVh; Sun, 2 Jun 2013 09:43:17 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 44DF821F9079; Sun, 2 Jun 2013 09:43:16 -0700 (PDT) Received: from [192.168.6.83] (ip-64-134-24-48.public.wayport.net [64.134.24.48]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r52GdFQP003810 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 2 Jun 2013 09:39:16 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r52GdFQP003810 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370191157; bh=fJwckmV3WE0LOMzjapd3ykyB0QE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=UR6j3lWHqIF6vHpwjMTCrDwASmw8KIppiT6/LINqi1uWvJ03GEF5WgmvRjMOyJMAv p1CNqAytvDWH2z4rUAWJXbjuYQHMPV4juEhh5idH0jEZaOPXOh11wn0qKXhUnkFnTU QcywIGtLIS/JFoFKP0HYXXl3ZIy3iUqlMD5f212w= Content-Type: multipart/alternative; boundary="Apple-Mail=_090F416F-4969-4C0D-8E3F-DFD15DC4CE97" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Owen DeLong In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> Date: Sun, 2 Jun 2013 11:39:15 -0500 Message-Id: <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Sun, 02 Jun 2013 09:39:17 -0700 (PDT) Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 16:43:18 -0000 --Apple-Mail=_090F416F-4969-4C0D-8E3F-DFD15DC4CE97 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 2, 2013, at 11:10 AM, Ted Lemon wrote: > On Jun 2, 2013, at 11:59 AM, Owen DeLong wrote: >> You are assuming that all of the subordinate routers will act as DHCP = relays rather than doing PD. >> That is certainly one possible solution, but, not necessarily ideal = in all cases. >> In cases where the subordinate routers should receive delegations and = perform their own PD for their subordinate routers, having a larger bit = field can be useful for greater flexibility. >=20 > No, there is no use case where this is better than doing the = delegations from the router that received the initial delegation (since = we're apparently just arguing by vigorous assertion). >=20 We can agree to disagree.=20 One example that comes to mind is if I want greater control and I want = my most capable router with the greatest configuration flexibility to be = in charge of the addressing scheme, but, it is not the router that = interfaces with my ISP. >> Thus, providing 16 bits to the end site is, IMHO, worth while. >=20 > And hence, this conclusion is not supported. >=20 > You are welcome, of course, to contradict me by stating such a use = case, but bear in mind that when you delegate prefixes for further = sub-delegation, topology changes in the homenet become impossible. So = your use case for doing this would have to enable some pretty awesome = functionality before it would be worth doing. Also make sure you think = about how it would work during a renumbering event, with sub-delegations = and sub-sub-delegations all having different lifetimes. >=20 Actually, the need for the larger bit field is precisely to allow = topology changes in said deployment scenario. If the top level router = hands out, for example, /50s to its 3 subordinate routers, the = subordinate routers can support a number of different topologies without = requiring any changes at the top-level router. Additionally, a fourth = subordinate router can be added with its own underlying topology = supported. OTOH, if there are more than 3 subordinate routers, the top level router = can delegate /51s. True, this would complicate the change from 3 to more = than 3 subordinate routers at the top level somewhat. > (I've got nothing against delegating /48's to the home, but the reason = we did that was to maintain flexibility, not because we really expect a = typical homenet to have 65,536 subnets. At least for most reasonable = values of "we.") >=20 You just said exactly what I said to begin with=85 It's to have a bit = field wide enough to allow flexibility in the automation of the = hierarchical assignments, not to create 65K subnets. I never asserted it = was because we needed 65K subnets. Owen --Apple-Mail=_090F416F-4969-4C0D-8E3F-DFD15DC4CE97 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Ted.Lemon@nominum.com> = wrote:
On Jun 2, 2013, at 11:59 AM, Owen DeLong <owen@delong.com> wrote:
You are assuming that all of the subordinate routers will act as DHCP = relays rather than doing PD.
That is certainly one possible solution, but, not necessarily ideal in = all cases.
In cases where the subordinate routers should receive delegations and = perform their own PD for their subordinate routers, having a larger bit = field can be useful for greater flexibility.

No, there is no use case where this is better than doing the delegations = from the router that received the initial delegation (since we're = apparently just arguing by vigorous assertion).


We can agree to = disagree. 

One example that comes to mind = is if I want greater control and I want my most capable router with the = greatest configuration flexibility to be in charge of the addressing = scheme, but, it is not the router that interfaces with my = ISP.

Thus, providing 16 bits to the end site is, IMHO, worth while.

And hence, this conclusion is not supported.

You are welcome, of course, to contradict me by stating such a use = case, but bear in mind that when you delegate prefixes for further = sub-delegation, topology changes in the homenet become impossible. =   So your use case for doing this would have to enable some pretty awesome functionality before it would be worth doing. =   Also make sure you think about how it would work during a = renumbering event, with sub-delegations and sub-sub-delegations all = having different lifetimes.


Actually, the need for = the larger bit field is precisely to allow topology changes in said = deployment scenario. If the top level router hands out, for example, = /50s to its 3 subordinate routers, the subordinate routers can support a = number of different topologies without requiring any changes at the = top-level router. Additionally, a fourth subordinate router can be added = with its own underlying topology = supported.

OTOH, if there are more than 3 = subordinate routers, the top level router can delegate /51s. True, this = would complicate the change from 3 to more than 3 subordinate routers at = the top level somewhat.

(I've got nothing against delegating /48's to the home, but the = reason we did that was to maintain flexibility, not because we really = expect a typical homenet to have 65,536 subnets.   At least for = most reasonable values of "we.")


You just said exactly what I said to begin = with=85 It's to have a bit field wide enough to allow flexibility in the = automation of the hierarchical assignments, not to create 65K subnets. I = never asserted it was because we needed 65K = subnets.

Owen

= --Apple-Mail=_090F416F-4969-4C0D-8E3F-DFD15DC4CE97-- From tjc@ecs.soton.ac.uk Sun Jun 2 09:52:10 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9083921F90CD; Sun, 2 Jun 2013 09:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFBHfC93BxLo; Sun, 2 Jun 2013 09:52:09 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 3032921F909A; Sun, 2 Jun 2013 09:52:06 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r52Gpu5f019037; Sun, 2 Jun 2013 17:51:56 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r52Gpu5f019037 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1370191916; bh=hBKqaYlPWroiM1MSwYDkkHMeW1k=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=13FR9hPT8qZbVmDwBXh+FVDjKWVNUMZEMH3n7V7q4r96kJsrK2cqn6ZD1W7ryjgzp bFtyDB/5BGcvDDl+XXn/oJVVw66Vq6ZfNdoaBNIeFpSBMqlKq6WYZF88CSqWQYm3aP CPpsXZGFbOCR4yUrh81DQckwmG+FQyBk+51QCuxU= 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 p51Hpu043065588322 ret-id none; Sun, 02 Jun 2013 17:51:56 +0100 Received: from [192.168.1.110] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r52GoZkD000565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 2 Jun 2013 17:50:36 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_9D859031-26FE-4F5B-B5A1-C69AFC356B77" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Tim Chown In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C16A4@mbx-01.win.nominum.com> Date: Sun, 2 Jun 2013 17:50:38 +0100 Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C16A4@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p51Hpu043065588300; tid=p51Hpu043065588322; client=relay,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r52Gpu5f019037 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: Owen DeLong , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 16:52:10 -0000 --Apple-Mail=_9D859031-26FE-4F5B-B5A1-C69AFC356B77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 2 Jun 2013, at 17:31, Ted Lemon wrote: > On Jun 2, 2013, at 12:29 PM, Tim Chown wrote: >> Well, this is why the homenet arch says that prefix delegation should = be efficient. Using DHCP-PD forces a structure to the delegations, and = thus potential inefficiency. The OSPF-based solution doesn't have that = limitation, but then has to handle potential clashes.=20 >=20 > No it _doesn't_. There is no reason for DHCP-PD to be inefficient. = Why do you think it has to be inefficient? Fair point - it would be good if Fred tickled = draft-baker-homenet-prefix-assignment-01 which talks about that. Tim --Apple-Mail=_9D859031-26FE-4F5B-B5A1-C69AFC356B77 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=windows-1252
On 2 Jun 2013, at 17:31, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Jun 2, 2013, at 12:29 PM, Tim Chown <tjc@ecs.soton.ac.uk> wrote:
Well, this is why the homenet arch says that prefix delegation should be efficient.  Using DHCP-PD forces a structure to the delegations, and thus potential inefficiency. The OSPF-based solution doesn't have that limitation, but then has to handle potential clashes. 

No it _doesn't_.   There is no reason for DHCP-PD to be inefficient.   Why do you think it has to be inefficient?

Fair point - it would be good if Fred tickled draft-baker-homenet-prefix-assignment-01 which talks about that.

Tim

--Apple-Mail=_9D859031-26FE-4F5B-B5A1-C69AFC356B77-- From rdroms.ietf@gmail.com Sun Jun 2 13:47:26 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C75B21F9104; Sun, 2 Jun 2013 13:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.176 X-Spam-Level: X-Spam-Status: No, score=-101.176 tagged_above=-999 required=5 tests=[AWL=1.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERV4epAEl+82; Sun, 2 Jun 2013 13:47:21 -0700 (PDT) Received: from mail-ye0-f169.google.com (mail-ye0-f169.google.com [209.85.213.169]) by ietfa.amsl.com (Postfix) with ESMTP id 578EA21F901F; Sun, 2 Jun 2013 13:47:21 -0700 (PDT) Received: by mail-ye0-f169.google.com with SMTP id m9so921031yen.14 for ; Sun, 02 Jun 2013 13:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=hT4KdSBjsDXNqEoYwUGfKiuzRoznovZrzIwKmtzIHU4=; b=udCakXAsQ+ImQrni8i8jaLNR1Hpvio2EMzd1QD30VPH17vnHbfA8c9hTCPkx4p9EB7 4L1DPHI+fiopWF7zIAZxHgY19qiGBJdFsNc2uvhaKbWDo94XxH6HXVhchhbHOAf8gJJd 3fjAKW4eyQYQEXFrBuf2lIhse7dpVwZWUauUiDRcn+j7AxKWDxOfCdD1MM4I2oXtuKKH 6rGA8bWQd8NAcX5SxyaNz4AZU55pf+X1PkjX582FhxMFqpwSMFxMY77jJ8vlFji5k+zi P9c8KwuXpZmuFgfl7V29ChoR+vzhBZmhmxWxKQK0w9jjp+/fSPMVs3e4gk4hQETwIeNP hHQQ== X-Received: by 10.236.51.230 with SMTP id b66mr5410230yhc.116.1370206040871; Sun, 02 Jun 2013 13:47:20 -0700 (PDT) Received: from [10.12.7.85] (mobile-198-228-196-228.mycingular.net. [198.228.196.228]) by mx.google.com with ESMTPSA id m74sm87239925yhm.0.2013.06.02.13.47.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Jun 2013 13:47:19 -0700 (PDT) References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C16A4@mbx-01.win.nominum.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-A32D32F2-D448-4D6C-8D78-1BAF967BCACE Content-Transfer-Encoding: 7bit Message-Id: <6EBDAA70-E2C1-47CF-9FF1-0844C8868CA5@gmail.com> X-Mailer: iPhone Mail (10B350) From: Ralph Droms Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Date: Sun, 2 Jun 2013 16:47:16 -0400 To: Tim Chown Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong , Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 20:47:26 -0000 --Apple-Mail-A32D32F2-D448-4D6C-8D78-1BAF967BCACE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Jun 2, 2013, at 12:50 PM, Tim Chown wrote: > On 2 Jun 2013, at 17:31, Ted Lemon wrote: >=20 >> On Jun 2, 2013, at 12:29 PM, Tim Chown wrote: >>> Well, this is why the homenet arch says that prefix delegation should be= efficient. Using DHCP-PD forces a structure to the delegations, and thus p= otential inefficiency. The OSPF-based solution doesn't have that limitation,= but then has to handle potential clashes.=20 >>=20 >> No it _doesn't_. There is no reason for DHCP-PD to be inefficient. Wh= y do you think it has to be inefficient? >=20 > Fair point - it would be good if Fred tickled draft-baker-homenet-prefix-a= ssignment-01 which talks about that. Yes, draft-baker-homenet-prefix-assignment describes non-hierarchical assign= ment, in which all prefixes are delegates from a single server. I'll resuscitate it, as it seems to be a useful reference for this discussio= n. - Ralph >=20 > Tim >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail-A32D32F2-D448-4D6C-8D78-1BAF967BCACE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Jun 2, 2013, at 1= 2:50 PM, Tim Chown <tjc@ecs.soton.= ac.uk> wrote:

On 2 Jun 2013, at 17:31, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Jun 2, 2013, at 12:29 PM, Tim Chown <tjc@ecs.soton.ac.uk> wrote:
Well, this is why the homenet arch says that prefix delegation should be efficien= t.  Using DHCP-PD forces a structure to the delegations, and thus poten= tial inefficiency. The OSPF-based solution doesn't have that limitation, but= then has to handle potential clashes. 

No it _doesn't_.   There is no reason for DHCP-PD to be inefficien= t.   Why do you think it has to be inefficient?

Fair point - it would be good if Fred tick= led draft-baker-homenet-prefix-= assignment-01 which talks about that.
Yes, draft-baker-homenet-prefix-assignment describes non-hierarchical= assignment, in which all prefixes are delegates from a single server.
=
I'll resuscitate it, as it seems to be a useful reference fo= r this discussion.

- Ralph

=
=
Tim
--------------= ------------------------------------------------------
IETF I= Pv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listi= nfo/ipv6
-----------------------------------------------= ---------------------
= --Apple-Mail-A32D32F2-D448-4D6C-8D78-1BAF967BCACE-- From rdroms.ietf@gmail.com Sun Jun 2 13:51:09 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895BE21F9104; Sun, 2 Jun 2013 13:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.189 X-Spam-Level: X-Spam-Status: No, score=-101.189 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id of+3Uq3SO+WC; Sun, 2 Jun 2013 13:51:09 -0700 (PDT) Received: from mail-gg0-x233.google.com (mail-gg0-x233.google.com [IPv6:2607:f8b0:4002:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id B17F621F9051; Sun, 2 Jun 2013 13:51:08 -0700 (PDT) Received: by mail-gg0-f179.google.com with SMTP id c4so910499ggn.38 for ; Sun, 02 Jun 2013 13:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=mpjZh7LnCbzICedsFHZc+Otc+X56CgvJLrOcEn3iEjM=; b=NbnubCVpxZTd/leVbGeGeqL2PIlavU0nHUJ+SzC+zmGyBqCkptD+TiQ3LLsZE9B+ae KTdZ6C6ZtcN8JdbfGVK2WNTgLtJ9ltCBkzXFYIU6mYcZCKdjZHZmiBu92eS0tvFJ1KDd EWpLRlL9SF4eXuFyUyFibAgw9K5X5eCEw2KWB6l6DwFCEgYhaRTIcNXiBpugsKuQ5wED /mCkA7lmzSXewL9vUsA1omh/N3+xffUAB0dldHqk4x7XeWTvOX8CYQp44t5J4NxMJmue bYqH43yzcJSrndGCf1Wm7zzGyiDYSFPmJyER6+KSFYJpZzQF6/wEjgCU+IXEOJKrzTO8 HFCg== X-Received: by 10.236.60.134 with SMTP id u6mr13631494yhc.40.1370206268274; Sun, 02 Jun 2013 13:51:08 -0700 (PDT) Received: from [10.12.7.85] (mobile-198-228-196-228.mycingular.net. [198.228.196.228]) by mx.google.com with ESMTPSA id y71sm42995191yhj.10.2013.06.02.13.51.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Jun 2013 13:51:06 -0700 (PDT) References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-998BEE93-1E61-495F-A030-C00AED269055 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B350) From: Ralph Droms Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Date: Sun, 2 Jun 2013 16:51:03 -0400 To: Owen DeLong Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 20:51:09 -0000 --Apple-Mail-998BEE93-1E61-495F-A030-C00AED269055 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Jun 2, 2013, at 11:59 AM, Owen DeLong wrote: >=20 > On Jun 2, 2013, at 1:51 AM, Ted Lemon wrote: >=20 >> On Jun 2, 2013, at 1:22 AM, Owen DeLong wrote: >>> {ISP Connection} -> Router -> multiple segments each of which contains o= ne or more routers, some of which have multiple segments which contain addit= ional routers. >>> All of the routers below the second tier are downstream from the routers= at the second tier which are downstream from the first tier router. >>=20 >> This is trivially solved with PD at the PE router that gets the delegatio= n from the ISP. I thought you were talking about a multi-homed topology. = Also trivially solved, but might involve two edge routers each with their o= wn set of prefixes to delegate. >=20 > You are assuming that all of the subordinate routers will act as DHCP rela= ys rather than doing PD. >=20 > That is certainly one possible solution, but, not necessarily ideal in all= cases. >=20 > In cases where the subordinate routers should receive delegations and perf= orm their own PD for their subordinate routers, having a larger bit field ca= n be useful for greater flexibility. Under what circumstances would this deployment model be useful? - Ralph >=20 > Thus, providing 16 bits to the end site is, IMHO, worth while. >=20 > Owen >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail-998BEE93-1E61-495F-A030-C00AED269055 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Jun 2, 2013, at 1= 1:59 AM, Owen DeLong <owen@delong.com<= /a>> wrote:



On Jun 2, 2013, at 1:22 AM, Owen DeLong <owen@delong.com> wrote:
{ISP Connection} -> Router -> multiple segments each of which contains= one or more routers, some of which have multiple segments which contain add= itional routers.
All of the routers below the second tier are downstream from the routers at t= he second tier which are downstream from the first tier router.

This is trivially solved with PD at the PE router that gets the delegat= ion from the ISP.   I thought you were talking about a multi-homed topo= logy.   Also trivially solved, but might involve two edge routers each w= ith their own set of prefixes to delegate.


You are assuming that all of the subordinate rou= ters will act as DHCP relays rather than doing PD.

= That is certainly one possible solution, but, not necessarily ideal in all c= ases.

In cases where the subordinate routers should= receive delegations and perform their own PD for their subordinate routers,= having a larger bit field can be useful for greater flexibility.

Under what circumstances would this deployment m= odel be useful?

- Ralph


Thus, providing 16 bits to the end site= is, IMHO, worth while.

Owen

----------------------= ----------------------------------------------
IETF IPv6 wor= king group mailing list
ipv= 6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv= 6
------------------------------------------------------= --------------
= --Apple-Mail-998BEE93-1E61-495F-A030-C00AED269055-- From tjc@ecs.soton.ac.uk Sun Jun 2 14:03:23 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190FB21F918C; Sun, 2 Jun 2013 14:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBxvh6UEoETv; Sun, 2 Jun 2013 14:03:22 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 014AC21F9104; Sun, 2 Jun 2013 14:03:19 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r52L39q1032153; Sun, 2 Jun 2013 22:03:09 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r52L39q1032153 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1370206989; bh=gU9U/9gVCCDKWyOO0X6OHlZXOxQ=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=Xnza0Us/nOxwXD4b8VpxZywi8dfynsb5YG3AnxxXz4okT25lzFgczSx+srEpWTCC7 HHgxEG089PJxDl0umK7EwDkSfWqHpNajEoufiKayeD6TTZ1TQQXufKxcdFT4T1TC69 RIufC1MmDkFYWqpFptlyVZ5F2J5rWcrdhnmUtIPo= 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 p51M390430657084Q6 ret-id none; Sun, 02 Jun 2013 22:03:09 +0100 Received: from [192.168.1.110] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r52L2iT1010629 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 2 Jun 2013 22:02:44 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_F9344773-14C0-4225-8E2B-F813ED4F8BC2" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Tim Chown In-Reply-To: Date: Sun, 2 Jun 2013 22:02:44 +0100 Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> To: Ralph Droms X-Mailer: Apple Mail (2.1503) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p51M39043065708400; tid=p51M390430657084Q6; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r52L39q1032153 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong , Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 21:03:23 -0000 --Apple-Mail=_F9344773-14C0-4225-8E2B-F813ED4F8BC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2 Jun 2013, at 21:51, Ralph Droms wrote: >=20 > On Jun 2, 2013, at 11:59 AM, Owen DeLong wrote: >=20 >>=20 >> On Jun 2, 2013, at 1:51 AM, Ted Lemon wrote: >>=20 >>> On Jun 2, 2013, at 1:22 AM, Owen DeLong wrote: >>>> {ISP Connection} -> Router -> multiple segments each of which = contains one or more routers, some of which have multiple segments which = contain additional routers. >>>> All of the routers below the second tier are downstream from the = routers at the second tier which are downstream from the first tier = router. >>>=20 >>> This is trivially solved with PD at the PE router that gets the = delegation from the ISP. I thought you were talking about a = multi-homed topology. Also trivially solved, but might involve two = edge routers each with their own set of prefixes to delegate. >>>=20 >>=20 >> You are assuming that all of the subordinate routers will act as DHCP = relays rather than doing PD. >>=20 >> That is certainly one possible solution, but, not necessarily ideal = in all cases. >>=20 >> In cases where the subordinate routers should receive delegations and = perform their own PD for their subordinate routers, having a larger bit = field can be useful for greater flexibility. >=20 > Under what circumstances would this deployment model be useful? Isn't the hipnet model one with recursive PD? (http://tools.ietf.org/html/draft-grundemann-homenet-hipnet-01#page-11) Tim --Apple-Mail=_F9344773-14C0-4225-8E2B-F813ED4F8BC2 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 2 Jun 2013, at 21:51, Ralph Droms <rdroms.ietf@gmail.com> wrote:

On Jun 2, 2013, at 11:59 AM, Owen DeLong <owen@delong.com> wrote:


On Jun 2, 2013, at 1:51 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Jun 2, 2013, at 1:22 AM, Owen DeLong <owen@delong.com> wrote:
{ISP Connection} -> Router -> multiple segments each of which contains one or more routers, some of which have multiple segments which contain additional routers.
All of the routers below the second tier are downstream from the routers at the second tier which are downstream from the first tier router.

This is trivially solved with PD at the PE router that gets the delegation from the ISP.   I thought you were talking about a multi-homed topology.   Also trivially solved, but might involve two edge routers each with their own set of prefixes to delegate.


You are assuming that all of the subordinate routers will act as DHCP relays rather than doing PD.

That is certainly one possible solution, but, not necessarily ideal in all cases.

In cases where the subordinate routers should receive delegations and perform their own PD for their subordinate routers, having a larger bit field can be useful for greater flexibility.

Under what circumstances would this deployment model be useful?

Isn't the hipnet model one with recursive PD?

Tim

--Apple-Mail=_F9344773-14C0-4225-8E2B-F813ED4F8BC2-- From rdroms.ietf@gmail.com Sun Jun 2 14:25:36 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C173A21F904B; Sun, 2 Jun 2013 14:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.693 X-Spam-Level: X-Spam-Status: No, score=-101.693 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goBuzWrT-evv; Sun, 2 Jun 2013 14:25:32 -0700 (PDT) Received: from mail-ye0-f172.google.com (mail-ye0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E9A3121F9021; Sun, 2 Jun 2013 14:25:31 -0700 (PDT) Received: by mail-ye0-f172.google.com with SMTP id m15so941858yen.17 for ; Sun, 02 Jun 2013 14:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=A3fNraRm8ksBW3NCoYsC3mGOnP5dx7FV4kqZNAVvP3c=; b=InRPxxux82POAed/72oo9sd+q2w30BP1hhoUdxV4RC699f80YzJ8E1+IHzCCXuryJS 1iLoZIwIS3nhTkhjjTJIRZ0LPy6DzoHiOsFyi4fZ5Bn7XXPFYReZ1GmAznuJa9ADce+J JayDmQSrkv7va2UA4Z274jTgIZ9+V/N4tocaLQIXoUOPVeZlU3YLA+/4djjCnWTMEvCe yZRMpyvGRqGVCKbP9G6UcRXyJhWEG+RNAZs2O3B7FtyMreQbQBE66fTQpk8Nrwn+TzVT ll+v/JGxSdFwbLpdX9TKR19h9Ug4LD0r19kL8FOzSTk4MfsrntsuCgwc9UnF4zbXpiSn 5R4w== X-Received: by 10.236.76.4 with SMTP id a4mr13792366yhe.44.1370208331156; Sun, 02 Jun 2013 14:25:31 -0700 (PDT) Received: from [10.12.7.85] (mobile-198-228-196-228.mycingular.net. [198.228.196.228]) by mx.google.com with ESMTPSA id a24sm87566562yho.24.2013.06.02.14.25.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Jun 2013 14:25:30 -0700 (PDT) References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-9769D8B4-6E88-45CF-9222-EB6EAFDB3C50 Content-Transfer-Encoding: 7bit Message-Id: <8BDE8312-549D-4A1B-AC53-EBD54B789F3F@gmail.com> X-Mailer: iPhone Mail (10B350) From: Ralph Droms Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Date: Sun, 2 Jun 2013 17:25:28 -0400 To: Tim Chown Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong , Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 21:25:36 -0000 --Apple-Mail-9769D8B4-6E88-45CF-9222-EB6EAFDB3C50 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Jun 2, 2013, at 5:02 PM, Tim Chown wrote: > On 2 Jun 2013, at 21:51, Ralph Droms wrote: >>=20 >> On Jun 2, 2013, at 11:59 AM, Owen DeLong wrote: >>=20 >>>=20 >>> On Jun 2, 2013, at 1:51 AM, Ted Lemon wrote: >>>=20 >>>> On Jun 2, 2013, at 1:22 AM, Owen DeLong wrote: >>>>> {ISP Connection} -> Router -> multiple segments each of which contains= one or more routers, some of which have multiple segments which contain add= itional routers. >>>>> All of the routers below the second tier are downstream from the route= rs at the second tier which are downstream from the first tier router. >>>>=20 >>>> This is trivially solved with PD at the PE router that gets the delegat= ion from the ISP. I thought you were talking about a multi-homed topology.= Also trivially solved, but might involve two edge routers each with their= own set of prefixes to delegate. >>>=20 >>> You are assuming that all of the subordinate routers will act as DHCP re= lays rather than doing PD. >>>=20 >>> That is certainly one possible solution, but, not necessarily ideal in a= ll cases. >>>=20 >>> In cases where the subordinate routers should receive delegations and pe= rform their own PD for their subordinate routers, having a larger bit field c= an be useful for greater flexibility. >>=20 >> Under what circumstances would this deployment model be useful? >=20 > Isn't the hipnet model one with recursive PD? > (http://tools.ietf.org/html/draft-grundemann-homenet-hipnet-01#page-11) >=20 > Tim >=20 Right. I think the recursive model is specified in HIPnet without any motiv= ation. I've been meaning to ask if the non-recursive model would work in HI= Pnet. - Ralph --Apple-Mail-9769D8B4-6E88-45CF-9222-EB6EAFDB3C50 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Jun 2, 2013, at 5= :02 PM, Tim Chown <tjc@ecs.soton.a= c.uk> wrote:

On 2= Jun 2013, at 21:51, Ralph Droms <rdroms.ietf@gmail.com> wrote:

On Jun 2, 2013, at 11:59 AM, Owen DeLong <owen@delong.com> wrote:


On Jun 2, 2013, at 1:51 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
On Jun 2, 2013, at 1:22 AM, Owen DeLong <owen@delong.com> wrote:
{ISP Connection} -> Router -> multiple segments each of which contains= one or more routers, some of which have multiple segments which contain add= itional routers.
All of the routers below the second tier are downstream from the routers at t= he second tier which are downstream from the first tier router.

This is trivially solved with PD at the PE router that gets the delegat= ion from the ISP.   I thought you were talking about a multi-homed topo= logy.   Also trivially solved, but might involve two edge routers each w= ith their own set of prefixes to delegate.


You are assuming that all of the subordinate rou= ters will act as DHCP relays rather than doing PD.

= That is certainly one possible solution, but, not necessarily ideal in all c= ases.

In cases where the subordinate routers should= receive delegations and perform their own PD for their subordinate routers,= having a larger bit field can be useful for greater flexibility.

Under what circumstances would this deployment model b= e useful?

Isn't the hipnet model one with r= ecursive PD?

Tim

Right.  I think the recursive model is specified in HIPnet wi= thout any motivation.  I've been meaning to ask if the non-recursive mo= del would work in HIPnet.

- Ralph

= --Apple-Mail-9769D8B4-6E88-45CF-9222-EB6EAFDB3C50-- From albert.e.manfredi@boeing.com Sun Jun 2 15:31:13 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4810C21F8F61; Sun, 2 Jun 2013 15:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qmvp4GCJThvZ; Sun, 2 Jun 2013 15:31:07 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id F1E5921F8F4D; Sun, 2 Jun 2013 15:31:06 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r52MV6F3027792; Sun, 2 Jun 2013 15:31:06 -0700 Received: from XCH-PHX-104.sw.nos.boeing.com (xch-phx-104.sw.nos.boeing.com [137.136.238.7]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r52MV4br027785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Sun, 2 Jun 2013 15:31:05 -0700 Received: from XCH-PHX-503.sw.nos.boeing.com ([169.254.3.131]) by XCH-PHX-104.sw.nos.boeing.com ([169.254.4.103]) with mapi id 14.02.0328.011; Sun, 2 Jun 2013 15:31:03 -0700 From: "Manfredi, Albert E" To: Owen DeLong , Ted Lemon Subject: RE: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAAL+AIAACBKA///qVNA= Date: Sun, 2 Jun 2013 22:31:03 +0000 Message-ID: <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> In-Reply-To: <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_021E64FECA7E5A4699562F4E6671648103D35FXCHPHX503swnosboe_" MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 22:31:13 -0000 --_000_021E64FECA7E5A4699562F4E6671648103D35FXCHPHX503swnosboe_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The kind of painfully obvious solution, especially when we consider the eff= ects of the much-ballyhooed "Internet of Things," is that we have to allow = for prefixes > /64. It's not just home nets. What about automobile nets, or more generically, "= vehicle nets"? Are we going to try to rationalize why every vehicle on the = road, sea, or sky should also be given a /48, because after all, for sure = each subsystem in that vehicle will also need to be able to have its own hi= erarchical subnet structure? I think the time has come for even something like SLAAC to be modified, to = accommodate IIDs less than 64 bits. And isn't it convenient that the origin= al idea of creating IIDs out of MAC addresses has lost favor in recent year= s? Egregious waste of resources, in this case IPv6 address space, should make = people uncomfortable. I think we need what amounts to CIDR, applied this ti= me to IPv6. Bert From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Owe= n DeLong Sent: Sunday, June 02, 2013 12:39 PM You just said exactly what I said to begin with... It's to have a bit field= wide enough to allow flexibility in the automation of the hierarchical ass= ignments, not to create 65K subnets. I never asserted it was because we nee= ded 65K subnets. --_000_021E64FECA7E5A4699562F4E6671648103D35FXCHPHX503swnosboe_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The k= ind of painfully obvious solution, especially when we consider the effects = of the much-ballyhooed “Internet of Things,” is that we have to= allow for prefixes > /64.

=  

It= 217;s not just home nets. What about automobile nets, or more generically, = “vehicle nets”? Are we going to try to rationalize why every ve= hicle on the road, sea, or sky  should also be given a /48, because after all, for sure each subsystem in that vehicle will also = need to be able to have its own hierarchical subnet structure?

=  

I thi= nk the time has come for even something like SLAAC to be modified, to accom= modate IIDs less than 64 bits. And isn’t it convenient that the origi= nal idea of creating IIDs out of MAC addresses has lost favor in recent years?

=  

Egreg= ious waste of resources, in this case IPv6 address space, should make peopl= e uncomfortable. I think we need what amounts to CIDR, applied this time to= IPv6.

=  

Bert<= o:p>

=  

=  

From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Owen DeLong
Sent: Sunday, June 02, 2013 12:39 PM

 

You just said exactly what I said to begin with̷= 0; It's to have a bit field wide enough to allow flexibility in the automat= ion of the hierarchical assignments, not to create 65K subnets. I never ass= erted it was because we needed 65K subnets.

=  

=  

--_000_021E64FECA7E5A4699562F4E6671648103D35FXCHPHX503swnosboe_-- From brian.e.carpenter@gmail.com Sun Jun 2 15:51:45 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1DFE21F925A; Sun, 2 Jun 2013 15:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66ElbBcu+BiN; Sun, 2 Jun 2013 15:51:45 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3087F21F9246; Sun, 2 Jun 2013 15:51:45 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id 10so6991966ied.28 for ; Sun, 02 Jun 2013 15:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=79QbN2+RGpyr2wq3hRDFEJfx3TU/D1f+q66H1rg3wTU=; b=kV385pKJk4He3HyoZxzNLXhh398BJM8V8cexnT54q3sTRyTQuFN1wo4kEL5nHSaHkt E11J2XFHIAHeAYbx5TCoDJ2lTYM4fwVCu9Hj6yJxt4Ki0u2yUNfMnuBPwB0igL4wD9x7 B3YDKpAy99SXtpxgdAIZ1Tfw9ZH2T8LHKTyxmkH1jbdXbpF16+OS5JP33J79JF08u1ro HLP3ohCvMo0GUV8w6CmtbkaidJCFcmugKaKt31DNihZCOCGsksBQOkUapUpoUJIEteFV M+lJjWhTEHg9Oj2zquZUVqHFKdRNjZ3soqSLADq+eCfNjycHbE2gOuYNfEdWfsdnjjRG K0FQ== X-Received: by 10.42.121.211 with SMTP id k19mr8842556icr.26.1370213504829; Sun, 02 Jun 2013 15:51:44 -0700 (PDT) Received: from [192.168.1.2] (224.171.252.27.dyn.cust.vf.net.nz. [27.252.171.224]) by mx.google.com with ESMTPSA id d9sm16246535igr.4.2013.06.02.15.51.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Jun 2013 15:51:43 -0700 (PDT) Message-ID: <51ABCC79.4090401@gmail.com> Date: Mon, 03 Jun 2013 10:51:37 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Manfredi, Albert E" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> In-Reply-To: <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong , Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 22:51:45 -0000 On 03/06/2013 10:31, Manfredi, Albert E wrote: > The kind of painfully obvious solution, especially when we consider the effects of the much-ballyhooed "Internet of Things," is that we have to allow for prefixes > /64. > > It's not just home nets. What about automobile nets, or more generically, "vehicle nets"? Are we going to try to rationalize why every vehicle on the road, sea, or sky should also be given a /48, Why is this an issue, since there are 15 trillion of them available? Yes, of course I know about H ratios, but deploying a few billion /48s under some thousands of PA prefixes is well within a prudent policy. Brian From bmanning@isi.edu Sun Jun 2 16:06:41 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E6921F8EB2; Sun, 2 Jun 2013 16:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHYYQRbEWQZK; Sun, 2 Jun 2013 16:06:35 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 113F721F8E37; Sun, 2 Jun 2013 16:06:34 -0700 (PDT) Received: from [192.168.0.4] (cpe-24-24-228-167.socal.res.rr.com [24.24.228.167]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r52N66e7002352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 2 Jun 2013 16:06:15 -0700 (PDT) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: manning bill In-Reply-To: <51ABCC79.4090401@gmail.com> Date: Sun, 2 Jun 2013 16:06:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <51ABC! C79.4090401@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1283) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ted Lemon , Owen DeLong X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 23:06:41 -0000 On 2June2013Sunday, at 15:51, Brian E Carpenter wrote: > On 03/06/2013 10:31, Manfredi, Albert E wrote: >> The kind of painfully obvious solution, especially when we consider = the effects of the much-ballyhooed "Internet of Things," is that we have = to allow for prefixes > /64. >>=20 >> It's not just home nets. What about automobile nets, or more = generically, "vehicle nets"? Are we going to try to rationalize why = every vehicle on the road, sea, or sky should also be given a /48,=20 >=20 > Why is this an issue, since there are 15 trillion of them available? >=20 > Yes, of course I know about H ratios, but deploying a few billion /48s > under some thousands of PA prefixes is well within a prudent policy. >=20 > Brian and operationally, there is no problem whatsoever with all that = extra 'dark space" being advertised - makes a fine environment for DDoS = launches. /48's are a horrible policy - one should only advertise what one = is actually using. /bill= From Ted.Lemon@nominum.com Sun Jun 2 16:14:25 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE94E21F8519; Sun, 2 Jun 2013 16:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKBzVRJoIMrc; Sun, 2 Jun 2013 16:14:19 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id D773C21F84FD; Sun, 2 Jun 2013 16:14:18 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUavRym547O7O1cx6aZQm4U6/wVcMKUuD@postini.com; Sun, 02 Jun 2013 16:14:18 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id F10A81B81AD; Sun, 2 Jun 2013 16:14:17 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id CB21E190052; Sun, 2 Jun 2013 16:14:17 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 2 Jun 2013 16:14:17 -0700 From: Ted Lemon To: Owen DeLong Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAAL+AIAACBKAgABuXQA= Date: Sun, 2 Jun 2013 23:14:17 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C1E59@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> In-Reply-To: <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C1E59mbx01winnominum_" MIME-Version: 1.0 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 23:14:25 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C1E59mbx01winnominum_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jun 2, 2013, at 12:39 PM, Owen DeLong > wrote: We can agree to disagree. Do you want to fly in an airplane designed by someone who agrees to disagre= e with you on whether heavy objects fall faster in a vacuum? Agreeing to = disagree on matters of opinion is fine, but we are discussing matters of fa= ct. One example that comes to mind is if I want greater control and I want my m= ost capable router with the greatest configuration flexibility to be in cha= rge of the addressing scheme, but, it is not the router that interfaces wit= h my ISP. In this case, your "edge" router is the router you attach to your ISP route= r; your ISP router consumes one /64, and your edge router has 65,534 left. = Got anything else? --_000_8D23D4052ABE7A4490E77B1A012B6307751C1E59mbx01winnominum_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4B6A22ED72C7DB40A571E6643CF1601A@nominum.com> Content-Transfer-Encoding: quoted-printable
On Jun 2, 2013, at 12:39 PM, Owen DeLong <owen@delong.com> wrote:
We can agree to disagree. 

Do you want to fly in an airplane designed by someone who agrees to disagre= e with you on whether heavy objects fall faster in a vacuum?   Agreein= g to disagree on matters of opinion is fine, but we are discussing matters = of fact.

One example that comes to mind is if I want greater control and I want my m= ost capable router with the greatest configuration flexibility to be in cha= rge of the addressing scheme, but, it is not the router that interfaces wit= h my ISP.

In this case, your "edge" router is the router you attach to= your ISP router; your ISP router consumes one /64, and your edge router ha= s 65,534 left.   Got anything else?

--_000_8D23D4052ABE7A4490E77B1A012B6307751C1E59mbx01winnominum_-- From Ted.Lemon@nominum.com Sun Jun 2 16:17:36 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B50421F8551; Sun, 2 Jun 2013 16:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1is1HjpwDSg0; Sun, 2 Jun 2013 16:17:29 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id B895C21F84FD; Sun, 2 Jun 2013 16:17:29 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUavSiQN/msE29Wg/ACKlOXHzPHKVfRNQ@postini.com; Sun, 02 Jun 2013 16:17:29 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 5E51E1B818D; Sun, 2 Jun 2013 16:17:29 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 52E3B190052; Sun, 2 Jun 2013 16:17:29 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Sun, 2 Jun 2013 16:17:23 -0700 From: Ted Lemon To: Tim Chown Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAFFqgIAAA0MAgAAlngA= Date: Sun, 2 Jun 2013 23:17:22 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@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: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C1EF5mbx01winnominum_" MIME-Version: 1.0 Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 23:17:36 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C1EF5mbx01winnominum_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jun 2, 2013, at 5:02 PM, Tim Chown > wrote: Isn't the hipnet model one with recursive PD? Yes. A fine engineering solution for demonstration purposes, but not a go= od solution for us to recommend for deployment in the long term. Because = it commits wide prefixes to sub-delegations, it wastes address space profli= gately, and likely would require a /48 for a fairly trivial subnetted homen= et. --_000_8D23D4052ABE7A4490E77B1A012B6307751C1EF5mbx01winnominum_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jun 2, 2013, at 5:02 PM, Tim Chown <tjc@ecs.soton.ac.uk> wrote:
Isn't the hipnet model one with recursive PD?

Yes.   A fine engineering solution for demonstration purposes, bu= t not a good solution for us to recommend for deployment in the long term. =   Because it commits wide prefixes to sub-delegations, it wastes addre= ss space profligately, and likely would require a /48 for a fairly trivial subnetted homenet.

--_000_8D23D4052ABE7A4490E77B1A012B6307751C1EF5mbx01winnominum_-- From internet-drafts@ietf.org Sun Jun 2 16:37:07 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3F621F8FE8; Sun, 2 Jun 2013 16:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.117 X-Spam-Level: X-Spam-Status: No, score=-102.117 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxN+vyhao99n; Sun, 2 Jun 2013 16:37:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 729FD21F85E0; Sun, 2 Jun 2013 16:36:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-stable-privacy-addresses-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130602233646.11112.39637.idtracker@ietfa.amsl.com> Date: Sun, 02 Jun 2013 16:36:46 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 23:37:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : A method for Generating Stable Privacy-Enhanced Addresse= s with IPv6 Stateless Address Autoconfiguration (SLAAC) Author(s) : Fernando Gont Filename : draft-ietf-6man-stable-privacy-addresses-09.txt Pages : 29 Date : 2013-06-02 Abstract: This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware address (e.g., using IEEE identifiers), such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique- local addresses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-stable-privacy-addresses= -09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Jun 2 16:37:50 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85EEA21F85B2; Sun, 2 Jun 2013 16:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.129 X-Spam-Level: X-Spam-Status: No, score=-102.129 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4G-7koXv1T9; Sun, 2 Jun 2013 16:37:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE3521F925A; Sun, 2 Jun 2013 16:37:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-nd-extension-headers-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130602233747.18094.74151.idtracker@ietfa.amsl.com> Date: Sun, 02 Jun 2013 16:37:47 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 23:37:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Security Implications of IPv6 Fragmentation with IPv6 Ne= ighbor Discovery Author(s) : Fernando Gont Filename : draft-ietf-6man-nd-extension-headers-05.txt Pages : 16 Date : 2013-06-02 Abstract: This document analyzes the security implications of employing IPv6 fragmentation with Neighbor Discovery (ND) messages. It updates RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective counter-measures for Neighbor Discovery attacks. Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND), and formally updates RFC 3971 to provide advice regarding how the aforementioned security implications can be prevented. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-nd-extension-headers There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-nd-extension-headers-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-nd-extension-headers-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From brian.e.carpenter@gmail.com Sun Jun 2 16:39:44 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792F821F8B21; Sun, 2 Jun 2013 16:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhAwJlB8HVmm; Sun, 2 Jun 2013 16:39:44 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id DA90C21F8B07; Sun, 2 Jun 2013 16:39:43 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id s9so8854807iec.16 for ; Sun, 02 Jun 2013 16:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=an0wbq/6gTvuKBMZlfiahUpBRmp+4LW8IAu0l3+SSOc=; b=Bc2aZE7UahZFU0W7su3HRcNMO5N6LyBn/uQeZjef2vMxHvxhFexzqjdeG16y2QdyUJ JB1OV5iyj7JlkaypuYjA+Y9xmAUGELo2cQqVpn2ZFp9I2yCJ0yo9tWV/iJ89pwQjLU6e ItK+H8IWKH1RTlaWgBmgxcUwDZKbD0JOsP70WxEOkBHB7+c+cLr5MNvtv5gDSLfCcyVF R3HvxgEdWyq9K5KhOAXnncMVzjgNHfgIAQ/HG6w1kv+4aYaEzm5HrlUAIKw8pbCbw6g0 PvK7mpFiMHRjiHhpKV1SwBFWhmgYTgQw+6on5/nDV4czNS19SNCaswVJB1Zf8P+wEXy2 /iWA== X-Received: by 10.50.60.67 with SMTP id f3mr1511843igr.27.1370216383478; Sun, 02 Jun 2013 16:39:43 -0700 (PDT) Received: from [192.168.1.2] (224.171.252.27.dyn.cust.vf.net.nz. [27.252.171.224]) by mx.google.com with ESMTPSA id z6sm13349731igw.8.2013.06.02.16.39.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Jun 2013 16:39:42 -0700 (PDT) Message-ID: <51ABD7B8.2010006@gmail.com> Date: Mon, 03 Jun 2013 11:39:36 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: manning bill Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <51ABC! C79.4090401@gmail.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> In-Reply-To: <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ted Lemon , Owen DeLong X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 23:39:44 -0000 On 03/06/2013 11:06, manning bill wrote: > On 2June2013Sunday, at 15:51, Brian E Carpenter wrote: > >> On 03/06/2013 10:31, Manfredi, Albert E wrote: >>> The kind of painfully obvious solution, especially when we consider the effects of the much-ballyhooed "Internet of Things," is that we have to allow for prefixes > /64. >>> >>> It's not just home nets. What about automobile nets, or more generically, "vehicle nets"? Are we going to try to rationalize why every vehicle on the road, sea, or sky should also be given a /48, >> Why is this an issue, since there are 15 trillion of them available? >> >> Yes, of course I know about H ratios, but deploying a few billion /48s >> under some thousands of PA prefixes is well within a prudent policy. >> >> Brian > > and operationally, there is no problem whatsoever with all that extra 'dark space" being advertised - makes a fine environment for DDoS launches. > /48's are a horrible policy - one should only advertise what one is actually using. Advertised where? Vehicle prefixes will need to be heavily aggregated anyway, so you wouldn't see anything as long as a car's /48 in BGP. Dark space is a fact of life when you have lots of address space, isn't it? Brian From sander@steffann.nl Sun Jun 2 16:47:39 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C0221F8F29; Sun, 2 Jun 2013 16:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[AWL=-1.048, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhcJvIRcBIcU; Sun, 2 Jun 2013 16:47:34 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 81EBF21F8EBE; Sun, 2 Jun 2013 16:47:33 -0700 (PDT) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id 952302002; Mon, 3 Jun 2013 01:47:32 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Sander Steffann In-Reply-To: <51ABD7B8.2010006@gmail.com> Date: Mon, 3 Jun 2013 01:47:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <51ABC! C79.4090401@gmail.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <51 ABD7B8.2010006@gmail.com> To: manning bill X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org WG" , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 23:47:39 -0000 On 03/06/2013 11:06, manning bill wrote: > /48's are a horrible policy - one should only advertise what one is = actually using. Now *that* would cause a nice fragmented DFZ... Sander From albert.e.manfredi@boeing.com Sun Jun 2 17:13:55 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E5621F8E6E; Sun, 2 Jun 2013 17:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 718511WjujEh; Sun, 2 Jun 2013 17:13:49 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id A122921F8E12; Sun, 2 Jun 2013 17:13:49 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r530ER0F020892; Sun, 2 Jun 2013 17:14:27 -0700 Received: from XCH-PHX-102.sw.nos.boeing.com (xch-phx-102.sw.nos.boeing.com [137.136.238.5]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r530EQ5o020886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Sun, 2 Jun 2013 17:14:26 -0700 Received: from XCH-PHX-503.sw.nos.boeing.com ([169.254.3.131]) by XCH-PHX-102.sw.nos.boeing.com ([169.254.2.161]) with mapi id 14.02.0328.011; Sun, 2 Jun 2013 17:13:47 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter Subject: RE: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOX+PKVx1J02yXYEGEbq/FVzPaNpkjgRsAgAAJVwD//4/OYIAAAhuQ Date: Mon, 3 Jun 2013 00:13:46 +0000 Message-ID: <021E64FECA7E5A4699562F4E6671648103D431@XCH-PHX-503.sw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 00:13:56 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBb bWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCg0KPiBBZHZlcnRpc2VkIHdoZXJl PyBWZWhpY2xlIHByZWZpeGVzIHdpbGwgbmVlZCB0byBiZSBoZWF2aWx5IGFnZ3JlZ2F0ZWQgYW55 d2F5LA0KPiBzbyB5b3Ugd291bGRuJ3Qgc2VlIGFueXRoaW5nIGFzIGxvbmcgYXMgYSBjYXIncyAv NDggaW4gQkdQLg0KPiANCj4gRGFyayBzcGFjZSBpcyBhIGZhY3Qgb2YgbGlmZSB3aGVuIHlvdSBo YXZlIGxvdHMgb2YgYWRkcmVzcyBzcGFjZSwgaXNuJ3QgaXQ/DQoNClllcywgb2YgY291cnNlIHdl IG5lZWQgdG8gcHJvbW90ZSBhZ2dyZWdhdGlvbi4gU2VlbXMgdG8gbWUgdGhhdCBpdCdzIGhhcmQg dG8gcHJlZGljdCB0aGUgZnV0dXJlIG9mIHRoaXMgSW9UIHRoaW5nLCBhbmQgdGhhdCA0OC1iaXQg cHJlZml4ZXMgYXJlIHVsdGltYXRlbHkgd2F5IG1vcmUgbGltaXRpbmcgdGhhbiB0aGV5IHNob3Vs ZCBiZSwgd2hpbGUgdGhlIDY0LWJpdCBJSURzIGFyZSB3YXkgbW9yZSBnZW5lcm91cyB0aGFuIHRo ZXkgbmVlZCB0byBiZS4NCg0KSXQgc2VlbXMgdG8gYmUgdGhhdCBsb2NhbGl6ZWQgaGllcmFyY2hp Y2FsIG5ldHMgYXJlIGdvaW5nIHRvIGJlY29tZSB0aGUgbm9ybS4gQSBudW1iZXIgdGhhdCBtYWtl cyBzZW5zZSB0byBtZSB3b3VsZCBiZSwgZm9yIGV4YW1wbGUsIDE2LWJpdCBJSURzLiBTdGlsbCBh IGh1Z2UgbnVtYmVyIG9mIGxvY2FsIGhvc3RzIGluIHRoZSBzdWItc3ViIG5ldCAoZS5nLiB0aGUg c3RlZXJpbmcgY29udHJvbCBzeXN0ZW0pLCBidXQgdGhlbiB0aGF0IGVudGlyZSB2ZWhpY2xlIGFu ZCBhbGwgaXRzIHN1Ym5ldHMgY291bGQgYmUgZ2l2ZW4gYSAvNjQuIEVhc2lseS4NCg0KSSBzdXBw b3NlIHRoYXQgYSBsb2NhbCBESENQdjYgc2VydmVyIGNvdWxkIHRha2UgY2FyZSBvZiB0aGlzIGFu eXdheSwgdGhvdWdoLiBTbyBtYXliZSB0aGVyZSdzIG5vIHByb2JsZW0uDQoNCkJlcnQNCg0K From lorenzo@google.com Sun Jun 2 17:40:51 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0AE21F896D for ; Sun, 2 Jun 2013 17:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.527 X-Spam-Level: X-Spam-Status: No, score=-1.527 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS4HkTRekkLV for ; Sun, 2 Jun 2013 17:40:50 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 46BA921F89A5 for ; Sun, 2 Jun 2013 17:40:49 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id bs12so1523148qab.1 for ; Sun, 02 Jun 2013 17:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XrLUwXOm6MS1/9IWCSvsFW5/Hz1pDV2m52lfh8DWR9Q=; b=cEWIpiQVNBWIYBWk59F4yd3PJgKRvN3Zp/VZ/gqVTpqWy40goOdJ3kCvbPJl+BWRku 6uY9vB98mb0mla3wLwGtMO2ZQbLGEJfBhPeK5jRWgjSkbjU5rP9a9elnBjw02PBMCxVC lqAslASLuWB3/5rwjSPIoGbqY05nZ9OGl5bKePWV0J+n33/UsWJH1pbuqk+l+k5KqGV7 9PXKaXwLkot3nfQnifwS1ci5cYa3CQth/EA6+Rg8IN3pIDv954mB/UnqewusRAekUuoI mvx+ofk1kkMeXj4JqCI3DX5NZNs8oG5Q1qfLsmvC7g8Te+x5Q4vSc7aPVS/T+x7g+LJw nH7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=XrLUwXOm6MS1/9IWCSvsFW5/Hz1pDV2m52lfh8DWR9Q=; b=HQE7Fh5l/auC1zVW0Q32NmRRg7KTIUuOKZgI92pcweOoXcPXuIQsKlLILf0ODUnxUA 7W+cIWg4tkSVTDWaKW2qUruKDFb/B8HPFcX6KSgpQUX0iYDT4Glnr/eonS9+PfTfmhfK wtTxxPM1kdEi6xbGRWrRukrpaLqxa2B7jrNGd4hFe7MPrsd1m3Hbz+m0Azfjbo+9jU/4 C6L4m0f8VY0e2SfWlNJ7cl8MltCG4TuFJ6RejJznPQ5i/26m1jYn9KJuiGm1pV3HqgsS NxtQJ6UanHlEnzZ6B5Ygrb//bkbtmADgqKLFTkHrpN8F5AReBD6rwWTlobCnNAuty/Da sdUA== X-Received: by 10.224.214.134 with SMTP id ha6mr16978677qab.77.1370220045063; Sun, 02 Jun 2013 17:40:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.198 with HTTP; Sun, 2 Jun 2013 17:40:23 -0700 (PDT) In-Reply-To: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> From: Lorenzo Colitti Date: Mon, 3 Jun 2013 09:40:23 +0900 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 To: Tim Chown Content-Type: multipart/alternative; boundary=20cf300fb23d0d197004de35371f X-Gm-Message-State: ALoCoQlNdAMYUPiDpBHkQh+gu19r/+Cvm19BtB/U3H6BELVBLGVrtRjTP9nK2HNH90mBGjc8p9eOwEwSSLumQ9qkQ1XaaJnHUvXTDkOLO4xhSm7dtcwZn9zXDVRbEfSGKv7PcA0iKnQekjMGhRw5HL3FIngzd9qmwIAj6c2Sd7oZqCllRVIYJimiYM6yFbcx9tfoCnlnMqG8 Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 00:40:51 -0000 --20cf300fb23d0d197004de35371f Content-Type: text/plain; charset=ISO-8859-1 An unadopted draft does not an implementation (or a deployment!) make. On Sun, Jun 2, 2013 at 4:05 AM, Tim Chown wrote: > On 1 Jun 2013, at 13:42, Owen DeLong wrote: > > > On Jun 1, 2013, at 5:58 AM, Ted Lemon wrote: > > On May 31, 2013, at 10:47 PM, Owen DeLong wrote: > > What solutions exist today that provide for the home of the future where > there are, in fact, multiple levels of routers many of which are managing > routers underneath them with multiple links attached? > > > There's a fairly ugly DHCPv6 PD binary splitting solution that's actually > been implemented, which is not efficient because it does sub-delegations of > >/64 prefixes to internal routers. There's the better PD solution that > lets the router that got the initial delegation sub-delegate /64s > throughout the home, which results in efficient use of the initial prefix. > And there's delegation over ZOSPF, for which there is running code that > the implementors seem to think works, and which is also efficient in its > use of prefixes. This is a solved problem. > > > URLs to documentation of any/all of the above? > > The only one I was aware of was the first one you mentioned, which, while > running is fairly primitive in its capabilities. > > The second one sounds like it gets pretty dysfunctional if you have > downstream routers with downstream routers. > > I haven't even heard of the third one, so absent some reference, I can't > really comment. > > > zOSPF-based: > http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-autoconfig-00 > http://tools.ietf.org/html/draft-arkko-homenet-prefix-assignment-04 > > DHCP-based: > http://tools.ietf.org/html/draft-grundemann-homenet-hipnet-01 > http://tools.ietf.org/html/draft-baker-homenet-prefix-assignment-01 > > See also > http://tools.ietf.org/html/draft-ietf-homenet-arch-08#page-25 > > There are at least two interoperable implementations of the zOSPF solution > using different platforms (bird and quagga) > > Tim > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --20cf300fb23d0d197004de35371f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
An unadopted draft does not an implementation (or a deploy= ment!) make.


On Sun, Jun 2, 2013 at 4:05 AM, Tim Chown <tjc@ecs.soton.ac.uk&= gt; wrote:
On 1 Jun 2013, at 13:42, Owen DeLong <owen@delong.com> wrote= :


=
On Jun 1, 2013, at 5:58 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
On May 31, 2013, at 10:47 PM, Owen DeLong <owen@delong.com>=A0wrote:
What solutions exist today that provide for the home of the future where there = are, in fact, multiple levels of routers many of which are managing routers= underneath them with multiple links attached?

There's a fairly ugly DHCPv6 PD binary splitting solution that'= ;s actually been implemented, which is not efficient because it does sub-de= legations of >/64 prefixes to internal routers. =A0 There's the bett= er PD solution that lets the router that got the initial delegation sub-delegate /64s throughout the home, which results in= efficient use of the initial prefix. =A0 And there's delegation over Z= OSPF, for which there is running code that the implementors seem to think w= orks, and which is also efficient in its use of prefixes. =A0 This is a solved problem.


URLs to documentation of any/all of the above?<= /div>

The only one I was aware of was the first one you = mentioned, which, while running is fairly primitive in its capabilities.

The second one sounds like it gets pretty dysfunctional= if you have downstream routers with downstream routers.

I haven't even heard of the third one, so absent some reference,= I can't really comment.


See also

The= re are at least two interoperable implementations of the zOSPF solution usi= ng different platforms (bird and quagga)

Tim

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


--20cf300fb23d0d197004de35371f-- From lorenzo@google.com Sun Jun 2 17:48:30 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B67A21F86F0 for ; Sun, 2 Jun 2013 17:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHOJSprcOEqE for ; Sun, 2 Jun 2013 17:48:29 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C47D321F89A6 for ; Sun, 2 Jun 2013 17:48:29 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id a1so1825506qcx.6 for ; Sun, 02 Jun 2013 17:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gM6RyPIb06bqptCwroBWLAUcOlPdRdJqjs/jm0TcdrE=; b=P8Tfa2yx+778nSBc802BbNctBrx9LcccGW1V7vNMfCQjAM/xcYhXHsNsHtq0mflD4U ZdsEFG3+NEjYAcDOAk3s2TpXjtkpqt9XOoUpgsPh+lygwy//u0x5Q7yMG6p7R5flQ4Bo tZBXwP7cs17js5Il3w1gdN/S3KoeJo5PRwaTTi+5VRdJH+sxgzVUEaaea3SdyqiBcC0B bCogWzrxW3SIiFN+E4MdeT6KFaYl2WVCLR3oAoyK6ggCD6eh+sJnG1ld1Az1CQHrPMQW e3jGHVNA8kF5DFnhRhz5VMUkziQxavCfi84iFFXGVg/ExU2v6t95GCL8XKc9EitbHAA1 SsBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=gM6RyPIb06bqptCwroBWLAUcOlPdRdJqjs/jm0TcdrE=; b=gfhPSooWtxFBtFRx6zUL+v4ruMV4Vz9uRvWh0a033xjIs37ZQTRQWYSFVcpzsI5Jbp kIWlyioiJ2dV32On2ZobPzZWvOufA/10G5sAsf8u8Z9v3LLOX63kztLmvR4fYbvm7rGP YRQeTxJ0N8h54BQYXzpV1o6thRfQHZIswgeIqdy1np44J7Z9MJKpNkpbPHwNFf32YHKF CepCnUecDubylH+lBmVzjkYEM1uW3aO/nBnSda2Y+mHAUUC0gtefvcrEyrXzCa5f34GS K3C+O6Qkx4zO2C0ced3Wozos+XAmrZC+KcjBSBN78YSv4aF9cbFm/RqXx1zaAFabCR9x jNgw== X-Received: by 10.229.137.73 with SMTP id v9mr3734285qct.77.1370220508914; Sun, 02 Jun 2013 17:48:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.198 with HTTP; Sun, 2 Jun 2013 17:48:08 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> From: Lorenzo Colitti Date: Mon, 3 Jun 2013 09:48:08 +0900 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 To: Ted Lemon Content-Type: multipart/alternative; boundary=00235452fd9cb2fecb04de355264 X-Gm-Message-State: ALoCoQlOrgWYlHdcb+v2RKxGYPlphstUpWSMWOaMcTdy0uPPbB5Sx5u96lwqJwSuS7pWxFRbYcNo5484nARk9U2x0g4EeqI60Y4W4G4wvO+IKfr3JnDgWwam+9OKWpUtJFXnklX/fdCJluwDapgwat82+dXR0SvidnPfcc+CavrGTiH9LRlu5WnmODm5asz7ODhsSLR7AdWJ Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 00:48:30 -0000 --00235452fd9cb2fecb04de355264 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jun 2, 2013 at 3:51 PM, Ted Lemon wrote: > This is trivially solved with PD at the PE router that gets the > delegation from the ISP. I thought you were talking about a multi-homed > topology. Also trivially solved, but might involve two edge routers each > with their own set of prefixes to delegate. > And when one of those two edge routers is unplugged by the user, the network is dead in the water. We need to do better than that. --00235452fd9cb2fecb04de355264 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jun 2, 2013 at 3:51 PM, Ted Lemon <Ted.Lemon@= nominum.com> wrote:
This is trivially solved with PD at the PE router that gets the delega= tion from the ISP. =A0 I thought you were talking about a multi-homed topol= ogy. =A0 Also trivially solved, but might involve two edge routers each wit= h their own set of prefixes to delegate.

And when one of those tw= o edge routers is unplugged by the user, the network is dead in the water. = We need to do better than that.
--00235452fd9cb2fecb04de355264-- From lorenzo@google.com Sun Jun 2 17:51:41 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D428721F8EAE for ; Sun, 2 Jun 2013 17:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.857 X-Spam-Level: X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGOUMXDXNIbs for ; Sun, 2 Jun 2013 17:51:41 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 44A4F21F8A0B for ; Sun, 2 Jun 2013 17:51:41 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id l11so1818232qcy.23 for ; Sun, 02 Jun 2013 17:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=p4la1bHlrMyQC07qTOQpRVGIMDJ+GTMB3LFIBNAdPpA=; b=H1KspHSBTqIqM3x56ufEzsoT1R0Kjl148Bv+G6Ak/+j9I1r7kV/D8QfXwIFyTRr8XP SjeHNcqq9qC1o8fkSWTs0QosyZuRYj72nH8RdmS6Vv1rJ92BZEeJ8HOEsNIIW8GILZX0 hOTZw80fbWrym2gO1EFWctwOXPpDcHT7MuBCZ1xFcZjVXWaEmw4s3tr9gGYuA0edys/C 2Ae4bCH3Or47GRJ/AHIHtR3iQiGOS7XGZqcoNmqFROZfdrJlnTcHd9+Q31PF+79UXhzr 3iTRTnyPho+51bmNAi+ApYIWJLV65TABYqCQoEgFEpx7q2j8efbbux8GpFnwC5c2P+2x fKVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=p4la1bHlrMyQC07qTOQpRVGIMDJ+GTMB3LFIBNAdPpA=; b=XaSr49bIWaHa7RSu6xg63T684kTZshjTsqWj0fzK+9i2jmwGpySM3a5roTe1/44YkX dCASnbrZGI+MT4GBkRxqJ62xfY2+xCfRitbjebGTBlgm5oCgxGlQ3hzlyM7TzR18R/uE CtpHJRA7JfhOrxInnjr9EcufWFv+CoO7uozrSPedFDbqEbxrQz//k/uO2V8/UNa5FHzo jU0Gr5RZjaCoQmEtekVOCUnX47oDzy46aoaBU4BYnaFcbngTlRaZ9haQZ3at7QmG40/7 2eWBA9fsZIzkw2/Tr31HpBjDcJEhGWoHe1xDI63mGG3ssruKH3j8g/7eagWk7/foCdUD bCIg== X-Received: by 10.224.38.133 with SMTP id b5mr16988057qae.78.1370220700736; Sun, 02 Jun 2013 17:51:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.198 with HTTP; Sun, 2 Jun 2013 17:51:20 -0700 (PDT) In-Reply-To: <6EBDAA70-E2C1-47CF-9FF1-0844C8868CA5@gmail.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C16A4@mbx-01.win.nominum.com> <6EBDAA70-E2C1-47CF-9FF1-0844C8868CA5@gmail.com> From: Lorenzo Colitti Date: Mon, 3 Jun 2013 09:51:20 +0900 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 To: Ralph Droms Content-Type: multipart/alternative; boundary=001a11c29f6021dfcf04de355e31 X-Gm-Message-State: ALoCoQk3F0Jp3LOGClsU8tU57x+PKwQ/h0S/jYQPncXp2zl9GT2gfnBneniVE3kfG4htd2wBFHjDX9+ks7BL4eNgJqwQuGUp+2MZpyxja5FoAWrbh0ONogoP38o2rHiDAhoQidXDRFs7GG9uAVUk660+rQxQxvpbFAxCzkiE3wOn4nKzBRh5Ga0q75Pa57i+R/mPPM2PRMBC Cc: Tim Chown , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 00:51:41 -0000 --001a11c29f6021dfcf04de355e31 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 3, 2013 at 5:47 AM, Ralph Droms wrote: > Yes, draft-baker-homenet-prefix-assignment describes non-hierarchical > assignment, in which all prefixes are delegates from a single server. > > I'll resuscitate it, as it seems to be a useful reference for this > discussion. > We shouldn't resuscitate it unless it has a solution for "user unplugs the router which assigned all the prefixes in the home". "Making hosts try all their addresses all the time" (or, more euphemistically, "happy eyeballs"), is not a solution. --001a11c29f6021dfcf04de355e31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 3, 2013 at 5:47 AM, Ralph Droms <rdroms.i= etf@gmail.com> wrote:
Yes,=A0draft-baker-homenet-prefix-assignment describes non-hierarchical ass= ignment, in which all prefixes are delegates from a single server.

I'll resuscitate it, as it = seems to be a useful reference for this discussion.

We shouldn't resuscitate it unless it has a s= olution for "user unplugs the router which assigned all the prefixes i= n the home".

"Making hosts t= ry all their addresses all the time" (or, more euphemistically, "= happy eyeballs"), is not a solution.
--001a11c29f6021dfcf04de355e31-- From bmanning@isi.edu Sun Jun 2 19:47:09 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CB621F8E12; Sun, 2 Jun 2013 19:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvRwDOldy3zW; Sun, 2 Jun 2013 19:47:03 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 87D5F21F8CF4; Sun, 2 Jun 2013 19:47:03 -0700 (PDT) Received: from [192.168.0.4] (cpe-24-24-228-167.socal.res.rr.com [24.24.228.167]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r532kZ1Q010372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 2 Jun 2013 19:46:45 -0700 (PDT) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: manning bill In-Reply-To: <51ABD7B8.2010006@gmail.com> Date: Sun, 2 Jun 2013 19:46:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <51ABC! C79.4090401@gmail.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <5! 1ABD7B8.2010006@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1283) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu Cc: Owen DeLong , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 02:47:09 -0000 On 2June2013Sunday, at 16:39, Brian E Carpenter wrote: > On 03/06/2013 11:06, manning bill wrote: >> On 2June2013Sunday, at 15:51, Brian E Carpenter wrote: >>=20 >>> On 03/06/2013 10:31, Manfredi, Albert E wrote: >>>> The kind of painfully obvious solution, especially when we consider = the effects of the much-ballyhooed "Internet of Things," is that we have = to allow for prefixes > /64. >>>>=20 >>>> It's not just home nets. What about automobile nets, or more = generically, "vehicle nets"? Are we going to try to rationalize why = every vehicle on the road, sea, or sky should also be given a /48,=20 >>> Why is this an issue, since there are 15 trillion of them available? >>>=20 >>> Yes, of course I know about H ratios, but deploying a few billion = /48s >>> under some thousands of PA prefixes is well within a prudent policy. >>>=20 >>> Brian >>=20 >> and operationally, there is no problem whatsoever with all that = extra 'dark space" being advertised - makes a fine environment for DDoS = launches. >> /48's are a horrible policy - one should only advertise what = one is actually using. >=20 > Advertised where? Vehicle prefixes will need to be heavily aggregated > anyway, so you wouldn't see anything as long as a car's /48 in BGP. >=20 > Dark space is a fact of life when you have lots of address space, = isn't it? >=20 > Brian >=20 advertised to a peer=85 and your presumption of need doesn't = seem to be backed up by some of the current work in vehicle networking. by your logic, we shouldn't see prefixes shorter than /24 in v4 = space BGP=85 but there they are and have been for years. darkspace is not a fact of life - if you only advertise what you = use. there is no difference between a /48 and a /121 or a /9 and a = /27 - each consumes a single routing table slot. if i'm using only a /121 out of that /32 i'm forced to take, why = should i be forced to advertise more than i use? one slot is one = slot. right? /bill From Ted.Lemon@nominum.com Sun Jun 2 19:50:00 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8702321F8717; Sun, 2 Jun 2013 19:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3T2Sp2U4SrXJ; Sun, 2 Jun 2013 19:49:53 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id BA50A21F86F5; Sun, 2 Jun 2013 19:49:53 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUawEUcqUt1uMJ12q5NHMwHDaFLvFktLF@postini.com; Sun, 02 Jun 2013 19:49:53 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 321B71B81C4; Sun, 2 Jun 2013 19:49:53 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1AE7F190052; Sun, 2 Jun 2013 19:49:53 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 2 Jun 2013 19:49:53 -0700 From: Ted Lemon To: Lorenzo Colitti Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOX/MGS3pojCy3VUic0CoSvPDmfJkjv30A Date: Mon, 3 Jun 2013 02:49:52 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C22A7@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C22A7mbx01winnominum_" MIME-Version: 1.0 Cc: Tim Chown , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 02:50:00 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C22A7mbx01winnominum_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jun 2, 2013, at 8:40 PM, Lorenzo Colitti > wrote: An unadopted draft does not an implementation (or a deployment!) make. The two are in fact completely orthogonal! --_000_8D23D4052ABE7A4490E77B1A012B6307751C22A7mbx01winnominum_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jun 2, 2013, at 8:40 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
An unadopted draft does not an implementation (or a deployment!) make.

The two are in fact completely orthogonal!


--_000_8D23D4052ABE7A4490E77B1A012B6307751C22A7mbx01winnominum_-- From Ted.Lemon@nominum.com Sun Jun 2 19:51:14 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3388721F8717; Sun, 2 Jun 2013 19:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRMgC92uSwlf; Sun, 2 Jun 2013 19:51:07 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5688D21F86F5; Sun, 2 Jun 2013 19:51:07 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUawEmwR2Gh/mXQexKT/iJTo5G2QLylBm@postini.com; Sun, 02 Jun 2013 19:51:07 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C1E101B81C4; Sun, 2 Jun 2013 19:51:06 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id BA19A190052; Sun, 2 Jun 2013 19:51:06 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Sun, 2 Jun 2013 19:51:01 -0700 From: Ted Lemon To: Lorenzo Colitti Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgAEstwCAACJUAA== Date: Mon, 3 Jun 2013 02:51:00 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C22CF@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C22CFmbx01winnominum_" MIME-Version: 1.0 Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 02:51:14 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C22CFmbx01winnominum_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jun 2, 2013, at 8:48 PM, Lorenzo Colitti > wrote: And when one of those two edge routers is unplugged by the user, the networ= k is dead in the water. We need to do better than that. Yes, there is a lot of code out there that breaks horribly in the presence = of multihoming. --_000_8D23D4052ABE7A4490E77B1A012B6307751C22CFmbx01winnominum_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jun 2, 2013, at 8:48 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
And when one of those two edge routers is unplugged by the user, the network i= s dead in the water. We need to do better than that.

Yes, there is a lot of code out there that breaks horribly in the pres= ence of multihoming.

--_000_8D23D4052ABE7A4490E77B1A012B6307751C22CFmbx01winnominum_-- From Ted.Lemon@nominum.com Sun Jun 2 19:53:14 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BD721F8E37; Sun, 2 Jun 2013 19:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfHPtdN7ord7; Sun, 2 Jun 2013 19:53:07 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 33F8F21F8763; Sun, 2 Jun 2013 19:53:07 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUawFE4RPMDB1xjbxCXAuWNJ7lGFMe1V+@postini.com; Sun, 02 Jun 2013 19:53:07 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C2CAB1B81C4; Sun, 2 Jun 2013 19:53:06 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id BBBD7190052; Sun, 2 Jun 2013 19:53:06 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 2 Jun 2013 19:53:06 -0700 From: Ted Lemon To: Lorenzo Colitti Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOX/SXKMgRcH6hQEK2lJMdDTmTB5kjwGCA Date: Mon, 3 Jun 2013 02:53:06 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C2311@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C16A4@mbx-01.win.nominum.com> <6EBDAA70-E2C1-47CF-9FF1-0844C8868CA5@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C2311mbx01winnominum_" MIME-Version: 1.0 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 02:53:14 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C2311mbx01winnominum_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jun 2, 2013, at 8:51 PM, Lorenzo Colitti > wrote: We shouldn't resuscitate it unless it has a solution for "user unplugs the = router which assigned all the prefixes in the home". "Making hosts try all their addresses all the time" (or, more euphemistical= ly, "happy eyeballs"), is not a solution. If your point is that zOSPF is a better solution, you may be right. If yo= ur point is that hierarchical delegation within the homenet is better, you = would be wrong. The original discussion was about that question, not the = question of which of the two solutions is better. --_000_8D23D4052ABE7A4490E77B1A012B6307751C2311mbx01winnominum_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jun 2, 2013, at 8:51 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
We shouldn't resuscitate it unless it has a solution for "user unplugs= the router which assigned all the prefixes in the home".
"Making hosts try all their addresses all the time" (or, more eup= hemistically, "happy eyeballs"), is not a solution.

If your point is that zOSPF is a better solution, you may be right. &n= bsp; If your point is that hierarchical delegation within the homenet is be= tter, you would be wrong.   The original discussion was about that que= stion, not the question of which of the two solutions is better.

--_000_8D23D4052ABE7A4490E77B1A012B6307751C2311mbx01winnominum_-- From lorenzo@google.com Sun Jun 2 20:23:24 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E08D21F8D2B for ; Sun, 2 Jun 2013 20:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GG3QqB11rf63 for ; Sun, 2 Jun 2013 20:23:24 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id E8C8F21F8F0E for ; Sun, 2 Jun 2013 20:23:23 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id hu16so1550154qab.20 for ; Sun, 02 Jun 2013 20:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VZpd0rsVJ/U9QMp7pbk2sqLbwNEKRS0l9DzSJPgjYgA=; b=IEx4Jhvhd/SAUTs80OZKbWriXcutX+8eodL2WzOall+iwgFSONFNmGAfIkopfCwz4g Nco9Ly3LwCCIVCesPssd6qd/R4W69jlMBSSjMrzM5zfm+54+4iykXzxkyNXCoX8zsNqm kA+FbhBHvCR7APf5w/o+MoPLullpx+97fAcqcC1q8/8nDZcmUc9mCSgm3DSIR3INNURd 8P/Ofwriu8MAiJyjZLGN6yeewjt0Q+hJKs+p6Uf5HhJZPVCpkcN6g2l4nFn03Ax+T7yU p0u1O1/9+QXGMuv2QbeyR8d6KICHEfvDTSqYUAEE7CA45ByW/1bk3tHYzlvR2vnaUv0U 39zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=VZpd0rsVJ/U9QMp7pbk2sqLbwNEKRS0l9DzSJPgjYgA=; b=HAZ6+3UJ+vnpMbnbGAXyUHBrYN4wwB7PoGhUY67GWE5w4QlrnYncnMFpkj+JWSwDoG GuJtvXgTR+UrjnKjMhLW90RTCn4I0xmPi+bRzxxPtGhPsCGnuBQe0WCBFFWUXUjSg07s hpucOoqxOmLyDJwDD2c5b+ZJtrNFQDd9w8OGFnIvWT5GOxWKZr3t/FQNaT3eI+T2mbYi psdXYklMiK/kU8pFtutR+KRPqxEiy3dlSndVkTgeBT4l3xhvfq7K0qpHwBm2AdQzut/b vPYR+DCFYppjN4EcT2r3lYlkvMu7cixAwmEf3PM6euS6onDXUvxzNjYzImZ6N83ahgFd vi6g== X-Received: by 10.224.214.134 with SMTP id ha6mr17331675qab.77.1370229803257; Sun, 02 Jun 2013 20:23:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.198 with HTTP; Sun, 2 Jun 2013 20:23:03 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C2311@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C16A4@mbx-01.win.nominum.com> <6EBDAA70-E2C1-47CF-9FF1-0844C8868CA5@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751C2311@mbx-01.win.nominum.com> From: Lorenzo Colitti Date: Mon, 3 Jun 2013 12:23:03 +0900 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf300fb23daf45b404de377cb6 X-Gm-Message-State: ALoCoQn0LOugj0X/S2RSLcITsCZumlUes3LLuRgun3Kxy8gO3WE5NKQioD8q9uyVd7Pl2IpKAxBXzE7MkaqTXLAVR/ExqR6LdhE36iaeM7lDsA0uHraSeX2HCyyz7p/Df4pmomXHFnFAXQHPfcIyTST40TSZw0+jWXEvxBDhbVa6pXq2aj03vXAlxph1P8KWX0uRihcPyl1w Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 03:23:24 -0000 --20cf300fb23daf45b404de377cb6 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 3, 2013 at 11:53 AM, Ted Lemon wrote: > If your point is that zOSPF is a better solution, you may be right. If > your point is that hierarchical delegation within the homenet is better, > you would be wrong. The original discussion was about that question, not > the question of which of the two solutions is better. > Yep, neither hierarchical delegation nor relaying and delegation from the edge solve that problem. SADR does, but it remains to be seen whether it can actually be implemented in the real world. --20cf300fb23daf45b404de377cb6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 3, 2013 at 11:53 AM, Ted Lemon <Ted.Lemon= @nominum.com> wrote:
If your point is that zOSPF is a better solution, you may be right. = =A0 If your point is that hierarchical delegation within the homenet is bet= ter, you would be wrong. =A0 The original discussion was about that questio= n, not the question of which of the two solutions is better.

Yep, neither hierarchical delegation nor relaying and delegation from th= e edge solve that problem. SADR does, but it remains to be seen whether it = can actually be implemented in the real world.
--20cf300fb23daf45b404de377cb6-- From owen@delong.com Sun Jun 2 20:23:43 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5C321F8F83; Sun, 2 Jun 2013 20:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8Fy9FrvaMjL; Sun, 2 Jun 2013 20:23:42 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 68A7C21F8F78; Sun, 2 Jun 2013 20:23:42 -0700 (PDT) Received: from [192.168.6.83] (ip-64-134-24-48.public.wayport.net [64.134.24.48]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r533LtPA025490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 2 Jun 2013 20:21:56 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r533LtPA025490 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370229719; bh=yVTJVIVQcv08E6mv3JBBl3ZuGug=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=EBMoeNHDbyvAwgm3eOOigdGWjCwoRB3xpP01Ir4Vv4Pp4qfQOeYaUY1hwEDr/mW75 ZN94tKrMrv/T/qflaFEWLunCPvkB+ggDbyTF/WFrYyy5n/2ie1wwkVAJGxNCe2Umgw qQLpc6M8bp1sJMy3TgGW5esPazE4FJeXucKEc+oI= Content-Type: multipart/alternative; boundary="Apple-Mail=_A81C14B5-4A8B-47CB-A6F2-E2BB7763D3BA" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Owen DeLong In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> Date: Sun, 2 Jun 2013 22:21:54 -0500 Message-Id: <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Sun, 02 Jun 2013 20:21:59 -0700 (PDT) Cc: Tim Chown , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ralph Droms , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 03:23:43 -0000 --Apple-Mail=_A81C14B5-4A8B-47CB-A6F2-E2BB7763D3BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 2, 2013, at 6:17 PM, Ted Lemon wrote: > On Jun 2, 2013, at 5:02 PM, Tim Chown wrote: >> Isn't the hipnet model one with recursive PD? >=20 > Yes. A fine engineering solution for demonstration purposes, but not = a good solution for us to recommend for deployment in the long term. = Because it commits wide prefixes to sub-delegations, it wastes address = space profligately, and likely would require a /48 for a fairly trivial = subnetted homenet. >=20 You say that as if it would be a bad thing. I don't see a problem with it. Owen --Apple-Mail=_A81C14B5-4A8B-47CB-A6F2-E2BB7763D3BA Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jun 2, 2013, at 6:17 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Jun 2, 2013, at 5:02 PM, Tim Chown <tjc@ecs.soton.ac.uk> wrote:
Isn't the hipnet model one with recursive PD?

Yes.   A fine engineering solution for demonstration purposes, but not a good solution for us to recommend for deployment in the long term.   Because it commits wide prefixes to sub-delegations, it wastes address space profligately, and likely would require a /48 for a fairly trivial subnetted homenet.



You say that as if it would be a bad thing.

I don't see a problem with it.

Owen

--Apple-Mail=_A81C14B5-4A8B-47CB-A6F2-E2BB7763D3BA-- From owen@delong.com Sun Jun 2 20:28:54 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296B121F8FA9; Sun, 2 Jun 2013 20:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2lnhgRaBCbz; Sun, 2 Jun 2013 20:28:53 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 17CE821F8F9E; Sun, 2 Jun 2013 20:28:52 -0700 (PDT) Received: from [192.168.6.83] (ip-64-134-24-48.public.wayport.net [64.134.24.48]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r533Og7D025527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 2 Jun 2013 20:24:44 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r533Og7D025527 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370229885; bh=64PX6g5F59OhIWca0vj1DpceKaA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=L2bgXXByLsSE8f3mWuZAwswDGgLvE4xokxYuoM4sjhjhfLP37VfxbV/gW8xP8gCT2 OWfjDY2nMAnVSnE/y4zPwMhbDn1p/56uLjs9QMwDuE0618lPczX6604bEVLcwGLVJS VltiSGZGzWb/0/JsWCSWyLibLOhJFQ5MI0vxrlR4= Content-Type: multipart/alternative; boundary="Apple-Mail=_9F71A39B-7303-4B08-B21F-8B701C43D13E" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Owen DeLong In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C1E59@mbx-01.win.nominum.com> Date: Sun, 2 Jun 2013 22:24:42 -0500 Message-Id: <4A767C76-97DA-4A7C-9FED-C2AA9EE22D9E@delong.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1E59@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Sun, 02 Jun 2013 20:24:45 -0700 (PDT) Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 03:28:54 -0000 --Apple-Mail=_9F71A39B-7303-4B08-B21F-8B701C43D13E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 2, 2013, at 6:14 PM, Ted Lemon wrote: > On Jun 2, 2013, at 12:39 PM, Owen DeLong wrote: >> We can agree to disagree.=20 >=20 > Do you want to fly in an airplane designed by someone who agrees to = disagree with you on whether heavy objects fall faster in a vacuum? = Agreeing to disagree on matters of opinion is fine, but we are = discussing matters of fact. >=20 Your prior statement: > No, there is no use case where this is better than doing the = delegations from the router that received the initial delegation (since = we're apparently just arguing by vigorous assertion). Is your opinion. I disagree with your opinion and have a different = opinion. It is my opinion that there are use cases. >> One example that comes to mind is if I want greater control and I = want my most capable router with the greatest configuration flexibility = to be in charge of the addressing scheme, but, it is not the router that = interfaces with my ISP. >=20 > In this case, your "edge" router is the router you attach to your ISP = router; your ISP router consumes one /64, and your edge router has = 65,534 left. Got anything else? >=20 My edge router is going to be the one that receives the PD delegation = from the ISP. The router that I want to manage most of the delegations = is not that router. In this case, I want my edge router to delegate to = said other router rather than act as the central PD authority within my = network. It doesn't matter how many prefixes it does or does not use, that = differs from what you proposed and is a valid use case where your = proposal is not desirable. Owen --Apple-Mail=_9F71A39B-7303-4B08-B21F-8B701C43D13E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Ted.Lemon@nominum.com> = wrote:

On Jun 2, 2013, at 12:39 PM, Owen DeLong <owen@delong.com> wrote:
We can agree to disagree. 

Do you want to fly in an airplane designed by someone who agrees to = disagree with you on whether heavy objects fall faster in a vacuum? =   Agreeing to disagree on matters of opinion is fine, but we are = discussing matters of fact.


Your prior = statement:

No, there is no use case where = this is better than doing the delegations from the router that received = the initial delegation (since we're apparently just arguing by vigorous = assertion).
Is = your opinion. I disagree with your opinion and have a different opinion. = It is my opinion that there are use cases.

One example that comes to mind is if I want greater control and I want = my most capable router with the greatest configuration flexibility to be = in charge of the addressing scheme, but, it is not the router that = interfaces with my ISP.

In this case, your "edge" router is the router you attach to your = ISP router; your ISP router consumes one /64, and your edge router has = 65,534 left.   Got anything else?


My edge router is going to be the one that = receives the PD delegation from the ISP. The router that I want to = manage most of the delegations is not that router. In this case, I want = my edge router to delegate to said other router rather than act as the = central PD authority within my network.

It = doesn't matter how many prefixes it does or does not use, that differs = from what you proposed and is a valid use case where your proposal is = not = desirable.

Owen

= --Apple-Mail=_9F71A39B-7303-4B08-B21F-8B701C43D13E-- From owen@delong.com Sun Jun 2 20:29:01 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7442121F91AB; Sun, 2 Jun 2013 20:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTFAMvBXocZg; Sun, 2 Jun 2013 20:29:00 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7149021F90EE; Sun, 2 Jun 2013 20:29:00 -0700 (PDT) Received: from [192.168.6.83] (ip-64-134-24-48.public.wayport.net [64.134.24.48]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r533Q5Zo025554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 2 Jun 2013 20:26:06 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r533Q5Zo025554 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370229967; bh=o4OH55T89UWnmTalxpg1QfwujWI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=ZCy82/HtvHEU20BM2q6oLSVvaJjdjfUSYCu2y9KFVgQ3l6jvSvZLUkMCIKY3hwLjt /gnBtOuz6ri0xMtVx0mBJKCp4EMsisLM0sgBVrxkKxIMMdbUs/tIsMjU5gueBW6q+Q fy2NAx2CRLY67tddVPV0+o6Panx+NXTHfD6Y+pVo= Content-Type: multipart/alternative; boundary="Apple-Mail=_4A533C2A-4C43-4DCB-85B8-92061D86AAF8" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Owen DeLong In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C2311@mbx-01.win.nominum.com> Date: Sun, 2 Jun 2013 22:26:04 -0500 Message-Id: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@m! bx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C16A4@mbx-01.win.nominum.com> <6EBDAA70-E2C1-47CF-9FF1-0844C8868CA5@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751C2311@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Sun, 02 Jun 2013 20:26:07 -0700 (PDT) Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ralph Droms , Lorenzo Colitti X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 03:29:01 -0000 --Apple-Mail=_4A533C2A-4C43-4DCB-85B8-92061D86AAF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jun 2, 2013, at 9:53 PM, Ted Lemon wrote: > On Jun 2, 2013, at 8:51 PM, Lorenzo Colitti = wrote: >> We shouldn't resuscitate it unless it has a solution for "user = unplugs the router which assigned all the prefixes in the home". >> "Making hosts try all their addresses all the time" (or, more = euphemistically, "happy eyeballs"), is not a solution. >=20 > If your point is that zOSPF is a better solution, you may be right. = If your point is that hierarchical delegation within the homenet is = better, you would be wrong. The original discussion was about that = question, not the question of which of the two solutions is better. >=20 My point is that it should be up to the person running the home net (or = other end site) to decide what is better for their site and that we = should not be making the choice for them. Owen --Apple-Mail=_4A533C2A-4C43-4DCB-85B8-92061D86AAF8 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Jun 2, 2013, at 9:53 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Jun 2, 2013, at 8:51 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
We shouldn't resuscitate it unless it has a solution for "user unplugs the router which assigned all the prefixes in the home".
"Making hosts try all their addresses all the time" (or, more euphemistically, "happy eyeballs"), is not a solution.

If your point is that zOSPF is a better solution, you may be right.   If your point is that hierarchical delegation within the homenet is better, you would be wrong.   The original discussion was about that question, not the question of which of the two solutions is better.

My point is that it should be up to the person running the home net (or other end site) to decide what is better for their site and that we should not be making the choice for them.

Owen

--Apple-Mail=_4A533C2A-4C43-4DCB-85B8-92061D86AAF8-- From owen@delong.com Mon Jun 3 05:18:12 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C06021F9633; Mon, 3 Jun 2013 05:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBEJ4Dyn5iGX; Mon, 3 Jun 2013 05:18:03 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD1E21F961B; Mon, 3 Jun 2013 05:18:00 -0700 (PDT) Received: from [192.168.6.83] (ip-64-134-24-48.public.wayport.net [64.134.24.48]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r53CHPBX006302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 Jun 2013 05:17:26 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r53CHPBX006302 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370261848; bh=Fk8u8lsv4xoRF+AVaBPT9eGkmO4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=4zvOJcM4PJmL5q8pIsFNXbY43QY9woYO3oHwJ0SxiyxMnerqDiynaiC4EwO6PU/KJ uH7ji4maYfgkfjaeeY66iWMlqe+b7r7P5FiPdK4ucL+H3opiWrdzvRdb48hBRdAOY/ pjkjMdPHnI6wgMq9UKH27nZm+tcWj3RCYVS1NzSg= Content-Type: multipart/alternative; boundary="Apple-Mail=_E919BD31-7923-4421-A0C2-7791D10A928E" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Owen DeLong In-Reply-To: Date: Mon, 3 Jun 2013 07:17:24 -0500 Message-Id: <10F40025-07E1-459E-8945-2CC685B889FF@delong.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@m! bx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> To: Sheng Jiang X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 03 Jun 2013 05:17:28 -0700 (PDT) Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 12:18:12 -0000 --Apple-Mail=_E919BD31-7923-4421-A0C2-7791D10A928E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 You're looking at the internet of today. Think about 10, 15, 20 years out when everything you buy at the grocery = store has an IP address and most audio amplifiers act as routers to = head-end the other entertainment devices in the cluster. Think about a time when HDMI is supplanted by multi-gigabit wireless = connectivity. Who knows what the future will hold or what technologies may be = developed to take advantage of these new capabilities of end-to-end = addressing. I'd hate to see them stifled because we got stingy with address space. How is an address less wasted by sitting in the free pool long beyond = the useful life of the protocol than it is by being deployed to allow = for flexibility in network design? Owen On Jun 3, 2013, at 2:57 AM, Sheng Jiang wrote: > I have to say the hierarchical assignment is a such great way to waste = address space or prefix bit. I cannot real see much benefits or use = cases of it. Why may home site 3 subordinate routers? How many subnets = or devices may a /48 prefix serve in this model? > =20 > Cheers, > =20 > Sheng >=20 >=20 > On 3 June 2013 00:39, Owen DeLong wrote: >=20 > On Jun 2, 2013, at 11:10 AM, Ted Lemon wrote: >=20 >> On Jun 2, 2013, at 11:59 AM, Owen DeLong wrote: >>> You are assuming that all of the subordinate routers will act as = DHCP relays rather than doing PD. >>> That is certainly one possible solution, but, not necessarily ideal = in all cases. >>> In cases where the subordinate routers should receive delegations = and perform their own PD for their subordinate routers, having a larger = bit field can be useful for greater flexibility. >>=20 >> No, there is no use case where this is better than doing the = delegations from the router that received the initial delegation (since = we're apparently just arguing by vigorous assertion). >>=20 >=20 > We can agree to disagree.=20 >=20 > One example that comes to mind is if I want greater control and I want = my most capable router with the greatest configuration flexibility to be = in charge of the addressing scheme, but, it is not the router that = interfaces with my ISP. >=20 >>> Thus, providing 16 bits to the end site is, IMHO, worth while. >>=20 >> And hence, this conclusion is not supported. >>=20 >> You are welcome, of course, to contradict me by stating such a use = case, but bear in mind that when you delegate prefixes for further = sub-delegation, topology changes in the homenet become impossible. So = your use case for doing this would have to enable some pretty awesome = functionality before it would be worth doing. Also make sure you think = about how it would work during a renumbering event, with sub-delegations = and sub-sub-delegations all having different lifetimes. >>=20 >=20 > Actually, the need for the larger bit field is precisely to allow = topology changes in said deployment scenario. If the top level router = hands out, for example, /50s to its 3 subordinate routers, the = subordinate routers can support a number of different topologies without = requiring any changes at the top-level router. Additionally, a fourth = subordinate router can be added with its own underlying topology = supported. >=20 > OTOH, if there are more than 3 subordinate routers, the top level = router can delegate /51s. True, this would complicate the change from 3 = to more than 3 subordinate routers at the top level somewhat. >=20 >> (I've got nothing against delegating /48's to the home, but the = reason we did that was to maintain flexibility, not because we really = expect a typical homenet to have 65,536 subnets. At least for most = reasonable values of "we.") >>=20 >=20 > You just said exactly what I said to begin with=E2=80=A6 It's to have = a bit field wide enough to allow flexibility in the automation of the = hierarchical assignments, not to create 65K subnets. I never asserted it = was because we needed 65K subnets. >=20 > Owen >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 > --=20 > Sheng Jiang =E8=92=8B=E8=83=9C --Apple-Mail=_E919BD31-7923-4421-A0C2-7791D10A928E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 shengjiang@gmail.com> = wrote:

I have to say the hierarchical = assignment is a such great way to waste address space or prefix bit. I = cannot real see much benefits or use cases of it. Why may home site 3 = subordinate routers? How many subnets or devices may a /48 prefix serve = in this model?
=
 
Cheers,
 
Sheng
=


On 3 June = 2013 00:39, Owen DeLong <owen@delong.com> wrote:

On Jun 2, 2013, at 11:10 AM, = Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Jun 2, 2013, at 11:59 AM, Owen DeLong <owen@delong.com> wrote:
You are assuming that all of the subordinate routers will act as DHCP = relays rather than doing PD.
That is certainly one possible solution, but, not necessarily ideal in = all cases.
In cases where the subordinate routers should receive delegations and = perform their own PD for their subordinate routers, having a larger bit = field can be useful for greater flexibility.

No, there is no use case where this is better than doing the delegations = from the router that received the initial delegation (since we're = apparently just arguing by vigorous assertion).


We can agree to = disagree. 

One example that comes to mind = is if I want greater control and I want my most capable router with the = greatest configuration flexibility to be in charge of the addressing = scheme, but, it is not the router that interfaces with my ISP.

Thus, providing 16 bits to the end site is, IMHO, worth while.

And hence, this conclusion is not supported.

You are welcome, of course, to contradict me by stating such a use = case, but bear in mind that when you delegate prefixes for further = sub-delegation, topology changes in the homenet become impossible. =   So your use case for doing this would have to enable some pretty awesome functionality before it would be worth doing. =   Also make sure you think about how it would work during a = renumbering event, with sub-delegations and sub-sub-delegations all = having different lifetimes.


Actually, the = need for the larger bit field is precisely to allow topology changes in = said deployment scenario. If the top level router hands out, for = example, /50s to its 3 subordinate routers, the subordinate routers can = support a number of different topologies without requiring any changes = at the top-level router. Additionally, a fourth subordinate router can = be added with its own underlying topology supported.

OTOH, if there are more than 3 subordinate routers, = the top level router can delegate /51s. True, this would complicate the = change from 3 to more than 3 subordinate routers at the top level = somewhat.

(I've got nothing against delegating /48's to the home, but the = reason we did that was to maintain flexibility, not because we really = expect a typical homenet to have 65,536 subnets.   At least for = most reasonable values of "we.")


You just said exactly what I said to = begin with=E2=80=A6 It's to have a bit field wide enough to allow = flexibility in the automation of the hierarchical assignments, not to = create 65K subnets. I never asserted it was because we needed 65K = subnets.

Owen


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




--
Sheng Jiang = =E8=92=8B=E8=83=9C

= --Apple-Mail=_E919BD31-7923-4421-A0C2-7791D10A928E-- From Ted.Lemon@nominum.com Mon Jun 3 05:28:04 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611E821F84B5; Mon, 3 Jun 2013 05:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2VpVZ4cl2Vn; Mon, 3 Jun 2013 05:27:57 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0458021F962A; Mon, 3 Jun 2013 05:27:55 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUayLy47oCR/NyKrXtY4UfUz+H9RW00QU@postini.com; Mon, 03 Jun 2013 05:27:56 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6437E1B81E0; Mon, 3 Jun 2013 05:27:55 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 54213190052; Mon, 3 Jun 2013 05:27:55 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 05:27:55 -0700 From: Ted Lemon To: Owen DeLong Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAFFqgIAAA0MAgAAlngCAAERTAIAAmIuA Date: Mon, 3 Jun 2013 12:27:54 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> In-Reply-To: <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C26CBmbx01winnominum_" MIME-Version: 1.0 Cc: Tim Chown , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ralph Droms , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 12:28:04 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C26CBmbx01winnominum_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jun 2, 2013, at 11:21 PM, Owen DeLong > wrote: Yes. A fine engineering solution for demonstration purposes, but not a go= od solution for us to recommend for deployment in the long term. Because = it commits wide prefixes to sub-delegations, it wastes address space profli= gately, and likely would require a /48 for a fairly trivial subnetted homen= et. You say that as if it would be a bad thing. I don't see a problem with it. IIRC, what started this conversation was the claim that wasting bits on sem= antic identifiers was bad because it wasted address space. If you don't t= hink wasting address space is a problem, why are we even having this debate= ? --_000_8D23D4052ABE7A4490E77B1A012B6307751C26CBmbx01winnominum_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jun 2, 2013, at 11:21 PM, Owen DeLong <owen@delong.com> wrote:
Yes.   A fine engineering solution for demonstration purposes, but not= a good solution for us to recommend for deployment in the long term.  = ; Because it commits wide prefixes to sub-delegations, it wastes address sp= ace profligately, and likely would require a /48 for a fairly trivial subnetted homenet.
You say that as if it would be a bad thing.
I don't see a problem with it.

IIRC, what started this conversation was the claim that wasting bits o= n semantic identifiers was bad because it wasted address space.   If y= ou don't think wasting address space is a problem, why are we even having t= his debate?

--_000_8D23D4052ABE7A4490E77B1A012B6307751C26CBmbx01winnominum_-- From Ted.Lemon@nominum.com Mon Jun 3 05:33:11 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3150421F9399; Mon, 3 Jun 2013 05:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5k80f1lrs35b; Mon, 3 Jun 2013 05:33:04 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 954AD21F966B; Mon, 3 Jun 2013 05:33:02 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUayM/ljf4jsuNjlg4d0ORmEDZ8qH5C3t@postini.com; Mon, 03 Jun 2013 05:33:02 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E968E1B81E1; Mon, 3 Jun 2013 05:33:01 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E0193190052; Mon, 3 Jun 2013 05:33:01 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 05:32:55 -0700 From: Ted Lemon To: Owen DeLong Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAAL+AIAACBKAgABuXQCAAEX5AIAAmSoA Date: Mon, 3 Jun 2013 12:32:54 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C2736@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1E59@mbx-01.win.nominum.com> <4A767C76-97DA-4A7C-9FED-C2AA9EE22D9E@delong.com> In-Reply-To: <4A767C76-97DA-4A7C-9FED-C2AA9EE22D9E@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C2736mbx01winnominum_" MIME-Version: 1.0 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 12:33:11 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C2736mbx01winnominum_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jun 2, 2013, at 11:24 PM, Owen DeLong > wrote: No, there is no use case where this is better than doing the delegations fr= om the router that received the initial delegation (since we're apparently = just arguing by vigorous assertion). Is your opinion. I disagree with your opinion and have a different opinion.= It is my opinion that there are use cases. You can't have an opinion about whether something exists. Either it exist= s, or it doesn't. If it exists, you can show that it exists by describing= it. You can have an opinion about whether something *might* exist, but t= hat's not the same thing. And of course you didn't state it that way, bec= ause it's a really weak argument. One example that comes to mind is if I want greater control and I want my m= ost capable router with the greatest configuration flexibility to be in cha= rge of the addressing scheme, but, it is not the router that interfaces wit= h my ISP. In this case, your "edge" router is the router you attach to your ISP route= r; your ISP router consumes one /64, and your edge router has 65,534 left. = Got anything else? My edge router is going to be the one that receives the PD delegation from = the ISP. The router that I want to manage most of the delegations is not th= at router. In this case, I want my edge router to delegate to said other ro= uter rather than act as the central PD authority within my network. It doesn't matter how many prefixes it does or does not use, that differs f= rom what you proposed and is a valid use case where your proposal is not de= sirable. What you just said is exactly what I said above. If your ISP router is cr= ap and you don't want it managing your prefixes, delegate _all_ your prefix= es from your ISP router to an internal router and have _it_ delegate the pr= efixes individually within the homenet (whether with PD or zOSPF). Whether = the ISP router or this internal router acts as the delegator of prefixes, t= he prefixes are used efficiently. Do you have a point to make here, or ar= e you just trying to win an argument through attrition? --_000_8D23D4052ABE7A4490E77B1A012B6307751C2736mbx01winnominum_ Content-Type: text/html; charset="Windows-1252" Content-ID: <879897410BCD954D95C60E13DC0F1DBD@nominum.com> Content-Transfer-Encoding: quoted-printable
On Jun 2, 2013, at 11:24 PM, Owen DeLong <owen@delong.com> wrote:
No, there is no use case where this is better than doing the delegations fr= om the router that received the initial delegation (since we're apparently = just arguing by vigorous assertion).
Is your opinion. I disagree with your opinion and have a different opinion.= It is my opinion that there are use cases.

You can't have an opinion about whether something exists.   Either it = exists, or it doesn't.   If it exists, you can show that it exists by = describing it.   You can have an opinion about whether something *migh= t* exist, but that's not the same thing.   And of course you didn't state it that way, because it's a really weak argumen= t.


One example that comes to mind is if I want greater control and I want my m= ost capable router with the greatest configuration flexibility to be in cha= rge of the addressing scheme, but, it is not the router that interfaces wit= h my ISP.

In this case, your "edge" router is the router you attach to= your ISP router; your ISP router consumes one /64, and your edge router ha= s 65,534 left.   Got anything else?


My edge router is going to be the one that receives the PD delegation = from the ISP. The router that I want to manage most of the delegations is n= ot that router. In this case, I want my edge router to delegate to said oth= er router rather than act as the central PD authority within my network.

It doesn't matter how many prefixes it does or does not use, that diff= ers from what you proposed and is a valid use case where your proposal is n= ot desirable.

What you just said is exactly what I said above.   If your ISP ro= uter is crap and you don't want it managing your prefixes, delegate _all_ y= our prefixes from your ISP router to an internal router and have _it_ deleg= ate the prefixes individually within the homenet (whether with PD or zOSPF). Whether the ISP router or this int= ernal router acts as the delegator of prefixes, the prefixes are used effic= iently.   Do you have a point to make here, or are you just trying to = win an argument through attrition?

--_000_8D23D4052ABE7A4490E77B1A012B6307751C2736mbx01winnominum_-- From Ted.Lemon@nominum.com Mon Jun 3 05:42:06 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE4D21F9642; Mon, 3 Jun 2013 05:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDceDOxT3-TM; Mon, 3 Jun 2013 05:41:59 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCEB21F9632; Mon, 3 Jun 2013 05:41:59 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUayPFw1OLOaaEEERhFWZtCnfDTu2XHNf@postini.com; Mon, 03 Jun 2013 05:41:59 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 10FE01B81E1; Mon, 3 Jun 2013 05:41:59 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 05359190052; Mon, 3 Jun 2013 05:41:59 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 05:41:58 -0700 From: Ted Lemon To: Owen DeLong Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOX/SXKMgRcH6hQEK2lJMdDTmTB5kjwGCAgAAJNwCAAJtQgA== Date: Mon, 3 Jun 2013 12:41:57 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C280D@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@m! bx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C16A4@mbx-01.win.nominum.com> <6EBDAA70-E2C1-47CF-9FF1-0844C8868CA5@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307751C2311@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C280Dmbx01winnominum_" MIME-Version: 1.0 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ralph Droms , Lorenzo Colitti X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 12:42:06 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C280Dmbx01winnominum_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jun 2, 2013, at 11:26 PM, Owen DeLong > wrote: My point is that it should be up to the person running the home net (or oth= er end site) to decide what is better for their site and that we should not= be making the choice for them. So, to recap, RIR policies seem to allow ISPs to allocate /48s for clients.= Someone made the claim that semantic prefix bits are not likely to pass = muster with RIRs because they use too many bits. But ISPs seem to think t= hat /48s are bigger than necessary; some don't use semantic bits, but still= only give each customer a /56, which actually is a pretty useful allocatio= n. So the point where we started this argument was over the question of w= hether ISPs could in fact get allocations from RIRs big enough to support t= he use of semantic prefixes. My claim was that they could, because they c= an just use some bits out of the /48 and still have enough to give every cu= stomer a /56, which is widely held to be adequate. You have been debating the question of whether it's possible for sites to s= urvive on a mere /56, making the point that internal site address allocatio= n is necessarily inefficient. You've made no convincing argument that thi= s is true, and have failed to refute two different arguments I've made show= ing that it is not true. I personally have no position on semantic bits o= r /48 versus /56=97I'm work for neither an RIR nor an ISP, and have no pers= onal knowledge of the vicissitudes of life within such organizations. But= I think that the arguments that are being made here ought to be grounded i= n reality. If I have failed to help achieve that, I apologize. --_000_8D23D4052ABE7A4490E77B1A012B6307751C280Dmbx01winnominum_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jun 2, 2013, at 11:26 PM, Owen DeLong <owen@delong.com> wrote:
My point is that it should be up to the person running the home net (or oth= er end site) to decide what is better for their site and that we should not= be making the choice for them.

So, to recap, RIR policies seem to allow ISPs to allocate /48s for cli= ents.   Someone made the claim that semantic prefix bits are not likel= y to pass muster with RIRs because they use too many bits.   But ISPs = seem to think that /48s are bigger than necessary; some don't use semantic bits, but still only give each customer a /56, whi= ch actually is a pretty useful allocation.   So the point where we sta= rted this argument was over the question of whether ISPs could in fact get = allocations from RIRs big enough to support the use of semantic prefixes.   My claim was that they could, because= they can just use some bits out of the /48 and still have enough to give e= very customer a /56, which is widely held to be adequate.

You have been debating the question of whether it's possible for sites= to survive on a mere /56, making the point that internal site address allo= cation is necessarily inefficient.   You've made no convincing argumen= t that this is true, and have failed to refute two different arguments I've made showing that it is not true. &= nbsp; I personally have no position on semantic bits or /48 versus /56=97I'= m work for neither an RIR nor an ISP, and have no personal knowledge of the= vicissitudes of life within such organizations.   But I think that the arguments that are being made here ought to be= grounded in reality.   If I have failed to help achieve that, I apolo= gize.

--_000_8D23D4052ABE7A4490E77B1A012B6307751C280Dmbx01winnominum_-- From fgont@si6networks.com Mon Jun 3 06:30:45 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3408F21F915C for ; Mon, 3 Jun 2013 06:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRsgNjXS-BGQ for ; Mon, 3 Jun 2013 06:30:44 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 7489F21F8425 for ; Mon, 3 Jun 2013 06:30:43 -0700 (PDT) Received: from [2001:5c0:1400:a::a0f] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UjUq5-0001aX-L5; Mon, 03 Jun 2013 15:30:21 +0200 Message-ID: <51AC9A6B.8050705@si6networks.com> Date: Mon, 03 Jun 2013 15:30:19 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Alissa Cooper , "tom.petch" , Dave Thaler Subject: Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-09.txt References: <20130602233646.11112.39637.idtracker@ietfa.amsl.com> In-Reply-To: <20130602233646.11112.39637.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 13:30:45 -0000 Folks, This version of the I-D is meant to address feedback from Alissa Cooper, Dave Thaler, and Tom Petch. For the most part, these are the changes: * A new appendix has been added, detailing the types of attacks we want to mitigate. * I've added some text noting that an attacker has a variety of probing techniques, and that there are some that cannot be blocked/mitigated by the host itself. * Some text from the intro was moved to the appendix about RFC4941, such that the intro can focus on what it is meant to focus. I'd hope that, in the worst case scenario, we might need an additional iteration/revision... but this rev 8or the next) should be ready to ship. Thoughts? Thanks! Fernando On 06/03/2013 01:36 AM, 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 Maintenance Working Group of the IETF. > > Title : A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC) > Author(s) : Fernando Gont > Filename : draft-ietf-6man-stable-privacy-addresses-09.txt > Pages : 29 > Date : 2013-06-02 > > Abstract: > This document specifies a method for generating IPv6 Interface > Identifiers to be used with IPv6 Stateless Address Autoconfiguration > (SLAAC), such that addresses configured using this method are stable > within each subnet, but the Interface Identifier changes when hosts > move from one network to another. This method is meant to be an > alternative to generating Interface Identifiers based on hardware > address (e.g., using IEEE identifiers), such that the benefits of > stable addresses can be achieved without sacrificing the privacy of > users. The method specified in this document applies to all prefixes > a host may be employing, including link-local, global, and unique- > local addresses. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-stable-privacy-addresses-09 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From owen@delong.com Mon Jun 3 06:49:15 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9FC21F9712; Mon, 3 Jun 2013 06:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BgQRc50ZIhS; Mon, 3 Jun 2013 06:49:14 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A057E21F964C; Mon, 3 Jun 2013 06:49:14 -0700 (PDT) Received: from [192.168.6.83] (ip-64-134-24-48.public.wayport.net [64.134.24.48]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r53DkcK8008759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 Jun 2013 06:46:40 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r53DkcK8008759 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370267202; bh=lpklrkMPlvP9l9ZhIy2MZVTKiZs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=IL2rIzMRr6pn3ea+nAHyGCh9eTpib1hQ+4sQbPDQ3+x3Nkh7/EqUCrEVY4kg9OzIa FvkiOrsiaMPl37s6MlC9Cu1RBD9StMAHp01+m05c3P/Hs8wI0RbqZ8shbYHWbvN8dv y1uhYIwjwY7HS7LOo246xEMatH1Z0+RJBK3/7zCU= Content-Type: multipart/alternative; boundary="Apple-Mail=_A0907ED1-FB05-46D4-83BB-E1DF253B8743" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Owen DeLong In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> Date: Mon, 3 Jun 2013 08:46:38 -0500 Message-Id: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 03 Jun 2013 06:46:42 -0700 (PDT) Cc: Tim Chown , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ralph Droms , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 13:49:15 -0000 --Apple-Mail=_A0907ED1-FB05-46D4-83BB-E1DF253B8743 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 3, 2013, at 7:27 AM, Ted Lemon wrote: > On Jun 2, 2013, at 11:21 PM, Owen DeLong wrote: >>> Yes. A fine engineering solution for demonstration purposes, but = not a good solution for us to recommend for deployment in the long term. = Because it commits wide prefixes to sub-delegations, it wastes address = space profligately, and likely would require a /48 for a fairly trivial = subnetted homenet. >> You say that as if it would be a bad thing. >> I don't see a problem with it. >=20 > IIRC, what started this conversation was the claim that wasting bits = on semantic identifiers was bad because it wasted address space. If = you don't think wasting address space is a problem, why are we even = having this debate? >=20 I guess it boils down to the definition of waste. I believe that making bits available for greater flexibility in consumer = networking is a good use of bits. I believe that stealing bits from the consumer for purposes of allowing = the provider to overload the IP address with yet more unrelated meaning = (semantic identifiers) isn't a good idea even if it didn't involve = stealing the bits from consumers. Owen --Apple-Mail=_A0907ED1-FB05-46D4-83BB-E1DF253B8743 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jun 3, 2013, at 7:27 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Jun 2, 2013, at 11:21 PM, Owen DeLong <owen@delong.com> wrote:
Yes.   A fine engineering solution for demonstration purposes, but not a good solution for us to recommend for deployment in the long term.   Because it commits wide prefixes to sub-delegations, it wastes address space profligately, and likely would require a /48 for a fairly trivial subnetted homenet.
You say that as if it would be a bad thing.
I don't see a problem with it.

IIRC, what started this conversation was the claim that wasting bits on semantic identifiers was bad because it wasted address space.   If you don't think wasting address space is a problem, why are we even having this debate?


I guess it boils down to the definition of waste.

I believe that making bits available for greater flexibility in consumer networking is a good use of bits.

I believe that stealing bits from the consumer for purposes of allowing the provider to overload the IP address with yet more unrelated meaning (semantic identifiers) isn't a good idea even if it didn't involve stealing the bits from consumers.

Owen

--Apple-Mail=_A0907ED1-FB05-46D4-83BB-E1DF253B8743-- From owen@delong.com Mon Jun 3 06:54:10 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA4111E80A5; Mon, 3 Jun 2013 06:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeiAOoVM7YPH; Mon, 3 Jun 2013 06:54:09 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7D04F11E80A3; Mon, 3 Jun 2013 06:54:09 -0700 (PDT) Received: from [192.168.6.83] (ip-64-134-24-48.public.wayport.net [64.134.24.48]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r53DmqZG008841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 Jun 2013 06:48:53 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r53DmqZG008841 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370267335; bh=ydjruQh/Xa9Vv9eSXTV+6HrARjA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=IQJ8oTp+Tbw3fHwc6Yk/aebmWlqf+4A+B4fBO8KTlvPWgJCsfFgkCVB5UMEhmeyzM qUNaWXhVUYp7wK7t1r3dAHrjz6uocSsSIAL9Zk3DLweCZf1kjiBZPzgNM2Xdb+vdvc 7RlYgD5EeEx10D1wg9ZqbntW0LdxiNtTsF0mPcuE= Content-Type: multipart/alternative; boundary="Apple-Mail=_C195B3DC-6AA5-4113-A532-2F1AFC4B2EC6" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Owen DeLong In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C2736@mbx-01.win.nominum.com> Date: Mon, 3 Jun 2013 08:48:52 -0500 Message-Id: <724728FA-35FE-4699-BB06-CD9E83F97485@delong.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1E59@mbx-01.win.nominum.com> <4A767C76-97DA-4A7C-9FED-C2AA9EE22D9E@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C2736@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 03 Jun 2013 06:48:55 -0700 (PDT) Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 13:54:10 -0000 --Apple-Mail=_C195B3DC-6AA5-4113-A532-2F1AFC4B2EC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 3, 2013, at 7:32 AM, Ted Lemon wrote: > On Jun 2, 2013, at 11:24 PM, Owen DeLong wrote: >>> No, there is no use case where this is better than doing the = delegations from the router that received the initial delegation (since = we're apparently just arguing by vigorous assertion). >> Is your opinion. I disagree with your opinion and have a different = opinion. It is my opinion that there are use cases. >=20 > You can't have an opinion about whether something exists. Either it = exists, or it doesn't. If it exists, you can show that it exists by = describing it. You can have an opinion about whether something *might* = exist, but that's not the same thing. And of course you didn't state = it that way, because it's a really weak argument. Sure you can. Since neither of us knows whether it exists or not, we = both have opinions. Lots of people are of the opinion that there is extra terrestrial life. = Lots of people are of the opinion that it does not exist. The fact that the former cannot prove that it exists does not prove the = case for the latter. Lack of proof of existence is not the same thing as = proof of non-existence. Owen --Apple-Mail=_C195B3DC-6AA5-4113-A532-2F1AFC4B2EC6 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=windows-1252
On Jun 3, 2013, at 7:32 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Jun 2, 2013, at 11:24 PM, Owen DeLong <owen@delong.com> wrote:
No, there is no use case where this is better than doing the delegations from the router that received the initial delegation (since we're apparently just arguing by vigorous assertion).
Is your opinion. I disagree with your opinion and have a different opinion. It is my opinion that there are use cases.

You can't have an opinion about whether something exists.   Either it exists, or it doesn't.   If it exists, you can show that it exists by describing it.   You can have an opinion about whether something *might* exist, but that's not the same thing.   And of course you didn't state it that way, because it's a really weak argument.

Sure you can. Since neither of us knows whether it exists or not, we both have opinions.

Lots of people are of the opinion that there is extra terrestrial life. Lots of people are of the opinion that it does not exist.

The fact that the former cannot prove that it exists does not prove the case for the latter. Lack of proof of existence is not the same thing as proof of non-existence.

Owen

--Apple-Mail=_C195B3DC-6AA5-4113-A532-2F1AFC4B2EC6-- From jmh@joelhalpern.com Mon Jun 3 07:07:06 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971D121F96FE; Mon, 3 Jun 2013 07:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLhNFaFNritR; Mon, 3 Jun 2013 07:07:00 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id CC50A21F96ED; Mon, 3 Jun 2013 07:07:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 5BA911C01A1; Mon, 3 Jun 2013 07:07:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-135-127.clppva.east.verizon.net [70.106.135.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 551511C0907; Mon, 3 Jun 2013 07:06:57 -0700 (PDT) Message-ID: <51ACA2F8.7060601@joelhalpern.com> Date: Mon, 03 Jun 2013 10:06:48 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Sheng Jiang Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 14:07:06 -0000 If I am reading this correctly, in the end this is riven by the fact that existing boxes can easily filter on addresses (although it will take a lot of filters), but can not apply ACLs to DSCPs or extension headers? It seems like what we need is a draft that clearly explains why trying to shoehorn this information into the address is a bad idea, rather than trying to defend the choice. (Your emails seem to vary between the two stances.) Yours, Joel On 6/3/2013 3:57 AM, Sheng Jiang wrote: > I have to say the hierarchical assignment is a such great way to waste > address space or prefix bit. I cannot real see much benefits or use > cases of it. Why may home site 3 subordinate routers? How many subnets > or devices may a /48 prefix serve in this model? > Cheers, > Sheng > ... From roland.bless@kit.edu Mon Jun 3 07:09:48 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B987221F994E; Mon, 3 Jun 2013 07:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqGais8U6Zj8; Mon, 3 Jun 2013 07:09:44 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id BF65821F9922; Mon, 3 Jun 2013 07:09:42 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 id 1UjVS3-0006Vi-KA; Mon, 03 Jun 2013 16:09:41 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 7CADEA80166; Mon, 3 Jun 2013 16:09:35 +0200 (CEST) Message-ID: <51ACA39F.2000009@kit.edu> Date: Mon, 03 Jun 2013 16:09:35 +0200 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ray Hunter Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <51A71ACA.3000608@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> <51A733E1.7040008@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99A07@nkgeml512-mbx.china.huawei.com> <51A841B5.3010805@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99CF4@nkgeml512-mbx.china.huawei.com> <6B838546-4FB3-4EDB-9F84-D8CF0AF3080D@millnert.se> <51A87174.3080204@globis.net> In-Reply-To: <51A87174.3080204@globis.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1370268581.472106000 Cc: Martin Millnert , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 14:09:48 -0000 Hi, On 31.05.2013 11:46, Ray Hunter wrote: > But why are people coming up with these schemes for encoding semantics > in the address prefixes in the first place? That's what I'd like to > understand first and foremost: what lack of functionality is > motivating/forcing these people to adopt such schemes? I'm not sure. Some impressions from the draft I got when I browsed over it: - An address is something that the provider controls, therefore it may have more trust in the address information, esp. if source address filtering is done properly. The draft seems to promote the idea in favor of others like DSCP marking (which is untrusted up to the boundary node anyway). - Overloading semantics is IMHO a bad thing as it complicates things as well, e.g., encoding application-level semantics into the network layer is generally a bad idea (see end-to-end argument - putting appl.-level knowledge into the network implies inflexibility and increased complexity). Moreover, choosing the right address/network prefix must not require network topology knowledge in the application (remembering the site-locals discussion several years ago). - one useful scenario, however, may be the use of different security zones. We actually proposed this in an internal network of a vehicle - the particular advantage is here that you can easily perform security policy enforcement with firewalls and address filtering rules. However, you also may have a topological/logical subnet structure in addition to the security zones, leading to a subnet matrix structure. In addition to that you may have different QoS requirements for traffic within a subnet, so DSCP marking is also orthogonal to the "address" semantics - you should not encode them into the prefix as well. - dividing a network into different subnets according to different semantics is nothing unusual and is widely used today, mostly motivated by either topological aspects, logical user/device groups, and/or trust/security domains. However, semantics b., d. and e. of http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03#section-4.3 (applications, traffic identity types, quality requirements) seem to be bad reasons for "encoding" them into prefixes, IMHO. Thus, if the document is adopted somehow, it should rather point out the potential pitfalls. Currently, as other already said, it reads as it would be a preferred operational method... Regards, Roland From Ted.Lemon@nominum.com Mon Jun 3 07:22:25 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BADED21F99A5; Mon, 3 Jun 2013 07:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ew7MYQFLR+0z; Mon, 3 Jun 2013 07:22:19 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id BB7D021F90EF; Mon, 3 Jun 2013 07:22:18 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUaymlWfRvyi5Qlutjo+rZ1lhBT2oSlYN@postini.com; Mon, 03 Jun 2013 07:22:18 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 01FA21B81A9; Mon, 3 Jun 2013 07:22:12 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E74B7190052; Mon, 3 Jun 2013 07:22:11 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 07:22:05 -0700 From: Ted Lemon To: Owen DeLong Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAFFqgIAAA0MAgAAlngCAAERTAIAAmIuAgAAWAQCAAAnmAA== Date: Mon, 3 Jun 2013 14:22:04 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C2D69@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C2D69mbx01winnominum_" MIME-Version: 1.0 Cc: Tim Chown , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ralph Droms , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 14:22:25 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C2D69mbx01winnominum_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jun 3, 2013, at 9:46 AM, Owen DeLong > wrote: I believe that making bits available for greater flexibility in consumer ne= tworking is a good use of bits. I believe that stealing bits from the consumer for purposes of allowing the= provider to overload the IP address with yet more unrelated meaning (seman= tic identifiers) isn't a good idea even if it didn't involve stealing the b= its from consumers. But these arguments are mutually contradictory, since the bits are in fact = making use of the added flexibility IPv6 gives to consumer networking. Wh= at you seem to be saying is that we need to preserve the ability of end-use= rs to spend bits like water by stopping ISPs from spending them. Being an= end-user, I have a lot of sympathy for your position, but I don't think th= is is something on which the IETF is likely to achieve a strong consensus, = and that's okay. Whether you like semantic prefixes or not, they are some= thing that ISPs are experimenting with, for reasons they think are valid. = What we should be talking about is not whether they can do these experimen= ts, but why they are doing them. --_000_8D23D4052ABE7A4490E77B1A012B6307751C2D69mbx01winnominum_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jun 3, 2013, at 9:46 AM, Owen DeLong <owen@delong.com> wrote:
I believe that making bits available for greater flexibility in consumer ne= tworking is a good use of bits.

I believe that stealing bits from the consumer for purposes of allowing the= provider to overload the IP address with yet more unrelated meaning (seman= tic identifiers) isn't a good idea even if it didn't involve stealing the b= its from consumers.

But these arguments are mutually contradictory, since the bits are in = fact making use of the added flexibility IPv6 gives to consumer networking.=   What you seem to be saying is that we need to preserve the ability = of end-users to spend bits like water by stopping ISPs from spending them.   Being an end-user, I have a lo= t of sympathy for your position, but I don't think this is something on whi= ch the IETF is likely to achieve a strong consensus, and that's okay.  = ; Whether you like semantic prefixes or not, they are something that ISPs are experimenting with, for reasons they thin= k are valid.   What we should be talking about is not whether they can= do these experiments, but why they are doing them.

--_000_8D23D4052ABE7A4490E77B1A012B6307751C2D69mbx01winnominum_-- From owen@delong.com Mon Jun 3 07:39:05 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB70D21F99E7; Mon, 3 Jun 2013 07:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HV5yrHUhkbfO; Mon, 3 Jun 2013 07:39:04 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B763121F99E4; Mon, 3 Jun 2013 07:39:04 -0700 (PDT) Received: from [172.20.10.2] (156.sub-70-195-195.myvzw.com [70.195.195.156]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r53Ea4N1010707 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 Jun 2013 07:36:06 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r53Ea4N1010707 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370270167; bh=eVLFZNZP1NHsMV+iVEWjRmg6rI4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=EEAmb1CqMCo+QOVv0AZ/Ss81uMNPJ9vy8ss5LW2Me6qBEpin04UUAQJ2F6/IgVY4c HHmBbVv5GVFbYvrquHUsbWkM2yZbX7h7Z9UeCfezCgDwghCpAyk8j3TP/LjiZzp8S5 7VST3Jj+w0XhbHVBs1lXrBoczNCvVVM8lNmUAzf0= Content-Type: multipart/alternative; boundary="Apple-Mail=_587FEFC0-9512-4B7A-A554-9246C235DC18" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Owen DeLong In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C2D69@mbx-01.win.nominum.com> Date: Mon, 3 Jun 2013 09:36:04 -0500 Message-Id: <7767FF5D-194E-445A-A890-05A3E4C7CCC1@delong.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C2D69@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 03 Jun 2013 07:36:07 -0700 (PDT) Cc: Tim Chown , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ralph Droms , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 14:39:06 -0000 --Apple-Mail=_587FEFC0-9512-4B7A-A554-9246C235DC18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 3, 2013, at 9:22 AM, Ted Lemon wrote: > On Jun 3, 2013, at 9:46 AM, Owen DeLong wrote: >> I believe that making bits available for greater flexibility in = consumer networking is a good use of bits. >>=20 >> I believe that stealing bits from the consumer for purposes of = allowing the provider to overload the IP address with yet more unrelated = meaning (semantic identifiers) isn't a good idea even if it didn't = involve stealing the bits from consumers. >=20 > But these arguments are mutually contradictory, since the bits are in = fact making use of the added flexibility IPv6 gives to consumer = networking. What you seem to be saying is that we need to preserve the = ability of end-users to spend bits like water by stopping ISPs from = spending them. Being an end-user, I have a lot of sympathy for your = position, but I don't think this is something on which the IETF is = likely to achieve a strong consensus, and that's okay. Whether you = like semantic prefixes or not, they are something that ISPs are = experimenting with, for reasons they think are valid. What we should = be talking about is not whether they can do these experiments, but why = they are doing them. >=20 No, they are not. They are stealing from the consumer's flexibility to = provide (questionable) functionality to the provider. I am not saying that consumers should be able to spend bits like water. = I'm saying that consumers should get their intended 16 bits of = flexibility. No more, no less. If you said consumers should get /44s per = end site because they need additional flexibility, I'd be asking you to = prove use cases. But the original protocol design intended 16 bits of = flexibility and the address size was calculated to include that. As to what we should be talking about, we should, indeed be talking both = about why providers are doing these experiments and also why this type = of overloading of unrelated meaning onto address bits is an inherently = bad idea. Fortunately, we are talking about both of those things. Owen --Apple-Mail=_587FEFC0-9512-4B7A-A554-9246C235DC18 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jun 3, 2013, at 9:22 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Jun 3, 2013, at 9:46 AM, Owen DeLong <owen@delong.com> wrote:
I believe that making bits available for greater flexibility in consumer networking is a good use of bits.

I believe that stealing bits from the consumer for purposes of allowing the provider to overload the IP address with yet more unrelated meaning (semantic identifiers) isn't a good idea even if it didn't involve stealing the bits from consumers.

But these arguments are mutually contradictory, since the bits are in fact making use of the added flexibility IPv6 gives to consumer networking.   What you seem to be saying is that we need to preserve the ability of end-users to spend bits like water by stopping ISPs from spending them.   Being an end-user, I have a lot of sympathy for your position, but I don't think this is something on which the IETF is likely to achieve a strong consensus, and that's okay.   Whether you like semantic prefixes or not, they are something that ISPs are experimenting with, for reasons they think are valid.   What we should be talking about is not whether they can do these experiments, but why they are doing them.


No, they are not. They are stealing from the consumer's flexibility to provide (questionable) functionality to the provider.

I am not saying that consumers should be able to spend bits like water. I'm saying that consumers should get their intended 16 bits of flexibility. No more, no less. If you said consumers should get /44s per end site because they need additional flexibility, I'd be asking you to prove use cases. But the original protocol design intended 16 bits of flexibility and the address size was calculated to include that.

As to what we should be talking about, we should, indeed be talking both about why providers are doing these experiments and also why this type of overloading of unrelated meaning onto address bits is an inherently bad idea.

Fortunately, we are talking about both of those things.

Owen

--Apple-Mail=_587FEFC0-9512-4B7A-A554-9246C235DC18-- From ales.vizdal@t-mobile.cz Mon Jun 3 07:59:21 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFA421F99C5; Mon, 3 Jun 2013 07:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lh041a0wgkOE; Mon, 3 Jun 2013 07:59:16 -0700 (PDT) Received: from rztmailhub.t-mobile.cz (rztmailhub.t-mobile.cz [93.153.104.86]) by ietfa.amsl.com (Postfix) with ESMTP id 05D4B21F99D5; Mon, 3 Jun 2013 07:59:16 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by rztmailhub.t-mobile.cz (Postfix) with ESMTP id A9D9A2E0859; Mon, 3 Jun 2013 16:59:11 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Mon, 3 Jun 2013 16:59:14 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "Joel M. Halpern" , Sheng Jiang Date: Mon, 3 Jun 2013 16:59:13 +0200 Subject: RE: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: Ac5gY7e/ThobHM67QP6LD5MeCr1FeAAAdTxQ Message-ID: <1808340F7EC362469DDFFB112B37E2FCC895DBD258@SRVHKE02.rdm.cz> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <51ACA2F8.7060601@joelhalpern.com> In-Reply-To: <51ACA2F8.7060601@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 14:59:21 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Joel M. > Halpern > Sent: Monday, June 03, 2013 4:07 PM > To: Sheng Jiang > Cc: ; draft-jiang-v6ops-semantic-prefix@tools.ietf.org; i= pv6@ietf.org > Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jian= g-v6ops- > semantic-prefix-03 >=20 > If I am reading this correctly, in the end this is riven by the fact that= existing boxes > can easily filter on addresses (although it will take a lot of filters), = but can not apply > ACLs to DSCPs or extension headers? The current boxes can do both ACL filtering as well as DSCP mangling, but a= s mentioned earlier the DSCP bits cannot be trusted, so a markdown/re-marking is requir= ed potentially involving DPI. Maintaining ACLs is also time consuming. Semantics can help to put the burden on the originator, so he has to pick t= he right address/prefix according to the semantics to access a service. The edge box= could use=20 an ACL (potentially network wide) to match certain bits only to allow the = packet to reach the service as well as to apply the defined QoS policy. > It seems like what we need is a draft that clearly explains why trying to= shoehorn this > information into the address is a bad idea, rather than trying to defend = the choice. > (Your emails seem to vary between the two stances.) >=20 > Yours, > Joel >=20 > On 6/3/2013 3:57 AM, Sheng Jiang wrote: > > I have to say the hierarchical assignment is a such great way to waste > > address space or prefix bit. I cannot real see much benefits or use > > cases of it. Why may home site 3 subordinate routers? How many subnets > > or devices may a /48 prefix serve in this model? > > Cheers, > > Sheng Cheers, Ales From shengjiang@gmail.com Mon Jun 3 00:28:02 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1754C21F9360; Mon, 3 Jun 2013 00:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvhQ-8F7KV5A; Mon, 3 Jun 2013 00:28:01 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 800E621F935A; Mon, 3 Jun 2013 00:28:00 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id er20so1014067lab.31 for ; Mon, 03 Jun 2013 00:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QDkeyvpky0n3pA7Zfq4ZLSPt5RZxwmmHlj6ikr1bmqg=; b=IQRNF2LUoxq0BR5D3aZQsCupsSI6/gHlCoxAbRs8GwqyQ/WsIsowm9LxijepWR3kht l4NuwfjnjEi68Y6qVkaYQLSZCkd2QrsulFURL+hKrZjM6UYcc/vGouMvjPIlH8HnH6nw l4Fd1IOeox7kaZK8LEQB5jWjlnnR7CEg/qLu+fTucBASU/UXlN2PoOlCgKTN8WHhnU3N UeZx8k/IVMjWzUAfFb0vjnN+ZXKr+HHYYKjecLVGVl2bws4NpXWfpRyEbnhunDTrxbYq pC+yCPZ7loiGiawM4tqbUjPMRDH47eDEHqIDYXncuT7s4hP6EbeyBlsY5VebRH9fw4KX dZcg== MIME-Version: 1.0 X-Received: by 10.152.116.7 with SMTP id js7mr10389977lab.7.1370244479377; Mon, 03 Jun 2013 00:27:59 -0700 (PDT) Received: by 10.112.67.166 with HTTP; Mon, 3 Jun 2013 00:27:59 -0700 (PDT) In-Reply-To: <708D821F-0EA0-44EE-AA5E-6321C7E73910@castlepoint.net> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <51A71ACA.3000608@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> <51A733E1.7040008@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99A07@nkgeml512-mbx.china.huawei.com> <51A841B5.3010805@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99CF4@nkgeml512-mbx.china.huawei.com> <6B838546-4FB3-4EDB-9F84-D8CF0AF3080D@millnert.se> <51A87174.3080204@globis.net> <708D821F-0EA0-44EE-AA5E-6321C7E73910@castlepoint.net> Date: Mon, 3 Jun 2013 15:27:59 +0800 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Sheng Jiang To: Shane Amante Content-Type: multipart/alternative; boundary=001a11c2672a72e5fb04de3ae750 X-Mailman-Approved-At: Mon, 03 Jun 2013 08:11:56 -0700 Cc: Ray Hunter , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 07:28:02 -0000 --001a11c2672a72e5fb04de3ae750 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Shane, Actually, we do assume the SP deploys unicast filters to drop incoming packets with illegitimate source IP address/prefix. After then, the packets become trusted. It is the filter who makes sure the prefix right. The filter should link back to other states of the user, like user authentication, etc, in order to match the packet to its properties and check whether it is mapped to right semantics or not. Cheers, Sheng On 1 June 2013 11:20, Shane Amante wrote: > Hi Sheng, Ray, > > On May 31, 2013, at 3:46 AM, Ray Hunter wrote: > [--snip--] > > But why are people coming up with these schemes for encoding semantics > > in the address prefixes in the first place? That's what I'd like to > > understand first and foremost: what lack of functionality is > > motivating/forcing these people to adopt such schemes? > > +1. > > In one part of the draft, Section 2.1, it appears to suggest that packets > coming in to the border of an SP boundary are "untrusted", therefore > existing packet header fields (e.g.: IPv6 TC) cannot be trusted. If > incoming packets are untrusted: > - why doesn't the SP deploy unicast RPF to drop incoming packets with an > illegitimate source IP address/prefix? > - more importantly, how is an SP able to _trust_ and somehow enforce that > the prefixes that it is handing out (dynamically via DHCP?) are being > properly assigned according the policies governing the mapping of semanti= c > prefix <-> user-type/application/security-domain/etc.? > > -shane > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 Sheng Jiang =E8=92=8B=E8=83=9C --001a11c2672a72e5fb04de3ae750 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Shane,
=C2=A0
Actually, we do= =C2=A0assume the SP deploys unicast=C2=A0filters to drop incoming packets w= ith illegitimate source IP address/prefix. After then, the packets become t= rusted.
=C2=A0
It is the filter who makes sure the prefix right. The filt= er should link back to other states of the user, like user authentication, = etc, in order to match the packet to its properties and check whether it is= mapped to right semantics or not.
=C2=A0
Cheers,
=C2=A0
Sheng
<= div class=3D"gmail_extra">

On 1 June 2013= 11:20, Shane Amante <shane@castlepoint.net> wrote:
Hi Sheng, Ray,

On May 31, 2013, at 3:46 AM, Ray Hunter <v6ops@globis.net> wrote:
[--snip--]
> But why are people coming up with these schemes for = encoding semantics
> in the address prefixes in the first place? That's what I'd li= ke to
> understand first and foremost: what lack of functionality is
> motivating/forcing these people to adopt such schemes?

+1.

In one part of the draft, Section 2.1, it appears to suggest that packets c= oming in to the border of an SP boundary are "untrusted", therefo= re existing packet header fields (e.g.: IPv6 TC) cannot be trusted. =C2=A0I= f incoming packets are untrusted:
- why doesn't the SP deploy unicast RPF to drop incoming packets with a= n illegitimate source IP address/prefix?
- more importantly, how is an SP able to _trust_ and somehow enforce that t= he prefixes that it is handing out (dynamically via DHCP?) are being proper= ly assigned according the policies governing the mapping of semantic prefix= <-> user-type/application/security-domain/etc.?

-shane
_____________________= __________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops



--
Sheng Jiang= =E8=92=8B=E8=83=9C --001a11c2672a72e5fb04de3ae750-- From shengjiang@gmail.com Mon Jun 3 00:57:40 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FC821F8FE8; Mon, 3 Jun 2013 00:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rh1b14UxY8Qv; Mon, 3 Jun 2013 00:57:34 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id 78CC821F8EAE; Mon, 3 Jun 2013 00:57:33 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id w10so3412356lbi.23 for ; Mon, 03 Jun 2013 00:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y8ZeuvcwZoEGwOVIsu+lBd9F2fsSoEShv1S1QLmN1IQ=; b=XMxE1KzmeNecLuiNBDz0gIWg8VO3QxakV0RqEP9q+aqEBz0aQzvXIdmBnMxDiRlNCM 3MDmd3gweMygAzxffDmgnTDBb2rYftAMJyOpX6AQvYKQ+iq3P67P4AvAqe7zpW47ci/W mV4TSTBxNUSSh9daWWShqadrsc6bhLcTSRvu0oOy/0RZCZDb+I16dGEJ2Xm63iM9RpF/ DvcRW6xPV+6AEdHLKuvSrIrPCBImdk4PainjWHyW9D7uQ1p5NFUf9iQ7dmcEmKxAo/9Q riG8+pNko689aJNBb38KwIznVR/fN+DeNIsI+A+ucErAJlK6735g+9k82DMJTp3dCh6T Cy2A== MIME-Version: 1.0 X-Received: by 10.152.27.194 with SMTP id v2mr10367259lag.22.1370246252369; Mon, 03 Jun 2013 00:57:32 -0700 (PDT) Received: by 10.112.67.166 with HTTP; Mon, 3 Jun 2013 00:57:32 -0700 (PDT) In-Reply-To: <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> Date: Mon, 3 Jun 2013 15:57:32 +0800 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Sheng Jiang To: Owen DeLong Content-Type: multipart/alternative; boundary=089e0158c2ac209ca504de3b5165 X-Mailman-Approved-At: Mon, 03 Jun 2013 08:11:56 -0700 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 07:57:40 -0000 --089e0158c2ac209ca504de3b5165 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have to say the hierarchical assignment is a such great way to waste address space or prefix bit. I cannot real see much benefits or use cases of it. Why may home site 3 subordinate routers? How many subnets or devices may a /48 prefix serve in this model? Cheers, Sheng On 3 June 2013 00:39, Owen DeLong wrote: > > On Jun 2, 2013, at 11:10 AM, Ted Lemon wrote: > > On Jun 2, 2013, at 11:59 AM, Owen DeLong wrote: > > You are assuming that all of the subordinate routers will act as DHCP > relays rather than doing PD. > That is certainly one possible solution, but, not necessarily ideal in > all cases. > In cases where the subordinate routers should receive delegations and > perform their own PD for their subordinate routers, having a larger bit > field can be useful for greater flexibility. > > > No, there is no use case where this is better than doing the delegations > from the router that received the initial delegation (since we're > apparently just arguing by vigorous assertion). > > > We can agree to disagree. > > One example that comes to mind is if I want greater control and I want my > most capable router with the greatest configuration flexibility to be in > charge of the addressing scheme, but, it is not the router that interface= s > with my ISP. > > Thus, providing 16 bits to the end site is, IMHO, worth while. > > > And hence, this conclusion is not supported. > > You are welcome, of course, to contradict me by stating such a use case, > but bear in mind that when you delegate prefixes for further > sub-delegation, topology changes in the homenet become impossible. So > your use case for doing this would have to enable some pretty awesome > functionality before it would be worth doing. Also make sure you think > about how it would work during a renumbering event, with sub-delegations > and sub-sub-delegations all having different lifetimes. > > > Actually, the need for the larger bit field is precisely to allow topolog= y > changes in said deployment scenario. If the top level router hands out, f= or > example, /50s to its 3 subordinate routers, the subordinate routers can > support a number of different topologies without requiring any changes at > the top-level router. Additionally, a fourth subordinate router can be > added with its own underlying topology supported. > > OTOH, if there are more than 3 subordinate routers, the top level router > can delegate /51s. True, this would complicate the change from 3 to more > than 3 subordinate routers at the top level somewhat. > > (I've got nothing against delegating /48's to the home, but the reason > we did that was to maintain flexibility, not because we really expect a > typical homenet to have 65,536 subnets. At least for most reasonable > values of "we.") > > > You just said exactly what I said to begin with=E2=80=A6 It's to have a b= it field > wide enough to allow flexibility in the automation of the hierarchical > assignments, not to create 65K subnets. I never asserted it was because w= e > needed 65K subnets. > > Owen > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --=20 Sheng Jiang =E8=92=8B=E8=83=9C --089e0158c2ac209ca504de3b5165 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have to say the hierarchical assignment is a such g= reat way to waste address space or prefix bit. I cannot real see much benef= its or use cases of it. Why may home site 3 subordinate routers? How many s= ubnets or devices may a /48 prefix serve in this model?
=C2=A0
Cheers,
=C2=A0
Sheng
<= div class=3D"gmail_extra">

On 3 June 2013= 00:39, Owen DeLong <owen@delong.com> wrote:

O= n Jun 2, 2013, at 11:10 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Jun 2, 2013, at 11:59 AM, Owen DeLong <owen@delong.com>=C2=A0wrote:
You are assuming that all of the subordinate routers will act as DHCP relay= s rather than doing PD.
That is certainly one possible solution, but, not necessarily ideal in all = cases.
In cases where the subordinate routers should receive delegations and perfo= rm their own PD for their subordinate routers, having a larger bit field ca= n be useful for greater flexibility.

No, there is no use case where this is better than doing the delegations fr= om the router that received the initial delegation (since we're apparen= tly just arguing by vigorous assertion).


We can agree to disa= gree.=C2=A0

One example that comes to mind is if I= want greater control and I want my most capable router with the greatest c= onfiguration flexibility to be in charge of the addressing scheme, but, it = is not the router that interfaces with my ISP.

=
Thus, providing 16 bits to the end site is, IMHO, worth while.

And hence, this conclusion is not supported.

You are welcome, of course, to contradict me by stating such a use cas= e, but bear in mind that when you delegate prefixes for further sub-delegat= ion, topology changes in the homenet become impossible. =C2=A0 So your use = case for doing this would have to enable some pretty awesome functionality before it would be worth doing. =C2=A0 A= lso make sure you think about how it would work during a renumbering event,= with sub-delegations and sub-sub-delegations all having different lifetime= s.


Actually, the need f= or the larger bit field is precisely to allow topology changes in said depl= oyment scenario. If the top level router hands out, for example, /50s to it= s 3 subordinate routers, the subordinate routers can support a number of di= fferent topologies without requiring any changes at the top-level router. A= dditionally, a fourth subordinate router can be added with its own underlyi= ng topology supported.

OTOH, if there are more than 3 subordinate routers, the= top level router can delegate /51s. True, this would complicate the change= from 3 to more than 3 subordinate routers at the top level somewhat.

=
(I've got nothing against delegating /48's to the home, but th= e reason we did that was to maintain flexibility, not because we really exp= ect a typical homenet to have 65,536 subnets. =C2=A0 At least for most reas= onable values of "we.")


You just said exactly what I said to begi= n with=E2=80=A6 It's to have a bit field wide enough to allow flexibili= ty in the automation of the hierarchical assignments, not to create 65K sub= nets. I never asserted it was because we needed 65K subnets.

Owen


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




--
Sheng Jiang =E8=92= =8B=E8=83=9C --089e0158c2ac209ca504de3b5165-- From bmanning@isi.edu Mon Jun 3 08:45:34 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCE221F96E9; Mon, 3 Jun 2013 08:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vP2gtHDgOsMc; Mon, 3 Jun 2013 08:45:21 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 57F0121F9007; Mon, 3 Jun 2013 08:45:18 -0700 (PDT) Received: from [128.9.184.118] ([128.9.184.118]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r53Fin8N020557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 Jun 2013 08:44:50 -0700 (PDT) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: manning bill In-Reply-To: <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> Date: Mon, 3 Jun 2013 08:44:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <51ABC! C79.4090401@gmail.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <5! 1 ABD7B8.2010006@gmail.com> <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> To: Sander Steffann X-Mailer: Apple Mail (2.1283) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu Cc: "v6ops@ietf.org WG" , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 15:45:35 -0000 On 2June2013Sunday, at 16:47, Sander Steffann wrote: > On 03/06/2013 11:06, manning bill wrote: >> /48's are a horrible policy - one should only advertise what one is = actually using. >=20 > Now *that* would cause a nice fragmented DFZ... > Sander >=20 I'm going to inject a route. One route. why do you care if its a /9, = a /28, a /47, or a /121? Its -one- route. That one route covers everything I'm going to use=85 and nothing I'm = not. Is there a credible reason you want to be the vector of DDoS attacks, by = announcing dark space (by proxy aggregation)? Is that an operational liability you are willing to assume, just so you = can have "unfragmented" DFZ space? /bill= From sander@steffann.nl Mon Jun 3 08:51:22 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1400D21F9622; Mon, 3 Jun 2013 08:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.028 X-Spam-Level: X-Spam-Status: No, score=-1.028 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFF+xXoDI4Ca; Mon, 3 Jun 2013 08:51:16 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 66C7421F93B9; Mon, 3 Jun 2013 08:51:14 -0700 (PDT) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id C71D72033; Mon, 3 Jun 2013 17:51:13 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Sander Steffann In-Reply-To: <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> Date: Mon, 3 Jun 2013 17:51:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <51ABC! C79.4090401@gmail.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <5! 1 ABD7B8.2010006@gmail.com> <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> To: manning bill X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org WG" , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 15:51:22 -0000 > On 2June2013Sunday, at 16:47, Sander Steffann wrote: >=20 >> On 03/06/2013 11:06, manning bill wrote: >>> /48's are a horrible policy - one should only advertise what one is = actually using. >>=20 >> Now *that* would cause a nice fragmented DFZ... >> Sander >=20 > I'm going to inject a route. One route. why do you care if its a = /9, a /28, a /47, or a /121? Its -one- route. > That one route covers everything I'm going to use=85 and nothing I'm = not. That is very optimistic. If I'm using 11 /64s in my networks then I'll = at least have to announce 3 routes (/67, /65, /64), otherwise I'll = announcing more space than I'm actually using... - Sander From bmanning@isi.edu Mon Jun 3 09:12:32 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3665D21F9631; Mon, 3 Jun 2013 09:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 044miT65140P; Mon, 3 Jun 2013 09:12:26 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0D47B21F9630; Mon, 3 Jun 2013 09:12:26 -0700 (PDT) Received: from [128.9.184.118] ([128.9.184.118]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r53GBh0X025883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 Jun 2013 09:11:44 -0700 (PDT) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: manning bill In-Reply-To: Date: Mon, 3 Jun 2013 09:11:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <51ABC! C79.4090401@gmail.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <5! ! 1 ABD7B8.2010006@gmail.com> <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> To: Sander Steffann X-Mailer: Apple Mail (2.1283) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu Cc: "v6ops@ietf.org WG" , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 16:12:32 -0000 On 3June2013Monday, at 8:51, Sander Steffann wrote: >> On 2June2013Sunday, at 16:47, Sander Steffann wrote: >>=20 >>> On 03/06/2013 11:06, manning bill wrote: >>>> /48's are a horrible policy - one should only advertise what one is = actually using. >>>=20 >>> Now *that* would cause a nice fragmented DFZ... >>> Sander >>=20 >> I'm going to inject a route. One route. why do you care if its a = /9, a /28, a /47, or a /121? Its -one- route. >> That one route covers everything I'm going to use=85 and nothing I'm = not. >=20 > That is very optimistic. If I'm using 11 /64s in my networks then I'll = at least have to announce 3 routes (/67, /65, /64), otherwise I'll = announcing more space than I'm actually using... >=20 > - Sander >=20 Impressive - you have eleven networks, each with 4294311936x10 = to the 32nd number of nodes? My goodness thats a lot of nodes. Bigger = than the Internet, larger than the projected IoT=85.. And every single one of those addresses = is used? I'd dearly love to see your technical deployment plan for = such a huge network. Is it on file with RIPE? Or perhaps you are really only using a single digits of IPv6 = address in that range of trillions of actual addresses? And you won't = mind if I forge source addresses into your darkspace, just so I can hide my tracks? Thanks ever so. Pragmatically, much of the IPv6 protocol/application development = has ignored half the 128bit space and treats IPv6 as a 64bit address = platform. =20 =09 /bill= From albert.e.manfredi@boeing.com Mon Jun 3 12:23:16 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98A521E8063; Mon, 3 Jun 2013 12:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzCjuykPYEmQ; Mon, 3 Jun 2013 12:23:01 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9FB11E80D9; Mon, 3 Jun 2013 12:17:13 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r53JHDUE025510; Mon, 3 Jun 2013 12:17:13 -0700 Received: from XCH-PHX-507.sw.nos.boeing.com (xch-phx-507.sw.nos.boeing.com [137.136.239.65]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r53JHCwt025488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 3 Jun 2013 12:17:12 -0700 Received: from XCH-BLV-512.nw.nos.boeing.com (137.136.239.145) by XCH-PHX-507.sw.nos.boeing.com (137.136.239.65) with Microsoft SMTP Server (TLS) id 14.2.328.11; Mon, 3 Jun 2013 12:17:12 -0700 Received: from XCH-PHX-503.sw.nos.boeing.com ([169.254.3.131]) by XCH-BLV-512.nw.nos.boeing.com ([169.254.12.178]) with mapi id 14.02.0328.011; Mon, 3 Jun 2013 12:17:11 -0700 From: "Manfredi, Albert E" To: manning bill , Sander Steffann Subject: RE: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOYHFL3ipuRmg4gUm92k3T7UVz05kkmMsAgAAFxYD//74fsA== Date: Mon, 3 Jun 2013 19:17:11 +0000 Message-ID: <021E64FECA7E5A4699562F4E6671648103D669@XCH-PHX-503.sw.nos.boeing.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <51ABC! C79.4090401@gmail.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <5! ! 1 ABD7B8.2010006@gmail.com> <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "v6ops@ietf.org WG" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 19:23:17 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > manning bill > Pragmatically, much of the IPv6 protocol/application development has > ignored half the 128bit space and treats IPv6 as a 64bit address platform= . Exactly. It's time to reinvent CIDR. Bert From iesg-secretary@ietf.org Mon Jun 3 12:29:25 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5DE21E8087; Mon, 3 Jun 2013 12:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.407 X-Spam-Level: X-Spam-Status: No, score=-102.407 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDCoFjVH1A6i; Mon, 3 Jun 2013 12:29:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBBCE21E80A0; Mon, 3 Jun 2013 12:23:07 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Protocol Action: 'Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery' to Proposed Standard (draft-ietf-6man-nd-extension-headers-05.txt) X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130603192307.17650.56927.idtracker@ietfa.amsl.com> Date: Mon, 03 Jun 2013 12:23:07 -0700 Cc: 6man chair <6man-chairs@tools.ietf.org>, 6man mailing list , RFC Editor X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 19:29:25 -0000 The IESG has approved the following document: - 'Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery' (draft-ietf-6man-nd-extension-headers-05.txt) as Proposed Standard This document is the product of the IPv6 Maintenance Working Group. The IESG contact persons are Brian Haberman and Ted Lemon. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-6man-nd-extension-headers/ Technical Summary: This document analyzes the security implications of using IPv6 Extension Headers with Neighbor Discovery (ND) messages. It updates RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective counter-measures for Neighbor Discovery attacks. Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND), and formally updates RFC 3971 to provide advice regarding how the aforementioned security implications can be prevented. Working Group Summary: There is working support for this document. It has been discussed on the mailing list and in face to face 6man sessions. The chairs did a review that improved the quality of the document. Document Quality: No known implementations. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Bob Hinden, Document Shepherd Brian Haberman, Internet AD RFC Editor Note OLD splitting the necessary information into multiple RA messages NEW splitting the necessary information into multiple Router Advertisement (RA) messages OLD options such as the CGA option NEW options such as the Cryptographically Generated Address (CGA) option OLD that would result in fragmented CPA messages. NEW that would result in fragmented Certification Path Advertisement (CPA) messages. From brian.e.carpenter@gmail.com Mon Jun 3 13:36:10 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64B611E80F4; Mon, 3 Jun 2013 13:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmdlkJ59F0no; Mon, 3 Jun 2013 13:36:01 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD9221E80B8; Mon, 3 Jun 2013 13:27:45 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id e14so12036825iej.1 for ; Mon, 03 Jun 2013 13:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4iL+6vQXXfOOOl/Rek58w7S5AmMmf11xuG/hJUPwsRY=; b=U86cuMt9Zl2mpDClJ2PT+7YGmyG14vVTk2JffuFYHkR9NxvQVnDgfJ102Jugr7Lgq3 7X7ztVz7bw3SfQnhlwrnLG9VTon26FVorzXDB+wCnlZHri6UdruSAI2lIsWg9aQyQ8c8 x4zWBB529O+CvJUhna/Be2O0zSu/+9UIe2s/CptgTVYeAfPn2tTzetHQXZoeIi1D8uD0 qyxeS4DgYGdjqANFGBLegmiIVSsoOR/hybgFS0E5AfeyO57S6tHPFawZQJ0B5H9plSQn K0SC9hg2REFwJXis23NrivClXkOvN6ilvy9TjuMmYLo2oa1NFTak1UkVNTQjc/U9h+IO k9yg== X-Received: by 10.50.73.37 with SMTP id i5mr9225861igv.88.1370291264671; Mon, 03 Jun 2013 13:27:44 -0700 (PDT) Received: from [192.168.1.2] (224.171.252.27.dyn.cust.vf.net.nz. [27.252.171.224]) by mx.google.com with ESMTPSA id k10sm21053032ige.0.2013.06.03.13.27.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 13:27:43 -0700 (PDT) Message-ID: <51ACFC3D.90709@gmail.com> Date: Tue, 04 Jun 2013 08:27:41 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: manning bill Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <51ABC! C79.4090401@gmail.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <5! 1 ABD7B8.2010006@gmail.com> <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> In-Reply-To: <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, "v6ops@ietf.org WG" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 20:36:11 -0000 On 04/06/2013 03:44, manning bill wrote: > On 2June2013Sunday, at 16:47, Sander Steffann wrote: >=20 >> On 03/06/2013 11:06, manning bill wrote: >>> /48's are a horrible policy - one should only advertise what one is a= ctually using. >> Now *that* would cause a nice fragmented DFZ... >> Sander >> >=20 >=20 > I'm going to inject a route. One route. why do you care if its a /9,= a /28, a /47, or a /121? I've heard tell that there are routers that are designed to handle prefixes up to /64 efficiently but have a much harder time with prefixes longer than that, as a reasonable engineering trade-off. Not being a router designer, I don't know how true this is. Brian Its -one- route. > That one route covers everything I'm going to use=E2=80=A6 and nothing= I'm not. >=20 > Is there a credible reason you want to be the vector of DDoS attacks, b= y announcing dark space (by proxy aggregation)? > Is that an operational liability you are willing to assume, just so you= can have "unfragmented" DFZ space? >=20 >=20 > /bill From markzzzsmith@yahoo.com.au Mon Jun 3 14:21:41 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0775221F86F5 for ; Mon, 3 Jun 2013 14:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcMpVZ8wBUgM for ; Mon, 3 Jun 2013 14:21:40 -0700 (PDT) Received: from nm20.bullet.mail.bf1.yahoo.com (nm20.bullet.mail.bf1.yahoo.com [98.139.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 83BD621F86AE for ; Mon, 3 Jun 2013 14:16:18 -0700 (PDT) Received: from [98.139.212.149] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jun 2013 21:16:17 -0000 Received: from [98.139.212.199] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jun 2013 21:16:17 -0000 Received: from [127.0.0.1] by omp1008.mail.bf1.yahoo.com with NNFMP; 03 Jun 2013 21:16:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 684705.35345.bm@omp1008.mail.bf1.yahoo.com Received: (qmail 5335 invoked by uid 60001); 3 Jun 2013 21:16:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1370294177; bh=1JmAIjZI8e4wj8dc3+40cM0KS4hQR/kUFTYlO1LRHg0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=trcbTnEn2PvkHvOLQfO6HB/eY2l1hUpbgR9PQ/2LrJabJXF60mbn5pWxUTAc4v4+yNMHyee1huMzGmJ86yxFknfwCL3P6V55nDBsFqLGNYovwkG98+1tcPUQddW2qLQEXyQ2bEGgU10ZqFLGNqK/ksMBqNcY9j+Q7/bt8hI2W/E= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HAkEgf21uBY17q7PeeC+FdxzS2hdSKORxhf77/WiVEBqqpmALW6clzxJD0bV+bevAYlO+8Sxpn7TSrw0oH3CU2wTkT5iM7SGGa5chFmd3PNIRxT/aihD7vUYaJgJWQKvw7Q0PYpZmzuxRudq54L75LfAyIBDo1ldnXjEdAQOGtI=; X-YMail-OSG: mRMo6lAVM1kD8KOTbofnjgIXAn95g30oRvptLBFwF0tONH7 zKhh8KmhR9Edd.oQqOfWTHWAlkk2hysX3ytx_MGlt5cfgU4cmp1twzyvy5MK 7uDiNPN4_6TiaEbjXtGL3RxmJ1LxLxAHPBI1JqW6mWxVdJR13n99mDFRrWSE 1A00bxIanbuEkA7mDpQBqaWyrvoxY8v1M474H5ivrrUBlNJFgu2clcswm0.j 8_sFjHRoxkm1YNvh2ZS4s2S6tIrsm4BWf25x1mtmi0opNuVhmi_5NFaU7LtF xN1OfYAOUCBWXWbo7DEJSafp1ru4MI2Jzx5EwwCN3uJGJLX07JwZ0fOUNbM5 qepVqAlhn720v_ZNyUVZj5LhdKdMoRCw3imQONndM5LVShJ0m0GnM2ETxptL vu5goSm6z0FA0RAwZ67MuspuC36uQEAMugTGrkZTfPdIiKoJoBAX7Lp2jdR4 yDwmMcVcRpfd0IQp0Um4rlN6kon_Tq5vs8vVbxMpxR2to6g3VLPh_K0SA90K qw90V1ns5dG4Rx4OF9L6Tkjkfn5pNx1oaKeVeJoZQ6lyx3pFLQAIwUNr0JmW 5p0jGnCCR Received: from [150.101.221.237] by web142502.mail.bf1.yahoo.com via HTTP; Mon, 03 Jun 2013 14:16:17 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPgo.IFRvOiBtYW5uaW5nIGJpbGwgPGJtYW5uaW5nQGlzaS5lZHU.Cj4gQ2M6IGlwdjZAaWV0Zi5vcmc7ICJ2Nm9wc0BpZXRmLm9yZyBXRyIgPHY2b3BzQGlldGYub3JnPgo.IFNlbnQ6IFR1ZXNkYXksIDQgSnVuZSAyMDEzIDY6MjcgQU0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBDb3VsZCBJUHY2IGFkZHJlc3MgYmUgbW9yZSB0aGFuCglsb2NhdG9yPy8vZHIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <51ABC! C79.4090401@gmail.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <5! 1 ABD7B8.2010006@gmail.com> <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> <51ACFC3D.90709@gmail.com> Message-ID: <1370294177.86144.YahooMailNeo@web142502.mail.bf1.yahoo.com> Date: Mon, 3 Jun 2013 14:16:17 -0700 (PDT) From: Mark Smith Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 To: Brian E Carpenter , manning bill In-Reply-To: <51ACFC3D.90709@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 21:21:41 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Brian E Carpenter =0A> To: manning bill =0A> Cc: ipv= 6@ietf.org; "v6ops@ietf.org WG" =0A> Sent: Tuesday, 4 June = 2013 6:27 AM=0A> Subject: Re: [v6ops] Could IPv6 address be more than=0A=09= locator?//draft-jiang-v6ops-semantic-prefix-03=0A> =0A> On 04/06/2013 03:44= , manning bill wrote:=0A>> On 2June2013Sunday, at 16:47, Sander Steffann w= rote:=0A>> =0A>>> On 03/06/2013 11:06, manning bill wrote:=0A>>>> /48's a= re a horrible policy - one should only advertise what =0A> one is actually = using.=0A>>> Now *that* would cause a nice fragmented DFZ...=0A>>> Sander= =0A>>> =0A>> =0A>> =0A>> I'm going to inject a route.=C2=A0 One route.=C2= =A0 why do you care if its=C2=A0 a /9, =0A> a /28, a /47, or a /121?=0A> = =0A> I've heard tell that there are routers that are designed to handle=0A>= prefixes up to /64 efficiently but have a much harder time with=0A> prefix= es longer than that, as a reasonable engineering trade-off.=0A> Not being a= router designer, I don't know how true this is.=0A>=C2=A0=0A=0A"right-sizi= ng" prefixes to the number of hosts being used also has a cost, which is th= e constant cost of on-going adjustment of prefix size, including complete r= enumbering of the subnet if the specific prefix cannot be expanded further,= and far more complex address space management. This is a cost was initiall= y hidden in IPv4=C2=A0by the fact that it became essential in IPv4 due to t= he size of IPv4's address space. RFC1918 and NAT subsequently predominantly= eliminated it, by providing plenty of address space, and preventing that a= ddress space from being reachable from the Internet, the likely source of a= ttacks on it.=C2=A0=0A=0AThe issue with IPv6's large prefixes isn't really = the specific size of the prefix, it is the exploitable state that is create= d during neighbor presence discovery. If the exploitability of this state i= s reduced, or better yet eliminated, via a host/address registration protoc= ol, the amount of dark space announced doesn't matter.=C2=A0=0A=0ARegards,= =0AMark.=0A=0A> =C2=A0 =C2=A0 Brian=0A> =0A> =C2=A0 Its -one- route.=0A>> = That one route covers everything I'm going to use=E2=80=A6=C2=A0 and nothi= ng I'm =0A> not.=0A>> =0A>> Is there a credible reason you want to be the = vector of DDoS attacks, by =0A> announcing dark space (by proxy aggregation= )?=0A>> Is that an operational liability you are willing to assume, just s= o you can =0A> have "unfragmented" DFZ space?=0A>> =0A>> =0A>> /bill=0A> = =0A> --------------------------------------------------------------------= =0A> IETF IPv6 working group mailing list=0A> ipv6@ietf.org=0A> Administrat= ive Requests: https://www.ietf.org/mailman/listinfo/ipv6=0A> --------------= ------------------------------------------------------=0A> From andrewmcgr@gmail.com Mon Jun 3 16:00:13 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54F221F96DE; Mon, 3 Jun 2013 16:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crYUwUqRnDC3; Mon, 3 Jun 2013 16:00:00 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6B421F973D; Mon, 3 Jun 2013 15:59:09 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id eg20so653420lab.5 for ; Mon, 03 Jun 2013 15:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HoPWZ8BYh3JPTPLq/z44a2yVWK24zPBrEHs5oWfds8c=; b=Z6qaXAK1pI/tImzDqjH8shByG7/mhZFrmDDvOaTA1g4E0VTJhPC6t4C3batTCNYd6j SBecMt6jV/Bp0WjbjZtE+tnH6pm/hsqEBU4MABdwdmj0dPsQrTfVJ4mxN6FQsVJe2cSn 8WlQJcUIKfyCcdZsmZWlBGMRukGyjsVV1amlG951c39a6ORbVSX+lGTeXU+jjzDErB7t S1wWFo9XiX5M2IMAUN4st1UcC6ffF1hYwwLv0Uk/I1ED+spU1RUAOUGwSTQg3+o1HxwZ BckKw9EH2BUwNUnRY/A8MCJiFIgo3WGVpfkA34Irw0LHyAZPxTXoAfRJ/89i4B6cTI/j dAUA== MIME-Version: 1.0 X-Received: by 10.152.21.99 with SMTP id u3mr11907066lae.27.1370300348834; Mon, 03 Jun 2013 15:59:08 -0700 (PDT) Received: by 10.112.5.65 with HTTP; Mon, 3 Jun 2013 15:59:08 -0700 (PDT) In-Reply-To: <51ACFC3D.90709@gmail.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> <51ACFC3D.90709@gmail.com> Date: Tue, 4 Jun 2013 08:59:08 +1000 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Andrew McGregor To: Brian E Carpenter Content-Type: multipart/alternative; boundary=089e0149397a872a6804de47e94e Cc: "v6ops@ietf.org WG" , ipv6@ietf.org, manning bill X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 23:00:14 -0000 --089e0149397a872a6804de47e94e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable That's completely true; many switch chips cannot route on longer than /64 prefixes, so attempting to do so starts to either heat up the software slow path, or consume ACL entries, or is simply not supported at all. While this is arguably a bug, it is also pretty much ubiquitous in the current generation of ethernet switches, which are the basis for the majority of routers. On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 04/06/2013 03:44, manning bill wrote: > > On 2June2013Sunday, at 16:47, Sander Steffann wrote: > > > >> On 03/06/2013 11:06, manning bill wrote: > >>> /48's are a horrible policy - one should only advertise what one is > actually using. > >> Now *that* would cause a nice fragmented DFZ... > >> Sander > >> > > > > > > I'm going to inject a route. One route. why do you care if its a /9, > a /28, a /47, or a /121? > > I've heard tell that there are routers that are designed to handle > prefixes up to /64 efficiently but have a much harder time with > prefixes longer than that, as a reasonable engineering trade-off. > Not being a router designer, I don't know how true this is. > > Brian > > Its -one- route. > > That one route covers everything I'm going to use=85 and nothing I'm n= ot. > > > > Is there a credible reason you want to be the vector of DDoS attacks, b= y > announcing dark space (by proxy aggregation)? > > Is that an operational liability you are willing to assume, just so you > can have "unfragmented" DFZ space? > > > > > > /bill > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --089e0149397a872a6804de47e94e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
That's completely true; many switch chips cannot route= on longer than /64 prefixes, so attempting to do so starts to either heat = up the software slow path, or consume ACL entries, or is simply not support= ed at all. =A0While this is arguably a bug, it is also pretty much ubiquito= us in the current generation of ethernet switches, which are the basis for = the majority of routers.


On Tue, Jun 4= , 2013 at 6:27 AM, Brian E Carpenter <brian.e.carpenter@gmail.co= m> wrote:
On 04/06/2013 03:44, manni= ng bill wrote:
> On 2June2013Sunday, at 16:47, Sander Steffann wrote:
>
>> On 03/06/2013 11:06, manning bill wrote:
>>> /48's are a horrible policy - one should only advertise wh= at one is actually using.
>> Now *that* would cause a nice fragmented DFZ...
>> Sander
>>
>
>
> I'm going to inject a route. =A0One route. =A0why do you care if i= ts =A0a /9, a /28, a /47, or a /121?

I've heard tell that there are routers that are designed to handl= e
prefixes up to /64 efficiently but have a much harder time with
prefixes longer than that, as a reasonable engineering trade-off.
Not being a router designer, I don't know how true this is.

=A0 =A0 Brian

=A0 =A0Its -one- route.
> That one route covers everything I'm going to use=85 =A0and nothin= g I'm not.
>
> Is there a credible reason you want to be the vector of DDoS attacks, = by announcing dark space (by proxy aggregation)?
> Is that an operational liability you are willing to assume, just so yo= u can have "unfragmented" DFZ space?
>
>
> /bill

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--089e0149397a872a6804de47e94e-- From joelja@bogus.com Mon Jun 3 16:09:18 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE5B11E80A5; Mon, 3 Jun 2013 16:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKOlE49GrLbw; Mon, 3 Jun 2013 16:09:07 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id A76E321F8808; Mon, 3 Jun 2013 16:09:07 -0700 (PDT) Received: from joels-MacBook-Air.local (73.sub-70-211-65.myvzw.com [70.211.65.73]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r53N91W7099061 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 3 Jun 2013 23:09:04 GMT (envelope-from joelja@bogus.com) Message-ID: <51AD2208.2010801@bogus.com> Date: Mon, 03 Jun 2013 16:08:56 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Andrew McGregor , Brian E Carpenter Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> <51ACFC3D.90709@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 03 Jun 2013 23:09:05 +0000 (UTC) Cc: "v6ops@ietf.org WG" , ipv6@ietf.org, manning bill X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 23:09:18 -0000 On 6/3/13 3:59 PM, Andrew McGregor wrote: > That's completely true; many switch chips cannot route on longer than > /64 prefixes, so attempting to do so starts to either heat up the > software slow path, or consume ACL entries, or is simply not supported > at all. While this is arguably a bug, it is also pretty much > ubiquitous in the current generation of ethernet switches, which are > the basis for the majority of routers. please cite specifics. I have no devices in the field that have such a limitation. joel > > > On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter > > wrote: > > On 04/06/2013 03:44, manning bill wrote: > > On 2June2013Sunday, at 16:47, Sander Steffann wrote: > > > >> On 03/06/2013 11:06, manning bill wrote: > >>> /48's are a horrible policy - one should only advertise what > one is actually using. > >> Now *that* would cause a nice fragmented DFZ... > >> Sander > >> > > > > > > I'm going to inject a route. One route. why do you care if its a > /9, a /28, a /47, or a /121? > > I've heard tell that there are routers that are designed to handle > prefixes up to /64 efficiently but have a much harder time with > prefixes longer than that, as a reasonable engineering trade-off. > Not being a router designer, I don't know how true this is. > > Brian > > Its -one- route. > > That one route covers everything I'm going to use… and nothing > I'm not. > > > > Is there a credible reason you want to be the vector of DDoS > attacks, by announcing dark space (by proxy aggregation)? > > Is that an operational liability you are willing to assume, just > so you can have "unfragmented" DFZ space? > > > > > > /bill > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From andrewmcgr@gmail.com Mon Jun 3 18:59:01 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F77121F896D; Mon, 3 Jun 2013 18:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMuUA43YLNWS; Mon, 3 Jun 2013 18:58:45 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id 994C321F9927; Mon, 3 Jun 2013 18:27:46 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id r10so87859lbi.25 for ; Mon, 03 Jun 2013 18:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hpqxGnodHo9Wfn9K+02TqEfK2a8hz08iUrU/K5bDiJk=; b=nxIwP5ZsObpKtIxKgyEa0kHvebtQWpRwwwp8lymmhUu06xF7UKnXXeQABo0oQzJaOO 8yv6NLb9SQptuRvyrRD9I43Fe4ybiTCZZeCaHY+9SFhkgGnDid//iEWOYJVlMzzhbXL6 1gRDtM8f1+5LNF6HK2PdKtug2uTJUWw/jyB8Heiawwve/C+PcyccQY7w6Bxiv8SMlLi3 wScEmXLxh5k3J/FAngEBpBm7nP1NV5w/sje9h0FZmALu/gYMgugIT0PpQzCdVP+X6RAw GjnrY7I57qYurW89LTFdy3aATh98Z5OViw7gbGqABlWvgbdwO8oHA5PKiBdZeKRR8zBu 9/Qg== MIME-Version: 1.0 X-Received: by 10.112.188.161 with SMTP id gb1mr11989942lbc.107.1370309265467; Mon, 03 Jun 2013 18:27:45 -0700 (PDT) Received: by 10.112.5.65 with HTTP; Mon, 3 Jun 2013 18:27:45 -0700 (PDT) In-Reply-To: <51AD2208.2010801@bogus.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> <51ACFC3D.90709@gmail.com> <51AD2208.2010801@bogus.com> Date: Tue, 4 Jun 2013 11:27:45 +1000 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Andrew McGregor To: joel jaeggli Content-Type: multipart/alternative; boundary=001a11c36dae00305104de49fd48 Cc: "v6ops@ietf.org WG" , ipv6@ietf.org, manning bill X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 01:59:01 -0000 --001a11c36dae00305104de49fd48 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ok maybe I'm overstating it a bit... but there are a lot of those chips out there, and they are painful. On Tue, Jun 4, 2013 at 9:08 AM, joel jaeggli wrote: > On 6/3/13 3:59 PM, Andrew McGregor wrote: > >> That's completely true; many switch chips cannot route on longer than /6= 4 >> prefixes, so attempting to do so starts to either heat up the software s= low >> path, or consume ACL entries, or is simply not supported at all. While t= his >> is arguably a bug, it is also pretty much ubiquitous in the current >> generation of ethernet switches, which are the basis for the majority of >> routers. >> > please cite specifics. I have no devices in the field that have such a > limitation. > > joel > >> >> >> On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter < >> brian.e.carpenter@gmail.com >> >> wrote: >> >> On 04/06/2013 03:44, manning bill wrote: >> > On 2June2013Sunday, at 16:47, Sander Steffann wrote: >> > >> >> On 03/06/2013 11:06, manning bill wrote: >> >>> /48's are a horrible policy - one should only advertise what >> one is actually using. >> >> Now *that* would cause a nice fragmented DFZ... >> >> Sander >> >> >> > >> > >> > I'm going to inject a route. One route. why do you care if its a >> /9, a /28, a /47, or a /121? >> >> I've heard tell that there are routers that are designed to handle >> prefixes up to /64 efficiently but have a much harder time with >> prefixes longer than that, as a reasonable engineering trade-off. >> Not being a router designer, I don't know how true this is. >> >> Brian >> >> Its -one- route. >> > That one route covers everything I'm going to use=85 and nothing >> I'm not. >> > >> > Is there a credible reason you want to be the vector of DDoS >> attacks, by announcing dark space (by proxy aggregation)? >> > Is that an operational liability you are willing to assume, just >> so you can have "unfragmented" DFZ space? >> > >> > >> > /bill >> >> ------------------------------**------------------------------** >> -------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> >> Administrative Requests: https://www.ietf.org/mailman/**listinfo/ipv= 6 >> ------------------------------**------------------------------** >> -------- >> >> >> >> >> ------------------------------**------------------------------**-------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/**listinfo/ipv6 >> ------------------------------**------------------------------**-------- >> > > --001a11c36dae00305104de49fd48 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Ok maybe I'm overstating it a bit... but there are a l= ot of those chips out there, and they are painful.


On Tue, Jun 4, 2013 at 9:08 AM, = joel jaeggli <joelja@bogus.com> wrote:
On 6/3/13 3:59 PM, Andrew = McGregor wrote:
That's completely true; many switch chips cannot route on longer than /= 64 prefixes, so attempting to do so starts to either heat up the software s= low path, or consume ACL entries, or is simply not supported at all. While = this is arguably a bug, it is also pretty much ubiquitous in the current ge= neration of ethernet switches, which are the basis for the majority of rout= ers.
please cite specifics. I have no devices in the field that have such a limi= tation.

joel


On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter <brian.e.carpenter@gmail.com= <mailto:brian.e.carpenter@gmail.com>> wrote:

=A0 =A0 On 04/06/2013 03:44, manning bill wrote:
=A0 =A0 > On 2June2013Sunday, at 16:47, Sander Steffann wrote:
=A0 =A0 >
=A0 =A0 >> On 03/06/2013 11:06, manning bill wrote:
=A0 =A0 >>> /48's are a horrible policy - one should only adve= rtise what
=A0 =A0 one is actually using.
=A0 =A0 >> Now *that* would cause a nice fragmented DFZ...
=A0 =A0 >> Sander
=A0 =A0 >>
=A0 =A0 >
=A0 =A0 >
=A0 =A0 > I'm going to inject a route. One route. why do you care if= its a
=A0 =A0 /9, a /28, a /47, or a /121?

=A0 =A0 I've heard tell that there are routers that are designed to han= dle
=A0 =A0 prefixes up to /64 efficiently but have a much harder time with
=A0 =A0 prefixes longer than that, as a reasonable engineering trade-off. =A0 =A0 Not being a router designer, I don't know how true this is.

=A0 =A0 Brian

=A0 =A0 Its -one- route.
=A0 =A0 > That one route covers everything I'm going to use=85 and n= othing
=A0 =A0 I'm not.
=A0 =A0 >
=A0 =A0 > Is there a credible reason you want to be the vector of DDoS =A0 =A0 attacks, by announcing dark space (by proxy aggregation)?
=A0 =A0 > Is that an operational liability you are willing to assume, ju= st
=A0 =A0 so you can have "unfragmented" DFZ space?
=A0 =A0 >
=A0 =A0 >
=A0 =A0 > /bill

=A0 =A0 ------------------------------------------------------------= --------
=A0 =A0 IETF IPv6 working group mailing list
=A0 =A0 ipv6@ietf.org <mailto:ipv6@ietf.o= rg>

=A0 =A0 Administrative Requests: https://www.ietf.org/mailman/listinfo= /ipv6
=A0 =A0 ------------------------------------------------------------= --------




-------------------------------------------------------------= -------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
-------------------------------------------------------------= -------


--001a11c36dae00305104de49fd48-- From shengjiang@gmail.com Mon Jun 3 18:37:43 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9FA11E8120; Mon, 3 Jun 2013 18:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.748 X-Spam-Level: X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMmmHaMH5sXG; Mon, 3 Jun 2013 18:37:29 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9A85221E80E3; Mon, 3 Jun 2013 17:59:57 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id v5so72326lbc.30 for ; Mon, 03 Jun 2013 17:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+dFK5OHOtAnXH3zcY/EQjy+j1kbCAr/mzRzNz9tJasI=; b=UZ3w9pLETs10ClMC2omoAqMjoo5THjz7cLIfVKihbGDBfW5LPVwvvXfLrRmCuGCYQm R12HPE5OmuBf/3JYGLfd/UMJ5rL5r3JvcFE8bGWDEUeN3hHYQcA5YjTaKcyAm7q2g9Fo NX7pyixuuFdULPZ+FcUBPv7I9ZlRy6FaQvTN5BV4/q9H4dhDbyMwqqUUZoHhgz+TnOm7 47yZvpUdRZnkawrmdtSiSuqJlqEg7e5pnYyocLInCnjYCQFlllgWPl4M0EISHvYvUqo/ pLODKx27dxxAAz8SuSExFX4fZr97G41Ypas/g1dZ+ffmWOqMUbAUsCAxBqLh1T8liKM7 ynEA== MIME-Version: 1.0 X-Received: by 10.152.27.194 with SMTP id v2mr12027433lag.22.1370307565978; Mon, 03 Jun 2013 17:59:25 -0700 (PDT) Received: by 10.112.67.166 with HTTP; Mon, 3 Jun 2013 17:59:25 -0700 (PDT) In-Reply-To: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> Date: Tue, 4 Jun 2013 08:59:25 +0800 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Sheng Jiang To: Owen DeLong Content-Type: multipart/alternative; boundary=089e0158c2acb408fd04de499730 X-Mailman-Approved-At: Mon, 03 Jun 2013 19:18:33 -0700 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ted Lemon , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 01:37:44 -0000 --089e0158c2acb408fd04de499730 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This looks a typical double standard for me. You are willing to allow homenet (the network operator in this case is subscribers) to play semantic in their networks with the bits from 48 to 63, while you disallow ISPs to set the semantic bits in their networks with the bits from 20 to 48 or 56. You certainly have two theories for each of them. To clarify myself, I am not really against the way giving bits for homenets to better organize their networks. For me, this looks like a variation of semantic prefix. If you have more concrete example how homenet use their bits. I guess I can include them as the third type of semantic prefix, besides ISP and enterprise. Cheers, Sheng On 3 June 2013 21:46, Owen DeLong wrote: > > On Jun 3, 2013, at 7:27 AM, Ted Lemon wrote: > > On Jun 2, 2013, at 11:21 PM, Owen DeLong wrote: > > Yes. A fine engineering solution for demonstration purposes, but not a > good solution for us to recommend for deployment in the long term. > Because it commits wide prefixes to sub-delegations, it wastes address > space profligately, and likely would require a /48 for a fairly trivial > subnetted homenet. > > You say that as if it would be a bad thing. > I don't see a problem with it. > > > IIRC, what started this conversation was the claim that wasting bits on > semantic identifiers was bad because it wasted address space. If you > don't think wasting address space is a problem, why are we even having th= is > debate? > > > I guess it boils down to the definition of waste. > > I believe that making bits available for greater flexibility in consumer > networking is a good use of bits. > > I believe that stealing bits from the consumer for purposes of allowing > the provider to overload the IP address with yet more unrelated meaning > (semantic identifiers) isn't a good idea even if it didn't involve steali= ng > the bits from consumers. > > Owen > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --=20 Sheng Jiang =E8=92=8B=E8=83=9C --089e0158c2acb408fd04de499730 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This looks a typical double standard for me. You are = willing to allow homenet (the network operator in this case is subscribers)= to play semantic in their networks with the bits from 48 to 63, while you = disallow ISPs to set the semantic bits in their networks with the bits from= 20 to 48 or 56. You certainly have two theories for each of them.
=C2=A0
To clarify myself, I am not really against the way gi= ving bits for homenets to better organize their networks. For me, this look= s like a variation of semantic prefix. If you have more concrete example ho= w homenet use their bits. I guess I can include them as the third type of s= emantic prefix, besides ISP and enterprise.
=C2=A0
Cheers,
=C2=A0
Sheng
<= div class=3D"gmail_extra">

On 3 June 2013= 21:46, Owen DeLong <owen@delong.com> wrote:

<= div>On Jun 3, 2013, at 7:27 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Jun 2, 2013, at 11:21 PM, Owen DeLong <owen@delong.com> wrote:
Yes. =C2=A0 A fine engineering solution for demonstration purposes, but not= a good solution for us to recommend for deployment in the long term. =C2= =A0 Because it commits wide prefixes to sub-delegations, it wastes address = space profligately, and likely would require a /48 for a fairly trivial subnetted homenet.
You say that as if it would be a bad thing.
I don't see a problem with it.

IIRC, what started this conversation was the claim that wasting bits o= n semantic identifiers was bad because it wasted address space. =C2=A0 If y= ou don't think wasting address space is a problem, why are we even havi= ng this debate?


I guess it boils down to the defini= tion of waste.

I believe that making bits availabl= e for greater flexibility in consumer networking is a good use of bits.

I believe that stealing bits from the consumer for purp= oses of allowing the provider to overload the IP address with yet more unre= lated meaning (semantic identifiers) isn't a good idea even if it didn&= #39;t involve stealing the bits from consumers.

Owen


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




--
Sheng Jiang =E8=92= =8B=E8=83=9C --089e0158c2acb408fd04de499730-- From shengjiang@gmail.com Mon Jun 3 18:38:23 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F0D11E812C; Mon, 3 Jun 2013 18:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzet2iPRsSIe; Mon, 3 Jun 2013 18:38:09 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9CE21E80F0; Mon, 3 Jun 2013 18:00:22 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id fs12so4036621lab.7 for ; Mon, 03 Jun 2013 18:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uubYcuipTAUk21ywUNe0s5RFofG3v6QvohuNvUwfjDA=; b=sPKM7yVf1+ANap8CgReqGxdiF6gFZLi7+vPkWgBAnX/+m2p6t4D2kM+fvwAIdYCTCP uS0ODc6CVafb3GWJQ9oVCiVeAsZe//PkqFe0v8AwDs62hVAfMn0DYL9Gw1vXexTm/cZ9 crn2ETIDIGULsDYJ5B8mOauEcVjNwPzCYU+MgKaG1RMxiDBJWaqfU2FvTS8BcOP5iAUr 5vDwoiSpeewLV6+pOKxG/0Fc+KRGfXMKRaoUsqhBnWXD1x1RbxasUcATcjvPIlm4H5Hs 2LKhDqOGLMoOBSjn/J2yluq0rQGKzqpnColgg780hKvHTF7xWXCa1/r+vec0oj/l2x58 OeFg== MIME-Version: 1.0 X-Received: by 10.112.60.233 with SMTP id k9mr11788660lbr.61.1370307622040; Mon, 03 Jun 2013 18:00:22 -0700 (PDT) Received: by 10.112.67.166 with HTTP; Mon, 3 Jun 2013 18:00:21 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> Date: Tue, 4 Jun 2013 09:00:21 +0800 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Sheng Jiang To: Ted Lemon Content-Type: multipart/alternative; boundary=e89a8f83a6590b7d7804de499b10 X-Mailman-Approved-At: Mon, 03 Jun 2013 19:18:33 -0700 Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 01:38:23 -0000 --e89a8f83a6590b7d7804de499b10 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Exactly. I agree we should not block the possibility for the future. However, I don't agree we should block the current requirements to make the way for the uncertainties of future. We should first serve the needs today, then we the better current network will become a better fundamental for our future. Cheers, Sheng On 3 June 2013 20:27, Ted Lemon wrote: > On Jun 2, 2013, at 11:21 PM, Owen DeLong wrote: > > Yes. A fine engineering solution for demonstration purposes, but not a > good solution for us to recommend for deployment in the long term. > Because it commits wide prefixes to sub-delegations, it wastes address > space profligately, and likely would require a /48 for a fairly trivial > subnetted homenet. > > You say that as if it would be a bad thing. > I don't see a problem with it. > > > IIRC, what started this conversation was the claim that wasting bits on > semantic identifiers was bad because it wasted address space. If you > don't think wasting address space is a problem, why are we even having th= is > debate? > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --=20 Sheng Jiang =E8=92=8B=E8=83=9C --e89a8f83a6590b7d7804de499b10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Exactly. I agree we should not block the possibility = for the future. However, I don't agree we should block the current requ= irements to make the way for the uncertainties of future. We should first s= erve the needs today, then we the better current network will become a bett= er fundamental for our future.
=C2=A0
Cheers,
=C2=A0
Sheng
<= div class=3D"gmail_extra">

On 3 June 2013= 20:27, Ted Lemon <Ted.Lemon@nominum.com> wrote:
On Jun 2, 2013, at 11:21 PM, Owen DeLong <owen@delong.com> wrote:
Yes. =C2=A0 A fine engineering solution for demonstration purposes, but not= a good solution for us to recommend for deployment in the long term. =C2= =A0 Because it commits wide prefixes to sub-delegations, it wastes address = space profligately, and likely would require a /48 for a fairly trivial subnetted homenet.
You say that as if it would be a bad thing.
I don't see a problem with it.

IIRC, what started this conversation was the claim that wasting = bits on semantic identifiers was bad because it wasted address space. =C2= =A0 If you don't think wasting address space is a problem, why are we e= ven having this debate?


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




--
Sheng Jiang =E8=92= =8B=E8=83=9C --e89a8f83a6590b7d7804de499b10-- From shengjiang@gmail.com Mon Jun 3 18:47:31 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A3221F99D7; Mon, 3 Jun 2013 18:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 194hlUmVj6Bt; Mon, 3 Jun 2013 18:47:21 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4F221E8134; Mon, 3 Jun 2013 18:13:08 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id lx15so4120738lab.10 for ; Mon, 03 Jun 2013 18:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ydRGVYQKIAPmkLB1Y/5IDCRQMififmGqOdydjYxK+sI=; b=Vnkhc9QAWPjA2i7rwZlPRm/ULKxbSLL2wOhwX/FosulGm52MFbzJE51Qn8Bk0C0/MR tj/HyXk06lYDJFCpdyXgbG0We1sZgACN5eLYWnBJd/SfuP73Qi4R1izMwT3XEaMD7IYI T0BnK5XyMAen3XjoVI0nT+vB7WdZYBEEpJpi7EzTMzAPIAMcDnNXKzLYNDTQWTa2AFbg qyHFVa2ELKgGzpPnMOGK/h6CuDBs4ANDtXPVDnedCHoIPqfZcTgcbbtOUsTpzny2/XLT iH0j+PbDMM67zTl32ngUuLMN4iZvYAVhBoYTZsYA/2cN6uWItwmSVMHz3rGNp/pDshXp 5Upg== MIME-Version: 1.0 X-Received: by 10.112.140.69 with SMTP id re5mr12048667lbb.0.1370308387099; Mon, 03 Jun 2013 18:13:07 -0700 (PDT) Received: by 10.112.67.166 with HTTP; Mon, 3 Jun 2013 18:13:06 -0700 (PDT) In-Reply-To: <51ACA39F.2000009@kit.edu> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <51A71ACA.3000608@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> <51A733E1.7040008@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99A07@nkgeml512-mbx.china.huawei.com> <51A841B5.3010805@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99CF4@nkgeml512-mbx.china.huawei.com> <6B838546-4FB3-4EDB-9F84-D8CF0AF3080D@millnert.se> <51A87174.3080204@globis.net> <51ACA39F.2000009@kit.edu> Date: Tue, 4 Jun 2013 09:13:06 +0800 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Sheng Jiang To: "Bless, Roland (TM)" Content-Type: multipart/alternative; boundary=001a11c34204a55cc004de49c890 X-Mailman-Approved-At: Mon, 03 Jun 2013 19:18:33 -0700 Cc: Ray Hunter , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 01:47:31 -0000 --001a11c34204a55cc004de49c890 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Roland, Thanks for your comments. Yes, the authors will restructure this draft - making it more an analysis draft rather than a proposal. The pitfalls will be an very important part for a neutral analysis. Cheers, Sheng On 3 June 2013 22:09, Bless, Roland (TM) wrote: > Hi, > > On 31.05.2013 11:46, Ray Hunter wrote: > > > But why are people coming up with these schemes for encoding semantics > > in the address prefixes in the first place? That's what I'd like to > > understand first and foremost: what lack of functionality is > > motivating/forcing these people to adopt such schemes? > > I'm not sure. Some impressions from the draft I got when I browsed > over it: > - An address is something that the provider controls, therefore > it may have more trust in the address information, esp. if > source address filtering is done properly. The draft seems > to promote the idea in favor of others like DSCP marking > (which is untrusted up to the boundary node anyway). > > - Overloading semantics is IMHO a bad thing as it complicates > things as well, e.g., encoding application-level semantics into the > network layer is generally a bad idea (see end-to-end > argument - putting appl.-level knowledge into the network implies > inflexibility and increased complexity). Moreover, choosing the right > address/network prefix must not require network topology knowledge > in the application (remembering the site-locals discussion several > years ago). > > - one useful scenario, however, may be the use of different security > zones. We actually proposed this in an internal network > of a vehicle - the particular advantage is here that you can easily > perform security policy enforcement with firewalls and address > filtering rules. > However, you also may have a topological/logical subnet structure > in addition to the security zones, leading to a subnet matrix > structure. In addition to that you may have different QoS > requirements for traffic within a subnet, so DSCP marking is also > orthogonal to the "address" semantics - you should not encode them > into the prefix as well. > > - dividing a network into different subnets according to different > semantics is nothing unusual and is widely used today, mostly > motivated by either topological aspects, logical user/device groups, > and/or trust/security domains. However, semantics b., d. and e. > of > http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03#section-4= .3 > (applications, traffic identity types, quality requirements) > seem to be bad reasons for "encoding" them into prefixes, IMHO. > > Thus, if the document is adopted somehow, it should rather > point out the potential pitfalls. Currently, as other already said, > it reads as it would be a preferred operational method... > > Regards, > Roland > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 Sheng Jiang =E8=92=8B=E8=83=9C --001a11c34204a55cc004de49c890 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Roland,
=C2=A0
Thanks for you= r comments. Yes, the authors will restructure this draft - making it more a= n analysis draft rather than a proposal. The pitfalls will be an very impor= tant part for a neutral analysis.
=C2=A0
Cheers,
=C2=A0
Sheng
<= div class=3D"gmail_extra">

On 3 June 2013= 22:09, Bless, Roland (TM) <roland.bless@kit.edu> wrote:<= br>
Hi,

On 31.05.2013 11:46, Ray Hunter wrote:

> But why are people coming up with these schemes for encoding semantics=
> in the address prefixes in the first place? That's what I'd li= ke to
> understand first and foremost: what lack of functionality is
> motivating/forcing these people to adopt such schemes?

I'm not sure. Some impressions from the draft I got when I browse= d
over it:
- An address is something that the provider controls, therefore
=C2=A0 it may have more trust in the address information, esp. if
=C2=A0 source address filtering is done properly. The draft seems
=C2=A0 to promote the idea in favor of others like DSCP marking
=C2=A0 (which is untrusted up to the boundary node anyway).

- Overloading semantics is IMHO a bad thing as it complicates
=C2=A0 things as well, e.g., encoding application-level semantics into the<= br> =C2=A0 network layer is generally a bad idea (see end-to-end
=C2=A0 argument - putting appl.-level knowledge into the network implies =C2=A0 inflexibility and increased complexity). Moreover, choosing the righ= t
=C2=A0 address/network prefix must not require network topology knowledge =C2=A0 in the application (remembering the site-locals discussion several =C2=A0 years ago).

- one useful scenario, however, may be the use of different security
=C2=A0 zones. We actually proposed this in an internal network
=C2=A0 of a vehicle - the particular advantage is here that you can easily<= br> =C2=A0 perform security policy enforcement with firewalls and address
=C2=A0 filtering rules.
=C2=A0 However, you also may have a topological/logical subnet structure =C2=A0 in addition to the security zones, leading to a subnet matrix
=C2=A0 structure. In addition to that you may have different QoS
=C2=A0 requirements for traffic within a subnet, so DSCP marking is also =C2=A0 orthogonal to the "address" semantics - you should not enc= ode them
=C2=A0 into the prefix as well.

- dividing a network into different subnets according to different
=C2=A0 semantics is nothing unusual and is widely used today, mostly
=C2=A0 motivated by either topological aspects, logical user/device groups,=
=C2=A0 and/or trust/security domains. However, semantics b., d. and e.
=C2=A0 of
http://tools.ietf.org/html/draft-jiang-v6ops= -semantic-prefix-03#section-4.3
(applications, traffic identity types, quality requirements)
=C2=A0 seem to be bad reasons for "encoding" them into prefixes, = IMHO.

Thus, if the document is adopted somehow, it should rather
point out the potential pitfalls. Currently, as other already said,
it reads as it would be a preferred operational method...

Regards,
=C2=A0Roland

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



--
Sheng Jiang= =E8=92=8B=E8=83=9C --001a11c34204a55cc004de49c890-- From shengjiang@gmail.com Mon Jun 3 19:01:32 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C2021F8BC0; Mon, 3 Jun 2013 19:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.832 X-Spam-Level: X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BheJMVS195n9; Mon, 3 Jun 2013 19:01:04 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id 8038521F994D; Mon, 3 Jun 2013 18:29:53 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id w10so89252lbi.23 for ; Mon, 03 Jun 2013 18:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xxVQnKr2JtL0hM8IxRJtKgsexSTGT+qJTLqwiTEvXrE=; b=nvLGdC1H20dwubY+ua1D2OvLcKY181REHh0JdCLy2iBTXohOH6TIj7UjnAT7ZVv4ot zctFJW2FooLVS/mYH6e9NszLOEjY/+kBHFEI9omaxUvQ4chQs/eLmgBjyMwr+tm/J+AQ 8kiILR2tejqG1JawcvGqTclCxe06wbJQxZvNcB9n6CNy2eXToND7stc0asVjNFEYsFdY swksoro6cjNAuit2qV4b+fORwhfFIv3MDEe6d3pmADYeazXDDKcaAm/rXK/KzNr+lGgo g+4FPjbzw4linMyAsLPBBrz6SrjBVyn8WanQSU2ZMR2GVRr8i+fcS7dc7cNj93IXGT1R ULEQ== MIME-Version: 1.0 X-Received: by 10.112.120.170 with SMTP id ld10mr11937325lbb.31.1370309392311; Mon, 03 Jun 2013 18:29:52 -0700 (PDT) Received: by 10.112.67.166 with HTTP; Mon, 3 Jun 2013 18:29:52 -0700 (PDT) In-Reply-To: <7767FF5D-194E-445A-A890-05A3E4C7CCC1@delong.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C2D69@mbx-01.win.nominum.com> <7767FF5D-194E-445A-A890-05A3E4C7CCC1@delong.com> Date: Tue, 4 Jun 2013 09:29:52 +0800 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Sheng Jiang To: Owen DeLong Content-Type: multipart/alternative; boundary=047d7bf0c5be8fa9b204de4a04a1 X-Mailman-Approved-At: Mon, 03 Jun 2013 19:18:33 -0700 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ted Lemon , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 02:01:32 -0000 --047d7bf0c5be8fa9b204de4a04a1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >They are stealing from the consumer's flexibility to >provide (questionable) functionality to the provider. What's the problem if the consumer get /48 as you want, and providers play their 28 bits (bit 20~47)? For me, the consumer flexibility looks more uncertain although I don't have much against it. Sheng On 3 June 2013 22:36, Owen DeLong wrote: > > On Jun 3, 2013, at 9:22 AM, Ted Lemon wrote: > > On Jun 3, 2013, at 9:46 AM, Owen DeLong wrote: > > I believe that making bits available for greater flexibility in consumer > networking is a good use of bits. > > I believe that stealing bits from the consumer for purposes of allowing > the provider to overload the IP address with yet more unrelated meaning > (semantic identifiers) isn't a good idea even if it didn't involve steali= ng > the bits from consumers. > > > But these arguments are mutually contradictory, since the bits are in fac= t > making use of the added flexibility IPv6 gives to consumer networking. > What you seem to be saying is that we need to preserve the ability of > end-users to spend bits like water by stopping ISPs from spending them. > Being an end-user, I have a lot of sympathy for your position, but I don'= t > think this is something on which the IETF is likely to achieve a strong > consensus, and that's okay. Whether you like semantic prefixes or not, > they are something that ISPs are experimenting with, for reasons they thi= nk > are valid. What we should be talking about is not whether they can do > these experiments, but why they are doing them. > > > No, they are not. They are stealing from the consumer's flexibility to > provide (questionable) functionality to the provider. > > I am not saying that consumers should be able to spend bits like water. > I'm saying that consumers should get their intended 16 bits of flexibilit= y. > No more, no less. If you said consumers should get /44s per end site > because they need additional flexibility, I'd be asking you to prove use > cases. But the original protocol design intended 16 bits of flexibility a= nd > the address size was calculated to include that. > > As to what we should be talking about, we should, indeed be talking both > about why providers are doing these experiments and also why this type of > overloading of unrelated meaning onto address bits is an inherently bad > idea. > > Fortunately, we are talking about both of those things. > > Owen > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --=20 Sheng Jiang =E8=92=8B=E8=83=9C --047d7bf0c5be8fa9b204de4a04a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>They are stealing from the consumer's flexibi= lity to
>provide (questionable) functionality to the provider.=
=C2=A0
What's the problem if the consumer get /48 = as you want, and providers play their 28 bits (bit 20~47)?
=C2=A0
For me, the consumer flexibility looks more uncertain= although I don't have much against it.
=C2=A0
Shen= g


= On 3 June 2013 22:36, Owen DeLong <owen@delong.com> wrote:

<= div>On Jun 3, 2013, at 9:22 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Jun 3, 2013, at 9:46 AM, Owen DeLong <owen@delong.com>=C2=A0wrote:
I believe that making bits available for greater flexibility in consumer ne= tworking is a good use of bits.

I believe that stealing bits from the consumer for purposes of allowing the= provider to overload the IP address with yet more unrelated meaning (seman= tic identifiers) isn't a good idea even if it didn't involve steali= ng the bits from consumers.

But these arguments are mutually contradictory, since the bits are in = fact making use of the added flexibility IPv6 gives to consumer networking.= =C2=A0 What you seem to be saying is that we need to preserve the ability = of end-users to spend bits like water by stopping ISPs from spending them. =C2=A0 Being an end-user, I have a lo= t of sympathy for your position, but I don't think this is something on= which the IETF is likely to achieve a strong consensus, and that's oka= y. =C2=A0 Whether you like semantic prefixes or not, they are something that ISPs are experimenting with, for reasons they thin= k are valid. =C2=A0 What we should be talking about is not whether they can= do these experiments, but why they are doing them.


No, they are not. They are stealing= from the consumer's flexibility to provide (questionable) functionalit= y to the provider.

I am not saying that consumers = should be able to spend bits like water. I'm saying that consumers shou= ld get their intended 16 bits of flexibility. No more, no less. If you said= consumers should get /44s per end site because they need additional flexib= ility, I'd be asking you to prove use cases. But the original protocol = design intended 16 bits of flexibility and the address size was calculated = to include that.

As to what we should be talking about, we should, indee= d be talking both about why providers are doing these experiments and also = why this type of overloading of unrelated meaning onto address bits is an i= nherently bad idea.

Fortunately, we are talking about both of those things.=

Ow= en


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




--
Sheng Jiang =E8=92= =8B=E8=83=9C --047d7bf0c5be8fa9b204de4a04a1-- From lorenzo@google.com Mon Jun 3 19:23:20 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A048A11E810D for ; Mon, 3 Jun 2013 19:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAgPlOjx2Sf2 for ; Mon, 3 Jun 2013 19:23:03 -0700 (PDT) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id BA1C611E817D for ; Mon, 3 Jun 2013 18:44:57 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id q19so2840091qeb.18 for ; Mon, 03 Jun 2013 18:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=O0DCoMAXsnROggz4xWYm2csPAqGxt/Cp5eM4FpCb2xQ=; b=U09CLpZelpu9//wss8vhcMNUMZd+LVhbgjBT5fwLAykA8PFFyahcB3IXP0gUiMXpdK 1oaTyjJL+cYcour1lmRccH+P/BxlAVJT+ugfw9GMps0neTGi9CoWKjpHOmevR3TMdDeL XR5DKH2OJ/16SDiVtdOaIHLQOVKUYjrR3KEodf4XoRN9PX4XNRXkcA3pAXeJTen0oGV5 OJ2P37Fb+ev9f882HbC4yKWD9rjbCxioKKxvGYUwUHyykLX5B+EkwHmQTUGMzBJd2RWD c2WEVO55M1xefE7+/jiI7NwkRFOVybIUBugrXJ/ii+xM0AqZLC1gR9sYfSmwYOKYWEU3 2vxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=O0DCoMAXsnROggz4xWYm2csPAqGxt/Cp5eM4FpCb2xQ=; b=ktuL3DE9zbcAiztGIljKmK6ZR83iw/qlJvfd9RnbPno23ftFpt4DHYYYUOmHRZWetm uwJahcK5K+X6GBT2r0nPah5aS6+UOdb05fDiOnYJ82hmjYUP5kg0oD41fjCikJVZ31Lv HDdzV48Lbcz47P/D4GEZeZIQ99aP7+N3a8PSRe8VunoIYtvZ9jAC04Pq769mhN1j47Cy +p6pp2CrnmyXNWUh3SCACQS4+tfS9Nti4UNq0pBJvc1gosK+3XbeYZt/wXdMm112lcy3 UnFPmjl69Sy1hTs9kpP/EG3omPiy9yBuY/JIntgq9c8lrAHSWR9jSqlFrp0sO5L0aARu ZSJw== X-Received: by 10.229.137.73 with SMTP id v9mr5445016qct.77.1370310297059; Mon, 03 Jun 2013 18:44:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.198 with HTTP; Mon, 3 Jun 2013 18:44:36 -0700 (PDT) In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC895DBD258@SRVHKE02.rdm.cz> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <51ACA2F8.7060601@joelhalpern.com> <1808340F7EC362469DDFFB112B37E2FCC895DBD258@SRVHKE02.rdm.cz> From: Lorenzo Colitti Date: Tue, 4 Jun 2013 10:44:36 +0900 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 To: =?UTF-8?B?VsOtemRhbCBBbGXFoQ==?= Content-Type: multipart/alternative; boundary=00235452fd9c7d39c904de4a3a17 X-Gm-Message-State: ALoCoQlt8vHq3w8oEx+RVs7fV6i9hsej/VkNeciTMsuWEIOjNPTTQV17ZbxPlE2QhPwsr43Nb+cvloWuanaReHzNDI5iIFtN9+6tMPwtgCQ+fMNFsyVrKLsfmTcJUPHpwWu3CWYMQB5nsx96hrlmVrILHzBsSEQ8/zhzIXnTQEMt5YdY/UQaKmbzrOJUNjbTLBjiAur1I1U0 Cc: Sheng Jiang , "" , "ipv6@ietf.org" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 02:23:20 -0000 --00235452fd9c7d39c904de4a3a17 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 3, 2013 at 11:59 PM, V=C3=ADzdal Ale=C5=A1 wrote: > > If I am reading this correctly, in the end this is riven by the fact > that existing boxes > > can easily filter on addresses (although it will take a lot of filters)= , > but can not apply > > ACLs to DSCPs or extension headers? > > The current boxes can do both ACL filtering as well as DSCP mangling, but > as mentioned > earlier the DSCP bits cannot be trusted, so a markdown/re-marking is > required potentially > involving DPI. Maintaining ACLs is also time consuming. > I don't understand what the difference is. Why can the addresses be trusted? Answer - because you drop packets if the host uses the wrong address. But all the space is routed to the user anyway, and the semantic bits only express semantics, right? Therefore you can't use routing or RPF to implement the drops, and you have to use an ACL. So if you have to use an ACL to do this anyway, then why can't you make the ACL drop packets if the host uses the wrong DSCP codepoint? That way you don't need to use extra address space. --00235452fd9c7d39c904de4a3a17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 3, 2013 at 11:59 PM, V=C3=ADzdal Ale=C5=A1 <ales.vizdal@t-mobile.cz> wrote:
> If I am reading this correctly, in the end this is ri= ven by the fact that existing boxes
> can easily filter on addresses (although it will take a lot of filters= ), but can not apply
> ACLs to DSCPs or extension headers?

The current boxes can do both ACL filtering as well as DSCP mangling, but a= s mentioned
earlier the DSCP bits cannot be trusted, so a markdown/re-marking is requir= ed potentially
involving DPI. Maintaining ACLs is also time consuming.

I don't understand what the difference is. Why c= an the addresses be trusted? Answer - because you drop packets if the host = uses the wrong address. But all the space is routed to the user anyway, and= the semantic bits only express semantics, right? Therefore you can't u= se routing or RPF to implement the drops, and you have to use an ACL.

So if you have to use an ACL to do this any= way, then why can't you make the ACL drop packets if the host uses the = wrong DSCP codepoint? That way you don't need to use extra address spac= e.
--00235452fd9c7d39c904de4a3a17-- From lorenzo@google.com Mon Jun 3 20:01:11 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF07B21F8EF2 for ; Mon, 3 Jun 2013 20:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 423u+mgnx4zR for ; Mon, 3 Jun 2013 20:01:00 -0700 (PDT) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1785211E80F6 for ; Mon, 3 Jun 2013 19:08:40 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id f14so85427qak.14 for ; Mon, 03 Jun 2013 19:08:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zZasMs5NmN+i/A0Vvtqx8r9w1bciQ41vVTAWedt8HsE=; b=OsGSeg1aU+dxRVUJonPQlvtiiCFuBnzmasR+a3kU1WqQSqDnnnI39XoQXbhxw3E80O 9AElFSaz4S9qPBt9Vq1jIL3IOFsLxlyDen2brSlBLTHhfQfN0+xravclkLW6bXqAVgm0 1roVgORUSNMihirO4uOySbCSLIBI/76ScvmeqWASkRb7LSMWN384TBBsKNNUHLMDby43 eh8CKf4qg88T7oBpc4UAnxUx40BHXTZBZrokVpYaJMsPl8ixm8FmDnH3UB+zCgrQssg1 PEmDOkJw7LQzbVM++nubdEB3YPH71J8KPuqFvbTDvUINsT1ELefTD340AxDJv70EDq9e BUdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=zZasMs5NmN+i/A0Vvtqx8r9w1bciQ41vVTAWedt8HsE=; b=cuPdTOlRaK6CmloMwn73sSAzMkpu04/rbKXGsSI7ZDcZJe4Y/EEjSm3+djwTt0mo+H A9gcpWAnxdgFMv00WeyL6dOtfKcSN6Ea4NY5z2l6p1qaegtJ3NdEEQgq+EdjBSyEqBqx QvSTtApfqORgf+M7OJ4VaP8vNnXPliVC7c2P/NTdFcJDEH7SGZMXXjBq4TuLgItc9OOz jFeGwct92hS7Rix+XfoRmB6jZGwL03m/yCO4fS0f0O+Nah1PRal267x4m0XIJVBJchpG Qq7ELHsgFsB45WeDp7YGENaMVLqHMUOiiF647o+fVERxvtEy6lqJz8VqWhqSVwE5OIdH wvKw== X-Received: by 10.49.85.131 with SMTP id h3mr24668131qez.42.1370311720304; Mon, 03 Jun 2013 19:08:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.198 with HTTP; Mon, 3 Jun 2013 19:08:20 -0700 (PDT) In-Reply-To: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C2D69@mbx-01.win.nominum.com> <7767FF5D-194E-445A-A890-05A3E4C7CCC1@delong.com> From: Lorenzo Colitti Date: Tue, 4 Jun 2013 11:08:20 +0900 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 To: Sheng Jiang Content-Type: multipart/alternative; boundary=047d7bd7566a52272204de4a8fb1 X-Gm-Message-State: ALoCoQn9oVkyGqXbJBXPgFg769Lu3WtUO9mATJ049364tKcey6a/vo5VOXl/Zw73o3onlL1oGuALxg4d4tvNF8kr5KdfsELVVZemR7BXUoQP1WWvdf6rxnfV63GoM94OnJtwfBHIneYkfDfhSdfj7qmBdAJfQCSjleSstAs9MaGFDAQv7yEg+tgywADA4ihqbwtb/GrNFGIQ Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 03:01:11 -0000 --047d7bd7566a52272204de4a8fb1 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 4, 2013 at 10:29 AM, Sheng Jiang wrote: > >They are stealing from the consumer's flexibility to > >provide (questionable) functionality to the provider. > > What's the problem if the consumer get /48 as you want, and providers play > their 28 bits (bit 20~47)? > The problem is that the RIRs will not accept "we use semantic bits" as a justification for requesting more address space. Thus the provider only has the following choices: 1. Give customers less than a /48. 2. Request more space than they need for the customers they have, and hope that they never have to get more address space in the future. 3. Not use semantic prefixes. --047d7bd7566a52272204de4a8fb1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 4, 2013 at 10:29 AM, Sheng Jiang <shengjia= ng@gmail.com> wrote:
>They are stea= ling from the consumer's flexibility to
>provide (question= able) functionality to the provider.
=A0
What's the problem if the consumer get /48 as = you want, and providers play their 28 bits (bit 20~47)?

The problem is that the RIRs will not accept "= ;we use semantic bits" as a justification for requesting more address = space. Thus the provider only has the following choices:

1. Give customers less than a /48.
2. Request= more space than they need for the customers they have, and hope that they = never have to get more address space in the future.
3. Not = use semantic prefixes.
--047d7bd7566a52272204de4a8fb1-- From ipepelnjak@gmail.com Mon Jun 3 20:04:06 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD6F21F8F78; Mon, 3 Jun 2013 20:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjI+WUsVNbgW; Mon, 3 Jun 2013 20:03:56 -0700 (PDT) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 59C5611E8102; Mon, 3 Jun 2013 19:11:40 -0700 (PDT) Received: by mail-ea0-f177.google.com with SMTP id j14so1798619eak.36 for ; Mon, 03 Jun 2013 19:11:33 -0700 (PDT) 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:x-mailer:from:subject:date:to; bh=YzDlshfKDm9+BeZLz5tj3fMqwXHTj1HK0MpIVd81vPs=; b=cFjhX21+RBS5r3ooOVxbaRlAGLvnvlV0YAhMTn681mRZikkj+FVsC+8nw1AtJIad07 +z8Cg6ZeEBVPL7KmhE7MjjHHCcncfUonG4eljZaz3PGX/hCIpR5bCnYmssA1tavA//fl //WZpibdcM+DnuwSCAvu0vZOU78MtdEiQk5bFHUHle++kCiPd0+9WUL8+kPgZHOhcASl YD8nnc+2+S7hNzSSHYfZgMPxzMfQNwWZ2fIe+ROxtH+0rcohMihEMMMjW9VZUsEKlufQ aYI/viM/K6nP/+t30Qqer5vj402qTLmCMapEYs8uguWvqiE15rQDS7FKrnyumlynrNAd uDDQ== X-Received: by 10.15.54.4 with SMTP id s4mr24972010eew.49.1370311893227; Mon, 03 Jun 2013 19:11:33 -0700 (PDT) Received: from [192.168.200.202] (BSN-61-33-18.dial-up.dsl.siol.net. [86.61.33.18]) by mx.google.com with ESMTPSA id f1sm60406881eem.17.2013.06.03.19.11.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 19:11:32 -0700 (PDT) References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> <51ACFC3D.90709@gmail.com> <51AD2208.2010801@bogus.com> In-Reply-To: <51AD2208.2010801@bogus.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <4FDCE28C-0B1E-4A8E-AB73-044A9B4BEB07@gmail.com> X-Mailer: iPad Mail (9B206) From: Ivan Pepelnjak Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Date: Tue, 4 Jun 2013 04:11:33 +0200 To: joel jaeggli X-Mailman-Approved-At: Mon, 03 Jun 2013 20:06:28 -0700 Cc: "v6ops@ietf.org WG" , manning bill , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 03:04:06 -0000 Read the recent "p2p /64" thread of ipv6-ops cluenet mailing list =3D=3D=3D=3D=3D Mistyped and autocorrected on a clunky virtual keyboard On 4. jun. 2013, at 01:08, joel jaeggli wrote: > On 6/3/13 3:59 PM, Andrew McGregor wrote: >> That's completely true; many switch chips cannot route on longer than /64= prefixes, so attempting to do so starts to either heat up the software slow= path, or consume ACL entries, or is simply not supported at all. While this= is arguably a bug, it is also pretty much ubiquitous in the current generat= ion of ethernet switches, which are the basis for the majority of routers. > please cite specifics. I have no devices in the field that have such a lim= itation. >=20 > joel >>=20 >>=20 >> On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter > wrote: >>=20 >> On 04/06/2013 03:44, manning bill wrote: >> > On 2June2013Sunday, at 16:47, Sander Steffann wrote: >> > >> >> On 03/06/2013 11:06, manning bill wrote: >> >>> /48's are a horrible policy - one should only advertise what >> one is actually using. >> >> Now *that* would cause a nice fragmented DFZ... >> >> Sander >> >> >> > >> > >> > I'm going to inject a route. One route. why do you care if its a >> /9, a /28, a /47, or a /121? >>=20 >> I've heard tell that there are routers that are designed to handle >> prefixes up to /64 efficiently but have a much harder time with >> prefixes longer than that, as a reasonable engineering trade-off. >> Not being a router designer, I don't know how true this is. >>=20 >> Brian >>=20 >> Its -one- route. >> > That one route covers everything I'm going to use=E2=80=A6 and nothi= ng >> I'm not. >> > >> > Is there a credible reason you want to be the vector of DDoS >> attacks, by announcing dark space (by proxy aggregation)? >> > Is that an operational liability you are willing to assume, just >> so you can have "unfragmented" DFZ space? >> > >> > >> > /bill >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >>=20 >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ggm@algebras.org Mon Jun 3 21:24:53 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510CB21E80D1 for ; Mon, 3 Jun 2013 21:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDJ8xVL6Vv5W for ; Mon, 3 Jun 2013 21:24:39 -0700 (PDT) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9B321E80F5 for ; Mon, 3 Jun 2013 20:25:20 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id q11so6508308pdj.24 for ; Mon, 03 Jun 2013 20:25:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=V1BuMIC0mpGyDBLKaKSjsxZKM2oUHU0pp2tQ7YAuurg=; b=jXOCxe05tDCrw3DAtAMSsYnhEO1FDz6c51y7szBz4n2GH/oRXKv2BU8VIMziDTahci ehwF3cw7iB95wot29BXOE4V5YVVbIIr6bGMkLuNWrJuALrHVlRsTXzz6++pdXOaC/peK uCuXRhwKNkhpZq8ZMq6u9w1BPk0604TvKsDYNDDjCCX+9LeE+YfL7INgssESgFE+Ibe2 LgGvJzVzRV0UBy6TVJw3QsRP6EABi11PKKdASrT81Vm3LyYzO9UPTKLd5aA+wyyj/93d aj6a1x5LATr8DXynB+yWoValuXGK2OM6awvPVQuez3ESszMnihWW/7tgh2GQ8i7v8oqx XcgQ== MIME-Version: 1.0 X-Received: by 10.66.50.4 with SMTP id y4mr27324545pan.216.1370316319945; Mon, 03 Jun 2013 20:25:19 -0700 (PDT) Received: by 10.70.25.195 with HTTP; Mon, 3 Jun 2013 20:25:19 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:7d56:7f99:c756:21bd] In-Reply-To: <4FDCE28C-0B1E-4A8E-AB73-044A9B4BEB07@gmail.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> <51ACFC3D.90709@gmail.com> <51AD2208.2010801@bogus.com> <4FDCE28C-0B1E-4A8E-AB73-044A9B4BEB07@gmail.com> Date: Tue, 4 Jun 2013 13:25:19 +1000 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: George Michaelson To: Ivan Pepelnjak Content-Type: multipart/alternative; boundary=bcaec544eb967b06fa04de4ba139 X-Gm-Message-State: ALoCoQnVHHzOD1PRJaXZHXyX1nDKUynCAM4xtqPpWh0vVZBGOKZkTdtKGnf3dwnmdpOaJaIfrrta Cc: "v6ops@ietf.org WG" , "ipv6@ietf.org" , manning bill X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 04:24:53 -0000 --bcaec544eb967b06fa04de4ba139 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Just to remind people, RIR policy is community driven. If the operations people feel they need a policy for IPv6 allocations and assignments which takes accounts of semantic bits, they can derive consensus driven policies to do it. Its not done in the IETF. There might be an issue with how it squares against IETF goals of conservation, but thats part of the discussion in RIR policy space maybe. I think there is a touch of catch-22 here: there isn't a clear sense this is an industry wide practice demanding that policy initiative (I do not preclude it: I just observe, it hasn't happened yet) and there is an absence of a well understood methodology of using it and applying it which differs radically in outcome from ACL based methods. If there was an IETF standard I am sure somebody could propose an allocations model which reflected it, but who knows if that would get traction. I notice that there are large providers who feel semantic bit flagging works for them. So, I do not say "nobody is doing it" as much as "nobody has said they want an RIR allocations policy which reflects it, yet" The first time this came up, I think I said to mike that I could understand ISPs wanting to say "this is a mechanism we use inside our locus of control, to flag behaviours of packets" -ie that it was unlikely there was a model for this to be meaningful between providers, but inside a single autonomous region, sure: why not. (the formalism that you didn't get the /32 under a model of consumption which assumed this kind of usage of the bits is really not a big deal for me personally, although I am sure it would upset some people) -G PS I am an RIR employee. I do not speak to policy in any formal sense. I work in research. On Tue, Jun 4, 2013 at 12:11 PM, Ivan Pepelnjak wrote= : > Read the recent "p2p /64" thread of ipv6-ops cluenet mailing list > > =3D=3D=3D=3D=3D > Mistyped and autocorrected on a clunky virtual keyboard > > On 4. jun. 2013, at 01:08, joel jaeggli wrote: > > > On 6/3/13 3:59 PM, Andrew McGregor wrote: > >> That's completely true; many switch chips cannot route on longer than > /64 prefixes, so attempting to do so starts to either heat up the softwar= e > slow path, or consume ACL entries, or is simply not supported at all. Whi= le > this is arguably a bug, it is also pretty much ubiquitous in the current > generation of ethernet switches, which are the basis for the majority of > routers. > > please cite specifics. I have no devices in the field that have such a > limitation. > > > > joel > >> > >> > >> On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com > wrote: > >> > >> On 04/06/2013 03:44, manning bill wrote: > >> > On 2June2013Sunday, at 16:47, Sander Steffann wrote: > >> > > >> >> On 03/06/2013 11:06, manning bill wrote: > >> >>> /48's are a horrible policy - one should only advertise what > >> one is actually using. > >> >> Now *that* would cause a nice fragmented DFZ... > >> >> Sander > >> >> > >> > > >> > > >> > I'm going to inject a route. One route. why do you care if its a > >> /9, a /28, a /47, or a /121? > >> > >> I've heard tell that there are routers that are designed to handle > >> prefixes up to /64 efficiently but have a much harder time with > >> prefixes longer than that, as a reasonable engineering trade-off. > >> Not being a router designer, I don't know how true this is. > >> > >> Brian > >> > >> Its -one- route. > >> > That one route covers everything I'm going to use=85 and nothing > >> I'm not. > >> > > >> > Is there a credible reason you want to be the vector of DDoS > >> attacks, by announcing dark space (by proxy aggregation)? > >> > Is that an operational liability you are willing to assume, just > >> so you can have "unfragmented" DFZ space? > >> > > >> > > >> > /bill > >> > >> -------------------------------------------------------------------= - > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------= - > >> > >> > >> > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > > > _______________________________________________ > > 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 > --bcaec544eb967b06fa04de4ba139 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Just to remind people, RIR policy is community driven. If = the operations people feel they need a policy for IPv6 allocations and assi= gnments which takes accounts of semantic bits, they can derive consensus dr= iven policies to do it. Its not done in the IETF. There might be an issue w= ith how it squares against IETF goals of conservation, but thats part of th= e discussion in RIR policy space maybe.

I think there is a touch of catch-22 here: there isn't a= clear sense this is an industry wide practice demanding that policy initia= tive (I do not preclude it: I just observe, it hasn't happened yet) and= there is an absence of a well understood methodology of using it and apply= ing it which differs radically in outcome from ACL based methods. If there = was an IETF standard I am sure somebody could propose an allocations model = which reflected it, but who knows if that would get traction.=A0

I notice that there are large providers who feel = semantic bit flagging works for them. So, I do not say "nobody is doin= g it" as much as "nobody has said they want an RIR allocations po= licy which reflects it, yet"

The first time this came up, I think I said= to mike that I could understand ISPs wanting to say "this is a mechan= ism we use inside our locus of control, to flag behaviours of packets"= -ie that it was unlikely there was a model for this to be meaningful betwe= en providers, but inside a single autonomous region, sure: why not. (the fo= rmalism that you didn't get the /32 under a model of consumption which = assumed this kind of usage of the bits is really not a big deal for me pers= onally, although I am sure it would upset some people)

-G

PS = I am an RIR employee. I do not speak to policy in any formal sense. I work = in research.


On Tue, Jun 4, 2013 at 12:11 PM, Ivan Pepelnjak <ipepelnjak@gmail.com> wrote:
Read the recent "p2p /64" thread of ipv6-ops cluenet mailing list=

=3D=3D=3D=3D=3D
Mistyped and autocorrected on a clunky virtual keyboard

On 4. jun. 2013, at 01:08, joel jaeggli <joelja@bogus.com> wrote:

> On 6/3/13 3:59 PM, Andrew McGregor wrote:
>> That's completely true; many switch chips cannot route on long= er than /64 prefixes, so attempting to do so starts to either heat up the s= oftware slow path, or consume ACL entries, or is simply not supported at al= l. While this is arguably a bug, it is also pretty much ubiquitous in the c= urrent generation of ethernet switches, which are the basis for the majorit= y of routers.
> please cite specifics. I have no devices in the field that have such a= limitation.
>
> joel
>>
>>
>> On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter <brian.e.carpenter@gmail.com <mail= to:brian.e.carpenter@gmail.c= om>> wrote:
>>
>> =A0 =A0On 04/06/2013 03:44, manning bill wrote:
>> =A0 =A0> On 2June2013Sunday, at 16:47, Sander Steffann wrote: >> =A0 =A0>
>> =A0 =A0>> On 03/06/2013 11:06, manning bill wrote:
>> =A0 =A0>>> /48's are a horrible policy - one should o= nly advertise what
>> =A0 =A0one is actually using.
>> =A0 =A0>> Now *that* would cause a nice fragmented DFZ... >> =A0 =A0>> Sander
>> =A0 =A0>>
>> =A0 =A0>
>> =A0 =A0>
>> =A0 =A0> I'm going to inject a route. One route. why do you= care if its a
>> =A0 =A0/9, a /28, a /47, or a /121?
>>
>> =A0 =A0I've heard tell that there are routers that are designe= d to handle
>> =A0 =A0prefixes up to /64 efficiently but have a much harder time = with
>> =A0 =A0prefixes longer than that, as a reasonable engineering trad= e-off.
>> =A0 =A0Not being a router designer, I don't know how true this= is.
>>
>> =A0 =A0Brian
>>
>> =A0 =A0Its -one- route.
>> =A0 =A0> That one route covers everything I'm going to use= =85 and nothing
>> =A0 =A0I'm not.
>> =A0 =A0>
>> =A0 =A0> Is there a credible reason you want to be the vector o= f DDoS
>> =A0 =A0attacks, by announcing dark space (by proxy aggregation)? >> =A0 =A0> Is that an operational liability you are willing to as= sume, just
>> =A0 =A0so you can have "unfragmented" DFZ space?
>> =A0 =A0>
>> =A0 =A0>
>> =A0 =A0> /bill
>>
>> =A0 =A0-----------------------------------------------------------= ---------
>> =A0 =A0IETF IPv6 working group mailing list
>> =A0 =A0ipv6@ietf.org <mail= to:ipv6@ietf.org>
>> =A0 =A0Administrative Requests: https://www.ietf.org/mailman/listinf= o/ipv6
>> =A0 =A0-----------------------------------------------------------= ---------
>>
>>
>>
>>
>> ------------------------------------------------------------------= --
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<= /a>
>> ------------------------------------------------------------------= --
>
> __________________= _____________________________
> 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

--bcaec544eb967b06fa04de4ba139-- From owen@delong.com Mon Jun 3 21:52:43 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CE821F9815; Mon, 3 Jun 2013 21:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8cQk9jANAiU; Mon, 3 Jun 2013 21:52:29 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B079921F8EF2; Mon, 3 Jun 2013 20:57:47 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r543rBt2000947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 Jun 2013 20:53:11 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r543rBt2000947 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370317992; bh=bxBrnv6rqcEnRDOIjULso7lppsY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=CDd7tulP//owMZ3JH86AKQFEjJvK+jyvM9dE9UGGuq2H2BMxWr+R+/cnlOrJLfoRU jbtXoTLtPvwBxpndPZzoZBTVm/zhQKFbAdjwiaNpYqfwwGNkcd9svkGmW4a4vx3/NP XbxeKJRbYE3zVJAxICMPMSggw6McSljpkOXELwyc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Owen DeLong In-Reply-To: Date: Mon, 3 Jun 2013 20:53:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@m! bx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> To: Sheng Jiang X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 03 Jun 2013 20:53:12 -0700 (PDT) Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ted Lemon , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 04:52:43 -0000 On Jun 3, 2013, at 17:59 , Sheng Jiang wrote: > This looks a typical double standard for me. You are willing to allow = homenet (the network operator in this case is subscribers) to play = semantic in their networks with the bits from 48 to 63, while you = disallow ISPs to set the semantic bits in their networks with the bits = from 20 to 48 or 56. You certainly have two theories for each of them. > =20 No, I have no desire to recommend semantic usage for bits 48-63, either. I do want those bits to belong to the subscriber and not be hijacked by = the provider. I was speaking in terms of likely automatic partitioning created by = routers, not semantics. Remember, these routers will be like LEGOs in = the future. The homenet user will expect to be able to arbitrarily plug = them together and have stuff just work. That's not semantics... That's something else. > To clarify myself, I am not really against the way giving bits for = homenets to better organize their networks. For me, this looks like a = variation of semantic prefix. If you have more concrete example how = homenet use their bits. I guess I can include them as the third type of = semantic prefix, besides ISP and enterprise. I think you need to take a better look. To me, what I am suggesting in = the homenet world has nothing to do with semantics (or if it does, the = semantics are coincidental) and everything to do with topology. Owen From shengjiang@gmail.com Mon Jun 3 20:52:10 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E4921E8183; Mon, 3 Jun 2013 20:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8eI79TYWrvt; Mon, 3 Jun 2013 20:52:00 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id C00F821E8196; Mon, 3 Jun 2013 19:56:23 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id fs12so4181054lab.35 for ; Mon, 03 Jun 2013 19:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xxMalC3hkosjPoiZ4ZW8vSJ+QlG609xYdMJOsB1Y/Q4=; b=yvPN50OyYnWsRgMWcQoV3yadm60PYzZ68vuisEAoq1M0fkAQMeEdqYbUEr6sAVA04H NYybbqdL5Te2OjHJ5ao/Uq23si6AfwhABAR4lET/PwJnVhvmBEzpx39X4pimGo89kcrn /bwkN0ZRPu4zxBI+mCAf20NlPvtdUpK57ArI9Ac/udu3EdqLpNyWepRTswLOaUD33ysR KE3eT3tmcCLNlx/7HJEPMQarWJrcYR+8U5kODuLOz95YC5tyxo8koqI3UaFLwBT6qKYK G65X+nefp04+f1IA9TmFBNV4zw5H3JkWXcXEkirCe67NumNZR8jEtok3V5choxsXL6Hy Qz6A== MIME-Version: 1.0 X-Received: by 10.112.157.129 with SMTP id wm1mr12022915lbb.69.1370314580791; Mon, 03 Jun 2013 19:56:20 -0700 (PDT) Received: by 10.112.67.166 with HTTP; Mon, 3 Jun 2013 19:56:20 -0700 (PDT) In-Reply-To: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <51ACA2F8.7060601@joelhalpern.com> <1808340F7EC362469DDFFB112B37E2FCC895DBD258@SRVHKE02.rdm.cz> Date: Tue, 4 Jun 2013 10:56:20 +0800 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Sheng Jiang To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=001a11c33fd2d194c904de4b39b3 X-Mailman-Approved-At: Mon, 03 Jun 2013 22:04:02 -0700 Cc: "" , "ipv6@ietf.org" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 03:52:10 -0000 --001a11c33fd2d194c904de4b39b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Semantic addresses is beyond the access control. For example, you can compare the security semantic bits of source and destination addresses. If they belong to different security domain, and you have a policy they should not communicate each other, you could drop the packet. Sheng On 4 June 2013 09:44, Lorenzo Colitti wrote: > On Mon, Jun 3, 2013 at 11:59 PM, V=C3=ADzdal Ale=C5=A1 wrote: > >> > If I am reading this correctly, in the end this is riven by the fact >> that existing boxes >> > can easily filter on addresses (although it will take a lot of >> filters), but can not apply >> > ACLs to DSCPs or extension headers? >> >> The current boxes can do both ACL filtering as well as DSCP mangling, bu= t >> as mentioned >> earlier the DSCP bits cannot be trusted, so a markdown/re-marking is >> required potentially >> involving DPI. Maintaining ACLs is also time consuming. >> > > I don't understand what the difference is. Why can the addresses be > trusted? Answer - because you drop packets if the host uses the wrong > address. But all the space is routed to the user anyway, and the semantic > bits only express semantics, right? Therefore you can't use routing or RP= F > to implement the drops, and you have to use an ACL. > > So if you have to use an ACL to do this anyway, then why can't you make > the ACL drop packets if the host uses the wrong DSCP codepoint? That way > you don't need to use extra address space. > --=20 Sheng Jiang =E8=92=8B=E8=83=9C --001a11c33fd2d194c904de4b39b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Semantic addresses is beyond the access control. For = example, you can compare the security semantic bits of source and destinati= on addresses. If they belong=C2=A0to different security domain, and you hav= e a policy they should not communicate each other, you could drop the packe= t.
=C2=A0
Sheng


<= div class=3D"gmail_quote">On 4 June 2013 09:44, Lorenzo Colitti <lorenz= o@google.com> wrote:
On Mon, J= un 3, 2013 at 11:59 PM, V=C3=ADzdal Ale=C5=A1 <ales.vizdal@t-mobile.= cz> wrote:
> If I am reading this correctly, in the end this is ri= ven by the fact that existing boxes
> can easily filter on addresses (although it will take a lot of filters= ), but can not apply
> ACLs to DSCPs or extension headers?

The current boxes can do both ACL filtering as well as DSCP mangling, but a= s mentioned
earlier the DSCP bits cannot be trusted, so a markdown/re-marking is requir= ed potentially
involving DPI. Maintaining ACLs is also time consuming.

I don't understand what the difference is. Why c= an the addresses be trusted? Answer - because you drop packets if the host = uses the wrong address. But all the space is routed to the user anyway, and= the semantic bits only express semantics, right? Therefore you can't u= se routing or RPF to implement the drops, and you have to use an ACL.

So if you have to use an ACL to do this anyway, then wh= y can't you make the ACL drop packets if the host uses the wrong DSCP c= odepoint? That way you don't need to use extra address space.



--
Sheng Jiang =E8=92=8B= =E8=83=9C --001a11c33fd2d194c904de4b39b3-- From joelja@bogus.com Mon Jun 3 22:19:13 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED5421E80A7; Mon, 3 Jun 2013 22:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XH5qTMXv74wj; Mon, 3 Jun 2013 22:19:01 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF4621F8B04; Mon, 3 Jun 2013 21:27:32 -0700 (PDT) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r544RQ7c002650 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 4 Jun 2013 04:27:29 GMT (envelope-from joelja@bogus.com) Message-ID: <51AD6CA8.1090909@bogus.com> Date: Mon, 03 Jun 2013 21:27:20 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Ivan Pepelnjak Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> <51ACFC3D.90709@gmail.com> <51AD2208.2010801@bogus.com> <4FDCE28C-0B1E-4A8E-AB73-044A9B4BEB07@gmail.com> In-Reply-To: <4FDCE28C-0B1E-4A8E-AB73-044A9B4BEB07@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 04 Jun 2013 04:27:30 +0000 (UTC) Cc: "v6ops@ietf.org WG" , manning bill , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 05:19:13 -0000 On 6/3/13 7:11 PM, Ivan Pepelnjak wrote: > Read the recent "p2p /64" thread of ipv6-ops cluenet mailing list You are refering to: http://lists.cluenet.de/pipermail/ipv6-ops/2013-June/thread.html I stand by my statement... The inability to properly apply ACLs on the 3750 for routes longer than /64 on some 3750 variants is a problem. A route is not an ACL. Using an mock modifed eui64 address for your loopback address so that your control-plane acl works properly seems asine I will give you that. http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_55_se/commmand/reference/cli2.html#wp11682185 cam tables are designed or partitioned in general to favor ipv4 route count over ipv6, while route table size is impacted that does not affect throughput. > ===== > Mistyped and autocorrected on a clunky virtual keyboard > > On 4. jun. 2013, at 01:08, joel jaeggli wrote: > >> On 6/3/13 3:59 PM, Andrew McGregor wrote: >>> That's completely true; many switch chips cannot route on longer than /64 prefixes, so attempting to do so starts to either heat up the software slow path, or consume ACL entries, or is simply not supported at all. While this is arguably a bug, it is also pretty much ubiquitous in the current generation of ethernet switches, which are the basis for the majority of routers. >> please cite specifics. I have no devices in the field that have such a limitation. >> >> joel >>> >>> On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter > wrote: >>> >>> On 04/06/2013 03:44, manning bill wrote: >>> > On 2June2013Sunday, at 16:47, Sander Steffann wrote: >>> > >>> >> On 03/06/2013 11:06, manning bill wrote: >>> >>> /48's are a horrible policy - one should only advertise what >>> one is actually using. >>> >> Now *that* would cause a nice fragmented DFZ... >>> >> Sander >>> >> >>> > >>> > >>> > I'm going to inject a route. One route. why do you care if its a >>> /9, a /28, a /47, or a /121? >>> >>> I've heard tell that there are routers that are designed to handle >>> prefixes up to /64 efficiently but have a much harder time with >>> prefixes longer than that, as a reasonable engineering trade-off. >>> Not being a router designer, I don't know how true this is. >>> >>> Brian >>> >>> Its -one- route. >>> > That one route covers everything I'm going to use… and nothing >>> I'm not. >>> > >>> > Is there a credible reason you want to be the vector of DDoS >>> attacks, by announcing dark space (by proxy aggregation)? >>> > Is that an operational liability you are willing to assume, just >>> so you can have "unfragmented" DFZ space? >>> > >>> > >>> > /bill >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >>> >>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From v6ops@globis.net Tue Jun 4 00:57:44 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5A821F9123; Tue, 4 Jun 2013 00:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoiL5zGjf+Vg; Tue, 4 Jun 2013 00:57:34 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0CC21F8D2B; Tue, 4 Jun 2013 00:02:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 9CE658700B2; Tue, 4 Jun 2013 09:01:58 +0200 (CEST) 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 2Q8UC187PP28; Tue, 4 Jun 2013 09:01:58 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 00622870089; Tue, 4 Jun 2013 09:01:57 +0200 (CEST) Message-ID: <51AD90DF.4090307@globis.net> Date: Tue, 04 Jun 2013 09:01:51 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Mark Smith Subject: Re: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <51ABC! C79.4090401@gmail.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <5! 1 ABD7B8.2010006@gmail.com> <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> <51ACFC3D.90709@gmail.com> <1370294177.86144.YahooMailNeo@web142502.mail.bf1.yahoo.com> In-Reply-To: <1370294177.86144.YahooMailNeo@web142502.mail.bf1.yahoo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org WG" , "ipv6@ietf.org" , manning bill X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 07:57:44 -0000 Mark Smith wrote: > > > ----- Original Message ----- >> From: Brian E Carpenter >> To: manning bill >> Cc: ipv6@ietf.org; "v6ops@ietf.org WG" >> Sent: Tuesday, 4 June 2013 6:27 AM >> Subject: Re: [v6ops] Could IPv6 address be more than > locator?//draft-jiang-v6ops-semantic-prefix-03 >> On 04/06/2013 03:44, manning bill wrote: >>> On 2June2013Sunday, at 16:47, Sander Steffann wrote: >>> >>>> On 03/06/2013 11:06, manning bill wrote: >>>>> /48's are a horrible policy - one should only advertise what >> one is actually using. >>>> Now *that* would cause a nice fragmented DFZ... >>>> Sander >>>> >>> I'm going to inject a route. One route. why do you care if its a /9, >> a /28, a /47, or a /121? >> >> I've heard tell that there are routers that are designed to handle >> prefixes up to /64 efficiently but have a much harder time with >> prefixes longer than that, as a reasonable engineering trade-off. >> Not being a router designer, I don't know how true this is. >> > > "right-sizing" prefixes to the number of hosts being used also has a cost, which is the constant cost of on-going adjustment of prefix size, including complete renumbering of the subnet if the specific prefix cannot be expanded further, and far more complex address space management. This is a cost was initially hidden in IPv4 by the fact that it became essential in IPv4 due to the size of IPv4's address space. RFC1918 and NAT subsequently predominantly eliminated it, by providing plenty of address space, and preventing that address space from being reachable from the Internet, the likely source of attacks on it. > > The issue with IPv6's large prefixes isn't really the specific size of the prefix, it is the exploitable state that is created during neighbor presence discovery. If the exploitability of this state is reduced, or better yet eliminated, via a host/address registration protocol, the amount of dark space announced doesn't matter. > > Regards, > Mark. I take this conclusion about ND being the only problem with a large operational dose of salt. AFAIK The only exploit we've seen up until now is neighbor presence discovery. So yes it's important to mitigate that, and I agree address registration is one potential solution. But 2^64 is a very large number. Anything that stores any sort of state about an IPv6 address/IID for any significant amount of time is a potential DOS target. Whether that be ND, a firewall forwarding table, a DNSBL, an IDP probe, a DHCPv6 server lease cache, a network management station status log, or a WFQ or netflow table in a router. No, I haven't seen anything like this yet in the wild, but to my mind good engineering would suggest that you size resources in a balanced way to match both upside (management convenience and difficulty to brute-force scan the address space) and downside (potential resource depletion). IMHO systems that service more than one segment should also take measures to ensure that depletion of any resources allocated to servicing a single /64 segment does not result in resource depletion for an entire site or enterprise. I don't want to lose my DHCPv6 enterprise server or forensic logging because an attacker has conquered one LAN and is sending lots of requests from 2^64 "unique" systems. Simple, appropriately sized, static, ingress filters have saved my bacon on more than one occasion. regards RayH > >> Brian >> >> Its -one- route. >>> That one route covers everything I'm going to use… and nothing I'm >> not. >>> Is there a credible reason you want to be the vector of DDoS attacks, by >> announcing dark space (by proxy aggregation)? >>> Is that an operational liability you are willing to assume, just so you can >> have "unfragmented" DFZ space? >>> /bill >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > From joelja@bogus.com Tue Jun 4 03:33:07 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEFA21F9BAE; Tue, 4 Jun 2013 03:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqvRKY4qEFIb; Tue, 4 Jun 2013 03:32:53 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id D782E21F9BB0; Tue, 4 Jun 2013 02:27:47 -0700 (PDT) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r549Rigd005439 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 4 Jun 2013 09:27:45 GMT (envelope-from joelja@bogus.com) Message-ID: <51ADB30B.8000204@bogus.com> Date: Tue, 04 Jun 2013 02:27:39 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Ivan Pepelnjak Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> <51ACFC3D.90709@gmail.com> <51AD2208.2010801@bogus.com> <4FDCE28C-0B1E-4A8E-AB73-044A9B4BEB07@gmail.com> <51AD6CA8.1090909@bogus.com> <003301ce60e1$03d93e00$0b8bba00$@com> In-Reply-To: <003301ce60e1$03d93e00$0b8bba00$@com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 04 Jun 2013 09:27:45 +0000 (UTC) Cc: v6ops@ietf.org, 'manning bill' , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 10:33:07 -0000 On 6/3/13 10:04 PM, Ivan Pepelnjak wrote: > Did you read the part about DC switches in general and Nexus 5500 in particular? Nexus 5500 is not a particularly capable layer 3 switch, due to the magic of cam partitioning it supports only 128 LPM (longer than 64bit route) entries for v6 so you'd better be prepared to summarize. Lets go back to the statement... > On 6/3/13 3:59 PM, Andrew McGregor wrote: >> That's completely true; many switch chips cannot route on longer >> than /64 prefixes, so attempting to do so starts to either heat up the software slow path, or consume ACL entries, or is simply not supported at all. While this is arguably a bug, it is also pretty much ubiquitous in the current generation of ethernet switches, which are the basis for the majority of routers. none of those statements are true when applied to the nexus 5500. > >> -----Original Message----- >> From: joel jaeggli [mailto:joelja@bogus.com] >> Sent: Tuesday, June 04, 2013 6:27 AM >> To: Ivan Pepelnjak >> Cc: Andrew McGregor; Brian E Carpenter; v6ops@ietf.org WG; ipv6@ietf.org; >> manning bill >> Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft- >> jiang-v6ops-semantic-prefix-03 >> >> On 6/3/13 7:11 PM, Ivan Pepelnjak wrote: >>> Read the recent "p2p /64" thread of ipv6-ops cluenet mailing list >> You are refering to: >> >> http://lists.cluenet.de/pipermail/ipv6-ops/2013-June/thread.html >> >> I stand by my statement... >> >> The inability to properly apply ACLs on the 3750 for routes longer than >> /64 on some 3750 variants is a problem. A route is not an ACL. Using an >> mock modifed eui64 address for your loopback address so that your control- >> plane acl works properly seems asine I will give you that. >> >> http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release >> /12.2_55_se/commmand/reference/cli2.html#wp11682185 >> >> cam tables are designed or partitioned in general to favor ipv4 route >> count over ipv6, while route table size is impacted that does not affect >> throughput. >> >>> ===== >>> Mistyped and autocorrected on a clunky virtual keyboard >>> >>> On 4. jun. 2013, at 01:08, joel jaeggli wrote: >>> >>>> On 6/3/13 3:59 PM, Andrew McGregor wrote: >>>>> That's completely true; many switch chips cannot route on longer than >> /64 prefixes, so attempting to do so starts to either heat up the software >> slow path, or consume ACL entries, or is simply not supported at all. >> While this is arguably a bug, it is also pretty much ubiquitous in the >> current generation of ethernet switches, which are the basis for the >> majority of routers. >>>> please cite specifics. I have no devices in the field that have such a >> limitation. >>>> joel >>>>> On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter >> > wrote: >>>>> On 04/06/2013 03:44, manning bill wrote: >>>>> > On 2June2013Sunday, at 16:47, Sander Steffann wrote: >>>>> > >>>>> >> On 03/06/2013 11:06, manning bill wrote: >>>>> >>> /48's are a horrible policy - one should only advertise what >>>>> one is actually using. >>>>> >> Now *that* would cause a nice fragmented DFZ... >>>>> >> Sander >>>>> >> >>>>> > >>>>> > >>>>> > I'm going to inject a route. One route. why do you care if its a >>>>> /9, a /28, a /47, or a /121? >>>>> >>>>> I've heard tell that there are routers that are designed to handle >>>>> prefixes up to /64 efficiently but have a much harder time with >>>>> prefixes longer than that, as a reasonable engineering trade-off. >>>>> Not being a router designer, I don't know how true this is. >>>>> >>>>> Brian >>>>> >>>>> Its -one- route. >>>>> > That one route covers everything I'm going to use… and nothing >>>>> I'm not. >>>>> > >>>>> > Is there a credible reason you want to be the vector of DDoS >>>>> attacks, by announcing dark space (by proxy aggregation)? >>>>> > Is that an operational liability you are willing to assume, just >>>>> so you can have "unfragmented" DFZ space? >>>>> > >>>>> > >>>>> > /bill >>>>> >>>>> ------------------------------------------------------------------ >> -- >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >>>>> -------------------------------------------------------------------- >>>>> >>>>> >>>>> >>>>> >>>>> -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>> -------------------------------------------------------------------- >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops > From bmanning@isi.edu Tue Jun 4 06:49:51 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2B921F9E2E; Tue, 4 Jun 2013 06:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6O-KYgHccFBW; Tue, 4 Jun 2013 06:49:37 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 8746B21F9A15; Tue, 4 Jun 2013 05:16:41 -0700 (PDT) Received: from [128.9.184.118] ([128.9.184.118]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r54CGKxo012027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 4 Jun 2013 05:16:20 -0700 (PDT) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: manning bill In-Reply-To: <51ACFC3D.90709@gmail.com> Date: Tue, 4 Jun 2013 05:16:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <51ABC! C79.4090401@gmail.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <5! 1 ABD7B8.2010006@gmail.com> <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> <51ACFC3D.90709@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1283) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu Cc: ipv6@ietf.org, "v6ops@ietf.org WG" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 13:49:52 -0000 i've heard that too. hardware designers going for the 80% solution. = However /64 is -NOT- part of the IPv6 spec. the hardware is supposed to support bit masking across the range. /bill On 3June2013Monday, at 13:27, Brian E Carpenter wrote: > On 04/06/2013 03:44, manning bill wrote: >> On 2June2013Sunday, at 16:47, Sander Steffann wrote: >>=20 >>> On 03/06/2013 11:06, manning bill wrote: >>>> /48's are a horrible policy - one should only advertise what one is = actually using. >>> Now *that* would cause a nice fragmented DFZ... >>> Sander >>>=20 >>=20 >>=20 >> I'm going to inject a route. One route. why do you care if its a = /9, a /28, a /47, or a /121? >=20 > I've heard tell that there are routers that are designed to handle > prefixes up to /64 efficiently but have a much harder time with > prefixes longer than that, as a reasonable engineering trade-off. > Not being a router designer, I don't know how true this is. >=20 > Brian >=20 > Its -one- route. >> That one route covers everything I'm going to use=85 and nothing I'm = not. >>=20 >> Is there a credible reason you want to be the vector of DDoS attacks, = by announcing dark space (by proxy aggregation)? >> Is that an operational liability you are willing to assume, just so = you can have "unfragmented" DFZ space? >>=20 >>=20 >> /bill >=20 From bmanning@isi.edu Tue Jun 4 08:55:39 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADB821F9ECA; Tue, 4 Jun 2013 08:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id En9lUx3BFsUG; Tue, 4 Jun 2013 08:55:22 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 94C6C21F9C8C; Tue, 4 Jun 2013 06:51:31 -0700 (PDT) Received: from [128.9.184.118] ([128.9.184.118]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r54Dp4ii009533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 4 Jun 2013 06:51:05 -0700 (PDT) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=utf-8 From: manning bill In-Reply-To: Date: Tue, 4 Jun 2013 06:51:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <392D823E-36C6-4A25-960A-F6AE783482C2@isi.edu> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> <51ACFC3D.90709@gmail.com> <51AD2208.2010801@bogus.com> <4FDCE28C-0B1E-4A8E-AB73-044A9B4! BEB07@gmail.com> To: Sheng Jiang X-Mailer: Apple Mail (2.1283) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu Cc: Ivan Pepelnjak , "v6ops@ietf.org WG" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 15:55:44 -0000 are you intending to document -all- variants of the semantics address = holder may use to address and organize their assigned numbers? or are you intending to document a "preferred" version of address = semantics? /bill On 4June2013Tuesday, at 6:24, Sheng Jiang wrote: > Hi, George, > =20 > Yes, network operators have the freedom to plan the address in their = prefer ways. There are many different ways to organize address schemas. = Different network operators (including both ISPs and enterprises) has = various considerations. Some consideration may be important for one = network operator while makes much less sense for others. Why rule out = others possibilities or mechanism by saying I have reasons to do things = in my way? There are ISPs and enterprises who have chosen to embed their = cared semantics into address and organize network or routing polices = accordingly. We need to document this and give the analysis we could. > =20 > Cheers, > =20 > Sheng >=20 >=20 > On 4 June 2013 11:25, George Michaelson wrote: > Just to remind people, RIR policy is community driven. If the = operations people feel they need a policy for IPv6 allocations and = assignments which takes accounts of semantic bits, they can derive = consensus driven policies to do it. Its not done in the IETF. There = might be an issue with how it squares against IETF goals of = conservation, but thats part of the discussion in RIR policy space = maybe. >=20 > I think there is a touch of catch-22 here: there isn't a clear sense = this is an industry wide practice demanding that policy initiative (I do = not preclude it: I just observe, it hasn't happened yet) and there is an = absence of a well understood methodology of using it and applying it = which differs radically in outcome from ACL based methods. If there was = an IETF standard I am sure somebody could propose an allocations model = which reflected it, but who knows if that would get traction.=20 >=20 > I notice that there are large providers who feel semantic bit flagging = works for them. So, I do not say "nobody is doing it" as much as "nobody = has said they want an RIR allocations policy which reflects it, yet" >=20 > The first time this came up, I think I said to mike that I could = understand ISPs wanting to say "this is a mechanism we use inside our = locus of control, to flag behaviours of packets" -ie that it was = unlikely there was a model for this to be meaningful between providers, = but inside a single autonomous region, sure: why not. (the formalism = that you didn't get the /32 under a model of consumption which assumed = this kind of usage of the bits is really not a big deal for me = personally, although I am sure it would upset some people) >=20 > -G >=20 > PS I am an RIR employee. I do not speak to policy in any formal sense. = I work in research. >=20 >=20 > On Tue, Jun 4, 2013 at 12:11 PM, Ivan Pepelnjak = wrote: > Read the recent "p2p /64" thread of ipv6-ops cluenet mailing list >=20 > =3D=3D=3D=3D=3D > Mistyped and autocorrected on a clunky virtual keyboard >=20 > On 4. jun. 2013, at 01:08, joel jaeggli wrote: >=20 > > On 6/3/13 3:59 PM, Andrew McGregor wrote: > >> That's completely true; many switch chips cannot route on longer = than /64 prefixes, so attempting to do so starts to either heat up the = software slow path, or consume ACL entries, or is simply not supported = at all. While this is arguably a bug, it is also pretty much ubiquitous = in the current generation of ethernet switches, which are the basis for = the majority of routers. > > please cite specifics. I have no devices in the field that have such = a limitation. > > > > joel > >> > >> > >> On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter = > = wrote: > >> > >> On 04/06/2013 03:44, manning bill wrote: > >> > On 2June2013Sunday, at 16:47, Sander Steffann wrote: > >> > > >> >> On 03/06/2013 11:06, manning bill wrote: > >> >>> /48's are a horrible policy - one should only advertise what > >> one is actually using. > >> >> Now *that* would cause a nice fragmented DFZ... > >> >> Sander > >> >> > >> > > >> > > >> > I'm going to inject a route. One route. why do you care if its = a > >> /9, a /28, a /47, or a /121? > >> > >> I've heard tell that there are routers that are designed to = handle > >> prefixes up to /64 efficiently but have a much harder time with > >> prefixes longer than that, as a reasonable engineering = trade-off. > >> Not being a router designer, I don't know how true this is. > >> > >> Brian > >> > >> Its -one- route. > >> > That one route covers everything I'm going to use=E2=80=A6 and = nothing > >> I'm not. > >> > > >> > Is there a credible reason you want to be the vector of DDoS > >> attacks, by announcing dark space (by proxy aggregation)? > >> > Is that an operational liability you are willing to assume, = just > >> so you can have "unfragmented" DFZ space? > >> > > >> > > >> > /bill > >> > >> = -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6 > >> = -------------------------------------------------------------------- > >> > >> > >> > >> > >> = -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> = -------------------------------------------------------------------- > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 > --=20 > Sheng Jiang =E8=92=8B=E8=83=9C From bmanning@isi.edu Tue Jun 4 09:57:09 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0843C21F9C4F; Tue, 4 Jun 2013 09:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRbjNd7S43tl; Tue, 4 Jun 2013 09:56:54 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4898D21F9A6A; Tue, 4 Jun 2013 07:44:49 -0700 (PDT) Received: from [128.9.184.118] ([128.9.184.118]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r54EiOlo000874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 4 Jun 2013 07:44:24 -0700 (PDT) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=GB2312 From: manning bill In-Reply-To: Date: Tue, 4 Jun 2013 07:44:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <634198A4-5A4E-4B59-9B16-311160330A98@isi.edu> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> <51ACFC3D.90709@gmail.com> <51AD2208.2010801@bogus.com> <392D823E-36C6-4A25-960A-F6AE783482C2@isi.edu> To: Sheng Jiang X-Mailer: Apple Mail (2.1283) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu Cc: Ivan Pepelnjak , "v6ops@ietf.org WG" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 16:57:09 -0000 I believe this is fraught with danger. It perhaps better to identify semantic constructs than to presuppose = representative cases. things like even/odd for in/out-bound links, lat/log encoding or other geo-location etc. as a survey of technique. /bill On 4June2013Tuesday, at 7:32, Sheng Jiang wrote: > For sure, we cannot document all variants, but we can document the = most representative ones. My current plan is three categeries: ISP's, = enterprise's and subscribe's. Each categery has one example (in = appendexes), I guess. > =20 > Cheers, > =20 > Sheng >=20 >=20 > On 4 June 2013 21:51, manning bill wrote: > are you intending to document -all- variants of the semantics address = holder may use to address and organize their assigned numbers? > or are you intending to document a "preferred" version of address = semantics? >=20 > /bill >=20 >=20 > On 4June2013Tuesday, at 6:24, Sheng Jiang wrote: >=20 > > Hi, George, > > > > Yes, network operators have the freedom to plan the address in their = prefer ways. There are many different ways to organize address schemas. = Different network operators (including both ISPs and enterprises) has = various considerations. Some consideration may be important for one = network operator while makes much less sense for others. Why rule out = others possibilities or mechanism by saying I have reasons to do things = in my way? There are ISPs and enterprises who have chosen to embed their = cared semantics into address and organize network or routing polices = accordingly. We need to document this and give the analysis we could. > > > > Cheers, > > > > Sheng > > > > > > On 4 June 2013 11:25, George Michaelson wrote: > > Just to remind people, RIR policy is community driven. If the = operations people feel they need a policy for IPv6 allocations and = assignments which takes accounts of semantic bits, they can derive = consensus driven policies to do it. Its not done in the IETF. There = might be an issue with how it squares against IETF goals of = conservation, but thats part of the discussion in RIR policy space = maybe. > > > > I think there is a touch of catch-22 here: there isn't a clear sense = this is an industry wide practice demanding that policy initiative (I do = not preclude it: I just observe, it hasn't happened yet) and there is an = absence of a well understood methodology of using it and applying it = which differs radically in outcome from ACL based methods. If there was = an IETF standard I am sure somebody could propose an allocations model = which reflected it, but who knows if that would get traction. > > > > I notice that there are large providers who feel semantic bit = flagging works for them. So, I do not say "nobody is doing it" as much = as "nobody has said they want an RIR allocations policy which reflects = it, yet" > > > > The first time this came up, I think I said to mike that I could = understand ISPs wanting to say "this is a mechanism we use inside our = locus of control, to flag behaviours of packets" -ie that it was = unlikely there was a model for this to be meaningful between providers, = but inside a single autonomous region, sure: why not. (the formalism = that you didn't get the /32 under a model of consumption which assumed = this kind of usage of the bits is really not a big deal for me = personally, although I am sure it would upset some people) > > > > -G > > > > PS I am an RIR employee. I do not speak to policy in any formal = sense. I work in research. > > > > > > On Tue, Jun 4, 2013 at 12:11 PM, Ivan Pepelnjak = wrote: > > Read the recent "p2p /64" thread of ipv6-ops cluenet mailing list > > > > =3D=3D=3D=3D=3D > > Mistyped and autocorrected on a clunky virtual keyboard > > > > On 4. jun. 2013, at 01:08, joel jaeggli wrote: > > > > > On 6/3/13 3:59 PM, Andrew McGregor wrote: > > >> That's completely true; many switch chips cannot route on longer = than /64 prefixes, so attempting to do so starts to either heat up the = software slow path, or consume ACL entries, or is simply not supported = at all. While this is arguably a bug, it is also pretty much ubiquitous = in the current generation of ethernet switches, which are the basis for = the majority of routers. > > > please cite specifics. I have no devices in the field that have = such a limitation. > > > > > > joel > > >> > > >> > > >> On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter = > = wrote: > > >> > > >> On 04/06/2013 03:44, manning bill wrote: > > >> > On 2June2013Sunday, at 16:47, Sander Steffann wrote: > > >> > > > >> >> On 03/06/2013 11:06, manning bill wrote: > > >> >>> /48's are a horrible policy - one should only advertise = what > > >> one is actually using. > > >> >> Now *that* would cause a nice fragmented DFZ... > > >> >> Sander > > >> >> > > >> > > > >> > > > >> > I'm going to inject a route. One route. why do you care if = its a > > >> /9, a /28, a /47, or a /121? > > >> > > >> I've heard tell that there are routers that are designed to = handle > > >> prefixes up to /64 efficiently but have a much harder time = with > > >> prefixes longer than that, as a reasonable engineering = trade-off. > > >> Not being a router designer, I don't know how true this is. > > >> > > >> Brian > > >> > > >> Its -one- route. > > >> > That one route covers everything I'm going to use=A1=AD and = nothing > > >> I'm not. > > >> > > > >> > Is there a credible reason you want to be the vector of DDoS > > >> attacks, by announcing dark space (by proxy aggregation)? > > >> > Is that an operational liability you are willing to assume, = just > > >> so you can have "unfragmented" DFZ space? > > >> > > > >> > > > >> > /bill > > >> > > >> = -------------------------------------------------------------------- > > >> IETF IPv6 working group mailing list > > >> ipv6@ietf.org > > >> Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6 > > >> = -------------------------------------------------------------------- > > >> > > >> > > >> > > >> > > >> = -------------------------------------------------------------------- > > >> IETF IPv6 working group mailing list > > >> ipv6@ietf.org > > >> Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6 > > >> = -------------------------------------------------------------------- > > > > > > _______________________________________________ > > > 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 > > > > > > > > > > -- > > Sheng Jiang =BD=AF=CA=A4 >=20 >=20 >=20 >=20 > --=20 > Sheng Jiang =BD=AF=CA=A4 From owen@delong.com Tue Jun 4 10:16:31 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF2521E809F; Tue, 4 Jun 2013 10:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVypCemozqMW; Tue, 4 Jun 2013 10:16:26 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2DF21F9CC5; Tue, 4 Jun 2013 08:18:55 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r54FCxfl016063 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 4 Jun 2013 08:12:59 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r54FCxfl016063 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370358780; bh=TDZbW5z5lHDa/IWh1UFj4Mi6PTg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=lot1pBd6DBpuuWkExcdKCTiaYBMC11qTYre3IMkg3fjfcym616eGtz2AX3PaQc0WH wNMeQcAs7Zoxz1iUt2ZRj0htERvEu6RPz1lruZvw/ivphvCQfi93EN0xrNd8IaIle5 fyHrVsuUlkLiEBu/uj+HU1RtKPLi7ZiHQEaz944E= Content-Type: multipart/alternative; boundary="Apple-Mail=_AEEADAFB-1C90-4BE1-AD74-9A1D3194C6DB" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Owen DeLong In-Reply-To: Date: Tue, 4 Jun 2013 08:12:59 -0700 Message-Id: <050AD4E8-31AA-41DD-A137-06A8542D8C21@delong.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delon! g.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> To: Sheng Jiang X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 04 Jun 2013 08:13:00 -0700 (PDT) Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ted Lemon , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:16:31 -0000 --Apple-Mail=_AEEADAFB-1C90-4BE1-AD74-9A1D3194C6DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I don't rule out anything. I state that the bits should be there so that = automated topologies can be made to function in an arbitrary = plug-and-play environment. If it can be used for other purposes, that's fine, but I do not suggest = that we should support those other purposes officially. OTOH, because of the first use case that I do feel we should continue to = support officially, I do not support stealing those bits from the end = user for the purposes of ISP semantic addressing. Owen On Jun 4, 2013, at 06:14 , Sheng Jiang wrote: > I do understand your hierarical allocation is only topology. But do = you think that's the only way subscriber, who has 16 bits, may organize = their subnets. How could you rule out all other posibilities by = suggesting you have one of the good ways to do things? > =20 > Cheers, > =20 > Sheng >=20 >=20 > On 4 June 2013 11:53, Owen DeLong wrote: >=20 > On Jun 3, 2013, at 17:59 , Sheng Jiang wrote: >=20 > > This looks a typical double standard for me. You are willing to = allow homenet (the network operator in this case is subscribers) to play = semantic in their networks with the bits from 48 to 63, while you = disallow ISPs to set the semantic bits in their networks with the bits = from 20 to 48 or 56. You certainly have two theories for each of them. > > >=20 > No, I have no desire to recommend semantic usage for bits 48-63, = either. >=20 > I do want those bits to belong to the subscriber and not be hijacked = by the provider. >=20 > I was speaking in terms of likely automatic partitioning created by = routers, not semantics. Remember, these routers will be like LEGOs in = the future. The homenet user will expect to be able to arbitrarily plug = them together and have stuff just work. >=20 > That's not semantics... That's something else. >=20 > > To clarify myself, I am not really against the way giving bits for = homenets to better organize their networks. For me, this looks like a = variation of semantic prefix. If you have more concrete example how = homenet use their bits. I guess I can include them as the third type of = semantic prefix, besides ISP and enterprise. >=20 > I think you need to take a better look. To me, what I am suggesting in = the homenet world has nothing to do with semantics (or if it does, the = semantics are coincidental) and everything to do with topology. >=20 > Owen >=20 >=20 >=20 >=20 > --=20 > Sheng Jiang =E8=92=8B=E8=83=9C --Apple-Mail=_AEEADAFB-1C90-4BE1-AD74-9A1D3194C6DB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = don't rule out anything. I state that the bits should be there so that = automated topologies can be made to function in an arbitrary = plug-and-play environment.

If it can be used for = other purposes, that's fine, but I do not suggest that we should support = those other purposes officially.

OTOH, because = of the first use case that I do feel we should continue to support = officially, I do not support stealing those bits from the end user for = the purposes of ISP semantic = addressing.

Owen

On Jun = 4, 2013, at 06:14 , Sheng Jiang <shengjiang@gmail.com> = wrote:

I do understand your hierarical = allocation is only topology. But do you think that's the only way = subscriber, who has 16 bits, may organize their subnets. How could you = rule out all other posibilities by suggesting you have one of the good = ways to do things?
=
 
Cheers,
 
Sheng
=


On 4 June = 2013 11:53, Owen DeLong <owen@delong.com> wrote:

On Jun 3, 2013, at 17:59 , Sheng Jiang <shengjiang@gmail.com> = wrote:

> This looks a typical double standard for me. You are willing to = allow homenet (the network operator in this case is subscribers) to play = semantic in their networks with the bits from 48 to 63, while you = disallow ISPs to set the semantic bits in their networks with the bits = from 20 to 48 or 56. You certainly have two theories for each of = them.
>

No, I have no desire to recommend semantic usage for bits 48-63, = either.

I do want those bits to belong to the subscriber and not be hijacked by = the provider.

I was speaking in terms of likely automatic partitioning created by = routers, not semantics. Remember, these routers will be like LEGOs in = the future. The homenet user will expect to be able to arbitrarily plug = them together and have stuff just work.

That's not semantics... That's something else.

> To clarify myself, I am not really against the way giving bits for = homenets to better organize their networks. For me, this looks like a = variation of semantic prefix. If you have more concrete example how = homenet use their bits. I guess I can include them as the third type of = semantic prefix, besides ISP and enterprise.

I think you need to take a better look. To me, what I am = suggesting in the homenet world has nothing to do with semantics (or if = it does, the semantics are coincidental) and everything to do with = topology.

Owen




--
Sheng = Jiang =E8=92=8B=E8=83=9C

= --Apple-Mail=_AEEADAFB-1C90-4BE1-AD74-9A1D3194C6DB-- From ipepelnjak@gmail.com Mon Jun 3 23:12:28 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC2C21F9AE9; Mon, 3 Jun 2013 23:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORcEr7rdvE9f; Mon, 3 Jun 2013 23:12:17 -0700 (PDT) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id DA7BE21E8186; Mon, 3 Jun 2013 22:04:39 -0700 (PDT) Received: by mail-ea0-f178.google.com with SMTP id q15so4167022ead.23 for ; Mon, 03 Jun 2013 22:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=Y8dV70UjwR/moyEX3Fczlo50VucYw/vBKIr4/9tldko=; b=clzPD9L+K3fHo3mgTy0HKAxz6Uqhkhd+1zz8m75w87vyHTrrvLZjQDdOGp15c4ytbe 0jKGjhfkaF7lndYP/1VthO3gJXGjyTOw7D5ORtOqXAGQC/gHydgPi+q9v66bFABk2b7g u6ErIryZ3QSFHEHPXhEHVmFLqMc8+KCHVZUh0B4V3RhOlZJwX1S/xoRZUYQnI/RKFXYk kdwMhmcacuHvNsIifqrtZXxSZL4KMnF0/LMjqIponuXfevIKX0gMehs6DswcT2rceBbi 4lQFUkRyJATNSleiYWy/ODZPtI30BJ25IK/LUfNMyPsVckl3VW2iYafwnCcD6Cu2pKxU YTkA== X-Received: by 10.15.44.10 with SMTP id y10mr25442532eev.5.1370322278927; Mon, 03 Jun 2013 22:04:38 -0700 (PDT) Received: from PIPINB2009 (BSN-61-33-18.dial-up.dsl.siol.net. [86.61.33.18]) by mx.google.com with ESMTPSA id y2sm89141514eeu.2.2013.06.03.22.04.37 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 03 Jun 2013 22:04:38 -0700 (PDT) From: "Ivan Pepelnjak" To: "'joel jaeggli'" References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> <51ACFC3D.90709@gmail.com> <51AD2208.2010801@bogus.com> <4FDCE28C-0B1E-4A8E-AB73-044A9B4BEB07@gmail.com> <51AD6CA8.1090909@bogus.com> In-Reply-To: <51AD6CA8.1090909@bogus.com> Subject: RE: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Date: Tue, 4 Jun 2013 07:04:37 +0200 Message-ID: <003301ce60e1$03d93e00$0b8bba00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5g29UeiB6IqNOPRrSRQMPL90rspgABSFTA Content-Language: sl X-Mailman-Approved-At: Tue, 04 Jun 2013 10:41:03 -0700 Cc: v6ops@ietf.org, 'manning bill' , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 06:12:28 -0000 Did you read the part about DC switches in general and Nexus 5500 in = particular? > -----Original Message----- > From: joel jaeggli [mailto:joelja@bogus.com] > Sent: Tuesday, June 04, 2013 6:27 AM > To: Ivan Pepelnjak > Cc: Andrew McGregor; Brian E Carpenter; v6ops@ietf.org WG; = ipv6@ietf.org; > manning bill > Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft- > jiang-v6ops-semantic-prefix-03 >=20 > On 6/3/13 7:11 PM, Ivan Pepelnjak wrote: > > Read the recent "p2p /64" thread of ipv6-ops cluenet mailing list > You are refering to: >=20 > http://lists.cluenet.de/pipermail/ipv6-ops/2013-June/thread.html >=20 > I stand by my statement... >=20 > The inability to properly apply ACLs on the 3750 for routes longer = than > /64 on some 3750 variants is a problem. A route is not an ACL. Using = an > mock modifed eui64 address for your loopback address so that your = control- > plane acl works properly seems asine I will give you that. >=20 > = http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/releas= e > /12.2_55_se/commmand/reference/cli2.html#wp11682185 >=20 > cam tables are designed or partitioned in general to favor ipv4 route > count over ipv6, while route table size is impacted that does not = affect > throughput. >=20 > > =3D=3D=3D=3D=3D > > Mistyped and autocorrected on a clunky virtual keyboard > > > > On 4. jun. 2013, at 01:08, joel jaeggli wrote: > > > >> On 6/3/13 3:59 PM, Andrew McGregor wrote: > >>> That's completely true; many switch chips cannot route on longer = than > /64 prefixes, so attempting to do so starts to either heat up the = software > slow path, or consume ACL entries, or is simply not supported at all. > While this is arguably a bug, it is also pretty much ubiquitous in the > current generation of ethernet switches, which are the basis for the > majority of routers. > >> please cite specifics. I have no devices in the field that have = such a > limitation. > >> > >> joel > >>> > >>> On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter > > = wrote: > >>> > >>> On 04/06/2013 03:44, manning bill wrote: > >>> > On 2June2013Sunday, at 16:47, Sander Steffann wrote: > >>> > > >>> >> On 03/06/2013 11:06, manning bill wrote: > >>> >>> /48's are a horrible policy - one should only advertise = what > >>> one is actually using. > >>> >> Now *that* would cause a nice fragmented DFZ... > >>> >> Sander > >>> >> > >>> > > >>> > > >>> > I'm going to inject a route. One route. why do you care if = its a > >>> /9, a /28, a /47, or a /121? > >>> > >>> I've heard tell that there are routers that are designed to = handle > >>> prefixes up to /64 efficiently but have a much harder time = with > >>> prefixes longer than that, as a reasonable engineering = trade-off. > >>> Not being a router designer, I don't know how true this is. > >>> > >>> Brian > >>> > >>> Its -one- route. > >>> > That one route covers everything I'm going to use=E2=80=A6 = and nothing > >>> I'm not. > >>> > > >>> > Is there a credible reason you want to be the vector of DDoS > >>> attacks, by announcing dark space (by proxy aggregation)? > >>> > Is that an operational liability you are willing to assume, = just > >>> so you can have "unfragmented" DFZ space? > >>> > > >>> > > >>> > /bill > >>> > >>> = ------------------------------------------------------------------ > -- > >>> IETF IPv6 working group mailing list > >>> ipv6@ietf.org > >>> Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > >>> > >>> = -------------------------------------------------------------------- > >>> > >>> > >>> > >>> > >>> = -------------------------------------------------------------------- > >>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>> = -------------------------------------------------------------------- > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops From shengjiang@gmail.com Tue Jun 4 08:04:22 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A1F21F9C37; Tue, 4 Jun 2013 08:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.173 X-Spam-Level: X-Spam-Status: No, score=-3.173 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+4X2gVkQaRt; Tue, 4 Jun 2013 08:03:52 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 254BF21F9C4B; Tue, 4 Jun 2013 06:15:02 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id p10so638317lbi.3 for ; Tue, 04 Jun 2013 06:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y0K+q+DG481FQEAJMsXjYrq3ad4uAizvYdDkSL+PDxY=; b=w3j1AS9KssbY0acIei5AyJPZ87OVe9MdYBbciolzCzGMObm0vU6KvbzgaWITapA4y6 Alz9PvXP0K/r6jCfkjN6NoCJ9SdWFHesRAcyWZeJs0CIB3IOlr84KdQSws/4uc/elK+J mzME82mPs0W0ukKKOT4SjNaaQ6eIcxB88v4gpcw20u4QqpSGpCEvRAmRMcchptufAF6/ wqsmfaMdq65ZbGtIvD1S0b3kguSESIPWwM1SXci399SHGXcTFu4I3TJWpOrmRS0S6eQJ Kh2PI5AtjvLs/bfrP5sV4Qrwo0rBypeuanIgkH4zDXh5KVHyKObvZIwVgXERSm5o+9oe RvLQ== MIME-Version: 1.0 X-Received: by 10.112.171.165 with SMTP id av5mr5898674lbc.48.1370351697698; Tue, 04 Jun 2013 06:14:57 -0700 (PDT) Received: by 10.112.67.166 with HTTP; Tue, 4 Jun 2013 06:14:57 -0700 (PDT) In-Reply-To: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> Date: Tue, 4 Jun 2013 21:14:57 +0800 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Sheng Jiang To: Owen DeLong Content-Type: multipart/alternative; boundary=001a11c377da28a48204de53de8b X-Mailman-Approved-At: Tue, 04 Jun 2013 10:41:04 -0700 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ted Lemon , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 15:04:22 -0000 --001a11c377da28a48204de53de8b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I do understand your hierarical allocation is only topology. But do you think that's the only way subscriber, who has 16 bits, may organize their subnets. How could you rule out all other posibilities by suggesting you have one of the good ways to do things? Cheers, Sheng On 4 June 2013 11:53, Owen DeLong wrote: > > On Jun 3, 2013, at 17:59 , Sheng Jiang wrote: > > > This looks a typical double standard for me. You are willing to allow > homenet (the network operator in this case is subscribers) to play semant= ic > in their networks with the bits from 48 to 63, while you disallow ISPs to > set the semantic bits in their networks with the bits from 20 to 48 or 56= . > You certainly have two theories for each of them. > > > > No, I have no desire to recommend semantic usage for bits 48-63, either. > > I do want those bits to belong to the subscriber and not be hijacked by > the provider. > > I was speaking in terms of likely automatic partitioning created by > routers, not semantics. Remember, these routers will be like LEGOs in the > future. The homenet user will expect to be able to arbitrarily plug them > together and have stuff just work. > > That's not semantics... That's something else. > > > To clarify myself, I am not really against the way giving bits for > homenets to better organize their networks. For me, this looks like a > variation of semantic prefix. If you have more concrete example how homen= et > use their bits. I guess I can include them as the third type of semantic > prefix, besides ISP and enterprise. > > I think you need to take a better look. To me, what I am suggesting in th= e > homenet world has nothing to do with semantics (or if it does, the > semantics are coincidental) and everything to do with topology. > > Owen > > --=20 Sheng Jiang =E8=92=8B=E8=83=9C --001a11c377da28a48204de53de8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I do understand your hierarical allocation is only to= pology. But do you think that's the only way subscriber, who has 16 bit= s, may organize their subnets. How could you rule out all other posibilitie= s by suggesting you have one of the good ways to do things?
=C2=A0
Cheers,
=C2=A0
Sheng
<= div class=3D"gmail_extra">

On 4 June 2013= 11:53, Owen DeLong <owen@delong.com> wrote:

On Jun 3, 2013, at 17:59 , Sheng Jiang <shengjiang@gmail.com> wrote:

> This looks a typical double standard for me. You are willing to allow = homenet (the network operator in this case is subscribers) to play semantic= in their networks with the bits from 48 to 63, while you disallow ISPs to = set the semantic bits in their networks with the bits from 20 to 48 or 56. = You certainly have two theories for each of them.
>

No, I have no desire to recommend semantic usage for bits 48-63, eith= er.

I do want those bits to belong to the subscriber and not be hijacked by the= provider.

I was speaking in terms of likely automatic partitioning created by routers= , not semantics. Remember, these routers will be like LEGOs in the future. = The homenet user will expect to be able to arbitrarily plug them together a= nd have stuff just work.

That's not semantics... That's something else.

> To clarify myself, I am not really against the way giving bits for hom= enets to better organize their networks. For me, this looks like a variatio= n of semantic prefix. If you have more concrete example how homenet use the= ir bits. I guess I can include them as the third type of semantic prefix, b= esides ISP and enterprise.

I think you need to take a better look. To me, what I am suggesting i= n the homenet world has nothing to do with semantics (or if it does, the se= mantics are coincidental) and everything to do with topology.

Owen




--
Sheng Jia= ng =E8=92=8B=E8=83=9C --001a11c377da28a48204de53de8b-- From shengjiang@gmail.com Tue Jun 4 08:17:03 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7882821F9BF8; Tue, 4 Jun 2013 08:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.958 X-Spam-Level: X-Spam-Status: No, score=-2.958 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zzb3PgW+KdIj; Tue, 4 Jun 2013 08:16:49 -0700 (PDT) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2F021F9C98; Tue, 4 Jun 2013 06:24:38 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id d10so649016lbj.28 for ; Tue, 04 Jun 2013 06:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bHlXX7HcLXGcYmSouo+DOIL63DMe3cpkCblqin+Hx0s=; b=Zb8mD8i5JY1pqQLGGWqZq0Vmo57I2E3+K9SniwNurv80laVySM/A951/rabzqxaXeE AYMWYy+vJNmgU+bT1zv0MtMydjw/aRSCyJvm5kkDB811+gW9gPvvTjt3FcFmX/N5TlNW OcjeH77MjQ33hQrPp/GxRiJJUtf62HEIn5SUK7kJcaE8j24zRUuHeBzDO6tQUONOmTnW 3cAsqBbZ9WrOZlkhCAFbh+Bn/0xyldIXYEIGW2P6BdZykpwn5J7VVd+cxofVQ6NZBy+A nnKwuhsPtKUYdkQrD8AAR1EXVBUheTcgumJIneQS9cQiYTjbWStFxxsTKKdreoPyzL1Y uAkA== MIME-Version: 1.0 X-Received: by 10.152.19.166 with SMTP id g6mr13064147lae.4.1370352277598; Tue, 04 Jun 2013 06:24:37 -0700 (PDT) Received: by 10.112.67.166 with HTTP; Tue, 4 Jun 2013 06:24:37 -0700 (PDT) In-Reply-To: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> <51ACFC3D.90709@gmail.com> <51AD2208.2010801@bogus.com> <4FDCE28C-0B1E-4A8E-AB73-044A9B4BEB07@gmail.com> Date: Tue, 4 Jun 2013 21:24:37 +0800 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Sheng Jiang To: George Michaelson Content-Type: multipart/alternative; boundary=089e01493c0eb9393004de5400ad X-Mailman-Approved-At: Tue, 04 Jun 2013 10:41:04 -0700 Cc: Ivan Pepelnjak , "v6ops@ietf.org WG" , manning bill , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 15:17:03 -0000 --089e01493c0eb9393004de5400ad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, George, Yes, network operators have the freedom to plan the address in their prefer ways. There are many different ways to organize address schemas. Different network operators (including both ISPs and enterprises) has various considerations. Some consideration may be important for one network operator while makes much less sense for others. Why rule out others possibilities or mechanism by saying I have reasons to do things in my way? There are ISPs and enterprises who have chosen to embed their cared semantics into address and organize network or routing polices accordingly. We need to document this and give the analysis we could. Cheers, Sheng On 4 June 2013 11:25, George Michaelson wrote: > Just to remind people, RIR policy is community driven. If the operations > people feel they need a policy for IPv6 allocations and assignments which > takes accounts of semantic bits, they can derive consensus driven policie= s > to do it. Its not done in the IETF. There might be an issue with how it > squares against IETF goals of conservation, but thats part of the > discussion in RIR policy space maybe. > > I think there is a touch of catch-22 here: there isn't a clear sense this > is an industry wide practice demanding that policy initiative (I do not > preclude it: I just observe, it hasn't happened yet) and there is an > absence of a well understood methodology of using it and applying it whic= h > differs radically in outcome from ACL based methods. If there was an IETF > standard I am sure somebody could propose an allocations model which > reflected it, but who knows if that would get traction. > > I notice that there are large providers who feel semantic bit flagging > works for them. So, I do not say "nobody is doing it" as much as "nobody > has said they want an RIR allocations policy which reflects it, yet" > > The first time this came up, I think I said to mike that I could > understand ISPs wanting to say "this is a mechanism we use inside our loc= us > of control, to flag behaviours of packets" -ie that it was unlikely there > was a model for this to be meaningful between providers, but inside a > single autonomous region, sure: why not. (the formalism that you didn't g= et > the /32 under a model of consumption which assumed this kind of usage of > the bits is really not a big deal for me personally, although I am sure i= t > would upset some people) > > -G > > PS I am an RIR employee. I do not speak to policy in any formal sense. I > work in research. > > > On Tue, Jun 4, 2013 at 12:11 PM, Ivan Pepelnjak wro= te: > >> Read the recent "p2p /64" thread of ipv6-ops cluenet mailing list >> >> =3D=3D=3D=3D=3D >> Mistyped and autocorrected on a clunky virtual keyboard >> >> On 4. jun. 2013, at 01:08, joel jaeggli wrote: >> >> > On 6/3/13 3:59 PM, Andrew McGregor wrote: >> >> That's completely true; many switch chips cannot route on longer than >> /64 prefixes, so attempting to do so starts to either heat up the softwa= re >> slow path, or consume ACL entries, or is simply not supported at all. Wh= ile >> this is arguably a bug, it is also pretty much ubiquitous in the current >> generation of ethernet switches, which are the basis for the majority of >> routers. >> > please cite specifics. I have no devices in the field that have such a >> limitation. >> > >> > joel >> >> >> >> >> >> On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter < >> brian.e.carpenter@gmail.com > wrote: >> >> >> >> On 04/06/2013 03:44, manning bill wrote: >> >> > On 2June2013Sunday, at 16:47, Sander Steffann wrote: >> >> > >> >> >> On 03/06/2013 11:06, manning bill wrote: >> >> >>> /48's are a horrible policy - one should only advertise what >> >> one is actually using. >> >> >> Now *that* would cause a nice fragmented DFZ... >> >> >> Sander >> >> >> >> >> > >> >> > >> >> > I'm going to inject a route. One route. why do you care if its a >> >> /9, a /28, a /47, or a /121? >> >> >> >> I've heard tell that there are routers that are designed to handle >> >> prefixes up to /64 efficiently but have a much harder time with >> >> prefixes longer than that, as a reasonable engineering trade-off. >> >> Not being a router designer, I don't know how true this is. >> >> >> >> Brian >> >> >> >> Its -one- route. >> >> > That one route covers everything I'm going to use=E2=80=A6 and n= othing >> >> I'm not. >> >> > >> >> > Is there a credible reason you want to be the vector of DDoS >> >> attacks, by announcing dark space (by proxy aggregation)? >> >> > Is that an operational liability you are willing to assume, just >> >> so you can have "unfragmented" DFZ space? >> >> > >> >> > >> >> > /bill >> >> >> >> ------------------------------------------------------------------= -- >> >> IETF IPv6 working group mailing list >> >> ipv6@ietf.org >> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv= 6 >> >> ------------------------------------------------------------------= -- >> >> >> >> >> >> >> >> >> >> -------------------------------------------------------------------- >> >> IETF IPv6 working group mailing list >> >> ipv6@ietf.org >> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> >> -------------------------------------------------------------------- >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --=20 Sheng Jiang =E8=92=8B=E8=83=9C --089e01493c0eb9393004de5400ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, George,
=C2=A0
Yes, network o= perators have the freedom to plan the address in their prefer ways.=C2=A0Th= ere are many different ways to organize address schemas. Different network = operators (including both ISPs and enterprises) has various considerations.= Some consideration may be important for one network operator while makes m= uch less sense for others. Why rule out others possibilities or mechanism b= y saying I have reasons to do things in my way? There are ISPs and enterpri= ses who have chosen to embed their cared semantics into address and organiz= e network or routing polices accordingly. We need to document this and give= the analysis we could.
=C2=A0
Cheers,
=C2=A0
Sheng
<= div class=3D"gmail_extra">

On 4 June 2013= 11:25, George Michaelson <ggm@algebras.org> wrote:
Just to remind people, RIR = policy is community driven. If the operations people feel they need a polic= y for IPv6 allocations and assignments which takes accounts of semantic bit= s, they can derive consensus driven policies to do it. Its not done in the = IETF. There might be an issue with how it squares against IETF goals of con= servation, but thats part of the discussion in RIR policy space maybe.

I think there is a touch of catch-22 here: there isn't a= clear sense this is an industry wide practice demanding that policy initia= tive (I do not preclude it: I just observe, it hasn't happened yet) and= there is an absence of a well understood methodology of using it and apply= ing it which differs radically in outcome from ACL based methods. If there = was an IETF standard I am sure somebody could propose an allocations model = which reflected it, but who knows if that would get traction.=C2=A0

I notice that there are large providers who feel semant= ic bit flagging works for them. So, I do not say "nobody is doing it&q= uot; as much as "nobody has said they want an RIR allocations policy w= hich reflects it, yet"

The first time this came up, I think I said to mike tha= t I could understand ISPs wanting to say "this is a mechanism we use i= nside our locus of control, to flag behaviours of packets" -ie that it= was unlikely there was a model for this to be meaningful between providers= , but inside a single autonomous region, sure: why not. (the formalism that= you didn't get the /32 under a model of consumption which assumed this= kind of usage of the bits is really not a big deal for me personally, alth= ough I am sure it would upset some people)

-G

PS I am an RI= R employee. I do not speak to policy in any formal sense. I work in researc= h.


On Tue, Jun 4, 2013 at 12:11 PM, Ivan Pepelnjak <ipepelnjak@gmail.com> wrote:
Read the recent "p2p /64" thread of ipv6-ops cluenet mailing list=

=3D=3D=3D=3D=3D
Mistyped and autocorrected on a clunky virtual keyboard

On 4. jun. 2013, at 01:08, joel jaeggli <joelja@bogus.com> wrote:

> On 6/3/13 3:59 PM, Andrew McGregor wrote:
>> That's completely true; many switch chips cannot route on long= er than /64 prefixes, so attempting to do so starts to either heat up the s= oftware slow path, or consume ACL entries, or is simply not supported at al= l. While this is arguably a bug, it is also pretty much ubiquitous in the c= urrent generation of ethernet switches, which are the basis for the majorit= y of routers.
> please cite specifics. I have no devices in the field that have such a= limitation.
>
> joel
>>
>>
>> On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter <brian.e.carpenter@gmai= l.com <mailto:brian.e.carpenter@gmail.com>> wrote:
>>
>> =C2=A0 =C2=A0On 04/06/2013 03:44, manning bill wrote:
>> =C2=A0 =C2=A0> On 2June2013Sunday, at 16:47, Sander Steffann wr= ote:
>> =C2=A0 =C2=A0>
>> =C2=A0 =C2=A0>> On 03/06/2013 11:06, manning bill wrote:
>> =C2=A0 =C2=A0>>> /48's are a horrible policy - one sh= ould only advertise what
>> =C2=A0 =C2=A0one is actually using.
>> =C2=A0 =C2=A0>> Now *that* would cause a nice fragmented DFZ= ...
>> =C2=A0 =C2=A0>> Sander
>> =C2=A0 =C2=A0>>
>> =C2=A0 =C2=A0>
>> =C2=A0 =C2=A0>
>> =C2=A0 =C2=A0> I'm going to inject a route. One route. why = do you care if its a
>> =C2=A0 =C2=A0/9, a /28, a /47, or a /121?
>>
>> =C2=A0 =C2=A0I've heard tell that there are routers that are d= esigned to handle
>> =C2=A0 =C2=A0prefixes up to /64 efficiently but have a much harder= time with
>> =C2=A0 =C2=A0prefixes longer than that, as a reasonable engineerin= g trade-off.
>> =C2=A0 =C2=A0Not being a router designer, I don't know how tru= e this is.
>>
>> =C2=A0 =C2=A0Brian
>>
>> =C2=A0 =C2=A0Its -one- route.
>> =C2=A0 =C2=A0> That one route covers everything I'm going t= o use=E2=80=A6 and nothing
>> =C2=A0 =C2=A0I'm not.
>> =C2=A0 =C2=A0>
>> =C2=A0 =C2=A0> Is there a credible reason you want to be the ve= ctor of DDoS
>> =C2=A0 =C2=A0attacks, by announcing dark space (by proxy aggregati= on)?
>> =C2=A0 =C2=A0> Is that an operational liability you are willing= to assume, just
>> =C2=A0 =C2=A0so you can have "unfragmented" DFZ space? >> =C2=A0 =C2=A0>
>> =C2=A0 =C2=A0>
>> =C2=A0 =C2=A0> /bill
>>
>> =C2=A0 =C2=A0-----------------------------------------------------= ---------------
>> =C2=A0 =C2=A0IETF IPv6 working group mailing list
>> =C2=A0 =C2=A0ip= v6@ietf.org <mailto:ipv6@ietf.org>
>> =C2=A0 =C2=A0Administrative Requests: https://www.ietf.org/mailman/l= istinfo/ipv6
>> =C2=A0 =C2=A0-----------------------------------------------------= ---------------
>>
>>
>>
>>
>> ------------------------------------------------------------------= --
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<= /a>
>> ------------------------------------------------------------------= --
>


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




--
Sheng Jiang =E8=92= =8B=E8=83=9C --089e01493c0eb9393004de5400ad-- From shengjiang@gmail.com Tue Jun 4 09:48:44 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F8B21F9F35; Tue, 4 Jun 2013 09:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGvdG1nbtygg; Tue, 4 Jun 2013 09:48:31 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF9421F9774; Tue, 4 Jun 2013 07:32:33 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id fs12so294635lab.35 for ; Tue, 04 Jun 2013 07:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jBOwDSVerMgjE95k8/A4/t6no8Gal+RVs07669uz6qM=; b=LTYpQaw8md4ycsdSrGtRfptwIHR+cjQLLNFh6gbgDLtO0j5hg/dWO/DT3Gq1O7jUVg il54kYZLzYdUsmBSdkXXR2jW9KSzXGK1qAd5ulhvTCPUBhilT+ALSYN8FBEB1Wi426Sj qwDK4zDBAF+bCqHH29yg8BvfwsOHMn6VpFCydc/luUmaK7TCEux24pLJ3WlKCWinzoIe n/pjQ2+IRw+72tPDR+rFbrSXKveByOMX0VN49RMKb/DOLNrUWXS6gPTYnmxUNORdzZMz es1Rk85dxEoSzS8uK+uuAj2ms+NHUt/NntqQEVVph738UWY9XLsZfLQUb0eOPXJvEAPz ysDA== MIME-Version: 1.0 X-Received: by 10.152.19.166 with SMTP id g6mr13194406lae.4.1370356352316; Tue, 04 Jun 2013 07:32:32 -0700 (PDT) Received: by 10.112.67.166 with HTTP; Tue, 4 Jun 2013 07:32:31 -0700 (PDT) In-Reply-To: <392D823E-36C6-4A25-960A-F6AE783482C2@isi.edu> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> <51ACFC3D.90709@gmail.com> <51AD2208.2010801@bogus.com> <392D823E-36C6-4A25-960A-F6AE783482C2@isi.edu> Date: Tue, 4 Jun 2013 22:32:31 +0800 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Sheng Jiang To: manning bill Content-Type: multipart/alternative; boundary=089e01493c0e987a9704de54f380 X-Mailman-Approved-At: Tue, 04 Jun 2013 10:41:04 -0700 Cc: Ivan Pepelnjak , "v6ops@ietf.org WG" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 16:48:44 -0000 --089e01493c0e987a9704de54f380 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable For sure, we cannot document all variants, but we can document the most representative ones. My current plan is three categeries: ISP's, enterprise's and subscribe's. Each categery has one example (in appendexes), I guess. Cheers, Sheng On 4 June 2013 21:51, manning bill wrote: > are you intending to document -all- variants of the semantics address > holder may use to address and organize their assigned numbers? > or are you intending to document a "preferred" version of address > semantics? > > /bill > > > On 4June2013Tuesday, at 6:24, Sheng Jiang wrote: > > > Hi, George, > > > > Yes, network operators have the freedom to plan the address in their > prefer ways. There are many different ways to organize address schemas. > Different network operators (including both ISPs and enterprises) has > various considerations. Some consideration may be important for one netwo= rk > operator while makes much less sense for others. Why rule out others > possibilities or mechanism by saying I have reasons to do things in my wa= y? > There are ISPs and enterprises who have chosen to embed their cared > semantics into address and organize network or routing polices accordingl= y. > We need to document this and give the analysis we could. > > > > Cheers, > > > > Sheng > > > > > > On 4 June 2013 11:25, George Michaelson wrote: > > Just to remind people, RIR policy is community driven. If the operation= s > people feel they need a policy for IPv6 allocations and assignments which > takes accounts of semantic bits, they can derive consensus driven policie= s > to do it. Its not done in the IETF. There might be an issue with how it > squares against IETF goals of conservation, but thats part of the > discussion in RIR policy space maybe. > > > > I think there is a touch of catch-22 here: there isn't a clear sense > this is an industry wide practice demanding that policy initiative (I do > not preclude it: I just observe, it hasn't happened yet) and there is an > absence of a well understood methodology of using it and applying it whic= h > differs radically in outcome from ACL based methods. If there was an IETF > standard I am sure somebody could propose an allocations model which > reflected it, but who knows if that would get traction. > > > > I notice that there are large providers who feel semantic bit flagging > works for them. So, I do not say "nobody is doing it" as much as "nobody > has said they want an RIR allocations policy which reflects it, yet" > > > > The first time this came up, I think I said to mike that I could > understand ISPs wanting to say "this is a mechanism we use inside our loc= us > of control, to flag behaviours of packets" -ie that it was unlikely there > was a model for this to be meaningful between providers, but inside a > single autonomous region, sure: why not. (the formalism that you didn't g= et > the /32 under a model of consumption which assumed this kind of usage of > the bits is really not a big deal for me personally, although I am sure i= t > would upset some people) > > > > -G > > > > PS I am an RIR employee. I do not speak to policy in any formal sense. = I > work in research. > > > > > > On Tue, Jun 4, 2013 at 12:11 PM, Ivan Pepelnjak > wrote: > > Read the recent "p2p /64" thread of ipv6-ops cluenet mailing list > > > > =3D=3D=3D=3D=3D > > Mistyped and autocorrected on a clunky virtual keyboard > > > > On 4. jun. 2013, at 01:08, joel jaeggli wrote: > > > > > On 6/3/13 3:59 PM, Andrew McGregor wrote: > > >> That's completely true; many switch chips cannot route on longer tha= n > /64 prefixes, so attempting to do so starts to either heat up the softwar= e > slow path, or consume ACL entries, or is simply not supported at all. Whi= le > this is arguably a bug, it is also pretty much ubiquitous in the current > generation of ethernet switches, which are the basis for the majority of > routers. > > > please cite specifics. I have no devices in the field that have such = a > limitation. > > > > > > joel > > >> > > >> > > >> On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com > wrote: > > >> > > >> On 04/06/2013 03:44, manning bill wrote: > > >> > On 2June2013Sunday, at 16:47, Sander Steffann wrote: > > >> > > > >> >> On 03/06/2013 11:06, manning bill wrote: > > >> >>> /48's are a horrible policy - one should only advertise what > > >> one is actually using. > > >> >> Now *that* would cause a nice fragmented DFZ... > > >> >> Sander > > >> >> > > >> > > > >> > > > >> > I'm going to inject a route. One route. why do you care if its = a > > >> /9, a /28, a /47, or a /121? > > >> > > >> I've heard tell that there are routers that are designed to handl= e > > >> prefixes up to /64 efficiently but have a much harder time with > > >> prefixes longer than that, as a reasonable engineering trade-off. > > >> Not being a router designer, I don't know how true this is. > > >> > > >> Brian > > >> > > >> Its -one- route. > > >> > That one route covers everything I'm going to use=A1=AD and not= hing > > >> I'm not. > > >> > > > >> > Is there a credible reason you want to be the vector of DDoS > > >> attacks, by announcing dark space (by proxy aggregation)? > > >> > Is that an operational liability you are willing to assume, jus= t > > >> so you can have "unfragmented" DFZ space? > > >> > > > >> > > > >> > /bill > > >> > > >> > -------------------------------------------------------------------- > > >> IETF IPv6 working group mailing list > > >> ipv6@ietf.org > > >> Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > >> > -------------------------------------------------------------------- > > >> > > >> > > >> > > >> > > >> -------------------------------------------------------------------- > > >> IETF IPv6 working group mailing list > > >> ipv6@ietf.org > > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > >> -------------------------------------------------------------------- > > > > > > _______________________________________________ > > > 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 > > > > > > > > > > -- > > Sheng Jiang =BD=AF=CA=A4 > > --=20 Sheng Jiang =BD=AF=CA=A4 --089e01493c0e987a9704de54f380 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
For sure, we cannot document all variants, but we can= document the most representative ones. My current plan is three categeries= : ISP's, enterprise's and subscribe's. Each categery has one ex= ample (in appendexes), I guess.
 
Cheers,
 
Sheng
<= div class=3D"gmail_extra">

On 4 June 2013= 21:51, manning bill <bmanning@isi.edu> wrote:
are you intending to document -all- variants= of  the semantics address holder may use to address and organize thei= r assigned numbers?
or are you intending to document a "preferred" version of address= semantics?

/bill


On 4June2013Tuesday, at 6:24, Sheng Jiang wrote:

> Hi, George,
>
> Yes, network operators have the freedom to plan the address in their p= refer ways. There are many different ways to organize address schemas. Diff= erent network operators (including both ISPs and enterprises) has various c= onsiderations. Some consideration may be important for one network operator= while makes much less sense for others. Why rule out others possibilities = or mechanism by saying I have reasons to do things in my way? There are ISP= s and enterprises who have chosen to embed their cared semantics into addre= ss and organize network or routing polices accordingly. We need to document= this and give the analysis we could.
>
> Cheers,
>
> Sheng
>
>
> On 4 June 2013 11:25, George Michaelson <ggm@algebras.org> wrote:
> Just to remind people, RIR policy is community driven. If the operatio= ns people feel they need a policy for IPv6 allocations and assignments whic= h takes accounts of semantic bits, they can derive consensus driven policie= s to do it. Its not done in the IETF. There might be an issue with how it s= quares against IETF goals of conservation, but thats part of the discussion= in RIR policy space maybe.
>
> I think there is a touch of catch-22 here: there isn't a clear sen= se this is an industry wide practice demanding that policy initiative (I do= not preclude it: I just observe, it hasn't happened yet) and there is = an absence of a well understood methodology of using it and applying it whi= ch differs radically in outcome from ACL based methods. If there was an IET= F standard I am sure somebody could propose an allocations model which refl= ected it, but who knows if that would get traction.
>
> I notice that there are large providers who feel semantic bit flagging= works for them. So, I do not say "nobody is doing it" as much as= "nobody has said they want an RIR allocations policy which reflects i= t, yet"
>
> The first time this came up, I think I said to mike that I could under= stand ISPs wanting to say "this is a mechanism we use inside our locus= of control, to flag behaviours of packets" -ie that it was unlikely t= here was a model for this to be meaningful between providers, but inside a = single autonomous region, sure: why not. (the formalism that you didn't= get the /32 under a model of consumption which assumed this kind of usage = of the bits is really not a big deal for me personally, although I am sure = it would upset some people)
>
> -G
>
> PS I am an RIR employee. I do not speak to policy in any formal sense.= I work in research.
>
>
> On Tue, Jun 4, 2013 at 12:11 PM, Ivan Pepelnjak <ipepelnjak@gmail.com> wrote:
> Read the recent "p2p /64" thread of ipv6-ops cluenet mailing= list
>
> =3D=3D=3D=3D=3D
> Mistyped and autocorrected on a clunky virtual keyboard
>
> On 4. jun. 2013, at 01:08, joel jaeggli <joelja@bogus.com> wrote:
>
> > On 6/3/13 3:59 PM, Andrew McGregor wrote:
> >> That's completely true; many switch chips cannot route on= longer than /64 prefixes, so attempting to do so starts to either heat up = the software slow path, or consume ACL entries, or is simply not supported = at all. While this is arguably a bug, it is also pretty much ubiquitous in = the current generation of ethernet switches, which are the basis for the ma= jority of routers.
> > please cite specifics. I have no devices in the field that have s= uch a limitation.
> >
> > joel
> >>
> >>
> >> On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter <brian.e.carpenter@gmail.com <= ;mailto:brian.e.carpenter@gm= ail.com>> wrote:
> >>
> >>    On 04/06/2013 03:44, manning bill wrote:
> >>    > On 2June2013Sunday, at 16:47, Sander Steffa= nn wrote:
> >>    >
> >>    >> On 03/06/2013 11:06, manning bill wrote= :
> >>    >>> /48's are a horrible policy - o= ne should only advertise what
> >>    one is actually using.
> >>    >> Now *that* would cause a nice fragmente= d DFZ...
> >>    >> Sander
> >>    >>
> >>    >
> >>    >
> >>    > I'm going to inject a route. One route.= why do you care if its a
> >>    /9, a /28, a /47, or a /121?
> >>
> >>    I've heard tell that there are routers that = are designed to handle
> >>    prefixes up to /64 efficiently but have a much h= arder time with
> >>    prefixes longer than that, as a reasonable engin= eering trade-off.
> >>    Not being a router designer, I don't know ho= w true this is.
> >>
> >>    Brian
> >>
> >>    Its -one- route.
> >>    > That one route covers everything I'm go= ing to use… and nothing
> >>    I'm not.
> >>    >
> >>    > Is there a credible reason you want to be t= he vector of DDoS
> >>    attacks, by announcing dark space (by proxy aggr= egation)?
> >>    > Is that an operational liability you are wi= lling to assume, just
> >>    so you can have "unfragmented" DFZ spa= ce?
> >>    >
> >>    >
> >>    > /bill
> >>
> >>    ------------------------------------------------= --------------------
> >>    IETF IPv6 working group mailing list
> >>    ipv6@ietf.org <mailto:ipv6@ietf.org>
> >>    Administrative Requests: https://www.ietf.org/mail= man/listinfo/ipv6
> >>    ------------------------------------------------= --------------------
> >>
> >>
> >>
> >>
> >> -------------------------------------------------------------= -------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/= ipv6
> >> -------------------------------------------------------------= -------
> >
> > _______________________________________________
> > 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
>
>
>
>
> --
> Sheng Jiang =BD=AF=CA=A4




--
Sheng Jiang= =BD=AF=CA=A4 --089e01493c0e987a9704de54f380-- From Ted.Lemon@nominum.com Tue Jun 4 10:53:47 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA5A21F9A86; Tue, 4 Jun 2013 10:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.529 X-Spam-Level: X-Spam-Status: No, score=-106.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVfnMoIA9XD5; Tue, 4 Jun 2013 10:53:41 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC6721E80F7; Tue, 4 Jun 2013 10:05:16 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUa4eR5mTGxcjkAbBRAQ5cDjjO92b9Qyp@postini.com; Tue, 04 Jun 2013 10:05:16 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 076721B81EB; Tue, 4 Jun 2013 10:05:11 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id EE606190052; Tue, 4 Jun 2013 10:05:10 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Tue, 4 Jun 2013 10:05:10 -0700 From: Ted Lemon To: Owen DeLong Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAFFqgIAAA0MAgAAlngCAAERTAIAAmIuAgAAWAQCAALv5gIAAMI2AgACc9YCAACD6gIAAH1gA Date: Tue, 4 Jun 2013 17:05:10 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C4022@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delon! g.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> <050AD4E8-31AA-41DD-A137-06A8542D8C21@delong.com> In-Reply-To: <050AD4E8-31AA-41DD-A137-06A8542D8C21@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C4022mbx01winnominum_" MIME-Version: 1.0 Cc: "" , Sheng Jiang , "ipv6@ietf.org" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:53:48 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C4022mbx01winnominum_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jun 4, 2013, at 11:12 AM, Owen DeLong > wrote: I don't rule out anything. I state that the bits should be there so that au= tomated topologies can be made to function in an arbitrary plug-and-play en= vironment. If it can be used for other purposes, that's fine, but I do not suggest tha= t we should support those other purposes officially. OTOH, because of the first use case that I do feel we should continue to su= pport officially, I do not support stealing those bits from the end user fo= r the purposes of ISP semantic addressing. So even though we have solutions to allocate prefixes efficiently in arbitr= ary home network topologies, and even though these solutions are just as ea= sy to deploy as the solution that wastes addresses, and even though they pr= ovide better reliability than the wasteful solution, you use the nonexisten= t lack of such mechanisms as justification for a position you are taking in= an argument. Why are you wasting two working groups' time continuing to = assert this argument on that basis? --_000_8D23D4052ABE7A4490E77B1A012B6307751C4022mbx01winnominum_ Content-Type: text/html; charset="us-ascii" Content-ID: <0EA02FCAFCB99C4BBB9B3EC9B68056E3@nominum.com> Content-Transfer-Encoding: quoted-printable
On Jun 4, 2013, at 11:12 AM, Owen DeLong <owen@delong.com> wrote:
I don't rule out anything. I state that the bits should be there so that aut= omated topologies can be made to function in an arbitrary plug-and-play env= ironment.
If it can be used for other purposes, that's fine, but I do not suggest tha= t we should support those other purposes officially.
OTOH, because of the first use case that I do feel we should continue to su= pport officially, I do not support stealing those bits from the end user fo= r the purposes of ISP semantic addressing.

So even though we have solutions to allocate prefixes efficiently in a= rbitrary home network topologies, and even though these solutions are just = as easy to deploy as the solution that wastes addresses, and even though th= ey provide better reliability than the wasteful solution, you use the nonexistent lack of such mechanisms as = justification for a position you are taking in an argument.   Why are = you wasting two working groups' time continuing to assert this argument on = that basis?

--_000_8D23D4052ABE7A4490E77B1A012B6307751C4022mbx01winnominum_-- From gert@space.net Tue Jun 4 14:42:40 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B90821F96F2 for ; Tue, 4 Jun 2013 14:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pX7c0hmAb3op for ; Tue, 4 Jun 2013 14:42:39 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id B60C621F9BA0 for ; Tue, 4 Jun 2013 12:18:57 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id ACB6260A83 for ; Tue, 4 Jun 2013 21:18:52 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 7807560A67 for ; Tue, 4 Jun 2013 21:18:52 +0200 (CEST) Received: (qmail 4009 invoked by uid 1007); 4 Jun 2013 21:18:52 +0200 Date: Tue, 4 Jun 2013 21:18:52 +0200 From: Gert Doering To: Sheng Jiang Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Message-ID: <20130604191852.GW2504@Space.Net> References: <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C2D69@mbx-01.win.nominum.com> <7767FF5D-194E-445A-A890-05A3E4C7CCC1@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 21:42:40 -0000 Hi, On Tue, Jun 04, 2013 at 09:29:52AM +0800, Sheng Jiang wrote: > >They are stealing from the consumer's flexibility to > >provide (questionable) functionality to the provider. > > What's the problem if the consumer get /48 as you want, and providers play > their 28 bits (bit 20~47)? Where are these numbers coming from? Providers get a /32(*), unless they can show that they have *more users* than would fit into a /32. (*) RIR policies differ a bit on this, but it's certainly not a /20 anywhere. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From ales.vizdal@t-mobile.cz Tue Jun 4 14:43:31 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0925821F9A6F; Tue, 4 Jun 2013 14:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGweePvJyO-a; Tue, 4 Jun 2013 14:43:25 -0700 (PDT) Received: from rztmailhub.t-mobile.cz (rztmailhub.t-mobile.cz [93.153.104.86]) by ietfa.amsl.com (Postfix) with ESMTP id 12E5E21F9CAD; Tue, 4 Jun 2013 14:30:54 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by rztmailhub.t-mobile.cz (Postfix) with ESMTP id D890A2E06C6; Tue, 4 Jun 2013 23:30:48 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Tue, 4 Jun 2013 23:30:52 +0200 From: =?utf-8?B?VsOtemRhbCBBbGXFoQ==?= To: Lorenzo Colitti Date: Tue, 4 Jun 2013 23:30:50 +0200 Subject: RE: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: Ac5gxSMJpUjs6zRZRJqqb7aIPKf/oAAnEnjA Message-ID: <1808340F7EC362469DDFFB112B37E2FCC895DBD5B5@SRVHKE02.rdm.cz> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <51ACA2F8.7060601@joelhalpern.com> <1808340F7EC362469DDFFB112B37E2FCC895DBD258@SRVHKE02.rdm.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_1808340F7EC362469DDFFB112B37E2FCC895DBD5B5SRVHKE02rdmcz_" MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: Sheng Jiang , "" , "ipv6@ietf.org" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 21:43:31 -0000 --_000_1808340F7EC362469DDFFB112B37E2FCC895DBD5B5SRVHKE02rdmcz_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KU2VudDog VHVlc2RheSwgSnVuZSAwNCwgMjAxMyAzOjQ1IEFNDQpUbzogVsOtemRhbCBBbGXFoQ0KQ2M6IEpv ZWwgTS4gSGFscGVybjsgU2hlbmcgSmlhbmc7IDx2Nm9wc0BpZXRmLm9yZz47IGRyYWZ0LWppYW5n LXY2b3BzLXNlbWFudGljLXByZWZpeEB0b29scy5pZXRmLm9yZzsgaXB2NkBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFt2Nm9wc10gQ291bGQgSVB2NiBhZGRyZXNzIGJlIG1vcmUgdGhhbiBsb2NhdG9y Py8vZHJhZnQtamlhbmctdjZvcHMtc2VtYW50aWMtcHJlZml4LTAzDQoNCk9uIE1vbiwgSnVuIDMs IDIwMTMgYXQgMTE6NTkgUE0sIFbDrXpkYWwgQWxlxaEgPGFsZXMudml6ZGFsQHQtbW9iaWxlLmN6 PG1haWx0bzphbGVzLnZpemRhbEB0LW1vYmlsZS5jej4+IHdyb3RlOg0KPiBJZiBJIGFtIHJlYWRp bmcgdGhpcyBjb3JyZWN0bHksIGluIHRoZSBlbmQgdGhpcyBpcyByaXZlbiBieSB0aGUgZmFjdCB0 aGF0IGV4aXN0aW5nIGJveGVzDQo+IGNhbiBlYXNpbHkgZmlsdGVyIG9uIGFkZHJlc3NlcyAoYWx0 aG91Z2ggaXQgd2lsbCB0YWtlIGEgbG90IG9mIGZpbHRlcnMpLCBidXQgY2FuIG5vdCBhcHBseQ0K PiBBQ0xzIHRvIERTQ1BzIG9yIGV4dGVuc2lvbiBoZWFkZXJzPw0KDQpUaGUgY3VycmVudCBib3hl cyBjYW4gZG8gYm90aCBBQ0wgZmlsdGVyaW5nIGFzIHdlbGwgYXMgRFNDUCBtYW5nbGluZywgYnV0 IGFzIG1lbnRpb25lZA0KZWFybGllciB0aGUgRFNDUCBiaXRzIGNhbm5vdCBiZSB0cnVzdGVkLCBz byBhIG1hcmtkb3duL3JlLW1hcmtpbmcgaXMgcmVxdWlyZWQgcG90ZW50aWFsbHkNCmludm9sdmlu ZyBEUEkuIE1haW50YWluaW5nIEFDTHMgaXMgYWxzbyB0aW1lIGNvbnN1bWluZy4NCg0KSSBkb24n dCB1bmRlcnN0YW5kIHdoYXQgdGhlIGRpZmZlcmVuY2UgaXMuIFdoeSBjYW4gdGhlIGFkZHJlc3Nl cyBiZSB0cnVzdGVkPyBBbnN3ZXIgLSBiZWNhdXNlIHlvdSBkcm9wIHBhY2tldHMgaWYgdGhlIGhv c3QgdXNlcyB0aGUgd3JvbmcgYWRkcmVzcy4gQnV0IGFsbCB0aGUgc3BhY2UgaXMgcm91dGVkIHRv IHRoZSB1c2VyIGFueXdheSwgYW5kIHRoZSBzZW1hbnRpYyBiaXRzIG9ubHkgZXhwcmVzcyBzZW1h bnRpY3MsIHJpZ2h0PyBUaGVyZWZvcmUgeW91IGNhbid0IHVzZSByb3V0aW5nIG9yIFJQRiB0byBp bXBsZW1lbnQgdGhlIGRyb3BzLCBhbmQgeW91IGhhdmUgdG8gdXNlIGFuIEFDTC4NCg0KW2FsZXNd IExldOKAmXMgYXNzdW1lIHRoZSBTUCBpcyBwcm92aWRpbmcgYSBwcmVmaXggcGVyIHNlcnZpY2Us IHNvIHRoZSBob3N0IHdpbGwgYmUgcHJvdmlkZWQgd2l0aCBtdWx0aXBsZSBhZGRyZXNzZXMgZnJv bSBtdWx0aXBsZSBwcmVmaXhlcyAoZS5nLiB2b2ljZSwgaXB0diwgSW50ZXJuZXQpLg0KSWYgdGhl IGhvc3QgcGlja3MgYSB3cm9uZyBhZGRyZXNzIHdpdGggYmV0dGVyIFFvUyBwb2xpY3kgZS5nLiBp cHR2IHRvIHRhbGsgdG8gdGhlIEludGVybmV0IGl0IHdvbuKAmXQgd29yayBhcyB0aGlzIHByZWZp eCBzaGFsbCBiZSB1c2VkIHRvIHRhbGsgdG8gaXB0diBvbmx5LCBzbyB0aGVyZSBpcw0Kbm8gcG9p bnQgaW4gcGxheWluZyB3aXRoIHByZWZpeGVzIG9uIHRoZSBob3N0IHNpZGUuIEFDTHMgc2hhbGwg YmUgaW5zdGFsbGVkIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSBzZXJ2aWNlIGRlc2lnbmF0ZWQgcHJl Zml4IGNhbiByZWFjaCB0aGUgcmVzcGVjdGl2ZSBzZXJ2aWNlIG9ubHkgYnkNCm1hdGNoaW5nIHRo ZSBzZW1hbnRpYyBiaXRzLiBTZW1hbnRpY3Mgc2hhbGwgbm90IGJlIGxpbWl0ZWQgdG8gUW9TIG9u bHkgYXMgaXQgY2FuIGRlZmluZSBzZXJ2aWNlLCBjdXN0b21lciwgdnBuIHNlcnZpY2UsIHNlY3Vy aXR5IGxldmVsLCBsb2NhdGlvbiDigKYgc28gdGhlIEFDTHMNCmNhbiBiZSBzaW1wbGlmaWVkIHRv IG1hdGNoIHRoZSBzZW1hbnRpY3MgYml0cyBpbnN0ZWFkIG9mIG1hdGNoaW5nIGV4YWN0IHNyYyAv IGRzdCBhbmQgbWFpbnRhaW5pbmcg4oCYc29tZXRpbWVz4oCZIGxvbmcgbGlzdHMgb2YgdGhlc2Uu IFNvIHVzZXJzIHdpdGggdGhlIHNhbWUNCnNlcnZpY2UgcHJvZmlsZSBjYW4gdXNlIHRoZSBzYW1l IEFDTHMuDQoNClNvIGlmIHlvdSBoYXZlIHRvIHVzZSBhbiBBQ0wgdG8gZG8gdGhpcyBhbnl3YXks IHRoZW4gd2h5IGNhbid0IHlvdSBtYWtlIHRoZSBBQ0wgZHJvcCBwYWNrZXRzIGlmIHRoZSBob3N0 IHVzZXMgdGhlIHdyb25nIERTQ1AgY29kZXBvaW50PyBUaGF0IHdheSB5b3UgZG9uJ3QgbmVlZCB0 byB1c2UgZXh0cmEgYWRkcmVzcyBzcGFjZS4NCg0KW2FsZXNdIEFDTHMgY2FuIGJlIHVzZWQgdG8g c2V0L2NoYW5nZSB0aGUgRFNDUCwgYnV0IHRoZSBzZW1hbnRpY3MgaXMgbm90IG9ubHkgYWJvdXQg UW9TL0RTQ1AuIFNlbWFudGljcyBjYW4gaGVscCB0byBzaW1wbHkgc2V0IHRoZSBEU0NQIGJhc2Vk IG9uIHRoZSBzZW1hbnRpYyBiaXRzDQplbmNvZGVkIGluIHRoZSBhZGRyZXNzIChzcmMvZHN0KSBj b21wYXJlZCB0byBtYXRjaGluZyBzcmMgLyBkc3QgLyBsNCBwb3J0cyBvciBldmVuIGVtcGxveWlu ZyBEUEkgb24gYSBwZXIgc3Vic2NyaWJlciBiYXNpcy4NCg== --_000_1808340F7EC362469DDFFB112B37E2FCC895DBD5B5SRVHKE02rdmcz_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVw dCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwv aGVhZD48Ym9keSBsYW5nPUVOLUdCIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1X b3JkU2VjdGlvbjE+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVu em9AZ29vZ2xlLmNvbV0gPGJyPjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDA0LCAyMDEzIDM6 NDUgQU08YnI+PGI+VG86PC9iPiBWw616ZGFsIEFsZcWhPGJyPjxiPkNjOjwvYj4gSm9lbCBNLiBI YWxwZXJuOyBTaGVuZyBKaWFuZzsgJmx0O3Y2b3BzQGlldGYub3JnJmd0OzsgZHJhZnQtamlhbmct djZvcHMtc2VtYW50aWMtcHJlZml4QHRvb2xzLmlldGYub3JnOyBpcHY2QGlldGYub3JnPGJyPjxi PlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBDb3VsZCBJUHY2IGFkZHJlc3MgYmUgbW9yZSB0aGFu IGxvY2F0b3I/Ly9kcmFmdC1qaWFuZy12Nm9wcy1zZW1hbnRpYy1wcmVmaXgtMDM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9uIE1vbiwgSnVuIDMsIDIwMTMgYXQgMTE6 NTkgUE0sIFbDrXpkYWwgQWxlxaEgJmx0OzxhIGhyZWY9Im1haWx0bzphbGVzLnZpemRhbEB0LW1v YmlsZS5jeiIgdGFyZ2V0PSJfYmxhbmsiPmFsZXMudml6ZGFsQHQtbW9iaWxlLmN6PC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+PGRpdj48ZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSc+PHAgY2xhc3M9TXNvTm9y bWFsPiZndDsgSWYgSSBhbSByZWFkaW5nIHRoaXMgY29ycmVjdGx5LCBpbiB0aGUgZW5kIHRoaXMg aXMgcml2ZW4gYnkgdGhlIGZhY3QgdGhhdCBleGlzdGluZyBib3hlczxicj4mZ3Q7IGNhbiBlYXNp bHkgZmlsdGVyIG9uIGFkZHJlc3NlcyAoYWx0aG91Z2ggaXQgd2lsbCB0YWtlIGEgbG90IG9mIGZp bHRlcnMpLCBidXQgY2FuIG5vdCBhcHBseTxicj4mZ3Q7IEFDTHMgdG8gRFNDUHMgb3IgZXh0ZW5z aW9uIGhlYWRlcnM/PGJyPjxicj5UaGUgY3VycmVudCBib3hlcyBjYW4gZG8gYm90aCBBQ0wgZmls dGVyaW5nIGFzIHdlbGwgYXMgRFNDUCBtYW5nbGluZywgYnV0IGFzIG1lbnRpb25lZDxicj5lYXJs aWVyIHRoZSBEU0NQIGJpdHMgY2Fubm90IGJlIHRydXN0ZWQsIHNvIGEgbWFya2Rvd24vcmUtbWFy a2luZyBpcyByZXF1aXJlZCBwb3RlbnRpYWxseTxicj5pbnZvbHZpbmcgRFBJLiBNYWludGFpbmlu ZyBBQ0xzIGlzIGFsc28gdGltZSBjb25zdW1pbmcuPG86cD48L286cD48L3A+PC9ibG9ja3F1b3Rl PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPkkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHRoZSBkaWZmZXJlbmNl IGlzLiBXaHkgY2FuIHRoZSBhZGRyZXNzZXMgYmUgdHJ1c3RlZD8gQW5zd2VyIC0gYmVjYXVzZSB5 b3UgZHJvcCBwYWNrZXRzIGlmIHRoZSBob3N0IHVzZXMgdGhlIHdyb25nIGFkZHJlc3MuIEJ1dCBh bGwgdGhlIHNwYWNlIGlzIHJvdXRlZCB0byB0aGUgdXNlciBhbnl3YXksIGFuZCB0aGUgc2VtYW50 aWMgYml0cyBvbmx5IGV4cHJlc3Mgc2VtYW50aWNzLCByaWdodD8gVGhlcmVmb3JlIHlvdSBjYW4n dCB1c2Ugcm91dGluZyBvciBSUEYgdG8gaW1wbGVtZW50IHRoZSBkcm9wcywgYW5kIHlvdSBoYXZl IHRvIHVzZSBhbiBBQ0wuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5bYWxlc10gTGV04oCZ cyBhc3N1bWUgdGhlIFNQIGlzIHByb3ZpZGluZyBhIHByZWZpeCBwZXIgc2VydmljZSwgc28gdGhl IGhvc3Qgd2lsbCBiZSBwcm92aWRlZCB3aXRoIG11bHRpcGxlIGFkZHJlc3NlcyBmcm9tIG11bHRp cGxlIHByZWZpeGVzIChlLmcuIHZvaWNlLCBpcHR2LCBJbnRlcm5ldCkuIDxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JZiB0aGUg aG9zdCBwaWNrcyBhIHdyb25nIGFkZHJlc3Mgd2l0aCBiZXR0ZXIgUW9TIHBvbGljeSBlLmcuIGlw dHYgdG8gdGFsayB0byB0aGUgSW50ZXJuZXQgaXQgd29u4oCZdCB3b3JrIGFzIHRoaXMgcHJlZml4 IHNoYWxsIGJlIHVzZWQgdG8gdGFsayB0byBpcHR2IG9ubHksIHNvIHRoZXJlIGlzIDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5u byBwb2ludCBpbiBwbGF5aW5nIHdpdGggcHJlZml4ZXMgb24gdGhlIGhvc3Qgc2lkZS4gQUNMcyBz aGFsbCBiZSBpbnN0YWxsZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIHNlcnZpY2UgZGVzaWduYXRl ZCBwcmVmaXggY2FuIHJlYWNoIHRoZSByZXNwZWN0aXZlIHNlcnZpY2Ugb25seSBieSA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ bWF0Y2hpbmcgdGhlIHNlbWFudGljIGJpdHMuIFNlbWFudGljcyBzaGFsbCBub3QgYmUgbGltaXRl ZCB0byBRb1Mgb25seSBhcyBpdCBjYW4gZGVmaW5lIHNlcnZpY2UsIGN1c3RvbWVyLCB2cG4gc2Vy dmljZSwgc2VjdXJpdHkgbGV2ZWwsIGxvY2F0aW9uIOKApiBzbyB0aGUgQUNMcyA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Y2Fu IGJlIHNpbXBsaWZpZWQgdG8gbWF0Y2ggdGhlIHNlbWFudGljcyBiaXRzIGluc3RlYWQgb2YgbWF0 Y2hpbmcgZXhhY3Qgc3JjIC8gZHN0IGFuZCBtYWludGFpbmluZyDigJhzb21ldGltZXPigJkgbG9u ZyBsaXN0cyBvZiB0aGVzZS4gU28gdXNlcnMgd2l0aCB0aGUgc2FtZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5zZXJ2aWNlIHBy b2ZpbGUgY2FuIHVzZSB0aGUgc2FtZSBBQ0xzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZl cmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+U28gaWYgeW91IGhhdmUgdG8gdXNl IGFuIEFDTCB0byBkbyB0aGlzIGFueXdheSwgdGhlbiB3aHkgY2FuJ3QgeW91IG1ha2UgdGhlIEFD TCBkcm9wIHBhY2tldHMgaWYgdGhlIGhvc3QgdXNlcyB0aGUgd3JvbmcgRFNDUCBjb2RlcG9pbnQ/ IFRoYXQgd2F5IHlvdSBkb24ndCBuZWVkIHRvIHVzZSBleHRyYSBhZGRyZXNzIHNwYWNlLjxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5bYWxlc10gQUNMcyBjYW4gYmUgdXNlZCB0byBzZXQvY2hhbmdlIHRoZSBEU0NQLCBi dXQgdGhlIHNlbWFudGljcyBpcyBub3Qgb25seSBhYm91dCBRb1MvRFNDUC4gU2VtYW50aWNzIGNh biBoZWxwIHRvIHNpbXBseSBzZXQgdGhlIERTQ1AgYmFzZWQgb24gdGhlIHNlbWFudGljIGJpdHM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+ZW5jb2RlZCBpbiB0aGUgYWRkcmVzcyAoc3JjL2RzdCkgY29tcGFyZWQgdG8gbWF0Y2hp bmcgc3JjIC8gZHN0IC8gbDQgcG9ydHMgb3IgZXZlbiBlbXBsb3lpbmcgRFBJIG9uIGEgcGVyIHN1 YnNjcmliZXIgYmFzaXMuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2Pjwv ZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_1808340F7EC362469DDFFB112B37E2FCC895DBD5B5SRVHKE02rdmcz_-- From shengjiang@gmail.com Tue Jun 4 16:44:40 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A061221F9A13; Tue, 4 Jun 2013 16:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[AWL=-1.192, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PK7lvp3xOkt; Tue, 4 Jun 2013 16:44:35 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id DC97F21F9A11; Tue, 4 Jun 2013 16:44:34 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id v10so1270367lbd.20 for ; Tue, 04 Jun 2013 16:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iWmpeEx/nZ9vFncueUCfnCpwFhelV8hSSWDoScdsYzU=; b=HNlQZO5dCgXsSWMquanBzSSioqE6rFrP/Uc0OmpRtrNadcRfGVigcLz+ZswOZKxW1B X4b6p/Wnof9BuakCFZTATY3Ckuc1wdK0AEe1pUj7yR1FQWaPpKhjqt5Cnw2I12Yo0tAh DmHBrPIKjW/vbmMNzkehoR3zRqR1Wz0v8rn0LCH14Qcp3pApfnJ+5kZg/VpATyU4+zpw PIOsGnnr+SS+SPHyMzt3DvHrpkYQ20gjICuKgKFIRuN1TfL9K4N578R96pxJMRJf3r3c zVwDv6s0knmZRq2GXaMYsT+cjgX6dEvmtIAVy1dALptMyl1LjgVD/NRUXoaBecFuIOGd E6sw== MIME-Version: 1.0 X-Received: by 10.112.60.233 with SMTP id k9mr13864649lbr.61.1370389473675; Tue, 04 Jun 2013 16:44:33 -0700 (PDT) Received: by 10.112.67.166 with HTTP; Tue, 4 Jun 2013 16:44:33 -0700 (PDT) In-Reply-To: <634198A4-5A4E-4B59-9B16-311160330A98@isi.edu> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> <51ACFC3D.90709@gmail.com> <51AD2208.2010801@bogus.com> <392D823E-36C6-4A25-960A-F6AE783482C2@isi.edu> <634198A4-5A4E-4B59-9B16-311160330A98@isi.edu> Date: Wed, 5 Jun 2013 07:44:33 +0800 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Sheng Jiang To: manning bill Content-Type: multipart/alternative; boundary=e89a8f83a659c84e4404de5ca9b3 X-Mailman-Approved-At: Tue, 04 Jun 2013 18:26:50 -0700 Cc: Ivan Pepelnjak , "v6ops@ietf.org WG" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 23:44:40 -0000 --e89a8f83a659c84e4404de5ca9b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We do NOT "support" anything. This would be an analysis document. The motivation is to document existing typical semantic IP address mechanisms and analyze them, both good and bad side. I will make this very clear in the new version. Sheng On 4 June 2013 22:44, manning bill wrote: > I believe this is fraught with danger. > It perhaps better to identify semantic constructs than to presuppose > representative cases. > > things like even/odd for in/out-bound links, > lat/log encoding or other geo-location > etc. > > as a survey of technique. > > /bill > > > On 4June2013Tuesday, at 7:32, Sheng Jiang wrote: > > > For sure, we cannot document all variants, but we can document the most > representative ones. My current plan is three categeries: ISP's, > enterprise's and subscribe's. Each categery has one example (in > appendexes), I guess. > > > > Cheers, > > > > Sheng > > > > > > On 4 June 2013 21:51, manning bill wrote: > > are you intending to document -all- variants of the semantics address > holder may use to address and organize their assigned numbers? > > or are you intending to document a "preferred" version of address > semantics? > > > > /bill > > > > > > On 4June2013Tuesday, at 6:24, Sheng Jiang wrote: > > > > > Hi, George, > > > > > > Yes, network operators have the freedom to plan the address in their > prefer ways. There are many different ways to organize address schemas. > Different network operators (including both ISPs and enterprises) has > various considerations. Some consideration may be important for one netwo= rk > operator while makes much less sense for others. Why rule out others > possibilities or mechanism by saying I have reasons to do things in my wa= y? > There are ISPs and enterprises who have chosen to embed their cared > semantics into address and organize network or routing polices accordingl= y. > We need to document this and give the analysis we could. > > > > > > Cheers, > > > > > > Sheng > > > > > > > > > On 4 June 2013 11:25, George Michaelson wrote: > > > Just to remind people, RIR policy is community driven. If the > operations people feel they need a policy for IPv6 allocations and > assignments which takes accounts of semantic bits, they can derive > consensus driven policies to do it. Its not done in the IETF. There might > be an issue with how it squares against IETF goals of conservation, but > thats part of the discussion in RIR policy space maybe. > > > > > > I think there is a touch of catch-22 here: there isn't a clear sense > this is an industry wide practice demanding that policy initiative (I do > not preclude it: I just observe, it hasn't happened yet) and there is an > absence of a well understood methodology of using it and applying it whic= h > differs radically in outcome from ACL based methods. If there was an IETF > standard I am sure somebody could propose an allocations model which > reflected it, but who knows if that would get traction. > > > > > > I notice that there are large providers who feel semantic bit flaggin= g > works for them. So, I do not say "nobody is doing it" as much as "nobody > has said they want an RIR allocations policy which reflects it, yet" > > > > > > The first time this came up, I think I said to mike that I could > understand ISPs wanting to say "this is a mechanism we use inside our loc= us > of control, to flag behaviours of packets" -ie that it was unlikely there > was a model for this to be meaningful between providers, but inside a > single autonomous region, sure: why not. (the formalism that you didn't g= et > the /32 under a model of consumption which assumed this kind of usage of > the bits is really not a big deal for me personally, although I am sure i= t > would upset some people) > > > > > > -G > > > > > > PS I am an RIR employee. I do not speak to policy in any formal sense= . > I work in research. > > > > > > > > > On Tue, Jun 4, 2013 at 12:11 PM, Ivan Pepelnjak > wrote: > > > Read the recent "p2p /64" thread of ipv6-ops cluenet mailing list > > > > > > =3D=3D=3D=3D=3D > > > Mistyped and autocorrected on a clunky virtual keyboard > > > > > > On 4. jun. 2013, at 01:08, joel jaeggli wrote: > > > > > > > On 6/3/13 3:59 PM, Andrew McGregor wrote: > > > >> That's completely true; many switch chips cannot route on longer > than /64 prefixes, so attempting to do so starts to either heat up the > software slow path, or consume ACL entries, or is simply not supported at > all. While this is arguably a bug, it is also pretty much ubiquitous in t= he > current generation of ethernet switches, which are the basis for the > majority of routers. > > > > please cite specifics. I have no devices in the field that have suc= h > a limitation. > > > > > > > > joel > > > >> > > > >> > > > >> On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com > wrote: > > > >> > > > >> On 04/06/2013 03:44, manning bill wrote: > > > >> > On 2June2013Sunday, at 16:47, Sander Steffann wrote: > > > >> > > > > >> >> On 03/06/2013 11:06, manning bill wrote: > > > >> >>> /48's are a horrible policy - one should only advertise wha= t > > > >> one is actually using. > > > >> >> Now *that* would cause a nice fragmented DFZ... > > > >> >> Sander > > > >> >> > > > >> > > > > >> > > > > >> > I'm going to inject a route. One route. why do you care if it= s > a > > > >> /9, a /28, a /47, or a /121? > > > >> > > > >> I've heard tell that there are routers that are designed to > handle > > > >> prefixes up to /64 efficiently but have a much harder time with > > > >> prefixes longer than that, as a reasonable engineering trade-of= f. > > > >> Not being a router designer, I don't know how true this is. > > > >> > > > >> Brian > > > >> > > > >> Its -one- route. > > > >> > That one route covers everything I'm going to use=E2=80=A6 an= d nothing > > > >> I'm not. > > > >> > > > > >> > Is there a credible reason you want to be the vector of DDoS > > > >> attacks, by announcing dark space (by proxy aggregation)? > > > >> > Is that an operational liability you are willing to assume, > just > > > >> so you can have "unfragmented" DFZ space? > > > >> > > > > >> > > > > >> > /bill > > > >> > > > >> > -------------------------------------------------------------------- > > > >> IETF IPv6 working group mailing list > > > >> ipv6@ietf.org > > > >> Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > > >> > -------------------------------------------------------------------- > > > >> > > > >> > > > >> > > > >> > > > >> ------------------------------------------------------------------= -- > > > >> IETF IPv6 working group mailing list > > > >> ipv6@ietf.org > > > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv= 6 > > > >> ------------------------------------------------------------------= -- > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > > > > > > > > -- > > > Sheng Jiang =E8=92=8B=E8=83=9C > > > > > > > > > > -- > > Sheng Jiang =E8=92=8B=E8=83=9C > > --=20 Sheng Jiang =E8=92=8B=E8=83=9C --e89a8f83a659c84e4404de5ca9b3 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
We do NOT "support" anything. This would be= an analysis document. The motivation is to document existing typical seman= tic IP address mechanisms and analyze them, both good and bad side. I will = make this very clear in the new version.
 
Sheng


<= div class=3D"gmail_quote">On 4 June 2013 22:44, manning bill <bmanning@isi.= edu> wrote:
I believe this is fraught with danger.
It perhaps better to identify semantic constructs than to presuppose repres= entative cases.

things like  even/odd  for in/out-bound links,
lat/log  encoding or other geo-location
etc.

as a survey of technique.

/bill


On 4June2013Tuesday, at 7:32, Sheng Jiang wrote:

> For sure, we cannot document all variants, but we can document the mos= t representative ones. My current plan is three categeries: ISP's, ente= rprise's and subscribe's. Each categery has one example (in appende= xes), I guess.
>
> Cheers,
>
> Sheng
>
>
> On 4 June 2013 21:51, manning bill <bmanning@isi.edu> wrote:
> are you intending to document -all- variants of  the semantics ad= dress holder may use to address and organize their assigned numbers?
> or are you intending to document a "preferred" version of ad= dress semantics?
>
> /bill
>
>
> On 4June2013Tuesday, at 6:24, Sheng Jiang wrote:
>
> > Hi, George,
> >
> > Yes, network operators have the freedom to plan the address in th= eir prefer ways. There are many different ways to organize address schemas.= Different network operators (including both ISPs and enterprises) has vari= ous considerations. Some consideration may be important for one network ope= rator while makes much less sense for others. Why rule out others possibili= ties or mechanism by saying I have reasons to do things in my way? There ar= e ISPs and enterprises who have chosen to embed their cared semantics into = address and organize network or routing polices accordingly. We need to doc= ument this and give the analysis we could.
> >
> > Cheers,
> >
> > Sheng
> >
> >
> > On 4 June 2013 11:25, George Michaelson <ggm@algebras.org> wrote:
> > Just to remind people, RIR policy is community driven. If the ope= rations people feel they need a policy for IPv6 allocations and assignments= which takes accounts of semantic bits, they can derive consensus driven po= licies to do it. Its not done in the IETF. There might be an issue with how= it squares against IETF goals of conservation, but thats part of the discu= ssion in RIR policy space maybe.
> >
> > I think there is a touch of catch-22 here: there isn't a clea= r sense this is an industry wide practice demanding that policy initiative = (I do not preclude it: I just observe, it hasn't happened yet) and ther= e is an absence of a well understood methodology of using it and applying i= t which differs radically in outcome from ACL based methods. If there was a= n IETF standard I am sure somebody could propose an allocations model which= reflected it, but who knows if that would get traction.
> >
> > I notice that there are large providers who feel semantic bit fla= gging works for them. So, I do not say "nobody is doing it" as mu= ch as "nobody has said they want an RIR allocations policy which refle= cts it, yet"
> >
> > The first time this came up, I think I said to mike that I could = understand ISPs wanting to say "this is a mechanism we use inside our = locus of control, to flag behaviours of packets" -ie that it was unlik= ely there was a model for this to be meaningful between providers, but insi= de a single autonomous region, sure: why not. (the formalism that you didn&= #39;t get the /32 under a model of consumption which assumed this kind of u= sage of the bits is really not a big deal for me personally, although I am = sure it would upset some people)
> >
> > -G
> >
> > PS I am an RIR employee. I do not speak to policy in any formal s= ense. I work in research.
> >
> >
> > On Tue, Jun 4, 2013 at 12:11 PM, Ivan Pepelnjak <ipepelnjak@gmail.com> wrote:
> > Read the recent "p2p /64" thread of ipv6-ops cluenet ma= iling list
> >
> > =3D=3D=3D=3D=3D
> > Mistyped and autocorrected on a clunky virtual keyboard
> >
> > On 4. jun. 2013, at 01:08, joel jaeggli <joelja@bogus.com> wrote:
> >
> > > On 6/3/13 3:59 PM, Andrew McGregor wrote:
> > >> That's completely true; many switch chips cannot rou= te on longer than /64 prefixes, so attempting to do so starts to either hea= t up the software slow path, or consume ACL entries, or is simply not suppo= rted at all. While this is arguably a bug, it is also pretty much ubiquitou= s in the current generation of ethernet switches, which are the basis for t= he majority of routers.
> > > please cite specifics. I have no devices in the field that h= ave such a limitation.
> > >
> > > joel
> > >>
> > >>
> > >> On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpent= er@gmail.com>> wrote:
> > >>
> > >>    On 04/06/2013 03:44, manning bill wrote: > > >>    > On 2June2013Sunday, at 16:47, Sander S= teffann wrote:
> > >>    >
> > >>    >> On 03/06/2013 11:06, manning bill = wrote:
> > >>    >>> /48's are a horrible polic= y - one should only advertise what
> > >>    one is actually using.
> > >>    >> Now *that* would cause a nice frag= mented DFZ...
> > >>    >> Sander
> > >>    >>
> > >>    >
> > >>    >
> > >>    > I'm going to inject a route. One r= oute. why do you care if its a
> > >>    /9, a /28, a /47, or a /121?
> > >>
> > >>    I've heard tell that there are routers = that are designed to handle
> > >>    prefixes up to /64 efficiently but have a m= uch harder time with
> > >>    prefixes longer than that, as a reasonable = engineering trade-off.
> > >>    Not being a router designer, I don't kn= ow how true this is.
> > >>
> > >>    Brian
> > >>
> > >>    Its -one- route.
> > >>    > That one route covers everything I'= ;m going to use… and nothing
> > >>    I'm not.
> > >>    >
> > >>    > Is there a credible reason you want to= be the vector of DDoS
> > >>    attacks, by announcing dark space (by proxy= aggregation)?
> > >>    > Is that an operational liability you a= re willing to assume, just
> > >>    so you can have "unfragmented" DF= Z space?
> > >>    >
> > >>    >
> > >>    > /bill
> > >>
> > >>    -------------------------------------------= -------------------------
> > >>    IETF IPv6 working group mailing list
> > >>    ipv6@ietf.= org <mailto:ipv6@ietf.org> > > >>    Administrative Requests: https://www.ietf.org= /mailman/listinfo/ipv6
> > >>    -------------------------------------------= -------------------------
> > >>
> > >>
> > >>
> > >>
> > >> --------------------------------------------------------= ------------
> > >> IETF IPv6 working group mailing list
> > >> ipv6@ietf.org
> > >> Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
> > >> --------------------------------------------------------= ------------
> > >
> > > _______________________________________________
> > > 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
> >
> >
> >
> >
> > --
> > Sheng Jiang =BD=AF=CA=A4
>
>
>
>
> --
> Sheng Jiang =BD=AF=CA=A4




--
Sheng Jiang= =BD=AF=CA=A4 --e89a8f83a659c84e4404de5ca9b3-- From shengjiang@gmail.com Tue Jun 4 16:55:43 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF9321F9957; Tue, 4 Jun 2013 16:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.095 X-Spam-Level: X-Spam-Status: No, score=-3.095 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDNbYzBx1vPW; Tue, 4 Jun 2013 16:55:37 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE8321F8F0C; Tue, 4 Jun 2013 16:55:33 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id t11so1297324lbd.1 for ; Tue, 04 Jun 2013 16:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IuncwtQuiDQaZIEofscWquRSow0jJht5NFZayLHV/MQ=; b=TiDBLxt1CXSoZpmgIfLMsH4BnVAcR2kjO1p+huUGoHn16wzpHMbxUrDdoI1K7+OVrd T14RCM2sxZhYpVb8j8j+ruh8qG91ehXBzBf5v2Gw6WCY0eAU+KhMT3200xsGIO4BxnQX Pm09ef/Jogyzg8D4IvmIqMDKyBIuCeggRdvDBVz2LHshUr4AfUKZL45pQJzDNbbx8NoL 62YmipWOJxHb8OAj0LmzbOtYMVw3fMbUzopbSP9qRBUOt3h3b6MDvRV5H8sDzWRyiv69 j9qHyck/UoOx5xNhcZB7BBP7LFh1AIHojUiIqUDYNSGCLZOUWtyOzrATMedP1Stxx+Yy 19mg== MIME-Version: 1.0 X-Received: by 10.152.19.65 with SMTP id c1mr14251210lae.24.1370390125330; Tue, 04 Jun 2013 16:55:25 -0700 (PDT) Received: by 10.112.67.166 with HTTP; Tue, 4 Jun 2013 16:55:25 -0700 (PDT) In-Reply-To: <20130604191852.GW2504@Space.Net> References: <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C2D69@mbx-01.win.nominum.com> <7767FF5D-194E-445A-A890-05A3E4C7CCC1@delong.com> <20130604191852.GW2504@Space.Net> Date: Wed, 5 Jun 2013 07:55:25 +0800 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Sheng Jiang To: Gert Doering Content-Type: multipart/alternative; boundary=089e014943089fc70d04de5cd09f X-Mailman-Approved-At: Tue, 04 Jun 2013 18:26:51 -0700 Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 23:55:43 -0000 --089e014943089fc70d04de5cd09f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As far as I know, most of Tier1 providers gets /24, /26 or bigger. For RIR's policy, please see recent email from George Michaelson. Although he did not speak in any formal, he explained RIR policy is much flexiable than most of us thought. http://www.ietf.org/mail-archive/web/v6ops/current/msg16697.html Sheng On 5 June 2013 03:18, Gert Doering wrote: > Hi, > > On Tue, Jun 04, 2013 at 09:29:52AM +0800, Sheng Jiang wrote: > > >They are stealing from the consumer's flexibility to > > >provide (questionable) functionality to the provider. > > > > What's the problem if the consumer get /48 as you want, and providers > play > > their 28 bits (bit 20~47)? > > Where are these numbers coming from? Providers get a /32(*), unless they > can > show that they have *more users* than would fit into a /32. > > (*) RIR policies differ a bit on this, but it's certainly not a /20 > anywhere. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > --=20 Sheng Jiang =E8=92=8B=E8=83=9C --089e014943089fc70d04de5cd09f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As far as I know, most of Tier1 provid= ers gets /24, /26 or bigger.
=C2=A0
For RIR's polic= y, please see recent email from=C2=A0George Michaelson. Although he did not= speak=C2=A0in any formal, he explained RIR policy is much flexiable than m= ost of us thought.=C2=A0
=C2=A0
=C2=A0
Sheng
<= /div>


On 5 June 2013 03:18, Gert Doering <gert@s= pace.net> wrote:
Hi,

On Tue, Jun 04, 2013 at 09:29:52AM +0800, Sheng Jiang wrote:
> >They are stealing from the consumer's flexibility to
> >provide (questionable) functionality to the provider.
>
> What's the problem if the consumer get /48 as you want, and provid= ers play
> their 28 bits (bit 20~47)?

Where are these numbers coming from? =C2=A0Providers get a /32(*), un= less they can
show that they have *more users* than would fit into a /32.

(*) RIR policies differ a bit on this, but it's certainly not a /20 any= where.

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=A0Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Aufsichtsratsvo= 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 HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-IdNr.:= DE813185279



--
Sheng Jia= ng =E8=92=8B=E8=83=9C
--089e014943089fc70d04de5cd09f-- From lorenzo@google.com Tue Jun 4 19:15:15 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED3921F8FB3 for ; Tue, 4 Jun 2013 19:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htXpM3yAqLxe for ; Tue, 4 Jun 2013 19:15:12 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1630021F9AF3 for ; Tue, 4 Jun 2013 19:15:05 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id bn16so3036390qab.14 for ; Tue, 04 Jun 2013 19:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=v5m22QoeBciBrcuxHOz0sMzIek2+3ocpepJ46aZkWT0=; b=Ji6M129iBwUSrGiAhyZa6JONCl6w9EnWxbCdGvjXxoSv4yJdkyQZqJfFxazD57CmCX /W0yjNZY9KrNy6kCq2iIvFOVFaucIV/X5eqjezSMP9nt46RNhYZsdcQEatwF9ypi9hPs LuPv/PYsJNBLlUNPmeCanjPnfM6BuNhgl9vBDBHXerJHricPdy+baiq3qwGDniFB5NSj fBgz9CLZf31DL0K26w3TY4iF0O7gYD88/P6vY50KkbJ9c+b74aMKH1zkyvkCTdw/C2NX UZDBToOWLby+Cb0305HPg997rwBtM2jsFUE6Z4ExPVN7o8Dtw+9mOUhiyJPiVWbMrMG7 k0kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=v5m22QoeBciBrcuxHOz0sMzIek2+3ocpepJ46aZkWT0=; b=kRkD48WTgL74zqgHPHQuYVSqPNgPAjmMr+bdWoxHzo5cC4ZlA9KbKxn/UINtItOq3/ Sl//lHkZymUw9nXwCvFSj4qzzD+nFqp8mf4T9EX0oEbyUuGw5kWWaKe7Qusgs4N1O5ax cGgwj8WUQThkpawcdI9f3uPkn4mxftq9jlvg4icnLjAGn6TxHEgOGUnQGcXk8ZsI5T4O 3nd2J69g2cyTjeqvdrMLWMFRUbT9B0fO4CSoLQZZikkRnXT17+1ErwNcBgIZULWS6EVG tctO2sqX1n75zGub+pkpxNLQF63pjDePsK19BaNXiR8V2aAWabIRpklQtwqTFZATyod4 Ncsw== X-Received: by 10.229.160.144 with SMTP id n16mr10271171qcx.154.1370398490755; Tue, 04 Jun 2013 19:14:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.158.8 with HTTP; Tue, 4 Jun 2013 19:14:29 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C4022@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> <050AD4E8-31AA-41DD-A137-06A8542D8C21@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C4022@mbx-01.win.nominum.com> From: Lorenzo Colitti Date: Wed, 5 Jun 2013 11:14:29 +0900 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 To: Ted Lemon Content-Type: multipart/alternative; boundary=14dae9472d5b3e2a1004de5ec3da X-Gm-Message-State: ALoCoQl3lOt0LmWBOnLvCyXrxRGU7O7cWF2w3+w7Fr60lZwInCQlG7cpUj2TTlbWPHzjm2Y4HFFCu12asDBxpm/ZiaZ1bOvtD7W77DzI18sn8AwgEb7aoANH34U/CADtg1ymkDSGRooDJhRFTKDoi25g29NLt831KSzGF6Gs9O6hzo4+kpORP2MpRTCOLd3R/xdjoEwCsJxE Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 02:15:17 -0000 --14dae9472d5b3e2a1004de5ec3da Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 5, 2013 at 2:05 AM, Ted Lemon wrote: > So even though we have solutions to allocate prefixes efficiently in > arbitrary home network topologies > We don't have solutions. We only have ideas on how solutions might be built, and it must be noted that those ideas have not been adopted by any WG so far. So I would say this statement is premature. > even though these solutions are just as easy to deploy as the solution > that wastes addresses, > Those solutions are not "just as easy to deploy", because they require more standardization and more sophisticated home router implemetations than the wasteful solution (which, I might add, is also being presented in the same working group). We may get there, but I think it's by no means guaranteed. Addressing policy cannot be shaped on what the IETF thinks might happen in the best case. It must be done taking into account real world constraints. If efficiently-addressed, routed home networks don't happen, then the only way to allow routed home networks is to use a hierarchical solution (which works today - it's what I have at home, using hardware that is already deployed in the high single digit millions of units). --14dae9472d5b3e2a1004de5ec3da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 2:05 AM, Ted Lemon <Ted.Lemon@= nominum.com> wrote:
So even though we have solutions to allocate prefixes efficiently in a= rbitrary home network topologies

We don't have solutions. We only have ideas on how solutions mi= ght be built, and it must be noted that those ideas have not been adopted b= y any WG so far. So I would say this statement is premature.
=A0
even though these solutions are just as easy to deploy as the solution th= at wastes addresses,

Those solutions are not = "just as easy to deploy", because they require more standardizati= on and more sophisticated home router implemetations than the wasteful solu= tion (which, I might add, is also being presented in the same working group= ). We may get there, but I think it's by no means guaranteed.

Addressing policy cannot be shaped on what = the IETF thinks might happen in the best case. It must be done taking into = account real world constraints. If efficiently-addressed, routed home netwo= rks don't happen, then the only way to allow routed home networks is to= use a hierarchical solution (which works today - it's what I have at h= ome, using hardware that is already deployed in the high single digit milli= ons of units).
--14dae9472d5b3e2a1004de5ec3da-- From Ted.Lemon@nominum.com Tue Jun 4 19:46:24 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB0B21F9AE8; Tue, 4 Jun 2013 19:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.374 X-Spam-Level: X-Spam-Status: No, score=-106.374 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fNEBnU3OG5z; Tue, 4 Jun 2013 19:46:17 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4B91F21F93B9; Tue, 4 Jun 2013 19:46:17 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUa6meOaCGMxO2LIX2BAx2XGPOz9wH7Us@postini.com; Tue, 04 Jun 2013 19:46:17 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8F5021B81F4; Tue, 4 Jun 2013 19:46:16 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 805AF190052; Tue, 4 Jun 2013 19:46:16 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Tue, 4 Jun 2013 19:46:16 -0700 From: Ted Lemon To: Lorenzo Colitti Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAFFqgIAAA0MAgAAlngCAAERTAIAAmIuAgAAWAQCAALv5gIAAMI2AgACc9YCAACD6gIAAH1gAgACZeoCAAAjegA== Date: Wed, 5 Jun 2013 02:46:14 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C4D5F@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> <050AD4E8-31AA-41DD-A137-06A8542D8C21@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C4022@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C4D5Fmbx01winnominum_" MIME-Version: 1.0 Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 02:46:24 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C4D5Fmbx01winnominum_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jun 4, 2013, at 10:14 PM, Lorenzo Colitti > wrote: Addressing policy cannot be shaped on what the IETF thinks might happen in = the best case. It must be done taking into account real world constraints. = If efficiently-addressed, routed home networks don't happen, then the only = way to allow routed home networks is to use a hierarchical solution (which = works today - it's what I have at home, using hardware that is already depl= oyed in the high single digit millions of units). Be that as it may, ISPs all seem to be deploying networks with /56's to the= home, not /48's. Edge-rooted PD is an ops doc=97no new protocol work is = required. --_000_8D23D4052ABE7A4490E77B1A012B6307751C4D5Fmbx01winnominum_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jun 4, 2013, at 10:14 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
Addressing policy cannot be shaped on what the IETF thinks might happen in the best c= ase. It must be done taking into account real world constraints. If efficie= ntly-addressed, routed home networks don't happen, then the only way to all= ow routed home networks is to use a hierarchical solution (which works today - it's what I have at home, usi= ng hardware that is already deployed in the high single digit millions of u= nits).

Be that as it may, ISPs all seem to be deploying networks with /56's t= o the home, not /48's.   Edge-rooted PD is an ops doc=97no new protoco= l work is required.

--_000_8D23D4052ABE7A4490E77B1A012B6307751C4D5Fmbx01winnominum_-- From lorenzo@google.com Tue Jun 4 19:53:54 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9D621F9B2B for ; Tue, 4 Jun 2013 19:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CR1glCCI73qt for ; Tue, 4 Jun 2013 19:53:54 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id B927521F9B1C for ; Tue, 4 Jun 2013 19:53:53 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id e1so622033qcy.36 for ; Tue, 04 Jun 2013 19:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9DklSEAu1t6IWzYoLUWsXSu1daZEshbJCoYHXGCiBl8=; b=kVGoMfNPF5R4tCWTXfDgpf53TxwggZ+JsOVxVXzHRusJIKZ9OrasQkJ2gafpUfEmHj Tw5O544d6DfxbP5K58zspDWSfuSkG21zrDs9wCeAeTD0h3v3pUxDD3f1EZ2Bjvc1GV5Y 8/o8bm7stXpBvnw2EZeGSB1QXBrZ4zk89YIa9g645+ykTXIbXYjdGyoG25uErCyzQDYb /yCO8JLytllirmLSx30s7X+zNXylTTVkUkze8xegCg7oNV7VBmyfoDO2LBVx947PNMo0 czBds89Pdon+00g5IXqIK5ybX/cOgAvxqY57gfUS8exDN+MhljW+N/Ep9IveU7V02UGi Md/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=9DklSEAu1t6IWzYoLUWsXSu1daZEshbJCoYHXGCiBl8=; b=ikEMzpILtHDRNyaufs0V6GMmDPO88nWtlnne0GzLm9HpaanAjES+sE6YWJZLfdS+a+ VWbBGTo5dkjM6HEwrZTlq8Ouc/359xhrF3t5d8PdRUMxTmD73/wsT1D5UI7NETuJvaH1 qUmo8V11G2aAB+RjwIHhE+d2Wev+TL3OCJ3znUMf7uf5XWGhEkGRQgg3t6tT24kXqbOD kcAfbBL/8Eb5FOVdA/vM/R73ULQZ+3MIIupQQzg7GjEeY3RhqJYVI9lu5ulewc7Sn8qy iPyBEbr66AY/QMSeIv1TdukJ6AZfd4ZJWbv6HudNIRfzVpub9JCYK+bMez65lF3JTkM/ WxRQ== X-Received: by 10.49.49.167 with SMTP id v7mr30478980qen.10.1370400833111; Tue, 04 Jun 2013 19:53:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.158.8 with HTTP; Tue, 4 Jun 2013 19:53:32 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C4D5F@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> <050AD4E8-31AA-41DD-A137-06A8542D8C21@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C4022@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C4D5F@mbx-01.win.nominum.com> From: Lorenzo Colitti Date: Wed, 5 Jun 2013 11:53:32 +0900 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7b6da828dbb35304de5f4ed2 X-Gm-Message-State: ALoCoQlEz60rP5p33jkEB5/UuK5n+YMVa3Ger1bXID921sKYX1kF1kKyZG5KbcbW1FZKYVJdcFon83UAnWnsAl+7y8e+DFLalf1hTvEdBqhhtpV/eAOEu5RT8yZAb/+XqljiABRa3OG/FO42U9Mtv3EkAmGrxeSL+x1XbNjP3XyaAS/vutGVDbBq2HZYzOy65Lt/1VDUG0H3 Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 02:53:54 -0000 --047d7b6da828dbb35304de5f4ed2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Jun 5, 2013 at 11:46 AM, Ted Lemon wrote: > Be that as it may, ISPs all seem to be deploying networks with /56's to > the home, not /48's. Edge-rooted PD is an ops doc=97no new protocol wor= k is > required. > So then your argument should be "RIRs should not plan to assign /48s to subscribers because ISPs are assigning /56s to subscribers anyway"? --047d7b6da828dbb35304de5f4ed2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 11:46 AM, Ted Lemon <Ted.Lemon= @nominum.com> wrote:
Be that as it may, ISPs all seem to be deploying networks with /56'= ;s to the home, not /48's. =A0 Edge-rooted PD is an ops doc=97no new pr= otocol work is required.

So then your argument should be "RIRs should not plan to assign /48s t= o subscribers because ISPs are assigning /56s to subscribers anyway"?<= /div>
--047d7b6da828dbb35304de5f4ed2-- From Ted.Lemon@nominum.com Tue Jun 4 20:02:59 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D08C21F9B26; Tue, 4 Jun 2013 20:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.529 X-Spam-Level: X-Spam-Status: No, score=-106.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2R4r4RT8cO4g; Tue, 4 Jun 2013 20:02:48 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id F134F21F9AFB; Tue, 4 Jun 2013 20:02:47 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUa6qVwumnLyEyrP/pwQ4njEaJx69GPHO@postini.com; Tue, 04 Jun 2013 20:02:48 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8F51E1B81F1; Tue, 4 Jun 2013 20:02:47 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 83680190052; Tue, 4 Jun 2013 20:02:47 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Tue, 4 Jun 2013 20:02:47 -0700 From: Ted Lemon To: Lorenzo Colitti Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAFFqgIAAA0MAgAAlngCAAERTAIAAmIuAgAAWAQCAALv5gIAAMI2AgACc9YCAACD6gIAAH1gAgACZeoCAAAjegIAAAgsAgAAClQA= Date: Wed, 5 Jun 2013 03:02:46 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C4E3E@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C4E3Embx01winnominum_" MIME-Version: 1.0 Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 03:02:59 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C4E3Embx01winnominum_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jun 4, 2013, at 10:53 PM, Lorenzo Colitti > wrote: So then your argument should be "RIRs should not plan to assign /48s to sub= scribers because ISPs are assigning /56s to subscribers anyway"? No, it shouldn't. My argument is that the belief that no bits are availab= le for use in semantic prefix-based routing is not sustainable. It may be= that semantic bits in the prefix are a bad idea for any of a variety of re= asons, but there are bits available if ISPs decide to architect their netwo= rk using semantic prefixes. We were quibbling over one way of acquiring s= uch bits, but the fundamental point is that such bits can be acquired, so t= he premise that they can't is not useful in arguing against the use of sema= ntic prefixes. If semantic prefixes are a bad idea, it's for some other reason than bits. = It would be helpful if the conversation could leave behind this rathole a= nd move on to discussing whatever it is that is actually wrong with semanti= c prefixes. --_000_8D23D4052ABE7A4490E77B1A012B6307751C4E3Embx01winnominum_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jun 4, 2013, at 10:53 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
So then your argument should be "RIRs should not plan to assign /48s to = subscribers because ISPs are assigning /56s to subscribers anyway"?

No, it shouldn't.   My argument is that the belief that no bits a= re available for use in semantic prefix-based routing is not sustainable. &= nbsp; It may be that semantic bits in the prefix are a bad idea for any of = a variety of reasons, but there are bits available if ISPs decide to architect their network using semantic prefixes.   = We were quibbling over one way of acquiring such bits, but the fundamental = point is that such bits can be acquired, so the premise that they can't is = not useful in arguing against the use of semantic prefixes.

If semantic prefixes are a bad idea, it's for some other reason than b= its.   It would be helpful if the conversation could leave behind this= rathole and move on to discussing whatever it is that is actually wrong wi= th semantic prefixes.

--_000_8D23D4052ABE7A4490E77B1A012B6307751C4E3Embx01winnominum_-- From john.mann@monash.edu Tue Jun 4 20:07:56 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB7D21F9B3C for ; Tue, 4 Jun 2013 20:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.376 X-Spam-Level: X-Spam-Status: No, score=-5.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDNelOS6cc7Q for ; Tue, 4 Jun 2013 20:07:51 -0700 (PDT) Received: from na3sys009aog106.obsmtp.com (na3sys009aog106.obsmtp.com [74.125.149.77]) by ietfa.amsl.com (Postfix) with ESMTP id D2B8F21F9B34 for ; Tue, 4 Jun 2013 20:07:50 -0700 (PDT) Received: from mail-we0-f172.google.com ([74.125.82.172]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKUa6rhdStmwT583VaUiaeVUKz09gXnsn7@postini.com; Tue, 04 Jun 2013 20:07:51 PDT Received: by mail-we0-f172.google.com with SMTP id q56so864060wes.31 for ; Tue, 04 Jun 2013 20:07:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=N7cjIbUECAS8WTipF9lSJx21BQZUt/flMpEEj25qrIg=; b=XhzyUcG822ZCTT+5DoBywOIbIoppQ9JOXqir5qe3NvYbFLy4A6ZKHFsXBlB2BZr2uN X2/NSAbjXXBWVpjPtoccfQs6ixNSIP5OUZbDe4lxGiyQwo2rig8FB8Q8nwbG2gxDIa7r hIgn6k6Hzbsa8Vf7EhCf3TYXpMQopbQOwWJg5XWdLSXM8AgFSue0dHO4IdpgyMjQ2zBu rqZ1ZF+C2MMnqoQvV2UyvsQsDwdti91DopHxLe3o9vY88Oe1fSjKnp3BJMOg1q8iqIw3 eniRpEvQ1pui9kbiLll9t6UfVMbjjIQKZoS39HMHxxxFRvlINz9vpFcKeBeEkvdpxQXb cERg== X-Received: by 10.180.9.80 with SMTP id x16mr4208652wia.63.1370401668246; Tue, 04 Jun 2013 20:07:48 -0700 (PDT) X-Received: by 10.180.9.80 with SMTP id x16mr4208643wia.63.1370401668167; Tue, 04 Jun 2013 20:07:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.112.201 with HTTP; Tue, 4 Jun 2013 20:07:28 -0700 (PDT) In-Reply-To: References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <51A71ACA.3000608@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC994A0@nkgeml512-mbx.china.huawei.com> <51A733E1.7040008@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99A07@nkgeml512-mbx.china.huawei.com> <51A841B5.3010805@globis.net> <5D36713D8A4E7348A7E10DF7437A4B923AC99CF4@nkgeml512-mbx.china.huawei.com> <6B838546-4FB3-4EDB-9F84-D8CF0AF3080D@millnert.se> <51A87174.3080204@globis.net> <51ACA39F.2000009@kit.edu> From: John Mann Date: Wed, 5 Jun 2013 13:07:28 +1000 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 To: Sheng Jiang Content-Type: multipart/alternative; boundary=001a11c21f84a18a1c04de5f80b6 X-Gm-Message-State: ALoCoQlO6sowbkzxJ2NqBQ01TwhWSrUcAeFdn1sfJhyWgYpCqIzX5b7pMBJWd1D7wvDKYQadvsiJFsDmCDJC5wCC5/cAd39UsMf7HrWQc2eGdqxOwCGUCg8HqQODN99J6O8QlCsFz4DS Cc: Ray Hunter , "" , "ipv6@ietf.org" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 03:07:56 -0000 --001a11c21f84a18a1c04de5f80b6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I see some issues when using non-topological address hierarchies: 1. For example, if you use addresses then you can have one route entry to route all traffic to a location, i.e. But, it is harder to send traffic of one over different links than other classes -- you can't have 1 route table entry for: <*> --> <*> You need L routes if you have L locations. [ Does your router support non-contiguous masks in ACLs, route-maps etc ?? See e.g. Cisco IOS IPv6 Command Reference http://www.cisco.com/en/US/docs/ios/ipv6/command/reference/ipv6_10.html#wp2= 653677 IPv6 ACLs only allow e.g. *source-ipv6-prefix*/*prefix-length* which only specifies a left-most contiguous set of bits. It doesn't allow for non-contiguous wildcard-masks like IPv4 did. ] 2. Conversely, if you use addresses then it is easier to route via and ACLs are very easy. But you aren't aggregating by location any more. 3. Or, if you use addresses then you get route aggregation per location, and aggregation per user. But you have lost all route aggregation by and if you can't do non-contiguous ACLs, then filtering by will be very hard. =3D=3D=3D And if you have more semantic fields, then the routing and ACL complexity compounds. =3D=3D=3D At Monash University, the IPv6 address plan is basically ACLs by or are easy. We aren't summarising routes in our IGP, so not being able to summarise by location isn't a big issue for us. John On 4 June 2013 11:13, Sheng Jiang wrote: > Hi, Roland, > > Thanks for your comments. Yes, the authors will restructure this draft - > making it more an analysis draft rather than a proposal. The pitfalls wil= l > be an very important part for a neutral analysis. > > Cheers, > > Sheng > > > On 3 June 2013 22:09, Bless, Roland (TM) wrote: > >> Hi, >> >> On 31.05.2013 11:46, Ray Hunter wrote: >> >> > But why are people coming up with these schemes for encoding semantics >> > in the address prefixes in the first place? That's what I'd like to >> > understand first and foremost: what lack of functionality is >> > motivating/forcing these people to adopt such schemes? >> >> I'm not sure. Some impressions from the draft I got when I browsed >> over it: >> - An address is something that the provider controls, therefore >> it may have more trust in the address information, esp. if >> source address filtering is done properly. The draft seems >> to promote the idea in favor of others like DSCP marking >> (which is untrusted up to the boundary node anyway). >> >> - Overloading semantics is IMHO a bad thing as it complicates >> things as well, e.g., encoding application-level semantics into the >> network layer is generally a bad idea (see end-to-end >> argument - putting appl.-level knowledge into the network implies >> inflexibility and increased complexity). Moreover, choosing the right >> address/network prefix must not require network topology knowledge >> in the application (remembering the site-locals discussion several >> years ago). >> >> - one useful scenario, however, may be the use of different security >> zones. We actually proposed this in an internal network >> of a vehicle - the particular advantage is here that you can easily >> perform security policy enforcement with firewalls and address >> filtering rules. >> However, you also may have a topological/logical subnet structure >> in addition to the security zones, leading to a subnet matrix >> structure. In addition to that you may have different QoS >> requirements for traffic within a subnet, so DSCP marking is also >> orthogonal to the "address" semantics - you should not encode them >> into the prefix as well. >> >> - dividing a network into different subnets according to different >> semantics is nothing unusual and is widely used today, mostly >> motivated by either topological aspects, logical user/device groups, >> and/or trust/security domains. However, semantics b., d. and e. >> of >> >> http://tools.ietf.org/html/draft-jiang-v6ops-semantic-prefix-03#section-= 4.3 >> (applications, traffic identity types, quality requirements) >> seem to be bad reasons for "encoding" them into prefixes, IMHO. >> >> Thus, if the document is adopted somehow, it should rather >> point out the potential pitfalls. Currently, as other already said, >> it reads as it would be a preferred operational method... >> >> Regards, >> Roland >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > > -- > Sheng Jiang =E8=92=8B=E8=83=9C > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --001a11c21f84a18a1c04de5f80b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I see some issues when using = non-topological address=C2=A0hierarchies:

1. For example, if you use addresses
=C2=A0 =C2=A0<I= SP><location><user class><user#><subnet>
then you can have one route entry to route all traffic to a loca= tion, i.e.
=C2=A0 =C2=A0 <ISP><location>
<= div style>But, it is harder to send traffic of one <user class> over = different links than other classes --
you can't have 1 route table entry for: =C2=A0
=C2=A0 =C2=A0<ISP><*><user class1> --> <IS= P><*><user class1>
You need L routes if you = have L locations.

[ Does your router support non-contiguous m= asks in ACLs, route-maps etc ??
=C2=A0 =C2=A0See e.g. Cisco= IOS IPv6 Command Reference
=C2=A0 =C2=A0 =C2=A0 http= ://www.cisco.com/en/US/docs/ios/ipv6/command/reference/ipv6_10.html#wp26536= 77
=C2=A0 =C2=A0IPv6 ACLs only allow e.g. =C2=A0source-ipv6-prefix/<= em class=3D"" style=3D"color:rgb(0,0,0);font-family:Arial,Helvetica,sans-se= rif;font-size:12px">prefix-length=C2=A0= =C2=A0=C2=A0which only specifies a left-most contiguous set of bits.=
=C2=A0 =C2=A0It doesn't allow for non-contiguous wildcard-masks like IP= v4 did.
]

2. Conversel= y, if you use addresses
=C2=A0 <ISP><user class>= ;<location><user#><subnet>
then it is easier to route via <user class> and <user c= lass> ACLs are very easy.
But you aren't aggregating= by location any more.

3. Or, if you u= se addresses
=C2=A0 =C2=A0<ISP><location><user#><user cl= ass><subnet>
then you get route aggregation per lo= cation, and aggregation per user.
But you have lost all rou= te aggregation by <user class>
and if you can't do non-contiguous ACLs, then filtering by &= lt;user class> will be very hard.

= =3D=3D=3D
And if you have more semantic fields, then the ro= uting and ACL complexity compounds.

=3D=3D=3D
At Monash Univers= ity, the IPv6 address plan is basically
=C2=A0 =C2=A0 <I= SP><user class><faculty><location>
ACL= s by <user class> or <user class><faculty> are easy.
We aren't summarising routes in our IGP, so not being able t= o summarise by location isn't a big issue for us.

<= /div>
=C2=A0 =C2=A0 John



On 4 June 2013 11:13, Sheng Jiang <s= hengjiang@gmail.com> wrote:
Hi, Roland,
=C2=A0
Thanks for you= r comments. Yes, the authors will restructure this draft - making it more a= n analysis draft rather than a proposal. The pitfalls will be an very impor= tant part for a neutral analysis.
=C2=A0
Cheers,
=C2=A0
Sheng
<= div class=3D"gmail_extra">

On 3 June 2013= 22:09, Bless, Roland (TM) <roland.bless@kit.edu> wrote:<= br>
Hi,

On 31.05.2013 11:46, Ray Hunter wrote:

> But why are people coming up with these schemes for encoding semantics=
> in the address prefixes in the first place? That's what I'd li= ke to
> understand first and foremost: what lack of functionality is
> motivating/forcing these people to adopt such schemes?

I'm not sure. Some impressions from the draft I got when I browse= d
over it:
- An address is something that the provider controls, therefore
=C2=A0 it may have more trust in the address information, esp. if
=C2=A0 source address filtering is done properly. The draft seems
=C2=A0 to promote the idea in favor of others like DSCP marking
=C2=A0 (which is untrusted up to the boundary node anyway).

- Overloading semantics is IMHO a bad thing as it complicates
=C2=A0 things as well, e.g., encoding application-level semantics into the<= br> =C2=A0 network layer is generally a bad idea (see end-to-end
=C2=A0 argument - putting appl.-level knowledge into the network implies =C2=A0 inflexibility and increased complexity). Moreover, choosing the righ= t
=C2=A0 address/network prefix must not require network topology knowledge =C2=A0 in the application (remembering the site-locals discussion several =C2=A0 years ago).

- one useful scenario, however, may be the use of different security
=C2=A0 zones. We actually proposed this in an internal network
=C2=A0 of a vehicle - the particular advantage is here that you can easily<= br> =C2=A0 perform security policy enforcement with firewalls and address
=C2=A0 filtering rules.
=C2=A0 However, you also may have a topological/logical subnet structure =C2=A0 in addition to the security zones, leading to a subnet matrix
=C2=A0 structure. In addition to that you may have different QoS
=C2=A0 requirements for traffic within a subnet, so DSCP marking is also =C2=A0 orthogonal to the "address" semantics - you should not enc= ode them
=C2=A0 into the prefix as well.

- dividing a network into different subnets according to different
=C2=A0 semantics is nothing unusual and is widely used today, mostly
=C2=A0 motivated by either topological aspects, logical user/device groups,=
=C2=A0 and/or trust/security domains. However, semantics b., d. and e.
=C2=A0 of
http://tools.ietf.org/html/draft-jiang-v6ops= -semantic-prefix-03#section-4.3
(applications, traffic identity types, quality requirements)
=C2=A0 seem to be bad reasons for "encoding" them into prefixes, = IMHO.

Thus, if the document is adopted somehow, it should rather
point out the potential pitfalls. Currently, as other already said,
it reads as it would be a preferred operational method...

Regards,
=C2=A0Roland


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



--
Sheng Jiang =E8=92=8B=E8=83=9C

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


--001a11c21f84a18a1c04de5f80b6-- From lorenzo@google.com Tue Jun 4 20:11:43 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6086021F96EA for ; Tue, 4 Jun 2013 20:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWg1HPE4d58p for ; Tue, 4 Jun 2013 20:11:42 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id A173821F9385 for ; Tue, 4 Jun 2013 20:11:42 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c10so181020qcz.28 for ; Tue, 04 Jun 2013 20:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=POD63/U9c6Jv2I0yfuDh49wkn0G8e3cCR0c5bxywvpM=; b=KfoKLCTStyA4LJgIgamdI/udIQwA1hOyS/1Mg12TD6hBGglEiv5GLh4ia8wec9Rd/c NbnTCIH77CGKoxb+FY5RuzIkJSa2ZI65nkkTzQvu90eiHoTk41UTjG+DvUho4YeO9EQ+ bnGheTaA0bUJq8RP4JpZ5Q/mi4YkkavMmdQmqq35eXld9gXZ53d9ek2UzzP96J8LNNhe D1oAg+OY5fZxgxvQv/bpf5MUv7n43a34pJ4JxkTIgepWQj9kSvD24aqKp9h8ovxevYb5 tgUc7EPj1XcdcU1em+fHGM2vf5xLrDGMibk0vIKDrf9Ab1notSlMRjhxRrRVxT/V9YGL T8Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=POD63/U9c6Jv2I0yfuDh49wkn0G8e3cCR0c5bxywvpM=; b=RPGU/85mWijELq2Ybrt+tR5ojq4D3pOe6OwJAtKznjcIALcs8+52toai3vajZ/8nbY HPO3V6D2ssE5SmkPBHmFDZ702YcnyflCPrtKbhjXpM4vhwj3B6rjb0MVHPbpOrZ0s9xU 3dVCnhy7RNhKOdros41mddQRDUvdKFyYtK+mQyB5v+O9gfyHPqLY1Zt0w3b5obZt9i/a hvN7GE3qtIGdA+jyN1yjtfHa9WnyHbNcCqKJS3r81br2m8oI4SFAQFvUX52Kdyxq+GOZ wtH2h1S5FjRub2AHJ2RpWgzoh/fP9Q3HoSIYBiTPEvWyDmleXEwTkjDofCIbFHsryT6T j4oQ== X-Received: by 10.229.160.144 with SMTP id n16mr10333865qcx.154.1370401901953; Tue, 04 Jun 2013 20:11:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.158.8 with HTTP; Tue, 4 Jun 2013 20:11:21 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C4E3E@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B6307751C4E3E@mbx-01.win.nominum.com> From: Lorenzo Colitti Date: Wed, 5 Jun 2013 12:11:21 +0900 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 To: Ted Lemon Content-Type: multipart/alternative; boundary=14dae9472d5b90f0c704de5f8eeb X-Gm-Message-State: ALoCoQlz9i9bJFokSMMufX/8QbufrmjEiwJNxB7P59ajwCcfY+Pj16i5DMkbD7XRmcOGBCZf62h/+0OjAJLANo5dP1k673wouJgPFPYxPZABsN5pBVub4GC1TJPDYuXD7uh2TD3K+TCEHSlN0BwLi6C0NsTTJlOROalHx3zUdJPhOVJla+XoWUMwbZ/MFekN0UyI8RCdAG/r Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 03:11:43 -0000 --14dae9472d5b90f0c704de5f8eeb Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 5, 2013 at 12:02 PM, Ted Lemon wrote: > So then your argument should be "RIRs should not plan to assign /48s to > subscribers because ISPs are assigning /56s to subscribers anyway"? > > > No, it shouldn't. My argument is that the belief that no bits are > available for use in semantic prefix-based routing is not sustainable. > Wait, but the email I just replied to was talking about user allocations. I guess the question is: if every user gets a /48, are there still bits available for semantic prefixes or not? If so, then we don't have to have this conversation. If not, then it seems to me that the situation is that ISPs can choose to either assign users /48s or use semantic prefixes, but not both. If that's the case, you can certainly then say "there's no point in giving users /48, it's too much" - that's a perfectly valid opinion to hold. However, we must take into account that today, RIR policy is based on allowing ISPs to assigning /48s to users. Which of the two is it? --14dae9472d5b90f0c704de5f8eeb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 12:02 PM, Ted Lemon <Ted.Lemon= @nominum.com> wrote:
So then your argument should be "RIRs should not plan to assign /48s to = subscribers because ISPs are assigning /56s to subscribers anyway"?

No, it shouldn't. =A0 My argument is that the belief that no bits = are available for use in semantic prefix-based routing is not sustainable.<= /div>

Wait, but the email I just repl= ied to was talking about user allocations.

I guess the question is: if every user gets a /48, are = there still bits available for semantic prefixes or not? If so, then we don= 't have to have this conversation. If not, then it seems to me that the= situation is that ISPs can choose to either assign users /48s or use seman= tic prefixes, but not both.

If that's the case, you can certainly then say &quo= t;there's no point in giving users /48, it's too much" - that&= #39;s a perfectly valid opinion to hold. However, we must take into account= that today, RIR policy is based on allowing ISPs to assigning /48s to user= s.

Which of the two is it?
--14dae9472d5b90f0c704de5f8eeb-- From Ted.Lemon@nominum.com Tue Jun 4 20:20:34 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3480421F9AB9; Tue, 4 Jun 2013 20:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.531 X-Spam-Level: X-Spam-Status: No, score=-106.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fga8pQwUiz9E; Tue, 4 Jun 2013 20:20:27 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6044121F9AB0; Tue, 4 Jun 2013 20:20:26 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUa6uecfkkvKMwkIf8Y6i1imKuAc2Iu0t@postini.com; Tue, 04 Jun 2013 20:20:26 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 3D0FF108002; Tue, 4 Jun 2013 20:20:25 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2116F190052; Tue, 4 Jun 2013 20:20:25 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Tue, 4 Jun 2013 20:20:19 -0700 From: Ted Lemon To: Lorenzo Colitti Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAFFqgIAAA0MAgAAlngCAAERTAIAAmIuAgAAWAQCAALv5gIAAMI2AgACc9YCAACD6gIAAH1gAgACZeoCAAAjegIAAAgsAgAAClQCAAAJmgIAAAoAA Date: Wed, 5 Jun 2013 03:20:18 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C4F11@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B6307751C4E3E@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C4F11mbx01winnominum_" MIME-Version: 1.0 Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 03:20:34 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C4F11mbx01winnominum_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jun 4, 2013, at 11:11 PM, Lorenzo Colitti > wrote: On Wed, Jun 5, 2013 at 12:02 PM, Ted Lemon > wrote: So then your argument should be "RIRs should not plan to assign /48s to sub= scribers because ISPs are assigning /56s to subscribers anyway"? No, it shouldn't. My argument is that the belief that no bits are availab= le for use in semantic prefix-based routing is not sustainable. Wait, but the email I just replied to was talking about user allocations. I guess the question is: if every user gets a /48, are there still bits ava= ilable for semantic prefixes or not? If so, then we don't have to have this= conversation. If not, then it seems to me that the situation is that ISPs = can choose to either assign users /48s or use semantic prefixes, but not bo= th. No, that's not at all a central point of this debate. Someone said that R= IRs won't give ISPs more prefix than they need to give each of their custom= ers a /48. It has been pointed out that RIRs do not in fact have a hard-a= nd-fast policy to this effect, so in fact even an ISP that gives out a /48 = to every customer may be able to use semantic prefixes, depending on the sp= ecific policies of their "local" RIR. In addition, I pointed out that in fact RIR allocation policies based on th= e _assumption_ that each end-user site would get a /48, in combination with= the general tendency of ISPs to _actually_ allocate only a /56, mean that = there are eight bits to play with even if the RIR policy is quite strict. = The ISP can legitimately argue that they are giving those bits to the cust= omer, because they are assigning multiple prefixes to the customer. So th= ere simply isn't a problem getting bits if the ISP decides this is a soluti= on they want to implement. If that's the case, you can certainly then say "there's no point in giving = users /48, it's too much" - that's a perfectly valid opinion to hold. Howev= er, we must take into account that today, RIR policy is based on allowing I= SPs to assigning /48s to users. Which of the two is it? There is no such dichotomy. The question of how wide a mask we ought to g= ive end-users isn't really even open for debate. RIRs are not, at the mom= ent, imposing policy on ISPs that restricts them to only one /56 per custom= er. And it's generally agreed (perhaps not by you) that a /56 is going to= be plenty for a typical end-user home network. So the point isn't that a= /48 is a waste of space. It's that a /48 is assumed, and because it is a= ssumed, there are definitely bits available for semantic prefix assignment. --_000_8D23D4052ABE7A4490E77B1A012B6307751C4F11mbx01winnominum_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jun 4, 2013, at 11:11 PM, Lorenzo Colitti <lorenzo@google.com> wrote:

On Wed, Jun 5, 2013 at 12:02 PM, Ted Lemon <Ted.Lemon= @nominum.com> wrote:
So then your argument should be "RIRs should not plan to assign /48s to = subscribers because ISPs are assigning /56s to subscribers anyway"?

No, it shouldn't.   My argument is that the belief that no bits a= re available for use in semantic prefix-based routing is not sustainable.

Wait, but the email I just replied to was talking about user allocatio= ns.

I guess the question is: if every user gets a /48, are there still bit= s available for semantic prefixes or not? If so, then we don't have to have= this conversation. If not, then it seems to me that the situation is that = ISPs can choose to either assign users /48s or use semantic prefixes, but not both.

No, that's not at all a central point of this debate.   Someone said t= hat RIRs won't give ISPs more prefix than they need to give each of their c= ustomers a /48.   It has been pointed out that RIRs do not in fact hav= e a hard-and-fast policy to this effect, so in fact even an ISP that gives out a /48 to every customer may be able to = use semantic prefixes, depending on the specific policies of their "lo= cal" RIR.

In addition, I pointed out that in fact RIR allocation policies based = on the _assumption_ that each end-user site would get a /48, in combination= with the general tendency of ISPs to _actually_ allocate only a /56, mean = that there are eight bits to play with even if the RIR policy is quite strict.   The ISP can legitimate= ly argue that they are giving those bits to the customer, because they are = assigning multiple prefixes to the customer.   So there simply isn't a= problem getting bits if the ISP decides this is a solution they want to implement.

If that's the case, you can certainly then say "there's no point = in giving users /48, it's too much" - that's a perfectly valid opinion= to hold. However, we must take into account that today, RIR policy is base= d on allowing ISPs to assigning /48s to users.

Which of the two is it?

There is no such dichotomy.   The question of how wide a mask we = ought to give end-users isn't really even open for debate.   RIRs are = not, at the moment, imposing policy on ISPs that restricts them to only one= /56 per customer.   And it's generally agreed (perhaps not by you) that a /56 is going to be plenty for a typical end-us= er home network.   So the point isn't that a /48 is a waste of space. =   It's that a /48 is assumed, and because it is assumed, there are def= initely bits available for semantic prefix assignment.

--_000_8D23D4052ABE7A4490E77B1A012B6307751C4F11mbx01winnominum_-- From lorenzo@google.com Tue Jun 4 20:43:11 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4517221F9AAD for ; Tue, 4 Jun 2013 20:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cE+-8KaO5UF for ; Tue, 4 Jun 2013 20:43:10 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3C94F21F9AB2 for ; Tue, 4 Jun 2013 20:43:09 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id bs12so3084523qab.1 for ; Tue, 04 Jun 2013 20:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xQWZ5JlISF2TFdXpi2HmcUbURAmyMYEMgWw1ewW47YU=; b=AQ/q01thQB/JghhfQMDYUeZAOT7BnZrcFM5gx5qIRs+zKWoEzoHXO38OvomfPSaf9z kkmPytZkWFhUT0x7yc1k0UlDJ2BETDTgdRG9V++oGMCLaaq8k4/EFiSwMPBYS1tzZ0BO IQ/0F00CZvlimL1dMt+ML8lf9n9KH2syt7zmEc0bDUsux/DRYh585WCM8OYyFsCrkobD MYFj0mIJDjurIGQZp7dxWozyULiQQGYERAcC4LwOzIXwpbno8CS35SKALh7Ivd8lAxpw JtbuUmK4gdCpFS9jqvF7r3z49JB0I+oWp/RERKiRlA/mux6ONPse3ASrIFvlKbelRBsZ +yJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=xQWZ5JlISF2TFdXpi2HmcUbURAmyMYEMgWw1ewW47YU=; b=k8lfhzkC98wl6zn0QIGplBbsdc9UpvPJvAeNylLUqFLd43Bsz2Rh9jtXmV5BcWIbMP qWNido217VQ3WBb7rGL0uWhz0kI/qSVVgVgnHx1IfO9s/hSS/gikMQQwrEtxAjxvhP/W rZ5M6r0GuYM7VsWXrMHjiNZzWZsExOXjLtJM88oZB57gIKFx+EdP3yA9gOQklgvvF7ip BCGSnbjW6k9rem9pw4aI9bkMMz7p5zqmo7fQiWCGz4qLpe43Fz6Q0dkroXdF57g7eXAS rfWvxmWPToglJWcgGZ1opTS4kGo/9Bk6nLFhPOTG+rrZHdboUbKO3U1aZ2SN3u8GlIBB QzKA== X-Received: by 10.49.49.167 with SMTP id v7mr30641343qen.10.1370403788624; Tue, 04 Jun 2013 20:43:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.158.8 with HTTP; Tue, 4 Jun 2013 20:42:48 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C4F11@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B6307751C4E3E@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C4F11@mbx-01.win.nominum.com> From: Lorenzo Colitti Date: Wed, 5 Jun 2013 12:42:48 +0900 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7b6da82805471d04de5fffc6 X-Gm-Message-State: ALoCoQncMUcHx2t1quGh9VTjqHJp3+84qJ+jGqE/cFh2P9jr0adwHhx+SHQ5qNUWzhGscgPQH9/14fq20GMTKBXjKxJPwPXoGGW7kWehice9KeHUyfr9m3XCYvTJL8hJoOjA7ZEurtzsObgJ4GufLMOPnlV47EvmcTJaAvpng0OFO2HBvMZhImIitlIlsBCECZm/2uFRGP7R Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 03:43:11 -0000 --047d7b6da82805471d04de5fffc6 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 5, 2013 at 12:20 PM, Ted Lemon wrote: > So the point isn't that a /48 is a waste of space. It's that a /48 is > assumed, and because it is assumed, there are definitely bits available for > semantic prefix assignment. > I still don't understand. What the above sentences seem to be saying is that "there are bits available for semantic prefix assignment because RIRs assume /48 but users don't actually get /48". Is that your point? If so, I don't see how you can also state that there are enough bits to both give every user a /48 and to use semantic prefix bits. --047d7b6da82805471d04de5fffc6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 5, 2013 at 12:20 PM, Ted Lemon <Ted.Lemon= @nominum.com> wrote:
So the point isn't that a /48 is a waste of space. =A0 It's th= at a /48 is assumed, and because it is assumed, there are definitely bits a= vailable for semantic prefix assignment.

I stil= l don't understand. What the above sentences seem to be saying is that = "there are bits available for semantic prefix assignment because RIRs = assume /48 but users don't actually get /48". Is that your point?<= /div>

If so, I don't see how you can also sta= te that there are enough bits to both give every user a /48 and to use sema= ntic prefix bits.
--047d7b6da82805471d04de5fffc6-- From gert@space.net Wed Jun 5 01:37:02 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0083D21F99ED for ; Wed, 5 Jun 2013 01:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBC4GsiGgm41 for ; Wed, 5 Jun 2013 01:37:01 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 4C89A21F9732 for ; Wed, 5 Jun 2013 01:37:00 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 165A360A27 for ; Wed, 5 Jun 2013 10:36:59 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id EF49260A19 for ; Wed, 5 Jun 2013 10:36:58 +0200 (CEST) Received: (qmail 37025 invoked by uid 1007); 5 Jun 2013 10:36:58 +0200 Date: Wed, 5 Jun 2013 10:36:58 +0200 From: Gert Doering To: Sheng Jiang Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Message-ID: <20130605083658.GC2504@Space.Net> References: <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C2D69@mbx-01.win.nominum.com> <7767FF5D-194E-445A-A890-05A3E4C7CCC1@delong.com> <20130604191852.GW2504@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2ZXnG0twRSEA0LxK" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ralph Droms , Owen DeLong , Gert Doering X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 08:37:02 -0000 --2ZXnG0twRSEA0LxK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jun 05, 2013 at 07:55:25AM +0800, Sheng Jiang wrote: > As far as I know, most of Tier1 providers gets /24, /26 or bigger. No :-) As this has nothing to do with the "Tier1"-ness, but with the number of customers that the provider will provide /48s to. So if a "Tier1" is only connecting BGP customer, and never actually giving IPv6 addresses to their customers, they will *not* get more than the default allocation size (usually a /32) from their RIR. OTOH, a Tier3 cable ISP who has 10 million customers and plans to give each of them a /48 can get a /24 or so just fine... > For RIR's policy, please see recent email from George Michaelson. Although > he did not speak in any formal, he explained RIR policy is much flexiable > than most of us thought. I'm aware of RIR policy, which is why I challenged your claims about ISPs having a /20 to play with. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --2ZXnG0twRSEA0LxK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQCVAwUBUa74qqkuBuNlUUl1AQJk2QQAooyY9oZ1JT78nHUTLQvAt7ou6ALCoWFy 5b2ML+EB6xZF9rPiko9e7Bnj2u4VJaxDgMHypl9FwWvNxU/7RTWxCtkBF340rGvE dI55tgy6ooJ3p05ASBrBYZAP6oFHfRuEwANxa+WzI3OTkqFzl6IaegidjSQV77WW L/4BlqUIsnY= =/1TS -----END PGP SIGNATURE----- --2ZXnG0twRSEA0LxK-- From bmanning@isi.edu Wed Jun 5 07:22:02 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A76521F9A61; Wed, 5 Jun 2013 07:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.109 X-Spam-Level: X-Spam-Status: No, score=-103.109 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swy3LgLCqKPz; Wed, 5 Jun 2013 07:21:57 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4519121F99CF; Wed, 5 Jun 2013 07:21:57 -0700 (PDT) Received: from [128.9.184.118] ([128.9.184.118]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r55EL6DV029460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 5 Jun 2013 07:21:06 -0700 (PDT) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=GB2312 From: manning bill In-Reply-To: Date: Wed, 5 Jun 2013 07:21:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3B9C72A5-A1D8-41DC-A605-E95A3F28452A@isi.edu> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C05FE@mbx-01.win.nominum.com> <9B3FBB40-1C85-4918-8003-3DF3FEE68B09@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1603@mbx-01.win.nominum.com> <268AF0A5-9030-4BB5-9DD7-7990FDEB356F@delong.com> <021E64FECA7E5A4699562F4E6671648103D35F@XCH-PHX-503.sw.nos.boeing.com> <6117F474-AEC7-4454-BEB0-0A13BA644BFA@isi.edu> <78FF4AA6-F0B2-4440-8B4E-AD62AC20DB96@steffann.nl> <8E383FD5-22BB-4887-BE2F-F8BB35D1357E@isi.edu> <51ACFC3D.90709@gmail.com> <51AD2208.2010801@bogus.com> <392D823E-36C6-4A25-960A-F6AE783482C2@isi.edu> <634198A4-5A4E-4B59-9B16-311160330A98@isi.edu> To: Sheng Jiang X-Mailer: Apple Mail (2.1283) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu Cc: Ivan Pepelnjak , "v6ops@ietf.org WG" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 14:22:02 -0000 i don't believe that I said support. but when you select cases as representative, you are biasing the result. people place all sorts of semantic clues in the methods of addressing=A1=AD= more so when the addresses themselves are too large to be memnonic.=20 I happen to believe that the idea of documenting semantic constructs is = less interesting as IETF protocol work and more interesting as = operational practice. And as operational practice, describing characteristics of semantic = drivers and implementations might be worthwhile. =20 The caveat is that you still want to restrict your analysis to "typical" = methods=A1=AD which is disingenuous if you are truly doing an analysis = of the methods of embedding semantic constructs in addressing. Your Bias is showing. /bill On 4June2013Tuesday, at 16:44, Sheng Jiang wrote: > We do NOT "support" anything. This would be an analysis document. The = motivation is to document existing typical semantic IP address = mechanisms and analyze them, both good and bad side. I will make this = very clear in the new version. > =20 > Sheng >=20 >=20 > On 4 June 2013 22:44, manning bill wrote: > I believe this is fraught with danger. > It perhaps better to identify semantic constructs than to presuppose = representative cases. >=20 > things like even/odd for in/out-bound links, > lat/log encoding or other geo-location > etc. >=20 > as a survey of technique. >=20 > /bill >=20 >=20 > On 4June2013Tuesday, at 7:32, Sheng Jiang wrote: >=20 > > For sure, we cannot document all variants, but we can document the = most representative ones. My current plan is three categeries: ISP's, = enterprise's and subscribe's. Each categery has one example (in = appendexes), I guess. > > > > Cheers, > > > > Sheng > > > > > > On 4 June 2013 21:51, manning bill wrote: > > are you intending to document -all- variants of the semantics = address holder may use to address and organize their assigned numbers? > > or are you intending to document a "preferred" version of address = semantics? > > > > /bill > > > > > > On 4June2013Tuesday, at 6:24, Sheng Jiang wrote: > > > > > Hi, George, > > > > > > Yes, network operators have the freedom to plan the address in = their prefer ways. There are many different ways to organize address = schemas. Different network operators (including both ISPs and = enterprises) has various considerations. Some consideration may be = important for one network operator while makes much less sense for = others. Why rule out others possibilities or mechanism by saying I have = reasons to do things in my way? There are ISPs and enterprises who have = chosen to embed their cared semantics into address and organize network = or routing polices accordingly. We need to document this and give the = analysis we could. > > > > > > Cheers, > > > > > > Sheng > > > > > > > > > On 4 June 2013 11:25, George Michaelson wrote: > > > Just to remind people, RIR policy is community driven. If the = operations people feel they need a policy for IPv6 allocations and = assignments which takes accounts of semantic bits, they can derive = consensus driven policies to do it. Its not done in the IETF. There = might be an issue with how it squares against IETF goals of = conservation, but thats part of the discussion in RIR policy space = maybe. > > > > > > I think there is a touch of catch-22 here: there isn't a clear = sense this is an industry wide practice demanding that policy initiative = (I do not preclude it: I just observe, it hasn't happened yet) and there = is an absence of a well understood methodology of using it and applying = it which differs radically in outcome from ACL based methods. If there = was an IETF standard I am sure somebody could propose an allocations = model which reflected it, but who knows if that would get traction. > > > > > > I notice that there are large providers who feel semantic bit = flagging works for them. So, I do not say "nobody is doing it" as much = as "nobody has said they want an RIR allocations policy which reflects = it, yet" > > > > > > The first time this came up, I think I said to mike that I could = understand ISPs wanting to say "this is a mechanism we use inside our = locus of control, to flag behaviours of packets" -ie that it was = unlikely there was a model for this to be meaningful between providers, = but inside a single autonomous region, sure: why not. (the formalism = that you didn't get the /32 under a model of consumption which assumed = this kind of usage of the bits is really not a big deal for me = personally, although I am sure it would upset some people) > > > > > > -G > > > > > > PS I am an RIR employee. I do not speak to policy in any formal = sense. I work in research. > > > > > > > > > On Tue, Jun 4, 2013 at 12:11 PM, Ivan Pepelnjak = wrote: > > > Read the recent "p2p /64" thread of ipv6-ops cluenet mailing list > > > > > > =3D=3D=3D=3D=3D > > > Mistyped and autocorrected on a clunky virtual keyboard > > > > > > On 4. jun. 2013, at 01:08, joel jaeggli wrote: > > > > > > > On 6/3/13 3:59 PM, Andrew McGregor wrote: > > > >> That's completely true; many switch chips cannot route on = longer than /64 prefixes, so attempting to do so starts to either heat = up the software slow path, or consume ACL entries, or is simply not = supported at all. While this is arguably a bug, it is also pretty much = ubiquitous in the current generation of ethernet switches, which are the = basis for the majority of routers. > > > > please cite specifics. I have no devices in the field that have = such a limitation. > > > > > > > > joel > > > >> > > > >> > > > >> On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter = > = wrote: > > > >> > > > >> On 04/06/2013 03:44, manning bill wrote: > > > >> > On 2June2013Sunday, at 16:47, Sander Steffann wrote: > > > >> > > > > >> >> On 03/06/2013 11:06, manning bill wrote: > > > >> >>> /48's are a horrible policy - one should only advertise = what > > > >> one is actually using. > > > >> >> Now *that* would cause a nice fragmented DFZ... > > > >> >> Sander > > > >> >> > > > >> > > > > >> > > > > >> > I'm going to inject a route. One route. why do you care if = its a > > > >> /9, a /28, a /47, or a /121? > > > >> > > > >> I've heard tell that there are routers that are designed to = handle > > > >> prefixes up to /64 efficiently but have a much harder time = with > > > >> prefixes longer than that, as a reasonable engineering = trade-off. > > > >> Not being a router designer, I don't know how true this is. > > > >> > > > >> Brian > > > >> > > > >> Its -one- route. > > > >> > That one route covers everything I'm going to use=A1=AD = and nothing > > > >> I'm not. > > > >> > > > > >> > Is there a credible reason you want to be the vector of = DDoS > > > >> attacks, by announcing dark space (by proxy aggregation)? > > > >> > Is that an operational liability you are willing to = assume, just > > > >> so you can have "unfragmented" DFZ space? > > > >> > > > > >> > > > > >> > /bill > > > >> > > > >> = -------------------------------------------------------------------- > > > >> IETF IPv6 working group mailing list > > > >> ipv6@ietf.org > > > >> Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6 > > > >> = -------------------------------------------------------------------- > > > >> > > > >> > > > >> > > > >> > > > >> = -------------------------------------------------------------------- > > > >> IETF IPv6 working group mailing list > > > >> ipv6@ietf.org > > > >> Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6 > > > >> = -------------------------------------------------------------------- > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > > > > > > > > -- > > > Sheng Jiang =BD=AF=CA=A4 > > > > > > > > > > -- > > Sheng Jiang =BD=AF=CA=A4 >=20 >=20 >=20 >=20 > --=20 > Sheng Jiang =BD=AF=CA=A4 From sander@steffann.nl Wed Jun 5 07:23:15 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517B621F9AB6; Wed, 5 Jun 2013 07:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdb98HM+7AgP; Wed, 5 Jun 2013 07:23:14 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 13D0021F99CF; Wed, 5 Jun 2013 07:23:14 -0700 (PDT) Received: from [IPv6:2a00:8640:1::dda3:3329:89ea:aaa4] (unknown [IPv6:2a00:8640:1:0:dda3:3329:89ea:aaa4]) by mail.sintact.nl (Postfix) with ESMTP id 18D66202E; Wed, 5 Jun 2013 16:23:12 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Sander Steffann In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C4D5F@mbx-01.win.nominum.com> Date: Wed, 5 Jun 2013 16:23:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1507C534-9CA6-4170-AB04-0D41E13D58A7@steffann.nl> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mb x-01.win.nominum.com> <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> <050AD4E8-31AA-41DD-A137-06A8542D8C21@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C4022@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C4D5F@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org WG" , draft-jiang-v6ops-semantic-prefix@tools.ietf.org, "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 14:23:15 -0000 Hi Ted, Op 5 jun. 2013, om 04:46 heeft Ted Lemon het = volgende geschreven: > Be that as it may, ISPs all seem to be deploying networks with /56's = to the home, not /48's. Not in my part of the world (Netherlands). They all give at least a /56. = These I know: - XS4ALL: /48 to all using PPPoA with DHCPv6-PD - Solcon: /56 to home users using PPPoA with DHCPv6-PD - OnsBrabantNet: /56 to all using 6rd I know that KPN (the Dutch incumbent, one of the biggest ISPs of The = Netherlands) will do /48 to all as well. They haven't deployed yet = though. So they playing field is mixed. Some do /56, but the major players do = (or will do) /48. Cheers, Sander From Ted.Lemon@nominum.com Wed Jun 5 07:54:17 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B73421F9AA5; Wed, 5 Jun 2013 07:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.533 X-Spam-Level: X-Spam-Status: No, score=-106.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAy2hKT1VW3V; Wed, 5 Jun 2013 07:54:10 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9552121F9952; Wed, 5 Jun 2013 07:54:10 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUa9RDjv9+3HuTk9Prex7MH3VamrnAJ1P@postini.com; Wed, 05 Jun 2013 07:54:10 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 11C131B81E3; Wed, 5 Jun 2013 07:54:06 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0677B19005C; Wed, 5 Jun 2013 07:54:06 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 07:54:06 -0700 From: Ted Lemon To: Lorenzo Colitti Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAFFqgIAAA0MAgAAlngCAAERTAIAAmIuAgAAWAQCAALv5gIAAMI2AgACc9YCAACD6gIAAH1gAgACZeoCAAAjegIAAAgsAgAAClQCAAAJmgIAAAoAAgAAGSQCAALuOgA== Date: Wed, 5 Jun 2013 14:54:05 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C554C@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B6307751C4E3E@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C4F11@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C554Cmbx01winnominum_" MIME-Version: 1.0 Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 14:54:17 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C554Cmbx01winnominum_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jun 4, 2013, at 11:42 PM, Lorenzo Colitti > wrote: I still don't understand. What the above sentences seem to be saying is tha= t "there are bits available for semantic prefix assignment because RIRs ass= ume /48 but users don't actually get /48". Is that your point? No. There are bits available because (1) RIRs may well allocate them even = to ISPs that assign /48s to end-users and (2) RIRs definitely do not assume= allocations smaller than /48 per customer, so ISPs can get the allocation = they need and use some of the bits for a semantic prefix, assigning a wider= prefix to the end-user (e.g., a /56). --_000_8D23D4052ABE7A4490E77B1A012B6307751C554Cmbx01winnominum_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <08C761C79591D2478FB09B70B276DE21@nominum.com> Content-Transfer-Encoding: quoted-printable
On Jun 4, 2013, at 11:42 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
I still don't understand. What the above sentences seem to be saying is that= "there are bits available for semantic prefix assignment because RIRs= assume /48 but users don't actually get /48". Is that your point?

No.  There are bits available because (1) RIRs may well allocate = them even to ISPs that assign /48s to end-users and (2) RIRs definitely do = not assume allocations smaller than /48 per customer, so ISPs can get the a= llocation they need and use some of the bits for a semantic prefix, assigning a wider prefix to the end-user (e.g.= , a /56).

--_000_8D23D4052ABE7A4490E77B1A012B6307751C554Cmbx01winnominum_-- From ian.farrer@telekom.de Wed Jun 5 01:00:50 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0243F21F8609; Wed, 5 Jun 2013 01:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AJk70GeiyFV; Wed, 5 Jun 2013 01:00:45 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id D9D5F21F96EF; Wed, 5 Jun 2013 01:00:44 -0700 (PDT) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 05 Jun 2013 10:00:42 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 5 Jun 2013 10:00:42 +0200 From: To: , Date: Wed, 5 Jun 2013 10:01:17 +0200 Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: Ac5hwsZDKNES619CQ0uWKjUnOt06oQ== Message-ID: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_CDD4B04875375ianfarrertelekomde_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 05 Jun 2013 08:33:25 -0700 Cc: ipv6@ietf.org, v6ops@ietf.org, draft-jiang-v6ops-semantic-prefix@tools.ietf.org, owen@delong.com, rdroms.ietf@gmail.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 08:00:50 -0000 --_000_CDD4B04875375ianfarrertelekomde_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If the SP allocates users the equivalent of a /48 divided up as multiple >/= 48s with semantic meaning to each of the assigned prefixes, then the user's= got a /48, and the SP's got their semantic bits. Ian From: Lorenzo Colitti > Date: Wednesday, 5 June 2013 05:42 To: Ted Lemon > Cc: Owen DeLong >, ">" >, "ipv6@ie= tf.org" >, "draft= -jiang-v6ops-semantic-prefix@tools.ietf.org" >, Ralph Droms > Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-= v6ops-semantic-prefix-03 Resent-To: >, Ian Farrer = >, >, > On Wed, Jun 5, 2013 at 12:20 PM, Ted Lemon > wrote: So the point isn't that a /48 is a waste of space. It's that a /48 is ass= umed, and because it is assumed, there are definitely bits available for se= mantic prefix assignment. I still don't understand. What the above sentences seem to be saying is tha= t "there are bits available for semantic prefix assignment because RIRs ass= ume /48 but users don't actually get /48". Is that your point? If so, I don't see how you can also state that there are enough bits to bot= h give every user a /48 and to use semantic prefix bits. --_000_CDD4B04875375ianfarrertelekomde_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
If the SP allocates= users the equivalent of a /48 divided up as multiple >/48s with semanti= c meaning to each of the assigned prefixes, then the user's got a /48, and = the SP's got their semantic bits.

Ian
From: Lorenzo C= olitti <lorenzo@google.com>=
Date: Wednesday, 5 June 2013 0= 5:42
To: Ted Lemon <Ted.Lemon@nominum.com>
Cc: Owen DeLong <owen@delong.com>, "<v6ops@ietf.org>" <v6ops@ietf.= org>, "ipv6@ietf.org" <ipv6@ietf.org>, "draft-jiang-v6ops-semantic-pre= fix@tools.ietf.org" <draft-jiang-v6ops-semantic-prefix@tools.ietf.org&g= t;, Ralph Droms <rdroms.ietf@gm= ail.com>
Subject: Re: [v= 6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-= prefix-03
Resent-To: <boyang.bo@huawei.com>, Ian Farrer = <ian.farrer@telekom.de>,= <jiangsheng@huawei.com>= , <sunqiong@ctbri.com.cn>= ;

On Wed, Jun 5, 2013 at 1= 2:20 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
So the point isn't tha= t a /48 is a waste of space.   It's that a /48 is assumed, and because= it is assumed, there are definitely bits available for semantic prefix ass= ignment.

I sti= ll don't understand. What the above sentences seem to be saying is that "th= ere are bits available for semantic prefix assignment because RIRs assume /= 48 but users don't actually get /48". Is that your point?

If so, I don't see how you can also state t= hat there are enough bits to both give every user a /48 and to use semantic= prefix bits.
--_000_CDD4B04875375ianfarrertelekomde_-- From Ted.Lemon@nominum.com Wed Jun 5 08:42:02 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5BD21F9AFA; Wed, 5 Jun 2013 08:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.535 X-Spam-Level: X-Spam-Status: No, score=-106.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9arcP88e8nAP; Wed, 5 Jun 2013 08:41:47 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id EDCE321F9ADC; Wed, 5 Jun 2013 08:41:46 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUa9cOsNzM7ZU6RzQHofUjjeq7HseiTar@postini.com; Wed, 05 Jun 2013 08:41:47 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 65A9C1B81F3; Wed, 5 Jun 2013 08:41:46 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 56F7919005C; Wed, 5 Jun 2013 08:41:46 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 08:41:46 -0700 From: Ted Lemon To: Sander Steffann Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAFFqgIAAA0MAgAAlngCAAERTAIAAmIuAgAAWAQCAALv5gIAAMI2AgACc9YCAACD6gIAAH1gAgACZeoCAAAjegIAAwruAgAAV84A= Date: Wed, 5 Jun 2013 15:41:45 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C5851@mbx-01.win.nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mb x-01.win.nominum.com> <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> <050AD4E8-31AA-41DD-A137-06A8542D8C21@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C4022@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C4D5F@mbx-01.win.nominum.com> <1507C534-9CA6-4170-AB04-0D41E13D58A7@steffann.nl> In-Reply-To: <1507C534-9CA6-4170-AB04-0D41E13D58A7@steffann.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <164B044F2D8B794497AD250F1B581C05@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 15:42:02 -0000 On Jun 5, 2013, at 10:23 AM, Sander Steffann wrote: > So they playing field is mixed. Some do /56, but the major players do (or= will do) /48. Sure, but you're just confirming my point that if a provider wants to do se= mantic prefixes, they can get enough bits to do them by allocating a /56 to= customers instead of a /48. The point is not to catalog the various choi= ces providers have made, but simply to point out that "bit scarcity" is not= a good argument to use against semantic prefixes. If they are a bad idea= , which they may well be, it is for some other reason. From ales.vizdal@t-mobile.cz Wed Jun 5 08:49:12 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A1C21F99B9; Wed, 5 Jun 2013 08:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNMl2N53vpkT; Wed, 5 Jun 2013 08:49:07 -0700 (PDT) Received: from rztmailhub.t-mobile.cz (rztmailhub.t-mobile.cz [93.153.104.86]) by ietfa.amsl.com (Postfix) with ESMTP id 2771521F9A40; Wed, 5 Jun 2013 08:49:07 -0700 (PDT) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by rztmailhub.t-mobile.cz (Postfix) with ESMTP id 89BE62E06F8; Wed, 5 Jun 2013 17:49:01 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk504.rdm.cz ([::1]) with mapi; Wed, 5 Jun 2013 17:49:05 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Ted Lemon , Sander Steffann Date: Wed, 5 Jun 2013 17:49:03 +0200 Subject: RE: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAFFqgIAAA0MAgAAlngCAAERTAIAAmIuAgAAWAQCAALv5gIAAMI2AgACc9YCAACD6gIAAH1gAgACZeoCAAAjegIAAwruAgAAV84D//4uWkA== Message-ID: <1808340F7EC362469DDFFB112B37E2FCC895E28655@SRVHKE02.rdm.cz> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mb x-01.win.nominum.com> <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> <050AD4E8-31AA-41DD-A137-06A8542D8C21@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C4022@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C4D5F@mbx-01.win.nominum.com> <1507C534-9CA6-4170-AB04-0D41E13D58A7@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5851@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C5851@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 15:49:12 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Ted > Lemon > Sent: Wednesday, June 05, 2013 5:42 PM > To: Sander Steffann > Cc: v6ops@ietf.org WG; = ; > ipv6@ietf.org 6man-wg > Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jian= g-v6ops- > semantic-prefix-03 >=20 > On Jun 5, 2013, at 10:23 AM, Sander Steffann wrote: > > So they playing field is mixed. Some do /56, but the major players do (= or will do) /48. >=20 > Sure, but you're just confirming my point that if a provider wants to do = semantic > prefixes, they can get enough bits to do them by allocating a /56 to cust= omers instead > of a /48. The point is not to catalog the various choices providers hav= e made, but > simply to point out that "bit scarcity" is not a good argument to use aga= inst semantic > prefixes. If they are a bad idea, which they may well be, it is for som= e other reason. It's been mentioned earlier, a provider can allocate multiple /56 prefixes = to a customer,=20 each of them having its own semantics (e.g. service based). From sander@steffann.nl Wed Jun 5 09:04:43 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4661B21F9AED; Wed, 5 Jun 2013 09:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.126 X-Spam-Level: X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[AWL=-1.474, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meAuKusMV-Kp; Wed, 5 Jun 2013 09:04:33 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id DFAE021F8A03; Wed, 5 Jun 2013 09:04:31 -0700 (PDT) Received: from [10.195.70.107] (unknown [188.207.97.57]) by mail.sintact.nl (Postfix) with ESMTP id 8E2432048; Wed, 5 Jun 2013 18:04:21 +0200 (CEST) References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <5D36713D8A4E7348A7E10DF7437A4B923AC992D2@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99354@nkgeml512-mbx.china.huawei.com> <8D23D4052ABE7A4490E77B1A012B6307751BD21E@mbx-01.win.nominum.com> <65746D62-1F0E-4FAD-AC6A-270BD5757C8A@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE2D@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C0209@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C1363@mb x-01.win.nominum.com> <9F6CC60F-1E5A-4A0F-9DF4-C9C3615A60A0@ecs.soton.ac.uk> <8D23D4052ABE7A4490E77B1A012B6307751C1EF5@mbx-01.win.nominum.com> <27103F53-0FE8-447F-B48B-EDC2F13530D3@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C26CB@mbx-01.win.nominum.com> <050AD4E8-31AA-41DD-A137-06A8542D8C21@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C4022@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C4D5F@mbx-01.win.nominum.com> <1507C534-9CA6-4170- AB04-0D41E13D58A7@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5851@mbx-01.win.nominum.com> Mime-Version: 1.0 (1.0) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C5851@mbx-01.win.nominum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> X-Mailer: iPhone Mail (10B329) From: Sander Steffann Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Date: Wed, 5 Jun 2013 18:04:15 +0200 To: Ted Lemon Cc: "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 16:04:43 -0000 Hi Ted, > On Jun 5, 2013, at 10:23 AM, Sander Steffann wrote: >> So they playing field is mixed. Some do /56, but the major players do (or= will do) /48. >=20 > Sure, but you're just confirming my point that if a provider wants to do s= emantic prefixes, they can get enough bits to do them by allocating a /56 to= customers instead of a /48. The point is not to catalog the various choic= es providers have made, but simply to point out that "bit scarcity" is not a= good argument to use against semantic prefixes. If they are a bad idea, w= hich they may well be, it is for some other reason. Keep in mind that RIRs won't give you extra address space though. If you ass= ign /56s to your users then that is what the RIR need-base calculations are b= ased on (according to current policy). Cheers, Sander From Ted.Lemon@nominum.com Wed Jun 5 09:12:07 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9498021F9B81; Wed, 5 Jun 2013 09:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcYqBy+05Y2k; Wed, 5 Jun 2013 09:12:01 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id EBB8D21F9B06; Wed, 5 Jun 2013 09:11:59 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUa9jTzZAW7I8V/9rfKMpWjm6pipkXDFq@postini.com; Wed, 05 Jun 2013 09:12:00 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 663371B81F1; Wed, 5 Jun 2013 09:11:59 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5C6FF19005C; Wed, 5 Jun 2013 09:11:59 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 09:11:59 -0700 From: Ted Lemon To: Sander Steffann Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAFFqgIAAA0MAgAAlngCAAERTAIAAmIuAgAAWAQCAALv5gIAAMI2AgACc9YCAACD6gIAAH1gAgACZeoCAAAjegIAAwruAgAAV84CAAAZKgIAAAigA Date: Wed, 5 Jun 2013 16:11:59 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> In-Reply-To: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 16:12:07 -0000 On Jun 5, 2013, at 12:04 PM, Sander Steffann wrote: > Keep in mind that RIRs won't give you extra address space though. If you = assign /56s to your users then that is what the RIR need-base calculations = are based on (according to current policy). So if the ISP says "we need a /48 per customer," the RIR is going to ask "o= kay, but what are the details of how you will use that /48?" I don't thin= k so. Why are we still talking about this? From albert.e.manfredi@boeing.com Wed Jun 5 12:29:24 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B3921F9B28; Wed, 5 Jun 2013 12:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVZUUxLo4WyP; Wed, 5 Jun 2013 12:29:18 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 62E9D21F9B2A; Wed, 5 Jun 2013 12:29:15 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r55JSrJG021298; Wed, 5 Jun 2013 14:28:53 -0500 Received: from XCH-PHX-205.sw.nos.boeing.com (xch-phx-205.sw.nos.boeing.com [137.136.238.16]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r55JSp4q021243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 5 Jun 2013 14:28:51 -0500 Received: from XCH-PHX-503.sw.nos.boeing.com ([169.254.3.131]) by XCH-PHX-205.sw.nos.boeing.com ([169.254.5.22]) with mapi id 14.02.0328.011; Wed, 5 Jun 2013 12:28:50 -0700 From: "Manfredi, Albert E" To: Ted Lemon Subject: RE: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOYZK8kYO76u5exEaW47moCM2uI5km3+MAgADCuoCAABXzgIAABkqAgAACKYD//8CV0A== Date: Wed, 5 Jun 2013 19:28:50 +0000 Message-ID: <021E64FECA7E5A4699562F4E6671648103DE44@XCH-PHX-503.sw.nos.boeing.com> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 19:29:24 -0000 Why not? Actually, I was about to make that suggestion myself. We can stop this infi= nite thread by simply saying, do whatever semantic tricks you want with the= address blocks allocated to you, but know that you won't get any more just= so you can play those semantic tricks. What's wrong with that as a policy? It's bad enough that the 128-bit address space has already be wasted to whe= re it's barely a 64-bit space. Now we're potentially being even more aggres= sively wasteful, but chucking away a good portion of the 48 or 56-bit prefi= xes. Bert > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of T= ed > Lemon > Sent: Wednesday, June 05, 2013 12:12 PM > To: Sander Steffann > Cc: v6ops@ietf.org WG; = ; > ipv6@ietf.org 6man-wg > Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jian= g- > v6ops-semantic-prefix-03 >=20 > On Jun 5, 2013, at 12:04 PM, Sander Steffann wrote: > > Keep in mind that RIRs won't give you extra address space though. If yo= u > assign /56s to your users then that is what the RIR need-base calculation= s > are based on (according to current policy). >=20 > So if the ISP says "we need a /48 per customer," the RIR is going to ask > "okay, but what are the details of how you will use that /48?" I don't > think so. Why are we still talking about this? >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From Ted.Lemon@nominum.com Wed Jun 5 13:15:01 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B954F21F9B8B; Wed, 5 Jun 2013 13:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.542 X-Spam-Level: X-Spam-Status: No, score=-106.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYwJnffew0F6; Wed, 5 Jun 2013 13:14:04 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC4021F9B64; Wed, 5 Jun 2013 13:14:01 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUa+cCIHYCIQ4LgZCQvHfONKiLp02ZV5j@postini.com; Wed, 05 Jun 2013 13:14:01 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AF20C1B81E1; Wed, 5 Jun 2013 13:14:00 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9A49E19005C; Wed, 5 Jun 2013 13:14:00 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 13:14:00 -0700 From: Ted Lemon To: "Manfredi, Albert E" Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOYiLrbD9i6MQQoUKual+GsbFSRpkoA4CA Date: Wed, 5 Jun 2013 20:13:59 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C62A3@mbx-01.win.nominum.com> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <021E64FECA7E5A4699562F4E6671648103DE44@XCH-PHX-503.sw.nos.boeing.com> In-Reply-To: <021E64FECA7E5A4699562F4E6671648103DE44@XCH-PHX-503.sw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 20:15:01 -0000 On Jun 5, 2013, at 3:28 PM, "Manfredi, Albert E" wrote: > Actually, I was about to make that suggestion myself. We can stop this in= finite thread by simply saying, do whatever semantic tricks you want with t= he address blocks allocated to you, but know that you won't get any more ju= st so you can play those semantic tricks. > What's wrong with that as a policy? The IETF doesn't set the policy. I have no objection to that policy, but = it ain't up to us. From owen@delong.com Wed Jun 5 15:23:43 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5A521F8A0B; Wed, 5 Jun 2013 15:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnnvWMug-Ptn; Wed, 5 Jun 2013 15:23:42 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFB621F91CA; Wed, 5 Jun 2013 15:23:05 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r55MJWEB004612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 5 Jun 2013 15:20:24 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r55MJWEB004612 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370470826; bh=r2cqceQEB0bdetyFI9KXJDdhcVU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=39aZrJcvyC4ORIb6y5WbRNzV34oKkpvlxJsnYe2CmFdjDFCa7dcDkwAXxyBlK0Sad pznAgsPtSdbMRQjxRgYbPLUF2dNUR11SX+O/3QaAISR77XHwAgDlIVFdpXDYVznJ5I RE1Jg1218ex8DApiDoC9VatMsleOIvnNMRGhLTFQ= Content-Type: multipart/alternative; boundary="Apple-Mail=_4EE136EA-D79F-4268-B148-80AA5AC35AD0" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Owen DeLong In-Reply-To: Date: Wed, 5 Jun 2013 15:20:24 -0700 Message-Id: <9E8838EC-78B8-427E-9822-81D26AD17AB4@delong.com> References: To: ian.farrer@telekom.de X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 05 Jun 2013 15:20:26 -0700 (PDT) Cc: v6ops@ietf.org, draft-jiang-v6ops-semantic-prefix@tools.ietf.org, ipv6@ietf.org, rdroms.ietf@gmail.com, lorenzo@google.com, Ted.Lemon@nominum.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 22:23:44 -0000 --Apple-Mail=_4EE136EA-D79F-4268-B148-80AA5AC35AD0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Unless the SP's semantic meaning of those bits otherwise restricts how = the user can use different chunks of that /48. Owen On Jun 5, 2013, at 01:01 , ian.farrer@telekom.de wrote: > If the SP allocates users the equivalent of a /48 divided up as = multiple >/48s with semantic meaning to each of the assigned prefixes, = then the user's got a /48, and the SP's got their semantic bits. >=20 > Ian >=20 > From: Lorenzo Colitti > Date: Wednesday, 5 June 2013 05:42 > To: Ted Lemon > Cc: Owen DeLong , "" = , "ipv6@ietf.org" , = "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" = , Ralph Droms = > Subject: Re: [v6ops] Could IPv6 address be more than = locator?//draft-jiang-v6ops-semantic-prefix-03 > Resent-To: , Ian Farrer , = , >=20 > On Wed, Jun 5, 2013 at 12:20 PM, Ted Lemon = wrote: >> So the point isn't that a /48 is a waste of space. It's that a /48 = is assumed, and because it is assumed, there are definitely bits = available for semantic prefix assignment. >=20 > I still don't understand. What the above sentences seem to be saying = is that "there are bits available for semantic prefix assignment because = RIRs assume /48 but users don't actually get /48". Is that your point? >=20 > If so, I don't see how you can also state that there are enough bits = to both give every user a /48 and to use semantic prefix bits. --Apple-Mail=_4EE136EA-D79F-4268-B148-80AA5AC35AD0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii ian.farrer@telekom.de= wrote:

If the SP allocates users = the equivalent of a /48 divided up as multiple >/48s with semantic = meaning to each of the assigned prefixes, then the user's got a /48, and = the SP's got their semantic = bits.

Ian

From: = Lorenzo Colitti <lorenzo@google.com>
Date: Wednesday, 5 June 2013 = 05:42
To: Ted Lemon <Ted.Lemon@nominum.com>
Cc: Owen DeLong <owen@delong.com>, "<v6ops@ietf.org>" <v6ops@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, "draft-jia= ng-v6ops-semantic-prefix@tools.ietf.org" <draft-jia= ng-v6ops-semantic-prefix@tools.ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
Subject: Re: [v6ops] Could IPv6 = address be more than = locator?//draft-jiang-v6ops-semantic-prefix-03
Resent-To: <boyang.bo@huawei.com>, Ian = Farrer <ian.farrer@telekom.de>, = <jiangsheng@huawei.com>, = <sunqiong@ctbri.com.cn>

On Wed, Jun = 5, 2013 at 12:20 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
So the point isn't that a /48 is a waste = of space.   It's that a /48 is assumed, and because it is assumed, = there are definitely bits available for semantic prefix = assignment.

I still = don't understand. What the above sentences seem to be saying is that = "there are bits available for semantic prefix assignment because RIRs = assume /48 but users don't actually get /48". Is that your = point?

If so, I don't see = how you can also state that there are enough bits to both give every = user a /48 and to use semantic prefix = bits.

= --Apple-Mail=_4EE136EA-D79F-4268-B148-80AA5AC35AD0-- From owen@delong.com Wed Jun 5 15:29:16 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72E021E8050; Wed, 5 Jun 2013 15:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9T5PaeLsiO0Z; Wed, 5 Jun 2013 15:29:15 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id DBC5521E8086; Wed, 5 Jun 2013 15:28:40 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r55MRd1b004770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 5 Jun 2013 15:27:40 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r55MRd1b004770 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370471260; bh=K0nx8mHy9BOur46hCYR9FjF+aN0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=z1B2QPZuaw3XOrAUx+ij8ryvb4eYYmzRSWWrokpHxR8gKEnvMLGXG0ccqwJLYZ9qq gHbxqG1T/SK5eYAbMpssFemJz3KH4ITLFPJy0xndcnceBZTbVciVqcljKuwNW9jeKy D1G6L62oXOH8Ju8Gnco1oYYyL2VQnULc1TNbIp7o= Content-Type: multipart/alternative; boundary="Apple-Mail=_0BBE9E40-1771-442F-82C5-AFB2F1B0DC2D" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Owen DeLong In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> Date: Wed, 5 Jun 2013 15:27:39 -0700 Message-Id: References: <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 05 Jun 2013 15:27:40 -0700 (PDT) Cc: "ipv6@ietf.org 6man-wg" , "v6ops@ietf.org WG" , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 22:29:16 -0000 --Apple-Mail=_0BBE9E40-1771-442F-82C5-AFB2F1B0DC2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 5, 2013, at 09:11 , Ted Lemon wrote: > On Jun 5, 2013, at 12:04 PM, Sander Steffann = wrote: >> Keep in mind that RIRs won't give you extra address space though. If = you assign /56s to your users then that is what the RIR need-base = calculations are based on (according to current policy). >=20 > So if the ISP says "we need a /48 per customer," the RIR is going to = ask "okay, but what are the details of how you will use that /48?" I = don't think so. Why are we still talking about this? >=20 =46rom ARIN policy: 6.5.2. Initial allocation to LIRs 6.5.2.1. Size All allocations shall be made on nibble boundaries. In no case shall an LIR receive smaller than a /32 unless they = specifically request a /36. In no case shall an ISP receive more than a = /16 initial allocation. The maximum allowable allocation shall be the smallest nibble-boundary = aligned block that can provide an equally sized nibble-boundary aligned = block to each of the requesters serving sites large enough to satisfy = the needs of the requesters largest single serving site using no more = than 75% of the available addresses.=20 This calculation can be summarized as /N where N =3D P-(X+Y) and P is = the organization's Provider Allocation Unit X is a multiple of 4 greater = than 4/3*serving sites and Y is a multiple of 4 greater than 4/3*end = sites served by largest serving site. For purposes of the calculation in (c), an end site which can justify = more than a /48 under the end-user assignment criteria in 6.5.8 shall = count as the appropriate number of /48s that would be assigned under = that policy. For purposes of the calculation in (c), an LIR which has subordinate = LIRs shall make such allocations according to the same policies and = criteria as ARIN. In such a case, the prefixes necessary for such an = allocation should be treated as fully utilized in determining the block = sizing for the parent LIR. LIRs which do not receive resources directly = from ARIN will not be able to make such allocations to subordinate LIRs = and subordinate LIRs which need more than a /32 shall apply directly to = ARIN. An LIR is not required to design or deploy their network according to = this structure. It is strictly a mechanism to determine the largest IP = address block to which the LIR is entitled. Note that this entire calculation is based on "Provider Assignment = Units". These are defined as: 2.15. Provider Assignment Unit (IPv6) When applied to IPv6 policies, the term "provider assignment unit" shall = mean the prefix of the smallest block a given ISP assigns to end sites = (recommended /48). So, if you are giving out multiple /56s to your customers with different = semantics and not a /48 to each customer, then, your PAU would be /56 = and not /48. Also note that if you give residential customers /56s, you will need to = be able to justify /48s for businesses in terms of the number of /56s = they need at each end site in order to qualify for an additional = allocation. At least this is how ARIN policy is currently structured. YMMV in other RIRs. Owen --Apple-Mail=_0BBE9E40-1771-442F-82C5-AFB2F1B0DC2D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Ted.Lemon@nominum.com> = wrote:
On Jun 5, 2013, at 12:04 PM, Sander Steffann <sander@steffann.nl> = wrote:
Keep in mind that RIRs won't give = you extra address space though. If you assign /56s to your users then = that is what the RIR need-base calculations are based on (according to = current policy).

So if the ISP says "we need a /48 = per customer," the RIR is going to ask "okay, but what are the details = of how you will use that /48?"   I don't think so. =   Why are we still talking about = this?


=46rom ARIN = policy:

6.5.2. Initial allocation to LIRs
  • All allocations = shall be made on nibble boundaries.
  • In no case shall = an LIR receive smaller than a /32 unless they specifically request a = /36. In no case shall an ISP receive more than a /16 initial = allocation.
  • The maximum allowable allocation = shall be the smallest nibble-boundary aligned block that can provide an = equally sized nibble-boundary aligned block to each of the requesters = serving sites large enough to satisfy the needs of the requesters = largest single serving site using no more than 75% of the available = addresses. 

    This calculation can be summarized as /N = where N =3D P-(X+Y) and P is the organization's Provider Allocation Unit = X is a multiple of 4 greater than 4/3*serving sites and Y is a multiple = of 4 greater than 4/3*end sites served by largest serving site.
  • For purposes of the calculation in (c), an end site which can = justify more than a /48 under the end-user assignment criteria in 6.5.8 = shall count as the appropriate number of /48s that would be assigned = under that policy.
  • For purposes of the calculation in = (c), an LIR which has subordinate LIRs shall make such allocations = according to the same policies and criteria as ARIN. In such a case, the = prefixes necessary for such an allocation should be treated as fully = utilized in determining the block sizing for the parent LIR. LIRs which = do not receive resources directly from ARIN will not be able to make = such allocations to subordinate LIRs and subordinate LIRs which need = more than a /32 shall apply directly to ARIN.
  • An LIR is not = required to design or deploy their network according to this structure. = It is strictly a mechanism to determine the largest IP address block to = which the LIR is entitled.

    • Note that this = entire calculation is based on "Provider Assignment Units". These are = defined as:

    2.15. Provider Assignment Unit (IPv6)

    When applied to IPv6 policies, the term = "provider assignment unit" shall mean the prefix of the smallest block a = given ISP assigns to end sites (recommended = /48).


    So, if you are giving out = multiple /56s to your customers with different semantics and not a /48 = to each customer, then, your PAU would be /56 and not = /48.

    Also note that if you give residential = customers /56s, you will need to be able to justify /48s for businesses = in terms of the number of /56s they need at each end site in order to = qualify for an additional allocation. At least this is how ARIN policy = is currently structured.

    YMMV in other = RIRs.

    Owen

    = --Apple-Mail=_0BBE9E40-1771-442F-82C5-AFB2F1B0DC2D-- From owen@delong.com Wed Jun 5 20:07:54 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1845A21F95EF; Wed, 5 Jun 2013 20:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQVtPA6BNohS; Wed, 5 Jun 2013 20:07:53 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 53E5F21F9630; Wed, 5 Jun 2013 20:07:52 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r5634V6W011422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 5 Jun 2013 20:04:31 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r5634V6W011422 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370487873; bh=rpfmWt+pf7o/0hDxyN/mcq9usgI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=YjIAIX3PxgZmDQccGx4H0sUCflJ5Ppa9zPU1UBrJMGNRoQMbIZNmSUxeyASeEjTSm BfVxFiPFPUvGWABV2DTYG8yLhhETkkwhNXfQl3ExmqezlLYGVTgpRJG+FrV4dmuXRl zRv8rlAnFVgPyn2EtAAfpqsE1KxQQ6v2/AWznTfw= Content-Type: multipart/alternative; boundary="Apple-Mail=_56276CB2-3311-4306-B8DB-6F209AF49BA8" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Owen DeLong In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C65F1@mbx-01.win.nominum.com> Date: Wed, 5 Jun 2013 20:04:31 -0700 Message-Id: References: <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C65F1@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 05 Jun 2013 20:04:33 -0700 (PDT) Cc: "ipv6@ietf.org 6man-wg" , "v6ops@ietf.org WG" , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 03:07:54 -0000 --Apple-Mail=_56276CB2-3311-4306-B8DB-6F209AF49BA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 5, 2013, at 15:55 , Ted Lemon wrote: > On Jun 5, 2013, at 6:27 PM, Owen DeLong wrote: >> Also note that if you give residential customers /56s, you will need = to be able to justify /48s for businesses in terms of the number of /56s = they need at each end site in order to qualify for an additional = allocation. At least this is how ARIN policy is currently structured. >=20 > I would feel pretty comfortable saying that I want a /48 to assign to = each customer, and then using some of the bits from each /48 for = semantic prefixes, because I'm using them to support the customer. I = don't see anything in the policy you've quoted that forbids this. I do = not think that I would have to make any inaccurate representations to = the RIR. Why are we still talking about this, Owen? You could probably get away with that. However, I would expect the first = customer that runs afoul of your semantics because they want more pieces = of their /48 under a different semantic control than you allow will = likely file a fraud report with ARIN, as you are not truly delegating = the /48 to the control of said end-site, but, instead exercising your = own control over the delegation of smaller chunks of it. We are still talking about it because you continue to try and defraud = the intent of the existing policy and claim that it is permitted. Owen --Apple-Mail=_56276CB2-3311-4306-B8DB-6F209AF49BA8 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
    On Jun 5, 2013, at 15:55 , Ted Lemon <Ted.Lemon@nominum.com> wrote:

    On Jun 5, 2013, at 6:27 PM, Owen DeLong <owen@delong.com> wrote:
    Also note that if you give residential customers /56s, you will need to be able to justify /48s for businesses in terms of the number of /56s they need at each end site in order to qualify for an additional allocation. At least this is how ARIN policy is currently structured.

    I would feel pretty comfortable saying that I want a /48 to assign to each customer, and then using some of the bits from each /48 for semantic prefixes, because I'm using them to support the customer.   I don't see anything in the policy you've quoted that forbids this.   I do not think that I would have to make any inaccurate representations to the RIR.   Why are we still talking about this, Owen?

    You could probably get away with that. However, I would expect the first customer that runs afoul of your semantics because they want more pieces of their /48 under a different semantic control than you allow will likely file a fraud report with ARIN, as you are not truly delegating the /48 to the control of said end-site, but, instead exercising your own control over the delegation of smaller chunks of it.

    We are still talking about it because you continue to try and defraud the intent of the existing policy and claim that it is permitted.

    Owen


    --Apple-Mail=_56276CB2-3311-4306-B8DB-6F209AF49BA8-- From Ted.Lemon@nominum.com Wed Jun 5 15:55:24 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD2A21F88AC; Wed, 5 Jun 2013 15:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.543 X-Spam-Level: X-Spam-Status: No, score=-106.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcZGgKsQ930k; Wed, 5 Jun 2013 15:55:18 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id F3FC921F86D3; Wed, 5 Jun 2013 15:55:17 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUa/B1eUkWAa7R3G5D+kSCnRPkwfI8W1u@postini.com; Wed, 05 Jun 2013 15:55:18 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 221F81B81E1; Wed, 5 Jun 2013 15:55:17 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1433119005C; Wed, 5 Jun 2013 15:55:17 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 15:55:17 -0700 From: Ted Lemon To: Owen DeLong Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAFFqgIAAA0MAgAAlngCAAERTAIAAmIuAgAAWAQCAALv5gIAAMI2AgACc9YCAACD6gIAAH1gAgACZeoCAAAjegIAAwruAgAAV84CAAAZKgIAAAigAgABo94CAAAe1AA== Date: Wed, 5 Jun 2013 22:55:16 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C65F1@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C65F1mbx01winnominum_" MIME-Version: 1.0 Cc: "ipv6@ietf.org 6man-wg" , "v6ops@ietf.org WG" , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 22:55:24 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C65F1mbx01winnominum_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jun 5, 2013, at 6:27 PM, Owen DeLong > wrote: Also note that if you give residential customers /56s, you will need to be = able to justify /48s for businesses in terms of the number of /56s they nee= d at each end site in order to qualify for an additional allocation. At lea= st this is how ARIN policy is currently structured. I would feel pretty comfortable saying that I want a /48 to assign to each = customer, and then using some of the bits from each /48 for semantic prefix= es, because I'm using them to support the customer. I don't see anything = in the policy you've quoted that forbids this. I do not think that I woul= d have to make any inaccurate representations to the RIR. Why are we stil= l talking about this, Owen? --_000_8D23D4052ABE7A4490E77B1A012B6307751C65F1mbx01winnominum_ Content-Type: text/html; charset="us-ascii" Content-ID: <299A80E475ADFA46929A520B62D38A92@nominum.com> Content-Transfer-Encoding: quoted-printable
    On Jun 5, 2013, at 6:27 PM, Owen DeLong <owen@delong.com> wrote:
    Also note that if you give residential customers /56s, you will need to be able= to justify /48s for businesses in terms of the number of /56s they need at= each end site in order to qualify for an additional allocation. At least t= his is how ARIN policy is currently structured.

    I would feel pretty comfortable saying that I want a /48 to assign to = each customer, and then using some of the bits from each /48 for semantic p= refixes, because I'm using them to support the customer.   I don't see= anything in the policy you've quoted that forbids this.   I do not think that I would have to make any ina= ccurate representations to the RIR.   Why are we still talking about t= his, Owen?

    --_000_8D23D4052ABE7A4490E77B1A012B6307751C65F1mbx01winnominum_-- From brian.e.carpenter@gmail.com Wed Jun 5 16:09:18 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E16321E8086 for ; Wed, 5 Jun 2013 16:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSlyj8RVSHV1 for ; Wed, 5 Jun 2013 16:09:14 -0700 (PDT) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id F0BD421F990D for ; Wed, 5 Jun 2013 16:09:13 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id bv13so2508101pdb.12 for ; Wed, 05 Jun 2013 16:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=cZRSfFu3ciN/tZ1cDsOQ0Lo8fyYbIHy4HRoaA7lsgHw=; b=TgQm3BkWTFHRa+2flrvldTNYh5c6i7ebgNkNJawAP0G/qHcPWVDQC/sEATMCFPj5y7 P+J6PcU/sQC9UjZ5J3J/qX1YKqCdKNOs36aPWblI6/1N9tueipq2MYIVSSwAK154doDA qHh8dMba5w0K71Nfa0OtxS5lZmwFSVFZTQwCmvZHt6BmTwNbzT2x8JJZFYUN6K0x5/q1 GFbMn2neZ/tDyh/FB8cwXckX7Jrf/2UIaQ4stL3D1OPsEWjnu1j6VUp3FO5ojwdqZUNj 2LMY7pdGQcBBEHP1NTkQ23uvMq4ZAV111uMB21kFqhDuqBW8r69dmImZ/ESQbzZTRRSl iWfg== X-Received: by 10.68.129.10 with SMTP id ns10mr35840274pbb.13.1370473745118; Wed, 05 Jun 2013 16:09:05 -0700 (PDT) Received: from [192.168.1.2] (1.199.252.27.dyn.cust.vf.net.nz. [27.252.199.1]) by mx.google.com with ESMTPSA id tb7sm69902285pbc.14.2013.06.05.16.09.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 16:09:04 -0700 (PDT) Message-ID: <51AFC515.8010704@gmail.com> Date: Thu, 06 Jun 2013 11:09:09 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: draft-ietf-6man-ext-transmit-01 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 23:09:18 -0000 If you're following the current discussion on v6ops, it seems that we need to decide whether to proceed with the subject draft, so that there is at least a marker for what forwarding nodes are supposed to do about extension headers. So, are there any more comments on the draft? Brian > Hi, > > This version is intended to respond to Ray Hunter's comments. > There are two important changes: > > 1. The MUST NOT that Ray mentioned is now SHOULD NOT. Really > this is a matter of internal consistency in the document, since > the exceptions to the SHOULD NOT are specified, so the MUST NOT > was inappropriate. > > 2. It is now made explicit that only standards-track extension > headers are covered. That knocks out HIP, which is Experimental. > > There are a few other changes of editorial nature. > > Brian + Sheng > > -------- Original Message -------- > Subject: I-D Action: draft-ietf-6man-ext-transmit-01.txt > Date: Wed, 29 May 2013 13:21:08 -0700 > From: internet-drafts at ietf.org > To: i-d-announce at ietf.org > CC: ipv6 at ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Maintenance Working Group of the IETF. > > Title : Transmission of IPv6 Extension Headers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-ietf-6man-ext-transmit-01.txt > Pages : 9 > Date : 2013-05-29 > > Abstract: > Various IPv6 extension headers have been standardised since the IPv6 > standard was first published. This document updates RFC 2460 to > clarify how intermediate nodes should deal with such extension > headers and with any that are defined in future. It also specifies > how extension headers should be registered by IANA, with a > corresponding minor update to RFC 2780. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-ext-transmit > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6man-ext-transmit-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ext-transmit-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From fgont@si6networks.com Wed Jun 5 18:52:03 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5431B21F87B7 for ; Wed, 5 Jun 2013 18:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nBh126DH9sy for ; Wed, 5 Jun 2013 18:52:02 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 8F70521F8749 for <6man@ietf.org>; Wed, 5 Jun 2013 18:51:59 -0700 (PDT) Received: from [186.134.49.61] (helo=[192.168.0.6]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UkPMT-0007Xk-L1; Thu, 06 Jun 2013 03:51:34 +0200 Message-ID: <51AFE3AF.1050300@si6networks.com> Date: Thu, 06 Jun 2013 03:19:43 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Alissa Cooper Subject: Re: Comments on draft-ietf-6man-stable-privacy-addresses-07 References: <72fb5db097d443eebb554cdc43d7a01f@BY2PR03MB269.namprd03.prod.outlook.com> <519AD0EF.60600@si6networks.com> <87b8552e4b4a479dbfca94bd88a09ce7@BY2PR03MB269.namprd03.prod.outlook.com> <519F3364.80301@si6networks.com> <51A207B0.4000900@si6networks.com> <51A93EEE.7080902@gont.com.ar> <6AD05DBB-1067-4F4D-996C-CAB7FEF0184F@cdt.org> In-Reply-To: <6AD05DBB-1067-4F4D-996C-CAB7FEF0184F@cdt.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Brian Haberman , "6man@ietf.org" <6man@ietf.org>, Dave Thaler , Ray Hunter , Fernando Gont , "tom.petch" , Christian Huitema , He Xuan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 01:52:03 -0000 On 06/06/2013 12:24 AM, Alissa Cooper wrote: > I'll try to re-state one of my questions more simply, based on the > -09: > > How is the attack explained in C.4 mitigated by the mechanism > specified in draft-ietf-6man-stable-privacy-addresses-09? It doesn't. For instance, Section B.1 explicitly says so (and this type of attack is not meant to be solved by stable-privacy-addresses). In some scenarios, it can be mitigated with RFC 4941. Hoawever, as noted in Section C.4, even ith RFC4941 there are scenarios n which yu cannot do much about it. >>> Which correlation attack vectors do random-per-network addresses >>> mitigate that temporary addresses do not? >> >> See appendix B of drat-ietf-6man-stable-privacy-addresses. > > I see the above-quoted text has been updated to the following: > > In scenarios in which "temporary addresses" are employed, > implementation of the mechanism described in this document (in > replacement of stable addresses based on e.g. IEEE identifiers) > would mitigate address- scanning attacks and also mitigate the > remaining vectors for correlating host activities based on the node's > IPv6 addresses. > > What "the remaining vectors for correlating host activities based on > the node's IPv6 addresses" actually means is "the remaining vectors > for correlating host activities across networks based on the node's > stable IPv6 address," correct? Yes. If you think it'd be better to phrase it that way, I can update the text accordingly. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From lorenzo@google.com Wed Jun 5 20:26:28 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C997621F911B for ; Wed, 5 Jun 2013 20:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jg4MCY6evZt4 for ; Wed, 5 Jun 2013 20:26:23 -0700 (PDT) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8836621F90F4 for ; Wed, 5 Jun 2013 20:26:23 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id ne12so1613751qeb.27 for ; Wed, 05 Jun 2013 20:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JIk5pX80/RASLt/opLKEnoaKHgeVW8xACamRQPqM28U=; b=KAQBg18C1jbchaR3pGzIIa1kCpGTh+fUp+2VqWz/4+4soUYU3OVJvqhUejvLV68FKL 3hJc2aTFMAthWmVCnU6m1A1ydJo/SCoo40Ntqant0ER/IHyY5CIavaTqe+dGaGwsZMYQ edMwK+oHG+MBwjr1A19jIzojqALapVYDJAwzjNHGkz0+Dz9QYzLK5uBNdAxwTkixbY1x eiDGE+7RBtJ948hxAiWrogwW0sILHzhop6tkd6KTLT1sGqiogRpTuJzC7Dpta1JQaTJs n+xZlgO3e0/+wasHT8Ws3z1/7Ql9u/Hno/61/4+FaNpNpZXFp6TNtujKMsY9HvDwSjy4 liqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=JIk5pX80/RASLt/opLKEnoaKHgeVW8xACamRQPqM28U=; b=EGBG4NlEnruXo8SSJuWXM5ZICoEIBmdpAboJg/Cvf+2nJx3CjlyID7Iy6HFuRDouF3 IWaSJm0xwP9rve2i/eg3ZBjgiqnOwCHJ6B/tUGnZJWholIVR08DyEk/t68DMnYZKTnnV RZDWzOCazq0SPBQ/WIwpB0GUdNvxDL/47AzkaTKm0ONFFT2xqzOFjTYSB3hvCi/V1oW3 +afPbXkTSsFDF0AEXiz6KzMy+qPl24dZ47n7LQmIMgFkwzheWuBbzwI/EqVYjIwAdnt6 cxIL0Ozjom1+io9qZ9PDCohLQCiRvWd132qyt1epYS7cHlsI+mvampiMRo8nocs5kfTv 6AbQ== X-Received: by 10.224.208.68 with SMTP id gb4mr31437030qab.25.1370489182913; Wed, 05 Jun 2013 20:26:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.158.8 with HTTP; Wed, 5 Jun 2013 20:26:00 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C554C@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B6307751C4E3E@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C4F11@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C554C@mbx-01.win.nominum.com> From: Lorenzo Colitti Date: Thu, 6 Jun 2013 12:26:00 +0900 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf300fafb5eaa4e004de73e0d4 X-Gm-Message-State: ALoCoQnhq6/FJHnnXonIJV6eaSoAMsk+IlWkdma61X4r1VAkwqtR2bwJ+NWShExD//Pym1df8TfaSLqOdjG0cX3kG7CzyRyp4c4OfjkxbiTbqKzl6t/2YJ9DCdLN1+jwKVb3lgq5mHL1kG/Z0IDvOEK1p8f6wET1K6LiAXbDe6nZLs6PR0GxAE+qhtiXX0TPmTK/RIAWj7b2 Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 03:26:28 -0000 --20cf300fafb5eaa4e004de73e0d4 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 5, 2013 at 11:54 PM, Ted Lemon wrote: > I still don't understand. What the above sentences seem to be saying is > that "there are bits available for semantic prefix assignment because RIRs > assume /48 but users don't actually get /48". Is that your point? > > > No. There are bits available because (1) RIRs may well allocate them even > to ISPs that assign /48s to end-users > Actually, assigning more than a /48 user is substantially harder. Just to take the APNIC policy, for example: === 5.5 Assignment by LIRs LIRs must make IPv6 assignments in accordance with the following provisions. 5.5.1 Assignment address space size The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (when only one subnet is anticipated for the end site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified." 5.5.2 Assignment of multiple /48s to a single end site When a single end site requires an additional /48 address block, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional /48s will be processed and reviewed (i.e., evaluation of justification) at the RIR/NIR level." === Thus, using semantic prefixes makes it much harder to assign /48s to users - indeed, the letter of the policy above suggests that a /48 is acceptable only in the case of "extra large end sites", and that *every single* user that needs more than a /48 needs to be separately justified. That's obviously not going to fly for a mass-market ISP. So basically, unless you want to go through reams of paperwork, you can either assign a /48 to each user, or you can use semantic prefixes, but not both. --20cf300fafb5eaa4e004de73e0d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Wed, Jun 5, 2013 at 11:54 PM, Ted Lemon <Ted.Lemon= @nominum.com> wrote:
    I still don't understand. What the above sentences seem to be saying is = that "there are bits available for semantic prefix assignment because = RIRs assume /48 but users don't actually get /48". Is that your po= int?

    No. =A0There are bits available because (1) RIRs may well alloca= te them even to ISPs that assign /48s to end-users
    =

    Actually, assigning more than a /48 user is subst= antially harder. Just to take the APNIC policy, for example:

    =3D=3D=3D

    5.5 Assignment by LIRs

    LIRs must mak= e IPv6 assignments in accordance with the following provisions.
    <= br>
    5.5.1 Assignment address space size
    =

    The exact size of the assignment is a= local decision for the LIR or ISP to make, using a minimum value of a /64 = (when only one subnet is anticipated for the end site) up to the normal max= imum of /48, except in cases of extra large end sites where a larger assign= ment can be justified."

    5.5.2 Assignment of multiple /48s to a= single end site

    When a single end sit= e requires an additional /48 address block, it must request the assignment = with documentation or materials that justify the request. Requests for mult= iple or additional /48s will be processed and reviewed (i.e., evaluation of= justification) at the RIR/NIR level."

    =3D=3D=3D

    <= div style>Thus, using semantic prefixes makes it much harder to assign /48s= to users - indeed, the letter of the policy above suggests that a /48 is a= cceptable only in the case of "extra large end sites", and that *= every single* user that needs more than a /48 needs to be separately justif= ied. That's obviously not going to fly for a mass-market ISP.

    So basically, unless you want to go through= reams of paperwork, you can either assign a /48 to each user, or you can u= se semantic prefixes, but not both.
    --20cf300fafb5eaa4e004de73e0d4-- From lorenzo@google.com Wed Jun 5 20:30:56 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68A921F9420 for ; Wed, 5 Jun 2013 20:30:56 -0700 (PDT) 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=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLTcNVtrsTxK for ; Wed, 5 Jun 2013 20:30:56 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id BD2F421F941F for ; Wed, 5 Jun 2013 20:30:55 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id n1so1397255qcw.13 for ; Wed, 05 Jun 2013 20:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8fscdUt803/nVf749nKOb9v0m/ssIij/xhrsSBI4+5E=; b=Dtzk8aXTO2kryGnAoS9X9H4QDvfFXJE5+8Yx/+DVIa0qZaU9wXTdvBGWcLjR2CydwV 2+m9XIWFNn2NAZKx1l41MmagU0j+j+meY8JC+0cvsXdRRMSlV0mlhu6bJsFES9Xud9G9 FI3R85etYKGsvVWDGqEb83Fx8Webdp0jwbgJJrUPdnm66pOCOWuOU9FC+Dmb6+FJOZJB UeVD6GoFbL6V0TaNBbjLaZLvnubqC2nUKC09fcPwalop25xd1cjWov/tyu8mgFEhV5Hk B05XfP+4ZluTFNQMjnfguO0mjjALz8hZM+m7/F2NBIaaJrbXxB6dcsUxnpZ5UhimVc/L inVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=8fscdUt803/nVf749nKOb9v0m/ssIij/xhrsSBI4+5E=; b=ory+O8xiBOm96AcE0//atUmEkpgJ405loFn+GRgR0QENFbEqPy0CzdGWEhjkRTgd0k ceRuhF/sR3GRB+DS2JOE0u2MBWDNofIBCxF6Cngw1URyMtNnyokmFROkiD0nOZ83jEGu trl5DNGPVuv7q6mAn3Q1os/lWgP7peVyfWeyQGhHonbh9rODCgAm0+aKTxaivZR2S73Z eRsoV0Mlg5WqD49Lm4b8tK9gqe0tZPI1bxmcIsndoqx9rpwDVgOcVcCR+DtvWTxceDJd GA4yhx6kdAplzu9t1tRKc+9zdp2a/2P1r5hQZI9LqfTO3Q3JwCgGBZKvRYs/jkJkopX4 mVXQ== X-Received: by 10.49.63.196 with SMTP id i4mr29627472qes.13.1370489455157; Wed, 05 Jun 2013 20:30:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.158.8 with HTTP; Wed, 5 Jun 2013 20:30:34 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> From: Lorenzo Colitti Date: Thu, 6 Jun 2013 12:30:34 +0900 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7bd75c5e24c65904de73f138 X-Gm-Message-State: ALoCoQmE9j9hI4lOj88LZRdPc2MCwc6/Z0Jo8HoMAOZrAbm8TEgU58+Bj2bk7AuvDbSag9qh1MFXsR2zkXe9eUtI+j7N/dcH3AynggOB3g9kjfaLaXJYCuorOs6EvrkdOG87Qvo4Q+XddFfTGl7g0goVrm9OoJXW78yGcV++b40/2oNrl1ahGbOCKm0gF+P8frBcRFqEStu4 Cc: "ipv6@ietf.org 6man-wg" , "v6ops@ietf.org WG" , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 03:30:56 -0000 --047d7bd75c5e24c65904de73f138 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 1:11 AM, Ted Lemon wrote: > On Jun 5, 2013, at 12:04 PM, Sander Steffann wrote: > > Keep in mind that RIRs won't give you extra address space though. If you > assign /56s to your users then that is what the RIR need-base calculations > are based on (according to current policy). > > So if the ISP says "we need a /48 per customer," the RIR is going to ask > "okay, but what are the details of how you will use that /48?" I don't > think so. Why are we still talking about this? Personally, I'm waiting for us to agree that due to current RIR policies, if an ISP chooses to use semantic prefixes, then it will not be able to give users as much space as it would be able to give them if it chose not to use semantic prefixes. --047d7bd75c5e24c65904de73f138 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Thu, Jun 6, 2013 at 1:11 AM, Ted Lemon <Ted.Lemon@= nominum.com> wrote:
    On Jun 5, 2013, at 12:04 P= M, Sander Steffann <sander@steffan= n.nl> wrote:
    > Keep in mind that RIRs won't give you extra address space though. = If you assign /56s to your users then that is what the RIR need-base calcul= ations are based on (according to current policy).

    So if the ISP says "we need a /48 per customer," the RIR is= going to ask "okay, but what are the details of how you will use that= /48?" =A0 I don't think so. =A0 Why are we still talking about th= is?

    Personally, I'm waiting for us to agree that = due to current RIR policies, if an ISP chooses to use semantic prefixes, th= en it will not be able to give users as much space as it would be able to g= ive them if it chose not to use semantic prefixes.
    --047d7bd75c5e24c65904de73f138-- From nalini.elkins@insidethestack.com Wed Jun 5 21:24:08 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E18421F936E for ; Wed, 5 Jun 2013 21:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiM4VcrxBUpV for ; Wed, 5 Jun 2013 21:24:03 -0700 (PDT) Received: from nm23.access.bullet.mail.mud.yahoo.com (nm23.access.bullet.mail.mud.yahoo.com [66.94.237.88]) by ietfa.amsl.com (Postfix) with ESMTP id E403421F9408 for ; Wed, 5 Jun 2013 21:23:59 -0700 (PDT) Received: from [66.94.237.195] by nm23.access.bullet.mail.mud.yahoo.com with NNFMP; 06 Jun 2013 04:23:59 -0000 Received: from [66.94.237.106] by tm6.access.bullet.mail.mud.yahoo.com with NNFMP; 06 Jun 2013 04:23:59 -0000 Received: from [127.0.0.1] by omp1011.access.mail.mud.yahoo.com with NNFMP; 06 Jun 2013 04:23:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 376421.38150.bm@omp1011.access.mail.mud.yahoo.com Received: (qmail 84918 invoked by uid 60001); 6 Jun 2013 04:23:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370492638; bh=S/TQ5+shRxjWeebG3djXXqZtjJlSV6r+y8QWsv4GGLo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=jDK21skz+jXz8k3STaI0P26pQsYRdcHyb0Fufy8EZbjkTYAcrC5dWYP/KunZpjyWI9ofUAMbZ9NG1+BcRHl8fSZFLpGiQ9mTIkI1Jalf6b5ov2KkvLjqf7Wojz+tQQVTpgCWua4MQbsoI6TlUamejeTNF+AgIT0XU8XFpzR+FiU= X-YMail-OSG: IaTZMhQVM1mtvGBJbujSTJpRg.QJOawUiL47JVhioVcrlcj 2bO2_zHlUXmN6t9nbEh8CrbvkvncuNnP2HwBafm64mrffjlc3wBqvbPAMiRF UrXx1SMZD6zKQNcNPisKcds.L.HA27fUIhXfZBmhBbqDMal.Mf46Z__N5Mio Ns1zrSupnqf8x2exmkPDlvpgOXy3fyU3WjGh1NeTVj4jlX1qpdiBhkpcG.nG KTQVJ1pGc40Luhrzg4KoGHq1pxZe_Gu_VHpDwJ72K89CqbMGryNdr45cA9T7 O3GGkXEmHohFll3Ir.44.Ec4_Zypl8y3RD0DwFRve1lRWzDJ3x5_YSUpFM0h mYRXV55Qh_grOsN4OaEOFeAIzv7KSH6T5pL8s_9fFGlXMmjqvfJ9yDZeAz0r V621s8I52AT2AV.nPe.HErb0LgT.kwTr_rsAjc8jgqkFpyD_dSOsPD_xmMuP fXXMXzzd9hqvNEaBHdih32Lq.xSBaUlvgP2XYJziqBSKeKJK7_eu6.DQMkrQ 5JJEJUw78VP83JXykHb00AJr6j9VYV_5ZJ6uQ6KBYjUUOJKmg3Y7Wrib.ztE OIi2Uqda3nk8wXB0rzj0opQXIQBfZj6TGZIIFYPPQbIYjxZsF41KJwihHHSm V_faW6cw.qYgwWErB3MbwP_Xmd8rTJspa55cbHX6hTn6kO4pkQr0v9dZoxVk tRGjVD.yEhJYtf_0aVoLNKyOrcsO2_OHIh6_2WZyyWELeDJABdiIeuEKghyC hj5UEVApQ Received: from [24.130.37.147] by web2802.biz.mail.ne1.yahoo.com via HTTP; Wed, 05 Jun 2013 21:23:58 PDT X-Rocket-MIMEInfo: 002.001, QnJpYW4sCgpUd28gcXVlc3Rpb25zOgoKRmlyc3Q6Cgo.PiBTb21lIHRyaWNreSBhbmQgcG90ZW50aWFsbHkgbWFsaWNpb3VzIGNhc2VzIHdpbGwgYmUgYXZvaWRlZCBieSBmb3JiaWRkaW5nCgo.PiB2ZXJ5IGxvbmcgY2hhaW5zIG9mIGV4dGVuc2lvbiBoZWFkZXJzIHRoYXQgbmVlZCB0byBiZSBmcmFnbWVudGVkIFtJLUQuaWV0Zi02bWFuLW92ZXJzaXplZC1oZWFkZXItY2hhaW5dLiAKCkkgd29uZGVyIGlmIHRoaXMgaXMgdGhlIHBsYWNlIHRvIGRlZmluZSAidmVyeSBsb25nIj8KClNlY29uZDoKCkFyZSB0aGUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.144.546 References: <51AFC515.8010704@gmail.com> Message-ID: <1370492638.82480.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> Date: Wed, 5 Jun 2013 21:23:58 -0700 (PDT) From: Nalini Elkins Subject: Re: draft-ietf-6man-ext-transmit-01 To: Brian E Carpenter , 6man In-Reply-To: <51AFC515.8010704@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-153701192-1158499625-1370492638=:82480" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 04:24:08 -0000 ---153701192-1158499625-1370492638=:82480 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Brian,=0A=0ATwo questions:=0A=0AFirst:=0A=0A>> Some tricky and potentially = malicious cases will be avoided by forbidding=0A=0A>> very long chains of e= xtension headers that need to be fragmented [I-D.ietf-6man-oversized-header= -chain]. =0A=0AI wonder if this is the place to define "very long"?=0A=0ASe= cond:=0A=0AAre there other RFCs which have rules for what "middle boxes" wi= ll do? I am not referring to translation techniques such as SIIT, etc. wh= ich is implemented in some load balancers.=0AI guess I am wondering more ab= out=A0if there is a precedent for regulating what packets firewalls will an= d will not forward.=0A=0ABTW, thanks so much for doing this!=0A=0A=A0=0ATha= nks,=0A=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.i= nsidethestack.com ---153701192-1158499625-1370492638=:82480 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 
    Brian,

    =

    Two questions:

    First:

    >=
;> Some tricky and potentially malicious cases will be avoided by=
 forbidding
    >>  very long chains=
 of extension headers that need to be fragmented [I-D.ietf-6man-oversized-header-chain]. 

    I wonder if this is the place to define "very long"?
    Second:

    Are there other RFCs which have r=
ules for what "middle boxes" will do?   I am not referring to translation t=
echniques such as SIIT, etc. which is implemented in some load balancers.
    I guess I am wondering more about=
 if there is a precedent for re=
gulating what packets firewalls will=
 and will
 not forward.

    =

    BTW, thanks so much for doing this!

     
    Thanks,

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

      
     
     
     
     
     
     
      
    
---153701192-1158499625-1370492638=:82480--

From brian.e.carpenter@gmail.com  Wed Jun  5 21:47:41 2013
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC86321F8D90 for ; Wed,  5 Jun 2013 21:47:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HR1ka0KsOja for ; Wed,  5 Jun 2013 21:47:37 -0700 (PDT)
Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0445121F941F for ; Wed,  5 Jun 2013 21:47:29 -0700 (PDT)
Received: by mail-pd0-f173.google.com with SMTP id v10so2815438pde.18 for ; Wed, 05 Jun 2013 21:47:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qRfLBjR5IlpI8449a8/wYnuXy1L8tEuGE6fznC6IjzU=; b=HPsdm6IrWNbYlMwHxrcPtlkHEjnxEwzP7cEeJZwUYebm9rPjiq9rDDKH4tmYH8JqHc NiGU3WbKuWSPfMmx9x0PJO6r1bB+v/AqTyNuqss5280faMQ18SLuvuoV/djnwTQFaBM4 kejsyxjTi1QG/dVTaJbc/foqs7eQbLb5yOM55DDeO18xv+4Bjw0Yu6X+E5/qZyMk7eps i+ZDGUa9A1UhlgaBkfRYywcfA2hcAaq5xTmcJcCPN7Obe4MhaPnJMGedoLayBuLAwCgd s0F99HDx7Ib3loZ3tgTdF7g9TV6V29X0IBqGrYVrOYlB/2omkJv9qNSAWpA6WIsNwJvd 3Ruw==
X-Received: by 10.66.155.199 with SMTP id vy7mr5578046pab.69.1370494049674; Wed, 05 Jun 2013 21:47:29 -0700 (PDT)
Received: from [192.168.1.2] (201.188.252.27.dyn.cust.vf.net.nz. [27.252.188.201]) by mx.google.com with ESMTPSA id ra4sm75815878pab.9.2013.06.05.21.47.27 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 21:47:28 -0700 (PDT)
Message-ID: <51B01466.2050306@gmail.com>
Date: Thu, 06 Jun 2013 16:47:34 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Nalini Elkins 
Subject: Re: draft-ietf-6man-ext-transmit-01
References: <51AFC515.8010704@gmail.com> <1370492638.82480.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com>
In-Reply-To: <1370492638.82480.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: 6man 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jun 2013 04:47:42 -0000

On 06/06/2013 16:23, Nalini Elkins wrote:
> Brian,
> 
> Two questions:
> 
> First:
> 
>>> Some tricky and potentially malicious cases will be
>>> avoided by forbidding
>>> very long chains of extension headers that need to be
>>> fragmented [I-D.ietf-6man-oversized-header-chain].
> 
> I wonder if this is the place to define "very long"?

I guess those two words can be deleted - the issue is only that
the header chain gets fragmented at all. The full discussion is
in the cited draft, of course.

> 
> Second:
> 
> Are there other RFCs which have rules for what "middle boxes"
> will do?   I am not referring to translation techniques such
> as SIIT, etc. which is implemented in some load balancers. I
> guess I am wondering more about if there is a precedent for
> regulating what packets firewalls will and will not forward.

The IETF hasn't done much about firewalls at all. This search
produces far more expired drafts than anything else:
https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit=

   Brian

> 
> BTW, thanks so much for doing this!
> 
> 
> Thanks,
> 
> 
> Nalini Elkins Inside Products, Inc. (831) 659-8360 
> www.insidethestack.com

From lorenzo@google.com  Thu Jun  6 03:05:07 2013
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A5921F972C for ; Thu,  6 Jun 2013 03:05:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=1.000,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zk6yIn5lMkWR for ; Thu,  6 Jun 2013 03:05:06 -0700 (PDT)
Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF6521F96FC for ; Thu,  6 Jun 2013 03:05:05 -0700 (PDT)
Received: by mail-qc0-f178.google.com with SMTP id n10so26571qcx.37 for ; Thu, 06 Jun 2013 03:05:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=55nnjTY3aUPMbR3ZgmpLjpX7ZzZtrDOWnBhZg3jxRn4=; b=KygaapsnkBJyez+4HitIItsOKx4THsavLsRuNY1VSMwn4C+Kb/+9gIRYoRYLbEbsE7 G+ZzE8YTC3dDxuznRaxt4C0OMMuYhshK0C/ncyixYeXN7NiyUtrvR68b77Hz4IC9C8aM Tl5cTKxZuM4eNVEbCTbrCZUYOY1GBlkmdhgBd3YK3AAfWMuhHk+N+81OmEtGSw2rjH/G 6+qWq7l/lkO71yOKP/5bQhoc478Uw+SivzrjGfoU1w6EA4XVg+FqrWi0X8ADvjd2CZ1z ORG6YzeApsnkgBOSmTKk5DUc0W99+rUOOjd2WMp5PYW1Ai8v5Qi/Y2N++vXxE7zkZYuK QXlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=55nnjTY3aUPMbR3ZgmpLjpX7ZzZtrDOWnBhZg3jxRn4=; b=flpuBOvTeErQRK+mvtLbkbA8C1/yiz1WA42Cf9cwzHJot6Xkz4K7ZPPahLWM+KSHJh MUYJqmP+9djJtMReGQduOGJmIOM0+gJqXA6ZtpcN72slTqdtI7LRtezjDIElZmccCl7U r8eP/Oe4Z39YQEyWaLeAAvF8d5fN4Is7yaFLwDXNtJi11d5BG/A0jflmQIeB0qkODXHO j0oxEXzYB0GCU7/WhzwWYNwCbup6W7NgeehVXU3bOlISZOsl/09zCrxX6o2H9vd+8HbH k/sJv8ApjQRytA9dKS3a2aJ3Vch5I5uVQ2PPGn61p9ergTT8Jizx84capmynGG4EgqG7 bbYg==
X-Received: by 10.224.98.65 with SMTP id p1mr33053115qan.70.1370513105417; Thu, 06 Jun 2013 03:05:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.158.8 with HTTP; Thu, 6 Jun 2013 03:04:44 -0700 (PDT)
In-Reply-To: 
References:  <8D23D4052ABE7A4490E77B1A012B6307751C4E3E@mbx-01.win.nominum.com>  <8D23D4052ABE7A4490E77B1A012B6307751C4F11@mbx-01.win.nominum.com>  <8D23D4052ABE7A4490E77B1A012B6307751C554C@mbx-01.win.nominum.com>  
From: Lorenzo Colitti 
Date: Thu, 6 Jun 2013 19:04:44 +0900
Message-ID: 
Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03
To: "Niall O'Reilly" 
Content-Type: multipart/alternative; boundary=20cf3074d9a4cf164204de79723e
X-Gm-Message-State: ALoCoQk9NDEENpKwPvecIaQ2HqTcGDIJhDRy33Pd7K+wXGeKb6kMpcCl/vHWxOteRm8PoBesNJKMpZQ9gAWxHOAJOdVpNQzxMI1pqD25/pNPSfCwSAgGAOqCN0EeUeC1viVqY+HiuJerkn7pPH9V0G7ROyoNWWAcOIKgHk5P15KQDZEac/FIg7Nc5XwcShfZbABvbh1ZP3CR
Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ted Lemon , Ralph Droms 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jun 2013 10:05:07 -0000

--20cf3074d9a4cf164204de79723e
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 6, 2013 at 6:10 PM, Niall O'Reilly  wrote:

>
> On 6 Jun 2013, at 04:26, Lorenzo Colitti wrote:
>
> >  indeed, the letter of the policy above suggests that a /48 is
> acceptable only in the case of "extra large end sites"
>
>         How do you read that into the extract you cited, Lorenzo?


Sorry - my statement should have said 'the letter of the policy above
suggests that *more than* a /48 is acceptable only in the case of "extra
large end sites"'. The argument is the same:

- Assigning more than a /48 to an end site is only acceptable in the case
of extra large end sites, and/or with substantial paperwork.
- Giving a user the use of a full /48 of space *and* using semantic bits
requires routing more than a /48 to the per user.
- Thus, if ISPs wants to use semantic bits, they will have to give users
less than the use of a full /48 of space.

Is that clearer now?

--20cf3074d9a4cf164204de79723e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


    On Thu, Jun 6, 2013 at 6:10 PM, Niall O'Reilly <ni=
all.oreilly@ucd.ie> wrote:
    



    
On 6 Jun 2013, at 04:26, Lorenzo Colitti wrote:
    

    
> =A0indeed, the letter of the policy above suggests that a /48 is accep=
table only in the case of "extra large end sites"
    

    

    =A0 =A0 =A0 =A0 How do you read that into the extract you cited, Lore=
nzo?

    Sorry - my statement should have=
 said 'the letter of the policy above suggests that *more than* a /48 i=
s acceptable only in the case of "extra large end sites"'. Th=
e argument is the same:
    



    - Assigning more than a /48 to an end site =
is only acceptable in the case of extra large end sites, and/or with substa=
ntial paperwork.
    - Giving a user the use of a full /48 of s=
pace *and* using semantic bits requires routing more than a /48 to the per =
user.
    


    - Thus, if ISPs wants to use semantic bits, they will have to gi=
ve users less than the use of a full /48 of space.

    Is that clearer now?
    

--20cf3074d9a4cf164204de79723e--

From shengjiang@gmail.com  Thu Jun  6 03:39:34 2013
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E92E21F9931; Thu,  6 Jun 2013 03:39:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oj2aCBRTTBsx; Thu,  6 Jun 2013 03:39:33 -0700 (PDT)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9175F21F9927; Thu,  6 Jun 2013 03:39:32 -0700 (PDT)
Received: by mail-la0-f45.google.com with SMTP id fr10so2430919lab.18 for ; Thu, 06 Jun 2013 03:39:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H2WKtese8H36KtBARXcT9SWbsGWBLFbPX0g/VwlOUv0=; b=SXGwWyVeRyxMS2dSMG/FOg03HOV/fhcRQf05I5jsN5vfMPhquQ59yBnfi5FsYrsqZR 6zARzRkEDeGQ7ly/KZ/h95w69U7qNjeOcQ+phqnblu1QLOjz0wTVSQTMJo0rbzPoIRgO 2hCKMoI/U4o0npjUrH9HcIymD3nyE/map6tI2lXJ8YPwKOtd53a5nF6cpRalNeFRKCk5 FCQyGXsTRXg7Z5lScSwmo7Ob38gleUGX+g5sSAL9Sjz1BwKgfgfe78HBUucnvDBOo0rv NF/99vMxaNTy7M61iNh1B6879/7YHWlUlCkQyEe06maAvW7RrvtpgYhejs/u6B7kmFFi zUdw==
MIME-Version: 1.0
X-Received: by 10.112.21.74 with SMTP id t10mr16569975lbe.129.1370515171452; Thu, 06 Jun 2013 03:39:31 -0700 (PDT)
Received: by 10.112.67.166 with HTTP; Thu, 6 Jun 2013 03:39:31 -0700 (PDT)
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C62A3@mbx-01.win.nominum.com>
References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <021E64FECA7E5A4699562F4E6671648103DE44@XCH-PHX-503.sw.nos.boeing.com> <8D23D4052ABE7A4490E77B1A012B6307751C62A3@mbx-01.win.nominum.com>
Date: Thu, 6 Jun 2013 18:39:31 +0800
Message-ID: 
Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03
From: Sheng Jiang 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=14dae94739f3f42bfd04de79edec
Cc: "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jun 2013 10:39:34 -0000

--14dae94739f3f42bfd04de79edec
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yes, this discussion has become far way from my original motivation of
analysing semantic prefix mechanism. I am going to stop replying to the
discuss regarding to the avaibilities of bits. In the future version, I
will add the bits consumption as one of the pitfalls.

By the way, ISPs are only one kind of network operators who are interesting
in semantic prefix. Enterprise network operators are another group of
network operators who can benefit from embedded semantics. And the
enterprises do not have subscribers who potentially need extra bits.

Cheers,

Sheng


On 6 June 2013 04:13, Ted Lemon  wrote:

> On Jun 5, 2013, at 3:28 PM, "Manfredi, Albert E" <
> albert.e.manfredi@boeing.com> wrote:
> > Actually, I was about to make that suggestion myself. We can stop this
> infinite thread by simply saying, do whatever semantic tricks you want wi=
th
> the address blocks allocated to you, but know that you won't get any more
> just so you can play those semantic tricks.
> > What's wrong with that as a policy?
>
> The IETF doesn't set the policy.   I have no objection to that policy, bu=
t
> it ain't up to us.
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>



--=20
Sheng Jiang =E8=92=8B=E8=83=9C

--14dae94739f3f42bfd04de79edec
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Yes, this discussion has become far way=C2=A0from my =
original motivation of analysing semantic prefix mechanism. I am going to s=
top replying to the discuss regarding to=C2=A0the avaibilities of=C2=A0bits=
. In the future version, I will add the bits consumption as one of the pitf=
alls.
    

    =C2=A0
    By the way, ISPs are only one kind of network operato=
rs who are interesting in semantic prefix. Enterprise network operators are=
 another group of network operators who can benefit from embedded semantics=
. And the enterprises do not have subscribers who potentially need extra bi=
ts.
    

    =C2=A0
    Cheers,
    =C2=A0
    Sheng
    <=
div class=3D"gmail_extra">

    On 6 June 2013=
 04:13, Ted Lemon <Ted.Lemon@nominum.com> wrote:
    

    On Jun 5, 2013, at 3:28 PM=
, "Manfredi, Albert E" <albert.e.manfredi@boeing.com> wrote:
    

> Actually, I was about to make that suggestion myself. We can stop this=
 infinite thread by simply saying, do whatever semantic tricks you want wit=
h the address blocks allocated to you, but know that you won't get any =
more just so you can play those semantic tricks.
    

> What's wrong with that as a policy?
    

    

    The IETF doesn't set the policy. =C2=A0 I have no objection to th=
at policy, but it ain't up to us.
    


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




    -- 
    Sheng Jiang=
 =E8=92=8B=E8=83=9C
    --14dae94739f3f42bfd04de79edec-- From sander@steffann.nl Thu Jun 6 03:53:02 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CAE21F9925; Thu, 6 Jun 2013 03:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.071 X-Spam-Level: X-Spam-Status: No, score=0.071 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkVWgFgqKBOO; Thu, 6 Jun 2013 03:52:58 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 77C1E21F9744; Thu, 6 Jun 2013 03:52:58 -0700 (PDT) Received: from [172.20.10.2] (unknown [188.207.83.66]) by mail.sintact.nl (Postfix) with ESMTP id E9DCD204E; Thu, 6 Jun 2013 12:52:56 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Sander Steffann In-Reply-To: Date: Thu, 6 Jun 2013 12:53:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <60F34E4C-BFC0-4970-97B0-9F5E833A83F6@steffann.nl> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <021E64FECA7E5A4699562F4E6671648103DE44@XCH-PHX-503.sw.nos.boeing.com> <8D23D4052ABE7A4490E77B1A012B6307751C62A3@mbx-01.win.nominum.com> To: Sheng Jiang X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org WG" , draft-jiang-v6ops-semantic-prefix@tools.ietf.org, "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 10:53:02 -0000 Hi, > By the way, ISPs are only one kind of network operators who are = interesting in semantic prefix. Enterprise network operators are another = group of network operators who can benefit from embedded semantics. And = the enterprises do not have subscribers who potentially need extra bits. Now for enterprises embedding semantics in the address plan is quite = common and makes a lot of sense. It saves a lot of maintenance work when = maintaining firewall policies etc. It's one of the options I described = in the addressing plan document [1] I wrote for SURFnet in 2010. Part of = that document was based on experiences at the University of Twente. Cheers, Sander [1] http://www.surfnet.nl/en/nieuws/Pages/IPv6numberplan.aspx From Ted.Lemon@nominum.com Thu Jun 6 04:25:49 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D842721F8D31; Thu, 6 Jun 2013 04:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.598 X-Spam-Level: X-Spam-Status: No, score=-108.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZENXgrts092; Thu, 6 Jun 2013 04:25:43 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 12E1721F9955; Thu, 6 Jun 2013 04:25:43 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUbBxtoBhg0G2NzMf81sz79R+rEulIcWE@postini.com; Thu, 06 Jun 2013 04:25:43 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 10DFC1B81F6; Thu, 6 Jun 2013 04:25:41 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E11D819005D; Thu, 6 Jun 2013 04:25:41 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 04:25:41 -0700 From: Ted Lemon To: Lorenzo Colitti Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAFFqgIAAA0MAgAAlngCAAERTAIAAmIuAgAAWAQCAALv5gIAAMI2AgACc9YCAACD6gIAAH1gAgACZeoCAAAjegIAAAgsAgAAClQCAAAJmgIAAAoAAgAAGSQCAALuOgIAA0hUAgACGBoA= Date: Thu, 6 Jun 2013 11:25:41 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C6EB9@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B6307751C4E3E@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C4F11@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C554C@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C6EB9mbx01winnominum_" MIME-Version: 1.0 Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 11:25:50 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C6EB9mbx01winnominum_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jun 5, 2013, at 11:26 PM, Lorenzo Colitti > wrote: Thus, using semantic prefixes makes it much harder to assign /48s to users = - indeed, the letter of the policy above suggests that a /48 is acceptable = only in the case of "extra large end sites", and that *every single* user t= hat needs more than a /48 needs to be separately justified. That's obviousl= y not going to fly for a mass-market ISP. You should reread the text. It says sites that need _more_ than a /48 are= "extra large end sites." --_000_8D23D4052ABE7A4490E77B1A012B6307751C6EB9mbx01winnominum_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <0FA44114E55A9B41A5C591B4FB8B7DEB@nominum.com> Content-Transfer-Encoding: quoted-printable
    On Jun 5, 2013, at 11:26 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
    Thus, using semantic prefixes makes it much harder to assign /48s to users = - indeed, the letter of the policy above suggests that a /48 is acceptable = only in the case of "extra large end sites", and that *every sing= le* user that needs more than a /48 needs to be separately justified. That's obviously not going to fly for a mass-m= arket ISP.

    You should reread the text.   It says sites that need _more_ than= a /48 are "extra large end sites."


    --_000_8D23D4052ABE7A4490E77B1A012B6307751C6EB9mbx01winnominum_-- From lorenzo@google.com Thu Jun 6 04:27:36 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC73221F99C7 for ; Thu, 6 Jun 2013 04:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.076 X-Spam-Level: X-Spam-Status: No, score=-3.076 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emrcy5+kzmCu for ; Thu, 6 Jun 2013 04:27:31 -0700 (PDT) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id AA49B21F9961 for ; Thu, 6 Jun 2013 04:27:31 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id ne12so1790247qeb.13 for ; Thu, 06 Jun 2013 04:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MbBbld1M+CdZem2ZD5dxWHyBTettCkNqs4SIV0egICI=; b=pJWicck2ed3VKH1xvtNIqGtkfjn8vujl/1oRrtPO0LmEM2Du4WqD/eEmDsHoCPhfJg BP7mYL5+72wxsJhpEicwKO4U36vSmgn/FXoWxfVfK/9KSppniuSvvOZ0IZRgHNoFRG8K zsRww2KGgqFI5K/1SULPVKK+OvrhpdA4dZPlVNDzI1F04R1MwWfoE5GkbDR4VAv2f5by cBktbIFB1H/wd20LG7yzRqZleP767VtJYFGvP+dd52EhmTEo5VTXVhKnRBaQtsDziVJE Gen7axvN+58HWLBam5FlpTidEsNzWYQa2q0bLGwoUd9nEGcYf2P9f3ef0YXFXm+Wa2GV +A1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=MbBbld1M+CdZem2ZD5dxWHyBTettCkNqs4SIV0egICI=; b=eUSINThtAnafcNYBIz6jjZRs+Prf+yhqSzqouLtdU9IaokaKaxGOq5Qh04tx8A9Cyd x6ggc0HYLvSu6pSwqKiF3uBocoW12T5ElVFEx6aMPM7qSxJQO1NmiUqapA19bjYsN3/o FihsX0HpE2tYz8rcChxvCLYyBxlOuJuUOkHF6KqMiKULFle1otMX23dKgSvfNvpO1OBW k49svzVy5CCSFeQ66VCoiDEt1yd1icxumE4uzl8/XaG08lt3se0KNUbZuKoUEP4u6tpE K1n3tOB5u3YS8biWg6QAoaKXBUsRf0S32nnpniwghF1VfK2EDFQQGP746tVaUt6GapqQ s8rw== X-Received: by 10.224.182.136 with SMTP id cc8mr34050138qab.10.1370518051059; Thu, 06 Jun 2013 04:27:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.158.8 with HTTP; Thu, 6 Jun 2013 04:27:10 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C6EB9@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B6307751C4E3E@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C4F11@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C554C@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C6EB9@mbx-01.win.nominum.com> From: Lorenzo Colitti Date: Thu, 6 Jun 2013 20:27:10 +0900 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf30363d3f97a84d04de7a99f8 X-Gm-Message-State: ALoCoQn2h20k0ZEWX4dbvrZdq6ImL3p2N3WdoK33xwZgeZ8iTI+EZ2x7Hi3VLLcfCmE7gDomsId2iKyZfLiryWyW/B0lbOohsXMoKvRXdh+0xOorLq/QxwxVsUHPw3BVxXj8cGNSpv9bwRxsL3DSFPiMlqmb5sgrrupUUudwPBzU8K1kTf55baVWIct4MjQ7JHcsmQbWVRf6 Cc: "ipv6@ietf.org" , "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , Owen DeLong , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 11:27:37 -0000 --20cf30363d3f97a84d04de7a99f8 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 8:25 PM, Ted Lemon wrote: > You should reread the text. It says sites that need _more_ than a /48 > are "extra large end sites." > Yes, Niall pointed that out to me. But the argument is the same, see my reply to him. --20cf30363d3f97a84d04de7a99f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Thu, Jun 6, 2013 at 8:25 PM, Ted Lemon <Ted.Lemon@= nominum.com> wrote:
    You should reread the text. =A0 It= says sites that need _more_ than a /48 are "extra large end sites.&qu= ot;

    Ye= s, Niall pointed that out to me. But the argument is the same, see my reply= to him.=A0
    --20cf30363d3f97a84d04de7a99f8-- From Ted.Lemon@nominum.com Thu Jun 6 04:34:20 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B2121F9961; Thu, 6 Jun 2013 04:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.598 X-Spam-Level: X-Spam-Status: No, score=-107.598 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vH0efY2Npzjr; Thu, 6 Jun 2013 04:34:13 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE7221F8FB6; Thu, 6 Jun 2013 04:34:13 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUbBztYbcgqDWF32kTfvFB51WzK4H6VUj@postini.com; Thu, 06 Jun 2013 04:34:13 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id EA68D1B81ED; Thu, 6 Jun 2013 04:34:12 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E2E3C19005D; Thu, 6 Jun 2013 04:34:12 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 04:34:12 -0700 From: Ted Lemon To: Lorenzo Colitti Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAFFqgIAAA0MAgAAlngCAAERTAIAAmIuAgAAWAQCAALv5gIAAMI2AgACc9YCAACD6gIAAH1gAgACZeoCAAAjegIAAwruAgAAV84CAAAZKgIAAAigAgAC9mQCAAIcfgA== Date: Thu, 6 Jun 2013 11:34:12 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C6F61mbx01winnominum_" MIME-Version: 1.0 Cc: "ipv6@ietf.org 6man-wg" , "v6ops@ietf.org WG" , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 11:34:20 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C6F61mbx01winnominum_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jun 5, 2013, at 11:30 PM, Lorenzo Colitti > wrote: Personally, I'm waiting for us to agree that due to current RIR policies, i= f an ISP chooses to use semantic prefixes, then it will not be able to give= users as much space as it would be able to give them if it chose not to us= e semantic prefixes. You will have to wait until someone from an RIR says "we won't allocate mor= e bits in cases like this." We have only heard from one person who works = for an RIR, and his opinion was that this was subject to negotiation, and n= ot clear-cut. But even if we did get some kind of firm commitment from RI= Rs that they would never give an ISP extra bits, the ISP can still use bits= from the customer's allocation, unless RIRs change _that_ policy too (Owen= 's absurd accusations of fraud notwithstanding). We've gone around and around on this for days, and nobody's been able to ma= ke a solid case for the proposition that there aren't enough bits to do sem= antic prefixes. I think we don't need to argue that question anymore. I= s that _really_ the _only_ argument against semantic prefixes? --_000_8D23D4052ABE7A4490E77B1A012B6307751C6F61mbx01winnominum_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
    On Jun 5, 2013, at 11:30 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
    Personally, I'm waiting for us to agree that due to current RIR policies, if an ISP ch= ooses to use semantic prefixes, then it will not be able to give users as m= uch space as it would be able to give them if it chose not to use semantic = prefixes.

    You will have to wait until someone from an RIR says "we won't al= locate more bits in cases like this."   We have only heard from o= ne person who works for an RIR, and his opinion was that this was subject t= o negotiation, and not clear-cut.   But even if we did get some kind of firm commitment from RIRs that they would never gi= ve an ISP extra bits, the ISP can still use bits from the customer's alloca= tion, unless RIRs change _that_ policy too (Owen's absurd accusations of fr= aud notwithstanding).

    We've gone around and around on this for days, and nobody's been able = to make a solid case for the proposition that there aren't enough bits to d= o semantic prefixes.   I think we don't need to argue that question an= ymore.   Is that _really_ the _only_ argument against semantic prefixes?

    --_000_8D23D4052ABE7A4490E77B1A012B6307751C6F61mbx01winnominum_-- From otroan@employees.org Thu Jun 6 04:48:35 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A3D21F99D9; Thu, 6 Jun 2013 04:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyNu3i3Dcm1T; Thu, 6 Jun 2013 04:48:29 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 53CC221F9922; Thu, 6 Jun 2013 04:48:25 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAO91sFGQ/khR/2dsb2JhbABZgwkxv0R3FnSCIwEBBAFZIBALRlcGiBoGu0uNe4EEMweCemEDnV2LIoFYgTk6gS0 X-IronPort-AV: E=Sophos;i="4.87,814,1363132800"; d="scan'208";a="14037230" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 06 Jun 2013 11:48:22 +0000 Received: from [10.147.112.161] (dhcp-lys01-vla250-10-147-112-161.cisco.com [10.147.112.161]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r56BmJdv011302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Jun 2013 11:48:19 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Ole Troan In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> Date: Thu, 6 Jun 2013 13:48:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <820A3277-4080-4588-AEF5-D42456A54D9B@employees.org> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) Cc: "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" , Lorenzo Colitti X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 11:48:35 -0000 >> Personally, I'm waiting for us to agree that due to current RIR = policies, if an ISP chooses to use semantic prefixes, then it will not = be able to give users as much space as it would be able to give them if = it chose not to use semantic prefixes. >=20 > You will have to wait until someone from an RIR says "we won't = allocate more bits in cases like this." We have only heard from one = person who works for an RIR, and his opinion was that this was subject = to negotiation, and not clear-cut. But even if we did get some kind of = firm commitment from RIRs that they would never give an ISP extra bits, = the ISP can still use bits from the customer's allocation, unless RIRs = change _that_ policy too (Owen's absurd accusations of fraud = notwithstanding). >=20 > We've gone around and around on this for days, and nobody's been able = to make a solid case for the proposition that there aren't enough bits = to do semantic prefixes. I think we don't need to argue that question = anymore. Is that _really_ the _only_ argument against semantic = prefixes? I find that a pretty convincing argument. given ample imagination, there is no limit to how many semantic bits = someone could find useful. nor is there a limit to what information someone could find useful to encode. we're seeing examples = of this, albeit further down in the address, for the A+P work. I don't think the IETF should condone this practice, and not write = documents that could be used as justification with the RIRs to acquire = more address space and what is allowed by the current policies. cheers, Ole= From lorenzo@google.com Thu Jun 6 04:49:21 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE6821F9A1A for ; Thu, 6 Jun 2013 04:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ag42zCFxczZ9 for ; Thu, 6 Jun 2013 04:49:20 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5189E21F9A1F for ; Thu, 6 Jun 2013 04:49:18 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id s11so1614686qcw.15 for ; Thu, 06 Jun 2013 04:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PABaCn4e8g7NnA39RmDZJn7JFHmcmJlZ1fZta+GTvDU=; b=hkvLrDxp99xoadD+cA2ieIieB/mORZ5V9d/r3j1MsE02/borl/MZI7J5uS4ODQAd4f Tp1GUQCM83/pRFUtm8vTzavajeM0vrvqphVchdX4CjHkPj0mw4bbdSyj2QToCWmXVtyk ODGlVD269WBFTkS65ZmlxvJ7tt3yDAt49u6BovMbcPVtRmkd/0atJVycY/aaz2GUQ0sq eWwxBsTyvfltup7/K/RCGou1LNcvKcQcdMQKGYyZx35KXZDXI1IuqVKHrUfmjsZAZrL2 8dMQCx02NTNaYWrlHlzUHcwwhTtoqjIPr9uf7saUSDlaehrc4cx5D9Gex5AJ9nTebx7p OCqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=PABaCn4e8g7NnA39RmDZJn7JFHmcmJlZ1fZta+GTvDU=; b=gy3RSc8UcMRwmwygz/6B+t8UySow25WXslEgSzu7UPVwBvp+qqownuFFRUif3VFQfi +HieUXDvLaGTYtJjczrafiZSH0KIayBKOFeZ5koro8Uff79Bt6lD/TrSqooSsdm+qwKw yHK2J27GtkDNwDuTg2FhZyffjBw5lrTrrRd6+WHEjksMTnCF4WYas/SF+Q/apq9hUzxG p1S8HX280XARXDGPQEuprU6Z20J+aLrP/DKk+F0gqSa82ELMkrZRwrk/ugnosZH8i4YT 4jEQpsGMFtiHkm1dQMUpgC3yh9M9C14Gtp7+JBcoBVXFsWRC2yZUppczb+zcfm9MYHrR ziIQ== X-Received: by 10.224.98.65 with SMTP id p1mr33500163qan.70.1370519357699; Thu, 06 Jun 2013 04:49:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.158.8 with HTTP; Thu, 6 Jun 2013 04:48:57 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> From: Lorenzo Colitti Date: Thu, 6 Jun 2013 20:48:57 +0900 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf3074d9a479580104de7ae7e1 X-Gm-Message-State: ALoCoQnbGz1C8p9QCapbJSm6i2e7VFg+9DbvlxJJoL9/r+TWAT9m7Z305AIV04xbUi2q27BrOACJyUTRYcY78waB/z0RkaUGvMmB6xZ7csX8mW2wIA+IET4mYLBzTaycB+FPlIBd1l9sr4rnWEcAxWgShY1WehSKOKsatGWWLfIzF1CxcX8lhU4YpUzPKHlVNzmER4Qy+0Ff Cc: "ipv6@ietf.org 6man-wg" , "v6ops@ietf.org WG" , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 11:49:21 -0000 --20cf3074d9a479580104de7ae7e1 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 8:34 PM, Ted Lemon wrote: > You will have to wait until someone from an RIR says "we won't allocate > more bits in cases like this." We have only heard from one person who > works for an RIR, and his opinion was that this was subject to negotiation, > and not clear-cut. > Sorry, but no. This is clearly spelled out in the policy which I quoted earlier. Surely you're not saying that hearsay from an employee who happens to work in the research group of an RIR is more authoritative than than the official, approved RIR policy that clearly spells this out? You're not saying that, right? Then what are you saying? We've gone around and around on this for days, and nobody's been able to > make a solid case for the proposition that there aren't enough bits to do > semantic prefixes. > It's made very clear in the policy that you can't do this *and* give out /48s to users at the same time (at least, without substantial pain). Thus, using these bits results in ISPs being able to give users less space than they would otherwise. If we agree on that, then we can move on. Do we? > I think we don't need to argue that question anymore. Is that _really_ > the _only_ argument against semantic prefixes? > There were others in this thread. One that comes to mind is "why can't you do this with DSCP, which was designed for the purpose to give packets semantics?". But one argument at a time, ok? --20cf3074d9a479580104de7ae7e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Thu, Jun 6, 2013 at 8:34 PM, Ted Lemon <Ted.Lemon@= nominum.com> wrote:
    You will have to wait until someon= e from an RIR says "we won't allocate more bits in cases like this= ." =A0 We have only heard from one person who works for an RIR, and hi= s opinion was that this was subject to negotiation, and not clear-cut.

    Sorry, but no. Thi= s is clearly spelled out in the policy which I quoted earlier. Surely you&#= 39;re not saying that hearsay from an employee who happens to work in the r= esearch group of an RIR is more authoritative than than the official, appro= ved RIR policy that clearly spells this out? You're not saying that, ri= ght? Then what are you saying?

    We've gone around and around on this for days, and no= body's been able to make a solid case for the proposition that there ar= en't enough bits to do semantic prefixes.

    It's made very clear in th= e policy that you can't do this *and* give out /48s to users at the sam= e time (at least, without substantial pain). Thus, using these bits results= in ISPs being able to give users less space than they would otherwise. If = we agree on that, then we can move on. Do we?
    =A0
    I think we don't need to argue that question anymore. =A0 Is= that _really_ the _only_ argument against semantic prefixes?

    There were others in this thread. One that comes to mind is &qu= ot;why can't you do this with DSCP, which was designed for the purpose = to give packets semantics?". But one argument at a time, ok?
    --20cf3074d9a479580104de7ae7e1-- From Ted.Lemon@nominum.com Thu Jun 6 06:14:46 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28BA21F99E3; Thu, 6 Jun 2013 06:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.932 X-Spam-Level: X-Spam-Status: No, score=-106.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOC2vvQ7oMBy; Thu, 6 Jun 2013 06:14:39 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4D421F99D5; Thu, 6 Jun 2013 06:14:38 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUbCLPjIdQABIjpwtExjX+iVMYynXQQz4@postini.com; Thu, 06 Jun 2013 06:14:38 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2A45E1B81D7; Thu, 6 Jun 2013 06:14:38 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 239B619005D; Thu, 6 Jun 2013 06:14:38 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 06:14:31 -0700 From: Ted Lemon To: Lorenzo Colitti Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAFFqgIAAA0MAgAAlngCAAERTAIAAmIuAgAAWAQCAALv5gIAAMI2AgACc9YCAACD6gIAAH1gAgACZeoCAAAjegIAAwruAgAAV84CAAAZKgIAAAigAgAC9mQCAAIcfgIAABCCAgAAX6IA= Date: Thu, 6 Jun 2013 13:14:31 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C73E5@mbx-01.win.nominum.com> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1BB5294C30BBCE4B80DA4874C7A3A6D4@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org 6man-wg" , "v6ops@ietf.org WG" , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 13:14:46 -0000 On Jun 6, 2013, at 7:48 AM, Lorenzo Colitti wrote: > Sorry, but no. This is clearly spelled out in the policy which I quoted e= arlier. Surely you're not saying that hearsay from an employee who happens = to work in the research group of an RIR is more authoritative than than the= official, approved RIR policy that clearly spells this out? You're not say= ing that, right? Then what are you saying? You are suffering from confirmation bias. The policy says nothing of the = kind. You are reading it that way because it agrees with the conclusion y= ou want to draw. This is why I am asking you to give some other reason. = RIR policy is not a reason. If the IETF should be recommending against th= is, there's a reason why we should be recommending against it. I'm simply= asking you to state that reason. If the reason is "not enough bits," the= n that's not a good enough reason, because if "not enough bits" were true, = we would be recommending against giving end-user sites /48's, and we are no= t. > There were others in this thread. One that comes to mind is "why can't yo= u do this with DSCP, which was designed for the purpose to give packets sem= antics?". But one argument at a time, ok? Right. And we've beaten this one to death, so let's move on to the next o= ne. From lorenzo@google.com Thu Jun 6 06:35:56 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3A821F9A2A for ; Thu, 6 Jun 2013 06:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Pz8rYHjm3iE for ; Thu, 6 Jun 2013 06:35:56 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF8321F9A21 for ; Thu, 6 Jun 2013 06:35:52 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id bv4so295612qab.18 for ; Thu, 06 Jun 2013 06:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YH9fYMcwt2URDnAsSivNoekCEYcbD/8Z8NYvfOClImQ=; b=UJYL1lAtzqOOZrLq11SXJdJ4Ch5g884XkErBp9OJScHgYD/UETv1b+M+XCkJVFHpux CHhoMezbC+HRl1FuvcL1G15zIRcVoJfETV2gy7JwG5nsRPbBg86LzeghYxHmdKxaQooB ZJ3e2wqYKwxPpfyLCDgcqW53qdAETmBuhwzzWTy5XGo5RoKLN3azp82sS5hnlsgTGpXn By+FUVjVp9MhVv14p5x3MxnNLzx+vTNeVQQTzuRI0gahdf3s9eTimmAN8Nx0uEclr4Xu 7j0HdlW1UFVqESSQ7NJTLj4jKyjdYCgKvcNpwckf8jrNt1H0eaJekmSHv6xQHIW8stOd eEBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=YH9fYMcwt2URDnAsSivNoekCEYcbD/8Z8NYvfOClImQ=; b=AeLlfTSez8w4n0V4Zvc6TVsVWJau3Epnre7GvHVj8x0mMtec5VVXagV4l0Ni+af5x1 u81wzcZQnzo0k1O3go9NPnsTGyNhPFzKCNi2E2Nc0BYlYrRDch1aIgUbCNWmyCnr5QqG m7/R9XXETJROWj8bPL3N8PTJur/4AxSyqvCDAzKGCtliVy2FStcJaJj8qb+KliSbx0R4 bUVxpRY34E8seJRAw/1yN84G8Ow3FDmuVJ64kv7kHUYSGRzQt1TcCpYoPbUDanNr+Ajb cI7CBNt7jUYphg8Uk5MpmoJhJnLs8OpVK8NPtTFBY84zdVkipTMZzbTfqMkESegZoPke iNgw== X-Received: by 10.49.101.74 with SMTP id fe10mr9388498qeb.11.1370525750481; Thu, 06 Jun 2013 06:35:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.158.8 with HTTP; Thu, 6 Jun 2013 06:35:30 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C73E5@mbx-01.win.nominum.com> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C73E5@mbx-01.win.nominum.com> From: Lorenzo Colitti Date: Thu, 6 Jun 2013 22:35:30 +0900 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 To: Ted Lemon Content-Type: multipart/alternative; boundary=001a11c2c6ce8378b404de7c64c5 X-Gm-Message-State: ALoCoQmjnMMEUq+Fun86G4Pn8pcRadYVsrgR2jxQ1ysqT732l5rlCABK6QdakOEjKDtPGTBSE6gblCz8UgDpfoMbw/pjBH2aP8P2lyVclLupyq9xouTrieu+UDEWqDrRlZaq2YDY5ag/O9tEYHhFJhPOM7K9uOfqSsmZlF0fFIJgs5LD17gkSd7TkpkiqUDk/Xk8Obsx2+Ny Cc: "ipv6@ietf.org 6man-wg" , "v6ops@ietf.org WG" , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 13:35:56 -0000 --001a11c2c6ce8378b404de7c64c5 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 10:14 PM, Ted Lemon wrote: > > Sorry, but no. This is clearly spelled out in the policy which I quoted > earlier. Surely you're not saying that hearsay from an employee who happens > to work in the research group of an RIR is more authoritative than than the > official, approved RIR policy that clearly spells this out? You're not > saying that, right? Then what are you saying? > > You are suffering from confirmation bias. The policy says nothing of the > kind. Saying "it says nothing of the sort" without even citing it is not a very convincing argument. If you want to state convincingly that it says nothing of the sort, then why not start from the text I posted earlier and explain why my interpretation is incorrect? --001a11c2c6ce8378b404de7c64c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Thu, Jun 6, 2013 at 10:14 PM, Ted Lemon <Ted.Lemon= @nominum.com> wrote:
    > Sorry, but no. This i= s clearly spelled out in the policy which I quoted earlier. Surely you'= re not saying that hearsay from an employee who happens to work in the rese= arch group of an RIR is more authoritative than than the official, approved= RIR policy that clearly spells this out? You're not saying that, right= ? Then what are you saying?

    You are suffering from confirmation bias. =A0 The policy says nothing= of the kind. =A0

    Saying "it sa= ys nothing of the sort" without even citing it is not a very convincin= g argument. If you want to state convincingly that it says nothing of the s= ort, then why not start from the text I posted earlier and explain why my i= nterpretation is incorrect?
    --001a11c2c6ce8378b404de7c64c5-- From Ted.Lemon@nominum.com Thu Jun 6 06:57:02 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4596521F93C4; Thu, 6 Jun 2013 06:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.848 X-Spam-Level: X-Spam-Status: No, score=-106.848 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fn8E+NKf6kmq; Thu, 6 Jun 2013 06:56:55 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 6430021F935A; Thu, 6 Jun 2013 06:56:55 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUbCVJmHz/Oqzjv2tnJ3V7EB6Ky5pRaHZ@postini.com; Thu, 06 Jun 2013 06:56:55 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id EE69C1B81D6; Thu, 6 Jun 2013 06:56:53 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E2C7519005D; Thu, 6 Jun 2013 06:56:53 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 06:56:53 -0700 From: Ted Lemon To: Lorenzo Colitti Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAFFqgIAAA0MAgAAlngCAAERTAIAAmIuAgAAWAQCAALv5gIAAMI2AgACc9YCAACD6gIAAH1gAgACZeoCAAAjegIAAwruAgAAV84CAAAZKgIAAAigAgAC9mQCAAIcfgIAABCCAgAAX6ICAAAXdAIAABfgA Date: Thu, 6 Jun 2013 13:56:52 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C75A3@mbx-01.win.nominum.com> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C73E5@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C75A3mbx01winnominum_" MIME-Version: 1.0 Cc: "ipv6@ietf.org 6man-wg" , "v6ops@ietf.org WG" , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 13:57:02 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C75A3mbx01winnominum_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jun 6, 2013, at 9:35 AM, Lorenzo Colitti > wrote: Saying "it says nothing of the sort" without even citing it is not a very c= onvincing argument. If you want to state convincingly that it says nothing = of the sort, then why not start from the text I posted earlier and explain = why my interpretation is incorrect? The statement you claim is in there isn't in there. How am I supposed to = point out to you the place where it isn't? --_000_8D23D4052ABE7A4490E77B1A012B6307751C75A3mbx01winnominum_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
    On Jun 6, 2013, at 9:35 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
    Saying "it says nothing of the sort" without even citing it is not a ve= ry convincing argument. If you want to state convincingly that it says noth= ing of the sort, then why not start from the text I posted earlier and expl= ain why my interpretation is incorrect?

    The statement you claim is in there isn't in there.   How am I su= pposed to point out to you the place where it isn't?

    --_000_8D23D4052ABE7A4490E77B1A012B6307751C75A3mbx01winnominum_-- From lorenzo@google.com Thu Jun 6 07:09:45 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C2B21F99F2 for ; Thu, 6 Jun 2013 07:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rncx+2P0HlU for ; Thu, 6 Jun 2013 07:09:44 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 718E721F99E3 for ; Thu, 6 Jun 2013 07:09:44 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id m15so471926qcq.19 for ; Thu, 06 Jun 2013 07:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zJlo+CTXpwSWXU007F7KXxg4lcAyJKbFKD3JBJhn8aA=; b=bBz4dHIaP4YDBO8Gx0CVzQjNhZZiSnkom3imr40AnmURe0wZ9Kp7WZ78y5HgdfULS+ yLDvdCfQ9umuIS2HWJFkxYgTUtg24grlWSySK1UD5kP7zk5ta1jN56bPDJU4LkAZnJdN aeq1HoV+yktadVFjEYKaXlGYhvtxvVhEW2EHI9V941AzjP4EeFBfwPzu5KmO6sX0CRgD BkRudd1xyjyz9LqP0jrO46L7e0pAKP7OKostCIymD9mgnW5msXznOPlT/Oj5LaMejmcN wYngZRm8Rqk24u3HTkfCtCUtDt613eXcm38Xx/Ji/4YHnE1nGZ/OVm/OfetOte9YEYlJ BNHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=zJlo+CTXpwSWXU007F7KXxg4lcAyJKbFKD3JBJhn8aA=; b=aVDA8LTVY2t1AIifU2zg3CW3HBuT3btSQh5dYeie04zSQuPLbsrJl9/YjJKy5u1O3T OqDEvLbHNR4r1a7P0NPoauaa8tDBjOQevKhYCnaCxVa5rhUTjRK2zcP8GSuBEVaNatv1 sLuNMsVgsyA32/B+mk+b/okexgJGhvubYGTJd52mxKDxG4VZ1IeFXXIRSOVJfFDFQZbq /MFz2Ps3Ie2PDMSuCo7FpevVwAc1nkwzWsgJH+JADBKDSPNAavHqv6TF/CAOlFW9vKBI SFzoUPnsv7wZyFLOBW4UHKRNbUYqauUemwBDyECLXCFSJwjdXAU7R3KRdJeZCkrANWR+ wFuQ== X-Received: by 10.49.49.167 with SMTP id v7mr40881566qen.10.1370527783841; Thu, 06 Jun 2013 07:09:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.158.8 with HTTP; Thu, 6 Jun 2013 07:09:23 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C75A3@mbx-01.win.nominum.com> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C73E5@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C75A3@mbx-01.win.nominum.com> From: Lorenzo Colitti Date: Thu, 6 Jun 2013 23:09:23 +0900 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7b6da828b61cda04de7cddcf X-Gm-Message-State: ALoCoQn0Ksq/tJ0uPH256BHGDgOf7hhLVA9wd4LUdS4phuDHqCNeFhWPKxlIWUgPhVLvdAVC/4HpFcvPkwn8DDfbctng8VrhMJNhx3NbwP08LBQQWkO9VJHy/OWEh2HGJeYW0cW4VQVkeRbXzKPU2E0STW0GGxVPUtyhawbdETSej73GG3FjSYut960gQM3/sfhg4UoDWtJi Cc: "ipv6@ietf.org 6man-wg" , "v6ops@ietf.org WG" , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 14:09:45 -0000 --047d7b6da828b61cda04de7cddcf Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 10:56 PM, Ted Lemon wrote: > Saying "it says nothing of the sort" without even citing it is not a > very convincing argument. If you want to state convincingly that it says > nothing of the sort, then why not start from the text I posted earlier and > explain why my interpretation is incorrect? > > > The statement you claim is in there isn't in there. How am I supposed to > point out to you the place where it isn't? > Start by saying how the statement I point to as justification does not, in fact, mean what I say, and why it does not? --047d7b6da828b61cda04de7cddcf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Thu, Jun 6, 2013 at 10:56 PM, Ted Lemon <Ted.Lemon= @nominum.com> wrote:
    Saying "it says nothing of the sort" without even citing it is not a ve= ry convincing argument. If you want to state convincingly that it says noth= ing of the sort, then why not start from the text I posted earlier and expl= ain why my interpretation is incorrect?

    The statement you claim is in there isn't in there. =A0 How = am I supposed to point out to you the place where it isn't?
    =

    Start by saying how the statement I = point to as justification does not, in fact, mean what I say, and why it do= es not?
    --047d7b6da828b61cda04de7cddcf-- From nalini.elkins@insidethestack.com Thu Jun 6 07:25:01 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E6A21F9A0A for ; Thu, 6 Jun 2013 07:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fyqxgcuD-MQ for ; Thu, 6 Jun 2013 07:24:49 -0700 (PDT) Received: from nm17-vm0.access.bullet.mail.mud.yahoo.com (nm17-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.21]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC5321F99BD for ; Thu, 6 Jun 2013 07:24:40 -0700 (PDT) Received: from [66.94.237.192] by nm17.access.bullet.mail.mud.yahoo.com with NNFMP; 06 Jun 2013 14:24:32 -0000 Received: from [66.94.237.107] by tm3.access.bullet.mail.mud.yahoo.com with NNFMP; 06 Jun 2013 14:24:32 -0000 Received: from [127.0.0.1] by omp1012.access.mail.mud.yahoo.com with NNFMP; 06 Jun 2013 14:24:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 856245.23828.bm@omp1012.access.mail.mud.yahoo.com Received: (qmail 18546 invoked by uid 60001); 6 Jun 2013 14:24:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370528672; bh=2KYNVdzNV4tmWqoIEve626eCnket13PPtQ4aqFa75OE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=D0GumGPnxmwBN+z095EYOkYI/sDJOCE0GltXUUP3TxJmdU/o99wAnSnIGtTPx4cbFVfdbKwrj4Xn+I5bErcR1+rw4022NEQZJrLdl5xqWqoHhuL9lZZKFXggiIuReppJVxRlb5Lv5lQODTZdLnsrA40D65VwBE3CqO3rVh/4Ylw= X-YMail-OSG: t641L5wVM1nh925vfZNlCLXY2vmefuBUZurjQW5n_MUPMeg Q2G.wpz5PrZtmp2xnCE.sMlzBnt5K_zQr7xGc5FSWXO6oTEf3rb5q109amVj PyqKeFHTJ0s9A78wNoiRENIZUE3l0Wdx7WhKBtWKTIK8bp8AKSelNCGVVEGX iClvUpiRdngVE9jiK_ahQylhkZ2XhqMnPWLlLasWxIg20nAkz09pYMwIbInD WALxb_72IoY2lBBwo.8BQvHmUjr74_X0VmvMoOe2nxvRmM_ZqpJUhs8JqwbG uv3atIGwuvxmgv.15IcMxboXOjH9.A5xbUikzdyTZacN1RvzwbWT7GIR9apD RBkO2.FZbwQDK3jbdu3pbETivhyLANCZ9OiwhIyaSJIhJRdb45YwBPfYOx6K WYIm5_mZk9mSnoe6ypFubtZL56yZi0OeH4.6.Cts3MMyF84m0qxXIrhr1Lo7 02dSZGuqHyL4wLHqa1A9R4GZUR3icB1wTpbFnnJHvuGNOXq_GVzvJYTe6OEx Xg_XTYki5Y_tCuL0VomNY7Y93ueQOlnTLCqQRd7FJdkK2LDbJdiZ1xOm.fKe RCltHNaazbmOyjqHno5L2FNv7uTGc08YzGtbpWpaRTny7_mK39d2NlGhv_d9 ltlsOSYPhQCe7GHLiRgE7PMA- Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Thu, 06 Jun 2013 07:24:32 PDT X-Rocket-MIMEInfo: 002.001, Pj4.IFNvbWUgdHJpY2t5IGFuZCBwb3RlbnRpYWxseSBtYWxpY2lvdXMgY2FzZXMgd2lsbCBiZcKgYXZvaWRlZCBieSBmb3JiaWRkaW5nwqB2ZXJ5IGxvbmcgY2hhaW5zIG9mIGV4dGVuc2lvbiBoZWFkZXJzIHRoYXQgbmVlZCB0byBiZQo.Pj4gZnJhZ21lbnRlZCBbSS1ELmlldGYtNm1hbi1vdmVyc2l6ZWQtaGVhZGVyLWNoYWluXS4KPsKgCj4gScKgwqB3b25kZXIgaWYgdGhpcyBpcyB0aGUgcGxhY2UgdG8gZGVmaW5lICJ2ZXJ5IGxvbmciPwoKPj7CoEkgZ3Vlc3MgdGhvc2UgdHdvIHdvcmRzIGNhbiBiZSBkZWwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.144.546 References: <51AFC515.8010704@gmail.com> <1370492638.82480.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <51B01466.2050306@gmail.com> Message-ID: <1370528672.17932.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Thu, 6 Jun 2013 07:24:32 -0700 (PDT) From: Nalini Elkins Subject: Re: draft-ietf-6man-ext-transmit-01 To: Brian E Carpenter In-Reply-To: <51B01466.2050306@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-1290907730-1370528672=:17932" Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 14:25:02 -0000 ---1551098171-1290907730-1370528672=:17932 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >>> Some tricky and potentially malicious cases will be=A0avoided by forbid= ding=A0very long chains of extension headers that need to be=0A>>> fragment= ed [I-D.ietf-6man-oversized-header-chain].=0A>=A0=0A> I=A0=A0wonder if this= is the place to define "very long"?=0A=0A>>=A0I guess those two words can = be deleted - the issue is only that=A0the header chain gets fragmented at a= ll. The full discussion is=A0in the cited draft, of course.=0A=0A=0AI know = the draft that you have cited and they do not define "long" either. =A0Ther= e has been quite a bit of discussion about what "long" means and IMHO somew= here, someone needs to take some kind of reasonable stand.=A0=0A=0A=0A>>The= IETF hasn't done much about firewalls at all. This search=A0produces far m= ore expired drafts than anything else:=0A>>=A0https://datatracker.ietf.org/= doc/search/?name=3Dfirewalls&rfcs=3Don&activeDrafts=3Don&oldDrafts=3Don&sea= rch_submit=3D=0A=0AThe reason I asked is because I think defining RFCs or r= ules for firewalls is a really good thing to do but if the vendors are not = in the habit of having to be compliant, then why would they pay attention t= o this draft that we are discussing? =A0I actually think maybe an RFC which= explicitly talks about firewalls is probably a good thing to do. =A0Now, g= etting vendors to comply...=0A=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside = Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A_______= _________________________=0A From: Brian E Carpenter =0ATo: Nalini Elkins =0ACc: 6man = =0ASent: Wednesday, June 5, 2013 9:47 PM=0ASubject: Re: dra= ft-ietf-6man-ext-transmit-01=0A =0A=0AOn 06/06/2013 16:23, Nalini Elkins wr= ote:=0A> Brian,=0A> =0A> Two questions:=0A> =0A> First:=0A> =0A>>> Some tri= cky and potentially malicious cases will be=0A>>> avoided by forbidding=0A>= >> very long chains of extension headers that need to be=0A>>> fragmented [= I-D.ietf-6man-oversized-header-chain].=0A> =0A> I wonder if this is the pla= ce to define "very long"?=0A=0AI guess those two words can be deleted - the= issue is only that=0Athe header chain gets fragmented at all. The full dis= cussion is=0Ain the cited draft, of course.=0A=0A> =0A> Second:=0A> =0A> Ar= e there other RFCs which have rules for what "middle boxes"=0A> will do?=A0= I am not referring to translation techniques such=0A> as SIIT, etc. which= is implemented in some load balancers. I=0A> guess I am wondering more abo= ut if there is a precedent for=0A> regulating what packets firewalls will a= nd will not forward.=0A=0AThe IETF hasn't done much about firewalls at all.= This search=0Aproduces far more expired drafts than anything else:=0Ahttps= ://datatracker.ietf.org/doc/search/?name=3Dfirewalls&rfcs=3Don&activeDrafts= =3Don&oldDrafts=3Don&search_submit=3D=0A=0A=A0 Brian=0A=0A> =0A> BTW, than= ks so much for doing this!=0A> =0A> =0A> Thanks,=0A> =0A> =0A> Nalini Elkin= s Inside Products, Inc. (831) 659-8360 =0A> www.insidethestack.com ---1551098171-1290907730-1370528672=:17932 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    >>> Som= e tricky and potentially malicious cases will be avoided by forbidding very long chains of extension headers that need to be
    >>> fragmented [I-D.ietf-6man-oversized-header-chain].
    = > 
    > I 

    >> I guess those two words can be deleted - the issue is only that=  the header chain gets fra= gmented at all. The full discussion is in the cited draft, of course.
    <= div style=3D"color: rgb(69, 69, 69); font-size: 12px; font-family: 'Helveti= ca Neue', Helvetica, Arial, sans-serif; background-color: transparent; font-s= tyle: normal;">


    >>= ;The IETF hasn't done much about firewalls at all. This search = produces far more expired drafts than= anything else:
    >> https://dat= atracker.ietf.org/doc/search/?name=3Dfirewalls&rfcs=3Don&activeDraf= ts=3Don&oldDrafts=3Don&search_submit=3D

    The reason I asked is because I think defining RFCs or rules= for firewalls is a really good thing to do but if the vendors are not in t= he habit of having to be compliant, then why would they pay attention to th= is draft that we are discussing?  I actually think maybe an RFC which = explicitly talks about firewalls is probably a good thing to do.  Now,= getting vendors to comply...
     
    Thanks,=

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

    From: Brian E Carpenter <brian.e.carpenter@gmail.com&= gt;
    To: Nalini Elkins <nal= ini.elkins@insidethestack.com>
    Cc: 6man <ipv6@ietf.org>
    Sent: Wednesday, June 5, 2013 9:47 PM
    Subject: Re: draft-ietf-6man-ext-tran= smit-01

    =0AOn 06/06/2= 013 16:23, Nalini Elkins wrote:
    > Brian,
    >
    > Two questio= ns:
    >
    > First:
    >
    >>> Some tricky and potent= ially malicious cases will be
    >>> avoided by forbidding
    >= >> very long chains of extension headers that need to be
    >>&= gt; fragmented [I-D.ietf-6man-oversized-header-chain].
    >
    > I w= onder if this is the place to define "very long"?

    I guess those two = words can be deleted - the issue is only that
    the header chain gets frag= mented at all. The full discussion is
    in the cited draft, of course.
    =
    >
    > Second:
    >
    > Are there other RFCs which have = rules for what "middle boxes"
    > will do?  I am not referring to= translation techniques such
    > as SIIT, etc. which is implemented in = some load balancers. I
    > guess I am wondering more about if there is = a precedent for
    > regulating what packets firewalls will and will not forward.

    The IETF hasn't done much about firewall= s at all. This search
    produces far more expired drafts than anything els= e:
    https://datatracker.ietf.org/doc/search/?name=3Dfirewal= ls&rfcs=3Don&activeDrafts=3Don&oldDrafts=3Don&search_submit= =3D

      Brian

    >
    > BTW, thanks so much for d= oing this!
    >
    >
    > Thanks,
    >
    >
    > Nali= ni Elkins Inside Products, Inc. (831) 659-8360
    > www.insidethestack.com

    ---1551098171-1290907730-1370528672=:17932-- From acooper@cdt.org Wed Jun 5 15:24:41 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6535C21F8FE5 for ; Wed, 5 Jun 2013 15:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+xMpmlKvrGk for ; Wed, 5 Jun 2013 15:24:35 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 83C3B21E804C for <6man@ietf.org>; Wed, 5 Jun 2013 15:24:32 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Wed, 5 Jun 2013 18:24:02 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Comments on draft-ietf-6man-stable-privacy-addresses-07 From: Alissa Cooper In-Reply-To: <51A93EEE.7080902@gont.com.ar> Date: Wed, 5 Jun 2013 18:24:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6AD05DBB-1067-4F4D-996C-CAB7FEF0184F@cdt.org> References: <72fb5db097d443eebb554cdc43d7a01f@BY2PR03MB269.namprd03.prod.outlook.com> <519AD0EF.60600@si6networks.com> <87b8552e4b4a479dbfca94bd88a09ce7@BY2PR03MB269.namprd03.prod.outlook.com> <519F3364.80301@si6networks.com> <51A207B0.4000900@si6networks.com> <51A93EEE.7080902@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Thu, 06 Jun 2013 08:26:30 -0700 Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Brian Haberman , "6man@ietf.org" <6man@ietf.org>, Dave Thaler , Ray Hunter , Christian Huitema , "tom.petch" , Fernando Gont , He Xuan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 22:24:42 -0000 I'll try to re-state one of my questions more simply, based on the -09: How is the attack explained in C.4 mitigated by the mechanism specified = in draft-ietf-6man-stable-privacy-addresses-09? One more comment below: On May 31, 2013, at 8:23 PM, Fernando Gont wrote: >> Another point for clarification: >>=20 >> On the other hand, in scenarios in which "temporary addresses" are >> employed together with stable addresses such as those based on IEEE=20= >> identifiers, implementation of the mechanism described in this=20 >> document would mitigate address-scanning attacks and also mitigate=20 >> some vectors for correlating host activities that are not mitigated=20= >> by the use of temporary addresses. >>=20 >> Which correlation attack vectors do random-per-network addresses >> mitigate that temporary addresses do not?=20 >=20 > See appendix B of drat-ietf-6man-stable-privacy-addresses. >=20 I see the above-quoted text has been updated to the following: In scenarios in which "temporary addresses" are employed, implementation of the mechanism described in this document (in replacement of stable addresses based on e.g. IEEE identifiers) would mitigate address- scanning attacks and also mitigate the remaining vectors for correlating host activities based on the node's IPv6 addresses. What "the remaining vectors for correlating host activities based on the = node's IPv6 addresses" actually means is "the remaining vectors for correlating host activities across networks based on the node's = stable IPv6 address," correct? Thanks, Alissa From niall.oreilly@ucd.ie Thu Jun 6 02:10:56 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF7121F96DE for ; Thu, 6 Jun 2013 02:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUEEE-Apwb5S for ; Thu, 6 Jun 2013 02:10:55 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD5F21F96FE for ; Thu, 6 Jun 2013 02:10:51 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w59so1819682wes.38 for ; Thu, 06 Jun 2013 02:10:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Ui6n2/Yzb2sGozfGRuyaFkasxGsQZz9K1VHl9tpBk8o=; b=MIPTodDJHm9orRrD1ot6HNzpOk5bpQpbC+wyGTy6yelN6tkw90Y7asjdRKPLoZO6NP Z4UMODE32I2pDewSxtObJZ/kUmAav1jdVApTlnqabl/PsmE6TNgvZ2wRyB7ffg3y8BV6 Flh99Xj0JAuxRm/fjaHi0xl8aaR4PFEuxXonrfeh6cYHGZxPUEkTkNpZohT10czOHvFy MDt8oevKU4lItko7aYhjzbXApfBOpK4Atig31arMKTNeOvv+vONsSXyRabApLpKdOJPs x3NlOXCdeR/sT5UlbHa1tFLeITMFBYUzmQe78bSGhTJCYcFfbZhjUGYYqqIXuhL84zwG WFTw== X-Received: by 10.194.176.71 with SMTP id cg7mr31584594wjc.18.1370509850794; Thu, 06 Jun 2013 02:10:50 -0700 (PDT) Received: from dhcp-c101a88b.ucd.ie (dhcp-c101a88b.ucd.ie. [193.1.168.139]) by mx.google.com with ESMTPSA id cw8sm14328058wib.7.2013.06.06.02.10.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Jun 2013 02:10:49 -0700 (PDT) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: "Niall O'Reilly" In-Reply-To: Date: Thu, 6 Jun 2013 10:10:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D23D4052ABE7A4490E77B1A012B6307751C4E3E@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C4F11@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C554C@mbx-01.win.nominum.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmcwDgieXz9JJP2lSc5mF5WfGKxe5jZUK8YItjykvdm5Jgh0IofdShIt1xZ9+do9Bbbz1TE X-Mailman-Approved-At: Thu, 06 Jun 2013 08:26:30 -0700 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Ted Lemon , Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 09:10:56 -0000 On 6 Jun 2013, at 04:26, Lorenzo Colitti wrote: > indeed, the letter of the policy above suggests that a /48 is = acceptable only in the case of "extra large end sites" How do you read that into the extract you cited, Lorenzo? Niall O'Reilly From acooper@cdt.org Thu Jun 6 06:40:59 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871C621F9017 for ; Thu, 6 Jun 2013 06:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH5CiPBocgVk for ; Thu, 6 Jun 2013 06:40:54 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 45F5121F8EB1 for <6man@ietf.org>; Thu, 6 Jun 2013 06:40:54 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 6 Jun 2013 09:40:25 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Comments on draft-ietf-6man-stable-privacy-addresses-07 From: Alissa Cooper In-Reply-To: <51AFE3AF.1050300@si6networks.com> Date: Thu, 6 Jun 2013 09:40:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <72fb5db097d443eebb554cdc43d7a01f@BY2PR03MB269.namprd03.prod.outlook.com> <519AD0EF.60600@si6networks.com> <87b8552e4b4a479dbfca94bd88a09ce7@BY2PR03MB269.namprd03.prod.outlook.com> <519F3364.80301@si6networks.com> <51A207B0.4000900@si6networks.com> <51A93EEE.7080902@gont.com.ar> <6AD05DBB-1067-4F4D-996C-CAB7FEF0184F@cdt.org> <51AFE3AF.1050300@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Thu, 06 Jun 2013 08:26:30 -0700 Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Brian Haberman , "6man@ietf.org" <6man@ietf.org>, Dave Thaler , Ray Hunter , Fernando Gont , "tom.petch" , Christian Huitema , He Xuan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 13:40:59 -0000 Hi Fernando, On Jun 5, 2013, at 9:19 PM, Fernando Gont wrote: > On 06/06/2013 12:24 AM, Alissa Cooper wrote: >> I'll try to re-state one of my questions more simply, based on the >> -09: >>=20 >> How is the attack explained in C.4 mitigated by the mechanism >> specified in draft-ietf-6man-stable-privacy-addresses-09? >=20 > It doesn't. Good, that confirms what I thought. > For instance, Section B.1 explicitly says so (and this type > of attack is not meant to be solved by stable-privacy-addresses). >=20 > In some scenarios, it can be mitigated with RFC 4941. Hoawever, as = noted > in Section C.4, even ith RFC4941 there are scenarios n which yu cannot > do much about it. >=20 Maybe it's just an organizational thing that makes me feel like this = isn't clear -- in B.1 it says "However, as noted earlier in this = document, in scenarios in which there is a reduced number of nodes =85" = but really that scenario is not discussed until later in the document = (C.4). Then appendix C says that "It aims to clarify the motivation of = employing the method specified in this document," but ends with the = attack described in C.4, which is not mitigated by the mechanism = specified in the document. I realize how this organization came about = but it seems like it would make a little more sense to have each of the = distinct threat models clearly described in one place in the body of the = document, followed by a discussion of which threats the mechanism = mitigates and which it does not. >=20 >=20 >>>> Which correlation attack vectors do random-per-network addresses=20 >>>> mitigate that temporary addresses do not? >>>=20 >>> See appendix B of drat-ietf-6man-stable-privacy-addresses. >>=20 >> I see the above-quoted text has been updated to the following: >>=20 >> In scenarios in which "temporary addresses" are employed, >> implementation of the mechanism described in this document (in >> replacement of stable addresses based on e.g. IEEE identifiers) >> would mitigate address- scanning attacks and also mitigate the >> remaining vectors for correlating host activities based on the node's >> IPv6 addresses. >>=20 >> What "the remaining vectors for correlating host activities based on >> the node's IPv6 addresses" actually means is "the remaining vectors >> for correlating host activities across networks based on the node's >> stable IPv6 address," correct? >=20 > Yes. If you think it'd be better to phrase it that way, I can update = the > text accordingly. >=20 Please do. Thanks, Alissa > Thanks! >=20 > Best regards, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 >=20 From v6ops@globis.net Thu Jun 6 08:33:13 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9B021F99D1 for ; Thu, 6 Jun 2013 08:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92yvL0zuVJtp for ; Thu, 6 Jun 2013 08:33:12 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5D75421F99CD for ; Thu, 6 Jun 2013 08:33:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 5C7D58700DF; Thu, 6 Jun 2013 17:32:56 +0200 (CEST) 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 cpi3CZhed8JP; Thu, 6 Jun 2013 17:32:56 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 173BE8700BD; Thu, 6 Jun 2013 17:32:56 +0200 (CEST) Message-ID: <51B0ABA2.2030007@globis.net> Date: Thu, 06 Jun 2013 17:32:50 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: draft-ietf-6man-ext-transmit-01 References: <51AFC515.8010704@gmail.com> In-Reply-To: <51AFC515.8010704@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 15:33:13 -0000 I can confirm that the 01 version does address all of my comments, and I now support. Thanks, RayH Brian E Carpenter wrote: > If you're following the current discussion on v6ops, it > seems that we need to decide whether to proceed with the > subject draft, so that there is at least a marker for what > forwarding nodes are supposed to do about extension headers. > > So, are there any more comments on the draft? > > Brian > >> Hi, >> >> This version is intended to respond to Ray Hunter's comments. >> There are two important changes: >> >> 1. The MUST NOT that Ray mentioned is now SHOULD NOT. Really >> this is a matter of internal consistency in the document, since >> the exceptions to the SHOULD NOT are specified, so the MUST NOT >> was inappropriate. >> >> 2. It is now made explicit that only standards-track extension >> headers are covered. That knocks out HIP, which is Experimental. >> >> There are a few other changes of editorial nature. >> >> Brian + Sheng >> >> -------- Original Message -------- >> Subject: I-D Action: draft-ietf-6man-ext-transmit-01.txt >> Date: Wed, 29 May 2013 13:21:08 -0700 >> From: internet-drafts at ietf.org >> To: i-d-announce at ietf.org >> CC: ipv6 at ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the IPv6 Maintenance Working Group of the IETF. >> >> Title : Transmission of IPv6 Extension Headers >> Author(s) : Brian Carpenter >> Sheng Jiang >> Filename : draft-ietf-6man-ext-transmit-01.txt >> Pages : 9 >> Date : 2013-05-29 >> >> Abstract: >> Various IPv6 extension headers have been standardised since the IPv6 >> standard was first published. This document updates RFC 2460 to >> clarify how intermediate nodes should deal with such extension >> headers and with any that are defined in future. It also specifies >> how extension headers should be registered by IANA, with a >> corresponding minor update to RFC 2780. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-6man-ext-transmit >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-6man-ext-transmit-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ext-transmit-01 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ > > > From v6ops@globis.net Thu Jun 6 09:15:23 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF26921F9936 for ; Thu, 6 Jun 2013 09:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD6Qppfj2Hgk for ; Thu, 6 Jun 2013 09:15:19 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4C99121F9A17 for ; Thu, 6 Jun 2013 09:15:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 8383E8700DF; Thu, 6 Jun 2013 18:15:03 +0200 (CEST) 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 fYG7hPxxVEeL; Thu, 6 Jun 2013 18:15:03 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 3ECC68700BD; Thu, 6 Jun 2013 18:15:03 +0200 (CEST) Message-ID: <51B0B581.7020203@globis.net> Date: Thu, 06 Jun 2013 18:14:57 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Nalini Elkins Subject: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: vishwas.manral@hp.com, Fernando Gont , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 16:15:23 -0000 Nalini Elkins wrote: > >>> Some tricky and potentially malicious cases will be avoided by > forbidding very long chains of extension headers that need to be > >>> fragmented [I-D.ietf-6man-oversized-header-chain]. > > > > I wonder if this is the place to define "very long"? > > >> I guess those two words can be deleted - the issue is only that the > header chain gets fragmented at all. The full discussion is in the > cited draft, of course. > > I know the draft that you have cited and they do not define "long" > either. There has been quite a bit of discussion about what "long" > means and IMHO somewhere, someone needs to take some kind of > reasonable stand. > Actually IMHO ietf-6man-oversized-header-chain DOES define "unusually long" very accurately. I-D.ietf-6man-oversized-header-chain requires that "the first fragment of a fragmented datagram is required to contain the entire IPv6 header chain" So in other words, any packet parsing engine should be prepared to examine an entire single frame up to the MTU of the local egress interface, but should not be expected to maintain any state across multiple fragments. We might also benefit operationally from setting an additional limit on the length of the hop hop option header, which is theoretically meant to be processed by routers along the path. However, my guess is that is well beyond the author's original intentions for draft-ietf-6man-oversized-header-chain-02, which was more focussed on firewalls. > > >>The IETF hasn't done much about firewalls at all. This > search produces far more expired drafts than anything else: > >> https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit= > > > The reason I asked is because I think defining RFCs or rules for > firewalls is a really good thing to do but if the vendors are not in > the habit of having to be compliant, then why would they pay attention > to this draft that we are discussing? I actually think maybe an RFC > which explicitly talks about firewalls is probably a good thing to do. > Now, getting vendors to comply... > > Thanks, > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > From nalini.elkins@insidethestack.com Thu Jun 6 09:20:57 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0FB21F92C5 for ; Thu, 6 Jun 2013 09:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5GT9Gk0gElh for ; Thu, 6 Jun 2013 09:20:51 -0700 (PDT) Received: from nm13.access.bullet.mail.mud.yahoo.com (nm13.access.bullet.mail.mud.yahoo.com [66.94.237.214]) by ietfa.amsl.com (Postfix) with ESMTP id 5A57C21F9298 for ; Thu, 6 Jun 2013 09:20:51 -0700 (PDT) Received: from [66.94.237.196] by nm13.access.bullet.mail.mud.yahoo.com with NNFMP; 06 Jun 2013 16:20:50 -0000 Received: from [66.94.237.116] by tm7.access.bullet.mail.mud.yahoo.com with NNFMP; 06 Jun 2013 16:20:50 -0000 Received: from [127.0.0.1] by omp1021.access.mail.mud.yahoo.com with NNFMP; 06 Jun 2013 16:20:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 566447.74734.bm@omp1021.access.mail.mud.yahoo.com Received: (qmail 98801 invoked by uid 60001); 6 Jun 2013 16:20:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370535650; bh=uFK2g8nY+G4/f7XcgnEsMx6IiQjuJmsClhewRBMN9T4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HolDG0FwBVHqjZbrE6yhE1Ykq6/cq4jqoAF91cFDycOIvyTx5UOUrbkmlA3kAjD26AGgwRpukGTHGcN6dBwHzUY/faKAkbSrnwDzIi3WoHn6EegayyKDOVeKYyzn8h3CwvFzyVSzxSTOe1BjyqF9lqS+l9mzbNZf6lDhXRuETQw= X-YMail-OSG: xxNH_9oVM1mSqDvI7KOLfG4PYVu_A9cnavwYbXaIvJWokoa QV2lqomZ1F2x3RDPUQ9KMqBRqUvBZQ1TGF5zkR3lLmvv4Q4lar0rq4fI8eD4 EOcaQtVw9pLgp6NEFTc.yk5c83aJJCMyB.RfWKyj37ReAfGjq_rFuhJ2VC4Y m11BoGuM9xacvoHc7D_h.Ods39pKmOz5oMcorpOLq7bCHt3D_38t6_Z7gPOf RR8ytzlh.yOlxc5.SGXFucGF2bgz9aah6YQTp3LrlV.C6gEdDRwC2JnIS56T vCttSepieDREKSPXs413TJbYXcNG.JZimvS.jINMkoUWYIE0sCnFmPXJj85k TKPeQo.Aa1caIuMQRKTtTATQoOpoFXNeyi67X1N2.zYJQy2WR2vQPQSov2SF CUeFpBwoBgD9rNQesUeFQsR9grK398tlykxGVsLVJbu2GgEMhJuqtqKXdiKQ _j22ktPL5pZRnHNYLyULMyl7eNQ4EWvXSBAr9CQyVBjUXrs9gKki8U34aNGr yOO78At6C0eokiBY2ZYwTzZAXYudwcyD.A6WZ8_eFfh5JERoE6qZFZn1CC_W NdeVue25cMz0B7HhzvqASFkB50McFNcDhHPR4GynhV90vRxFUbvElfcY2Rov CBCwKEgRvVpEFoEmsDr4XV4U- Received: from [24.130.37.147] by web2805.biz.mail.ne1.yahoo.com via HTTP; Thu, 06 Jun 2013 09:20:49 PDT X-Rocket-MIMEInfo: 002.001, U28sIGlmIHdlIGFyZSB0YWxraW5nIGFib3V0IHRoZSBNVFUgb2YgdGhlIGxvY2FsIGVncmVzc8KgaW50ZXJmYWNlLCB0aGVuIHNpbmNlLCBJIGJlbGlldmUsIHRoZSBtaW5pbXVtIE1UVSBzaXplIGZvciBJUHY2IGlzIDEsMjgwLCB0aGVuIGFsbCBkZXZpY2VzIHNob3VsZCBiZSBwcmVwYXJlZCB0byBleGFtaW5lIHVwIHRvIDEsMjgwIGJ5dGVzIHRvIGdldCB0aGUgTDQgaGVhZGVyPwoKwqAKVGhhbmtzLAoKCk5hbGluaSBFbGtpbnMKSW5zaWRlIFByb2R1Y3RzLCBJbmMuCig4MzEpIDY1OS04MzYwCnd3dy5pbnMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.144.546 References: <51B0B581.7020203@globis.net> Message-ID: <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Thu, 6 Jun 2013 09:20:49 -0700 (PDT) From: Nalini Elkins Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) To: Ray Hunter In-Reply-To: <51B0B581.7020203@globis.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1619178251-639216433-1370535649=:98609" Cc: "vishwas.manral@hp.com" , Fernando Gont , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 16:20:57 -0000 --1619178251-639216433-1370535649=:98609 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable So, if we are talking about the MTU of the local egress=A0interface, then s= ince, I believe, the minimum MTU size for IPv6 is 1,280, then all devices s= hould be prepared to examine up to 1,280 bytes to get the L4 header?=0A=0A= =A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-836= 0=0Awww.insidethestack.com=0A=0A=0A=0A________________________________=0A F= rom: Ray Hunter =0ATo: Nalini Elkins =0ACc: Brian E Carpenter ; 6man= ; Fernando Gont ; vishwas.manral@hp.= com =0ASent: Thursday, June 6, 2013 9:14 AM=0ASubject: draft-ietf-6man-over= sized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01)=0A =0A= =0ANalini Elkins wrote:=0A> >>> Some tricky and potentially malicious cases= will be avoided by=0A> forbidding very long chains of extension headers th= at need to be=0A> >>> fragmented [I-D.ietf-6man-oversized-header-chain].=0A= > > =0A> > I=A0 wonder if this is the place to define "very long"?=0A>=0A> = >> I guess those two words can be deleted - the issue is only that the=0A> = header chain gets fragmented at all. The full discussion is in the=0A> cite= d draft, of course.=0A>=0A> I know the draft that you have cited and they d= o not define "long"=0A> either.=A0 There has been quite a bit of discussion= about what "long"=0A> means and IMHO somewhere, someone needs to take some= kind of=0A> reasonable stand. =0A>=0AActually IMHO ietf-6man-oversized-hea= der-chain DOES define "unusually=0Along" very accurately.=0A=0AI-D.ietf-6ma= n-oversized-header-chain requires that "the first fragment=0Aof a fragmente= d datagram is required to contain the entire IPv6 header=0Achain"=0A=0ASo i= n other words, any packet parsing engine should be prepared to=0Aexamine an= entire single frame up to the MTU of the local egress=0Ainterface, but sho= uld not be expected to maintain any state across=0Amultiple fragments.=0A= =0AWe might also benefit operationally from setting an additional limit on= =0Athe length of the hop hop option header, which is theoretically meant to= =0Abe processed by routers along the path. However, my guess is that is=0Aw= ell beyond the author's original intentions for=0Adraft-ietf-6man-oversized= -header-chain-02, which was more focussed on=0Afirewalls.=0A=0A>=0A> >>The = IETF hasn't done much about firewalls at all. This=0A> search produces far = more expired drafts than anything else:=0A> >> https://datatracker.ietf.org= /doc/search/?name=3Dfirewalls&rfcs=3Don&activeDrafts=3Don&oldDrafts=3Don&se= arch_submit=3D=0A> =0A>=0A> The= reason I asked is because I think defining RFCs or rules for=0A> firewalls= is a really good thing to do but if the vendors are not in=0A> the habit o= f having to be compliant, then why would they pay attention=0A> to this dra= ft that we are discussing?=A0 I actually think maybe an RFC=0A> which expli= citly talks about firewalls is probably a good thing to do.=0A>=A0 Now, get= ting vendors to comply...=0A>=A0 =0A> Thanks,=0A>=0A> Nalini Elkins=0A> Ins= ide Products, Inc.=0A> (831) 659-8360=0A> www.insidethestack.com=0A> --1619178251-639216433-1370535649=:98609 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    So, if we are talking about the MTU of the local egre= ss interface, then s= ince, I believe, the minimum MTU size for IPv6 is 1,280, then all devices s= hould be prepared to examine up to 1,280 bytes to get the L4 header?=
     
    Thanks,

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

    From: Ray Hunter <v6ops@globis.net>
    To: Nalini Elkins <nalini.elkins@insidethestack.com= >
    Cc: Brian E Carpe= nter <brian.e.carpenter@gmail.com>; 6man <ipv6@ietf.org>; Ferna= ndo Gont <fgont@si6networks.com>; vishwas.manral@hp.com
    Sent: Thursday, June 6, 2013 9:14 = AM
    Subject: draft-ietf= -6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-0= 1)

    =0ANalini Elkins w= rote:
    > >>> Some tricky and potentially malicious cases will= be avoided by
    > forbidding very long chains of extension headers tha= t need to be
    > >>> fragmented [I-D.ietf-6man-oversized-heade= r-chain].
    > >
    > > I  wonder if this is the place to= define "very long"?
    >
    > >> I guess those two words can b= e deleted - the issue is only that the
    > header chain gets fragmented= at all. The full discussion is in the
    > cited draft, of course.
    &= gt;
    > I know the draft that you have cited and they do not define "lo= ng"
    > either.  There has been quite a bit of discussion about wh= at "long"
    > means and IMHO somewhere, someone needs to take some kind= of
    > reasonable stand.
    >
    Actually IMHO ietf-6man-oversized= -header-chain DOES define "unusually
    long" very accurately.

    I-D.i= etf-6man-oversized-header-chain requires that "the first fragment
    of a fragmented datagram is required to contain the enti= re IPv6 header
    chain"

    So in other words, any packet parsing engin= e should be prepared to
    examine an entire single frame up to the MTU of = the local egress
    interface, but should not be expected to maintain any s= tate across
    multiple fragments.

    We might also benefit operational= ly from setting an additional limit on
    the length of the hop hop option = header, which is theoretically meant to
    be processed by routers along th= e path. However, my guess is that is
    well beyond the author's original i= ntentions for
    draft-ietf-6man-oversized-header-chain-02, which was more = focussed on
    firewalls.

    >
    > >>The IETF hasn't done = much about firewalls at all. This
    > search produces far more expired = drafts than anything else:
    > >> https://datatracker.ietf.org/doc/search/?name=3Dfirewalls&r= fcs=3Don&activeDrafts=3Don&oldDrafts=3Don&search_submit=3D<= br>> <https://datatracker.ietf.org/doc/search/?name=3Df= irewalls&rfcs=3Don&activeDrafts=3Don&oldDrafts=3Don&search_= submit=3D>
    >
    > The reason I asked is because I think def= ining RFCs or rules for
    > firewalls is a really good thing to do but = if the vendors are not in
    > the habit of having to be compliant, then= why would they pay attention
    > to this draft that we are discussing?=   I actually think maybe an RFC
    > which explicitly talks about f= irewalls is probably a good thing to do.
    >  Now, getting vendors to comply...
    > 
    >= Thanks,
    >
    > Nalini Elkins
    > Inside Products, Inc.
    >= ; (831) 659-8360
    > www.insidethestack.com
    >



    =
    --1619178251-639216433-1370535649=:98609-- From Ted.Lemon@nominum.com Thu Jun 6 09:34:14 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BD521F9371; Thu, 6 Jun 2013 09:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.798 X-Spam-Level: X-Spam-Status: No, score=-106.798 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaBOqER+HteV; Thu, 6 Jun 2013 09:34:07 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6250121F93D4; Thu, 6 Jun 2013 09:34:07 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUbC5/renDEArFijdBzf0NpyWShT3SqNC@postini.com; Thu, 06 Jun 2013 09:34:07 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 086D01B81DA; Thu, 6 Jun 2013 09:34:06 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id F18F619005D; Thu, 6 Jun 2013 09:34:05 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 09:34:06 -0700 From: Ted Lemon To: Lorenzo Colitti Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAFFqgIAAA0MAgAAlngCAAERTAIAAmIuAgAAWAQCAALv5gIAAMI2AgACc9YCAACD6gIAAH1gAgACZeoCAAAjegIAAwruAgAAV84CAAAZKgIAAAigAgAC9mQCAAIcfgIAABCCAgAAX6ICAAAXdAIAABfgAgAADgICAAChsAA== Date: Thu, 6 Jun 2013 16:34:04 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C7C95@mbx-01.win.nominum.com> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C73E5@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C75A3@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C7C95mbx01winnominum_" MIME-Version: 1.0 Cc: "ipv6@ietf.org 6man-wg" , "v6ops@ietf.org WG" , "" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 16:34:14 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C7C95mbx01winnominum_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jun 6, 2013, at 10:09 AM, Lorenzo Colitti > wrote: Start by saying how the statement I point to as justification does not, in = fact, mean what I say, and why it does not? The text doesn't say that ARIN won't allocate bits for semantic prefixes. = It doesn't even mention semantic prefixes (which, frankly, isn't surprisin= g). It does say that you need to document what you want to do if you want= more than one /48 per customer, but that's not the same as saying that you= won't get the bits you want. It's certainly *possible* that ARIN will de= ny a request on the basis that you are wasting bits on semantic prefixes, b= ut the text you quoted DOES NOT SAY THAT. --_000_8D23D4052ABE7A4490E77B1A012B6307751C7C95mbx01winnominum_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <5C621BD21B17F3478CD2E7199AE025CB@nominum.com> Content-Transfer-Encoding: quoted-printable
    On Jun 6, 2013, at 10:09 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
    Start by saying how the statement I point to as justification does not, in fact,= mean what I say, and why it does not?

    The text doesn't say that ARIN won't allocate bits for semantic prefix= es.   It doesn't even mention semantic prefixes (which, frankly, isn't= surprising).   It does say that you need to document what you want to= do if you want more than one /48 per customer, but that's not the same as saying that you won't get the bits you want. &n= bsp; It's certainly *possible* that ARIN will deny a request on the basis t= hat you are wasting bits on semantic prefixes, but the text you quoted DOES= NOT SAY THAT.

    --_000_8D23D4052ABE7A4490E77B1A012B6307751C7C95mbx01winnominum_-- From v6ops@globis.net Thu Jun 6 09:42:46 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF56C21F99E3 for ; Thu, 6 Jun 2013 09:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQ-3sd9k6BhQ for ; Thu, 6 Jun 2013 09:42:41 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6992521F99C3 for ; Thu, 6 Jun 2013 09:42:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 7A1A4870077; Thu, 6 Jun 2013 18:42:25 +0200 (CEST) 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 DhveUxe2sjPa; Thu, 6 Jun 2013 18:42:25 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id BA334870047; Thu, 6 Jun 2013 18:42:24 +0200 (CEST) Message-ID: <51B0BBEA.4080105@globis.net> Date: Thu, 06 Jun 2013 18:42:18 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Nalini Elkins Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> In-Reply-To: <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "vishwas.manral@hp.com" , Fernando Gont , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 16:42:46 -0000 IMVHO interpreting the text of the current drafts. > Nalini Elkins > 6 June 2013 18:20 > So, if we are talking about the MTU of the local egress interface, > then since, I believe, the minimum MTU size for IPv6 is 1,280, then > all devices should be prepared to examine up to 1,280 bytes to get the > L4 header? Not quite. AFAICS 1. All parsing engines should be able to parse at least 1280 bytes to cover the minimum IPv6 MTU. 2. If all the local interfaces are Ethernet, and have an MTU set of 1500, the parsing engine on that box should be able to parse a full Ethernet frame of 1500 bytes of payload..... and so on for devices supporting links with larger MTUs, all the way up to jumbograms (if supported on that device). 3. draft-ietf-6man-ext-transmit gives the option of not parsing extension headers at all on high speed routers (only the hop by hop option is supposed to be parsed by routers on the path). But neither this draft, nor any other IETF draft that I know of, gives an option for parsing an IPv6 header chain "just for the first n bytes", where n is an arbitrary number picked out of the air by a vendor, whether that be 53, 256 or 1280. regards, RayH > > Thanks, > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > ------------------------------------------------------------------------ > *From:* Ray Hunter > *To:* Nalini Elkins > *Cc:* Brian E Carpenter ; 6man > ; Fernando Gont ; > vishwas.manral@hp.com > *Sent:* Thursday, June 6, 2013 9:14 AM > *Subject:* draft-ietf-6man-oversized-header-chain-02 (was Re: Re: > draft-ietf-6man-ext-transmit-01) > > Nalini Elkins wrote: > > >>> Some tricky and potentially malicious cases will be avoided by > > forbidding very long chains of extension headers that need to be > > >>> fragmented [I-D.ietf-6man-oversized-header-chain]. > > > > > > I wonder if this is the place to define "very long"? > > > > >> I guess those two words can be deleted - the issue is only that the > > header chain gets fragmented at all. The full discussion is in the > > cited draft, of course. > > > > I know the draft that you have cited and they do not define "long" > > either. There has been quite a bit of discussion about what "long" > > means and IMHO somewhere, someone needs to take some kind of > > reasonable stand. > > > Actually IMHO ietf-6man-oversized-header-chain DOES define "unusually > long" very accurately. > > I-D.ietf-6man-oversized-header-chain requires that "the first fragment > of a fragmented datagram is required to contain the entire IPv6 header > chain" > > So in other words, any packet parsing engine should be prepared to > examine an entire single frame up to the MTU of the local egress > interface, but should not be expected to maintain any state across > multiple fragments. > > We might also benefit operationally from setting an additional limit on > the length of the hop hop option header, which is theoretically meant to > be processed by routers along the path. However, my guess is that is > well beyond the author's original intentions for > draft-ietf-6man-oversized-header-chain-02, which was more focussed on > firewalls. > > > > > >>The IETF hasn't done much about firewalls at all. This > > search produces far more expired drafts than anything else: > > >> > https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit= > > > > > > > > > The reason I asked is because I think defining RFCs or rules for > > firewalls is a really good thing to do but if the vendors are not in > > the habit of having to be compliant, then why would they pay attention > > to this draft that we are discussing? I actually think maybe an RFC > > which explicitly talks about firewalls is probably a good thing to do. > > Now, getting vendors to comply... > > > > Thanks, > > > > Nalini Elkins > > Inside Products, Inc. > > (831) 659-8360 > > www.insidethestack.com > > > > > > Ray Hunter > 6 June 2013 18:14 > Nalini Elkins wrote: >>>>> Some tricky and potentially malicious cases will be avoided by >> forbidding very long chains of extension headers that need to be >>>>> fragmented [I-D.ietf-6man-oversized-header-chain]. >>> I wonder if this is the place to define "very long"? >>>> I guess those two words can be deleted - the issue is only that the >> header chain gets fragmented at all. The full discussion is in the >> cited draft, of course. >> >> I know the draft that you have cited and they do not define "long" >> either. There has been quite a bit of discussion about what "long" >> means and IMHO somewhere, someone needs to take some kind of >> reasonable stand. >> > Actually IMHO ietf-6man-oversized-header-chain DOES define "unusually > long" very accurately. > > I-D.ietf-6man-oversized-header-chain requires that "the first fragment > of a fragmented datagram is required to contain the entire IPv6 header > chain" > > So in other words, any packet parsing engine should be prepared to > examine an entire single frame up to the MTU of the local egress > interface, but should not be expected to maintain any state across > multiple fragments. > > We might also benefit operationally from setting an additional limit on > the length of the hop hop option header, which is theoretically meant to > be processed by routers along the path. However, my guess is that is > well beyond the author's original intentions for > draft-ietf-6man-oversized-header-chain-02, which was more focussed on > firewalls. > >>>> The IETF hasn't done much about firewalls at all. This >> search produces far more expired drafts than anything else: >>>> https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit= >> >> >> The reason I asked is because I think defining RFCs or rules for >> firewalls is a really good thing to do but if the vendors are not in >> the habit of having to be compliant, then why would they pay attention >> to this draft that we are discussing? I actually think maybe an RFC >> which explicitly talks about firewalls is probably a good thing to do. >> Now, getting vendors to comply... >> >> Thanks, >> >> Nalini Elkins >> Inside Products, Inc. >> (831) 659-8360 >> www.insidethestack.com >> > > ------------------------------------------------------------------------ From nalini.elkins@insidethestack.com Thu Jun 6 09:46:26 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD5B21F99C3 for ; Thu, 6 Jun 2013 09:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 287eJ95VRJhS for ; Thu, 6 Jun 2013 09:46:20 -0700 (PDT) Received: from nm5-vm0.access.bullet.mail.mud.yahoo.com (nm5-vm0.access.bullet.mail.mud.yahoo.com [66.94.237.155]) by ietfa.amsl.com (Postfix) with ESMTP id 58C8821F9640 for ; Thu, 6 Jun 2013 09:46:20 -0700 (PDT) Received: from [66.94.237.127] by nm5.access.bullet.mail.mud.yahoo.com with NNFMP; 06 Jun 2013 16:46:19 -0000 Received: from [66.94.237.119] by tm2.access.bullet.mail.mud.yahoo.com with NNFMP; 06 Jun 2013 16:46:19 -0000 Received: from [127.0.0.1] by omp1024.access.mail.mud.yahoo.com with NNFMP; 06 Jun 2013 16:46:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 444699.81047.bm@omp1024.access.mail.mud.yahoo.com Received: (qmail 20155 invoked by uid 60001); 6 Jun 2013 16:46:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370537178; bh=tqddB7FJa/0i5N7zBzaqYbRFQZW28j29tTrzRYmTcSY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=skTZHtDvY5psBolmc17t/8Z7AntFjOqBykDeP5XyckZ8Nw/EwOvDoUK+WFxq62RgwkKtrwtBqXbPifFvRYRZThgbVLgaq2kw8Af6r4Chzw4x/w0j6GcJouFQkP2N8mEnk+DPlo+soxp1E+b13oTrArjf+9t/452ODXxfuebiIh8= X-YMail-OSG: uCxHz9EVM1msFy_5INqYjBJ9.T9aosdj_z_j0VP356KXqnb dBQDfdYn_HuwLGuMLQn5Vk6fnEb3iLFLlBVmqIfYy9yViQ1.pFv6hekzQIrK hmgGatA7saCEP3nhTyU3f9FWR1xFJIpAAgUreOrbGNYMNZ7vbRr6TSSzTZg_ 0MW8tnp0i2iS3Chm2WSJyce.4ShTexIt9R74tWJJpzU6fThRnTp3PGQjTenC GXuNUHiZOM_f95wvWwq4dWUduljkGiVeiaOztKtnyWT2HEgyIbqzLEGJVIqA B4JQ2ot9YSiBQ7eCIa7JAaLlSA6MVkzQk4NGDVd.h4A371it0xp4GtmjzhvI kVd.LgLWGF1wxRCY20HbBNBddJacsEdz_7WejK.j08TrNGD1rI6mwpUCiDLe dEKd4owQdgWAqhfXfg_SdwpL8ie9.X0NExMFVTOhT8y00lp7KcSUJcYd0wug rSMxqT9dyL3lQUA7TW0s6zBIju5I2iI6AWIGkHKd0aVArWznSkd4Pc6311sX S4NW4R5DoGVMq7WbomeUsjxK3PtTLT7E77WrarcxCQbG9zjq9TgbK4SMUPMx eeu9hw0e5mOhi9dcjkyQTjrOr1b94GRU1YAkTeTqQGw9oS2x5UL1V7LN_VgS 2XUpSCqg3ktr.s.IItRpw3Ik- Received: from [24.130.37.147] by web2805.biz.mail.ne1.yahoo.com via HTTP; Thu, 06 Jun 2013 09:46:18 PDT X-Rocket-MIMEInfo: 002.001, QnV0IHRoZSByZWFsaXR5IG9mIHRoZSBzaXR1YXRpb24gaXMgdGhhdCBtdWNoIG9mIHRoZSBJbnRlcm5ldCBhcHBlYXJzIHRvIGJlIHJ1bm5pbmcgd2hlcmUKCiJuIGlzIGFuwqBhcmJpdHJhcnkgbnVtYmVyIHBpY2tlZCBvdXQgb2YgdGhlIGFpciBieSBhIHZlbmRvciIKCk9yIHJhdGhlcgoKIm11bHRpcGxlIGFyYml0cmFyeSBudW1iZXJzIiEKClllcz8KClRoYW5rcywKCk5hbGluaSBFbGtpbnMKSW5zaWRlIFByb2R1Y3RzLCBJbmMuCig4MzEpIDY1OS04MzYwCnd3dy5pbnNpZGV0aGVzdGFjay5jb20KCgoKX18BMAEBAQE- X-Mailer: YahooMailWebService/0.8.144.546 References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0BBEA.4080105@globis.net> Message-ID: <1370537178.16791.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Thu, 6 Jun 2013 09:46:18 -0700 (PDT) From: Nalini Elkins Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) To: Ray Hunter In-Reply-To: <51B0BBEA.4080105@globis.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1619178251-1151783889-1370537178=:16791" Cc: "vishwas.manral@hp.com" , Fernando Gont , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 16:46:26 -0000 --1619178251-1151783889-1370537178=:16791 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable But the reality of the situation is that much of the Internet appears to be= running where=0A=0A"n is an=A0arbitrary number picked out of the air by a = vendor"=0A=0AOr rather=0A=0A"multiple arbitrary numbers"!=0A=0AYes?=0A=0ATh= anks,=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.ins= idethestack.com=0A=0A=0A=0A________________________________=0A From: Ray Hu= nter =0ATo: Nalini Elkins =0ACc: Brian E Carpenter ; 6man ; Fernando Gont ; "vishwas.manral@hp.com" =0ASent: Thursday, June 6, 2013 9:42 AM=0ASubject: Re: d= raft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-t= ransmit-01)=0A =0A=0AIMVHO interpreting the text of the current drafts.=0A= =0A> Nalini Elkins =0A> 6 June 201= 3 18:20=0A> So, if we are talking about the MTU of the local egress interfa= ce,=0A> then since, I believe, the minimum MTU size for IPv6 is 1,280, then= =0A> all devices should be prepared to examine up to 1,280 bytes to get the= =0A> L4 header?=0ANot quite.=0A=0AAFAICS=0A=0A1. All parsing engines should= be able to parse at least 1280 bytes to=0Acover the minimum IPv6 MTU.=0A= =0A2. If all the local interfaces are Ethernet, and have an MTU set of=0A15= 00, the parsing engine on that box should be able to parse a full=0AEtherne= t frame of 1500 bytes of payload..... and so on for devices=0Asupporting li= nks with larger MTUs, all the way up to jumbograms (if=0Asupported on that = device).=0A=0A3. draft-ietf-6man-ext-transmit gives the option of not parsi= ng=0Aextension headers at all on high speed routers (only the hop by hop=0A= option is supposed to be parsed by routers on the path). But neither=0Athis= draft, nor any other IETF draft that I know of, gives an option for=0Apars= ing an IPv6 header chain "just for the first n bytes", where n is an=0Aarbi= trary number picked out of the air by a vendor, whether that be 53,=0A256 o= r 1280.=0A=0Aregards,=0ARayH=0A>=A0 =0A> Thanks,=0A>=0A> Nalini Elkins=0A> = Inside Products, Inc.=0A> (831) 659-8360=0A> www.insidethestack.com=0A>=0A>= ------------------------------------------------------------------------= =0A> *From:* Ray Hunter =0A> *To:* Nalini Elkins =0A> *Cc:* Brian E Carpenter ; 6man=0A> ; Fernando Gont ;= =0A> vishwas.manral@hp.com=0A> *Sent:* Thursday, June 6, 2013 9:14 AM=0A> *= Subject:* draft-ietf-6man-oversized-header-chain-02 (was Re: Re:=0A> draft-= ietf-6man-ext-transmit-01)=0A>=0A> Nalini Elkins wrote:=0A> > >>> Some tric= ky and potentially malicious cases will be avoided by=0A> > forbidding very= long chains of extension headers that need to be=0A> > >>> fragmented [I-D= .ietf-6man-oversized-header-chain].=0A> > >=0A> > > I=A0 wonder if this is = the place to define "very long"?=0A> >=0A> > >> I guess those two words can= be deleted - the issue is only that the=0A> > header chain gets fragmented= at all. The full discussion is in the=0A> > cited draft, of course.=0A> >= =0A> > I know the draft that you have cited and they do not define "long"= =0A> > either.=A0 There has been quite a bit of discussion about what "long= "=0A> > means and IMHO somewhere, someone needs to take some kind of=0A> > = reasonable stand.=0A> >=0A> Actually IMHO ietf-6man-oversized-header-chain = DOES define "unusually=0A> long" very accurately.=0A>=0A> I-D.ietf-6man-ove= rsized-header-chain requires that "the first fragment=0A> of a fragmented d= atagram is required to contain the entire IPv6 header=0A> chain"=0A>=0A> So= in other words, any packet parsing engine should be prepared to=0A> examin= e an entire single frame up to the MTU of the local egress=0A> interface, b= ut should not be expected to maintain any state across=0A> multiple fragmen= ts.=0A>=0A> We might also benefit operationally from setting an additional = limit on=0A> the length of the hop hop option header, which is theoreticall= y meant to=0A> be processed by routers along the path. However, my guess is= that is=0A> well beyond the author's original intentions for=0A> draft-iet= f-6man-oversized-header-chain-02, which was more focussed on=0A> firewalls.= =0A>=0A> >=0A> > >>The IETF hasn't done much about firewalls at all. This= =0A> > search produces far more expired drafts than anything else:=0A> > >>= =0A> https://datatracker.ietf.org/doc/search/?name=3Dfirewalls&rfcs=3Don&ac= tiveDrafts=3Don&oldDrafts=3Don&search_submit=3D=0A> =0A> >=0A> >=0A> >=0A> > The reaso= n I asked is because I think defining RFCs or rules for=0A> > firewalls is = a really good thing to do but if the vendors are not in=0A> > the habit of = having to be compliant, then why would they pay attention=0A> > to this dra= ft that we are discussing?=A0 I actually think maybe an RFC=0A> > which exp= licitly talks about firewalls is probably a good thing to do.=0A> >=A0 Now,= getting vendors to comply...=0A> > =0A> > Thanks,=0A> >=0A> > Nalini Elkin= s=0A> > Inside Products, Inc.=0A> > (831) 659-8360=0A> > www.insidethestack= .com =0A> >=0A>=0A>=0A>=0A> Ray Hunter =0A> 6 June 2013 18:14=0A> Nalini Elkins wrote:=0A>>>>= > Some tricky and potentially malicious cases will be avoided by=0A>> forbi= dding very long chains of extension headers that need to be=0A>>>>> fragmen= ted [I-D.ietf-6man-oversized-header-chain].=0A>>> I=A0 wonder if this is th= e place to define "very long"?=0A>>>> I guess those two words can be delete= d - the issue is only that the=0A>> header chain gets fragmented at all. Th= e full discussion is in the=0A>> cited draft, of course.=0A>>=0A>> I know t= he draft that you have cited and they do not define "long"=0A>> either.=A0 = There has been quite a bit of discussion about what "long"=0A>> means and I= MHO somewhere, someone needs to take some kind of=0A>> reasonable stand. = =0A>>=0A> Actually IMHO ietf-6man-oversized-header-chain DOES define "unusu= ally=0A> long" very accurately.=0A>=0A> I-D.ietf-6man-oversized-header-chai= n requires that "the first fragment=0A> of a fragmented datagram is require= d to contain the entire IPv6 header=0A> chain"=0A>=0A> So in other words, a= ny packet parsing engine should be prepared to=0A> examine an entire single= frame up to the MTU of the local egress=0A> interface, but should not be e= xpected to maintain any state across=0A> multiple fragments.=0A>=0A> We mig= ht also benefit operationally from setting an additional limit on=0A> the l= ength of the hop hop option header, which is theoretically meant to=0A> be = processed by routers along the path. However, my guess is that is=0A> well = beyond the author's original intentions for=0A> draft-ietf-6man-oversized-h= eader-chain-02, which was more focussed on=0A> firewalls.=0A>=0A>>>> The IE= TF hasn't done much about firewalls at all. This=0A>> search produces far m= ore expired drafts than anything else:=0A>>>> https://datatracker.ietf.org/= doc/search/?name=3Dfirewalls&rfcs=3Don&activeDrafts=3Don&oldDrafts=3Don&sea= rch_submit=3D=0A>> =0A>>=0A>> T= he reason I asked is because I think defining RFCs or rules for=0A>> firewa= lls is a really good thing to do but if the vendors are not in=0A>> the hab= it of having to be compliant, then why would they pay attention=0A>> to thi= s draft that we are discussing?=A0 I actually think maybe an RFC=0A>> which= explicitly talks about firewalls is probably a good thing to do.=0A>>=A0 N= ow, getting vendors to comply...=0A>>=A0 =0A>> Thanks,=0A>>=0A>> Nalini Elk= ins=0A>> Inside Products, Inc.=0A>> (831) 659-8360=0A>> www.insidethestack.= com=0A>>=0A>=0A> ----------------------------------------------------------= -------------- --1619178251-1151783889-1370537178=:16791 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    But the reality of the situation is that much of the = Internet appears to be running where
    <= span>
    "n is = an arbitrary num= ber picked out of the air by a vendor"

    Or rather

    "multiple arb= itrary numbers"!

    Yes?

    = Thanks,

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

    <= div dir=3D"ltr">
    From: Ray Hunter <v6ops@globis.n= et>
    To: Nalini Elki= ns <nalini.elkins@insidethestack.com>
    Cc: Brian E Carpenter <brian.e.carpenter@gmail.com= >; 6man <ipv6@ietf.org>; Fernando Gont <fgont@si6networks.com&g= t;; "vishwas.manral@hp.com" <vishwas.manral@hp.com>
    Sent: Thursday, June 6, 2013 9:42 = AM
    Subject: Re: draft-= ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transm= it-01)

    =0AIMVHO inter= preting the text of the current drafts.

    > Nalini Elkins <mailt= o:nalini.elkins@insidethestack.com>
    = > 6 June 2013 18:20
    > So, if we are talking about the MTU of the l= ocal egress interface,
    > then since, I believe, the minimum MTU size = for IPv6 is 1,280, then
    > all devices should be prepared to examine u= p to 1,280 bytes to get the
    > L4 header?
    Not quite.

    AFAICS<= br>
    1. All parsing engines should be able to parse at least 1280 bytes t= o
    cover the minimum IPv6 MTU.

    2. If all the local interfaces are = Ethernet, and have an MTU set of
    1500, the parsing engine on that box sh= ould be able to parse a full
    Ethernet frame of 1500 bytes of payload....= . and so on for devices
    supporting links with larger MTUs, all the way u= p to jumbograms (if
    supported on that device).

    3. draft-ietf-6man-ext-transmit gives the option of not parsing
    extension = headers at all on high speed routers (only the hop by hop
    option is supp= osed to be parsed by routers on the path). But neither
    this draft, nor a= ny other IETF draft that I know of, gives an option for
    parsing an IPv6 = header chain "just for the first n bytes", where n is an
    arbitrary numbe= r picked out of the air by a vendor, whether that be 53,
    256 or 1280.
    regards,
    RayH
    > 
    > Thanks,
    >
    > Nalini= Elkins
    > Inside Products, Inc.
    > (831) 659-8360
    > www.insidethestack.c= om
    >
    > ----------------------------------------------------= --------------------
    > *From:* Ray Hunter <v6ops@globis.net>> *To:* Nalini Elkins <nalini.elkins@insidethestack.com>
    >= *Cc:* Brian E Carpenter <brian.e.carpenter@gmail.com= >; 6man
    > <ipv6@ietf.org>; Fernando Gont <fgont@si6= networks.com>;
    > vishwas.manral@hp.com
    > *Sen= t:* Thursday, June 6, 2013 9:14 AM
    > *Subject:* draft-ietf-6man-overs= ized-header-chain-02 (was Re: Re:
    > draft-ietf-6man-ext-transmit-01)<= br>>
    > Nalini Elkins wrote:
    > > >>> Some tricky = and potentially malicious cases will be avoided by
    > > forbidding = very long chains of extension headers that need to be
    > > >>> frag= mented [I-D.ietf-6man-oversized-header-chain].
    > > >
    > &g= t; > I  wonder if this is the place to define "very long"?
    > = >
    > > >> I guess those two words can be deleted - the iss= ue is only that the
    > > header chain gets fragmented at all. The f= ull discussion is in the
    > > cited draft, of course.
    > ><= br>> > I know the draft that you have cited and they do not define "l= ong"
    > > either.  There has been quite a bit of discussion ab= out what "long"
    > > means and IMHO somewhere, someone needs to tak= e some kind of
    > > reasonable stand.
    > >
    > Actually= IMHO ietf-6man-oversized-header-chain DOES define "unusually
    > long"= very accurately.
    >
    > I-D.ietf-6man-oversized-header-chain requ= ires that "the first fragment
    > of a fragmented datagram is required to contain the entire IPv6 header
    > chain"
    >
    > = So in other words, any packet parsing engine should be prepared to
    > = examine an entire single frame up to the MTU of the local egress
    > in= terface, but should not be expected to maintain any state across
    > mu= ltiple fragments.
    >
    > We might also benefit operationally from = setting an additional limit on
    > the length of the hop hop option hea= der, which is theoretically meant to
    > be processed by routers along = the path. However, my guess is that is
    > well beyond the author's ori= ginal intentions for
    > draft-ietf-6man-oversized-header-chain-02, whi= ch was more focussed on
    > firewalls.
    >
    > >
    > >= ; >>The IETF hasn't done much about firewalls at all. This
    > &g= t; search produces far more expired drafts than anything else:
    > >= >>
    > https://datatracker.ietf.org/doc/search/?name=3Dfirewalls&r= fcs=3Don&activeDrafts=3Don&oldDrafts=3Don&search_submit=3D<= br>> <https://datatracker.ietf.org/doc/search/?name=3Df= irewalls&rfcs=3Don&activeDrafts=3Don&oldDrafts=3Don&search_= submit=3D>
    > >
    > <https://datatracke= r.ietf.org/doc/search/?name=3Dfirewalls&rfcs=3Don&activeDrafts=3Don= &oldDrafts=3Don&search_submit=3D
    > <https://datatracker.ietf.org/doc/search/?name=3Dfirewalls&r= fcs=3Don&activeDrafts=3Don&oldDrafts=3Don&search_submit=3D&= gt;>
    > >
    > > The reason I asked is because I think def= ining RFCs or rules for
    > > firewalls is a really good thing to do= but if the vendors are not in
    > > the habit of having to be compl= iant, then why would they pay attention
    > > to this draft that we = are discussing?  I actually think maybe an RFC
    > > which expl= icitly talks about firewalls is probably a good thing to do.
    > >&n= bsp; Now, getting vendors to comply...
    > >
    > > Thanks,> >
    > > Nalini Elkins
    > > Inside Products, Inc.> > (831) 659-8360
    > > www.insidethestack.com <http://www.insid= ethestack.com/>
    > >
    >
    >
    >
    > Ray Hun= ter <mailto:v6ops@globis.net>
    > 6 June 2013 18:14
    > Nali= ni Elkins wrote:
    >>>>> Some tricky and potentially malici= ous cases will be avoided by
    >> forbidding very long chains of ext= ension headers that need to be
    >>>>> fragmented [I-D.ietf= -6man-oversized-header-chain].
    >>> I  wonder if this is th= e place to define "very long"?
    >>>> I guess those two words = can be deleted - the issue is only that the
    >> header chain gets f= ragmented at all. The full discussion is in the
    >> cited draft, of= course.
    >>
    >> I know the draft that you have cited and t= hey do not define "long"
    >> either.  There has been quite a bit of discussion about what "long"
    >> means and IMHO somewhere, = someone needs to take some kind of
    >> reasonable stand.
    >&g= t;
    > Actually IMHO ietf-6man-oversized-header-chain DOES define "unus= ually
    > long" very accurately.
    >
    > I-D.ietf-6man-oversize= d-header-chain requires that "the first fragment
    > of a fragmented da= tagram is required to contain the entire IPv6 header
    > chain"
    >=
    > So in other words, any packet parsing engine should be prepared to=
    > examine an entire single frame up to the MTU of the local egress> interface, but should not be expected to maintain any state across> multiple fragments.
    >
    > We might also benefit operationa= lly from setting an additional limit on
    > the length of the hop hop o= ption header, which is theoretically meant to
    > be processed by route= rs along the path. However, my guess is that is
    > well beyond the author's original intentions for
    > draft-ietf-6man-oversized-hea= der-chain-02, which was more focussed on
    > firewalls.
    >
    >= >>> The IETF hasn't done much about firewalls at all. This
    >= > search produces far more expired drafts than anything else:
    >>= ;>> https://datatracker.ietf.org/doc/search/?name=3Dfir= ewalls&rfcs=3Don&activeDrafts=3Don&oldDrafts=3Don&search_su= bmit=3D
    >> <https://datatracker.ietf.org/doc/= search/?name=3Dfirewalls&rfcs=3Don&activeDrafts=3Don&oldDrafts= =3Don&search_submit=3D>
    >>
    >> The reason I ask= ed is because I think defining RFCs or rules for
    >> firewalls is a really good thing to do but if the ve= ndors are not in
    >> the habit of having to be compliant, then why = would they pay attention
    >> to this draft that we are discussing?&= nbsp; I actually think maybe an RFC
    >> which explicitly talks abou= t firewalls is probably a good thing to do.
    >>  Now, getting = vendors to comply...
    >> 
    >> Thanks,
    >>
    = >> Nalini Elkins
    >> Inside Products, Inc.
    >> (831) = 659-8360
    >> www.insidethestack.com
    >>
    >
    > ---= ---------------------------------------------------------------------


    --1619178251-1151783889-1370537178=:16791-- From v6ops@globis.net Thu Jun 6 10:26:33 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40C021F9A38 for ; Thu, 6 Jun 2013 10:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQTrW9o0ioQC for ; Thu, 6 Jun 2013 10:26:32 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id E175421F9635 for ; Thu, 6 Jun 2013 10:26:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 8A6CA8700DF; Thu, 6 Jun 2013 19:26:00 +0200 (CEST) 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 xnWVLoSii+Lk; Thu, 6 Jun 2013 19:26:00 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 61A15870077; Thu, 6 Jun 2013 19:26:00 +0200 (CEST) Message-ID: <51B0C622.8090501@globis.net> Date: Thu, 06 Jun 2013 19:25:54 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Nalini Elkins Subject: Re: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0BBEA.4080105@globis.net> <1370537178.16791.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> In-Reply-To: <1370537178.16791.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "vishwas.manral@hp.com" , Fernando Gont , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 17:26:34 -0000 Nalini Elkins wrote: > But the reality of the situation is that much of the Internet appears > to be running where > > "n is an arbitrary number picked out of the air by a vendor" > > Or rather > > "multiple arbitrary numbers"! > > Yes? Correct. There is a non null union between the set of IETF standards and the set of operational configurations of the various networks that form the Internet; but neither is a proper subset of the other. That's nothing new. > > Thanks, > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > ------------------------------------------------------------------------ > *From:* Ray Hunter > *To:* Nalini Elkins > *Cc:* Brian E Carpenter ; 6man > ; Fernando Gont ; > "vishwas.manral@hp.com" > *Sent:* Thursday, June 6, 2013 9:42 AM > *Subject:* Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: > draft-ietf-6man-ext-transmit-01) > > IMVHO interpreting the text of the current drafts. > > > Nalini Elkins > > > 6 June 2013 18:20 > > So, if we are talking about the MTU of the local egress interface, > > then since, I believe, the minimum MTU size for IPv6 is 1,280, then > > all devices should be prepared to examine up to 1,280 bytes to get the > > L4 header? > Not quite. > > AFAICS > > 1. All parsing engines should be able to parse at least 1280 bytes to > cover the minimum IPv6 MTU. > > 2. If all the local interfaces are Ethernet, and have an MTU set of > 1500, the parsing engine on that box should be able to parse a full > Ethernet frame of 1500 bytes of payload..... and so on for devices > supporting links with larger MTUs, all the way up to jumbograms (if > supported on that device). > > 3. draft-ietf-6man-ext-transmit gives the option of not parsing > extension headers at all on high speed routers (only the hop by hop > option is supposed to be parsed by routers on the path). But neither > this draft, nor any other IETF draft that I know of, gives an option for > parsing an IPv6 header chain "just for the first n bytes", where n is an > arbitrary number picked out of the air by a vendor, whether that be 53, > 256 or 1280. > > regards, > RayH > > > > Thanks, > > > > Nalini Elkins > > Inside Products, Inc. > > (831) 659-8360 > > www.insidethestack.com > > > > ------------------------------------------------------------------------ > > *From:* Ray Hunter > > > *To:* Nalini Elkins > > > *Cc:* Brian E Carpenter >; 6man > > >; Fernando Gont > >; > > vishwas.manral@hp.com > > *Sent:* Thursday, June 6, 2013 9:14 AM > > *Subject:* draft-ietf-6man-oversized-header-chain-02 (was Re: Re: > > draft-ietf-6man-ext-transmit-01) > > > > Nalini Elkins wrote: > > > >>> Some tricky and potentially malicious cases will be avoided by > > > forbidding very long chains of extension headers that need to be > > > >>> fragmented [I-D.ietf-6man-oversized-header-chain]. > > > > > > > > I wonder if this is the place to define "very long"? > > > > > > >> I guess those two words can be deleted - the issue is only that the > > > header chain gets fragmented at all. The full discussion is in the > > > cited draft, of course. > > > > > > I know the draft that you have cited and they do not define "long" > > > either. There has been quite a bit of discussion about what "long" > > > means and IMHO somewhere, someone needs to take some kind of > > > reasonable stand. > > > > > Actually IMHO ietf-6man-oversized-header-chain DOES define "unusually > > long" very accurately. > > > > I-D.ietf-6man-oversized-header-chain requires that "the first fragment > > of a fragmented datagram is required to contain the entire IPv6 header > > chain" > > > > So in other words, any packet parsing engine should be prepared to > > examine an entire single frame up to the MTU of the local egress > > interface, but should not be expected to maintain any state across > > multiple fragments. > > > > We might also benefit operationally from setting an additional limit on > > the length of the hop hop option header, which is theoretically meant to > > be processed by routers along the path. However, my guess is that is > > well beyond the author's original intentions for > > draft-ietf-6man-oversized-header-chain-02, which was more focussed on > > firewalls. > > > > > > > > >>The IETF hasn't done much about firewalls at all. This > > > search produces far more expired drafts than anything else: > > > >> > > > https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit= > > > > > > > > > > > > > > >> > > > > > > The reason I asked is because I think defining RFCs or rules for > > > firewalls is a really good thing to do but if the vendors are not in > > > the habit of having to be compliant, then why would they pay attention > > > to this draft that we are discussing? I actually think maybe an RFC > > > which explicitly talks about firewalls is probably a good thing to do. > > > Now, getting vendors to comply... > > > > > > Thanks, > > > > > > Nalini Elkins > > > Inside Products, Inc. > > > (831) 659-8360 > > > www.insidethestack.com > > > > > > > > > > > Ray Hunter > > > 6 June 2013 18:14 > > Nalini Elkins wrote: > >>>>> Some tricky and potentially malicious cases will be avoided by > >> forbidding very long chains of extension headers that need to be > >>>>> fragmented [I-D.ietf-6man-oversized-header-chain]. > >>> I wonder if this is the place to define "very long"? > >>>> I guess those two words can be deleted - the issue is only that the > >> header chain gets fragmented at all. The full discussion is in the > >> cited draft, of course. > >> > >> I know the draft that you have cited and they do not define "long" > >> either. There has been quite a bit of discussion about what "long" > >> means and IMHO somewhere, someone needs to take some kind of > >> reasonable stand. > >> > > Actually IMHO ietf-6man-oversized-header-chain DOES define "unusually > > long" very accurately. > > > > I-D.ietf-6man-oversized-header-chain requires that "the first fragment > > of a fragmented datagram is required to contain the entire IPv6 header > > chain" > > > > So in other words, any packet parsing engine should be prepared to > > examine an entire single frame up to the MTU of the local egress > > interface, but should not be expected to maintain any state across > > multiple fragments. > > > > We might also benefit operationally from setting an additional limit on > > the length of the hop hop option header, which is theoretically meant to > > be processed by routers along the path. However, my guess is that is > > well beyond the author's original intentions for > > draft-ietf-6man-oversized-header-chain-02, which was more focussed on > > firewalls. > > > >>>> The IETF hasn't done much about firewalls at all. This > >> search produces far more expired drafts than anything else: > >>>> > https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit= > > >> > > > >> > >> The reason I asked is because I think defining RFCs or rules for > >> firewalls is a really good thing to do but if the vendors are not in > >> the habit of having to be compliant, then why would they pay attention > >> to this draft that we are discussing? I actually think maybe an RFC > >> which explicitly talks about firewalls is probably a good thing to do. > >> Now, getting vendors to comply... > >> > >> Thanks, > >> > >> Nalini Elkins > >> Inside Products, Inc. > >> (831) 659-8360 > >> www.insidethestack.com > >> > > > > ------------------------------------------------------------------------ > > > From owen@delong.com Thu Jun 6 11:43:43 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E1121F8E89; Thu, 6 Jun 2013 11:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFX+DsKnmYC4; Thu, 6 Jun 2013 11:43:43 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 335BE21F8DDD; Thu, 6 Jun 2013 11:43:42 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r56If8Ro015981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 6 Jun 2013 11:41:08 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r56If8Ro015981 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370544069; bh=y+p83C33UJbbo0mim4v7AtN2DLY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QlAWUJrkyMdyTEJo0PBebZQ708XWIUtqDG65CNTxQatmTdTUUiQ0gmzqSrVfQInYH vcjsz62pQLcjxvSf4BD+REcTO1dUlfMT0/Oi7UXDTbyku95eZEMBN/yRCzXzaa9y0b Xhz7o5ms03so+tUON9wX8GgzZN0K3Zi04O3CJ9RE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Owen DeLong In-Reply-To: Date: Thu, 6 Jun 2013 11:41:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <021E64FECA7E5A4699562F4E6671648103DE44@XCH-PHX-503.sw.nos.boeing.com> <8D23D4052ABE7A4490E77B1A012B6307751C62A3@mbx-01.win.nominum.com> To: Sheng Jiang X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 06 Jun 2013 11:41:09 -0700 (PDT) Cc: "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" , Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 18:43:44 -0000 On Jun 6, 2013, at 03:39 , Sheng Jiang wrote: > Yes, this discussion has become far way from my original motivation of = analysing semantic prefix mechanism. I am going to stop replying to the = discuss regarding to the avaibilities of bits. In the future version, I = will add the bits consumption as one of the pitfalls. > =20 > By the way, ISPs are only one kind of network operators who are = interesting in semantic prefix. Enterprise network operators are another = group of network operators who can benefit from embedded semantics. And = the enterprises do not have subscribers who potentially need extra bits. Your use of the word "benefit" here is questionable at best. It is an = example of language that seems to encourage this use rather than = evaluate it in an unbiased manner. "Enterprise operators are another group of network operators which may = succumb to this nasty pitfall of embedded semantics" would be an = equally biased statement in the opposite direction. I suggest that neutral would require something more along the lines of: "Enterprise operators are another group of network operators which may = choose to embed semantics in their address prefixes." Now, in terms of arguing the merits, there are significant differences = between these two. In the case of an enterprise operator, their choice = to embed semantics in the address has a limited scope of harm. It can = only negatively impact said enterprise. In the case of an ISP, this can have significant consequences not only = for the ISP, but also for their downstream customers. Owen From owen@delong.com Thu Jun 6 11:58:34 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC7121E8054; Thu, 6 Jun 2013 11:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.275 X-Spam-Level: X-Spam-Status: No, score=-3.275 tagged_above=-999 required=5 tests=[AWL=1.325, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1w+RSHer-bMP; Thu, 6 Jun 2013 11:58:33 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D2BED11E80ED; Thu, 6 Jun 2013 11:58:33 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r56Iv7L3016601 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 6 Jun 2013 11:57:08 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r56Iv7L3016601 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370545028; bh=WOda8Z61Hyv24ywj0qYkQ6bs/O4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=FiTTUlQhvuCGMckv+MNm3GKsPv1WN61UooyvnLnb2Vvmr2psifeJdUyM+ssaTg10c hsWd4OKlEiAApIxPTCw8tRABaVnB/J+EhwjGcKUaPMdKOSz+CVYwbfWvvusTk0WaEQ Xno0glC1J8U3GDaCXuEoRvPr6qAywkdGc51+r/xk= Content-Type: multipart/alternative; boundary="Apple-Mail=_EF1C7FB3-2598-4A70-A48B-B22BFDAA056E" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Owen DeLong In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> Date: Thu, 6 Jun 2013 11:57:07 -0700 Message-Id: <9B71CE05-E12D-4FE9-8222-6FBFD7938F0C@delong.com> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 06 Jun 2013 11:57:08 -0700 (PDT) Cc: "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" , Lorenzo Colitti X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 18:58:34 -0000 --Apple-Mail=_EF1C7FB3-2598-4A70-A48B-B22BFDAA056E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jun 6, 2013, at 04:34 , Ted Lemon wrote: > On Jun 5, 2013, at 11:30 PM, Lorenzo Colitti = wrote: >> Personally, I'm waiting for us to agree that due to current RIR = policies, if an ISP chooses to use semantic prefixes, then it will not = be able to give users as much space as it would be able to give them if = it chose not to use semantic prefixes. >=20 > You will have to wait until someone from an RIR says "we won't = allocate more bits in cases like this." We have only heard from one = person who works for an RIR, and his opinion was that this was subject = to negotiation, and not clear-cut. But even if we did get some kind of = firm commitment from RIRs that they would never give an ISP extra bits, = the ISP can still use bits from the customer's allocation, unless RIRs = change _that_ policy too (Owen's absurd accusations of fraud = notwithstanding). While I am not employed by an RIR, I think I have a pretty good = perspective on RIR policy, especially as it exists in the ARIN region = and most especially the IPv6 policies in the ARIN region. I am the = primary author of the current ARIN IPv6 ISP policy and a contributing = author to the current end-user policy. I have also been actively = involved in the ARIN policy process for more than a decade and am in my = 6th year of service on the ARIN AC. While my statements in this forum are my opinion alone and not intended = to represent ARIN or the AC, I think I bring a pretty good knowledge of = both the letter and the intent of the policies as they exist today. If you claim you gave a customer a /48 and the customer reports that = they are not allowed to exercise control over the use of that /48, then, = you have not, in fact, delegated authority over that /48 as you have = claimed to ARIN and that is, in fact, resource fraud in violation of = ARIN policy. I'm not sure why you think this is an absurd claim. > We've gone around and around on this for days, and nobody's been able = to make a solid case for the proposition that there aren't enough bits = to do semantic prefixes. I think we don't need to argue that question = anymore. Is that _really_ the _only_ argument against semantic = prefixes? There are enough bits to do it in your first allocation. Whether you = will be able to get a subsequent allocation when you run out without = achieving sufficiently efficient utilization later due to the = inefficiencies imposed by this particular style of use is the open = question. Other than you, most posters seem to recognize that this is, = in fact, a likely drawback. Owen --Apple-Mail=_EF1C7FB3-2598-4A70-A48B-B22BFDAA056E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Ted.Lemon@nominum.com> = wrote:
    On Jun 5, 2013, at 11:30 PM, Lorenzo Colitti <lorenzo@google.com> = wrote:

    While I am not = employed by an RIR, I think I have a pretty good perspective on RIR = policy, especially as it exists in the ARIN region and most especially = the IPv6 policies in the ARIN region. I am the primary author of the = current ARIN IPv6 ISP policy and a contributing author to the current = end-user policy. I have also been actively involved in the ARIN policy = process for more than a decade and am in my 6th year of service on the = ARIN AC.

    While my statements in this forum are = my opinion alone and not intended to represent ARIN or the AC, I think I = bring a pretty good knowledge of both the letter and the intent of the = policies as they exist today.

    If you claim you = gave a customer a /48 and the customer reports that they are not allowed = to exercise control over the use of that /48, then, you have not, in = fact, delegated authority over that /48 as you have claimed to ARIN and = that is, in fact, resource fraud in violation of ARIN policy. I'm not = sure why you think this is an absurd = claim.

    We've gone around and around on this for days, and nobody's been = able to make a solid case for the proposition that there aren't enough = bits to do semantic prefixes.   I think we don't need to argue that = question anymore.   Is that _really_ the _only_ argument against semantic = prefixes?

    There are enough bits = to do it in your first allocation. Whether you will be able to get a = subsequent allocation when you run out without achieving sufficiently = efficient utilization later due to the inefficiencies imposed by this = particular style of use is the open question. Other than you, most = posters seem to recognize that this is, in fact, a likely = drawback.

    Owen

    = --Apple-Mail=_EF1C7FB3-2598-4A70-A48B-B22BFDAA056E-- From fgont@si6networks.com Thu Jun 6 13:09:04 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E37921F9446 for ; Thu, 6 Jun 2013 13:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5SM9oWneeDC for ; Thu, 6 Jun 2013 13:09:04 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id C6A4621F947C for ; Thu, 6 Jun 2013 13:09:00 -0700 (PDT) Received: from ip-109-41-244-229.web.vodafone.de ([109.41.244.229] helo=[192.168.0.101]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UkgU1-0007ye-9X; Thu, 06 Jun 2013 22:08:29 +0200 Message-ID: <51B0EC3B.1080408@si6networks.com> Date: Thu, 06 Jun 2013 22:08:27 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ray Hunter Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> In-Reply-To: <51B0B581.7020203@globis.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: vishwas.manral@hp.com, 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 20:09:04 -0000 On 06/06/2013 06:14 PM, Ray Hunter wrote: > So in other words, any packet parsing engine should be prepared to > examine an entire single frame up to the MTU of the local egress > interface, but should not be expected to maintain any state across > multiple fragments. FWIW, some earlier version of this document tried to require that the entire IPv6 header chain be present within the first 1280 bytes -- but some folks thought that was too constricting. > We might also benefit operationally from setting an additional limit on > the length of the hop hop option header, which is theoretically meant to > be processed by routers along the path. However, my guess is that is > well beyond the author's original intentions for > draft-ietf-6man-oversized-header-chain-02, which was more focussed on > firewalls. I (personally) think it would be valuable to limit the number of instance of each extension header -- but that wouldn't probably fly here... Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Thu Jun 6 13:09:44 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1E321E80C1 for ; Thu, 6 Jun 2013 13:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSKAP0THNNGb for ; Thu, 6 Jun 2013 13:09:43 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9373E21E80B7 for ; Thu, 6 Jun 2013 13:09:43 -0700 (PDT) Received: from ip-109-41-244-229.web.vodafone.de ([109.41.244.229] helo=[192.168.0.101]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UkgV4-0007z8-Od; Thu, 06 Jun 2013 22:09:34 +0200 Message-ID: <51B0EC7B.1090904@si6networks.com> Date: Thu, 06 Jun 2013 22:09:31 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Nalini Elkins Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> In-Reply-To: <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "vishwas.manral@hp.com" , Ray Hunter , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 20:09:44 -0000 On 06/06/2013 06:20 PM, Nalini Elkins wrote: > So, if we are talking about the MTU of the local egress interface, then > since, I believe, the minimum MTU size for IPv6 is 1,280, then all > devices should be prepared to examine up to 1,280 bytes to get the L4 > header? In theory, yes. In practice, it wouldn't make much sense, probably (most of the packet containing overhead?). Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From joelja@bogus.com Thu Jun 6 13:20:23 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5E021F99A0 for ; Thu, 6 Jun 2013 13:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjnXUrqoTeWP for ; Thu, 6 Jun 2013 13:20:22 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id A504321F9998 for ; Thu, 6 Jun 2013 13:20:22 -0700 (PDT) Received: from joels-MacBook-Air.local (4.sub-70-208-144.myvzw.com [70.208.144.4]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r56KJdCB043079 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 6 Jun 2013 20:19:40 GMT (envelope-from joelja@bogus.com) Message-ID: <51B0EED6.6020200@bogus.com> Date: Thu, 06 Jun 2013 16:19:34 -0400 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Fernando Gont , Nalini Elkins Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> In-Reply-To: <51B0EC7B.1090904@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 06 Jun 2013 20:19:41 +0000 (UTC) Cc: "vishwas.manral@hp.com" , Ray Hunter , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 20:20:23 -0000 On 6/6/13 4:09 PM, Fernando Gont wrote: > On 06/06/2013 06:20 PM, Nalini Elkins wrote: >> So, if we are talking about the MTU of the local egress interface, then >> since, I believe, the minimum MTU size for IPv6 is 1,280, then all >> devices should be prepared to examine up to 1,280 bytes to get the L4 >> header? > In theory, yes. In practice, it wouldn't make much sense, probably (most > of the packet containing overhead?). There's a question you can pose to an asic designer... What does it cost at this point to extend the header processing from 53/64/128/256 bytes. bearing in mind also that part of the reason that the space already has increased is due to encapsulation, label-in-label q-in-q so the ipv6 header is not the only thing competing for more room. > Cheers, From fgont@si6networks.com Thu Jun 6 13:36:16 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E7121F972C for ; Thu, 6 Jun 2013 13:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LATanbJFlvku for ; Thu, 6 Jun 2013 13:36:11 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 389BE21E808D for <6man@ietf.org>; Thu, 6 Jun 2013 13:36:11 -0700 (PDT) Received: from ip-109-46-54-212.web.vodafone.de ([109.46.54.212] helo=[192.168.0.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UkguP-0002JZ-Oo; Thu, 06 Jun 2013 22:35:45 +0200 Message-ID: <51B0EAE1.5080006@si6networks.com> Date: Thu, 06 Jun 2013 22:02:41 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Alissa Cooper Subject: Re: Comments on draft-ietf-6man-stable-privacy-addresses-07 References: <72fb5db097d443eebb554cdc43d7a01f@BY2PR03MB269.namprd03.prod.outlook.com> <519AD0EF.60600@si6networks.com> <87b8552e4b4a479dbfca94bd88a09ce7@BY2PR03MB269.namprd03.prod.outlook.com> <519F3364.80301@si6networks.com> <51A207B0.4000900@si6networks.com> <51A93EEE.7080902@gont.com.ar> <6AD05DBB-1067-4F4D-996C-CAB7FEF0184F@cdt.org> <51AFE3AF.1050300@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Brian Haberman , "6man@ietf.org" <6man@ietf.org>, Dave Thaler , Ray Hunter , Fernando Gont , "tom.petch" , Christian Huitema , He Xuan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 20:36:16 -0000 On 06/06/2013 03:40 PM, Alissa Cooper wrote: >> For instance, Section B.1 explicitly says so (and this type of >> attack is not meant to be solved by stable-privacy-addresses). >> >> In some scenarios, it can be mitigated with RFC 4941. Hoawever, as >> noted in Section C.4, even ith RFC4941 there are scenarios n which >> yu cannot do much about it. >> > > Maybe it's just an organizational thing that makes me feel like this > isn't clear -- in B.1 it says "However, as noted earlier in this > document, in scenarios in which there is a reduced number of nodes …" > but really that scenario is not discussed until later in the document > (C.4). The corresponding paragraph was moved to the appendix in version -09 -- it was part of the Intro in previous versions. I will update the document accordingly. > Then appendix C says that "It aims to clarify the motivation > of employing the method specified in this document," but ends with > the attack described in C.4, which is not mitigated by the mechanism > specified in the document. As with the above, this is a product of the text that I moved to the Appendix > I realize how this organization came about > but it seems like it would make a little more sense to have each of > the distinct threat models clearly described in one place in the body > of the document, followed by a discussion of which threats the > mechanism mitigates and which it does not. I'd personally prefer this not to be in the body of the document. For the most part, because I think that we might benefit of a separate document that does an analysis of all IID generation techniques, rather than only this one (I had planned to wok on such a document even before this whole discussion came up). To some extent, including such whole discussion here looks a bit side-tracking. But I'd love to hear what you and others think about it. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From v6ops@globis.net Thu Jun 6 13:41:35 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1449921E809A for ; Thu, 6 Jun 2013 13:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Axxz8wPHIiIS for ; Thu, 6 Jun 2013 13:41:34 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF3611E80E4 for ; Thu, 6 Jun 2013 13:41:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E3FF18700B2; Thu, 6 Jun 2013 22:41:16 +0200 (CEST) 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 81bzBC448j1X; Thu, 6 Jun 2013 22:41:16 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id B9A7587002E; Thu, 6 Jun 2013 22:41:16 +0200 (CEST) Message-ID: <51B0F3E6.4010006@globis.net> Date: Thu, 06 Jun 2013 22:41:10 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: joel jaeggli Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> In-Reply-To: <51B0EED6.6020200@bogus.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "vishwas.manral@hp.com" , Fernando Gont , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 20:41:35 -0000 > joel jaeggli > 6 June 2013 22:19 > On 6/6/13 4:09 PM, Fernando Gont wrote: >> On 06/06/2013 06:20 PM, Nalini Elkins wrote: >>> So, if we are talking about the MTU of the local egress interface, then >>> since, I believe, the minimum MTU size for IPv6 is 1,280, then all >>> devices should be prepared to examine up to 1,280 bytes to get the L4 >>> header? >> In theory, yes. In practice, it wouldn't make much sense, probably (most >> of the packet containing overhead?). > There's a question you can pose to an asic designer... What does it > cost at this point to extend the header processing from 53/64/128/256 > bytes. bearing in mind also that part of the reason that the space > already has increased is due to encapsulation, label-in-label q-in-q > so the ipv6 header is not the only thing competing for more room. >> Cheers, > May I suggest some other questions: Does size matter? Or is the complexity of the ASIC implementation of a header chain parser more heavily influenced by the fact that the header chain is defined as a linked list of type-length-value items that can be built up in any number of valid combinations, and so has to be traversed and interpreted at every individual link? What if the most common individual TLV option tokens were standardized further? And the transmission order fixed? What if the most common individual extension headers were standardized further? And the transmission order fixed? Would this help make hardware parsing possible/economic? regards, RayH From wwwrun@rfc-editor.org Thu Jun 6 13:52:36 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD3211E80A3; Thu, 6 Jun 2013 13:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5Tk7D4SMfWR; Thu, 6 Jun 2013 13:52:36 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7924721F9936; Thu, 6 Jun 2013 13:52:36 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1871662118; Thu, 6 Jun 2013 13:51:09 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6957 on Duplicate Address Detection Proxy From: rfc-editor@rfc-editor.org Message-Id: <20130606205109.1871662118@rfc-editor.org> Date: Thu, 6 Jun 2013 13:51:09 -0700 (PDT) Cc: ipv6@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 20:52:37 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6957 Title: Duplicate Address Detection Proxy Author: F. Costa, J-M. Combes, Ed., X. Pougnard, H. Li Status: Standards Track Stream: IETF Date: June 2013 Mailbox: fabio.costa@orange.com, jeanmichel.combes@orange.com, xavier.pougnard@orange.com, lihy@huawei.com Pages: 16 Characters: 32537 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-6man-dad-proxy-07.txt URL: http://www.rfc-editor.org/rfc/rfc6957.txt The document describes a proxy-based mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with a "split-horizon" forwarding scheme, primarily deployed for Digital Subscriber Line (DSL) and Fiber access architectures. Based on the DAD signaling, the first-hop router stores in a Binding Table all known IPv6 addresses used on a point-to-multipoint domain (e.g., VLAN). When a node performs DAD for an address already used by another node, the first-hop router defends the address rather than the device using the address. This document is a product of the IPv6 Maintenance Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Thu Jun 6 13:58:19 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448C411E8109; Thu, 6 Jun 2013 13:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.263 X-Spam-Level: X-Spam-Status: No, score=-102.263 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wF5YxuAS+O8B; Thu, 6 Jun 2013 13:58:18 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 17BB611E8102; Thu, 6 Jun 2013 13:58:18 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id EC53862178; Thu, 6 Jun 2013 13:56:50 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6957 on Duplicate Address Detection Proxy From: rfc-editor@rfc-editor.org Message-Id: <20130606205650.EC53862178@rfc-editor.org> Date: Thu, 6 Jun 2013 13:56:50 -0700 (PDT) Cc: ipv6@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 20:58:19 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6957 Title: Duplicate Address Detection Proxy Author: F. Costa, J-M. Combes, Ed., X. Pougnard, H. Li Status: Standards Track Stream: IETF Date: June 2013 Mailbox: fabio.costa@orange.com, jeanmichel.combes@orange.com, xavier.pougnard@orange.com, lihy@huawei.com Pages: 16 Characters: 32537 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-6man-dad-proxy-07.txt URL: http://www.rfc-editor.org/rfc/rfc6957.txt The document describes a proxy-based mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with a "split-horizon" forwarding scheme, primarily deployed for Digital Subscriber Line (DSL) and Fiber access architectures. Based on the DAD signaling, the first-hop router stores in a Binding Table all known IPv6 addresses used on a point-to-multipoint domain (e.g., VLAN). When a node performs DAD for an address already used by another node, the first-hop router defends the address rather than the device using the address. This document is a product of the IPv6 Maintenance Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From Ted.Lemon@nominum.com Thu Jun 6 18:27:03 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB9F11E80A2; Thu, 6 Jun 2013 18:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.765 X-Spam-Level: X-Spam-Status: No, score=-106.765 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrIP2A4h6UbB; Thu, 6 Jun 2013 18:26:56 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7025F21F8994; Thu, 6 Jun 2013 18:26:56 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUbE23/E5Q3H1b8s6B7TI2zkMM6wuD5vu@postini.com; Thu, 06 Jun 2013 18:26:56 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D828C1B81FA; Thu, 6 Jun 2013 18:26:54 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id CF05419005D; Thu, 6 Jun 2013 18:26:54 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 18:26:54 -0700 From: Ted Lemon To: Owen DeLong Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAFFqgIAAA0MAgAAlngCAAERTAIAAmIuAgAAWAQCAALv5gIAAMI2AgACc9YCAACD6gIAAH1gAgACZeoCAAAjegIAAwruAgAAV84CAAAZKgIAAAigAgAC9mQCAAIcfgIAAe8GAgABs5wA= Date: Fri, 7 Jun 2013 01:26:54 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C850C@mbx-01.win.nominum.com> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> <9B71CE05-E12D-4FE9-8222-6FBFD7938F0C@delong.com> In-Reply-To: <9B71CE05-E12D-4FE9-8222-6FBFD7938F0C@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C850Cmbx01winnominum_" MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" , Lorenzo Colitti X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 01:27:03 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C850Cmbx01winnominum_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jun 6, 2013, at 2:57 PM, Owen DeLong > wrote: If you claim you gave a customer a /48 and the customer reports that they a= re not allowed to exercise control over the use of that /48, then, you have= not, in fact, delegated authority over that /48 as you have claimed to ARI= N and that is, in fact, resource fraud in violation of ARIN policy. I'm not= sure why you think this is an absurd claim. Because you haven't cited a policy that substantiates it, despite claiming = to have written the policy that would say this. There are enough bits to do it in your first allocation. Whether you will b= e able to get a subsequent allocation when you run out without achieving su= fficiently efficient utilization later due to the inefficiencies imposed by= this particular style of use is the open question. Other than you, most po= sters seem to recognize that this is, in fact, a likely drawback. Yes, we're aware that it's a drawback. Consumption of address space is a = drawback of using a 64-bit host identifier, too. But it's not a strong ar= gument against doing it. You seem to feel _really_ strongly about this; i= s it really the case that your only objection is that you think it's not po= ssible for an ISP to get enough bits to do it? --_000_8D23D4052ABE7A4490E77B1A012B6307751C850Cmbx01winnominum_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <405F200514ED714D9E87795F3B291306@nominum.com> Content-Transfer-Encoding: quoted-printable
    On Jun 6, 2013, at 2:57 PM, Owen DeLong <owen@delong.com> wrote:
    If you claim you gave a customer a /48 and the customer reports that they are= not allowed to exercise control over the use of that /48, then, you have n= ot, in fact, delegated authority over that /48 as you have claimed to ARIN = and that is, in fact, resource fraud in violation of ARIN policy. I'm not sure why you think this is an absurd = claim.

    Because you haven't cited a policy that substantiates it, despite clai= ming to have written the policy that would say this.

    There are enough bits to do it in your first allo= cation. Whether you will be able to get a subsequent allocation when you ru= n out without achieving sufficiently efficient utilization later due to the= inefficiencies imposed by this particular style of use is the open question. Other than you, most posters seem to re= cognize that this is, in fact, a likely drawback.

    Yes, we're aware that it's a drawback.   Consumption of address s= pace is a drawback of using a 64-bit host identifier, too.   But it's = not a strong argument against doing it.   You seem to feel _really_ st= rongly about this; is it really the case that your only objection is that you think it's not possible for an ISP to get enoug= h bits to do it?

    --_000_8D23D4052ABE7A4490E77B1A012B6307751C850Cmbx01winnominum_-- From lorenzo@google.com Thu Jun 6 18:38:51 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA9321F93E0 for ; Thu, 6 Jun 2013 18:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkEF95a8yTSH for ; Thu, 6 Jun 2013 18:38:51 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id D34D021F93C4 for ; Thu, 6 Jun 2013 18:38:50 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id hu16so746217qab.8 for ; Thu, 06 Jun 2013 18:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wDzzN22TtQyWrtE1vt02fx3tMuWnMyUELr7ENEmeUds=; b=OEsz9dvGjWVM1aqPVGek0zUHS5vLUFiCKw8VDZvBTUW6DcSMmB/fxWDSo91rMK33qN cnfiVgC8SrGBVz2effNlvOwKE0gE+t7GMZkqx3h6PeG5iaP2D+Oi+hCGQbs5pQV9KX1s UdbHX7XvPTwfCg9shXrUnzIjEXrxnuoBNVzKtVXzM6b3TGjiN1/Ys7apfntk7IdiJft1 XPZumK1SQqmbmkACgk1tos5iWd8DnumHq4JmPIMxQKt/Du0OfKKlwAdIWCfdb6d2VDFP Fb3wQbIXZyrVZzdRhzZsAbpg1AwjjdRpY8aPLRt5WuE2UGtVhHI5mxeM6+9YU3yk9wPM JB8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=wDzzN22TtQyWrtE1vt02fx3tMuWnMyUELr7ENEmeUds=; b=PDKj1sWSL19EfMn4YNKURP/+JnYcjYL0s3JVWcHWDWWMChwja49oQZb2qIHWzvTp+R ZGPEeCcbwwZCM1+K4SBXGJNFNCS/kDneyVfelcd/DHpAfg/1+pZrNYGmUd3V4WHYJTls eRJFfYqxzPyjOKt5KI483mXUAmwgzE7Tud4oDFeDsIiOY3r0wnuxJS/ftm072n9wUMu1 TNrmqo171r1mxNvZ7lSHzPS/CXQB7tJDPvQS9g+oVvW/tc9MZ+jlRMoHJQOq2bsVEkgi FGSTi9kJOx6n0tqUfkmxK6wG9FXhnmYTt28nEFisg/4EEtghJ4N3fDkWdXvc9GEvK1we miGA== X-Received: by 10.49.101.74 with SMTP id fe10mr13230268qeb.11.1370569130132; Thu, 06 Jun 2013 18:38:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.158.8 with HTTP; Thu, 6 Jun 2013 18:38:30 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C850C@mbx-01.win.nominum.com> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> <9B71CE05-E12D-4FE9-8222-6FBFD7938F0C@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C850C@mbx-01.win.nominum.com> From: Lorenzo Colitti Date: Fri, 7 Jun 2013 10:38:30 +0900 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 To: Ted Lemon Content-Type: multipart/alternative; boundary=001a11c2c6ce2472e804de867ed4 X-Gm-Message-State: ALoCoQknEHo2z83ReBJNBJhnwMfCoGoQan2rKEyIAc7Phk802vE0IrC7XS5Q2O0Blpy8IVWFpb0J+phEZrrXXQxNEO/rNgqfBa31QM5prm8sqXUKW9KFwL8SxFlXFcAwogf+EAxSQHjnVHP9RDY7D/hw0OPfkuLESCPl387xGmVK15j9KIa/3oZ58Yocai+6gtpEHAR3wiEy Cc: "ipv6@ietf.org 6man-wg" , "v6ops@ietf.org WG" , "" , Owen DeLong X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 01:38:51 -0000 --001a11c2c6ce2472e804de867ed4 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 7, 2013 at 10:26 AM, Ted Lemon wrote: > If you claim you gave a customer a /48 and the customer reports that > they are not allowed to exercise control over the use of that /48, then, > you have not, in fact, delegated authority over that /48 as you have > claimed to ARIN and that is, in fact, resource fraud in violation of ARIN > policy. I'm not sure why you think this is an absurd claim. > > > Because you haven't cited a policy that substantiates it, despite claiming > to have written the policy that would say this. > What about the APNIC policy I cited a few emails ago? You have not explained why you think it supports your point of view that using semantic bits does not make it harder for ISPs to assign /48s to users. --001a11c2c6ce2472e804de867ed4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Fri, Jun 7, 2013 at 10:26 AM, Ted Lemon <Ted.Lemon= @nominum.com> wrote:
    If you claim you gave a customer a /48 and the customer reports that they are= not allowed to exercise control over the use of that /48, then, you have n= ot, in fact, delegated authority over that /48 as you have claimed to ARIN = and that is, in fact, resource fraud in violation of ARIN policy. I'm not sure why you think this is an abs= urd claim.

    Because you haven't cited a policy that substantiates it, de= spite claiming to have written the policy that would say this.
    <= /blockquote>

    What about the APNIC policy I cited a= few emails ago? You have not explained why you think it supports your poin= t of view that using semantic bits does not make it harder for ISPs to assi= gn /48s to users.
    --001a11c2c6ce2472e804de867ed4-- From jcurran@istaff.org Thu Jun 6 13:34:44 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAF421F994A; Thu, 6 Jun 2013 13:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4xnv5mjuRP0; Thu, 6 Jun 2013 13:34:38 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 40DC721F972C; Thu, 6 Jun 2013 13:34:38 -0700 (PDT) Received: from pool-71-191-247-90.washdc.fios.verizon.net ([71.191.247.90] helo=diamond.istaff.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1UkgtB-000LPN-Lk; Thu, 06 Jun 2013 20:34:29 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 71.191.247.90 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18gjsJTc47VYH5VadW6jaU1 Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=us-ascii From: John Curran X-Priority: 1 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AC99B56@nkgeml512-mbx.china.huawei.com> Date: Thu, 6 Jun 2013 16:34:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <15AAD527-9221-4D59-BDC8-12CF3116FCE2@istaff.org> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <51A7A5B1.3050709@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99B56@nkgeml512-mbx.china.huawei.com> To: Sheng Jiang X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Thu, 06 Jun 2013 18:49:41 -0700 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Tim Chown , Lorenzo Colitti X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 20:34:44 -0000 On May 30, 2013, at 11:28 PM, Sheng Jiang wrote: > Agree. The network providers should know they cannot get more = addresses because they use their block for semantic, which lead to lower = address utility rate. >=20 > Will make this clear in the new section "potential pitfalls". Sheng -=20 It would be very helpful to put that clarifying point into the draft=20= text, i.e. ("cannot get more addresses because they use their block=20= for semantic"). Note that it would just as helpful to include the=20 converse (i.e. "ISPs should be able to get sufficiently sized address=20= blocks to allow semantic prefix use"); it really doesn't matter which phrase you include as long as the intent is clear to everyone. Your draft is very likely create less controversy if it states that one=20 cannot get more addresses automatically because of semantic use, but=20= ultimately the most important point is clarity of the intent either = way. =20 While the IETF does not set RIR policy, IETF recommendations are often=20= raised in the RIR policy development process. This means that an RFC=20= (even informational, even individual contribution) may be raised as=20 justification for why RIR policy should be changed. Clearly, a = working group output RFC and/or BCP carries more weight in the discussions = that=20 follow, but it is not inconceivable that publication of an esoteric = IPv6=20 use case (which requires larger ISP allocations) would kickoff = discussions=20 for changes to IPv6 ISP allocation policy. The tradeoffs in = appropriate management of the vast (but still fixed) IPv6 free pool will obviously=20= need to be considered, as will the actual community demand for that = type of technological solution, but recognize that the RIRs job is = facilitate,=20 not hinder, the distribution of IP addresses and that means trying to=20= accommodate whatever technical work comes out of the IETF. FYI, /John Disclaimer: My views alone. I am unaware of any formal consideration=20= by ARIN (or the IETF, for that matter) of how IETF RFC's=20 should interact with the RIR policy process, but the above ramblings reflect my best understanding of relationship. From Ted.Lemon@nominum.com Thu Jun 6 18:54:49 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEF21F0D2F; Thu, 6 Jun 2013 18:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.741 X-Spam-Level: X-Spam-Status: No, score=-106.741 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVgvBWRamFFY; Thu, 6 Jun 2013 18:54:42 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 39B9611E80A3; Thu, 6 Jun 2013 18:54:34 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUbE9WTc85TpSQgmbYJJI6Df288QEBIr1@postini.com; Thu, 06 Jun 2013 18:54:34 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id BF7761B80A0; Thu, 6 Jun 2013 18:54:33 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B511919005D; Thu, 6 Jun 2013 18:54:33 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 18:54:33 -0700 From: Ted Lemon To: Lorenzo Colitti Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAFFqgIAAA0MAgAAlngCAAERTAIAAmIuAgAAWAQCAALv5gIAAMI2AgACc9YCAACD6gIAAH1gAgACZeoCAAAjegIAAwruAgAAV84CAAAZKgIAAAigAgAC9mQCAAIcfgIAAe8GAgABs5wCAAAM+AIAABHyA Date: Fri, 7 Jun 2013 01:54:33 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C86DF@mbx-01.win.nominum.com> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> <9B71CE05-E12D-4FE9-8222-6FBFD7938F0C@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C850C@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C86DFmbx01winnominum_" MIME-Version: 1.0 Cc: "ipv6@ietf.org 6man-wg" , "v6ops@ietf.org WG" , "" , Owen DeLong X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 01:54:49 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C86DFmbx01winnominum_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jun 6, 2013, at 9:38 PM, Lorenzo Colitti > wrote: What about the APNIC policy I cited a few emails ago? You have not explaine= d why you think it supports your point of view that using semantic bits doe= s not make it harder for ISPs to assign /48s to users. The policy says that if you want to assign something bigger than a /48 to a= n end site, you have to explain why it's necessary. If you get more bits = but don't assign them to the end site, that doesn't relate to the text you = cited. If you get enough bits to assign a /48 to the end site, and assign= special meaning to some of those bits, that's not covered by the text. T= he text simply doesn't speak to this issue. I do not get the impression f= rom reading the text that semantic bits are not allowed, or that an ISP's d= esire to use semantic bits will not be accommodated. Apparently you do, b= ut I don't see it in there anywhere. Which goes back to the point I am apparently failing badly at getting acros= s: we aren't talking about a core issue here. If semantic prefixes are a = bad idea, they are a bad idea because of some reason other than bits. This is a really frustrating conversation. I don't claim to know whether = semantic prefix bits are a good idea or a bad idea. I really don't know. = I haven't heard a single convincing argument for or against them yet, bec= ause we keep beating this dead horse that there aren't enough bits, despite= the fact that there obviously are. --_000_8D23D4052ABE7A4490E77B1A012B6307751C86DFmbx01winnominum_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
    On Jun 6, 2013, at 9:38 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
    What about the APNIC policy I cited a few emails ago? You have not explained wh= y you think it supports your point of view that using semantic bits does no= t make it harder for ISPs to assign /48s to users.

    The policy says that if you want to assign something bigger than a /48= to an end site, you have to explain why it's necessary.   If you get = more bits but don't assign them to the end site, that doesn't relate to the= text you cited.   If you get enough bits to assign a /48 to the end site, and assign special meaning to some o= f those bits, that's not covered by the text.   The text simply doesn'= t speak to this issue.   I do not get the impression from reading the = text that semantic bits are not allowed, or that an ISP's desire to use semantic bits will not be accommodated.  = Apparently you do, but I don't see it in there anywhere.

    Which goes back to the point I am apparently failing badly at getting = across: we aren't talking about a core issue here.   If semantic prefi= xes are a bad idea, they are a bad idea because of some reason other than b= its.

    This is a really frustrating conversation.   I don't claim to kno= w whether semantic prefix bits are a good idea or a bad idea.   I real= ly don't know.   I haven't heard a single convincing argument for or a= gainst them yet, because we keep beating this dead horse that there aren't enough bits, despite the fact that there obviously= are.

    --_000_8D23D4052ABE7A4490E77B1A012B6307751C86DFmbx01winnominum_-- From lorenzo@google.com Thu Jun 6 19:41:10 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF37121F91B7 for ; Thu, 6 Jun 2013 19:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.043 X-Spam-Level: X-Spam-Status: No, score=-3.043 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQkmG4QWz6UM for ; Thu, 6 Jun 2013 19:41:05 -0700 (PDT) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id 77C1821F91B1 for ; Thu, 6 Jun 2013 19:41:05 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id f6so2415580qej.37 for ; Thu, 06 Jun 2013 19:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NzK6q3l20fppmKSNAD/6HFCMz7irzfghOsBlixoyB6A=; b=Eaz1yvitujfqAqwdR2BBxUq33DISJzPhDujaEsRY1gl2dV9blYe134E9CZTriwdHaR hbiUdzhWcGAOAfjYfr3ccZmYt/88UDLFYrzig0FLaplk5bLUt1Od0b2u9hbIyaxHRqN0 4zLFdP29ZKP5itF3Ho86ws2coTbdYV3jGV/XsQ2OIuUJ1iKIcRzyF0sALJtXLd2B7mfK HcT85nVhjTPchajDwTkFq9/Bis+ZvuQk45DzmlUcB2HLZy5B6SgAr6lFfppyycwq2clS e1001EBEsebmba+d2lNJt3d+suQrkxDtV/kVZ0RnrveHWoZYcYPgOOgKFJTOyX2WuYB9 XxaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=NzK6q3l20fppmKSNAD/6HFCMz7irzfghOsBlixoyB6A=; b=BtZds7kL/cRpv8SRC5eVnJdRGD7XWvyP9kvXS8qX36uiRVo7Ug33X0VKN2GUwIfhjF DsOiN+AN4T9O5ILuoLgdvwGcLLUsOQsb3ZXTJRums98VLE/wFNAp/sAJLIZSzZUpOwEt 3Sf51I0kfcwp27awdBLrTevmsIVuuGCCZ94Wa2eGtd44QgxK+a3xYJfas11JGVG32IOI q8ortTvWd2vIqGosbbQxbnYJ96c+V9zP/2lrFPIh2N0IrZC2pR2HIf9qMJDuqWEBr75c k74fQM10ru8nOmnn9FT5SL3WLXCYkPgOpBL2qxAPFolGZRP3epQDec4qO3D6pC76CTG1 8FNQ== X-Received: by 10.224.98.65 with SMTP id p1mr524955qan.70.1370572859694; Thu, 06 Jun 2013 19:40:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.158.8 with HTTP; Thu, 6 Jun 2013 19:40:37 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C86DF@mbx-01.win.nominum.com> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> <9B71CE05-E12D-4FE9-8222-6FBFD7938F0C@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C850C@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C86DF@mbx-01.win.nominum.com> From: Lorenzo Colitti Date: Fri, 7 Jun 2013 11:40:37 +0900 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf3074d9a470fdeb04de875c1c X-Gm-Message-State: ALoCoQm6vsNB/xUc8d7S0UWAsaPtT2VjN8RKWR6mGKSU6XjAprRzdpnUYK0nn82PP6fCr74JcUj8VJz7wsknNI2Do9HEf3ulR5KB5hT2vICJv5wlyzQyMEl2rImfVlWnxaaTEMJDqmNhCHQiT//SHItDth9b8x4GUzIhz2G3uxxTJ/a358lzd5Jj3I2SVVMChJJbVkBmTFIk Cc: "ipv6@ietf.org 6man-wg" , "v6ops@ietf.org WG" , "" , Owen DeLong X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 02:41:10 -0000 --20cf3074d9a470fdeb04de875c1c Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 7, 2013 at 10:54 AM, Ted Lemon wrote: > What about the APNIC policy I cited a few emails ago? You have not > explained why you think it supports your point of view that using semantic > bits does not make it harder for ISPs to assign /48s to users. > > > The policy says that if you want to assign something bigger than a /48 to > an end site, you have to explain why it's necessary. > For each and every end site ("when a single end site requires..."). To me, that sounds like it could turn into reams of busywork which would act as a disincentive to doing this. > If you get more bits but don't assign them to the end site, that doesn't > relate to the text you cited. > Absolutely, as long as you have address space to use. But if you assign a /48 to every end site but then *use more* than a /48 for those end sites (say, 4x more because you're using 2 bits of semantic prefixes), then it's possible/likely that you won't be able to get more space in the future, because the utilization criteria are based on the /48s that you do assign to the end sites. > If you get enough bits to assign a /48 to the end site, and assign special > meaning to some of those bits, that's not covered by the text. The text > simply doesn't speak to this issue. > Section 2.6 says "To assign means to delegate address space to an ISP or end-user". I think it could be reasonably argued that "delegate" means that the delegating party does not control anything about those bits any more (basically, Owen's argument). You could also argue the other way, of course, but we do have to recognize that existing policies do not clearly state whether this is possible. > I do not get the impression from reading the text that semantic bits are > not allowed, or that an ISP's desire to use semantic bits will not be > accommodated. > Nobody ever said they weren't allowed, just as nobody ever said you can't assign an IPv4 /24 to every residential user for privacy reasons. What I am saying is that if you choose to do so, you will likely find it hard to get additional address space because the RIRs are likely to consider that you are not making efficient use of the space you have. The reason I keep going on and on about this because I really think this should be reflected in the text of this document. These bits are not free in the way that DSCP bits are free. They come at a cost: a cost of using more address space (yes, hard to measure, we have plenty of space, etc. etc. - until we run out), and an opportunity cost because under RIR policies it's likely that users will have to get less address space than they would otherwise get. I am saying that the document should clearly state this cost, lest people think this is a free lunch, and should compare that cost to other options such as using the DSCP bits. > Which goes back to the point I am apparently failing badly at getting > across: we aren't talking about a core issue here. If semantic prefixes > are a bad idea, they are a bad idea because of some reason other than bits. > > This is a really frustrating conversation. I don't claim to know > whether semantic prefix bits are a good idea or a bad idea. I really > don't know. I haven't heard a single convincing argument for or against > them yet, because we keep beating this dead horse that there aren't enough > bits, despite the fact that there obviously are. > Like almost everything things in engineering, it's a cost/benefit tradeoff. This discussion about "not enough bits" is simply attempting to quantify some of the costs involved. I keep harping about it because the cost is NOT zero, and I think the document should cite that cost and compare the costs/benefits to alternative approaches like using DSCP (which *does* have zero cost in addressing). We do that analysis, we write it down, and then we can decide if it's a good idea or not. Cheers, Lorenzo --20cf3074d9a470fdeb04de875c1c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Fri, Jun 7, 2013 at 10:54 AM, Ted Lemon <Ted.Lemon= @nominum.com> wrote:
    What about the APNIC policy I cited a few emails ago? You have not explained wh= y you think it supports your point of view that using semantic bits does no= t make it harder for ISPs to assign /48s to users.

    The policy says that if you want to assign something bigger than= a /48 to an end site, you have to explain why it's necessary.

    For each and every end site (&quo= t;when a single end site requires..."). To me, that sounds like it cou= ld turn into reams of busywork which would act as a disincentive to doing t= his.
    =A0
    If = you get more bits but don't assign them to the end site, that doesn'= ;t relate to the text you cited.

    Absolutely, as long as you hav= e address space to use. But if you assign a /48 to every end site but then = *use more* than a /48 for those end sites (say, 4x more because you're = using 2 bits of semantic prefixes), then it's possible/likely that you = won't be able to get more space in the future, because the utilization = criteria are based on the /48s that you do assign to the end sites.
    =A0
    If = you get enough bits to assign a /48 to the end site, and assign special meaning to some o= f those bits, that's not covered by the text. =A0 The text simply doesn= 't speak to this issue.

    Section 2.6 says "To assign means to delegate address space to an ISP = or end-user". I think it could be reasonably argued that "delegat= e" means that the delegating party does not control anything about tho= se bits any more (basically, Owen's argument). You could also argue the= other way, of course, but we do have to recognize that existing policies d= o not clearly state whether this is possible.
    =A0
    I d= o not get the impression from reading the text that semantic bits are not a= llowed, or that an ISP's desire to use semantic bits will not be accommodated.

    Nobody ever said they weren= 't allowed, just as nobody ever said you can't assign an IPv4 /24 t= o every residential user for privacy reasons. What I am saying is that if y= ou choose to do so, you will likely find it hard to get additional address = space because the RIRs are likely to consider that you are not making effic= ient use of the space you have.

    The reason I keep going on and on about thi= s because I really think this should be reflected in the text of this docum= ent. These bits are not free in the way that DSCP bits are free. They come = at a cost: a cost of using more address space (yes, hard to measure, we hav= e plenty of space, etc. etc. - until we run out), and an opportunity cost b= ecause under RIR policies it's likely that users will have to get less = address space than they would otherwise get.

    I am saying that the document should clearl= y state this cost, lest people think this is a free lunch, and should compa= re that cost to other options such as using the DSCP bits.
    =A0
    Which goes back to the point I am apparently failing badly at getting = across: we aren't talking about a core issue here. =A0 If semantic pref= ixes are a bad idea, they are a bad idea because of some reason other than = bits.

    This is a really frustrating conversation. =A0 I don't claim to kn= ow whether semantic prefix bits are a good idea or a bad idea. =A0 I really= don't know. =A0 I haven't heard a single convincing argument for o= r against them yet, because we keep beating this dead horse that there aren't enough bits, despite the fact that there obvio= usly are.

    Like almost everything thi= ngs in engineering, it's a cost/benefit tradeoff. This discussion about= "not enough bits" is simply attempting to quantify some of the c= osts involved. I keep harping about it because the cost is NOT zero, and I = think the document should cite that cost and compare the costs/benefits to = alternative approaches like using DSCP (which *does* have zero cost in addr= essing). We do that analysis, we write it down, and then we can decide if i= t's a good idea or not.

    Cheers,
    Lorenzo
    =
    --20cf3074d9a470fdeb04de875c1c-- From jiangsheng@huawei.com Thu Jun 6 19:42:55 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E490511E80A4; Thu, 6 Jun 2013 19:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rd5lVVIxNfk; Thu, 6 Jun 2013 19:42:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7295A21F8FCB; Thu, 6 Jun 2013 19:42:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATQ47496; Fri, 07 Jun 2013 02:42:47 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 7 Jun 2013 03:41:53 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 7 Jun 2013 10:42:44 +0800 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.01.0323.007; Fri, 7 Jun 2013 10:42:40 +0800 From: Sheng Jiang To: Owen DeLong , Sheng Jiang Subject: RE: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOYqIreYB7EHmXR0+A7JbK0DaUI5kof3AAgAEHRrA= Date: Fri, 7 Jun 2013 02:42:39 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC9D21B@nkgeml512-mbx.china.huawei.com> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <021E64FECA7E5A4699562F4E6671648103DE44@XCH-PHX-503.sw.nos.boeing.com> <8D23D4052ABE7A4490E77B1A012B6307751C62A3@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" , Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 02:42:56 -0000 Pj4gWWVzLCB0aGlzIGRpc2N1c3Npb24gaGFzIGJlY29tZSBmYXIgd2F5IGZyb20gbXkgb3JpZ2lu YWwgbW90aXZhdGlvbiBvZg0KPmFuYWx5c2luZyBzZW1hbnRpYyBwcmVmaXggbWVjaGFuaXNtLiBJ IGFtIGdvaW5nIHRvIHN0b3AgcmVwbHlpbmcgdG8gdGhlDQo+ZGlzY3VzcyByZWdhcmRpbmcgdG8g dGhlIGF2YWliaWxpdGllcyBvZiBiaXRzLiBJbiB0aGUgZnV0dXJlIHZlcnNpb24sIEkgd2lsbCBh ZGQgdGhlDQo+Yml0cyBjb25zdW1wdGlvbiBhcyBvbmUgb2YgdGhlIHBpdGZhbGxzLg0KPj4NCj4+ IEJ5IHRoZSB3YXksIElTUHMgYXJlIG9ubHkgb25lIGtpbmQgb2YgbmV0d29yayBvcGVyYXRvcnMg d2hvIGFyZSBpbnRlcmVzdGluZw0KPmluIHNlbWFudGljIHByZWZpeC4gRW50ZXJwcmlzZSBuZXR3 b3JrIG9wZXJhdG9ycyBhcmUgYW5vdGhlciBncm91cCBvZg0KPm5ldHdvcmsgb3BlcmF0b3JzIHdo byBjYW4gYmVuZWZpdCBmcm9tIGVtYmVkZGVkIHNlbWFudGljcy4gQW5kIHRoZQ0KPmVudGVycHJp c2VzIGRvIG5vdCBoYXZlIHN1YnNjcmliZXJzIHdobyBwb3RlbnRpYWxseSBuZWVkIGV4dHJhIGJp dHMuDQo+DQo+WW91ciB1c2Ugb2YgdGhlIHdvcmQgImJlbmVmaXQiIGhlcmUgaXMgcXVlc3Rpb25h YmxlIGF0IGJlc3QuIEl0IGlzIGFuIGV4YW1wbGUgb2YNCj5sYW5ndWFnZSB0aGF0IHNlZW1zIHRv IGVuY291cmFnZSB0aGlzIHVzZSByYXRoZXIgdGhhbiBldmFsdWF0ZSBpdCBpbiBhbg0KPnVuYmlh c2VkIG1hbm5lci4NCj4NCj4iRW50ZXJwcmlzZSBvcGVyYXRvcnMgYXJlIGFub3RoZXIgZ3JvdXAg b2YgbmV0d29yayBvcGVyYXRvcnMgd2hpY2ggbWF5DQo+c3VjY3VtYiB0byB0aGlzIG5hc3R5IHBp dGZhbGwgb2YgZW1iZWRkZWQgc2VtYW50aWNzIiB3b3VsZCBiZSAgYW4gZXF1YWxseQ0KPmJpYXNl ZCBzdGF0ZW1lbnQgaW4gdGhlIG9wcG9zaXRlIGRpcmVjdGlvbi4NCj4NCj5JIHN1Z2dlc3QgdGhh dCBuZXV0cmFsIHdvdWxkIHJlcXVpcmUgc29tZXRoaW5nIG1vcmUgYWxvbmcgdGhlIGxpbmVzIG9m Og0KPg0KPiJFbnRlcnByaXNlIG9wZXJhdG9ycyBhcmUgYW5vdGhlciBncm91cCBvZiBuZXR3b3Jr IG9wZXJhdG9ycyB3aGljaCBtYXkNCj5jaG9vc2UgdG8gZW1iZWQgc2VtYW50aWNzIGluIHRoZWly IGFkZHJlc3MgcHJlZml4ZXMuIg0KPg0KPk5vdywgaW4gdGVybXMgb2YgYXJndWluZyB0aGUgbWVy aXRzLCB0aGVyZSBhcmUgc2lnbmlmaWNhbnQgZGlmZmVyZW5jZXMgYmV0d2Vlbg0KPnRoZXNlIHR3 by4gSW4gdGhlIGNhc2Ugb2YgYW4gZW50ZXJwcmlzZSBvcGVyYXRvciwgdGhlaXIgY2hvaWNlIHRv IGVtYmVkDQo+c2VtYW50aWNzIGluIHRoZSBhZGRyZXNzIGhhcyBhIGxpbWl0ZWQgc2NvcGUgb2Yg aGFybS4gSXQgY2FuIG9ubHkgbmVnYXRpdmVseQ0KPmltcGFjdCBzYWlkIGVudGVycHJpc2UuDQo+ DQo+SW4gdGhlIGNhc2Ugb2YgYW4gSVNQLCB0aGlzIGNhbiBoYXZlIHNpZ25pZmljYW50IGNvbnNl cXVlbmNlcyBub3Qgb25seSBmb3IgdGhlDQo+SVNQLCBidXQgYWxzbyBmb3IgdGhlaXIgZG93bnN0 cmVhbSBjdXN0b21lcnMuDQoNCkhpLCBPd2VuLA0KDQpJIHRha2UgdGhpcyBhcyBtdWNoIG1vcmUg dXNlZnVsIGRpc2N1c3Npb24gdGhhbiBiaXQgYXZhaWxhYmlsaXR5LiBJIHNoYXJlIHlvdXIgb3Bp bmlvbiB0aGF0IElTUHMgc2hvdWxkIGJlIG11Y2ggbW9yZSBjYXJlZnVsbHkgYXMgdGhlaXIgd2ls bCBiZSBjb25zZXF1ZW5jZXMgZm9yIGRvd25zdHJlYW0gY3VzdG9tZXJzLCBjb21wYXJpbmcgdG8g ZW50ZXJwcmlzZS4gVGhlc2Ugd2lsbCBiZSBpbmNsdWRlZCBpbnRvIHRoZSBmdXR1cmUgdmVyc2lv bi4gOikNCg0KQXMgYSBuZXV0cmFsIGFuYWx5c2lzLCBpdCBpcyBmaW5lIHRvIHNheSB0aGVyZSBh cmUgYmVuZWZpdHMgYW5kIHBpdGZhbGxzLiBBbGwgZ29vZCB0aGluZ3MgY29tZSB3aXRoIGNvc3Rz LiBJIHdpbGwgbWFrZSBzdXJlIHdlIGRvY3VtZW50IGJvdGggc2lkZXMgaW4gdGhlIGRyYWZ0Lg0K DQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCg0KPk93ZW4NCg0K From jiangsheng@huawei.com Thu Jun 6 20:44:39 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203CF21F9285; Thu, 6 Jun 2013 20:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OC3+k3S7Uqb7; Thu, 6 Jun 2013 20:44:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2360721F926E; Thu, 6 Jun 2013 20:44:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASE49967; Fri, 07 Jun 2013 03:44:18 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 7 Jun 2013 04:43:20 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 7 Jun 2013 04:44:16 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Fri, 7 Jun 2013 11:44:10 +0800 From: Sheng Jiang To: John Curran Subject: RE: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXDsZXTVBYam7gkul8TB7nKV985kcQnwAgAB+FQCAAAQAgIAA0WeAgAEOlHCACgdZgIAA9U7A Date: Fri, 7 Jun 2013 03:44:08 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC9D3A2@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <51A7A5B1.3050709@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99B56@nkgeml512-mbx.china.huawei.com> <15AAD527-9221-4D59-BDC8-12CF3116FCE2@istaff.org> In-Reply-To: <15AAD527-9221-4D59-BDC8-12CF3116FCE2@istaff.org> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" , Tim Chown , Lorenzo Colitti X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 03:44:39 -0000 Pj4gQWdyZWUuIFRoZSBuZXR3b3JrIHByb3ZpZGVycyBzaG91bGQga25vdyB0aGV5IGNhbm5vdCBn ZXQgbW9yZSBhZGRyZXNzZXMNCj5iZWNhdXNlIHRoZXkgdXNlIHRoZWlyIGJsb2NrIGZvciBzZW1h bnRpYywgd2hpY2ggbGVhZCB0byBsb3dlciBhZGRyZXNzIHV0aWxpdHkNCj5yYXRlLg0KPj4NCj4+ IFdpbGwgbWFrZSB0aGlzIGNsZWFyIGluIHRoZSBuZXcgc2VjdGlvbiAicG90ZW50aWFsIHBpdGZh bGxzIi4NCj4NCj5TaGVuZyAtDQo+DQo+ICBJdCB3b3VsZCBiZSB2ZXJ5IGhlbHBmdWwgdG8gcHV0 IHRoYXQgY2xhcmlmeWluZyBwb2ludCBpbnRvIHRoZSBkcmFmdA0KPiAgdGV4dCwgIGkuZS4gKCJj YW5ub3QgZ2V0IG1vcmUgYWRkcmVzc2VzIGJlY2F1c2UgdGhleSB1c2UgdGhlaXIgYmxvY2sNCj4g IGZvciBzZW1hbnRpYyIpLiBOb3RlIHRoYXQgaXQgd291bGQganVzdCBhcyBoZWxwZnVsIHRvIGlu Y2x1ZGUgdGhlDQo+ICBjb252ZXJzZSAoaS5lLiAiSVNQcyBzaG91bGQgYmUgYWJsZSB0byBnZXQg c3VmZmljaWVudGx5IHNpemVkIGFkZHJlc3MNCj4gIGJsb2NrcyB0byBhbGxvdyBzZW1hbnRpYyBw cmVmaXggdXNlIik7IGl0IHJlYWxseSBkb2Vzbid0IG1hdHRlciB3aGljaA0KPiAgcGhyYXNlIHlv dSBpbmNsdWRlIGFzIGxvbmcgYXMgdGhlIGludGVudCBpcyBjbGVhciB0byBldmVyeW9uZS4gIFlv dXINCj4gIGRyYWZ0IGlzIHZlcnkgbGlrZWx5IGNyZWF0ZSBsZXNzIGNvbnRyb3ZlcnN5IGlmIGl0 IHN0YXRlcyB0aGF0IG9uZQ0KPiAgY2Fubm90IGdldCBtb3JlIGFkZHJlc3NlcyBhdXRvbWF0aWNh bGx5IGJlY2F1c2Ugb2Ygc2VtYW50aWMgdXNlLCBidXQNCj4gIHVsdGltYXRlbHkgdGhlIG1vc3Qg aW1wb3J0YW50IHBvaW50IGlzIGNsYXJpdHkgb2YgdGhlIGludGVudCBlaXRoZXIgd2F5Lg0KPg0K PiAgV2hpbGUgdGhlIElFVEYgZG9lcyBub3Qgc2V0IFJJUiBwb2xpY3ksIElFVEYgcmVjb21tZW5k YXRpb25zIGFyZSBvZnRlbg0KPiAgcmFpc2VkIGluIHRoZSBSSVIgcG9saWN5IGRldmVsb3BtZW50 IHByb2Nlc3MuIFRoaXMgbWVhbnMgdGhhdCBhbiBSRkMNCj4gIChldmVuIGluZm9ybWF0aW9uYWws IGV2ZW4gaW5kaXZpZHVhbCBjb250cmlidXRpb24pIG1heSBiZSByYWlzZWQgYXMNCj4gIGp1c3Rp ZmljYXRpb24gZm9yIHdoeSBSSVIgcG9saWN5IHNob3VsZCBiZSBjaGFuZ2VkLiAgQ2xlYXJseSwg YSB3b3JraW5nDQo+ICBncm91cCBvdXRwdXQgUkZDIGFuZC9vciBCQ1AgY2FycmllcyBtb3JlIHdl aWdodCBpbiB0aGUgZGlzY3Vzc2lvbnMgdGhhdA0KPiAgZm9sbG93LCBidXQgaXQgaXMgbm90IGlu Y29uY2VpdmFibGUgdGhhdCBwdWJsaWNhdGlvbiBvZiBhbiBlc290ZXJpYyBJUHY2DQo+ICB1c2Ug Y2FzZSAod2hpY2ggcmVxdWlyZXMgbGFyZ2VyIElTUCBhbGxvY2F0aW9ucykgd291bGQga2lja29m ZiBkaXNjdXNzaW9ucw0KPiAgZm9yIGNoYW5nZXMgdG8gSVB2NiBJU1AgYWxsb2NhdGlvbiBwb2xp Y3kuICBUaGUgdHJhZGVvZmZzIGluIGFwcHJvcHJpYXRlDQo+ICBtYW5hZ2VtZW50IG9mIHRoZSB2 YXN0IChidXQgc3RpbGwgZml4ZWQpIElQdjYgZnJlZSBwb29sIHdpbGwgb2J2aW91c2x5DQo+ICBu ZWVkIHRvIGJlIGNvbnNpZGVyZWQsIGFzIHdpbGwgdGhlIGFjdHVhbCBjb21tdW5pdHkgZGVtYW5k IGZvciB0aGF0IHR5cGUNCj4gIG9mIHRlY2hub2xvZ2ljYWwgc29sdXRpb24sIGJ1dCByZWNvZ25p emUgdGhhdCB0aGUgUklScyBqb2IgaXMgZmFjaWxpdGF0ZSwNCj4gIG5vdCBoaW5kZXIsIHRoZSBk aXN0cmlidXRpb24gb2YgSVAgYWRkcmVzc2VzIGFuZCB0aGF0IG1lYW5zIHRyeWluZyB0bw0KPiAg YWNjb21tb2RhdGUgd2hhdGV2ZXIgdGVjaG5pY2FsIHdvcmsgY29tZXMgb3V0IG9mIHRoZSBJRVRG Lg0KDQpIaSwgSm9obiwNCg0KVGhhbmtzIGZvciB5b3VyIG1lc3NhZ2UuIFllcywgSSB3aWxsIGFk ZCBsb3dlciBhZGRyZXNzIHV0aWxpdHkgcmF0ZSBhcyBvbmUgb2YgdGhlIG1ham9yIHBpdGZhbGxz LiBIb3dldmVyLCBJIGRvbid0IHdhbnQgdG8gbWFrZSBhbiBhYnNvbHV0ZSBzdGF0ZW1lbnQgb2Yg ImNhbm5vdCIuIEFzIGEgbmV1dHJhbCBhbmFseXNpcywgaXQgaXMgYmV0dGVyIHRvIGp1c3QgbWFr ZSBvYnNlcnZhdGlvbiwgc3VjaCBhcyAidGhlcmUgaXMgcmlzayB0aGF0IHRoZXkgbWF5IG5vdCIu IFdlIGRvIG5vdCB3YW50IHRvIGluZmx1ZW5jZSB0aGUgUklSIHBvbGljeSBlaXRoZXIgd2F5LCB3 aGljaCB3b3VsZCBiZSBxdWl0ZSBjb250cm92ZXJzaWFsLiBJdCBpcyBiZXR0ZXIgd2UgZG8gbm90 IHRvdWNoIHRoaXMuDQoNCkNoZWVycywNCg0KU2hlbmcNCg0KPkZZSSwNCj4vSm9obg0KPg0KPkRp c2NsYWltZXI6ICBNeSB2aWV3cyBhbG9uZS4gIEkgYW0gdW5hd2FyZSBvZiBhbnkgZm9ybWFsIGNv bnNpZGVyYXRpb24NCj4gICAgICAgICAgICAgYnkgQVJJTiAob3IgdGhlIElFVEYsIGZvciB0aGF0 IG1hdHRlcikgb2YgaG93IElFVEYgUkZDJ3MNCj4gICAgICAgICAgICAgc2hvdWxkIGludGVyYWN0 IHdpdGggdGhlIFJJUiBwb2xpY3kgcHJvY2VzcywgYnV0IHRoZSBhYm92ZQ0KPiAgICAgICAgICAg ICByYW1ibGluZ3MgcmVmbGVjdCBteSBiZXN0IHVuZGVyc3RhbmRpbmcgb2YgcmVsYXRpb25zaGlw Lg0KDQo= From jcurran@istaff.org Thu Jun 6 21:57:45 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4C921F8EB1; Thu, 6 Jun 2013 21:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHxVGRGfbi2j; Thu, 6 Jun 2013 21:57:10 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id B1DAF21F8EB2; Thu, 6 Jun 2013 21:57:07 -0700 (PDT) Received: from pool-71-191-247-90.washdc.fios.verizon.net ([71.191.247.90] helo=diamond.istaff.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Ukojb-0000ap-0x; Fri, 07 Jun 2013 04:57:07 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 71.191.247.90 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18lEof+JM8JjxrVPMaWBmrI Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: John Curran In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AC9D3A2@nkgeml512-mbx.china.huawei.com> Date: Fri, 7 Jun 2013 00:57:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5F9F072A-2047-4A53-B21E-6FF8F8C8FEDA@istaff.org> References: <5D36713D8A4E7348A7E10DF7437A4B923AC98DAE@nkgeml512-mbx.china.huawei.com> <03680813-07D9-459B-A229-FA974C9A4B9E@ecs.soton.ac.uk> <8E492087-390E-4F8E-8078-1D0E63849243@delong.com> <51A7A5B1.3050709@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B923AC99B56@nkgeml512-mbx.china.huawei.com> <15AAD527-9221-4D59-BDC8-12CF3116FCE2@istaff.org> <5D36713D8A4E7348A7E10DF7437A4B923AC9D3A2@nkgeml512-mbx.china.huawei.com> To: Sheng Jiang X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Thu, 06 Jun 2013 22:02:48 -0700 Cc: "" , "draft-jiang-v6ops-semantic-prefix@tools.ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 04:57:46 -0000 On Jun 6, 2013, at 11:44 PM, Sheng Jiang wrote: > Hi, John, >=20 > Thanks for your message. Yes, I will add lower address utility rate as = one of the major pitfalls. However, I don't want to make an absolute = statement of "cannot". As a neutral analysis, it is better to just make = observation, such as "there is risk that they may not". We do not want = to influence the RIR policy either way, which would be quite = controversial. It is better we do not touch this. Sheng -=20 =20 Yes, I see your point that "cannot get more addresses because they use=20= their block for semantic" would be considered an absolute directive. = On=20 the other hand, we do want to be clear about the high possibility that=20= they will not be able to obtain additional address based on semantic = use,=20 so a simple warning that incorporates both lower utility rate and the = risk of being potentially unable to obtain more address should suffice. = Such=20 a statement in the draft would let the discussion continue focused on = the technical aspects of semantic prefixes, provides a fair warning to = anyone=20 adopting the technology, and yet keeps open the possibility of any = outcome=20 from future RIR discussions of this technology. Thanks! /John Disclaimers: My views alone. No semantics are encoded in my underlying=20= network packets (I already have enough work keeping useful=20= semantic meaning at the application layer... :-) =20 From richih.mailinglist@gmail.com Thu Jun 6 23:03:14 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919A921F91BC; Thu, 6 Jun 2013 23:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xq6a1Pv91S-k; Thu, 6 Jun 2013 23:03:14 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 617C121F91BF; Thu, 6 Jun 2013 23:03:13 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id j13so2747214wgh.33 for ; Thu, 06 Jun 2013 23:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lqKl/P9qrwjme9Sh8yCnpbNxZt/aU5NxH/VA4uTCmEk=; b=ulv5FtKmxQyBPzsMsABRFHm0CCrWnCiOpcAYJp09TaKcNQKY3BVPQXnuM9g+bqb6MC SQwC7utMOtc367TlcULsFxeZb7cUlpkQKR8y2yL4JD7TbE19rTevPGN0rnSwo7Xp7jaa NVezOwDX0CTo+ZcNhDR8p9BaFvevOHBPC1lzMjL8LIsFspYXY7GVYRiPu4STto+TjU3Y Kh06ssuaAkpHIgw76I+upCzOglb5QG5finhJNMI3bFyBFCVX7Vy47Q5GX5O7lHxLI8gQ wYzbiCh3AS4wBd1SV9R5H6iTHvseCC/BwJroFtX0l7cnxM2j8GX8VEG7WjIBg67lUvbL IzbQ== MIME-Version: 1.0 X-Received: by 10.180.11.166 with SMTP id r6mr560990wib.45.1370584992424; Thu, 06 Jun 2013 23:03:12 -0700 (PDT) Received: by 10.194.17.9 with HTTP; Thu, 6 Jun 2013 23:03:11 -0700 (PDT) Received: by 10.194.17.9 with HTTP; Thu, 6 Jun 2013 23:03:11 -0700 (PDT) In-Reply-To: <9B71CE05-E12D-4FE9-8222-6FBFD7938F0C@delong.com> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> <9B71CE05-E12D-4FE9-8222-6FBFD7938F0C@delong.com> Date: Fri, 7 Jun 2013 08:03:11 +0200 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Richard Hartmann To: Owen DeLong Content-Type: multipart/alternative; boundary=001a11c248f09bc4d404de8a2fe9 Cc: "v6ops@ietf.org WG" , "<, draft-jiang-v6ops-semantic-prefix@tools.ietf.org>, " , 6man List , Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 06:03:14 -0000 --001a11c248f09bc4d404de8a2fe9 Content-Type: text/plain; charset=UTF-8 On Jun 6, 2013 8:58 PM, "Owen DeLong" wrote: > While my statements in this forum are my opinion alone and not intended to represent ARIN or the AC, I think I bring a pretty good knowledge of both the letter and the intent of the policies as they exist today. Thus, it should be easy for you to point out where the policy says this. And easier to point to a discussion about the intent. > If you claim you gave a customer a /48 and the customer reports that they are not allowed to exercise control over the use of that /48, then, you have not, in fact, delegated authority over that /48 as you have claimed to ARIN and that is, in fact, resource fraud in violation of ARIN policy. I'm not sure why you think this is an absurd claim. While the customer may be allowed to use their prefix where and how they please, the policy says nothing about forcing the ISP to route everything everywhere. The ISP would not disallow usage in any way, they would simply not route according to arbitrary whims which are against their semantic policy. As an aside, handing out /56 per customer and semantic unit will most likely solve any real world problems. And if the customer really needs more than 256 semantic contexts, or more than 256 /64 per semantic context, the LIR can probably document and prove the need for more than a /48... Richard Sent by mobile; excuse my brevity. --001a11c248f09bc4d404de8a2fe9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

    On Jun 6, 2013 8:58 PM, "Owen DeLong" <owen@delong.com> wrote:

    > While my statements in this forum are my opinion alone = and not intended to represent ARIN or the AC, I think I bring a pretty good= knowledge of both the letter and the intent of the policies as they exist = today.

    Thus, it should be easy for you to point out where the polic= y says this. And easier to point to a discussion about the intent.

    > If you claim you gave a customer a /48 and the customer= reports that they are not allowed to exercise control over the use of that= /48, then, you have not, in fact, delegated authority over that /48 as you= have claimed to ARIN and that is, in fact, resource fraud in violation of = ARIN policy. I'm not sure why you think this is an absurd claim.

    While the customer may be allowed to use their prefix where = and how they please, the policy says nothing about forcing the ISP to route= everything everywhere.
    The ISP would not disallow usage in any way, they would simply not route ac= cording to arbitrary whims which are against their semantic policy.

    As an aside, handing out /56 per customer and semantic unit = will most likely solve any real world problems. And if the customer really = needs more than 256 semantic contexts, or more than 256 /64 per semantic co= ntext, the LIR can probably document and prove the need for more than a /48= ...

    Richard

    Sent by mobile; excuse my brevity.

    --001a11c248f09bc4d404de8a2fe9-- From ietfc@btconnect.com Fri Jun 7 01:18:53 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28A221F94F9 for ; Fri, 7 Jun 2013 01:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7FMMZavDLzm for ; Fri, 7 Jun 2013 01:18:46 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0189.outbound.messaging.microsoft.com [213.199.154.189]) by ietfa.amsl.com (Postfix) with ESMTP id DAD9521F9485 for <6man@ietf.org>; Fri, 7 Jun 2013 01:18:44 -0700 (PDT) Received: from mail109-db8-R.bigfish.com (10.174.8.246) by DB8EHSOBE004.bigfish.com (10.174.4.67) with Microsoft SMTP Server id 14.1.225.23; Fri, 7 Jun 2013 08:18:43 +0000 Received: from mail109-db8 (localhost [127.0.0.1]) by mail109-db8-R.bigfish.com (Postfix) with ESMTP id 73859202AA; Fri, 7 Jun 2013 08:18:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.181; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0711HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zzbb2dI98dI9371I103dK542I1432I1418I62a3Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275ch1033IL6d524h8275bh8275dhz2dh2a8h5a9h668h839h946hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail109-db8 (localhost.localdomain [127.0.0.1]) by mail109-db8 (MessageSwitch) id 1370593121609615_13408; Fri, 7 Jun 2013 08:18:41 +0000 (UTC) Received: from DB8EHSMHS003.bigfish.com (unknown [10.174.8.246]) by mail109-db8.bigfish.com (Postfix) with ESMTP id 88A9A2C00C3; Fri, 7 Jun 2013 08:18:41 +0000 (UTC) Received: from AMSPRD0711HT004.eurprd07.prod.outlook.com (157.56.250.181) by DB8EHSMHS003.bigfish.com (10.174.4.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 7 Jun 2013 08:18:41 +0000 Received: from DBXPRD0411HT005.eurprd04.prod.outlook.com (157.56.253.165) by pod51017.outlook.com (10.242.14.165) with Microsoft SMTP Server (TLS) id 14.16.311.1; Fri, 7 Jun 2013 08:18:41 +0000 Message-ID: <015c01ce6356$cd7112c0$4001a8c0@gateway.2wire.net> From: t.petch To: Fernando Gont , Alissa Cooper References: <72fb5db097d443eebb554cdc43d7a01f@BY2PR03MB269.namprd03.prod.outlook.com><519AD0EF.60600@si6networks.com><87b8552e4b4a479dbfca94bd88a09ce7@BY2PR03MB269.namprd03.prod.outlook.com><519F3364.80301@si6networks.com><51A207B0.4000900@si6networks.com><51A93EEE.7080902@gont.com.ar><6AD05DBB-1067-4F4D-996C-CAB7FEF0184F@cdt.org><51AFE3AF.1050300@si6networks.com> <51B0EAE1.5080006@si6networks.com> Subject: Re: Comments on draft-ietf-6man-stable-privacy-addresses-07 Date: Fri, 7 Jun 2013 09:12:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.165] X-OriginatorOrg: btconnect.com Cc: 6man-chairs@tools.ietf.org, Brian Haberman , 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 08:18:53 -0000 ----- Original Message ----- From: "Fernando Gont" To: "Alissa Cooper" Cc: <6man-chairs@tools.ietf.org>; "Brian Haberman" ; <6man@ietf.org>; "Dave Thaler" ; "Ray Hunter" ; "Fernando Gont" ; "tom.petch" ; "Christian Huitema" ; "He Xuan" Sent: Thursday, June 06, 2013 9:02 PM On 06/06/2013 03:40 PM, Alissa Cooper wrote: >> For instance, Section B.1 explicitly says so (and this type of >> attack is not meant to be solved by stable-privacy-addresses). > I realize how this organization came about > but it seems like it would make a little more sense to have each of > the distinct threat models clearly described in one place in the body > of the document, followed by a discussion of which threats the > mechanism mitigates and which it does not. I'd personally prefer this not to be in the body of the document. For the most part, because I think that we might benefit of a separate document that does an analysis of all IID generation techniques, rather than only this one (I had planned to wok on such a document even before this whole discussion came up). To some extent, including such whole discussion here looks a bit side-tracking. But I'd love to hear what you and others think about it. Yes! but I'd rather see this published sooner rather than later. I have always found this a complicated I-D to read, and each successive versions seems harder, as more and more gets added. Yes, what is added is related and is about the problems of IPv6, but that is a bottomless pit:-) I would rather you has stopped a version or two ago, leaving some of the compare and contrast, and the unsolved problems, at least in detail, for another day. (But the Introduction is better in this version). When I look back at the comments on this in the recent past, I do wonder if perhaps there is an element of unconscious hindering, of asking for more not because it will make the document noticeably better but rather as a way of saying something like um, I am not too sure about this going forward. Leaving the psychology aside, I would like this to progress as is. I believe that there will more comments that will need changes in the later stages of review, perhaps a GenArt or security directorate, or the dreaded IETF Last Call. Tom Petch Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From otroan@employees.org Fri Jun 7 02:06:19 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73FF21F92C5 for ; Fri, 7 Jun 2013 02:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjyhKfn8kZdA for ; Fri, 7 Jun 2013 02:06:13 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id EC0A521F96F4 for ; Fri, 7 Jun 2013 02:06:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGOhsVGrRDoJ/2dsb2JhbABZgwm/InwWdIIjAQEEATo/BQsLDjhXBogaBbwajXuBBDMHgnphA5NtiXCLIoFYgTk6gS0 X-IronPort-AV: E=Sophos;i="4.87,820,1363132800"; d="scan'208";a="80446008" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 07 Jun 2013 09:06:11 +0000 Received: from [10.147.116.46] (dhcp-lys02-vla252-10-147-116-46.cisco.com [10.147.116.46]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r579675c022480 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Jun 2013 09:06:09 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) From: Ole Troan In-Reply-To: <51B0F3E6.4010006@globis.net> Date: Fri, 7 Jun 2013 11:06:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1503) Cc: "vishwas.manral@hp.com" , 6man , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 09:06:19 -0000 [absolutely no chair hat] > Does size matter? >=20 > Or is the complexity of the ASIC implementation of a header chain = parser > more heavily influenced by the fact that the header chain is defined = as > a linked list of type-length-value items that can be built up in any > number of valid combinations, and so has to be traversed and = interpreted > at every individual link? >=20 > What if the most common individual TLV option tokens were standardized > further? >=20 > And the transmission order fixed? >=20 > What if the most common individual extension headers were standardized > further? >=20 > And the transmission order fixed? >=20 > Would this help make hardware parsing possible/economic? since it's Friday... and thinking aloud, what extension headers are in = actual use today? what would be the consequence of relegating them to networks using them = only among consenting adults? IPv6-Opts: ----------------- Link specific: Jumbo Payload Consenting Adults: RPL Option, CALIPSO, Line-Identification Option, MPL = Option Experimental: Quick-Start, SMF_DPD, ILNP Nonce, IP_DFF Not implemented: Tunnel Encapsulation Limit Hop-by-Hop option: Router Alert. DOS vector Home Address - could use tunneling. IPv6-Route: ------------------- There are two source route types, one used by mobile IP (that could use = tunnelling), and one used by RPL, which could be supported in a RPL network. IPv6-Frag: --------------- It would be an interesting analysis to see what application layer = protocols must change if we were to remove fragmentation from the Internet layer. of course you have AH, ESP, various GRE, IP in IP stuff as well. cheers, Ole= From sm@resistor.net Fri Jun 7 03:25:51 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E0F21F8EC3 for ; Fri, 7 Jun 2013 03:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHXfn61WWzOL for ; Fri, 7 Jun 2013 03:25:47 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4740021F8E8C for <6man@ietf.org>; Fri, 7 Jun 2013 03:25:47 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r57AOCmk008428; Fri, 7 Jun 2013 03:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1370600663; bh=g3Lm8QX/6WK3S8DCP2ymIamstYorf/mjf+ERNWPCkIc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=oAYRMvkCwBynA0wLeGoXi0gbEzH1Vzd6AkWWurHRfaEobJNFjxCm4qdhDZjfBYpuL AI0td//oaO5/7y1cUBzxH0sCRR/GDPJ2DYMfwv2LvJetzhfi3uamjId1EcADJJ7v59 JFqGzJi0U0LXDQt8zi0P6iAiWIVX4GS0WlPFYrCc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1370600663; i=@resistor.net; bh=g3Lm8QX/6WK3S8DCP2ymIamstYorf/mjf+ERNWPCkIc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0xbL2oyRb7VB+LHth4s/lhjoMvr0N8czF9cUWhd5TuOa2UfQFdyFR9ngOn/YL5uhx XpzNKwKT8WY+UEKooW7ohbmIqp2yA3fmsSrr+d5AFL38DGA8L8FBVSsQKY8+GqIYMN wh6KZpyagC5zkbtuKtqTS7ucxxXDLfmI6knG5HUQ= Message-Id: <6.2.5.6.2.20130607022708.0caec640@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 07 Jun 2013 02:51:55 -0700 To: Fernando Gont From: SM Subject: Re: Comments on draft-ietf-6man-stable-privacy-addresses-07 In-Reply-To: <51B0EAE1.5080006@si6networks.com> References: <72fb5db097d443eebb554cdc43d7a01f@BY2PR03MB269.namprd03.prod.outlook.com> <519AD0EF.60600@si6networks.com> <87b8552e4b4a479dbfca94bd88a09ce7@BY2PR03MB269.namprd03.prod.outlook.com> <519F3364.80301@si6networks.com> <51A207B0.4000900@si6networks.com> <51A93EEE.7080902@gont.com.ar> <6AD05DBB-1067-4F4D-996C-CAB7FEF0184F@cdt.org> <51AFE3AF.1050300@si6networks.com> <51B0EAE1.5080006@si6networks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Brian Haberman , 6man@ietf.org, Dave Thaler , Ray Hunter , Alissa Cooper , Fernando Gont , "tom.petch" , Christian Huitema , He Xuan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 10:25:52 -0000 Hi Fernando, At 13:02 06-06-2013, Fernando Gont wrote: >I'd personally prefer this not to be in the body of the document. For >the most part, because I think that we might benefit of a separate >document that does an analysis of all IID generation techniques, rather >than only this one (I had planned to wok on such a document even before >this whole discussion came up). To some extent, including such whole >discussion here looks a bit side-tracking. My preference would be to have the threat model in one place followed by the discussion of which threats are addressed or not addressed. If the level of detail is a distraction I would move some of that text to an Appendix. Another alternative is to discuss about the threats under Security Considerations. As a reader I would look for the reason to implement what's in draft-ietf-6man-stable-privacy-addresses-09 and how it is done. I am ok with what you prefer in terms of document organization. Regards, -sm From nalini.elkins@insidethestack.com Fri Jun 7 05:47:15 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333CD21F8667 for ; Fri, 7 Jun 2013 05:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RptPdZ1CYZTI for ; Fri, 7 Jun 2013 05:47:00 -0700 (PDT) Received: from nm20.access.bullet.mail.mud.yahoo.com (nm20.access.bullet.mail.mud.yahoo.com [66.94.237.221]) by ietfa.amsl.com (Postfix) with ESMTP id 7226721F8609 for ; Fri, 7 Jun 2013 05:47:00 -0700 (PDT) Received: from [66.94.237.193] by nm20.access.bullet.mail.mud.yahoo.com with NNFMP; 07 Jun 2013 12:47:00 -0000 Received: from [66.94.237.106] by tm4.access.bullet.mail.mud.yahoo.com with NNFMP; 07 Jun 2013 12:47:00 -0000 Received: from [127.0.0.1] by omp1011.access.mail.mud.yahoo.com with NNFMP; 07 Jun 2013 12:47:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 75981.85651.bm@omp1011.access.mail.mud.yahoo.com Received: (qmail 83514 invoked by uid 60001); 7 Jun 2013 12:46:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370609219; bh=h+gbKhfp153oU6/PAe21JIkT0G4eJYgo7BLp5+hftl8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ir6kf4afAVHH1N07Um8YZwT1KlUpuYJ+VvKL29TG+xhn7G7xLO/95lcp+mgO0APH+ku7lhR6TGikWzObuABrhmI4p60lcdC3knPbbXyJeoQiqejPaVft03JEoi36gOoQmWfsn9KXbiCg8ligR9jiaqTUzVXc0EpEirvh9BAoNrM= X-YMail-OSG: yvDNoj0VM1mVDO0RPDIGGu7kBYil_O_O4U.ivwpPAqNFoWv 1.DDsNYmmC2177gNEg8rNaesUtUL8T_rO99_.blizJFDFoaGGbXaeywKNtI_ Zziy4feszx1CnCGYkONVJjbvDMohC0JkM5YRjwDSpFCRCZkJprUHhgDEdpfk 5gtzQPPjnaf3idLVV631A2O4Zq9cItyYtIS6sjvN_6ugZmxU9fyql6lWP0LP VQfdDuAPIgmzib2k0wHuxZKoW8Ji.ExiNNC1_WQv2eNS2Y0MnqmNif7etiKy h54SKovgGU8VN4eIjINreC_bH2yxsfyjC_h9U2bUpgLhFYkYKUzXGpWr6674 vToMOu1GKxskhoF9rXOl0DZC591igv9IiWOZJpW0zBLdkwxMuuUj1IF4cAue XyXqeekKWorgQPwOwhl4g9tccCyMIOhNMFP6nMziLjD.14qyl5XCtPbCR1xE TzceezS01s9hVAd8ePNDkCKYcoKpNVTvXIvRJkCwVEZCQC1AFKaxusLQ3MGw du2BYMelB3UzJ9x7ZMjaEKVPwEQVrZyfmXDLBHuCsSbY.umbuwfU4PiqC4XU IDdKGxsQSLN2LEqtyZzwz9InNPvYDz3lnNTA83OXNwjbGZzutX.lTCXHtsSx ld0yd1naGNx7gT_YXAdCNEHu_MIK1zZl15KzH Received: from [50.131.220.245] by web2801.biz.mail.ne1.yahoo.com via HTTP; Fri, 07 Jun 2013 05:46:59 PDT X-Rocket-MIMEInfo: 002.001, WWVzISDCoCBMZXQgdGhvc2Ugb2YgdXMgd2hvIHdhbnQgdG8gdXNlIGV4dGVuc2lvbiBoZWFkZXJzIHVzZSB0aGVtIQrCoApUaGFua3MsCgoKTmFsaW5pIEVsa2lucwpJbnNpZGUgUHJvZHVjdHMsIEluYy4KKDgzMSkgNjU5LTgzNjAKd3d3Lmluc2lkZXRoZXN0YWNrLmNvbQoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogT2xlIFRyb2FuIDxvdHJvYW5AZW1wbG95ZWVzLm9yZz4KVG86IFJheSBIdW50ZXIgPHY2b3BzQGdsb2Jpcy5uZXQ.IApDYzogInZpc2h3YXMubWFucmFsQGhwLmMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.145.547 References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> Message-ID: <1370609219.74983.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Date: Fri, 7 Jun 2013 05:46:59 -0700 (PDT) From: Nalini Elkins Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) To: Ole Troan , Ray Hunter In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="36908767-1681805276-1370609219=:74983" Cc: "vishwas.manral@hp.com" , Fernando Gont , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 12:47:15 -0000 --36908767-1681805276-1370609219=:74983 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Yes! =A0 Let those of us who want to use extension headers use them!=0A=A0= =0AThanks,=0A=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-8360= =0Awww.insidethestack.com=0A=0A=0A=0A________________________________=0A Fr= om: Ole Troan =0ATo: Ray Hunter = =0ACc: "vishwas.manral@hp.com" ; 6man ; Fernando Gont =0ASent: Friday, June 7, 2013 2:06= AM=0ASubject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: d= raft-ietf-6man-ext-transmit-01)=0A =0A=0A[absolutely no chair hat]=0A=0A> D= oes size matter?=0A> =0A> Or is the complexity of the ASIC implementation o= f a header chain parser=0A> more heavily influenced by the fact that the he= ader chain is defined as=0A> a linked list of type-length-value items that = can be built up in any=0A> number of valid combinations, and so has to be t= raversed and interpreted=0A> at every individual link?=0A> =0A> What if the= most common individual TLV option tokens were standardized=0A> further?=0A= > =0A> And the transmission order fixed?=0A> =0A> What if the most common i= ndividual extension headers were standardized=0A> further?=0A> =0A> And the= transmission order fixed?=0A> =0A> Would this help make hardware parsing p= ossible/economic?=0A=0Asince it's Friday... and thinking aloud, what extens= ion headers are in actual use today?=0Awhat would be the consequence of rel= egating them to networks using them only=0Aamong consenting adults?=0A=0AIP= v6-Opts:=0A-----------------=0ALink specific: Jumbo Payload=0AConsenting Ad= ults: RPL Option, CALIPSO, Line-Identification Option, MPL Option=0AExperim= ental: Quick-Start, SMF_DPD, ILNP Nonce, IP_DFF=0ANot implemented: Tunnel E= ncapsulation Limit=0AHop-by-Hop option: Router Alert. DOS vector=0AHome Add= ress - could use tunneling.=0A=0AIPv6-Route:=0A-------------------=0AThere = are two source route types, one used by mobile IP (that could use tunnellin= g),=0Aand one used by RPL, which could be supported in a RPL network.=0A=0A= IPv6-Frag:=0A---------------=0AIt would be an interesting analysis to see w= hat application layer protocols must change if=0Awe were to remove fragment= ation from the Internet layer.=0A=0Aof course you have AH, ESP, various GRE= , IP in IP stuff as well.=0A=0Acheers,=0AOle=0A----------------------------= ----------------------------------------=0AIETF IPv6 working group mailing = list=0Aipv6@ietf.org=0AAdministrative Requests: https://www.ietf.org/mailma= n/listinfo/ipv6=0A---------------------------------------------------------= ----------- --36908767-1681805276-1370609219=:74983 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    Yes!   Let those= of us who want to use extension headers use them!
    <= div> 
    Thanks,

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

    = From: Ole Troan <otroan@= employees.org>
    To: = Ray Hunter <v6ops@globis.net>
    Cc: "vishwas.manral@hp.com" <vishwas.manral@hp.com>; 6m= an <ipv6@ietf.org>; Fernando Gont <fgont@si6networks.com>
    = Sent: Friday, June 7, 2013 2:06 AM=
    Subject: Re: draft-ie= tf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit= -01)

    =0A[absolutely n= o chair hat]

    > Does size matter?
    >
    > Or is the compl= exity of the ASIC implementation of a header chain parser
    > more heav= ily influenced by the fact that the header chain is defined as
    > a li= nked list of type-length-value items that can be built up in any
    > nu= mber of valid combinations, and so has to be traversed and interpreted
    &= gt; at every individual link?
    >
    > What if the most common indi= vidual TLV option tokens were standardized
    > further?
    >
    >= ; And the transmission order fixed?
    >
    > What if the most commo= n individual extension headers were standardized
    > further?
    > <= br>> And the transmission order fixed?
    >
    > Would this help = make hardware parsing possible/economic?

    since it's Friday... and th= inking aloud, what extension headers are in actual use today?
    what would= be the consequence of relegating them to networks using them only
    among consenting adults?

    IPv6-Opts:
    ---------= --------
    Link specific: Jumbo Payload
    Consenting Adults: RPL Option, = CALIPSO, Line-Identification Option, MPL Option
    Experimental: Quick-Star= t, SMF_DPD, ILNP Nonce, IP_DFF
    Not implemented: Tunnel Encapsulation Lim= it
    Hop-by-Hop option: Router Alert. DOS vector
    Home Address - could u= se tunneling.

    IPv6-Route:
    -------------------
    There are two so= urce route types, one used by mobile IP (that could use tunnelling),
    and= one used by RPL, which could be supported in a RPL network.

    IPv6-Fr= ag:
    ---------------
    It would be an interesting analysis to see what a= pplication layer protocols must change if
    we were to remove fragmentatio= n from the Internet layer.

    of course you have AH, ESP, various GRE, = IP in IP stuff as well.

    cheers,
    Ole
    --------------------------= ------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.= org/mailman/listinfo/ipv6
    ------------------------------------------= --------------------------


    --36908767-1681805276-1370609219=:74983-- From Ted.Lemon@nominum.com Fri Jun 7 06:23:42 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B364721F8618; Fri, 7 Jun 2013 06:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.82 X-Spam-Level: X-Spam-Status: No, score=-106.82 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNEB-11xh7Xi; Fri, 7 Jun 2013 06:23:36 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id CB59421F8617; Fri, 7 Jun 2013 06:23:35 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUbHez9ZOcN19r+O9uuwq+uE3KqAsYFJg@postini.com; Fri, 07 Jun 2013 06:23:35 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A255E1B8050; Fri, 7 Jun 2013 06:23:27 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 95A7719005D; Fri, 7 Jun 2013 06:23:27 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Fri, 7 Jun 2013 06:23:27 -0700 From: Ted Lemon To: Lorenzo Colitti Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOXm45WoMnwVBJ2U2+cujDGH1pcpkgllOAgAAGw4CAAIlogIAAHNkAgAA7XoCAANwAAIAAGRcAgACZEACAAFFqgIAAA0MAgAAlngCAAERTAIAAmIuAgAAWAQCAALv5gIAAMI2AgACc9YCAACD6gIAAH1gAgACZeoCAAAjegIAAwruAgAAV84CAAAZKgIAAAigAgAC9mQCAAIcfgIAAe8GAgABs5wCAAAM+AIAABHyAgAAM34CAALOaAA== Date: Fri, 7 Jun 2013 13:23:26 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751C90F7@mbx-01.win.nominum.com> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> <9B71CE05-E12D-4FE9-8222-6FBFD7938F0C@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C850C@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C86DF@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751C90F7mbx01winnominum_" MIME-Version: 1.0 Cc: "ipv6@ietf.org 6man-wg" , "v6ops@ietf.org WG" , "" , Owen DeLong X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 13:23:42 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751C90F7mbx01winnominum_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jun 6, 2013, at 10:40 PM, Lorenzo Colitti > wrote: Like almost everything things in engineering, it's a cost/benefit tradeoff.= This discussion about "not enough bits" is simply attempting to quantify s= ome of the costs involved. I keep harping about it because the cost is NOT = zero, and I think the document should cite that cost and compare the costs/= benefits to alternative approaches like using DSCP (which *does* have zero = cost in addressing). We do that analysis, we write it down, and then we can= decide if it's a good idea or not. Argh. I don't think anybody ever said that there was no cost to these bit= s, and I agree that the cost should be discussed. So I guess we've been a= rguing over a nonexistent disagreement! :| --_000_8D23D4052ABE7A4490E77B1A012B6307751C90F7mbx01winnominum_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <93136DDDFA6D7344A2B1F062C2101D24@nominum.com> Content-Transfer-Encoding: quoted-printable
    On Jun 6, 2013, at 10:40 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
    Like almost everything things in engineering, it's a cost/benefit tradeoff. Thi= s discussion about "not enough bits" is simply attempting to quan= tify some of the costs involved. I keep harping about it because the cost i= s NOT zero, and I think the document should cite that cost and compare the costs/benefits to alternative approaches li= ke using DSCP (which *does* have zero cost in addressing). We do that analy= sis, we write it down, and then we can decide if it's a good idea or not.

    Argh.   I don't think anybody ever said that there was no cost to= these bits, and I agree that the cost should be discussed.   So I gue= ss we've been arguing over a nonexistent disagreement!   :|

    --_000_8D23D4052ABE7A4490E77B1A012B6307751C90F7mbx01winnominum_-- From joelja@bogus.com Fri Jun 7 08:26:35 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9BE21F9678; Fri, 7 Jun 2013 08:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cOdByddCftv; Fri, 7 Jun 2013 08:26:34 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 63B2521F9675; Fri, 7 Jun 2013 08:26:34 -0700 (PDT) Received: from joels-MacBook-Air.local ([196.38.103.34]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r57FQFog055883 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 7 Jun 2013 15:26:25 GMT (envelope-from joelja@bogus.com) Message-ID: <51B1A934.4000207@bogus.com> Date: Fri, 07 Jun 2013 05:34:44 -0400 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Lorenzo Colitti , Ted Lemon Subject: Moderate: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C73E5@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C75A3@mbx-01.win.nominum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 07 Jun 2013 15:26:30 +0000 (UTC) Cc: Owen DeLong , "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 15:26:35 -0000 On 6/6/13 10:09 AM, Lorenzo Colitti wrote: > On Thu, Jun 6, 2013 at 10:56 PM, Ted Lemon > wrote: > >> Saying "it says nothing of the sort" without even citing it is >> not a very convincing argument. If you want to state convincingly >> that it says nothing of the sort, then why not start from the >> text I posted earlier and explain why my interpretation is incorrect? > > The statement you claim is in there isn't in there. How am I > supposed to point out to you the place where it isn't? > > > Start by saying how the statement I point to as justification does > not, in fact, mean what I say, and why it does not? I think we established somewhat conclusively were the various participants in this discussion stand, myself included. We're mostly generating heat at this point on the policy debate so I think we can move on. have a good weekend. thanks joel > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Fri Jun 7 13:03:41 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F5121F96F7 for ; Fri, 7 Jun 2013 13:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyaDVqvtW+ny for ; Fri, 7 Jun 2013 13:03:28 -0700 (PDT) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF5E21F94E1 for ; Fri, 7 Jun 2013 13:03:28 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id u10so5175087pdi.22 for ; Fri, 07 Jun 2013 13:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oN2NB81+W2IU4UFZh3IB23p6j7g5KeHysWF8pLchFfg=; b=x+tBQmUqJLySVUZkVgXwtYTscEjmEUYFzSpoG/I86bxvYOpgjaBsxlL0uvWQGFUwkI j449RbrGrGEI6nH6f6QjNs277tOfnbwimB3qq8PlWwymqBc3Q2podC/WE9Nol7JbbPuL uPlQ25xLrkZKYtN5sh1mldsnalN3JdoLpbqlfBWOzpZP7NEPpKlxFuUPGZ9eiPXaD4mx q7fiDv+sd4mFfL4su9jgi5qNeL60xDH4iieRDsTus087T2s3c/lfWb7GboIl2byyJ8mp eDj7lX4R2aNDwThtsb8wmVwt2lOUNnHI/tDuwgDRjrjOE68w+xTOJ4LMHmlNljQbKmL8 3YgQ== X-Received: by 10.67.22.99 with SMTP id hr3mr4374316pad.12.1370635407864; Fri, 07 Jun 2013 13:03:27 -0700 (PDT) Received: from [192.168.1.2] (70.71.252.27.dyn.cust.vf.net.nz. [27.252.71.70]) by mx.google.com with ESMTPSA id xz1sm4530775pab.5.2013.06.07.13.03.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Jun 2013 13:03:27 -0700 (PDT) Message-ID: <51B23C98.8040009@gmail.com> Date: Sat, 08 Jun 2013 08:03:36 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ole Troan Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vishwas.manral@hp.com" , Ray Hunter , 6man , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 20:03:41 -0000 Ole, I think the list of headers in -ext-transmit is complete, if you include HIP. However, you last question illustrates the Catch-22 problem - the ones in use today are the ones that manage to get through firewalls, sometimes, today. We don't *know* which ones would be in use if the network was transparent to them. Your other questions are interesting ones, but I am also interested in seeing a detailed analysis of exactly what is hard for modern technology in dealing with what is currently standardised. All I hear is "our current design doesn't do this." That isn't helpful. Regards Brian On 07/06/2013 21:06, Ole Troan wrote: > [absolutely no chair hat] > >> Does size matter? >> >> Or is the complexity of the ASIC implementation of a header chain parser >> more heavily influenced by the fact that the header chain is defined as >> a linked list of type-length-value items that can be built up in any >> number of valid combinations, and so has to be traversed and interpreted >> at every individual link? >> >> What if the most common individual TLV option tokens were standardized >> further? >> >> And the transmission order fixed? >> >> What if the most common individual extension headers were standardized >> further? >> >> And the transmission order fixed? >> >> Would this help make hardware parsing possible/economic? > > since it's Friday... and thinking aloud, what extension headers are in actual use today? > what would be the consequence of relegating them to networks using them only > among consenting adults? > > IPv6-Opts: > ----------------- > Link specific: Jumbo Payload > Consenting Adults: RPL Option, CALIPSO, Line-Identification Option, MPL Option > Experimental: Quick-Start, SMF_DPD, ILNP Nonce, IP_DFF > Not implemented: Tunnel Encapsulation Limit > Hop-by-Hop option: Router Alert. DOS vector > Home Address - could use tunneling. > > IPv6-Route: > ------------------- > There are two source route types, one used by mobile IP (that could use tunnelling), > and one used by RPL, which could be supported in a RPL network. > > IPv6-Frag: > --------------- > It would be an interesting analysis to see what application layer protocols must change if > we were to remove fragmentation from the Internet layer. > > of course you have AH, ESP, various GRE, IP in IP stuff as well. > > cheers, > Ole > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > . > From owen@delong.com Fri Jun 7 15:19:07 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87DF21F99A6; Fri, 7 Jun 2013 15:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsA7t8J27xFH; Fri, 7 Jun 2013 15:19:06 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C583821F99A8; Fri, 7 Jun 2013 15:19:06 -0700 (PDT) Received: from [10.255.251.221] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r57MCmQT023606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 7 Jun 2013 15:12:49 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r57MCmQT023606 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370643170; bh=vR8orhfRnt+Cccwvod+iiX92F34=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=zxSgoqhoOIC58cFtKsJjuekLK9wAruAF9a2kbE5AwLyNkokzouGvPkl/i3NFOCBrx ueHlioe5Ny2ECj1fdkK5xra7AminlQdF9bcL4ARgndFA71QHa66oruKuEh4GsOOM1T xX6oR3FyX7kBS9q0awS87nQFm1EhU9zpuEbq8eag= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Owen DeLong In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AC9D21B@nkgeml512-mbx.china.huawei.com> Date: Fri, 7 Jun 2013 15:12:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6E92D779-70BD-488B-B81C-95681AA26F4C@delong.com> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <021E64FECA7E5A4699562F4E6671648103DE44@XCH-PHX-503.sw.nos.boeing.com> <8D23D4052ABE7A4490E77B1A012B6307751C62A3@mbx-01.win.nominum.com> <5D36713D8A4E7348A7E10DF7437A4B923AC9D21B@nkgeml512-mbx.china.huawei.com> To: Sheng Jiang X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 07 Jun 2013 15:12:50 -0700 (PDT) Cc: "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" , Sheng Jiang , Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 22:19:07 -0000 >>> By the way, ISPs are only one kind of network operators who are = interesting >> in semantic prefix. Enterprise network operators are another group of >> network operators who can benefit from embedded semantics. And the >> enterprises do not have subscribers who potentially need extra bits. >>=20 >> Your use of the word "benefit" here is questionable at best. It is an = example of >> language that seems to encourage this use rather than evaluate it in = an >> unbiased manner. >>=20 >> "Enterprise operators are another group of network operators which = may >> succumb to this nasty pitfall of embedded semantics" would be an = equally >> biased statement in the opposite direction. >>=20 >> I suggest that neutral would require something more along the lines = of: >>=20 >> "Enterprise operators are another group of network operators which = may >> choose to embed semantics in their address prefixes." >>=20 >> Now, in terms of arguing the merits, there are significant = differences between >> these two. In the case of an enterprise operator, their choice to = embed >> semantics in the address has a limited scope of harm. It can only = negatively >> impact said enterprise. >>=20 >> In the case of an ISP, this can have significant consequences not = only for the >> ISP, but also for their downstream customers. >=20 > As a neutral analysis, it is fine to say there are benefits and = pitfalls. All good things come with costs. I will make sure we document = both sides in the draft. >=20 Yes. However, when you talk about classes of users that may use a = technology, there are multiple ways to express that potential use. "Those that may benefit=85" is a positive way. "The world will end if=85" is a negative way. "The following groups may use=85" is neutral. When you are talking about how something can be implemented or the = relative merits of doing so, then it is appropriate to discuss the = benefits and pitfalls (ideally in as neutral a fashion as possible). I hope that clarifies what I was attempting to express above. Owen From jiangsheng@huawei.com Fri Jun 7 18:58:18 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411CA21F99FE; Fri, 7 Jun 2013 18:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OTpWlz0nUfA; Fri, 7 Jun 2013 18:58:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F16E121F9A00; Fri, 7 Jun 2013 18:58:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASF25813; Sat, 08 Jun 2013 01:58:06 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 8 Jun 2013 02:57:05 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 8 Jun 2013 02:58:03 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Sat, 8 Jun 2013 09:57:59 +0800 From: Sheng Jiang To: Owen DeLong Subject: RE: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Topic: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 Thread-Index: AQHOYqIreYB7EHmXR0+A7JbK0DaUI5kof3AAgAEHRrCAAMYyAIAAwFmQ Date: Sat, 8 Jun 2013 01:57:58 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AC9DC3C@nkgeml512-mbx.china.huawei.com> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <021E64FECA7E5A4699562F4E6671648103DE44@XCH-PHX-503.sw.nos.boeing.com> <8D23D4052ABE7A4490E77B1A012B6307751C62A3@mbx-01.win.nominum.com> <5D36713D8A4E7348A7E10DF7437A4B923AC9D21B@nkgeml512-mbx.china.huawei.com> <6E92D779-70BD-488B-B81C-95681AA26F4C@delong.com> In-Reply-To: <6E92D779-70BD-488B-B81C-95681AA26F4C@delong.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" , Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 01:58:18 -0000 Pj4+PiBCeSB0aGUgd2F5LCBJU1BzIGFyZSBvbmx5IG9uZSBraW5kIG9mIG5ldHdvcmsgb3BlcmF0 b3JzIHdobyBhcmUNCj5pbnRlcmVzdGluZw0KPj4+IGluIHNlbWFudGljIHByZWZpeC4gRW50ZXJw cmlzZSBuZXR3b3JrIG9wZXJhdG9ycyBhcmUgYW5vdGhlciBncm91cCBvZg0KPj4+IG5ldHdvcmsg b3BlcmF0b3JzIHdobyBjYW4gYmVuZWZpdCBmcm9tIGVtYmVkZGVkIHNlbWFudGljcy4gQW5kIHRo ZQ0KPj4+IGVudGVycHJpc2VzIGRvIG5vdCBoYXZlIHN1YnNjcmliZXJzIHdobyBwb3RlbnRpYWxs eSBuZWVkIGV4dHJhIGJpdHMuDQo+Pj4NCj4+PiBZb3VyIHVzZSBvZiB0aGUgd29yZCAiYmVuZWZp dCIgaGVyZSBpcyBxdWVzdGlvbmFibGUgYXQgYmVzdC4gSXQgaXMgYW4NCj5leGFtcGxlIG9mDQo+ Pj4gbGFuZ3VhZ2UgdGhhdCBzZWVtcyB0byBlbmNvdXJhZ2UgdGhpcyB1c2UgcmF0aGVyIHRoYW4g ZXZhbHVhdGUgaXQgaW4gYW4NCj4+PiB1bmJpYXNlZCBtYW5uZXIuDQo+Pj4NCj4+PiAiRW50ZXJw cmlzZSBvcGVyYXRvcnMgYXJlIGFub3RoZXIgZ3JvdXAgb2YgbmV0d29yayBvcGVyYXRvcnMgd2hp Y2ggbWF5DQo+Pj4gc3VjY3VtYiB0byB0aGlzIG5hc3R5IHBpdGZhbGwgb2YgZW1iZWRkZWQgc2Vt YW50aWNzIiB3b3VsZCBiZSAgYW4NCj5lcXVhbGx5DQo+Pj4gYmlhc2VkIHN0YXRlbWVudCBpbiB0 aGUgb3Bwb3NpdGUgZGlyZWN0aW9uLg0KPj4+DQo+Pj4gSSBzdWdnZXN0IHRoYXQgbmV1dHJhbCB3 b3VsZCByZXF1aXJlIHNvbWV0aGluZyBtb3JlIGFsb25nIHRoZSBsaW5lcyBvZjoNCj4+Pg0KPj4+ ICJFbnRlcnByaXNlIG9wZXJhdG9ycyBhcmUgYW5vdGhlciBncm91cCBvZiBuZXR3b3JrIG9wZXJh dG9ycyB3aGljaCBtYXkNCj4+PiBjaG9vc2UgdG8gZW1iZWQgc2VtYW50aWNzIGluIHRoZWlyIGFk ZHJlc3MgcHJlZml4ZXMuIg0KPj4+DQo+Pj4gTm93LCBpbiB0ZXJtcyBvZiBhcmd1aW5nIHRoZSBt ZXJpdHMsIHRoZXJlIGFyZSBzaWduaWZpY2FudCBkaWZmZXJlbmNlcw0KPmJldHdlZW4NCj4+PiB0 aGVzZSB0d28uIEluIHRoZSBjYXNlIG9mIGFuIGVudGVycHJpc2Ugb3BlcmF0b3IsIHRoZWlyIGNo b2ljZSB0byBlbWJlZA0KPj4+IHNlbWFudGljcyBpbiB0aGUgYWRkcmVzcyBoYXMgYSBsaW1pdGVk IHNjb3BlIG9mIGhhcm0uIEl0IGNhbiBvbmx5IG5lZ2F0aXZlbHkNCj4+PiBpbXBhY3Qgc2FpZCBl bnRlcnByaXNlLg0KPj4+DQo+Pj4gSW4gdGhlIGNhc2Ugb2YgYW4gSVNQLCB0aGlzIGNhbiBoYXZl IHNpZ25pZmljYW50IGNvbnNlcXVlbmNlcyBub3Qgb25seSBmb3INCj50aGUNCj4+PiBJU1AsIGJ1 dCBhbHNvIGZvciB0aGVpciBkb3duc3RyZWFtIGN1c3RvbWVycy4NCj4+DQo+PiBBcyBhIG5ldXRy YWwgYW5hbHlzaXMsIGl0IGlzIGZpbmUgdG8gc2F5IHRoZXJlIGFyZSBiZW5lZml0cyBhbmQgcGl0 ZmFsbHMuIEFsbCBnb29kDQo+dGhpbmdzIGNvbWUgd2l0aCBjb3N0cy4gSSB3aWxsIG1ha2Ugc3Vy ZSB3ZSBkb2N1bWVudCBib3RoIHNpZGVzIGluIHRoZSBkcmFmdC4NCj4+DQo+DQo+WWVzLiBIb3dl dmVyLCB3aGVuIHlvdSB0YWxrIGFib3V0IGNsYXNzZXMgb2YgdXNlcnMgdGhhdCBtYXkgdXNlIGEg dGVjaG5vbG9neSwNCj50aGVyZSBhcmUgbXVsdGlwbGUgd2F5cyB0byBleHByZXNzIHRoYXQgcG90 ZW50aWFsIHVzZS4NCj4NCj4iVGhvc2UgdGhhdCBtYXkgYmVuZWZpdOKApiIgaXMgYSBwb3NpdGl2 ZSB3YXkuDQo+IlRoZSB3b3JsZCB3aWxsIGVuZCBpZuKApiIgaXMgYSBuZWdhdGl2ZSB3YXkuDQo+ IlRoZSBmb2xsb3dpbmcgZ3JvdXBzIG1heSB1c2XigKYiIGlzIG5ldXRyYWwuDQo+DQo+V2hlbiB5 b3UgYXJlIHRhbGtpbmcgYWJvdXQgaG93IHNvbWV0aGluZyBjYW4gYmUgaW1wbGVtZW50ZWQgb3Ig dGhlDQo+cmVsYXRpdmUgbWVyaXRzIG9mIGRvaW5nIHNvLCB0aGVuIGl0IGlzIGFwcHJvcHJpYXRl IHRvIGRpc2N1c3MgdGhlIGJlbmVmaXRzIGFuZA0KPnBpdGZhbGxzIChpZGVhbGx5IGluIGFzIG5l dXRyYWwgYSBmYXNoaW9uIGFzIHBvc3NpYmxlKS4NCg0KSGksIE93ZW4sDQoNClRoYW5rcyBmb3Ig eW91ciBuZXV0cmFsIHN1Z2dlc3Rpb24uIEkgYWdyZWUgb24gdGhpcywgYW5kIHdpbGwgdHJ5IG15 IGJlc3QgdG8gdXNlIHRoZSBuZXV0cmFsIGxhbmd1YWdlIGluIHRoZSBmdXR1cmUgdmVyc2lvbi4g VG8gY2xhcmlmeSBteXNlbGYsIEkgdGhpbmsgInRoZSBYIGdyb3VwcyBtYXkgZ2V0IFkgYmVuZWZp dCB3aXRoIFogY29zdCIgaXMgYSBuZXV0cmFsIGFuYWx5c2lzLg0KDQpDaGVlcnMsDQoNClNoZW5n DQoNCj5JIGhvcGUgdGhhdCBjbGFyaWZpZXMgd2hhdCBJIHdhcyBhdHRlbXB0aW5nIHRvIGV4cHJl c3MgYWJvdmUuDQo+DQo+T3dlbg0KDQo= From lorenzo@google.com Fri Jun 7 19:00:58 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D566221F9A08 for ; Fri, 7 Jun 2013 19:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.033 X-Spam-Level: X-Spam-Status: No, score=-3.033 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OX4q1tM9T2WK for ; Fri, 7 Jun 2013 19:00:46 -0700 (PDT) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id 6719B21F9A10 for ; Fri, 7 Jun 2013 19:00:46 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id 1so3182518qec.34 for ; Fri, 07 Jun 2013 19:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Gpn8PBhsW5aA/8wTcX67U4GR87QJaNfWaXTsS5YJqTo=; b=R3GePgv7d+a/Iit33TQEz/cdHZln0Gb0hm9So/g0MAsJYHDnkNLaVfAHrwO9zDA56y NMYWFrahLkLLH86+pAbogLJ9HrRU0QQ+0YLLgXXZLI/w7NROmO1gE52gnndy5YwbFGR0 tmo0wzLgX620iw5anch49ipi6f6ZJhhxH2Mfo91bxjV+dQQrtkj7t5mNeIS8/RlZm3xo CY42cDNeL7yLNttIfMF37hLerfPlkSUHM4pv7ZhQZpyho/oDMGUnRvyYq83jG2aFR9aN 4JkRUbgLq5t/s7ridbkZ31eTnUZZWvGMu/v3ZCZesOxAB5vtu3EiOSpFa1QyY2gRQlxa 22tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Gpn8PBhsW5aA/8wTcX67U4GR87QJaNfWaXTsS5YJqTo=; b=KiT6nc4OXPNM66AlO7bWYAL/kN77VR37nBQNuRE40c1yxXvpZ1RwWe09/Vj4PSkrX3 sblq8YfA6EBCie/pT3z/NiGjkTj5CxtNHH74HMkFQWUFWY5b6tVUXroIGfNYPfiMLpZj vNTDh0CChL7BrkIdEwvqN0WZBI8FOuDYCvl0g3JxTKqIfjBYb0A/Bt8lr7G1uz6nAUhs laJ6JkRlaKntfrlQDRn991B+vBFBHHKm4B/ITU3bafYMqs/+yh0VFHFyuzOAOJtY23bK 94hR2rpkjTMwEDF8rTMiEcjAXH6G+KE48WpDh0g5Eae2SCszziXCjPu5XBWL87H3bnu4 3yxA== X-Received: by 10.229.119.72 with SMTP id y8mr514006qcq.39.1370656845782; Fri, 07 Jun 2013 19:00:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.158.8 with HTTP; Fri, 7 Jun 2013 19:00:24 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751C90F7@mbx-01.win.nominum.com> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> <9B71CE05-E12D-4FE9-8222-6FBFD7938F0C@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C850C@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C86DF@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C90F7@mbx-01.win.nominum.com> From: Lorenzo Colitti Date: Sat, 8 Jun 2013 11:00:24 +0900 Message-ID: Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 To: Ted Lemon Content-Type: multipart/alternative; boundary=001a1133327067026004de9aea2f X-Gm-Message-State: ALoCoQkKZ1VdmZsrrUFloAD1MMCp6kWjgHk9to6jfDfw7A4sepKdwS2XwPcuKC7PQCMhmVFZ6h8NqFt33f+CTwv9mBNdLhPqTBVY9sAW/k8+JK/1f5S4aT6oMXKRHRx469UEaHCz0H52u8IN3I3tn4jdOnAMAtnCFDMggou6M2EPAsRKm/9ZaxxsNbJ6OxI+mCcLx/pWRMp2 Cc: "ipv6@ietf.org 6man-wg" , "v6ops@ietf.org WG" , "" , Owen DeLong X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 02:00:59 -0000 --001a1133327067026004de9aea2f Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 7, 2013 at 10:23 PM, Ted Lemon wrote: > Argh. I don't think anybody ever said that there was no cost to these > bits, and I agree that the cost should be discussed. So I guess we've > been arguing over a nonexistent disagreement! :| > Yes, that happens. :-( One thing to bear in mind is that it depends a lot on how much space you already have. Examples: 1. Deutsche Telekom has a /19. That's over 500M /48s, and if they use it only in Germany, that's 5 for every person in the country, with a fair bit left over. So they can afford to use 2 bits for semantic prefixes. 2. Comcast only appears to have a /29 and a /28 (2001:558::/29, 2601::/28). That's only 1.5M /48s, and they have about 10x that many customers. They likely can't use /48 plus semantic prefixes, because if ARIN doesn't accept "semantic prefixes" as using space efficiently (and word from ARIN on this thread seems, well, negative on the matter), then they won't be able to get more space from ARIN. That means that there is a fundamental tension between using semantic prefixes and giving more address space to customers. We need to be very careful not to create an incentive to give less address space to customers, because IPv4 shows us very clearly how that ends up complicating the whole network. Cheers, Lorenzo --001a1133327067026004de9aea2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Fri, Jun 7, 2013 at 10:23 PM, Ted Lemon <Ted.Lemon= @nominum.com> wrote:
    Argh. =A0 I don't think anybody ever said that there was no cost t= o these bits, and I agree that the cost should be discussed. =A0 So I guess= we've been arguing over a nonexistent disagreement! =A0 :|
    =

    Yes, that happens. :-(

    One thing to bear in mind is that it depends a lot = on how much space you already have. Examples:

    1. Deutsche Telekom has a /19. That's over 500M /48s, and if= they use it only in Germany, that's 5 for every person in the country,= with a fair bit left over. So they can afford to use 2 bits for semantic p= refixes.

    2. Comcast only appears to have a /29 and a= /28 (2001:558::/29, 2601::/28). That's only 1.5M /48s, and they have a= bout 10x that many customers. They likely can't use /48 plus semantic p= refixes, because if ARIN doesn't accept "semantic prefixes" a= s using space efficiently (and word from ARIN on this thread seems, well, n= egative on the matter), then they won't be able to get more space from = ARIN. That means that there is a fundamental tension between using semantic= prefixes and giving more address space to customers.

    We need to be very careful not to create an= incentive to give less address space to customers, because IPv4 shows us v= ery clearly how that ends up complicating the whole network.

    Cheers,
    Lorenzo
    --001a1133327067026004de9aea2f-- From owen@delong.com Fri Jun 7 19:18:14 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703D321F9986; Fri, 7 Jun 2013 19:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4xFEnrGptLK; Fri, 7 Jun 2013 19:18:13 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 3253021F997E; Fri, 7 Jun 2013 19:18:12 -0700 (PDT) Received: from [10.255.251.221] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r582HL75029801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 7 Jun 2013 19:17:21 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r582HL75029801 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370657842; bh=Fm1gbqJvW6flthtKdNKlyAbBwFE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=a6QZ+3/vd5eUW+W2urTV4hx9wLFmrQWVhLOLkwHx9G51OlCrcqMM8yhfQaH7nY7L2 7Hct+FQM4flLtzAPdzZfif7+Vj7AArEDRsKp089cUfzRDSzO3/aIhZBPAw1xbnpspg 0YG9G3GH85Voz/l88wEyiY0yxCCKPF9OCOEhGACE= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 From: Owen DeLong In-Reply-To: Date: Fri, 7 Jun 2013 19:17:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <932B5FC1-FDAB-458B-9117-56E543CC911E@delong.com> References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> <9B71CE05-E12D-4FE9-8222-6FBFD7938F0C@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C850C@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C86DF@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C90F7@mbx-01.win.nominum.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 07 Jun 2013 19:17:22 -0700 (PDT) Cc: "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" , Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 02:18:14 -0000 >=20 > 2. Comcast only appears to have a /29 and a /28 (2001:558::/29, = 2601::/28). That's only 1.5M /48s, and they have about 10x that many = customers. They likely can't use /48 plus semantic prefixes, because if = ARIN doesn't accept "semantic prefixes" as using space efficiently (and = word from ARIN on this thread seems, well, negative on the matter), then = they won't be able to get more space from ARIN. That means that there is = a fundamental tension between using semantic prefixes and giving more = address space to customers. >=20 It also means that Comcast has a dramatically undersized allocation and = will most likely be depriving their customers. Owen From jeroen@massar.ch Fri Jun 7 20:05:21 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBD011E80A6; Fri, 7 Jun 2013 20:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVhmxXKwgdIj; Fri, 7 Jun 2013 20:05:20 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 751CD11E80A3; Fri, 7 Jun 2013 20:05:19 -0700 (PDT) Received: from kami.ch.unfix.org (unknown [IPv6:2001:559:8000:c9:7256:81ff:fea5:2925]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 88DA1801C2BA; Sat, 8 Jun 2013 05:05:04 +0200 (CEST) Message-ID: <51B29F5F.70400@massar.ch> Date: Fri, 07 Jun 2013 20:05:03 -0700 From: Jeroen Massar Organization: Massar User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Owen DeLong Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> <9B71CE05-E12D-4FE9-8222-6FBFD7938F0C@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C850C@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C86DF@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C90F7@mbx-01.win.nominum.com> <932B5FC1-FDAB-458B-9117-56E543CC911E@delong.com> In-Reply-To: <932B5FC1-FDAB-458B-9117-56E543CC911E@delong.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" , Ted Lemon , Lorenzo Colitti X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 03:05:22 -0000 On 2013-06-07 19:17, Owen DeLong wrote: >> >> 2. Comcast only appears to have a /29 and a /28 (2001:558::/29, >> 2601::/28). That's only 1.5M /48s, and they have about 10x that >> many customers. They likely can't use /48 plus semantic prefixes, >> because if ARIN doesn't accept "semantic prefixes" as using space >> efficiently (and word from ARIN on this thread seems, well, >> negative on the matter), then they won't be able to get more space >> from ARIN. That means that there is a fundamental tension between >> using semantic prefixes and giving more address space to >> customers. >> > > It also means that Comcast has a dramatically undersized allocation > and will most likely be depriving their customers. Comcast is mostly an end-user ISP isn't it? Because in ARIN land ISPs are supposed to calculate with /56s and suddenly there is a lot of space for doling out /56 to end-users and /48s and larger for their corporate clients. And then it is good that they are skipping out on the 6rd deployment. Funny to see that even good network engineers did not grasp the concept of 'request a /48 for every customer', and multiply that with the HD ratio and voila request that address space and be over with it, but that they had to return for a second prefix though... Also https://www.arin.net/policy/nrpm.html --------------------- 2.8. Utilization (IPv6) In IPv6, "utilization" is only measured in terms of the bits to the left of the /56 boundary. In other words, utilization refers to the assignment of /56s to end sites, and not the number of addresses assigned within individual /56s at those end sites. ------------------ Although in 2.15 in that document it is recommended to do /48. Though this is not reflected in the current policy, it likely comes from 2005-8 (https://www.arin.net/policy/proposals/2005_8.html) 8<------- The following guidelines may be useful (but they are only guidelines): - /64 when it is known that one and only one subnet is needed - /56 for small sites, those expected to need only a few subnets over the next 5 years. - /48 for larger sites ---------->8 Greets, Jeroen From joelja@bogus.com Sat Jun 8 01:24:36 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0BA21F99F2; Sat, 8 Jun 2013 01:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.103 X-Spam-Level: X-Spam-Status: No, score=-102.103 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwvRCbHsNvLU; Sat, 8 Jun 2013 01:24:34 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id AFDB021F99FE; Sat, 8 Jun 2013 01:24:34 -0700 (PDT) Received: from wifi-216-56.mtg.afnog.org (wifi-216-56.mtg.afnog.org [196.200.216.56]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r588OM0j067706 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 8 Jun 2013 08:24:26 GMT (envelope-from joelja@bogus.com) Message-ID: <51B2EA36.5040403@bogus.com> Date: Sat, 08 Jun 2013 10:24:22 +0200 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Owen DeLong , Lorenzo Colitti Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-jiang-v6ops-semantic-prefix-03 References: <05DB0BDC-9B6D-4852-B878-5320ABC14D67@steffann.nl> <8D23D4052ABE7A4490E77B1A012B6307751C5A63@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C6F61@mbx-01.win.nominum.com> <9B71CE05-E12D-4FE9-8222-6FBFD7938F0C@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751C850C@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C86DF@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307751C90F7@mbx-01.win.nominum.com> <932B5FC1-FDAB-458B-9117-56E543CC911E@delong.com> In-Reply-To: <932B5FC1-FDAB-458B-9117-56E543CC911E@delong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 08 Jun 2013 08:24:30 +0000 (UTC) Cc: "v6ops@ietf.org WG" , "" , "ipv6@ietf.org 6man-wg" , Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 08:24:37 -0000 On 6/8/13 4:17 AM, Owen DeLong wrote: >> 2. Comcast only appears to have a /29 and a /28 (2001:558::/29, 2601::/28). That's only 1.5M /48s, and they have about 10x that many customers. They likely can't use /48 plus semantic prefixes, because if ARIN doesn't accept "semantic prefixes" as using space efficiently (and word from ARIN on this thread seems, well, negative on the matter), then they won't be able to get more space from ARIN. That means that there is a fundamental tension between using semantic prefixes and giving more address space to customers. >> > It also means that Comcast has a dramatically undersized allocation and will most likely be depriving their customers. Wierdly, I know them not to been fools. one observation that can be made about larger assignments made at a later time is that: A. they have been at this a long time and thinking/application has need a long time in coming. B. They're managing their resource assignment. > Owen > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From joelja@bogus.com Sat Jun 8 01:37:33 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5905721F9A12 for ; Sat, 8 Jun 2013 01:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eb3o6OS9oP4J for ; Sat, 8 Jun 2013 01:37:32 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3362121F9A11 for ; Sat, 8 Jun 2013 01:37:32 -0700 (PDT) Received: from wifi-216-56.mtg.afnog.org (wifi-216-56.mtg.afnog.org [196.200.216.56]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r588alqc067808 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 8 Jun 2013 08:36:51 GMT (envelope-from joelja@bogus.com) Message-ID: <51B2ED1F.9030703@bogus.com> Date: Sat, 08 Jun 2013 10:36:47 +0200 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Ray Hunter , Nalini Elkins Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0BBEA.4080105@globis.net> <1370537178.16791.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0C622.8090501@globis.net> In-Reply-To: <51B0C622.8090501@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 08 Jun 2013 08:36:55 +0000 (UTC) Cc: "vishwas.manral@hp.com" , Fernando Gont , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 08:37:33 -0000 On 6/6/13 1:25 PM, Ray Hunter wrote: > Nalini Elkins wrote: >> But the reality of the situation is that much of the Internet appears >> to be running where >> >> "n is an arbitrary number picked out of the air by a vendor" The number is the product of compromise between (in no particular order) performance, transitor count, memory size, cost, heat, standards compliance, customer requirements, product lifetime. The are room for multiple products in the market-place. and some of them have quite long life-cycles. There is ipv6 capable silicon forwarding at 10Gbe/OC192 rates in the internet that was designed 13-15 years ago and which was still recently commercially available having been iteratively improved. >> Or rather >> >> "multiple arbitrary numbers"! >> >> Yes? > Correct. > > There is a non null union between the set of IETF standards and the set > of operational configurations of the various networks that form the > Internet; but neither is a proper subset of the other. That's nothing new. Part of the reasons we have a couple of drafts floating around right now related to problems in that space, is that operators want the IETF community to be aware of the limitations of where we are today. Doubtless some people participating in the IETF are aware of how asic-based-forwarding works in the internet today having made significant contributions to where we are, but not everyone is. Manufacturers are understandably cagey about the internal workings of their hardware. As on operator I have an interest in telling people if their assumptions are at variance with what we can support. > >> Thanks, >> >> Nalini Elkins >> Inside Products, Inc. >> (831) 659-8360 >> www.insidethestack.com >> >> ------------------------------------------------------------------------ >> *From:* Ray Hunter >> *To:* Nalini Elkins >> *Cc:* Brian E Carpenter ; 6man >> ; Fernando Gont ; >> "vishwas.manral@hp.com" >> *Sent:* Thursday, June 6, 2013 9:42 AM >> *Subject:* Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: >> draft-ietf-6man-ext-transmit-01) >> >> IMVHO interpreting the text of the current drafts. >> >>> Nalini Elkins > > >>> 6 June 2013 18:20 >>> So, if we are talking about the MTU of the local egress interface, >>> then since, I believe, the minimum MTU size for IPv6 is 1,280, then >>> all devices should be prepared to examine up to 1,280 bytes to get the >>> L4 header? >> Not quite. >> >> AFAICS >> >> 1. All parsing engines should be able to parse at least 1280 bytes to >> cover the minimum IPv6 MTU. >> >> 2. If all the local interfaces are Ethernet, and have an MTU set of >> 1500, the parsing engine on that box should be able to parse a full >> Ethernet frame of 1500 bytes of payload..... and so on for devices >> supporting links with larger MTUs, all the way up to jumbograms (if >> supported on that device). >> >> 3. draft-ietf-6man-ext-transmit gives the option of not parsing >> extension headers at all on high speed routers (only the hop by hop >> option is supposed to be parsed by routers on the path). But neither >> this draft, nor any other IETF draft that I know of, gives an option for >> parsing an IPv6 header chain "just for the first n bytes", where n is an >> arbitrary number picked out of the air by a vendor, whether that be 53, >> 256 or 1280. >> >> regards, >> RayH >>> Thanks, >>> >>> Nalini Elkins >>> Inside Products, Inc. >>> (831) 659-8360 >>> www.insidethestack.com >>> >>> ------------------------------------------------------------------------ >>> *From:* Ray Hunter > >>> *To:* Nalini Elkins > > >>> *Cc:* Brian E Carpenter > >; 6man >>> >; Fernando Gont >> >; >>> vishwas.manral@hp.com >>> *Sent:* Thursday, June 6, 2013 9:14 AM >>> *Subject:* draft-ietf-6man-oversized-header-chain-02 (was Re: Re: >>> draft-ietf-6man-ext-transmit-01) >>> >>> Nalini Elkins wrote: >>>>>>> Some tricky and potentially malicious cases will be avoided by >>>> forbidding very long chains of extension headers that need to be >>>>>>> fragmented [I-D.ietf-6man-oversized-header-chain]. >>>>> I wonder if this is the place to define "very long"? >>>>>> I guess those two words can be deleted - the issue is only that the >>>> header chain gets fragmented at all. The full discussion is in the >>>> cited draft, of course. >>>> >>>> I know the draft that you have cited and they do not define "long" >>>> either. There has been quite a bit of discussion about what "long" >>>> means and IMHO somewhere, someone needs to take some kind of >>>> reasonable stand. >>>> >>> Actually IMHO ietf-6man-oversized-header-chain DOES define "unusually >>> long" very accurately. >>> >>> I-D.ietf-6man-oversized-header-chain requires that "the first fragment >>> of a fragmented datagram is required to contain the entire IPv6 header >>> chain" >>> >>> So in other words, any packet parsing engine should be prepared to >>> examine an entire single frame up to the MTU of the local egress >>> interface, but should not be expected to maintain any state across >>> multiple fragments. >>> >>> We might also benefit operationally from setting an additional limit on >>> the length of the hop hop option header, which is theoretically meant to >>> be processed by routers along the path. However, my guess is that is >>> well beyond the author's original intentions for >>> draft-ietf-6man-oversized-header-chain-02, which was more focussed on >>> firewalls. >>> >>>>>> The IETF hasn't done much about firewalls at all. This >>>> search produces far more expired drafts than anything else: >> https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit= >> >> > > >> > >> > >> >>>> The reason I asked is because I think defining RFCs or rules for >>>> firewalls is a really good thing to do but if the vendors are not in >>>> the habit of having to be compliant, then why would they pay attention >>>> to this draft that we are discussing? I actually think maybe an RFC >>>> which explicitly talks about firewalls is probably a good thing to do. >>>> Now, getting vendors to comply... >>>> >>>> Thanks, >>>> >>>> Nalini Elkins >>>> Inside Products, Inc. >>>> (831) 659-8360 >>>> www.insidethestack.com >>>> >>> >>> >>> Ray Hunter > >>> 6 June 2013 18:14 >>> Nalini Elkins wrote: >>>>>>> Some tricky and potentially malicious cases will be avoided by >>>> forbidding very long chains of extension headers that need to be >>>>>>> fragmented [I-D.ietf-6man-oversized-header-chain]. >>>>> I wonder if this is the place to define "very long"? >>>>>> I guess those two words can be deleted - the issue is only that the >>>> header chain gets fragmented at all. The full discussion is in the >>>> cited draft, of course. >>>> >>>> I know the draft that you have cited and they do not define "long" >>>> either. There has been quite a bit of discussion about what "long" >>>> means and IMHO somewhere, someone needs to take some kind of >>>> reasonable stand. >>>> >>> Actually IMHO ietf-6man-oversized-header-chain DOES define "unusually >>> long" very accurately. >>> >>> I-D.ietf-6man-oversized-header-chain requires that "the first fragment >>> of a fragmented datagram is required to contain the entire IPv6 header >>> chain" >>> >>> So in other words, any packet parsing engine should be prepared to >>> examine an entire single frame up to the MTU of the local egress >>> interface, but should not be expected to maintain any state across >>> multiple fragments. >>> >>> We might also benefit operationally from setting an additional limit on >>> the length of the hop hop option header, which is theoretically meant to >>> be processed by routers along the path. However, my guess is that is >>> well beyond the author's original intentions for >>> draft-ietf-6man-oversized-header-chain-02, which was more focussed on >>> firewalls. >>> >>>>>> The IETF hasn't done much about firewalls at all. This >>>> search produces far more expired drafts than anything else: >> https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit= >> >> > > >>>> The reason I asked is because I think defining RFCs or rules for >>>> firewalls is a really good thing to do but if the vendors are not in >>>> the habit of having to be compliant, then why would they pay attention >>>> to this draft that we are discussing? I actually think maybe an RFC >>>> which explicitly talks about firewalls is probably a good thing to do. >>>> Now, getting vendors to comply... >>>> >>>> Thanks, >>>> >>>> Nalini Elkins >>>> Inside Products, Inc. >>>> (831) 659-8360 >>>> www.insidethestack.com >>>> >>> ------------------------------------------------------------------------ >> >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From joelja@bogus.com Sat Jun 8 02:13:41 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6487821F99F8 for ; Sat, 8 Jun 2013 02:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpVP+2BwVr1F for ; Sat, 8 Jun 2013 02:13:40 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B017F21F95D7 for ; Sat, 8 Jun 2013 02:13:40 -0700 (PDT) Received: from wifi-216-56.mtg.afnog.org (wifi-216-56.mtg.afnog.org [196.200.216.56]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r589Cws9068199 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 8 Jun 2013 09:13:02 GMT (envelope-from joelja@bogus.com) Message-ID: <51B2F59A.3090003@bogus.com> Date: Sat, 08 Jun 2013 11:12:58 +0200 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Ray Hunter Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> In-Reply-To: <51B0F3E6.4010006@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 08 Jun 2013 09:13:04 +0000 (UTC) Cc: "vishwas.manral@hp.com" , Fernando Gont , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 09:13:41 -0000 On 6/6/13 10:41 PM, Ray Hunter wrote: >> joel jaeggli >> 6 June 2013 22:19 >> On 6/6/13 4:09 PM, Fernando Gont wrote: >>> On 06/06/2013 06:20 PM, Nalini Elkins wrote: >>>> So, if we are talking about the MTU of the local egress interface, then >>>> since, I believe, the minimum MTU size for IPv6 is 1,280, then all >>>> devices should be prepared to examine up to 1,280 bytes to get the L4 >>>> header? >>> In theory, yes. In practice, it wouldn't make much sense, probably (most >>> of the packet containing overhead?). >> There's a question you can pose to an asic designer... What does it >> cost at this point to extend the header processing from 53/64/128/256 >> bytes. bearing in mind also that part of the reason that the space >> already has increased is due to encapsulation, label-in-label q-in-q >> so the ipv6 header is not the only thing competing for more room. >>> Cheers, > May I suggest some other questions: > > Does size matter? It does because typically the memory associated with the forwarding/header lookup is very fast and expensive. It never holds the whole packet currently. This was of course in our draft. > > Or is the complexity of the ASIC implementation of a header chain parser > more heavily influenced by the fact that the header chain is defined as > a linked list of type-length-value items that can be built up in any > number of valid combinations, and so has to be traversed and interpreted > at every individual link? Traversal is expensive yes. > > What if the most common individual TLV option tokens were standardized > further? > > And the transmission order fixed? > > What if the most common individual extension headers were standardized > further? > > And the transmission order fixed? > > Would this help make hardware parsing possible/economic? > > regards, > RayH > From v6ops@globis.net Sat Jun 8 04:06:53 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022D821F8F2F for ; Sat, 8 Jun 2013 04:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4lgceru1Lk4 for ; Sat, 8 Jun 2013 04:06:52 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 898F021F961B for ; Sat, 8 Jun 2013 04:06:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 6BBEE8700E7; Sat, 8 Jun 2013 13:06:35 +0200 (CEST) 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 yQr4XCaCrivp; Sat, 8 Jun 2013 13:06:35 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 3AF05870089; Sat, 8 Jun 2013 13:06:35 +0200 (CEST) Message-ID: <51B31034.2020903@globis.net> Date: Sat, 08 Jun 2013 13:06:28 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: joel jaeggli Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> In-Reply-To: <51B2F59A.3090003@bogus.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "vishwas.manral@hp.com" , Fernando Gont , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 11:06:53 -0000 > joel jaeggli > 8 June 2013 11:12 > On 6/6/13 10:41 PM, Ray Hunter wrote: >>> joel jaeggli >>> 6 June 2013 22:19 >>> On 6/6/13 4:09 PM, Fernando Gont wrote: >>>> On 06/06/2013 06:20 PM, Nalini Elkins wrote: >>>>> So, if we are talking about the MTU of the local egress interface, >>>>> then >>>>> since, I believe, the minimum MTU size for IPv6 is 1,280, then all >>>>> devices should be prepared to examine up to 1,280 bytes to get the L4 >>>>> header? >>>> In theory, yes. In practice, it wouldn't make much sense, probably >>>> (most >>>> of the packet containing overhead?). >>> There's a question you can pose to an asic designer... What does it >>> cost at this point to extend the header processing from 53/64/128/256 >>> bytes. bearing in mind also that part of the reason that the space >>> already has increased is due to encapsulation, label-in-label q-in-q >>> so the ipv6 header is not the only thing competing for more room. >>>> Cheers, >> May I suggest some other questions: >> >> Does size matter? > It does because typically the memory associated with the > forwarding/header lookup is very fast and expensive. It never holds > the whole packet currently. This was of course in our draft. Understood. Do you think hardware based forwarding with parsing of a header up to a single frame at wire speed is realistic in the foreseeable future? [no state required to be maintained across frames, but upper limit = entire header is contained in the 1st frame of a packet, as per draft-ietf-6man-oversized-header-chain-02] >> >> Or is the complexity of the ASIC implementation of a header chain parser >> more heavily influenced by the fact that the header chain is defined as >> a linked list of type-length-value items that can be built up in any >> number of valid combinations, and so has to be traversed and interpreted >> at every individual link? > Traversal is expensive yes. ACK. Can we as an IETF community do anything about that? "Unhindered by any technical knowledge" as they say in Dutch, if we published an *informational* RFC that defined some basic syntax structure to facilitate optimized forwarding in hardware, would this help out with simplifying future designs (less iterative traversal, less transistors, less branch complexity) and get us all more bang for the buck? I was thinking something along the lines of: - The preferred length of a Hop by Hop extension header for optimized forwarding in hardware is always 16 octets long. - the Hop by Hop EH may be present exactly once, or not present, and is always transmitted directly after the IPv6 header (already the case in 2460) - Strict processing in transmission order is not required when performing optimized hardware forwarding, and options may be evaluated in parallel (potentially dubious according to 2460) provided that only the Pad1, PadN, Jumbogram and Router Alert options are present. - the Router Alert option RFC2711 should always be the first option (4 octets) if present if not present it should be replaced with Padn option for 4 octets - the second option should always be the Jumbogram option (rfc2675) (6 octets) if present if not present it should be replaced with Padn option for 6 octets - The remaining 4 octets are currently undefined (reserved for future use) and should be filled with 4 * pad1 (4 octets) [Just trying to help out making sensible trade offs] regards, RayH >> >> What if the most common individual TLV option tokens were standardized >> further? >> >> And the transmission order fixed? >> >> What if the most common individual extension headers were standardized >> further? >> >> And the transmission order fixed? >> >> Would this help make hardware parsing possible/economic? >> >> regards, >> RayH >> > From fgont@si6networks.com Sun Jun 9 07:12:46 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3453B21F867B for ; Sun, 9 Jun 2013 07:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umuvQAYsBWtv for ; Sun, 9 Jun 2013 07:12:44 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 32C1821F85F7 for ; Sun, 9 Jun 2013 07:12:44 -0700 (PDT) Received: from [186.134.37.222] (helo=[192.168.0.6]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UlgM3-0002g9-HN; Sun, 09 Jun 2013 16:12:24 +0200 Message-ID: <51B4865D.2000207@si6networks.com> Date: Sun, 09 Jun 2013 15:42:53 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: joel jaeggli Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> In-Reply-To: <51B2F59A.3090003@bogus.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "vishwas.manral@hp.com" , Ray Hunter , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 14:12:46 -0000 On 06/08/2013 11:12 AM, joel jaeggli wrote: >> >> Or is the complexity of the ASIC implementation of a header chain parser >> more heavily influenced by the fact that the header chain is defined as >> a linked list of type-length-value items that can be built up in any >> number of valid combinations, and so has to be traversed and interpreted >> at every individual link? > Traversal is expensive yes. Yet this has always been claimed as a "feature" -- which I've never really understood, btw. IIRC, the claim was that routers didn't need to parse all options to get the ones it's interested in (as opposed to v4, where the IPv4 might contain both "destination options" and router options). However,as soon as one realizes that many boxes need to access the L4 information, this header-chain structure seems rather painful. I guess having a L4-pointer would have helped quite a lot. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Sun Jun 9 07:12:55 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB24421F9607 for ; Sun, 9 Jun 2013 07:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zeg7JlHMlE4I for ; Sun, 9 Jun 2013 07:12:55 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id CF90421F9420 for ; Sun, 9 Jun 2013 07:12:54 -0700 (PDT) Received: from [186.134.37.222] (helo=[192.168.0.6]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UlgMM-0002gH-J7; Sun, 09 Jun 2013 16:12:43 +0200 Message-ID: <51B4872B.8000505@si6networks.com> Date: Sun, 09 Jun 2013 15:46:19 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ray Hunter Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B31034.2020903@globis.net> In-Reply-To: <51B31034.2020903@globis.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "vishwas.manral@hp.com" , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 14:12:55 -0000 Ray, On 06/08/2013 01:06 PM, Ray Hunter wrote: > I was thinking something along the lines of: > > - The preferred length of a Hop by Hop extension header for optimized > forwarding in hardware is always 16 octets long. > > - the Hop by Hop EH may be present exactly once, or not present, and is > always transmitted directly after the IPv6 header (already the case in 2460) I'd say one should enforce a "each EH can be present at most once". ANd, me, I'd limit the EH chain to 1280 octets (at most) -- even that is kind of irrational: 1280 is the IPv6 minimum MTU... so we'd be allowing packets that are 100& overhead. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From v6ops@globis.net Sun Jun 9 09:37:05 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BACB721F8D16 for ; Sun, 9 Jun 2013 09:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtxXtHTx9PU0 for ; Sun, 9 Jun 2013 09:37:05 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id AF31021F8C4C for ; Sun, 9 Jun 2013 09:37:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id AB1E48700E7; Sun, 9 Jun 2013 18:36:48 +0200 (CEST) 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 Kpe1bfQxOMcH; Sun, 9 Jun 2013 18:36:48 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 8A19C870089; Sun, 9 Jun 2013 18:36:48 +0200 (CEST) Message-ID: <51B4AF1A.4070006@globis.net> Date: Sun, 09 Jun 2013 18:36:42 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Fernando Gont Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B31034.2020903@globis.net> <51B4872B.8000505@si6networks.com> In-Reply-To: <51B4872B.8000505@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "vishwas.manral@hp.com" , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 16:37:05 -0000 > Fernando Gont > 9 June 2013 15:46 > Ray, > > I'd say one should enforce a "each EH can be present at most once". > > ANd, me, I'd limit the EH chain to 1280 octets (at most) -- even that is > kind of irrational: 1280 is the IPv6 minimum MTU... so we'd be allowing > packets that are 100& overhead. > > Cheers, I just wanted to start with one simple example. It can of course be extended. BTW there is a precedent for publishing recommendations to enable optimised parsing of variable byte-aligned options. http://tools.ietf.org/html/rfc1323#page-7 & Appendix A advises an optimal layout of TCP options to enable fast processing of a commonly recurring pattern by RISC processors. > Ray Hunter > 8 June 2013 13:06 >> joel jaeggli >> 8 June 2013 11:12 >> On 6/6/13 10:41 PM, Ray Hunter wrote: >>>> joel jaeggli >>>> 6 June 2013 22:19 >>>> On 6/6/13 4:09 PM, Fernando Gont wrote: >>>>> On 06/06/2013 06:20 PM, Nalini Elkins wrote: >>>>>> So, if we are talking about the MTU of the local egress interface, >>>>>> then >>>>>> since, I believe, the minimum MTU size for IPv6 is 1,280, then all >>>>>> devices should be prepared to examine up to 1,280 bytes to get the L4 >>>>>> header? >>>>> In theory, yes. In practice, it wouldn't make much sense, probably >>>>> (most >>>>> of the packet containing overhead?). >>>> There's a question you can pose to an asic designer... What does it >>>> cost at this point to extend the header processing from 53/64/128/256 >>>> bytes. bearing in mind also that part of the reason that the space >>>> already has increased is due to encapsulation, label-in-label q-in-q >>>> so the ipv6 header is not the only thing competing for more room. >>>>> Cheers, >>> May I suggest some other questions: >>> >>> Does size matter? >> It does because typically the memory associated with the >> forwarding/header lookup is very fast and expensive. It never holds >> the whole packet currently. This was of course in our draft. > Understood. > > Do you think hardware based forwarding with parsing of a header up to a > single frame at wire speed is realistic in the foreseeable future? > > [no state required to be maintained across frames, but upper limit = > entire header is contained in the 1st frame of a packet, as per > draft-ietf-6man-oversized-header-chain-02] >>> Or is the complexity of the ASIC implementation of a header chain parser >>> more heavily influenced by the fact that the header chain is defined as >>> a linked list of type-length-value items that can be built up in any >>> number of valid combinations, and so has to be traversed and interpreted >>> at every individual link? >> Traversal is expensive yes. > ACK. > > Can we as an IETF community do anything about that? > > > "Unhindered by any technical knowledge" as they say in Dutch, if we > published an *informational* RFC that defined some basic syntax > structure to facilitate optimized forwarding in hardware, would this > help out with simplifying future designs (less iterative traversal, less > transistors, less branch complexity) and get us all more bang for the buck? > > > I was thinking something along the lines of: > > - The preferred length of a Hop by Hop extension header for optimized > forwarding in hardware is always 16 octets long. > > - the Hop by Hop EH may be present exactly once, or not present, and is > always transmitted directly after the IPv6 header (already the case in 2460) > > - Strict processing in transmission order is not required when > performing optimized hardware forwarding, and options may be evaluated > in parallel (potentially dubious according to 2460) provided that only > the Pad1, PadN, Jumbogram and Router Alert options are present. > > - the Router Alert option RFC2711 should always be the first option (4 > octets) if present > if not present it should be replaced with Padn option for 4 octets > > - the second option should always be the Jumbogram option (rfc2675) (6 > octets) if present > if not present it should be replaced with Padn option for 6 octets > > - The remaining 4 octets are currently undefined (reserved for future > use) and should be filled with 4 * pad1 (4 octets) > > > > [Just trying to help out making sensible trade offs] > > regards, > RayH > >>> What if the most common individual TLV option tokens were standardized >>> further? >>> >>> And the transmission order fixed? >>> >>> What if the most common individual extension headers were standardized >>> further? >>> >>> And the transmission order fixed? >>> >>> Would this help make hardware parsing possible/economic? >>> >>> regards, >>> RayH >>> > > From tom.taylor.stds@gmail.com Sun Jun 9 09:49:28 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1AA21F9273 for ; Sun, 9 Jun 2013 09:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EKwr3ejyok3 for ; Sun, 9 Jun 2013 09:49:28 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id E25E021F8EAE for ; Sun, 9 Jun 2013 09:49:27 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id 10so751753ied.28 for ; Sun, 09 Jun 2013 09:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=QUJvVIQP5Kvhyuatd87jA+GYHt/mNiY7kXOhK1bbxb0=; b=AbIhgwpIrKVqxBAvni1I6cYX9XFhqVkXCa9tqGxj4TrgB7hN1GKMqcgFrI1h+6n8Up RTswj7THxjh+xsXKSmv/hS5CXiEtWKTJtxGdkpju5pOOIqGlKbTlgxgn80zW4rrH9tRy myK2/R8nWZgg3BV9j1B4r4p14tZo9Q6HGb20rshotrM5yQ39M6Qo9Cw4hGMbtk77n1KR gnRtJ3a+IscW+xiGy5QHOGyVvnMkcCPkRBuBIk8UJO1Gul2NQKmg4s0MbJjAYiDL+Rg8 hyTwMobzp8usug89KiNNXUhE75cgi2yXPBsa1YtGd2Ew142jYIbL5zDsWimrEJFi4UCk gEoA== X-Received: by 10.50.131.137 with SMTP id om9mr2605512igb.1.1370796567493; Sun, 09 Jun 2013 09:49:27 -0700 (PDT) Received: from [192.168.1.64] ([216.254.162.169]) by mx.google.com with ESMTPSA id qn10sm5384510igc.6.2013.06.09.09.49.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Jun 2013 09:49:26 -0700 (PDT) Message-ID: <51B4B216.5050205@gmail.com> Date: Sun, 09 Jun 2013 12:49:26 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B4865D.2000207@si6networks.com> In-Reply-To: <51B4865D.2000207@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 16:49:28 -0000 On 09/06/2013 9:42 AM, Fernando Gont wrote: > On 06/08/2013 11:12 AM, joel jaeggli wrote: >>> >>> Or is the complexity of the ASIC implementation of a header chain parser >>> more heavily influenced by the fact that the header chain is defined as >>> a linked list of type-length-value items that can be built up in any >>> number of valid combinations, and so has to be traversed and interpreted >>> at every individual link? >> Traversal is expensive yes. > > Yet this has always been claimed as a "feature" -- which I've never > really understood, btw. > > IIRC, the claim was that routers didn't need to parse all options to get > the ones it's interested in (as opposed to v4, where the IPv4 might > contain both "destination options" and router options). > > However,as soon as one realizes that many boxes need to access the L4 > information, this header-chain structure seems rather painful. > > I guess having a L4-pointer would have helped quite a lot. > > Cheers, > Would it be practical to define a HBH option that has an L4 pointer and assign a fixed order to it? From fgont@si6networks.com Sun Jun 9 10:48:32 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE3821F9017 for ; Sun, 9 Jun 2013 10:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5r4cz19ytnhR for ; Sun, 9 Jun 2013 10:48:31 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id B2CDA21F8E9D for ; Sun, 9 Jun 2013 10:48:31 -0700 (PDT) Received: from [186.134.37.222] (helo=[192.168.0.6]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Uljiw-0007Wh-7D; Sun, 09 Jun 2013 19:48:15 +0200 Message-ID: <51B4B6CE.1060903@si6networks.com> Date: Sun, 09 Jun 2013 19:09:34 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ray Hunter Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B31034.2020903@globis.net> <51B4872B.8000505@si6networks.com> <51B4AF1A.4070006@globis.net> In-Reply-To: <51B4AF1A.4070006@globis.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "vishwas.manral@hp.com" , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 17:48:32 -0000 On 06/09/2013 06:36 PM, Ray Hunter wrote: >> Fernando Gont >> 9 June 2013 15:46 >> Ray, >> >> I'd say one should enforce a "each EH can be present at most once". >> >> ANd, me, I'd limit the EH chain to 1280 octets (at most) -- even that is >> kind of irrational: 1280 is the IPv6 minimum MTU... so we'd be allowing >> packets that are 100& overhead. >> >> Cheers, > I just wanted to start with one simple example. It can of course be > extended. Agreed. -- I should have said "I'd also limit..". Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Sun Jun 9 10:48:33 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBE121F9362 for ; Sun, 9 Jun 2013 10:48:33 -0700 (PDT) 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=[AWL=0.397, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLQYfIU6Z+RY for ; Sun, 9 Jun 2013 10:48:33 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9B221F9017 for ; Sun, 9 Jun 2013 10:48:33 -0700 (PDT) Received: from [186.134.37.222] (helo=[192.168.0.6]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UljjD-0007Wo-1L; Sun, 09 Jun 2013 19:48:32 +0200 Message-ID: <51B4B870.50500@si6networks.com> Date: Sun, 09 Jun 2013 19:16:32 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tom Taylor Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B4865D.2000207@si6networks.com> <51B4B216.5050205@gmail.com> In-Reply-To: <51B4B216.5050205@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 17:48:34 -0000 On 06/09/2013 06:49 PM, Tom Taylor wrote: >> I guess having a L4-pointer would have helped quite a lot. >> >> Cheers, >> > Would it be practical to define a HBH option that has an L4 pointer and > assign a fixed order to it? 1) I doubt that would fly. 2) IPv6 EHs seem to be so unreliable already, that if you're to implement an "extension", you better rely on something else. -- not that I like it, but... me not liking it doesn't make the situation any better :-( Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From arturo.servin@gmail.com Sun Jun 9 15:10:00 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF28621F9050 for ; Sun, 9 Jun 2013 15:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dh+WF24kqQs7 for ; Sun, 9 Jun 2013 15:09:59 -0700 (PDT) Received: from mail-gg0-x235.google.com (mail-gg0-x235.google.com [IPv6:2607:f8b0:4002:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id BAD6E21F8BB7 for ; Sun, 9 Jun 2013 15:09:59 -0700 (PDT) Received: by mail-gg0-f181.google.com with SMTP id r4so1089872ggn.12 for ; Sun, 09 Jun 2013 15:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=alxRKkO+DuGDYu9Yi7dvuZMvHZT2c/xZSqu8u/90Lxs=; b=pfnf6fZtyoNRmhA9Q1RqF4D0WVR2us6mnyXkKKPU2yxjEHWfjVNSEy45IdIodl8T0S 9fyHz5FU7Ingu79caGK+JXV1IKC/5NTo7Qz5lHhLPswFY0GWhbe5wCtahDzHjOqWFak6 STWXaBSIlzi18kOqT1wf2ceh7xu2Oi9e31tsZ21LQaTf5E2qmf8JcGFc/jvPFWwg4v9M aOnX/jH8ri2c/+5ZWOLz5XiQVVqpF/F7R+st2WTENc/7ZWv+GnUUdfqpF+eZbV8UVkpD TUbES2VC+Cw9ImtnPjzhSsKmIbrm1kR/QpDiMe1TIIk1saiXzYuvLzmk5E0Lu7qxwn6O voUg== X-Received: by 10.236.200.33 with SMTP id y21mr2961940yhn.175.1370815799097; Sun, 09 Jun 2013 15:09:59 -0700 (PDT) Received: from Arturos-MacBook-Pro.local (r186-48-221-12.dialup.adsl.anteldata.net.uy. [186.48.221.12]) by mx.google.com with ESMTPSA id v28sm541399yhv.17.2013.06.09.15.09.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Jun 2013 15:09:57 -0700 (PDT) Message-ID: <51B4FD31.1000703@gmail.com> Date: Sun, 09 Jun 2013 19:09:53 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Fernando Gont Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B31034.2020903@globis.net> <51B4872B.8000505@si6networks.com> In-Reply-To: <51B4872B.8000505@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "vishwas.manral@hp.com" , Ray Hunter , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 22:10:00 -0000 There is another conversation in v6ops that mentioned that switching ASICs do not inspect beyond 40 bytes. -as On 6/9/13 10:46 AM, Fernando Gont wrote: > Ray, > > On 06/08/2013 01:06 PM, Ray Hunter wrote: >> I was thinking something along the lines of: >> >> - The preferred length of a Hop by Hop extension header for optimized >> forwarding in hardware is always 16 octets long. >> >> - the Hop by Hop EH may be present exactly once, or not present, and is >> always transmitted directly after the IPv6 header (already the case in 2460) > > I'd say one should enforce a "each EH can be present at most once". > > ANd, me, I'd limit the EH chain to 1280 octets (at most) -- even that is > kind of irrational: 1280 is the IPv6 minimum MTU... so we'd be allowing > packets that are 100& overhead. > > Cheers, > From brian.e.carpenter@gmail.com Sun Jun 9 21:31:31 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3AA21F8F4D for ; Sun, 9 Jun 2013 21:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8f+zLtZJmDDQ for ; Sun, 9 Jun 2013 21:31:31 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 43FE821F8EB3 for ; Sun, 9 Jun 2013 21:31:31 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id tj12so2285647pac.12 for ; Sun, 09 Jun 2013 21:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=d5nWB8SWiQoTO8COf8nHDJgsatRjqutV/YjDtsmE+t0=; b=vXG5A2y98nVNotirmqv2A/x8QVxtN1z1ngS5F3VJ1z8adJt1NQky487GTdjzIib5bh ffCiZsIXaZ6/OkZsgNyoXUQcSTLKWw7tIqsTMAOsLkjorNlmCggAJKrcMePf2oP3AWpB QllnZYVsocSKD5Mn3OYPrJmFsSOqE6MOrbCRhk9b91oJVlzBjGrcwgoW6SQXR9QTWhPh nAlQh2sh1n/jksFcxS8SaBQiYAX9Eq4ht4VRbPvNHnBvQJ0K8w1aDE/dgfZVDkyXVeXk NYF3JUeNL4olnxxynafD3gDS3mOO2NW+3fguW2eG1WcHfhPsUOQP3PWYEJs7DvO0qMI3 PUCg== X-Received: by 10.66.227.38 with SMTP id rx6mr12090710pac.195.1370838690988; Sun, 09 Jun 2013 21:31:30 -0700 (PDT) Received: from [192.168.1.2] (118-92-62-227.dsl.dyn.ihug.co.nz. [118.92.62.227]) by mx.google.com with ESMTPSA id wt5sm8831052pbc.38.2013.06.09.21.31.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Jun 2013 21:31:30 -0700 (PDT) Message-ID: <51B55698.7050307@gmail.com> Date: Mon, 10 Jun 2013 16:31:20 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tom Taylor Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B4865D.2000207@si6networks.com> <51B4B216.5050205@gmail.com> In-Reply-To: <51B4B216.5050205@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 04:31:31 -0000 On 10/06/2013 04:49, Tom Taylor wrote: > On 09/06/2013 9:42 AM, Fernando Gont wrote: ... >> I guess having a L4-pointer would have helped quite a lot. >> >> Cheers, >> > Would it be practical to define a HBH option that has an L4 pointer and > assign a fixed order to it? http://tools.ietf.org/html/draft-zhang-6man-offset-option-01 It didn't fly in this WG at the time. Brian From andrewmcgr@gmail.com Sun Jun 9 22:01:16 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D4621F8B98 for ; Sun, 9 Jun 2013 22:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dVop3e8o1kf for ; Sun, 9 Jun 2013 22:01:12 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id 146E821F901F for ; Sun, 9 Jun 2013 22:01:09 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id t13so930365lbd.29 for ; Sun, 09 Jun 2013 22:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y/lll3Awc9wv3sH4shTR9hom+7o5x4KmSOfGjSdYf98=; b=m9xnOQDvEBl3biruvLC0cAex2pXH5CrdX57zLEXGfYEjILWwn12WtmYV80t16m7oxq dB5FuAx4Ie9Q3P71x1GIcHWt7hdhE1teM8lzCTYG2Ico/DtPaFc+Buq5j1wSFtfuWtx3 hBIT2sg+94VTn+XMFNH1yOSKJqRrpS0n5q0YDd3qv0ac+tMyIyhQ+ilwFvN8fsA1e+uT RG2rAYmmujZ+7Wv6JmNodNo+YBhff+vfwvh20diZTT9z8bbZ9CNcZ3ydxNe4q+heEw/E ADVXaahxZ9UiQa8amnX6rKGQf3bqhdqMQCLGo+sXewpHFMVNWNj7PXgmo0AZadDfjjfV 8fwQ== MIME-Version: 1.0 X-Received: by 10.112.125.199 with SMTP id ms7mr5679571lbb.29.1370840467556; Sun, 09 Jun 2013 22:01:07 -0700 (PDT) Received: by 10.112.5.65 with HTTP; Sun, 9 Jun 2013 22:01:07 -0700 (PDT) In-Reply-To: <51B4FD31.1000703@gmail.com> References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B31034.2020903@globis.net> <51B4872B.8000505@si6networks.com> <51B4FD31.1000703@gmail.com> Date: Mon, 10 Jun 2013 15:01:07 +1000 Message-ID: Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) From: Andrew McGregor To: Arturo Servin Content-Type: multipart/alternative; boundary=089e012284fa1cce7004dec5abd4 Cc: "vishwas.manral@hp.com" , Fernando Gont , 6man , Ray Hunter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 05:01:16 -0000 --089e012284fa1cce7004dec5abd4 Content-Type: text/plain; charset=ISO-8859-1 Which is definitely not true in general. Some do that, many do not inspect beyond 128, some go further. On Mon, Jun 10, 2013 at 8:09 AM, Arturo Servin wrote: > > There is another conversation in v6ops that mentioned that > switching > ASICs do not inspect beyond 40 bytes. > > > -as > > On 6/9/13 10:46 AM, Fernando Gont wrote: > > Ray, > > > > On 06/08/2013 01:06 PM, Ray Hunter wrote: > >> I was thinking something along the lines of: > >> > >> - The preferred length of a Hop by Hop extension header for optimized > >> forwarding in hardware is always 16 octets long. > >> > >> - the Hop by Hop EH may be present exactly once, or not present, and is > >> always transmitted directly after the IPv6 header (already the case in > 2460) > > > > I'd say one should enforce a "each EH can be present at most once". > > > > ANd, me, I'd limit the EH chain to 1280 octets (at most) -- even that is > > kind of irrational: 1280 is the IPv6 minimum MTU... so we'd be allowing > > packets that are 100& overhead. > > > > Cheers, > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --089e012284fa1cce7004dec5abd4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Which is definitely not true in general. =A0Some do that, = many do not inspect beyond 128, some go further.


    On Mon, Jun 10, 2013 at 8:09 AM, A= rturo Servin <arturo.servin@gmail.com> wrote:

    =A0 =A0 =A0 =A0 There is another conversation in v6ops that mentioned that = switching
    ASICs do not inspect beyond 40 bytes.


    -as

    On 6/9/13 10:46 AM, Fernando Gont wrote:
    > Ray,
    >
    > On 06/08/2013 01:06 PM, Ray Hunter wrote:
    >> I was thinking something along the lines of:
    >>
    >> - The preferred length of a Hop by Hop extension header for optimi= zed
    >> forwarding in hardware is always 16 octets long.
    >>
    >> - the Hop by Hop EH may be present exactly once, or not present, a= nd is
    >> always transmitted directly after the IPv6 header (already the cas= e in 2460)
    >
    > I'd say one should enforce a "each EH can be present at most = once".
    >
    > ANd, me, I'd limit the EH chain to 1280 octets (at most) -- even t= hat is
    > kind of irrational: 1280 is the IPv6 minimum MTU... so we'd be all= owing
    > packets that are 100& overhead.
    >
    > Cheers,
    >
    -----------------------------= ---------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------

    --089e012284fa1cce7004dec5abd4-- From joelja@bogus.com Sun Jun 9 22:40:23 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E1021F90CC for ; Sun, 9 Jun 2013 22:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onWTuP2z+LXY for ; Sun, 9 Jun 2013 22:40:23 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2F721F8B90 for ; Sun, 9 Jun 2013 22:40:23 -0700 (PDT) Received: from joels-MacBook-Air.local ([41.223.117.26]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r5A5daPH018670 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 10 Jun 2013 05:39:41 GMT (envelope-from joelja@bogus.com) Message-ID: <51B56692.4030101@bogus.com> Date: Mon, 10 Jun 2013 07:39:30 +0200 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0 MIME-Version: 1.0 To: Andrew McGregor , Arturo Servin Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B31034.2020903@globis.net> <51B4872B.8000505@si6networks.com> <51B4FD31.1000703@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 10 Jun 2013 05:39:44 +0000 (UTC) Cc: "vishwas.manral@hp.com" , Fernando Gont , 6man , Ray Hunter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 05:40:23 -0000 On 6/10/13 7:01 AM, Andrew McGregor wrote: > Which is definitely not true in general. Some do that, many do not > inspect beyond 128, some go further. > The lower bound is probably 53. There's a lowest common denominator problem if you expect to be able to find an l4 header as part of your forwarding decision > > On Mon, Jun 10, 2013 at 8:09 AM, Arturo Servin > > wrote: > > > There is another conversation in v6ops that mentioned that > switching > ASICs do not inspect beyond 40 bytes. > That was never said. You should reread the thread. What was said is that the fixed portion of the ipv6 header is 40 bytes, which is all you need to forward on modula hop-by-hop options. unless you need to find the l4 header for some reason in which case you're back to here: http://tools.ietf.org/html/draft-wkumari-long-headers-00 > > > > -as > > On 6/9/13 10:46 AM, Fernando Gont wrote: > > Ray, > > > > On 06/08/2013 01:06 PM, Ray Hunter wrote: > >> I was thinking something along the lines of: > >> > >> - The preferred length of a Hop by Hop extension header for > optimized > >> forwarding in hardware is always 16 octets long. > >> > >> - the Hop by Hop EH may be present exactly once, or not > present, and is > >> always transmitted directly after the IPv6 header (already the > case in 2460) > > > > I'd say one should enforce a "each EH can be present at most once". > > > > ANd, me, I'd limit the EH chain to 1280 octets (at most) -- even > that is > > kind of irrational: 1280 is the IPv6 minimum MTU... so we'd be > allowing > > packets that are 100& overhead. > > > > Cheers, > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From randy@psg.com Mon Jun 10 03:49:29 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C59221F85C0 for ; Mon, 10 Jun 2013 03:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQ+Pyz2HlWKB for ; Mon, 10 Jun 2013 03:49:19 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id DE14221F85BF for ; Mon, 10 Jun 2013 03:49:10 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Ulzeu-00066w-TB; Mon, 10 Jun 2013 10:49:09 +0000 Date: Mon, 10 Jun 2013 12:49:06 +0200 Message-ID: From: Randy Bush To: Andrew McGregor Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) In-Reply-To: References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B31034.2020903@globis.net> <51B4872B.8000505@si6networks.com> <51B4FD31.1000703@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 10:49:29 -0000 i think of it as a somewhat arbitrary operational (not protocol, i.e. does not belong in this wg) best common practice. just as i warn my customer that they can announce a /64 to me, and can pay me to announce it to my peers, that my peers will not listen to it or propagate it. similarly, you might be able to send 4k of bleeding extension headers to me, but i am likely to drop the packet on the floor. and if i don't, someone down the line likely will. so i would suggest a bcp draft in grow or v6ops that says that it is unsafe to send more than X bytes in extensions. randy From arturo.servin@gmail.com Mon Jun 10 04:29:32 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4816821F871D for ; Mon, 10 Jun 2013 04:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diGSZkQ0XOSX for ; Mon, 10 Jun 2013 04:29:31 -0700 (PDT) Received: from mail-gh0-x231.google.com (mail-gh0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD8D21F8633 for ; Mon, 10 Jun 2013 04:29:31 -0700 (PDT) Received: by mail-gh0-f177.google.com with SMTP id f20so851500ghb.22 for ; Mon, 10 Jun 2013 04:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=iYiGzbwGV8a5zUWgRzdtvLLsCaM1IXzwvuzfq4p1BZg=; b=MjUhSog+kKxPV5W2P73II8oCj6lRCi7CdZKSjedMJQTN7+F13TVB3FFqEIFqD/Ma8a anvdWHoMIxVufMrCskZtNf86drZyYPUZD/bS3Vi4X0XEeWGSHfMf8dT/lTh/kxHK+dOA m9p1wR5Q6JCHqHaXyK9HVkAuuWlDyz1ML7Jui/RBIwWq+Gqv/T0Sl8dCFefYQ34p+ZYi 53u8mDKixwIwVmP9W+Rp5d8bZv+5kLgKj/+XA9Hcyqe4WLelg3+kYvOH59NWZvQ/rDGU xTTn0ywdidz51aqdK3TwwzlU+ndOBRyVMXitLTNEv30ntJTgypQ/z0rI5WOFW0VHF1aN 2sBg== X-Received: by 10.236.118.105 with SMTP id k69mr3800419yhh.102.1370863770845; Mon, 10 Jun 2013 04:29:30 -0700 (PDT) Received: from Arturos-MacBook-Pro.local ([2800:af:ba30:e7d3:1d11:e371:b0f2:ff19]) by mx.google.com with ESMTPSA id v31sm14914307yhe.13.2013.06.10.04.29.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Jun 2013 04:29:30 -0700 (PDT) Message-ID: <51B5B894.6070708@gmail.com> Date: Mon, 10 Jun 2013 08:29:24 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: joel jaeggli Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B31034.2020903@globis.net> <51B4872B.8000505@si6networks.com> <51B4FD31.1000703@gmail.com> <51B56692.4030101@bogus.com> In-Reply-To: <51B56692.4030101@bogus.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "vishwas.manral@hp.com" , Fernando Gont , 6man , Ray Hunter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 11:29:32 -0000 Joel My mistake, you are right. And thanks for the reference, that is exactly what I needed to clear some doubts. Nevertheless, shouldn't we see the problem of long headers chains as operational and security instead of two separate issues as we have now? Regards, as On 6/10/13 2:39 AM, joel jaeggli wrote: > On 6/10/13 7:01 AM, Andrew McGregor wrote: >> Which is definitely not true in general. Some do that, many do not >> inspect beyond 128, some go further. >> > The lower bound is probably 53. There's a lowest common denominator > problem if you expect to be able to find an l4 header as part of your > forwarding decision >> >> On Mon, Jun 10, 2013 at 8:09 AM, Arturo Servin >> > wrote: >> >> >> There is another conversation in v6ops that mentioned that >> switching >> ASICs do not inspect beyond 40 bytes. >> > That was never said. You should reread the thread. What was said is that > the fixed portion of the ipv6 header is 40 bytes, which is all you need > to forward on modula hop-by-hop options. unless you need to find the l4 > header for some reason in which case you're back to here: > > http://tools.ietf.org/html/draft-wkumari-long-headers-00 >> >> >> >> -as >> >> On 6/9/13 10:46 AM, Fernando Gont wrote: >> > Ray, >> > >> > On 06/08/2013 01:06 PM, Ray Hunter wrote: >> >> I was thinking something along the lines of: >> >> >> >> - The preferred length of a Hop by Hop extension header for >> optimized >> >> forwarding in hardware is always 16 octets long. >> >> >> >> - the Hop by Hop EH may be present exactly once, or not >> present, and is >> >> always transmitted directly after the IPv6 header (already the >> case in 2460) >> > >> > I'd say one should enforce a "each EH can be present at most once". >> > >> > ANd, me, I'd limit the EH chain to 1280 octets (at most) -- even >> that is >> > kind of irrational: 1280 is the IPv6 minimum MTU... so we'd be >> allowing >> > packets that are 100& overhead. >> > >> > Cheers, >> > >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From nalini.elkins@insidethestack.com Mon Jun 10 07:10:09 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E3F21F84CA for ; Mon, 10 Jun 2013 07:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=-0.814, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPfn2N+vL8uA for ; Mon, 10 Jun 2013 07:10:02 -0700 (PDT) Received: from nm2.access.bullet.mail.sp2.yahoo.com (nm2.access.bullet.mail.sp2.yahoo.com [98.139.44.129]) by ietfa.amsl.com (Postfix) with ESMTP id 6794621F84AF for ; Mon, 10 Jun 2013 07:10:02 -0700 (PDT) Received: from [98.139.44.107] by nm2.access.bullet.mail.sp2.yahoo.com with NNFMP; 10 Jun 2013 14:10:00 -0000 Received: from [98.139.44.72] by tm12.access.bullet.mail.sp2.yahoo.com with NNFMP; 10 Jun 2013 14:10:00 -0000 Received: from [127.0.0.1] by omp1009.access.mail.sp2.yahoo.com with NNFMP; 10 Jun 2013 14:10:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 234014.94894.bm@omp1009.access.mail.sp2.yahoo.com Received: (qmail 21374 invoked by uid 60001); 10 Jun 2013 14:09:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370873399; bh=c0i32cVf/jSgAvcvADTxC3ZTDXB5Vw6ufUZNT8jmMjg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=chVC9Zdv1IV6mKfsPVauzNHAT7DP0tSqx8xijw9IrVqETkKUnQjRZ8d5LebAYDa3Pui+8DzvYu2AunaDdr3gOoSc3VPRSXo70Rdq+izEcr24mzGEUoCAFl6LbXQ5Q3K0H9LAndlwlAMzJb1KqWpqcUHOdUGzMNOf97U51//42I4= X-YMail-OSG: XWBHzDsVM1m3XyI3N71mC_nYufnCXjIiib1lLjWAPat9gga pxirkKMaBQngeuNoDgffXuQiqrv34J6zK0xlMdMyanBxo1bbZr3dEzmgIXZc RNwUOkG4Iz5Rz3u9uRUNoxn65n3YskV.0NB74VgJ057KwgSOd80vcaEkZKpb pU9H2qicxQ4vo9M4BHcKkruyjvrdYUAsc7p2ESDrB2FLLoTsEMuVTfFRnL_o __XUjlgt5u1FH.p3cWrmGAleRXMVnVLX1uqQifVYHofioPerfvBYqFTIvWMB apNf5GMWumTKvvrLnRyrIcY3Ls1jaXiSe.dWV0Y8FhWFxYFuj_m6hLHaI.gI Rsv_DTPr_sQIeTLUYHXjg8U7GD6oWKGQwYSvjGncvvk_l6euYMxRVmdxd7_s SxSGxXZyuks576_nZTNkD3zz9zfXp7g7gFIbXBLF5zHjx.pCMzd9eOOOA7I7 uNGzGuRCkXrpRQsCILFGS.Bls8Ds_x_2wVo_xErAUON7_0jux2JTrFWQVQNl NJF7RNWjK1fxwbKdoa_eISY0YNYNte0AsMOEUi4Rhe6d_OGUeDqFzaHdywpl orA-- Received: from [24.130.37.147] by web2806.biz.mail.ne1.yahoo.com via HTTP; Mon, 10 Jun 2013 07:09:59 PDT X-Rocket-MIMEInfo: 002.001, Cj5UaGUgbG93ZXIgYm91bmQgaXMgcHJvYmFibHkgNTMuIFRoZXJlJ3MgYSBsb3dlc3QgY29tbW9uIGRlbm9taW5hdG9ywqAKPnByb2JsZW0gaWYgeW91IGV4cGVjdCB0byBiZSBhYmxlIHRvIGZpbmQgYW4gbDQgaGVhZGVyIGFzIHBhcnQgb2YgeW91csKgCj5mb3J3YXJkaW5nIGRlY2lzaW9uCgoKR3V5cywKCjUzID0gbm90IGdvb2QuIMKgSnVzdCBiZWNhdXNlIHNvbWUgcGVvcGxlIGFyZSByZS11c2luZyBvbGQgaGFyZHdhcmUgY2FyZHMgdGhleSBoYWQgaGFuZ2luZyBhcm91bmQgZG9lcyBub3QgbWVhbiBldmUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.146.552 References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B31034.2020903@globis.net> <51B4872B.8000505@si6networks.com> <51B4FD31.1000703@gmail.com> <51B56692.4030101@bogus.com> Message-ID: <1370873399.18459.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Date: Mon, 10 Jun 2013 07:09:59 -0700 (PDT) From: Nalini Elkins Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) To: joel jaeggli , Andrew McGregor , Arturo Servin In-Reply-To: <51B56692.4030101@bogus.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1510626085-431383404-1370873399=:18459" Cc: "vishwas.manral@hp.com" , Fernando Gont , 6man , Ray Hunter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 14:10:09 -0000 --1510626085-431383404-1370873399=:18459 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A>The lower bound is probably 53. There's a lowest common denominator=A0= =0A>problem if you expect to be able to find an l4 header as part of your= =A0=0A>forwarding decision=0A=0A=0AGuys,=0A=0A53 =3D not good. =A0Just beca= use some people are re-using old hardware cards they had hanging around doe= s not mean everyone has to go along with it.=0A=0ANalini --1510626085-431383404-1370873399=:18459 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

    >The lower bound is probably= 53. There's a lowest common denominator 
    >problem if you expect = to be able to find an l4 header as part of your 
    >forwarding deci= sion

    Guys,

    53 =3D not good.  Just because some people are re-u= sing old hardware cards they had hanging around does not mean everyone has = to go along with it.

    Nalini
    --1510626085-431383404-1370873399=:18459-- From christopher.morrow@gmail.com Mon Jun 10 07:32:01 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03C321F8956 for ; Mon, 10 Jun 2013 07:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACaE4UZq9i-I for ; Mon, 10 Jun 2013 07:32:01 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9A23721F894E for ; Mon, 10 Jun 2013 07:32:00 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id lx15so4794882lab.35 for ; Mon, 10 Jun 2013 07:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qmBjoBlfJqPhHZXRpKT19Y6MKMqKkmhLTzyQPAU5/90=; b=GS6lec8XqfzxDONVXd9Hcic6Uw+thnkBWw/9Bbl25XapEd4meOO4gREETEJsecudDE raW+gzIqJnFf+PfQ7ItM0EXeDfErWeiLGOKq8GT3BhUZpn+o1NnWD9dVPWBYdXBojG6n 1Meq1hXPaz2g8n0Qyi690prG2sZbbgmmyZZ8z2v4+UQWrEwgJR+ZcFuhdY4RU+zY1KKs rWt62IFXUNuwzZN993z1cNHvlXCjH2zc+5zlo3b61y9AMpI9a0FEPrkwavMJvSMsKT8Y Lsb+zZmb1Jjv4J+PB/RgvqmaTdC8ZXbG0AI8SdyVyBCtrFcukei6NLMm5wDyPQgAw9ZD uiog== MIME-Version: 1.0 X-Received: by 10.112.146.97 with SMTP id tb1mr6771971lbb.26.1370874719469; Mon, 10 Jun 2013 07:31:59 -0700 (PDT) Received: by 10.152.133.37 with HTTP; Mon, 10 Jun 2013 07:31:59 -0700 (PDT) In-Reply-To: <1370873399.18459.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B31034.2020903@globis.net> <51B4872B.8000505@si6networks.com> <51B4FD31.1000703@gmail.com> <51B56692.4030101@bogus.com> <1370873399.18459.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Date: Mon, 10 Jun 2013 10:31:59 -0400 Message-ID: Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) From: Christopher Morrow To: Nalini Elkins Content-Type: text/plain; charset=ISO-8859-1 Cc: "vishwas.manral@hp.com" , 6man , Arturo Servin , Ray Hunter , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 14:32:02 -0000 On Mon, Jun 10, 2013 at 10:09 AM, Nalini Elkins wrote: > 53 = not good. Just because some people are re-using old hardware cards > they had hanging around does not mean everyone has to go along with it. define old. define 'hanging around' define the location from which capex can be drawn to replace 'old' and 'hanging around' modules which are clearly perfectly functional in the network today. -chris From joelja@bogus.com Mon Jun 10 07:35:23 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C918321F8F87 for ; Mon, 10 Jun 2013 07:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBU85c9u524H for ; Mon, 10 Jun 2013 07:35:23 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 301A921F8F6E for ; Mon, 10 Jun 2013 07:35:23 -0700 (PDT) Received: from wifi-216-88.mtg.afnog.org (wifi-216-88.mtg.afnog.org [196.200.216.88]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r5AEYWaW023946 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 10 Jun 2013 14:34:36 GMT (envelope-from joelja@bogus.com) Message-ID: <51B5E3F7.1050105@bogus.com> Date: Mon, 10 Jun 2013 16:34:31 +0200 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0 MIME-Version: 1.0 To: Nalini Elkins , Andrew McGregor , Arturo Servin Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B31034.2020903@globis.net> <51B4872B.8000505@si6networks.com> <51B4FD31.1000703@gmail.com> <51B56692.4030101@bogus.com> <1370873399.18459.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> In-Reply-To: <1370873399.18459.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 10 Jun 2013 14:34:38 +0000 (UTC) Cc: "vishwas.manral@hp.com" , Fernando Gont , 6man , Ray Hunter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 14:35:23 -0000 On 6/10/13 4:09 PM, Nalini Elkins wrote: > > >The lower bound is probably 53. There's a lowest common denominator > >problem if you expect to be able to find an l4 header as part of your > >forwarding decision > > Guys, > > 53 = not good. Just because some people are re-using old hardware > cards they had hanging around does not mean everyone has to go along > with it. Last time I bought one of that particular arch boxes new was in 2011. I don't have any in my current network but things don't age out of the internet as quickly as I can change jobs, certainly not in enterprises either. > Nalini From fgont@si6networks.com Mon Jun 10 07:52:54 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302C121F940D for ; Mon, 10 Jun 2013 07:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvsHeodYC5nt for ; Mon, 10 Jun 2013 07:52:53 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 298CF21F9458 for ; Mon, 10 Jun 2013 07:52:49 -0700 (PDT) Received: from [186.134.37.222] (helo=[192.168.0.6]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Um3Sa-0004vM-Uc; Mon, 10 Jun 2013 16:52:41 +0200 Message-ID: <51B5E823.6050802@si6networks.com> Date: Mon, 10 Jun 2013 16:52:19 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Nalini Elkins Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B31034.2020903@globis.net> <51B4872B.8000505@si6networks.com> <51B4FD31.1000703@gmail.com> <51B56692.4030101@bogus.com> <1370873399.18459.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> In-Reply-To: <1370873399.18459.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "vishwas.manral@hp.com" , 6man , Arturo Servin , Ray Hunter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 14:52:54 -0000 On 06/10/2013 04:09 PM, Nalini Elkins wrote: > >>The lower bound is probably 53. There's a lowest common denominator >>problem if you expect to be able to find an l4 header as part of your >>forwarding decision > > Guys, > > 53 = not good. Just because some people are re-using old hardware cards > they had hanging around does not mean everyone has to go along with it. Agreed: You can always choose to "engineer" an un-deployable protocol/mechanism and complain about the network. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nalini.elkins@insidethestack.com Mon Jun 10 07:56:42 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A411621F938E for ; Mon, 10 Jun 2013 07:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.461, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSowasB8Ohyo for ; Mon, 10 Jun 2013 07:56:35 -0700 (PDT) Received: from nm21-vm0.access.bullet.mail.mud.yahoo.com (nm21-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.31]) by ietfa.amsl.com (Postfix) with ESMTP id 3F94221F86CA for ; Mon, 10 Jun 2013 07:56:33 -0700 (PDT) Received: from [66.94.237.201] by nm21.access.bullet.mail.mud.yahoo.com with NNFMP; 10 Jun 2013 14:56:32 -0000 Received: from [66.94.237.110] by tm12.access.bullet.mail.mud.yahoo.com with NNFMP; 10 Jun 2013 14:56:32 -0000 Received: from [127.0.0.1] by omp1015.access.mail.mud.yahoo.com with NNFMP; 10 Jun 2013 14:56:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 723650.3284.bm@omp1015.access.mail.mud.yahoo.com Received: (qmail 71635 invoked by uid 60001); 10 Jun 2013 14:56:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370876192; bh=KRTLZtG7Pua4cZYMlh6TwvFNRSdt1MUcto+BN/7Yuow=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ae108NxzGldSgTB8vNqnGdMelx1UwM+S2DnwmeMYPwbXIe7hDIactKx8IL3pTlGl7/kyI3tUkb6RZZntec0AVOqyLAVoMLGH+GBq43vWJMk4GVBht3HbujptdqL34Rg3jBE943k67z5Mbxt/wdBd2yfGsiFzwh4FuU0UKqFbiaA= X-YMail-OSG: BASSf2YVM1mwMB8X0yvt2s4ZjbkeSOr39V4eDNr7OQqW2dQ V10ZSK5VMfBBmHZBKdjUa6IWk8wtSHw7fI_.gq2r78BfyRq.NylIQsdIFvD0 WrCtjOf83.3tnnJwFQHdpJY00QyvyFHp94kzdoMHF3yyaR1qcs0la9.NAuU9 nAoZLKOdRLVjWnU3cJfqJtpLLPRsQq0Cpq5MLVfvbL1Ca40EO.NDF3UE4p_l rcphA5jOFnh0px0PUuMCCkyuU1f78AZJbfsX431LdsoPTJ9r4_XFCaGJKlng jYPUml.zWtgQbF3MLRBGsfVRpl406Pv3Ksy21q0XEZqk6hNObNn70SNWafCm Ro9ko8rFEkXXmd1BELYFjrupYq8TCA_sAUlzlpgExBGFnTK9p2qTs7KtjIHp bSE7VmLcWiRN38H8eq1QTKXqEmH3KRo5w4LMRqArOy8AZc4yxdIzxmRBuDGX desNDSaorR8sundAndDwUEZjspOeRj17Bs8v.mkTSVy8wRC1fmf7EBodo88h JikWg5t59UrIsm5t_UPX7L0ydD369hIiZxDOBW5KZPW7Dokg4nGYIPKqe Received: from [24.130.37.147] by web2801.biz.mail.ne1.yahoo.com via HTTP; Mon, 10 Jun 2013 07:56:32 PDT X-Rocket-MIMEInfo: 002.001, CgrCoD4gPlRoZSBsb3dlciBib3VuZCBpcyBwcm9iYWJseSA1My4gVGhlcmUncyBhIGxvd2VzdCBjb21tb24gZGVub21pbmF0b3I.ID5wcm9ibGVtIGlmIHlvdSBleHBlY3QgdG8gYmUgYWJsZSB0byBmaW5kIGFuIGw0IGhlYWRlciBhcyBwYXJ0IG9mIHlvdXIKPiA.Zm9yd2FyZGluZyBkZWNpc2lvbgo.wqAKPiBHdXlzLAo.wqAKPiA1MyA9IG5vdCBnb29kLsKgIEp1c3QgYmVjYXVzZSBzb21lIHBlb3BsZSBhcmUgcmUtdXNpbmcgb2xkIGhhcmR3YXJlIGNhcmRzIHRoZXkgaGFkIGhhbmdpbmcgYXJvdW5kIGRvZXMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.146.552 References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B31034.2020903@globis.net> <51B4872B.8000505@si6networks.com> <51B4FD31.1000703@gmail.com> <51B56692.4030101@bogus.com> <1370873399.18459.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B5E3F7.1050105@bogus.com> Message-ID: <1370876192.70632.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Date: Mon, 10 Jun 2013 07:56:32 -0700 (PDT) From: Nalini Elkins Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) To: joel jaeggli , Andrew McGregor , Arturo Servin In-Reply-To: <51B5E3F7.1050105@bogus.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="36908767-1999705165-1370876192=:70632" Cc: "vishwas.manral@hp.com" , Fernando Gont , 6man , Ray Hunter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 14:56:42 -0000 --36908767-1999705165-1370876192=:70632 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A=A0> >The lower bound is probably 53. There's a lowest common denomin= ator> >problem if you expect to be able to find an l4 header as part of you= r=0A> >forwarding decision=0A>=A0=0A> Guys,=0A>=A0=0A> 53 =3D not good.=A0 = Just because some people are re-using old hardware cards they had hanging a= round does not mean everyone has to go along with it.=0A=0A>>Last time=A0 I= bought one of that particular arch boxes new was in 2011. I don't have any= in my current network but things don't age out of the internet as quickly = as I can change jobs, certainly not in enterprises either.=0A=0ASure. =A0I = don't even want to get started on war stories of the kind of equipment / so= ftware protocols some of our folks have hanging around. =A0I totally know t= hat but I don't encourage them buying more of the same either!=0A=0AI suppo= se what I am thinking is that since there are no "IETF Police", then the on= ly "teeth" there are in the standards is the ability to say "this is not co= mpliant". =A0That is not a trivial thing. =A0People pay attention to that.= =0A=0AIf there is consensus that EH's are valuable - then, maybe the way fo= rward should be to:=0A=0A1. =A0Decide how to get to the L4 header best.=0A= =0A2. =A0Maybe a recommendation on how much of the header should be read in= to ASIC. =A0Is that out of scope?=0A=0ANalini --36908767-1999705165-1370876192=:70632 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

     > >The lower bound is prob= ably 53. There's a lowest common denominator
    > >problem if= you expect to be able to find an l4 header as part of your
    > >for= warding decision
    > 
    > Guys,
    > 
    > 53 =3D not good. = Just because some people are re-using old hardware cards they had hanging = around does not mean everyone has to go along with it.

    >>Last time  I bought on= e of that particular arch boxes new was in 2011. I don't have any in my cur= rent network but things don't age out of the internet as quickly as I can change jobs, = certainly not in enterprises either.

    Sure.  I don't even want to g= et started on war stories of the kind of equipment / software protocols som= e of our folks have hanging around.  I totally know that but I don't e= ncourage them buying more of the same either!

    I suppose what I = am thinking is that since there are no "IETF Police", then the only "teeth"= there are in the standards is the ability to say "this is not compliant". =  That is not a trivial thing.  People pay attention to that.

    If th= ere is consensus that EH's are valuable - then, maybe the way forward should b= e to:

    1.  Decide how to get to the L4 header best.

    <= font face=3D"times new roman, new york, times, serif">2.  Maybe a reco= mmendation on how much of the header should be read into ASIC.  Is tha= t out of scope?

    Nalini
    --36908767-1999705165-1370876192=:70632-- From randy@psg.com Mon Jun 10 07:57:28 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B74021F9476 for ; Mon, 10 Jun 2013 07:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4S+t1m8WK82B for ; Mon, 10 Jun 2013 07:57:27 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id EAF6A21F949D for ; Mon, 10 Jun 2013 07:57:22 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Um3X0-00075c-U3; Mon, 10 Jun 2013 14:57:15 +0000 Date: Mon, 10 Jun 2013 16:57:10 +0200 Message-ID: From: Randy Bush To: Nalini Elkins Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) In-Reply-To: <1370873399.18459.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B31034.2020903@globis.net> <51B4872B.8000505@si6networks.com> <51B4FD31.1000703@gmail.com> <51B56692.4030101@bogus.com> <1370873399.18459.YahooMailNeo@web2806.biz.mail.ne1.yahoo.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=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "vishwas.manral@hp.com" , 6man , Arturo Servin , Ray Hunter , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 14:57:28 -0000 > 53 =3D not good. =A0Just because some people are re-using old hardware > cards they had hanging around does not mean everyone has to go along > with it. you are completely correct. you are welcome to send 10gb of headers. just do not be surprised when they do not make it to the destination. welcome to ops reality. randy From warren@kumari.net Mon Jun 10 08:04:02 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C0E21E804C for ; Mon, 10 Jun 2013 08:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.584 X-Spam-Level: X-Spam-Status: No, score=-101.584 tagged_above=-999 required=5 tests=[AWL=1.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fc67HheHKuhF for ; Mon, 10 Jun 2013 08:03:55 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A48021F9005 for ; Mon, 10 Jun 2013 08:03:51 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.108]) by vimes.kumari.net (Postfix) with ESMTPSA id 302F91B401CE; Mon, 10 Jun 2013 11:03:36 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [6MAN] draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) From: Warren Kumari In-Reply-To: <51B55698.7050307@gmail.com> Date: Mon, 10 Jun 2013 11:03:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <510D1209-7F9E-42AA-B790-A418CBF2959D@kumari.net> References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B4865D.2000207@si6networks.com> <51B4B216.5050205@gmail.com> <51B55698.7050307@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1503) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 15:04:02 -0000 On Jun 10, 2013, at 12:31 AM, Brian E Carpenter = wrote: > On 10/06/2013 04:49, Tom Taylor wrote: >> On 09/06/2013 9:42 AM, Fernando Gont wrote: >=20 > ... >>> I guess having a L4-pointer would have helped quite a lot. >>>=20 >>> Cheers, >>>=20 >> Would it be practical to define a HBH option that has an L4 pointer = and >> assign a fixed order to it? >=20 > http://tools.ietf.org/html/draft-zhang-6man-offset-option-01 >=20 > It didn't fly in this WG at the time. The issue is that, in order to be able to see header X you need to push = all the bits up to header X onto the forwarding engine. Having a header = that says "The L4 header is at byte 142" simply pushes the L4 out by = another 8 bytes, exacerbating the problem. This issue is: 1: In order to make a decision on header X the forwarding / filtering = engine needs to see header X 2: This require pushing at least up to the forwarding engine in a "cell". 3: Bandwidth into the forwarding engine is expensive / limited, and = storage on the forwarding engine is expensive (this is not DRAM ;-)) 4: As you don't know (until you've looked) how far into the packet = header X is, you need to choose some number and ship that many bytes to = the forwarding engine. 5: Having a header that points at the L4 info doesn't help -- by the = time you can see it you've already sucked the bits onto the engine.=20 6: Having additional logic that "prescreens" the packets looking for a = pointer header *could* possibly work, but that is much of the forwarding = engine logic - see #3. Choosing the optimum cell size is the tricky bit. If you increase the = cell size you vastly increase cost -- if your competitors don't do the = same, you've priced yourself out of the market.=20 We are planning on updating the long-headers draft / publishing another = "implementers guide" draft that suggests 128 or 256 bytes (as a straw = man). This will hopefully be something that major vendors will sign up = for. W > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -- It's a mistake trying to cheer up camels. You might as well drop = meringues into a black hole. -- Terry Prachett From christopher.morrow@gmail.com Mon Jun 10 08:22:51 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D08D21F971B for ; Mon, 10 Jun 2013 08:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.1 X-Spam-Level: X-Spam-Status: No, score=-103.1 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5o6fq6u9VPV for ; Mon, 10 Jun 2013 08:22:45 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id BD8A621F96FE for ; Mon, 10 Jun 2013 08:22:44 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id o10so4005556lbi.25 for ; Mon, 10 Jun 2013 08:22:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qntih9a9NJ0f7/KZ18YN7+1T/9u24VuyagJmfIxa7PM=; b=lg+TAuNrBt/lU7X3grWgT3+6IcAahjMs9H/0WM5ajAk79p9je8R1KYi8lBp7v0PfOn VJ7Q2FWbbresG77KTIAAviQYkIWsln/29BOXuw13nm7CVh2CZmdQLlomgCr4/lHNRnSU 90bPiMIn+hf+lOUyl6sXui9hxpC9aRIWDCMTr4xWt9gYT/bUekeg8r3jip9svAidw+p6 p+R8S7xDDq4UmqazRG98eGQ1YV4wgs1JH/wZqn+rm40anJw1M6+npFTPzRkkBTGbK41T LFIrdWDDKzvbT3ariKp6Lz+6+yIFAZFLArl2msZJZuzOjyyURAW59fGc2+rqkM+16QCe kzug== MIME-Version: 1.0 X-Received: by 10.112.142.228 with SMTP id rz4mr6738360lbb.62.1370877763596; Mon, 10 Jun 2013 08:22:43 -0700 (PDT) Received: by 10.152.133.37 with HTTP; Mon, 10 Jun 2013 08:22:43 -0700 (PDT) In-Reply-To: <1370876192.70632.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B31034.2020903@globis.net> <51B4872B.8000505@si6networks.com> <51B4FD31.1000703@gmail.com> <51B56692.4030101@bogus.com> <1370873399.18459.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B5E3F7.1050105@bogus.com> <1370876192.70632.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Date: Mon, 10 Jun 2013 11:22:43 -0400 Message-ID: Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) From: Christopher Morrow To: Nalini Elkins Content-Type: text/plain; charset=ISO-8859-1 Cc: "vishwas.manral@hp.com" , 6man , Arturo Servin , Ray Hunter , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 15:22:52 -0000 On Mon, Jun 10, 2013 at 10:56 AM, Nalini Elkins wrote: > If there is consensus that EH's are valuable - then, maybe the way forward > should be to: > > 1. Decide how to get to the L4 header best. > > 2. Maybe a recommendation on how much of the header should be read into > ASIC. Is that out of scope? Some of the discussion already had talks about ordering and optimum method to find X in the header chain. What happens in these situations when someone sends 'lots' of packets with 'bad ordering' of the header bits? Will the devices in the path behave 'well'? or will I get degraded forwarding performance because of bad ordering? or will the packets be dropped? or ? it's worth thinking about what can go wrong with this requirement to order EH bits in certain ways. -chris From sthaug@nethelp.no Mon Jun 10 09:02:39 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C68021F992A for ; Mon, 10 Jun 2013 09:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mjoe7UB4u3S2 for ; Mon, 10 Jun 2013 09:02:34 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id A025F21F994F for ; Mon, 10 Jun 2013 09:02:32 -0700 (PDT) Received: (qmail 31462 invoked from network); 10 Jun 2013 16:02:30 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 10 Jun 2013 16:02:30 -0000 Date: Mon, 10 Jun 2013 18:02:30 +0200 (CEST) Message-Id: <20130610.180230.41714531.sthaug@nethelp.no> To: christopher.morrow@gmail.com Subject: Re: draft-ietf-6man-oversized-header-chain-02 From: sthaug@nethelp.no In-Reply-To: References: <51B56692.4030101@bogus.com> <1370873399.18459.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: vishwas.manral@hp.com, ipv6@ietf.org, arturo.servin@gmail.com, v6ops@globis.net, fgont@si6networks.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 16:02:39 -0000 > > 53 = not good. Just because some people are re-using old hardware cards > > they had hanging around does not mean everyone has to go along with it. > > define old. > define 'hanging around' > define the location from which capex can be drawn to replace 'old' and > 'hanging around' modules which are clearly perfectly functional in the > network today. This is precisely the problem. I don't think anybody is going to phase out functional equipment just because it can't peek all the way into a 64k byte header chain. I might be able to put some requirement on this ability into future RFQs if there is sensible guidance on what the limit should be. Note that I'm not going to be asking for 4k byte or 64k byte - neither of those constitute sensible guidance in my book. 128 or 256 bytes sound much more reasonable. It would be good to have a document which gives sensible guidance here, preferably based on input from actual hardware-based forwarding equipment manufacturers. Steinar Haug, AS 2116 From v6ops@globis.net Mon Jun 10 11:44:34 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC9021F8EC3 for ; Mon, 10 Jun 2013 11:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hYZ7lbxwK0v for ; Mon, 10 Jun 2013 11:44:33 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2864821F8EEA for ; Mon, 10 Jun 2013 11:44:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id BB4C6870089; Mon, 10 Jun 2013 20:44:16 +0200 (CEST) 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 1glre9i+IAZk; Mon, 10 Jun 2013 20:44:16 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 88C1D870002; Mon, 10 Jun 2013 20:44:16 +0200 (CEST) Message-ID: <51B61E7A.4020303@globis.net> Date: Mon, 10 Jun 2013 20:44:10 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Christopher Morrow Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B31034.2020903@globis.net> <51B4872B.8000505@si6networks.com> <51B4FD31.1000703@gmail.com> <51B56692.4030101@bogus.com> <1370873399.18459.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B5E3F7.1050105@bogus.com> <1370876192.70632.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "vishwas.manral@hp.com" , 6man , Arturo Servin , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 18:44:35 -0000 > Christopher Morrow > 10 June 2013 17:22 > On Mon, Jun 10, 2013 at 10:56 AM, Nalini Elkins > > Some of the discussion already had talks about ordering and optimum > method to find X in the header chain. What happens in these situations > when someone sends 'lots' of packets with 'bad ordering' of the header > bits? Will the devices in the path behave 'well'? or will I get > degraded forwarding performance because of bad ordering? or will the > packets be dropped? or ? > > it's worth thinking about what can go wrong with this requirement to > order EH bits in certain ways. > > -chris > I purposefully left that particular can unopened, because I consider it unlikely that we will obtain rough consensus on it. IMHO it's better to have an informational RFC that says "if you obey these simple formatting rules, your packet is likely to be transported (fast)" than nothing at all. I just searched draft-ietf-v6ops-6204bis-12 for requirements on extension headers. Nada AFAICS. I also just tested my own home CPE for outbound transmission of extension headers (with and without firewall configured): HBH EH: tick Destination Options EH: tick Fragment EH: looks like they're always dropped regards, RayH From christopher.morrow@gmail.com Mon Jun 10 12:00:08 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD67421F8B90 for ; Mon, 10 Jun 2013 12:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.349 X-Spam-Level: X-Spam-Status: No, score=-103.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M58LjPHZeYw6 for ; Mon, 10 Jun 2013 11:59:56 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id 818A021F86D5 for ; Mon, 10 Jun 2013 11:59:53 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id 13so3428183lba.16 for ; Mon, 10 Jun 2013 11:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xPzI3BOmYED44mTwwLlxYN/CBYfJY7rNFcIWSDBA3oI=; b=q9NV5NQBq/WYa3Uv/NIed1RjjPu2OYp2oRh+QmTUpUBWgkPq0tJGCzjF39m1IU8ml9 k89kyNzE1VF71jEOumtOU7zYR6IuI9delAX+kkZvn+XxVLpCtKpuJRlgAnEYLka+3f9w YtkIuqa/EVXeAZogzgeFqxj1wLClNT5J6AznO39W6TOtozRpnbpp9JEhnZJ2yp4Uo2FT 7ZTboA5y+7TdwPfEMFKSp1LO2fEMz0wJCAPiVwXNmqqNNwaGMwVPHxDS+WpW4Vj1DMWT ZhqamnFvjRzw5b+UeYXpifzWduLKH2Ixi2d9iQIKgMYnpheQdKqAoqy9leh1fYq2ZyQg IOEQ== MIME-Version: 1.0 X-Received: by 10.152.44.225 with SMTP id h1mr5523372lam.90.1370890792338; Mon, 10 Jun 2013 11:59:52 -0700 (PDT) Received: by 10.152.133.37 with HTTP; Mon, 10 Jun 2013 11:59:52 -0700 (PDT) In-Reply-To: <51B61E7A.4020303@globis.net> References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B31034.2020903@globis.net> <51B4872B.8000505@si6networks.com> <51B4FD31.1000703@gmail.com> <51B56692.4030101@bogus.com> <1370873399.18459.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B5E3F7.1050105@bogus.com> <1370876192.70632.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B61E7A.4020303@globis.net> Date: Mon, 10 Jun 2013 14:59:52 -0400 Message-ID: Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) From: Christopher Morrow To: Ray Hunter Content-Type: text/plain; charset=ISO-8859-1 Cc: "vishwas.manral@hp.com" , 6man , Arturo Servin , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 19:00:08 -0000 On Mon, Jun 10, 2013 at 2:44 PM, Ray Hunter wrote: >> Christopher Morrow >> 10 June 2013 17:22 >> On Mon, Jun 10, 2013 at 10:56 AM, Nalini Elkins >> >> Some of the discussion already had talks about ordering and optimum >> method to find X in the header chain. What happens in these situations >> when someone sends 'lots' of packets with 'bad ordering' of the header >> bits? Will the devices in the path behave 'well'? or will I get >> degraded forwarding performance because of bad ordering? or will the >> packets be dropped? or ? >> >> it's worth thinking about what can go wrong with this requirement to >> order EH bits in certain ways. >> >> -chris >> > I purposefully left that particular can unopened, because I consider it > unlikely that we will obtain rough consensus on it. :) > IMHO it's better to have an informational RFC that says "if you obey > these simple formatting rules, your packet is likely to be transported > (fast)" than nothing at all. right, but you're also asking HW manufacturers to optomize on a certain ordering (sort of), that's going to lead to: 1, 2, 3 ordering works great! but: 3,2,1 == slow-path :( or COULD lead to that. > I just searched draft-ietf-v6ops-6204bis-12 for requirements on > extension headers. Nada AFAICS. > > I also just tested my own home CPE for outbound transmission of > extension headers (with and without firewall configured): > HBH EH: tick > Destination Options EH: tick > Fragment EH: looks like they're always dropped neat... how about proto-59? (noext-headers)? :) From v6ops@globis.net Mon Jun 10 12:35:24 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5EB821F99F6 for ; Mon, 10 Jun 2013 12:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSL3WgXlUboh for ; Mon, 10 Jun 2013 12:35:24 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 299F221F99F4 for ; Mon, 10 Jun 2013 12:35:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 2806C8700EB; Mon, 10 Jun 2013 21:35:08 +0200 (CEST) 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 fsmPNkf4F2IB; Mon, 10 Jun 2013 21:35:08 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id B00CB8700EA; Mon, 10 Jun 2013 21:35:07 +0200 (CEST) Message-ID: <51B62A65.7020309@globis.net> Date: Mon, 10 Jun 2013 21:35:01 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Christopher Morrow Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B31034.2020903@globis.net> <51B4872B.8000505@si6networks.com> <51B4FD31.1000703@gmail.com> <51B56692.4030101@bogus.com> <1370873399.18459.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B5E3F7.1050105@bogus.com> <1370876192.70632.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B61E7A.4020303@globis.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "vishwas.manral@hp.com" , 6man , Arturo Servin , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 19:35:25 -0000 > Christopher Morrow > 10 June 2013 20:59 > On Mon, Jun 10, 2013 at 2:44 PM, Ray Hunter wrote: >>> Christopher Morrow >>> 10 June 2013 17:22 >>> On Mon, Jun 10, 2013 at 10:56 AM, Nalini Elkins >>> >>> Some of the discussion already had talks about ordering and optimum >>> method to find X in the header chain. What happens in these situations >>> when someone sends 'lots' of packets with 'bad ordering' of the header >>> bits? Will the devices in the path behave 'well'? or will I get >>> degraded forwarding performance because of bad ordering? or will the >>> packets be dropped? or ? >>> >>> it's worth thinking about what can go wrong with this requirement to >>> order EH bits in certain ways. >>> >>> -chris >>> >> I purposefully left that particular can unopened, because I consider it >> unlikely that we will obtain rough consensus on it. > > :) > >> IMHO it's better to have an informational RFC that says "if you obey >> these simple formatting rules, your packet is likely to be transported >> (fast)" than nothing at all. > > right, but you're also asking HW manufacturers to optomize on a > certain ordering (sort of), that's going to lead to: 1, 2, 3 ordering > works great! Yes. Better than today. > but: 3,2,1 == slow-path :( > > or COULD lead to that. Same as today. So they'll continue to make their own decision on whether to deploy slow path or drop. >> I just searched draft-ietf-v6ops-6204bis-12 for requirements on >> extension headers. Nada AFAICS. >> >> I also just tested my own home CPE for outbound transmission of >> extension headers (with and without firewall configured): >> HBH EH: tick >> Destination Options EH: tick >> Fragment EH: looks like they're always dropped > > neat... how about proto-59? (noext-headers)? :) Untested (no test source yet) regards, RayH From joelja@bogus.com Mon Jun 10 13:05:24 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED0A21E804E for ; Mon, 10 Jun 2013 13:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTViaMzpWPsz for ; Mon, 10 Jun 2013 13:05:23 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7A34C21F99C7 for ; Mon, 10 Jun 2013 13:05:23 -0700 (PDT) Received: from joels-MacBook-Air.local ([41.223.117.22]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r5AK4wLZ028211 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 10 Jun 2013 20:05:04 GMT (envelope-from joelja@bogus.com) Message-ID: <51B63163.3040103@bogus.com> Date: Mon, 10 Jun 2013 22:04:51 +0200 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0 MIME-Version: 1.0 To: Ray Hunter , Christopher Morrow Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B31034.2020903@globis.net> <51B4872B.8000505@si6networks.com> <51B4FD31.1000703@gmail.com> <51B56692.4030101@bogus.com> <1370873399.18459.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B5E3F7.1050105@bogus.com> <1370876192.70632.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B61E7A.4020303@globis.net> <51B62A65.7020309@globis.net> In-Reply-To: <51B62A65.7020309@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 10 Jun 2013 20:05:09 +0000 (UTC) Cc: "vishwas.manral@hp.com" , 6man , Arturo Servin , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 20:05:24 -0000 On 6/10/13 9:35 PM, Ray Hunter wrote: >> Christopher Morrow >> 10 June 2013 20:59 >> On Mon, Jun 10, 2013 at 2:44 PM, Ray Hunter wrote: >>>> Christopher Morrow >>>> 10 June 2013 17:22 >>>> On Mon, Jun 10, 2013 at 10:56 AM, Nalini Elkins >>>> >>>> Some of the discussion already had talks about ordering and optimum >>>> method to find X in the header chain. What happens in these situations >>>> when someone sends 'lots' of packets with 'bad ordering' of the header >>>> bits? Will the devices in the path behave 'well'? or will I get >>>> degraded forwarding performance because of bad ordering? or will the >>>> packets be dropped? or ? >>>> >>>> it's worth thinking about what can go wrong with this requirement to >>>> order EH bits in certain ways. >>>> >>>> -chris >>>> >>> I purposefully left that particular can unopened, because I consider it >>> unlikely that we will obtain rough consensus on it. >> :) >> >>> IMHO it's better to have an informational RFC that says "if you obey >>> these simple formatting rules, your packet is likely to be transported >>> (fast)" than nothing at all. >> right, but you're also asking HW manufacturers to optomize on a >> certain ordering (sort of), that's going to lead to: 1, 2, 3 ordering >> works great! > Yes. Better than today. > >> but: 3,2,1 == slow-path :( >> >> or COULD lead to that. > Same as today. So they'll continue to make their own decision on whether > to deploy slow path or drop. Understand that there is no slow path in high capacity devices. There is fast path or no path. If slow path exists it becomes a bottleneck or a dos target. > >>> I just searched draft-ietf-v6ops-6204bis-12 for requirements on >>> extension headers. Nada AFAICS. >>> >>> I also just tested my own home CPE for outbound transmission of >>> extension headers (with and without firewall configured): >>> HBH EH: tick >>> Destination Options EH: tick >>> Fragment EH: looks like they're always dropped >> neat... how about proto-59? (noext-headers)? :) > Untested (no test source yet) > > regards, > RayH > From brian.e.carpenter@gmail.com Mon Jun 10 13:12:08 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC28721F9956 for ; Mon, 10 Jun 2013 13:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20Cxmo+cDPLL for ; Mon, 10 Jun 2013 13:12:07 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4EB21F96E4 for ; Mon, 10 Jun 2013 13:12:07 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id 10so3964258ied.28 for ; Mon, 10 Jun 2013 13:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mjw0mZNuk2SzIv/8OAJj6Rg8JpKYCxareI6GjHvj6Mo=; b=iOX9p7FBqY5FGIuKLSu/O/JVVX3Lef44ySTkhIYBCdzguOV/KUiHtn3bXSGhOdirxZ ICX4GzHIAx1R97jn27jBbrCausoktJ52TRBZ4/ttgkX27+um1a3459TtamWbzharb+5s OnTSdo2NQqwQoDQUjXIZB+r0iFls9cwKcmWi3mX21Fo17aNJPBvBBJx7ukCpxYRj1CLL C9lt0cturFmcoYHZDZ8n39G5v/gRmhZQelSi7eiRNsPZDpKK9tkyLvb43snpRvqqBFt4 ZzpZzKFtEP3PzmIMwPvbXHrTwMcgWMtXZMmn0nTN0cqAIrzVmCBFJRDvsH/E+/Su2S7C eqCQ== X-Received: by 10.50.152.37 with SMTP id uv5mr3393035igb.13.1370895126624; Mon, 10 Jun 2013 13:12:06 -0700 (PDT) Received: from [192.168.1.2] (118-92-62-227.dsl.dyn.ihug.co.nz. [118.92.62.227]) by mx.google.com with ESMTPSA id z6sm9929552igw.8.2013.06.10.13.12.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Jun 2013 13:12:06 -0700 (PDT) Message-ID: <51B63314.9080502@gmail.com> Date: Tue, 11 Jun 2013 08:12:04 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Warren Kumari Subject: Re: [6MAN] draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B4865D.2000207@si6networks.com> <51B4B216.5050205@gmail.com> <51B55698.7050307@gmail.com> <510D1209-7F9E-42AA-B790-A418CBF2959D@kumari.net> In-Reply-To: <510D1209-7F9E-42AA-B790-A418CBF2959D@kumari.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 20:12:08 -0000 Why wouldn't we add a sentence in -oversized-header-chain following this: > 6. Updating RFC 2460 > > If an IPv6 packet is fragmented, the first fragment of that IPv6 > packet (i.e., the fragment having a Fragment Offset of 0) MUST > contain the entire IPv6 header chain. The entire IPv6 header including the header chain SHOULD NOT exceed 256 octets. (or whatever magic number we decide on). We might need some words to justify that, but they can be found in this thread. Regards Brian Carpenter On 11/06/2013 03:03, Warren Kumari wrote: > On Jun 10, 2013, at 12:31 AM, Brian E Carpenter wrote: > >> On 10/06/2013 04:49, Tom Taylor wrote: >>> On 09/06/2013 9:42 AM, Fernando Gont wrote: >> ... >>>> I guess having a L4-pointer would have helped quite a lot. >>>> >>>> Cheers, >>>> >>> Would it be practical to define a HBH option that has an L4 pointer and >>> assign a fixed order to it? >> http://tools.ietf.org/html/draft-zhang-6man-offset-option-01 >> >> It didn't fly in this WG at the time. > > The issue is that, in order to be able to see header X you need to push all the bits up to header X onto the forwarding engine. Having a header that says "The L4 header is at byte 142" simply pushes the L4 out by another 8 bytes, exacerbating the problem. > > This issue is: > 1: In order to make a decision on header X the forwarding / filtering engine needs to see header X > 2: This require pushing at least up to the forwarding engine in a "cell". > 3: Bandwidth into the forwarding engine is expensive / limited, and storage on the forwarding engine is expensive (this is not DRAM ;-)) > 4: As you don't know (until you've looked) how far into the packet header X is, you need to choose some number and ship that many bytes to the forwarding engine. > 5: Having a header that points at the L4 info doesn't help -- by the time you can see it you've already sucked the bits onto the engine. > 6: Having additional logic that "prescreens" the packets looking for a pointer header *could* possibly work, but that is much of the forwarding engine logic - see #3. > > Choosing the optimum cell size is the tricky bit. If you increase the cell size you vastly increase cost -- if your competitors don't do the same, you've priced yourself out of the market. > > We are planning on updating the long-headers draft / publishing another "implementers guide" draft that suggests 128 or 256 bytes (as a straw man). This will hopefully be something that major vendors will sign up for. > > W > > >> Brian >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > -- > It's a mistake trying to cheer up camels. You might as well drop meringues into a black hole. -- Terry Prachett > > > . > From sthaug@nethelp.no Mon Jun 10 13:42:20 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5108821F9926 for ; Mon, 10 Jun 2013 13:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWz-ahR+-yRy for ; Mon, 10 Jun 2013 13:42:15 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id A51CB21F96DF for ; Mon, 10 Jun 2013 13:42:14 -0700 (PDT) Received: (qmail 48590 invoked from network); 10 Jun 2013 20:42:12 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 10 Jun 2013 20:42:12 -0000 Date: Mon, 10 Jun 2013 22:42:12 +0200 (CEST) Message-Id: <20130610.224212.71163453.sthaug@nethelp.no> To: brian.e.carpenter@gmail.com Subject: Re: [6MAN] draft-ietf-6man-oversized-header-chain-02 From: sthaug@nethelp.no In-Reply-To: <51B63314.9080502@gmail.com> References: <51B55698.7050307@gmail.com> <510D1209-7F9E-42AA-B790-A418CBF2959D@kumari.net> <51B63314.9080502@gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 20:42:20 -0000 > Why wouldn't we add a sentence in -oversized-header-chain > following this: > > > 6. Updating RFC 2460 > > > > If an IPv6 packet is fragmented, the first fragment of that IPv6 > > packet (i.e., the fragment having a Fragment Offset of 0) MUST > > contain the entire IPv6 header chain. > > > The entire IPv6 header including the header chain SHOULD NOT exceed > 256 octets. > > (or whatever magic number we decide on). I like this addition very much. Do you think it is realistic to get input from hardware manufacturers on what the magic number should be? Steinar Haug, AS 2116 From v6ops@globis.net Mon Jun 10 13:48:07 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DED21F9A64 for ; Mon, 10 Jun 2013 13:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktdO5a0CePLp for ; Mon, 10 Jun 2013 13:48:07 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id B62FC21F9A3A for ; Mon, 10 Jun 2013 13:48:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id CA3FF8700EA; Mon, 10 Jun 2013 22:47:50 +0200 (CEST) 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 07zesIbmOEm9; Mon, 10 Jun 2013 22:47:50 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 9ED7C8700E7; Mon, 10 Jun 2013 22:47:50 +0200 (CEST) Message-ID: <51B63B70.5010901@globis.net> Date: Mon, 10 Jun 2013 22:47:44 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: joel jaeggli Subject: Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B31034.2020903@globis.net> <51B4872B.8000505@si6networks.com> <51B4FD31.1000703@gmail.com> <51B56692.4030101@bogus.com> <1370873399.18459.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B5E3F7.1050105@bogus.com> <1370876192.70632.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <51B61E7A.4020303@globis.net> <51B62A65.7020309@globis.net> <51B63163.3040103@bogus.com> In-Reply-To: <51B63163.3040103@bogus.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "vishwas.manral@hp.com" , 6man , Arturo Servin , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 20:48:07 -0000 > joel jaeggli > 10 June 2013 22:04 > On 6/10/13 9:35 PM, Ray Hunter wrote: >>> Christopher Morrow >>> 10 June 2013 20:59 >>> On Mon, Jun 10, 2013 at 2:44 PM, Ray Hunter wrote: >>>>> Christopher Morrow >>>>> 10 June 2013 17:22 >>>>> On Mon, Jun 10, 2013 at 10:56 AM, Nalini Elkins >>>>> >>>>> Some of the discussion already had talks about ordering and optimum >>>>> method to find X in the header chain. What happens in these >>>>> situations >>>>> when someone sends 'lots' of packets with 'bad ordering' of the >>>>> header >>>>> bits? Will the devices in the path behave 'well'? or will I get >>>>> degraded forwarding performance because of bad ordering? or will the >>>>> packets be dropped? or ? >>>>> >>>>> it's worth thinking about what can go wrong with this requirement to >>>>> order EH bits in certain ways. >>>>> >>>>> -chris >>>>> >>>> I purposefully left that particular can unopened, because I >>>> consider it >>>> unlikely that we will obtain rough consensus on it. >>> :) >>> >>>> IMHO it's better to have an informational RFC that says "if you obey >>>> these simple formatting rules, your packet is likely to be transported >>>> (fast)" than nothing at all. >>> right, but you're also asking HW manufacturers to optomize on a >>> certain ordering (sort of), that's going to lead to: 1, 2, 3 ordering >>> works great! >> Yes. Better than today. >> >>> but: 3,2,1 == slow-path :( >>> >>> or COULD lead to that. >> Same as today. So they'll continue to make their own decision on whether >> to deploy slow path or drop. > Understand that there is no slow path in high capacity devices. > > There is fast path or no path. > > If slow path exists it becomes a bottleneck or a dos target. > I understand exactly. Which is why I am studiously ignoring the issue. :) regards, RayH >> >>>> I just searched draft-ietf-v6ops-6204bis-12 for requirements on >>>> extension headers. Nada AFAICS. >>>> >>>> I also just tested my own home CPE for outbound transmission of >>>> extension headers (with and without firewall configured): >>>> HBH EH: tick >>>> Destination Options EH: tick >>>> Fragment EH: looks like they're always dropped >>> neat... how about proto-59? (noext-headers)? :) >> Untested (no test source yet) >> >> regards, >> RayH >> > > From warren@kumari.net Mon Jun 10 13:59:36 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33EEC21F9A30 for ; Mon, 10 Jun 2013 13:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.923 X-Spam-Level: X-Spam-Status: No, score=-101.923 tagged_above=-999 required=5 tests=[AWL=0.676, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOJuResmJMwP for ; Mon, 10 Jun 2013 13:59:31 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602B821F99E9 for ; Mon, 10 Jun 2013 13:59:31 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.108]) by vimes.kumari.net (Postfix) with ESMTPSA id 7E0EB1B40789; Mon, 10 Jun 2013 16:59:30 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [6MAN] draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) From: Warren Kumari In-Reply-To: <51B63314.9080502@gmail.com> Date: Mon, 10 Jun 2013 16:59:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <34A6E408-10F3-4824-96EF-4A85016DA590@kumari.net> References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B4865D.2000207@si6networks.com> <51B4B216.5050205@gmail.com> <51B55698.7050307@gmail.com> <510D1209-7F9E-42AA-B790-A418CBF2959D@kumari.net> <51B63314.9080502@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1503) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 20:59:36 -0000 On Jun 10, 2013, at 4:12 PM, Brian E Carpenter = wrote: > Why wouldn't we add a sentence in -oversized-header-chain > following this: >=20 >> 6. Updating RFC 2460 >>=20 >> If an IPv6 packet is fragmented, the first fragment of that IPv6 >> packet (i.e., the fragment having a Fragment Offset of 0) MUST >> contain the entire IPv6 header chain. >=20 >=20 > The entire IPv6 header including the header chain SHOULD NOT exceed > 256 octets. >=20 > (or whatever magic number we decide on). >=20 > We might need some words to justify that, but they can be found > in this thread. You mean like what I said in the below email:=20 >> We are planning on updating the long-headers draft / publishing = another "implementers guide" draft that suggests 128 or 256 bytes (as a = straw man). This will hopefully be something that major vendors will = sign up for. Fine idea! W >=20 > Regards > Brian Carpenter >=20 > On 11/06/2013 03:03, Warren Kumari wrote: >> On Jun 10, 2013, at 12:31 AM, Brian E Carpenter = wrote: >>=20 >>> On 10/06/2013 04:49, Tom Taylor wrote: >>>> On 09/06/2013 9:42 AM, Fernando Gont wrote: >>> ... >>>>> I guess having a L4-pointer would have helped quite a lot. >>>>>=20 >>>>> Cheers, >>>>>=20 >>>> Would it be practical to define a HBH option that has an L4 pointer = and >>>> assign a fixed order to it? >>> http://tools.ietf.org/html/draft-zhang-6man-offset-option-01 >>>=20 >>> It didn't fly in this WG at the time. >>=20 >> The issue is that, in order to be able to see header X you need to = push all the bits up to header X onto the forwarding engine. Having a = header that says "The L4 header is at byte 142" simply pushes the L4 out = by another 8 bytes, exacerbating the problem. >>=20 >> This issue is: >> 1: In order to make a decision on header X the forwarding / filtering = engine needs to see header X >> 2: This require pushing at least up to the forwarding engine in a "cell". >> 3: Bandwidth into the forwarding engine is expensive / limited, and = storage on the forwarding engine is expensive (this is not DRAM ;-)) >> 4: As you don't know (until you've looked) how far into the packet = header X is, you need to choose some number and ship that many bytes to = the forwarding engine. >> 5: Having a header that points at the L4 info doesn't help -- by the = time you can see it you've already sucked the bits onto the engine.=20 >> 6: Having additional logic that "prescreens" the packets looking for = a pointer header *could* possibly work, but that is much of the = forwarding engine logic - see #3. >>=20 >> Choosing the optimum cell size is the tricky bit. If you increase the = cell size you vastly increase cost -- if your competitors don't do the = same, you've priced yourself out of the market.=20 >>=20 >> We are planning on updating the long-headers draft / publishing = another "implementers guide" draft that suggests 128 or 256 bytes (as a = straw man). This will hopefully be something that major vendors will = sign up for. >>=20 >> W >>=20 >>=20 >>> Brian >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>>=20 >>=20 >> -- >> It's a mistake trying to cheer up camels. You might as well drop = meringues into a black hole. -- Terry Prachett >>=20 >>=20 >> . >>=20 >=20 -- It is impossible to sharpen a pencil with a blunt axe. It is equally = vain to try to do it with ten blunt axes instead. -- E.W Dijkstra, 1930-2002 From warren@kumari.net Mon Jun 10 15:10:10 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3A121E804B for ; Mon, 10 Jun 2013 15:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.292 X-Spam-Level: X-Spam-Status: No, score=-101.292 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GFeWfGATEue for ; Mon, 10 Jun 2013 15:10:03 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8115211E80AE for ; Mon, 10 Jun 2013 15:10:03 -0700 (PDT) Received: from [192.168.1.152] (unknown [66.84.81.108]) by vimes.kumari.net (Postfix) with ESMTPSA id 59BDD1B4057E; Mon, 10 Jun 2013 18:10:02 -0400 (EDT) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B4865D.2000207@si6networks.com> <51B4B216.5050205@gmail.com> <51B55698.7050307@gmail.com> <510D1209-7F9E-42AA-B790-A418CBF2959D@kumari.net> <51B63314.9080502@gmail.com> <34A6E408-10F3-4824-96EF-4A85016DA590@kumari.net> In-Reply-To: <34A6E408-10F3-4824-96EF-4A85016DA590@kumari.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <25948B98-5011-42AC-91F2-DA3B0C9BF11C@kumari.net> X-Mailer: iPhone Mail (10B350) From: Warren Kumari Subject: Re: [6MAN] draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) Date: Mon, 10 Jun 2013 18:10:02 -0400 To: Brian E Carpenter Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 22:10:11 -0000 Warren Kumari ------ Please excuse typing, etc -- This was sent from a device with a tiny keyboar= d. On Jun 10, 2013, at 4:59 PM, Warren Kumari wrote: >=20 > On Jun 10, 2013, at 4:12 PM, Brian E Carpenter wrote: >=20 >> Why wouldn't we add a sentence in -oversized-header-chain >> following this: >>=20 >>> 6. Updating RFC 2460 >>>=20 >>> If an IPv6 packet is fragmented, the first fragment of that IPv6 >>> packet (i.e., the fragment having a Fragment Offset of 0) MUST >>> contain the entire IPv6 header chain. >>=20 >>=20 >> The entire IPv6 header including the header chain SHOULD NOT exceed >> 256 octets. >>=20 >> (or whatever magic number we decide on). >>=20 >> We might need some words to justify that, but they can be found >> in this thread. >=20 > You mean like what I said in the below email:=20 >>> We are planning on updating the long-headers draft / publishing another "= implementers guide" draft that suggests 128 or 256 bytes (as a straw man). T= his will hopefully be something that major vendors will sign up for. >=20 >=20 > Fine idea! ... and we are still planning on doing this as well. Never hurts to have the= same things repeated.... W >=20 > W >=20 >>=20 >> Regards >> Brian Carpenter >>=20 >> On 11/06/2013 03:03, Warren Kumari wrote: >>> On Jun 10, 2013, at 12:31 AM, Brian E Carpenter wrote: >>>=20 >>>> On 10/06/2013 04:49, Tom Taylor wrote: >>>>> On 09/06/2013 9:42 AM, Fernando Gont wrote: >>>> ... >>>>>> I guess having a L4-pointer would have helped quite a lot. >>>>>>=20 >>>>>> Cheers, >>>>> Would it be practical to define a HBH option that has an L4 pointer an= d >>>>> assign a fixed order to it? >>>> http://tools.ietf.org/html/draft-zhang-6man-offset-option-01 >>>>=20 >>>> It didn't fly in this WG at the time. >>>=20 >>> The issue is that, in order to be able to see header X you need to push a= ll the bits up to header X onto the forwarding engine. Having a header that s= ays "The L4 header is at byte 142" simply pushes the L4 out by another 8 byt= es, exacerbating the problem. >>>=20 >>> This issue is: >>> 1: In order to make a decision on header X the forwarding / filtering en= gine needs to see header X >>> 2: This require pushing at least up to the forwarding engine in a "cell". >>> 3: Bandwidth into the forwarding engine is expensive / limited, and stor= age on the forwarding engine is expensive (this is not DRAM ;-)) >>> 4: As you don't know (until you've looked) how far into the packet heade= r X is, you need to choose some number and ship that many bytes to the forwa= rding engine. >>> 5: Having a header that points at the L4 info doesn't help -- by the tim= e you can see it you've already sucked the bits onto the engine.=20 >>> 6: Having additional logic that "prescreens" the packets looking for a p= ointer header *could* possibly work, but that is much of the forwarding engi= ne logic - see #3. >>>=20 >>> Choosing the optimum cell size is the tricky bit. If you increase the ce= ll size you vastly increase cost -- if your competitors don't do the same, y= ou've priced yourself out of the market.=20 >>>=20 >>> We are planning on updating the long-headers draft / publishing another "= implementers guide" draft that suggests 128 or 256 bytes (as a straw man). T= his will hopefully be something that major vendors will sign up for. >>>=20 >>> W >>>=20 >>>=20 >>>> Brian >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>>=20 >>> -- >>> It's a mistake trying to cheer up camels. You might as well drop meringu= es into a black hole. -- Terry Prachett >>>=20 >>>=20 >>> . >=20 > -- > It is impossible to sharpen a pencil with a blunt axe. It is equally vain= > to try to do it with ten blunt axes instead. > -- E.W Dijkstra, 1930-2002 >=20 >=20 >=20 From huitema@microsoft.com Mon Jun 10 17:36:22 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEDC21E8098 for ; Mon, 10 Jun 2013 17:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfJ5Neic+Sy6 for ; Mon, 10 Jun 2013 17:36:16 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id 09CBF21E809B for ; Mon, 10 Jun 2013 17:36:15 -0700 (PDT) Received: from BN1BFFO11FD022.protection.gbl (10.58.52.201) by BN1BFFO11HUB007.protection.gbl (10.58.53.117) with Microsoft SMTP Server (TLS) id 15.0.707.0; Tue, 11 Jun 2013 00:26:43 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD022.mail.protection.outlook.com (10.58.53.82) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Tue, 11 Jun 2013 00:26:43 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.47]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0136.001; Tue, 11 Jun 2013 00:26:10 +0000 From: Christian Huitema To: Warren Kumari , Brian E Carpenter Subject: RE: [6MAN] draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) Thread-Topic: [6MAN] draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) Thread-Index: AQHOZhbc49vAexarm0aC6FVQQqEiJJkvbp8AgAA39ZA= Date: Tue, 11 Jun 2013 00:26:10 +0000 Message-ID: References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B4865D.2000207@si6networks.com> <51B4B216.5050205@gmail.com> <51B55698.7050307@gmail.com> <510D1209-7F9E-42AA-B790-A418CBF2959D@kumari.net> <51B63314.9080502@gmail.com> <34A6E408-10F3-4824-96EF-4A85016DA590@kumari.net> In-Reply-To: <34A6E408-10F3-4824-96EF-4A85016DA590@kumari.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704005)(189002)(199002)(47976001)(76482001)(74876001)(23726002)(81342001)(74502001)(56776001)(76796001)(31966008)(54356001)(77982001)(76786001)(46406003)(47446002)(65816001)(51856001)(79102001)(74706001)(80022001)(46102001)(63696002)(33656001)(6806003)(74366001)(74662001)(81542001)(50466002)(4396001)(54316002)(66066001)(69226001)(49866001)(77096001)(56816003)(55846006)(47736001)(16406001)(59766001)(53806001)(50986001)(20776003)(47776003); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB007; H:TK5EX14MLTC104.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 087474FBFA Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 00:36:22 -0000 >> 6. Updating RFC 2460 >>=20 >> If an IPv6 packet is fragmented, the first fragment of that IPv6 >> packet (i.e., the fragment having a Fragment Offset of 0) MUST >> contain the entire IPv6 header chain. >=20 >=20 > The entire IPv6 header including the header chain SHOULD NOT exceed > 256 octets. If you think about it, the whole point of extension headers is to help "the= network." If it was merely end-to-end information, whatever hosts send in = the EH could just as well be encoded as options in the application layer. I= f it is really meant to be private, encrypt the whole thing, and show just = the ESP header. You really have to wonder why anyone would send complex cha= ins of extension headers that cannot be parsed by routers. -- Christian Huitema From fgont@si6networks.com Mon Jun 10 19:21:43 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFD721E80A1 for ; Mon, 10 Jun 2013 19:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHab+yGIBedc for ; Mon, 10 Jun 2013 19:21:38 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF7321E805A for ; Mon, 10 Jun 2013 19:21:37 -0700 (PDT) Received: from [186.134.37.222] (helo=[192.168.0.6]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmEDB-0006Af-NT; Tue, 11 Jun 2013 04:21:30 +0200 Message-ID: <51B684D6.8050503@si6networks.com> Date: Tue, 11 Jun 2013 04:00:54 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [6MAN] draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B4865D.2000207@si6networks.com> <51B4B216.5050205@gmail.com> <51B55698.7050307@gmail.com> <510D1209-7F9E-42AA-B790-A418CBF2959D@kumari.net> <51B63314.9080502@gmail.com> In-Reply-To: <51B63314.9080502@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 02:21:44 -0000 Hi, Brian, On 06/10/2013 10:12 PM, Brian E Carpenter wrote: > Why wouldn't we add a sentence in -oversized-header-chain > following this: > >> 6. Updating RFC 2460 >> >> If an IPv6 packet is fragmented, the first fragment of that IPv6 >> packet (i.e., the fragment having a Fragment Offset of 0) MUST >> contain the entire IPv6 header chain. > > > The entire IPv6 header including the header chain SHOULD NOT exceed > 256 octets. > > (or whatever magic number we decide on). I fully agree. -- For instance, at least the individual version of this I-D included wording along those lines (at the time, the I-D was required the entire header chain to be within the first 1280 bytes of a packet). > We might need some words to justify that, but they can be found > in this thread. How about something along the lines of: * A large number of deployed systems reportedly drop packets that do not contain the entire IPv6 header chain within the first XXX bytes. * Since extension headers represent overhead to transmission of IPv6 payloads, the IPv6 header chain is expected to be small fraction of a full-sized packet. With an IPv6 minimum MTU of 1280 bytes, a limit of XXX bytes for the entire header chain already allows for YYY % of overhead. (for the first bullet, we could add an informative reference to Warren et al's I-D). Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Mon Jun 10 19:21:55 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A61721E80A2; Mon, 10 Jun 2013 19:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YV6DPpvbHWum; Mon, 10 Jun 2013 19:21:54 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4AE21E805A; Mon, 10 Jun 2013 19:21:45 -0700 (PDT) Received: from [186.134.37.222] (helo=[192.168.0.6]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmEDP-0006An-Rt; Tue, 11 Jun 2013 04:21:44 +0200 Message-ID: <51B6876A.9020202@si6networks.com> Date: Tue, 11 Jun 2013 04:11:54 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "6man@ietf.org" <6man@ietf.org> Subject: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 02:21:55 -0000 Folks, We're currently editing the aforementioned I-D. So far, the I-D just required that the entire IPv6 header chain be present in the first fragment. Based on recent/ongoing discussions on the 6man and v6ops lists, there seems to be quite a few folks pushing the idea of limiting the size f the IPv6 header chain to some value (typically in the order of a few hundred bytes). An earlier version of draft-ietf-6man-oversized-header-chain limited the header chain to 1280 bytes, but this requirement was later removed. However, since then a number of folks have produced real world data which indicates that packets "won't make it to the destination node" if the header chain is larger than a few hundred bytes, and I believe that, overall, our understanding of the problem and situation has increased since then. My question to th wg is: 1) Do we want to limit the size of the IPv6 header chain? 2) If so, which limit should we pick? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From cb.list6@gmail.com Mon Jun 10 20:21:53 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CD321E80AA; Mon, 10 Jun 2013 20:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DS12SHYStC6Q; Mon, 10 Jun 2013 20:21:52 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D7E6721E804E; Mon, 10 Jun 2013 20:21:51 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hj3so1285574wib.10 for ; Mon, 10 Jun 2013 20:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eQM5XbXHLdIOu6p/EbHOUf0nOaLUtiyrHS6aRkrArHo=; b=Fan0UdZuYNnVq2a9HZfIFPTkG2R626BrsUvXcqjxEoxOqhq1iGUELOZNCS8PbY8Jx/ KYNUy8RbX/OrCVzNhlegeWRYssep5LBlKZt7I9qRtZabctjUQCAC2TIsKOFckH3SU9+w 7tZrmOb9Ga68zN+BDca+uVKXr149hm+D4KY+pCQiAQAn5pFU7FRIufdujYHHI7yoEnmp maOlpKWn5XoBeCFy1c64idT6c6KQAI9dua74izYlFyHZemxoyBbN2RvfaJrQRH77foAj oTgGonkllftaksLcZqjfqIddhX3ZqfLUGONO/u6ammO6fFpeQFz4T3bLjOAfL/EajcgH y2Gw== MIME-Version: 1.0 X-Received: by 10.194.172.66 with SMTP id ba2mr6977513wjc.22.1370920911033; Mon, 10 Jun 2013 20:21:51 -0700 (PDT) Received: by 10.194.56.231 with HTTP; Mon, 10 Jun 2013 20:21:50 -0700 (PDT) Received: by 10.194.56.231 with HTTP; Mon, 10 Jun 2013 20:21:50 -0700 (PDT) In-Reply-To: <51B6876A.9020202@si6networks.com> References: <51B6876A.9020202@si6networks.com> Date: Mon, 10 Jun 2013 20:21:50 -0700 Message-ID: Subject: Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) From: "cb.list6" To: Fernando Gont Content-Type: multipart/alternative; boundary=089e01184dd4eada1004ded86549 Cc: IPv6 Ops WG , 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 03:21:53 -0000 --089e01184dd4eada1004ded86549 Content-Type: text/plain; charset=ISO-8859-1 On Jun 10, 2013 7:23 PM, "Fernando Gont" wrote: > > Folks, > > We're currently editing the aforementioned I-D. So far, the I-D just > required that the entire IPv6 header chain be present in the first fragment. > > Based on recent/ongoing discussions on the 6man and v6ops lists, there > seems to be quite a few folks pushing the idea of limiting the size f > the IPv6 header chain to some value (typically in the order of a few > hundred bytes). > > An earlier version of draft-ietf-6man-oversized-header-chain limited the > header chain to 1280 bytes, but this requirement was later removed. > > However, since then a number of folks have produced real world data > which indicates that packets "won't make it to the destination node" if > the header chain is larger than a few hundred bytes, and I believe that, > overall, our understanding of the problem and situation has increased > since then. > > My question to th wg is: > > 1) Do we want to limit the size of the IPv6 header chain? > > 2) If so, which limit should we pick? > It's not the size, it is how you use it. I would suggest "common types" be permitted (tcp, udp, sctp, icmpv6, frag, esp, ah) while anything else must be behind an esp. This ensures all parties agree that further arbitrary headers will only be processed by the concenting end systems. CB > Thanks! > > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --089e01184dd4eada1004ded86549 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


    On Jun 10, 2013 7:23 PM, "Fernando Gont" <fgont@si6networks.com> wrote:
    >
    > Folks,
    >
    > We're currently editing the aforementioned I-D. So far, the I-D ju= st
    > required that the entire IPv6 header chain be present in the first fra= gment.
    >
    > Based on recent/ongoing discussions on the 6man and v6ops lists, there=
    > seems to be quite a few folks pushing the idea of limiting the size f<= br> > the IPv6 header chain to some value (typically in the order of a few > hundred bytes).
    >
    > An earlier version of draft-ietf-6man-oversized-header-chain limited t= he
    > header chain to 1280 bytes, but this requirement was later removed. >
    > However, since then a number of folks have produced real world data > which indicates that packets "won't make it to the destinatio= n node" if
    > the header chain is larger than a few hundred bytes, and I believe tha= t,
    > overall, our understanding of the problem and situation has increased<= br> > since then.
    >
    > My question to th wg is:
    >
    > 1) Do we want to limit the size of the IPv6 header chain?
    >
    > 2) If so, which limit should we pick?
    >

    It's not the size, it is how you use it.

    I would suggest "common types" be permitted (tcp, = udp, sctp, icmpv6, frag, esp, ah) while anything else must be behind an esp= . This ensures all parties agree that further arbitrary headers will only b= e processed by the concenting end systems.

    CB
    > Thanks!
    >
    > Best regards,
    > --
    > Fernando Gont
    > SI6 Networks
    > e-mail: fgont@si6networks.com=
    > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
    >
    >
    >
    >
    > -------------------------------------------------------------------- > IETF IPv6 working group mailing list
    > ipv6@ietf.org
    > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > --------------------------------------------------------------------

    --089e01184dd4eada1004ded86549-- From brian.e.carpenter@gmail.com Mon Jun 10 20:26:29 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29F911E80D7 for ; Mon, 10 Jun 2013 20:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBrlKsX-+TBV for ; Mon, 10 Jun 2013 20:26:28 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D598211E80CC for ; Mon, 10 Jun 2013 20:26:28 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id uo1so3218111pbc.31 for ; Mon, 10 Jun 2013 20:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=x7L24zYU+xtln5+zbJzEcsba5tCNopoeQ6f9Xo2RgcE=; b=WDcRcb+ZTlj32zRhzkPej7ykWwv/1Kh4qVYDO/qP/YLJtA/nXqfssg6umFizXDXCgY JAdI6pJhKiTBMyi1gOE1Vtse524wgewh43105d6gWsBe1bbRpyXaKRJ7KlPFNlaCXbjz L6suGzT58aotE2CQhS6IckCyVAjwoKCb2uN8i7O6o0FjQkPuxv1Sd/RDLZXiDi3swAFl jTScOskG7QhLedEICcDM/bg/SEcLASlPVPhlpWjYqR99zPr2lASDVCCfP/92/TTC36RC Vf65dBlDPq6ki+L18z2q6M3VwN8Nc7LksC4ZeCOChsHWe2ZNSPp5ZZptkbwaenTrfoJ/ kx9w== X-Received: by 10.68.213.162 with SMTP id nt2mr12332482pbc.179.1370921188318; Mon, 10 Jun 2013 20:26:28 -0700 (PDT) Received: from [192.168.1.2] (118-92-62-227.dsl.dyn.ihug.co.nz. [118.92.62.227]) by mx.google.com with ESMTPSA id qe10sm10259560pbb.2.2013.06.10.20.26.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Jun 2013 20:26:27 -0700 (PDT) Message-ID: <51B698E2.3030901@gmail.com> Date: Tue, 11 Jun 2013 15:26:26 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Warren Kumari Subject: Re: [6MAN] draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B4865D.2000207@si6networks.com> <51B4B216.5050205@gmail.com> <51B55698.7050307@gmail.com> <510D1209-7F9E-42AA-B790-A418CBF2959D@kumari.net> <51B63314.9080502@gmail.com> <34A6E408-10F3-4824-96EF-4A85016DA590@kumari.net> In-Reply-To: <34A6E408-10F3-4824-96EF-4A85016DA590@kumari.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 03:26:29 -0000 On 11/06/2013 08:59, Warren Kumari wrote: > On Jun 10, 2013, at 4:12 PM, Brian E Carpenter wrote: > >> Why wouldn't we add a sentence in -oversized-header-chain >> following this: >> >>> 6. Updating RFC 2460 >>> >>> If an IPv6 packet is fragmented, the first fragment of that IPv6 >>> packet (i.e., the fragment having a Fragment Offset of 0) MUST >>> contain the entire IPv6 header chain. >> >> The entire IPv6 header including the header chain SHOULD NOT exceed >> 256 octets. >> >> (or whatever magic number we decide on). >> >> We might need some words to justify that, but they can be found >> in this thread. > > You mean like what I said in the below email: Sure, except that this would add it to a standards track draft (fwiw). Brian >>> We are planning on updating the long-headers draft / publishing another "implementers guide" draft that suggests 128 or 256 bytes (as a straw man). This will hopefully be something that major vendors will sign up for. > > > Fine idea! > > W > >> Regards >> Brian Carpenter >> >> On 11/06/2013 03:03, Warren Kumari wrote: >>> On Jun 10, 2013, at 12:31 AM, Brian E Carpenter wrote: >>> >>>> On 10/06/2013 04:49, Tom Taylor wrote: >>>>> On 09/06/2013 9:42 AM, Fernando Gont wrote: >>>> ... >>>>>> I guess having a L4-pointer would have helped quite a lot. >>>>>> >>>>>> Cheers, >>>>>> >>>>> Would it be practical to define a HBH option that has an L4 pointer and >>>>> assign a fixed order to it? >>>> http://tools.ietf.org/html/draft-zhang-6man-offset-option-01 >>>> >>>> It didn't fly in this WG at the time. >>> The issue is that, in order to be able to see header X you need to push all the bits up to header X onto the forwarding engine. Having a header that says "The L4 header is at byte 142" simply pushes the L4 out by another 8 bytes, exacerbating the problem. >>> >>> This issue is: >>> 1: In order to make a decision on header X the forwarding / filtering engine needs to see header X >>> 2: This require pushing at least up to the forwarding engine in a "cell". >>> 3: Bandwidth into the forwarding engine is expensive / limited, and storage on the forwarding engine is expensive (this is not DRAM ;-)) >>> 4: As you don't know (until you've looked) how far into the packet header X is, you need to choose some number and ship that many bytes to the forwarding engine. >>> 5: Having a header that points at the L4 info doesn't help -- by the time you can see it you've already sucked the bits onto the engine. >>> 6: Having additional logic that "prescreens" the packets looking for a pointer header *could* possibly work, but that is much of the forwarding engine logic - see #3. >>> >>> Choosing the optimum cell size is the tricky bit. If you increase the cell size you vastly increase cost -- if your competitors don't do the same, you've priced yourself out of the market. >>> >>> We are planning on updating the long-headers draft / publishing another "implementers guide" draft that suggests 128 or 256 bytes (as a straw man). This will hopefully be something that major vendors will sign up for. >>> >>> W >>> >>> >>>> Brian >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>>> >>> -- >>> It's a mistake trying to cheer up camels. You might as well drop meringues into a black hole. -- Terry Prachett >>> >>> >>> . >>> > > -- > It is impossible to sharpen a pencil with a blunt axe. It is equally vain > to try to do it with ten blunt axes instead. > -- E.W Dijkstra, 1930-2002 > > > > From brian.e.carpenter@gmail.com Mon Jun 10 20:31:56 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937A611E80D7 for ; Mon, 10 Jun 2013 20:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtgbGxjtI8Lw for ; Mon, 10 Jun 2013 20:31:56 -0700 (PDT) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 29DD011E80CC for ; Mon, 10 Jun 2013 20:31:55 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id md12so6945771pbc.16 for ; Mon, 10 Jun 2013 20:31:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fCi34jnNLW8E2yEL4oGkQGXYHYF0Eoa/2DjLEKjuRF4=; b=RJzLINTnb6GF2pYqbEeO9BrThZ4DwcVWHQmNY0jViH+ekvrjqCuoX1e1y+j2JBP2tC BUmrU8iCipSF6KM+OcATdW7CAGJ8kamhYgAWv7DTWBQgOJuvj4tzOafmMBup7UvK7r3/ wv1es8D3ejUywUnlQv+pizhimVLKu6QsD7ntLYPKtdy/WcAV/qa7gfFpEpIWVq5HcmJm hWnAYv61KHUYmDFENJ6WuzaFYAnxAsAQL8HqHMvdZRBlxynBpJSw8tkMiIC9Q1lyN6Dw 57syRQjTHO6NiiR9GtoWYZkiLp7Uvui3rIEq/oKU7Wf9GsOCII6xIAUTatNmwAHNNGx4 O5zg== X-Received: by 10.68.129.10 with SMTP id ns10mr12744011pbb.13.1370921514621; Mon, 10 Jun 2013 20:31:54 -0700 (PDT) Received: from [192.168.1.2] (118-92-62-227.dsl.dyn.ihug.co.nz. [118.92.62.227]) by mx.google.com with ESMTPSA id p2sm17937449pag.22.2013.06.10.20.31.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Jun 2013 20:31:54 -0700 (PDT) Message-ID: <51B69A29.9080802@gmail.com> Date: Tue, 11 Jun 2013 15:31:53 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: sthaug@nethelp.no Subject: Re: [6MAN] draft-ietf-6man-oversized-header-chain-02 References: <51B55698.7050307@gmail.com> <510D1209-7F9E-42AA-B790-A418CBF2959D@kumari.net> <51B63314.9080502@gmail.com> <20130610.224212.71163453.sthaug@nethelp.no> In-Reply-To: <20130610.224212.71163453.sthaug@nethelp.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 03:31:56 -0000 On 11/06/2013 08:42, sthaug@nethelp.no wrote: >> Why wouldn't we add a sentence in -oversized-header-chain >> following this: >> >>> 6. Updating RFC 2460 >>> >>> If an IPv6 packet is fragmented, the first fragment of that IPv6 >>> packet (i.e., the fragment having a Fragment Offset of 0) MUST >>> contain the entire IPv6 header chain. >> >> The entire IPv6 header including the header chain SHOULD NOT exceed >> 256 octets. >> >> (or whatever magic number we decide on). > > I like this addition very much. > > Do you think it is realistic to get input from hardware manufacturers > on what the magic number should be? It seems that you'd get different answers according to the capability of each manufacturer's silicon. 256 would be a marker in the sand for future hardware, and it doesn't seem to be craziness. But maybe it's worth inventing a "worst reasonable case" packet with some rational combination of headers. Brian > > Steinar Haug, AS 2116 > From brian.e.carpenter@gmail.com Mon Jun 10 20:34:21 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E2111E80CC; Mon, 10 Jun 2013 20:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18LJagf7MbwP; Mon, 10 Jun 2013 20:34:21 -0700 (PDT) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6379B11E80E1; Mon, 10 Jun 2013 20:34:18 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id jt11so7916869pbb.22 for ; Mon, 10 Jun 2013 20:34:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8mK/BVNImZxMsESlsVGmAchtyjuBurB6v558WVZNpAg=; b=Ngh6yTjESHul58liRhpaU+UFXmU/47sEcC+GGcXpkqXcpDV+5UAt0U8SCxGfYQW72x pPeQt2qhjWr0MQG1lwLjPKCylxWxGuUsPF6Wjt8ZG57F5amTFyc2SGEdr/77eo740JXs E9eXfSW+I2J0iVB4342evKIqEUrKLDvEjcOWYBxLHisgPA6jXPYpeWs3pL9pohkAomLy cdc0TPA6j1XXd5y1Hl/+bcN9EPZf6rpcXthiZt58zZ26d4b0clxbUHqL2WaIXJOfTW/i bL72QfBnPBrhbE8N/05NIo7Uwviw1kJpROHbtNa2VeEtJQL48eR9fhAOOp0C5qrUZ70s 1hfA== X-Received: by 10.66.164.232 with SMTP id yt8mr16758062pab.21.1370921658164; Mon, 10 Jun 2013 20:34:18 -0700 (PDT) Received: from [192.168.1.2] (118-92-62-227.dsl.dyn.ihug.co.nz. [118.92.62.227]) by mx.google.com with ESMTPSA id fr1sm12699641pbb.26.2013.06.10.20.34.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Jun 2013 20:34:17 -0700 (PDT) Message-ID: <51B69AB8.3080502@gmail.com> Date: Tue, 11 Jun 2013 15:34:16 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "cb.list6" Subject: Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <51B6876A.9020202@si6networks.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , IPv6 Ops WG , 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 03:34:21 -0000 On 11/06/2013 15:21, cb.list6 wrote: > On Jun 10, 2013 7:23 PM, "Fernando Gont" wrote: >> Folks, >> >> We're currently editing the aforementioned I-D. So far, the I-D just >> required that the entire IPv6 header chain be present in the first > fragment. >> Based on recent/ongoing discussions on the 6man and v6ops lists, there >> seems to be quite a few folks pushing the idea of limiting the size f >> the IPv6 header chain to some value (typically in the order of a few >> hundred bytes). >> >> An earlier version of draft-ietf-6man-oversized-header-chain limited the >> header chain to 1280 bytes, but this requirement was later removed. >> >> However, since then a number of folks have produced real world data >> which indicates that packets "won't make it to the destination node" if >> the header chain is larger than a few hundred bytes, and I believe that, >> overall, our understanding of the problem and situation has increased >> since then. >> >> My question to th wg is: >> >> 1) Do we want to limit the size of the IPv6 header chain? >> >> 2) If so, which limit should we pick? >> > > It's not the size, it is how you use it. > > I would suggest "common types" be permitted (tcp, udp, sctp, icmpv6, frag, > esp, ah) while anything else must be behind an esp. This ensures all > parties agree that further arbitrary headers will only be processed by the > concenting end systems. Truly, you won't get consensus for that; it isn't realistic. I think we're already very near consensus on an unconstrained limit in the 128/256 area. Brian > > CB >> Thanks! >> >> Best regards, >> -- >> Fernando Gont >> SI6 Networks >> e-mail: fgont@si6networks.com >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >> >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From cb.list6@gmail.com Mon Jun 10 20:45:01 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FA311E80CC; Mon, 10 Jun 2013 20:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLMxNfwSNtGD; Mon, 10 Jun 2013 20:45:00 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 296AC11E80D5; Mon, 10 Jun 2013 20:44:59 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u53so5512366wes.9 for ; Mon, 10 Jun 2013 20:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SgiMeFolc5H0eg+uYuP/LHB/x4QSdM5zRlf5JIo2A7E=; b=DIGzlppO/Rnb2Pa2CLrNiICstVhg2zQgJKx13m5oKO0TZj5Z3NTU9BSZq/4fYa3vem cKCqawm3QK0ALn3H5p5oEoonHfz+btIe/9tPibtz61TtfnOVrpYO18rH29MXAVnxztKN Z4QUIZ15FzXlOJ4v6TBNjBfUCbmV8KEceyaz74uEGIAy2k2K23Dt0/6Nv+FAo89wp9/V r7afURkCnpTKJXlCgmqbwVjh52UHPNFxXDmgwc2C2a4bc/n0poi3JVBJxKQQgpSKvEQv FsCZPBHSkFN27r9h4EFz7CcLM8FL73nDUEokOjidzRQaVfGWpkXblFEPpVHW5R8jIPwb f2Dg== MIME-Version: 1.0 X-Received: by 10.180.11.166 with SMTP id r6mr191451wib.45.1370922299281; Mon, 10 Jun 2013 20:44:59 -0700 (PDT) Received: by 10.194.56.231 with HTTP; Mon, 10 Jun 2013 20:44:59 -0700 (PDT) Received: by 10.194.56.231 with HTTP; Mon, 10 Jun 2013 20:44:59 -0700 (PDT) In-Reply-To: <51B69AB8.3080502@gmail.com> References: <51B6876A.9020202@si6networks.com> <51B69AB8.3080502@gmail.com> Date: Mon, 10 Jun 2013 20:44:59 -0700 Message-ID: Subject: Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) From: "cb.list6" To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a11c248f0a9d73004ded8b8bf Cc: Fernando Gont , IPv6 Ops WG , 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 03:45:01 -0000 --001a11c248f0a9d73004ded8b8bf Content-Type: text/plain; charset=ISO-8859-1 On Jun 10, 2013 8:34 PM, "Brian E Carpenter" wrote: > > On 11/06/2013 15:21, cb.list6 wrote: > > On Jun 10, 2013 7:23 PM, "Fernando Gont" wrote: > >> Folks, > >> > >> We're currently editing the aforementioned I-D. So far, the I-D just > >> required that the entire IPv6 header chain be present in the first > > fragment. > >> Based on recent/ongoing discussions on the 6man and v6ops lists, there > >> seems to be quite a few folks pushing the idea of limiting the size f > >> the IPv6 header chain to some value (typically in the order of a few > >> hundred bytes). > >> > >> An earlier version of draft-ietf-6man-oversized-header-chain limited the > >> header chain to 1280 bytes, but this requirement was later removed. > >> > >> However, since then a number of folks have produced real world data > >> which indicates that packets "won't make it to the destination node" if > >> the header chain is larger than a few hundred bytes, and I believe that, > >> overall, our understanding of the problem and situation has increased > >> since then. > >> > >> My question to th wg is: > >> > >> 1) Do we want to limit the size of the IPv6 header chain? > >> > >> 2) If so, which limit should we pick? > >> > > > > It's not the size, it is how you use it. > > > > I would suggest "common types" be permitted (tcp, udp, sctp, icmpv6, frag, > > esp, ah) while anything else must be behind an esp. This ensures all > > parties agree that further arbitrary headers will only be processed by the > > concenting end systems. > > Truly, you won't get consensus for that; it isn't realistic. I think we're > already very near consensus on an unconstrained limit in the 128/256 > area. > > Brian > Concenus from who? Ghosts of protocols past? Or what one fellow calls the "ipv6 priesthood" Is this yet another RA vs DHCPv6 disconnect? But what does 128/256 mean to a network operator? Load balancer or fw or router vendor? I believe meaningful guidance must be provided in terms of permutations that can be expressed in what the common folk call an "access list". Simply saying that there can be arbitrary chaining of x bytes long does not benefit anyone in a practical way, afaik. CB > > > > CB > >> Thanks! > >> > >> Best regards, > >> -- > >> Fernando Gont > >> SI6 Networks > >> e-mail: fgont@si6networks.com > >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > >> > >> > >> > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > > > > > ------------------------------------------------------------------------ > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- --001a11c248f0a9d73004ded8b8bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


    On Jun 10, 2013 8:34 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote: >
    > On 11/06/2013 15:21, cb.list6 wrote:
    > > On Jun 10, 2013 7:23 PM, "Fernando Gont" <fgont@si6networks.com> wrote:
    > >> Folks,
    > >>
    > >> We're currently editing the aforementioned I-D. So far, t= he I-D just
    > >> required that the entire IPv6 header chain be present in the = first
    > > fragment.
    > >> Based on recent/ongoing discussions on the 6man and v6ops lis= ts, there
    > >> seems to be quite a few folks pushing the idea of limiting th= e size f
    > >> the IPv6 header chain to some value (typically in the order o= f a few
    > >> hundred bytes).
    > >>
    > >> An earlier version of draft-ietf-6man-oversized-header-chain = limited the
    > >> header chain to 1280 bytes, but this requirement was later re= moved.
    > >>
    > >> However, since then a number of folks have produced real worl= d data
    > >> which indicates that packets "won't make it to the d= estination node" if
    > >> the header chain is larger than a few hundred bytes, and I be= lieve that,
    > >> overall, our understanding of the problem and situation has i= ncreased
    > >> since then.
    > >>
    > >> My question to th wg is:
    > >>
    > >> 1) Do we want to limit the size of the IPv6 header chain?
    > >>
    > >> 2) If so, which limit should we pick?
    > >>
    > >
    > > It's not the size, it is how you use it.
    > >
    > > I would suggest "common types" be permitted (tcp, udp, = sctp, icmpv6, frag,
    > > esp, ah) while anything else must be behind an esp. This ensures = all
    > > parties agree that further arbitrary headers will only be process= ed by the
    > > concenting end systems.
    >
    > Truly, you won't get consensus for that; it isn't realistic. I= think we're
    > already very near consensus on an unconstrained limit in the 128/256 > area.
    >
    > =A0 =A0 Brian
    >

    Concenus from who? Ghosts of protocols past? Or what one fel= low calls the "ipv6 priesthood" Is this yet another RA vs DHCPv6 = disconnect?

    But what does 128/256 mean to a network operator? Load balan= cer or fw or router vendor?

    I believe meaningful guidance must be provided in terms of p= ermutations that can be expressed in what the common folk call an "acc= ess list".

    Simply saying that there can be arbitrary chaining of x byte= s long does not benefit anyone in a practical way, afaik.

    CB

    > >
    > > CB
    > >> Thanks!
    > >>
    > >> Best regards,
    > >> --
    > >> Fernando Gont
    > >> SI6 Networks
    > >> e-mail: fgont@si6net= works.com
    > >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E= 7492
    > >>
    > >>
    > >>
    > >>
    > >> -------------------------------------------------------------= -------
    > >> IETF IPv6 working group mailing list
    > >> ipv6@ietf.org
    > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > >> -------------------------------------------------------------= -------
    > >
    > >
    > > -----------------------------------------------------------------= -------
    > >
    > > -----------------------------------------------------------------= ---
    > > IETF IPv6 working group mailing list
    > > ipv6@ietf.org
    > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > > -----------------------------------------------------------------= ---

    --001a11c248f0a9d73004ded8b8bf-- From brian.e.carpenter@gmail.com Mon Jun 10 20:56:18 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C31E11E80DE; Mon, 10 Jun 2013 20:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.232 X-Spam-Level: X-Spam-Status: No, score=-102.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZJomg17poCz; Mon, 10 Jun 2013 20:56:17 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id C926221F9633; Mon, 10 Jun 2013 20:56:17 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id bj3so3896882pad.14 for ; Mon, 10 Jun 2013 20:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Z2ZK6SQ1/wC0Hy2lhjQ1RqE6XtSaE0+nmMyDnZ+KWao=; b=ZuTNTuYH9AANl3jo1C4Mc2fqX8W5WaW5Nx94oYma/2KQzoD8pNCL43mBhdAcm2MTpE 2f6jWzYCCe7c88VHd2OQ1oWz8qfinXdAMfIl1GqHCy/op33zJuVEKfnAFxFoVhUcEeZf 45YTmKoUZ/JNSlfngQZFvTuwVILIxk5S0Rhdy1zhc4Oe9gl5VRDXUqF3bQKRHmMMxO/k W54/IpiXJcE2XPuORswIDMRdl+6HYofH/8hvdYLZsvj8K1PWkjKorrlCFwTiYuiEBeHj 5DXAv87oLf1wDwSgI6jWJynsmfwkyq+KC9nygcVabCaPm4C5kJrpUKvVij4qAWwZDZWZ 9p1w== X-Received: by 10.68.191.167 with SMTP id gz7mr12994844pbc.16.1370922977541; Mon, 10 Jun 2013 20:56:17 -0700 (PDT) Received: from [192.168.1.2] (30.211.252.27.dyn.cust.vf.net.nz. [27.252.211.30]) by mx.google.com with ESMTPSA id fr1sm12780002pbb.26.2013.06.10.20.56.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Jun 2013 20:56:16 -0700 (PDT) Message-ID: <51B69FDB.1090809@gmail.com> Date: Tue, 11 Jun 2013 15:56:11 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "cb.list6" Subject: Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <51B6876A.9020202@si6networks.com> <51B69AB8.3080502@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , IPv6 Ops WG , 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 03:56:18 -0000 On 11/06/2013 15:44, cb.list6 wrote: > On Jun 10, 2013 8:34 PM, "Brian E Carpenter" > wrote: >> On 11/06/2013 15:21, cb.list6 wrote: >>> On Jun 10, 2013 7:23 PM, "Fernando Gont" wrote: >>>> Folks, >>>> >>>> We're currently editing the aforementioned I-D. So far, the I-D just >>>> required that the entire IPv6 header chain be present in the first >>> fragment. >>>> Based on recent/ongoing discussions on the 6man and v6ops lists, there >>>> seems to be quite a few folks pushing the idea of limiting the size f >>>> the IPv6 header chain to some value (typically in the order of a few >>>> hundred bytes). >>>> >>>> An earlier version of draft-ietf-6man-oversized-header-chain limited > the >>>> header chain to 1280 bytes, but this requirement was later removed. >>>> >>>> However, since then a number of folks have produced real world data >>>> which indicates that packets "won't make it to the destination node" if >>>> the header chain is larger than a few hundred bytes, and I believe > that, >>>> overall, our understanding of the problem and situation has increased >>>> since then. >>>> >>>> My question to th wg is: >>>> >>>> 1) Do we want to limit the size of the IPv6 header chain? >>>> >>>> 2) If so, which limit should we pick? >>>> >>> It's not the size, it is how you use it. >>> >>> I would suggest "common types" be permitted (tcp, udp, sctp, icmpv6, > frag, >>> esp, ah) while anything else must be behind an esp. This ensures all >>> parties agree that further arbitrary headers will only be processed by > the >>> concenting end systems. >> Truly, you won't get consensus for that; it isn't realistic. I think we're >> already very near consensus on an unconstrained limit in the 128/256 >> area. >> >> Brian >> > > Concenus from who? Ghosts of protocols past? Or what one fellow calls the > "ipv6 priesthood" Is this yet another RA vs DHCPv6 disconnect? No, from the discussion on these two lists in the last week or so. > > But what does 128/256 mean to a network operator? Load balancer or fw or > router vendor? It means the size that leading-edge hw can inspect at line speed, from what a number of operators have been saying. > > I believe meaningful guidance must be provided in terms of permutations > that can be expressed in what the common folk call an "access list". That's a second level issue and it isn't future-proof. It may well be useful to document reasonable and unreasonable combinations of extension headers, in terms of expectations of what firewalls might be looking for, but there's no one-size-fits-all answer, especially when you include extensions that haven't been invented yet. > > Simply saying that there can be arbitrary chaining of x bytes long does not > benefit anyone in a practical way, afaik. IMHO it does; for a start it makes it clear that (say) 257 bytes of headers have a vanishingly small chance of getting through the network, and that's much more guidance than we give today. And it gives hardware designers a target that seems to relate to reality. Brian > > CB > >>> CB >>>> Thanks! >>>> >>>> Best regards, >>>> -- >>>> Fernando Gont >>>> SI6 Networks >>>> e-mail: fgont@si6networks.com >>>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >>>> >>>> >>>> >>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> >>> ------------------------------------------------------------------------ >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- > From cb.list6@gmail.com Mon Jun 10 21:23:24 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4FF21E80BB; Mon, 10 Jun 2013 21:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NLiTEhNF8jO; Mon, 10 Jun 2013 21:23:23 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 93EF021E80BC; Mon, 10 Jun 2013 21:23:22 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so4457065wgh.35 for ; Mon, 10 Jun 2013 21:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0zn2NJJJz7wdOqhR3Q+GYY2kc5s8Dz8lAxKtVKad4I0=; b=xKOIhjwb03yp6Q6webL97CsV0tDELR+BfLNr7wTleJNwOmUGBm0G52hBoFzrJAvGnt WSJjoe76KrYod0H9bII9LBlIveiy9RhU44EjSvStHuIwrCgvdcipE7uXHcJ/DKaBvVbI E57bg5bGVuNpCHD3j++JdqAunEWR3R0TfIfG9NbU/B/eOmL4T5b7sHuQ33ZRNEBC9c9y nHcqa2gIj52fVlC+/pgtyUffxAicrsuUKKqa3QIy3YUdiaM/gbpNwSXlr7KcyLWbzGD9 +zLMwFGbJ2t3LxBe/FubxP8VOx/CMm1MLKV6PoBR/Wv2Msq2T+1Tp55Y7KxURDAd5GKK VfWQ== MIME-Version: 1.0 X-Received: by 10.180.36.205 with SMTP id s13mr61876wij.31.1370924601684; Mon, 10 Jun 2013 21:23:21 -0700 (PDT) Received: by 10.194.56.231 with HTTP; Mon, 10 Jun 2013 21:23:21 -0700 (PDT) Received: by 10.194.56.231 with HTTP; Mon, 10 Jun 2013 21:23:21 -0700 (PDT) In-Reply-To: <51B69FDB.1090809@gmail.com> References: <51B6876A.9020202@si6networks.com> <51B69AB8.3080502@gmail.com> <51B69FDB.1090809@gmail.com> Date: Mon, 10 Jun 2013 21:23:21 -0700 Message-ID: Subject: Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) From: "cb.list6" To: Brian E Carpenter Content-Type: multipart/alternative; boundary=e89a8f642b58e5b7da04ded941e3 Cc: Fernando Gont , IPv6 Ops WG , 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 04:23:24 -0000 --e89a8f642b58e5b7da04ded941e3 Content-Type: text/plain; charset=ISO-8859-1 On Jun 10, 2013 8:56 PM, "Brian E Carpenter" wrote: > > On 11/06/2013 15:44, cb.list6 wrote: > > On Jun 10, 2013 8:34 PM, "Brian E Carpenter" < brian.e.carpenter@gmail.com> > > wrote: > >> On 11/06/2013 15:21, cb.list6 wrote: > >>> On Jun 10, 2013 7:23 PM, "Fernando Gont" wrote: > >>>> Folks, > >>>> > >>>> We're currently editing the aforementioned I-D. So far, the I-D just > >>>> required that the entire IPv6 header chain be present in the first > >>> fragment. > >>>> Based on recent/ongoing discussions on the 6man and v6ops lists, there > >>>> seems to be quite a few folks pushing the idea of limiting the size f > >>>> the IPv6 header chain to some value (typically in the order of a few > >>>> hundred bytes). > >>>> > >>>> An earlier version of draft-ietf-6man-oversized-header-chain limited > > the > >>>> header chain to 1280 bytes, but this requirement was later removed. > >>>> > >>>> However, since then a number of folks have produced real world data > >>>> which indicates that packets "won't make it to the destination node" if > >>>> the header chain is larger than a few hundred bytes, and I believe > > that, > >>>> overall, our understanding of the problem and situation has increased > >>>> since then. > >>>> > >>>> My question to th wg is: > >>>> > >>>> 1) Do we want to limit the size of the IPv6 header chain? > >>>> > >>>> 2) If so, which limit should we pick? > >>>> > >>> It's not the size, it is how you use it. > >>> > >>> I would suggest "common types" be permitted (tcp, udp, sctp, icmpv6, > > frag, > >>> esp, ah) while anything else must be behind an esp. This ensures all > >>> parties agree that further arbitrary headers will only be processed by > > the > >>> concenting end systems. > >> Truly, you won't get consensus for that; it isn't realistic. I think we're > >> already very near consensus on an unconstrained limit in the 128/256 > >> area. > >> > >> Brian > >> > > > > Concenus from who? Ghosts of protocols past? Or what one fellow calls the > > "ipv6 priesthood" Is this yet another RA vs DHCPv6 disconnect? > > No, from the discussion on these two lists in the last > week or so. > > > > But what does 128/256 mean to a network operator? Load balancer or fw or > > router vendor? > > It means the size that leading-edge hw can inspect at line speed, > from what a number of operators have been saying. > > > > > I believe meaningful guidance must be provided in terms of permutations > > that can be expressed in what the common folk call an "access list". > > That's a second level issue and it isn't future-proof. It may well be > useful to document reasonable and unreasonable combinations of > extension headers, in terms of expectations of what firewalls might > be looking for, but there's no one-size-fits-all answer, especially > when you include extensions that haven't been invented yet. > > > > > Simply saying that there can be arbitrary chaining of x bytes long does not > > benefit anyone in a practical way, afaik. > > IMHO it does; for a start it makes it clear that (say) 257 bytes of > headers have a vanishingly small chance of getting through the > network, and that's much more guidance than we give today. And it > gives hardware designers a target that seems to relate to reality. > > Brian I believe Warren's data hints at the idea that the packets will vanish if they don't fit a very specific profile. CB > > > > CB > > > >>> CB > >>>> Thanks! > >>>> > >>>> Best regards, > >>>> -- > >>>> Fernando Gont > >>>> SI6 Networks > >>>> e-mail: fgont@si6networks.com > >>>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > >>>> > >>>> > >>>> > >>>> > >>>> -------------------------------------------------------------------- > >>>> IETF IPv6 working group mailing list > >>>> ipv6@ietf.org > >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>> -------------------------------------------------------------------- > >>> > >>> ------------------------------------------------------------------------ > >>> > >>> -------------------------------------------------------------------- > >>> IETF IPv6 working group mailing list > >>> ipv6@ietf.org > >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>> -------------------------------------------------------------------- > > --e89a8f642b58e5b7da04ded941e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


    On Jun 10, 2013 8:56 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote: >
    > On 11/06/2013 15:44, cb.list6 wrote:
    > > On Jun 10, 2013 8:34 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com>= ;
    > > wrote:
    > >> On 11/06/2013 15:21, cb.list6 wrote:
    > >>> On Jun 10, 2013 7:23 PM, "Fernando Gont" <fgont@si6networks.com> wrote:=
    > >>>> Folks,
    > >>>>
    > >>>> We're currently editing the aforementioned I-D. S= o far, the I-D just
    > >>>> required that the entire IPv6 header chain be present= in the first
    > >>> fragment.
    > >>>> Based on recent/ongoing discussions on the 6man and v= 6ops lists, there
    > >>>> seems to be quite a few folks pushing the idea of lim= iting the size f
    > >>>> the IPv6 header chain to some value (typically in the= order of a few
    > >>>> hundred bytes).
    > >>>>
    > >>>> An earlier version of draft-ietf-6man-oversized-heade= r-chain limited
    > > the
    > >>>> header chain to 1280 bytes, but this requirement was = later removed.
    > >>>>
    > >>>> However, since then a number of folks have produced r= eal world data
    > >>>> which indicates that packets "won't make it = to the destination node" if
    > >>>> the header chain is larger than a few hundred bytes, = and I believe
    > > that,
    > >>>> overall, our understanding of the problem and situati= on has increased
    > >>>> since then.
    > >>>>
    > >>>> My question to th wg is:
    > >>>>
    > >>>> 1) Do we want to limit the size of the IPv6 header ch= ain?
    > >>>>
    > >>>> 2) If so, which limit should we pick?
    > >>>>
    > >>> It's not the size, it is how you use it.
    > >>>
    > >>> I would suggest "common types" be permitted (tc= p, udp, sctp, icmpv6,
    > > frag,
    > >>> esp, ah) while anything else must be behind an esp. This = ensures all
    > >>> parties agree that further arbitrary headers will only be= processed by
    > > the
    > >>> concenting end systems.
    > >> Truly, you won't get consensus for that; it isn't rea= listic. I think we're
    > >> already very near consensus on an unconstrained limit in the = 128/256
    > >> area.
    > >>
    > >> =A0 =A0 Brian
    > >>
    > >
    > > Concenus from who? Ghosts of protocols past? Or what one fellow c= alls the
    > > "ipv6 priesthood" Is this yet another RA vs DHCPv6 disc= onnect?
    >
    > No, from the discussion on these two lists in the last
    > week or so.
    > >
    > > But what does 128/256 mean to a network operator? Load balancer o= r fw or
    > > router vendor?
    >
    > It means the size that leading-edge hw can inspect at line speed,
    > from what a number of operators have been saying.
    >
    > >
    > > I believe meaningful guidance must be provided in terms of permut= ations
    > > that can be expressed in what the common folk call an "acces= s list".
    >
    > That's a second level issue and it isn't future-proof. It may = well be
    > useful to document reasonable and unreasonable combinations of
    > extension headers, in terms of expectations of what firewalls might > be looking for, but there's no one-size-fits-all answer, especiall= y
    > when you include extensions that haven't been invented yet.
    >
    > >
    > > Simply saying that there can be arbitrary chaining of x bytes lon= g does not
    > > benefit anyone in a practical way, afaik.
    >
    > IMHO it does; for a start it makes it clear that (say) 257 bytes of > headers have a vanishingly small chance of getting through the
    > network, and that's much more guidance than we give today. And it<= br> > gives hardware designers a target that seems to relate to reality.
    >
    > =A0 =A0 Brian

    I believe Warren's data hints at the idea that the packe= ts will vanish if they don't fit a very specific profile.=A0

    CB

    > >
    > > CB
    > >
    > >>> CB
    > >>>> Thanks!
    > >>>>
    > >>>> Best regards,
    > >>>> --
    > >>>> Fernando Gont
    > >>>> SI6 Networks
    > >>>> e-mail: fgon= t@si6networks.com
    > >>>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0= D55 1D4E 7492
    > >>>>
    > >>>>
    > >>>>
    > >>>>
    > >>>> -----------------------------------------------------= ---------------
    > >>>> IETF IPv6 working group mailing list
    > >>>> ipv6@ietf.org > >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>> -----------------------------------------------------= ---------------
    > >>>
    > >>> ---------------------------------------------------------= ---------------
    > >>>
    > >>> ---------------------------------------------------------= -----------
    > >>> IETF IPv6 working group mailing list
    > >>> ipv6@ietf.org
    > >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > >>> ---------------------------------------------------------= -----------
    > >

    --e89a8f642b58e5b7da04ded941e3-- From otroan@employees.org Tue Jun 11 02:01:38 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F0C21F8F5C for ; Tue, 11 Jun 2013 02:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPgODgae+9ZC for ; Tue, 11 Jun 2013 02:01:32 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id DB59F21F8F3E for ; Tue, 11 Jun 2013 02:01:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFALDmtlGQ/khM/2dsb2JhbABZgwm/QnsWdIIjAQEEATo/EAtGVwaIGga5do4AgQQzB4J/YQOpAoFYgTk6gS0 X-IronPort-AV: E=Sophos;i="4.87,844,1363132800"; d="scan'208";a="155203990" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 11 Jun 2013 09:01:27 +0000 Received: from dhcp-lys02-vla252-10-147-116-93.cisco.com (dhcp-lys02-vla252-10-147-116-93.cisco.com [10.147.116.93]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5B91OxH024939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Jun 2013 09:01:25 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [6MAN] draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) From: Ole Troan In-Reply-To: Date: Tue, 11 Jun 2013 11:01:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B4865D.2000207@si6networks.com> <51B4B216.5050205@gmail.com> <51B55698.7050307@gmail.com> <510D1209-7F9E-42AA-B790-A418CBF2959D@kumari.net> <51B63314.9080502@gmail.com> <34A6E408-10F3-4824-96EF-4A85016DA590@kumari.net> To: Christian Huitema X-Mailer: Apple Mail (2.1508) Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 09:01:38 -0000 >> The entire IPv6 header including the header chain SHOULD NOT exceed >> 256 octets. >=20 > If you think about it, the whole point of extension headers is to help = "the network." If it was merely end-to-end information, whatever hosts = send in the EH could just as well be encoded as options in the = application layer. If it is really meant to be private, encrypt the = whole thing, and show just the ESP header. You really have to wonder why = anyone would send complex chains of extension headers that cannot be = parsed by routers. historical revisionism? ;-) I thought the invention of extension headers was there to strongly = compel routers not to parse into the packet. a router does ECMP on the 5-tuple. the extension header chain doesn't = help with that. a middlebox makes some policy decision on arbitrary bits in the packet = (including L7). I'm not sure I see what help the middlebox gets from the extension header chain here? in my view there is no difference between the following cases: - 2nd fragment - extension header chain longer than first packet - unknown extension header - unknown L4 - ESP a firewall/filtering router with the policy of only allowing packets = with known L4, will drop the packet in all the above cases. only fixing the extension header issue doesn't solve the "problem" (in = quotation marks since I'm not sure we all agree there is one). what should we as the IETF do? we could accommodate our protocols to become more firewall friendly, e.g. deprecate IP layer fragmentation, deprecate extension headers (or = limit their length). but, do we then also push the Internet further away from an open end to = end capable Internet, stifle innovation in transport etc? cheers, Ole= From jared@puck.nether.net Tue Jun 11 02:50:56 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8EB21F962B; Tue, 11 Jun 2013 02:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZpcaN9llqtb; Tue, 11 Jun 2013 02:50:55 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7E42921F962A; Tue, 11 Jun 2013 02:50:55 -0700 (PDT) Received: from [10.0.0.129] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.7/8.14.5) with ESMTP id r5B9olJV001342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Jun 2013 05:50:47 -0400 Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=windows-1252 From: Jared Mauch In-Reply-To: Date: Tue, 11 Jun 2013 05:50:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9636419F-A126-4775-A6C9-3864F8C22323@puck.nether.net> References: <51B6876A.9020202@si6networks.com> <51B69AB8.3080502@gmail.com> <51B69FDB.1090809@gmail.com> To: "cb.list6" X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (puck.nether.net [204.42.254.5]); Tue, 11 Jun 2013 05:50:48 -0400 (EDT) Cc: Fernando Gont , IPv6 Ops WG , 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 09:50:56 -0000 On Jun 11, 2013, at 12:23 AM, cb.list6 wrote: > I believe Warren's data hints at the idea that the packets will vanish = if they don't fit a very specific profile. =20 Very likely=85 Anything beyond the ability of my device to filter poses a security = risk. =20 Example from 2008 of operators turning off header processing: http://www.gossamer-threads.com/lists/nsp/juniper/15066 - Jared= From fgont@si6networks.com Tue Jun 11 04:51:11 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32CC21F9433 for ; Tue, 11 Jun 2013 04:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yiq6NIORgksO for ; Tue, 11 Jun 2013 04:51:10 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id EC07A21F9412 for ; Tue, 11 Jun 2013 04:51:09 -0700 (PDT) Received: from [186.134.37.222] (helo=[192.168.0.6]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmN6N-0002ku-HV; Tue, 11 Jun 2013 13:51:04 +0200 Message-ID: <51B70C86.1010209@si6networks.com> Date: Tue, 11 Jun 2013 13:39:50 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ole Troan Subject: Re: [6MAN] draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B4865D.2000207@si6networks.com> <51B4B216.5050205@gmail.com> <51B55698.7050307@gmail.com> <510D1209-7F9E-42AA-B790-A418CBF2959D@kumari.net> <51B63314.9080502@gmail.com> <34A6E408-10F3-4824-96EF-4A85016DA590@kumari.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 11:51:11 -0000 On 06/11/2013 11:01 AM, Ole Troan wrote: > > a router does ECMP on the 5-tuple. the extension header chain doesn't > help with that. a middlebox makes some policy decision on arbitrary > bits in the packet (including L7). I'm not sure I see what help the > middlebox gets from the extension header chain here? > > in my view there is no difference between the following cases: > - 2nd fragment > - extension header chain longer than first packet > - unknown extension header > - unknown L4 - ESP These cases are different (at least from a fw point of view). - 2nd fragment is okay, beacuse you'd apply the fltering policy t the first fragment. - extension header chain longer than first apcket is harmful - Unknown ext header is enough to block as "unwanted traffic" - unknown layer 4 is enough to block - ESP may or may not be okay depending on your policy > a firewall/filtering router with the policy of only allowing packets > with known L4, will drop the packet in all the above cases. Not really. For instance, stateless filters allow non-first fragments. > what should we as the IETF do? > > we could accommodate our protocols to become more firewall friendly, Yes -- or be prepared that more traffic is blocked. > e.g. deprecate IP layer fragmentation, deprecate extension headers > (or limit their length). Me, I would deprecate fragmentation, nor would I deprecate extension headers. I would, however, limit the size of the extension header chain (to some value... whether 256 bytes, 1280 bytes, or whatever). > but, do we then also push the Internet > further away from an open end to end capable Internet, stifle > innovation in transport etc? This cat is out of the bug (and has been out of the bag for.. what? 20 years?). Firewalls block unknown traffic. And from a netadmin pov, you usually want your network to do what's required to do, and not more than that -- that's what "default deny" is about. You don't really want an attacker to hack your network using something for which there wasn't a legitimate use case (legitimate == such traffic was needed by the task to be performed, and this was known as such to the admin). -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Tue Jun 11 04:51:45 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2EA21F94E1; Tue, 11 Jun 2013 04:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rle6kMY5z8eG; Tue, 11 Jun 2013 04:51:42 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 60FC521F942B; Tue, 11 Jun 2013 04:51:42 -0700 (PDT) Received: from [186.134.37.222] (helo=[192.168.0.6]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmN6y-0002lJ-2P; Tue, 11 Jun 2013 13:51:41 +0200 Message-ID: <51B70F16.4050007@si6networks.com> Date: Tue, 11 Jun 2013 13:50:46 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jared Mauch Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <51B6876A.9020202@si6networks.com> <51B69AB8.3080502@gmail.com> <51B69FDB.1090809@gmail.com> <9636419F-A126-4775-A6C9-3864F8C22323@puck.nether.net> In-Reply-To: <9636419F-A126-4775-A6C9-3864F8C22323@puck.nether.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: 6man@ietf.org, IPv6 Ops WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 11:51:45 -0000 On 06/11/2013 11:50 AM, Jared Mauch wrote: > > On Jun 11, 2013, at 12:23 AM, cb.list6 wrote: > >> I believe Warren's data hints at the idea that the packets will vanish if they don't fit a very specific profile. > > Very likely… > > Anything beyond the ability of my device to filter poses a security risk. That's why we're considering limiting the size of the IPv6 header chain. > Example from 2008 of operators turning off header processing: > > http://www.gossamer-threads.com/lists/nsp/juniper/15066 I only skimmed through the that thread... but it seems unlreated to this issue -- that thread seems to be about filtering RHT0, which has/had known security issues such as being useful for amplification attacks. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From joelja@bogus.com Tue Jun 11 05:06:24 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253E521F949F for ; Tue, 11 Jun 2013 05:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxA0Fx92R431 for ; Tue, 11 Jun 2013 05:06:22 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id F027021F955A for ; Tue, 11 Jun 2013 05:06:21 -0700 (PDT) Received: from wifi-216-88.mtg.afnog.org (wifi-216-88.mtg.afnog.org [196.200.216.88]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r5BC66nL038742 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 11 Jun 2013 12:06:10 GMT (envelope-from joelja@bogus.com) Message-ID: <51B712AC.5080108@bogus.com> Date: Tue, 11 Jun 2013 14:06:04 +0200 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0 MIME-Version: 1.0 To: Fernando Gont , Ole Troan Subject: Re: [6MAN] draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B4865D.2000207@si6networks.com> <51B4B216.5050205@gmail.com> <51B55698.7050307@gmail.com> <510D1209-7F9E-42AA-B790-A418CBF2959D@kumari.net> <51B63314.9080502@gmail.com> <34A6E408-10F3-4824-96EF-4A85016DA590@kumari.net> <51B70C86.1010209@si6networks.com> In-Reply-To: <51B70C86.1010209@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 11 Jun 2013 12:06:12 +0000 (UTC) Cc: Christian Huitema , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 12:06:24 -0000 On 6/11/13 1:39 PM, Fernando Gont wrote: > On 06/11/2013 11:01 AM, Ole Troan wrote: >> a router does ECMP on the 5-tuple. the extension header chain doesn't >> help with that. a middlebox makes some policy decision on arbitrary >> bits in the packet (including L7). I'm not sure I see what help the >> middlebox gets from the extension header chain here? >> >> in my view there is no difference between the following cases: >> - 2nd fragment >> - extension header chain longer than first packet >> - unknown extension header >> - unknown L4 - ESP > These cases are different (at least from a fw point of view). > > - 2nd fragment is okay, beacuse you'd apply the fltering policy t the > first fragment. Wierdly I'm not that interested in a filtering half a dos attack. which is probably what happens with amplification and EDNS0 or just some joker sending me a metric ton of fragments. > > - extension header chain longer than first apcket is harmful > > - Unknown ext header is enough to block as "unwanted traffic" > > - unknown layer 4 is enough to block > > - ESP may or may not be okay depending on your policy > > >> a firewall/filtering router with the policy of only allowing packets >> with known L4, will drop the packet in all the above cases. > Not really. For instance, stateless filters allow non-first fragments. > > > >> what should we as the IETF do? >> >> we could accommodate our protocols to become more firewall friendly, > Yes -- or be prepared that more traffic is blocked. > > > >> e.g. deprecate IP layer fragmentation, deprecate extension headers >> (or limit their length). > Me, I would deprecate fragmentation, nor would I deprecate extension > headers. I would, however, limit the size of the extension header chain > (to some value... whether 256 bytes, 1280 bytes, or whatever). > > >> but, do we then also push the Internet >> further away from an open end to end capable Internet, stifle >> innovation in transport etc? > This cat is out of the bug (and has been out of the bag for.. what? 20 > years?). Firewalls block unknown traffic. > > And from a netadmin pov, you usually want your network to do what's > required to do, and not more than that -- that's what "default deny" is > about. > > You don't really want an attacker to hack your network using something > for which there wasn't a legitimate use case (legitimate == such traffic > was needed by the task to be performed, and this was known as such to > the admin). > > From otroan@employees.org Tue Jun 11 05:13:00 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E69321F96F7 for ; Tue, 11 Jun 2013 05:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WXTXO+hrbEg for ; Tue, 11 Jun 2013 05:12:54 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6179B21F9926 for ; Tue, 11 Jun 2013 05:12:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAJoSt1GQ/khL/2dsb2JhbABZgwm/Qn0WdIIjAQEEAXkQCw44VwaIGga6LY8EMweCf2EDqQKBWIE5Og X-IronPort-AV: E=Sophos;i="4.87,845,1363132800"; d="scan'208";a="83270385" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 11 Jun 2013 12:12:46 +0000 Received: from dhcp-lys02-vla252-10-147-116-93.cisco.com (dhcp-lys02-vla252-10-147-116-93.cisco.com [10.147.116.93]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5BCCiFI025812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Jun 2013 12:12:44 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [6MAN] draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) From: Ole Troan In-Reply-To: <51B70C86.1010209@si6networks.com> Date: Tue, 11 Jun 2013 14:12:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2DFE2AE6-E9D6-47F9-BC38-756045D037D4@employees.org> References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B4865D.2000207@si6networks.com> <51B4B216.5050205@gmail.com> <51B55698.7050307@gmail.com> <510D1209-7F9E-42AA-B790-A418CBF2959D@kumari.net> <51B63314.9080502@gmail.com> <34A6E408-10F3-4824-96EF-4A85016DA590@kumari.net> <51B70C86.1010209@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1508) Cc: Christian Huitema , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 12:13:00 -0000 [...] >> but, do we then also push the Internet >> further away from an open end to end capable Internet, stifle >> innovation in transport etc? >=20 > This cat is out of the bug (and has been out of the bag for.. what? 20 > years?). Firewalls block unknown traffic. >=20 > And from a netadmin pov, you usually want your network to do what's > required to do, and not more than that -- that's what "default deny" = is > about. >=20 > You don't really want an attacker to hack your network using something > for which there wasn't a legitimate use case (legitimate =3D=3D such = traffic > was needed by the task to be performed, and this was known as such to > the admin). it is far from that clear cut. it depends on where in the network you = are. in my home at least my hosts are a lot better at dropping unwanted = traffic than my CPE is. I would be interested in an analysis of where and how header parsing is = used. ISP: ECMP, DOS Enterprise border: Default drop anything I don't understand (firewall), = including reassembly of fragments Data centre border: Only allow legitimate applications? I don't think there is much the IETF can do with the protocols it = designs that will help in the case where someone operates a "throw anything I don't understand away" policy. cheers, Ole= From fernando@gont.com.ar Tue Jun 11 05:42:30 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7296321F9982; Tue, 11 Jun 2013 05:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4ZUBN6T9CNk; Tue, 11 Jun 2013 05:42:30 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id DFCCB21F96E1; Tue, 11 Jun 2013 05:42:29 -0700 (PDT) Received: from [186.134.37.222] (helo=[192.168.0.6]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmNu1-0003vb-HD; Tue, 11 Jun 2013 14:42:22 +0200 Message-ID: <51B7125C.3060603@gont.com.ar> Date: Tue, 11 Jun 2013 14:04:44 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <51B6876A.9020202@si6networks.com> <51B69AB8.3080502@gmail.com> <51B69FDB.1090809@gmail.com> In-Reply-To: <51B69FDB.1090809@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , 6man@ietf.org, IPv6 Ops WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 12:42:30 -0000 On 06/11/2013 05:56 AM, Brian E Carpenter wrote: >> Simply saying that there can be arbitrary chaining of x bytes long does not >> benefit anyone in a practical way, afaik. > > IMHO it does; for a start it makes it clear that (say) 257 bytes of > headers have a vanishingly small chance of getting through the > network, and that's much more guidance than we give today. And it > gives hardware designers a target that seems to relate to reality. FWIW, that's my take, as well. Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fgont@si6networks.com Tue Jun 11 05:43:15 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD4F21F99A4 for ; Tue, 11 Jun 2013 05:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iQG1cvR3HLu for ; Tue, 11 Jun 2013 05:43:13 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id B612D21F99A1 for ; Tue, 11 Jun 2013 05:42:59 -0700 (PDT) Received: from [186.134.37.222] (helo=[192.168.0.6]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmNuV-0003vm-Uv; Tue, 11 Jun 2013 14:42:53 +0200 Message-ID: <51B7157F.8050007@si6networks.com> Date: Tue, 11 Jun 2013 14:18:07 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: joel jaeggli Subject: Re: [6MAN] draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B4865D.2000207@si6networks.com> <51B4B216.5050205@gmail.com> <51B55698.7050307@gmail.com> <510D1209-7F9E-42AA-B790-A418CBF2959D@kumari.net> <51B63314.9080502@gmail.com> <34A6E408-10F3-4824-96EF-4A85016DA590@kumari.net> <51B70C86.1010209@si6networks.com> <51B712AC.5080108@bogus.com> In-Reply-To: <51B712AC.5080108@bogus.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 12:43:15 -0000 On 06/11/2013 02:06 PM, joel jaeggli wrote: >>> in my view there is no difference between the following cases: >>> - 2nd fragment >>> - extension header chain longer than first packet >>> - unknown extension header >>> - unknown L4 - ESP >> These cases are different (at least from a fw point of view). >> >> - 2nd fragment is okay, beacuse you'd apply the fltering policy t the >> first fragment. > Wierdly I'm not that interested in a filtering half a dos attack. which > is probably what happens with amplification and EDNS0 or just some joker > sending me a metric ton of fragments. That is a separate issue. The discussion was about which packets were harmful from an inspection point of view. Whether to filter fragments or not is a different issues, and probably depends which device the fragments are destined to, and whether there can be a legitimate use case for them or not (e.g., you might want to allow fragments for clients, but drop them if they are destined to your web server... in the same way that you might filter fragments to your router, but not through your router). Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nalini.elkins@insidethestack.com Tue Jun 11 05:57:02 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3257A21F998A for ; Tue, 11 Jun 2013 05:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOBqijBUX7lq for ; Tue, 11 Jun 2013 05:56:56 -0700 (PDT) Received: from nm9-vm0.access.bullet.mail.mud.yahoo.com (nm9-vm0.access.bullet.mail.mud.yahoo.com [66.94.237.249]) by ietfa.amsl.com (Postfix) with ESMTP id 2A50C21F9984 for <6man@ietf.org>; Tue, 11 Jun 2013 05:56:56 -0700 (PDT) Received: from [66.94.237.127] by nm9.access.bullet.mail.mud.yahoo.com with NNFMP; 11 Jun 2013 12:56:55 -0000 Received: from [66.94.237.112] by tm2.access.bullet.mail.mud.yahoo.com with NNFMP; 11 Jun 2013 12:56:55 -0000 Received: from [127.0.0.1] by omp1017.access.mail.mud.yahoo.com with NNFMP; 11 Jun 2013 12:56:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 132983.63066.bm@omp1017.access.mail.mud.yahoo.com Received: (qmail 23247 invoked by uid 60001); 11 Jun 2013 12:56:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370955414; bh=IEIaLMQsj83avTWOoBeQjhK4iC0WSCHp7fmd4I1h1tU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=vlRc0vCnvPdKy4CxbESw1KMEAepfAkiArF0db3TcUsHtbG7AVWFAKIA/MPTNogn8LB8FjVDZUZKMHznW12dhmlHQcOG0DW2GMupUuQVqZNpd/WGrn5/4/sgvVSGIsoeUd4e+4MsvZ7l7JTo3vjXnmB6QWUOkbhUyrEkiqPNY/Vs= X-YMail-OSG: _hqHl4MVM1meO.M5jXorGrwt4ct.MzYjFBjIhlFetQS3zP4 gJoHf4ppBW_HqVbYiN.6yDx53ZSGF8q2dVZUJ7MvqKoAzZ0EwV2P3eiE7aqc A1OUYa3kpyk1fad9kQDFhcv1.tcFBnaPmobII6T49dUyM3iqYr2eqvxaSjY4 Cot0fiGWYTvizdjI_CwThjiDR5gPSZoQEBgIQgEjPeE8Q.rU4Z1foahVFZmu zs3x0T4ypc_q_WPMqeZNaL6v_5ya47294i2yZKRmQ52A1.c0DGspiLNlA3gw 5vn2N4To0VXQlLnCyXtJ_oLYNoe5a1MpIhVjxXl5jkaWQL9jwNpVqcjd2rvj Eog89SjH_eM_ud0btcN_9VNwLV_U8pocrFjsNkR1yRoB29HU1gM968L4K7IT GxN1tMrQ_hhWJbtZyJ4WbDZPeZt88k0q3.PoHfUiD_Oi2gztRLIwrrXOSBSO Qru6s.dUyPdH_av4wfDeowUlQkLB5vrKfDd_MvhW1NywfFFOGt3rRnwJvCGD g5CA4cELX8QFVB_Dj0A6a3HgIcDEmRQI3sLNVhGx_BCEmk.vobPQi8G2wX7x VNWqVhRoWfioEj9xHUm50yZ3trrfmF1EGQD8sBWO7Mn5zMw9yT8._v9SVR.p CO2D55D1otVfxr1RAoutHdqj4_WFAEAtE7Yl0ikUYuc1Pn3wiTxaXQq9JMrN q5csHdw-- Received: from [24.130.37.147] by web2802.biz.mail.ne1.yahoo.com via HTTP; Tue, 11 Jun 2013 05:56:54 PDT X-Rocket-MIMEInfo: 002.001, CgpPbiBKdW4gMTEsIDIwMTMsIGF0IDEyOjIzIEFNLCBjYi5saXN0NiA8Y2IubGlzdDZAZ21haWwuY29tPiB3cm90ZToKCj4gSSBiZWxpZXZlIFdhcnJlbidzIGRhdGEgaGludHMgYXQgdGhlIGlkZWEgdGhhdCB0aGUgcGFja2V0cyB3aWxsIHZhbmlzaCBpZiB0aGV5IGRvbid0IGZpdCBhIHZlcnkgc3BlY2lmaWMgcHJvZmlsZS7CoCAKCj5WZXJ5IGxpa2VseeKApgoKPkFueXRoaW5nIGJleW9uZCB0aGUgYWJpbGl0eSBvZiBteSBkZXZpY2UgdG8gZmlsdGVyIHBvc2VzIGEgc2VjdXJpdHkgcmlzay7CoCAKCj5FeGEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.146.552 References: <51B6876A.9020202@si6networks.com> <51B69AB8.3080502@gmail.com> <51B69FDB.1090809@gmail.com> <9636419F-A126-4775-A6C9-3864F8C22323@puck.nether.net> Message-ID: <1370955414.21828.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> Date: Tue, 11 Jun 2013 05:56:54 -0700 (PDT) From: Nalini Elkins Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) To: Jared Mauch , "cb.list6" In-Reply-To: <9636419F-A126-4775-A6C9-3864F8C22323@puck.nether.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-153701192-1501173685-1370955414=:21828" Cc: Fernando Gont , IPv6 Ops WG , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 12:57:02 -0000 ---153701192-1501173685-1370955414=:21828 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A=0AOn Jun 11, 2013, at 12:23 AM, cb.list6 wrote:=0A= =0A> I believe Warren's data hints at the idea that the packets will vanish= if they don't fit a very specific profile.=C2=A0 =0A=0A>Very likely=E2=80= =A6=0A=0A>Anything beyond the ability of my device to filter poses a securi= ty risk.=C2=A0 =0A=0A>Example from 2008 of operators turning off header pro= cessing:=0A=0A>http://www.gossamer-threads.com/lists/nsp/juniper/15066=0A= =0A>Jared=0A=0A2008? =C2=A0 RH0? =C2=A0=C2=A0=0A=0ADudes, have we not moved= beyond this?=0A_______________________________________________=0Av6ops mai= ling list=0Av6ops@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/v6ops ---153701192-1501173685-1370955414=:21828 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

    On Jun 11, 2013, at 12:23 AM, cb.list6 = <cb.list6@gmail.com> wrote:

    > I believe Warren's data = hints at the idea that the packets will vanish if they don't fit a very spe= cific profile. 

    >Very likely=E2=80=A6

    >Anything b= eyond the ability of my device to filter poses a security risk. 
    <= br>>Example from 2008 of operators turning off header processing:
    >http://www.gossamer-threads.com/lists/nsp/juniper/15066

    >Jar= ed

    2008?   RH0?   

    Dudes, have we not moved beyond this?
    _____________= __________________________________
    v6ops mailing list
    v6ops@ietf.org
    = h= ttps://www.ietf.org/mailman/listinfo/v6ops


    ---153701192-1501173685-1370955414=:21828-- From randy@psg.com Tue Jun 11 08:17:54 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DEE21F99F0; Tue, 11 Jun 2013 08:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyJpDzOrpHkT; Tue, 11 Jun 2013 08:17:53 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id E1A4821F99C6; Tue, 11 Jun 2013 08:17:53 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UmQKW-000DMG-6n; Tue, 11 Jun 2013 15:17:52 +0000 Date: Tue, 11 Jun 2013 17:17:49 +0200 Message-ID: From: Randy Bush To: Nalini Elkins Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) In-Reply-To: <1370955414.21828.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> References: <51B6876A.9020202@si6networks.com> <51B69AB8.3080502@gmail.com> <51B69FDB.1090809@gmail.com> <9636419F-A126-4775-A6C9-3864F8C22323@puck.nether.net> <1370955414.21828.YahooMailNeo@web2802.biz.mail.ne1.yahoo.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=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG , IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 15:17:54 -0000 > 2008? =A0 RH0? =A0=A0 > Dudes, have we not moved beyond this? Jun 10 15:03:54 psg kernel: IPFW2: IPV6 - Unknown Extension Header(64), ext= _hd=3D0 welcome to the operational internet randy From warren@kumari.net Tue Jun 11 08:20:30 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB2E21F99AB; Tue, 11 Jun 2013 08:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JgwxA88WJwj; Tue, 11 Jun 2013 08:20:25 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8EA21F965B; Tue, 11 Jun 2013 08:20:25 -0700 (PDT) Received: from [192.168.0.187] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id E6C071B401CE; Tue, 11 Jun 2013 11:20:23 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [6MAN] Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) From: Warren Kumari In-Reply-To: Date: Tue, 11 Jun 2013 11:20:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8DACCDCF-FDAF-461C-A833-BF5F3BED20AE@kumari.net> References: <51B6876A.9020202@si6networks.com> <51B69AB8.3080502@gmail.com> <51B69FDB.1090809@gmail.com> <9636419F-A126-4775-A6C9-3864F8C22323@puck.nether.net> <1370955414.21828.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> To: Randy Bush X-Mailer: Apple Mail (2.1503) Cc: IPv6 Deployment Prevention , IPv6 Ops WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 15:20:30 -0000 On Jun 11, 2013, at 11:17 AM, Randy Bush wrote: >> 2008? RH0? =20 >> Dudes, have we not moved beyond this? >=20 Nope, and we never will. It is really easy to send an RH0 packet -- if = you were an attacker, why wouldn't you at least try it?! > Jun 10 15:03:54 psg kernel: IPFW2: IPV6 - Unknown Extension = Header(64), ext_hd=3D0 >=20 > welcome to the operational internet >=20 Indeed. W > randy > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -- I don't think the execution is relevant when it was obviously a bad idea = in the first place. This is like putting rabid weasels in your pants, and later expressing = regret at having chosen those particular rabid weasels and that pair of = pants.=20 ---maf Warren Kumari warren@kumari.net From nalini.elkins@insidethestack.com Tue Jun 11 08:37:21 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D7C21F99F6 for ; Tue, 11 Jun 2013 08:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fmt6dcUQYEhg for ; Tue, 11 Jun 2013 08:37:14 -0700 (PDT) Received: from nm25.access.bullet.mail.mud.yahoo.com (nm25.access.bullet.mail.mud.yahoo.com [66.94.237.90]) by ietfa.amsl.com (Postfix) with ESMTP id C6EB421F99BB for ; Tue, 11 Jun 2013 08:37:14 -0700 (PDT) Received: from [66.94.237.201] by nm25.access.bullet.mail.mud.yahoo.com with NNFMP; 11 Jun 2013 15:37:13 -0000 Received: from [66.94.237.98] by tm12.access.bullet.mail.mud.yahoo.com with NNFMP; 11 Jun 2013 15:37:13 -0000 Received: from [127.0.0.1] by omp1003.access.mail.mud.yahoo.com with NNFMP; 11 Jun 2013 15:37:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 879741.84370.bm@omp1003.access.mail.mud.yahoo.com Received: (qmail 53911 invoked by uid 60001); 11 Jun 2013 15:37:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370965033; bh=8K2I4ILTXmhC/9mJUwFxOPiaYbrnSk0jjyAnAfL7gnU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AkPf8fdKYHe8N7r96vYOblNEDhLAF2z8UY/LeWowocZGkeXsmNCIjE1H2a21xtAyFY0iPCnjQ1InQrAoCUyn7yuRFPoFvtZVEz4q4rIsazkghjDCY2yxezjaNsvIcuh/Kuv8gYnBVaJPK8axxN2BM7cj62z+S5eE/FCDUSWDJ+U= X-YMail-OSG: 0QkKcO4VM1mc8ZKqa8iaCPNmNJ9anfpfdMj4ouXdl.0rJFB HebIqPhgA6q6BotHb9WTM0D.Jks026CtG3Z6YFFfVxhuDE3yeeQVe3wq8T5d ABVDp202dBoW2gadg8D0r1a1HbxwmD_AKpHBdQ9EHPzLHk7Rz5z621NspNYX o16ksNRXAnh7ayvSXhD2aRwIZOXoLUyr0EPLFlKzcqZ2fntkSg2tHuFCR59j qN2dbW.ngYE8.i51IUP_4w7mWITHPX8RusSdVhawYGvECLLMHz9i597SVv8y TZgEztzgycThAoCjnKf7kPQQhivTCy7mcnmSU3PpnvxsqEKw_7Xn.KdTaQZ2 Xwu50aUrtxX0zQxzeuVd8AlIcBzlJAlRPMzRYVWl26FNqL4Ko6o7zIYPn1Vi XMidd62dK0cxYwMzGCh1JHhp7ZrBOZoEWox17.3QFhEnh0C0CcSmCi90dizC S5.o1K5eSMB9rhUNPh6TTTxsgfHfrgygb8K.ewm3SdjKs8a2a.l1VFSka9vI YvWpdxKMIhWdz90Sc3A9DsgUW3AvIdH_njqx1ojmUpbak2pq.CYoVgQ8hAIO Kfaf8HxBW Received: from [24.130.37.147] by web2805.biz.mail.ne1.yahoo.com via HTTP; Tue, 11 Jun 2013 08:37:13 PDT X-Rocket-MIMEInfo: 002.001, wqAKPiAyMDA4PyDCoCBSSDA_IMKgwqAKPiBEdWRlcywgaGF2ZSB3ZSBub3QgbW92ZWQgYmV5b25kIHRoaXM_Cgo.Pkp1biAxMCAxNTowMzo1NCBwc2cga2VybmVsOiBJUEZXMjogSVBWNiAtIFVua25vd24gRXh0ZW5zaW9uIEhlYWRlcig2NCksIGV4dF9oZD0wCgo.PndlbGNvbWUgdG8gdGhlIG9wZXJhdGlvbmFsIGludGVybmV0Cgo.PnJhbmR5CgpTdXJlLCBndXlzLiDCoEkgd2FzIG9ubHkgc2hvd2luZyBmcnVzdHJhdGlvbi4gwqBJIHN1cHBvc2UgYXQgdmVuZG9ycyBzdGlsbCBzdXBwb3J0aW5nIGhlYWRlcnMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.146.552 References: <51B6876A.9020202@si6networks.com> <51B69AB8.3080502@gmail.com> <51B69FDB.1090809@gmail.com> <9636419F-A126-4775-A6C9-3864F8C22323@puck.nether.net> <1370955414.21828.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> Message-ID: <1370965033.52494.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Tue, 11 Jun 2013 08:37:13 -0700 (PDT) From: Nalini Elkins Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) To: Randy Bush In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1619178251-1005108325-1370965033=:52494" Cc: IPv6 Ops WG , IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 15:37:21 -0000 --1619178251-1005108325-1370965033=:52494 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =A0=0A> 2008? =A0 RH0? =A0=A0=0A> Dudes, have we not moved beyond this?=0A= =0A>>Jun 10 15:03:54 psg kernel: IPFW2: IPV6 - Unknown Extension Header(64)= , ext_hd=3D0=0A=0A>>welcome to the operational internet=0A=0A>>randy=0A=0AS= ure, guys. =A0I was only showing frustration. =A0I suppose at vendors still= supporting headers deprecated for quite a while. =A0 But, it takes a while= for equipment to get upgraded everywhere. =A0(Sigh)=0A=0AAnd what is with = the "IPv6 Deployment Prevention" group name for the IPv6@IETF.org list? =A0= Just noticed that. =A0HAHAHAHAHA? =A0 Frustration, anyone? --1619178251-1005108325-1370965033=:52494 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
     
    =
    =0A> 2008?   RH0?   
    &g= t; Dudes, have we not moved beyond this?

    >>Jun 10 15:03:54 psg= kernel: IPFW2: IPV6 - Unknown Extension Header(64), ext_hd=3D0

    >= >welcome to the operational internet

    >>randy

    Sure, guys. =  I was only showing frustration.  I suppose at vendors still supp= orting headers deprecated for quite a while.   But, it takes a while f= or equipment to get upgraded everywhere.  (Sigh)

    And what is with th= e "IPv6 Deployment Prevention" group name for the IPv6@IETF.org list?  = ;Just noticed that.  HAHAHAHAHA?   Frustration, anyone?

    --1619178251-1005108325-1370965033=:52494-- From randy@psg.com Tue Jun 11 08:43:00 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DEE21F965B; Tue, 11 Jun 2013 08:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URGOpPXG0kSf; Tue, 11 Jun 2013 08:43:00 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C3FB721F880F; Tue, 11 Jun 2013 08:42:59 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UmQio-000DSn-Be; Tue, 11 Jun 2013 15:42:59 +0000 Date: Tue, 11 Jun 2013 17:42:55 +0200 Message-ID: From: Randy Bush To: Nalini Elkins Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) In-Reply-To: <1370965033.52494.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> References: <51B6876A.9020202@si6networks.com> <51B69AB8.3080502@gmail.com> <51B69FDB.1090809@gmail.com> <9636419F-A126-4775-A6C9-3864F8C22323@puck.nether.net> <1370955414.21828.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370965033.52494.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Ops WG , IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 15:43:00 -0000 > it takes a while for equipment to get upgraded everywhere. it's pretty quick, no more than a decade or two randy From nalini.elkins@insidethestack.com Tue Jun 11 08:45:09 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E736321F96FB for ; Tue, 11 Jun 2013 08:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoKekxngvkDX for ; Tue, 11 Jun 2013 08:45:02 -0700 (PDT) Received: from nm27-vm7.access.bullet.mail.bf1.yahoo.com (nm27-vm7.access.bullet.mail.bf1.yahoo.com [216.109.115.230]) by ietfa.amsl.com (Postfix) with ESMTP id B9A4A21F994A for ; Tue, 11 Jun 2013 08:45:01 -0700 (PDT) Received: from [66.196.81.163] by nm27.access.bullet.mail.bf1.yahoo.com with NNFMP; 11 Jun 2013 15:45:01 -0000 Received: from [66.94.237.196] by tm9.access.bullet.mail.bf1.yahoo.com with NNFMP; 11 Jun 2013 15:45:01 -0000 Received: from [66.94.237.112] by tm7.access.bullet.mail.mud.yahoo.com with NNFMP; 11 Jun 2013 15:45:01 -0000 Received: from [127.0.0.1] by omp1017.access.mail.mud.yahoo.com with NNFMP; 11 Jun 2013 15:45:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 123293.87232.bm@omp1017.access.mail.mud.yahoo.com Received: (qmail 98151 invoked by uid 60001); 11 Jun 2013 15:45:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370965500; bh=k8ZnXGIvIpV3soCVOTWcYg1AYeKWRWn4avxFgplZHFM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=StdN5ZRbLW79sz0IhCI6/ZQCnCLMH83hC39NHVWckU3akiBdI9Y3t+5LxMJrHk0fv0Focw+DcZVVCu7zMvmnhD1qtoRugTLpDMrRNXqNYvi5UaMVn6mqvokl7OHx7J8p9rLbLExEvifea2log1TabrWi2jZeC/hfg+S3aEBftc0= X-YMail-OSG: ZcovsvgVM1l5TQ6.M4G8YMzhvV7Tr.psL5D9_zE6rPSWOBt VN0eQRkj8dD77RA6ZA62wgg8tn_MoMucCkP13ah97k8UZ8P9xYvNODPc41Rw 1PEheV7YNn0FOjBr7yQdoXBNzy_FlYSae3Kif1HwbRQag22Z8qh._caQCREn HFPcGRDNucZzxUAI.cDUADtAxpDn1K6b0IFyrMwbpClzLTPepHpup4SKBJuo h05BUsOZnETLmlnQJ4jvDO95JcYVA0ernO6uX.xC9PQ9NKjoxiPf9Bq409WP 9AeZiB.QqFCs_l8pB3qVuJHu0PQMZxvQmHOKupt7csWFByaEl_Mk2FpVe575 dgYRePS3V2lvodx0Qy0Ke.Ht8qxfKPrBWBQOkOAoZ8J0FDuU6A37RjX7nyxt slx4nVqiEpfNYbHLLiUCzTQzSSDtP7hzLdJMjGyEhZq79Np4ktrmUTqm7fhW Z_r.5JVeCcGAqVLGOyha3kuq.Bzy3yoAQoWsAncoIz6KdDKrfeEK8ziUQuJb kkgr_X4IkwKZSYQBwQq1F3jrIC7ErUdK9.gFvXOci_rOSrWNsaOf34P0- Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Tue, 11 Jun 2013 08:45:00 PDT X-Rocket-MIMEInfo: 002.001, Cgo.IGl0IHRha2VzIGEgd2hpbGUgZm9yIGVxdWlwbWVudCB0byBnZXQgdXBncmFkZWQgZXZlcnl3aGVyZS4KCj4.aXQncyBwcmV0dHkgcXVpY2ssIG5vIG1vcmUgdGhhbiBhIGRlY2FkZSBvciB0d28KCkhBSEFIQUhBLiDCoCBTYW1lIGluIGVudGVycHJpc2VzLiDCoFNvbWUgb2Ygb3VyIGZvbGtzIGFyZSBydXNoaW5nIG1hZGx5IGZyb20gMTk4MCB0byAxOTgxLgoKcmFuZHkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.146.552 References: <51B6876A.9020202@si6networks.com> <51B69AB8.3080502@gmail.com> <51B69FDB.1090809@gmail.com> <9636419F-A126-4775-A6C9-3864F8C22323@puck.nether.net> <1370955414.21828.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <1370965033.52494.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Message-ID: <1370965500.97882.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Tue, 11 Jun 2013 08:45:00 -0700 (PDT) From: Nalini Elkins Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) To: Randy Bush In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-821179973-1370965500=:97882" Cc: IPv6 Ops WG , IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 15:45:09 -0000 ---1551098171-821179973-1370965500=:97882 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A> it takes a while for equipment to get upgraded everywhere.=0A=0A>>i= t's pretty quick, no more than a decade or two=0A=0AHAHAHAHA. =A0 Same in e= nterprises. =A0Some of our folks are rushing madly from 1980 to 1981.=0A=0A= randy ---1551098171-821179973-1370965500=:97882 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

    =0A> it takes a while for equipment = to get upgraded everywhere.

    >>it's pretty quick, no more than = a decade or two

    HAHAHAHA.   Same in enterprises.  Some of our f= olks are rushing madly from 1980 to 1981.

    randy


    ---1551098171-821179973-1370965500=:97882-- From warren@kumari.net Tue Jun 11 09:15:26 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8DD21F8AC2; Tue, 11 Jun 2013 09:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7oOjgPap7Lc; Tue, 11 Jun 2013 09:15:21 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5136D21F8F15; Tue, 11 Jun 2013 09:15:21 -0700 (PDT) Received: from [192.168.0.187] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id C72671B403F4; Tue, 11 Jun 2013 12:15:19 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [6MAN] Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) From: Warren Kumari In-Reply-To: <9636419F-A126-4775-A6C9-3864F8C22323@puck.nether.net> Date: Tue, 11 Jun 2013 12:15:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51B6876A.9020202@si6networks.com> <51B69AB8.3080502@gmail.com> <51B69FDB.1090809@gmail.com> <9636419F-A126-4775-A6C9-3864F8C22323@puck.nether.net> To: Jared Mauch X-Mailer: Apple Mail (2.1503) Cc: Fernando Gont , 6man@ietf.org, IPv6 Ops WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 16:15:26 -0000 On Jun 11, 2013, at 5:50 AM, Jared Mauch wrote: >=20 > On Jun 11, 2013, at 12:23 AM, cb.list6 wrote: >=20 >> I believe Warren's data hints at the idea that the packets will = vanish if they don't fit a very specific profile. =20 Yup.=20 >=20 > Very likely=85 >=20 > Anything beyond the ability of my device to filter poses a security = risk. =20 Also yup. And the deployability of things like extension headers is influenced by = operator's default-deny / filtering policy.=20 If the IPv6 stack on a host knows that the traffic is local to a link = (like link-local :-)) it has a high likelihood of being able to ship any = old thing (including EH) to other hosts - most folk don't filter on L2. As soon as the traffic is destined for a different subnet the stack has = no (easy) way of knowing if the traffic is likely to hit a filter[0] -- = this makes it "dangerous" for it to assume that it can insert headers = into the packet, and so it should assume that such packets will be = dropped. The obvious exception to this is things explicitly configured, like ESP = -- I assume (with my v4 hat!) that most things I try to connect to will = drop IPSec, except VPN servers, which has specific rules to allow allow = it. If you are using IPv6 ESP / AH to encrypt traffic to something that is = expecting it (like a VPN widget) you can probably expect that there are = explicit terms in the filters to allow it. There is also a human on the = end to debug things if it doesn't work right - if you click the "Make a = VPN!!!!" button [1] and nothing happens you can call someone and shout = till they fix it :-P W [0]: Well, the host stack could probe by sending packets with and = without EH and only use them if they seem to work. This implies that the = actual extensions are not critical though. [1]: or site-to-site VPN, etc. >=20 > Example from 2008 of operators turning off header processing: >=20 > http://www.gossamer-threads.com/lists/nsp/juniper/15066 >=20 > - Jared > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -- After you'd known Christine for any length of time, you found yourself = fighting a desire to look into her ear to see if you could spot daylight = coming the other way. -- (Terry Pratchett, Maskerade) From sander@steffann.nl Tue Jun 11 16:59:12 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8EF21F9ABE; Tue, 11 Jun 2013 16:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIeUvRVPiosI; Tue, 11 Jun 2013 16:59:08 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 241BA21F9A78; Tue, 11 Jun 2013 16:58:59 -0700 (PDT) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id 96D91206F; Wed, 12 Jun 2013 01:58:56 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) From: Sander Steffann In-Reply-To: <51B6876A.9020202@si6networks.com> Date: Wed, 12 Jun 2013 01:58:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51B6876A.9020202@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1508) Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 23:59:12 -0000 Hi, > My question to th wg is: >=20 > 1) Do we want to limit the size of the IPv6 header chain? I think it is necessary yes. > 2) If so, which limit should we pick? I think there are two conditions here: - The full layer-4 header must be within this limit, and it must be in = the first fragment (if fragmented at all) - The limit should be larger than what is currently used + some margin = for stuff we forgot Take i.e. Figure 3 of = http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_pap= er0900aecd8054d37d.html as example. It shows a Mobile-IPv6 packet: IPv6 = header (40 octets) + Routing header (24 octets) + Destination Options = header (24 octets) + Fragmentation header (8 octets). Add to that a = basic TCP header (20 octets) and we arrive at 116 octets. So a limit of 128 would currently probably be ok, but I personally would = prefer the limit to be a bit higher just to have some extra margin. Cheers, Sander From marka@isc.org Tue Jun 11 17:38:07 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D06421F9B43; Tue, 11 Jun 2013 17:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlfp4bR-m+q9; Tue, 11 Jun 2013 17:38:07 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id F0BC321F9B3F; Tue, 11 Jun 2013 17:38:06 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 6E7EEC951A; Wed, 12 Jun 2013 00:38:04 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1370997485; bh=RDpi6t1GCSFrKTWvAVEIVic0HRUQZPdiLn17zyP9u94=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=MBqEmMTV4olXLhPBakoQdqn33eRJgQ2haawuJSwlqhnftRZN1UnLRF/VflD+zIepl bQaqT8mN1/DToWThHeRRbwyzrA6DAScCPC1U+A/J6yQF7IGORJme/s7U0xGNKFSWU4 TeghN9nl0HvDNKLRrrDjOl1/NWqIyCu+7KAtDazw= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Wed, 12 Jun 2013 00:38:04 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:60d5:da61:24bd:3a9a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 301F5216C40; Wed, 12 Jun 2013 00:38:04 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 0374235C2E8B; Wed, 12 Jun 2013 10:37:59 +1000 (EST) To: Sander Steffann From: Mark Andrews References: <51B6876A.9020202@si6networks.com> Subject: Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) In-reply-to: Your message of "Wed, 12 Jun 2013 01:58:55 +0200." Date: Wed, 12 Jun 2013 10:37:59 +1000 Message-Id: <20130612003800.0374235C2E8B@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 00:38:07 -0000 The obvious limit is no re-assembly required to find the L4 header. As for fragments not containing enough information create a new fragement header code and copy more of the existing headers. Use ICMPv6 Parameter Problem as a signal to switch back to the old fragmentation header. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From fgont@si6networks.com Wed Jun 12 06:05:25 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D29321F9B10; Wed, 12 Jun 2013 06:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQWTn--Jptwo; Wed, 12 Jun 2013 06:05:24 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 8668721F9AD3; Wed, 12 Jun 2013 06:05:24 -0700 (PDT) Received: from [186.134.1.134] (helo=[192.168.0.6]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Umkjm-0007Dn-Jv; Wed, 12 Jun 2013 15:05:19 +0200 Message-ID: <51B867C8.8010100@si6networks.com> Date: Wed, 12 Jun 2013 14:21:28 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Mark Andrews Subject: Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> In-Reply-To: <20130612003800.0374235C2E8B@drugs.dv.isc.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 13:05:25 -0000 On 06/12/2013 02:37 AM, Mark Andrews wrote: > The obvious limit is no re-assembly required to find the L4 header. That's already in draft-ietf-6man-oersized-header-chain > As for fragments not containing enough information create a new > fragement header code and copy more of the existing headers. Use > ICMPv6 Parameter Problem as a signal to switch back to the old > fragmentation header. mm.. not sure what you mean. P.S.: Any thoughts regarding limiting the extension header chain to some specific size? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From touch@isi.edu Wed Jun 12 10:07:36 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E8E21F9ACC; Wed, 12 Jun 2013 10:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.966 X-Spam-Level: X-Spam-Status: No, score=-102.966 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4TKu7vXV+cl; Wed, 12 Jun 2013 10:07:30 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id E9B4321F9A7A; Wed, 12 Jun 2013 10:07:29 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r5CH71W2013936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 10:07:01 -0700 (PDT) Message-ID: <51B8AAA7.3020909@isi.edu> Date: Wed, 12 Jun 2013 10:06:47 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Fernando Gont , Internet Area Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> In-Reply-To: <51B867C8.8010100@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Wed, 12 Jun 2013 10:22:00 -0700 Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Mark Andrews X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:07:36 -0000 Cc'd to INTAREA, where I believe fundamental changes to IP should be discussed: On 6/12/2013 5:21 AM, Fernando Gont wrote: > On 06/12/2013 02:37 AM, Mark Andrews wrote: >> The obvious limit is no re-assembly required to find the L4 header. > > That's already in draft-ietf-6man-oersized-header-chain Why is that not being reviewed in INTAREA? This isn't a 6man issue: It is not chartered to develop major changes or additions to the IPv6 specifications Further, at best, 2460 should say that the first fragment should include everything up to and including the fragment header. However, anything other than that wouldn't reassemble, so it's a self-correcting implementation error. EVERYTHING that IP *needs* to examine is before the frag header; that's already in 2460. Joe From fgont@si6networks.com Wed Jun 12 10:36:47 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134E411E80EC; Wed, 12 Jun 2013 10:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iszRpTjsmAkF; Wed, 12 Jun 2013 10:36:45 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA9611E80E3; Wed, 12 Jun 2013 10:36:45 -0700 (PDT) Received: from pd95c600c.dip0.t-ipconnect.de ([217.92.96.12] helo=[192.168.0.77]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmoyO-0005fP-Ig; Wed, 12 Jun 2013 19:36:41 +0200 Message-ID: <51B8B1A4.90702@si6networks.com> Date: Wed, 12 Jun 2013 19:36:36 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Joe Touch Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> In-Reply-To: <51B8AAA7.3020909@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Mark Andrews X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:36:47 -0000 On 06/12/2013 07:06 PM, Joe Touch wrote: > Cc'd to INTAREA, where I believe fundamental changes to IP should be > discussed: I disagree. This is nto a fundamental change, but rather a deployment issue, well within the charter. See: The 6man working group is responsible for the maintenance, upkeep, and advancement of the IPv6 protocol specifications and addressing architecture. It is not chartered to develop major changes or additions to the IPv6 specifications. The working group will address protocol limitations/issues discovered during deployment and operation. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From internet-drafts@ietf.org Wed Jun 12 10:45:15 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD9721F99C1; Wed, 12 Jun 2013 10:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+NGfnPyFr3X; Wed, 12 Jun 2013 10:45:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92EF111E80A2; Wed, 12 Jun 2013 10:45:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-stable-privacy-addresses-10.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130612174513.32059.54189.idtracker@ietfa.amsl.com> Date: Wed, 12 Jun 2013 10:45:13 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:45:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : A method for Generating Stable Privacy-Enhanced Addresse= s with IPv6 Stateless Address Autoconfiguration (SLAAC) Author(s) : Fernando Gont Filename : draft-ietf-6man-stable-privacy-addresses-10.txt Pages : 29 Date : 2013-06-12 Abstract: This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware address (e.g., using IEEE identifiers), such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique- local addresses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-stable-privacy-addresses= -10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fgont@si6networks.com Wed Jun 12 10:47:56 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB9311E80F7; Wed, 12 Jun 2013 10:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIz6MNdltgOu; Wed, 12 Jun 2013 10:47:56 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 246E011E80E6; Wed, 12 Jun 2013 10:47:56 -0700 (PDT) Received: from [2001:5c0:1400:a::391] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Ump96-0005wZ-S2; Wed, 12 Jun 2013 19:47:44 +0200 Message-ID: <51B8B43E.3070103@si6networks.com> Date: Wed, 12 Jun 2013 19:47:42 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Joe Touch Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <51B8B1A4.90702@si6networks.com> <51B8B381.6090609@isi.edu> In-Reply-To: <51B8B381.6090609@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Mark Andrews X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:47:57 -0000 On 06/12/2013 07:44 PM, Joe Touch wrote: >> >> I disagree. This is nto a fundamental change, but rather a deployment >> issue, well within the charter. See: > > It can't be just a deployment issue if it updates 2460 to change how > fragmentation works. It doesn't change how fragmentation works. It just clarifies a corner case which was allowed by the standard, but is not employed in practice, and none expected to happen. >> The 6man working group is responsible for the maintenance, upkeep, >> and advancement of the IPv6 protocol specifications and addressing >> architecture. It is not chartered to develop major changes or >> additions to the IPv6 specifications. > > IPv6 already puts all the per-hop information before the fragmentation > header. Requiring the entire header chain to be inside the first > fragment is, IMO, a major change. I guess we must agree to disagree. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From gert@space.net Wed Jun 12 10:49:12 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C21911E80F7 for ; Wed, 12 Jun 2013 10:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1m6+tBQGfLs for ; Wed, 12 Jun 2013 10:49:12 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD1C11E8105 for <6man@ietf.org>; Wed, 12 Jun 2013 10:49:11 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 9E49060A03 for <6man@ietf.org>; Wed, 12 Jun 2013 19:49:08 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 6B1B86085B for <6man@ietf.org>; Wed, 12 Jun 2013 19:49:08 +0200 (CEST) Received: (qmail 9979 invoked by uid 1007); 12 Jun 2013 19:49:08 +0200 Date: Wed, 12 Jun 2013 19:49:08 +0200 From: Gert Doering To: Joe Touch Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) Message-ID: <20130612174908.GT2504@Space.Net> References: <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51B8AAA7.3020909@isi.edu> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:49:12 -0000 Hi, On Wed, Jun 12, 2013 at 10:06:47AM -0700, Joe Touch wrote: > EVERYTHING that IP *needs* to examine is before the frag header; that's > already in 2460. And *this* is why IETF is still producing documents that vendors can not implement. Loop back to about 50 messages earlier in this thread, thanks so much. We're not talking ivory tower theoretical routers. We're talking about devices that can stand the heat out there, like "be able to apply different rate limiting classes to incoming BGP SYNs from trusted networks, and to ICMP packets from the world". This MUST be done by the hardware, and it MUST be able to look at *Layer 4* information. *sigh* And then people wonder why operators stop bothering with IETF processes. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From fgont@si6networks.com Wed Jun 12 10:55:09 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0BD21E80AD for ; Wed, 12 Jun 2013 10:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIkB-2UbLJ0M for ; Wed, 12 Jun 2013 10:55:08 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE1521E80A6 for ; Wed, 12 Jun 2013 10:55:08 -0700 (PDT) Received: from [2001:5c0:1400:a::391] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmpGB-00067I-Na; Wed, 12 Jun 2013 19:55:03 +0200 Message-ID: <51B8B5F6.4080404@si6networks.com> Date: Wed, 12 Jun 2013 19:55:02 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org> Subject: Progressing draft-ietf-6man-stable-privacy-addresses (Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-10.txt) References: <20130612174513.32059.54189.idtracker@ietfa.amsl.com> In-Reply-To: <20130612174513.32059.54189.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Brian Haberman , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:55:09 -0000 Folks, This latest revision addresses the feedback sent by Alissa Cooper. Should we progress this document now? Thanks! Fernando On 06/12/2013 07:45 PM, 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 Maintenance Working Group of the IETF. > > Title : A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC) > Author(s) : Fernando Gont > Filename : draft-ietf-6man-stable-privacy-addresses-10.txt > Pages : 29 > Date : 2013-06-12 > > Abstract: > This document specifies a method for generating IPv6 Interface > Identifiers to be used with IPv6 Stateless Address Autoconfiguration > (SLAAC), such that addresses configured using this method are stable > within each subnet, but the Interface Identifier changes when hosts > move from one network to another. This method is meant to be an > alternative to generating Interface Identifiers based on hardware > address (e.g., using IEEE identifiers), such that the benefits of > stable addresses can be achieved without sacrificing the privacy of > users. The method specified in this document applies to all prefixes > a host may be employing, including link-local, global, and unique- > local addresses. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-10 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-stable-privacy-addresses-10 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From gert@space.net Wed Jun 12 11:30:07 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B7C21E804B for ; Wed, 12 Jun 2013 11:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, GB_AFFORDABLE=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7C4luqwQkZKQ for ; Wed, 12 Jun 2013 11:30:07 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 09ED621F95EF for <6man@ietf.org>; Wed, 12 Jun 2013 11:30:06 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 469F560863 for <6man@ietf.org>; Wed, 12 Jun 2013 20:30:05 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 2B959609F8 for <6man@ietf.org>; Wed, 12 Jun 2013 20:30:05 +0200 (CEST) Received: (qmail 76591 invoked by uid 1007); 12 Jun 2013 20:30:05 +0200 Date: Wed, 12 Jun 2013 20:30:05 +0200 From: Gert Doering To: Joe Touch Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) Message-ID: <20130612183004.GU2504@Space.Net> References: <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <20130612174908.GT2504@Space.Net> <51B8B6C9.2020606@isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OP8LxFWJZDVUP7sm" Content-Disposition: inline In-Reply-To: <51B8B6C9.2020606@isi.edu> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Gert Doering X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 18:30:07 -0000 --OP8LxFWJZDVUP7sm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jun 12, 2013 at 10:58:33AM -0700, Joe Touch wrote: > > We're talking about > > devices that can stand the heat out there >=20 > Sounds like you're living in a tower much more fragile than ivory. >=20 > If you want to stand the heat, build heat-proof stuff. I'm not a vendor, so I can't build anything myself (not on a multi-10G scale, at least). I'd like to have my vendors build devices that are heat-proof, affordable, and still conform to specifications. Without resorting to "pick any two". Specifications that are just wildly decoupled from the world ("a router is a router and has no need to look at anything but the IP address of the destination") are not helping anyone. So I'm willing to take a vendor that is heat-proof, affordable, and violates fully idiotic use-cases=20 permitted by ivory tower computer scientists designing protocols with arbitrarily long linked lists in packet headers, with no upper bounds. People tell me that IPv6 is so much better than IPv4 because all the nice restructuring of the IPv6 headers. Well, yes. Vendors do build devices that can stand the heat for IPv4, but not for IPv6. Guess why. Yes,=20 because the new header structure is so great. (And the reason for that is not in all cases "because they have more experience building IPv4 boxes") Sorry for ranting. But IETF is asking for operator input, so maybe start listening to it. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --OP8LxFWJZDVUP7sm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQCVAwUBUbi+LKkuBuNlUUl1AQK/UQP/QldOm8CUcZVq2noRhPBrvAxs8BwgKb/t NN876flbZGbSrJs70cRKLYGB3KZOo2xjyTDaS49S12aMa5HoFEU7ZMv5CRlMU/BV r+9xIRr1+CXaDFAc28cGfRKUc/s0oVsUOil3uvVzoKrzMiNS6XAiVOSjGu9OzBca 9V8XJu3Ck+g= =3/c3 -----END PGP SIGNATURE----- --OP8LxFWJZDVUP7sm-- From touch@isi.edu Wed Jun 12 10:45:14 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E28C11E80F9; Wed, 12 Jun 2013 10:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJidhS5Yvbjo; Wed, 12 Jun 2013 10:45:08 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 524C821F99C1; Wed, 12 Jun 2013 10:45:08 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r5CHilFi025683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 10:44:47 -0700 (PDT) Message-ID: <51B8B381.6090609@isi.edu> Date: Wed, 12 Jun 2013 10:44:33 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Fernando Gont Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <51B8B1A4.90702@si6networks.com> In-Reply-To: <51B8B1A4.90702@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Wed, 12 Jun 2013 11:39:21 -0700 Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Mark Andrews X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:45:14 -0000 On 6/12/2013 10:36 AM, Fernando Gont wrote: > On 06/12/2013 07:06 PM, Joe Touch wrote: >> Cc'd to INTAREA, where I believe fundamental changes to IP should be >> discussed: > > I disagree. This is nto a fundamental change, but rather a deployment > issue, well within the charter. See: It can't be just a deployment issue if it updates 2460 to change how fragmentation works. > The 6man working group is responsible for the maintenance, upkeep, > and advancement of the IPv6 protocol specifications and addressing > architecture. It is not chartered to develop major changes or > additions to the IPv6 specifications. IPv6 already puts all the per-hop information before the fragmentation header. Requiring the entire header chain to be inside the first fragment is, IMO, a major change. Joe From touch@isi.edu Wed Jun 12 10:59:40 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE0B21F8F5C; Wed, 12 Jun 2013 10:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.934 X-Spam-Level: X-Spam-Status: No, score=-104.934 tagged_above=-999 required=5 tests=[AWL=1.665, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsWaMfk6nR2o; Wed, 12 Jun 2013 10:59:17 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4F621F9952; Wed, 12 Jun 2013 10:59:16 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r5CHwRuX022846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 10:58:27 -0700 (PDT) Message-ID: <51B8B6C9.2020606@isi.edu> Date: Wed, 12 Jun 2013 10:58:33 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Gert Doering Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <20130612174908.GT2504@Space.Net> In-Reply-To: <20130612174908.GT2504@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Wed, 12 Jun 2013 11:39:21 -0700 Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:59:40 -0000 On 6/12/2013 10:49 AM, Gert Doering wrote: > Hi, > > On Wed, Jun 12, 2013 at 10:06:47AM -0700, Joe Touch wrote: >> EVERYTHING that IP *needs* to examine is before the frag header; that's >> already in 2460. > > And *this* is why IETF is still producing documents that vendors can not > implement. Loop back to about 50 messages earlier in this thread, thanks > so much. Loop back to the part where I pointed out that this is about competing business issues, not theory. > We're talking about > devices that can stand the heat out there Sounds like you're living in a tower much more fragile than ivory. If you want to stand the heat, build heat-proof stuff. Joe From kre@munnari.OZ.AU Wed Jun 12 11:46:34 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4712221E80AB; Wed, 12 Jun 2013 11:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.172 X-Spam-Level: X-Spam-Status: No, score=0.172 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2kqiMQM0ROG; Wed, 12 Jun 2013 11:46:29 -0700 (PDT) Received: from jade.coe.psu.ac.th (munnari.OZ.AU [202.29.151.3]) by ietfa.amsl.com (Postfix) with ESMTP id 5837E21E8099; Wed, 12 Jun 2013 11:46:26 -0700 (PDT) Received: from perseus.noi.kre.to (jade.coe.psu.AC.TH [IPv6:2001:3c8:9007:1::21]) by jade.coe.psu.ac.th with ESMTP id r5CIj4mP011156; Thu, 13 Jun 2013 01:45:04 +0700 (ICT) Received: from perseus.noi.kre.to (localhost [127.0.0.1]) by perseus.noi.kre.to (8.14.7/8.14.2) with ESMTP id r5CIioB7018951; Thu, 13 Jun 2013 01:44:55 +0700 (ICT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.5 From: Robert Elz To: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) In-Reply-To: <20130612174908.GT2504@Space.Net> References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Jun 2013 01:44:50 +0700 Message-ID: <10707.1371062690@perseus.noi.kre.to> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 18:46:34 -0000 Date: Wed, 12 Jun 2013 19:49:08 +0200 From: Gert Doering Message-ID: <20130612174908.GT2504@Space.Net> | Loop back to about 50 messages earlier in this thread, I don't generally read this list (any more) - just happened to see the past hour's worth of messages, so I have no idea what was 50 messages earlier, but ... | We're not talking ivory tower theoretical routers. We're talking about | devices that can stand the heat out there, like "be able to apply different | rate limiting classes to incoming BGP SYNs from trusted networks, and to | ICMP packets from the world". This MUST be done by the hardware, and it | MUST be able to look at *Layer 4* information. If that's the issue, then the routers should just be treating any packet with a frag header like dirt. That's what they deserve. Lowest sched priority, and most likely to be dropped. That's easy to accomplish in hardware (well as easy as anything else that involves looking down header chains) and perfectly acceptable - everyone knows that if one sends fragmented packets performance goes out the window. Perfectly acceptable result, and no changes at all to v6 specs are needed to get to that. On the other hand, if the real issue is firewalls, then there really should be no issue at all - firewalls already need to be able to reassemble packet chains, or they can't look inside TCP properly (as while no-one sane would ever split tcp segments in weird places, hackers will if the firewalls can't handle it properly). Reassembling IP frags is childs play compared to reassembling tcp segments. Again, no need to change anything in the IPv6 specs. Lastly, this comment caught my eye ... fgont@si6networks.com said: | It doesn't change how fragmentation works. It just clarifies a corner case | which was allowed by the standard, but is not employed in practice, and none | expected to happen. Huh? Is that really claimimng that no-one ever thought that the frag header would be anywhere but last in the header chain? That would be absurd. For one, in normal use, dest options should normally come after a frag header, processing them before the packet is reassembled would mean processing them before the packet is received correctly, which would be 100% bogus (on the other hand, if options were even invented to allow the sender some control over reassembly - perhaps to lower timeouts or something - then a destopts header before the frag header would be rational.) Beyond that, I have had cases where a frag header before a routing header made perfect sense - I know that routing headers are largely deprecated these days, but before that, it was possible to send a fragmented packet over a low MTU link, have it reassembled at the far side of that link, and then the routing header (following the frag header) causes the packet to continue over links with a larger MTU, so the penalties of fragmentation apply only where they are really needed. What's more, for the remaining use of routing headers (route opt for mobile IPv6) putting the frag header before the routing header is also the sane way to run things (the routing header there is really just a fancy destination option). Lastly, consider that most v6 headers are allowed to be larger than the MTU of the most common links in the internet at the time (and for that matter, still) and certainly larger than the required MTU for v6 links, and ask yourself how that would make any sense at all if all headers are required to be before the frag header. Leave the specs alone, header chanins can have headers (other than hop by hop opts of course) in whatever order makes sense to the application that needs to send those headers. No more rules. Just deal with it. kre From christopher.morrow@gmail.com Wed Jun 12 11:52:30 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C7311E80F7; Wed, 12 Jun 2013 11:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.433 X-Spam-Level: X-Spam-Status: No, score=-103.433 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbMT+M5NPi61; Wed, 12 Jun 2013 11:52:25 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id BB02A11E80EF; Wed, 12 Jun 2013 11:52:22 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id 13so5703062lba.16 for ; Wed, 12 Jun 2013 11:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PC3uCcAPP7uOUZYpYtU3oWaYe5ntTp/tr1hTqMzNZ1E=; b=UmjQBN4Wda1uyQYMUiIAopHXlCjv3vAVVsQeDHFSwsDKpNd2sSFX84AmO1Lr3fUr20 O1z3ahYHtF/NPVdLE410ats0y4sWFD4hpQSc2VK35FTE8R9MLILOsLEr1GERvYo0DIm8 D61NU2QHE4dkMeJBUXg4x8J/JAaEEJ2pUNj94RWTKCMlwt9MX1RWX85t99ofKpWu1L01 UvSWGndDC/+m9meIJ4sfsulG3fLnNKBrFGIV0QhoAJer9iUEM56zMg2xGNXa/aRzwGSA OSbp4GIKVuUIsqkmkfvT96EDhaUUOaWWj1LuBAJxlOA32oTwMf3D9b0zikEDLYtwrQ2T 4tvA== MIME-Version: 1.0 X-Received: by 10.152.42.236 with SMTP id r12mr10302387lal.46.1371063141363; Wed, 12 Jun 2013 11:52:21 -0700 (PDT) Received: by 10.152.5.104 with HTTP; Wed, 12 Jun 2013 11:52:20 -0700 (PDT) In-Reply-To: <10707.1371062690@perseus.noi.kre.to> References: <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <20130612174908.GT2504@Space.Net> <10707.1371062690@perseus.noi.kre.to> Date: Wed, 12 Jun 2013 14:52:20 -0400 Message-ID: Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) From: Christopher Morrow To: Robert Elz Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 18:52:30 -0000 On Wed, Jun 12, 2013 at 2:44 PM, Robert Elz wrote: > everyone knows that if one sends fragmented packets > performance goes out the window. Perfectly acceptable result, and no > changes at all to v6 specs are needed to get to that. edns0 + dnsssec == +1pkt responses From touch@isi.edu Wed Jun 12 12:56:20 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD43A11E80F6; Wed, 12 Jun 2013 12:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.703 X-Spam-Level: X-Spam-Status: No, score=-102.703 tagged_above=-999 required=5 tests=[AWL=-0.704, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maHpRQnDuUfn; Wed, 12 Jun 2013 12:56:00 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 915A911E80F9; Wed, 12 Jun 2013 12:55:48 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r5CJtDI3027759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 12:55:14 -0700 (PDT) Message-ID: <51B8D213.8040900@isi.edu> Date: Wed, 12 Jun 2013 12:54:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Robert Elz Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> In-Reply-To: <10707.1371062690@perseus.noi.kre.to> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 19:56:20 -0000 So let me get this straight: - operationally, it's appropriate to drop all fragments because they interfere with a router being efficient - operationally, it's appropriate to block ICMPs because they could interfere with network operation Sounds a lot like the Internet and its users are getting in the way of router vendors and their business model. Joe On 6/12/2013 11:44 AM, Robert Elz wrote: > Date: Wed, 12 Jun 2013 19:49:08 +0200 > From: Gert Doering > Message-ID: <20130612174908.GT2504@Space.Net> > > | Loop back to about 50 messages earlier in this thread, > > I don't generally read this list (any more) - just happened to see the > past hour's worth of messages, so I have no idea what was 50 messages > earlier, but ... > > | We're not talking ivory tower theoretical routers. We're talking about > | devices that can stand the heat out there, like "be able to apply different > | rate limiting classes to incoming BGP SYNs from trusted networks, and to > | ICMP packets from the world". This MUST be done by the hardware, and it > | MUST be able to look at *Layer 4* information. > > If that's the issue, then the routers should just be treating any packet with > a frag header like dirt. That's what they deserve. Lowest sched priority, > and most likely to be dropped. That's easy to accomplish in hardware (well > as easy as anything else that involves looking down header chains) > and perfectly acceptable - everyone knows that if one sends fragmented packets > performance goes out the window. Perfectly acceptable result, and no > changes at all to v6 specs are needed to get to that. > > On the other hand, if the real issue is firewalls, then there really should be > no issue at all - firewalls already need to be able to reassemble packet > chains, or they can't look inside TCP properly (as while no-one sane > would ever split tcp segments in weird places, hackers will if the firewalls > can't handle it properly). Reassembling IP frags is childs play compared > to reassembling tcp segments. > > Again, no need to change anything in the IPv6 specs. > > Lastly, this comment caught my eye ... > > fgont@si6networks.com said: > | It doesn't change how fragmentation works. It just clarifies a corner case > | which was allowed by the standard, but is not employed in practice, and none > | expected to happen. > > Huh? Is that really claimimng that no-one ever thought that the frag > header would be anywhere but last in the header chain? That would be > absurd. For one, in normal use, dest options should normally come > after a frag header, processing them before the packet is reassembled would > mean processing them before the packet is received correctly, which would be > 100% bogus (on the other hand, if options were even invented to allow the > sender some control over reassembly - perhaps to lower timeouts or something - > then a destopts header before the frag header would be rational.) > > Beyond that, I have had cases where a frag header before a routing header > made perfect sense - I know that routing headers are largely deprecated these > days, but before that, it was possible to send a fragmented packet over a > low MTU link, have it reassembled at the far side of that link, and then > the routing header (following the frag header) causes the packet to continue > over links with a larger MTU, so the penalties of fragmentation apply > only where they are really needed. What's more, for the remaining use of > routing headers (route opt for mobile IPv6) putting the frag header before > the routing header is also the sane way to run things (the routing header there > is really just a fancy destination option). > > Lastly, consider that most v6 headers are allowed to be larger than the > MTU of the most common links in the internet at the time (and for that > matter, still) and certainly larger than the required MTU for v6 links, and > ask yourself how that would make any sense at all if all headers are > required to be before the frag header. > > Leave the specs alone, header chanins can have headers (other than hop by > hop opts of course) in whatever order makes sense to the application that > needs to send those headers. No more rules. Just deal with it. > > kre > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fgont@si6networks.com Wed Jun 12 13:23:07 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDB611E80F0; Wed, 12 Jun 2013 13:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9zioF0K8RZC; Wed, 12 Jun 2013 13:23:06 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 8927011E80BA; Wed, 12 Jun 2013 13:23:05 -0700 (PDT) Received: from [2001:5c0:1400:a::323] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmrZN-0001Ya-Qq; Wed, 12 Jun 2013 22:23:01 +0200 Message-ID: <51B8D8A4.6030002@si6networks.com> Date: Wed, 12 Jun 2013 22:23:00 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Robert Elz Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> In-Reply-To: <10707.1371062690@perseus.noi.kre.to> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 20:23:07 -0000 On 06/12/2013 08:44 PM, Robert Elz wrote: > | We're not talking ivory tower theoretical routers. We're talking about > | devices that can stand the heat out there, like "be able to apply different > | rate limiting classes to incoming BGP SYNs from trusted networks, and to > | ICMP packets from the world". This MUST be done by the hardware, and it > | MUST be able to look at *Layer 4* information. > > If that's the issue, then the routers should just be treating any packet with > a frag header like dirt. That's not what the discussion is about. We're talking about long IPv6 header chains... which might not contain a fragment header (e.g., simply the fixed IPv6 header, plus one long (or a few) dest options header, and then the real payload). > That's what they deserve. Lowest sched priority, > and most likely to be dropped. That's easy to accomplish in hardware (well > as easy as anything else that involves looking down header chains) > and perfectly acceptable - everyone knows that if one sends fragmented packets > performance goes out the window. Perfectly acceptable result, and no > changes at all to v6 specs are needed to get to that. It is not quite acceptable if the specs say one thing, and the real world says another. > On the other hand, if the real issue is firewalls, then there really should be > no issue at all - firewalls already need to be able to reassemble packet > chains, There are stateless filters, too. > Lastly, this comment caught my eye ... > > fgont@si6networks.com said: > | It doesn't change how fragmentation works. It just clarifies a corner case > | which was allowed by the standard, but is not employed in practice, and none > | expected to happen. > > Huh? Is that really claimimng that no-one ever thought that the frag > header would be anywhere but last in the header chain? That would be > absurd. I have no idea what you're talking about. The current version of draft-ietf-6man-oversized-header-chain essentially bans packets such as thos in page 5 of Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From gert@space.net Wed Jun 12 13:40:24 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB93711E80F0 for ; Wed, 12 Jun 2013 13:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZyTelGnsNTu for ; Wed, 12 Jun 2013 13:40:24 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 329A511E80E7 for <6man@ietf.org>; Wed, 12 Jun 2013 13:40:24 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 7EAE2609F4 for <6man@ietf.org>; Wed, 12 Jun 2013 22:40:22 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 59C0660831 for <6man@ietf.org>; Wed, 12 Jun 2013 22:40:22 +0200 (CEST) Received: (qmail 18173 invoked by uid 1007); 12 Jun 2013 22:40:22 +0200 Date: Wed, 12 Jun 2013 22:40:22 +0200 From: Gert Doering To: Joe Touch Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) Message-ID: <20130612204022.GY2504@Space.Net> References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51B8D213.8040900@isi.edu> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 20:40:24 -0000 Hi, On Wed, Jun 12, 2013 at 12:54:59PM -0700, Joe Touch wrote: > So let me get this straight: > > - operationally, it's appropriate to drop all fragments because they > interfere with a router being efficient > > - operationally, it's appropriate to block ICMPs because they could > interfere with network operation > You're constructing something, that at least I never said. My router *has* to rate-limit ICMP packets that are directed at it, otherwise it's easy to nuke it away (unless I find a vendor that will give me a fully wirespeed control-plane...). But yeah, when I have to make a choice between "there is no way to make my router stand the heat but to make them unpingable", and "have it die the next time someone out there is bored", guess what my customers expect me to do (and even then, it might be necessary to be able to rate-limit BGP related packets at a different speed and using a different policer than "all the other packets that my router sees", so a pure ACL on IPv6 address without protocol/ports won't do the job) Now, having sanity in the standards - and I really like the idea of limiting the full chain of extention headers to some limit, like 256 bytes, which can then be implemented by the vendors taking my money - would help find some compromise that enables *some* flexibility, but at the same time helps me implement the necessary control in the network to make it work under adverse conditions. > Sounds a lot like the Internet and its users are getting in the way of > router vendors and their business model. No, more like "reality conflicting with the IETF model of defining beautiful things based on theoretical possibilities". Gert Doering -- operator -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From brian.e.carpenter@gmail.com Wed Jun 12 13:48:13 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B543311E8115; Wed, 12 Jun 2013 13:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZyqrUXkNpMK; Wed, 12 Jun 2013 13:48:07 -0700 (PDT) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9E911E8114; Wed, 12 Jun 2013 13:48:07 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id 10so10428705pdi.25 for ; Wed, 12 Jun 2013 13:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WKBREC8n9jsSbeSbtZ5iyT/tx/kR/jW4srEebNno3HQ=; b=QNSMlPnR3TsW/FOD44ZYp8E4PQ0lFhsPYDBAQ09DgbsLMLmEqhkVkW09G4dd4kqixZ KjGE6h90sVGam9iohqxGSbMPHSn0TVexaIPKZjIvjF/V5W8OkTYQJu8hhSYRvIPCoB4W JFqcCJQ1l8E54zRw5RdMfqvhCBufFWU/f+XlztUyXagpdJ3XOj8jlxymnHnAou6kdcrK Cf4koXXqumbAqrPGa+ZFjBaA5rwS7mclRWKgnbROezmgq1t7AUJ+o9JhuAtamH4c1iRM 1atxRc+U8iyCIGKOEusUXpIaQ0Qszmbaks9hDAHoxRBJiTmPOxS3e/IdeFg588PN/D3D l6Mg== X-Received: by 10.66.83.7 with SMTP id m7mr12453104pay.150.1371070085749; Wed, 12 Jun 2013 13:48:05 -0700 (PDT) Received: from [192.168.1.2] (153.235.252.27.dyn.cust.vf.net.nz. [27.252.235.153]) by mx.google.com with ESMTPSA id vb8sm20407717pbc.11.2013.06.12.13.48.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Jun 2013 13:48:05 -0700 (PDT) Message-ID: <51B8DE89.2040004@gmail.com> Date: Thu, 13 Jun 2013 08:48:09 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sander Steffann Subject: Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <51B6876A.9020202@si6networks.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 20:48:13 -0000 On 12/06/2013 11:58, Sander Steffann wrote: > Hi, > >> My question to th wg is: >> >> 1) Do we want to limit the size of the IPv6 header chain? > > I think it is necessary yes. > >> 2) If so, which limit should we pick? > > I think there are two conditions here: > - The full layer-4 header must be within this limit, and it must be in the first fragment (if fragmented at all) > - The limit should be larger than what is currently used + some margin for stuff we forgot > > Take i.e. Figure 3 of http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html as example. It shows a Mobile-IPv6 packet: IPv6 header (40 octets) + Routing header (24 octets) + Destination Options header (24 octets) + Fragmentation header (8 octets). Add to that a basic TCP header (20 octets) and we arrive at 116 octets. > > So a limit of 128 would currently probably be ok, but I personally would prefer the limit to be a bit higher just to have some extra margin. I think we should advocate 256 as a target for hardware designers; we know that some of them have current hardware limits less than that, but a "SHOULD inspect 256" seems reasonable (and conversely, a "SHOULD NOT exceed 256" for hosts generating IPv6 packets). Given time (as somebody said, maybe ten years) this would palliate the problem. Brian From touch@isi.edu Wed Jun 12 13:51:09 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7266911E80FD; Wed, 12 Jun 2013 13:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.975 X-Spam-Level: X-Spam-Status: No, score=-104.975 tagged_above=-999 required=5 tests=[AWL=1.624, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsYSTBniyMGP; Wed, 12 Jun 2013 13:51:03 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 32A4711E80CC; Wed, 12 Jun 2013 13:50:59 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r5CKneSp028661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 13:49:40 -0700 (PDT) Message-ID: <51B8DED6.9030306@isi.edu> Date: Wed, 12 Jun 2013 13:49:26 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Gert Doering Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> In-Reply-To: <20130612204022.GY2504@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 20:51:09 -0000 FWIW, I wouldn't mind: - IPv6 *should* limit its header chains to (some reasonable limit) What I expect when that's not the case: - SOME packets get through, perhaps more slowly - when the router can't keep up, it can drop the overload This isn't any different from many other things, e.g., when a router can't keep up with IPv6 packets that overload an egress. However, anything that says "if the chain is >X, then drop" is broken, period. At some point, if you want to play "IPv6 router", you need to earn the title. Joe On 6/12/2013 1:40 PM, Gert Doering wrote: > Hi, > > On Wed, Jun 12, 2013 at 12:54:59PM -0700, Joe Touch wrote: >> So let me get this straight: >> >> - operationally, it's appropriate to drop all fragments because they >> interfere with a router being efficient >> >> - operationally, it's appropriate to block ICMPs because they could >> interfere with network operation >> > > You're constructing something, that at least I never said. > > My router *has* to rate-limit ICMP packets that are directed at it, > otherwise it's easy to nuke it away (unless I find a vendor that will > give me a fully wirespeed control-plane...). But yeah, when I have > to make a choice between "there is no way to make my router stand the > heat but to make them unpingable", and "have it die the next time > someone out there is bored", guess what my customers expect me to do > (and even then, it might be necessary to be able to rate-limit BGP > related packets at a different speed and using a different policer than > "all the other packets that my router sees", so a pure ACL on IPv6 > address without protocol/ports won't do the job) > > Now, having sanity in the standards - and I really like the idea of > limiting the full chain of extention headers to some limit, like 256 > bytes, which can then be implemented by the vendors taking my money - > would help find some compromise that enables *some* flexibility, but > at the same time helps me implement the necessary control in the network > to make it work under adverse conditions. > > >> Sounds a lot like the Internet and its users are getting in the way of >> router vendors and their business model. > > No, more like "reality conflicting with the IETF model of defining > beautiful things based on theoretical possibilities". > > Gert Doering > -- operator > From fgont@si6networks.com Wed Jun 12 14:08:54 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93C421E8097; Wed, 12 Jun 2013 14:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QI5Na-EP8WMA; Wed, 12 Jun 2013 14:08:54 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 328EE21E8091; Wed, 12 Jun 2013 14:08:54 -0700 (PDT) Received: from [2001:5c0:1400:a::323] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmsHe-0002fO-1b; Wed, 12 Jun 2013 23:08:46 +0200 Message-ID: <51B8E35C.3070207@si6networks.com> Date: Wed, 12 Jun 2013 23:08:44 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Joe Touch Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> In-Reply-To: <51B8DED6.9030306@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Gert Doering , Robert Elz X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 21:08:54 -0000 On 06/12/2013 10:49 PM, Joe Touch wrote: > FWIW, I wouldn't mind: > > - IPv6 *should* limit its header chains to (some reasonable limit) > > What I expect when that's not the case: > > - SOME packets get through, perhaps more slowly > - when the router can't keep up, it can drop the overload > > This isn't any different from many other things, e.g., when a router > can't keep up with IPv6 packets that overload an egress. > > However, anything that says "if the chain is >X, then drop" is broken, > period. FWIW, I don't think anyone has proposed "if the chain is larger than X, then drop". We're just aiming at limiting the header chain length, *not* encouraging router to drop when the header chain exceeds that length. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From otroan@employees.org Wed Jun 12 14:25:57 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DB311E80E7; Wed, 12 Jun 2013 14:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Do84lOHBEcz4; Wed, 12 Jun 2013 14:25:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB9511E80CC; Wed, 12 Jun 2013 14:25:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAInmuFGQ/khL/2dsb2JhbABaDoJ7v0OBARZ0giMBAQQBOj8FCwtGVwaIGwa7LI4MgQQzB4J/YQOpAoFYeUA6gS0 X-IronPort-AV: E=Sophos;i="4.87,854,1363132800"; d="scan'208";a="155269681" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 12 Jun 2013 21:25:46 +0000 Received: from dhcp-10-61-111-244.cisco.com (dhcp-10-61-111-244.cisco.com [10.61.111.244]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5CLPg4M027652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Jun 2013 21:25:43 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) From: Ole Troan In-Reply-To: <51B8DED6.9030306@isi.edu> Date: Wed, 12 Jun 2013 23:25:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1508) Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Gert Doering , Robert Elz X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 21:25:58 -0000 Joe, > FWIW, I wouldn't mind: >=20 > - IPv6 *should* limit its header chains to (some reasonable limit) >=20 > What I expect when that's not the case: >=20 > - SOME packets get through, perhaps more slowly > - when the router can't keep up, it can drop the overload >=20 > This isn't any different from many other things, e.g., when a router = can't keep up with IPv6 packets that overload an egress. >=20 > However, anything that says "if the chain is >X, then drop" is broken, = period. At some point, if you want to play "IPv6 router", you need to = earn the title. an IPv6 router compliant with RFC2460 does not inspect the header chain. I'm not aware of any router that drop packets with extension headers. I'm aware of network operators applying filtering policy that results in = packets with extension headers being dropped. it would be very interesting to see where in the network those policies = are used. my assumption was on Enterprise border, and that packets go across the Internet unhindered, as well as = inside of Enterprises. it would be interesting if someone could test that. RIPE Atlas? or if operators on the list = would share what the filter where and why. just to be clear I'm not against the IETF documenting e.g. in a BCP, = what the longest expected header chain should be. cheers, Ole= From touch@isi.edu Wed Jun 12 14:31:39 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1A121E80CF; Wed, 12 Jun 2013 14:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.037 X-Spam-Level: X-Spam-Status: No, score=-103.037 tagged_above=-999 required=5 tests=[AWL=-0.438, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRoZsmneVAKx; Wed, 12 Jun 2013 14:31:33 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB5811E80FF; Wed, 12 Jun 2013 14:31:20 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r5CLUo9b004569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 14:30:53 -0700 (PDT) Message-ID: <51B8E87C.6010402@isi.edu> Date: Wed, 12 Jun 2013 14:30:36 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ole Troan Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Gert Doering , Robert Elz X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 21:31:39 -0000 On 6/12/2013 2:25 PM, Ole Troan wrote: > Joe, > >> FWIW, I wouldn't mind: >> >> - IPv6 *should* limit its header chains to (some reasonable limit) >> >> What I expect when that's not the case: >> >> - SOME packets get through, perhaps more slowly >> - when the router can't keep up, it can drop the overload >> >> This isn't any different from many other things, e.g., when a router can't keep up with IPv6 packets that overload an egress. >> >> However, anything that says "if the chain is >X, then drop" is broken, period. At some point, if you want to play "IPv6 router", you need to earn the title. > > an IPv6 router compliant with RFC2460 does not inspect the header chain. That cannot be true; there are headers after IPv6 but before fragmentation that are hop-by-hop. Joe From otroan@employees.org Wed Jun 12 14:36:16 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B833B11E8109; Wed, 12 Jun 2013 14:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLttRTIvyX+T; Wed, 12 Jun 2013 14:36:11 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 439BC11E80FF; Wed, 12 Jun 2013 14:36:10 -0700 (PDT) Received: from dhcp-10-61-111-244.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 72FA75EF1; Wed, 12 Jun 2013 14:36:07 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) From: Ole Troan In-Reply-To: <51B8E87C.6010402@isi.edu> Date: Wed, 12 Jun 2013 23:36:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E87C.6010402@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1508) Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Gert Doering , Robert Elz X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 21:36:17 -0000 Joe, >> an IPv6 router compliant with RFC2460 does not inspect the header = chain. >=20 > That cannot be true; there are headers after IPv6 but before = fragmentation that are hop-by-hop. with the exception of the HBH header, correct. I got tired of writing = that each time I was repeating myself. the HBH is an issue to itself. expect those packets to be severely rate = limited. cheers, Ole From jeroen@massar.ch Wed Jun 12 14:44:34 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C5E21E80D8; Wed, 12 Jun 2013 14:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3w7UYwNosbp; Wed, 12 Jun 2013 14:44:31 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id AA5D621E8094; Wed, 12 Jun 2013 14:44:31 -0700 (PDT) Received: from kami.ch.unfix.org (173-164-171-230-SFBA.hfc.comcastbusiness.net [173.164.171.230]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 8F527801C2BA; Wed, 12 Jun 2013 23:44:27 +0200 (CEST) Message-ID: <51B8EBBA.4000803@massar.ch> Date: Wed, 12 Jun 2013 14:44:26 -0700 From: Jeroen Massar Organization: Massar User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ole Troan Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E87C.6010402@isi.edu> <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> In-Reply-To: <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Joe Touch , Gert Doering X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 21:44:34 -0000 On 2013-06-12 14:36, Ole Troan wrote: > Joe, > >>> an IPv6 router compliant with RFC2460 does not inspect the header chain. >> >> That cannot be true; there are headers after IPv6 but before fragmentation that are hop-by-hop. > > with the exception of the HBH header, correct. I got tired of writing that each time I was repeating myself. > the HBH is an issue to itself. expect those packets to be severely rate limited. I am wondering why.... if your box cannot handle any headers, just forward the packet, decreasing the hopcount and that is just. Much more efficient, does not get in the slow path and some other box that is more capable will handle special requests. Unless the router in question knows what that HBH header will do (read: it was implemented when the definition of that header was defined) or what it should do with it, it won't be able to do anything with it anyway. Thus just ignoring/skipping it, heck not parsing any headers at all, will be quite fine... And if there is a HBH ever that a router should support, then only new router will support it anyway. Disclaimer: this is the model that sixxsd (used for the SixXS PoPs) does, and it seems to work like a charm; that is, no complaints yet ;) Greets, Jeroen From fgont@si6networks.com Wed Jun 12 14:44:55 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9774221E8101; Wed, 12 Jun 2013 14:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1duOgkSYFVl1; Wed, 12 Jun 2013 14:44:55 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id C97B921E8100; Wed, 12 Jun 2013 14:44:54 -0700 (PDT) Received: from [2001:5c0:1400:a::323] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmsqU-0003Um-72; Wed, 12 Jun 2013 23:44:46 +0200 Message-ID: <51B8EBCD.7070104@si6networks.com> Date: Wed, 12 Jun 2013 23:44:45 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ole Troan Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Joe Touch , Gert Doering X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 21:44:55 -0000 On 06/12/2013 11:25 PM, Ole Troan wrote: >> However, anything that says "if the chain is >X, then drop" is broken, period. At some point, if you want to play "IPv6 router", you need to earn the title. > > an IPv6 router compliant with RFC2460 does not inspect the header chain. > > I'm not aware of any router that drop packets with extension headers. > I'm aware of network operators applying filtering policy that results in packets with extension headers being dropped. IIRC, someone reported that Cisco ASA drop v6 packets with extension headers by default..... > just to be clear I'm not against the IETF documenting e.g. in a BCP, what the longest expected header chain should be. Well, that seems more std track than bcp to me. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From otroan@employees.org Wed Jun 12 14:54:39 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B88C11E8119; Wed, 12 Jun 2013 14:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JB+aA9c-eoKg; Wed, 12 Jun 2013 14:54:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id CF66111E810E; Wed, 12 Jun 2013 14:54:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALDsuFGQ/khL/2dsb2JhbABagwm/Q4EBFnSCIwEBBAE6PxALDjhXBogbBrsqjxAzB4J/YQOpAoFYgTk6 X-IronPort-AV: E=Sophos;i="4.87,854,1363132800"; d="scan'208";a="155270498" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 12 Jun 2013 21:54:01 +0000 Received: from dhcp-10-61-111-244.cisco.com (dhcp-10-61-111-244.cisco.com [10.61.111.244]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5CLrwGj001946 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Jun 2013 21:53:59 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) From: Ole Troan In-Reply-To: <51B8EBCD.7070104@si6networks.com> Date: Wed, 12 Jun 2013 23:53:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <24AA8E8A-B173-4BD1-99D6-7BB7B9008142@employees.org> References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8EBCD.7070104@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1508) Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 21:54:39 -0000 Fernando, >>> However, anything that says "if the chain is >X, then drop" is = broken, period. At some point, if you want to play "IPv6 router", you = need to earn the title. >>=20 >> an IPv6 router compliant with RFC2460 does not inspect the header = chain. >>=20 >> I'm not aware of any router that drop packets with extension headers. >> I'm aware of network operators applying filtering policy that results = in packets with extension headers being dropped. >=20 > IIRC, someone reported that Cisco ASA drop v6 packets with extension > headers by default..... I think you'll find that the Cisco ASA isn't marketed as a router = either, it is a firewall. >> just to be clear I'm not against the IETF documenting e.g. in a BCP, = what the longest expected header chain should be. >=20 > Well, that seems more std track than bcp to me. I don't think we should encode in standard a number that is based on the = ability of current hardware. nor do I think we have any standard documents describing the behaviour = of filtering routers / firewalls / middleboxes in this respect. cheers, Ole= From fernando@gont.com.ar Wed Jun 12 14:58:21 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B7421E8111; Wed, 12 Jun 2013 14:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ok08YPKALqMI; Wed, 12 Jun 2013 14:58:21 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 2518011E810E; Wed, 12 Jun 2013 14:58:21 -0700 (PDT) Received: from [2001:5c0:1400:a::323] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Umt3O-0003qq-QR; Wed, 12 Jun 2013 23:58:06 +0200 Message-ID: <51B8EEEE.8000400@gont.com.ar> Date: Wed, 12 Jun 2013 23:58:06 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jeroen Massar Subject: Discussion about header chains (was Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)) References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E87C.6010402@isi.edu> <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> <51B8EBBA.4000803@massar.ch> In-Reply-To: <51B8EBBA.4000803@massar.ch> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Joe Touch , Gert Doering X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 21:58:22 -0000 Jeroen, On 06/12/2013 11:44 PM, Jeroen Massar wrote: >> with the exception of the HBH header, correct. I got tired of writing that each time I was repeating myself. >> the HBH is an issue to itself. expect those packets to be severely rate limited. > > I am wondering why.... if your box cannot handle any headers, just > forward the packet, decreasing the hopcount and that is just. Well, the router is supposed to process the HBH header. And, for some options, if the option in question is not supported, the packet should be dropped -- i.e., you cannot just "ignore the hbh header" (at east in theory). > And if there is a HBH ever that a router should support, then only new > router will support it anyway. > > Disclaimer: this is the model that sixxsd (used for the SixXS PoPs) > does, and it seems to work like a charm; that is, no complaints yet ;) Probably because nobody uses such headers in practice ;-) Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@isi.edu Wed Jun 12 15:04:23 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6F911E8102; Wed, 12 Jun 2013 15:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.021 X-Spam-Level: X-Spam-Status: No, score=-103.021 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYr64FcreaiR; Wed, 12 Jun 2013 15:04:17 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6D35721E8128; Wed, 12 Jun 2013 15:04:13 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r5CM3uUB026186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 15:03:56 -0700 (PDT) Message-ID: <51B8F03E.7080004@isi.edu> Date: Wed, 12 Jun 2013 15:03:42 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ole Troan Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E87C.6010402@isi.edu> <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> In-Reply-To: <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Gert Doering , Robert Elz X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:04:24 -0000 On 6/12/2013 2:36 PM, Ole Troan wrote: > Joe, > >>> an IPv6 router compliant with RFC2460 does not inspect the header chain. >> >> That cannot be true; there are headers after IPv6 but before fragmentation that are hop-by-hop. > > with the exception of the HBH header, correct. I got tired of writing that each time I was repeating myself. > the HBH is an issue to itself. expect those packets to be severely rate limited. There are three such headers that could come before fragmentation. They are (in order): HBH Destination Opts Routing Header The DO is to support RH, e.g., where the DO options are examined at each hop in the RH (it would appear only if RH is present). All of these options have to be copied for fragmentation; you would need to copy everything up to the frag header. Again, RFC 2460 is already clear on this point: The Unfragmentable Part consists of the IPv6 header plus any extension headers that must be processed by nodes en route to the destination, that is, all headers up to and including the Routing header if present, else the Hop-by-Hop Options header if present, else no extension headers. Joe From touch@isi.edu Wed Jun 12 15:07:32 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C3621E80E0; Wed, 12 Jun 2013 15:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.006 X-Spam-Level: X-Spam-Status: No, score=-103.006 tagged_above=-999 required=5 tests=[AWL=-0.407, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9KnRF4AbhY2; Wed, 12 Jun 2013 15:07:26 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6E61011E810E; Wed, 12 Jun 2013 15:07:26 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r5CM6dQX026769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 15:06:40 -0700 (PDT) Message-ID: <51B8F0E1.5090409@isi.edu> Date: Wed, 12 Jun 2013 15:06:25 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jeroen Massar Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E87C.6010402@isi.edu> <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> <51B8EBBA.4000803@massar.ch> In-Reply-To: <51B8EBBA.4000803@massar.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Gert Doering X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:07:32 -0000 On 6/12/2013 2:44 PM, Jeroen Massar wrote: > Unless the router in question knows what that HBH header will do (read: > it was implemented when the definition of that header was defined) or > what it should do with it, it won't be able to do anything with it > anyway. Thus just ignoring/skipping it, heck not parsing any headers at > all, will be quite fine... The only valid way to ignore the HBH header is when all its component options are "00" - skip option if not supported. If you don't check that, then you don't know whether it's valid to ignore the options. That would interfere with the semantics of options defined as "discard" or "discard and inform". Joe From sthaug@nethelp.no Wed Jun 12 15:08:08 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E930921E8143 for ; Wed, 12 Jun 2013 15:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6KjmqyrwAvr for ; Wed, 12 Jun 2013 15:08:03 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 29A6711E8114 for <6man@ietf.org>; Wed, 12 Jun 2013 15:07:51 -0700 (PDT) Received: (qmail 15649 invoked from network); 12 Jun 2013 22:07:50 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 12 Jun 2013 22:07:50 -0000 Date: Thu, 13 Jun 2013 00:07:50 +0200 (CEST) Message-Id: <20130613.000750.78718087.sthaug@nethelp.no> To: fgont@si6networks.com Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) From: sthaug@nethelp.no In-Reply-To: <51B8E35C.3070207@si6networks.com> References: <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, 6man@ietf.org, int-area@ietf.org, touch@isi.edu X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:08:09 -0000 > > However, anything that says "if the chain is >X, then drop" is broken, > > period. > > FWIW, I don't think anyone has proposed "if the chain is larger than X, > then drop". On the other hand - I, as an operator, may well decide to drop such packets. Steinar Haug, AS 2116 From touch@isi.edu Wed Jun 12 15:08:30 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6632411E8115; Wed, 12 Jun 2013 15:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.992 X-Spam-Level: X-Spam-Status: No, score=-102.992 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5-O0TfQzx8e; Wed, 12 Jun 2013 15:08:24 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 89B6A11E8117; Wed, 12 Jun 2013 15:08:15 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r5CM7sVx027001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 15:07:54 -0700 (PDT) Message-ID: <51B8F12C.1040204@isi.edu> Date: Wed, 12 Jun 2013 15:07:40 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Fernando Gont Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8EBCD.7070104@si6networks.com> In-Reply-To: <51B8EBCD.7070104@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Gert Doering X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:08:30 -0000 On 6/12/2013 2:44 PM, Fernando Gont wrote: >> just to be clear I'm not against the IETF documenting e.g. in a BCP, what the longest expected header chain should be. > > Well, that seems more std track than bcp to me. If it's an operational recommendation (SHOULD because that's all that routers are expected to support), then it would be BCP. If you want to prohibit hosts from generating longer chains, that would be std track. Joe From fgont@si6networks.com Wed Jun 12 15:10:23 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F58E21F942B; Wed, 12 Jun 2013 15:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qULY8yFc3PUd; Wed, 12 Jun 2013 15:10:22 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9801321F8624; Wed, 12 Jun 2013 15:10:22 -0700 (PDT) Received: from [2001:5c0:1400:a::323] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmtF5-0004G1-2h; Thu, 13 Jun 2013 00:10:11 +0200 Message-ID: <51B8F1C1.3000400@si6networks.com> Date: Thu, 13 Jun 2013 00:10:09 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ole Troan Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8EBCD.7070104@si6networks.com> <24AA8E8A-B173-4BD1-99D6-7BB7B9008142@employees.org> In-Reply-To: <24AA8E8A-B173-4BD1-99D6-7BB7B9008142@employees.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:10:23 -0000 Hi, Ole, On 06/12/2013 11:53 PM, Ole Troan wrote: >> IIRC, someone reported that Cisco ASA drop v6 packets with extension >> headers by default..... > > I think you'll find that the Cisco ASA isn't marketed as a router either, it is a firewall. Agreed. >>> just to be clear I'm not against the IETF documenting e.g. in a BCP, what the longest expected header chain should be. >> >> Well, that seems more std track than bcp to me. > > I don't think we should encode in standard a number that is based on the ability of current hardware. > nor do I think we have any standard documents describing the behaviour of filtering routers / firewalls / middleboxes in this respect. Does it make any sense to tell people that they can send packets when we really know that there's no way they are going to get to their intended destination? Some random folks, for some reason, starts sending those packets. He's packets miserably die in the network. He comes to us, and we all say "oh yeah... they are being dropped.. we know that". And the folk asks us "why didn't you say so?". When standards diverge so much from reality, that's no good, IMHO. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From otroan@employees.org Wed Jun 12 15:12:52 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0161221E8087; Wed, 12 Jun 2013 15:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrCKxFfEnBPm; Wed, 12 Jun 2013 15:12:46 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id ABB9711E8102; Wed, 12 Jun 2013 15:12:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANXxuFGQ/khL/2dsb2JhbABaDoJ7v0SBARZ0giQBBXkQC0ZXBoghuymOC4EFMweCf2EDk26VFIFYeUA6gSw X-IronPort-AV: E=Sophos;i="4.87,854,1363132800"; d="scan'208";a="14658698" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 12 Jun 2013 22:12:33 +0000 Received: from dhcp-10-61-111-244.cisco.com (dhcp-10-61-111-244.cisco.com [10.61.111.244]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5CMCUxB006890 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Jun 2013 22:12:31 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) From: Ole Troan In-Reply-To: <51B8F03E.7080004@isi.edu> Date: Thu, 13 Jun 2013 00:12:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E87C.6010402@isi.edu> <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> <51B8F03E.7080004@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1508) Cc: IPv6 Operations , 6man@ietf.org, Gert Doering , Robert Elz X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:12:52 -0000 Joe, >>>> an IPv6 router compliant with RFC2460 does not inspect the header = chain. >>>=20 >>> That cannot be true; there are headers after IPv6 but before = fragmentation that are hop-by-hop. >>=20 >> with the exception of the HBH header, correct. I got tired of writing = that each time I was repeating myself. >> the HBH is an issue to itself. expect those packets to be severely = rate limited. >=20 > There are three such headers that could come before fragmentation. = They are (in order): > =09 > HBH > Destination Opts > Routing Header >=20 > The DO is to support RH, e.g., where the DO options are examined at = each hop in the RH (it would appear only if RH is present). >=20 > All of these options have to be copied for fragmentation; you would = need to copy everything up to the frag header. >=20 > Again, RFC 2460 is already clear on this point: >=20 > The Unfragmentable Part consists of the IPv6 header plus any > extension headers that must be processed by nodes en route to the > destination, that is, all headers up to and including the Routing > header if present, else the Hop-by-Hop Options header if present, > else no extension headers. that's quite a different case. with source routing the packet is = destined to the router itself. also note that RH0 is deprecated. cheers, Ole= From fgont@si6networks.com Wed Jun 12 15:18:55 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B2121F99BE; Wed, 12 Jun 2013 15:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVbs9Jpd9JkL; Wed, 12 Jun 2013 15:18:55 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 512C921F99B7; Wed, 12 Jun 2013 15:18:48 -0700 (PDT) Received: from [2001:5c0:1400:a::323] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmtNC-0005FH-8C; Thu, 13 Jun 2013 00:18:34 +0200 Message-ID: <51B8F3B9.40406@si6networks.com> Date: Thu, 13 Jun 2013 00:18:33 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: sthaug@nethelp.no Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> <20130613.000750.78718087.sthaug@nethelp.no> In-Reply-To: <20130613.000750.78718087.sthaug@nethelp.no> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, 6man@ietf.org, int-area@ietf.org, touch@isi.edu X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:18:56 -0000 On 06/13/2013 12:07 AM, sthaug@nethelp.no wrote: >>> However, anything that says "if the chain is >X, then drop" is broken, >>> period. >> >> FWIW, I don't think anyone has proposed "if the chain is larger than X, >> then drop". > > On the other hand - I, as an operator, may well decide to drop such > packets. Agreed. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Wed Jun 12 15:19:36 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E43C21E80DC; Wed, 12 Jun 2013 15:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6auiTo79WaWZ; Wed, 12 Jun 2013 15:19:36 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id CBAC821E8064; Wed, 12 Jun 2013 15:19:35 -0700 (PDT) Received: from [2001:5c0:1400:a::323] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmtO6-0005ME-UJ; Thu, 13 Jun 2013 00:19:31 +0200 Message-ID: <51B8F3F2.2060707@si6networks.com> Date: Thu, 13 Jun 2013 00:19:30 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Joe Touch Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8EBCD.7070104@si6networks.com> <51B8F12C.1040204@isi.edu> In-Reply-To: <51B8F12C.1040204@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Gert Doering X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:19:36 -0000 On 06/13/2013 12:07 AM, Joe Touch wrote: > > On 6/12/2013 2:44 PM, Fernando Gont wrote: >>> just to be clear I'm not against the IETF documenting e.g. in a BCP, >>> what the longest expected header chain should be. >> >> Well, that seems more std track than bcp to me. > > If it's an operational recommendation (SHOULD because that's all that > routers are expected to support), then it would be BCP. > > If you want to prohibit hosts from generating longer chains, that would > be std track. I want to recommend hosts not to send such packets. Hence it looks like std track. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From v6ops@globis.net Wed Jun 12 15:22:19 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E1221E805F; Wed, 12 Jun 2013 15:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pCxkhDBEl9K; Wed, 12 Jun 2013 15:22:17 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id A428D21E8064; Wed, 12 Jun 2013 15:22:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id A5871870077; Thu, 13 Jun 2013 00:22:00 +0200 (CEST) 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 hsZelgKGR-4B; Thu, 13 Jun 2013 00:22:00 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 7EFBE870002; Thu, 13 Jun 2013 00:22:00 +0200 (CEST) Message-ID: <51B8F482.3020204@globis.net> Date: Thu, 13 Jun 2013 00:21:54 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <51B6876A.9020202@si6networks.com> <51B8DE89.2040004@gmail.com> In-Reply-To: <51B8DE89.2040004@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:22:19 -0000 Brian E Carpenter wrote: > On 12/06/2013 11:58, Sander Steffann wrote: >> Hi, >> >>> My question to th wg is: >>> >>> 1) Do we want to limit the size of the IPv6 header chain? >> I think it is necessary yes. >> >>> 2) If so, which limit should we pick? >> I think there are two conditions here: >> - The full layer-4 header must be within this limit, and it must be in the first fragment (if fragmented at all) >> - The limit should be larger than what is currently used + some margin for stuff we forgot >> >> Take i.e. Figure 3 of http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html as example. It shows a Mobile-IPv6 packet: IPv6 header (40 octets) + Routing header (24 octets) + Destination Options header (24 octets) + Fragmentation header (8 octets). Add to that a basic TCP header (20 octets) and we arrive at 116 octets. >> >> So a limit of 128 would currently probably be ok, but I personally would prefer the limit to be a bit higher just to have some extra margin. > > I think we should advocate 256 as a target for hardware designers; we know that > some of them have current hardware limits less than that, but a "SHOULD inspect 256" > seems reasonable (and conversely, a "SHOULD NOT exceed 256" for hosts generating > IPv6 packets). > > Given time (as somebody said, maybe ten years) this would palliate the > problem. > > Brian Whilst I agree we need to take steps to simplify the problem, I'd like some feedback from hardware manufacturers either publicly or privately whether this limit is sufficient on its own. If the packet parser/ forwarding engine is implemented as a byte code machine, it's the attacker who controls what code is executed. 200+ bytes of extension header opcodes could probably still be crafted with a combination of enough pad1's and useful options to tie up around a couple of hundred byte-code-machine cycles before the last option can be processed, whilst also disrupting any prefetch or pipelining optimisations. Then there's almost certainly a direct link between the clock rate of the packet parsing engine and the all important packets per second marketing number. My gut feeling is that we also need to provide more opportunities for parallel processing. regards, RayH From warren@kumari.net Wed Jun 12 15:26:32 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CBE21E8064; Wed, 12 Jun 2013 15:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmZQ1aPMl4i8; Wed, 12 Jun 2013 15:26:27 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2312011E8119; Wed, 12 Jun 2013 15:26:26 -0700 (PDT) Received: from [192.168.6.179] (ip-64-134-41-42.public.wayport.net [64.134.41.42]) by vimes.kumari.net (Postfix) with ESMTPSA id 9DCF41B401CE; Wed, 12 Jun 2013 18:26:24 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [6MAN] Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) From: Warren Kumari In-Reply-To: <10707.1371062690@perseus.noi.kre.to> Date: Wed, 12 Jun 2013 18:26:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6FAE3DF4-B5B4-4F21-9098-761523745CC3@kumari.net> References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> To: Robert Elz X-Mailer: Apple Mail (2.1503) Cc: Internet Area , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:26:32 -0000 On Jun 12, 2013, at 2:44 PM, Robert Elz wrote: > Date: Wed, 12 Jun 2013 19:49:08 +0200 > From: Gert Doering > Message-ID: <20130612174908.GT2504@Space.Net> >=20 > | Loop back to about 50 messages earlier in this thread, >=20 > I don't generally read this list (any more) - just happened to see the > past hour's worth of messages, so I have no idea what was 50 messages > earlier, but ... >=20 > | We're not talking ivory tower theoretical routers. We're talking = about > | devices that can stand the heat out there, like "be able to apply = different > | rate limiting classes to incoming BGP SYNs from trusted networks, = and to > | ICMP packets from the world". This MUST be done by the hardware, = and it > | MUST be able to look at *Layer 4* information. >=20 > If that's the issue, then the routers should just be treating any = packet with > a frag header like dirt. =20 You mean like: http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-01 = ? Seeing as I filter on routers (which don't do reassembly) and I want to = know what's actually in the packets I let into my network, they just get = dropped on the floor. Ain't nobody noticed, so, if it ain't broke=85 W > That's what they deserve. Lowest sched priority, > and most likely to be dropped. That's easy to accomplish in hardware = (well > as easy as anything else that involves looking down header chains)=20 > and perfectly acceptable - everyone knows that if one sends fragmented = packets > performance goes out the window. Perfectly acceptable result, and no > changes at all to v6 specs are needed to get to that. >=20 > On the other hand, if the real issue is firewalls, then there really = should be > no issue at all - firewalls already need to be able to reassemble = packet > chains, or they can't look inside TCP properly (as while no-one sane > would ever split tcp segments in weird places, hackers will if the = firewalls > can't handle it properly). Reassembling IP frags is childs play = compared > to reassembling tcp segments. >=20 > Again, no need to change anything in the IPv6 specs. >=20 > Lastly, this comment caught my eye ... >=20 > fgont@si6networks.com said: > | It doesn't change how fragmentation works. It just clarifies a = corner case > | which was allowed by the standard, but is not employed in practice, = and none > | expected to happen.=20 >=20 > Huh? Is that really claimimng that no-one ever thought that the frag > header would be anywhere but last in the header chain? That would be > absurd. For one, in normal use, dest options should normally come > after a frag header, processing them before the packet is reassembled = would > mean processing them before the packet is received correctly, which = would be > 100% bogus (on the other hand, if options were even invented to allow = the > sender some control over reassembly - perhaps to lower timeouts or = something - > then a destopts header before the frag header would be rational.) >=20 > Beyond that, I have had cases where a frag header before a routing = header > made perfect sense - I know that routing headers are largely = deprecated these > days, but before that, it was possible to send a fragmented packet = over a > low MTU link, have it reassembled at the far side of that link, and = then > the routing header (following the frag header) causes the packet to = continue > over links with a larger MTU, so the penalties of fragmentation apply > only where they are really needed. What's more, for the remaining = use of > routing headers (route opt for mobile IPv6) putting the frag header = before > the routing header is also the sane way to run things (the routing = header there > is really just a fancy destination option). >=20 > Lastly, consider that most v6 headers are allowed to be larger than = the > MTU of the most common links in the internet at the time (and for that > matter, still) and certainly larger than the required MTU for v6 = links, and > ask yourself how that would make any sense at all if all headers are > required to be before the frag header. >=20 > Leave the specs alone, header chanins can have headers (other than hop = by > hop opts of course) in whatever order makes sense to the application = that > needs to send those headers. No more rules. Just deal with it. >=20 > kre >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -- After you'd known Christine for any length of time, you found yourself = fighting a desire to look into her ear to see if you could spot daylight = coming the other way. -- (Terry Pratchett, Maskerade) From touch@isi.edu Wed Jun 12 15:26:48 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0124811E811A; Wed, 12 Jun 2013 15:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.979 X-Spam-Level: X-Spam-Status: No, score=-102.979 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yvv1j2qoxhps; Wed, 12 Jun 2013 15:26:42 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF3B11E8119; Wed, 12 Jun 2013 15:26:42 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r5CMQAqK000374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 15:26:10 -0700 (PDT) Message-ID: <51B8F574.5000100@isi.edu> Date: Wed, 12 Jun 2013 15:25:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Fernando Gont Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8EBCD.7070104@si6networks.com> <51B8F12C.1040204@isi.edu> <51B8F3F2.2060707@si6networks.com> In-Reply-To: <51B8F3F2.2060707@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Gert Doering X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:26:48 -0000 On 6/12/2013 3:19 PM, Fernando Gont wrote: > On 06/13/2013 12:07 AM, Joe Touch wrote: >> >> On 6/12/2013 2:44 PM, Fernando Gont wrote: >>>> just to be clear I'm not against the IETF documenting e.g. in a BCP, >>>> what the longest expected header chain should be. >>> >>> Well, that seems more std track than bcp to me. >> >> If it's an operational recommendation (SHOULD because that's all that >> routers are expected to support), then it would be BCP. >> >> If you want to prohibit hosts from generating longer chains, that would >> be std track. > > I want to recommend hosts not to send such packets. Hence it looks like > std track. Telling them they SHOULD NOT is BCP. It's a configuration, and it's compliant with the existing standard AFAICT, so since it's not a change per se it wouldn't be a STD. Joe From fgont@si6networks.com Wed Jun 12 15:37:38 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011DD21E80E4; Wed, 12 Jun 2013 15:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uKB196Wj+ni; Wed, 12 Jun 2013 15:37:37 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 756B911E811D; Wed, 12 Jun 2013 15:37:36 -0700 (PDT) Received: from [2001:5c0:1400:a::323] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmtfV-000657-IG; Thu, 13 Jun 2013 00:37:29 +0200 Message-ID: <51B8F828.1080304@si6networks.com> Date: Thu, 13 Jun 2013 00:37:28 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Joe Touch Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8EBCD.7070104@si6networks.com> <51B8F12C.1040204@isi.edu> <51B8F3F2.2060707@si6networks.com> <51B8F574.5000100@isi.edu> In-Reply-To: <51B8F574.5000100@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Gert Doering X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:37:38 -0000 On 06/13/2013 12:25 AM, Joe Touch wrote: >> I want to recommend hosts not to send such packets. Hence it looks like >> std track. > > Telling them they SHOULD NOT is BCP. It's a configuration, and it's > compliant with the existing standard AFAICT, so since it's not a change > per se it wouldn't be a STD. It's not configuration -- after all, it's the apps that are supposed to select which options they include. The current std allows for arbitrary lengths of the header chain. And we want to say "The header chain should be up to X bytes, because otherwise interoperability will be affected". Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From warren@kumari.net Wed Jun 12 15:45:27 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0811C11E80F8; Wed, 12 Jun 2013 15:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-OUu90-XjZu; Wed, 12 Jun 2013 15:45:09 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10E711E8114; Wed, 12 Jun 2013 15:45:09 -0700 (PDT) Received: from [192.168.6.179] (ip-64-134-41-42.public.wayport.net [64.134.41.42]) by vimes.kumari.net (Postfix) with ESMTPSA id 7F5C01B401CE; Wed, 12 Jun 2013 18:45:08 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [6MAN] Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) From: Warren Kumari In-Reply-To: <20130613.000750.78718087.sthaug@nethelp.no> Date: Wed, 12 Jun 2013 18:45:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6759493F-9B2E-4B1C-83BB-32D54E1822C6@kumari.net> References: <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> <20130613.000750.78718087.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.1503) Cc: v6ops@ietf.org, 6man@ietf.org, int-area@ietf.org, touch@isi.edu, fgont@si6networks.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:45:27 -0000 On Jun 12, 2013, at 6:07 PM, sthaug@nethelp.no wrote: >>> However, anything that says "if the chain is >X, then drop" is = broken, >>> period. >>=20 >> FWIW, I don't think anyone has proposed "if the chain is larger than = X, >> then drop". >=20 > On the other hand - I, as an operator, may well decide to drop such > packets. And, presumably, you as an operator are likely to also have something = like: filter AllowExpected { term web { from { destination-address { 2001:db8::100/128; } next-header tcp; destination-port [ http https ]; } then accept; } term example { from { destination-address { 2001:db8::123/128; } next-header udp; destination-port 17; } then accept; } term default { then { count default-deny; discard; } } } If the router cannot see the L4 header (because it has not sucked enough = bytes up to the filtering widget) you'd expect it to hit the "default" = term, I presume (I sure would!) This has accomplishes the same thing (unless you've decided to choose a = smaller number than the filtering logic supports). W BTW: Who added every basically single IETF list to this thread? >=20 > Steinar Haug, AS 2116 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -- After you'd known Christine for any length of time, you found yourself = fighting a desire to look into her ear to see if you could spot daylight = coming the other way. -- (Terry Pratchett, Maskerade) From wesley.george@twcable.com Wed Jun 12 16:22:47 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B9B11E80FD for ; Wed, 12 Jun 2013 16:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.027 X-Spam-Level: X-Spam-Status: No, score=0.027 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ85PcHbxkal for ; Wed, 12 Jun 2013 16:22:42 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 00A1911E8112 for ; Wed, 12 Jun 2013 16:22:41 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.87,855,1363147200"; d="scan'208,217";a="92510046" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 12 Jun 2013 19:22:15 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Wed, 12 Jun 2013 19:22:40 -0400 From: "George, Wes" To: Nalini Elkins Date: Wed, 12 Jun 2013 19:22:41 -0400 Subject: RE: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) Thread-Topic: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: draft-ietf-6man-ext-transmit-01) Thread-Index: Ac5l6tK1sweePmpfSeSR11wYhPur4wB1318A Message-ID: <2671C6CDFBB59E47B64C10B3E0BD592304344F345F@PRVPEXVS15.corp.twcable.com> References: <51B0B581.7020203@globis.net> <1370535649.98609.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <51B0EC7B.1090904@si6networks.com> <51B0EED6.6020200@bogus.com> <51B0F3E6.4010006@globis.net> <51B2F59A.3090003@bogus.com> <51B31034.2020903@globis.net> <51B4872B.8000505@si6networks.com> <51B4FD31.1000703@gmail.com> <51B56692.4030101@bogus.com> <1370873399.18459.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <51B5E3F7.1050105@bogus.com> <1370876192.70632.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> In-Reply-To: <1370876192.70632.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2671C6CDFBB59E47B64C10B3E0BD592304344F345FPRVPEXVS15cor_" MIME-Version: 1.0 Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 23:22:47 -0000 --_000_2671C6CDFBB59E47B64C10B3E0BD592304344F345FPRVPEXVS15cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Nal= ini Elkins I suppose what I am thinking is that since there are no "IETF Police", then= the only "teeth" there are in the standards is the ability to say "this is= not compliant". That is not a trivial thing. People pay attention to tha= t. [WEG] The IETF doesn't do compliance testing either. The only teeth in any = IETF standard is you as a customer telling a vendor that they must support = a set of IETF standards (that you explicitly define by giving them a list),= and then doing your own testing to ensure that it meets your requirements,= and not buying it or requiring fixes from said vendor if it fails your tes= ts because it didn't implement the standard completely or correctly. Wes George ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_2671C6CDFBB59E47B64C10B3E0BD592304344F345FPRVPEXVS15cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    From: ipv6-bou= nces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Nalini Elkins

     

    I suppose what I am thinking is that since there are no "IETF Polic= e", then the only "teeth" there are in the standards is the = ability to say "this is not compliant".  That is not a trivi= al thing.  People pay attention to that.<= /p>

     

    [WEG] The IETF doesn’t do complia= nce testing either. The only teeth in any IETF standard is you as a custome= r telling a vendor that they must support a set of IETF standards (that you explicitly define by giving them a list), and then doing your ow= n testing to ensure that it meets your requirements, and not buying it or r= equiring fixes from said vendor if it fails your tests because it didn̵= 7;t implement the standard completely or correctly.

    This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
    --_000_2671C6CDFBB59E47B64C10B3E0BD592304344F345FPRVPEXVS15cor_-- From touch@isi.edu Wed Jun 12 17:00:23 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC1811E8114; Wed, 12 Jun 2013 17:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.967 X-Spam-Level: X-Spam-Status: No, score=-102.967 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RoQXAuVVDLC; Wed, 12 Jun 2013 17:00:17 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7036D11E811A; Wed, 12 Jun 2013 17:00:15 -0700 (PDT) Received: from [128.9.184.156] ([128.9.184.156]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r5CNxiuS019954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 16:59:44 -0700 (PDT) Message-ID: <51B90B76.40007@isi.edu> Date: Wed, 12 Jun 2013 16:59:50 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Warren Kumari Subject: Re: [6MAN] Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> <20130613.000750.78718087.sthaug@nethelp.no> <6759493F-9B2E-4B1C-83BB-32D54E1822C6@kumari.net> In-Reply-To: <6759493F-9B2E-4B1C-83BB-32D54E1822C6@kumari.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: fgont@si6networks.com, v6ops@ietf.org, 6man@ietf.org, int-area@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 00:00:23 -0000 FWIW, I added INTAREA, because I don't consider potentially killing off IPv6 header extensions as merely maintenance (6man) or operational (v6ops). Joe On 6/12/2013 3:45 PM, Warren Kumari wrote: > BTW: Who added every basically single IETF list to this thread? From fgont@si6networks.com Wed Jun 12 17:15:25 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091ED21F9986; Wed, 12 Jun 2013 17:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9ncHtiCFlWz; Wed, 12 Jun 2013 17:15:24 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 4146F21F9981; Wed, 12 Jun 2013 17:15:23 -0700 (PDT) Received: from [2001:5c0:1400:a::1bd] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UmvC0-0008Mi-BK; Thu, 13 Jun 2013 02:15:08 +0200 Message-ID: <51B90F0B.9050603@si6networks.com> Date: Thu, 13 Jun 2013 02:15:07 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Joe Touch Subject: Re: [6MAN] Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> <20130613.000750.78718087.sthaug@nethelp.no> <6759493F-9B2E-4B1C-83BB-32D54E1822C6@kumari.net> <51B90B76.40007@isi.edu> In-Reply-To: <51B90B76.40007@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: int-area@ietf.org, v6ops@ietf.org, 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 00:15:25 -0000 On 06/13/2013 01:59 AM, Joe Touch wrote: > FWIW, I added INTAREA, because I don't consider potentially killing off > IPv6 header extensions as merely maintenance (6man) or operational (v6ops). We're trying to do exactly the opposite: try to define under which constraints we can expect them to work. If we continue on the current path (do nothing), they will be effectively killed. (see Brian et al's I-D, Warren et al's I-D, etc.). Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From marka@isc.org Wed Jun 12 19:07:49 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C85211E8106; Wed, 12 Jun 2013 19:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGjaZL-TgJCJ; Wed, 12 Jun 2013 19:07:47 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id E16C111E8114; Wed, 12 Jun 2013 19:07:46 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 3DDC3C9530; Thu, 13 Jun 2013 02:07:38 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1371089266; bh=eXa0juQI5PendGtdGSKdEG/116sb0o+db5OKQo+nAhM=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=bGs1KRbiqbn3YRJ1rgF4VkC4Qna+mLXzJesR9Zj3pKXxy0ErH+lEWetGj9u38CiYn 3IHXI5eKTobNOxwYQV/1x7fcgl4NdDqEDBh3d/HSjZehmbL+SlMno4t/2ezvhAxMVH 8BPuep3AS+R7l87EGv3A53DsPOS9iNekF8JERXEk= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Thu, 13 Jun 2013 02:07:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:e980:38d3:9f1c:e9ba]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 3F505216C4B; Thu, 13 Jun 2013 02:07:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 7F7B535D3BA9; Thu, 13 Jun 2013 12:07:17 +1000 (EST) To: Warren Kumari From: Mark Andrews References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <6FAE3DF4-B5B4-4F21-9098-761523745CC3@kumari.net> Subject: Re: [v6ops] [6MAN] Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) In-reply-to: Your message of "Wed, 12 Jun 2013 18:26:23 -0400." <6FAE3DF4-B5B4-4F21-9098-761523745CC3@kumari.net> Date: Thu, 13 Jun 2013 12:07:17 +1000 Message-Id: <20130613020717.7F7B535D3BA9@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 02:07:49 -0000 In message <6FAE3DF4-B5B4-4F21-9098-761523745CC3@kumari.net>, Warren Kumari writes: > > On Jun 12, 2013, at 2:44 PM, Robert Elz wrote: > > > Date: Wed, 12 Jun 2013 19:49:08 +0200 > > From: Gert Doering > > Message-ID: <20130612174908.GT2504@Space.Net> > > = > > > | Loop back to about 50 messages earlier in this thread, > > = > > > I don't generally read this list (any more) - just happened to see the > > past hour's worth of messages, so I have no idea what was 50 messages > > earlier, but ... > > = > > > | We're not talking ivory tower theoretical routers. We're talking about > > | devices that can stand the heat out there, like "be able to apply diffe= > rent > > | rate limiting classes to incoming BGP SYNs from trusted networks, and to > > | ICMP packets from the world". This MUST be done by the hardware, and it > > | MUST be able to look at *Layer 4* information. > > = > > > If that's the issue, then the routers should just be treating any packet = > with > > a frag header like dirt. = > > > You mean like: http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-01 ? > > Seeing as I filter on routers (which don't do reassembly) and I want to kno= > w what's actually in the packets I let into my network, they just get dropp= > ed on the floor. > Ain't nobody noticed, so, if it ain't broke=85 > > W Don't take lack of complaints as "nobody noticed". If you want complaints then nameserver vendors can remove the code which tries you handle your broken routers. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From arturo.servin@gmail.com Wed Jun 12 19:54:55 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FDC21F999E; Wed, 12 Jun 2013 19:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bktuD3PbSiFp; Wed, 12 Jun 2013 19:54:54 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 09F4C21F8B21; Wed, 12 Jun 2013 19:54:53 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id v1so1133007yhn.22 for ; Wed, 12 Jun 2013 19:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=oAXi674Z6DHpxm0khuXLXF33wlDsKs6yXZM7P6wu1/M=; b=upUvvwk1158y90gyWxmIioFXCMHv6tru4nZ+LCTAxqCebkc7NO5/36cON5ogDpSIzN Bk6rQQ2Qk3Jd2pGNoii8izSUnIPJp6O4zLQm7mpf01ofDBTCVP3ZPS7sdUs6bU2guq9a 1o8wm/0VRIlsG9vcyljEFGq2KI2agSoLdZQzlvFRJVzn8khlFblTa5fP1m+rjdpl9gs0 f4T1qIND7sfwfG+Lus2ohecICgrK8QCC/j1x+3D98aYwguPXvNw5+8HsTX3NdUYBgk6u ibCq6g35s0uQ0YggXU6pFErsGQPtLvmJ9aR/vUpcpwtBSLYfDIPSf9MLoa86Eiiyzq7T jV8w== X-Received: by 10.236.60.134 with SMTP id u6mr9664777yhc.40.1371092093391; Wed, 12 Jun 2013 19:54:53 -0700 (PDT) Received: from Arturos-MacBook-Pro.local ([190.186.17.178]) by mx.google.com with ESMTPSA id q70sm31492462yhg.14.2013.06.12.19.54.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Jun 2013 19:54:52 -0700 (PDT) Message-ID: <51B9347D.3060207@gmail.com> Date: Wed, 12 Jun 2013 22:54:53 -0400 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ray Hunter Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <51B6876A.9020202@si6networks.com> <51B8DE89.2040004@gmail.com> <51B8F482.3020204@globis.net> In-Reply-To: <51B8F482.3020204@globis.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 02:54:55 -0000 Agreed. Let's ask some "running code" people some input about the practical constraints. /as On 6/12/13 6:21 PM, Ray Hunter wrote: >>> So a limit of 128 would currently probably be ok, but I personally would prefer the limit to be a bit higher just to have some extra margin. >> > >> > I think we should advocate 256 as a target for hardware designers; we know that >> > some of them have current hardware limits less than that, but a "SHOULD inspect 256" >> > seems reasonable (and conversely, a "SHOULD NOT exceed 256" for hosts generating >> > IPv6 packets). >> > >> > Given time (as somebody said, maybe ten years) this would palliate the >> > problem. >> > >> > Brian > > Whilst I agree we need to take steps to simplify the problem, I'd like > some feedback from hardware manufacturers either publicly or privately > whether this limit is sufficient on its own. From brian.e.carpenter@gmail.com Wed Jun 12 22:16:16 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7A221F99C3; Wed, 12 Jun 2013 22:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoKIDZ4OioG8; Wed, 12 Jun 2013 22:16:16 -0700 (PDT) Received: from mail-gh0-x22c.google.com (mail-gh0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B7DF721F99B6; Wed, 12 Jun 2013 22:16:15 -0700 (PDT) Received: by mail-gh0-f172.google.com with SMTP id r18so1286008ghr.3 for ; Wed, 12 Jun 2013 22:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ivQOS2qgOYxhSjTfKQZFfL7MepyHJAJ9BwHdIM3DQHA=; b=HBuP5dKHlGT7eseBZSIPO/FFeLkiNRz8NRUOzsR9ei2JJlQORTJpjZRFkz80Q0eKJ4 Ri/FSKlpwsIiuwUXrLHSK5Ckmjx7KQMo6jpx6wGuSLrk6F0sFT72sHDwqeSvAPbWmkdO tHNf3WMcXSepsB4wsoWfHt1l5sxmTLiRxU5BtUl8iKFSZRCjAPtoBElHfmxNU3LMhMR/ +eM3CaSQdY6+um5VhFku2OGaZVXOrQJt5S6zwnO873J5xJ1CIXtzl9NPO9ZKgoNLx1A3 MZqKtO+BB302tkrMXBOtkCChzM1pgSMnjXScapqzUo/OMrkDzD4REZNLY0RlngdnxOx6 8kYw== X-Received: by 10.236.30.134 with SMTP id k6mr7754818yha.125.1371100575328; Wed, 12 Jun 2013 22:16:15 -0700 (PDT) Received: from [192.168.1.2] (153.235.252.27.dyn.cust.vf.net.nz. [27.252.235.153]) by mx.google.com with ESMTPSA id b50sm32223527yhl.1.2013.06.12.22.16.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Jun 2013 22:16:14 -0700 (PDT) Message-ID: <51B955A3.7040907@gmail.com> Date: Thu, 13 Jun 2013 17:16:19 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E87C.6010402@isi.edu> <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> <51B8EBBA.4000803@massar.ch> <51B8F0E1.5090409@isi.edu> In-Reply-To: <51B8F0E1.5090409@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations , Internet Area X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 05:16:16 -0000 On 13/06/2013 10:06, Joe Touch wrote: > > > On 6/12/2013 2:44 PM, Jeroen Massar wrote: >> Unless the router in question knows what that HBH header will do (read: >> it was implemented when the definition of that header was defined) or >> what it should do with it, it won't be able to do anything with it >> anyway. Thus just ignoring/skipping it, heck not parsing any headers at >> all, will be quite fine... > > The only valid way to ignore the HBH header is when all its component > options are "00" - skip option if not supported. > > If you don't check that, then you don't know whether it's valid to > ignore the options. That would interfere with the semantics of options > defined as "discard" or "discard and inform". Reality check: high speed routers don't look at HbH options. Your best hope is that they throw them on a slow path, but not all designs have a slow path. If you are designing a HbH option, you'd better assume that some routers will ignore it. On 13/06/2013 10:21, Ray Hunter wrote: >> I think we should advocate 256 as a target for hardware designers; we know that >> > some of them have current hardware limits less than that, but a "SHOULD inspect 256" >> > seems reasonable (and conversely, a "SHOULD NOT exceed 256" for hosts generating >> > IPv6 packets). >> > >> > Given time (as somebody said, maybe ten years) this would palliate the >> > problem. >> > >> > Brian > > > Whilst I agree we need to take steps to simplify the problem, I'd like > some feedback from hardware manufacturers either publicly or privately > whether this limit is sufficient on its own. I'm pretty sure that it isn't; it's a starting point for digging out of the hole, because it bounds one aspect of the problem. Brian (cross-posting with reluctance) From jeroen@massar.ch Thu Jun 13 00:02:51 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F9421F991E; Thu, 13 Jun 2013 00:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dsfdk8DxIfz; Thu, 13 Jun 2013 00:02:46 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [78.47.209.234]) by ietfa.amsl.com (Postfix) with ESMTP id A6C0A21F9798; Thu, 13 Jun 2013 00:02:41 -0700 (PDT) Received: from kami.ch.unfix.org (unknown [IPv6:2001:559:8000:c9:7256:81ff:fea5:2925]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id B8669801C2BA; Thu, 13 Jun 2013 09:02:19 +0200 (CEST) Message-ID: <51B96E7B.8010706@massar.ch> Date: Thu, 13 Jun 2013 00:02:19 -0700 From: Jeroen Massar Organization: Massar User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Fernando Gont Subject: Re: Discussion about header chains (was Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)) References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E87C.6010402@isi.edu> <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> <51B8EBBA.4000803@massar.ch> <51B8EEEE.8000400@gont.com.ar> In-Reply-To: <51B8EEEE.8000400@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Joe Touch X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 07:02:51 -0000 On 2013-06-12 14:58, Fernando Gont wrote: > Jeroen, > > On 06/12/2013 11:44 PM, Jeroen Massar wrote: >>> with the exception of the HBH header, correct. I got tired of writing that each time I was repeating myself. >>> the HBH is an issue to itself. expect those packets to be severely rate limited. >> >> I am wondering why.... if your box cannot handle any headers, just >> forward the packet, decreasing the hopcount and that is just. > > Well, the router is supposed to process the HBH header. According to the spec, yes, but does it make sense? See more below. (note that must is not written in capitols in 2460 btw ;) > And, for some > options, if the option in question is not supported, the packet should > be dropped -- i.e., you cannot just "ignore the hbh header" (at east in > theory). Why not? Is there any HBH header that is crucial for operation of IPv6? It might be in the RFC, does not mean it is actually needed ;) On 2013-06-12 15:06, Joe Touch wrote: > [..] > The only valid way to ignore the HBH header is when all its component > options are "00" - skip option if not supported. None of the variants will ever catch on/make sense unless one can do a full network upgrade to support that special option. And unless one can upgrade the whole Internet (or at least the network your packets travel over), the only useful one is ignore, the others are futile unless one wants to probe which boxes support that feature, which would thus allow fingerprinting of the age of the stack. > If you don't check that, then you don't know whether it's valid to > ignore the options. That would interfere with the semantics of options > defined as "discard" or "discard and inform". But ignoring them, allows any box that does implement the option to actually process them. If something uses the 'discard' ones, it would require the whole network to be upgraded in one go, and that is not ever going to happen. Thus either one does that upgrade or one never specifies discard and then ignoring is perfect IMHO. Greets, Jeroen (hmmm should have had this whole discussion the previous week, as then I could have asked Bob Hinden what the real intent behind all of this was upto at least this morning ;) From randy@psg.com Thu Jun 13 01:18:02 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0AD21F999B; Thu, 13 Jun 2013 01:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+VexB72mdGR; Thu, 13 Jun 2013 01:18:02 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 586B921F8EDF; Thu, 13 Jun 2013 01:18:01 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Un2jH-00006g-5n; Thu, 13 Jun 2013 08:17:59 +0000 Date: Thu, 13 Jun 2013 10:17:55 +0200 Message-ID: From: Randy Bush To: Fernando Gont Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) In-Reply-To: <51B8E35C.3070207@si6networks.com> References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: Internet Area , IPv6 Operations , IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 08:18:02 -0000 > FWIW, I don't think anyone has proposed "if the chain is larger than X, > then drop". i am saying that i am telling my neighbor that, if the header length is larger than X, it is likely that their packet will not propagate. it's an ops bcp statement, not a statement of ipv6 protocol definition. same as telling them that a bgp announcement of a prefix longer than a /24 likely will not propagete. today, real routers really do drop packets with headers longer than various limits. as an op, i am trying to remove the surpeise in the 'various'. randy From cb.list6@gmail.com Thu Jun 13 06:27:30 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573D421F8F33; Thu, 13 Jun 2013 06:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KJfrWJ29qr6; Thu, 13 Jun 2013 06:27:29 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAC121F8EC3; Thu, 13 Jun 2013 06:27:28 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id m6so1549085wiv.3 for ; Thu, 13 Jun 2013 06:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wEi7kAW0z67pVzxwA6R3ktR881uQueGu61NQetvMukg=; b=kklL8h0RrLJRCjJ8DiznCKK/eKzYlWkyGqiCxpVu83q8RNqS/fhltI6ItGErHEVZZv nWtWxiDqO5jGUSyIPxr12Pm83ZoC2Noq+QKfubkKbZYAwg0G1/35g9jV4ELQsMm/pYls tNHm/1S8vAdxEs3Smsz5GNqrwIamrNAbn9op5SuU2G8CbYtqIe0CBjI9zTE+NJFnBhQu KauDWCjyPmbXJlV4+uEUM4P8+hMyXL33BfYp0J5cszbesL+WoVBisrK9si9k2wCXq1vI mJ9yi3csp0CRXdiaynrkhTH5YyCpyrZLexn1KcjFL+Go9g8tGIwZiSvrOy4+hfZk5E8H FAiQ== MIME-Version: 1.0 X-Received: by 10.180.184.101 with SMTP id et5mr527227wic.45.1371130048328; Thu, 13 Jun 2013 06:27:28 -0700 (PDT) Received: by 10.194.56.231 with HTTP; Thu, 13 Jun 2013 06:27:28 -0700 (PDT) Received: by 10.194.56.231 with HTTP; Thu, 13 Jun 2013 06:27:28 -0700 (PDT) In-Reply-To: References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> Date: Thu, 13 Jun 2013 06:27:28 -0700 Message-ID: Subject: Re: [Int-area] [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) From: "cb.list6" To: Randy Bush Content-Type: multipart/alternative; boundary=001a11c2289a78b9c904df091731 Cc: Fernando Gont , IPv6 Ops WG , Internet Area , IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 13:27:30 -0000 --001a11c2289a78b9c904df091731 Content-Type: text/plain; charset=ISO-8859-1 On Jun 13, 2013 1:18 AM, "Randy Bush" wrote: > > > FWIW, I don't think anyone has proposed "if the chain is larger than X, > > then drop". > > i am saying that i am telling my neighbor that, if the header length is > larger than X, it is likely that their packet will not propagate. it's > an ops bcp statement, not a statement of ipv6 protocol definition. > > same as telling them that a bgp announcement of a prefix longer than a > /24 likely will not propagete. > > today, real routers really do drop packets with headers longer than > various limits. as an op, i am trying to remove the surpeise in the > 'various'. > > randy > Randy, is it more helpful to document well known and acceptable permutations rather x number of bytes? In the end, byte guidance provides a cap on what is possible but does not help the world understand what is rational and acceptable and what is likely to reach its destination CB _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area --001a11c2289a78b9c904df091731 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


    On Jun 13, 2013 1:18 AM, "Randy Bush" <randy@psg.com> wrote:
    >
    > > FWIW, I don't think anyone has proposed "if the chain is= larger than X,
    > > then drop".
    >
    > i am saying that i am telling my neighbor that, if the header length i= s
    > larger than X, it is likely that their packet will not propagate. =A0i= t's
    > an ops bcp statement, not a statement of ipv6 protocol definition.
    >
    > same as telling them that a bgp announcement of a prefix longer than a=
    > /24 likely will not propagete.
    >
    > today, real routers really do drop packets with headers longer than > various limits. =A0as an op, i am trying to remove the surpeise in the=
    > 'various'.
    >
    > randy
    >

    Randy, is it more helpful to document well known and accepta= ble permutations rather x number of bytes?=A0

    In the end, byte guidance provides a cap on what is possible= but does not help the world understand what is rational and acceptable and= what is likely to reach its destination

    CB _______________________________________________
    > Int-area mailing list
    > Int-area@ietf.org
    > https://www= .ietf.org/mailman/listinfo/int-area

    --001a11c2289a78b9c904df091731-- From touch@isi.edu Thu Jun 13 13:19:05 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA7F21F9A65; Thu, 13 Jun 2013 13:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.955 X-Spam-Level: X-Spam-Status: No, score=-102.955 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6fuN0Xv+Wd1; Thu, 13 Jun 2013 13:19:00 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 25E8121F9A3D; Thu, 13 Jun 2013 13:19:00 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r5DKI2cA011356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Jun 2013 13:18:02 -0700 (PDT) Message-ID: <51BA28EB.3040508@isi.edu> Date: Thu, 13 Jun 2013 13:17:47 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jeroen Massar Subject: Re: Discussion about header chains (was Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)) References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E87C.6010402@isi.edu> <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> <51B8EBBA.4000803@massar.ch> <51B8EEEE.8000400@gont.com.ar> <51B96E7B.8010706@massar.ch> In-Reply-To: <51B96E7B.8010706@massar.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 20:19:06 -0000 On 6/13/2013 12:02 AM, Jeroen Massar wrote: > On 2013-06-12 14:58, Fernando Gont wrote: >> Jeroen, >> >> On 06/12/2013 11:44 PM, Jeroen Massar wrote: >>>> with the exception of the HBH header, correct. I got tired of writing that each time I was repeating myself. >>>> the HBH is an issue to itself. expect those packets to be severely rate limited. >>> >>> I am wondering why.... if your box cannot handle any headers, just >>> forward the packet, decreasing the hopcount and that is just. >> >> Well, the router is supposed to process the HBH header. > > According to the spec, yes, but does it make sense? See more below. > (note that must is not written in capitols in 2460 btw ;) > >> And, for some >> options, if the option in question is not supported, the packet should >> be dropped -- i.e., you cannot just "ignore the hbh header" (at east in >> theory). > > Why not? Is there any HBH header that is crucial for operation of IPv6? Current non-experimental ones include: - jumbograms - RPL - router alert - CALIPSO (informational, but which includes a note about hazards of HBH opts, but claims there was a conclusion that this was still the correct approach) RPL was just approved in 2012. Even though few of these are 'crucial', why are router vendors still creating new standards, and why does the IESG continue to approve them? Joe From dougb@dougbarton.us Thu Jun 13 13:24:13 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7B121F9A6A for ; Thu, 13 Jun 2013 13:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6I3Nr76eBi6G for ; Thu, 13 Jun 2013 13:24:08 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 9E44721F9A52 for ; Thu, 13 Jun 2013 13:24:06 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:224:e8ff:fe30:109b] (unknown [IPv6:2001:470:d:5e7:224:e8ff:fe30:109b]) by dougbarton.us (Postfix) with ESMTPSA id D872B22B28 for ; Thu, 13 Jun 2013 20:23:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1371155038; bh=/4BJpFaoKeDodqdMihOjqlAklY6XhrkvUYl/XpG0Vis=; h=Date:From:To:Subject:References:In-Reply-To; b=tnRTVFPDbDPsTjvYSDnelqrnXxV194vzk92nRx8VVLmUkbiamyuhCu5vyLS4uOo6I wtW1UMqsc4wKj2z8dvsGi4Rbz9ITXFxUK+7dPV4yfpaB0GLPjtLeY31pOWG4KrSauk XTKGL03p3+1abt+IHc3YTjc9MaGQfzPyOosXl4G4= Message-ID: <51BA2A5E.6050102@dougbarton.us> Date: Thu, 13 Jun 2013 13:23:58 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 20:24:13 -0000 On 06/13/2013 01:17 AM, Randy Bush wrote: >> FWIW, I don't think anyone has proposed "if the chain is larger than X, >> then drop". > > i am saying that i am telling my neighbor that, if the header length is > larger than X, it is likely that their packet will not propagate. it's > an ops bcp statement, not a statement of ipv6 protocol definition. > > same as telling them that a bgp announcement of a prefix longer than a > /24 likely will not propagete. > > today, real routers really do drop packets with headers longer than > various limits. as an op, i am trying to remove the surprise in the > 'various'. I agree with Randy, providing guidance on this topic will be very helpful, and BCP is the right category. As for what the number should be, if 256 is in the 80th percentile or higher of Warren's survey, that should be fine. A few vendors who are examining less than that now may be encouraged to increase up to 256 knowing that they have a reasonable upper bound to shoot for, as opposed to an arbitrarily large number that varies from implementation to implementation. Doug From jeroen@massar.ch Thu Jun 13 13:54:38 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA15021F91BC; Thu, 13 Jun 2013 13:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toQChgo2CX+p; Thu, 13 Jun 2013 13:54:34 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [78.47.209.234]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE3121F9AC2; Thu, 13 Jun 2013 13:54:33 -0700 (PDT) Received: from kami.ch.unfix.org (unknown [IPv6:2001:559:8000:c9:7256:81ff:fea5:2925]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 5BF7A801C2BA; Thu, 13 Jun 2013 22:54:29 +0200 (CEST) Message-ID: <51BA3184.1040500@massar.ch> Date: Thu, 13 Jun 2013 13:54:28 -0700 From: Jeroen Massar Organization: Massar User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Joe Touch Subject: Re: Discussion about header chains (was Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)) References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E87C.6010402@isi.edu> <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> <51B8EBBA.4000803@massar.ch> <51B8EEEE.8000400@gont.com.ar> <51B96E7B.8010706@massar.ch> <51BA28EB.3040508@isi.edu> In-Reply-To: <51BA28EB.3040508@isi.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 20:54:38 -0000 On 2013-06-13 13:17, Joe Touch wrote: [..] >>> And, for some >>> options, if the option in question is not supported, the packet should >>> be dropped -- i.e., you cannot just "ignore the hbh header" (at east in >>> theory). >> >> Why not? Is there any HBH header that is crucial for operation of IPv6? > > Current non-experimental ones include: peeking at http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml 'act' and noting there are a few protocols that have act != 00 that might be affected by this. > - jumbograms act = 11 (discard + notify senders, non-multicast) I am not aware of any medium being able to do even close to 65k (or heck 20k) packets, let alone over it. Is there any gear anywhere in the world which actually implements/needs this? Now for boxes that actually have both a Jumbogram capable interface and a non-jumbogram interface, for those boxes being able to understand and thus reject this option would make sense indeed. Anywhere else this option should never be seen. (And if the code does not know about it, the hardware will likely not get it either). > - RPL act = 01 (discard) I don't see damage when this packet is ignored though. "The RPL Option is only for use between RPL routers participating in the same RPL Instance." Code that does not know about RPL does not support it and does not include the instance. (Generally this looks like one of those 'scary' and 'do not want to see from another operator on my network' kind of options btw) Security considerations does not hi-light what problems could happen if a box just ignores it unfortunately. > - router alert act = 00 (ignore) thus handled by routers that do not do HBH at all. > - CALIPSO (informational, but which includes a note about > hazards of HBH opts, but claims there was a conclusion > that this was still the correct approach) act = 00 (ignore), thus no issue here. I btw love the IESG note at the top: "The IESG notes that general deployment of protocols with hop-by-hop options are problematic, and the development of such protocols is consequently discouraged." and: "It is unsuitable for use and ineffective on the global public Internet." > RPL was just approved in 2012. > > Even though few of these are 'crucial', why are router vendors still > creating new standards, and why does the IESG continue to approve them? Except maybe one day far in the future where Jumbopackets are needed, I do not see any of these as 'crucial'. I also do not see a single problem with routers that simply completely ignore anything but the IP header (thus decrement hop-limit, error+icmp if needed, forward the packet to the next hop) and do not look at any of the next headers... Note that this kind of ignore does allow future HBH options to be developed and deployed without issues (maybe somebody comes up with a useful thing). Processing overhead in routers is none, as they just route, boxes that have more knowledge can handle the options. (which is I assume also the idea behind the act bits, but it seems they only limit deployment of something new, not allow it) I would love to be informed though if anybody knows any situation where that can be problematic, now or in the future. Greets, Jeroen From touch@isi.edu Thu Jun 13 14:03:53 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CA921F9A62; Thu, 13 Jun 2013 14:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.944 X-Spam-Level: X-Spam-Status: No, score=-104.944 tagged_above=-999 required=5 tests=[AWL=1.655, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FTY1oN2PRlS; Thu, 13 Jun 2013 14:03:48 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id D369E21F9A4E; Thu, 13 Jun 2013 14:03:47 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r5DL2APN021811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Jun 2013 14:02:10 -0700 (PDT) Message-ID: <51BA3358.6040701@isi.edu> Date: Thu, 13 Jun 2013 14:02:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jeroen Massar Subject: Re: Discussion about header chains (was Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)) References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E87C.6010402@isi.edu> <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> <51B8EBBA.4000803@massar.ch> <51B8EEEE.8000400@gont.com.ar> <51B96E7B.8010706@massar.ch> <51BA28EB.3040508@isi.edu> <51BA3184.1040500@massar.ch> In-Reply-To: <51BA3184.1040500@massar.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 21:03:53 -0000 On 6/13/2013 1:54 PM, Jeroen Massar wrote: > On 2013-06-13 13:17, Joe Touch wrote: > [..] >>>> And, for some >>>> options, if the option in question is not supported, the packet should >>>> be dropped -- i.e., you cannot just "ignore the hbh header" (at east in >>>> theory). >>> >>> Why not? Is there any HBH header that is crucial for operation of IPv6? >> >> Current non-experimental ones include: > > peeking at > http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml > 'act' and noting there are a few protocols that have act != 00 that > might be affected by this. Agreed. I'm not sure why the table includes HBH and DO in the same list without additional info; it would be useful to expand that table to indicate that. However, even ignoring the HBH opts wouldn't help if they can't be "jumped over" efficiently to find other headers in the chain. I.e., ignoring HBH isn't he same as prohibiting it or limiting it. Joe From jeroen@massar.ch Thu Jun 13 14:10:38 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B1F21F999A; Thu, 13 Jun 2013 14:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJn89vYCpNtD; Thu, 13 Jun 2013 14:10:33 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [78.47.209.234]) by ietfa.amsl.com (Postfix) with ESMTP id 074EC21F9947; Thu, 13 Jun 2013 14:10:32 -0700 (PDT) Received: from kami.ch.unfix.org (dhcp-84.wireless.lah1.vix.su [24.104.150.84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id CDCB1801C2BA; Thu, 13 Jun 2013 23:10:28 +0200 (CEST) Message-ID: <51BA3544.2060901@massar.ch> Date: Thu, 13 Jun 2013 14:10:28 -0700 From: Jeroen Massar Organization: Massar User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Joe Touch Subject: Re: Discussion about header chains (was Re: [v6ops] Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)) References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E87C.6010402@isi.edu> <6342A61C-16AF-49FC-A3F9-AF62EB88836C@employees.org> <51B8EBBA.4000803@massar.ch> <51B8EEEE.8000400@gont.com.ar> <51B96E7B.8010706@massar.ch> <51BA28EB.3040508@isi.edu> <51BA3184.1040500@massar.ch> <51BA3358.6040701@isi.edu> In-Reply-To: <51BA3358.6040701@isi.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, Internet Area , Robert Elz , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 21:10:38 -0000 On 2013-06-13 14:02, Joe Touch wrote: [..] >> peeking at >> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml >> 'act' and noting there are a few protocols that have act != 00 that >> might be affected by this. > > Agreed. > > I'm not sure why the table includes HBH and DO in the same list without > additional info; it would be useful to expand that table to indicate that. There are a few other nits in that list, eg references to [IPV6] while those RFCs are quite well known ;) > However, even ignoring the HBH opts wouldn't help if they can't be > "jumped over" efficiently to find other headers in the chain. I.e., > ignoring HBH isn't he same as prohibiting it or limiting it. The whole design for HBH/DO is so that they are always aligned on 8-bytes and start with the ID and a length (which is per 8 bytes), thus should be reasonably efficient to jump over them if one wants to parse them (till we hit 512bit cpu's). Greets, Jeroen From ietfc@btconnect.com Fri Jun 14 02:12:34 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F51E21F9C47 for ; Fri, 14 Jun 2013 02:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USjLtVjHhfSS for ; Fri, 14 Jun 2013 02:12:19 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id A41C221F9C14 for ; Fri, 14 Jun 2013 02:12:11 -0700 (PDT) Received: from mail176-ch1-R.bigfish.com (10.43.68.242) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Fri, 14 Jun 2013 09:12:10 +0000 Received: from mail176-ch1 (localhost [127.0.0.1]) by mail176-ch1-R.bigfish.com (Postfix) with ESMTP id 6A1613804A1; Fri, 14 Jun 2013 09:12:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.181; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0711HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -16 X-BigFish: PS-16(zzbb2dI98dI9371I542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail176-ch1 (localhost.localdomain [127.0.0.1]) by mail176-ch1 (MessageSwitch) id 1371201129500826_22086; Fri, 14 Jun 2013 09:12:09 +0000 (UTC) Received: from CH1EHSMHS029.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail176-ch1.bigfish.com (Postfix) with ESMTP id 68C7AC0074; Fri, 14 Jun 2013 09:12:09 +0000 (UTC) Received: from AMSPRD0711HT002.eurprd07.prod.outlook.com (157.56.250.181) by CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 14 Jun 2013 09:12:09 +0000 Received: from pc6 (86.135.128.129) by pod51017.outlook.com (10.242.14.163) with Microsoft SMTP Server (TLS) id 14.16.324.0; Fri, 14 Jun 2013 09:11:57 +0000 Message-ID: <00ca01ce68df$553ed560$4001a8c0@gateway.2wire.net> From: t.petch To: Doug Barton , References: <20130612174908.GT2504@Space.Net><51B6876A.9020202@si6networks.com><20130612003800.0374235C2E8B@drugs.dv.isc.org><51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu><10707.1371062690@perseus.noi.kre.to><51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net><51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> <51BA2A5E.6050102@dougbarton.us> Subject: Re: [v6ops] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain) Date: Fri, 14 Jun 2013 09:39:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.135.128.129] X-OriginatorOrg: btconnect.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 09:12:34 -0000 ----- Original Message ----- From: "Doug Barton" To: Sent: Thursday, June 13, 2013 9:23 PM > On 06/13/2013 01:17 AM, Randy Bush wrote: > >> FWIW, I don't think anyone has proposed "if the chain is larger than X, > >> then drop". > > > > i am saying that i am telling my neighbor that, if the header length is > > larger than X, it is likely that their packet will not propagate. it's > > an ops bcp statement, not a statement of ipv6 protocol definition. > > > > same as telling them that a bgp announcement of a prefix longer than a > > /24 likely will not propagete. > > > > today, real routers really do drop packets with headers longer than > > various limits. as an op, i am trying to remove the surprise in the > > 'various'. > > I agree with Randy, providing guidance on this topic will be very > helpful, and BCP is the right category. > > As for what the number should be, if 256 is in the 80th percentile or > higher of Warren's survey, that should be fine. A few vendors who are > examining less than that now may be encouraged to increase up to 256 > knowing that they have a reasonable upper bound to shoot for, as opposed > to an arbitrarily large number that varies from implementation to > implementation. I would like to check with current hardware designers that 256 is a good number for them, as opposed to 240, say. What I mean is that 256 is a nice round number, for us as for them, and so is a natural choice. But sometimes that has to include red tape, control information and such like, so what you get as a nice round number is a bit less when you pass it on to the next level of processing. Of course, with some hardware, that is built in, so that the hardware gets something greater and passes on a nice round number to its user (as with memory cards) but I have known occasions in the past when this was not the case and the choice of a nice round number caused problems. Apart from that 'detail', I agree with the approach. Tom Petch > Doug > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From sm@resistor.net Fri Jun 14 03:18:45 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081A621F9C63 for ; Fri, 14 Jun 2013 03:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 678xZ2Mwp9aq for ; Fri, 14 Jun 2013 03:18:44 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7998C21F9AEB for ; Fri, 14 Jun 2013 03:18:43 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r5EAIcG6014423; Fri, 14 Jun 2013 03:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1371205123; bh=E4q4rxhI2ryIzQ0rXf9MFHhZwWk9cB7riwF+2tV59zI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=DbqaAyjZxBodqVxwHVCCzRCJNLP1NsBXSq0kVWDOeenIlj5gNVGI6LZPAF2xNpEcG eH6WBdUfw7Rjo4QHJkhKNBo8eE3u4f5qVK6b7B9fM/VvXJIJHHtFdW7bWnVjBNiGdQ i0n8bWojU0VSeH6VipTNk0JtDugsQ0UmPcmvJs2Q= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1371205123; i=@resistor.net; bh=E4q4rxhI2ryIzQ0rXf9MFHhZwWk9cB7riwF+2tV59zI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=F8WilHkuK/WBygUjVTUcaaoYHANrQo34J3UOndcCR5Jwu0k53NZEMP8siuPpTvLsA XNLMWLe3szinIwBbQFQwmZs7k8QDeoaw29DixIfONQB+NdCKvzehtflKcqc8WD9p4Y yPFLAVbme9UPaf1RZHTAxspLT06duoPNFKCZpUJw= Message-Id: <6.2.5.6.2.20130614031112.0bbde158@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 14 Jun 2013 03:18:37 -0700 To: ipv6@ietf.org From: SM Subject: Re: Progressing draft-ietf-6man-stable-privacy-addresses (Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-10.txt) In-Reply-To: <51B8B5F6.4080404@si6networks.com> References: <20130612174513.32059.54189.idtracker@ietfa.amsl.com> <51B8B5F6.4080404@si6networks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 10:18:45 -0000 At 10:55 12-06-2013, Fernando Gont wrote: >This latest revision addresses the feedback sent by Alissa Cooper. > >Should we progress this document now? Yes. The proposal will be implemented. Regards, -sm From v6ops@globis.net Fri Jun 14 06:25:41 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1D621F9C95; Fri, 14 Jun 2013 06:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZwWvEUVLzzd; Fri, 14 Jun 2013 06:25:41 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4F421F9C81; Fri, 14 Jun 2013 06:25:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 4360987007E; Fri, 14 Jun 2013 15:25:25 +0200 (CEST) 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 RCcMV8y7OMHp; Fri, 14 Jun 2013 15:25:25 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 13CB5870077; Fri, 14 Jun 2013 15:25:25 +0200 (CEST) Message-ID: <51BB19BE.1070806@globis.net> Date: Fri, 14 Jun 2013 15:25:18 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Sander Steffann Subject: Re: Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <51B6876A.9020202@si6networks.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 13:25:41 -0000 Sander Steffann wrote: > Hi, > >> My question to th wg is: >> >> 1) Do we want to limit the size of the IPv6 header chain? > > I think it is necessary yes. > >> 2) If so, which limit should we pick? > > I think there are two conditions here: > - The full layer-4 header must be within this limit, and it must be in the first fragment (if fragmented at all) > - The limit should be larger than what is currently used + some margin for stuff we forgot > > Take i.e. Figure 3 of http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html as example. It shows a Mobile-IPv6 packet: IPv6 header (40 octets) + Routing header (24 octets) + Destination Options header (24 octets) + Fragmentation header (8 octets). Add to that a basic TCP header (20 octets) and we arrive at 116 octets. > > So a limit of 128 would currently probably be ok, but I personally would prefer the limit to be a bit higher just to have some extra margin. > > Cheers, > Sander > I've been trawling through various standards trying to identify sane extension header combinations myself. I've come across a couple of problematic standardised options already defined that don't appear to have individual length limits below the overall generic limit of 256 octets per option (derived from the "Opt Data Len" field being 1 octet), so limiting the overall header length to 256 octets could have direct impact on those. PadN (of course) The lineID option rfc6788. The Routing Protocol for Low-Power and Lossy Networks (RPL) Option rfc6553 regards, RayH From tom.taylor.stds@gmail.com Fri Jun 14 06:58:06 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD5021F9C99; Fri, 14 Jun 2013 06:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yltjJhUWZBPn; Fri, 14 Jun 2013 06:58:05 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4576B21F9C8A; Fri, 14 Jun 2013 06:58:05 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id ta17so648777obb.36 for ; Fri, 14 Jun 2013 06:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+NcUTT4bfvz5II8vGhhCeEhU03Nk9m2YTS8AAt0tbIM=; b=RNZb/Xn7CIs5jdinEceySHSt6i0qwWh/joaxgCTxlT0qrfm+XXgduCfDVSaJyZtykz oG7PQCJmmUMSesUq25wx3CMvc9pfBKqjLZUr29Ls2LWHPboHKMvATfaCMXkbXzO3vQr+ a8ZR823YwnUuFQ13J/NEqi2s2+F4ngfh1owSYWNbE39Vr/6yPjd6BQWSoU7AhRGuxrOi yFsYfh9s15dtcctdieWHJl33KI+v0vupu72iU3PrEFNJhdabnYLjb/OTyuOtia5lM/Zr fMCYafYCO7zZAxQpk0KGKbufmkp+1EwBDxolmuxPh3HeAzfNzyyqaQEDDF3OpkxWiLnu Q3sg== X-Received: by 10.60.102.6 with SMTP id fk6mr1417682oeb.43.1371218284211; Fri, 14 Jun 2013 06:58:04 -0700 (PDT) Received: from [192.168.1.64] ([216.254.161.150]) by mx.google.com with ESMTPSA id c10sm2433967oej.1.2013.06.14.06.58.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Jun 2013 06:58:03 -0700 (PDT) Message-ID: <51BB216B.20906@gmail.com> Date: Fri, 14 Jun 2013 09:58:03 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ray Hunter Subject: Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <51B6876A.9020202@si6networks.com> <51BB19BE.1070806@globis.net> In-Reply-To: <51BB19BE.1070806@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 13:58:06 -0000 On 14/06/2013 9:25 AM, Ray Hunter wrote: > ... > I've been trawling through various standards trying to identify sane > extension header combinations myself. > > I've come across a couple of problematic standardised options already > defined that don't appear to have individual length limits below the > overall generic limit of 256 octets per option (derived from the "Opt > Data Len" field being 1 octet), so limiting the overall header length to > 256 octets could have direct impact on those. > > PadN (of course) > > The lineID option rfc6788. > > The Routing Protocol for Low-Power and Lossy Networks (RPL) Option rfc6553 > > regards, > RayH ... Neither of these should appear outside of limited domains. The Line Identification option passes from the Access Node in a broadband deployment to the edge router (BNG) and goes no further. The RPL option is used only inside of RPL networks. Tom Taylor From v6ops@globis.net Fri Jun 14 07:22:11 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DA821F9CC8; Fri, 14 Jun 2013 07:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RE2mEK2RuLWG; Fri, 14 Jun 2013 07:22:10 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 47B8D21F9CC6; Fri, 14 Jun 2013 07:22:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 4096B87007E; Fri, 14 Jun 2013 16:21:48 +0200 (CEST) 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 t9ceTVhXlp6Q; Fri, 14 Jun 2013 16:21:48 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id C2143870076; Fri, 14 Jun 2013 16:21:47 +0200 (CEST) Message-ID: <51BB26F5.3040704@globis.net> Date: Fri, 14 Jun 2013 16:21:41 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Tom Taylor Subject: Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <51B6876A.9020202@si6networks.com> <51BB19BE.1070806@globis.net> <51BB216B.20906@gmail.com> In-Reply-To: <51BB216B.20906@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 14:22:11 -0000 > Tom Taylor > 14 June 2013 15:58 > On 14/06/2013 9:25 AM, Ray Hunter wrote: >> > ... > >> I've been trawling through various standards trying to identify sane >> extension header combinations myself. >> >> I've come across a couple of problematic standardised options already >> defined that don't appear to have individual length limits below the >> overall generic limit of 256 octets per option (derived from the "Opt >> Data Len" field being 1 octet), so limiting the overall header length to >> 256 octets could have direct impact on those. >> >> PadN (of course) >> >> The lineID option rfc6788. >> >> The Routing Protocol for Low-Power and Lossy Networks (RPL) Option >> rfc6553 >> >> regards, >> RayH > ... > > Neither of these should appear outside of limited domains. The Line > Identification option passes from the Access Node in a broadband > deployment to the edge router (BNG) and goes no further. The RPL > option is used only inside of RPL networks. > > Tom Taylor > FWIW I agree. But what would a standard limit of 256 octets on the header chain mean if one single option can be as long as the limit for the entire header chain? Is the limit only applicable across AS boundaries? On high speed devices only? YMMV? regards, RayH From tom.taylor.stds@gmail.com Fri Jun 14 08:07:01 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E098221F9B79; Fri, 14 Jun 2013 08:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xsNPTKd9FG3; Fri, 14 Jun 2013 08:07:01 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1576521F8749; Fri, 14 Jun 2013 08:07:00 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id ta17so741220obb.36 for ; Fri, 14 Jun 2013 08:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=05lWdkVct8Lsi516NoXkeAbtPTPeyef/JxG1TBJQaJE=; b=GvIaceN8DqRrHl5b8ZQ9L2DD2dfBhOvukNKHAo4FmOjRYEAynZf1dji36Ws+ePIbG4 /BbdPbWY2T4bDdCROFdYfMoOeSf2xEkv2LkIMAUOQT0EIbE/y2OXkEWXyFFN6SVjTfRV NsDhsEZiZxvYVvvLEqU5UHd2yGqw+ITdrV+1OU3npNw1x0Yf03RtRykKz2XCNkpkfSxw R6XDJSjGr2prmF3OR/EmoMaqK7Xbg3EPOJSt0s9cabB+nVWl9U4MKbexuc2TrH6ybxsT mSZHcZh+ZbpYMBzh+uPRGi+m7m1u0UF6aa3p0/iO5qTKbb2c1+a6m5nmXjUT1mooDxDF KrsA== X-Received: by 10.182.144.231 with SMTP id sp7mr1802088obb.14.1371222408174; Fri, 14 Jun 2013 08:06:48 -0700 (PDT) Received: from [192.168.1.64] ([216.254.161.150]) by mx.google.com with ESMTPSA id i2sm2550715obz.11.2013.06.14.08.06.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Jun 2013 08:06:47 -0700 (PDT) Message-ID: <51BB3187.2050307@gmail.com> Date: Fri, 14 Jun 2013 11:06:47 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ray Hunter Subject: Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <51B6876A.9020202@si6networks.com> <51BB19BE.1070806@globis.net> <51BB216B.20906@gmail.com> <51BB26F5.3040704@globis.net> In-Reply-To: <51BB26F5.3040704@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 15:07:02 -0000 On 14/06/2013 10:21 AM, Ray Hunter wrote: >> Tom Taylor >> 14 June 2013 15:58 >> On 14/06/2013 9:25 AM, Ray Hunter wrote: >>> >> ... >> >>> I've been trawling through various standards trying to identify sane >>> extension header combinations myself. >>> >>> I've come across a couple of problematic standardised options already >>> defined that don't appear to have individual length limits below the >>> overall generic limit of 256 octets per option (derived from the "Opt >>> Data Len" field being 1 octet), so limiting the overall header length to >>> 256 octets could have direct impact on those. >>> >>> PadN (of course) >>> >>> The lineID option rfc6788. >>> >>> The Routing Protocol for Low-Power and Lossy Networks (RPL) Option >>> rfc6553 >>> >>> regards, >>> RayH >> ... >> >> Neither of these should appear outside of limited domains. The Line >> Identification option passes from the Access Node in a broadband >> deployment to the edge router (BNG) and goes no further. The RPL >> option is used only inside of RPL networks. >> >> Tom Taylor >> > FWIW I agree. > > But what would a standard limit of 256 octets on the header chain mean > if one single option can be as long as the limit for the entire header > chain? > Is the limit only applicable across AS boundaries? On high speed devices > only? YMMV? > > regards, > RayH > Best answer I can see is that the limit applies except for routers supporting specific features. Corollary is that not all routers will do so, and people defining such features should be aware of that. Tom Taylor From v6ops@globis.net Fri Jun 14 09:23:32 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2311321F9CD0; Fri, 14 Jun 2013 09:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2RFYQAdLCDu; Fri, 14 Jun 2013 09:23:31 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAAF21F9CC3; Fri, 14 Jun 2013 09:23:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id A0A378700EC; Fri, 14 Jun 2013 18:23:15 +0200 (CEST) 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 RjGRyUJbH45Q; Fri, 14 Jun 2013 18:23:15 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 5B1FC870076; Fri, 14 Jun 2013 18:23:15 +0200 (CEST) Message-ID: <51BB436D.3010808@globis.net> Date: Fri, 14 Jun 2013 18:23:09 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Tom Taylor Subject: Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <51B6876A.9020202@si6networks.com> <51BB19BE.1070806@globis.net> <51BB216B.20906@gmail.com> <51BB26F5.3040704@globis.net> <51BB3187.2050307@gmail.com> In-Reply-To: <51BB3187.2050307@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 16:23:32 -0000 > Tom Taylor > 14 June 2013 17:06 > > Best answer I can see is that the limit applies except for routers > supporting specific features. Corollary is that not all routers will > do so, and people defining such features should be aware of that. > > Tom Taylor > Ray Hunter > 14 June 2013 16:21 > FWIW I agree. > > But what would a standard limit of 256 octets on the header chain mean > if one single option can be as long as the limit for the entire header > chain? > Is the limit only applicable across AS boundaries? On high speed devices > only? YMMV? > > regards, > RayH > Tom Taylor > 14 June 2013 15:58 > On 14/06/2013 9:25 AM, Ray Hunter wrote: >> > ... > >> I've been trawling through various standards trying to identify sane >> extension header combinations myself. >> >> I've come across a couple of problematic standardised options already >> defined that don't appear to have individual length limits below the >> overall generic limit of 256 octets per option (derived from the "Opt >> Data Len" field being 1 octet), so limiting the overall header length to >> 256 octets could have direct impact on those. >> >> PadN (of course) >> >> The lineID option rfc6788. >> >> The Routing Protocol for Low-Power and Lossy Networks (RPL) Option >> rfc6553 >> >> regards, >> RayH > ... > > Neither of these should appear outside of limited domains. The Line > Identification option passes from the Access Node in a broadband > deployment to the edge router (BNG) and goes no further. The RPL > option is used only inside of RPL networks. > > Tom Taylor > What about nested Generic Packet Tunneling in IPv6 [rfc2473]? That'll add another 48 octets per nesting level. [fresh IPv6 tunnel header + destination options including IPv6 Tunnel Hop Limit] On the one hand I can see they'll be really useful, certainly during a transition period, to allow operators to bypass core devices that cannot cope with switching more complex header chains in hardware. On the other hand, their very ability to hide L4 headers and complex header chains will likely make them unlikely to survive traversing firewalls. regards, RayH From dougb@dougbarton.us Fri Jun 14 11:56:56 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9742C21F9C71 for ; Fri, 14 Jun 2013 11:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcK6+qVG509X for ; Fri, 14 Jun 2013 11:56:56 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id F14CB21F9C5B for ; Fri, 14 Jun 2013 11:56:55 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:224:e8ff:fe30:109b] (unknown [IPv6:2001:470:d:5e7:224:e8ff:fe30:109b]) by dougbarton.us (Postfix) with ESMTPSA id 817A122B28; Fri, 14 Jun 2013 18:56:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1371236214; bh=BpeKMvAPC+mwbWKz5USEOUQHu04w43KZEBEa6FmGAcU=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=JQj0V8WlKDsGSA0VCuvZ40OhhVuCXua487KbkGDJtKiEOUuvJB4IESGqMndynwhAP ZSJwD1hUiq2eDpVRH4S2Ycqlgko9QKUSyshehNbTiD+5LNipuduh6mtSJZkn8s7KdL mxegpcIpVzqX2PwMRQu6B+O0ZhxGrNjsdWqb2AAQ= Message-ID: <51BB6776.8040307@dougbarton.us> Date: Fri, 14 Jun 2013 11:56:54 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "t.petch" Subject: Re: [v6ops] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain) References: <20130612174908.GT2504@Space.Net><51B6876A.9020202@si6networks.com><20130612003800.0374235C2E8B@drugs.dv.isc.org><51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu><10707.1371062690@perseus.noi.kre.to><51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net><51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> <51BA2A5E.6050102@dougbarton.us> <00ca01ce68df$553ed560$4001a8c0@gateway.2wire.net> In-Reply-To: <00ca01ce68df$553ed560$4001a8c0@gateway.2wire.net> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 18:56:56 -0000 On 06/14/2013 01:39 AM, t.petch wrote: > ----- Original Message ----- > From: "Doug Barton" > To: > Sent: Thursday, June 13, 2013 9:23 PM >> On 06/13/2013 01:17 AM, Randy Bush wrote: >>>> FWIW, I don't think anyone has proposed "if the chain is larger > than X, >>>> then drop". >>> >>> i am saying that i am telling my neighbor that, if the header length > is >>> larger than X, it is likely that their packet will not propagate. > it's >>> an ops bcp statement, not a statement of ipv6 protocol definition. >>> >>> same as telling them that a bgp announcement of a prefix longer than > a >>> /24 likely will not propagete. >>> >>> today, real routers really do drop packets with headers longer than >>> various limits. as an op, i am trying to remove the surprise in the >>> 'various'. >> >> I agree with Randy, providing guidance on this topic will be very >> helpful, and BCP is the right category. >> >> As for what the number should be, if 256 is in the 80th percentile or >> higher of Warren's survey, that should be fine. A few vendors who are >> examining less than that now may be encouraged to increase up to 256 >> knowing that they have a reasonable upper bound to shoot for, as > opposed >> to an arbitrarily large number that varies from implementation to >> implementation. > > I would like to check with current hardware designers that 256 is a good > number for them, as opposed to 240, say. Others (more knowledgeable than I) had already made that point, but for the record, yes, we should check with the hardware folks on this. > What I mean is that 256 is a nice round number, for us as for them, and > so is a natural choice. But sometimes that has to include red tape, > control information and such like, so what you get as a nice round > number is a bit less when you pass it on to the next level of > processing. Of course, with some hardware, that is built in, so that > the hardware gets something greater and passes on a nice round number to > its user (as with memory cards) but I have known occasions in the past > when this was not the case and the choice of a nice round number caused > problems. > > Apart from that 'detail', I agree with the approach. > > Tom Petch > >> Doug >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > From brian.e.carpenter@gmail.com Fri Jun 14 13:21:39 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F5B21F9CC3; Fri, 14 Jun 2013 13:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.632 X-Spam-Level: X-Spam-Status: No, score=-102.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1me-OYsUa27R; Fri, 14 Jun 2013 13:21:33 -0700 (PDT) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by ietfa.amsl.com (Postfix) with ESMTP id 80C8E21F9C56; Fri, 14 Jun 2013 13:21:33 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id 10so902784pdi.39 for ; Fri, 14 Jun 2013 13:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EGa+FLhb/0jzWcX98uh07tj1dYwg+PAYV+v8iNCTYoo=; b=zuYQp17evGGNqWxPiAIB+Kqz0d6FYOc54+qj+Kae2p0zyJUOVLl1uoQugEs57ESvBU mLQGVBJTGnW17brx5zKSJV9jw1V+O04rQqzBItphirto9iDBkMcyd/RU5hMqVNSVU4vR otMh2Ubzudv7FxSnjhpMaJY0g3lgk2JDPAQQvmCSj2+FRn6Nra1k0vjnRDT4xboxglw1 DNcBo2577F2i14w79Fu83Y8QJP9raAh0mAQqWUXQbI8J/+Ln2pBB4L/p7SdN5UnDCKBk sEU6DSCs4gSeeMxnD3XKP/ZKksdM+xsv7S9qtIucKhMh+SywKt7yk7wZCN7sBTPvGKBg 1KzQ== X-Received: by 10.66.240.70 with SMTP id vy6mr4135826pac.70.1371241293220; Fri, 14 Jun 2013 13:21:33 -0700 (PDT) Received: from [192.168.1.2] (118-92-41-46.dsl.dyn.ihug.co.nz. [118.92.41.46]) by mx.google.com with ESMTPSA id wt5sm3373464pbc.38.2013.06.14.13.21.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Jun 2013 13:21:32 -0700 (PDT) Message-ID: <51BB7B56.8050609@gmail.com> Date: Sat, 15 Jun 2013 08:21:42 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Hunter Subject: Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <51B6876A.9020202@si6networks.com> <51BB19BE.1070806@globis.net> In-Reply-To: <51BB19BE.1070806@globis.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 20:21:39 -0000 Ray, On 15/06/2013 01:25, Ray Hunter wrote: ... > > I've come across a couple of problematic standardised options already > defined that don't appear to have individual length limits below the > overall generic limit of 256 octets per option (derived from the "Opt > Data Len" field being 1 octet), so limiting the overall header length to > 256 octets could have direct impact on those. > > PadN (of course) Right, but that would be clearly pointless or some kind of attack, so dropping it would be fine. > > The lineID option rfc6788. " This document uses a mechanism that tunnels Neighbor Discovery (ND) packets inside another IPv6 packet that uses a destination option (Line-ID option) to convey line-identification information..." In other words, only used in a local context where ND makes sense; not an issue for WAN traffic. > > The Routing Protocol for Low-Power and Lossy Networks (RPL) Option rfc6553 Only used within a ROLL domain. I don't think cases like this are troublesome. Extension headers and options that need to be used over the WAN are the problem cases. That's why this is a SHOULD NOT and a health warning, not a MUST NOT. Brian From brian.e.carpenter@gmail.com Fri Jun 14 13:25:34 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D36F21F9D38; Fri, 14 Jun 2013 13:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.628 X-Spam-Level: X-Spam-Status: No, score=-102.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAGBKx5WdgGk; Fri, 14 Jun 2013 13:25:18 -0700 (PDT) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by ietfa.amsl.com (Postfix) with ESMTP id E8E4921F99A0; Fri, 14 Jun 2013 13:24:53 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id y14so910934pdi.2 for ; Fri, 14 Jun 2013 13:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kUzM5U78/N2e0UEH3APE4Ibz4pVBdpQLihAzIRbDhz8=; b=oCttGzaPPJ+hHsA9OFDYLAXR0y75so/ycJ7B/AjR+kh4IuC9NVLeBRFU6DfsdAjyBo UxoVfhSErOmXPXqznFjsNRbtYhIHgz6oYMJGtZlNVpTrkdLu7cbvPS21E1WsHHm/IJ5M 5JIVjhIAw9pVMxJyf7RaDJgPkNgzXuT75QzDOu7j3teV9LEhJhiHg82xP3HedOE14gvw 1Y0TWXqcUl4ZJ2o+3545peA/qbAGQPrbaLuFe3051MBAaoTPPbpDLXtvRVtpWTlK4cL8 e7IOmRJwPntFC2ZEV4TtwzhUpzptevAcUWFRd2Ak8HhsQrEdGw11A1YD2UH+TXcKbgOM B3bQ== X-Received: by 10.68.41.106 with SMTP id e10mr4147744pbl.136.1371241493565; Fri, 14 Jun 2013 13:24:53 -0700 (PDT) Received: from [192.168.1.2] (118-92-41-46.dsl.dyn.ihug.co.nz. [118.92.41.46]) by mx.google.com with ESMTPSA id un15sm3664931pab.7.2013.06.14.13.24.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Jun 2013 13:24:52 -0700 (PDT) Message-ID: <51BB7C1F.8060100@gmail.com> Date: Sat, 15 Jun 2013 08:25:03 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Hunter Subject: Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain) References: <51B6876A.9020202@si6networks.com> <51BB19BE.1070806@globis.net> <51BB216B.20906@gmail.com> <51BB26F5.3040704@globis.net> <51BB3187.2050307@gmail.com> <51BB436D.3010808@globis.net> In-Reply-To: <51BB436D.3010808@globis.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 20:25:34 -0000 On 15/06/2013 04:23, Ray Hunter wrote: ... > What about nested Generic Packet Tunneling in IPv6 [rfc2473]? > > That'll add another 48 octets per nesting level. [fresh IPv6 tunnel > header + destination options including IPv6 Tunnel Hop Limit] > > On the one hand I can see they'll be really useful, certainly during a > transition period, to allow operators to bypass core devices that cannot > cope with switching more complex header chains in hardware. On the other > hand, their very ability to hide L4 headers and complex header chains > will likely make them unlikely to survive traversing firewalls. Exactly. Tunnels of any kind are considered very suspect, so I don't think this is part of the same problem. Brian From alh-ietf@tndh.net Fri Jun 14 14:19:28 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6750C21F9AE7; Fri, 14 Jun 2013 14:19:28 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ...that system for details.\n \n Content previ[...] X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSghxFwCy-RZ; Fri, 14 Jun 2013 14:19:27 -0700 (PDT) Received: from express.tndh.net (express.tndh.net [IPv6:2001:470:e930:1240:20d:56ff:fe04:4c0a]) by ietfa.amsl.com (Postfix) with ESMTP id DB4AE21F9B16; Fri, 14 Jun 2013 14:19:19 -0700 (PDT) Received: from express.tndh.local ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1UnbOh-000Pgx-Fc; Fri, 14 Jun 2013 14:19:09 -0700 From: "Tony Hain" To: References: <20130612174908.GT2504@Space.Net><51B6876A.9020202@si6networks.com><20130612003800.0374235C2E8B@drugs.dv.isc.org><51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu><10707.1371062690@perseus.noi.kre.to><51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net><51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> <51BA2A5E.6050102@dougbarton.us> <00ca01ce68df$553ed560$4001a8c0@gateway.2wire.net> <51BB6776.8040307@dougbarton.us> In-Reply-To: <51BB6776.8040307@dougbarton.us> Subject: RE: [v6ops] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain) Date: Fri, 14 Jun 2013 14:19:03 -0700 Message-ID: <013101ce6944$cbb62e90$63228bb0$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE9wTHuBFzNyWAeOm0owX7A30J4PgMo0JkjAiu3dr0A3IXrigITvNG6AdG8WXoBUiNvRgGQ3T7NAfCEKioBFB6FwQLjiAmRAm5Lqn0CeX7TKgJBvZ2CAfDqh6yZdyEMAA== Content-Language: en-us X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a X-SA-Exim-Mail-From: alh-ietf@tndh.net X-SA-Exim-Scanned: No (on express.tndh.net); SAEximRunCond expanded to false Cc: v6ops@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 21:19:28 -0000 Doug Barton wrote: > >>... > >> I agree with Randy, providing guidance on this topic will be very > >> helpful, and BCP is the right category. > >> > >> As for what the number should be, if 256 is in the 80th percentile or > >> higher of Warren's survey, that should be fine. A few vendors who are > >> examining less than that now may be encouraged to increase up to 256 > >> knowing that they have a reasonable upper bound to shoot for, as > > opposed > >> to an arbitrarily large number that varies from implementation to > >> implementation. > > > > I would like to check with current hardware designers that 256 is a > > good number for them, as opposed to 240, say. > > Others (more knowledgeable than I) had already made that point, but for > the record, yes, we should check with the hardware folks on this. > While guidance is useful to establish a consistent-behavior baseline across vendors and deployments, care must be taken to avoid the trap of precluding innovation and evolution. Well-meaning limits based on current hardware capabilities will become doctrine over time, and changing values to allow something new will become virtually impossible, as the utility of the new thing without a significant deployment base will never outdo the inertia of established practice. Particularly when there is a perception that the established practice has some 'security' value. I have no issue with requiring L4 in the first fragment, though what constitutes a fragment needs to change. It is long past time that 1500B packets should have been removed as a limiting factor, and if/when we ever do get to something larger, restricting header chains to 256B will look absurd. BCP -> YES Hard byte count -> NO (make that hell no) Focus on the real operational requirement (firewall functionality), then make sure that the constraint automatically tracks evolution in firewall functionality. Getting there leads to L4 in the first fragment, and anything else leads to artificial constraints that will need to be redone, if that is even possible. Tony From dougb@dougbarton.us Fri Jun 14 14:33:54 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF1121F9A95 for ; Fri, 14 Jun 2013 14:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Y+3CCgUBQF6 for ; Fri, 14 Jun 2013 14:33:53 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 84D5921F9A64 for ; Fri, 14 Jun 2013 14:33:53 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:917c:43ca:5e44:2879] (unknown [IPv6:2001:470:d:5e7:917c:43ca:5e44:2879]) by dougbarton.us (Postfix) with ESMTPSA id 16CCA22B28 for ; Fri, 14 Jun 2013 21:33:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1371245633; bh=2nTu3yehNioz0I4RQXtgub9E4dCbXYvNRR27GD7S/mk=; h=Date:From:To:Subject:References:In-Reply-To; b=kK1x2jtoGCvHrCnt0tk1mtDA0MF18FoevNHBdJ8wzG/XG5M1yM6W0aH7cDzDXoctE bhHEBAvGvCkFxn90M72P6KbVAhIfo5eFEo5a+XNbysXcexyOrXFedc0O89B0uJfm3v EjY03ExcqlO3uWGHkkMRNEhqvh2VrJ931YSDZjH0= Message-ID: <51BB8C40.7070808@dougbarton.us> Date: Fri, 14 Jun 2013 14:33:52 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [v6ops] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain) References: <20130612174908.GT2504@Space.Net><51B6876A.9020202@si6networks.com><20130612003800.0374235C2E8B@drugs.dv.isc.org><51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu><10707.1371062690@perseus.noi.kre.to><51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net><51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> <51BA2A5E.6050102@dougbarton.us> <00ca01ce68df$553ed560$4001a8c0@gateway.2wire.net> <51BB6776.8040307@dougbarton.us> <013101ce6944$cbb62e90$63228bb0$@tndh.net> In-Reply-To: <013101ce6944$cbb62e90$63228bb0$@tndh.net> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 21:33:54 -0000 On 06/14/2013 02:19 PM, Tony Hain wrote: > While guidance is useful to establish a consistent-behavior baseline across > vendors and deployments, care must be taken to avoid the trap of precluding > innovation and evolution. Well-meaning limits based on current hardware > capabilities will become doctrine over time, and changing values to allow > something new will become virtually impossible, as the utility of the new > thing without a significant deployment base will never outdo the inertia of > established practice. Particularly when there is a perception that the > established practice has some 'security' value. The flip side of that is that if we don't stop changing the spec the protocol will never be deployed in a meaningful way. We cannot expect hardware vendors to do fast path for an effectively infinite number of bytes of EH. If you think that a number based on current limitations is too ... limiting, make your case for what the number should be. But "infinite" is not on the table. From warren@kumari.net Fri Jun 14 15:00:51 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4E721F99F2 for ; Fri, 14 Jun 2013 15:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZK8TwUdWRM7b for ; Fri, 14 Jun 2013 15:00:37 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAAA21F99CF for ; Fri, 14 Jun 2013 15:00:36 -0700 (PDT) Received: from [172.20.10.2] (unknown [166.137.107.252]) by vimes.kumari.net (Postfix) with ESMTPSA id A0CFC1B401C5; Fri, 14 Jun 2013 18:00:35 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [6MAN] Re: [v6ops] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain) From: Warren Kumari In-Reply-To: <51BB6776.8040307@dougbarton.us> Date: Fri, 14 Jun 2013 18:00:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130612174908.GT2504@Space.Net><51B6876A.9020202@si6networks.com><20130612003800.0374235C2E8B@drugs.dv.isc.org><51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu><10707.1371062690@perseus.noi.kre.to><51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net><51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> <51BA2A5E.6050102@dougbarton.us> <00ca01ce68df$553ed560$4001a8c0@gateway.2wire.net> <51BB6776.8040307@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1503) Cc: ipv6@ietf.org, "t.petch" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 22:00:51 -0000 On Jun 14, 2013, at 2:56 PM, Doug Barton wrote: > On 06/14/2013 01:39 AM, t.petch wrote: >> ----- Original Message ----- >> From: "Doug Barton" >> To: >> Sent: Thursday, June 13, 2013 9:23 PM >>> On 06/13/2013 01:17 AM, Randy Bush wrote: >>>>> FWIW, I don't think anyone has proposed "if the chain is larger >> than X, >>>>> then drop". >>>>=20 >>>> i am saying that i am telling my neighbor that, if the header = length >> is >>>> larger than X, it is likely that their packet will not propagate. >> it's >>>> an ops bcp statement, not a statement of ipv6 protocol definition. >>>>=20 >>>> same as telling them that a bgp announcement of a prefix longer = than >> a >>>> /24 likely will not propagete. >>>>=20 >>>> today, real routers really do drop packets with headers longer than >>>> various limits. as an op, i am trying to remove the surprise in = the >>>> 'various'. >>>=20 >>> I agree with Randy, providing guidance on this topic will be very >>> helpful, and BCP is the right category. >>>=20 >>> As for what the number should be, if 256 is in the 80th percentile = or >>> higher of Warren's survey, that should be fine. A few vendors who = are >>> examining less than that now may be encouraged to increase up to 256 >>> knowing that they have a reasonable upper bound to shoot for, as >> opposed >>> to an arbitrarily large number that varies from implementation to >>> implementation. >>=20 >> I would like to check with current hardware designers that 256 is a = good >> number for them, as opposed to 240, say. >=20 > Others (more knowledgeable than I) had already made that point, but = for the record, yes, we should check with the hardware folks on this. I've already mentioned this in one of the N (where is is becoming = distressingly large) threads on this, but we are planning on: A: adding something like this (you should be able to look N bytes / = headers in the packet) to the long headers draft (RSN, promise!) and / = or B: writing an advice to implementers draft. One of the co-authors (Ron) of the long-headers draft works for Juniper = and has discussed this with their forwarding folk. We are also having = discussions with other vendors on the same topic, and will hopefully = have another author from at least one of the other large chappies=85 W >=20 >> What I mean is that 256 is a nice round number, for us as for them, = and >> so is a natural choice. But sometimes that has to include red tape, >> control information and such like, so what you get as a nice round >> number is a bit less when you pass it on to the next level of >> processing. Of course, with some hardware, that is built in, so that >> the hardware gets something greater and passes on a nice round number = to >> its user (as with memory cards) but I have known occasions in the = past >> when this was not the case and the choice of a nice round number = caused >> problems. >>=20 >> Apart from that 'detail', I agree with the approach. >>=20 >> Tom Petch >>=20 >>> Doug >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>>=20 >>=20 >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -- Credo quia absurdum est. From lorenzo@google.com Fri Jun 14 15:15:44 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E7521E8086 for ; Fri, 14 Jun 2013 15:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nS8--DSTifkr for ; Fri, 14 Jun 2013 15:15:44 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2038521E805E for ; Fri, 14 Jun 2013 15:15:41 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id w56so898807wes.25 for ; Fri, 14 Jun 2013 15:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=45Mgx1bUQzTbbtDSoXIhN8/UxlbOap6ho+Z4zDv9/SA=; b=jdzWMl1tEZCP+cqBdxnMHbQ4sM9atqOhF/9H1D4Ts4WlZLBSFuDhzBPax1Rqp+PmAy Ngq1ycrIdfobJ6cLnndHHygSWu0h4IAUJ5aLUFhSBJKY0twtocWuKLiXGyaF7dwr1LS4 SYzriaU9GZobvzmDdwqV3eSj6Op7DLcWzeewGXGAY84WTO90QwSQv5b2s753JgRdQhzm B0c8gMeh6uVMW8Qcsz4ZkJAwMKi6L5EyvZzK6XY1LSzgGT5LfHVTXmhJIacJdd7L8ACs k5/SptZ8KgCOW/MVny78cxTO2/HZ4u3zuzCWalppKaf3b4hz/eyOzdjw5Iq/+AH9Ua8D +EzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=45Mgx1bUQzTbbtDSoXIhN8/UxlbOap6ho+Z4zDv9/SA=; b=cGNy1gWPG2CD3AtfNlsDlkwpDSefQ4hszCR2y+bCtcOn1iAViRI+zaI+P5HQaZfoWk a24eG00kXQi3S3ToPxqthu4meoJ7qUJstCoQ6bY3SgghCatG/Dl6svr388KQH8Al6sv7 JC9HQrMV5tQ2X0J6zsLTHvgROxFd1P/uYLWk2GGpcgTw1zVEp7r6jmBAHJ75bA80MnLc TgeE2rpNhXSt8YE2Jf15fisMqCbPymtmNb244DFnUcLck2tbefVjObiEOapKnbmT9SMR LrXDC4HKjemp2k9UUGx/oj3kBXOMx3Qdb2eJHHshJ/zaVjm1nnQpdlrNp4cX88YUWEli B2qA== X-Received: by 10.194.6.37 with SMTP id x5mr2593453wjx.35.1371248141240; Fri, 14 Jun 2013 15:15:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.94.138 with HTTP; Fri, 14 Jun 2013 15:15:20 -0700 (PDT) In-Reply-To: <013101ce6944$cbb62e90$63228bb0$@tndh.net> References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> <51BA2A5E.6050102@dougbarton.us> <00ca01ce68df$553ed560$4001a8c0@gateway.2wire.net> <51BB6776.8040307@dougbarton.us> <013101ce6944$cbb62e90$63228bb0$@tndh.net> From: Lorenzo Colitti Date: Fri, 14 Jun 2013 15:15:20 -0700 Message-ID: Subject: Re: [v6ops] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain) To: Tony Hain Content-Type: multipart/alternative; boundary=047d7b5d9acd5bb6a604df2496a2 X-Gm-Message-State: ALoCoQnfI00gR5XZjcQ+ilc35BN42rsDP5slAqVloILf3MxI/3kSSahR/nEJg8Vd1VROHUGARZpcxrZUKs+0ZnuvS2PE0PCks2veFO0hdIb44l2fGLL04rtsUga+UrbqT92JI/s+XHnnUwxEic1h428GM7Qh1Ssbj/BNfXLUSy9gqdaSaMl5uFFveRWRMXbQwLg+DVlY0MbU Cc: "v6ops@ietf.org WG" , IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 22:15:45 -0000 --047d7b5d9acd5bb6a604df2496a2 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 14, 2013 at 2:19 PM, Tony Hain wrote: > Focus on the real operational requirement (firewall functionality), then > make sure that the constraint automatically tracks evolution in firewall > functionality. Getting there leads to L4 in the first fragment, and > anything > else leads to artificial constraints that will need to be redone, if that > is > even possible. > The problem with that approach is that for a very substantial fraction of Internet backbones, the real operational requirement is substantially *less* capable than what is written in RFC 2460 and than what you propose here. --047d7b5d9acd5bb6a604df2496a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Fri, Jun 14, 2013 at 2:19 PM, Tony Hain <alh-ietf@tndh= .net> wrote:
    Focus on=A0the real operational requirement = =A0(firewall functionality), then make sure=A0that the constraint automatic= ally tracks evolution in firewall
    functionality. Getting there leads to L4 in the first fragment, and anythin= g
    else leads to artificial constraints that will need to be redone, if that i= s
    even possible.

    The problem with t= hat approach is that for a very substantial fraction of Internet backbones,= the real operational requirement is substantially *less* capable than what= is written in RFC 2460 and than what you propose here.
    --047d7b5d9acd5bb6a604df2496a2-- From dougb@dougbarton.us Fri Jun 14 15:31:15 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A108621F9B15 for ; Fri, 14 Jun 2013 15:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAtNXZfK89Aw for ; Fri, 14 Jun 2013 15:31:15 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4857021F9B19 for ; Fri, 14 Jun 2013 15:31:13 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:917c:43ca:5e44:2879] (unknown [IPv6:2001:470:d:5e7:917c:43ca:5e44:2879]) by dougbarton.us (Postfix) with ESMTPSA id E219C22B6A for ; Fri, 14 Jun 2013 22:31:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1371249073; bh=CA53KbA4f6qKCsDwHtNWR3eI7Cf+WWF879hDG/EtwAw=; h=Date:From:To:Subject:References:In-Reply-To; b=VjeNkA0bgGmnLfcAkbuD2VTzKKjKRPefhq5LapUmxwJTzBQArRyIWCmIsXAk/l/xO SCYT8FlkkGzJcu5x7TI/sVNBdmXMUdn0vqfFe34GVi0Cr3xPmwQnvFRXhj7RnZs8uJ NDkJ96MCcYeBFTClYz0a1dKLxosSAm/0Q5axlJfU= Message-ID: <51BB99B0.70609@dougbarton.us> Date: Fri, 14 Jun 2013 15:31:12 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [6MAN] Re: [v6ops] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain) References: <20130612174908.GT2504@Space.Net><51B6876A.9020202@si6networks.com><20130612003800.0374235C2E8B@drugs.dv.isc.org><51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu><10707.1371062690@perseus.noi.kre.to><51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net><51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> <51BA2A5E.6050102@dougbarton.us> <00ca01ce68df$553ed560$4001a8c0@gateway.2wire.net> <51BB6776.8040307@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 22:31:15 -0000 On 06/14/2013 03:00 PM, Warren Kumari wrote: > I've already mentioned this in one of the N (where is is becoming distressingly large) threads on this Yeah, you would be one of those "more knowledgeable" folks I was referring to. :) From warren@kumari.net Fri Jun 14 18:52:06 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1B421F99A2 for ; Fri, 14 Jun 2013 18:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VngGiJ7ZxBMh for ; Fri, 14 Jun 2013 18:52:01 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A80721F9AB1 for ; Fri, 14 Jun 2013 18:52:01 -0700 (PDT) Received: from [192.168.0.155] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id E974B1B4057E; Fri, 14 Jun 2013 21:51:56 -0400 (EDT) References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> <51BA2A5E.6050102@dougbarton.us> <00ca01ce68df$553ed560$4001a8c0@gateway.2wire.net> <51BB6776.8040307@dougbarton.us> <51BB99B0.70609@dougbarton.us> In-Reply-To: <51BB99B0.70609@dougbarton.us> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <2DD36135-5657-4CAD-9FA0-3B7692B75EBC@kumari.net> X-Mailer: iPhone Mail (10B350) From: Warren Kumari Subject: Re: [6MAN] Re: [6MAN] Re: [v6ops] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain) Date: Fri, 14 Jun 2013 21:51:55 -0400 To: Doug Barton Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 01:52:06 -0000 On Jun 14, 2013, at 6:31 PM, Doug Barton wrote: > On 06/14/2013 03:00 PM, Warren Kumari wrote: >> I've already mentioned this in one of the N (where is is becoming distres= singly large) threads on this >=20 > Yeah, you would be one of those "more knowledgeable" folks I was referring= to. :) Oh, well thank you. I appreciate this, and feel honored. W P.S: no sarcasm. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From fgont@si6networks.com Mon Jun 17 22:12:03 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C37B21F9D9A for ; Mon, 17 Jun 2013 22:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tW0dPj6wmERe for ; Mon, 17 Jun 2013 22:12:01 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id D41A521F9CF3 for ; Mon, 17 Jun 2013 22:11:59 -0700 (PDT) Received: from lvelizy-156-46-53-44.w80-11.abo.wanadoo.fr ([80.11.221.44] helo=[192.168.4.23]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UooCu-0008RK-80; Tue, 18 Jun 2013 07:11:53 +0200 Message-ID: <51BFEC17.7060207@si6networks.com> Date: Tue, 18 Jun 2013 07:11:51 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Fernando Gont Subject: Re: Progressing draft-ietf-6man-stable-privacy-addresses (Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-10.txt) References: <20130612174513.32059.54189.idtracker@ietfa.amsl.com> <51B8B5F6.4080404@si6networks.com> In-Reply-To: <51B8B5F6.4080404@si6networks.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Brian Haberman , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 05:12:03 -0000 ping? On 06/12/2013 07:55 PM, Fernando Gont wrote: > Folks, > > This latest revision addresses the feedback sent by Alissa Cooper. > > Should we progress this document now? > > Thanks! > Fernando > > > > > On 06/12/2013 07:45 PM, 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 Maintenance Working Group of the IETF. >> >> Title : A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC) >> Author(s) : Fernando Gont >> Filename : draft-ietf-6man-stable-privacy-addresses-10.txt >> Pages : 29 >> Date : 2013-06-12 >> >> Abstract: >> This document specifies a method for generating IPv6 Interface >> Identifiers to be used with IPv6 Stateless Address Autoconfiguration >> (SLAAC), such that addresses configured using this method are stable >> within each subnet, but the Interface Identifier changes when hosts >> move from one network to another. This method is meant to be an >> alternative to generating Interface Identifiers based on hardware >> address (e.g., using IEEE identifiers), such that the benefits of >> stable addresses can be achieved without sacrificing the privacy of >> users. The method specified in this document applies to all prefixes >> a host may be employing, including link-local, global, and unique- >> local addresses. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-10 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-stable-privacy-addresses-10 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From otroan@employees.org Tue Jun 18 01:20:20 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573F221F9AB2 for ; Tue, 18 Jun 2013 01:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9C7hTxnNv2Z for ; Tue, 18 Jun 2013 01:20:18 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 343B321F9AAA for ; Tue, 18 Jun 2013 01:20:18 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 9F6F45EF1; Tue, 18 Jun 2013 01:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=MrwjpzUl45yVaQ1S7Sfi+Q3xE1w=; b=Whr2cztErl6T6RDGFP 86ShQpJ+1Mgj1caXJpgxLc5guuFvENIVN0vkLc4lXGCKKDgm/cEpkFwuRDuAYq4+ AqEwMx+w6DYnJvK1jSPD9frzRujyNiXD1PzqD3HcbhqOQAQ2YXA0i6lN0ZI/wbZO BlZBrZlIFj+uDZwj4K6g4ihzA= 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=L2WDNFPeb7gO/dxuqnVM1tIYiyvye8umpdCgLuOY4lR+71fw378 78ul5JZeQn2sPzvrcfzspLD+J+7P5Hw2Ge76XWY3i2K184hXoe2ebjHDCWUo450D mg6Dv9dWYhXGoAqnay3YXjSE7I1uTUvbCOurUqgv4oaShETFYijUTHwY= Received: from dhcp-10-61-111-107.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 061985ED9; Tue, 18 Jun 2013 01:20:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Progressing draft-ietf-6man-stable-privacy-addresses (Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-10.txt) From: Ole Troan In-Reply-To: <51BFEC17.7060207@si6networks.com> Date: Tue, 18 Jun 2013 10:20:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130612174513.32059.54189.idtracker@ietfa.amsl.com> <51B8B5F6.4080404@si6networks.com> <51BFEC17.7060207@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1508) Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Brian Haberman , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 08:20:20 -0000 Fernando, > ping? We are thinking that it would be good to have a separate draft that = describes the current approaches to IID creation and how they effect = privacy and tracking. Somewhat along the lines of the email and chart = sent to the IPv6 list by Alissa Cooper. The stable-privacy draft should then wait until that work has = progressed. Best regards, Ole (6man co-chair hat on) From fgont@si6networks.com Tue Jun 18 04:17:42 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2C821F9C99 for ; Tue, 18 Jun 2013 04:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOObNj9dUvnf for ; Tue, 18 Jun 2013 04:17:42 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 03E2E21F9C62 for ; Tue, 18 Jun 2013 04:17:40 -0700 (PDT) Received: from [2001:5c0:1000:a::1109] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Uotuk-0008Lw-5l; Tue, 18 Jun 2013 13:17:30 +0200 Message-ID: <51C041C5.70203@si6networks.com> Date: Tue, 18 Jun 2013 13:17:25 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ole Troan Subject: Re: Progressing draft-ietf-6man-stable-privacy-addresses (Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-10.txt) References: <20130612174513.32059.54189.idtracker@ietfa.amsl.com> <51B8B5F6.4080404@si6networks.com> <51BFEC17.7060207@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Brian Haberman , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 11:17:42 -0000 Ole, On 06/18/2013 10:20 AM, Ole Troan wrote: > >> ping? > > We are thinking that it would be good to have a separate draft that > describes the current approaches to IID creation and how they effect > privacy and tracking. Somewhat along the lines of the email and chart > sent to the IPv6 list by Alissa Cooper. > > The stable-privacy draft should then wait until that work has > progressed. I'm already working on such I-D.. but I disagree that progrees of this document should depend on such document. Why should it? We kind of beaten this issue to death.. and that's the reason for which I ended up adding all the text that I added to the I-D. There's people working on implementations of this document, so we should progress it in a timely fashion. Besides, my personal sense of the wg is that all of the comments I received were addressed, and that there's general agreement to move the document forward. So, procedurally-speaking, I don't understand the basis of stalling this document. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From ietf@rozanak.com Tue Jun 18 10:33:20 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4660721E8091 for ; Tue, 18 Jun 2013 10:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IlSK+vwn2B9 for ; Tue, 18 Jun 2013 10:33:15 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 47ADD21E8094 for ; Tue, 18 Jun 2013 10:33:15 -0700 (PDT) Received: from kopoli (e179167165.adsl.alicedsl.de [85.179.167.165]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Lmrky-1UNKzk2d4O-00h7Jz; Tue, 18 Jun 2013 13:33:08 -0400 From: "Hosnieh Rafiee" To: , "Tim Chown" Subject: I-D: Router Advertisement Based Privacy - draft-rafiee-6man-ra-privacy Date: Tue, 18 Jun 2013 19:33:01 +0200 Message-ID: <000601ce6c49$e54415e0$afcc41a0$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CE6C5A.A8D0B670" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5sSVc53hvL+z6/TKaGkCODj9IxFw== Content-Language: en-us X-Provags-ID: V02:K0:7G9U4NnndWCzH4kT58zHE81h+hZNBE9zwarbcP15yYG 0zK11Af+cvJYi3mCwiC/+ooZlObr2Nc8FJU+yw3hFW/4Mco8CL t6cLXNqrNDNPzmRaM9iR54FRc8Fx71TF9YCZUFZO1HVJEtUGVI cqOGluPr7LzF3hWczEXT4neMorMOYn//ddT0Xb0m9Uyxi2Clkt VLz86NKja0rnUZd/tYJkTIOpLop5ednrlwa6J5xpa0a3d/Wx6W iUaIEZhpbLQ1PaLwu5qiqYSTYKrBXcrpYJWzibnOAVZopT4HVo fL+hziO3sDFgqEXWRZMcpju6DSoagG9p6WvGZmG+7RNpbVwFMn 0xAXtnmzuowBiyT1YbjM= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 17:33:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0007_01CE6C5A.A8D0B670 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have improved the document and also clearly explained the problems = that this document addresses in the Introduction section. I also = improved the algorithm for IID lifetime, which is now a conditional = application based lifetime. = http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy-04=20 =20 =20 Abstract: Privacy is an important issue which concerns many governments and users, with its importance becoming more evident every day. Nodes change their IP addresses frequently in order to avoid being tracked by attackers. The act of frequently changing IP addresses also helps to prevent the leakage of information by nodes. In IPv6 networks there is currently one solution for maintaining the privacy of nodes when IPv6 StateLess Address AutoConfiguration (SLAAC) (RFC 4862) is used. Unfortunately there are some problems associated with this solution which entails the use of the Privacy Extension (RFC 4941). One of the issues with this RFC concerns the wording that is used which allows the implementation to make the choice as to what approach to use and in so doing, in some cases, the choice made is not the most prudent or best approach and this is not ideal and can cause some problems. Some of these problems are concerned with not generating a new Interface ID (IID) after changing the router prefix. Another concern would be the fact that nodes may use an IID that was generated based on a MAC address as a public address, and then use this in their response. The act of cutting the current connections to other nodes, if the max lifetime of the old IID has elapsed, is also not clearly explained nor is whether or not the already used IID should be kept in stable storage, There is also a concern about the need to have stable storage available for the generation of a randomized IID. The RFC gives no explanation as to how to make use of CGA in its randomizing solution when stable storage is not available or how to use the same approach for random value generation in all implementations where there is a lack of stable storage. The purpose of this document is to address these issues, to update the current RFC and to introduce a new algorithm for the lifetime of IID. =20 Please take a look and share your comments. Thanks, Regards, Hosnieh ------=_NextPart_000_0007_01CE6C5A.A8D0B670 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

    I have = improved the document and also clearly explained the problems that this = document addresses in the Introduction section. I also improved the = algorithm for IID lifetime, which is now a conditional application based = lifetime.

    http://tools.ietf.org/htm= l/draft-rafiee-6man-ra-privacy-04

     

     

    Abstract:

    =C2=A0=C2=A0 Privacy is an important issue which = concerns many governments and

    =C2=A0=C2=A0 users, with its importance becoming = more evident every day. Nodes

    =C2=A0=C2=A0 change their IP addresses frequently = in order to avoid being tracked

    =C2=A0=C2=A0 by attackers. The act of frequently = changing IP addresses also helps

    =C2=A0=C2=A0 to prevent the leakage of information = by nodes. In IPv6 networks

    =C2=A0=C2=A0 there is currently one solution for = maintaining the privacy of nodes

    =C2=A0=C2=A0 when IPv6 StateLess Address = AutoConfiguration (SLAAC) (RFC 4862) is

    =C2=A0=C2=A0 used. Unfortunately there are some = problems associated with this

    =C2=A0=C2=A0 solution which entails the use of the = Privacy Extension (RFC 4941).

    =C2=A0=C2=A0 One of the issues with this RFC = concerns the wording that is used

    =C2=A0=C2=A0 which allows the implementation to = make the choice as to what

    =C2=A0=C2=A0 approach to use and in so doing, in = some cases, the choice made is

    =C2=A0=C2=A0 not the most prudent or best approach = and this is not ideal and can

    =C2=A0=C2=A0 cause some problems. Some of these = problems are concerned with not

    =C2=A0=C2=A0 generating a new Interface ID (IID) = after changing the router prefix.

    =C2=A0=C2=A0 Another concern would be the fact that = nodes may use an IID that was

    =C2=A0=C2=A0 generated based on a MAC address as a = public address, and then use

    =C2=A0=C2=A0 this in their response. The act of = cutting the current connections to

    =C2=A0=C2=A0 other nodes, if the max lifetime of = the old IID has elapsed, is also

    =C2=A0=C2=A0 not clearly explained nor is whether = or not the already used IID

    =C2=A0=C2=A0 should be kept in stable storage, = There is also a concern about the

    =C2=A0=C2=A0 need to have stable storage available = for the generation of a

    =C2=A0=C2=A0 randomized IID. The RFC gives no = explanation as to how to make use of

    =C2=A0=C2=A0 CGA in its randomizing solution when = stable storage is not available

    =C2=A0=C2=A0 or how to use the same approach for = random value generation in all

    =C2=A0=C2=A0 implementations where there is a lack = of stable storage. The purpose

    =C2=A0=C2=A0 of this document is to address these = issues, to update the current

    =C2=A0=C2=A0 RFC and to introduce a new algorithm = for the lifetime of IID.

     

    Please take a look and share your = comments.

    Thanks,

    Regards,

    Hosnieh

    ------=_NextPart_000_0007_01CE6C5A.A8D0B670-- From brian.e.carpenter@gmail.com Tue Jun 18 15:32:28 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA8321E80C9 for ; Tue, 18 Jun 2013 15:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cft3-bh1h3z7 for ; Tue, 18 Jun 2013 15:32:27 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D6FC621E8096 for ; Tue, 18 Jun 2013 15:32:27 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa11so4455348pad.33 for ; Tue, 18 Jun 2013 15:32:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hdJGU/0TynOlcMH8id4OkRJ5fDmzXfqbNkRzTY6QYjY=; b=VPu1IOQJpC9vaZnFNoDpg+Mpuc+ipaVOkRXnzdQ5GzHHw4VKVEkWRFqxBd1ZCruP6K /rIQmGHZl8/hxxgN+e7T0G3kGKP8ZCA665W0693syVchtztPQMjWRs3ULowK2NFzq5mm 3fiY5ONDZ3L2wZkK58JGbPKj3/MdbXA+akhcwp7OzGrLbO9zpChbJG9Cz/yqtF2QNBN4 pj+8QPhpYt+Qczk5gznBFuocOXhP6KZSx6994pFCb1R44ZKYJbumIjXCybePNyRSJ/wE JFHzUkF2TOQW1dv9nW4BaXG2jTHubUhWvZqhDI5k4iDKO8l1O/k3J5xwsI5t1Z5L9v5c 3N7Q== X-Received: by 10.68.193.138 with SMTP id ho10mr18860107pbc.163.1371594747628; Tue, 18 Jun 2013 15:32:27 -0700 (PDT) Received: from [192.168.178.20] (36.200.69.111.dynamic.snap.net.nz. [111.69.200.36]) by mx.google.com with ESMTPSA id o10sm20019597pbq.39.2013.06.18.15.32.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 15:32:27 -0700 (PDT) Message-ID: <51C0DFFD.3090302@gmail.com> Date: Wed, 19 Jun 2013 10:32:29 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont Subject: Re: Progressing draft-ietf-6man-stable-privacy-addresses (Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-10.txt) References: <20130612174513.32059.54189.idtracker@ietfa.amsl.com> <51B8B5F6.4080404@si6networks.com> <51BFEC17.7060207@si6networks.com> <51C041C5.70203@si6networks.com> In-Reply-To: <51C041C5.70203@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, ipv6@ietf.org, Brian Haberman X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 22:32:28 -0000 Hi, On 18/06/2013 23:17, Fernando Gont wrote: > Ole, > > On 06/18/2013 10:20 AM, Ole Troan wrote: >>> ping? >> We are thinking that it would be good to have a separate draft that >> describes the current approaches to IID creation and how they effect >> privacy and tracking. Somewhat along the lines of the email and chart >> sent to the IPv6 list by Alissa Cooper. >> >> The stable-privacy draft should then wait until that work has >> progressed. > > I'm already working on such I-D.. but I disagree that progrees of this > document should depend on such document. Why should it? I tend to agree with Fernando. The dependency is the other way round; stable-privacy-addresses is a reference for the new draft. I have the same question about draft-ietf-6man-ug. We responded to all comments in the -01 version. Brian > > We kind of beaten this issue to death.. and that's the reason for which > I ended up adding all the text that I added to the I-D. > > There's people working on implementations of this document, so we should > progress it in a timely fashion. Besides, my personal sense of the wg is > that all of the comments I received were addressed, and that there's > general agreement to move the document forward. > > So, procedurally-speaking, I don't understand the basis of stalling this > document. > > Cheers, From Anders_Brandt@sigmadesigns.com Tue Jun 18 23:45:14 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291E121F9F66 for ; Tue, 18 Jun 2013 23:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yoc08Xq3sDA for ; Tue, 18 Jun 2013 23:45:10 -0700 (PDT) Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id 24FF121F9F61 for ; Tue, 18 Jun 2013 23:45:09 -0700 (PDT) From: Anders Brandt To: "ipv6@ietf.org" Subject: FW: [6lowpan] New Version Notification for draft-brandt-6man-lowpanz-01.txt Thread-Topic: [6lowpan] New Version Notification for draft-brandt-6man-lowpanz-01.txt Thread-Index: AQHOQCkTk08wLi/OM0C22BuY90C/tZk88KIA Date: Wed, 19 Jun 2013 06:45:08 +0000 Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD2D8DCF94@cph-ex1> References: <20130423134356.11747.20964.idtracker@ietfa.amsl.com> <03F31C213F2C6941BFDDBB4336E9E6CD20E0676F@cph-ex1> In-Reply-To: <03F31C213F2C6941BFDDBB4336E9E6CD20E0676F@cph-ex1> Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FEAS-SYSTEM-WL: anders_brandt@sigmadesigns.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 06:45:14 -0000 A new version of I-D, draft-brandt-6man-lowpanz-02.txt has been posted to t= he IETF repository. Filename: draft-brandt-6man-lowpanz Revision: 02 Title: Transmission of IPv6 packets over ITU-T G.9959 Networks Creation date: 2013-06-18 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-brandt-6man-lowp= anz-02.txt Status: http://datatracker.ietf.org/doc/draft-brandt-6man-lowpanz Htmlized: http://tools.ietf.org/html/draft-brandt-6man-lowpanz-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-brandt-6man-lowpa= nz-02 Abstract: This document describes the frame format for transmission of IPv6 packets and a method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks. Cheers, Anders Brandt = =20 From Anders_Brandt@sigmadesigns.com Wed Jun 19 00:05:06 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C36821F9F6E; Wed, 19 Jun 2013 00:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXnJUGrHHH9m; Wed, 19 Jun 2013 00:05:01 -0700 (PDT) Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF5921F8628; Wed, 19 Jun 2013 00:05:01 -0700 (PDT) From: Anders Brandt To: "ipv6@ietf.org" Subject: Adoption of draft-brandt-6man-lowpanz as a new 6man WG document Thread-Topic: Adoption of draft-brandt-6man-lowpanz as a new 6man WG document Thread-Index: Ac5suxTkf0Y8BDBNTLiZ0wVlDmvqAg== Date: Wed, 19 Jun 2013 07:04:58 +0000 Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD2D8DD003@cph-ex1> Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.52] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FEAS-SYSTEM-WL: anders_brandt@sigmadesigns.com Cc: "6lowpan@ietf.org" <6lowpan@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 07:05:06 -0000 KENDJ2VkIHRvIDZsb3dwYW5AaWV0Zi5vcmcsIDZsb0BpZXRmLm9yZykNCg0KVGhlIEludGVybmV0 IERyYWZ0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJyYW5kdC02bWFuLWxvd3Bh bnotMDIgd2FzIHN1Ym1pdHRlZCBvbiBKdW5lIDE4LCAyMDEzLg0KDQpTaW5jZSB0aGUgLTAwIHJl dmlzaW9uLCB0aGUgSW50ZXJuZXQgRHJhZnQgaGFzIGJlZW4gdXBkYXRlZCB0byBhZGRyZXNzIGFs bCBjb21tZW50cyByZWNlaXZlZC4NClRoZSBhdXRob3JzIHdvdWxkIHRoZXJlZm9yZSBsaWtlIHRv IGFzayB0aGF0IHRoZSBkb2N1bWVudCBhcyBhZG9wdGVkIGFzIGEgNk1BTiBXRyBkb2N1bWVudC4N Cg0KVGhpcyBkb2N1bWVudCBTSE9VTEQgYmUgb3duZWQgYnkgdGhlIDZMb1dQQU4gV0cuIDZMb1dQ QU4gaXMgaG93ZXZlciBub3QgYWN0aXZlLg0KVGhpcyBkb2N1bWVudCBNQVkgYmUgb3duZWQgYnkg dGhlIDZMbyBXRy4gNkxvIGlzIGhvd2V2ZXIgcGVuZGluZyBhIEJPRiBpbiBCZXJsaW4uDQoNCkZv ciB0aGUgdGltZSBiZWluZywgdGhlIDZNQU4gV0cgaXMgdGhlcmVmb3JlIHByb3Bvc2VkIGFzIHRo ZSBob21lIG9mIHRoaXMgSW50ZXJuZXQgRHJhZnQuDQoNCg0KVGhhbmtzLA0KICBBbmRlcnMgQnJh bmR0DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW5kZXJzIEJyYW5k dA0KPiBTZW50OiAxOS4ganVuaSAyMDEzIDA4OjQ1DQo+IFRvOiA2bG93cGFuQGlldGYub3JnDQo+ IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYnJhbmR0LTZtYW4t bG93cGFuei0wMi50eHQNCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1icmFuZHQt Nm1hbi1sb3dwYW56LTAyLnR4dCBoYXMgYmVlbiBwb3N0ZWQgdG8NCj4gdGhlIElFVEYgcmVwb3Np dG9yeS4NCj4gDQo+IEZpbGVuYW1lOgkgZHJhZnQtYnJhbmR0LTZtYW4tbG93cGFueg0KPiBSZXZp c2lvbjoJIDAyDQo+IFRpdGxlOgkJIFRyYW5zbWlzc2lvbiBvZiBJUHY2IHBhY2tldHMgb3ZlciBJ VFUtVCBHLjk5NTkgTmV0d29ya3MNCj4gQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDYtMTgNCj4gR3Jv dXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IE51bWJlciBvZiBwYWdlczogMTQNCj4gVVJM OiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1i cmFuZHQtNm1hbi1sb3dwYW56LQ0KPiAwMi50eHQNCj4gU3RhdHVzOiAgICAgICAgICBodHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJyYW5kdC02bWFuLWxvd3BhbnoNCj4gSHRt bGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icmFuZHQtNm1h bi1sb3dwYW56LTAyDQo+IERpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtYnJhbmR0LTZtYW4tbG93cGFuei0wMg0KPiANCj4gQWJzdHJhY3Q6DQo+ ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBmcmFtZSBmb3JtYXQgZm9yIHRyYW5zbWlz c2lvbiBvZiBJUHY2DQo+ICAgIHBhY2tldHMgYW5kIGEgbWV0aG9kIG9mIGZvcm1pbmcgSVB2NiBs aW5rLWxvY2FsIGFkZHJlc3NlcyBhbmQNCj4gICAgc3RhdGVsZXNzbHkgYXV0b2NvbmZpZ3VyZWQg SVB2NiBhZGRyZXNzZXMgb24gSVRVLVQgRy45OTU5IG5ldHdvcmtzLg0KPiANCj4gDQo+IENoZWVy cywNCj4gICBBbmRlcnMgQnJhbmR0DQoNCg== From otroan@employees.org Wed Jun 19 00:48:30 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FBD21F9F88 for ; Wed, 19 Jun 2013 00:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rb45b1FP76CW for ; Wed, 19 Jun 2013 00:48:30 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 634D421F9F80 for ; Wed, 19 Jun 2013 00:48:30 -0700 (PDT) Received: from dhcp-10-61-100-174.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id E422E5E61; Wed, 19 Jun 2013 00:48:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Progressing draft-ietf-6man-stable-privacy-addresses (Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-10.txt) From: Ole Troan In-Reply-To: <51C0DFFD.3090302@gmail.com> Date: Wed, 19 Jun 2013 09:48:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130612174513.32059.54189.idtracker@ietfa.amsl.com> <51B8B5F6.4080404@si6networks.com> <51BFEC17.7060207@si6networks.com> <51C041C5.70203@si6networks.com> <51C0DFFD.3090302@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1508) Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Fernando Gont , Brian Haberman , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 07:48:31 -0000 Brian, >>>> ping? >>> We are thinking that it would be good to have a separate draft that >>> describes the current approaches to IID creation and how they effect >>> privacy and tracking. Somewhat along the lines of the email and = chart >>> sent to the IPv6 list by Alissa Cooper. >>>=20 >>> The stable-privacy draft should then wait until that work has >>> progressed. >>=20 >> I'm already working on such I-D.. but I disagree that progrees of = this >> document should depend on such document. Why should it? >=20 > I tend to agree with Fernando. The dependency is the other way round; > stable-privacy-addresses is a reference for the new draft. possibly; difficult to argue how dependencies should go for a yet-to-be = written document. ;-) we're looking at having a session on privacy/tracking and interface = identifiers in Berlin. my suggestion was to do the WGLC for stable-privacy-addresses after = that. > I have the same question about draft-ietf-6man-ug. We responded to > all comments in the -01 version. we will initiate a last call on that ASAP. cheers, Ole= From sm@resistor.net Wed Jun 19 02:15:44 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCACC21F9FC0 for ; Wed, 19 Jun 2013 02:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJRHE7GZVZ78 for ; Wed, 19 Jun 2013 02:15:43 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB3B21F9FA7 for ; Wed, 19 Jun 2013 02:15:43 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r5J9FS8X016073; Wed, 19 Jun 2013 02:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1371633340; bh=ISdJ2OYZ3s6/2mWXBg+H2Nu1N7qzofawJeVKW4Z4DFY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cQeMI6R/Sdggoen9OBolxkzdCujzwR8iDo9U0exrnt2O21kzWO/7crHLDEivWPQnL gE1i47M7BpT55ZXXeSb9Xq/EahSoUVnSmVSt73MGj7Vtw72jl8LstbD4/Fj0uZW77n ElRMQGhBZ6ZaaihKzEtXqHyyes65/rgDdVZE/at4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1371633340; i=@resistor.net; bh=ISdJ2OYZ3s6/2mWXBg+H2Nu1N7qzofawJeVKW4Z4DFY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=o6KmHK3JPrfNhdvaVkHO/BwjNP0AwpsvAS0lMQobA/vVrpovXXtOMDVHCm4E7MdJ7 /lbllp6f1WyXMNcFJztlyLpCt2+GbKwkDdiAOKVWRU1/2Iq0+G29cm3Y6ajGEOnDHY 1Y4duAXw1jWt+6Cr4HD6RMz8RdUfVfd9GJTkgd0M= Message-Id: <6.2.5.6.2.20130619020258.0cfbe2a0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 19 Jun 2013 02:15:21 -0700 To: Ole Troan From: SM Subject: Re: Progressing draft-ietf-6man-stable-privacy-addresses (Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-10.txt) In-Reply-To: References: <20130612174513.32059.54189.idtracker@ietfa.amsl.com> <51B8B5F6.4080404@si6networks.com> <51BFEC17.7060207@si6networks.com> <51C041C5.70203@si6networks.com> <51C0DFFD.3090302@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: 6man-chairs@tools.ietf.org, Fernando Gont , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 09:15:45 -0000 Hi Ole, At 00:48 19-06-2013, Ole Troan wrote: >possibly; difficult to argue how dependencies should go for a >yet-to-be written document. ;-) There was a message asking Fernando to wait because of a yet-to-be-written draft. :-) In my opinion the dependency would be non-normative. There doesn't seem to be much room for argument there. Regards, -sm From fgont@si6networks.com Wed Jun 19 02:35:40 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC07421F9E65 for ; Wed, 19 Jun 2013 02:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE53t5TrS3si for ; Wed, 19 Jun 2013 02:35:36 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 550B721F9DE2 for ; Wed, 19 Jun 2013 02:35:36 -0700 (PDT) Received: from communautedecommunesdusud.rain.fr ([194.250.109.156] helo=[172.16.0.46]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UpEnX-0007uF-42; Wed, 19 Jun 2013 11:35:27 +0200 Message-ID: <51C17B59.50103@si6networks.com> Date: Wed, 19 Jun 2013 11:35:21 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ole Troan Subject: Re: Progressing draft-ietf-6man-stable-privacy-addresses (Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-10.txt) References: <20130612174513.32059.54189.idtracker@ietfa.amsl.com> <51B8B5F6.4080404@si6networks.com> <51BFEC17.7060207@si6networks.com> <51C041C5.70203@si6networks.com> <51C0DFFD.3090302@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Brian Haberman , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 09:35:40 -0000 On 06/19/2013 09:48 AM, Ole Troan wrote: >> >> I tend to agree with Fernando. The dependency is the other way round; >> stable-privacy-addresses is a reference for the new draft. > > possibly; difficult to argue how dependencies should go for a yet-to-be written document. ;-) > we're looking at having a session on privacy/tracking and interface identifiers in Berlin. > my suggestion was to do the WGLC for stable-privacy-addresses after that. Just to get a clear picture: * We're stalling a wg item because you think that draft-ietf-stable-privacy-addresses should have a (normative?) reference to a document that the wg did not even express interest in? * I went through the energy-consuming exercise of addressing all the comments we had received. But now the document is stalled for other reason. * Has the wg ever decided to wait till July/August (1.5 months from now) to ship the document? -- So far, all comments I've seen (at least 5) have argued in favor of shipping the document... so it looks like there's consensus on shipping... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From otroan@employees.org Wed Jun 19 03:21:16 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C8B21F91A5 for ; Wed, 19 Jun 2013 03:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtTe1yofRxK1 for ; Wed, 19 Jun 2013 03:21:09 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 803B021F91BF for ; Wed, 19 Jun 2013 03:21:09 -0700 (PDT) Received: from dhcp-10-61-100-174.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 905F65F12; Wed, 19 Jun 2013 03:21:04 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Progressing draft-ietf-6man-stable-privacy-addresses (Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-10.txt) From: Ole Troan In-Reply-To: <6.2.5.6.2.20130619020258.0cfbe2a0@resistor.net> Date: Wed, 19 Jun 2013 12:20:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5DE8710C-5715-48EF-87F9-D2C78AFB2CDF@employees.org> References: <20130612174513.32059.54189.idtracker@ietfa.amsl.com> <51B8B5F6.4080404@si6networks.com> <51BFEC17.7060207@si6networks.com> <51C041C5.70203@si6networks.com> <51C0DFFD.3090302@gmail.com> <6.2.5.6.2.20130619020258.0cfbe2a0@resistor.net> To: SM X-Mailer: Apple Mail (2.1508) Cc: 6man-chairs@tools.ietf.org, Fernando Gont , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 10:21:17 -0000 SM, >> possibly; difficult to argue how dependencies should go for a = yet-to-be written document. ;-) >=20 > There was a message asking Fernando to wait because of a = yet-to-be-written draft. :-) In my opinion the dependency would be = non-normative. There doesn't seem to be much room for argument there. the action is on the chairs to initiate the WGLC, and subsequently to = review the document. given the discussion on the list, we are planning a larger session on = privacy, tracking and the interface identifier in Berlin. I thought it would make sense to do the last call on this document, = after that discussion. personally I would have preferred to scale back the stable-privacy = document, and move some of the general privacy and tracking discussion to a more general draft. the other consideration is also, what's the sudden rush? given that = interface-id generation is a local implementation specific matter, there is nothing stopping someone who = wants different interface-id's today to go out and implement them. cheers, Ole From ietf@rozanak.com Wed Jun 19 04:08:23 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599E021F9C1F for ; Wed, 19 Jun 2013 04:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTMOcP9qRtTD for ; Wed, 19 Jun 2013 04:08:17 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 7530821F8717 for ; Wed, 19 Jun 2013 04:08:15 -0700 (PDT) Received: from FB10H117WS01 ([141.89.226.146]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MIdk0-1UrTAa2ehE-002IY4; Wed, 19 Jun 2013 07:08:10 -0400 From: "Hosnieh Rafiee" To: "'Ole Troan'" , "'SM'" References: <20130612174513.32059.54189.idtracker@ietfa.amsl.com> <51B8B5F6.4080404@si6networks.com> <51BFEC17.7060207@si6networks.com> <51C041C5.70203@si6networks.com> <51C0DFFD.3090302@gmail.com> <6.2.5.6.2.20130619020258.0cfbe2a0@resistor.net> <5DE8710C-5715-48EF-87F9-D2C78AFB2CDF@employees.org> In-Reply-To: <5DE8710C-5715-48EF-87F9-D2C78AFB2CDF@employees.org> Subject: RE: Progressing draft-ietf-6man-stable-privacy-addresses (Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-10.txt) Date: Wed, 19 Jun 2013 13:07:55 +0200 Message-ID: <000001ce6cdd$48df77a0$da9e66e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5s1s5IfVsOES3oQICVVIsoaxCtcQABEIWA Content-Language: de X-Provags-ID: V02:K0:/T5yCBGr1QtDxr967n1kfHE4MWTow8Kg8mmltNIgJHP K0A35rgtEiTWi1/KRKibJpyaFrlalfiIm1+VmHpm0bHv09M7Sa 5CXy7N4LmOuWlL9xxMlMumG6wNgpDxXTydGy8y3bYS+eV6tcZg /nxtz064AtIcsPqQO7c8YOI5lNtiYy9k80c9c1WkpwC+P48uXT uuhYaWU6AVvIdRH9uflAEAjrxPj7kCW/JTfzE8LDF6AeXkDhg5 t5p2mqRoAe9PgeaZlxDDFSNsGjmOZ3FpKht6L9b0WtgjNbz85R rTTEnwR8AqIn5d+63DorTCWHFrpuh1+077ZcFY3xVi+GpXiTpe UiCfCHg0mnCqU/k4B8hk= Cc: 6man-chairs@tools.ietf.org, 'Fernando Gont' , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 11:08:23 -0000 Ole, In my opinion, if you would prefer an absolute privacy, then changing = the IP address is not a complete solution and you need also to use an = encryption approach to protect users' data at least in higher layers. So all of the current active drafts can provide privacy to some extend which highly depends on some factors such as: How they maintain the lifetime of the address, the security mechanisms = in used (firewalls, etc) , etc. >=20 > >> possibly; difficult to argue how dependencies should go for a > >> yet-to-be written document. ;-) > > > > There was a message asking Fernando to wait because of a yet-to-be- > written draft. :-) In my opinion the dependency would be non- > normative. There doesn't seem to be much room for argument there. >=20 > the action is on the chairs to initiate the WGLC, and subsequently to > review the document. > given the discussion on the list, we are planning a larger session on > privacy, tracking and the interface identifier in Berlin. >=20 > I thought it would make sense to do the last call on this document, > after that discussion. >=20 > personally I would have preferred to scale back the stable-privacy > document, and move some of the general privacy and tracking discussion > to a more general draft. > the other consideration is also, what's the sudden rush? given that > interface-id generation is a local implementation specific matter, > there is nothing stopping someone who wants different interface-id's > today to go out and implement them. Regards, Hosnieh, Gesendet =FCber MYMAIL f=FCr Android From otroan@employees.org Wed Jun 19 04:18:36 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9119721F99FB for ; Wed, 19 Jun 2013 04:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiu4LoMgmIn9 for ; Wed, 19 Jun 2013 04:18:30 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id C362221F99F7 for ; Wed, 19 Jun 2013 04:18:30 -0700 (PDT) Received: from dhcp-10-61-100-174.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 5379A5E61; Wed, 19 Jun 2013 04:18:23 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Progressing draft-ietf-6man-stable-privacy-addresses (Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-10.txt) From: Ole Troan In-Reply-To: <000001ce6cdd$48df77a0$da9e66e0$@com> Date: Wed, 19 Jun 2013 13:18:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130612174513.32059.54189.idtracker@ietfa.amsl.com> <51B8B5F6.4080404@si6networks.com> <51BFEC17.7060207@si6networks.com> <51C041C5.70203@si6networks.com> <51C0DFFD.3090302@gmail.com> <6.2.5.6.2.20130619020258.0cfbe2a0@resistor.net> <5DE8710C-5715-48EF-87F9-D2C78AFB2CDF@employees.org> <000001ce6cdd$48df77a0$da9e66e0$@com> To: "Hosnieh Rafiee" X-Mailer: Apple Mail (2.1508) Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, 'Fernando Gont' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 11:18:36 -0000 Hosnieh, > In my opinion, if you would prefer an absolute privacy, then changing = the IP > address is not a complete solution and you need also to use an = encryption > approach to protect users' data at least in higher layers. So all of = the > current active drafts can provide privacy to some extend which highly > depends on some factors such as: > How they maintain the lifetime of the address, the security mechanisms = in > used (firewalls, etc) , etc. I think we in this context only should focus on the effects = interface-ids have on privacy and tracking. the larger issue is out of scope for 6man.=20 cheers, Ole= From ietf@rozanak.com Wed Jun 19 10:10:26 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C06D21F9E29 for ; Wed, 19 Jun 2013 10:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOF1Ds8ESx+Z for ; Wed, 19 Jun 2013 10:10:20 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 31D3421F9E0C for ; Wed, 19 Jun 2013 10:10:20 -0700 (PDT) Received: from kopoli (e179166044.adsl.alicedsl.de [85.179.166.44]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MEXD7-1V4Sz61tl3-00G04R; Wed, 19 Jun 2013 13:09:48 -0400 From: "Hosnieh Rafiee" To: "'Ole Troan'" References: <20130612174513.32059.54189.idtracker@ietfa.amsl.com> <51B8B5F6.4080404@si6networks.com> <51BFEC17.7060207@si6networks.com> <51C041C5.70203@si6networks.com> <51C0DFFD.3090302@gmail.com> <6.2.5.6.2.20130619020258.0cfbe2a0@resistor.net> <5DE8710C-5715-48EF-87F9-D2C78AFB2CDF@employees.org> <000001ce6cdd$48df77a0$da9e66e0$@com> In-Reply-To: Subject: RE: Progressing draft-ietf-6man-stable-privacy-addresses (Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-10.txt) Date: Wed, 19 Jun 2013 19:09:36 +0200 Message-ID: <000001ce6d0f$cd4521c0$67cf6540$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: Ac5s3rs5t4oRu7eEGO2yPy2k8cjsUAAAGr6Q Content-Language: en-us X-Provags-ID: V02:K0:jZlbs1PG/hMciM8GuYwdZmjEFCr6TKIJo5PJ9rI9xvr PfHyCLN/vGRD6rBBS9wYP+CKc32Oh9H9KGnj0BPIYC9OChcu/B 1YzczphVg4KI88XNUxW2lRrzY+1VVuvPIcpLOLRD7WGkEvFZ04 LQRHo9LjQlquLynbnllMgQu+Lsv/B+6HgXHavKA4j9q1DPh0Mt nt11KodL4/Qi9vQqQxXALTKAMQSm/x2Cf8/pfNw4bfm79r3qyZ RXaIEfJXgaMb0la+e2JdsIrMay/OKMxrtV9JRt3kZ8un05SN3n h6H9BzDuwwk2LmAL86MWNZKY7V09bYr0K8fXJZLqBLTJVggGl2 lkcbEQfR6bVHKfo1WTfY= Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, 'Fernando Gont' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 17:10:26 -0000 Ole, > > I think we in this context only should focus on the effects interface- > ids have on privacy and tracking. the larger issue is out of scope for > 6man. I am not sure about your response. What I understand here is that if you cannot track a node means then the node has privacy and if you can track it, then the privacy of the node is in doubt. What is the purpose of scanning here? Why is tracking a node important? What is to be gained from a users' IP addresses (location information) if you are not going to use it to obtain the user's information and then carry out other malicious endeavors? - I do think that it is because you want to obtain a user's information which is in the upper layers. Or does one scan just for the purpose of learning which ports are open which are not so that attacks can be initiated against nodes via their open ports or attacks initiated against a particular network? In my opinion, if the purpose of your scan is the last one, then this is a security issue. If it concerns users' information, then it is a privacy issue. If you think that it is out of the scope of this group to deal with the users' data, then it is probably not the right place to discuss users' privacy issues too. Thanks, Hosnieh From dougb@dougbarton.us Wed Jun 19 10:44:45 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187F621F9D5D for ; Wed, 19 Jun 2013 10:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzH75Gnrnl1K for ; Wed, 19 Jun 2013 10:44:39 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id A118A21F9D70 for ; Wed, 19 Jun 2013 10:44:38 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:224:e8ff:fe30:109b] (unknown [IPv6:2001:470:d:5e7:224:e8ff:fe30:109b]) by dougbarton.us (Postfix) with ESMTPSA id 36CE422B6A for ; Wed, 19 Jun 2013 17:44:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1371663877; bh=MCuVllYoVOWXHS9b176IZdaljeZ1g+2Fr4Eq2d7bM8Y=; h=Date:From:To:Subject:References:In-Reply-To; b=bqwPgrI28sfLVXyaJ28noYtydGGn2j+vo3I5dPJQF2IG2tzUtHnZ+UbsD3tDuqCgW b54Pqtf0PzskVGERHydLQad1ilNHgMxihX5TcdZhWJx6/ifBVlUepnVYIpKVUaZZJS extrbC184IPbBMnq4G9HssZaH1kKYrOf27rifF08= Message-ID: <51C1EE04.5000901@dougbarton.us> Date: Wed, 19 Jun 2013 10:44:36 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Progressing draft-ietf-6man-stable-privacy-addresses (Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-10.txt) References: <20130612174513.32059.54189.idtracker@ietfa.amsl.com> <51B8B5F6.4080404@si6networks.com> <51BFEC17.7060207@si6networks.com> <51C041C5.70203@si6networks.com> <51C0DFFD.3090302@gmail.com> <6.2.5.6.2.20130619020258.0cfbe2a0@resistor.net> <5DE8710C-5715-48EF-87F9-D2C78AFB2CDF@employees.org> <000001ce6cdd$48df77a0$da9e66e0$@com> <000001ce6d0f$cd4521c0$67cf6540$@rozanak.com> In-Reply-To: <000001ce6d0f$cd4521c0$67cf6540$@rozanak.com> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 17:44:45 -0000 On 06/19/2013 10:09 AM, Hosnieh Rafiee wrote: > In my opinion, if the purpose of your scan is the last one, then this is a > security issue. If it concerns users' information, then it is a privacy > issue. If you think that it is out of the scope of this group to deal with > the users' data, then it is probably not the right place to discuss users' > privacy issues too. Hosnieh, It seems that you are combining too many things into the same category, and trying to make "all or nothing" judgments about them. If I'm right about that (and I very well might not be) then I think your perspective is wrong. The original purpose of what became 4941 was to avoid the stable lower 64 bits of an address being used by third parties to track a device/user as it moved from network to network. Referring to them as "privacy" addresses was a convenient shorthand that more or less accurately conveys their intended purpose. However 3041 was published in 2001, and even though IP address related tracking was still the primary method of user tracking on the web (which was the primary, but not exclusive motivator for the privacy extensions in the first place) at the time 3041 was written it was already being replaced by other, more sophisticated methods. Now IP addresses are merely 1 data point in the vast ocean of data that is collected for a user on the web, and because of NAT and other reasons it is not even relied on that heavily. So at least in terms of web-related stuff, 4941, or other similar mechanisms, are of very limited utility for protecting users' privacy. One can make the argument that they are useful in other areas however, so to be clear I'm not suggesting that we remove them. For what it's worth I am in agreement that the larger topics of communication security are outside the scope of this WG. In relation to draft-ietf-6man-stable-privacy-addresses I remain unconvinced that it is necessary at all, and oppose its publication. There are 2 well-defined use cases, places where addresses need to be tracked (like businesses), and places where they don't. If addresses need to be tracked, turn off 4941. If they don't, you can turn it on. I have yet to see a convincing argument for a third use case that would be covered by the draft, and at this point any changes to the IPv6 spec need a VERY convincing use case. Doug From markzzzsmith@yahoo.com.au Wed Jun 19 14:40:45 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF8911E80E6 for ; Wed, 19 Jun 2013 14:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWVuVYVGtEuQ for ; Wed, 19 Jun 2013 14:40:40 -0700 (PDT) Received: from nm34-vm5.bullet.mail.bf1.yahoo.com (nm34-vm5.bullet.mail.bf1.yahoo.com [72.30.239.77]) by ietfa.amsl.com (Postfix) with ESMTP id E489421F9F34 for ; Wed, 19 Jun 2013 14:40:39 -0700 (PDT) Received: from [98.139.212.149] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 19 Jun 2013 21:40:38 -0000 Received: from [98.139.212.214] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 19 Jun 2013 21:40:38 -0000 Received: from [127.0.0.1] by omp1023.mail.bf1.yahoo.com with NNFMP; 19 Jun 2013 21:40:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 732982.98795.bm@omp1023.mail.bf1.yahoo.com Received: (qmail 60248 invoked by uid 60001); 19 Jun 2013 21:40:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1371678038; bh=NHaDL6xqWBVXr6NqgGPqAgY5FII9CAqfiTnSZ6KtH4s=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=PR/olu8HV85TOAGwp9+4ZCw6Ete/DZqMcgel6GNb3uJWG9KIQkNhtgHpqqa6s6T5avOuWZ99KsN1TgJ3OxLlKPVMr0nkz0Dmg2ozQbzMHArulLF2wVPVhopNVG1lKwTv+XkoiGa/57l1eNQCn7efWb4XeJSoOJTAyRP+a56mRM8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cq7UsNRLS0rYwUZsfOi9LKgYOT8Wm55VabxqnATc2RzgeAdLMsWgDJw/MXTHg07cQIQB6H+j2R/b7wkuFqtM7xPEdO79jcaTQQnsNeLB/IL7xCb9L1tTmE5LHUrpCj6fXvEgHid4bPbskxPomDPHj65Hoqgj0WbdlothfOg3Bak=; X-YMail-OSG: 5DSejsQVM1ncXmzINAyLtgEUUJGSX4fLCkUMvDGnlNeR70a NpdG6Z.Vme69xoyo8CH19U3i.gx9roW8ztk2M6EUDyUkXZsIIeh.yQVyeclY J4xJrDdryrLRHw87khXu9sDBGo1Y.Pip6ta9HMSL_HWeRJ_7LsBxOIHvDszt rc6949I3kHThJBIgjYR9wgOWXirvgKbuEdv6ntjqJzpVoLjdOTytlP.zI_A7 a_gBBlNeoeCNHrrmnxbnDwHIHtC0bks2U3q9W7oa93pAxfNsJUVIGm6lSFgd BiMDEj7kccBdc_U.sqMrb28laRbBRK1BIfWCHYWMFn5EcRi9hPYwh_YL.TCF sFr..QQgRiToWtJ48YCnHDKmXO2tznYIebNotN4VVwonPRZFAcVflJeKH4TK dMKVj.k8CDaKf4YbxwofdcoAY4swb3ANlcRhmiU3NPpRui0UfPLNybM4yY.4 p5rGT35J7azH1WCKulaeDJLQ8aaN1hSqX20Xe7xYUVBvPBNlNxYKKWM4LDPa UaRpoHxRmvxVIYuQx8u7RBuI69zrHtdHCc3b1raeSQbRuwxjZr5Vmqw26OUp Am1S6Q9nXNuKy Received: from [150.101.221.237] by web142504.mail.bf1.yahoo.com via HTTP; Wed, 19 Jun 2013 14:40:38 PDT X-Rocket-MIMEInfo: 002.001, CjxzbmlwPgoKPgo.SW4gcmVsYXRpb24gdG8gZHJhZnQtaWV0Zi02bWFuLXN0YWJsZS1wcml2YWN5LWFkZHJlc3NlcyBJIHJlbWFpbiAKPnVuY29udmluY2VkIHRoYXQgaXQgaXMgbmVjZXNzYXJ5IGF0IGFsbCwgYW5kIG9wcG9zZSBpdHMgcHVibGljYXRpb24uwqAKCkkgdGhpbmsgd2hhdCBpcyBwcm9wb3NlZCBpcyBhIHVzZWZ1bCBpbXByb3ZlbWVudC4KCk5vdGUgdGhhdCBmb3IgcHVibGljYXRpb24gdG8gaGFwcGVuLCByb3VnaCBjb25zZW5zdXMgbmVlZHMgdG8gYmUgcmVhY2hlZCwgbm90IHVuYW5pbWl0eS4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.147.553 References: <20130612174513.32059.54189.idtracker@ietfa.amsl.com> <51B8B5F6.4080404@si6networks.com> <51BFEC17.7060207@si6networks.com> <51C041C5.70203@si6networks.com> <51C0DFFD.3090302@gmail.com> <6.2.5.6.2.20130619020258.0cfbe2a0@resistor.net> <5DE8710C-5715-48EF-87F9-D2C78AFB2CDF@employees.org> <000001ce6cdd$48df77a0$da9e66e0$@com> <000001ce6d0f$cd4521c0$67cf6540$@rozanak.com> <51C1EE04.5000901@dougbarton.us> Message-ID: <1371678038.57972.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Wed, 19 Jun 2013 14:40:38 -0700 (PDT) From: Mark Smith Subject: Re: Progressing draft-ietf-6man-stable-privacy-addresses (Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-10.txt) To: Doug Barton , "ipv6@ietf.org" In-Reply-To: <51C1EE04.5000901@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 21:40:45 -0000 =0A=0A=0A>=0A>In relation to draft-ietf-6man-stable-privacy-addresses= I remain =0A>unconvinced that it is necessary at all, and oppose its publi= cation.=A0=0A=0AI think what is proposed is a useful improvement.=0A=0ANote= that for publication to happen, rough consensus needs to be reached, not u= nanimity. =A0=0A=0A=0A>There are 2 well-defined use cases, places where add= resses need to be =0A>tracked (like businesses),=0A=0AThe problem is that t= his also allows tracking in the Internet. Business uses want to track devic= es internally, but would also want to minimise tracking on the Internet. Th= is is the middle ground between existing L2 derived IIDs and RFC4941s. I ge= nerally don't agree with the idea of using layer 2 or layer 3 addresses to = identify people because I don't think they're tightly coupled enough. Howev= er, I still think there is a useful benefit in not exposing globally unique= link layer addresses beyond the scope of where they're necessary i.e. on t= he link itself. Minimising information disclosure is a good security and pr= ivacy principle.=0A=0A=0A> and places where they don't. If addresses =0A>ne= ed to be tracked, turn off 4941. If they don't, you can turn it on.=0A=0ATh= e other benefit of this approach is that it breaks the coupling between lay= er 2 interface addresses and layer 3 addresses, such that changing the laye= r 2 interface would not change the layer 3 address. This has been a common = complaint from some server and networking people. While static addressing c= an easily overcome that issue, it is useful to have defaults that don't cre= ate the issue in the first place.=0A=0AMy view is that, for devices that do= n't enable RFC4941 by default, this method should be the new default way of= generating IPv6 IIDs.=0A=0A> I =0A>have yet to see a convincing argument f= or a third use case that would be =0A>covered by the draft, and at this poi= nt any changes to the IPv6 spec =0A>need a VERY convincing use case.=0A>=0A= =0AI think it always depends on the cost of the changes verses the benefits= . In this specific case, the costs of deploying this change are comparative= ly minor:=0A=0Ao it can be deployed in a piecemeal, device by device manner= =0A=0Ao it only needs to be implemented on devices that care about the priv= acy of addresses (where RFC4941 are "too private") or those which would ben= efit from IIDs that are not as tightly coupled to the link-layer interface = adresses (typically servers or routers)=0A=0Ao it doesn't require any chang= es to on-the-wire protocols=A0=0A=0Ao it can be implemented via user space = processes, rather than requiring an OS upgrade, although an OS upgrade is p= robably preferable=0A=0AOne of the fundamental drawbacks of IPv6 is that it= was designed in the early to mid 1990s. That was necessary because the pri= mary problem it was dealing with was the running out of IPv4 addresses. Of = course other techniques that came along that delayed that problem having a = significant effect. However, in the mean time adoption of the Internet as e= xploded, and a lot of lessons have and are being learned about how it will = be both used and abused. Ideally we could stop development and deployment o= f IPv6, and design and deploy IPv10 with the benefit of both IPv4 and IPv6 = hindsight. That is unfortunately impractical, because we finally now need a= solution to IPv4 addresses running out, rather than one in 5 to 10 or more= years. Incremental improvement rather than radical change (requiring a ver= sion bump) to IPv6 is the only choice we have.=0A=0ARegards,=0AMark. From otroan@employees.org Thu Jun 20 00:13:55 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD0121E80DB for ; Thu, 20 Jun 2013 00:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lj0DvWc2oZKI for ; Thu, 20 Jun 2013 00:13:49 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6E92621E80B0 for ; Thu, 20 Jun 2013 00:13:49 -0700 (PDT) Received: from dhcp-10-61-101-188.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 3B8B65EF6; Thu, 20 Jun 2013 00:13:46 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Progressing draft-ietf-6man-stable-privacy-addresses (Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-10.txt) From: Ole Troan In-Reply-To: <1371678038.57972.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Thu, 20 Jun 2013 09:13:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <73559E9D-A99B-4E49-8767-AE8309159FB6@employees.org> References: <20130612174513.32059.54189.idtracker@ietfa.amsl.com> <51B8B5F6.4080404@si6networks.com> <51BFEC17.7060207@si6networks.com> <51C041C5.70203@si6networks.com> <51C0DFFD.3090302@gmail.com> <6.2.5.6.2.20130619020258.0cfbe2a0@resistor.net> <5DE8710C-5715-48EF-87F9-D2C78AFB2CDF@employees.org> <000001ce6cdd$48df77a0$da9e66e0$@com> <000001ce6d0f$cd4521c0$67cf6540$@rozanak.com> <51C1EE04.5000901@dougbarton.us> <1371678038.57972.YahooMailNeo@web142504.mail.bf1.yahoo.com> To: Mark Smith X-Mailer: Apple Mail (2.1508) Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 07:13:55 -0000 >> In relation to draft-ietf-6man-stable-privacy-addresses I remain=20 >> unconvinced that it is necessary at all, and oppose its publication.=20= >=20 > I think what is proposed is a useful improvement. >=20 > Note that for publication to happen, rough consensus needs to be = reached, not unanimity. =20 >=20 >=20 >> There are 2 well-defined use cases, places where addresses need to be=20= >> tracked (like businesses), >=20 > The problem is that this also allows tracking in the Internet. = Business uses want to track devices internally, but would also want to = minimise tracking on the Internet. This is the middle ground between = existing L2 derived IIDs and RFC4941s. I generally don't agree with the = idea of using layer 2 or layer 3 addresses to identify people because I = don't think they're tightly coupled enough. However, I still think there = is a useful benefit in not exposing globally unique link layer addresses = beyond the scope of where they're necessary i.e. on the link itself. = Minimising information disclosure is a good security and privacy = principle. wouldn't a business that require tracking devices internally use DHCP? the DHCP server could use mechanisms similar to what we are discussing = for SLAAC, or any other algorithm to create addresses that have properties making them hard to track = externally. I also think it is a useful benefit of not exposing link-layer addresses = in the IPv6 address. >> and places where they don't. If addresses=20 >> need to be tracked, turn off 4941. If they don't, you can turn it on. >=20 > The other benefit of this approach is that it breaks the coupling = between layer 2 interface addresses and layer 3 addresses, such that = changing the layer 2 interface would not change the layer 3 address. = This has been a common complaint from some server and networking people. = While static addressing can easily overcome that issue, it is useful to = have defaults that don't create the issue in the first place. even with the mechanisms discussed either the address needs to be stored = in persistent storage, or one have to be very careful about the = interface-id generation mechanism to make it independent of a change of = L2 address. > My view is that, for devices that don't enable RFC4941 by default, = this method should be the new default way of generating IPv6 IIDs. Fernando is making a good point that these addresses should be the = default method even when RFC4941 is enabled by default. the bigger question is how applications and the host stack should behave = with regards to all these addresses? should a host that isn't advertising any services even configure a = public address? I'm not sure the issue of how applications should deal with the plethora = of addresses with varying lifetimes and properties are in the scope of 6man, but it would certainly be = interesting to hear the views of someone from the apps area. >> have yet to see a convincing argument for a third use case that would = be=20 >> covered by the draft, and at this point any changes to the IPv6 spec=20= >> need a VERY convincing use case. >>=20 >=20 > I think it always depends on the cost of the changes verses the = benefits. In this specific case, the costs of deploying this change are = comparatively minor: >=20 > o it can be deployed in a piecemeal, device by device manner >=20 > o it only needs to be implemented on devices that care about the = privacy of addresses (where RFC4941 are "too private") or those which = would benefit from IIDs that are not as tightly coupled to the = link-layer interface adresses (typically servers or routers) >=20 > o it doesn't require any changes to on-the-wire protocols=20 >=20 > o it can be implemented via user space processes, rather than = requiring an OS upgrade, although an OS upgrade is probably preferable indeed, and you can even argue over the need to standardize something = that isn't on-the wire and cannot be tested externally. > One of the fundamental drawbacks of IPv6 is that it was designed in = the early to mid 1990s. That was necessary because the primary problem = it was dealing with was the running out of IPv4 addresses. Of course = other techniques that came along that delayed that problem having a = significant effect. However, in the mean time adoption of the Internet = as exploded, and a lot of lessons have and are being learned about how = it will be both used and abused. Ideally we could stop development and = deployment of IPv6, and design and deploy IPv10 with the benefit of both = IPv4 and IPv6 hindsight. That is unfortunately impractical, because we = finally now need a solution to IPv4 addresses running out, rather than = one in 5 to 10 or more years. Incremental improvement rather than = radical change (requiring a version bump) to IPv6 is the only choice we = have. hmmm... thats quickly going to become a rat-hole, but I'm not convinced = that we would have designed IPv6 very differently if we had done it = today. cheers, Ole= From rbonica@juniper.net Thu Jun 20 08:55:44 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705D021F9E3B for ; Thu, 20 Jun 2013 08:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.426 X-Spam-Level: X-Spam-Status: No, score=-100.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyW-aQHkZxBD for ; Thu, 20 Jun 2013 08:55:28 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id B529221F9E30 for ; Thu, 20 Jun 2013 08:55:25 -0700 (PDT) Received: from mail132-ch1-R.bigfish.com (10.43.68.229) by CH1EHSOBE022.bigfish.com (10.43.70.79) with Microsoft SMTP Server id 14.1.225.23; Thu, 20 Jun 2013 15:55:22 +0000 Received: from mail132-ch1 (localhost [127.0.0.1]) by mail132-ch1-R.bigfish.com (Postfix) with ESMTP id E0B033001FA for ; Thu, 20 Jun 2013 15:55:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz9371I936eI542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2fh2a8h683h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail132-ch1: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=rbonica@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail132-ch1 (localhost.localdomain [127.0.0.1]) by mail132-ch1 (MessageSwitch) id 1371743721535559_19968; Thu, 20 Jun 2013 15:55:21 +0000 (UTC) Received: from CH1EHSMHS041.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.240]) by mail132-ch1.bigfish.com (Postfix) with ESMTP id 8094D2205AB for ; Thu, 20 Jun 2013 15:55:21 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.53) by CH1EHSMHS041.bigfish.com (10.43.69.250) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 20 Jun 2013 15:55:20 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 20 Jun 2013 08:55:20 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Thu, 20 Jun 2013 08:55:19 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.12) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 20 Jun 2013 09:07:17 -0700 Received: from mail16-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.23; Thu, 20 Jun 2013 15:55:18 +0000 Received: from mail16-va3 (localhost [127.0.0.1]) by mail16-va3-R.bigfish.com (Postfix) with ESMTP id 59F613A0277 for ; Thu, 20 Jun 2013 15:55:18 +0000 (UTC) Received: from mail16-va3 (localhost.localdomain [127.0.0.1]) by mail16-va3 (MessageSwitch) id 1371743716794911_28120; Thu, 20 Jun 2013 15:55:16 +0000 (UTC) Received: from VA3EHSMHS031.bigfish.com (unknown [10.7.14.228]) by mail16-va3.bigfish.com (Postfix) with ESMTP id BDF5C220083 for ; Thu, 20 Jun 2013 15:55:16 +0000 (UTC) Received: from BY2PRD0512HT003.namprd05.prod.outlook.com (157.56.238.5) by VA3EHSMHS031.bigfish.com (10.7.99.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 20 Jun 2013 15:55:16 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.17]) by BY2PRD0512HT003.namprd05.prod.outlook.com ([10.255.243.36]) with mapi id 14.16.0324.000; Thu, 20 Jun 2013 15:55:12 +0000 From: Ronald Bonica To: "ipv6@ietf.org 6man-wg" Subject: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHObc3OGhJfZWsTvkmEF1gJL7lsrZk+wGpw Date: Thu, 20 Jun 2013 15:55:11 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 15:55:44 -0000 Rm9sa3MsDQoNClBsZWFzZSByZXZpZXcgdGhpcyBkcmFmdCBhbmQgcHJvdmlkZSBjb21tZW50cy4N Cg0KICAgICAgICAgICAgICAgICAgICAgIFJvbg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnXQ0KPiBTZW50OiBUaHVyc2RheSwgSnVuZSAyMCwgMjAxMyAxMTo0OCBB TQ0KPiBUbzogUm9uYWxkIEJvbmljYQ0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWJvbmljYS02bWFuLWZyYWctZGVwcmVjYXRlLQ0KPiAwMC50eHQNCj4gDQo+ IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYm9uaWNhLTZtYW4tZnJhZy1kZXByZWNh dGUtMDAudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUm9uIEJvbmlj YSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGDQo+IHJlcG9zaXRvcnkuDQo+IA0KPiBGaWxlbmFtZToJ IGRyYWZ0LWJvbmljYS02bWFuLWZyYWctZGVwcmVjYXRlDQo+IFJldmlzaW9uOgkgMDANCj4gVGl0 bGU6CQkgSVB2NiBGcmFnbWVudCBIZWFkZXIgRGVwcmVjYXRlZA0KPiBDcmVhdGlvbiBkYXRlOgkg MjAxMy0wNi0yMA0KPiBHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gTnVtYmVyIG9m IHBhZ2VzOiA3DQo+IFVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtYm9uaWNhLTZtYW4tDQo+IGZyYWctZGVwcmVjYXRlLTAwLnR4dA0KPiBT dGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm9u aWNhLTZtYW4tDQo+IGZyYWctZGVwcmVjYXRlDQo+IEh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm9uaWNhLTZtYW4tZnJhZy0NCj4gZGVwcmVjYXRlLTAw DQo+IA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgbWVtbyBkZXByZWNhdGVzIHRoZSBJUHY2 IEZyYWdtZW50IEhlYWRlci4gIEl0IHByb3ZpZGVzIHJlYXNvbnMNCj4gICAgZm9yIGRlcHJlY2F0 aW9uIGFuZCB1cGRhdGVzIFJGQyAyNDYwLg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IFRoZSBJRVRG IFNlY3JldGFyaWF0DQo+IA0KPiANCg0K From arturo.servin@gmail.com Thu Jun 20 09:37:11 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696FD21F9D30 for ; Thu, 20 Jun 2013 09:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWAYYBSw73HW for ; Thu, 20 Jun 2013 09:37:10 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 732FE21F9D85 for ; Thu, 20 Jun 2013 09:37:10 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz11so6525992pad.30 for ; Thu, 20 Jun 2013 09:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Hei/gt2/N933J4y3L7JRoRqaR7hHLj7xqTKuGtKv5f4=; b=iRFv8eUWYJWcL6IlMp6nerYHcFq6O+JWMj0hxhPZChUHwgZMV9iKmgH4hQ35WJhLok MjRlTrO4T1Svch+JySpxnSXbYULuOjQft5j2z47N/Z5/MNTAkGyDWlEke8PyXIULPVAr Qp8hqpRKd85J9tucfAguJCM7Hs/4H91je0e9Q5iQ13nx/u+alTRna9w4ZNK+vzUMksM8 Hcm73jjq/B1vlleyxAS5fQuNNztCNjJl5/7UVyeOdgNO8hxzWtwTB2c9Pfbl9KC4Ills vVfJrl44ubaH1haZh3HILl13c8oWa5Cvk+ujjCvVyx+ouQiAFHRETdOSGrXZru+Ys8vk /RwQ== X-Received: by 10.68.212.72 with SMTP id ni8mr8183394pbc.114.1371746230169; Thu, 20 Jun 2013 09:37:10 -0700 (PDT) Received: from Arturos-MacBook-Pro.local ([202.183.168.2]) by mx.google.com with ESMTPSA id bs2sm1429649pad.17.2013.06.20.09.37.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 09:37:09 -0700 (PDT) Message-ID: <51C32FA9.1090207@gmail.com> Date: Thu, 20 Jun 2013 23:36:57 +0700 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 16:37:11 -0000 Ron, Warren In general I tent to agree with you. Would you have references or data to back up these two statements? 1) " Most popular TCP [RFC0793] implementations leverage this technology and restrict their segment size so that IP fragmentation is not required." 2) " As a result, IPv6 fragments carrying TCP payload are rarely observed on the Internet." Regards, as On 6/20/13 10:55 PM, Ronald Bonica wrote: > Folks, > > Please review this draft and provide comments. > > Ron > > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Thursday, June 20, 2013 11:48 AM >> To: Ronald Bonica >> Subject: New Version Notification for draft-bonica-6man-frag-deprecate- >> 00.txt >> >> >> A new version of I-D, draft-bonica-6man-frag-deprecate-00.txt >> has been successfully submitted by Ron Bonica and posted to the IETF >> repository. >> >> Filename: draft-bonica-6man-frag-deprecate >> Revision: 00 >> Title: IPv6 Fragment Header Deprecated >> Creation date: 2013-06-20 >> Group: Individual Submission >> Number of pages: 7 >> URL: http://www.ietf.org/internet-drafts/draft-bonica-6man- >> frag-deprecate-00.txt >> Status: http://datatracker.ietf.org/doc/draft-bonica-6man- >> frag-deprecate >> Htmlized: http://tools.ietf.org/html/draft-bonica-6man-frag- >> deprecate-00 >> >> >> Abstract: >> This memo deprecates the IPv6 Fragment Header. It provides reasons >> for deprecation and updates RFC 2460. >> >> >> >> >> >> The IETF Secretariat >> >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From markzzzsmith@yahoo.com.au Thu Jun 20 13:57:05 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C4321F9DB5 for ; Thu, 20 Jun 2013 13:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iicBVIkzMtt for ; Thu, 20 Jun 2013 13:57:00 -0700 (PDT) Received: from nm36-vm5.bullet.mail.bf1.yahoo.com (nm36-vm5.bullet.mail.bf1.yahoo.com [72.30.238.141]) by ietfa.amsl.com (Postfix) with ESMTP id E2FC421F996F for ; Thu, 20 Jun 2013 13:56:57 -0700 (PDT) Received: from [66.196.81.172] by nm36.bullet.mail.bf1.yahoo.com with NNFMP; 20 Jun 2013 20:56:57 -0000 Received: from [98.139.212.244] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 20 Jun 2013 20:56:57 -0000 Received: from [127.0.0.1] by omp1053.mail.bf1.yahoo.com with NNFMP; 20 Jun 2013 20:56:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 111982.42789.bm@omp1053.mail.bf1.yahoo.com Received: (qmail 5615 invoked by uid 60001); 20 Jun 2013 20:56:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1371761816; bh=nlGL+33IwoAAWOME13N3uig94hXrRw4tHHVLes97R/Y=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=u2S00E+1zkQpKgQhhxjBd6Hjc3+m1ORzhUyFm8YZfeXgr0++lk43Mn39X3NT/k/crF91ofbNDLLCI2xyAD2n6a++QJG1bt3fBM3i6xCto+jD2nJ2xKkl1my0db0k68GhBkTe3rts5ZsEd4Br89Wx6B/Tt9vAgPgA7JHq5td8n48= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bpG78hDd/0/9ncdjfcXPh9B5tX5lZaa4LC4B42u2U6lggZ1FjH4Z7cjehOA7jgw7DLdadQjxKX/o10OwJpjqLTUktpiVqBlrMSbx4p1r65dMNcJGs0WTJrNs0DT/V84zjqQNqTXTclvBkwjKdzcjb2ZGdZpCod070w/YO5ZgC90=; X-YMail-OSG: HH0leAkVM1nmYd5MUQnXgNdkgXZvMb_bLAt4lkVWp5kF7Ht BhyHDQV.Rx8Xd7NgEIhb1cQCIB2Q2LQhYaIdAEaiAghD_O9CV4jMo7GmRf.3 gXFZEDN8R9iseJKFvJpbp.eXUald2bBEWyhr9XXF2eIcAnUwDsBrHlMX71c4 tFG2wIp5ehGvE9yxBj8mT5a7nAbtGhcBH.0oMgwKW1G7M3wK7K1o7yS_fL0p 2RA5NfS3tf1P83mjtV2iokhO7GNwV2yKHTGQM7H3Ws0VmGWAjh7w_dMUN1As E3pJhevdRN73_EcWg6ZR_1kAWGIjFTyQ91znCORRwZoVIT6XlCB5edTffU9f jMgN_fLiTCH0vE7C0mQu7NtTjh.fabhe6tIRlT_XDZa7Iq4W5LkMjwvF70s5 tVxHsUbYSYnMTuyfO_Ul7Svwneagvbv.9idxGKJuoIpANK.OSXUboWWYboUH cwQ5jAXip.sFJLcnRn0v937XXQgw00Ai1Kh4yhkpZvKkq4bjvFpjwo1QH04L OiG6mkmHbWIqzVUrK1.meU773_vPqeawGO.84zPX7tRw5UOiES_IgSoQm5Lr Zij3CxyHGGt0- Received: from [150.101.221.237] by web142505.mail.bf1.yahoo.com via HTTP; Thu, 20 Jun 2013 13:56:56 PDT X-Rocket-MIMEInfo: 002.001, SGksCgpJIGFsc28gdGVuZCB0byBhZ3JlZSB3aXRoIHRoaXMgZHJhZnQuIEhvd2V2ZXIsIEknbSB3b25kZXJpbmcgYWJvdXQgaG93IHRoaXMgd2lsbCBlZmZlY3Qgbm9uLVVEUC9UQ1AgcHJvdG9jb2xzIHRoYXQgYXNzdW1lIElQIGxheWVyIGZyYWdtZW50YXRpb24gdG8gdGFrZSBjYXJlIG9mIHRoZWlyIGxhcmdlciBwYXlsb2FkcyBlLmcsIE9TUEY_CgpTQ1RQIGFuZCBEQ0NQIG1pZ2h0IGFsc28gYmUgd29ydGggbG9va2luZyBhdCAtIGhvcGVmdWxseSB0aGVpciBkZXBsb3ltZW50IHdpbGwgaW5jcmVhc2UgZHUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.148.554 References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> Message-ID: <1371761816.4644.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Thu, 20 Jun 2013 13:56:56 -0700 (PDT) From: Mark Smith Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt To: Ronald Bonica , "ipv6@ietf.org 6man-wg" In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 20:57:05 -0000 Hi,=0A=0AI also tend to agree with this draft. However, I'm wondering about= how this will effect non-UDP/TCP protocols that assume IP layer fragmentat= ion to take care of their larger payloads e.g, OSPF?=0A=0ASCTP and DCCP mig= ht also be worth looking at - hopefully their deployment will increase due = to no NATs in IPv6.=0A=0AAlso, the impact on tunnel protocols such as GRE a= nd IPsec might be worth both considering and discussing. It is a while sinc= e I spent time in this area, however I remember there are commonly options = or defaults to either set the DF flag universally on the outer tunnel packe= t, or to copy the DF value from the inner packet. For at least GRE and IPse= c, the tunnel protocols themselves don't independently perform periodic PMT= UD between the tunnel endpoints to determine tunnel MTU.=0A=0ARegards,=0AMa= rk.=0A=0A=0A=0A=0A----- Original Message -----=0A> From: Ronald Bonica =0A> To: "ipv6@ietf.org 6man-wg" =0A> Cc: = =0A> Sent: Friday, 21 June 2013 1:55 AM=0A> Subject: FW: New Version Notifi= cation for=0A=09draft-bonica-6man-frag-deprecate-00.txt=0A> =0A> Folks,=0A>= =0A> Please review this draft and provide comments.=0A> =0A> =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ron=0A> =0A> =0A>> -----Original Message--= ---=0A>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]= =0A>> Sent: Thursday, June 20, 2013 11:48 AM=0A>> To: Ronald Bonica=0A>> = Subject: New Version Notification for draft-bonica-6man-frag-deprecate-=0A= >> 00.txt=0A>> =0A>> =0A>> A new version of I-D, draft-bonica-6man-frag-d= eprecate-00.txt=0A>> has been successfully submitted by Ron Bonica and pos= ted to the IETF=0A>> repository.=0A>> =0A>> Filename:=A0=A0=A0 draft-bon= ica-6man-frag-deprecate=0A>> Revision:=A0=A0=A0 00=0A>> Title:=A0=A0=A0 = =A0=A0=A0 IPv6 Fragment Header Deprecated=0A>> Creation date:=A0=A0=A0 2= 013-06-20=0A>> Group:=A0=A0=A0 =A0=A0=A0 Individual Submission=0A>> Numb= er of pages: 7=0A>> URL:=A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/intern= et-drafts/draft-bonica-6man-=0A>> frag-deprecate-00.txt=0A>> Status:=A0 = =A0 =A0 =A0 =A0 http://datatracker.ietf.org/doc/draft-bonica-6man-=0A>> fr= ag-deprecate=0A>> Htmlized:=A0 =A0 =A0 =A0 http://tools.ietf.org/html/draf= t-bonica-6man-frag-=0A>> deprecate-00=0A>> =0A>> =0A>> Abstract:=0A>> =A0= =A0 This memo deprecates the IPv6 Fragment Header.=A0 It provides reasons= =0A>> =A0 =A0 for deprecation and updates RFC 2460.=0A>> =0A>> =0A>> =0A>> = =0A>> =0A>> The IETF Secretariat=0A>> =0A>> =0A> =0A> --------------------= ------------------------------------------------=0A> IETF IPv6 working grou= p mailing list=0A> ipv6@ietf.org=0A> Administrative Requests: https://www.i= etf.org/mailman/listinfo/ipv6=0A> -----------------------------------------= ---------------------------=0A> From bill.jouris@insidethestack.com Thu Jun 20 15:32:43 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A934F21F9E59 for ; Thu, 20 Jun 2013 15:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hb6dL29jLm9V for ; Thu, 20 Jun 2013 15:32:38 -0700 (PDT) Received: from nm25-vm0.access.bullet.mail.sp2.yahoo.com (nm25-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.184]) by ietfa.amsl.com (Postfix) with ESMTP id 91AA221F9E1B for ; Thu, 20 Jun 2013 15:32:38 -0700 (PDT) Received: from [98.139.44.99] by nm25.access.bullet.mail.sp2.yahoo.com with NNFMP; 20 Jun 2013 22:32:37 -0000 Received: from [98.139.44.89] by tm4.access.bullet.mail.sp2.yahoo.com with NNFMP; 20 Jun 2013 22:32:37 -0000 Received: from [127.0.0.1] by omp1026.access.mail.sp2.yahoo.com with NNFMP; 20 Jun 2013 22:32:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 894896.8173.bm@omp1026.access.mail.sp2.yahoo.com Received: (qmail 34838 invoked by uid 60001); 20 Jun 2013 22:32:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1371767557; bh=Zi2kdhxGKgaicaLT3rQRrdFdiUQA03XQ26TDOdayqbA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=CYZt4+frrlCQVRfNk6jsFGpb1OSfjxwEDyHx0nyF/e+rDgjj+ZLGMhtWHjWvVVLIiHiw49MD780DbJ1v4rln/QdQs+morNIfP4D1+bRuPnpKGYIpAFJNh2aTj9ErSJiBJkXrNj/3n7US/TAD/I3KE8I+1+SeTeo6OISt4Zv0t6g= X-YMail-OSG: _4JdUBkVM1nmfoe7y8ouK_u5QKucCEsskPgU4NMPhnY4Pk1 0agqJ7KzEhpFEAaV2LzLF1YKKfVrOJEKvRLE6rW8PVSNNjCW7CbuaJj9Yu_P fg511kb1bfDm18GFvJtkP_Pxg_rJwYrEuiO4fypKX6mIFQP1Zip9hY36ixVE DJozhbThatTGh3Lihl_hhDvbdgE8YGWqmy3.DCNfeb57JdcqbM3GxyLeeEJY nvX.CX3GGyh32TmvN.5JGO8b1SbZYxAVwn1ri6yhpEXwM0hBHzgHraCnxSTW et0BB9vHTRPOI2GUZu_1pUYqHkpInCGiMnxUAHKR3MwQ84LhfDmEbS4b3Xr2 bOjGWNRyxuwxNRTOzU5j2ei6RrI2UM_U56C0vnk3tvKWckU5KHfF8aWY.jZt FLC7fOT5sBlYEURrKmDKsscSRmy5h5.7oXuiMv5Ua1dBxiTXbK8cBcCeAAPF _Ky0jSsBDqd_eUwgF.ZhL.mo4i.zT.zviftpDj1pkfHzcl3f3onw4Ub5fCaM vFr7ZhrQYVr.9QYCF_fJuTew5.zGHGUfubQ1uCJ5G5Bf9Be5I.XYA7rnASSR AcpK2DPkDuzuLnnsXwnsrk.BN5KGml9X6A4fH.hStlLBwND1s9qexeUfsn17 oCjaFzHnSb.g_V_ZQLlJLGg-- Received: from [50.143.174.186] by web2803.biz.mail.ne1.yahoo.com via HTTP; Thu, 20 Jun 2013 15:32:37 PDT X-Rocket-MIMEInfo: 002.001, SXMgaXQgdGhhdCB0aGUgb3BlcmF0aW9uYWwgKnJlcXVpcmVtZW50KiBpcyBsZXNzP8KgIE9yIHRoYXQgdGhlIGN1cnJlbnQgb3BlcmF0aW9uYWwgKmNhcGFiaWxpdHkqIGlzIGxlc3M_CgpJdCBzZWVtcyBsaWtlLCBnaXZlbiB0aGUgUkZDLCB0aGUgcmVxdWlyZW1lbnQgaXMgbm90IHlldCB3aXRoaW4gdGhlIGNhcGFiaWxpdHkgb2YgdGhlIGV4aXN0aW5nIGJhY2tib25lLsKgIFdoaWNoIGlzLCBhdCBtb3N0LCBhbiBhcmd1bWVudCBmb3IgYWxsb3dpbmcgc29tZSBhZGRpdGlvbmFsIHRpbWUgZm9yIHRoZSBiYWMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.148.554 References: <20130612174908.GT2504@Space.Net> <51B6876A.9020202@si6networks.com> <20130612003800.0374235C2E8B@drugs.dv.isc.org> <51B867C8.8010100@si6networks.com> <51B8AAA7.3020909@isi.edu> <10707.1371062690@perseus.noi.kre.to> <51B8D213.8040900@isi.edu> <20130612204022.GY2504@Space.Net> <51B8DED6.9030306@isi.edu> <51B8E35C.3070207@si6networks.com> <51BA2A5E.6050102@dougbarton.us> <00ca01ce68df$553ed560$4001a8c0@gateway.2wire.net> <51BB6776.8040307@dougbarton.us> <013101ce6944$cbb62e90$63228bb0$@tndh.net> Message-ID: <1371767557.28978.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Thu, 20 Jun 2013 15:32:37 -0700 (PDT) From: Bill Jouris Subject: Re: [v6ops] Limiting the size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain) To: "v6ops@ietf.org WG" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-1454117559-1371767557=:28978" Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Jouris List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 22:32:43 -0000 ---1551098171-1454117559-1371767557=:28978 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Is it that the operational *requirement* is less?=A0 Or that the current op= erational *capability* is less?=0A=0AIt seems like, given the RFC, the requ= irement is not yet within the capability of the existing backbone.=A0 Which= is, at most, an argument for allowing some additional time for the backbon= e to be upgraded.=A0 And (since the RFC is how many years old by now?) not = necessarily an enormous amount of additional time.=0A=0A=A0=0ABill Jouris= =0AInside Products, Inc.=0Awww.insidethestack.com=0A831-659-8360=0A925-855-= 9512 (direct)=0A=0A=0A=0A=0A________________________________=0A From: Loren= zo Colitti =0ATo: Tony Hain =0ACc: = "v6ops@ietf.org WG" ; IETF IPv6 Mailing List =0ASent: Friday, June 14, 2013 3:15 PM=0ASubject: Re: [v6ops] Limiting th= e size of the IPv6 headerchain (draft-ietf-6man-oversized-header-chain)=0A = =0A=0A=0AOn Fri, Jun 14, 2013 at 2:19 PM, Tony Hain wro= te:=0A=0AFocus on=A0the real operational requirement =A0(firewall functiona= lity), then make sure=A0that the constraint automatically tracks evolution = in firewall=0A>functionality. Getting there leads to L4 in the first fragme= nt, and anything=0A>else leads to artificial constraints that will need to = be redone, if that is=0A>even possible.=0A>=0A=0AThe problem with that appr= oach is that for a very substantial fraction of Internet backbones, the rea= l operational requirement is substantially *less* capable than what is writ= ten in RFC 2460 and than what you propose here.=0A_________________________= ______________________=0Av6ops mailing list=0Av6ops@ietf.org=0Ahttps://www.= ietf.org/mailman/listinfo/v6ops ---1551098171-1454117559-1371767557=:28978 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    Is it that the operat= ional *requirement* is less?  Or that the current operational *capabil= ity* is less?

    It seems like, given the RFC, = the requirement is not yet within the capability of the existing backbone.&= nbsp; Which is, at most, an argument for allowing some additional time for = the backbone to be upgraded.  And (since the RFC is how many years old= by now?) not necessarily an enormous amount of additional time.
    =
     
    Bill Jouris
    Inside Products, Inc.
    www.insidethestack.com
    831-659-8360=
    925-855-9512 (direct)


    From: Lorenzo Colitti <lorenzo@google.= com>
    To: Tony Hain = <alh-ietf@tndh.net>
    Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>; IETF IPv6 Mailing List = <ipv6@ietf.org>
    Sent: Friday, June 14, 2013 3:15 PM
    Subject: Re: [v6ops] Limiting the size of the IPv6 headercha= in (draft-ietf-6man-oversized-header-chain)

    =0A
    On Fri, Jun 14, 201= 3 at 2:19 PM, Tony Hain <alh-ietf@tndh.net> wrote:
    =0A=0A
    Focus on the real operational requireme= nt  (firewall functionality), then make sure that the constraint = automatically tracks evolution in firewall
    =0A=0A=0Afunctionality. Getti= ng there leads to L4 in the first fragment, and anything
    =0Aelse leads t= o artificial constraints that will need to be redone, if that is
    =0Aeven= possible.

    The problem with = that approach is that for a very substantial fraction of Internet backbones= , the real operational requirement is substantially *less* capable than wha= t is written in RFC 2460 and than what you propose here.
    =0A=0A
    <= /div>
    =0A

    _______________________________________________
    v6ops mailing li= st
    v= 6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops

    =
    ---1551098171-1454117559-1371767557=:28978-- From fernando@gont.com.ar Thu Jun 20 18:06:33 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC24E21F9B06 for ; Thu, 20 Jun 2013 18:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OulsuQNVpnEg for ; Thu, 20 Jun 2013 18:06:29 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id CD0B821F9B05 for ; Thu, 20 Jun 2013 18:06:26 -0700 (PDT) Received: from 25.red-95-122-164.staticip.rima-tde.net ([95.122.164.25] helo=[192.168.1.134]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Uppnb-00079X-GZ; Fri, 21 Jun 2013 03:05:59 +0200 Message-ID: <51C3A6F5.4060408@gont.com.ar> Date: Fri, 21 Jun 2013 03:05:57 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ole Troan Subject: Progressing stable-privacy-addresses (bis) (was Re: Progressing draft-ietf-6man-stable-privacy-addresses (Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-10.txt)) References: <20130612174513.32059.54189.idtracker@ietfa.amsl.com> <51B8B5F6.4080404@si6networks.com> <51BFEC17.7060207@si6networks.com> <51C041C5.70203@si6networks.com> <51C0DFFD.3090302@gmail.com> <6.2.5.6.2.20130619020258.0cfbe2a0@resistor.net> <5DE8710C-5715-48EF-87F9-D2C78AFB2CDF@employees.org> In-Reply-To: <5DE8710C-5715-48EF-87F9-D2C78AFB2CDF@employees.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 01:06:34 -0000 On 06/19/2013 12:20 PM, Ole Troan wrote: >> >> There was a message asking Fernando to wait because of a >> yet-to-be-written draft. :-) In my opinion the dependency would >> be non-normative. There doesn't seem to be much room for argument >> there. > > the action is on the chairs to initiate the WGLC, and subsequently to > review the document. given the discussion on the list, we are > planning a larger session on privacy, tracking and the interface > identifier in Berlin. Why don't you want to ship this document, which seems to be what the wg is supporting? This document has been suffering from unnecessary delays for almost a year now. It's not very encouraging for people to contribute opinions to this wg if, when most people seem to be arguing one way, but you decide to go another. Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From sm@resistor.net Thu Jun 20 20:49:41 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF0521F9C50 for ; Thu, 20 Jun 2013 20:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3m9QS9A9v3IL for ; Thu, 20 Jun 2013 20:49:41 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1452221F9C4D for ; Thu, 20 Jun 2013 20:49:40 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r5L3nV6Z027349; Thu, 20 Jun 2013 20:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1371786577; bh=xF1jH8TTnxN3UoiSC1wiV0CWWJGjFaGPSLLE/vQoqHY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QbPiTjsHcfIHj0ZmH7REVICgCXeGKN0AfzWxZ4xQtnFWLXDlevIOBpC76SY2EzEBA +IEFkNdUDVUKKnRWI3dfbKxTj7SzChkT6BiOT35ZUrhWvT5ODScmLVYCu1a8uDUfEC g6CBKMlst8mj/rlITLiMUEVPCIgMTdht/mfKuKuE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1371786577; i=@resistor.net; bh=xF1jH8TTnxN3UoiSC1wiV0CWWJGjFaGPSLLE/vQoqHY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=SDWBtlFmK3hCVl/K5T5Gw4yN1f6U6V/21Wg9fxLZAM5Lpya8AxUAhHnuw7J38uyTh TNWNcN/5Lx8SbvultsBbC7en2EaaWY/rKx0n4RlmkW3De/j1mFzrppcT/a7EvucB55 lgLg3+ulHWHDE9RSgtsBygl06iYd9dOeuLKQTxtM= Message-Id: <6.2.5.6.2.20130620203337.0cd3eda8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 20 Jun 2013 20:42:20 -0700 To: Ole Troan From: SM Subject: Re: Progressing draft-ietf-6man-stable-privacy-addresses (Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-10.txt) In-Reply-To: <5DE8710C-5715-48EF-87F9-D2C78AFB2CDF@employees.org> References: <20130612174513.32059.54189.idtracker@ietfa.amsl.com> <51B8B5F6.4080404@si6networks.com> <51BFEC17.7060207@si6networks.com> <51C041C5.70203@si6networks.com> <51C0DFFD.3090302@gmail.com> <6.2.5.6.2.20130619020258.0cfbe2a0@resistor.net> <5DE8710C-5715-48EF-87F9-D2C78AFB2CDF@employees.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: 6man-chairs@tools.ietf.org, Fernando Gont , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 03:49:41 -0000 Hi Ole, At 03:20 19-06-2013, Ole Troan wrote: >the action is on the chairs to initiate the WGLC, and subsequently >to review the document. Ok. >given the discussion on the list, we are planning a larger session >on privacy, tracking and the interface identifier >in Berlin. Ok. >I thought it would make sense to do the last call on this document, >after that discussion. I'll comment below. >personally I would have preferred to scale back the stable-privacy >document, and move some of the general >privacy and tracking discussion to a more general draft. >the other consideration is also, what's the sudden rush? given that >interface-id generation is a local >implementation specific matter, there is nothing stopping someone >who wants different interface-id's today >to go out and implement them. It's not a sudden rush. :-) The specification is going to be implemented in an open source project. The only proposed changed (see above) is the privacy and tracking discussion. Nobody has submitted a more general draft. It seems odd to have to wait for a session in Berlin when there isn't any concrete proposal being discussed on the mailing list. Regards, -sm From achatz@forthnetgroup.gr Fri Jun 21 01:03:17 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91ECB11E8169 for ; Fri, 21 Jun 2013 01:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0UzB1J7bFmJ for ; Fri, 21 Jun 2013 01:03:12 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id BFE3411E8167 for ; Fri, 21 Jun 2013 01:03:11 -0700 (PDT) Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-06.forthnet.gr (8.14.4/8.14.4) with ESMTP id r5L839b3016024; Fri, 21 Jun 2013 11:03:09 +0300 Received: from MX-IN-02.forthnet.gr (mx-in-02.forthnet.gr [193.92.150.185]) by mx-av-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id r5L839KF004566; Fri, 21 Jun 2013 11:03:09 +0300 Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-02.forthnet.gr (8.14.4/8.14.4) with ESMTP id r5L838ei007077; Fri, 21 Jun 2013 11:03:09 +0300 Authentication-Results: MX-IN-02.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <51C408BC.4030909@forthnetgroup.gr> Date: Fri, 21 Jun 2013 11:03:08 +0300 From: Tassos Chatzithomaoglou Organization: Forthnet User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17.1 MIME-Version: 1.0 To: Ronald Bonica , "ipv6@ietf.org 6man-wg" Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 08:03:17 -0000 I really like this idea. What worries me is the different cases to be examined/solved depending on the source device: host (applications) or router (protocols). And this draft takes into account mostly the first. -- Tassos Ronald Bonica wrote on 20/06/2013 18:55: > Folks, > > Please review this draft and provide comments. > > Ron > > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Thursday, June 20, 2013 11:48 AM >> To: Ronald Bonica >> Subject: New Version Notification for draft-bonica-6man-frag-deprecate- >> 00.txt >> >> >> A new version of I-D, draft-bonica-6man-frag-deprecate-00.txt >> has been successfully submitted by Ron Bonica and posted to the IETF >> repository. >> >> Filename: draft-bonica-6man-frag-deprecate >> Revision: 00 >> Title: IPv6 Fragment Header Deprecated >> Creation date: 2013-06-20 >> Group: Individual Submission >> Number of pages: 7 >> URL: http://www.ietf.org/internet-drafts/draft-bonica-6man- >> frag-deprecate-00.txt >> Status: http://datatracker.ietf.org/doc/draft-bonica-6man- >> frag-deprecate >> Htmlized: http://tools.ietf.org/html/draft-bonica-6man-frag- >> deprecate-00 >> >> >> Abstract: >> This memo deprecates the IPv6 Fragment Header. It provides reasons >> for deprecation and updates RFC 2460. >> >> >> >> >> >> The IETF Secretariat >> >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From simon.perreault@viagenie.ca Fri Jun 21 01:22:50 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96FD21F866E for ; Fri, 21 Jun 2013 01:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89qBLjfOMZ5k for ; Fri, 21 Jun 2013 01:22:48 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7063121F8956 for ; Fri, 21 Jun 2013 01:22:47 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9F3B340426 for ; Fri, 21 Jun 2013 04:22:46 -0400 (EDT) Message-ID: <51C40D55.4090206@viagenie.ca> Date: Fri, 21 Jun 2013 10:22:45 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> In-Reply-To: <51C408BC.4030909@forthnetgroup.gr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 08:22:50 -0000 Le 2013-06-21 10:03, Tassos Chatzithomaoglou a écrit : > I really like this idea. +1 > What worries me is the different cases to be examined/solved depending on the source device: host (applications) or router (protocols). > And this draft takes into account mostly the first. Impacts on SIIT [RFC6145] would also need to be analyzed. Fun fun fun! ;) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From otroan@employees.org Fri Jun 21 01:24:04 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511F021E80CE for ; Fri, 21 Jun 2013 01:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.586 X-Spam-Level: X-Spam-Status: No, score=-10.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBaEsHMr+NEe for ; Fri, 21 Jun 2013 01:23:57 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 10EC421F866E for ; Fri, 21 Jun 2013 01:23:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAIQMxFGQ/khN/2dsb2JhbABbgwnAL38WdIIjAQEEAXkFCws7C1cGJ4d0BrxQjxYzB4MAYQOpB4FYgTk6 X-IronPort-AV: E=Sophos;i="4.87,911,1363132800"; d="scan'208";a="83535341" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 21 Jun 2013 08:23:54 +0000 Received: from dhcp-lys01-vla250-10-147-112-135.cisco.com (dhcp-lys01-vla250-10-147-112-135.cisco.com [10.147.112.135]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5L8NqT8020612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Jun 2013 08:23:52 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Progressing stable-privacy-addresses (bis) (was Re: Progressing draft-ietf-6man-stable-privacy-addresses (Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-10.txt)) From: Ole Troan In-Reply-To: <51C3A6F5.4060408@gont.com.ar> Date: Fri, 21 Jun 2013 10:23:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9BD1B8AF-4C08-4DEC-A3FE-6586F336174B@employees.org> References: <20130612174513.32059.54189.idtracker@ietfa.amsl.com> <51B8B5F6.4080404@si6networks.com> <51BFEC17.7060207@si6networks.com> <51C041C5.70203@si6networks.com> <51C0DFFD.3090302@gmail.com> <6.2.5.6.2.20130619020258.0cfbe2a0@resistor.net> <5DE8710C-5715-48EF-87F9-D2C78AFB2CDF@employees.org> <51C3A6F5.4060408@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1508) Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 08:24:04 -0000 Fernando, >>> There was a message asking Fernando to wait because of a >>> yet-to-be-written draft. :-) In my opinion the dependency would >>> be non-normative. There doesn't seem to be much room for argument >>> there. >>=20 >> the action is on the chairs to initiate the WGLC, and subsequently to >> review the document. given the discussion on the list, we are >> planning a larger session on privacy, tracking and the interface >> identifier in Berlin. >=20 > Why don't you want to ship this document, which seems to be what the = wg > is supporting? have I said that? then please let me clarify. I do think this document should be published. > This document has been suffering from unnecessary delays for almost a > year now. this document was returned to the working group by the AD, after the = IETF last call. to me that's a strong hint from the community that we didn't do a good = enough job in the working group. before re-sending the document, I want to make = sure we have dotted every i and crossed every t. there are other interface-identifier mechanisms proposed, I want to make = sure we go back and=20 look at the bigger picture to ensure that we understand all the issues = and that we are reasonably confident that we are done. > It's not very encouraging for people to contribute opinions to this wg > if, when most people seem to be arguing one way, but you decide to go > another. I think you have made your point, thank you. cheers, Ole= From stbryant@cisco.com Fri Jun 21 07:39:14 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D2521F9BDB; Fri, 21 Jun 2013 07:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.383 X-Spam-Level: X-Spam-Status: No, score=-110.383 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faByYFTegINx; Fri, 21 Jun 2013 07:39:09 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id B7B8C11E8193; Fri, 21 Jun 2013 07:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8857; q=dns/txt; s=iport; t=1371825548; x=1373035148; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=SZPcSEOoxK3ukKiU5hTJ1TDWrdeF6yPnSvZladOuWK4=; b=ZaPNa+t/BTz+JKpqtEOMviC0zBmDJ6M81l9xuTn5/uQrsZIVLlAClnsW Ovls2DwBkrjSKFtWu7gS4H9F1dTReCNgUJUYhtzp2syr9mG/9fla9XWR+ tYm+y1pSqJ7jwGmhP+vNqtXrAxVzeoO7w/Db6GXAVbNMTR/LZKLEidRh/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAK1kxFGQ/khN/2dsb2JhbABbgwkxiSm2VYECFnSCIwEBAQQBAQFrCgEMBBwDAQIKFg8JAwIBAgEVHwcCCAYBDAEFAgEBF4dzDLxCjX6BOhEHBoNbA5dDgSmQG4MQ X-IronPort-AV: E=Sophos;i="4.87,913,1363132800"; d="scan'208,217";a="14893308" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 21 Jun 2013 14:39:06 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5LEd4u6025782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jun 2013 14:39:04 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r5LEd3hm025510; Fri, 21 Jun 2013 15:39:03 +0100 (BST) Message-ID: <51C46587.3020907@cisco.com> Date: Fri, 21 Jun 2013 15:39:03 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: isis-wg , "ospf@ietf.org" , "mpls@ietf.org" , "rtgwg@ietf.org" , 6man@ietf.org Subject: Fwd: Status BOF in Berlin References: <51C352CA.6000307@cisco.com> In-Reply-To: <51C352CA.6000307@cisco.com> X-Forwarded-Message-Id: <51C352CA.6000307@cisco.com> Content-Type: multipart/alternative; boundary="------------080101000407060509050103" Cc: ops-area@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 14:39:14 -0000 This is a multi-part message in MIME format. --------------080101000407060509050103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This BOF touches on technology of interest to each of the working groups on the "To" list. I apologies to those that have already seen this through circulation to routing-discussion, but I know that not everyone is subscribed there. The list for discussion of this topic is status@ietf.org - Stewart -------- Original Message -------- Subject: Status BOF in Berlin Date: Thu, 20 Jun 2013 20:06:50 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com To: routing-discussion@ietf.org CC: status@ietf.org STATUS * Name: Stacked Tunnels for Source Routing (STATUS) [Was TUBAS] * Status: Approved * Description The IETF has two packet-based forwarding technologies: IP and MPLS. IP previously had a source-based routing mechanism made available through an IP Option. This mechanism has, however, not been widely used and has a number of issues that make its use inadvisable, and other mechanisms (such as RFC 1940 ) do not appear to have been implemented at all. The ability of a router to influence or control the forwarding path of an individual packet or all the packets of a given Forwarding Equivalence Class (FEC) is a desirable feature for a number of reasons including Label Switched Path stitching, egress protection, explicit routing, egress ASBR link selection, and backup (bypass tunnels, Remote Loop-Free Alternates) routing. This can be achieved by facilitating source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter- domain and intra-domain routes. Historically, distribution of MPLS label binding information was done by relying on label distribution protocols such as LDP and RSVP-TE. Several new proposals have been made to make use of the MPLS forwarding plane in novel but backward-compatible ways, and to install forwarding instructions using information distributed by the IGP running in the network, or through the management plane. It has been suggested that similar mechanisms might also be applied in IPv6. This BoF is intended to discuss the practicalities of various use cases and to establish a consensus around the problem space and desirability of developing solutions in this area with a view to determining whether the IETF should have a Working Group on this topic. * Responsible Area Directors: Adrian Farrel and Stewart Bryant * BoF Chairs: Alvaro Retana, John Scudder * * Mailing list: https://www.ietf.org/mailman/listinfo/status Further details can be found at http://trac.tools.ietf.org/bof/trac/wiki - Stewart --------------080101000407060509050103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This BOF touches on technology of interest to each of the
    working groups on the "To" list.

    I apologies to those that have already seen this through
    circulation to routing-discussion, but I know that not
    everyone is subscribed there.

    The list for discussion of this topic is status@ietf.org

    - Stewart

    -------- Original Message --------
    Subject: Status BOF in Berlin
    Date: Thu, 20 Jun 2013 20:06:50 +0100
    From: Stewart Bryant <stbryant@cisco.com>
    Reply-To: stbryant@cisco.com
    To: routing-discussion@ietf.org
    CC: status@ietf.org


    STATUS

    • Name: Stacked Tunnels for Source Routing (STATUS) [Was TUBAS]
    • Status: Approved
    • Description

    The IETF has two packet-based forwarding technologies: IP and MPLS.

    IP previously had a source-based routing mechanism made available through an IP Option. This mechanism has, however, not been widely used and has a number of issues that make its use inadvisable, and other mechanisms (such as RFC 1940) do not appear to have been implemented at all.

    The ability of a router to influence or control the forwarding path of an individual packet or all the packets of a given Forwarding Equivalence Class (FEC) is a desirable feature for a number of reasons including Label Switched Path stitching, egress protection, explicit routing, egress ASBR link selection, and backup (bypass tunnels, Remote Loop-Free Alternates) routing. This can be achieved by facilitating source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter- domain and intra-domain routes.

    Historically, distribution of MPLS label binding information was done by relying on label distribution protocols such as LDP and RSVP-TE.

    Several new proposals have been made to make use of the MPLS forwarding plane in novel but backward-compatible ways, and to install forwarding instructions using information distributed by the IGP running in the network, or through the management plane. It has been suggested that similar mechanisms might also be applied in IPv6.

    This BoF is intended to discuss the practicalities of various use cases and to establish a consensus around the problem space and desirability of developing solutions in this area with a view to determining whether the IETF should have a Working Group on this topic.

    Further details can be found  at http://trac.tools.ietf.org/bof/trac/wiki

    - Stewart



    --------------080101000407060509050103-- From fgont@si6networks.com Fri Jun 21 08:53:09 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562C221F9E0C for ; Fri, 21 Jun 2013 08:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCnqXKe8QznS for ; Fri, 21 Jun 2013 08:53:08 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id DC9E021F9CF6 for ; Fri, 21 Jun 2013 08:53:03 -0700 (PDT) Received: from 25.red-95-122-164.staticip.rima-tde.net ([95.122.164.25] helo=[192.168.1.134]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Uq3dd-0003Oy-Ok; Fri, 21 Jun 2013 17:52:38 +0200 Message-ID: <51C476BC.2070607@si6networks.com> Date: Fri, 21 Jun 2013 17:52:28 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ole Troan Subject: Re: Progressing stable-privacy-addresses (bis) (was Re: Progressing draft-ietf-6man-stable-privacy-addresses (Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-10.txt)) References: <20130612174513.32059.54189.idtracker@ietfa.amsl.com> <51B8B5F6.4080404@si6networks.com> <51BFEC17.7060207@si6networks.com> <51C041C5.70203@si6networks.com> <51C0DFFD.3090302@gmail.com> <6.2.5.6.2.20130619020258.0cfbe2a0@resistor.net> <5DE8710C-5715-48EF-87F9-D2C78AFB2CDF@employees.org> <51C3A6F5.4060408@gont.com.ar> <9BD1B8AF-4C08-4DEC-A3FE-6586F336174B@employees.org> In-Reply-To: <9BD1B8AF-4C08-4DEC-A3FE-6586F336174B@employees.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 15:53:09 -0000 Ole, My apologies if my coments cam across the wrong way. PLease find my comments in-line... On 06/21/2013 10:23 AM, Ole Troan wrote: > >> This document has been suffering from unnecessary delays for almost a >> year now. > > this document was returned to the working group by the AD, after the IETF last call. > to me that's a strong hint from the community that we didn't do a good enough job > in the working group. I never understood why the document came back to the wg. What we had to address was, for the most part, the discussion fo the "NIC identifier" we were using. 90% of the other text that was added was the product of later wg discussions, and had nothing to do with the IETF LC. > before re-sending the document, I want to make sure we have > dotted every i and crossed every t. Isn't that what reviews are for? For instance, I polled every single guy that had provided comments since IETF LC to double-check that their feedback had been addressed. You mentioned that you planned to have a general discussion at the next IETF. Yet everything that had to do with IETF LC had nothing to d with "general issues", but rather with low level details (whether Interface Indexes are constant or not, etc.). Me, I personally think that if we rally want to make sure that the document is ready, we just need reviews in that direction. If we're ging to rewind back to WGLC, then, by itself, gives enough opportunities to review and comment (there's still IETF LC, etc.). > there are other interface-identifier mechanisms proposed, I want to make sure we go back and > look at the bigger picture to ensure that we understand all the issues and that we are reasonably > confident that we are done. We have beaten this one to death, for more than a year. If having to address low-level details in the I-D is going to be an opportunity to rewind one year in the publication process, it becomes difficult to make progress. I don't think one anyone would think that "we need to make sure we understand the bigger picture"... because the I-D was brought back to the wg for a low-level detail, and not for the "bigger picture". Just me trying to make progress. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From rbonica@juniper.net Fri Jun 21 09:30:59 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176B821F9FA5 for ; Fri, 21 Jun 2013 09:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.426 X-Spam-Level: X-Spam-Status: No, score=-100.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSn1D2ynpxGe for ; Fri, 21 Jun 2013 09:30:53 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB1E21F9C69 for ; Fri, 21 Jun 2013 09:30:45 -0700 (PDT) Received: from mail132-ch1-R.bigfish.com (10.43.68.247) by CH1EHSOBE019.bigfish.com (10.43.70.76) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 16:30:44 +0000 Received: from mail132-ch1 (localhost [127.0.0.1]) by mail132-ch1-R.bigfish.com (Postfix) with ESMTP id 6C83D300398 for ; Fri, 21 Jun 2013 16:30:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: PS-26(zzbb2dI9371I936eI148cI542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2fh2a8h683h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail132-ch1: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=rbonica@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail132-ch1 (localhost.localdomain [127.0.0.1]) by mail132-ch1 (MessageSwitch) id 1371832240119776_13210; Fri, 21 Jun 2013 16:30:40 +0000 (UTC) Received: from CH1EHSMHS014.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.232]) by mail132-ch1.bigfish.com (Postfix) with ESMTP id 09DE3220630 for ; Fri, 21 Jun 2013 16:30:40 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.52) by CH1EHSMHS014.bigfish.com (10.43.70.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Jun 2013 16:30:38 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 21 Jun 2013 09:30:11 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 21 Jun 2013 09:30:11 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.188) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 21 Jun 2013 09:42:08 -0700 Received: from mail56-co1-R.bigfish.com (10.243.78.236) by CO1EHSOBE022.bigfish.com (10.243.66.85) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 16:30:10 +0000 Received: from mail56-co1 (localhost [127.0.0.1]) by mail56-co1-R.bigfish.com (Postfix) with ESMTP id 79445B007CE for ; Fri, 21 Jun 2013 16:30:10 +0000 (UTC) Received: from mail56-co1 (localhost.localdomain [127.0.0.1]) by mail56-co1 (MessageSwitch) id 1371832149168269_21913; Fri, 21 Jun 2013 16:29:09 +0000 (UTC) Received: from CO1EHSMHS027.bigfish.com (unknown [10.243.78.236]) by mail56-co1.bigfish.com (Postfix) with ESMTP id 0CF4D3C0105; Fri, 21 Jun 2013 16:29:04 +0000 (UTC) Received: from BY2PRD0512HT004.namprd05.prod.outlook.com (157.56.238.5) by CO1EHSMHS027.bigfish.com (10.243.66.37) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Jun 2013 16:29:03 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.17]) by BY2PRD0512HT004.namprd05.prod.outlook.com ([10.255.243.37]) with mapi id 14.16.0324.000; Fri, 21 Jun 2013 16:29:02 +0000 From: Ronald Bonica To: Tassos Chatzithomaoglou , "ipv6@ietf.org 6man-wg" Subject: RE: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHObc3OGhJfZWsTvkmEF1gJL7lsrZk+wGpwgAEPggCAAI03oA== Date: Fri, 21 Jun 2013 16:29:02 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> In-Reply-To: <51C408BC.4030909@forthnetgroup.gr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%FORTHNETGROUP.GR$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 16:30:59 -0000 SGkgVGFzc29zLA0KDQpUaGFua3MgZm9yIHJldmlld2luZyB0aGUgZHJhZnQuIENvdWxkIHlvdSBw cm92aWRlIG1vcmUgZGV0YWlsIG9uIHdoYXQgaXMgbWlzc2luZz8NCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBSb24NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IFRhc3NvcyBDaGF0eml0aG9tYW9nbG91IFttYWlsdG86YWNoYXR6QGZvcnRobmV0Z3JvdXAu Z3JdDQo+IFNlbnQ6IEZyaWRheSwgSnVuZSAyMSwgMjAxMyA0OjAzIEFNDQo+IFRvOiBSb25hbGQg Qm9uaWNhOyBpcHY2QGlldGYub3JnIDZtYW4td2cNCj4gU3ViamVjdDogUmU6IEZXOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJvbmljYS02bWFuLWZyYWctDQo+IGRlcHJlY2F0 ZS0wMC50eHQNCj4gDQo+IEkgcmVhbGx5IGxpa2UgdGhpcyBpZGVhLg0KPiBXaGF0IHdvcnJpZXMg bWUgaXMgdGhlIGRpZmZlcmVudCBjYXNlcyB0byBiZSBleGFtaW5lZC9zb2x2ZWQgZGVwZW5kaW5n DQo+IG9uIHRoZSBzb3VyY2UgZGV2aWNlOiBob3N0IChhcHBsaWNhdGlvbnMpIG9yIHJvdXRlciAo cHJvdG9jb2xzKS4NCj4gQW5kIHRoaXMgZHJhZnQgdGFrZXMgaW50byBhY2NvdW50IG1vc3RseSB0 aGUgZmlyc3QuDQo+IA0KPiAtLQ0KPiBUYXNzb3MNCj4gDQo+IFJvbmFsZCBCb25pY2Egd3JvdGUg b24gMjAvMDYvMjAxMyAxODo1NToNCj4gPiBGb2xrcywNCj4gPg0KPiA+IFBsZWFzZSByZXZpZXcg dGhpcyBkcmFmdCBhbmQgcHJvdmlkZSBjb21tZW50cy4NCj4gPg0KPiA+ICAgICAgICAgICAgICAg ICAgICAgICBSb24NCj4gPg0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10NCj4gPj4gU2VudDogVGh1cnNkYXksIEp1bmUgMjAsIDIwMTMgMTE6NDggQU0N Cj4gPj4gVG86IFJvbmFsZCBCb25pY2ENCj4gPj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvcg0KPiA+PiBkcmFmdC1ib25pY2EtNm1hbi1mcmFnLWRlcHJlY2F0ZS0gMDAudHh0 DQo+ID4+DQo+ID4+DQo+ID4+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1ib25pY2EtNm1h bi1mcmFnLWRlcHJlY2F0ZS0wMC50eHQNCj4gPj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBSb24gQm9uaWNhIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYNCj4gPj4gcmVwb3NpdG9y eS4NCj4gPj4NCj4gPj4gRmlsZW5hbWU6CSBkcmFmdC1ib25pY2EtNm1hbi1mcmFnLWRlcHJlY2F0 ZQ0KPiA+PiBSZXZpc2lvbjoJIDAwDQo+ID4+IFRpdGxlOgkJIElQdjYgRnJhZ21lbnQgSGVhZGVy IERlcHJlY2F0ZWQNCj4gPj4gQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDYtMjANCj4gPj4gR3JvdXA6 CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ID4+IE51bWJlciBvZiBwYWdlczogNw0KPiA+PiBV Ukw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWJvbmljYS0NCj4gNm1hbi0NCj4gPj4gZnJhZy1kZXByZWNhdGUtMDAudHh0DQo+ID4+IFN0YXR1 czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ib25pY2Et Nm1hbi0NCj4gPj4gZnJhZy1kZXByZWNhdGUNCj4gPj4gSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib25pY2EtNm1hbi1mcmFnLQ0KPiA+PiBkZXByZWNh dGUtMDANCj4gPj4NCj4gPj4NCj4gPj4gQWJzdHJhY3Q6DQo+ID4+ICAgIFRoaXMgbWVtbyBkZXBy ZWNhdGVzIHRoZSBJUHY2IEZyYWdtZW50IEhlYWRlci4gIEl0IHByb3ZpZGVzDQo+IHJlYXNvbnMN Cj4gPj4gICAgZm9yIGRlcHJlY2F0aW9uIGFuZCB1cGRhdGVzIFJGQyAyNDYwLg0KPiA+Pg0KPiA+ Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiA+Pg0KPiA+ Pg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBs aXN0DQo+ID4gaXB2NkBpZXRmLm9yZw0KPiA+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiA+DQo+IA0KPiANCg0K From v6ops@globis.net Fri Jun 21 10:04:12 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA15D21F9EAA for ; Fri, 21 Jun 2013 10:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DawcRIK+5HQj for ; Fri, 21 Jun 2013 10:04:12 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6188421F9E21 for ; Fri, 21 Jun 2013 10:04:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 904D8870088; Fri, 21 Jun 2013 19:03:56 +0200 (CEST) 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 BcospMgrAUTJ; Fri, 21 Jun 2013 19:03:56 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 707B2870087; Fri, 21 Jun 2013 19:03:56 +0200 (CEST) Message-ID: <51C48776.9070107@globis.net> Date: Fri, 21 Jun 2013 19:03:50 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Ronald Bonica Subject: Re: RE: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 17:04:13 -0000 I have also read this draft. It mentions that DNSSEC will be impacted. What's the alternative if DNSSEC can't send multiple UDP fragments? Isn't expecting a busy DNS server to maintain TCP session state for every single query going to be prohibitively expensive? Leading to even bigger DoS worries than fragmentation apparently causes? Isn't using TCP for all DNS queries going to considerably slow down the name resolution process, which will impact all applications? (multiple RTT for the connection establishment and teardown if you clean up properly) Since PMTUD is also currently pretty broken in practice, also due to "Operator Behavior" and filtering of ICMPv6 in firewalls, doesn't this memo effectively state that IPv6 = 1280 octets? regards, RayH Ronald Bonica wrote: > Hi Tassos, > > Thanks for reviewing the draft. Could you provide more detail on what is missing? > > Ron From joelja@bogus.com Fri Jun 21 10:20:31 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B0021F9FCF for ; Fri, 21 Jun 2013 10:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vo-GwxiL085F for ; Fri, 21 Jun 2013 10:20:31 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0D23521F9FCC for ; Fri, 21 Jun 2013 10:20:31 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r5LHK2ZQ096524 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 21 Jun 2013 17:20:02 GMT (envelope-from joelja@bogus.com) Message-ID: <51C48B3C.80702@bogus.com> Date: Fri, 21 Jun 2013 10:19:56 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0 MIME-Version: 1.0 To: Ray Hunter , Ronald Bonica Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C48776.9070107@globis.net> In-Reply-To: <51C48776.9070107@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 21 Jun 2013 17:20:02 +0000 (UTC) Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 17:20:32 -0000 On 6/21/13 10:03 AM, Ray Hunter wrote: > I have also read this draft. > > It mentions that DNSSEC will be impacted. > > What's the alternative if DNSSEC can't send multiple UDP fragments? so I'm pretty sure I don't want to expose myself to really big replies because that pushed the opportunity to amplify considerably. so EDNS0 limited to ~1420 or ~1280 I could probably live with. > Isn't expecting a busy DNS server to maintain TCP session state for > every single query going to be prohibitively expensive? handshakes are expensive yes, and imho signficant effort should be engaged in to avoid that. > Leading to even bigger DoS worries than fragmentation apparently causes? The cost shifts. I'm not that excited about making connections over TCP unless I have to. > Isn't using TCP for all DNS queries going to considerably slow down the > name resolution process, which will impact all applications? > (multiple RTT for the connection establishment and teardown if you clean > up properly) > > Since PMTUD is also currently pretty broken in practice, also due to > "Operator Behavior" and filtering of ICMPv6 in firewalls, doesn't this > memo effectively state that IPv6 = 1280 octets? So, I'm not willing to throw up my hands in despair over PMTUD yet. there are certianly cases where it doesn't work. they're a little less chronic then not being able to find the L4 header. > > regards, > RayH > > Ronald Bonica wrote: >> Hi Tassos, >> >> Thanks for reviewing the draft. Could you provide more detail on what is missing? >> >> Ron > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From rbonica@juniper.net Fri Jun 21 12:01:24 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1FB21E8183 for ; Fri, 21 Jun 2013 12:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.447 X-Spam-Level: X-Spam-Status: No, score=-100.447 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFC1W09S8zBL for ; Fri, 21 Jun 2013 12:01:18 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 77AA321F92EC for ; Fri, 21 Jun 2013 12:01:14 -0700 (PDT) Received: from mail154-va3-R.bigfish.com (10.7.14.233) by VA3EHSOBE013.bigfish.com (10.7.40.63) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 19:00:59 +0000 Received: from mail154-va3 (localhost [127.0.0.1]) by mail154-va3-R.bigfish.com (Postfix) with ESMTP id A5140120130 for ; Fri, 21 Jun 2013 19:00:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zzbb2dI98dI9371I936eI542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail154-va3: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=rbonica@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT001.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail154-va3 (localhost.localdomain [127.0.0.1]) by mail154-va3 (MessageSwitch) id 1371841256973703_11435; Fri, 21 Jun 2013 19:00:56 +0000 (UTC) Received: from VA3EHSMHS025.bigfish.com (unknown [10.7.14.226]) by mail154-va3.bigfish.com (Postfix) with ESMTP id DDFB1320055 for ; Fri, 21 Jun 2013 19:00:56 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.53) by VA3EHSMHS025.bigfish.com (10.7.99.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Jun 2013 19:00:56 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 21 Jun 2013 12:00:56 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 21 Jun 2013 12:00:55 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.186) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 21 Jun 2013 12:04:21 -0700 Received: from mail98-co1-R.bigfish.com (10.243.78.241) by CO1EHSOBE025.bigfish.com (10.243.66.88) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 19:00:55 +0000 Received: from mail98-co1 (localhost [127.0.0.1]) by mail98-co1-R.bigfish.com (Postfix) with ESMTP id 2F448500624 for ; Fri, 21 Jun 2013 19:00:55 +0000 (UTC) Received: from mail98-co1 (localhost.localdomain [127.0.0.1]) by mail98-co1 (MessageSwitch) id 1371841253760543_15923; Fri, 21 Jun 2013 19:00:53 +0000 (UTC) Received: from CO1EHSMHS029.bigfish.com (unknown [10.243.78.243]) by mail98-co1.bigfish.com (Postfix) with ESMTP id B6E91C00073; Fri, 21 Jun 2013 19:00:53 +0000 (UTC) Received: from BY2PRD0512HT001.namprd05.prod.outlook.com (157.56.238.5) by CO1EHSMHS029.bigfish.com (10.243.66.39) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Jun 2013 19:00:53 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.17]) by BY2PRD0512HT001.namprd05.prod.outlook.com ([10.255.243.34]) with mapi id 14.16.0324.000; Fri, 21 Jun 2013 19:00:51 +0000 From: Ronald Bonica To: Arturo Servin , "ipv6@ietf.org" Subject: RE: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHObdSALMoHoTTaGUmz5vu4FdCoY5lAfOWA Date: Fri, 21 Jun 2013 19:00:51 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> In-Reply-To: <51C32FA9.1090207@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 19:01:24 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Arturo Servin > Sent: Thursday, June 20, 2013 12:37 PM > To: ipv6@ietf.org > Subject: Re: FW: New Version Notification for draft-bonica-6man-frag- > deprecate-00.txt >=20 > Ron, Warren >=20 > In general I tent to agree with you. >=20 > Would you have references or data to back up these two statements? >=20 > 1) " Most popular TCP [RFC0793] implementations leverage this > technology > and restrict their segment size so that IP fragmentation is not > required." The best references that I can find are in user documentation. However, I t= hought that it would be inappropriate to reference user documentation in an= IETF document. AFAIKS, the Microsoft, Apple, Linux and FreeBSD TCP implementations all lev= erage PMTUD. However, I am not an expert on any of those platforms and invi= te people who are to comment. > 2) " As a result, IPv6 fragments carrying TCP payload are > rarely observed on the Internet." I don't know of a study. However, this is probably a safe assumption consid= ering that: - many TCP implementation leverage PMTUD - many enterprise block fragments - many firewalls, by default, block IPv6 fragments Ron >=20 >=20 > Regards, > as >=20 > On 6/20/13 10:55 PM, Ronald Bonica wrote: > > Folks, > > > > Please review this draft and provide comments. > > > > Ron > > > > > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Thursday, June 20, 2013 11:48 AM > >> To: Ronald Bonica > >> Subject: New Version Notification for > >> draft-bonica-6man-frag-deprecate- 00.txt > >> > >> > >> A new version of I-D, draft-bonica-6man-frag-deprecate-00.txt > >> has been successfully submitted by Ron Bonica and posted to the IETF > >> repository. > >> > >> Filename: draft-bonica-6man-frag-deprecate > >> Revision: 00 > >> Title: IPv6 Fragment Header Deprecated > >> Creation date: 2013-06-20 > >> Group: Individual Submission > >> Number of pages: 7 > >> URL: http://www.ietf.org/internet-drafts/draft-bonica- > 6man- > >> frag-deprecate-00.txt > >> Status: http://datatracker.ietf.org/doc/draft-bonica-6man- > >> frag-deprecate > >> Htmlized: http://tools.ietf.org/html/draft-bonica-6man-frag- > >> deprecate-00 > >> > >> > >> Abstract: > >> This memo deprecates the IPv6 Fragment Header. It provides > reasons > >> for deprecation and updates RFC 2460. > >> > >> > >> > >> > >> > >> The IETF Secretariat > >> > >> > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From rbonica@juniper.net Fri Jun 21 12:12:49 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1048221F9F1D for ; Fri, 21 Jun 2013 12:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.453 X-Spam-Level: X-Spam-Status: No, score=-100.453 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbhBVIdC2g6I for ; Fri, 21 Jun 2013 12:12:42 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 054E521F9F1B for ; Fri, 21 Jun 2013 12:12:41 -0700 (PDT) Received: from mail212-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 19:12:41 +0000 Received: from mail212-va3 (localhost [127.0.0.1]) by mail212-va3-R.bigfish.com (Postfix) with ESMTP id 77CB02A01A1 for ; Fri, 21 Jun 2013 19:12:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zz98dI9371I148cI542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail212-va3: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=rbonica@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail212-va3 (localhost.localdomain [127.0.0.1]) by mail212-va3 (MessageSwitch) id 1371841959823285_8871; Fri, 21 Jun 2013 19:12:39 +0000 (UTC) Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.229]) by mail212-va3.bigfish.com (Postfix) with ESMTP id C6B05D4009C for ; Fri, 21 Jun 2013 19:12:39 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.54) by VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Jun 2013 19:12:38 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 21 Jun 2013 12:12:32 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 21 Jun 2013 12:12:31 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.12) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 21 Jun 2013 12:15:58 -0700 Received: from mail153-va3-R.bigfish.com (10.7.14.227) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 19:12:31 +0000 Received: from mail153-va3 (localhost [127.0.0.1]) by mail153-va3-R.bigfish.com (Postfix) with ESMTP id E9BBB160127 for ; Fri, 21 Jun 2013 19:12:30 +0000 (UTC) Received: from mail153-va3 (localhost.localdomain [127.0.0.1]) by mail153-va3 (MessageSwitch) id 1371841948574496_9985; Fri, 21 Jun 2013 19:12:28 +0000 (UTC) Received: from VA3EHSMHS007.bigfish.com (unknown [10.7.14.225]) by mail153-va3.bigfish.com (Postfix) with ESMTP id 7EA374C00E8; Fri, 21 Jun 2013 19:12:28 +0000 (UTC) Received: from BY2PRD0512HT002.namprd05.prod.outlook.com (157.56.238.5) by VA3EHSMHS007.bigfish.com (10.7.99.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Jun 2013 19:12:26 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.17]) by BY2PRD0512HT002.namprd05.prod.outlook.com ([10.255.243.35]) with mapi id 14.16.0324.000; Fri, 21 Jun 2013 19:12:26 +0000 From: Ronald Bonica To: Ray Hunter Subject: RE: RE: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: RE: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHObc3OGhJfZWsTvkmEF1gJL7lsrZk+wGpwgAEPggCAAI03oIAACdsAgAAi/1A= Date: Fri, 21 Jun 2013 19:12:25 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2509F85FBA@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C48776.9070107@globis.net> In-Reply-To: <51C48776.9070107@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%GLOBIS.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%FORTHNETGROUP.GR$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 19:12:49 -0000 Ray, Joel has already responded regarding DNSSEC. However, I would like to add a= word regarding PMTUD brokenness. If the bad operator behavior to which you refer is the filtering of ICMP PT= B messages, that bad behavior will break IPv6 fragmentation to the same deg= ree that it breaks PMTUD. So, keeping IPv6 fragmentation around won't help = very much. Ron > -----Original Message----- > From: Ray Hunter [mailto:v6ops@globis.net] > Sent: Friday, June 21, 2013 1:04 PM > To: Ronald Bonica > Cc: Tassos Chatzithomaoglou; ipv6@ietf.org 6man-wg > Subject: Re: RE: FW: New Version Notification for draft-bonica-6man- > frag-deprecate-00.txt >=20 > I have also read this draft. >=20 > It mentions that DNSSEC will be impacted. >=20 > What's the alternative if DNSSEC can't send multiple UDP fragments? >=20 > Isn't expecting a busy DNS server to maintain TCP session state for > every single query going to be prohibitively expensive? > Leading to even bigger DoS worries than fragmentation apparently > causes? >=20 > Isn't using TCP for all DNS queries going to considerably slow down the > name resolution process, which will impact all applications? > (multiple RTT for the connection establishment and teardown if you > clean up properly) >=20 > Since PMTUD is also currently pretty broken in practice, also due to > "Operator Behavior" and filtering of ICMPv6 in firewalls, doesn't this > memo effectively state that IPv6 =3D 1280 octets? >=20 > regards, > RayH >=20 > Ronald Bonica wrote: > > Hi Tassos, > > > > Thanks for reviewing the draft. Could you provide more detail on what > is missing? > > > > Ron >=20 From v6ops@globis.net Fri Jun 21 12:44:26 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC3321F9FBA for ; Fri, 21 Jun 2013 12:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Huh8m6NpilG for ; Fri, 21 Jun 2013 12:44:25 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 989D721F9F3D for ; Fri, 21 Jun 2013 12:44:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id CADC8870070; Fri, 21 Jun 2013 21:44:09 +0200 (CEST) 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 HD-YZ8fyHa-1; Fri, 21 Jun 2013 21:44:09 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 9F9BE87005B; Fri, 21 Jun 2013 21:44:09 +0200 (CEST) Message-ID: <51C4AD03.2050303@globis.net> Date: Fri, 21 Jun 2013 21:44:03 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Ronald Bonica Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C48776.9070107@globis.net> <2CF4CB03E2AA464BA0982EC92A02CE2509F85FBA@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509F85FBA@BY2PRD0512MB653.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 19:44:26 -0000 > Ronald Bonica > 21 June 2013 21:12 > Ray, > > Joel has already responded regarding DNSSEC. However, I would like to > add a word regarding PMTUD brokenness. > > If the bad operator behavior to which you refer is the filtering of > ICMP PTB messages, that bad behavior will break IPv6 fragmentation to > the same degree that it breaks PMTUD. So, keeping IPv6 fragmentation > around won't help very much. > > Ron > I don't 100% agree. In the case that PMTUD is broken, there'd be nothing to stop a current DNSSEC implementation from always assuming a default path MTU of 1280, without awaiting confirmation from PMTUD, and fragmenting the UDP packet pre-emptively [assuming fragmentation was not equally broken along the path as ICMP PTB was]. Looking at the opposite case [PMTUD OK, fragmentation deprecated] if there's no fragmentation header available, what's the point of a stack implementing PMTUD at the network layer (for UDP), when the only action it could then take AFAICS is to punt to the application anyway? BTW I'm not per se anti your draft. It's radical, but I'd like to explore the pros and cons further before taking a position. regards, RayH > > > > > Ray Hunter > 21 June 2013 19:03 > I have also read this draft. > > It mentions that DNSSEC will be impacted. > > What's the alternative if DNSSEC can't send multiple UDP fragments? > > Isn't expecting a busy DNS server to maintain TCP session state for > every single query going to be prohibitively expensive? > Leading to even bigger DoS worries than fragmentation apparently causes? > > Isn't using TCP for all DNS queries going to considerably slow down the > name resolution process, which will impact all applications? > (multiple RTT for the connection establishment and teardown if you clean > up properly) > > Since PMTUD is also currently pretty broken in practice, also due to > "Operator Behavior" and filtering of ICMPv6 in firewalls, doesn't this > memo effectively state that IPv6 = 1280 octets? > > regards, > RayH > ------------------------------------------------------------------------ From fred@cisco.com Fri Jun 21 12:49:13 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E949F21F9F06 for ; Fri, 21 Jun 2013 12:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.46 X-Spam-Level: X-Spam-Status: No, score=-110.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMvAz6R-upRM for ; Fri, 21 Jun 2013 12:49:08 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4F52921F9EB7 for ; Fri, 21 Jun 2013 12:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1259; q=dns/txt; s=iport; t=1371844148; x=1373053748; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Pf+fk25+/FjL34/KLzerOzaJww0Phs6yv2D52WRj2ac=; b=ibggUPTQKK/VTHyuoNOby2GRioYefISjq75hIRDb4u1JYaMyuq9u+Efz IyycBnKrK1WIdMWrLDAF+UrDYikzTjdidXNzGq/D6Ap2aqRTSoUNe1f0d BNLT7faMdDug50Y2AH62YWEPtFhDx0o0outZXNyH+3+IQcMW+/kGcDBRz 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAIitxFGtJV2Y/2dsb2JhbABVBoMJer80gQUWdIIkAQEEOj0CEAIBCA4UFBAyJQIEDg2IBrxUjiNzAjEHgwBhA6kHgw+CKA X-IronPort-AV: E=Sophos;i="4.87,915,1363132800"; d="scan'208";a="225965268" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 21 Jun 2013 19:49:07 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5LJn7DP021324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Jun 2013 19:49:07 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Fri, 21 Jun 2013 14:49:07 -0500 From: "Fred Baker (fred)" To: Ronald Bonica Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHObrhjL3Ojw6JhC0OW06YU8Za0UA== Date: Fri, 21 Jun 2013 19:49:06 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B921F57@xmb-rcd-x09.cisco.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.125] Content-Type: text/plain; charset="us-ascii" Content-ID: <01726846F3D08E41B246781B1EAFC74C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 19:49:14 -0000 I suppose I'm the contrarian, but this draft gives me some heartburn surrou= nding the robustness principle. Yes, TCP MSS generally limits the use of fr= agmentation for IPv6. We don't have a counterpart to MSS for UDP, and other= s have noted that OSPF etc may have issues.=20 Thinking hypothetically, it would be unusual for OSPF to not be able to man= age packet size via LSA choice, but suppose I am on an interface that has a= given MTU, and I have a single LSA that is larger than that MTU, perhaps a= Router LSA on a wide fan-out unit. Deprecating the fragmentation capabilit= y forces each client of the network layer to create a means for fragmentati= on/segmentation. That might be some other protocol that essentially duplica= tes what we're deprecating, or it could be something in which a router has = to make enough routing instances of itself to split the Router LSA across t= hem, or something like that. Personally, I think I would prefer a statement that says that the first fra= gment MUST contain the transport header (which Fernando has been pushing), = and encourages transports and applications to implement some variation on P= MTU rather than depending on fragmentation, but not deprecating the capabil= ity.= From rbonica@juniper.net Fri Jun 21 12:54:24 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4645521F9C5A for ; Fri, 21 Jun 2013 12:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.957 X-Spam-Level: X-Spam-Status: No, score=-101.957 tagged_above=-999 required=5 tests=[AWL=1.510, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQy385VSDCDv for ; Fri, 21 Jun 2013 12:54:17 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id 659CB21F9C3F for ; Fri, 21 Jun 2013 12:54:17 -0700 (PDT) Received: from mail195-co9-R.bigfish.com (10.236.132.245) by CO9EHSOBE026.bigfish.com (10.236.130.89) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 19:54:05 +0000 Received: from mail195-co9 (localhost [127.0.0.1]) by mail195-co9-R.bigfish.com (Postfix) with ESMTP id 6256EC801C1 for ; Fri, 21 Jun 2013 19:54:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: PS0(zzzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail195-co9: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=rbonica@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail195-co9 (localhost.localdomain [127.0.0.1]) by mail195-co9 (MessageSwitch) id 1371844443801549_21600; Fri, 21 Jun 2013 19:54:03 +0000 (UTC) Received: from CO9EHSMHS020.bigfish.com (unknown [10.236.132.251]) by mail195-co9.bigfish.com (Postfix) with ESMTP id B7EDE140266 for ; Fri, 21 Jun 2013 19:54:03 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.54) by CO9EHSMHS020.bigfish.com (10.236.130.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Jun 2013 19:54:03 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 21 Jun 2013 12:54:03 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 21 Jun 2013 12:54:02 -0700 Received: from CO9EHSOBE010.bigfish.com (207.46.163.28) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 21 Jun 2013 12:57:28 -0700 Received: from mail81-co9-R.bigfish.com (10.236.132.247) by CO9EHSOBE010.bigfish.com (10.236.130.73) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 19:54:01 +0000 Received: from mail81-co9 (localhost [127.0.0.1]) by mail81-co9-R.bigfish.com (Postfix) with ESMTP id EB3801E01B3 for ; Fri, 21 Jun 2013 19:54:01 +0000 (UTC) Received: from mail81-co9 (localhost.localdomain [127.0.0.1]) by mail81-co9 (MessageSwitch) id 1371844440694308_15377; Fri, 21 Jun 2013 19:54:00 +0000 (UTC) Received: from CO9EHSMHS026.bigfish.com (unknown [10.236.132.242]) by mail81-co9.bigfish.com (Postfix) with ESMTP id A73F980058; Fri, 21 Jun 2013 19:54:00 +0000 (UTC) Received: from BY2PRD0512HT003.namprd05.prod.outlook.com (157.56.238.5) by CO9EHSMHS026.bigfish.com (10.236.130.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Jun 2013 19:54:00 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.17]) by BY2PRD0512HT003.namprd05.prod.outlook.com ([10.255.243.36]) with mapi id 14.16.0324.000; Fri, 21 Jun 2013 19:53:59 +0000 From: Ronald Bonica To: Ray Hunter Subject: RE: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHObc3OGhJfZWsTvkmEF1gJL7lsrZk+wGpwgAEPggCAAI03oIAACdsAgAAi/1CAAAnEgIAAAmuw Date: Fri, 21 Jun 2013 19:53:59 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2509F86075@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C48776.9070107@globis.net> <2CF4CB03E2AA464BA0982EC92A02CE2509F85FBA@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C4AD03.2050303@globis.net> In-Reply-To: <51C4AD03.2050303@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%GLOBIS.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%FORTHNETGROUP.GR$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 19:54:24 -0000 > I don't 100% agree. In the case that PMTUD is broken, there'd be > nothing to stop a current DNSSEC implementation from always assuming a > default path MTU of 1280, without awaiting confirmation from PMTUD, and > fragmenting the UDP packet pre-emptively [assuming fragmentation was > not equally broken along the path as ICMP PTB was]. >=20 Do any implementations actually do this? If they do, how well are they working, today? Ron From brian.e.carpenter@gmail.com Fri Jun 21 13:52:47 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B38221F9947 for ; Fri, 21 Jun 2013 13:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4d7wZ-Gd5Rac for ; Fri, 21 Jun 2013 13:52:41 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 079F221F91BF for ; Fri, 21 Jun 2013 13:52:37 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so8334770pbb.19 for ; Fri, 21 Jun 2013 13:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+8IZFYvdt4mej3JhpNcia7WHruaroOdGyUNfuQrTckM=; b=c1Y3ok0T8Za5zF50VXtg5TXb9lUzDYZvLeisblv8xc5nBykYqGF3ZB0CJ32hjEYaK7 gX9lid3ZnBWl/RnFHuRSyJIg2qw3kyMpG4Xl9eLavuHm3DRow/JJ/zGS8BkqkKEQrnd2 zjC9YIJhO1VAlYIeDuUOaFEOky7dh2Lx6kM7hcn3e8S6+1iTncttwSXvQuQjuf38Ua8d E8EFC1k0IiQasrOyfIBMUrXZK9Qq5j8c2TthP0aZGarcDEWQmj6i9wZnRf67u0SZK6So e93ElmBSZdpgAabQeWH2Nt6pPGk4Lkp+faufXvFqdqsTbjuTSdrww6Is3tZSD4Z6RQpy rE7Q== X-Received: by 10.66.159.195 with SMTP id xe3mr17835404pab.49.1371847956261; Fri, 21 Jun 2013 13:52:36 -0700 (PDT) Received: from [192.168.178.20] (36.200.69.111.dynamic.snap.net.nz. [111.69.200.36]) by mx.google.com with ESMTPSA id dj5sm6207540pbc.25.2013.06.21.13.52.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Jun 2013 13:52:35 -0700 (PDT) Message-ID: <51C4BD1E.6030002@gmail.com> Date: Sat, 22 Jun 2013 08:52:46 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ronald Bonica Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C48776.9070107@globis.net> <2CF4CB03E2AA464BA0982EC92A02CE2509F85FBA@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C4AD03.2050303@globis.net> <2CF4CB03E2AA464BA0982EC92A02CE2509F86075@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509F86075@BY2PRD0512MB653.namprd05.prod.outlook.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ray Hunter , "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 20:52:48 -0000 On 22/06/2013 07:53, Ronald Bonica wrote: >> I don't 100% agree. In the case that PMTUD is broken, there'd be >> nothing to stop a current DNSSEC implementation from always assuming a >> default path MTU of 1280, without awaiting confirmation from PMTUD, and >> fragmenting the UDP packet pre-emptively [assuming fragmentation was >> not equally broken along the path as ICMP PTB was]. >> > > Do any implementations actually do this? > > If they do, how well are they working, today? Does it matter? Since we know that fragmentation is broken on some paths due to broken firewalls, and that other paths have tunnels on them, and that MSS negotiation fails on some paths, today's sad reality is that the only safe link MTU for all times and places is 1280. I'm not yet convinced that deprecating fragmentation is sufficient to fix this problem. In this case, not being sufficient might also mean not necessary, so I'd like to see much more thorough analysis across the IETF as a whole before reaching a conclusion. (Thanks to the authors for coming out and saying it, though.) Brian From rbonica@juniper.net Fri Jun 21 15:01:07 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204E421F9E33 for ; Fri, 21 Jun 2013 15:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.738 X-Spam-Level: X-Spam-Status: No, score=-100.738 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zZENrR9aIYx for ; Fri, 21 Jun 2013 15:01:00 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 3057221F9E53 for ; Fri, 21 Jun 2013 15:01:00 -0700 (PDT) Received: from mail122-co1-R.bigfish.com (10.243.78.250) by CO1EHSOBE025.bigfish.com (10.243.66.88) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 22:00:59 +0000 Received: from mail122-co1 (localhost [127.0.0.1]) by mail122-co1-R.bigfish.com (Postfix) with ESMTP id 4E77F54031C for ; Fri, 21 Jun 2013 22:00:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: PS-26(zzbb2dI98dI9371I542I1432I1418Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275dhz2fh2a8h683h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail122-co1: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=rbonica@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail122-co1 (localhost.localdomain [127.0.0.1]) by mail122-co1 (MessageSwitch) id 1371852055816098_10901; Fri, 21 Jun 2013 22:00:55 +0000 (UTC) Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.226]) by mail122-co1.bigfish.com (Postfix) with ESMTP id BB935BC0088 for ; Fri, 21 Jun 2013 22:00:55 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.52) by CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Jun 2013 22:00:55 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 21 Jun 2013 15:00:54 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 21 Jun 2013 15:00:54 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.184) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 21 Jun 2013 15:04:19 -0700 Received: from mail119-co1-R.bigfish.com (10.243.78.251) by CO1EHSOBE013.bigfish.com (10.243.66.76) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Jun 2013 22:00:53 +0000 Received: from mail119-co1 (localhost [127.0.0.1]) by mail119-co1-R.bigfish.com (Postfix) with ESMTP id 17E9F3400F8 for ; Fri, 21 Jun 2013 22:00:53 +0000 (UTC) Received: from mail119-co1 (localhost.localdomain [127.0.0.1]) by mail119-co1 (MessageSwitch) id 1371852050140238_9750; Fri, 21 Jun 2013 22:00:50 +0000 (UTC) Received: from CO1EHSMHS010.bigfish.com (unknown [10.243.78.254]) by mail119-co1.bigfish.com (Postfix) with ESMTP id 15EA82008F; Fri, 21 Jun 2013 22:00:50 +0000 (UTC) Received: from BY2PRD0512HT004.namprd05.prod.outlook.com (157.56.238.5) by CO1EHSMHS010.bigfish.com (10.243.66.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Jun 2013 22:00:42 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.17]) by BY2PRD0512HT004.namprd05.prod.outlook.com ([10.255.243.37]) with mapi id 14.16.0324.000; Fri, 21 Jun 2013 22:00:41 +0000 From: Ronald Bonica To: Brian E Carpenter Subject: RE: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHObc3OGhJfZWsTvkmEF1gJL7lsrZk+wGpwgAEPggCAAI03oIAACdsAgAAi/1CAAAnEgIAAAmuwgAAQyACAAA47QA== Date: Fri, 21 Jun 2013 22:00:41 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2509F8625A@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C48776.9070107@globis.net> <2CF4CB03E2AA464BA0982EC92A02CE2509F85FBA@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C4AD03.2050303@globis.net> <2CF4CB03E2AA464BA0982EC92A02CE2509F86075@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C4BD1E.6030002@gmail.com> In-Reply-To: <51C4BD1E.6030002@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GLOBIS.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: Ray Hunter , "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 22:01:07 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4gRSBDYXJwZW50 ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6IEZyaWRheSwg SnVuZSAyMSwgMjAxMyA0OjUzIFBNDQo+IFRvOiBSb25hbGQgQm9uaWNhDQo+IENjOiBSYXkgSHVu dGVyOyBpcHY2QGlldGYub3JnIDZtYW4td2cNCj4gU3ViamVjdDogUmU6IEZXOiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJvbmljYS02bWFuLWZyYWctDQo+IGRlcHJlY2F0ZS0w MC50eHQNCj4gDQo+IE9uIDIyLzA2LzIwMTMgMDc6NTMsIFJvbmFsZCBCb25pY2Egd3JvdGU6DQo+ ID4+IEkgZG9uJ3QgMTAwJSBhZ3JlZS4gSW4gdGhlIGNhc2UgdGhhdCBQTVRVRCBpcyBicm9rZW4s IHRoZXJlJ2QgYmUNCj4gPj4gbm90aGluZyB0byBzdG9wIGEgY3VycmVudCBETlNTRUMgaW1wbGVt ZW50YXRpb24gZnJvbSBhbHdheXMgYXNzdW1pbmcNCj4gPj4gYSBkZWZhdWx0IHBhdGggTVRVIG9m IDEyODAsIHdpdGhvdXQgYXdhaXRpbmcgY29uZmlybWF0aW9uIGZyb20NCj4gUE1UVUQsDQo+ID4+ IGFuZCBmcmFnbWVudGluZyB0aGUgVURQIHBhY2tldCBwcmUtZW1wdGl2ZWx5IFthc3N1bWluZyBm cmFnbWVudGF0aW9uDQo+ID4+IHdhcyBub3QgZXF1YWxseSBicm9rZW4gYWxvbmcgdGhlIHBhdGgg YXMgSUNNUCBQVEIgd2FzXS4NCj4gPj4NCj4gPg0KPiA+IERvIGFueSBpbXBsZW1lbnRhdGlvbnMg YWN0dWFsbHkgZG8gdGhpcz8NCj4gPg0KPiA+IElmIHRoZXkgZG8sIGhvdyB3ZWxsIGFyZSB0aGV5 IHdvcmtpbmcsIHRvZGF5Pw0KPiANCj4gRG9lcyBpdCBtYXR0ZXI/IA0KDQpIaSBCcmlhbiwNCg0K SSB0aGluayB0aGF0IGl0IGRvZXMuIElmIGEgRE5TU0VDIGltcGxhbnRhdGlvbiBmcmFnbWVudHMg ZXZlcnkgcGFja2V0IGxhcmdlciB0aGFuIDEyODAgYnl0ZXMsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhl ciB0aGF0IHBhY2tldCBuZWVkcyB0byBiZSBmcmFnbWVudGVkOg0KDQotIGl0IGlnbm9yZXMgdGhl IGFkdmljZSBvZiBSRkMgMjQ2MCBhbmQgUkZDIDU0MDUNCi0gaXQgZG9lc24ndCB3b3JrIHZlcnkg d2VsbCB0b2RheSwgYmVjYXVzZSBzbyBtYW55IG9wZXJhdG9ycyBmaWx0ZXIgaXRzIGZyYWdtZW50 ZWQgb3V0cHV0DQoNCkFGQUlLUywgdGhlcmUgYXJlIHR3byB3YXlzIHRvIG1ha2UgdGhpcyBhcHBs aWNhdGlvbiB3b3JrIGJldHRlcjoNCg0KLSBtYWtlIHBlb3BsZSBzdG9wIGZpbHRlcmluZyBJUHY2 IGZyYWdtZW50cw0KLSBjaGFuZ2UgdGhlIGltcGxlbWVudGF0aW9uJ3MgYmVoYXZpb3INCg0KR2l2 ZW4gdGhhdCB0aGUgZm9ybWVyIGlzIGltcG9zc2libGUsIGl0IHNlZW1zIHRoYXQgdGhlIGxhdGVy IGlzIHJlcXVpcmVkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQoNCg0K DQo= From tore@fud.no Sat Jun 22 02:29:12 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35E421F9D55 for ; Sat, 22 Jun 2013 02:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nujgXFsDWZa9 for ; Sat, 22 Jun 2013 02:29:12 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id F004821F9D50 for ; Sat, 22 Jun 2013 02:29:07 -0700 (PDT) Received: from [2a02:fe0:cf16:20:21d:60ff:fe48:f59e] (port=37634 helo=wrath.fud.no) by greed.fud.no with esmtpa (Exim 4.80) (envelope-from ) id 1UqK80-0001Wz-7y; Sat, 22 Jun 2013 11:29:04 +0200 Message-ID: <51C56E60.5040009@fud.no> Date: Sat, 22 Jun 2013 11:29:04 +0200 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ronald Bonica Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 09:29:12 -0000 * Ronald Bonica > [draft-bonica-6man-frag-deprecate] Being an operator I would definitively welcome getting rid of the complexities dealing with IPv6 fragments bring. That said, the draft needs additional discussion on this could be accomplished without breaking assumptions made by other protocols, though. On my network, I have two legitimate consumers of IPv6 fragments: 1) OSPFv3. RFC 2740 A.1 says «OSPF does not define a way to fragment its protocol packets, and depends on IPv6 fragmentation when transmitting packets larger than the link MTU». It does goes on to say «the OSPF packet types that are likely to be large [...] can usually be split into several separate protocol packets, without loss of functionality. This is recommended; IPv6 fragmentation should be avoided whenever possible». In my experience however, the implementation vendors appears to have skipped over that last recommendation. 2) SIIT (RFC 6145). There are several corner cases where a SIIT translator, or an IPv6 node communicating with an IPv4 node through such a translator, have to deal with IPv6 fragments. In particular: - When a SIIT translator receives an IPv4 packet with DF=0 that would result in an IPv6 packet that would exceed the IPv6 link MTU, it will split the original packet into IPv6 fragments. - When a SIIT translator receives an IPv4 fragment, it will translate this into one or more IPv6 fragments. - When the SIIT translator receives an IPv4 packet with DF=0 it «SHOULD always include an IPv6 Fragment Header to indicate that the sender allows fragmentation». (I wouldn't miss this feature going away though, as I disable it anyway.) - When an IPv6 node receives an ICMPv6 Packet Too Big message indicating a Path MTU less than 1280, it should either 1) simply heed the indicated Path MTU, or 2) limit the size of subsequent transmitted packets to 1280 and include a Fragmentation header (w/MF=0, i.e., an "atomic" fragment) in them. See RFC 2460 section 5. I know that Linux takes this second approach, at least. I cannot support your draft until it discusses or provides solutions for the above considerations. Finally I'll note that in all of the above cases, the use of IPv6 fragments is limited to within a single administrative domain (i.e., my network), so the rationale that IPv6 fragmentation does not work over the Internet does not really apply. Best regards, Tore Anderson From marka@isc.org Sat Jun 22 19:49:35 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD8921E805E for ; Sat, 22 Jun 2013 19:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAEsCv1zlio6 for ; Sat, 22 Jun 2013 19:49:31 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 8325B21E804B for ; Sat, 22 Jun 2013 19:49:31 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 114AAC9494; Sun, 23 Jun 2013 02:49:20 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1371955768; bh=OgZu14a0dzYQz/Knxz6M4LbQ0q7vqkIvcxuMq82DBeY=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=D6dvv/5YQJ00zjIhiWhJCPRAIlVFFfNlmfIz4r1g7WfWVdkk5SFnKIxPoRKCn2axf S5g7WgjevxYqSB6Thl3X3j6UMMKo5hU4S1RpAQLBxMdoRbd97mKRt2PyD0My8ChUFC DwM97SZGnM0QoKVsqIznguv4f2RbK6AgjoXQkIgY= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Sun, 23 Jun 2013 02:49:20 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4B45B160082; Sun, 23 Jun 2013 02:50:17 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id PbvqOkRwp3H9; Sun, 23 Jun 2013 02:50:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E52A4160050; Sun, 23 Jun 2013 02:50:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3mINAWS5cLgX; Sun, 23 Jun 2013 02:50:16 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id 261B216004B; Sun, 23 Jun 2013 02:50:16 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 8352C362ABA1; Sun, 23 Jun 2013 12:49:08 +1000 (EST) To: Ronald Bonica From: Mark Andrews References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C48776.9070107@globis.net> <2CF4CB03E2AA464BA0982EC92A02CE2509F85FBA@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C4AD03.2050303@globis.net> <2CF4CB03E2AA464BA0982EC92A02CE2509F86075@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C4BD1E.6030002@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F8625A@BY2PRD0512MB653.namprd05.prod.outlook.com> Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt In-reply-to: Your message of "Fri, 21 Jun 2013 22:00:41 +0000." <2CF4CB03E2AA464BA0982EC92A02CE2509F8625A@BY2PRD0512MB653.namprd05.prod.outlook.com> Date: Sun, 23 Jun 2013 12:49:05 +1000 Message-Id: <20130623024908.8352C362ABA1@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Ray Hunter , "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 02:49:36 -0000 In message <2CF4CB03E2AA464BA0982EC92A02CE2509F8625A@BY2PRD0512MB653.namprd05.prod.outlook.com>, Ronald Bonica wri tes: > > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > > Sent: Friday, June 21, 2013 4:53 PM > > To: Ronald Bonica > > Cc: Ray Hunter; ipv6@ietf.org 6man-wg > > Subject: Re: FW: New Version Notification for draft-bonica-6man-frag- > > deprecate-00.txt > > > > On 22/06/2013 07:53, Ronald Bonica wrote: > > >> I don't 100% agree. In the case that PMTUD is broken, there'd be > > >> nothing to stop a current DNSSEC implementation from always assuming > > >> a default path MTU of 1280, without awaiting confirmation from > > PMTUD, > > >> and fragmenting the UDP packet pre-emptively [assuming fragmentation > > >> was not equally broken along the path as ICMP PTB was]. > > >> > > > > > > Do any implementations actually do this? > > > > > > If they do, how well are they working, today? > > > > Does it matter? > > Hi Brian, > > I think that it does. If a DNSSEC implantation fragments every packet larger than 1280 bytes, regardless of whet > her that packet needs to be fragmented: > > - it ignores the advice of RFC 2460 and RFC 5405 > - it doesn't work very well today, because so many operators filter its fragmented output > > AFAIKS, there are two ways to make this application work better: > > - make people stop filtering IPv6 fragments > - change the implementation's behavior > > Given that the former is impossible, it seems that the later is required. > > Ron Named has set IPv6_USE_MIN_MTU for years for UDP. There are plenty of paths that have path mtu issues but not fragmentation issues (tunnels). Many firewalls allow fragments out but not icmp back in. Named currently sets IPv6_USE_MIN_MTU for TCP. Mark > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Fred.L.Templin@boeing.com Sun Jun 23 16:02:02 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18AC021F9C74 for ; Sun, 23 Jun 2013 16:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ihb4LFixxrr for ; Sun, 23 Jun 2013 16:01:56 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 40DB121F9B83 for ; Sun, 23 Jun 2013 16:01:55 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r5NN1sUu024120 for ; Sun, 23 Jun 2013 16:01:54 -0700 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 r5NN1qRs024108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Sun, 23 Jun 2013 16:01:53 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-PHX-509.sw.nos.boeing.com ([169.254.9.166]) with mapi id 14.02.0328.011; Sun, 23 Jun 2013 16:01:52 -0700 From: "Templin, Fred L" To: Ronald Bonica Subject: RE: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHOb7w5C5ZzwkGsRUquv6wgyw9yxZlD6jrg Date: Sun, 23 Jun 2013 23:01:51 +0000 Message-ID: <2134F8430051B64F815C691A62D983180A7772@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C48776.9070107@globis.net> <2CF4CB03E2AA464BA0982EC92A02CE2509F85FBA@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C4AD03.2050303@globis.net> <2CF4CB03E2AA464BA0982EC92A02CE2509F86075@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C4BD1E.6030002@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F8625A@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130623024908.8352C362ABA1@drugs.dv.isc.org> In-Reply-To: <20130623024908.8352C362ABA1@drugs.dv.isc.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 Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 23:02:02 -0000 Hi, Deprecation of IPv6 fragmentation would make life difficult for IPv6 tunnels. For tunnels that span paths with ~1280 MTUs, the tunnel ingress' only option is to fragment since it is not permitted to return a PTB with MTU less than 1280. See RFC2473 for example of a normative specification that depends on IPv6 fragmentation. Thanks - Fred fred.l.templin@boeing.com From fred@cisco.com Sun Jun 23 16:12:06 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C93421F9F80 for ; Sun, 23 Jun 2013 16:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.584 X-Spam-Level: X-Spam-Status: No, score=-110.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rS4lJs9pA55B for ; Sun, 23 Jun 2013 16:11:59 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7D91021F9F78 for ; Sun, 23 Jun 2013 16:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1044; q=dns/txt; s=iport; t=1372029119; x=1373238719; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RZe2GyJI+BC1oGQ1BDcPB1PqZz5qHHlvRLsU1XJZuT8=; b=GRn4LmlLj/05RQ4nicJnnuyg+ZHcM6rSFcnSH4gAnupiy/yN4a51VxlH zOh/nkBgQL44pY+ZTESRhcwSWk/ktQiBkXT/J8mg7heAsJ3nAmLznBBem OVisHUAvW6CuPKYVJrr2ISZMjnti/hserTcUjmy3BFhUmmsRHCCDlgCIA A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFALV/x1GtJXG9/2dsb2JhbABbgwl6vzd+FnSCIwEBAQMBbAoBAgULAgEIGAokMiUCBA4FCBOHbQa4QY8cAjEHgwJhA4hpoB6DEIIo X-IronPort-AV: E=Sophos;i="4.87,924,1363132800"; d="scan'208";a="226489848" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 23 Jun 2013 23:11:59 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5NNBwPe010499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 23 Jun 2013 23:11:58 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Sun, 23 Jun 2013 18:11:58 -0500 From: "Fred Baker (fred)" To: Tore Anderson Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHOcGcOI1L7sow7kkSTr5SDOLoWMA== Date: Sun, 23 Jun 2013 23:11:57 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> In-Reply-To: <51C56E60.5040009@fud.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.125] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 23:12:06 -0000 On Jun 22, 2013, at 2:29 AM, Tore Anderson wrote: > - When a SIIT translator receives an IPv4 packet with DF=3D0 that would > result in an IPv6 packet that would exceed the IPv6 link MTU, it will > split the original packet into IPv6 fragments. It *could* fragment the IPv4 packet and send it in two unfragmented IPv6 pa= ckets. > I cannot support your draft until it discusses or provides solutions for > the above considerations. I'm in a similar case with respect to protocols above IPv6 (OSPF and NFS/UD= P come quickly to mind) that depend on fragmentation to deal with the issue= . I think the Robustness Principle tells us that such applications SHOULD f= igure out how to live with PMTU, but it also tells us that we can't depreca= te fragmentation unless all known instances that depend on it have defined = practical work-arounds. I suspect that this would imply the re-creation of = the fragmentation feature in an intermediate protocol, which seems like a l= ot of work with little real gain.= From gdt@gdt.id.au Sun Jun 23 17:53:36 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4183221F9FA5 for ; Sun, 23 Jun 2013 17:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuT0IPkjMYM3 for ; Sun, 23 Jun 2013 17:53:30 -0700 (PDT) Received: from neotokyo.gdt.id.au (neotokyo.adelaide.aarnet.edu.au [202.158.193.52]) by ietfa.amsl.com (Postfix) with ESMTP id 0E79D21F9CD9 for ; Sun, 23 Jun 2013 17:53:29 -0700 (PDT) Received: from [192.168.255.5] (eth6445.sa.adsl.internode.on.net [150.101.30.44]) by neotokyo.gdt.id.au (Postfix) with ESMTPSA id 0E18932A0C82; Mon, 24 Jun 2013 10:23:15 +0930 (CST) Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_58D9B586-CA7E-48D5-BFFF-24A536B6BA46" From: Glen Turner In-Reply-To: <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> Date: Mon, 24 Jun 2013 10:23:12 +0930 Message-Id: References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> To: Fred Baker (fred) X-Mailer: Apple Mail (2.1283) X-Virus-Scanned: clamav-milter 0.97.8 at neotokyo X-Virus-Status: Clean Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 00:53:36 -0000 --Apple-Mail=_58D9B586-CA7E-48D5-BFFF-24A536B6BA46 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 24/06/2013, at 8:41 AM, Fred Baker (fred) wrote: >=20 > I'm in a similar case with respect to protocols above IPv6 (OSPF and = NFS/UDP come quickly to mind) that depend on fragmentation to deal with = the issue. I think the Robustness Principle tells us that such = applications SHOULD figure out how to live with PMTU, but it also tells = us that we can't deprecate fragmentation unless all known instances that = depend on it have defined practical work-arounds. I suspect that this = would imply the re-creation of the fragmentation feature in an = intermediate protocol, which seems like a lot of work with little real = gain. Calculating the PMTU for UDP protocols is left to applications, the = sockets API doesn't do this under the hood like it does for TCP. As a = result most UDP-using applications don't probe the PMTU. This is the = case for both IPv4 and IPv6, although the effect with IPv6 is lost = connectivity rather than in-flight fragmentation. Some small changes to the socket API for unconnected protocols would = make life substantially better for RADIUS implementors (and, I imagine, = DNS). We're more than happy to repeatedly pass the same application = protocol data unit into the socket whilst the socket probes the path = MTU. -glen= --Apple-Mail=_58D9B586-CA7E-48D5-BFFF-24A536B6BA46 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

    I'm in a similar = case with respect to protocols above IPv6 (OSPF and NFS/UDP come quickly = to mind) that depend on fragmentation to deal with the issue. I think = the Robustness Principle tells us that such applications SHOULD figure = out how to live with PMTU, but it also tells us that we can't deprecate = fragmentation unless all known instances that depend on it have defined = practical work-arounds. I suspect that this would imply the re-creation = of the fragmentation feature in an intermediate protocol, which seems = like a lot of work with little real = gain.

    Calculating the PMTU for UDP = protocols is left to applications, the sockets API doesn't do this under = the hood like it does for TCP. As a result most UDP-using applications = don't probe the PMTU. This is the case for both IPv4 and IPv6, although = the effect with IPv6 is lost connectivity rather than in-flight = fragmentation.

    Some small changes to the socket = API for unconnected protocols would make life substantially better for = RADIUS implementors (and, I imagine, DNS). We're more than happy to = repeatedly pass the same application protocol data unit into the socket = whilst the socket probes the path = MTU.

    -glen
    = --Apple-Mail=_58D9B586-CA7E-48D5-BFFF-24A536B6BA46-- From ggm@algebras.org Sun Jun 23 17:59:59 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346D411E80BA for ; Sun, 23 Jun 2013 17:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.844 X-Spam-Level: X-Spam-Status: No, score=-0.844 tagged_above=-999 required=5 tests=[AWL=1.133, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+9hfC6cIyh3 for ; Sun, 23 Jun 2013 17:59:58 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C01DE11E80D9 for ; Sun, 23 Jun 2013 17:59:58 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id uo1so10230547pbc.3 for ; Sun, 23 Jun 2013 17:59:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=EB+WU8pc4bOm80YS0d1jPD0zIoxgPLtRAFcYMBO+Rjk=; b=NAJW3RPP1LxKmfSilrFz3ha4YRHUr0lhsrRy01IN0hXyoS+A3JoKO4Zdcewfwz+Dpu q4fmDTghvDSrt0dY7LFmv0Kr2iNGMA2cScqbVppJx7uglW+ONWzwkd1JBBzxN1xEf2g9 EJOjg8Ntl1n2K7BhpuCS2054DSh0Y2AcyfjtIHu9g8jf1mhkLqwm9qv5qc6p6g1wKkQT jKbzkRB39C67duiE1X3W03BuooXa4Kr2O4TlDYj1A6rmuYJtgN74i4s4JDGs0e8h91U2 psX9Crs8Z1EiuLjKH329JcKEXBZu777vAs3WR4MIiWqNyzgPam50MWEghJ2UQmVT9E8X yRNA== MIME-Version: 1.0 X-Received: by 10.66.154.225 with SMTP id vr1mr25984646pab.85.1372035598095; Sun, 23 Jun 2013 17:59:58 -0700 (PDT) Received: by 10.70.25.195 with HTTP; Sun, 23 Jun 2013 17:59:58 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:e9d1:153a:bc3:8194] In-Reply-To: <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> Date: Mon, 24 Jun 2013 10:59:58 +1000 Message-ID: Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt From: George Michaelson To: "ipv6@ietf.org 6man-wg" Content-Type: multipart/alternative; boundary=047d7bacbcec71aa7304dfdbeeeb X-Gm-Message-State: ALoCoQmS2uVDmCaHDBII/alJfMWRL3E/NuGVTruynlqi1BgH2nhmYjn18mY9EkGmi63kmRjr3ip7 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 00:59:59 -0000 --047d7bacbcec71aa7304dfdbeeeb Content-Type: text/plain; charset=ISO-8859-1 Ron asserts the following two statements in this 00 draft: "..." As a result, IPv6 fragments carrying TCP payload are rarely observed on the Internet. and "..." Because many UDP-based applications follow the above-quoted recommendation, IPv6 fragments carrying UDP traffic are also rarely observed on the Internet. I'd like to understand the basis of these assertions. I believe what I am seeing, on the edge, suggests there is in fact V6 fragmentation in both TCP and UDP. Ron also asserts: The following is a list of UDP-based applications that do not follow the recommendation of [RFC5405] and rely in IPv6 fragmentation: o DNSSEC [RFC4035] The effectiveness of these protocols may currently be degraded by operator behavior. SeeSection 2.4 for details. I'd like to point out that at least BIND imposes a 1280 IPv6 packet limit. Its wired into the code. -George --047d7bacbcec71aa7304dfdbeeeb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Ron asserts the following two statements in this 00 draft:=

    =A0 =A0 =A0"..." As a result, IPv6 fragments = carrying TCP payload are rarely observed on the Internet.
    <= br>
    and
    =A0 =A0 =A0"..." Because many UDP-= based applications follow the above-quoted recommendation, IPv6 fragments c= arrying UDP traffic are also rarely observed on the Internet.


    I'd like to understand the ba= sis of these assertions. I believe what I am seeing, on the edge, suggests = there is in fact V6 fragmentation in both TCP and UDP.


    Ron also asserts:

    =A0 The following is a list of UDP-based applica= tions that do not follow the recommendation of [RFC5405] =A0and rely in IPv= 6 fragmentation:

    =A0 =A0o =A0DNSSEC [RFC4035]

    = =A0 =A0The effectiveness of these protocols may currently be degraded by op= erator behavior. =A0SeeSection 2.4 for details.

    I'd like to point out that at least BI= ND imposes a 1280 IPv6 packet limit. Its wired into the code.

    -George=
    --047d7bacbcec71aa7304dfdbeeeb-- From marka@isc.org Sun Jun 23 18:13:07 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DF921E8056 for ; Sun, 23 Jun 2013 18:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPuy10qpxzRe for ; Sun, 23 Jun 2013 18:13:03 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 608F021E804C for ; Sun, 23 Jun 2013 18:13:03 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 45678C94AD; Mon, 24 Jun 2013 01:12:49 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372036377; bh=dbN0hiTgdnbzGpf8dR34Ml72e/wNd5dSeYWMMpoabOs=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=ISSKXXOyG9kSEsaWgCgb2Rjb8X3PAtaqqK8Bne+KW3KF3Aj6tnT+iX+kKHZ9Irfcs aO2z4aLEd5aOuVwvNYFdSi9ezRPIPY7+Z42uZ7b2Jx/sNRLDXi4d6SyAn97EH9OdoS 8ce8hnt+feydqzUB6xth5XQoJK+ugnSXH+VU8kfQ= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Mon, 24 Jun 2013 01:12:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9D440160088; Mon, 24 Jun 2013 01:13:50 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 15BTx1TX6Ywp; Mon, 24 Jun 2013 01:13:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 12F5A160087; Mon, 24 Jun 2013 01:13:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Av214p-xdbNB; Mon, 24 Jun 2013 01:13:49 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id A41DF160051; Mon, 24 Jun 2013 01:13:49 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 11C1A362DA81; Mon, 24 Jun 2013 08:41:51 +1000 (EST) To: "Fred Baker (fred)" From: Mark Andrews References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> <8C48B86A895913448548E6D15DA7553B921F57@xmb-rcd-x09.cisco.com> Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt In-reply-to: Your message of "Fri, 21 Jun 2013 19:49:06 +0000." <8C48B86A895913448548E6D15DA7553B921F57@xmb-rcd-x09.cisco.com> Date: Mon, 24 Jun 2013 08:41:50 +1000 Message-Id: <20130623224151.11C1A362DA81@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 01:13:07 -0000 In message <8C48B86A895913448548E6D15DA7553B921F57@xmb-rcd-x09.cisco.com>, "Fred Baker (fred)" writes: > I suppose I'm the contrarian, but this draft gives me some heartburn surrounding the robustness principle. Yes, > TCP MSS generally limits the use of fragmentation for IPv6. We don't have a counterpart to MSS for UDP, and othe > rs have noted that OSPF etc may have issues. > > Thinking hypothetically, it would be unusual for OSPF to not be able to manage packet size via LSA choice, but s > uppose I am on an interface that has a given MTU, and I have a single LSA that is larger than that MTU, perhaps > a Router LSA on a wide fan-out unit. Deprecating the fragmentation capability forces each client of the network > layer to create a means for fragmentation/segmentation. That might be some other protocol that essentially dupli > cates what we're deprecating, or it could be something in which a router has to make enough routing instances of > itself to split the Router LSA across them, or something like that. > > Personally, I think I would prefer a statement that says that the first fragment MUST contain the transport head > er (which Fernando has been pushing), and encourages transports and applications to implement some variation on > PMTU rather than depending on fragmentation, but not deprecating the capability. Or additionallty supply the information the firewall is looking for in a skipable hop-by-hop option. For UDP that would be the two ports. 6 to 8 extra octets per fragment. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jiangsheng@huawei.com Sun Jun 23 18:46:51 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA38321F9983 for ; Sun, 23 Jun 2013 18:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmZMtYY4Kj1F for ; Sun, 23 Jun 2013 18:46:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1B92D21F9007 for ; Sun, 23 Jun 2013 18:46:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AST85350; Mon, 24 Jun 2013 01:46:07 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 24 Jun 2013 02:44:06 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 24 Jun 2013 02:44:41 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Mon, 24 Jun 2013 09:44:33 +0800 From: Sheng Jiang To: "Fred Baker (fred)" , Ronald Bonica Subject: RE: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHObrh5oVnOfg0y+kmEyboR2MaX65lEGBeQ Date: Mon, 24 Jun 2013 01:44:32 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923ACA4B26@nkgeml512-mbx.china.huawei.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> <8C48B86A895913448548E6D15DA7553B921F57@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B921F57@xmb-rcd-x09.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 Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 01:46:51 -0000 PkZyb206IGlwdjYtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mDQo+RnJlZCBCYWtlciAoZnJlZCkNCj5TZW50OiBTYXR1cmRheSwgSnVu ZSAyMiwgMjAxMyAzOjQ5IEFNDQo+VG86IFJvbmFsZCBCb25pY2ENCj5DYzogaXB2NkBpZXRmLm9y ZyA2bWFuLXdnDQo+U3ViamVjdDogUmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj5k cmFmdC1ib25pY2EtNm1hbi1mcmFnLWRlcHJlY2F0ZS0wMC50eHQNCj4NCj5JIHN1cHBvc2UgSSdt IHRoZSBjb250cmFyaWFuDQoNCisxLiBGb3IgbWUsIHRoaXMgZHJhZnQgbG9va3MgZGFuZ2Vyb3Vz IGJ5IHByb3Bvc2luZyB0byBkZXByZWNhdGUgZnJhZ21lbnRhdGlvbiB3aXRoIG9ubHkgb25lLXNp ZGUgb2JzZXJ2YXRpb24uIFRoaXMgZHJhZnQgZG9lcyBub3QgZ2l2ZSBlbm91Z2ggYW5hbHlzaXMg b24gdGhlc2UgZXhpc3RpbmcgZnJhZ21lbnRhdGlvbiB1c2UgY2FzZXMsIHBhcnRpY3VsYXJseSB0 aGVzZSB1c2UgY2FzZXMgdGhlIGZyYWdtZW50cyB3aXRoaW4gYSBzaW5nbGUgZG9tYWluLg0KDQpP biBvdGhlciBzaWRlICwgb25seSBkaXNhbGxvd2luZyBmcmFnbWVudGF0aW9uIHRvIGJlIHVzZWQg YW1vbmcgZG9tYWlucyBtYXkgaGVscGZ1bCB0byByZWR1Y2UgdGhlIG9wZXJhdGlvbmFsIGNvbXBs ZXguDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPmJ1dCB0aGlzIGRyYWZ0IGdpdmVzIG1l IHNvbWUgaGVhcnRidXJuDQo+c3Vycm91bmRpbmcgdGhlIHJvYnVzdG5lc3MgcHJpbmNpcGxlLiBZ ZXMsIFRDUCBNU1MgZ2VuZXJhbGx5IGxpbWl0cyB0aGUgdXNlIG9mDQo+ZnJhZ21lbnRhdGlvbiBm b3IgSVB2Ni4gV2UgZG9uJ3QgaGF2ZSBhIGNvdW50ZXJwYXJ0IHRvIE1TUyBmb3IgVURQLCBhbmQN Cj5vdGhlcnMgaGF2ZSBub3RlZCB0aGF0IE9TUEYgZXRjIG1heSBoYXZlIGlzc3Vlcy4NCj4NCj5U aGlua2luZyBoeXBvdGhldGljYWxseSwgaXQgd291bGQgYmUgdW51c3VhbCBmb3IgT1NQRiB0byBu b3QgYmUgYWJsZSB0bw0KPm1hbmFnZSBwYWNrZXQgc2l6ZSB2aWEgTFNBIGNob2ljZSwgYnV0IHN1 cHBvc2UgSSBhbSBvbiBhbiBpbnRlcmZhY2UgdGhhdCBoYXMNCj5hIGdpdmVuIE1UVSwgYW5kIEkg aGF2ZSBhIHNpbmdsZSBMU0EgdGhhdCBpcyBsYXJnZXIgdGhhbiB0aGF0IE1UVSwgcGVyaGFwcyBh DQo+Um91dGVyIExTQSBvbiBhIHdpZGUgZmFuLW91dCB1bml0LiBEZXByZWNhdGluZyB0aGUgZnJh Z21lbnRhdGlvbiBjYXBhYmlsaXR5DQo+Zm9yY2VzIGVhY2ggY2xpZW50IG9mIHRoZSBuZXR3b3Jr IGxheWVyIHRvIGNyZWF0ZSBhIG1lYW5zIGZvcg0KPmZyYWdtZW50YXRpb24vc2VnbWVudGF0aW9u LiBUaGF0IG1pZ2h0IGJlIHNvbWUgb3RoZXIgcHJvdG9jb2wgdGhhdA0KPmVzc2VudGlhbGx5IGR1 cGxpY2F0ZXMgd2hhdCB3ZSdyZSBkZXByZWNhdGluZywgb3IgaXQgY291bGQgYmUgc29tZXRoaW5n IGluDQo+d2hpY2ggYSByb3V0ZXIgaGFzIHRvIG1ha2UgZW5vdWdoIHJvdXRpbmcgaW5zdGFuY2Vz IG9mIGl0c2VsZiB0byBzcGxpdCB0aGUNCj5Sb3V0ZXIgTFNBIGFjcm9zcyB0aGVtLCBvciBzb21l dGhpbmcgbGlrZSB0aGF0Lg0KPg0KPlBlcnNvbmFsbHksIEkgdGhpbmsgSSB3b3VsZCBwcmVmZXIg YSBzdGF0ZW1lbnQgdGhhdCBzYXlzIHRoYXQgdGhlIGZpcnN0IGZyYWdtZW50DQo+TVVTVCBjb250 YWluIHRoZSB0cmFuc3BvcnQgaGVhZGVyICh3aGljaCBGZXJuYW5kbyBoYXMgYmVlbiBwdXNoaW5n KSwgYW5kDQo+ZW5jb3VyYWdlcyB0cmFuc3BvcnRzIGFuZCBhcHBsaWNhdGlvbnMgdG8gaW1wbGVt ZW50IHNvbWUgdmFyaWF0aW9uIG9uDQo+UE1UVSByYXRoZXIgdGhhbiBkZXBlbmRpbmcgb24gZnJh Z21lbnRhdGlvbiwgYnV0IG5vdCBkZXByZWNhdGluZyB0aGUNCj5jYXBhYmlsaXR5Lg0KPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+SUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+aXB2NkBpZXRm Lm9yZw0KPkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lwdjYNCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K From dougb@dougbarton.us Sun Jun 23 18:53:44 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D3721E8085 for ; Sun, 23 Jun 2013 18:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0ZgmNvmy7UG for ; Sun, 23 Jun 2013 18:53:43 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1D34F21E8083 for ; Sun, 23 Jun 2013 18:53:43 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:224:e8ff:fe30:109b] (unknown [IPv6:2001:470:d:5e7:224:e8ff:fe30:109b]) by dougbarton.us (Postfix) with ESMTPSA id A49CE22B0F for ; Mon, 24 Jun 2013 01:53:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1372038819; bh=Z201fLaiAnKWcQR2CXdImOMTdMEeeQHy8WOhmIU4hXM=; h=Date:From:To:Subject:References:In-Reply-To; b=QVe39L/LKtQ3O5o8MYOEVspy7Wuw04D8g7xK5X2/RBqT3b+kuyWjvBsS61QYabRBz lPG4Tsre9bjy12WyFEoEYvkjZVkhqeB2uxvXaygM+XlbBNqVBl0Py7KU7E+YhRfW6I IbMBGLcNVneOStk9jjujRbZci11OpY8Hs0sqUccs= Message-ID: <51C7A69F.40400@dougbarton.us> Date: Sun, 23 Jun 2013 18:53:35 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C48776.9070107@globis.net> <2CF4CB03E2AA464BA0982EC92A02CE2509F85FBA@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C4AD03.2050303@globis.net> <2CF4CB03E2AA464BA0982EC92A02CE2509F86075@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C4BD1E.6030002@gmail.com> In-Reply-To: <51C4BD1E.6030002@gmail.com> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 01:53:44 -0000 On 06/21/2013 01:52 PM, Brian E Carpenter wrote: > On 22/06/2013 07:53, Ronald Bonica wrote: >>> I don't 100% agree. In the case that PMTUD is broken, there'd be >>> nothing to stop a current DNSSEC implementation from always assuming a >>> default path MTU of 1280, without awaiting confirmation from PMTUD, and >>> fragmenting the UDP packet pre-emptively [assuming fragmentation was >>> not equally broken along the path as ICMP PTB was]. >>> >> >> Do any implementations actually do this? >> >> If they do, how well are they working, today? > > Does it matter? Since we know that fragmentation is broken on some > paths due to broken firewalls, and that other paths have tunnels > on them, and that MSS negotiation fails on some paths, today's > sad reality is that the only safe link MTU for all times and places > is 1280. > > I'm not yet convinced that deprecating fragmentation is sufficient > to fix this problem. In this case, not being sufficient might > also mean not necessary, so I'd like to see much more thorough > analysis across the IETF as a whole before reaching a conclusion. > > (Thanks to the authors for coming out and saying it, though.) Given that larger and faster pipes are becoming more common, and given that we know that larger packet sizes make for more efficient utilization of those pipes, IMO it's a really bad idea to "give up the fight" at this early stage in IPv6 deployment. Until there is dramatic evidence to the contrary it seems to me that it's still worthwhile to push for making the protocol work as designed. Doug From leo.liubing@huawei.com Sun Jun 23 19:19:22 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14C321E80A3 for ; Sun, 23 Jun 2013 19:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fqfd6DnMJt9q for ; Sun, 23 Jun 2013 19:19:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 16B8221E808D for ; Sun, 23 Jun 2013 19:19:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUG88807; Mon, 24 Jun 2013 02:19:16 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 24 Jun 2013 03:18:37 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 24 Jun 2013 10:19:13 +0800 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.240]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Mon, 24 Jun 2013 10:19:07 +0800 From: "Liubing (Leo)" To: "Templin, Fred L" , Ronald Bonica Subject: RE: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHOb7w5GhJfZWsTvkmEF1gJL7lsrZlDZbaAgAC4lMA= Date: Mon, 24 Jun 2013 02:19:06 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D734FB7@nkgeml506-mbx.china.huawei.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C48776.9070107@globis.net> <2CF4CB03E2AA464BA0982EC92A02CE2509F85FBA@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C4AD03.2050303@globis.net> <2CF4CB03E2AA464BA0982EC92A02CE2509F86075@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C4BD1E.6030002@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F8625A@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130623024908.8352C362ABA1@drugs.dv.isc.org> <2134F8430051B64F815C691A62D983180A7772@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180A7772@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ipv6@ietf.org List" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 02:19:23 -0000 I have the similar concern. Especially in the softwire context, fragmentation is always an important co= nsideration when developing various tunneling mechanisms. B.R. Bing > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Templin, Fred L > Sent: Monday, June 24, 2013 7:02 AM > To: Ronald Bonica > Cc: ipv6@ietf.org 6man-wg > Subject: RE: FW: New Version Notification for > draft-bonica-6man-frag-deprecate-00.txt >=20 > Hi, >=20 > Deprecation of IPv6 fragmentation would make life difficult for IPv6 > tunnels. For tunnels that span paths with ~1280 MTUs, the tunnel ingress' > only option is to fragment since it is not permitted to return a PTB with > MTU less than 1280. See RFC2473 for example of a normative specification > that depends on IPv6 fragmentation. >=20 > Thanks - Fred > fred.l.templin@boeing.com > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From marka@isc.org Sun Jun 23 20:10:03 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D718C21F9BC8 for ; Sun, 23 Jun 2013 20:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POolXK01QzoN for ; Sun, 23 Jun 2013 20:09:58 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 898B521F9360 for ; Sun, 23 Jun 2013 20:09:58 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id CA21BC9424; Mon, 24 Jun 2013 03:09:49 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372043398; bh=XhIK456Smnvq8IyOFH3wwWlKIxiMgfPHT36kSa2r9T0=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Vlbc3Gm0RiTLJbHL3pqVU9nG0JScXn8VsFuYapotgBz2CaYHpxvomkmERoQacQDgk lZTdRR25w1ms4bgZkfy4nab2LY4X4LKfKrq4b2tM0LCEup61I5JhHaS5B5qiYxx1bZ eLNJNkE4P0f9MwsKhtvliV6gNPRZZ4ovsVB26/NI= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Mon, 24 Jun 2013 03:09:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 84FFB160056; Mon, 24 Jun 2013 03:10:51 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id m9o_9J7g4kPo; Mon, 24 Jun 2013 03:10:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C0BDC160089; Mon, 24 Jun 2013 03:10:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2gBhJEfxIvSl; Mon, 24 Jun 2013 03:10:50 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id 53DD3160088; Mon, 24 Jun 2013 03:10:50 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id CA0DD363070C; Mon, 24 Jun 2013 13:09:39 +1000 (EST) To: Doug Barton From: Mark Andrews References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C48776.9070107@globis.net> <2CF4CB03E2AA464BA0982EC92A02CE2509F85FBA@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C4AD03.2050303@globis.net> <2CF4CB03E2AA464BA0982EC92A02CE2509F86075@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C4BD1E.6030002@gmail.com> <51C7A69F.40400@dougbarton.us> Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt In-reply-to: Your message of "Sun, 23 Jun 2013 18:53:35 -0700." <51C7A69F.40400@dougbarton.us> Date: Mon, 24 Jun 2013 13:09:39 +1000 Message-Id: <20130624030939.CA0DD363070C@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 03:10:03 -0000 In message <51C7A69F.40400@dougbarton.us>, Doug Barton writes: > Given that larger and faster pipes are becoming more common, and given > that we know that larger packet sizes make for more efficient > utilization of those pipes, IMO it's a really bad idea to "give up the > fight" at this early stage in IPv6 deployment. > > Until there is dramatic evidence to the contrary it seems to me that > it's still worthwhile to push for making the protocol work as designed. > > Doug For DNS PMTUD is just too slow (TCP) or doesn't work (UDP) as the servers don't keep query state to resend replies on ICMPv6 frag required and client retries are just too slow to trigger the resend. This is why I pushed for a way to say fragment at 1280 back in '98[1] which became IPv6_USE_MIN_MTU[2]. A recursive server has around 3 seconds to do a DNS lookup before the client gives up. In that time it has to talk to multiple servers. Deal with dead servers. Deal with packet loss due to congestion. Deal with broken servers that don't respond. Deal with PMTUD. Deal with broken firewalls that don't pass fragments. PMTUD can be eliminated by setting IPv6_USE_MIN_MTU. This should result in UDP fragments and TCP segments that don't get blocked due to IP packet size. Some TCP stacks are broken as IPv6_USE_MIN_MTU is ignored when they do their MSS negotiation. As far as I can see the main reason fragmentation becomes a issue is that firewalls and load balancers can't determine what to do with a fragment as some information from the L4 header is missing. If we supply that information in every fragment as a hop-by-hop option{s} most of the problems are addressed. You still have some firewalls that want to do deep inspection of the packet but even then they could reassemble after filtering based on the hop-by-hop option{s} which would provide some protection to the reassembly queues on the firewall. I also don't see what the deep inspection of UDP/DNS packets is trying to accomplish when the same firewall passes TCP/DNS messages without reassembling them. If you are a malicious server you would just set TC=1 and attack the client over TCP. Yes, most clients do correctly handle TC=1. Mark [1] https://datatracker.ietf.org/doc/draft-ietf-ipngwg-bsd-frag/ [2] http://tools.ietf.org/html/rfc3542 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From tore@fud.no Mon Jun 24 00:45:55 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9062D21F9D7D for ; Mon, 24 Jun 2013 00:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlJaNefwS+E3 for ; Mon, 24 Jun 2013 00:45:54 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id B2E1721E80D0 for ; Mon, 24 Jun 2013 00:45:49 -0700 (PDT) Received: from [2a02:fe0:cf16:20:21d:60ff:fe48:f59e] (port=33409 helo=wrath.fud.no) by greed.fud.no with esmtpa (Exim 4.80) (envelope-from ) id 1Ur1T4-0006zu-LS; Mon, 24 Jun 2013 09:45:42 +0200 Message-ID: <51C7F926.6030902@fud.no> Date: Mon, 24 Jun 2013 09:45:42 +0200 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Fred Baker (fred)" Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 07:45:55 -0000 * Fred Baker (fred) > On Jun 22, 2013, at 2:29 AM, Tore Anderson wrote: >> - When a SIIT translator receives an IPv4 packet with DF=0 that >> would result in an IPv6 packet that would exceed the IPv6 link MTU, >> it will split the original packet into IPv6 fragments. > > It *could* fragment the IPv4 packet and send it in two unfragmented > IPv6 packets. Wouldn't doing IPv4 fragmentation before translation to IPv6 be logically identical to this other case I mentioned? >> - When a SIIT translator receives an IPv4 fragment, it will translate >> this into one or more IPv6 fragments. I can't see how simply omitting the Fragmentation header in the IPv6 output could work here, as the node receiving those two unfragmented IPv6 packets would see the first one containing a truncated L4 payload, while the second one would be just garbage as it doesn't include a L4 header. Tore From rbonica@juniper.net Mon Jun 24 07:31:15 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76FB21E8132 for ; Mon, 24 Jun 2013 07:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.207 X-Spam-Level: X-Spam-Status: No, score=-100.207 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjGgNmosnfEr for ; Mon, 24 Jun 2013 07:31:09 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0186.outbound.messaging.microsoft.com [213.199.154.186]) by ietfa.amsl.com (Postfix) with ESMTP id 8188B21E8134 for ; Mon, 24 Jun 2013 07:31:08 -0700 (PDT) Received: from mail123-db8-R.bigfish.com (10.174.8.241) by DB8EHSOBE037.bigfish.com (10.174.4.100) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Jun 2013 14:31:07 +0000 Received: from mail123-db8 (localhost [127.0.0.1]) by mail123-db8-R.bigfish.com (Postfix) with ESMTP id 5A30216006A for ; Mon, 24 Jun 2013 14:31:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz9371I542I1432I1447Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail123-db8: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=rbonica@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail123-db8 (localhost.localdomain [127.0.0.1]) by mail123-db8 (MessageSwitch) id 1372084232769417_24478; Mon, 24 Jun 2013 14:30:32 +0000 (UTC) Received: from DB8EHSMHS002.bigfish.com (unknown [10.174.8.253]) by mail123-db8.bigfish.com (Postfix) with ESMTP id AE0E820045 for ; Mon, 24 Jun 2013 14:30:32 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.50) by DB8EHSMHS002.bigfish.com (10.174.4.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 24 Jun 2013 14:30:29 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 24 Jun 2013 07:30:23 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 24 Jun 2013 07:30:23 -0700 Received: from CH1EHSOBE020.bigfish.com (216.32.181.185) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 24 Jun 2013 07:33:42 -0700 Received: from mail116-ch1-R.bigfish.com (10.43.68.236) by CH1EHSOBE020.bigfish.com (10.43.70.77) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Jun 2013 14:30:22 +0000 Received: from mail116-ch1 (localhost [127.0.0.1]) by mail116-ch1-R.bigfish.com (Postfix) with ESMTP id 51CF1420274 for ; Mon, 24 Jun 2013 14:30:22 +0000 (UTC) Received: from mail116-ch1 (localhost.localdomain [127.0.0.1]) by mail116-ch1 (MessageSwitch) id 1372084171340723_3873; Mon, 24 Jun 2013 14:29:31 +0000 (UTC) Received: from CH1EHSMHS013.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail116-ch1.bigfish.com (Postfix) with ESMTP id EE0302A00DA; Mon, 24 Jun 2013 14:29:22 +0000 (UTC) Received: from BY2PRD0512HT003.namprd05.prod.outlook.com (157.56.238.5) by CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 24 Jun 2013 14:29:20 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.17]) by BY2PRD0512HT003.namprd05.prod.outlook.com ([10.255.243.36]) with mapi id 14.16.0324.000; Mon, 24 Jun 2013 14:29:10 +0000 From: Ronald Bonica To: Tore Anderson Subject: RE: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHObc3OGhJfZWsTvkmEF1gJL7lsrZk+wGpwgAK52QCAA3hUYA== Date: Mon, 24 Jun 2013 14:29:10 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2509F86DC1@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> In-Reply-To: <51C56E60.5040009@fud.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%FUD.NO$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 14:31:15 -0000 Tore, Thanks for these very actionable comments. I will address them in the next = draft version. Ron > -----Original Message----- > From: Tore Anderson [mailto:tore@fud.no] > Sent: Saturday, June 22, 2013 5:29 AM > To: Ronald Bonica > Cc: ipv6@ietf.org 6man-wg > Subject: Re: FW: New Version Notification for draft-bonica-6man-frag- > deprecate-00.txt >=20 > * Ronald Bonica >=20 > > [draft-bonica-6man-frag-deprecate] >=20 > Being an operator I would definitively welcome getting rid of the > complexities dealing with IPv6 fragments bring. That said, the draft > needs additional discussion on this could be accomplished without > breaking assumptions made by other protocols, though. >=20 > On my network, I have two legitimate consumers of IPv6 fragments: >=20 > 1) OSPFv3. RFC 2740 A.1 says its protocol packets, and depends on IPv6 fragmentation when > transmitting packets larger than the link MTU>. It does goes on to say > split into several separate protocol packets, without loss of > functionality. This is recommended; IPv6 fragmentation should be > avoided whenever possible>. > In my experience however, the implementation vendors appears to have > skipped over that last recommendation. >=20 > 2) SIIT (RFC 6145). There are several corner cases where a SIIT > translator, or an IPv6 node communicating with an IPv4 node through > such a translator, have to deal with IPv6 fragments. In particular: >=20 > - When a SIIT translator receives an IPv4 packet with DF=3D0 that would > result in an IPv6 packet that would exceed the IPv6 link MTU, it will > split the original packet into IPv6 fragments. >=20 > - When a SIIT translator receives an IPv4 fragment, it will translate > this into one or more IPv6 fragments. >=20 > - When the SIIT translator receives an IPv4 packet with DF=3D0 it always include an IPv6 Fragment Header to indicate that the sender > allows fragmentation>. (I wouldn't miss this feature going away though, > as I disable it anyway.) >=20 > - When an IPv6 node receives an ICMPv6 Packet Too Big message > indicating a Path MTU less than 1280, it should either 1) simply heed > the indicated Path MTU, or 2) limit the size of subsequent transmitted > packets to 1280 and include a Fragmentation header (w/MF=3D0, i.e., an > "atomic" fragment) in them. See RFC 2460 section 5. I know that Linux > takes this second approach, at least. >=20 > I cannot support your draft until it discusses or provides solutions > for the above considerations. >=20 > Finally I'll note that in all of the above cases, the use of IPv6 > fragments is limited to within a single administrative domain (i.e., my > network), so the rationale that IPv6 fragmentation does not work over > the Internet does not really apply. >=20 > Best regards, > Tore Anderson >=20 From rbonica@juniper.net Mon Jun 24 07:48:46 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2929B21E810E for ; Mon, 24 Jun 2013 07:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.081 X-Spam-Level: X-Spam-Status: No, score=-102.081 tagged_above=-999 required=5 tests=[AWL=1.345, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynWDOUhqDpQI for ; Mon, 24 Jun 2013 07:48:39 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 49ABB21E80FD for ; Mon, 24 Jun 2013 07:48:39 -0700 (PDT) Received: from mail125-co9-R.bigfish.com (10.236.132.225) by CO9EHSOBE019.bigfish.com (10.236.130.82) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Jun 2013 14:48:38 +0000 Received: from mail125-co9 (localhost [127.0.0.1]) by mail125-co9-R.bigfish.com (Postfix) with ESMTP id 777602E0831 for ; Mon, 24 Jun 2013 14:48:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: PS-1(zz1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h683h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail125-co9: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=rbonica@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail125-co9 (localhost.localdomain [127.0.0.1]) by mail125-co9 (MessageSwitch) id 1372085317164391_26232; Mon, 24 Jun 2013 14:48:37 +0000 (UTC) Received: from CO9EHSMHS007.bigfish.com (unknown [10.236.132.239]) by mail125-co9.bigfish.com (Postfix) with ESMTP id 21D034000BC for ; Mon, 24 Jun 2013 14:48:37 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.53) by CO9EHSMHS007.bigfish.com (10.236.130.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 24 Jun 2013 14:48:33 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 24 Jun 2013 07:48:31 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 24 Jun 2013 07:48:30 -0700 Received: from DB8EHSOBE017.bigfish.com (213.199.154.185) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 24 Jun 2013 08:00:25 -0700 Received: from mail154-db8-R.bigfish.com (10.174.8.225) by DB8EHSOBE017.bigfish.com (10.174.4.80) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Jun 2013 14:48:27 +0000 Received: from mail154-db8 (localhost [127.0.0.1]) by mail154-db8-R.bigfish.com (Postfix) with ESMTP id BF2A0800E9 for ; Mon, 24 Jun 2013 14:48:27 +0000 (UTC) Received: from mail154-db8 (localhost.localdomain [127.0.0.1]) by mail154-db8 (MessageSwitch) id 1372085306152964_17527; Mon, 24 Jun 2013 14:48:26 +0000 (UTC) Received: from DB8EHSMHS020.bigfish.com (unknown [10.174.8.248]) by mail154-db8.bigfish.com (Postfix) with ESMTP id 155834E004A; Mon, 24 Jun 2013 14:48:26 +0000 (UTC) Received: from BY2PRD0512HT003.namprd05.prod.outlook.com (157.56.238.5) by DB8EHSMHS020.bigfish.com (10.174.4.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 24 Jun 2013 14:48:23 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.17]) by BY2PRD0512HT003.namprd05.prod.outlook.com ([10.255.243.36]) with mapi id 14.16.0324.000; Mon, 24 Jun 2013 14:48:14 +0000 From: Ronald Bonica To: Sheng Jiang , "Fred Baker (fred)" Subject: RE: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHObrhqoPSgCrUHwECtndDXiOVBOJlEG04AgADagvA= Date: Mon, 24 Jun 2013 14:48:14 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2509F86EB0@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> <8C48B86A895913448548E6D15DA7553B921F57@xmb-rcd-x09.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923ACA4B26@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923ACA4B26@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 14:48:46 -0000 PiANCj4gKzEuIEZvciBtZSwgdGhpcyBkcmFmdCBsb29rcyBkYW5nZXJvdXMgYnkgcHJvcG9zaW5n IHRvIGRlcHJlY2F0ZQ0KPiBmcmFnbWVudGF0aW9uIHdpdGggb25seSBvbmUtc2lkZSBvYnNlcnZh dGlvbi4gVGhpcyBkcmFmdCBkb2VzIG5vdCBnaXZlDQo+IGVub3VnaCBhbmFseXNpcyBvbiB0aGVz ZSBleGlzdGluZyBmcmFnbWVudGF0aW9uIHVzZSBjYXNlcywgcGFydGljdWxhcmx5DQo+IHRoZXNl IHVzZSBjYXNlcyB0aGUgZnJhZ21lbnRzIHdpdGhpbiBhIHNpbmdsZSBkb21haW4uDQo+IA0KPiBP biBvdGhlciBzaWRlICwgb25seSBkaXNhbGxvd2luZyBmcmFnbWVudGF0aW9uIHRvIGJlIHVzZWQg YW1vbmcgZG9tYWlucw0KPiBtYXkgaGVscGZ1bCB0byByZWR1Y2UgdGhlIG9wZXJhdGlvbmFsIGNv bXBsZXguDQo+IA0KDQpTaGVuZywNCg0KSSBoZWFyIHlvdS4gVGhlIG5leHQgdmVyc2lvbiBvZiB0 aGUgZHJhZnQgd2lsbCBpbmNsdWRlIGEgZGlzY3Vzc2lvbiBvZiBTSUlULCBPU1BGdjMgYW5kIHR1 bm5lbGluZyBpbiBnZW5lcmFsLg0KDQooVGhpcyBzaG91bGQgYWRkcmVzcyB5b3VyIGNvbW1lbnRz LCBhcyB3ZWxsIGFzIHRob3NlIG9mIFRvcmUsIEZyZWQgYW5kIEZyZWQuKQ0KDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBSb24NCg0K From rbonica@juniper.net Mon Jun 24 09:38:34 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697BE21E8126 for ; Mon, 24 Jun 2013 09:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.269 X-Spam-Level: X-Spam-Status: No, score=-100.269 tagged_above=-999 required=5 tests=[AWL=-0.803, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgv4bWmzyfkT for ; Mon, 24 Jun 2013 09:38:27 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0189.outbound.messaging.microsoft.com [213.199.154.189]) by ietfa.amsl.com (Postfix) with ESMTP id 1A95921E811E for ; Mon, 24 Jun 2013 09:38:27 -0700 (PDT) Received: from mail70-db8-R.bigfish.com (10.174.8.232) by DB8EHSOBE034.bigfish.com (10.174.4.97) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Jun 2013 16:38:26 +0000 Received: from mail70-db8 (localhost [127.0.0.1]) by mail70-db8-R.bigfish.com (Postfix) with ESMTP id 1C9075800FD for ; Mon, 24 Jun 2013 16:38:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzc85fhzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1d7338h17326ah18c673h1c8fb4h8275bh8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail70-db8: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=rbonica@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail70-db8 (localhost.localdomain [127.0.0.1]) by mail70-db8 (MessageSwitch) id 1372091903842338_18513; Mon, 24 Jun 2013 16:38:23 +0000 (UTC) Received: from DB8EHSMHS006.bigfish.com (unknown [10.174.8.225]) by mail70-db8.bigfish.com (Postfix) with ESMTP id C9E9E300031 for ; Mon, 24 Jun 2013 16:38:23 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.52) by DB8EHSMHS006.bigfish.com (10.174.4.16) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 24 Jun 2013 16:38:18 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 24 Jun 2013 09:38:11 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 24 Jun 2013 09:38:10 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.184) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 24 Jun 2013 09:41:29 -0700 Received: from mail116-co1-R.bigfish.com (10.243.78.232) by CO1EHSOBE040.bigfish.com (10.243.66.105) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Jun 2013 16:38:10 +0000 Received: from mail116-co1 (localhost [127.0.0.1]) by mail116-co1-R.bigfish.com (Postfix) with ESMTP id 0DCF516015A for ; Mon, 24 Jun 2013 16:38:10 +0000 (UTC) Received: from mail116-co1 (localhost.localdomain [127.0.0.1]) by mail116-co1 (MessageSwitch) id 1372091888194665_352; Mon, 24 Jun 2013 16:38:08 +0000 (UTC) Received: from CO1EHSMHS022.bigfish.com (unknown [10.243.78.240]) by mail116-co1.bigfish.com (Postfix) with ESMTP id 2C830540077; Mon, 24 Jun 2013 16:38:08 +0000 (UTC) Received: from BY2PRD0512HT002.namprd05.prod.outlook.com (157.56.238.5) by CO1EHSMHS022.bigfish.com (10.243.66.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 24 Jun 2013 16:38:08 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.17]) by BY2PRD0512HT002.namprd05.prod.outlook.com ([10.255.243.35]) with mapi id 14.16.0324.000; Mon, 24 Jun 2013 16:38:07 +0000 From: Ronald Bonica To: George Michaelson , "ipv6@ietf.org 6man-wg" Subject: RE: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHOcGcZAVktROcGIk+BMbBlhw+60plEC30AgAEFrkA= Date: Mon, 24 Jun 2013 16:38:06 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_2CF4CB03E2AA464BA0982EC92A02CE2509F870FCBY2PRD0512MB653_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ALGEBRAS.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 16:38:34 -0000 --_000_2CF4CB03E2AA464BA0982EC92A02CE2509F870FCBY2PRD0512MB653_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like to understand the basis of these assertions. I believe what I am s= eeing, on the edge, suggests there is in fact V6 fragmentation in both TCP = and UDP. Hi George, It would be helpful if you could describe: - Where your observations are being made - What percentage of traffic is fragmented - What kinds of packets are being fragmented Ron --_000_2CF4CB03E2AA464BA0982EC92A02CE2509F870FCBY2PRD0512MB653_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

     

    I'd like to understand the basis of these assertions= . I believe what I am seeing, on the edge, suggests there is in fact V6 fra= gmentation in both TCP and UDP.

     

     

    Hi George,<= /span>

     <= /p>

    It would be helpful if yo= u could describe:

     <= /p>

    - =          Where your observ= ations are being made

    - =          What percentage o= f traffic is fragmented

    - =          What kinds of pac= kets are being fragmented

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      Ron

     <= /p>

    --_000_2CF4CB03E2AA464BA0982EC92A02CE2509F870FCBY2PRD0512MB653_-- From fred@cisco.com Mon Jun 24 09:50:23 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA30321E813E for ; Mon, 24 Jun 2013 09:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.494 X-Spam-Level: X-Spam-Status: No, score=-110.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aE8QD+7UWsdv for ; Mon, 24 Jun 2013 09:50:17 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEFD21E8139 for ; Mon, 24 Jun 2013 09:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1273; q=dns/txt; s=iport; t=1372092613; x=1373302213; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=U20ZqLFddZjCX1jLIIOOmmktr51bBZa67aVCBiWTAQ4=; b=mjVXFLGfGFDzZQMn6BqMXypG/juNZtjFeU5q/jhnyUY4jZvnZc2+ArFs i0CZ69OI2+qo55ScL3G3vp/zvCzfLnhOiuAO65wo0mkXWtDGoZXxOZ/O6 CLImxUdFQh9tTO802/oYcA3F867Dg7cdCnrDEWwuvE/1CfInyiR9QMb73 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAHh4yFGtJV2Z/2dsb2JhbABbgwl6vziBBhZ0giMBAQEEbQoCEAIBCBgKJDIlAgQOBQiIBrpnjx4xB4MCYQOIaaAegxCCKA X-IronPort-AV: E=Sophos;i="4.87,929,1363132800"; d="scan'208";a="223764158" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 24 Jun 2013 16:50:05 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5OGo5j1020570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Jun 2013 16:50:05 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Mon, 24 Jun 2013 11:50:05 -0500 From: "Fred Baker (fred)" To: Tore Anderson Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHOcK7XSn/cDsuJu0Ci4NKOF+S5OplFaDMA Date: Mon, 24 Jun 2013 16:50:04 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B924440@xmb-rcd-x09.cisco.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> <51C7F926.6030902@fud.no> In-Reply-To: <51C7F926.6030902@fud.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.125] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 16:50:23 -0000 On Jun 24, 2013, at 12:45 AM, Tore Anderson wrote: > * Fred Baker (fred) >=20 >> On Jun 22, 2013, at 2:29 AM, Tore Anderson wrote: >>> - When a SIIT translator receives an IPv4 packet with DF=3D0 that >>> would result in an IPv6 packet that would exceed the IPv6 link MTU, >>> it will split the original packet into IPv6 fragments. >>=20 >> It *could* fragment the IPv4 packet and send it in two unfragmented >> IPv6 packets. >=20 > Wouldn't doing IPv4 fragmentation before translation to IPv6 be > logically identical to this other case I mentioned? Ah. You're correct. I was thinking about tunnels. >>> - When a SIIT translator receives an IPv4 fragment, it will translate >>> this into one or more IPv6 fragments. >=20 > I can't see how simply omitting the Fragmentation header in the IPv6 > output could work here, as the node receiving those two unfragmented > IPv6 packets would see the first one containing a truncated L4 payload, > while the second one would be just garbage as it doesn't include a L4 > header. >=20 > Tore ----------------------------------- "We are learning to do a great many clever things...The next great task will be to learn not to do them." - G. K. Chesterton (1874-1936) From otroan@employees.org Mon Jun 24 10:37:48 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939DA21E8138 for ; Mon, 24 Jun 2013 10:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eX2QFAiSZP9y for ; Mon, 24 Jun 2013 10:37:48 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 244E421E8118 for ; Mon, 24 Jun 2013 10:37:48 -0700 (PDT) Received: from dhcp-10-61-102-29.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 640145F4A; Mon, 24 Jun 2013 10:37:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt From: Ole Troan In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923ACA4B26@nkgeml512-mbx.china.huawei.com> Date: Mon, 24 Jun 2013 13:37:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <34E0F96D-5CCB-4275-AF64-E451B00369E0@employees.org> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> <8C48B86A895913448548E6D15DA7553B921F57@xmb-rcd-x09.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923ACA4B26@nkgeml512-mbx.china.huawei.com> To: Sheng Jiang X-Mailer: Apple Mail (2.1508) Cc: "ipv6@ietf.org 6man-wg" , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 17:37:48 -0000 >> I suppose I'm the contrarian >=20 > +1. For me, this draft looks dangerous by proposing to deprecate = fragmentation with only one-side observation. This draft does not give = enough analysis on these existing fragmentation use cases, particularly = these use cases the fragments within a single domain. >=20 > On other side , only disallowing fragmentation to be used among = domains may helpful to reduce the operational complex. this draft should help us tease out answers to the question: "if we wanted to deprecate IPv6 fragmentation, could we?" then when we know the collateral damage, it will be easier to answer the = other question: "should we deprecate IP layer fragmentation or not". cheers, Ole= From Fred.L.Templin@boeing.com Mon Jun 24 10:50:46 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFF421E8106 for ; Mon, 24 Jun 2013 10:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bq4+vLFTsKlI for ; Mon, 24 Jun 2013 10:50:40 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 375E811E816F for ; Mon, 24 Jun 2013 10:50:39 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r5OHoc16005202 for ; Mon, 24 Jun 2013 12:50:39 -0500 Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r5OHobmX005183 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 24 Jun 2013 12:50:38 -0500 Received: from XCH-BLV-503.nw.nos.boeing.com (130.247.25.192) by XCH-NWHT-08.nw.nos.boeing.com (130.247.25.112) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 24 Jun 2013 10:50:37 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-BLV-503.nw.nos.boeing.com ([169.254.3.132]) with mapi id 14.02.0328.011; Mon, 24 Jun 2013 10:50:37 -0700 From: "Templin, Fred L" To: "Fred Baker (fred)" , Tore Anderson Subject: RE: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHOcGcOI1L7sow7kkSTr5SDOLoWMJlFJNrg Date: Mon, 24 Jun 2013 17:50:36 +0000 Message-ID: <2134F8430051B64F815C691A62D983180A93A6@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 17:50:46 -0000 Hi Fred, > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Fred Baker (fred) > Sent: Sunday, June 23, 2013 4:12 PM > To: Tore Anderson > Cc: ipv6@ietf.org 6man-wg > Subject: Re: New Version Notification for draft-bonica-6man-frag- > deprecate-00.txt >=20 >=20 > On Jun 22, 2013, at 2:29 AM, Tore Anderson wrote: > > - When a SIIT translator receives an IPv4 packet with DF=3D0 that would > > result in an IPv6 packet that would exceed the IPv6 link MTU, it will > > split the original packet into IPv6 fragments. >=20 > It *could* fragment the IPv4 packet and send it in two unfragmented > IPv6 packets. >=20 > > I cannot support your draft until it discusses or provides solutions > for > > the above considerations. >=20 > I'm in a similar case with respect to protocols above IPv6 (OSPF and > NFS/UDP come quickly to mind) that depend on fragmentation to deal with > the issue. I think the Robustness Principle tells us that such > applications SHOULD figure out how to live with PMTU, but it also tells > us that we can't deprecate fragmentation unless all known instances > that depend on it have defined practical work-arounds. I suspect that > this would imply the re-creation of the fragmentation feature in an > intermediate protocol, That is essentially what SEAL does - it provides an intermediate-level segmentation and reassembly capability that avoids the pitfalls of IP fragmentation. > which seems like a lot of work with little real gain. It's not that bad, and IMHO worth it. Thanks - Fred fred.l.templin@boeing.com > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From marc.lampo.ietf@gmail.com Mon Jun 24 12:19:50 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F5B11E8164 for ; Mon, 24 Jun 2013 12:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faF-0a5-6wfl for ; Mon, 24 Jun 2013 12:19:49 -0700 (PDT) Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id B1F8221E8149 for ; Mon, 24 Jun 2013 12:19:46 -0700 (PDT) Received: by mail-vb0-f48.google.com with SMTP id w15so8453697vbf.21 for ; Mon, 24 Jun 2013 12:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zLm5vnauJqxFAOrXSoh6+CW8IziLnH004G/dijmUnhM=; b=tLTRMuURfBqLKj+2ETUEdn0J1voON79nprwFI/SGQyIaGj6+s7gmlJ7/IB6jKA7iHH cufe2Srzl5BP5wkC8E1TPbVCCkDNZNd39OokuMIqHbWDj/iCVmgAOodh7byTCj0zx9d9 2j0MsIOUFieoxnrbcdEGtYmy+N9Djef6H1Lwo8Sog2Kf4BChDp1CLQ39DM+F0LEdNbpU G0JBXOejezjE97VUXiqAAerC/vHMMUkRSpWGTr1TOBJK5UKT9K60F4/A7AW5UpovUKac lhRXoJOBhCFHR7pdQodhtkZ1UL+sW5Hy65qweQDrDSCjluyAu4doj0n5e0IHuxJaQUAx qfQw== MIME-Version: 1.0 X-Received: by 10.52.121.42 with SMTP id lh10mr10375760vdb.39.1372101586055; Mon, 24 Jun 2013 12:19:46 -0700 (PDT) Received: by 10.59.2.100 with HTTP; Mon, 24 Jun 2013 12:19:45 -0700 (PDT) In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> Date: Mon, 24 Jun 2013 21:19:45 +0200 Message-ID: Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt From: Marc Lampo To: Ronald Bonica Content-Type: multipart/alternative; boundary=089e013a2178a1f8f704dfeb4b2b Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 19:19:50 -0000 --089e013a2178a1f8f704dfeb4b2b Content-Type: text/plain; charset=ISO-8859-1 -1 Not because I'm a fan of fragmentation, but I think a layer 3 (IP) protocol that does not support fragmentation should really be a *new* IP version. In my opinion, the changes are too dramatic : if layer 3, not supporting fragmentation, is asked to sent a message, too big for one packet, it should inform layer 4 with an error message; while a layer 3 that supports fragmentation, can fragment and send in multiple packets (and return succes to layer 4). I can imagine case exist - without searching for explicit examples, some already given or hinted at by others in this discussion - where two partners in a conversation cannot communicate (perhaps only simplex ?) because one is implemented on a host that implements IPv6 with fragmentation and the other on a host that implements IPv6 without fragmentation. I do agree that fragmentation introduces attack vectors, but allowing that hosts do not implement it is, for me, not the correct approach. I'd prefer to insist that all headers, up till and including the layer 4, are in the first fragment and that implementations provide correct implementation of fragmentation. (both suggestions merely a repetition of other contributors in this discussion) In one of the replies you, Ron, write : > I don't know of a study. However, this is probably a safe assumption considering that: > > - many TCP implementation leverage PMTUD > - many enterprise block fragments > - many firewalls, by default, block IPv6 fragments I cannot comment on the first point. My experience with enterprises is that firewalls used normally cope well with fragments (in the sense that they can flow through) ((perhaps in the old days, before "stateful inspection", with basic ACL's; but even a cheap home router copes with (IPv4) fragmentation)) As for point 3 : when I look at firewall capabilities concerning IPv6 I actually look if it is possible to allow *only* the fragmentation extension header (as, in my opinion, it is the only extension header needed to let the business run) ((a statement that, by itself, might generate discussion - please, in a different thread)) So, as for the list of 3 points, I cannot support this "safe assumption". Kind regards, Marc On Thu, Jun 20, 2013 at 5:55 PM, Ronald Bonica wrote: > Folks, > > Please review this draft and provide comments. > > Ron > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Thursday, June 20, 2013 11:48 AM > > To: Ronald Bonica > > Subject: New Version Notification for draft-bonica-6man-frag-deprecate- > > 00.txt > > > > > > A new version of I-D, draft-bonica-6man-frag-deprecate-00.txt > > has been successfully submitted by Ron Bonica and posted to the IETF > > repository. > > > > Filename: draft-bonica-6man-frag-deprecate > > Revision: 00 > > Title: IPv6 Fragment Header Deprecated > > Creation date: 2013-06-20 > > Group: Individual Submission > > Number of pages: 7 > > URL: http://www.ietf.org/internet-drafts/draft-bonica-6man- > > frag-deprecate-00.txt > > Status: http://datatracker.ietf.org/doc/draft-bonica-6man- > > frag-deprecate > > Htmlized: http://tools.ietf.org/html/draft-bonica-6man-frag- > > deprecate-00 > > > > > > Abstract: > > This memo deprecates the IPv6 Fragment Header. It provides reasons > > for deprecation and updates RFC 2460. > > > > > > > > > > > > The IETF Secretariat > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --089e013a2178a1f8f704dfeb4b2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    -1

    Not because I'm a fan o= f fragmentation, but I think a layer 3 (IP) protocol that does not support = fragmentation should really be a *new* IP version.
    In my opinion, the ch= anges are too dramatic :
    if layer 3, not supporting fragmentation, is asked to sent a message,= too big for one packet,
    it should inform layer 4 with an err= or message;
    while a layer 3 that supports fragmentation, can = fragment and send in multiple packets (and return succes to layer 4).

    I can imagine case exist - without searching for explicit ex= amples, some already given or hinted at by others in this discussion -
    w= here two partners in a conversation cannot communicate (perhaps only simple= x ?) because one is implemented
    on a host that implements IPv6 with fragmentation and the other = on a host that implements IPv6 without fragmentation.


    I do agree that fragmentation introduces attack vectors,
    but allowing that hosts do not implement it is, for me, not the correct app= roach.
    I'd prefer to insist that all headers, up till and= including the layer 4, are in the first fragment
    =A0and that= implementations provide correct implementation of fragmentation.
    (both suggestions merely a repetition of other contributors in t= his discussion)


    In one of the replies you, Ron, write :
    > I don't know of a study. However, this is probably a safe assumpti= on considering that:
    >
    > - many TCP implementation leverage PMTUD
    > - many enterprise block fragments
    > - many firewalls, by default, block IPv6 fragments

    I cannot comment on the first point.
    My experience with enterprises is that firewalls used normally cope well = with fragments
    =A0(in the sense that they can flow through)
    =A0((perhaps in the old days, before "stateful inspection&q= uot;, with basic ACL's;
    =A0=A0 but even a cheap home rout= er copes with (IPv4) fragmentation))
    As for point 3 : when I = look at firewall capabilities concerning IPv6
    =A0I actually look if it is possible to allow *only* the fragmen= tation extension header
    =A0(as, in my opinion, it is the only= extension header needed to let the business run)
    =A0((a stat= ement that, by itself, might generate discussion - please, in a different t= hread))
    So, as for the list of 3 points, I cannot support this "saf= e assumption".


    Kind regards,

    Marc


    On Th= u, Jun 20, 2013 at 5:55 PM, Ronald Bonica <rbonica@juniper.net> wrote:
    Folks,

    Please review this draft and provide comments.

    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ron


    > -----Original Message-----
    > From: internet-drafts@ietf= .org [mailto:internet-draft= s@ietf.org]
    > Sent: Thursday, June 20, 2013 11:48 AM
    > To: Ronald Bonica
    > Subject: New Version Notification for draft-bonica-6man-frag-deprecate= -
    > 00.txt
    >
    >
    > A new version of I-D, draft-bonica-6man-frag-deprecate-00.txt
    > has been successfully submitted by Ron Bonica and posted to the IETF > repository.
    >
    > Filename: =A0 =A0 =A0draft-bonica-6man-frag-deprecate
    > Revision: =A0 =A0 =A000
    > Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IPv6 Fragment Header Deprecated=
    > Creation date: =A0 =A0 =A0 =A0 2013-06-20
    > Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission
    > Number of pages: 7
    > URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-dr= afts/draft-bonica-6man-
    > frag-deprecate-00.txt
    > Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft= -bonica-6man-
    > frag-deprecate
    > Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-bonica= -6man-frag-
    > deprecate-00
    >
    >
    > Abstract:
    > =A0 =A0This memo deprecates the IPv6 Fragment Header. =A0It provides r= easons
    > =A0 =A0for deprecation and updates RFC 2460.
    >
    >
    >
    >
    >
    > The IETF Secretariat
    >
    >

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------

    --089e013a2178a1f8f704dfeb4b2b-- From markzzzsmith@yahoo.com.au Mon Jun 24 13:40:06 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B756521E80EC for ; Mon, 24 Jun 2013 13:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gzm9N3s+AuKl for ; Mon, 24 Jun 2013 13:40:01 -0700 (PDT) Received: from nm48-vm10.bullet.mail.bf1.yahoo.com (nm48-vm10.bullet.mail.bf1.yahoo.com [216.109.114.235]) by ietfa.amsl.com (Postfix) with ESMTP id 5671821E810B for ; Mon, 24 Jun 2013 13:40:00 -0700 (PDT) Received: from [98.139.215.143] by nm48.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jun 2013 20:39:59 -0000 Received: from [98.139.212.206] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jun 2013 20:39:59 -0000 Received: from [127.0.0.1] by omp1015.mail.bf1.yahoo.com with NNFMP; 24 Jun 2013 20:39:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 824237.15599.bm@omp1015.mail.bf1.yahoo.com Received: (qmail 85736 invoked by uid 60001); 24 Jun 2013 20:39:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1372106399; bh=koNpx3nWOAqLFNr8x66q/4SVjUPlj4bavAhxh8FZU8Q=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HctsObe/kOZqwcGurcHb/hdRzZ7lY9RFnAo7EOyWbgEwqf4y3sUwkkIPXxsSMK6j7TObYjAiuL0FPEDqzY+5dNtVD3QDsfOXfIPTM6iwIlwvOL7sWTYawjcRu57OBYE3XMb57+kP4Y257OwNmbmnWR34XeiykJH1LkSgDirpI40= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KJGI4H6fw2ZUN1cVQ62aKm55v/cQuylE3Gya9qCeZ389NSCs6rcNkZySOhQC6dI8xZl6/fx0A9DlZgneriVjkeUaxUxnQP3nlM+JYM1uDcYRj94qGMTghtIW1vEWB9LAZ/5ZIqzUKwAHoUIugG3WPZw1cDccARTp57CqiT6S4AQ=; X-YMail-OSG: rAkpmtoVM1kiVJgHzEWYrWU3cFnC_oi8yehQ6YdlyEicCpX YUIPbyGOrfleGU7zjA.zik4cbeIs6vV6TJ5fxKxbYcfV5gLr1z38iNRdYlSM SgfsZ9Pa5.fWZS7Ga1F1s1xZdeZWR6VWhuI8_IkTJiLz.Vw5Uy63JX02qIaf MC3dMMzDzGi0c4vEVyxt0SItbxaXO6BL0y8ktmjHeL5qqWZZMrOlcrkR4K8l WnuEdxz.jmy.3MNbxR6Vn6CMjXBvDHbvUZ0SmCvoNiBu96IGfDpv51FdKVij 4tJgVtgfJNlovXq1wTA_DKi0eeCEbc2TFeYQ61ibb1zb7NYA.ABu4yhTHh8b 1cH6A_QEZAB6ggPyzMLXFr4UktFa7JD7UidSLD7oeR6YkykX5h10OwrJb2Er XikSS6Wz4zCWZkhAb9yc5GRGB_E2Op.h36Hmew90iwBpckazRgqdPUyfGCtV AKQVSxwgy.2vr5QBnL1Rvj1KjSjgZoNbNCDtnWy9ni.TG60DgRCg5f4niO9j 4YCPM7LsGNzzoP7jFthIGkcYQ2JHoVhFc4XvixLRFcF.wsG5Kvw9OHdzyVkD D_eB6mSSP Received: from [150.101.221.237] by web142502.mail.bf1.yahoo.com via HTTP; Mon, 24 Jun 2013 13:39:59 PDT X-Rocket-MIMEInfo: 002.001, ClNvIEknbSBnZW5lcmFsbHkgb2sgd2l0aCBpdCwgbW9yZSBiZWNhdXNlIEkgdGhpbmsgYSByZWFzb25hYmxlIHByb3BvcnRpb24gb2YgYWRtaW5pc3RlcnMgb2YgdGhlIG5ldHdvcmsgYXJlIGVmZmVjdGl2ZWx5IGRlcHJlY2F0aW5nIGZlYXR1cmVzIHRoYXQgcmVseSBvbiB0aGUgbmV0d29yayBiZWhhdmlvdXIgYnkgcHJvaGliaXRpbmcgdGhlbS4KCgpJJ3ZlIG5vdGljZWQgdGhhdCBhIG51bWJlciBvZiBtZWNoYW5pc21zIGhhdmUgYmVlbiBkZXZlbG9wZWQgZm9ywqBob3N0cyB0byBlaXRoZXIgbW9yZSBhY3QBMAEBAQE- X-Mailer: YahooMailWebService/0.8.148.554 References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> Message-ID: <1372106399.82403.YahooMailNeo@web142502.mail.bf1.yahoo.com> Date: Mon, 24 Jun 2013 13:39:59 -0700 (PDT) From: Mark Smith Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt To: Marc Lampo , Ronald Bonica In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 20:40:06 -0000 =0ASo I'm generally ok with it, more because I think a reasonable proportio= n of administers of the network are effectively deprecating features that r= ely on the network behaviour by prohibiting them.=0A=0A=0AI've noticed that= a number of mechanisms have been developed for=A0hosts to either more acti= vely measure the capabilities of the network between the intended communica= tions end points and then take action to overcome them (the variety of NAT = traversal methods, ICMP-less PMTUD), or at least assume a limitation and ta= ke actions to overcome or avoid them (happy eyeballs, multipath TCP).=0A=0A= I think the=A0rapid adoption of mobile multihomed hosts (i.e., smartphones = and tablets) means that we will see hosts be smarter about these network li= mitations, because their connectivity to the network varies much more than = it used to - they may have one or more connections to the network, and the = quality and capability of those connections will vary. It seems as the netw= ork is ending up with more varying levels of "dumbness" (intentional or not= ), the hosts will get and are getting smarter.=0A=0ARegards,=0AMark.=0A=0A>= ________________________________=0A> From: Marc Lampo =0A>To: Ronald Bonica =0A>Cc: "ipv6@ietf.org 6m= an-wg" =0A>Sent: Tuesday, 25 June 2013 5:19 AM=0A>Subject: = Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.tx= t=0A> =0A>=0A>=0A>-1=0A>=0A>Not because I'm a fan of fragmentation, but I t= hink a layer 3 (IP) protocol that does not support fragmentation should rea= lly be a *new* IP version.=0A>In my opinion, the changes are too dramatic := =0A>if layer 3, not supporting fragmentation, is asked to sent a message, t= oo big for one packet,=0A>=0A>it should inform layer 4 with an error messag= e;=0A>=0A>while a layer 3 that supports fragmentation, can fragment and sen= d in multiple packets (and return succes to layer 4).=0A>=0A>=0A>I can imag= ine case exist - without searching for explicit examples, some already give= n or hinted at by others in this discussion -=0A>where two partners in a co= nversation cannot communicate (perhaps only simplex ?) because one is imple= mented=0A>=0A>on a host that implements IPv6 with fragmentation and the oth= er on a host that implements IPv6 without fragmentation.=0A>=0A>=0A>=0A>I d= o agree that fragmentation introduces attack vectors,=0A>=0A>but allowing t= hat hosts do not implement it is, for me, not the correct approach.=0A>=0A>= I'd prefer to insist that all headers, up till and including the layer 4, a= re in the first fragment=0A>=0A>=A0and that implementations provide correct= implementation of fragmentation.=0A>=0A>(both suggestions merely a repetit= ion of other contributors in this discussion)=0A>=0A>=0A>In one of the repl= ies you, Ron, write :=0A>> I don't know of a study. However, this is probab= ly a safe assumption considering that:=0A>>=0A>> - many TCP implementation = leverage PMTUD=0A>> - many enterprise block fragments=0A>> - many firewalls= , by default, block IPv6 fragments=0A>=0A>=0A>=0A>I cannot comment on the f= irst point.=0A>=0A>My experience with enterprises is that firewalls used no= rmally cope well with fragments=0A>=0A>=A0(in the sense that they can flow = through)=0A>=0A>=A0((perhaps in the old days, before "stateful inspection",= with basic ACL's;=0A>=0A>=A0=A0 but even a cheap home router copes with (I= Pv4) fragmentation))=0A>=0A>As for point 3 : when I look at firewall capabi= lities concerning IPv6=0A>=0A>=A0I actually look if it is possible to allow= *only* the fragmentation extension header=0A>=0A>=A0(as, in my opinion, it= is the only extension header needed to let the business run)=0A>=0A>=A0((a= statement that, by itself, might generate discussion - please, in a differ= ent thread))=0A>=0A>So, as for the list of 3 points, I cannot support this = "safe assumption".=0A>=0A>=0A>=0A>Kind regards,=0A>=0A>Marc=0A>=0A>=0A>=0A>= =0A>On Thu, Jun 20, 2013 at 5:55 PM, Ronald Bonica wr= ote:=0A>=0A>Folks,=0A>>=0A>>Please review this draft and provide comments.= =0A>>=0A>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ron=0A>>=0A>>=0A>>> -= ----Original Message-----=0A>>> From: internet-drafts@ietf.org [mailto:inte= rnet-drafts@ietf.org]=0A>>> Sent: Thursday, June 20, 2013 11:48 AM=0A>>> To= : Ronald Bonica=0A>>> Subject: New Version Notification for draft-bonica-6m= an-frag-deprecate-=0A>>> 00.txt=0A>>>=0A>>>=0A>>> A new version of I-D, dra= ft-bonica-6man-frag-deprecate-00.txt=0A>>> has been successfully submitted = by Ron Bonica and posted to the IETF=0A>>> repository.=0A>>>=0A>>> Filename= : =A0 =A0 =A0draft-bonica-6man-frag-deprecate=0A>>> Revision: =A0 =A0 =A000= =0A>>> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IPv6 Fragment Header Deprecat= ed=0A>>> Creation date: =A0 =A0 =A0 =A0 2013-06-20=0A>>> Group: =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 Individual Submission=0A>>> Number of pages: 7=0A>>> U= RL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-bonic= a-6man-=0A>>> frag-deprecate-00.txt=0A>>> Status: =A0 =A0 =A0 =A0 =A0http:/= /datatracker.ietf.org/doc/draft-bonica-6man-=0A>>> frag-deprecate=0A>>> Htm= lized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-bonica-6man-frag-=0A= >>> deprecate-00=0A>>>=0A>>>=0A>>> Abstract:=0A>>> =A0 =A0This memo depreca= tes the IPv6 Fragment Header. =A0It provides reasons=0A>>> =A0 =A0for depre= cation and updates RFC 2460.=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>=0A>>> The IETF S= ecretariat=0A>>>=0A>>>=0A>>=0A>>-------------------------------------------= -------------------------=0A>>IETF IPv6 working group mailing list=0A>>ipv6= @ietf.org=0A>>Administrative Requests: https://www.ietf.org/mailman/listinf= o/ipv6=0A>>----------------------------------------------------------------= ----=0A>>=0A>=0A>----------------------------------------------------------= ----------=0A>IETF IPv6 working group mailing list=0A>ipv6@ietf.org=0A>Admi= nistrative Requests: https://www.ietf.org/mailman/listinfo/ipv6=0A>--------= ------------------------------------------------------------=0A>=0A>=0A> From hagen@jauu.net Mon Jun 24 13:40:18 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E3A21E8129 for ; Mon, 24 Jun 2013 13:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kl1BrhCYQnT9 for ; Mon, 24 Jun 2013 13:40:18 -0700 (PDT) Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2001:4d88:1ffa:82:880:aa0:9009:64ae]) by ietfa.amsl.com (Postfix) with ESMTP id 65D1321E8108 for ; Mon, 24 Jun 2013 13:40:13 -0700 (PDT) Received: from pfeifer by Chamillionaire.breakpoint.cc with local (Exim 4.72) (envelope-from ) id 1UrDYZ-0007pQ-Dp; Mon, 24 Jun 2013 22:40:11 +0200 Date: Mon, 24 Jun 2013 22:40:09 +0200 From: Hagen Paul Pfeifer To: Ronald Bonica Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Message-ID: <20130624204008.GB3647@virgo.local> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "ipv6@ietf.org" , Arturo Servin X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 20:40:18 -0000 * Ronald Bonica | 2013-06-21 19:00:51 [+0000]: >I don't know of a study. However, this is probably a safe assumption considering that: > >- many TCP implementation leverage PMTUD >- many enterprise block fragments >- many firewalls, by default, block IPv6 fragments One of my clients using extensive fragmentation features, their application/transport layer is "build around" IPv6 fragmentation. Problem: all components are hard wired in silicon, there is no change/modification possible in the next decade. I'm a little bit sad about this incompatible protocol change/break. Fragmentation was an early design failure in IPv4 - for IPv6 fragmentation it is still supported and I see no way to obsolete fragmentation without incompatible protocol change. Especially "New IPv6 host implementations MAY support IPv6 fragmentation and reassembly, but are not required to do so." and "Network operators MAY filter IPv6 fragments.". - this break legacy application/stacks using fragmentation. Fragmentation is a nightmare for a middleboxes, no doubt and fragmentation was an design failure. But fixing it in a incompatible manner is even worse. There should never ever an protocol break. Hagen From hagen@jauu.net Mon Jun 24 13:52:30 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4691021F91A3 for ; Mon, 24 Jun 2013 13:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7awIWWy7izf for ; Mon, 24 Jun 2013 13:52:29 -0700 (PDT) Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2001:4d88:1ffa:82:880:aa0:9009:64ae]) by ietfa.amsl.com (Postfix) with ESMTP id B693121F9EA6 for ; Mon, 24 Jun 2013 13:52:29 -0700 (PDT) Received: from pfeifer by Chamillionaire.breakpoint.cc with local (Exim 4.72) (envelope-from ) id 1UrDkS-000850-O2; Mon, 24 Jun 2013 22:52:28 +0200 Date: Mon, 24 Jun 2013 22:52:27 +0200 From: Hagen Paul Pfeifer To: Ronald Bonica Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Message-ID: <20130624205226.GC3647@virgo.local> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130624204008.GB3647@virgo.local> X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Arturo Servin , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 20:52:30 -0000 * Hagen Paul Pfeifer | 2013-06-24 22:40:09 [+0200]: >I'm a little bit sad about this incompatible protocol change/break. >Fragmentation was an early design failure in IPv4 - for IPv6 fragmentation it >is still supported and I see no way to obsolete fragmentation without >incompatible protocol change. Especially "New IPv6 host implementations MAY >support IPv6 fragmentation and reassembly, but are not required to do so." and >"Network operators MAY filter IPv6 fragments.". - this break legacy >application/stacks using fragmentation. Sidenote: packets are generated within a sensor network domain sending fragmented packets via mcast to common PCs using general purpose OS (Windows, Linux, ...). "New IPv6 host implementations MAY support IPv6 fragmentation and reassembly" break things. "New IPv6 host implementations MAY support IPv6 fragmentation but MUST support reassembly" may superior. This will aging out fragmentation over a longer period, new hosts will not use it but existing - applications will not break. "Network operators MAY filter IPv6 fragments." is a policy thing and costumers have to deal with that already. So it is ok from my point of view. Hagen From rbonica@juniper.net Mon Jun 24 15:11:46 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624B921F85F7 for ; Mon, 24 Jun 2013 15:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.68 X-Spam-Level: X-Spam-Status: No, score=-100.68 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxsGTBm2YUaT for ; Mon, 24 Jun 2013 15:11:39 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 9502111E81A0 for ; Mon, 24 Jun 2013 15:11:39 -0700 (PDT) Received: from mail154-co1-R.bigfish.com (10.243.78.229) by CO1EHSOBE012.bigfish.com (10.243.66.75) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Jun 2013 22:11:25 +0000 Received: from mail154-co1 (localhost [127.0.0.1]) by mail154-co1-R.bigfish.com (Postfix) with ESMTP id 9B3D5C603B8 for ; Mon, 24 Jun 2013 22:11:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: PS-1(zz1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail154-co1: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=rbonica@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail154-co1 (localhost.localdomain [127.0.0.1]) by mail154-co1 (MessageSwitch) id 1372111883373307_14204; Mon, 24 Jun 2013 22:11:23 +0000 (UTC) Received: from CO1EHSMHS027.bigfish.com (unknown [10.243.78.244]) by mail154-co1.bigfish.com (Postfix) with ESMTP id 4F9B12004B for ; Mon, 24 Jun 2013 22:11:23 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.50) by CO1EHSMHS027.bigfish.com (10.243.66.37) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 24 Jun 2013 22:11:22 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 24 Jun 2013 15:11:21 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 24 Jun 2013 15:11:21 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.185) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 24 Jun 2013 15:14:39 -0700 Received: from mail13-ch1-R.bigfish.com (10.43.68.235) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Jun 2013 22:11:19 +0000 Received: from mail13-ch1 (localhost [127.0.0.1]) by mail13-ch1-R.bigfish.com (Postfix) with ESMTP id D7C3510026D for ; Mon, 24 Jun 2013 22:11:19 +0000 (UTC) Received: from mail13-ch1 (localhost.localdomain [127.0.0.1]) by mail13-ch1 (MessageSwitch) id 1372111878846390_1655; Mon, 24 Jun 2013 22:11:18 +0000 (UTC) Received: from CH1EHSMHS036.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.241]) by mail13-ch1.bigfish.com (Postfix) with ESMTP id C9BB01A004F; Mon, 24 Jun 2013 22:11:18 +0000 (UTC) Received: from BY2PRD0512HT003.namprd05.prod.outlook.com (157.56.238.5) by CH1EHSMHS036.bigfish.com (10.43.69.245) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 24 Jun 2013 22:11:18 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.17]) by BY2PRD0512HT003.namprd05.prod.outlook.com ([10.255.243.36]) with mapi id 14.16.0324.000; Mon, 24 Jun 2013 22:11:17 +0000 From: Ronald Bonica To: Hagen Paul Pfeifer Subject: RE: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHOcRsX7UHYoUo9i0CXdOQER31iGZlFV0KAgAAVfXA= Date: Mon, 24 Jun 2013 22:11:16 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> In-Reply-To: <20130624205226.GC3647@virgo.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%JAUU.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: Arturo Servin , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 22:11:46 -0000 >=20 > "New IPv6 host implementations MAY support IPv6 fragmentation and > reassembly" > break things. "New IPv6 host implementations MAY support IPv6 > fragmentation but MUST support reassembly" may superior. This will > aging out fragmentation over a longer period, new hosts will not use it > but existing - applications will not break. I could live with this. Would it satisfy other folks' objections? >=20 > "Network operators MAY filter IPv6 fragments." is a policy thing and > costumers have to deal with that already. So it is ok from my point of > view. Ack. It is a statement of fact, not an IETF imposed requirement. Ron >=20 > Hagen >=20 From jhw@apple.com Mon Jun 24 15:35:50 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6636821E8129 for ; Mon, 24 Jun 2013 15:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bk+CzOFih9Mu for ; Mon, 24 Jun 2013 15:35:43 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id E212521E811A for ; Mon, 24 Jun 2013 15:35:43 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MOX00D0O5ERMY61@mail-out.apple.com> for ipv6@ietf.org; Mon, 24 Jun 2013 15:35:42 -0700 (PDT) X-AuditID: 11807158-b7f486d0000079b6-2d-51c8c9be22c5 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id C7.8D.31158.EB9C8C15; Mon, 24 Jun 2013 15:35:42 -0700 (PDT) Received: from ba0301a-dhcp116.apple.com ([17.193.14.244]) by marigold.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MOX00KLH5FICD50@marigold.apple.com> for ipv6@ietf.org; Mon, 24 Jun 2013 15:35:42 -0700 (PDT) Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt From: james woodyatt In-reply-to: <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> Date: Mon, 24 Jun 2013 15:35:41 -0700 Message-id: <57D2AF30-1FC4-4B5E-8F48-4169384746B3@apple.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> To: "ipv6@ietf.org" X-Mailer: Apple Mail (2.1779) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUi2FDcorvv5IlAg+e7FC1enn3P5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujKcfNzEW/BSp2HjjL1MD4zv+LkZODgkBE4lju9axQNhiEhfu rWfrYuTiEBKYxCSx7PQVZghnAZNET99ksCpmAS2J9TuPM4HYvAJ6EjOnTWIEsYUFgiV2HJwC FmcTUJH4dvkumM0pkCxxesMJsF4WAVWJ9xMuMUPM0ZZ48u4CK8QcG4nDTTPZIZb9ZJJY1D8R bKiIgLLEjO5zbBDnyUqc6bnJMoGRfxaSO2YhuWMWkrkLGJlXMQoUpeYkVprqJRYU5KTqJefn bmIEB1lhxA7G/8usDjEKcDAq8fB+iDsRKMSaWFZcmXuIUYKDWUmEN1QEKMSbklhZlVqUH19U mpNafIhRmoNFSZxX0ut4oJBAemJJanZqakFqEUyWiYNTqoFxTWDGhF+Zx07tX6MYEKL+rWzd 5SlGLqen+Xnvu5NfIbhz+7/DIWnuf5zizk+8tScnrLUhvnb+6/RifqNfOmd+bC8vKWy92WRT F7viEtfcL2uElHx4rj7MiXq+08lwinn3os6n9/qOFSZPce7mkHiq8KnfP/9OcG5W69+Xp6wk mPcUH9op9F5FiaU4I9FQi7moOBEA8RImLS4CAAA= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 22:35:50 -0000 On Jun 24, 2013, at 15:11 , Ronald Bonica wrote: >> >> "Network operators MAY filter IPv6 fragments." > > Ack. It is a statement of fact, not an IETF imposed requirement. I hate to be *that* guy... but, perhaps you want to bin this whole draft if you don't want to impose that requirement. >> Updates: RFC 2460 >> Intended status: Standards Track >> [...] >> Requirements Language >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this ^^^^^ >> document are to be interpreted as described in RFC 2119 [RFC2119]. >> 5. MAY This word, or the adjective "OPTIONAL", mean that an item is >> truly optional. One vendor may choose to include the item because a >> particular marketplace requires it or because the vendor feels that >> it enhances the product while another vendor may omit the same item. >> An implementation which does not include a particular option MUST be ^^^^ >> prepared to interoperate with another implementation which does >> include the option, though perhaps with reduced functionality. In the >> same vein an implementation which does include a particular option >> MUST be prepared to interoperate with another implementation which >> does not include the option (except, of course, for the feature the >> option provides.) This draft, if published with the precise wording I quoted above, would be IETF establishing a new requirement for IPv6 hosts to "be prepared to interoperate with" [network operators] that implement the option of dropping IPv6 fragments. It's one thing for $ENTERPRISE to tell us that their network won't forward our IPv6 fragments. In theory, that can be worked out under a bilateral agreement. It's another thing entirely for IETF to tell everyone that our host implementations MUST be prepared to operate in networks that refuse to forward IPv6 fragments. I have to assume that IPv6 Ready certification tests would be updated to validate conformance to this updated standard. Please don't let anyone be confused about what is entailed for conformance to this update of RFC 2460. This is quite a major change to the Internet Protocol Version 6. I'm inclined to agree with other who say this proposal is so radical that it should warrant incrementing the major version number. -- james woodyatt core os networking From joelja@bogus.com Mon Jun 24 16:12:54 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D3421E80EF for ; Mon, 24 Jun 2013 16:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niXyM73g8WHi for ; Mon, 24 Jun 2013 16:12:54 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id E7AA421F9D2E for ; Mon, 24 Jun 2013 16:12:53 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r5ONCqKq041608 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 24 Jun 2013 23:12:52 GMT (envelope-from joelja@bogus.com) Message-ID: <51C8D26E.5050108@bogus.com> Date: Mon, 24 Jun 2013 16:12:46 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0 MIME-Version: 1.0 To: james woodyatt , "ipv6@ietf.org" Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <57D2AF30-1FC4-4B5E-8F48-4169384746B3@apple.com> In-Reply-To: <57D2AF30-1FC4-4B5E-8F48-4169384746B3@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 24 Jun 2013 23:12:52 +0000 (UTC) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 23:12:54 -0000 On 6/24/13 3:35 PM, james woodyatt wrote: > On Jun 24, 2013, at 15:11 , Ronald Bonica wrote: >>> "Network operators MAY filter IPv6 fragments." >> Ack. It is a statement of fact, not an IETF imposed requirement. > I hate to be *that* guy... but, perhaps you want to bin this whole draft if you don't want to impose that requirement. If for whatever reason you're in the position to never actually look that far into the header why would you care? >>> Updates: RFC 2460 >>> Intended status: Standards Track >>> [...] >>> Requirements Language >>> >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > ^^^^^ >>> document are to be interpreted as described in RFC 2119 [RFC2119]. >>> 5. MAY This word, or the adjective "OPTIONAL", mean that an item is >>> truly optional. One vendor may choose to include the item because a >>> particular marketplace requires it or because the vendor feels that >>> it enhances the product while another vendor may omit the same item. >>> An implementation which does not include a particular option MUST be > ^^^^ >>> prepared to interoperate with another implementation which does >>> include the option, though perhaps with reduced functionality. In the >>> same vein an implementation which does include a particular option >>> MUST be prepared to interoperate with another implementation which >>> does not include the option (except, of course, for the feature the >>> option provides.) > This draft, if published with the precise wording I quoted above, would be IETF establishing a new requirement for IPv6 hosts to "be prepared to interoperate with" [network operators] that implement the option of dropping IPv6 fragments. > > It's one thing for $ENTERPRISE to tell us that their network won't forward our IPv6 fragments. In theory, that can be worked out under a bilateral agreement. It's another thing entirely for IETF to tell everyone that our host implementations MUST be prepared to operate in networks that refuse to forward IPv6 fragments. I have to assume that IPv6 Ready certification tests would be updated to validate conformance to this updated standard. > > Please don't let anyone be confused about what is entailed for conformance to this update of RFC 2460. This is quite a major change to the Internet Protocol Version 6. I'm inclined to agree with other who say this proposal is so radical that it should warrant incrementing the major version number. > > > -- > james woodyatt > core os networking > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From jhw@apple.com Mon Jun 24 17:04:30 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5E621E8149 for ; Mon, 24 Jun 2013 17:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IrMgZ7ga76K for ; Mon, 24 Jun 2013 17:04:23 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 60F0E21E8132 for ; Mon, 24 Jun 2013 17:04:23 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MOX00LGR9IF5KP0@mail-out.apple.com> for ipv6@ietf.org; Mon, 24 Jun 2013 17:04:11 -0700 (PDT) X-AuditID: 11807158-b7f486d0000079b6-bd-51c8de7a7e3b Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 97.83.31158.A7ED8C15; Mon, 24 Jun 2013 17:04:10 -0700 (PDT) Received: from ba0301a-dhcp116.apple.com ([17.193.14.244]) by marigold.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MOX00K7V9IYCD80@marigold.apple.com> for ipv6@ietf.org; Mon, 24 Jun 2013 17:04:10 -0700 (PDT) Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt From: james woodyatt In-reply-to: <51C8D26E.5050108@bogus.com> Date: Mon, 24 Jun 2013 17:04:09 -0700 Message-id: <809CB7A5-45B2-42BE-84D6-0A0E2E3712E7@apple.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <57D2AF30-1FC4-4B5E-8F48-4169384746B3@apple.com> <51C8D26E.5050108@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1779) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FDcolt170SgwbozVhYvz75ncmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtutexkLdrBW/J52lrGBcRVLFyMHh4SAicSRLSVdjJxAppjE hXvr2boYuTiEBCYxSVzY+pgJwlnAJPHh1xomkCpmAR2J3u/fmEFsXgE9iZnTJjGC2MICwRI7 Dk4Bq2ETUJH4dvkumM0poCnxsGMeC4jNIqAqceXQBbDFzALKEn8vmEOM1JZ48u4CK8RIG4nZ R6aCtQoJnGSW+NFXAGKLAJX/2XiBGeJQWYkzPTdZJjAKzEJy0SwkF81CMnYBI/MqRoGi1JzE SlO9xIKCnFS95PzcTYzgsCuM2MH4f5nVIUYBDkYlHt4PcScChVgTy4orcw8xSnAwK4nwhooA hXhTEiurUovy44tKc1KLDzFKc7AoifNKeh0PFBJITyxJzU5NLUgtgskycXBKNTAa3c7M5Ht5 78eF8t3t7JEczlzskcaaAi39Xjsyboo6HGg/c6hR/POWz04q1eJH/soFPoo5H/WmJCc66zRH +P/thU/Fb1XLnN2U6byJX8ub9foWgTntrk/qpM0EOP9OjmVqu7q7aPLeVIkN7xb7fLj5czKL tLuk2r3Lj6+xT3615W3X9TyRb+uVWIozEg21mIuKEwEN47EYNwIAAA== Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 00:04:30 -0000 On Jun 24, 2013, at 16:12 , joel jaeggli wrote: > On 6/24/13 3:35 PM, james woodyatt wrote: >> On Jun 24, 2013, at 15:11 , Ronald Bonica wrote: >>>> "Network operators MAY filter IPv6 fragments." >>> Ack. It is a statement of fact, not an IETF imposed requirement. >> I hate to be *that* guy... but, perhaps you want to bin this whole draft if you don't want to impose that requirement. > If for whatever reason you're in the position to never actually look that far into the header why would you care? I have no idea what you're talking about. Could you please elaborate? -- james woodyatt core os networking From jiangsheng@huawei.com Mon Jun 24 17:49:22 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2ACB21F9EB4 for ; Mon, 24 Jun 2013 17:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bmy-C-i-ZOr for ; Mon, 24 Jun 2013 17:49:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8EA21F9DED for ; Mon, 24 Jun 2013 17:49:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUI57706; Tue, 25 Jun 2013 00:49:15 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 25 Jun 2013 01:48:35 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 25 Jun 2013 01:49:13 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.01.0323.007; Tue, 25 Jun 2013 08:49:07 +0800 From: Sheng Jiang To: Ronald Bonica , "Fred Baker (fred)" , =?utf-8?B?T2xlIFRyw7hhbg==?= Subject: RE: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHObrh5oVnOfg0y+kmEyboR2MaX65lEGBeQgABYEQCAASrQgA== Date: Tue, 25 Jun 2013 00:49:07 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923ACA52AE@nkgeml512-mbx.china.huawei.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> <8C48B86A895913448548E6D15DA7553B921F57@xmb-rcd-x09.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923ACA4B26@nkgeml512-mbx.china.huawei.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F86EB0@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509F86EB0@BY2PRD0512MB653.namprd05.prod.outlook.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AdS/ FwA0 K06z Leew LypU OIC9 QT2Y TvRj TwIx WKUz WWth YLGY auzm avRA bV8j nJ5u; 4; ZgByAGUAZABAAGMAaQBzAGMAbwAuAGMAbwBtADsAaQBwAHYANgBAAGkAZQB0AGYALgBvAHIAZwA7AG8AdAByAG8AYQBuAEAAZQBtAHAAbABvAHkAZQBlAHMALgBvAHIAZwA7AHIAYgBvAG4AaQBjAGEAQABqAHUAbgBpAHAAZQByAC4AbgBlAHQA; Sosha1_v1; 7; {E92745C9-9095-40F9-91A0-B41C3BB73C87}; agBpAGEAbgBnAHMAaABlAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Tue, 25 Jun 2013 00:48:59 GMT; UgBFADoAIABOAGUAdwAgAFYAZQByAHMAaQBvAG4AIABOAG8AdABpAGYAaQBjAGEAdABpAG8AbgAgAGYAbwByAAkAZAByAGEAZgB0AC0AYgBvAG4AaQBjAGEALQA2AG0AYQBuAC0AZgByAGEAZwAtAGQAZQBwAHIAZQBjAGEAdABlAC0AMAAwAC4AdAB4AHQA x-cr-puzzleid: {E92745C9-9095-40F9-91A0-B41C3BB73C87} x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 00:49:22 -0000 Pj4gKzEuIEZvciBtZSwgdGhpcyBkcmFmdCBsb29rcyBkYW5nZXJvdXMgYnkgcHJvcG9zaW5nIHRv IGRlcHJlY2F0ZQ0KPj4gZnJhZ21lbnRhdGlvbiB3aXRoIG9ubHkgb25lLXNpZGUgb2JzZXJ2YXRp b24uIFRoaXMgZHJhZnQgZG9lcyBub3QgZ2l2ZQ0KPj4gZW5vdWdoIGFuYWx5c2lzIG9uIHRoZXNl IGV4aXN0aW5nIGZyYWdtZW50YXRpb24gdXNlIGNhc2VzLCBwYXJ0aWN1bGFybHkNCj4+IHRoZXNl IHVzZSBjYXNlcyB0aGUgZnJhZ21lbnRzIHdpdGhpbiBhIHNpbmdsZSBkb21haW4uDQo+Pg0KPj4g T24gb3RoZXIgc2lkZSAsIG9ubHkgZGlzYWxsb3dpbmcgZnJhZ21lbnRhdGlvbiB0byBiZSB1c2Vk IGFtb25nIGRvbWFpbnMNCj4+IG1heSBoZWxwZnVsIHRvIHJlZHVjZSB0aGUgb3BlcmF0aW9uYWwg Y29tcGxleC4NCj4+DQo+DQo+U2hlbmcsDQo+DQo+SSBoZWFyIHlvdS4gVGhlIG5leHQgdmVyc2lv biBvZiB0aGUgZHJhZnQgd2lsbCBpbmNsdWRlIGEgZGlzY3Vzc2lvbiBvZiBTSUlULA0KPk9TUEZ2 MyBhbmQgdHVubmVsaW5nIGluIGdlbmVyYWwuDQo+DQo+KFRoaXMgc2hvdWxkIGFkZHJlc3MgeW91 ciBjb21tZW50cywgYXMgd2VsbCBhcyB0aG9zZSBvZiBUb3JlLCBGcmVkIGFuZCBGcmVkLikNCg0K SGksIFJvbiwNCg0KWWVzLCB0aGlzIHdpbGwgYWRkcmVzcyBteSBjb21tZW50cy4gSSBhZ3JlZSB3 aXRoIE9sZSB0aGF0IGFuIGFuYWx5c2lzIGRvY3VtZW50IHdvdWxkIGhlbHAgdXMgdG8gdW5kZXJz dGFuZCB0aGUgaXNzdWVzIGFuZCB0aGUgY29uc2VxdWVuY2VzLg0KDQpIb3dldmVyLCBJIHBlcnNv bmFsbHkgdGhpbmsgd2Ugd291bGQgZm91bmQgZGVwcmVjYXRpbmcgZnJhZ21lbnRhdGlvbiBpbiB3 aG9sZSBJUHY2IHByb3RvY29sIG1pZ2h0IGJlIHRvbyBkcmFtYXRpYyBhbmQgaGFkIHRvbyBtYW55 IGluY29tcGF0aWJsZSBpc3N1ZXMgYWZ0ZXIgY2FyZWZ1bGx5IGFuZCBuZXV0cmFsIGFuYWx5c2lz LiBUaGUgZGVwcmVjYXRpbmcgcHJvcG9zYWwgYnkgaXRzZWxmIG1pZ2h0IGNyZWF0ZSBtb3JlIHBy b2JsZW1zIHRoYW4gaXQgZml4ZXMuDQoNCkEgY29tcHJvbWlzZSBtZWNoYW5pc20gdGhhdCBvbmx5 IHJlc3RyaWN0IHRoZSB1c2FnZSBvZiBmcmFnbWVudGF0aW9uIGluIGNlcnRhaW4gc2NlbmFyaW9z IG1heSBiZSBtdWNoIGxlc3MgZGFtYWdlLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCj4N Cj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQoNCg== From ggm@algebras.org Mon Jun 24 18:24:15 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFD021E8156 for ; Mon, 24 Jun 2013 18:24:15 -0700 (PDT) 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=[AWL=0.567, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44Ia4L71GeIA for ; Mon, 24 Jun 2013 18:24:14 -0700 (PDT) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6175021E814A for ; Mon, 24 Jun 2013 18:24:14 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id xb12so11811391pbc.12 for ; Mon, 24 Jun 2013 18:24:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=mtaBdn3HCBWOuUyKOjgm+6fdlq3TEI6EcQIGQhsEkkY=; b=S7bs/S1d8gREKSNupSxeyVwWUkgJ12hL+se1Tji5zH+ibMcUEIZL1qMFb+AT7oSNsK J042wvSM7L4mu6RkRhgv6fTikTdouuqAmYoHFO2mL+b77NKtn0deXHgbj3TLVEQPt2tG vWhV95UEl2BwzdCk4I0tsjGd9mdp5VEmKQTVwh0GnaM+WwVW8IZd4MjxfAH1teRhiD8I r8PVaGd1cdzeNCXX4MGsuKUeSpydzMx/jI/kFGccPdUfamwLvN/R1qprBH7tbuFFrDXa 5Et6Kro0qs5QhStfSSXgKkwlgLhAiwEbqZ1+WVjZYf3ZYybXXFfVTwgkR/ROEYx/XEUI 8Osg== MIME-Version: 1.0 X-Received: by 10.66.162.102 with SMTP id xz6mr30477057pab.0.1372123454061; Mon, 24 Jun 2013 18:24:14 -0700 (PDT) Received: by 10.70.25.195 with HTTP; Mon, 24 Jun 2013 18:24:13 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:b8c9:b922:d0ed:8c40] In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> Date: Tue, 25 Jun 2013 11:24:13 +1000 Message-ID: Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt From: George Michaelson To: Ronald Bonica Content-Type: multipart/alternative; boundary=047d7b86e55011538004dff06308 X-Gm-Message-State: ALoCoQkuAa/MVBVk9K+uHYLq4wkJNzHF2nIXgk+B3XLmqnq3eKK1g23IBKoRgFiYWfkKur/NIRHj Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 01:24:15 -0000 --047d7b86e55011538004dff06308 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 25, 2013 at 2:38 AM, Ronald Bonica wrote: > ** ** > > I'd like to understand the basis of these assertions. I believe what I am > seeing, on the edge, suggests there is in fact V6 fragmentation in both TCP > and UDP.**** > > ** ** > > ** ** > > Hi George,**** > > ** ** > > It would be helpful if you could describe:**** > > ** ** > > **- **Where your observations are being made > On our own web services (www.apnic.net, and an associated whois service which attracts more wide ranging traffic) On 'high in the tree' DNS servers for reverse DNS, including an NS of in-addr.arpa and ip6.arpa (note: dns transport is disjoint from the namespace being searched: we see queries over v6 transport to v4 domains, and to ccTLD we secondary) In a packet capture of 2400::/12 run in conjunction with Merit, as research into darknets. > **** > > **- **What percentage of traffic is fragmented > our own web: practically none. our own dns: 0.01%. in a sequence of 10 minute samples. consistently, I might add. the 2400::/12: around 0.25% to 1%. so more variable, but higher. > **** > > **- **What kinds of packets are being fragmented > our own DNS: port 53. little TCP. 2400::/12 capture. mostly port 53. TCP doesn't get captured in the darknet research. Its impossible to establish the end-to-end relationship. I am not sure I call up to 1% of something 'rare'. I'm not even sure I call 0.1% or 0.01% of something 'rare'. Otherwise, Since IPv6 adoption rates are at this class of deployment by end user, perhaps it also should be considered for deprecation.. It really would be helpful to understand your assertion about the rarity of IPv6 fragmentation. I want to understand how you got to this point of view on IPv6 frags. -George **** > > **** > > Ron**** > > ** ** > --047d7b86e55011538004dff06308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



    On Tue, Jun 25, 2013 at 2:38 AM, Ronald Bonica &l= t;rbonica@juniper.= net> wrote:

    =A0

    I'd like to understand the basis of these assert= ions. I believe what I am seeing, on the edge, suggests there is in fact V6= fragmentation in both TCP and UDP.

    =A0

    =A0

    Hi George,

    =A0<= /p>

    It would be helpful if yo= u could describe:

    =A0<= /p>

    -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Where your observati= ons are being made


    On our own web services (www.apnic.net, and an associated whois service which attracts = more wide ranging traffic)

    On 'hig= h in the tree' DNS servers for reverse DNS, including an NS of in-addr.= arpa and ip6.arpa (note: dns transport is disjoint from the namespace being= searched: we see queries over v6 transport to v4 domains, and to ccTLD we = secondary)

    In a packet capture of 2400::/12 run in con= junction with Merit, as research into darknets.
    =A0

    -=A0=A0=A0=A0=A0=A0=A0=A0=A0 What percentage of t= raffic is fragmented


    our own web: practically none.=A0

    our own dns: 0.01%. in a sequence of 10 minute sample= s. consistently, I might add.

    the 2400= ::/12: =A0around 0.25% to 1%. so more variable, but higher.
    =A0

    -=A0=A0=A0=A0=A0=A0=A0=A0=A0 What kinds of packet= s are being fragmented


    our own DNS: port 53. little TCP.

    2400::/12 capture. mostly port 53. TCP doesn't ge= t captured in the darknet research. Its impossible to establish the end-to-= end relationship.

    I am not sure I call up to 1% of something = 'rare'. I'm not even sure I call 0.1% or 0.01% of something = 9;rare'. Otherwise, Since IPv6 adoption rates are at this class of depl= oyment by end user, perhaps it also should be considered for deprecation..<= /div>

    It really would be helpful to understand yo= ur assertion about the rarity of IPv6 fragmentation. I want to understand h= ow you got to this point of view on IPv6 frags.

    -George

    =A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Ron

    =A0<= /p>


    --047d7b86e55011538004dff06308-- From marka@isc.org Mon Jun 24 18:53:43 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA12F21F9C0F for ; Mon, 24 Jun 2013 18:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8342cVOtkx5 for ; Mon, 24 Jun 2013 18:53:40 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id F351A21F9007 for ; Mon, 24 Jun 2013 18:53:39 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 8CF2BC947C; Tue, 25 Jun 2013 01:53:29 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372125218; bh=xoZzzKubAJa/i8RmK0mm+bhWgd5kZwiy2WIy6L7cHKw=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=BFAT6C5aOfJTRcI6riNk2AmukX+Kx/Cx0cTZeSdybDNhRwSZW7Z303WvmvJk2MMOe qyFAOlbk+Mrf++jwjmh++/sT4VuGOPzi1toeNAU/HEOHRD8nDm8WrUVZRW3OZrLLOv 5Fna4ZtQrrJZyh3uP8UFuNPNv1fzkRnNOOGVWnEE= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 25 Jun 2013 01:53:29 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 69A6E160089; Tue, 25 Jun 2013 01:54:35 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 6DtimUkYJ8ao; Tue, 25 Jun 2013 01:54:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 78AF8160088; Tue, 25 Jun 2013 01:54:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MdsUOu4E4vUd; Tue, 25 Jun 2013 01:54:34 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id C670E160049; Tue, 25 Jun 2013 01:54:33 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 6B256363BD8F; Tue, 25 Jun 2013 11:53:17 +1000 (EST) To: George Michaelson From: Mark Andrews References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt In-reply-to: Your message of "Tue, 25 Jun 2013 11:24:13 +1000." Date: Tue, 25 Jun 2013 11:53:17 +1000 Message-Id: <20130625015317.6B256363BD8F@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 01:53:44 -0000 In message , George Michaelson writes: > --===============4023034923616370839== > Content-Type: multipart/alternative; boundary=047d7b86e55011538004dff06308 > > --047d7b86e55011538004dff06308 > Content-Type: text/plain; charset=ISO-8859-1 > > On Tue, Jun 25, 2013 at 2:38 AM, Ronald Bonica wrote: > > > ** ** > > > > I'd like to understand the basis of these assertions. I believe what I am > > seeing, on the edge, suggests there is in fact V6 fragmentation in both TCP > > and UDP.**** > > > > ** ** > > > > ** ** > > > > Hi George,**** > > > > ** ** > > > > It would be helpful if you could describe:**** > > > > ** ** > > > > **- **Where your observations are being made > > > > On our own web services (www.apnic.net, and an associated whois service > which attracts more wide ranging traffic) > > On 'high in the tree' DNS servers for reverse DNS, including an NS of > in-addr.arpa and ip6.arpa (note: dns transport is disjoint from the > namespace being searched: we see queries over v6 transport to v4 domains, > and to ccTLD we secondary) > > In a packet capture of 2400::/12 run in conjunction with Merit, as research > into darknets. > > > > **** > > > > **- **What percentage of traffic is fragmented > > > > our own web: practically none. > > our own dns: 0.01%. in a sequence of 10 minute samples. consistently, I > might add. > > the 2400::/12: around 0.25% to 1%. so more variable, but higher. > > > > **** > > > > **- **What kinds of packets are being fragmented > > > > our own DNS: port 53. little TCP. > > 2400::/12 capture. mostly port 53. TCP doesn't get captured in the darknet > research. Its impossible to establish the end-to-end relationship. > > I am not sure I call up to 1% of something 'rare'. I'm not even sure I call > 0.1% or 0.01% of something 'rare'. Otherwise, Since IPv6 adoption rates are > at this class of deployment by end user, perhaps it also should be > considered for deprecation.. > > It really would be helpful to understand your assertion about the rarity of > IPv6 fragmentation. I want to understand how you got to this point of view > on IPv6 frags. > > -George .58% of my IPv6 traffic in fragmented. Assuming that it is mostly UDP I get 14% of my IPv6 UDP traffic is fragmented. Most of that traffic is non local. I would assume most of the drops are due to PMTUD blocking the initial fragment but letting the tail fragment through as this machine is behind a tunnel. Mark ip6: 381915 total packets received 0 with size smaller than minimum 0 with data size < data length 0 with bad options 0 with incorrect version number 2213 fragments received 0 fragments dropped (dup or out of space) 48 fragments dropped after timeout 0 fragments that exceeded limit 1077 packets reassembled ok 217810 packets for this host 0 packets forwarded 93958 packets not forwardable 0 redirects sent 297719 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 5031 output packets discarded due to no route 33 output datagrams fragmented 66 fragments created 0 datagrams that can't be fragmented 0 packets that violated scope rules 93924 multicast packets which we don't join Input histogram: hop by hop: 132 TCP: 202894 UDP: 15103 fragment: 2213 ICMP6: 161573 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From joelja@bogus.com Mon Jun 24 18:58:57 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A6321F9D39 for ; Mon, 24 Jun 2013 18:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCyNNKIRGnxu for ; Mon, 24 Jun 2013 18:58:57 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0BC21F9D34 for ; Mon, 24 Jun 2013 18:58:57 -0700 (PDT) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r5P1wsNk043151 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 25 Jun 2013 01:58:55 GMT (envelope-from joelja@bogus.com) Message-ID: <51C8F959.4040108@bogus.com> Date: Mon, 24 Jun 2013 18:58:49 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0 MIME-Version: 1.0 To: james woodyatt Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <57D2AF30-1FC4-4B5E-8F48-4169384746B3@apple.com> <51C8D26E.5050108@bogus.com> <809CB7A5-45B2-42BE-84D6-0A0E2E3712E7@apple.com> In-Reply-To: <809CB7A5-45B2-42BE-84D6-0A0E2E3712E7@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 25 Jun 2013 01:58:56 +0000 (UTC) Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 01:58:57 -0000 On 6/24/13 5:04 PM, james woodyatt wrote: > On Jun 24, 2013, at 16:12 , joel jaeggli wrote: >> On 6/24/13 3:35 PM, james woodyatt wrote: >>> On Jun 24, 2013, at 15:11 , Ronald Bonica wrote: >>>>> "Network operators MAY filter IPv6 fragments." >>>> Ack. It is a statement of fact, not an IETF imposed requirement. >>> I hate to be *that* guy... but, perhaps you want to bin this whole draft if you don't want to impose that requirement. >> If for whatever reason you're in the position to never actually look that far into the header why would you care? > I have no idea what you're talking about. Could you please elaborate? if you have a device that does not need to look beyond the 40 byte fixed header to forward then finding the frag header is additional work. somewhat closer to the edge of the network I need to find the L4 header. but if you can't ( or don't want to look beyond the fixed header you probably shouldn't have to. insuring no fragmentation header exists implies further parsing of the header chain. > > -- > james woodyatt > core os networking > From rbonica@juniper.net Mon Jun 24 19:22:47 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5A521F9D79 for ; Mon, 24 Jun 2013 19:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.659 X-Spam-Level: X-Spam-Status: No, score=-100.659 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14h3LXUSCLLf for ; Mon, 24 Jun 2013 19:22:42 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 7F28F21F9C2C for ; Mon, 24 Jun 2013 19:22:42 -0700 (PDT) Received: from mail182-co1-R.bigfish.com (10.243.78.245) by CO1EHSOBE031.bigfish.com (10.243.66.96) with Microsoft SMTP Server id 14.1.225.23; Tue, 25 Jun 2013 02:22:41 +0000 Received: from mail182-co1 (localhost [127.0.0.1]) by mail182-co1-R.bigfish.com (Postfix) with ESMTP id CC5108801C9 for ; Tue, 25 Jun 2013 02:22:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz98dI9371I542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275ch1033IL8275bh8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail182-co1: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=rbonica@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail182-co1 (localhost.localdomain [127.0.0.1]) by mail182-co1 (MessageSwitch) id 1372126960435501_16283; Tue, 25 Jun 2013 02:22:40 +0000 (UTC) Received: from CO1EHSMHS028.bigfish.com (unknown [10.243.78.238]) by mail182-co1.bigfish.com (Postfix) with ESMTP id 6856B80067 for ; Tue, 25 Jun 2013 02:22:40 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.53) by CO1EHSMHS028.bigfish.com (10.243.66.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 25 Jun 2013 02:22:38 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 24 Jun 2013 19:22:36 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 24 Jun 2013 19:22:35 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.189) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 24 Jun 2013 19:25:54 -0700 Received: from mail45-co1-R.bigfish.com (10.243.78.244) by CO1EHSOBE010.bigfish.com (10.243.66.73) with Microsoft SMTP Server id 14.1.225.23; Tue, 25 Jun 2013 02:22:35 +0000 Received: from mail45-co1 (localhost [127.0.0.1]) by mail45-co1-R.bigfish.com (Postfix) with ESMTP id 22C062800AB for ; Tue, 25 Jun 2013 02:22:35 +0000 (UTC) Received: from mail45-co1 (localhost.localdomain [127.0.0.1]) by mail45-co1 (MessageSwitch) id 1372126952975415_9286; Tue, 25 Jun 2013 02:22:32 +0000 (UTC) Received: from CO1EHSMHS003.bigfish.com (unknown [10.243.78.230]) by mail45-co1.bigfish.com (Postfix) with ESMTP id DE431E004A; Tue, 25 Jun 2013 02:22:32 +0000 (UTC) Received: from BY2PRD0512HT003.namprd05.prod.outlook.com (157.56.238.5) by CO1EHSMHS003.bigfish.com (10.243.66.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 25 Jun 2013 02:22:32 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.17]) by BY2PRD0512HT003.namprd05.prod.outlook.com ([10.255.243.36]) with mapi id 14.16.0324.000; Tue, 25 Jun 2013 02:22:31 +0000 From: Ronald Bonica To: Mark Andrews , George Michaelson Subject: RE: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHOcUK8wy5viUlUDUi1/0ayqLbZ05lFqyazgAAHWQA= Date: Tue, 25 Jun 2013 02:22:31 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.prod.outlook.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625015317.6B256363BD8F@drugs.dv.isc.org> In-Reply-To: <20130625015317.6B256363BD8F@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ISC.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ALGEBRAS.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 02:22:47 -0000 Hi Mark, Thanks for this good empirical data! I would like to verify your assertion that most of the IPv6 fragment carry = UDP. Do you have any way to be sure? Ron > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org] > Sent: Monday, June 24, 2013 9:53 PM > To: George Michaelson > Cc: Ronald Bonica; ipv6@ietf.org 6man-wg > Subject: Re: New Version Notification for draft-bonica-6man-frag- > deprecate-00.txt >=20 >=20 > In message RKQ9eYg@mail.gmail.com> > , George Michaelson writes: > > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D4023034923616370839=3D= =3D > > Content-Type: multipart/alternative; > > boundary=3D047d7b86e55011538004dff06308 > > > > --047d7b86e55011538004dff06308 > > Content-Type: text/plain; charset=3DISO-8859-1 > > > > On Tue, Jun 25, 2013 at 2:38 AM, Ronald Bonica > wrote: > > > > > ** ** > > > > > > I'd like to understand the basis of these assertions. I believe > what > > > I am seeing, on the edge, suggests there is in fact V6 > fragmentation > > > in both TCP and UDP.**** > > > > > > ** ** > > > > > > ** ** > > > > > > Hi George,**** > > > > > > ** ** > > > > > > It would be helpful if you could describe:**** > > > > > > ** ** > > > > > > **- **Where your observations are being made > > > > > > > On our own web services (www.apnic.net, and an associated whois > > service which attracts more wide ranging traffic) > > > > On 'high in the tree' DNS servers for reverse DNS, including an NS of > > in-addr.arpa and ip6.arpa (note: dns transport is disjoint from the > > namespace being searched: we see queries over v6 transport to v4 > > domains, and to ccTLD we secondary) > > > > In a packet capture of 2400::/12 run in conjunction with Merit, as > > research into darknets. > > > > > > > **** > > > > > > **- **What percentage of traffic is fragmented > > > > > > > our own web: practically none. > > > > our own dns: 0.01%. in a sequence of 10 minute samples. consistently, > > I might add. > > > > the 2400::/12: around 0.25% to 1%. so more variable, but higher. > > > > > > > **** > > > > > > **- **What kinds of packets are being fragmented > > > > > > > our own DNS: port 53. little TCP. > > > > 2400::/12 capture. mostly port 53. TCP doesn't get captured in the > > darknet research. Its impossible to establish the end-to-end > relationship. > > > > I am not sure I call up to 1% of something 'rare'. I'm not even sure > I > > call 0.1% or 0.01% of something 'rare'. Otherwise, Since IPv6 > adoption > > rates are at this class of deployment by end user, perhaps it also > > should be considered for deprecation.. > > > > It really would be helpful to understand your assertion about the > > rarity of > > IPv6 fragmentation. I want to understand how you got to this point of > > view on IPv6 frags. > > > > -George >=20 > .58% of my IPv6 traffic in fragmented. Assuming that it is mostly UDP > I get 14% of my IPv6 UDP traffic is fragmented. Most of that traffic > is non local. I would assume most of the drops are due to PMTUD > blocking the initial fragment but letting the tail fragment through as > this machine is behind a tunnel. >=20 > Mark >=20 > ip6: > 381915 total packets received > 0 with size smaller than minimum > 0 with data size < data length > 0 with bad options > 0 with incorrect version number > 2213 fragments received > 0 fragments dropped (dup or out of space) > 48 fragments dropped after timeout > 0 fragments that exceeded limit > 1077 packets reassembled ok > 217810 packets for this host > 0 packets forwarded > 93958 packets not forwardable > 0 redirects sent > 297719 packets sent from this host > 0 packets sent with fabricated ip header > 0 output packets dropped due to no bufs, etc. > 5031 output packets discarded due to no route > 33 output datagrams fragmented > 66 fragments created > 0 datagrams that can't be fragmented > 0 packets that violated scope rules > 93924 multicast packets which we don't join > Input histogram: > hop by hop: 132 > TCP: 202894 > UDP: 15103 > fragment: 2213 > ICMP6: 161573 >=20 > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >=20 From brian.e.carpenter@gmail.com Mon Jun 24 19:39:25 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA69621F9DDC for ; Mon, 24 Jun 2013 19:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4XWqs1dwePF for ; Mon, 24 Jun 2013 19:39:25 -0700 (PDT) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4662621F9DC9 for ; Mon, 24 Jun 2013 19:39:25 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id xb12so11889533pbc.12 for ; Mon, 24 Jun 2013 19:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tuym8Zy8jMEq8VtZ9OheKLfu186+j5gVgMzSipWl2vI=; b=KwaAqCK9LfDQqL1wiqrchRUhWP4f1NlINueccK7fU/IeKbuPLaBKAdhB4tIRVcRJ/V IcKkcaFwWBFuvEh+Z1SJAEFxwEBQmELkWXO/yaZpaOesCLz15Q7INSy4L7TE2WsF0kkE ULxPdfWAiUL3WyvntY8qojafYgw+1xDkxcqe0inX5phaXc/yhWIoz6gY6MCqt9OWJYhk YyORQMahVRgwpzQqZLw5w8KJOE1LyGr4Ty5FY7b+rPoPrapRmOu9qfzKyLKf21Fx7vx2 wwT0gl1XlO76WiH1qXZY4MU5HVBg2LbW9RxJ5EOdXJhpr0KdX8ykLVNu7RdNa0nALssS UcZw== X-Received: by 10.68.189.36 with SMTP id gf4mr3910152pbc.27.1372127965006; Mon, 24 Jun 2013 19:39:25 -0700 (PDT) Received: from [192.168.178.22] (115.198.69.111.dynamic.snap.net.nz. [111.69.198.115]) by mx.google.com with ESMTPSA id sq5sm22649957pab.11.2013.06.24.19.39.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Jun 2013 19:39:24 -0700 (PDT) Message-ID: <51C902DC.9000408@gmail.com> Date: Tue, 25 Jun 2013 14:39:24 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ronald Bonica Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , Arturo Servin X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 02:39:25 -0000 On 25/06/2013 10:11, Ronald Bonica wrote: >> "New IPv6 host implementations MAY support IPv6 fragmentation and >> reassembly" >> break things. "New IPv6 host implementations MAY support IPv6 >> fragmentation but MUST support reassembly" may superior. This will >> aging out fragmentation over a longer period, new hosts will not use it >> but existing - applications will not break. > > I could live with this. Would it satisfy other folks' objections? I think it's far too soon in developing the analysis to be able to answer that question. This isn't cooked yet. > >> "Network operators MAY filter IPv6 fragments." is a policy thing and >> costumers have to deal with that already. So it is ok from my point of >> view. > > Ack. It is a statement of fact, not an IETF imposed requirement. If it's a statement of fact, it shouldn't use RFC 2119 language. It should simply state the truth: "Network operators might filter IPv6 fragments." Brian From randy@psg.com Mon Jun 24 19:44:13 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E09C11E80FE for ; Mon, 24 Jun 2013 19:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8OICNMJA8n3 for ; Mon, 24 Jun 2013 19:44:12 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id B173911E80FC for ; Mon, 24 Jun 2013 19:44:12 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UrJEm-00092V-Pp; Tue, 25 Jun 2013 02:44:09 +0000 Date: Tue, 25 Jun 2013 11:44:07 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt In-Reply-To: <51C902DC.9000408@gmail.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: "ipv6@ietf.org" , Arturo Servin X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 02:44:13 -0000 > If it's a statement of fact, it shouldn't use RFC 2119 language. It > should simply state the truth: "Network operators might filter IPv6 > fragments." s/might/do/ From joelja@bogus.com Mon Jun 24 20:04:04 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED56211E8102 for ; Mon, 24 Jun 2013 20:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sw32HPHH-g7h for ; Mon, 24 Jun 2013 20:04:03 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3063711E8101 for ; Mon, 24 Jun 2013 20:04:03 -0700 (PDT) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r5P33xKt043920 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 25 Jun 2013 03:04:00 GMT (envelope-from joelja@bogus.com) Message-ID: <51C90899.60504@bogus.com> Date: Mon, 24 Jun 2013 20:03:53 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0 MIME-Version: 1.0 To: Marc Lampo , Ronald Bonica Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 25 Jun 2013 03:04:00 +0000 (UTC) Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 03:04:04 -0000 On 6/24/13 12:19 PM, Marc Lampo wrote: > -1 > > Not because I'm a fan of fragmentation, but I think a layer 3 (IP) > protocol that does not support fragmentation should really be a *new* > IP version. > In my opinion, the changes are too dramatic : > if layer 3, not supporting fragmentation, is asked to sent a message, > too big for one packet, > it should inform layer 4 with an error message; > while a layer 3 that supports fragmentation, can fragment and send in > multiple packets (and return succes to layer 4). > imho in some respects this is simply closing the circle... Intermediate hopes can't fragment in ipv6 leaving it the exclusive domain of endpoints. if the endpoints can't simply generate large datagrams at the ip layer then they have to fragment upper layer datagrams somewhere else. I agree with Fred T that this is a particular problem with tunnels becuase the IP datagrams you're encapsulating will have to be fragmented in some fashion, alternatively you really have to be able to rely on PMTUD work and frankly I'd really like to work becuase I think it's rather sad that MTUs <= 1500 are all we can expect to support end-to-end. > I can imagine case exist - without searching for explicit examples, > some already given or hinted at by others in this discussion - > where two partners in a conversation cannot communicate (perhaps only > simplex ?) because one is implemented > on a host that implements IPv6 with fragmentation and the other on a > host that implements IPv6 without fragmentation. > > > I do agree that fragmentation introduces attack vectors, > but allowing that hosts do not implement it is, for me, not the > correct approach. > I'd prefer to insist that all headers, up till and including the layer > 4, are in the first fragment > and that implementations provide correct implementation of fragmentation. > (both suggestions merely a repetition of other contributors in this > discussion) > > > In one of the replies you, Ron, write : > > I don't know of a study. However, this is probably a safe assumption > considering that: > > > > - many TCP implementation leverage PMTUD > > - many enterprise block fragments > > - many firewalls, by default, block IPv6 fragments > > I cannot comment on the first point. > My experience with enterprises is that firewalls used normally cope > well with fragments > (in the sense that they can flow through) > ((perhaps in the old days, before "stateful inspection", with basic > ACL's; > but even a cheap home router copes with (IPv4) fragmentation)) > As for point 3 : when I look at firewall capabilities concerning IPv6 > I actually look if it is possible to allow *only* the fragmentation > extension header > (as, in my opinion, it is the only extension header needed to let the > business run) > ((a statement that, by itself, might generate discussion - please, in > a different thread)) > So, as for the list of 3 points, I cannot support this "safe assumption". > > > Kind regards, > > Marc > > > On Thu, Jun 20, 2013 at 5:55 PM, Ronald Bonica > wrote: > > Folks, > > Please review this draft and provide comments. > > Ron > > > > -----Original Message----- > > From: internet-drafts@ietf.org > [mailto:internet-drafts@ietf.org ] > > Sent: Thursday, June 20, 2013 11:48 AM > > To: Ronald Bonica > > Subject: New Version Notification for > draft-bonica-6man-frag-deprecate- > > 00.txt > > > > > > A new version of I-D, draft-bonica-6man-frag-deprecate-00.txt > > has been successfully submitted by Ron Bonica and posted to the IETF > > repository. > > > > Filename: draft-bonica-6man-frag-deprecate > > Revision: 00 > > Title: IPv6 Fragment Header Deprecated > > Creation date: 2013-06-20 > > Group: Individual Submission > > Number of pages: 7 > > URL: http://www.ietf.org/internet-drafts/draft-bonica-6man- > > frag-deprecate-00.txt > > Status: http://datatracker.ietf.org/doc/draft-bonica-6man- > > frag-deprecate > > Htmlized: http://tools.ietf.org/html/draft-bonica-6man-frag- > > deprecate-00 > > > > > > Abstract: > > This memo deprecates the IPv6 Fragment Header. It provides > reasons > > for deprecation and updates RFC 2460. > > > > > > > > > > > > The IETF Secretariat > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From marka@isc.org Mon Jun 24 21:02:34 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8FC21E808D for ; Mon, 24 Jun 2013 21:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kssuPsokJLof for ; Mon, 24 Jun 2013 21:02:30 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 3F02C21E805E for ; Mon, 24 Jun 2013 21:02:30 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 98077C9450; Tue, 25 Jun 2013 04:02:15 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372132943; bh=JUPRNoCqDORucNT/yqDmFpCk7MnS5DL+HtP11hRaMqA=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=uktUdSsp511/dpxXqMGM0EsmcBxDh2AhRpAJTd/tdRtTgqoTv12sRTK7r86rvd2GM HVqHI7yP/gJ22KapZD51IqiuTSnzJa6kFyHgqvPF5+uTfAUyGbV5Ur1aHhmNrUPcTK l/T2sMcXIr89a4HyoFaSoMJXxI63zoLWf61wGrBU= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 25 Jun 2013 04:02:15 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D3FF4160057; Tue, 25 Jun 2013 04:03:21 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id wH8lqeig2atv; Tue, 25 Jun 2013 04:03:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7F85A160089; Tue, 25 Jun 2013 04:03:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id miDJd6meMtYE; Tue, 25 Jun 2013 04:03:21 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id 21DBE160088; Tue, 25 Jun 2013 04:03:21 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 1CCA7363C42A; Tue, 25 Jun 2013 14:02:07 +1000 (EST) To: Ronald Bonica From: Mark Andrews References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625015317.6B256363BD8F@drugs.dv.isc.org> <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.prod.outlook.com> Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt In-reply-to: Your message of "Tue, 25 Jun 2013 02:22:31 +0000." <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.prod.outlook.com> Date: Tue, 25 Jun 2013 14:02:06 +1000 Message-Id: <20130625040207.1CCA7363C42A@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 04:02:34 -0000 In message <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.p rod.outlook.com>, Ronald Bonica writes: > Hi Mark, > > Thanks for this good empirical data! > > I would like to verify your assertion that most of the IPv6 fragment carry > UDP. Do you have any way to be sure? I've looked at packet traces in the past and the fragmented traffic is UDP. The box is running a validating recursive nameserver which advertises a 4096 byte EDNS UDP buffer. It draws in fragmented traffic. I can tell when there are out of order IPv4 fragments as the NAT in front of it doesn't handle the case where the first fragment received is not the initial fragment. Whether you see fragmented traffic is very dependent upon what you are doing, how things are configured and what the application layer has learnt about the network characteristics. There is a lot of potential fragmented traffic out there. Mark > Ron -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ggm@algebras.org Mon Jun 24 22:06:58 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFCB21F9AE0 for ; Mon, 24 Jun 2013 22:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-aPWknoh-Ey for ; Mon, 24 Jun 2013 22:06:57 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0F29721F9A8E for ; Mon, 24 Jun 2013 22:06:53 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id a13so26532087iee.20 for ; Mon, 24 Jun 2013 22:06:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=sBvehbIIz8b2OJUqAvCY2DN7Vbr9zbClYfjurTgGUJI=; b=PCmaWALIOOhjAapblosiq/xArzG2qgdDMR+tE+65qWspBEQON9K1fF9pWr2CIviEIC dMUq7hKkT8GwXpwzswtdAiYnQcfYCkzOOocKnNMkd/Gor24vwIH5nIzIKOpJ4nzSOC9/ WiT2ZAOoJD+IyB7RV7rP/rh/gVgWiQ/Cd79Rr3lRWv6hBlnxG/Eq9MEDwMb1Pm18VN+Q UyrDJluPN2vNvW1wcEAPg/Qe8orbwn+WBLuNjcUO2u4lO6BDMGT6PcGOojPWoeSm4NyU qXuq6g+cIstLnIRd9zqXCyTCPODLXgDha0J+5l/bKPsxb65OTcPl2unhXlwQtx1XtNcx G7Sg== MIME-Version: 1.0 X-Received: by 10.43.118.136 with SMTP id fq8mr9747607icc.101.1372136813671; Mon, 24 Jun 2013 22:06:53 -0700 (PDT) Received: by 10.64.137.68 with HTTP; Mon, 24 Jun 2013 22:06:53 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:e8f9:e610:63e7:58ce] In-Reply-To: <20130625040207.1CCA7363C42A@drugs.dv.isc.org> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625015317.6B256363BD8F@drugs.dv.isc.org> <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625040207.1CCA7363C42A@drugs.dv.isc.org> Date: Tue, 25 Jun 2013 15:06:53 +1000 Message-ID: Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt From: George Michaelson To: "ipv6@ietf.org 6man-wg" Content-Type: multipart/alternative; boundary=bcaec517c68c5cd14504dff37f18 X-Gm-Message-State: ALoCoQl+vd1qqEZowIelPlvNQqX52Mf/LZn3TgGvi6xWVnmcjTKb3l/01uL702G5t/V3gI7YkSSg X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 05:06:58 -0000 --bcaec517c68c5cd14504dff37f18 Content-Type: text/plain; charset=ISO-8859-1 One thing I *strongly* agree with: the sentence at 2.2: The effective MTU for IPv6 is 1280 bytes. This is looking compellingly awful, but true to me. I think there is enough pMTU breakage that its safer to MSS clamp down. The downside cost in apparent efficiency has been beaten to death, its a non-issue for me right now. We even see broken tunnel heads which report back with pMTU the size of the *outer* packet shroud, so tell 1400 byte packets to resend at ... 1400 bytes. FAIL. cheers -George --bcaec517c68c5cd14504dff37f18 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    One thing I *strongly* agree with: the sentence at 2.2:
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The effective MTU for = IPv6 is 1280 bytes.

    This is looking comp= ellingly awful, but true to me. I think there is enough pMTU breakage that = its safer to MSS clamp down. The downside cost in apparent efficiency has b= een beaten to death, its a non-issue for me right now. We even see broken t= unnel heads which report back with pMTU the size of the *outer* packet shro= ud, so tell 1400 byte packets to resend at ... 1400 bytes. FAIL.

    cheers

    -George
    --bcaec517c68c5cd14504dff37f18-- From fred@cisco.com Mon Jun 24 22:17:45 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA2111E810B for ; Mon, 24 Jun 2013 22:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.58 X-Spam-Level: X-Spam-Status: No, score=-110.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DjVUIBL0wKM for ; Mon, 24 Jun 2013 22:17:35 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3EB11E810E for ; Mon, 24 Jun 2013 22:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=445; q=dns/txt; s=iport; t=1372137455; x=1373347055; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=V33OQviyLGI7oMRKGtXYTrVzphWy1HTgECzaQuuDTOE=; b=bV5UeuTwPc1CDaCYpT47MfBDO1qjxMIfwDWdtRu/tFLuzJQanLZdDMwb gnSFGkscONdAsst9XTAQ+6Av2QHTquneHVbKt8XdCg6jql7HCo1aS1MtT nWu2URQPbR2qbhNviD8pXCeY2qEufYbSFMtADaCC3Trhq9z5MIbUPeq5o E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FALImyVGtJXG8/2dsb2JhbABagwl6gj68eIEDFnSCIwEBAQMBdwIFCwIBCCIkMiUCBA4FCIgABrp5jxwCMQeDAmEDiGmgHoMQgig X-IronPort-AV: E=Sophos;i="4.87,933,1363132800"; d="scan'208";a="226971772" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 25 Jun 2013 05:17:35 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5P5HZ30023874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Jun 2013 05:17:35 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 25 Jun 2013 00:17:34 -0500 From: "Fred Baker (fred)" To: Sheng Jiang Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHObrhw+oeXeGk8fUGYrsNNQcu2OplEbx8AgADa9wCAAKfigIAASwEA Date: Tue, 25 Jun 2013 05:17:34 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B924D3D@xmb-rcd-x09.cisco.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> <8C48B86A895913448548E6D15DA7553B921F57@xmb-rcd-x09.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923ACA4B26@nkgeml512-mbx.china.huawei.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F86EB0@BY2PRD0512MB653.namprd05.prod.outlook.com> <5D36713D8A4E7348A7E10DF7437A4B923ACA52AE@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923ACA52AE@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.125] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4A2F9D76852180408A5BCAF93A65B885@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 05:17:46 -0000 On Jun 24, 2013, at 5:49 PM, Sheng Jiang wrote: > However, I personally think we would found deprecating fragmentation in w= hole IPv6 protocol might be too dramatic and had too many incompatible issu= es after carefully and neutral analysis. That is consistent with my view, for reasons I have already stated. > The deprecating proposal by itself might create more problems than it fix= es. Possibly.= From gih@apnic.net Tue Jun 25 00:16:01 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40CE21F9FAF for ; Tue, 25 Jun 2013 00:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.745 X-Spam-Level: X-Spam-Status: No, score=-98.745 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoaFXSSONOV1 for ; Tue, 25 Jun 2013 00:15:57 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:3::243]) by ietfa.amsl.com (Postfix) with SMTP id 43F0321F9F83 for ; Tue, 25 Jun 2013 00:15:55 -0700 (PDT) Received: from NXMDA1.org.apnic.net (unknown [203.119.93.247]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Tue, 25 Jun 2013 17:15:50 +1000 (EST) Received: from [172.16.100.111] (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 25 Jun 2013 17:15:50 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt From: Geoff Huston In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.prod.outlook.com> Date: Tue, 25 Jun 2013 17:15:49 +1000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625015317.6B256363BD8F@drugs.dv.isc.org> <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.prod.outlook.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1508) Cc: "ipv6@ietf.org 6man-wg" , Mark Andrews X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 07:16:01 -0000 Hi, We _are_ seeing IPv6 packet fragmentation in TCP over IPv6, and the = causes are systematic, rather than random chance. What is happening is that the client is behind some form of tunnel = (MPLS) we _assume_. The server (FreeBSD recent version) is sitting with = a MTU of 1500, as is the client. The client opens 5 ports in parallel (possibly firefox???) The client = makes a request down port 1, then, a little later, makes another request = down port 2. The server sends large packets down the TCP session open to = port 1. A gateway on the path sends back an ICMP6 packet too big to the = server for this TCP session, with a new MTU of 1492. The TCP session on = port 1 now adjust its MSS to 1432 (=3D1492 - 60) and the server resends = its set of data as a sequence of packets each of which is 1492 octets in = size - all good, no fragmentation of TCP packets so far. But then, on the session open to the client's port 2 the server = assembles its set of packets for the second request to send to the = client. The TCP session on the server which is bound to port 2 of the = client is unaware of the MTU change (after all, the ICMP6 PTB message = was directed to the TCP session that is bound to client port 1, not port = 2), and the server's IPv6 driver gets a set of 1440 octet TCP payload = packets to send to the client. But there is a data structure in the = server (I think FreeBSD uses the routing table, but the FreeBSD folk = probably know better than I do which internal table is used to cache = path MTU data derived from ICMPv6 PTB messages) which says that for this = IPv6 destination address the new MTU is not 1500, but is 1492. The IPv6 = output driver now fragments the queued TCP packets to session connected = to the client port 2 to send 2 packets for each single packet passed to = it from the upper level TCP driver, and what heads onto the wire is a = 1420 octet payload and a 20 octet payload, with IPv6 fragmentation set = to bind them together. As far as I can see this is not "bad" behaviour. The second session has = not received it own ICMP6 packet too big, so this TCP session (and all = other parallel TCP sessions) are unaware of the need to drop its MSS, = and because of the cached per host entry with the new MTU the IP driver = is aware that it cannot send these packets out without fragmentation. So = the IP layer is aware of this lower path MTU and correctly fragments the = TCP packet to ensure delivery. I don't believe this is a bug per se. I = think its an unintended side effect of the way in which ICMP6 PTB = messages are processed by the recipient. How prevalent is this behaviour? Well, how prevalent are browsers that open up parallel ports to the same = destination? Gee, with today's browsers just about everyone does this! If you want to deprecate IPv6 fragmentation and still allow this form of = parallel session behaviour to work rather than wedge, then the internal = handling of ICMPv6 PTB messages in the host needs to be reworked as far = as I can tell. thanks, Geoff On 25/06/2013, at 12:22 PM, Ronald Bonica wrote: > Hi Mark, >=20 > Thanks for this good empirical data! >=20 > I would like to verify your assertion that most of the IPv6 fragment = carry UDP. Do you have any way to be sure? >=20 > Ron >=20 >=20 >> -----Original Message----- >> From: Mark Andrews [mailto:marka@isc.org] >> Sent: Monday, June 24, 2013 9:53 PM >> To: George Michaelson >> Cc: Ronald Bonica; ipv6@ietf.org 6man-wg >> Subject: Re: New Version Notification for draft-bonica-6man-frag- >> deprecate-00.txt >>=20 >>=20 >> In message > RKQ9eYg@mail.gmail.com> >> , George Michaelson writes: >>> --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D4023034923616370839=3D=3D= >>> Content-Type: multipart/alternative; >>> boundary=3D047d7b86e55011538004dff06308 >>>=20 >>> --047d7b86e55011538004dff06308 >>> Content-Type: text/plain; charset=3DISO-8859-1 >>>=20 >>> On Tue, Jun 25, 2013 at 2:38 AM, Ronald Bonica >> wrote: >>>=20 >>>> ** ** >>>>=20 >>>> I'd like to understand the basis of these assertions. I believe >> what >>>> I am seeing, on the edge, suggests there is in fact V6 >> fragmentation >>>> in both TCP and UDP.**** >>>>=20 >>>> ** ** >>>>=20 >>>> ** ** >>>>=20 >>>> Hi George,**** >>>>=20 >>>> ** ** >>>>=20 >>>> It would be helpful if you could describe:**** >>>>=20 >>>> ** ** >>>>=20 >>>> **- **Where your observations are being made >>>>=20 >>>=20 >>> On our own web services (www.apnic.net, and an associated whois >>> service which attracts more wide ranging traffic) >>>=20 >>> On 'high in the tree' DNS servers for reverse DNS, including an NS = of >>> in-addr.arpa and ip6.arpa (note: dns transport is disjoint from the >>> namespace being searched: we see queries over v6 transport to v4 >>> domains, and to ccTLD we secondary) >>>=20 >>> In a packet capture of 2400::/12 run in conjunction with Merit, as >>> research into darknets. >>>=20 >>>=20 >>>> **** >>>>=20 >>>> **- **What percentage of traffic is fragmented >>>>=20 >>>=20 >>> our own web: practically none. >>>=20 >>> our own dns: 0.01%. in a sequence of 10 minute samples. = consistently, >>> I might add. >>>=20 >>> the 2400::/12: around 0.25% to 1%. so more variable, but higher. >>>=20 >>>=20 >>>> **** >>>>=20 >>>> **- **What kinds of packets are being fragmented >>>>=20 >>>=20 >>> our own DNS: port 53. little TCP. >>>=20 >>> 2400::/12 capture. mostly port 53. TCP doesn't get captured in the >>> darknet research. Its impossible to establish the end-to-end >> relationship. >>>=20 >>> I am not sure I call up to 1% of something 'rare'. I'm not even sure >> I >>> call 0.1% or 0.01% of something 'rare'. Otherwise, Since IPv6 >> adoption >>> rates are at this class of deployment by end user, perhaps it also >>> should be considered for deprecation.. >>>=20 >>> It really would be helpful to understand your assertion about the >>> rarity of >>> IPv6 fragmentation. I want to understand how you got to this point = of >>> view on IPv6 frags. >>>=20 >>> -George >>=20 >> .58% of my IPv6 traffic in fragmented. Assuming that it is mostly = UDP >> I get 14% of my IPv6 UDP traffic is fragmented. Most of that traffic >> is non local. I would assume most of the drops are due to PMTUD >> blocking the initial fragment but letting the tail fragment through = as >> this machine is behind a tunnel. >>=20 >> Mark >>=20 >> ip6: >> 381915 total packets received >> 0 with size smaller than minimum >> 0 with data size < data length >> 0 with bad options >> 0 with incorrect version number >> 2213 fragments received >> 0 fragments dropped (dup or out of space) >> 48 fragments dropped after timeout >> 0 fragments that exceeded limit >> 1077 packets reassembled ok >> 217810 packets for this host >> 0 packets forwarded >> 93958 packets not forwardable >> 0 redirects sent >> 297719 packets sent from this host >> 0 packets sent with fabricated ip header >> 0 output packets dropped due to no bufs, etc. >> 5031 output packets discarded due to no route >> 33 output datagrams fragmented >> 66 fragments created >> 0 datagrams that can't be fragmented >> 0 packets that violated scope rules >> 93924 multicast packets which we don't join >> Input histogram: >> hop by hop: 132 >> TCP: 202894 >> UDP: 15103 >> fragment: 2213 >> ICMP6: 161573 >>=20 >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >>=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From marka@isc.org Tue Jun 25 00:17:57 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A559C21F9FC0 for ; Tue, 25 Jun 2013 00:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jBiwEJcMpn5 for ; Tue, 25 Jun 2013 00:17:52 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id D1FD021F9FB8 for ; Tue, 25 Jun 2013 00:17:52 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id F00B3C94CC; Tue, 25 Jun 2013 07:17:45 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372144672; bh=fq3gtEHIcLd7HXxdoumkfNn7wCsgwbaboIjFFEN8UNM=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=iea0v6/tmgueV6mpcIDlpImmJ+D0hewWVzIW0WLHkDd5BefBZv6OFNWObpEOk+2Nf EjUisPAy8wsDmXAvAeNCFhv+b7KgpqKQQTdLPukLtRKOPlmukoEcxX/Mv5VHgmERPJ 5CndBFGpYjqzWN/Y5m7P0g3bPcDBuB/viVHKIoTY= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 25 Jun 2013 07:17:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9CEDC16005A; Tue, 25 Jun 2013 07:18:52 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id xLLPJ0W-k_Ga; Tue, 25 Jun 2013 07:18:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id EF5F5160088; Tue, 25 Jun 2013 07:18:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ILFMDFfY79Eu; Tue, 25 Jun 2013 07:18:51 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id 8523716005A; Tue, 25 Jun 2013 07:18:51 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 4646A363CD3F; Tue, 25 Jun 2013 17:17:40 +1000 (EST) To: Randy Bush From: Mark Andrews References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt In-reply-to: Your message of "Tue, 25 Jun 2013 11:44:07 +0900." Date: Tue, 25 Jun 2013 17:17:40 +1000 Message-Id: <20130625071740.4646A363CD3F@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Arturo Servin , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 07:17:57 -0000 In message , Randy Bush writes: > > If it's a statement of fact, it shouldn't use RFC 2119 language. It > > should simply state the truth: "Network operators might filter IPv6 > > fragments." > > s/might/do/ Which would be a totally mis-leading statement. "Some network operators filter IPv6 fragments." -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Tue Jun 25 01:09:50 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2513521F9FCB for ; Tue, 25 Jun 2013 01:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVjbrEJeTxGt for ; Tue, 25 Jun 2013 01:09:45 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id CEA1421F9FE2 for ; Tue, 25 Jun 2013 01:09:40 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 28F3EC9425; Tue, 25 Jun 2013 08:09:25 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372147772; bh=9Z06KAi1ZuUv02edF5cHp9SF8yC197vPkDzCE0IUGpg=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=rpC9/YKMmZAv50LEvVXb5c+CfNQ97ln9g7iR5o4vHntw3kRO/58W5OPo1tDJ/58wd zCQktbO2pKDP9ryKrBCALv4aY+U7Cl4kxl18KeLTOeZkY9QhLuXctKTTSQtemfJdSR yObQW6QSp2t5xcenjDhOjuwg3QulVZ4u8bLwVTWw= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 25 Jun 2013 08:09:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 284DA16005A; Tue, 25 Jun 2013 08:10:32 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id bW0IZGmRQHhF; Tue, 25 Jun 2013 08:10:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8E70F160089; Tue, 25 Jun 2013 08:10:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id oGELJ8JZYm3P; Tue, 25 Jun 2013 08:10:31 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id D7BCC16005A; Tue, 25 Jun 2013 08:10:30 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 760E0363D4A9; Tue, 25 Jun 2013 18:09:20 +1000 (EST) To: Geoff Huston From: Mark Andrews References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625015317.6B256363BD8F@drugs.dv.isc.org> <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.prod.outlook.com> Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt In-reply-to: Your message of "Tue, 25 Jun 2013 17:15:49 +1000." Date: Tue, 25 Jun 2013 18:09:20 +1000 Message-Id: <20130625080920.760E0363D4A9@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 08:09:50 -0000 In message , Geoff Huston write s: > Hi, > > We _are_ seeing IPv6 packet fragmentation in TCP over IPv6, and the = > causes are systematic, rather than random chance. > > What is happening is that the client is behind some form of tunnel = > (MPLS) we _assume_. The server (FreeBSD recent version) is sitting with = > a MTU of 1500, as is the client. > > The client opens 5 ports in parallel (possibly firefox???) The client = > makes a request down port 1, then, a little later, makes another request = > down port 2. The server sends large packets down the TCP session open to = > port 1. A gateway on the path sends back an ICMP6 packet too big to the = > server for this TCP session, with a new MTU of 1492. The TCP session on = > port 1 now adjust its MSS to 1432 (=3D1492 - 60) and the server resends = > its set of data as a sequence of packets each of which is 1492 octets in = > size - all good, no fragmentation of TCP packets so far. > > But then, on the session open to the client's port 2 the server = > assembles its set of packets for the second request to send to the = > client. The TCP session on the server which is bound to port 2 of the = > client is unaware of the MTU change (after all, the ICMP6 PTB message = > was directed to the TCP session that is bound to client port 1, not port = > 2), and the server's IPv6 driver gets a set of 1440 octet TCP payload = > packets to send to the client. But there is a data structure in the = > server (I think FreeBSD uses the routing table, but the FreeBSD folk = > probably know better than I do which internal table is used to cache = > path MTU data derived from ICMPv6 PTB messages) which says that for this = > IPv6 destination address the new MTU is not 1500, but is 1492. The IPv6 = > output driver now fragments the queued TCP packets to session connected = > to the client port 2 to send 2 packets for each single packet passed to = > it from the upper level TCP driver, and what heads onto the wire is a = > 1420 octet payload and a 20 octet payload, with IPv6 fragmentation set = > to bind them together. > > As far as I can see this is not "bad" behaviour. The second session has = > not received it own ICMP6 packet too big, so this TCP session (and all = > other parallel TCP sessions) are unaware of the need to drop its MSS, = > and because of the cached per host entry with the new MTU the IP driver = > is aware that it cannot send these packets out without fragmentation. So = > the IP layer is aware of this lower path MTU and correctly fragments the = > TCP packet to ensure delivery. I don't believe this is a bug per se. I = > think its an unintended side effect of the way in which ICMP6 PTB = > messages are processed by the recipient. > > How prevalent is this behaviour? > > Well, how prevalent are browsers that open up parallel ports to the same = > destination? > > Gee, with today's browsers just about everyone does this! > > If you want to deprecate IPv6 fragmentation and still allow this form of = > parallel session behaviour to work rather than wedge, then the internal = > handling of ICMPv6 PTB messages in the host needs to be reworked as far = > as I can tell. > > thanks, > > Geoff Which probably is some of the cause of some of the fragements I am seeing. I went looking for just such behaviour on pages I normally visit and saw the above behaviour. Note this on only on the initial page load. On reload no fragmentation is seen which is to be expected. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From bob.hinden@gmail.com Tue Jun 25 01:38:33 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01C821F9ED0 for ; Tue, 25 Jun 2013 01:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WH53shdmUaI5 for ; Tue, 25 Jun 2013 01:38:33 -0700 (PDT) Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id BF9B021F8887 for ; Tue, 25 Jun 2013 01:38:28 -0700 (PDT) Received: by mail-ea0-f179.google.com with SMTP id b15so6639200eae.24 for ; Tue, 25 Jun 2013 01:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=8TFpQvr5OjBz3L3NnhoBk1YawiLy3zuzx2xbcTx3FII=; b=FMcMBi5CTDNjmNq0Kzi71SHXOFDZf2sYMHoLD5IxQhC44cIWr3VJcAfCKI8qAtF/1C ex3LsrqC+jKfRaotARR/1zx8aaNlj5+dkPrLZat9x+k3OfgKKP1V8Az3MYf1SVmO2OY3 IRNoXh6JzzOQSuA+9gs+kJ6irCYzghl6fN8BKZJfFp+MRZRP5IcyzsRadvMApoMSk7SI u3mRcu3i+lhRM5ArZYhuGcszNH1SxR+KPDtKdPS1Z6CHdCqBvp3kUe+BVxgcYY+qpSXD hxdZLj8MKpRv10mxkE2pYXslDXUDtFVSgN2ZqWLhWRFPeMQmswByzoCDNXYfLHD5bYsK ulJA== X-Received: by 10.14.3.73 with SMTP id 49mr28544075eeg.72.1372149507909; Tue, 25 Jun 2013 01:38:27 -0700 (PDT) Received: from [172.24.251.79] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id l42sm34200135eeo.14.2013.06.25.01.38.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Jun 2013 01:38:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt From: Bob Hinden In-Reply-To: Date: Tue, 25 Jun 2013 11:38:23 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625015317.6B256363BD8F@drugs.dv.isc.org> <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.prod.outlook.com> To: Geoff Huston X-Mailer: Apple Mail (2.1508) Cc: Bob Hinden , Mark Andrews , "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 08:38:33 -0000 Geoff, > If you want to deprecate IPv6 fragmentation and still allow this form = of parallel session behaviour to work rather than wedge, then the = internal handling of ICMPv6 PTB messages in the host needs to be = reworked as far as I can tell. >=20 I think it would be good to fix this even if we don't deprecate IPv6 = fragmentation. Bob From gdt@gdt.id.au Tue Jun 25 03:17:32 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C78A21F9EF5 for ; Tue, 25 Jun 2013 03:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8SYMxeHgEMt for ; Tue, 25 Jun 2013 03:17:32 -0700 (PDT) Received: from neotokyo.gdt.id.au (neotokyo.adelaide.aarnet.edu.au [IPv6:2001:388:4000:4001:ba27:ebff:fed3:9fa1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B8021E808C for ; Tue, 25 Jun 2013 03:17:27 -0700 (PDT) Received: from 2001-44b8-01d2-bb00-3026-e09e-aedb-5a3d.static.ipv6.internode.on.net (2001-44b8-01d2-bb00-3026-e09e-aedb-5a3d.static.ipv6.internode.on.net [IPv6:2001:44b8:1d2:bb00:3026:e09e:aedb:5a3d]) by neotokyo.gdt.id.au (Postfix) with ESMTPSA id E5EE032A076A; Tue, 25 Jun 2013 19:47:21 +0930 (CST) Date: Tue, 25 Jun 2013 19:47:13 +0930 (CST) From: Glen Turner To: Bob Hinden Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt In-Reply-To: Message-ID: References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625015317.6B256363BD8F@drugs.dv.isc.org> <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.prod.outlook.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.97.8 at neotokyo X-Virus-Status: Clean Cc: "ipv6@ietf.org 6man-wg" , Geoff Huston , Mark Andrews X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 10:17:32 -0000 On Tue, 25 Jun 2013, Bob Hinden wrote: > I think it would be good to fix this even if we don't deprecate IPv6 fragmentation. What's this look like on the API side? You pass in a packet. Does the socket block because there may a packet in parallel (and how does the mechanism under the API know that)? Is that better or worse than fragmentation? I think that FreeBSD has done the reasonable thing. Given that the API has accepted the packet it is transmitting it using the most recent information about the path, rather than transmitting it with high odds of failure. -- Glen Turner From gih@apnic.net Tue Jun 25 03:44:24 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6309421F9F80 for ; Tue, 25 Jun 2013 03:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.21 X-Spam-Level: X-Spam-Status: No, score=-99.21 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jmfuii9YVduw for ; Tue, 25 Jun 2013 03:44:18 -0700 (PDT) Received: from so-mailgw.apnic.net (so-mailgw.apnic.net [IPv6:2001:dd8:a:3::230]) by ietfa.amsl.com (Postfix) with SMTP id 0A42A21F9C6E for ; Tue, 25 Jun 2013 03:44:17 -0700 (PDT) Received: from NXMDA1.org.apnic.net (unknown [203.119.93.247]) by so-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Tue, 25 Jun 2013 20:44:10 +1000 (EST) Received: from IAMDA2.org.apnic.net (2001:dd8:a:852::21) by NXMDA1.org.apnic.net (2001:dd8:9:802::11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 25 Jun 2013 20:44:11 +1000 Received: from [192.168.1.7] (203.119.101.249) by IAMDA2.org.apnic.net (203.119.111.21) with Microsoft SMTP Server (TLS) id 14.1.438.0; Tue, 25 Jun 2013 20:44:10 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt From: Geoff Huston In-Reply-To: Date: Tue, 25 Jun 2013 20:44:09 +1000 Content-Transfer-Encoding: quoted-printable Message-ID: <4979E44C-B449-4B06-9293-C6F03FA9C87B@apnic.net> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625015317.6B256363BD8F@drugs.dv.isc.org> <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.prod.outlook.com> To: Glen Turner X-Mailer: Apple Mail (2.1508) Cc: "ipv6@ietf.org 6man-wg" , Bob Hinden , Mark Andrews X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 10:44:24 -0000 On 25/06/2013, at 8:17 PM, Glen Turner wrote: > On Tue, 25 Jun 2013, Bob Hinden wrote: >> I think it would be good to fix this even if we don't deprecate IPv6 = fragmentation. >=20 > What's this look like on the API side? You pass in a packet. Does the > socket block because there may a packet in parallel (and how does > the mechanism under the API know that)? Is that better or worse > than fragmentation? >=20 > I think that FreeBSD has done the reasonable thing. Given that the API > has accepted the packet it is transmitting it using the most recent > information about the path, rather than transmitting it with high > odds of failure. I also believe that FreeBSD has done the best it can, and reasonably so. = It is debatable whether a ICMP6 PTB message should apply to all currently open TCP sessions to = the same destination, as I wonder about multi-path TCP and path diversity here. Geoff =20= From tore@fud.no Tue Jun 25 04:37:45 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C4F21F9DE3 for ; Tue, 25 Jun 2013 04:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXiTUOesKJK3 for ; Tue, 25 Jun 2013 04:37:44 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id C517B21F9CBB for ; Tue, 25 Jun 2013 04:37:44 -0700 (PDT) Received: from [2a02:fe0:cf16:20:21d:60ff:fe48:f59e] (port=34044 helo=wrath.fud.no) by greed.fud.no with esmtpa (Exim 4.80) (envelope-from ) id 1UrRZ6-0007lL-3s; Tue, 25 Jun 2013 13:37:40 +0200 Message-ID: <51C98103.4050008@fud.no> Date: Tue, 25 Jun 2013 13:37:39 +0200 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: George Michaelson Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625015317.6B256363BD8F@drugs.dv.isc.org> <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625040207.1CCA7363C42A@drugs.dv.isc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "ipv6@ietf.org 6man-wg" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 11:37:45 -0000 * George Michaelson > One thing I *strongly* agree with: the sentence at 2.2: > > The effective MTU for IPv6 is 1280 bytes. > > This is looking compellingly awful, but true to me. I believe this is a gross exaggeration. I'm running 1500 bytes MTU on all the clients and servers in my network, and have yet to hear about significant trouble (there have been a few, but no more than what I get with IPv4 as well). So to see if this was only me, I tried to do a simple" wget -6" of all the URLs listed in the top 100 sites sorted by Alexa rank at http://www.worldipv6launch.org/participants/?q=1 and looked at what TCP MSS values I got back: TCP MSS Count --------------- 1212 2 1220 6 1380 6 1410 3 1416 1 1420 1 1436 1 1440 67 1460 1 Total 88 Only 9% were operating on the premise that «the effective MTU for IPv6 is [<=] 1280 bytes», while a clear majority of 77% were operating with an MTU of [>=] 1500. (I did not get exactly 100 successful TCP handshakes because some URLs were down, some did not have an IPv6 address published in DNS, while on the other hand some were giving me HTTP redirects, which results in multiple handshakes.) Tore From john@jlc.net Tue Jun 25 05:55:48 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB5021F9F80 for ; Tue, 25 Jun 2013 05:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.614 X-Spam-Level: X-Spam-Status: No, score=-105.614 tagged_above=-999 required=5 tests=[AWL=0.985, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kWEPgNol4QE for ; Tue, 25 Jun 2013 05:55:43 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id D865B21F9302 for ; Tue, 25 Jun 2013 05:55:32 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 3D35E33C22; Tue, 25 Jun 2013 08:55:32 -0400 (EDT) Date: Tue, 25 Jun 2013 08:55:32 -0400 From: John Leslie To: Brian E Carpenter Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Message-ID: <20130625125532.GE50067@verdi> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51C902DC.9000408@gmail.com> User-Agent: Mutt/1.4.1i Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 12:55:49 -0000 Brian E Carpenter wrote: > > If it's a statement of fact, it shouldn't use RFC 2119 language. It > should simply state the truth: "Network operators might filter IPv6 > fragments." +1 -- John Leslie From ietf@rozanak.com Tue Jun 25 08:27:34 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE8021F9DE3 for ; Tue, 25 Jun 2013 08:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMU1ji-fyhMZ for ; Tue, 25 Jun 2013 08:27:30 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id EB0DB21F99BC for ; Tue, 25 Jun 2013 08:27:29 -0700 (PDT) Received: from kopoli ([141.89.226.146]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0LoFOr-1UK5Cd3t3R-00gLCR; Tue, 25 Jun 2013 11:27:24 -0400 From: "Hosnieh Rafiee" To: Subject: New version: I-D: draft-rafiee-6man-ra-privacy Date: Tue, 25 Jun 2013 17:27:17 +0200 Message-ID: <000001ce71b8$7ce88f20$76b9ad60$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01CE71C9.4071D450" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5xuGldGjTImSyTTO+vtGSyuAvDlQ== Content-Language: en-us X-Provags-ID: V02:K0:JeJCcolFLp0Al77x6ImVy0kGzREGWJTBi3BmaPGgYF1 IMFhgK/CUHzdMOWNe9Zvjp0k+liokdCWKCotfv8HexStcLmo0Z s0d+Z3l483MPbV9t3KRaG1w65aIB62qDEft6V7kOASGIpQZQml EMsV8Q1Jny20FP/GJ6G6FxJFUVxoB75eA9TekpZp/ZLBnXi6av o6gzpzPjvsGOvDRNG70Y+38YL0GfqmOApHsdwvr91df/xDBcRr njCpRmIV/L91ov9wYvdiaZ7PQUhCvxZy2LRvxzfiqNE21sDc40 +zYAaVswaBPITXMW6mcFwZAmVrBqQeQGItbx18dNuZ+iD81hRN Xmzhz1PvrQnkoPIkVkbM= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 15:27:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01CE71C9.4071D450 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0002_01CE71C9.4071D450" ------=_NextPart_001_0002_01CE71C9.4071D450 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello, Has anybody had a chance to review it? http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy thank you, Regards, Hosnieh ------=_NextPart_001_0002_01CE71C9.4071D450 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

    Hello,

     

    Has anybody had a chance = to review it?

    http://t= ools.ietf.org/html/draft-rafiee-6man-ra-privacy

     

    thank = you,

    Regards,

    Hosnieh

     

    ------=_NextPart_001_0002_01CE71C9.4071D450-- ------=_NextPart_000_0001_01CE71C9.4071D450 Content-Type: text/plain; name="Untitled attachment 00015.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Untitled attachment 00015.txt" -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ------=_NextPart_000_0001_01CE71C9.4071D450-- From Fred.L.Templin@boeing.com Tue Jun 25 09:30:07 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A04211E811E for ; Tue, 25 Jun 2013 09:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TicsXFOCZXo for ; Tue, 25 Jun 2013 09:30:00 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id CDF2111E8124 for ; Tue, 25 Jun 2013 09:27:59 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r5PGScqD024131 for ; Tue, 25 Jun 2013 09:28:38 -0700 Received: from XCH-PHX-209.sw.nos.boeing.com (xch-phx-209.sw.nos.boeing.com [130.247.25.29]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r5PGScgg024123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Tue, 25 Jun 2013 09:28:38 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-PHX-209.sw.nos.boeing.com ([169.254.9.94]) with mapi id 14.02.0328.011; Tue, 25 Jun 2013 09:27:57 -0700 From: "Templin, Fred L" To: "ipv6@ietf.org" Subject: RE: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHOcaNWnIqWz28/U0KHjOMXVL4EuplGmyqg Date: Tue, 25 Jun 2013 16:27:57 +0000 Message-ID: <2134F8430051B64F815C691A62D983180AA470@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <20130625125532.GE50067@verdi> In-Reply-To: <20130625125532.GE50067@verdi> 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 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 16:30:07 -0000 Hi, I just wanted to put out one thought. When talking about fragmentation and reassembly, never say "always" and never say "never". It is true that some routers are not well positioned to perform steady-state fragmentation and reassembly but that does not mean that it should "never" be used for any purposes. "Fragmentation Considered Harmful" was a seminal work, but it fell into the trap of making black-and-white statements about fragmentation and reassembly that do not "always" hold in *all* contexts. IP provides: 1) routing, 2) addressing, 3) a best-effort delivery model, and 4) a fragmentation and reassembly capability. Omitting 4) would leave us with something other than IP. Thanks - Fred=20 From huitema@microsoft.com Tue Jun 25 09:37:10 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA1E21E8093 for ; Tue, 25 Jun 2013 09:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mh+yBE8cvsax for ; Tue, 25 Jun 2013 09:37:04 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) by ietfa.amsl.com (Postfix) with ESMTP id E57FE11E80FB for ; Tue, 25 Jun 2013 09:37:03 -0700 (PDT) Received: from BL2FFO11FD028.protection.gbl (10.173.161.203) by BL2FFO11HUB016.protection.gbl (10.173.160.108) with Microsoft SMTP Server (TLS) id 15.0.707.0; Tue, 25 Jun 2013 16:37:02 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD028.mail.protection.outlook.com (10.173.161.107) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Tue, 25 Jun 2013 16:37:02 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.49]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0136.001; Tue, 25 Jun 2013 16:36:51 +0000 From: Christian Huitema To: Geoff Huston , Glen Turner Subject: RE: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHOcUbCkXlYZ7OiLECYiDOPCwZ7E5lFsyKAgABR84CAABcSgIAAG52AgAAHhoCAAGISYA== Date: Tue, 25 Jun 2013 16:36:51 +0000 Message-ID: References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625015317.6B256363BD8F@drugs.dv.isc.org> <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.prod.outlook.com> <4979E44C-B449-4B06-9293-C6F03FA9C87B@apnic.net> In-Reply-To: <4979E44C-B449-4B06-9293-C6F03FA9C87B@apnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(49866001)(46406003)(77096001)(76482001)(31966008)(54356001)(76796001)(33656001)(76786001)(56776001)(53806001)(74706001)(74876001)(69226001)(59766001)(77982001)(81342001)(50466002)(44976004)(66066001)(54316002)(81542001)(51856001)(47736001)(50986001)(56816003)(47976001)(46102001)(47446002)(16406001)(6806003)(47776003)(74662001)(20776003)(74502001)(80022001)(74366001)(23726002)(4396001)(55846006)(79102001)(65816001)(63696002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB016; H:TK5EX14HUBC105.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0888B1D284 Cc: Bob Hinden , "ipv6@ietf.org 6man-wg" , Mark Andrews X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 16:37:10 -0000 > I also believe that FreeBSD has done the best it can, and reasonably so. = It is debatable whether a ICMP6 PTB message should apply to all currently o= pen TCP sessions to the same destination, as I wonder about multi-path TCP = and path diversity here. There are certainly different ways to implement that, without inserting a f= ragmentation header. For example, if the lower layer knows that the packet = is too big, it could send the local equivalent of "ICMP too big" back to th= e TCP layer. -- Christian Huitema From warren@kumari.net Tue Jun 25 11:21:13 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6372D21F9E45 for ; Tue, 25 Jun 2013 11:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJo1N-+nMYp2 for ; Tue, 25 Jun 2013 11:21:06 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846AB21F99D0 for ; Tue, 25 Jun 2013 11:21:02 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.90]) by vimes.kumari.net (Postfix) with ESMTPSA id 82BBB1B40088; Tue, 25 Jun 2013 14:21:00 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [6MAN] New Version Notification for draft-bonica-6man-frag-deprecate-00.txt From: Warren Kumari In-Reply-To: <51C902DC.9000408@gmail.com> Date: Tue, 25 Jun 2013 14:20:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6F17495B-F145-4D50-8053-3396F5A17821@kumari.net> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1508) Cc: Arturo Servin , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 18:21:13 -0000 On Jun 24, 2013, at 10:39 PM, Brian E Carpenter = wrote: > On 25/06/2013 10:11, Ronald Bonica wrote: >>> "New IPv6 host implementations MAY support IPv6 fragmentation and >>> reassembly" >>> break things. "New IPv6 host implementations MAY support IPv6 >>> fragmentation but MUST support reassembly" may superior. This will >>> aging out fragmentation over a longer period, new hosts will not use = it >>> but existing - applications will not break. >>=20 >> I could live with this. Would it satisfy other folks' objections? >=20 > I think it's far too soon in developing the analysis to be able > to answer that question. This isn't cooked yet. >=20 >>=20 >>> "Network operators MAY filter IPv6 fragments." is a policy thing and >>> costumers have to deal with that already. So it is ok from my point = of >>> view. >>=20 >> Ack. It is a statement of fact, not an IETF imposed requirement. >=20 > If it's a statement of fact, it shouldn't use RFC 2119 language. It > should simply state the truth: "Network operators might filter IPv6 = fragments." You mean like http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-01 = says? "This memo provides observational evidence for the dropping of IPv6 fragments along a significant number of paths, explores the operational impact of fragmentation and the reasons and scenarios where drops occur, and considers the effect of fragment drops on applications where fragmentation is known to occur, particularly including DNS." It references: = http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis= .pdf (also a fun read). W >=20 > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -- "Let's just say that if complete and utter chaos was lightning, he'd be = the sort to stand on a hilltop in a thunderstorm wearing wet copper = armour and shouting 'All gods are bastards'." -- Rincewind discussing Twoflower (Terry Pratchett, The Colour of = Magic) From otroan@employees.org Tue Jun 25 11:56:53 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453CB21F9C0C for ; Tue, 25 Jun 2013 11:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+bBunr1VRaF for ; Tue, 25 Jun 2013 11:56:47 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 23E3721F9A4B for ; Tue, 25 Jun 2013 11:56:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAK7myVGQ/khM/2dsb2JhbABagwnAMoEGFnSCIwEBAQMBOj0CEAtGVwaIGwa7Eo9FB4MCYQOpB4MsIA X-IronPort-AV: E=Sophos;i="4.87,938,1363132800"; d="scan'208";a="14986801" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 25 Jun 2013 18:56:45 +0000 Received: from dhcp-10-61-110-64.cisco.com (dhcp-10-61-110-64.cisco.com [10.61.110.64]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5PIudMN021238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Jun 2013 18:56:42 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt From: Ole Troan In-Reply-To: Date: Tue, 25 Jun 2013 14:56:37 -0400 Content-Transfer-Encoding: 7bit Message-Id: <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> To: Randy Bush X-Mailer: Apple Mail (2.1508) Cc: Arturo Servin , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 18:56:53 -0000 Randy, >> If it's a statement of fact, it shouldn't use RFC 2119 language. It >> should simply state the truth: "Network operators might filter IPv6 >> fragments." > > s/might/do/ would you be able to answer why and where? cheers, Ole From bjones@vt.edu Tue Jun 25 09:43:10 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACC511E8112 for ; Tue, 25 Jun 2013 09:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jo5MoWBOEm23 for ; Tue, 25 Jun 2013 09:43:06 -0700 (PDT) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by ietfa.amsl.com (Postfix) with ESMTP id F23D311E80FB for ; Tue, 25 Jun 2013 09:43:05 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id r5PGgYAP027754 for ; Tue, 25 Jun 2013 12:42:34 -0400 Received: by mail-qc0-f171.google.com with SMTP id n1so7339665qcw.2 for ; Tue, 25 Jun 2013 09:42:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=jBpkbv0zVuBbNIh+LCGAL+RmLIKHOFWeg9LJmleuzKM=; b=YrWPMxSEWewMt4G0JhmOnhXCwgYn7R1GUhi1sIcFm4zQ+otVMsclqfq1SFnb5QeNBq 9dxa06plmUGlGhBUjvFeoHCyiskFf9NH/5Iz+jdpHx2T1z72i4Mfgn6Y/Uxu0WVYLffT O6sxB7dcUMn6VuIBquIkQQezThwcqGjUL58WCsA0jrP3SS4jDeNjG92tdQ0GCH7rywR2 WBOlXmOmMuOlle+lKNR4IKki6pitMTRvQJxruclY2HyBD/mfdyeM397rR0IHUwZHj0xY sn/O9OnPFFKvpR3KGZyQ/OZcWnRMj5KPOz7DSpWPVmJU0RDG75g9DWPtSHUfh141SvWC Mvig== X-Received: by 10.49.35.180 with SMTP id i20mr33767698qej.61.1372178554658; Tue, 25 Jun 2013 09:42:34 -0700 (PDT) X-Received: by 10.49.35.180 with SMTP id i20mr33767690qej.61.1372178554582; Tue, 25 Jun 2013 09:42:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.253.5 with HTTP; Tue, 25 Jun 2013 09:42:13 -0700 (PDT) In-Reply-To: <2134F8430051B64F815C691A62D983180AA470@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <20130625125532.GE50067@verdi> <2134F8430051B64F815C691A62D983180AA470@XCH-BLV-504.nw.nos.boeing.com> From: Brian Jones Date: Tue, 25 Jun 2013 12:42:13 -0400 Message-ID: Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt To: "Templin, Fred L" Content-Type: multipart/alternative; boundary=047d7b67878c508a0104dffd3773 X-Gm-Message-State: ALoCoQklFS9Zvi6jcrBVJjwfSQelikaKozkZQjdJeQuGYNc9dNZ3MN0w804JwUep5hotsGCJaY0w7VwcmZOYropnq1laWirMSiCc962ONSNBsbLT22WrXtUE7XJO20PBWV+8KiHtqKWd Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 19:11:03 -0000 --047d7b67878c508a0104dffd3773 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 25, 2013 at 12:27 PM, Templin, Fred L wrote: > Hi, > > I just wanted to put out one thought. When talking about fragmentation > and reassembly, never say "always" and never say "never". It is true > that some routers are not well positioned to perform steady-state > fragmentation and reassembly but that does not mean that it should > "never" be used for any purposes. > > "Fragmentation Considered Harmful" was a seminal work, but it fell into > the trap of making black-and-white statements about fragmentation and > reassembly that do not "always" hold in *all* contexts. IP provides: > 1) routing, 2) addressing, 3) a best-effort delivery model, and 4) a > fragmentation and reassembly capability. Omitting 4) would leave us > with something other than IP. > +1 > > Thanks - Fred > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --047d7b67878c508a0104dffd3773 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

    On Tue, Jun 25, 2013 at 12:= 27 PM, Templin, Fred L <Fred.L.Templin@boeing.com> w= rote:
    Hi,

    I just wanted to put out one thought. When talking about fragmentation
    and reassembly, never say "always" and never say "never"= ;. It is true
    that some routers are not well positioned to perform steady-state
    fragmentation and reassembly but that does not mean that it should
    "never" be used for any purposes.

    "Fragmentation Considered Harmful" was a seminal work, but it fel= l into
    the trap of making black-and-white statements about fragmentation and
    reassembly that do not "always" hold in *all* contexts. IP provid= es:
    1) routing, 2) addressing, 3) a best-effort delivery model, and 4) a
    fragmentation and reassembly capability. Omitting 4) would leave us
    with something other than IP.

    +1
    =C2=A0
    <= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
    Thanks - Fred
    -----------------------------------= ---------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------

    --047d7b67878c508a0104dffd3773-- From randy@psg.com Tue Jun 25 12:42:18 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A80D21E80CE for ; Tue, 25 Jun 2013 12:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwbPZB8ZElv3 for ; Tue, 25 Jun 2013 12:42:18 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id DF2A021E80D4 for ; Tue, 25 Jun 2013 12:42:14 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UrZ81-000GZ7-Lz; Tue, 25 Jun 2013 19:42:13 +0000 Date: Wed, 26 Jun 2013 04:42:12 +0900 Message-ID: From: Randy Bush To: Ole Troan Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt In-Reply-To: <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 19:42:18 -0000 >>> If it's a statement of fact, it shouldn't use RFC 2119 language. It >>> should simply state the truth: "Network operators might filter IPv6 >>> fragments." >> s/might/do/ > would you be able to answer why and where? perceived, rightly or wrongly, as an attack vector. they do similarly for v4. often at enterprise borders (hell, they filter 53/tcp), and occasionally inter-isp. in reality, you can not count on pmtud working, and don't bet your buns on frags getting through. randy From otroan@employees.org Tue Jun 25 13:03:54 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B2521E80E1 for ; Tue, 25 Jun 2013 13:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Va9tDw8IzstA for ; Tue, 25 Jun 2013 13:03:49 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B87A221E80DE for ; Tue, 25 Jun 2013 13:03:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAEz3yVGQ/khR/2dsb2JhbABagwnAMoEGFnSCIwEBAQMBOj0CBQsLRlcGiBsGumaPEjMHgwJhA6kHgywg X-IronPort-AV: E=Sophos;i="4.87,939,1363132800"; d="scan'208";a="155756228" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 25 Jun 2013 20:03:47 +0000 Received: from dhcp-10-61-110-64.cisco.com (dhcp-10-61-110-64.cisco.com [10.61.110.64]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5PK3ftC028140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Jun 2013 20:03:45 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt From: Ole Troan In-Reply-To: Date: Tue, 25 Jun 2013 16:03:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> To: Randy Bush X-Mailer: Apple Mail (2.1508) Cc: IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 20:03:54 -0000 Randy, >>>> If it's a statement of fact, it shouldn't use RFC 2119 language. It >>>> should simply state the truth: "Network operators might filter IPv6 >>>> fragments." >>> s/might/do/ >> would you be able to answer why and where? >=20 > perceived, rightly or wrongly, as an attack vector. they do similarly > for v4. often at enterprise borders (hell, they filter 53/tcp), and > occasionally inter-isp. I'm aware of the Enterprise borders, I was a bit more surprised at the = inter ISP filtering. with my user hat on, I'm not paying my ISP to drop my packets. ;-) I understand why an ISP would filter ISPs towards its own = infrastructure, but what would be the reasoning for filtering fragments that it = transits? > in reality, you can not count on pmtud working, and don't bet your = buns > on frags getting through. right, so something has to change. if that's in-band MTU discovery for = all L4 protocols, or if it is something else I don't know. cheers, Ole= From randy@psg.com Tue Jun 25 13:14:12 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5364721E809F for ; Tue, 25 Jun 2013 13:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7e+kd7qPrB4 for ; Tue, 25 Jun 2013 13:14:11 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id DE24211E813A for ; Tue, 25 Jun 2013 13:13:59 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UrZch-000Ggc-SP; Tue, 25 Jun 2013 20:13:55 +0000 Date: Wed, 26 Jun 2013 05:13:54 +0900 Message-ID: From: Randy Bush To: Ole Troan Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt In-Reply-To: <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 20:14:12 -0000 > with my user hat on, I'm not paying my ISP to drop my packets. ;-) then you don't believe in qos, eh? 's ok. neither do i. :) > I understand why an ISP would filter ISPs towards its own > infrastructure, but what would be the reasoning for filtering > fragments that it transits? reasoning? you want reasoning? stay away from ops. >> in reality, you can not count on pmtud working, and don't bet your buns >> on frags getting through. > right, so something has to change. if that's in-band MTU discovery for > all L4 protocols, or if it is something else I don't know. ron has made one suggestion. though brutal, its simplicity and its recognition of reality appeal to me. randy From alh-ietf@tndh.net Tue Jun 25 13:35:37 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B0621F8934 for ; Tue, 25 Jun 2013 13:35:37 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ...that system for details.\n \n Content previ[...] X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSyqmoSi7Qcq for ; Tue, 25 Jun 2013 13:35:36 -0700 (PDT) Received: from express.tndh.net (express.tndh.net [IPv6:2001:470:e930:1240:20d:56ff:fe04:4c0a]) by ietfa.amsl.com (Postfix) with ESMTP id 83E4521F861F for ; Tue, 25 Jun 2013 13:35:36 -0700 (PDT) Received: from express.tndh.local ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1UrZxK-000761-Gc; Tue, 25 Jun 2013 13:35:20 -0700 From: "Tony Hain" To: "'Tore Anderson'" , "'George Michaelson'" References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625015317.6B256363BD8F@drugs.dv.isc.org> <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625040207.1CCA7363C42A@drugs.dv.isc.org> <51C98103.4050008@fud.no> In-Reply-To: <51C98103.4050008@fud.no> Subject: RE: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Date: Tue, 25 Jun 2013 13:35:14 -0700 Message-ID: <010f01ce71e3$7f43aea0$7dcb0be0$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFPmzyGg3SBeEPNIeSj1WaAnqHbKQGRFuihAQgjLW0B2P4/0wGC2zy+AgQy54sC+zKFhgIGAa8jAZL3LQUBgMkG5gKeeubQma70KAA= Content-Language: en-us X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a X-SA-Exim-Mail-From: alh-ietf@tndh.net X-SA-Exim-Scanned: No (on express.tndh.net); SAEximRunCond expanded to false Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 20:35:37 -0000 Tore Anderson wrote: > * George Michaelson > > > One thing I *strongly* agree with: the sentence at 2.2: > > > > The effective MTU for IPv6 is 1280 bytes. > > > > This is looking compellingly awful, but true to me. > > I believe this is a gross exaggeration. I'm running 1500 bytes MTU on all the > clients and servers in my network, and have yet to hear about significant > trouble (there have been a few, but no more than what I get with IPv4 as > well). So what happens over the next 10 years as there is a mix of 1500 & 4k systems? Or over the next 100 as the sizes continue to vary and routes flap across an array of link sizes? Yes pmtud sorts out part of that, but does tcp or the app need to become more dynamic about MSS changes during a connection? Why? Just so people that want to use the hammer of 'no fragments' are happy? Wouldn't it be better for everyone to actually solve the only real problem, and simply require the L4 protocol be in the first fragment? Short sighted myopia about a seriously outdated frame size should not drive decisions about long term deployment of an emerging protocol. If the L4 is in the first fragment, there are no other problems that need solving. If reassembly resources are a challenge for boxes specifically designed to do that, question why; but one could go further and require that the only fragment allowed to be smaller than 1280 is the last fragment. That would mitigate most of the resource-consumption-crafting nonsense. Tony From marka@isc.org Tue Jun 25 14:30:44 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249D621F9A5E for ; Tue, 25 Jun 2013 14:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpm6h-hUri-4 for ; Tue, 25 Jun 2013 14:30:38 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id C92AA21F99DD for ; Tue, 25 Jun 2013 14:30:38 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 6C031C94BE; Tue, 25 Jun 2013 21:30:30 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372195838; bh=vfqJBirw5zAivuCWCqy6kyxg5JLRAtPZ8iUwTvbRBdQ=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Ip9wRmwozKny4lRls/IdN921q+NuPd3DiwC34i+3k9IIpLbmRTeBNVyYFbg49vWVz UFRgbpa+1qROsYr61TBEcnSgai0oZsaBO1+dxWGrKfGtLz1ekC59LcqRSZsXvDiM9t q57nVFwOfMAWfI4o7M9Px+tdhYlDYbRxXO44CshQ= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 25 Jun 2013 21:30:30 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D50D616008E; Tue, 25 Jun 2013 21:31:39 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id YBVJQErAZN34; Tue, 25 Jun 2013 21:31:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D306D16008D; Tue, 25 Jun 2013 21:31:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id y1Q7RANDvctq; Tue, 25 Jun 2013 21:31:35 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id 249FE16005A; Tue, 25 Jun 2013 21:31:34 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id AE99B36416E4; Wed, 26 Jun 2013 07:30:21 +1000 (EST) To: "Tony Hain" From: Mark Andrews References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625015317.6B256363BD8F@drugs.dv.isc.org> <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625040207.1CCA7363C42A@drugs.dv.isc.org> <51C98103.4050008@fud.no> <010f01ce71e3$7f43aea0$7dcb0be0$@tndh.net> Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt In-reply-to: Your message of "Tue, 25 Jun 2013 13:35:14 -0700." <010f01ce71e3$7f43aea0$7dcb0be0$@tndh.net> Date: Wed, 26 Jun 2013 07:30:21 +1000 Message-Id: <20130625213021.AE99B36416E4@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: 'Tore Anderson' , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 21:30:44 -0000 Just a sample of traffic which has next header != {icmp6,tcp,udp} from overnight. The machine was suspended for around 6 hours. Mark % tcpdump -n -i en1 'ip6[6]' "!=" 6 and 'ip6[6]' '!=' 58 and 'ip6[6]' "!=" 17 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on en1, link-type EN10MB (Ethernet), capture size 65535 bytes 17:52:49.861052 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 1957066089:1957067489, ack 2497112622, win 8211, options [nop,nop,TS val 1119549604 ecr 198228615], length 1400 17:52:49.861058 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:49.870759 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60720: Flags [.], seq 4097604338:4097605738, ack 3676482518, win 8211, options [nop,nop,TS val 3406672242 ecr 198228624], length 1400 17:52:49.870861 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:49.906115 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60722: Flags [.], seq 3561334378:3561335778, ack 2160043005, win 8211, options [nop,nop,TS val 1133407665 ecr 198228649], length 1400 17:52:49.906199 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.051608 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 2316478184:2316479584, ack 4079720301, win 8211, options [nop,nop,TS val 865809331 ecr 198228615], length 1400 17:52:50.051789 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.178615 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 1428:2828, ack 1, win 8211, options [nop,nop,TS val 1119549917 ecr 198228942], length 1400 17:52:50.178666 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.179830 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 2856:4256, ack 1, win 8211, options [nop,nop,TS val 1119549917 ecr 198228942], length 1400 17:52:50.179894 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.182340 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60720: Flags [.], seq 1428:2828, ack 1, win 8211, options [nop,nop,TS val 3406672548 ecr 198228942], length 1400 17:52:50.182406 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.182930 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60720: Flags [.], seq 2856:4256, ack 1, win 8211, options [nop,nop,TS val 3406672548 ecr 198228942], length 1400 17:52:50.183046 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.292666 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60722: Flags [.], seq 1428:2828, ack 1, win 8211, options [nop,nop,TS val 1133408049 ecr 198229040], length 1400 17:52:50.292729 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.293216 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60722: Flags [.], seq 2856:4256, ack 1, win 8211, options [nop,nop,TS val 1133408049 ecr 198229040], length 1400 17:52:50.293269 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.391938 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 4284:5684, ack 1, win 8211, options [nop,nop,TS val 1119550117 ecr 198229141], length 1400 17:52:50.391944 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.392463 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 5712:7112, ack 1, win 8211, options [nop,nop,TS val 1119550117 ecr 198229141], length 1400 17:52:50.392669 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.393168 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 7140:8540, ack 1, win 8211, options [nop,nop,TS val 1119550117 ecr 198229141], length 1400 17:52:50.393407 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.393994 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 8568:9968, ack 1, win 8211, options [nop,nop,TS val 1119550117 ecr 198229141], length 1400 17:52:50.394089 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.394688 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 1428:2828, ack 1, win 8211, options [nop,nop,TS val 865809667 ecr 198229139], length 1400 17:52:50.394697 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.395152 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 2856:4256, ack 1, win 8211, options [nop,nop,TS val 865809667 ecr 198229139], length 1400 17:52:50.395217 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.396701 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60720: Flags [.], seq 4284:5684, ack 1, win 8211, options [nop,nop,TS val 3406672750 ecr 198229143], length 1400 17:52:50.396800 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.397830 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60720: Flags [.], seq 5712:7112, ack 1, win 8211, options [nop,nop,TS val 3406672750 ecr 198229143], length 1400 17:52:50.397895 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.398402 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60720: Flags [.], seq 7140:8540, ack 1, win 8211, options [nop,nop,TS val 3406672750 ecr 198229143], length 1400 17:52:50.398459 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.399010 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60720: Flags [.], seq 8568:9968, ack 1, win 8211, options [nop,nop,TS val 3406672750 ecr 198229143], length 1400 17:52:50.399162 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.607636 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 9996:11396, ack 1, win 8211, options [nop,nop,TS val 1119550327 ecr 198229350], length 1400 17:52:50.609180 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.609505 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 11424:12824, ack 1, win 8211, options [nop,nop,TS val 1119550327 ecr 198229350], length 1400 17:52:50.609702 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.613027 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 12852:14252, ack 1, win 8211, options [nop,nop,TS val 1119550332 ecr 198229351], length 1400 17:52:50.613095 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.613889 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 14280:15680, ack 1, win 8211, options [nop,nop,TS val 1119550332 ecr 198229351], length 1400 17:52:50.614165 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.614665 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 15708:17108, ack 1, win 8211, options [nop,nop,TS val 1119550332 ecr 198229351], length 1400 17:52:50.614905 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.615212 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60721: Flags [.], seq 17136:18536, ack 1, win 8211, options [nop,nop,TS val 1119550332 ecr 198229351], length 1400 17:52:50.615455 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.629914 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 4284:5684, ack 1, win 8211, options [nop,nop,TS val 865809894 ecr 198229352], length 1400 17:52:50.630027 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.631168 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 5712:7112, ack 1, win 8211, options [nop,nop,TS val 865809894 ecr 198229352], length 1400 17:52:50.631369 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.632230 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 7140:8540, ack 1, win 8211, options [nop,nop,TS val 865809894 ecr 198229352], length 1400 17:52:50.632348 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.632882 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 8568:9968, ack 1, win 8211, options [nop,nop,TS val 865809894 ecr 198229352], length 1400 17:52:50.633135 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.864705 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 9996:11396, ack 1, win 8211, options [nop,nop,TS val 865810124 ecr 198229581], length 1400 17:52:50.864769 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.865965 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 11424:12824, ack 1, win 8211, options [nop,nop,TS val 865810124 ecr 198229581], length 1400 17:52:50.866235 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.883550 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 12852:14252, ack 1, win 8211, options [nop,nop,TS val 865810143 ecr 198229582], length 1400 17:52:50.883564 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.883934 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 14280:15680, ack 1, win 8211, options [nop,nop,TS val 865810143 ecr 198229582], length 1400 17:52:50.884125 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.884744 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 15708:17108, ack 1, win 8211, options [nop,nop,TS val 865810143 ecr 198229582], length 1400 17:52:50.884814 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.885494 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 17136:18536, ack 1, win 8211, options [nop,nop,TS val 865810143 ecr 198229582], length 1400 17:52:50.885725 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.886132 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 18564:19964, ack 1, win 8211, options [nop,nop,TS val 865810143 ecr 198229583], length 1400 17:52:50.886616 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:50.887054 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 19992:21392, ack 1, win 8211, options [nop,nop,TS val 865810143 ecr 198229583], length 1400 17:52:50.887241 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.089406 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 21420:22820, ack 1, win 8211, options [nop,nop,TS val 865810343 ecr 198229813], length 1400 17:52:51.089596 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.089992 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 22848:24248, ack 1, win 8211, options [nop,nop,TS val 865810343 ecr 198229813], length 1400 17:52:51.090124 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.090587 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 24276:25676, ack 1, win 8211, options [nop,nop,TS val 865810343 ecr 198229813], length 1400 17:52:51.090808 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.091491 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 25704:27104, ack 1, win 8211, options [nop,nop,TS val 865810343 ecr 198229813], length 1400 17:52:51.091815 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.107807 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 27132:28532, ack 1, win 8211, options [nop,nop,TS val 865810362 ecr 198229830], length 1400 17:52:51.108014 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.108389 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 28560:29960, ack 1, win 8211, options [nop,nop,TS val 865810362 ecr 198229830], length 1400 17:52:51.108589 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.112032 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 29988:31388, ack 1, win 8211, options [nop,nop,TS val 865810366 ecr 198229831], length 1400 17:52:51.112039 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.112734 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 31416:32816, ack 1, win 8211, options [nop,nop,TS val 865810366 ecr 198229831], length 1400 17:52:51.112739 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.113331 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 32844:34244, ack 1, win 8211, options [nop,nop,TS val 865810366 ecr 198229831], length 1400 17:52:51.113376 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.114068 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 34272:35672, ack 1, win 8211, options [nop,nop,TS val 865810366 ecr 198229831], length 1400 17:52:51.114239 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.118589 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 35700:37100, ack 1, win 8211, options [nop,nop,TS val 865810370 ecr 198229832], length 1400 17:52:51.118596 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.119116 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 37128:38528, ack 1, win 8211, options [nop,nop,TS val 865810370 ecr 198229832], length 1400 17:52:51.119235 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.123112 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 38556:39956, ack 1, win 8211, options [nop,nop,TS val 865810377 ecr 198229833], length 1400 17:52:51.123242 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.123762 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 39984:41384, ack 1, win 8211, options [nop,nop,TS val 865810377 ecr 198229833], length 1400 17:52:51.123890 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.124392 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 41412:42812, ack 1, win 8211, options [nop,nop,TS val 865810377 ecr 198229833], length 1400 17:52:51.124493 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.125236 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 42840:44240, ack 1, win 8211, options [nop,nop,TS val 865810377 ecr 198229833], length 1400 17:52:51.125349 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.309557 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 44268:45668, ack 1, win 8211, options [nop,nop,TS val 865810562 ecr 198230033], length 1400 17:52:51.309602 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.310071 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 45696:47096, ack 1, win 8211, options [nop,nop,TS val 865810562 ecr 198230033], length 1400 17:52:51.310128 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.313615 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 47124:48524, ack 1, win 8211, options [nop,nop,TS val 865810566 ecr 198230034], length 1400 17:52:51.313686 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.314433 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 48552:49952, ack 1, win 8211, options [nop,nop,TS val 865810566 ecr 198230034], length 1400 17:52:51.314516 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.315002 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 49980:51380, ack 1, win 8211, options [nop,nop,TS val 865810566 ecr 198230034], length 1400 17:52:51.315112 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.316023 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 51408:52808, ack 1, win 8211, options [nop,nop,TS val 865810566 ecr 198230034], length 1400 17:52:51.316082 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.320310 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 52836:54236, ack 1, win 8211, options [nop,nop,TS val 865810570 ecr 198230035], length 1400 17:52:51.320317 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.320745 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 54264:55664, ack 1, win 8211, options [nop,nop,TS val 865810570 ecr 198230035], length 1400 17:52:51.320894 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.327384 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 55692:57092, ack 1, win 8211, options [nop,nop,TS val 865810580 ecr 198230051], length 1400 17:52:51.327442 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.328138 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 57120:58520, ack 1, win 8211, options [nop,nop,TS val 865810580 ecr 198230051], length 1400 17:52:51.328197 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.328724 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 58548:59948, ack 1, win 8211, options [nop,nop,TS val 865810580 ecr 198230051], length 1400 17:52:51.328785 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.329732 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 59976:61376, ack 1, win 8211, options [nop,nop,TS val 865810580 ecr 198230051], length 1400 17:52:51.329738 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.331214 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 61404:62804, ack 1, win 8211, options [nop,nop,TS val 865810585 ecr 198230055], length 1400 17:52:51.331335 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.334647 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 62832:64232, ack 1, win 8211, options [nop,nop,TS val 865810585 ecr 198230055], length 1400 17:52:51.334699 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.336451 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 64260:65660, ack 1, win 8211, options [nop,nop,TS val 865810590 ecr 198230056], length 1400 17:52:51.336511 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.337829 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 65688:67088, ack 1, win 8211, options [nop,nop,TS val 865810590 ecr 198230056], length 1400 17:52:51.338001 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.338441 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 67116:68516, ack 1, win 8211, options [nop,nop,TS val 865810590 ecr 198230056], length 1400 17:52:51.338630 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.339011 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 68544:69944, ack 1, win 8211, options [nop,nop,TS val 865810590 ecr 198230056], length 1400 17:52:51.339221 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.340045 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 69972:71372, ack 1, win 8211, options [nop,nop,TS val 865810594 ecr 198230056], length 1400 17:52:51.340159 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.340900 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 71400:72800, ack 1, win 8211, options [nop,nop,TS val 865810594 ecr 198230056], length 1400 17:52:51.341221 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.344948 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 72828:74228, ack 1, win 8211, options [nop,nop,TS val 865810598 ecr 198230061], length 1400 17:52:51.345017 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.345529 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 74256:75656, ack 1, win 8211, options [nop,nop,TS val 865810598 ecr 198230061], length 1400 17:52:51.345798 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.346156 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 75684:77084, ack 1, win 8211, options [nop,nop,TS val 865810598 ecr 198230061], length 1400 17:52:51.346416 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.347169 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 77112:78512, ack 1, win 8211, options [nop,nop,TS val 865810598 ecr 198230061], length 1400 17:52:51.347237 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.348336 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 78540:79940, ack 1, win 8211, options [nop,nop,TS val 865810602 ecr 198230065], length 1400 17:52:51.348396 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:51.348947 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60718: Flags [.], seq 79968:81368, ack 1, win 8211, options [nop,nop,TS val 865810602 ecr 198230065], length 1400 17:52:51.350828 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:52.145234 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60720: Flags [.], seq 11412:12812, ack 1787, win 8211, options [nop,nop,TS val 3406674465 ecr 198230615], length 1400 17:52:52.145609 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:52.146180 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60720: Flags [.], seq 12840:14240, ack 1787, win 8211, options [nop,nop,TS val 3406674465 ecr 198230615], length 1400 17:52:52.146557 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 17:52:52.146947 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1432) 443 > 60720: Flags [.], seq 14268:15668, ack 1787, win 8211, options [nop,nop,TS val 3406674465 ecr 198230615], length 1400 17:52:52.147254 IP6 2001:4f8:0:2::42 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1432|28) 18:07:13.332185 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:07:13.334532 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:07:13.338261 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:07:13.340579 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:07:13.537905 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:14:34.369295 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:16:40.235932 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 18:16:40.321234 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:16:40.323531 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:16:40.325932 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:16:40.734578 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68 18:16:41.243931 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:16:41.246590 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:16:41.251308 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:16:41.346659 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:16:41.349150 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:16:41.351525 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:16:41.353840 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:16:41.756973 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 18:16:42.984622 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:16:42.989295 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:16:43.204949 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:16:43.290904 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:16:43.293616 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:16:43.599059 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:16:43.600358 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:16:43.705533 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:16:45.237348 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:16:45.749322 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:46:40.415607 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:46:40.416955 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:46:40.420216 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:46:40.424803 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 18:46:40.726339 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:09:49.576248 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:09:49.578604 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:15:47.772145 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:15:47.886129 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68 19:15:48.079267 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:15:48.081514 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:15:48.387608 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68 19:15:48.899441 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:15:48.901953 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:15:49.003082 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:15:49.007907 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:15:49.105533 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:15:49.107893 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:15:49.112726 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:15:49.412782 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 19:15:49.414144 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:15:49.416516 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:15:49.924607 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:15:50.844019 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:15:50.949711 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:15:51.356982 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:15:52.892870 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:15:53.404971 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:42:01.155878 IP6 2001:500:f::1 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (0|1232) 53 > 58227: 4349*- 7/0/1 DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG, RRSIG[|domain] 19:42:01.156074 IP6 2001:500:f::1 > 2001:470:1f00:820:5532:e31b:5741:ca2: frag (1232|401) 19:57:15.894538 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:57:15.897083 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:57:15.899208 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:57:15.996810 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:57:16.405172 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:57:35.143376 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:02:56.483978 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 20:02:56.485356 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:02:56.491613 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:02:56.578470 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:02:56.988418 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68 20:02:57.500075 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:02:57.601454 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:02:57.703891 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:02:58.013403 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 20:02:59.444688 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:02:59.548441 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:02:59.855470 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:02:59.857730 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:02:59.959986 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:03:00.163930 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:03:00.166387 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:03:00.487691 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:03:00.489211 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:03:00.491527 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:03:00.981709 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:03:01.596051 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:03:02.005761 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:32:56.875744 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:32:56.878014 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:32:56.880359 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:32:56.882750 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:32:56.979255 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 20:42:11.994105 IP6 fe80::ad2e:e400:37d5:77ee > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68 20:42:13.318680 IP6 fe80::ad2e:e400:37d5:77ee > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 20:42:13.532224 IP6 fe80::ad2e:e400:37d5:77ee > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 20:50:34.875054 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:14:20.583254 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 21:14:21.584086 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 21:14:25.091410 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 21:14:26.595319 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 21:15:15.100274 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 5 group record(s), length 108 21:15:15.591888 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 5 group record(s), length 108 21:34:37.323302 IP6 2001:500:2c::254 > 2001:470:1f00:820:b00f:4e2b:37b5:6667: frag (0|1232) 53 > 51301: 50046*- 2/5/13 A 149.20.48.47, RRSIG (1224) 21:34:37.323529 IP6 2001:500:2c::254 > 2001:470:1f00:820:b00f:4e2b:37b5:6667: frag (1232|398) 21:36:34.572006 IP6 2001:500:60::30 > 2001:470:1f00:820:b00f:4e2b:37b5:6667: frag (0|1232) 53 > 56840: 54055- 0/9/13 (1224) 21:36:34.572257 IP6 2001:500:60::30 > 2001:470:1f00:820:b00f:4e2b:37b5:6667: frag (1232|379) 21:43:13.526347 IP6 2001:500:e::1 > 2001:470:1f00:820:b00f:4e2b:37b5:6667: frag (1448|188) 21:47:58.614379 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:47:58.918080 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:47:58.919373 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:47:59.024058 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:47:59.027673 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:47:59.029022 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:47:59.030457 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:47:59.046346 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68 21:47:59.430352 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:47:59.437089 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:47:59.442249 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:47:59.636019 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 21:47:59.740690 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:47:59.742069 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:47:59.746785 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:47:59.749210 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:48:00.046798 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 21:48:01.786421 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:48:02.093672 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:48:02.607743 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:48:02.612625 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:48:03.120620 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:48:12.336322 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:48:12.338697 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:48:12.559289 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:48:12.651572 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:48:12.662981 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:48:13.051988 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:48:13.356771 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:48:13.460406 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:48:13.463092 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:48:13.465456 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:48:13.592105 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:48:13.721509 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:48:13.722975 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 21:48:14.077058 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:17:58.503374 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:17:58.607065 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:17:58.609377 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:17:58.611831 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:17:58.617512 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:23:29.257394 IP6 2001:500:e::1 > 2001:470:1f00:820:b00f:4e2b:37b5:6667: frag (1448|185) 22:31:19.889116 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:31:19.893077 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:34:46.586189 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 4 group record(s), length 88 22:34:47.095108 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 4 group record(s), length 88 22:44:51.663691 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:44:51.667036 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:44:51.670728 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:44:51.878056 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68 22:44:52.380588 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 22:44:52.893356 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:44:52.898210 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:44:52.902725 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:44:52.995006 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:44:53.004304 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:44:53.404716 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:44:53.408237 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 22:44:53.411976 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:44:53.414459 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:44:53.417055 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:44:53.918425 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:44:54.940413 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:44:54.946081 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:44:55.351141 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:44:56.887002 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:44:57.402222 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 23:06:04.659331 IP6 2001:500:b::1 > 2001:470:1f00:820:9418:8590:f473:f88f: frag (0|1232) 53 > 64255: 60624*- 7/0/1 DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG, RRSIG[|domain] 23:06:04.659517 IP6 2001:500:b::1 > 2001:470:1f00:820:9418:8590:f473:f88f: frag (1232|401) 23:41:15.583240 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 23:41:16.084012 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 23:41:16.584356 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68 23:41:17.585750 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 23:42:56.242973 IP6 fe80::ad2e:e400:37d5:77ee > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68 23:42:56.746437 IP6 fe80::ad2e:e400:37d5:77ee > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68 23:44:58.091635 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 23:44:58.094088 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 23:44:58.193844 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 23:44:58.196307 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 23:44:58.198648 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 23:44:58.604426 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 23:49:41.742371 IP6 2001:500:e::1 > 2001:470:1f00:820:d042:f8b:b0bb:a254: frag (1448|185) 00:00:08.776153 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 00:00:08.778492 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 00:01:47.801090 IP6 2001:500:2c::254 > 2001:470:1f00:820:d042:f8b:b0bb:a254: frag (0|1232) 53 > 58283: 27824*- 2/5/13 A 149.20.64.50, RRSIG (1224) 00:01:47.801296 IP6 2001:500:2c::254 > 2001:470:1f00:820:d042:f8b:b0bb:a254: frag (1232|400) 00:01:47.801693 IP6 2001:500:2c::254 > 2001:470:1f00:820:d042:f8b:b0bb:a254: frag (0|1232) 53 > 63408: 65514*- 2/5/13 AAAA 2001:4f8:0:2::29, RRSIG (1224) 00:01:47.801884 IP6 2001:500:2c::254 > 2001:470:1f00:820:d042:f8b:b0bb:a254: frag (1232|412) 00:05:20.906027 IP6 fe80::ad2e:e400:37d5:77ee > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 00:05:21.419808 IP6 fe80::ad2e:e400:37d5:77ee > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 00:05:22.335053 IP6 fe80::ad2e:e400:37d5:77ee > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 00:05:22.437494 IP6 fe80::ad2e:e400:37d5:77ee > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 00:09:48.890996 IP6 2001:500:f::1 > 2001:470:1f00:820:d042:f8b:b0bb:a254: frag (0|1232) 53 > 64978: 69*- 7/0/1 DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG, RRSIG[|domain] 00:09:48.891117 IP6 2001:500:f::1 > 2001:470:1f00:820:d042:f8b:b0bb:a254: frag (1232|401) 00:20:20.828198 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 00:20:21.332122 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 00:20:21.943663 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 00:20:22.354147 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 00:20:22.762869 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 00:20:22.765160 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 00:20:22.767603 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 00:20:22.774397 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 00:20:23.889222 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 00:20:23.891529 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 00:20:24.299810 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 00:20:25.835941 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 00:20:26.347892 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 00:20:32.905387 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 00:20:32.907790 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 00:20:32.910144 IP6 fe80::59ea:5d2f:a630:f7b > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 06:33:09.151217 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 06:33:09.651534 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68 06:33:10.654793 IP6 fe80::6233:4bff:fe01:7585 > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68 06:38:25.162471 IP6 2001:500:e::1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1448|185) 06:38:26.394389 IP6 2001:500:b::1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 55664: 53890*- 7/0/1 DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG, RRSIG[|domain] 06:38:26.394602 IP6 2001:500:b::1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|401) 06:39:09.610324 IP6 2001:500:1b::1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 51395: 64701*- 7/0/1 DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG, RRSIG[|domain] 06:39:09.610497 IP6 2001:500:1b::1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|405) 06:39:22.148032 IP6 2001:500:60::30 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 62347: 55919*- 2/5/13 A 149.20.64.69, RRSIG (1224) 06:39:22.148144 IP6 2001:500:60::30 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|395) 06:39:22.148659 IP6 2001:500:60::30 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 51055: 41711*- 2/5/17 MX mx.pao1.isc.org. 10, RRSIG (1224) 06:39:22.149018 IP6 2001:500:60::30 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|791) 06:39:25.371843 IP6 2001:660:3003:2::4:1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 64760: 35070*- 6/0/1 DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG, RRSIG[|domain] 06:39:25.371971 IP6 2001:660:3003:2::4:1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|247) 06:40:07.150343 IP6 2001:500:2c::254 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 55392: 61643*- 2/5/13 TXT "dkim=unknown", RRSIG (1224) 06:40:07.150557 IP6 2001:500:2c::254 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|421) 06:40:36.902005 IP6 2001:500:71::30 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 51811: 30400*- 2/5/13 A 149.20.64.69, RRSIG (1224) 06:40:36.902182 IP6 2001:500:71::30 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|395) 06:40:55.571251 IP6 2620::630:4000:164:62:13:3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|64) 53 > 56429: 41844*- 5/0/1 DNSKEY[|domain] 06:40:55.572986 IP6 2620::630:4000:164:62:13:3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (64|1400) 06:40:56.055758 IP6 2001:1900:2268:770:198:77:70:11 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 59233: 54142*- 4/5/15 CNAME ftc.gov., RRSIG, A 164.62.13.221, RRSIG (1224) 06:40:56.056230 IP6 2001:1900:2268:770:198:77:70:11 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|1232) 06:40:56.056542 IP6 2001:1900:2268:770:198:77:70:11 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (2464|784) 06:41:32.449694 IP6 2001:418:1::39 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 62253: 41728*- 2/4/13 MX psg.com. 0, RRSIG (1224) 06:41:32.449785 IP6 2001:418:1::39 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|366) 06:41:38.714849 IP6 2001:500:2c::254 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 53495: 11304*- 2/5/13 A 149.20.64.69, RRSIG (1224) 06:41:38.714971 IP6 2001:500:2c::254 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|395) 06:42:18.992934 IP6 2400:8900::f03c:91ff:feae:2d4b > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (2896|236) 06:44:08.326550 IP6 2001:500:27::1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 62103: 29552*- 7/0/1 DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG, RRSIG[|domain] 06:44:08.326610 IP6 2001:500:27::1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|397) 06:44:13.380727 IP6 2001:500:2c::254 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 52690: 18373*- 2/5/13 A 149.20.64.69, RRSIG (1224) 06:44:13.380959 IP6 2001:500:2c::254 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|395) 06:44:13.415412 IP6 2001:500:2c::254 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 56045: 29309*- 2/5/13 TXT "v=DKIM1; k=rsa; " "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8x1EKBg6oaur3iEUtMjFolpkY" "CAjkUmGZ9zIqVQtEfpiGzceu3ZXh3pp2+EnJBD8y4Uiyi9zqQm/y871jJRcUvwUv" "R2Sxd5pyaRMeVyfiR/LChaY+ukPoDGDsT/XnZfdYipTtzZteiOhVst4rqBLF09zL" "no5EbG86nGTpMGEvoQIDAQAB", RRSIG (1224) 06:44:13.415630 IP6 2001:500:2c::254 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|650) 06:45:22.523759 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 64796: 23978*- 2/5/13 A 149.20.64.69, RRSIG (1224) 06:45:22.525115 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|395) 06:46:34.353865 IP6 2001:558:100a:5:68:87:68:244 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1448|1423) 06:46:35.481840 IP6 2001:558:100e:5:68:87:72:244 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1448|1423) 06:46:36.486151 IP6 2001:558:1004:7:68:87:85:132 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1448|1423) 06:46:37.692618 IP6 2001:558:fe23:8:69:252:250:103 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1448|1423) 06:46:38.560072 IP6 2001:558:1014:c:68:87:76:228 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1448|1423) 06:57:04.886209 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 64098: 49357*- 2/5/13 A 149.20.64.52, RRSIG (1224) 06:57:04.886422 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|400) 06:57:04.889513 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 64425: 27429*- 2/5/13 AAAA 2001:4f8:0:2::31, RRSIG (1224) 06:57:04.889767 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|412) 06:57:07.775639 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 63512: 59048*- 2/5/13 AAAA 2001:4f8:0:2::29, RRSIG (1224) 06:57:07.775644 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|412) 06:57:07.775645 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 60471: 18408*- 2/5/13 A 149.20.64.50, RRSIG (1224) 06:57:07.775646 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|400) 06:57:31.164959 IP6 2001:500:b::1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 54190: 24114*- 7/0/1 DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG, RRSIG[|domain] 06:57:31.165074 IP6 2001:500:b::1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|401) 06:57:38.876542 IP6 2610:20:6005:13::3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1448|453) 06:57:38.881370 IP6 2610:20:6005:13::3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1448|453) 06:57:39.976325 IP6 2610:20:6005:13::3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1432) 53 > 50400: 23372*- 3/5/10 CNAME www.glb.nist.gov., RRSIG, RRSIG (1424) 06:57:39.976517 IP6 2610:20:6005:13::3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1432|453) 06:57:39.978375 IP6 2610:20:6005:13::3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1432) 53 > 53127: 36865*- 3/5/10 CNAME www.glb.nist.gov., RRSIG, RRSIG (1424) 06:57:39.978527 IP6 2610:20:6005:13::3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1432|453) 06:57:40.308244 IP6 2610:20:6005:13::3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1432) 53 > 63791: 29216- 0/5/10 (1424) 06:57:40.308370 IP6 2610:20:6005:13::3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1432|99) 06:57:40.308712 IP6 2610:20:6005:13::3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1432) 53 > 65418: 62337- 0/5/10 (1424) 06:57:40.308929 IP6 2610:20:6005:13::3 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1432|99) 07:01:19.568135 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 50444: 34759*- 2/5/13 A 149.20.0.20, RRSIG (1224) 07:01:19.568305 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|400) 07:01:40.447897 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 55785: 10694*- 2/5/13 A 149.20.64.74, RRSIG (1224) 07:01:40.448025 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|399) 07:01:40.453161 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 61252: 62748*- 2/5/13 AAAA 2001:4f8:0:2::22, RRSIG (1224) 07:01:40.453409 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|411) 07:01:41.790461 IP6 2001:500:2c::254 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 63120: 45424*- 2/5/13 A 149.20.48.47, RRSIG (1224) 07:01:41.790601 IP6 2001:500:2c::254 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|398) 07:02:43.711442 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 58854: 24002*- 2/5/13 A 149.20.48.19, RRSIG (1224) 07:02:43.711667 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|404) 07:02:43.713360 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 57699: 25653*- 2/5/13 AAAA 2001:4f8:3:d::19, RRSIG (1224) 07:02:43.713598 IP6 2001:4f8:0:2::19 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|416) 07:20:54.992739 IP6 2001:500:f::1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (0|1232) 53 > 52860: 23762*- 7/0/1 DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG, RRSIG[|domain] 07:20:54.992950 IP6 2001:500:f::1 > 2001:470:1f00:820:c808:cec3:2057:d77c: frag (1232|401) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From fred@cisco.com Tue Jun 25 15:30:42 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E7021F91BC for ; Tue, 25 Jun 2013 15:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaVNZgVibsDM for ; Tue, 25 Jun 2013 15:30:37 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD9A11E8171 for ; Tue, 25 Jun 2013 15:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1828; q=dns/txt; s=iport; t=1372199437; x=1373409037; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YbBuBjYzS8yoHTZ1VBeMF8eCm+ouF6iB4073D7x1kFo=; b=A9zWIKuT2gcac0D1ZqLBtU9E2hLscjutNKE2/X8R7lHiIgbKLHqRhcs6 Kyn+6ip81VBoZ4X5yxFMCuisOyPGCkTDZMV4eAZduM7mx9ZTyynvkdbSB 3tI3hZ21TMk8wtxlaw67KB3/shQCPx8XJ00mTVpBPgm5n4dZ1CSwR3yny Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFANYYylGtJV2Y/2dsb2JhbABagwkxSb83gQcWdIIjAQEBAwEBAQE3NAkCBQsCAQgOFBQQJwslAgQOBQgTh20GDLpLBI4eeQIxB4MCYQOTcZUXgxGBaT8 X-IronPort-AV: E=Sophos;i="4.87,939,1363132800"; d="scan'208";a="227383432" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 25 Jun 2013 22:30:34 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5PMUYiQ003831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Jun 2013 22:30:34 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 25 Jun 2013 17:30:33 -0500 From: "Fred Baker (fred)" To: Ole Troan Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHOcdXNVc9Jzi6cikCUApHj4sRJiJlHV1gA Date: Tue, 25 Jun 2013 22:30:32 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B9264FE@xmb-rcd-x09.cisco.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> In-Reply-To: <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.125] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org" , Arturo Servin X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 22:30:42 -0000 The case usually mentioned is in firewalls, under a policy that targets rea= ssembly attacks. If system A sends a fragment but not all fragments of a me= ssage to system B, some of system B's resources are consumed until a timeou= t-or-something occurs. Dropping fragments prevents that. Personally, I think the right solution is not to drop fragments, but impose= limits on storage for reassembly. Fragments arriving in B should consume a= t most some amount of storage for some amount of time; if the time elapses,= one discards the stale fragments, and if a new fragment arrives when resou= rces are maxed out, one discards the oldest fragment present (LRU). We can = argue ad infinitum on the amount of storage and time; I actually don't thin= k the exact numbers are important. The time should be some multiple of the = largest RTT the system sees, which is probably on the order of hundreds of = milliseconds to seconds, and the storage quantum that is reasonable is prob= ably measured in kilobytes. Beyond orders of magnitude, it's cook's choice. Listing the folks that have that firewall rule - I can't say. There seems t= o be a widely-held belief that the people exist. On Jun 25, 2013, at 11:56 AM, Ole Troan wrote: > Randy, >=20 >>> If it's a statement of fact, it shouldn't use RFC 2119 language. It >>> should simply state the truth: "Network operators might filter IPv6 >>> fragments." >>=20 >> s/might/do/ >=20 > would you be able to answer why and where? >=20 > cheers, > Ole > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From jhw@apple.com Tue Jun 25 16:08:55 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47EF11E8185 for ; Tue, 25 Jun 2013 16:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3V5Q0+6ZztC for ; Tue, 25 Jun 2013 16:08:49 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5B24311E817E for ; Tue, 25 Jun 2013 16:08:49 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MOZ00MV71LRU2A0@mail-out.apple.com> for ipv6@ietf.org; Tue, 25 Jun 2013 16:08:48 -0700 (PDT) X-AuditID: 11807153-b7f3c6d000007b32-5f-51ca23002615 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id A6.6B.31538.0032AC15; Tue, 25 Jun 2013 16:08:48 -0700 (PDT) Received: from ba0301a-dhcp116.apple.com ([17.193.14.244]) by marigold.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MOZ0069M1MOD040@marigold.apple.com> for ipv6@ietf.org; Tue, 25 Jun 2013 16:08:48 -0700 (PDT) Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt From: james woodyatt In-reply-to: Date: Tue, 25 Jun 2013 16:08:49 -0700 Message-id: References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> To: IPv6 Deployment Prevention X-Mailer: Apple Mail (2.1779) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FDcosugfCrQYPsyM4uXZ98zOTB6LFny kymAMYrLJiU1J7MstUjfLoErY/vSyoIzrBWTDyo0MG5l6WLk5JAQMJG4/3MbK4QtJnHh3nq2 LkYuDiGBSUwSW35cYoJwFjBJ/N+4HKyDWUBLYv3O40wgNq+AnsTMaZMYQWxhgWCJd3fXs4PY bAIqEt8u3wWr4QSqX3biKFgNi4CqxJ5V25kg5shJ/Gk7CTVTW+LJuwusEDNtJBqfHWKGWPyE ReL/lDdgCRGgZYeOrWSCOFVW4kzPTZYJjAKzkNw0C8lNs5DMXcDIvIpRoCg1J7HSWC+xoCAn VS85P3cTIzjwCoN3MP5ZZnWIUYCDUYmHV2HryUAh1sSy4srcQ4wSHMxKIrz5N4BCvCmJlVWp RfnxRaU5qcWHGKU5WJTEeSW8jgcKCaQnlqRmp6YWpBbBZJk4OKUaGFlX31SMY88uNPuzbd06 xQtxUl9+eT47d/WYWqTtU3aVtvevgxNWLohcZTpb3+0Af8W8YHuXCHNb7vmTu55u5zRWPB/1 me/M5boSdfbY/AcqGUm/Xm9x/Ve+fa72pmz5cm8+0815O9Xzpz/MmG70+Y1pDs+dfeUsR9le nv4S1P5y462GheqCwkosxRmJhlrMRcWJAGb5J0U4AgAA X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 23:08:55 -0000 On Jun 25, 2013, at 13:13 , Randy Bush wrote: > > ron has made one suggestion. though brutal, its simplicity and its > recognition of reality appeal to me. Why not go large and deprecate all of RFC 2460? I'm not entirely joking. If the practical global MTU for IPv6 is 1280, and while the practical global MTU for IPv4 remains larger, then I would say that pretty much serves as a guarantee that the transition from IPv4 to IPv6 cannot ever be successful. It will always be the case that IPv4 is a better outer encapsulation that IPv6 for whatever overlay network succeeds as the next L3 protocol standard. -- james woodyatt core os networking From randy@psg.com Tue Jun 25 16:23:14 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCECA21E80A9 for ; Tue, 25 Jun 2013 16:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEi7aNpJ0GPH for ; Tue, 25 Jun 2013 16:23:14 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 6522711E8166 for ; Tue, 25 Jun 2013 16:23:14 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UrcZr-000HL8-VM; Tue, 25 Jun 2013 23:23:12 +0000 Date: Wed, 26 Jun 2013 08:23:10 +0900 Message-ID: From: Randy Bush To: james woodyatt Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt In-Reply-To: References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 23:23:14 -0000 > while the practical global MTU for IPv4 remains larger, then I would > say that pretty much serves as a guarantee that the transition from > IPv4 to IPv6 cannot ever be successful. i had a semi-discussion with olaf kolkman, who was saying dnssec and ipv6 were slow and steady transitions. i pointed out that dnssec, with all its warts, was forward compatible and there was no visible alternative. ipv6, otoh, is incompatible on the wire and to the user, and there are viable, though disgusting, alternatives, nat. i am not optimistic. in our second system syndrome religious ferver, we have left the customer behind. if we have any last chance, it is to make it as absolutely easy as possible for folk running ipv4 to add ipv6, no excuses, no self-righteous crap, no ivory tower. all speed bumps must br removed. st00pid terribly trivial example. why do i have to install a second dhcp server for v6? why does the default one not do both? so building, testing, installing, dhcpv6 goes on the enterprise's mess of a ipv6 transition pert chart and the perceived cost goes up. and no, dhcp- based enterprises are not gonna transition to stateless, i said no religion. ron is actually deploying ipv6 in enterprises to see what his customers are seeing, eating his own dogfood. he did not field this draft for his amusement or to get his name on an rfc. randy From marka@isc.org Tue Jun 25 16:37:38 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAB021E80E7 for ; Tue, 25 Jun 2013 16:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLj2rixlW0pu for ; Tue, 25 Jun 2013 16:37:34 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 1514021E80A9 for ; Tue, 25 Jun 2013 16:37:34 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 2AD0BC9483; Tue, 25 Jun 2013 23:37:25 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372203453; bh=tMX9uEb2IrWnjLi84G5lhErh3ufhVmU85Iv+Y+zfp9I=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=u1lI666V1gufjmKKfjcy/JK0sdLe3SHaJp76W/obiDyqh6W0Du9tDXczw9o+uCpqx NRCEEKlhzRM8euoaQuoRyQx7mORsNKgZPVF2wMiJLODTFUtJl1/u6N5gJBogoTLr9U W6Z7fwjRiPGcsdUvm7te2qR1bloljrRS2aekAmI0= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 25 Jun 2013 23:37:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E4E0016005A; Tue, 25 Jun 2013 23:38:34 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id rKO64meYnXPY; Tue, 25 Jun 2013 23:38:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3ADD016008E; Tue, 25 Jun 2013 23:38:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mv5oJluA3nxL; Tue, 25 Jun 2013 23:38:34 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id CB90316008D; Tue, 25 Jun 2013 23:38:33 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 618C53642429; Wed, 26 Jun 2013 09:37:17 +1000 (EST) To: "Tony Hain" From: Mark Andrews References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625015317.6B256363BD8F@drugs.dv.isc.org> <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625040207.1CCA7363C42A@drugs.dv.isc.org> <51C98103.4050008@fud.no> <010f01ce71e3$7f43aea0$7dcb0be0$@tndh.net> Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt In-reply-to: Your message of "Tue, 25 Jun 2013 13:35:14 -0700." <010f01ce71e3$7f43aea0$7dcb0be0$@tndh.net> Date: Wed, 26 Jun 2013 09:37:16 +1000 Message-Id: <20130625233717.618C53642429@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: 'Tore Anderson' , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 23:37:38 -0000 In message <010f01ce71e3$7f43aea0$7dcb0be0$@tndh.net>, "Tony Hain" writes: > Tore Anderson wrote: > > * George Michaelson > > > > > One thing I *strongly* agree with: the sentence at 2.2: > > > > > > The effective MTU for IPv6 is 1280 bytes. > > > > > > This is looking compellingly awful, but true to me. > > > > I believe this is a gross exaggeration. I'm running 1500 bytes MTU on all > the > > clients and servers in my network, and have yet to hear about significant > > trouble (there have been a few, but no more than what I get with IPv4 as > > well). > > So what happens over the next 10 years as there is a mix of 1500 & 4k > systems? Or over the next 100 as the sizes continue to vary and routes flap > across an array of link sizes? Yes pmtud sorts out part of that, but does > tcp or the app need to become more dynamic about MSS changes during a > connection? Why? Just so people that want to use the hammer of 'no > fragments' are happy? Wouldn't it be better for everyone to actually solve > the only real problem, and simply require the L4 protocol be in the first > fragment? > > Short sighted myopia about a seriously outdated frame size should not drive > decisions about long term deployment of an emerging protocol. If the L4 is > in the first fragment, there are no other problems that need solving. If > reassembly resources are a challenge for boxes specifically designed to do > that, question why; but one could go further and require that the only > fragment allowed to be smaller than 1280 is the last fragment. That would > mitigate most of the resource-consumption-crafting nonsense. > > Tony One needs to get the L4 information the firewall/loadbalancer uses in *each* fragment. For UDP this is the source and destination ports. Create a new skipable hop-by-hop option that contains a copy of these values and add it along with a fragment header when fragmenting UDP packets. For TCP ensure that the IP layer informs the TCP layer if it would have to fragment the packet. i.e. don't send fragmented TCP packets. For ICMPv6 ??? For IPv4 if DF=0 fragment the Ipv4 packet to fit in inside 1280 IPv6 packets destination reassembles. For IPv4 if DF=1 return IPv4 PTB For XXX ???? > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From brian.e.carpenter@gmail.com Tue Jun 25 16:48:35 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA3821E80F0 for ; Tue, 25 Jun 2013 16:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcMqmwjlLtsh for ; Tue, 25 Jun 2013 16:48:35 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 86DDB21E80EC for ; Tue, 25 Jun 2013 16:48:35 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kl14so13284414pab.6 for ; Tue, 25 Jun 2013 16:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KUgWQRrvn4vjdh5+BR6LvJRNk2VWxC4a9wK8eo7MIx0=; b=kzYVnffUw5uRyp3bpAaJMdLRSgzi50RpnPLW/6Bq9m0YLggBioe9VFagdh7+67nEWC 4zUhvgK+dLsbGLq9aI+kLBy7sXoXl+gZDgf/fze22XouQiIcanTwr5lo57S4woCgTuex fLSaIXdBjPSZcyOHx8uIOu/u/5rv4Tf1fr+fsjZffFUxD4Y7hd9MXD7pVWcnqcN2nk77 ulRhcMxGsKfiGbnPGet+nRc5QrYSVfolQM7gOi79j4grwJkMgVq3A8VykK8yme7vPMW6 Ce0McqYiWrBXEZXKm8mFrS7D6mu0E6mqH2phoL4sZSGzT4P6icD/wDJE50QRH9VDGz77 9ubA== X-Received: by 10.67.5.70 with SMTP id ck6mr2083637pad.110.1372204115210; Tue, 25 Jun 2013 16:48:35 -0700 (PDT) Received: from [192.168.178.22] (15.198.69.111.dynamic.snap.net.nz. [111.69.198.15]) by mx.google.com with ESMTPSA id ue9sm17462299pab.7.2013.06.25.16.48.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Jun 2013 16:48:34 -0700 (PDT) Message-ID: <51CA2C56.1080809@gmail.com> Date: Wed, 26 Jun 2013 11:48:38 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: james woodyatt Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 23:48:36 -0000 On 26/06/2013 11:08, james woodyatt wrote: > On Jun 25, 2013, at 13:13 , Randy Bush wrote: >> ron has made one suggestion. though brutal, its simplicity and its >> recognition of reality appeal to me. > > Why not go large and deprecate all of RFC 2460? > > I'm not entirely joking. If the practical global MTU for IPv6 is 1280, ... We went through a protracted phase where the practical global MTU for IPv4 was around 512, unless you wanted to reconfigure your laptop stack experimentally each time you checked into a hotel and figured out how to connect to the phone line. I even recall having to set the MTU to 256 in one hotel. We may well have to accept a protracted phase of 1280 for IPv6. Eventually it will resolve itself, as it did for IPv4. I think that's orthogonal to the question of deprecating L3 fragmentation. Brian From ggm@algebras.org Tue Jun 25 16:53:07 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CDF11E816B for ; Tue, 25 Jun 2013 16:53:07 -0700 (PDT) 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=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkssMZpvlj6e for ; Tue, 25 Jun 2013 16:53:06 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id C87AD11E8162 for ; Tue, 25 Jun 2013 16:53:06 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id xa12so13248997pbc.25 for ; Tue, 25 Jun 2013 16:53:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=N1PuUnXDfVdlv2Xe+i4S43IdLDHCTa+aB9PPyIeoWnY=; b=FHlclcTY39lRFQL+NmG6W3MhJfS0lF+UP6tbOvTjCubI74xzWC8nz72NeBhAguhJjL yCHcgaWTp0xw661YxRiUOvpEIGznu2f0cZ5AyMA1Mg98N074HajxMlfmTHQ+Cyn+gwTU ljZXThnX5LB88RnNjNpB+OR2SyauOpDKwhM6uPSnbTg6AJKonfB/QLULQv3eqanP4tTL iNsTgbU8ZOnOyYSrvovYarEwHSxkiOiDf5HpQxTAKW1LAB+nY1hY7bHT0lJYCxdapIUu vu2xtowDHy7+4Vo84DOnh+UBvbFbqPEVp4bTCPH8S3sQwLS+CRy/knEmbeeu/Z99BKT2 8vdg== MIME-Version: 1.0 X-Received: by 10.66.169.172 with SMTP id af12mr2036997pac.216.1372204386450; Tue, 25 Jun 2013 16:53:06 -0700 (PDT) Received: by 10.70.25.195 with HTTP; Tue, 25 Jun 2013 16:53:06 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:5cfa:3a7d:cf29:3a21] In-Reply-To: References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> Date: Wed, 26 Jun 2013 09:53:06 +1000 Message-ID: Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt From: George Michaelson To: IPv6 Deployment Prevention Content-Type: multipart/alternative; boundary=047d7bea3b1403929904e0033b2d X-Gm-Message-State: ALoCoQk07j5tpHVnMxmUbV9jCjo7XDypqW6YtS4+7eSc0xGsulmV+JEgl9w32UbXBO9JwFrEeDsg X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 23:53:07 -0000 --047d7bea3b1403929904e0033b2d Content-Type: text/plain; charset=ISO-8859-1 If the recommended MTU was dropped, the frag changes probably wouldn't be needed. If the recommended MTU was dropped, could we raise the recommended MTU again later, on some evidence based process to confirm how its working? If this was only a recommendation, would it be enough? No code changes required: totally in the hands of operators and host configuration. Can be done on BSD and Linux systems trivially. APNIC has been running some of its web services on a dropped MTU for some time. It definitely reduced the incidence of pMTU related fail-to-fetch over V6 which we were seeing. (a bunch of people in Europe were seeing this facing us. We have seen this facing sites like ISOC and the IETF, in times past, as a result of dual-stacking) On Wed, Jun 26, 2013 at 9:23 AM, Randy Bush wrote: > > while the practical global MTU for IPv4 remains larger, then I would > > say that pretty much serves as a guarantee that the transition from > > IPv4 to IPv6 cannot ever be successful. > > i had a semi-discussion with olaf kolkman, who was saying dnssec and > ipv6 were slow and steady transitions. i pointed out that dnssec, with > all its warts, was forward compatible and there was no visible > alternative. ipv6, otoh, is incompatible on the wire and to the user, > and there are viable, though disgusting, alternatives, nat. > > i am not optimistic. in our second system syndrome religious ferver, we > have left the customer behind. if we have any last chance, it is to > make it as absolutely easy as possible for folk running ipv4 to add > ipv6, no excuses, no self-righteous crap, no ivory tower. all speed > bumps must br removed. > > st00pid terribly trivial example. why do i have to install a second > dhcp server for v6? why does the default one not do both? so building, > testing, installing, dhcpv6 goes on the enterprise's mess of a ipv6 > transition pert chart and the perceived cost goes up. and no, dhcp- > based enterprises are not gonna transition to stateless, i said no > religion. > > ron is actually deploying ipv6 in enterprises to see what his customers > are seeing, eating his own dogfood. he did not field this draft for his > amusement or to get his name on an rfc. > > randy > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --047d7bea3b1403929904e0033b2d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    If the recommended MTU was dropped, the frag changes proba= bly wouldn't be needed.

    If the recommended MTU= was dropped, could we raise the recommended MTU again later, on some evide= nce based process to confirm how its working?

    If this was only a recommendation, would it= be enough? No code changes required: totally in the hands of operators and= host configuration. Can be done on BSD and Linux systems trivially.

    APNIC has been running some of its web serv= ices on a dropped MTU for some time. It definitely reduced the incidence of= pMTU related fail-to-fetch over V6 which we were seeing. (a bunch of peopl= e in Europe were seeing this facing us. We have seen this facing sites like= ISOC and the IETF, in times past, as a result of dual-stacking)


    On Wed,= Jun 26, 2013 at 9:23 AM, Randy Bush <randy@psg.com> wrote:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
    > while the practical global MTU for IPv4 remains larg= er, then I would
    > say that pretty much serves as a guarantee that the transition from > IPv4 to IPv6 cannot ever be successful.

    i had a semi-discussion with olaf kolkman, who was saying dnssec and<= br> ipv6 were slow and steady transitions. =A0i pointed out that dnssec, with all its warts, was forward compatible and there was no visible
    alternative. =A0ipv6, otoh, is incompatible on the wire and to the user, and there are viable, though disgusting, alternatives, nat.

    i am not optimistic. =A0in our second system syndrome religious ferver, we<= br> have left the customer behind. =A0if we have any last chance, it is to
    make it as absolutely easy as possible for folk running ipv4 to add
    ipv6, no excuses, no self-righteous crap, no ivory tower. =A0all speed
    bumps must br removed.

    st00pid terribly trivial example. =A0why do i have to install a second
    dhcp server for v6? =A0why does the default one not do both? =A0so building= ,
    testing, installing, dhcpv6 goes on the enterprise's mess of a ipv6
    transition pert chart and the perceived cost goes up. =A0and no, dhcp-
    based enterprises are not gonna transition to stateless, i said no
    religion.

    ron is actually deploying ipv6 in enterprises to see what his customers
    are seeing, eating his own dogfood. =A0he did not field this draft for his<= br> amusement or to get his name on an rfc.

    randy
    ---------------------= -----------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------

    --047d7bea3b1403929904e0033b2d-- From brian.e.carpenter@gmail.com Tue Jun 25 16:57:39 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6841421E80C9 for ; Tue, 25 Jun 2013 16:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQL2nOU9bDtV for ; Tue, 25 Jun 2013 16:57:39 -0700 (PDT) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 08E5511E817E for ; Tue, 25 Jun 2013 16:57:38 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id un1so13388559pbc.15 for ; Tue, 25 Jun 2013 16:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4XVb5fosS43H3JH28RPKkWV1YX3fj+13S57PqcYbqQw=; b=XRj2G0w0Nh5nIaV8zBVjWtwtDn2hcxjxKRCinV4sZWKRhRBYzBoG2bDHqS13U/fyzq nkj01WSyXGtf+qhSzuc1job1eDwCwhxeZoLpnOIMyFwQXzg8i0QmYbWQ3s6nNU79HQZa /VtBTdc5t5uBow1VzLzHILYUq7zcEaKH5J2RQwtNJMuThqrgNJjb8qyOef5682/gEhOE zzquh2U/EYfDxoszmtBD0uFtJFdOOqOdqrW2c8CXBqGq3WwblpyG2IDpsdeUR/abO/VX aR6UTIdF2mMberLEMAHD1V0+jmk5R5lBPcif2+qJp3uDbkzqT9pbyRkA9YRXCeIDWBF9 wYcg== X-Received: by 10.66.191.99 with SMTP id gx3mr2163207pac.88.1372204658479; Tue, 25 Jun 2013 16:57:38 -0700 (PDT) Received: from [192.168.178.22] (15.198.69.111.dynamic.snap.net.nz. [111.69.198.15]) by mx.google.com with ESMTPSA id p2sm27387390pag.22.2013.06.25.16.57.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Jun 2013 16:57:37 -0700 (PDT) Message-ID: <51CA2E75.7050204@gmail.com> Date: Wed, 26 Jun 2013 11:57:41 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Bush Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 23:57:39 -0000 On 26/06/2013 11:23, Randy Bush wrote: ... > ron is actually deploying ipv6 in enterprises to see what his customers > are seeing, eating his own dogfood. he did not field this draft for his > amusement or to get his name on an rfc. The only times I've seen hard FAILs with apparently operational IPv6 sites were caused by MTU mismatch and TCP MSS negotiation failure, followed by silence which I assumed was due to fragmented packets being discarded. Yes, this is a real problem and doing nothing certainly isn't an option. We just need to be sure that the cure isn't worse than the illness. Brian From marka@isc.org Tue Jun 25 17:07:04 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9451721E8102 for ; Tue, 25 Jun 2013 17:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFR8u2CXBRVY for ; Tue, 25 Jun 2013 17:06:59 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 189A321E80EC for ; Tue, 25 Jun 2013 17:06:59 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 758FCC9479; Wed, 26 Jun 2013 00:06:50 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372205218; bh=zgkI/0lEqDo4y3BaX75gvgSeJ5pF4PJwr4PMEhfD794=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=fLWCI3w979Yi9RGHD7oOobEfOBSFxeRz1/yfVgf4jikdDtYDqSbHa3YEkYFdqtxQj PCBD1Rb2FgM6PfgpnEwmvPRFYnPdEZfgqnl0pwe2D7MEuP8JMRL18xLihNGSVdEt+O yvsPKCEoqJ3IrikqZOf29CrqTnvqMPYIgMfSa5xc= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 26 Jun 2013 00:06:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5685F16005A; Wed, 26 Jun 2013 00:08:00 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id cPNXxuzSO_Yb; Wed, 26 Jun 2013 00:07:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DB9AD16008D; Wed, 26 Jun 2013 00:07:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RcAHntEkSo3N; Wed, 26 Jun 2013 00:07:59 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id 6608E16005A; Wed, 26 Jun 2013 00:07:59 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 047533642802; Wed, 26 Jun 2013 10:06:45 +1000 (EST) To: Brian E Carpenter From: Mark Andrews References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> <51CA2E75.7050204@gmail.com> Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt In-reply-to: Your message of "Wed, 26 Jun 2013 11:57:41 +1200." <51CA2E75.7050204@gmail.com> Date: Wed, 26 Jun 2013 10:06:45 +1000 Message-Id: <20130626000646.047533642802@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 00:07:04 -0000 In message <51CA2E75.7050204@gmail.com>, Brian E Carpenter writes: > On 26/06/2013 11:23, Randy Bush wrote: > ... > > > ron is actually deploying ipv6 in enterprises to see what his customers > > are seeing, eating his own dogfood. he did not field this draft for his > > amusement or to get his name on an rfc. > > The only times I've seen hard FAILs with apparently operational IPv6 > sites were caused by MTU mismatch and TCP MSS negotiation failure, > followed by silence which I assumed was due to fragmented packets > being discarded. Yes, this is a real problem and doing nothing > certainly isn't an option. We just need to be sure that the cure > isn't worse than the illness. Named uses IPV6_USE_MIN_MTU=1 to avoid this. It should affect MSS negotiation but MacOS and FreeBSD are broken (bug fix submitted for FreeBSD). Mark > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From kml@patheticgeek.net Tue Jun 25 17:49:31 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D1D11E8185 for ; Tue, 25 Jun 2013 17:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nkn99nJASoSS for ; Tue, 25 Jun 2013 17:49:25 -0700 (PDT) Received: from mail.patheticgeek.net (patheticgeek.net [166.84.136.10]) by ietfa.amsl.com (Postfix) with ESMTP id B57BB11E8103 for ; Tue, 25 Jun 2013 17:49:25 -0700 (PDT) Received: from temprokkaku (newmail [166.84.136.10]) by mail.patheticgeek.net (Postfix) with ESMTP id DA58B2091DC; Tue, 25 Jun 2013 20:37:46 -0400 (EDT) Date: Tue, 25 Jun 2013 17:49:32 -0700 From: Kevin Lahey To: Christian Huitema Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Message-ID: <20130625174932.14a71bab@temprokkaku> In-Reply-To: References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625015317.6B256363BD8F@drugs.dv.isc.org> <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.prod.outlook.com> <4979E44C-B449-4B06-9293-C6F03FA9C87B@apnic.net> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.12; x86_64--netbsd) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org 6man-wg" , Mark Andrews , Bob Hinden , Geoff Huston X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 00:49:31 -0000 On Tue, 25 Jun 2013 16:36:51 +0000 Christian Huitema wrote: > > I also believe that FreeBSD has done the best it can, and reasonably so. It is debatable whether a ICMP6 PTB message should apply to all currently open TCP sessions to the same destination, as I wonder about multi-path TCP and path diversity here. > > There are certainly different ways to implement that, without inserting a fragmentation header. For example, if the lower layer knows that the packet is too big, it could send the local equivalent of "ICMP too big" back to the TCP layer. This certainly seems like a bug, no matter how you slice it: * If the implementation wanted to allow for different MTUs on a per-flow basis (reasonable given the prevalence of NATs), it should go ahead and send a full-sized packet for the second flow, and find out what the MTU is. * If the implementation wanted to efficiently use the first Packet Too Big it got to fix all possible flows, TCP should re-segment the data in the second flow, rather than allowing fragmentation. I can't think of a case in which it would be better for TCP to fragment rather than re-segment (since it's a lot more efficient to recover from a dropped segment than a dropped fragment), but I'm sure I will as soon as I hit send. Kevin kml@patheticgeek.net From alh-ietf@tndh.net Tue Jun 25 17:57:34 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3925811E8185 for ; Tue, 25 Jun 2013 17:57:34 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ...that system for details.\n \n Content previ[...] X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouAA4gPOoqRT for ; Tue, 25 Jun 2013 17:57:33 -0700 (PDT) Received: from express.tndh.net (express.tndh.net [IPv6:2001:470:e930:1240:20d:56ff:fe04:4c0a]) by ietfa.amsl.com (Postfix) with ESMTP id 8013821F9D15 for ; Tue, 25 Jun 2013 17:57:33 -0700 (PDT) Received: from express.tndh.local ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ure2j-000Af0-1K; Tue, 25 Jun 2013 17:57:10 -0700 From: "Tony Hain" To: "'Mark Andrews'" References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625015317.6B256363BD8F@drugs.dv.isc.org> <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625040207.1CCA7363C42A@drugs.dv.isc.org> <51C98103.4050008@fud.no> <010f01ce71e3$7f43aea0$7dcb0be0$@tndh.net> <20130625233717.618C53642429@drugs.dv.isc.org> In-Reply-To: <20130625233717.618C53642429@drugs.dv.isc.org> Subject: RE: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Date: Tue, 25 Jun 2013 17:57:05 -0700 Message-ID: <014201ce7208$1378c5f0$3a6a51d0$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFPmzyGg3SBeEPNIeSj1WaAnqHbKQGRFuihAQgjLW0B2P4/0wGC2zy+AgQy54sC+zKFhgIGAa8jAZL3LQUBgMkG5gKeeubQAoS/2kUCfvxRdZmHUcGw Content-Language: en-us X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a X-SA-Exim-Mail-From: alh-ietf@tndh.net X-SA-Exim-Scanned: No (on express.tndh.net); SAEximRunCond expanded to false Cc: 'Tore Anderson' , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 00:57:34 -0000 Mark Andrews wrote: > One needs to get the L4 information the firewall/loadbalancer uses in *each* > fragment. This is a manufactured requirement to allow devices that can't do a full reassembly to operate in under a policy of 'verify the entire packet'. Unfortunately, it doesn't even do that since it doesn't actually detect overlapping fragments if it is just verifying that the L4 information is the same. Load balancers just need to get over it, and use something more/other than the L4 in the hash. The FL was intended to provide a consistent value over the life of an L4 session, so why not use that instead of developing yet another new option? Wait,,, that doesn't exist in IPv4, so it can't be used because that would require learning something different... > For UDP this is the source and destination ports. Create a new skipable hop- > by-hop option that contains a copy of these values and add it along with a > fragment header when fragmenting UDP packets. I have no problem with that concept, but why when there are other ways of accomplishing the task? Simply to mirror IPv4 is not a valid reason... > > For TCP ensure that the IP layer informs the TCP layer if it would have to > fragment the packet. i.e. don't send fragmented TCP packets. So TCP is never allowed to have a long-lived session ... Or routes are not allowed to flap. Which is it? You either tear down tcp and renegotiate mss every time routes flap to a path with a lower mtu, or you send fragments. It is easy to say the core is >=1500 now, but what happens with a mix of 1500/4k/9k/32k/... over the life of IPv6? Are routes never allowed to flap with larger MTUs? Do you require every TCP implementation to do dynamic MSS, and try to get that deployed within a decade to two? > > For ICMPv6 ??? > > For IPv4 if DF=0 fragment the Ipv4 packet to fit in inside 1280 IPv6 packets > destination reassembles. > For IPv4 if DF=1 return IPv4 PTB > > For XXX ???? From osmankh@yahoo.com Tue Jun 25 18:06:08 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8577E21F9971 for ; Tue, 25 Jun 2013 18:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBgkoEvKdnh5 for ; Tue, 25 Jun 2013 18:06:03 -0700 (PDT) Received: from nm9-vm0.bullet.mail.bf1.yahoo.com (nm9-vm0.bullet.mail.bf1.yahoo.com [98.139.213.154]) by ietfa.amsl.com (Postfix) with ESMTP id D053B21F9644 for ; Tue, 25 Jun 2013 18:05:56 -0700 (PDT) Received: from [98.139.215.140] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 26 Jun 2013 01:05:56 -0000 Received: from [98.139.211.162] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 26 Jun 2013 01:05:56 -0000 Received: from [127.0.0.1] by smtp219.mail.bf1.yahoo.com with NNFMP; 26 Jun 2013 01:05:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1372208756; bh=ZfBoQ1iAh5xayN6fx2qNIL7mLH8hMJS0Ip14p2Jq9Ks=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:References:From:Content-Type:X-Mailer:In-Reply-To:Message-Id:Date:To:Content-Transfer-Encoding:Mime-Version; b=jMgb83ZgfLIVVBdnddsSl5+et/5avCFQi+ofJ3Ajo04k7kb6AevZSp7prldaJNYgFIoNu7XH4yVjpPBK+JLyDhw7wI3ey7UMvd2dbJu3d+CnlPAnwfxIV4Ji0xZGl3GvsecOjNafspXiBjP76P3K7rls/pb+bK3HubGHEEHRHfY= X-Yahoo-Newman-Id: 139041.94753.bm@smtp219.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: gGRWh8cVM1mwMOCLyVbnD8qoO5w8eAMm.Lnjt_Dni8WivCE HxPayPHo2tFrTg3ezGO8WaKQzg1kn9yB0z6ezUQmFeKnoKEdAwqnjWTMBNOA VbNvF3AX9nLOW32ZWo_P2xPyGzmOdMV0VDahmMQ2DuWCh_Y6dKSCVKNIf4DY zDwFiCneLEUKG96MZFD3o.3DO336CYyCQ_KQ6kBkwfv6s_Dq4wGoVy2YariK 51lrnjnZGKpwUvvxUHb0EAVYthkCH7.XKceIbORTDtXkSzMdMv7cjca_3O.2 VIMhQjfxG376WnelMfC36wuLPT2t6XOlVbruuOUhGRAuNJp1TaXLVDxQ_i6W QJepa5Zx6QG0qSZ_nLXpOkNqGlhN8j9jz1d.Xzj5feJ19.k4ZtcEpO8Tj76S oUSFc4f5i.i2RFDrQFj_muxi640qlpmg4stkqpBgVT3sU19Gzq3DHNUboOIg EaK5xuv3iDzjPW2tBmZg_DZbpFKJUAMmfCmjcnZ2JZvzmgU9XTbRNwQ-- X-Yahoo-SMTP: RUL5CFuswBD02LFE5KfPCwZifSs- X-Rocket-Received: from [192.168.1.1] (osmankh@27.32.72.22 with ) by smtp219.mail.bf1.yahoo.com with SMTP; 25 Jun 2013 18:05:56 -0700 PDT Subject: RE: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: From: Usman Latif Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (9B206) In-Reply-To: Message-Id: <0F21D0E7-B884-4CC1-B808-E0C6447516B1@yahoo.com> Date: Wed, 26 Jun 2013 11:06:45 +1000 To: "ipv6@ietf.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 01:06:08 -0000 I have the following suggestion: IPv6 hosts can try to gain knowledge of the path MTU to a destination. If th= e path blocks or filters PMTUD etc, then the host should revert to 1280 byte= s else the hosts can use a higher packet size.=20 This mechanism would make Fragment header redundant anyway The only implication of the above mechanism would be that network providers '= must' support 1280 byte IPv6 packets in all situations Regards, Usman On 25/06/2013, at 5:00 AM, ipv6-request@ietf.org wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to=20 >=20 > https://www.ietf.org/mailman/listinfo/ipv6 >=20 > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. >=20 >=20 >=20 > Send ipv6 mailing list submissions to > ipv6@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/ipv6 > or, via email, send a message with subject or body 'help' to > ipv6-request@ietf.org >=20 > You can reach the person managing the list at > ipv6-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ipv6 digest..." >=20 >=20 > Today's Topics: >=20 > 1. RE: New Version Notification for > draft-bonica-6man-frag-deprecate-00.txt (Ronald Bonica) > 2. Re: New Version Notification for > draft-bonica-6man-frag-deprecate-00.txt (Fred Baker (fred)) > 3. Re: New Version Notification for > draft-bonica-6man-frag-deprecate-00.txt (Ole Troan) > 4. RE: New Version Notification for > draft-bonica-6man-frag-deprecate-00.txt (Templin, Fred L) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Mon, 24 Jun 2013 16:38:06 +0000 > From: Ronald Bonica > To: George Michaelson , "ipv6@ietf.org 6man-wg" > > Subject: RE: New Version Notification for > draft-bonica-6man-frag-deprecate-00.txt > Message-ID: > <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod= .outlook.com> > =20 > Content-Type: text/plain; charset=3D"us-ascii" >=20 >=20 > I'd like to understand the basis of these assertions. I believe what I am s= eeing, on the edge, suggests there is in fact V6 fragmentation in both TCP a= nd UDP. >=20 >=20 > Hi George, >=20 > It would be helpful if you could describe: >=20 >=20 > - Where your observations are being made >=20 > - What percentage of traffic is fragmented >=20 > - What kinds of packets are being fragmented > Ron >=20 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: >=20 > ------------------------------ >=20 > Message: 2 > Date: Mon, 24 Jun 2013 16:50:04 +0000 > From: "Fred Baker (fred)" > To: Tore Anderson > Cc: "ipv6@ietf.org 6man-wg" > Subject: Re: New Version Notification for > draft-bonica-6man-frag-deprecate-00.txt > Message-ID: > <8C48B86A895913448548E6D15DA7553B924440@xmb-rcd-x09.cisco.com> > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 >=20 > On Jun 24, 2013, at 12:45 AM, Tore Anderson wrote: >=20 >> * Fred Baker (fred) >>=20 >>> On Jun 22, 2013, at 2:29 AM, Tore Anderson wrote: >>>> - When a SIIT translator receives an IPv4 packet with DF=3D0 that >>>> would result in an IPv6 packet that would exceed the IPv6 link MTU, >>>> it will split the original packet into IPv6 fragments. >>>=20 >>> It *could* fragment the IPv4 packet and send it in two unfragmented >>> IPv6 packets. >>=20 >> Wouldn't doing IPv4 fragmentation before translation to IPv6 be >> logically identical to this other case I mentioned? >=20 > Ah. You're correct. I was thinking about tunnels. >=20 >>>> - When a SIIT translator receives an IPv4 fragment, it will translate >>>> this into one or more IPv6 fragments. >>=20 >> I can't see how simply omitting the Fragmentation header in the IPv6 >> output could work here, as the node receiving those two unfragmented >> IPv6 packets would see the first one containing a truncated L4 payload, >> while the second one would be just garbage as it doesn't include a L4 >> header. >>=20 >> Tore >=20 > ----------------------------------- > "We are learning to do a great many clever things...The next great task > will be to learn not to do them." >=20 > - G. K. Chesterton (1874-1936) >=20 >=20 >=20 >=20 >=20 >=20 > ------------------------------ >=20 > Message: 3 > Date: Mon, 24 Jun 2013 13:37:41 -0400 > From: Ole Troan > To: Sheng Jiang > Cc: "ipv6@ietf.org 6man-wg" , "Fred Baker \(fred\)" > > Subject: Re: New Version Notification for > draft-bonica-6man-frag-deprecate-00.txt > Message-ID: <34E0F96D-5CCB-4275-AF64-E451B00369E0@employees.org> > Content-Type: text/plain; charset=3Dus-ascii >=20 >>> I suppose I'm the contrarian >>=20 >> +1. For me, this draft looks dangerous by proposing to deprecate fragment= ation with only one-side observation. This draft does not give enough analys= is on these existing fragmentation use cases, particularly these use cases t= he fragments within a single domain. >>=20 >> On other side , only disallowing fragmentation to be used among domains m= ay helpful to reduce the operational complex. >=20 > this draft should help us tease out answers to the question: > "if we wanted to deprecate IPv6 fragmentation, could we?" >=20 > then when we know the collateral damage, it will be easier to answer the o= ther question: > "should we deprecate IP layer fragmentation or not". >=20 > cheers, > Ole >=20 > ------------------------------ >=20 > Message: 4 > Date: Mon, 24 Jun 2013 17:50:36 +0000 > From: "Templin, Fred L" > To: "Fred Baker (fred)" , Tore Anderson > Cc: "ipv6@ietf.org 6man-wg" > Subject: RE: New Version Notification for > draft-bonica-6man-frag-deprecate-00.txt > Message-ID: > <2134F8430051B64F815C691A62D983180A93A6@XCH-BLV-504.nw.nos.boeing.com> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Hi Fred, >=20 >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >> Fred Baker (fred) >> Sent: Sunday, June 23, 2013 4:12 PM >> To: Tore Anderson >> Cc: ipv6@ietf.org 6man-wg >> Subject: Re: New Version Notification for draft-bonica-6man-frag- >> deprecate-00.txt >>=20 >>=20 >> On Jun 22, 2013, at 2:29 AM, Tore Anderson wrote: >>> - When a SIIT translator receives an IPv4 packet with DF=3D0 that would >>> result in an IPv6 packet that would exceed the IPv6 link MTU, it will >>> split the original packet into IPv6 fragments. >>=20 >> It *could* fragment the IPv4 packet and send it in two unfragmented >> IPv6 packets. >>=20 >>> I cannot support your draft until it discusses or provides solutions >> for >>> the above considerations. >>=20 >> I'm in a similar case with respect to protocols above IPv6 (OSPF and >> NFS/UDP come quickly to mind) that depend on fragmentation to deal with >> the issue. I think the Robustness Principle tells us that such >> applications SHOULD figure out how to live with PMTU, but it also tells >> us that we can't deprecate fragmentation unless all known instances >> that depend on it have defined practical work-arounds. I suspect that >> this would imply the re-creation of the fragmentation feature in an >> intermediate protocol, >=20 > That is essentially what SEAL does - it provides an intermediate-level > segmentation and reassembly capability that avoids the pitfalls of IP > fragmentation. >=20 >> which seems like a lot of work with little real gain. >=20 > It's not that bad, and IMHO worth it. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > ipv6 mailing list > ipv6@ietf.org > https://www.ietf.org/mailman/listinfo/ipv6 >=20 >=20 > End of ipv6 Digest, Vol 110, Issue 75 > ************************************* From marka@isc.org Tue Jun 25 18:38:21 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C536F21E80EC for ; Tue, 25 Jun 2013 18:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5hbdpTgFLb5 for ; Tue, 25 Jun 2013 18:38:17 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id B402011E8192 for ; Tue, 25 Jun 2013 18:38:16 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 97FFCC947E; Wed, 26 Jun 2013 01:38:08 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372210696; bh=jTtmXeWt8pf9wmwBGnLOmNoJOo151GWRMZlf53GMKXg=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=JOyAx8vmFGsvXbAMK/118+UnyPpEGxZVU6jnEbY1KwHrUoHZOmh2NRNO5+8Locfoe y5qZw/VbnqIyVn4Vhl/Ap3sTphwwT6bakYafBBSQuWeddleI1FvtCcsQ9PMCjNpLhU h2WFOZghNRfZFZbT3TxoX/1Aa9ovWYT7nbbKeMsI= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 26 Jun 2013 01:38:08 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C4CCE16008E; Wed, 26 Jun 2013 01:39:18 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id R5oJ_7iGP5LV; Wed, 26 Jun 2013 01:39:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 36EB016008D; Wed, 26 Jun 2013 01:39:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rseB4CCfFcrS; Wed, 26 Jun 2013 01:39:18 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id 96B1016005A; Wed, 26 Jun 2013 01:39:17 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 741B23643834; Wed, 26 Jun 2013 11:38:04 +1000 (EST) To: "Tony Hain" From: Mark Andrews References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625015317.6B256363BD8F@drugs.dv.isc.org> <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625040207.1CCA7363C42A@drugs.dv.isc.org> <51C98103.4050008@fud.no> <010f01ce71e3$7f43aea0$7dcb0be0$@tndh.net> <20130625233717.618C53642429@drugs.dv.isc.org> <014201ce7208$1378c5f0$3a6a51d0$@tndh.net> Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt In-reply-to: Your message of "Tue, 25 Jun 2013 17:57:05 -0700." <014201ce7208$1378c5f0$3a6a51d0$@tndh.net> Date: Wed, 26 Jun 2013 11:38:04 +1000 Message-Id: <20130626013804.741B23643834@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: 'Tore Anderson' , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 01:38:21 -0000 In message <014201ce7208$1378c5f0$3a6a51d0$@tndh.net>, "Tony Hain" writes: > Mark Andrews wrote: > > One needs to get the L4 information the firewall/loadbalancer uses in > *each* > > fragment. > > This is a manufactured requirement to allow devices that can't do a full > reassembly to operate in under a policy of 'verify the entire packet'. > Unfortunately, it doesn't even do that since it doesn't actually detect > overlapping fragments if it is just verifying that the L4 information is the > same. Many firewalls are just trying to ensure packets match the tuple. They are not trying to protect from overlapping fragements. That said being able to filter out / forward without reassembly fragments that you are not interested in also reduces the number of fragments that need to be processed in the reassembly queues of the firewall itself when you are doing dpi of some of the packets. > Load balancers just need to get over it, and use something more/other than > the L4 in the hash. The FL was intended to provide a consistent value over > the life of an L4 session, so why not use that instead of developing yet > another new option? Wait,,, that doesn't exist in IPv4, so it can't be used > because that would require learning something different... Flow labels aren't a solution for all problems. Yes, load balancers should make use of them. > > For UDP this is the source and destination ports. Create a new skipable > hop- > > by-hop option that contains a copy of these values and add it along with a > > fragment header when fragmenting UDP packets. > > I have no problem with that concept, but why when there are other ways of > accomplishing the task? Simply to mirror IPv4 is not a valid reason... It isn't just mirror IPv4. > > For TCP ensure that the IP layer informs the TCP layer if it would have to > > fragment the packet. i.e. don't send fragmented TCP packets. > > So TCP is never allowed to have a long-lived session ... No. It's send the equivalent of PTB back to the TCP layer and have it re-segment rather than fragment a badly sized segment it passed to the IP layer. You have a broken stack if you see a TCP fragment. > Or routes are not > allowed to flap. Which is it? You either tear down tcp and renegotiate mss > every time routes flap to a path with a lower mtu, or you send fragments. It > is easy to say the core is >=1500 now, but what happens with a mix of > 1500/4k/9k/32k/... over the life of IPv6? Are routes never allowed to flap > with larger MTUs? Do you require every TCP implementation to do dynamic MSS, > and try to get that deployed within a decade to two? > > > > > For ICMPv6 ??? > > > > For IPv4 if DF=0 fragment the Ipv4 packet to fit in inside 1280 IPv6 > packets > > destination reassembles. > > For IPv4 if DF=1 return IPv4 PTB > > > > For XXX ???? > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Tue Jun 25 18:49:10 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7316D21E8100 for ; Tue, 25 Jun 2013 18:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZllOjGL3wDS for ; Tue, 25 Jun 2013 18:49:06 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id AE8FA21E810A for ; Tue, 25 Jun 2013 18:49:02 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id A11A6C9478; Wed, 26 Jun 2013 01:48:51 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372211342; bh=9swPsSpTtAdjai5RbHAjqjvB/CXb+6M3eGUBL29dtpQ=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=vErHZsVuQDLk0+KtccuFFZumcULpbpmPsmGk2+CoCOOXnnQNqTSOoPyLGpiQ+Zre2 fOA7q3giGXGxWhtjmIUoANSOSQh5aGKP7+DampznLzdQtoEBLE3mW2NQRg4L4W5Jyw 6IiyiS7hOfR78uP9gGkQ8sk479P10iTEIyofxZWE= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 26 Jun 2013 01:48:51 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CD64416005A; Wed, 26 Jun 2013 01:50:01 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id fIgLNIIdG9nO; Wed, 26 Jun 2013 01:49:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0DDF416008E; Wed, 26 Jun 2013 01:49:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Jl7dyd6_3y-r; Wed, 26 Jun 2013 01:49:55 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id 4693816008D; Wed, 26 Jun 2013 01:49:55 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id AC55536439B3; Wed, 26 Jun 2013 11:48:41 +1000 (EST) To: Usman Latif From: Mark Andrews References: <0F21D0E7-B884-4CC1-B808-E0C6447516B1@yahoo.com> Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt In-reply-to: Your message of "Wed, 26 Jun 2013 11:06:45 +1000." <0F21D0E7-B884-4CC1-B808-E0C6447516B1@yahoo.com> Date: Wed, 26 Jun 2013 11:48:41 +1000 Message-Id: <20130626014841.AC55536439B3@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 01:49:10 -0000 In message <0F21D0E7-B884-4CC1-B808-E0C6447516B1@yahoo.com>, Usman Latif writes : > I have the following suggestion: > > IPv6 hosts can try to gain knowledge of the path MTU to a destination. If the > path blocks or filters PMTUD etc, then the host should revert to 1280 bytes > else the hosts can use a higher packet size. > This mechanism would make Fragment header redundant anyway No, it doesn't. > The only implication of the above mechanism would be that network providers ' > must' support 1280 byte IPv6 packets in all situations > > > Regards, > Usman > > > On 25/06/2013, at 5:00 AM, ipv6-request@ietf.org wrote: > > > If you have received this digest without all the individual message > > attachments you will need to update your digest options in your list > > subscription. To do so, go to > > > > https://www.ietf.org/mailman/listinfo/ipv6 > > > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > > MIME or Plain Text Digests?" to MIME. You can set this option > > globally for all the list digests you receive at this point. > > > > > > > > Send ipv6 mailing list submissions to > > ipv6@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www.ietf.org/mailman/listinfo/ipv6 > > or, via email, send a message with subject or body 'help' to > > ipv6-request@ietf.org > > > > You can reach the person managing the list at > > ipv6-owner@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of ipv6 digest..." > > > > > > Today's Topics: > > > > 1. RE: New Version Notification for > > draft-bonica-6man-frag-deprecate-00.txt (Ronald Bonica) > > 2. Re: New Version Notification for > > draft-bonica-6man-frag-deprecate-00.txt (Fred Baker (fred)) > > 3. Re: New Version Notification for > > draft-bonica-6man-frag-deprecate-00.txt (Ole Troan) > > 4. RE: New Version Notification for > > draft-bonica-6man-frag-deprecate-00.txt (Templin, Fred L) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Mon, 24 Jun 2013 16:38:06 +0000 > > From: Ronald Bonica > > To: George Michaelson , "ipv6@ietf.org 6man-wg" > > > > Subject: RE: New Version Notification for > > draft-bonica-6man-frag-deprecate-00.txt > > Message-ID: > > <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod. > outlook.com> > > > > Content-Type: text/plain; charset="us-ascii" > > > > > > I'd like to understand the basis of these assertions. I believe what I am s > eeing, on the edge, suggests there is in fact V6 fragmentation in both TCP an > d UDP. > > > > > > Hi George, > > > > It would be helpful if you could describe: > > > > > > - Where your observations are being made > > > > - What percentage of traffic is fragmented > > > > - What kinds of packets are being fragmented > > Ron > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: 47/attachment.htm> > > > > ------------------------------ > > > > Message: 2 > > Date: Mon, 24 Jun 2013 16:50:04 +0000 > > From: "Fred Baker (fred)" > > To: Tore Anderson > > Cc: "ipv6@ietf.org 6man-wg" > > Subject: Re: New Version Notification for > > draft-bonica-6man-frag-deprecate-00.txt > > Message-ID: > > <8C48B86A895913448548E6D15DA7553B924440@xmb-rcd-x09.cisco.com> > > Content-Type: text/plain; charset="iso-8859-1" > > > > > > On Jun 24, 2013, at 12:45 AM, Tore Anderson wrote: > > > >> * Fred Baker (fred) > >> > >>> On Jun 22, 2013, at 2:29 AM, Tore Anderson wrote: > >>>> - When a SIIT translator receives an IPv4 packet with DF=0 that > >>>> would result in an IPv6 packet that would exceed the IPv6 link MTU, > >>>> it will split the original packet into IPv6 fragments. > >>> > >>> It *could* fragment the IPv4 packet and send it in two unfragmented > >>> IPv6 packets. > >> > >> Wouldn't doing IPv4 fragmentation before translation to IPv6 be > >> logically identical to this other case I mentioned? > > > > Ah. You're correct. I was thinking about tunnels. > > > >>>> - When a SIIT translator receives an IPv4 fragment, it will translate > >>>> this into one or more IPv6 fragments. > >> > >> I can't see how simply omitting the Fragmentation header in the IPv6 > >> output could work here, as the node receiving those two unfragmented > >> IPv6 packets would see the first one containing a truncated L4 payload, > >> while the second one would be just garbage as it doesn't include a L4 > >> header. > >> > >> Tore > > > > ----------------------------------- > > "We are learning to do a great many clever things...The next great task > > will be to learn not to do them." > > > > - G. K. Chesterton (1874-1936) > > > > > > > > > > > > > > ------------------------------ > > > > Message: 3 > > Date: Mon, 24 Jun 2013 13:37:41 -0400 > > From: Ole Troan > > To: Sheng Jiang > > Cc: "ipv6@ietf.org 6man-wg" , "Fred Baker \(fred\)" > > > > Subject: Re: New Version Notification for > > draft-bonica-6man-frag-deprecate-00.txt > > Message-ID: <34E0F96D-5CCB-4275-AF64-E451B00369E0@employees.org> > > Content-Type: text/plain; charset=us-ascii > > > >>> I suppose I'm the contrarian > >> > >> +1. For me, this draft looks dangerous by proposing to deprecate fragmenta > tion with only one-side observation. This draft does not give enough analysis > on these existing fragmentation use cases, particularly these use cases the > fragments within a single domain. > >> > >> On other side , only disallowing fragmentation to be used among domains ma > y helpful to reduce the operational complex. > > > > this draft should help us tease out answers to the question: > > "if we wanted to deprecate IPv6 fragmentation, could we?" > > > > then when we know the collateral damage, it will be easier to answer the ot > her question: > > "should we deprecate IP layer fragmentation or not". > > > > cheers, > > Ole > > > > ------------------------------ > > > > Message: 4 > > Date: Mon, 24 Jun 2013 17:50:36 +0000 > > From: "Templin, Fred L" > > To: "Fred Baker (fred)" , Tore Anderson > > Cc: "ipv6@ietf.org 6man-wg" > > Subject: RE: New Version Notification for > > draft-bonica-6man-frag-deprecate-00.txt > > Message-ID: > > <2134F8430051B64F815C691A62D983180A93A6@XCH-BLV-504.nw.nos.boeing.com> > > Content-Type: text/plain; charset="us-ascii" > > > > Hi Fred, > > > >> -----Original Message----- > >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > >> Fred Baker (fred) > >> Sent: Sunday, June 23, 2013 4:12 PM > >> To: Tore Anderson > >> Cc: ipv6@ietf.org 6man-wg > >> Subject: Re: New Version Notification for draft-bonica-6man-frag- > >> deprecate-00.txt > >> > >> > >> On Jun 22, 2013, at 2:29 AM, Tore Anderson wrote: > >>> - When a SIIT translator receives an IPv4 packet with DF=0 that would > >>> result in an IPv6 packet that would exceed the IPv6 link MTU, it will > >>> split the original packet into IPv6 fragments. > >> > >> It *could* fragment the IPv4 packet and send it in two unfragmented > >> IPv6 packets. > >> > >>> I cannot support your draft until it discusses or provides solutions > >> for > >>> the above considerations. > >> > >> I'm in a similar case with respect to protocols above IPv6 (OSPF and > >> NFS/UDP come quickly to mind) that depend on fragmentation to deal with > >> the issue. I think the Robustness Principle tells us that such > >> applications SHOULD figure out how to live with PMTU, but it also tells > >> us that we can't deprecate fragmentation unless all known instances > >> that depend on it have defined practical work-arounds. I suspect that > >> this would imply the re-creation of the fragmentation feature in an > >> intermediate protocol, > > > > That is essentially what SEAL does - it provides an intermediate-level > > segmentation and reassembly capability that avoids the pitfalls of IP > > fragmentation. > > > >> which seems like a lot of work with little real gain. > > > > It's not that bad, and IMHO worth it. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > > > > > ------------------------------ > > > > _______________________________________________ > > ipv6 mailing list > > ipv6@ietf.org > > https://www.ietf.org/mailman/listinfo/ipv6 > > > > > > End of ipv6 Digest, Vol 110, Issue 75 > > ************************************* > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jiangsheng@huawei.com Tue Jun 25 19:18:09 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5D621E8109 for ; Tue, 25 Jun 2013 19:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2G0opWRMmc+T for ; Tue, 25 Jun 2013 19:18:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5BD21E804E for ; Tue, 25 Jun 2013 19:18:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASV87272; Wed, 26 Jun 2013 02:17:50 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 26 Jun 2013 03:16:54 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 26 Jun 2013 03:17:35 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Wed, 26 Jun 2013 10:17:30 +0800 From: Sheng Jiang To: "Fred Baker (fred)" , Ole Troan Subject: RE: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHOcdXUWQEkPDtW1Eyd449vM5OFWplGfWwAgADEkkA= Date: Wed, 26 Jun 2013 02:17:30 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923ACA5B5E@nkgeml512-mbx.china.huawei.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9264FE@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B9264FE@xmb-rcd-x09.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 Cc: Arturo Servin , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 02:18:09 -0000 PlBlcnNvbmFsbHksIEkgdGhpbmsgdGhlIHJpZ2h0IHNvbHV0aW9uIGlzIG5vdCB0byBkcm9wIGZy YWdtZW50cywgYnV0IGltcG9zZQ0KPmxpbWl0cyBvbiBzdG9yYWdlIGZvciByZWFzc2VtYmx5LiAN Cg0KKzEuIEFsc28gc29tZSBvcGVyYXRpb24gb3IgaW1wbGVtZW50YXRpb24gcmVjb21tZW5kYXRp b25zLCB3aGljaCB0cnkgdG8gbGltaXQgdGhlIHVzYWdlIG9mIGZyYWdtZW50IGluIGNlcnRhaW4g c2NlbmFyaW9zLCBtYXkgYmUgaGVscGZ1bC4NCg0KU2hlbmcNCg0KPkZyYWdtZW50cyBhcnJpdmlu ZyBpbiBCIHNob3VsZCBjb25zdW1lIGF0DQo+bW9zdCBzb21lIGFtb3VudCBvZiBzdG9yYWdlIGZv ciBzb21lIGFtb3VudCBvZiB0aW1lOyBpZiB0aGUgdGltZSBlbGFwc2VzLA0KPm9uZSBkaXNjYXJk cyB0aGUgc3RhbGUgZnJhZ21lbnRzLCBhbmQgaWYgYSBuZXcgZnJhZ21lbnQgYXJyaXZlcyB3aGVu DQo+cmVzb3VyY2VzIGFyZSBtYXhlZCBvdXQsIG9uZSBkaXNjYXJkcyB0aGUgb2xkZXN0IGZyYWdt ZW50IHByZXNlbnQgKExSVSkuIFdlDQo+Y2FuIGFyZ3VlIGFkIGluZmluaXR1bSBvbiB0aGUgYW1v dW50IG9mIHN0b3JhZ2UgYW5kIHRpbWU7IEkgYWN0dWFsbHkgZG9uJ3QNCj50aGluayB0aGUgZXhh Y3QgbnVtYmVycyBhcmUgaW1wb3J0YW50LiBUaGUgdGltZSBzaG91bGQgYmUgc29tZSBtdWx0aXBs ZSBvZg0KPnRoZSBsYXJnZXN0IFJUVCB0aGUgc3lzdGVtIHNlZXMsIHdoaWNoIGlzIHByb2JhYmx5 IG9uIHRoZSBvcmRlciBvZiBodW5kcmVkcw0KPm9mIG1pbGxpc2Vjb25kcyB0byBzZWNvbmRzLCBh bmQgdGhlIHN0b3JhZ2UgcXVhbnR1bSB0aGF0IGlzIHJlYXNvbmFibGUgaXMNCj5wcm9iYWJseSBt ZWFzdXJlZCBpbiBraWxvYnl0ZXMuIEJleW9uZCBvcmRlcnMgb2YgbWFnbml0dWRlLCBpdCdzIGNv b2sncw0KPmNob2ljZS4NCj4NCj5MaXN0aW5nIHRoZSBmb2xrcyB0aGF0IGhhdmUgdGhhdCBmaXJl d2FsbCBydWxlIC0gSSBjYW4ndCBzYXkuIFRoZXJlIHNlZW1zIHRvIGJlIGENCj53aWRlbHktaGVs ZCBiZWxpZWYgdGhhdCB0aGUgcGVvcGxlIGV4aXN0Lg0KPg0KPk9uIEp1biAyNSwgMjAxMywgYXQg MTE6NTYgQU0sIE9sZSBUcm9hbiA8b3Ryb2FuQGVtcGxveWVlcy5vcmc+IHdyb3RlOg0KPg0KPj4g UmFuZHksDQo+Pg0KPj4+PiBJZiBpdCdzIGEgc3RhdGVtZW50IG9mIGZhY3QsIGl0IHNob3VsZG4n dCB1c2UgUkZDIDIxMTkgbGFuZ3VhZ2UuIEl0DQo+Pj4+IHNob3VsZCBzaW1wbHkgc3RhdGUgdGhl IHRydXRoOiAiTmV0d29yayBvcGVyYXRvcnMgbWlnaHQgZmlsdGVyIElQdjYNCj4+Pj4gZnJhZ21l bnRzLiINCj4+Pg0KPj4+IHMvbWlnaHQvZG8vDQo+Pg0KPj4gd291bGQgeW91IGJlIGFibGUgdG8g YW5zd2VyIHdoeSBhbmQgd2hlcmU/DQo+Pg0KPj4gY2hlZXJzLA0KPj4gT2xlDQo+PiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+PiBpcHY2QGll dGYub3JnDQo+PiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pcHY2DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ SUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+aXB2NkBpZXRmLm9yZw0KPkFk bWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lwdjYNCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K From fred@cisco.com Tue Jun 25 20:30:14 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D9F21E804E for ; Tue, 25 Jun 2013 20:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cV0iRnyJSr1 for ; Tue, 25 Jun 2013 20:30:09 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3764011E80FA for ; Tue, 25 Jun 2013 20:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=220; q=dns/txt; s=iport; t=1372217409; x=1373427009; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5jpFI3n1A9knCdp5JqxgOYEMSNeCq/i3OM0etby4RuE=; b=JIBfKgJZ+8QPgdSHXZzQVt03ZhkrUmF+t4R9nghRQEeXgcil76D+Qxjl dir785h1zmCAKsW0DdRAOw/vaZhFljYfX9T26xifu7i9y3wNbA6/Gx4ti qL4/zsd0mNbfPv+S1cZDWnLYBE0ykVOp3+bbYr/j4JxCQ9TnFdPE3VqH6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FANxfylGtJV2Z/2dsb2JhbABagwl6gj68eoEKFnSCIwEBAQMBOj0CBQsCAQgiFBAyJQIEDgUIiAAGukyPFwIxB4MCYQOpCIMRgig X-IronPort-AV: E=Sophos;i="4.87,941,1363132800"; d="scan'208";a="227244784" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 26 Jun 2013 03:30:08 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5Q3U8Fe021124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Jun 2013 03:30:08 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Tue, 25 Jun 2013 22:30:08 -0500 From: "Fred Baker (fred)" To: Randy Bush Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHOcdXNVc9Jzi6cikCUApHj4sRJiJlHKFIAgACCt4A= Date: Wed, 26 Jun 2013 03:30:07 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> 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.125] Content-Type: text/plain; charset="us-ascii" Content-ID: <7B90C4357D5A4649BEF8D6F69BF8896C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 03:30:14 -0000 On Jun 25, 2013, at 12:42 PM, Randy Bush wrote: > in reality, you can not count on pmtud working One of these days, I'll understand why Linux/FreeBSD/Windows/Apple don't im= plement RFC 4821. = From randy@psg.com Tue Jun 25 21:33:49 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5259711E8106 for ; Tue, 25 Jun 2013 21:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMh4Eaug18-L for ; Tue, 25 Jun 2013 21:33:49 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id E0E3B21E804E for ; Tue, 25 Jun 2013 21:33:48 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UrhQQ-000J0M-JF; Wed, 26 Jun 2013 04:33:46 +0000 Date: Wed, 26 Jun 2013 13:33:45 +0900 Message-ID: From: Randy Bush To: Fred Baker Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt In-Reply-To: <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 04:33:49 -0000 >> in reality, you can not count on pmtud working > One of these days, I'll understand why Linux/FreeBSD/Windows/Apple > don't implement RFC 4821. router code has also been problematic. a mess. but i do not harbor the fantasy that it will be fixed. i might wish it, but i don't expect it. randy From markzzzsmith@yahoo.com.au Wed Jun 26 03:56:54 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E7611E81B5 for ; Wed, 26 Jun 2013 03:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3h37yeC08hso for ; Wed, 26 Jun 2013 03:56:49 -0700 (PDT) Received: from nm35-vm5.bullet.mail.bf1.yahoo.com (nm35-vm5.bullet.mail.bf1.yahoo.com [72.30.238.77]) by ietfa.amsl.com (Postfix) with ESMTP id D1A6D11E81B2 for ; Wed, 26 Jun 2013 03:56:48 -0700 (PDT) Received: from [98.139.212.149] by nm35.bullet.mail.bf1.yahoo.com with NNFMP; 26 Jun 2013 10:56:47 -0000 Received: from [98.139.212.220] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 26 Jun 2013 10:56:47 -0000 Received: from [127.0.0.1] by omp1029.mail.bf1.yahoo.com with NNFMP; 26 Jun 2013 10:56:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 522187.37864.bm@omp1029.mail.bf1.yahoo.com Received: (qmail 94119 invoked by uid 60001); 26 Jun 2013 10:56:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1372244207; bh=YXR9XiIIB+9s4dvBbMdL3ol4Z6RbtKls8qH1fQfTIzI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=a3EV32+CMWMWuBYIrZG+Ar+/iAbThxHuo17TCUhbTuIrgy8CCLb17DtPAauxlYmJRw2b7JqZMpgq2zdH+hukQHFk+2MTvGSUZ/xeaxlH0hglSTGvRVHhClQPu0E9XDJodqHpwhBPJYUxbfo8LVaOR5xFq34Z+BvtFbcVxcx1Y1I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=sj2nepjFVW8jqTYG36Y77BfLueGNaI+GtBM/HyVm+OzK/zAq2xI7YwewblrfQMi9dgWrk4bhLaAQnGebhO5kwqRXbmmnT8jOEYYDvjDJ95n8WlWqLK6hy4UEZjfrvj55yC+bIDEpod1w5RL/zONiHIv1gvdj4G/qjiU3VVdS1VA=; X-YMail-OSG: BaIlYhIVM1mIn2CKMkYG085SoIbc99Sbjpj8Hg39xFriaVN Ex4loKBYTCub6WbOruUHKYOIWxWCmwQq8D936h3b6J9bT.azvNCHYriLoyl0 xwBYHivRTZ_XN3GPN0ZlLFRbNKXGR9MQ9Vb6GGrO5Y8zYGkJJbN6iVsbhM0n fDx0NOuuAcHnptQCQdtqhu.PCPiIYy97reBuBQ0FbQutx06TY0xgZXqsnNV8 IXAbnQfeJXpcTiBhcyW2VtjFjWoWjDqX77Z0j0WVe1Loq5Hzt_aCFhKXFuxk ciF_Lg.oCbxXZzex7DBAy_R0FkdOAQ1IfPZptttL3FJDtLowPRS4eQmYLzcX PysMDMqjl5BM...kNiO13A6cf7m31BTYlI8wAbXnVnuT9hyEV9fQ5ZK8PkMB F3pDDqqyhC9OsbgVwf8BC6bP9PPjoJ5ff0f_4YyDs7jVnKlGuuGxxf1JK78K Itki2_s9COW4XGqYYmr9eLRAykjswTgk9yKnKKIRJGblkX79eevfD6WPqGhN F8cgI4HFdO7.6iOcclfhvjyPgeaQa0MfCNlt7lsonyhhbwA0FMyIHcat9ZJ_ LwvH0XEnlI4XvS.3ahjzQ7adlova5RwD8JQHL3AeP0_tEne0GqoWLtSHVOHP Mx411S.UMInDMpOGOg6VvvR2QS_cLvOwOE9qDjU7W23jgsZYjvIC2myRGtFe zlX1TVDHpiirgvd5lNw-- Received: from [121.200.231.211] by web142505.mail.bf1.yahoo.com via HTTP; Wed, 26 Jun 2013 03:56:47 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBGcmVkIEJha2VyIChmcmVkKSA8ZnJlZEBjaXNjby5jb20.Cj4gVG86IFJhbmR5IEJ1c2ggPHJhbmR5QHBzZy5jb20.Cj4gQ2M6IElQdjYgRGVwbG95bWVudCBQcmV2ZW50aW9uIDxpcHY2QGlldGYub3JnPgo.IFNlbnQ6IFdlZG5lc2RheSwgMjYgSnVuZSAyMDEzIDE6MzAgUE0KPiBTdWJqZWN0OiBSZTogTmV3IFZlcnNpb24JTm90aWZpY2F0aW9uCWZvcgoJZHJhZnQtYm9uaWNhLTZtYW4tZnJhZy1kZXByZWNhdGUtMDAudHh0Cj4gCj4gCj4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.148.554 References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> Message-ID: <1372244207.93298.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Wed, 26 Jun 2013 03:56:47 -0700 (PDT) From: Mark ZZZ Smith Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt To: "Fred Baker \(fred\)" , Randy Bush In-Reply-To: <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 10:56:54 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Fred Baker (fred) =0A> To: Randy Bush =0A> Cc: IPv6 Deployment Preve= ntion =0A> Sent: Wednesday, 26 June 2013 1:30 PM=0A> Subject= : Re: New Version=09Notification=09for=0A=09draft-bonica-6man-frag-deprecat= e-00.txt=0A> =0A> =0A> On Jun 25, 2013, at 12:42 PM, Randy Bush wrote:=0A> =0A>> in reality, you can not count on pmtud working=0A> = =0A> One of these days, I'll understand why Linux/FreeBSD/Windows/Apple don= 't =0A> implement RFC 4821.=A0=0A=0AActually, Linux does, it just needs to = be switched on in=A0/proc/sys/net/ipv4/=0Atcp_mtu_probing - INTEGER Control= s TCP Packetization-Layer Path MTU Discovery. Takes three values: 0 - Disa= bled 1 - Disabled by default, enabled when an ICMP black hole detected 2 - = Always enabled, use initial MSS of tcp_base_mss.=0AI think Windows also imp= lements something similar:=0A"=0ATroubleshooting PMTU Black Hole Routers"= =0Ahttp://technet.microsoft.com/en-us/library/cc958871.aspx=0A=0A=0A=0AOne = of the issues with conventional ICMP PTB based PMTUD is the default rate li= mits on ICMP messages on broadband routers with PPPoE subscribers i.e. dumb= ell [1500][1492][1500] MTUs, slowing down PMTUD. Upping the limit on ICMP P= TBs is an obscure parameter to have to remember to change, and it isn't cle= ar exactly what to change it to - IIRC, the value I've used in the past is = 1000/s up from 10/s. RFC4821 would be nice because it would avoid control p= lane processing that ICMP based PMTUD causes.=0A=0ARegards,=0AMark. From fred@cisco.com Wed Jun 26 08:46:44 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967CF11E8116 for ; Wed, 26 Jun 2013 08:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcNYpzejBr9k for ; Wed, 26 Jun 2013 08:46:27 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB0C21F842E for ; Wed, 26 Jun 2013 08:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2613; q=dns/txt; s=iport; t=1372261587; x=1373471187; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=h1dIl8coZ5t4hONp9LYrqiYv/GOG5tiqWXYIcQF3XbI=; b=a14hgfn4e5K0IkHHgq9/JjflYMdSuMxzpoSVVQn9WRper/WUzRGaFq4B nINhg54tNsVYq6mRpUPA2mmefLqoYZP5tcp6mEdXUQnU/i64SAmrlJK9x T4cFxX3ukq2MQx5AiqJrFXi5yDcOQbnsyIeGf9xk2CxczKZ+HyTrT52yj g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAKALy1GtJXHA/2dsb2JhbABagwkxSb59gQEWdIIjAQEBAwF3AgUHBAIBCBEEAQEBCiQyFwEFCAIEDgUIh3QDCQYMujSMY4ExgQQCMQcGgnxhA4hqjHiDDIp3hSWDEYFpPw X-IronPort-AV: E=Sophos;i="4.87,945,1363132800"; d="scan'208";a="227714273" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 26 Jun 2013 15:46:26 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5QFkQeH028611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Jun 2013 15:46:26 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Wed, 26 Jun 2013 10:46:26 -0500 From: "Fred Baker (fred)" To: Mark ZZZ Smith Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHOcdXNVc9Jzi6cikCUApHj4sRJiJlHKFIAgACCt4CAAHzRgIAAUOqA Date: Wed, 26 Jun 2013 15:46:25 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B9273E2@xmb-rcd-x09.cisco.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <1372244207.93298.YahooMailNeo@web142505.mail.bf1.yahoo.com> In-Reply-To: <1372244207.93298.YahooMailNeo@web142505.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.125] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6C8E6DAAC17C3443846242A457F382CD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 15:46:44 -0000 On Jun 26, 2013, at 3:56 AM, Mark ZZZ Smith wro= te: > ----- Original Message ----- >> From: Fred Baker (fred) >> To: Randy Bush >> Cc: IPv6 Deployment Prevention >> Sent: Wednesday, 26 June 2013 1:30 PM >> Subject: Re: New Version Notification for draft-bonica-6man-frag-depreca= te-00.txt >>=20 >> On Jun 25, 2013, at 12:42 PM, Randy Bush wrote: >>> in reality, you can not count on pmtud working >>=20 >> One of these days, I'll understand why Linux/FreeBSD/Windows/Apple don't= implement RFC 4821.=20 >=20 > Actually, Linux does, it just needs to be switched on in /proc/sys/net/ip= v4/ > tcp_mtu_probing - INTEGER Controls TCP Packetization-Layer Path MTU Disco= very. Takes three values: 0 - Disabled 1 - Disabled by default, enabled wh= en an ICMP black hole detected 2 - Always enabled, use initial MSS of tcp_b= ase_mss. In other words, it's not on. There is some dead code there, but unless you = are the writer of the application or a Linux techie, it doesn't work for yo= u. > I think Windows also implements something similar: > " > Troubleshooting PMTU Black Hole Routers" > http://technet.microsoft.com/en-us/library/cc958871.aspx "To respond effectively to black hole routers, you must enable the Path MTU= BH Detect feature of TCP/IP." In other words, it's not on. There is some dead code there, but unless you = are the writer of the application or a Windows techie, it doesn't work for = you. My question isn't whether there is some experimental code somewhere that co= uld possibly implement it if someone rewrote the application or did some su= rgery in the system's configuration files. If my daughter bought a standard= system and started using it, would it work for her? My question is why fol= ks aren't implementing it in the normal case. Experimental code is kind of = pointless in the general case. > One of the issues with conventional ICMP PTB based PMTUD is the default r= ate limits on ICMP messages on broadband routers with PPPoE subscribers i.e= . dumbell [1500][1492][1500] MTUs, slowing down PMTUD. Upping the limit on = ICMP PTBs is an obscure parameter to have to remember to change, and it isn= 't clear exactly what to change it to - IIRC, the value I've used in the pa= st is 1000/s up from 10/s. RFC4821 would be nice because it would avoid con= trol plane processing that ICMP based PMTUD causes. >=20 > Regards, > Mark. If at first the idea is not absurd, then there is no hope for it. =20 Albert Einstein From Fred.L.Templin@boeing.com Wed Jun 26 09:19:04 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66EF11E8104 for ; Wed, 26 Jun 2013 09:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FiWPh73rQOU for ; Wed, 26 Jun 2013 09:19:00 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 2D68711E80EE for ; Wed, 26 Jun 2013 09:19:00 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r5QGJehD013781 for ; Wed, 26 Jun 2013 09:19:40 -0700 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r5QGJeuj013778 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 26 Jun 2013 09:19:40 -0700 Received: from XCH-BLV-202.nw.nos.boeing.com (10.57.37.69) by XCH-NWHT-05.nw.nos.boeing.com (130.247.25.109) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 26 Jun 2013 09:18:59 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-BLV-202.nw.nos.boeing.com ([169.254.2.60]) with mapi id 14.02.0328.011; Wed, 26 Jun 2013 09:18:58 -0700 From: "Templin, Fred L" To: Usman Latif , "ipv6@ietf.org" Subject: RE: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHOcgltI1L7sow7kkSTr5SDOLoWMJlILJYA Date: Wed, 26 Jun 2013 16:18:57 +0000 Message-ID: <2134F8430051B64F815C691A62D983180AC928@XCH-BLV-504.nw.nos.boeing.com> References: <0F21D0E7-B884-4CC1-B808-E0C6447516B1@yahoo.com> In-Reply-To: <0F21D0E7-B884-4CC1-B808-E0C6447516B1@yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 16:19:04 -0000 Hi, > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Usman Latif > Sent: Tuesday, June 25, 2013 6:07 PM > To: ipv6@ietf.org > Subject: RE: New Version Notification for draft-bonica-6man-frag- > deprecate-00.txt >=20 > I have the following suggestion: >=20 > IPv6 hosts can try to gain knowledge of the path MTU to a destination. That is called RFC4821. > If the path blocks or filters PMTUD etc, then the host should revert to > 1280 bytes else the hosts can use a higher packet size. With RFC4821, hosts can use larger packet sizes (if they are available) even it PMTUD doesn't work. > This mechanism would make Fragment header redundant anyway There have been a number of reasons identified as to why the IPv6 fragment header is still needed. > The only implication of the above mechanism would be that network > providers 'must' support 1280 byte IPv6 packets in all situations That goes without saying. The IPv6 minMTU is 1280 - it's the law. Thanks - Fred fred.l.templin@boeing.com =20 > Regards, > Usman >=20 >=20 > On 25/06/2013, at 5:00 AM, ipv6-request@ietf.org wrote: >=20 > > If you have received this digest without all the individual message > > attachments you will need to update your digest options in your list > > subscription. To do so, go to > > > > https://www.ietf.org/mailman/listinfo/ipv6 > > > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > > MIME or Plain Text Digests?" to MIME. You can set this option > > globally for all the list digests you receive at this point. > > > > > > > > Send ipv6 mailing list submissions to > > ipv6@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www.ietf.org/mailman/listinfo/ipv6 > > or, via email, send a message with subject or body 'help' to > > ipv6-request@ietf.org > > > > You can reach the person managing the list at > > ipv6-owner@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of ipv6 digest..." > > > > > > Today's Topics: > > > > 1. RE: New Version Notification for > > draft-bonica-6man-frag-deprecate-00.txt (Ronald Bonica) > > 2. Re: New Version Notification for > > draft-bonica-6man-frag-deprecate-00.txt (Fred Baker (fred)) > > 3. Re: New Version Notification for > > draft-bonica-6man-frag-deprecate-00.txt (Ole Troan) > > 4. RE: New Version Notification for > > draft-bonica-6man-frag-deprecate-00.txt (Templin, Fred L) > > > > > > --------------------------------------------------------------------- > - > > > > Message: 1 > > Date: Mon, 24 Jun 2013 16:38:06 +0000 > > From: Ronald Bonica > > To: George Michaelson , "ipv6@ietf.org 6man-wg" > > > > Subject: RE: New Version Notification for > > draft-bonica-6man-frag-deprecate-00.txt > > Message-ID: > > > <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod > .outlook.com> > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > > > I'd like to understand the basis of these assertions. I believe what > I am seeing, on the edge, suggests there is in fact V6 fragmentation in > both TCP and UDP. > > > > > > Hi George, > > > > It would be helpful if you could describe: > > > > > > - Where your observations are being made > > > > - What percentage of traffic is fragmented > > > > - What kinds of packets are being fragmented > > Ron > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: archive/web/ipv6/attachments/20130624/2d588547/attachment.htm> > > > > ------------------------------ > > > > Message: 2 > > Date: Mon, 24 Jun 2013 16:50:04 +0000 > > From: "Fred Baker (fred)" > > To: Tore Anderson > > Cc: "ipv6@ietf.org 6man-wg" > > Subject: Re: New Version Notification for > > draft-bonica-6man-frag-deprecate-00.txt > > Message-ID: > > <8C48B86A895913448548E6D15DA7553B924440@xmb-rcd-x09.cisco.com> > > Content-Type: text/plain; charset=3D"iso-8859-1" > > > > > > On Jun 24, 2013, at 12:45 AM, Tore Anderson wrote: > > > >> * Fred Baker (fred) > >> > >>> On Jun 22, 2013, at 2:29 AM, Tore Anderson wrote: > >>>> - When a SIIT translator receives an IPv4 packet with DF=3D0 that > >>>> would result in an IPv6 packet that would exceed the IPv6 link > MTU, > >>>> it will split the original packet into IPv6 fragments. > >>> > >>> It *could* fragment the IPv4 packet and send it in two unfragmented > >>> IPv6 packets. > >> > >> Wouldn't doing IPv4 fragmentation before translation to IPv6 be > >> logically identical to this other case I mentioned? > > > > Ah. You're correct. I was thinking about tunnels. > > > >>>> - When a SIIT translator receives an IPv4 fragment, it will > translate > >>>> this into one or more IPv6 fragments. > >> > >> I can't see how simply omitting the Fragmentation header in the IPv6 > >> output could work here, as the node receiving those two unfragmented > >> IPv6 packets would see the first one containing a truncated L4 > payload, > >> while the second one would be just garbage as it doesn't include a > L4 > >> header. > >> > >> Tore > > > > ----------------------------------- > > "We are learning to do a great many clever things...The next great > task > > will be to learn not to do them." > > > > - G. K. Chesterton (1874-1936) > > > > > > > > > > > > > > ------------------------------ > > > > Message: 3 > > Date: Mon, 24 Jun 2013 13:37:41 -0400 > > From: Ole Troan > > To: Sheng Jiang > > Cc: "ipv6@ietf.org 6man-wg" , "Fred Baker \(fred\)" > > > > Subject: Re: New Version Notification for > > draft-bonica-6man-frag-deprecate-00.txt > > Message-ID: <34E0F96D-5CCB-4275-AF64-E451B00369E0@employees.org> > > Content-Type: text/plain; charset=3Dus-ascii > > > >>> I suppose I'm the contrarian > >> > >> +1. For me, this draft looks dangerous by proposing to deprecate > fragmentation with only one-side observation. This draft does not give > enough analysis on these existing fragmentation use cases, particularly > these use cases the fragments within a single domain. > >> > >> On other side , only disallowing fragmentation to be used among > domains may helpful to reduce the operational complex. > > > > this draft should help us tease out answers to the question: > > "if we wanted to deprecate IPv6 fragmentation, could we?" > > > > then when we know the collateral damage, it will be easier to answer > the other question: > > "should we deprecate IP layer fragmentation or not". > > > > cheers, > > Ole > > > > ------------------------------ > > > > Message: 4 > > Date: Mon, 24 Jun 2013 17:50:36 +0000 > > From: "Templin, Fred L" > > To: "Fred Baker (fred)" , Tore Anderson > > Cc: "ipv6@ietf.org 6man-wg" > > Subject: RE: New Version Notification for > > draft-bonica-6man-frag-deprecate-00.txt > > Message-ID: > > <2134F8430051B64F815C691A62D983180A93A6@XCH-BLV- > 504.nw.nos.boeing.com> > > Content-Type: text/plain; charset=3D"us-ascii" > > > > Hi Fred, > > > >> -----Original Message----- > >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > Of > >> Fred Baker (fred) > >> Sent: Sunday, June 23, 2013 4:12 PM > >> To: Tore Anderson > >> Cc: ipv6@ietf.org 6man-wg > >> Subject: Re: New Version Notification for draft-bonica-6man-frag- > >> deprecate-00.txt > >> > >> > >> On Jun 22, 2013, at 2:29 AM, Tore Anderson wrote: > >>> - When a SIIT translator receives an IPv4 packet with DF=3D0 that > would > >>> result in an IPv6 packet that would exceed the IPv6 link MTU, it > will > >>> split the original packet into IPv6 fragments. > >> > >> It *could* fragment the IPv4 packet and send it in two unfragmented > >> IPv6 packets. > >> > >>> I cannot support your draft until it discusses or provides > solutions > >> for > >>> the above considerations. > >> > >> I'm in a similar case with respect to protocols above IPv6 (OSPF and > >> NFS/UDP come quickly to mind) that depend on fragmentation to deal > with > >> the issue. I think the Robustness Principle tells us that such > >> applications SHOULD figure out how to live with PMTU, but it also > tells > >> us that we can't deprecate fragmentation unless all known instances > >> that depend on it have defined practical work-arounds. I suspect > that > >> this would imply the re-creation of the fragmentation feature in an > >> intermediate protocol, > > > > That is essentially what SEAL does - it provides an intermediate- > level > > segmentation and reassembly capability that avoids the pitfalls of IP > > fragmentation. > > > >> which seems like a lot of work with little real gain. > > > > It's not that bad, and IMHO worth it. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > > > > > ------------------------------ > > > > _______________________________________________ > > ipv6 mailing list > > ipv6@ietf.org > > https://www.ietf.org/mailman/listinfo/ipv6 > > > > > > End of ipv6 Digest, Vol 110, Issue 75 > > ************************************* > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From hagen@jauu.net Wed Jun 26 13:22:12 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5186411E8107 for ; Wed, 26 Jun 2013 13:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTd6ZExftyLy for ; Wed, 26 Jun 2013 13:22:10 -0700 (PDT) Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2001:4d88:1ffa:82:880:aa0:9009:64ae]) by ietfa.amsl.com (Postfix) with ESMTP id BCC6221F9FD9 for ; Wed, 26 Jun 2013 13:22:10 -0700 (PDT) Received: from pfeifer by Chamillionaire.breakpoint.cc with local (Exim 4.72) (envelope-from ) id 1UrwEA-0004Kf-KK; Wed, 26 Jun 2013 22:22:07 +0200 Date: Wed, 26 Jun 2013 22:22:05 +0200 From: Hagen Paul Pfeifer To: Mark Andrews Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Message-ID: <20130626202205.GA6135@virgo.local> References: <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> <51CA2E75.7050204@gmail.com> <20130626000646.047533642802@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130626000646.047533642802@drugs.dv.isc.org> X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 20:22:12 -0000 * Mark Andrews | 2013-06-26 10:06:45 [+1000]: >Named uses IPV6_USE_MIN_MTU=1 to avoid this. It should affect MSS >negotiation but MacOS and FreeBSD are broken (bug fix submitted for >FreeBSD). problem report number or link into GNATS database? From marka@isc.org Wed Jun 26 14:53:41 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B0921F9B57 for ; Wed, 26 Jun 2013 14:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iF+Zqj9fYdOg for ; Wed, 26 Jun 2013 14:53:30 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 76F8421F9AB3 for ; Wed, 26 Jun 2013 14:53:28 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 5E694C9432; Wed, 26 Jun 2013 21:52:54 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372283581; bh=rC4lfnNf86ObpdgZS+kTZPbG7T8Otem7pzbjvCyuYWg=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=UaYgRYDLE0Mky2GOs0VbnuPQeiufJghGGdEBlXxwmXl1KQGV5iWUcH8d12PPnrr2o Pe3UlUX4XB6SHdznAotZu22NCBavTlWsXOMAwZX+ZwkEkVQWihZizxzWDcXxWni357 yCBWW06nMYBqS4hEkEy8x7VVK3327uiKbPH3j2SQ= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 26 Jun 2013 21:52:54 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 415A516009D; Wed, 26 Jun 2013 21:54:08 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id IZvwpxQna-zF; Wed, 26 Jun 2013 21:54:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D8DEC16009C; Wed, 26 Jun 2013 21:54:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JCiBUGLSl9H8; Wed, 26 Jun 2013 21:54:07 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id 8330116009B; Wed, 26 Jun 2013 21:54:07 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 0EA2A364EB2C; Thu, 27 Jun 2013 07:52:51 +1000 (EST) To: Hagen Paul Pfeifer From: Mark Andrews References: <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> <51CA2E75.7050204@gmail.com> <20130626000646.047533642802@drugs.dv.isc.org> <20130626202205.GA6135@virgo.local> Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt In-reply-to: Your message of "Wed, 26 Jun 2013 22:22:05 +0200." <20130626202205.GA6135@virgo.local> Date: Thu, 27 Jun 2013 07:52:51 +1000 Message-Id: <20130626215251.0EA2A364EB2C@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 21:53:44 -0000 In message <20130626202205.GA6135@virgo.local>, Hagen Paul Pfeifer writes: > * Mark Andrews | 2013-06-26 10:06:45 [+1000]: > > >Named uses IPV6_USE_MIN_MTU=1 to avoid this. It should affect MSS > >negotiation but MacOS and FreeBSD are broken (bug fix submitted for > >FreeBSD). > > problem report number or link into GNATS database? http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/173444 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From kauer@biplane.com.au Wed Jun 26 16:40:28 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8C611E8158 for ; Wed, 26 Jun 2013 16:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgMOdDwpRFeM for ; Wed, 26 Jun 2013 16:40:28 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 6F87A11E8156 for ; Wed, 26 Jun 2013 16:40:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUBAL96y1GWZX+7/2dsb2JhbAANToM6Q8AlhVUTiBUFp2CSLZM1A4hqkASKeohF Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.203]) ([150.101.127.187]) by ipmail06.adl2.internode.on.net with ESMTP; 27 Jun 2013 09:10:22 +0930 Message-ID: <1372290019.3215.32.camel@karl> Subject: question re REBIND in RFC 3315 (DHCPv6) From: Karl Auer To: IETF IPv6 Date: Thu, 27 Jun 2013 09:40:19 +1000 Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 23:40:28 -0000 This sorta also relates to the ongoing efforts to redo DHCP failover for v6. See: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requirements-05 I get the feeling I've missed something obvious. The description of how a server should respond to REBIND (RFC 3315 18.2.4) covers these three situations: - the IA is found and the addresses are OK - the IA is found and the addresses are not OK - the IA is NOT found and the addresses are not OK It does NOT appear to cover the situation where the IA is not found and the addresses *are* OK. Yet this situation is the only one where there is any difference between RENEW and REBIND, and the only situation where a client is likely to get to the point of sending a REBIND - i.e., because the server that is holding the IA for the client's addresses is not responding to a RENEW. I'm not sure I see the point of REBIND if no server apart from the original one is ever going to be able to permit continued use of the address. Looking to DHCPv4 for a hint, the description of rebinding in RFC 2131 was: "The DHCPREQUEST from a REBINDING client is intended to accommodate sites that have multiple DHCP servers and a mechanism for maintaining consistency among leases managed by multiple servers. A DHCP server MAY extend a client's lease only if it has local administrative authority to do so. In DHCPv6 (minus failover) there seems to be no "mechanism for maintaining consistency", and there is no mention in RFC 3315 of any additional behaviour involving "local administrative authority". So is REBIND basically pointless in DHCPv6? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 From fgont@si6networks.com Wed Jun 26 17:25:33 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D219611E8170 for ; Wed, 26 Jun 2013 17:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 523NlqbpmGkE for ; Wed, 26 Jun 2013 17:25:33 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id EA3F511E8155 for ; Wed, 26 Jun 2013 17:25:32 -0700 (PDT) Received: from [2001:5c0:1400:a::5f9] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Us01W-0001xE-Sj; Thu, 27 Jun 2013 02:25:19 +0200 Message-ID: <51CB7ECB.2080504@si6networks.com> Date: Thu, 27 Jun 2013 01:52:43 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Mark ZZZ Smith Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <1372244207.93298.YahooMailNeo@web142505.mail.bf1.yahoo.com> In-Reply-To: <1372244207.93298.YahooMailNeo@web142505.mail.bf1.yahoo.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Deployment Prevention , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 00:25:34 -0000 On 06/26/2013 12:56 PM, Mark ZZZ Smith wrote: > > One of the issues with conventional ICMP PTB based PMTUD is the > default rate limits on ICMP messages on broadband routers with PPPoE > subscribers i.e. dumbell [1500][1492][1500] MTUs, slowing down PMTUD. > Upping the limit on ICMP PTBs is an obscure parameter to have to > remember to change, and it isn't clear exactly what to change it to - > IIRC, the value I've used in the past is 1000/s up from 10/s. RFC4821 > would be nice because it would avoid control plane processing that > ICMP based PMTUD causes. Many implementers don't want to rely on a 100% ICMP-less PMTUD because of the potentially-lng convergence time (i.e. time to discover the PMTU). Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From jhw@apple.com Wed Jun 26 17:39:35 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9094C11E817E for ; Wed, 26 Jun 2013 17:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtRDBx70w2S8 for ; Wed, 26 Jun 2013 17:39:29 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2342F11E8177 for ; Wed, 26 Jun 2013 17:39:28 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MP100I1W0HP4N40@mail-out.apple.com> for ipv6@ietf.org; Wed, 26 Jun 2013 17:39:28 -0700 (PDT) X-AuditID: 11807158-b7f486d0000079b6-cd-51cb89c08d85 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id A1.38.31158.0C98BC15; Wed, 26 Jun 2013 17:39:28 -0700 (PDT) Received: from ba0301a-dhcp116.apple.com ([17.193.14.244]) by marigold.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MP10003I0HSNH30@marigold.apple.com> for ipv6@ietf.org; Wed, 26 Jun 2013 17:39:28 -0700 (PDT) Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt From: james woodyatt In-reply-to: <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> Date: Wed, 26 Jun 2013 17:39:27 -0700 Message-id: <3AE1B933-97B8-4312-8829-BC02AB6666CC@apple.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> To: IPv6 Deployment Prevention X-Mailer: Apple Mail (2.1779) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUi2FDconug83Sgwb2tChYvz75ncmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtRFS9gKGtkqNmyYwt7A+Jyli5GTQ0LAROJY6x9GCFtM4sK9 9WwgtpDAJCaJPffZuxi5gOwFTBLfD/1kB0kwC2hJrN95nAnE5hXQk5g5bRJYs7BAsMS7u+vB atgEVCS+Xb4LVsMp4C1x9tFuMJtFQFXi1PkrUHO0JZ68u8AKMcdG4vSFzywQy86xSBzb9R9s qAjQgkPHVjJBXCcrcabnJssERv5ZSO6YheSOWUjmLmBkXsUoUJSak1hpqpdYUJCTqpecn7uJ ERxihRE7GP8vszrEKMDBqMTD+4HxdKAQa2JZcWXuIUYJDmYlEd7QHKAQb0piZVVqUX58UWlO avEhRmkOFiVxXkmv44FCAumJJanZqakFqUUwWSYOTqkGxprUDm8Whbd/D3/u4EgJSb9pz9Pr 3i0S9TdyxY6VB1p3HE3YcutEneH6rQsXHJ9Rcj6g39NZU86b76jhjQkc0xRDRBJP1dzN3aX9 Nanwy7ftq+w1Z7d0B2ke8tyt9Lf3VXnKMeOglee/znR8NLOL+a6fd9mqKy9/RLj9qY57ZcfF Js3BJ95aoMRSnJFoqMVcVJwIACuyQO0tAgAA X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 00:39:35 -0000 On Jun 25, 2013, at 20:30 , Fred Baker (fred) wrote: > On Jun 25, 2013, at 12:42 PM, Randy Bush wrote: >> >> in reality, you can not count on pmtud working In reality, you can not count on the Internet working. Despite that, it mostly works, most everywhere you need it to work, most of the time. Only occasionally, does one encounter failure. > One of these days, I'll understand why Linux/FreeBSD/Windows/Apple don't implement RFC 4821. One of these days, I'll understand why operators don't make it MANDATORY for all hosts on their networks to implement RFC 4821 before they configure their routers to break ICMPv6 path MTU discovery. -- james woodyatt core os networking From marka@isc.org Wed Jun 26 18:04:57 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EF511E8164 for ; Wed, 26 Jun 2013 18:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_WORKS=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HMSNrrcw+9u for ; Wed, 26 Jun 2013 18:04:43 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 5E01F11E8161 for ; Wed, 26 Jun 2013 18:04:43 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id DAE46C94BA; Thu, 27 Jun 2013 01:04:34 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372295083; bh=L+eVw+FnuxklQ8pp9wVD+3+E84d4MGsUo4YOShw6pq0=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=kCWjGwXsEknijsyhXdzdbKcSch5mlcD6tdr6hNSQGWQMkF/dKdgMleK6GPm3IW3js /fw7jbWpnRSGErL6SpnVngXEgz4XFMaEadZMU9G4RgzjLjEZtXOIK1tHp5lPUcW99x 8T/fJnTqkSu2i4erAXnDnlRcitNu3UP+9H0KYr54= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 27 Jun 2013 01:04:34 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 56260160095; Thu, 27 Jun 2013 01:05:49 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 34HwI6ByFo0M; Thu, 27 Jun 2013 01:05:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 085B116009D; Thu, 27 Jun 2013 01:05:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id a8f-cJv-8wfp; Thu, 27 Jun 2013 01:05:48 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id AC01316009C; Thu, 27 Jun 2013 01:05:48 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id EFBA03653CEC; Thu, 27 Jun 2013 11:04:24 +1000 (EST) To: james woodyatt From: Mark Andrews References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <3AE1B933-97B8-4312-8829-BC02AB6666CC@apple.com> Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt In-reply-to: Your message of "Wed, 26 Jun 2013 17:39:27 -0700." <3AE1B933-97B8-4312-8829-BC02AB6666CC@apple.com> Date: Thu, 27 Jun 2013 11:04:24 +1000 Message-Id: <20130627010424.EFBA03653CEC@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 01:04:57 -0000 In message <3AE1B933-97B8-4312-8829-BC02AB6666CC@apple.com>, james woodyatt writes: > On Jun 25, 2013, at 20:30 , Fred Baker (fred) wrote: > > On Jun 25, 2013, at 12:42 PM, Randy Bush wrote: > >> > >> in reality, you can not count on pmtud working > > In reality, you can not count on the Internet working. Despite that, it mostly works, most everywhere you need it to wor > k, most of the time. Only occasionally, does one encounter failure. > > > One of these days, I'll understand why Linux/FreeBSD/Windows/Apple don't implement RFC 4821. > > One of these days, I'll understand why operators don't make it MANDATORY for all hosts on their networks to implement RFC > 4821 before they configure their routers to break ICMPv6 path MTU discovery. I don't know why firewall vendors permit configurations that block icmpv6 PTB while passing ipv6 packets bigger than 1280 over the same interface. Such a configuration is broken. If you don't want to let icmpv6 PTB in then set the MTU to 1280 and generate icmpv6 PTB for anything bigger than 1280 yourself. > -- > james woodyatt > core os networking > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From brian.e.carpenter@gmail.com Wed Jun 26 18:14:11 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F24511E8164 for ; Wed, 26 Jun 2013 18:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOnNmxLmzu7t for ; Wed, 26 Jun 2013 18:14:10 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 86D0211E8161 for ; Wed, 26 Jun 2013 18:14:10 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id bi5so310233pad.18 for ; Wed, 26 Jun 2013 18:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gyKbfNDeq7P/Ip8etm5Dp2Pi7eKX1Hhn+Oc6a26WFyg=; b=p23IIowic1IH9hVnfDouaye3iyTdxFPcKVYgv2TW1Uft0YcwcAkml8KpKa8drtG2gv StIaKzteJweRJ6X5Eyt2qVNIeSND0NxNqDjvNO9QTaQKU34585hTCNo4RExJto9gCegg cbfKCNkrT3cTcb8AeJ27E5QVHi3LE8oeRRt4vpoh/VK5lREtJ4/gc1jg7YW+Pvgz6dyE 8z5XdaavLP+jYHr9YkROJtI6RvoCZLd8a7X66qrmBG9Vo2oqPx4wsUEq8aBCaDM5pKTw EiHqYnitH9+mVKjx+0kF6Li6N9a1Dj6rJI3NOsmT/wOcG0uZoatjviwD/R8aZL/u9s6M cPDA== X-Received: by 10.66.145.98 with SMTP id st2mr3396094pab.24.1372295650113; Wed, 26 Jun 2013 18:14:10 -0700 (PDT) Received: from [172.24.31.170] (wireless-nat-1.auckland.ac.nz. [130.216.30.112]) by mx.google.com with ESMTPSA id pm7sm484264pbb.31.2013.06.26.18.14.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 18:14:09 -0700 (PDT) Message-ID: <51CB91E4.5090603@gmail.com> Date: Thu, 27 Jun 2013 13:14:12 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: draft-bonica-6man-frag-deprecate References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 01:14:11 -0000 Cutting to the chase, and assuming that the next version will have more analysis and observational evidence, I'm thinking something like the following: 3. Recommendation This memo deprecates IPv6 fragmentation and the IPv6 fragment header. Application and transport layer protocols SHOULD support effective PMTU discovery [RFC4821], since ICMP-based PMTU discovery [RFC1981] is unreliable. Any application or transport layer protocol that cannot support effective PMTU discovery MUST NOT in any circumstances send IPv6 packets that exceed the IPv6 minimum MTU of 1280 bytes. IPv6 stacks and forwarding nodes SHOULD continue to support inbound fragmented IPv6 packets as specified in [RFC2460]. However, this requirement exceeds the capability of some types of forwarding node such as firewalls and load balancers. Therefore implementers and operators need to be aware that on many paths through the Internet, IPv6 fragmentation will fail. Legacy applications and transport layer protocols that do not conform to the previous paragraph can expect connectivity failures as a result. From randy@psg.com Wed Jun 26 18:43:08 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23DEF11E815C for ; Wed, 26 Jun 2013 18:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RQtci7WaQnq for ; Wed, 26 Jun 2013 18:43:07 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 916BA11E8103 for ; Wed, 26 Jun 2013 18:43:07 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Us1En-000Ncq-4R; Thu, 27 Jun 2013 01:43:05 +0000 Date: Thu, 27 Jun 2013 10:43:04 +0900 Message-ID: From: Randy Bush To: james woodyatt Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt In-Reply-To: <3AE1B933-97B8-4312-8829-BC02AB6666CC@apple.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <3AE1B933-97B8-4312-8829-BC02AB6666CC@apple.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 01:43:08 -0000 >> in reality, you can not count on pmtud working > > In reality, you can not count on the Internet working. Despite that, > it mostly works, most everywhere you need it to work, most of the > time. Only occasionally, does one encounter failure. unlike pmtud > One of these days, I'll understand why operators don't make it > MANDATORY good luck with that randy From fred@cisco.com Wed Jun 26 21:14:59 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D66821F99E2 for ; Wed, 26 Jun 2013 21:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.229 X-Spam-Level: X-Spam-Status: No, score=-110.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PW+ji6VdSO6O for ; Wed, 26 Jun 2013 21:14:53 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A338521F99DA for ; Wed, 26 Jun 2013 21:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1440; q=dns/txt; s=iport; t=1372306493; x=1373516093; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HweSoH5kWjdyzLAeQGcq19dpkatM6Lv5Sotd/LWkmRk=; b=h81AHNJ5eJbyKw5A3EHHb5QgAouSeOJBNl4dGuTYriAnfBSChVna2aBb xtNUwWw7Gw8LRKCKTBg2JIeHKU9J3+/jA8nIlu7lJkqy/fqsxDzHmGO3o FN5BO+sRrWyx1dmAVcOkeJrJSrZ6jMAVmjtcIcR7jz2u5IlD6l/85dxMS k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFADS7y1GtJXHB/2dsb2JhbABbgwl6vwZ/FnSCIwEBAQMBbQoCBQsCAQgOCgokMiUCBA4FCIgABroVjh4FgQExB4MCYQOIaqAggxGBaQgXIA X-IronPort-AV: E=Sophos;i="4.87,949,1363132800"; d="scan'208";a="227763446" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 27 Jun 2013 04:14:43 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5R4EhPu025079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Jun 2013 04:14:43 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Wed, 26 Jun 2013 23:14:43 -0500 From: "Fred Baker (fred)" To: Fernando Gont Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHOcdXNVc9Jzi6cikCUApHj4sRJiJlHKFIAgACCt4CAAHzRgIAA2MuAgABJMwA= Date: Thu, 27 Jun 2013 04:14:43 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B929044@xmb-rcd-x09.cisco.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <1372244207.93298.YahooMailNeo@web142505.mail.bf1.yahoo.com> <51CB7ECB.2080504@si6networks.com> In-Reply-To: <51CB7ECB.2080504@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.125] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <801E63D7E8F8574CA4895341C560FAB0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 04:14:59 -0000 On Jun 26, 2013, at 4:52 PM, Fernando Gont wrote: > On 06/26/2013 12:56 PM, Mark ZZZ Smith wrote: >>=20 >> One of the issues with conventional ICMP PTB based PMTUD is the >> default rate limits on ICMP messages on broadband routers with PPPoE >> subscribers i.e. dumbell [1500][1492][1500] MTUs, slowing down PMTUD. >> Upping the limit on ICMP PTBs is an obscure parameter to have to >> remember to change, and it isn't clear exactly what to change it to - >> IIRC, the value I've used in the past is 1000/s up from 10/s. RFC4821 >> would be nice because it would avoid control plane processing that >> ICMP based PMTUD causes. >=20 > Many implementers don't want to rely on a 100% ICMP-less PMTUD because > of the potentially-lng convergence time (i.e. time to discover the PMTU). And when ICMP is blocked, and the convergence interval is infinite...? > 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 >=20 > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 ----------------------------------- "We are learning to do a great many clever things...The next great task will be to learn not to do them." - G. K. Chesterton (1874-1936) From fgont@si6networks.com Wed Jun 26 21:52:15 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19E721F9A81 for ; Wed, 26 Jun 2013 21:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frKMe3rXFlhH for ; Wed, 26 Jun 2013 21:52:15 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 17B7321F9A6F for ; Wed, 26 Jun 2013 21:52:14 -0700 (PDT) Received: from [2001:5c0:1400:a::5f9] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Us4Bi-0000lc-S6; Thu, 27 Jun 2013 06:52:06 +0200 Message-ID: <51CBC4F5.10807@si6networks.com> Date: Thu, 27 Jun 2013 06:52:05 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Fred Baker (fred)" Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <1372244207.93298.YahooMailNeo@web142505.mail.bf1.yahoo.com> <51CB7ECB.2080504@si6networks.com> <8C48B86A895913448548E6D15DA7553B929044@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B929044@xmb-rcd-x09.cisco.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Deployment Prevention X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 04:52:15 -0000 On 06/27/2013 06:14 AM, Fred Baker (fred) wrote: > > On Jun 26, 2013, at 4:52 PM, Fernando Gont > wrote: > >> On 06/26/2013 12:56 PM, Mark ZZZ Smith wrote: >>> >>> One of the issues with conventional ICMP PTB based PMTUD is the >>> default rate limits on ICMP messages on broadband routers with PPPoE >>> subscribers i.e. dumbell [1500][1492][1500] MTUs, slowing down PMTUD. >>> Upping the limit on ICMP PTBs is an obscure parameter to have to >>> remember to change, and it isn't clear exactly what to change it to - >>> IIRC, the value I've used in the past is 1000/s up from 10/s. RFC4821 >>> would be nice because it would avoid control plane processing that >>> ICMP based PMTUD causes. >> >> Many implementers don't want to rely on a 100% ICMP-less PMTUD because >> of the potentially-lng convergence time (i.e. time to discover the PMTU). > > And when ICMP is blocked, and the convergence interval is infinite...? Not sure what you mean. There ae two ways to implement RFC4821: 1) As a complete replacement of ICMP-based PMTUD, or, 2) For PMTUD back-whole detection Implementers I've talked to are fine with 2, but not with 1. If you process ICMPs, then when ICMP errors are received you don't need to rely on timeouts. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From hagen@jauu.net Wed Jun 26 22:52:46 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A650321F9C1D for ; Wed, 26 Jun 2013 22:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5AHD4f5x-cO for ; Wed, 26 Jun 2013 22:52:46 -0700 (PDT) Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2001:4d88:1ffa:82:880:aa0:9009:64ae]) by ietfa.amsl.com (Postfix) with ESMTP id 1772F21F9BF3 for ; Wed, 26 Jun 2013 22:52:45 -0700 (PDT) Received: from pfeifer by Chamillionaire.breakpoint.cc with local (Exim 4.72) (envelope-from ) id 1Us58M-0006nZ-Rj; Thu, 27 Jun 2013 07:52:43 +0200 Date: Thu, 27 Jun 2013 07:52:41 +0200 From: Hagen Paul Pfeifer To: Brian E Carpenter Subject: Re: draft-bonica-6man-frag-deprecate Message-ID: <20130627055241.GA3358@virgo.local> References: <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <51CB91E4.5090603@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51CB91E4.5090603@gmail.com> X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 05:52:46 -0000 * Brian E Carpenter | 2013-06-27 13:14:12 [+1200]: >Cutting to the chase, and assuming that the next version >will have more analysis and observational evidence, I'm thinking >something like the following: Nearly, skip five words: "and the IPv6 fragment header". One more time: a client of mine deploy sensor network applications using fragmentation. Not just for fun, no because of 2460. Think about this: if this ID becomes an RFC (or even earlier) someone posts a patch removing fragmentation from Linux/*BSD,3 month later all distribution ship a fragmentation/reassembly less stack. This breaks application, application which cannot changed because they are hard wired into silicon (DSP). This incompatible protocol break needs more time to mature out everywhere. I support the deprecation of fragmentation, but we need reassembling for a transition period - not fragmentation. But this is not in contradiction with the current effort here - everybody can be happy. My recommendation (slightly changed version, see second sentence): 3. Recommendation This memo deprecates IPv6 fragmentation. Host SHOULD still be able to reassembly fragmented packets. Application and transport layer protocols SHOULD support effective PMTU discovery [RFC4821], since ICMP-based PMTU discovery [RFC1981] is unreliable. Any application or transport layer protocol that cannot support effective PMTU discovery MUST NOT in any circumstances send IPv6 packets that exceed the IPv6 minimum MTU of 1280 bytes. IPv6 stacks and forwarding nodes SHOULD continue to support inbound fragmented IPv6 packets as specified in [RFC2460]. However, this requirement exceeds the capability of some types of forwarding node such as firewalls and load balancers. Therefore implementers and operators need to be aware that on many paths through the Internet, IPv6 fragmentation will fail. Legacy applications and transport layer protocols that do not conform to the previous paragraph can expect connectivity failures as a result. Hagen From marc.lampo.ietf@gmail.com Wed Jun 26 23:39:28 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689F421F9C5B for ; Wed, 26 Jun 2013 23:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9DtBxkvYxn7 for ; Wed, 26 Jun 2013 23:39:27 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7613021F9C53 for ; Wed, 26 Jun 2013 23:39:27 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id id13so126564vcb.27 for ; Wed, 26 Jun 2013 23:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=io7hyNgUSiJDD9MhPTfI2hq4ZAbcyS7KRyi7oxiIO0M=; b=gdHW82N2Dmdfp0QKhAe+7YLCIEyA8P5gIMl3NER4Scnw/0j3Zm7plUXRMFSnC/pDX4 ldpFpQOappSbnagjgNy06ESc08YIIUQXghKwNP2RAJrX5tW0o8Y1MudcbZMaeU68GK+z x9hgMxpxsEarJXKPHlawK2UZD23GrnkHfKjxaP59Rp7E9uo1E7mKP15Vsn+eTqJBNUFW Na+DfGaOpuu7DRhewAAT1NVBl3cRY5fW/lowKj0VnnUGPD/RZZ93t/tWC11GUosK8ZEg m3TeDWeo7nD73hHbx3nrb2trTlvU4wfybh80rXVDAV+uweZB3ZyodkopgkAG1vFHikyw 1ocQ== MIME-Version: 1.0 X-Received: by 10.58.181.225 with SMTP id dz1mr2972313vec.95.1372315164868; Wed, 26 Jun 2013 23:39:24 -0700 (PDT) Received: by 10.59.2.100 with HTTP; Wed, 26 Jun 2013 23:39:24 -0700 (PDT) In-Reply-To: <20130627055241.GA3358@virgo.local> References: <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <51CB91E4.5090603@gmail.com> <20130627055241.GA3358@virgo.local> Date: Thu, 27 Jun 2013 08:39:24 +0200 Message-ID: Subject: Re: draft-bonica-6man-frag-deprecate From: Marc Lampo To: Hagen Paul Pfeifer Content-Type: multipart/alternative; boundary=047d7b605020ec079904e01d05ea Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 06:39:28 -0000 --047d7b605020ec079904e01d05ea Content-Type: text/plain; charset=ISO-8859-1 > This incompatible protocol break ... Incompatible protocol or is it time for the next IP version, without fragmentation right from the beginning ? As the reasons, stated in the draft, also apply to IPv4. Would we think about deprecating the use of fragmentation fields in the IPv4 header and recommending they MUST always be set to 0 ? Kind regards, Marc Lampo On Thu, Jun 27, 2013 at 7:52 AM, Hagen Paul Pfeifer wrote: > * Brian E Carpenter | 2013-06-27 13:14:12 [+1200]: > > >Cutting to the chase, and assuming that the next version > >will have more analysis and observational evidence, I'm thinking > >something like the following: > > Nearly, skip five words: "and the IPv6 fragment header". One more time: a > client of mine deploy sensor network applications using fragmentation. Not > just for fun, no because of 2460. Think about this: if this ID becomes an > RFC > (or even earlier) someone posts a patch removing fragmentation from > Linux/*BSD,3 month later all distribution ship a fragmentation/reassembly > less > stack. This breaks application, application which cannot changed because > they > are hard wired into silicon (DSP). This incompatible protocol break needs > more > time to mature out everywhere. > > I support the deprecation of fragmentation, but we need reassembling for a > transition period - not fragmentation. But this is not in contradiction > with > the current effort here - everybody can be happy. My recommendation > (slightly > changed version, see second sentence): > > 3. Recommendation > > This memo deprecates IPv6 fragmentation. Host SHOULD still be > able to > reassembly fragmented packets. Application and transport layer > protocols > SHOULD support effective PMTU discovery [RFC4821], since > ICMP-based PMTU > discovery [RFC1981] is unreliable. Any application or transport > layer > protocol that cannot support effective PMTU discovery MUST NOT in > any > circumstances send IPv6 packets that exceed the IPv6 minimum MTU > of 1280 > bytes. > > IPv6 stacks and forwarding nodes SHOULD continue to support inbound > fragmented IPv6 packets as specified in [RFC2460]. However, this > requirement exceeds the capability of some types of forwarding node > such as firewalls and load balancers. Therefore implementers and > operators need to be aware that on many paths through the Internet, > IPv6 fragmentation will fail. Legacy applications and transport layer > protocols that do not conform to the previous paragraph can expect > connectivity failures as a result. > > > > Hagen > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --047d7b605020ec079904e01d05ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    > This incompatible protocol break = ...

    Incompatible protocol or is it time for the next IP = version, without fragmentation right from the beginning ?


    As the reasons, stated in the draft, also apply to IPv4.=A0 Would we think = about deprecating the use of fragmentation fields in the IPv4 header and re= commending they MUST always be set to 0 ?


    Kind regards,
    Marc Lampo


    On Thu, Jun 27, 2013 at 7:52 AM, Hagen Paul Pfeifer <hagen@jauu.ne= t> wrote:
    * Brian E Carpenter | 2013-06-27 13:14:12 [+= 1200]:

    >Cutting to the chase, and assuming that the next version
    >will have more analysis and observational evidence, I'm thinking >something like the following:

    Nearly, skip five words: "and the IPv6 fragment header". On= e more time: a
    client of mine deploy sensor network applications using fragmentation. Not<= br> just for fun, no because of 2460. Think about this: if this ID becomes an R= FC
    (or even earlier) someone posts a patch removing fragmentation from
    Linux/*BSD,3 month later all distribution ship a fragmentation/reassembly l= ess
    stack. This breaks application, application which cannot changed because th= ey
    are hard wired into silicon (DSP). This incompatible protocol break needs m= ore
    time to mature out everywhere.

    I support the deprecation of fragmentation, but we need reassembling for a<= br> transition period - not fragmentation. But this is not in contradiction wit= h
    the current effort here - everybody can be happy. My recommendation (slight= ly
    changed version, see second sentence):

    3. =A0Recommendation

    =A0 =A0 =A0 =A0 =A0This memo deprecates IPv6 fragmentation. Host SHOULD sti= ll be able to
    =A0 =A0 =A0 =A0 =A0reassembly fragmented packets. =A0Application and transp= ort layer protocols
    =A0 =A0 =A0 =A0 =A0SHOULD support effective PMTU d= iscovery [RFC4821], since ICMP-based PMTU
    =A0 =A0 =A0 =A0 =A0discovery [RFC1981] is unreliable. Any application or tr= ansport layer
    =A0 =A0 =A0 =A0 =A0protocol that cannot support effective PMTU discovery MU= ST NOT in any
    =A0 =A0 =A0 =A0 =A0circumstances send IPv6 packets that exceed the IPv6 min= imum MTU of 1280
    =A0 =A0 =A0 =A0 =A0bytes.

    =A0 =A0IPv6 stacks and forwarding nodes SHOULD continue to support inbound<= br> =A0 =A0fragmented IPv6 packets as specified in [RFC2460]. However, this
    =A0 =A0requirement exceeds the capability of some types of forwarding node<= br> =A0 =A0such as firewalls and load balancers. Therefore implementers and
    =A0 =A0operators need to be aware that on many paths through the Internet,<= br> =A0 =A0IPv6 fragmentation will fail. Legacy applications and transport laye= r
    =A0 =A0protocols that do not conform to the previous paragraph can expect =A0 =A0connectivity failures as a result.



    Hagen
    ---------------------= -----------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------

    --047d7b605020ec079904e01d05ea-- From rdroms.ietf@gmail.com Thu Jun 27 04:17:48 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD58321F9A9B for ; Thu, 27 Jun 2013 04:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.2 X-Spam-Level: X-Spam-Status: No, score=-102.2 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzFQeg8Kv51b for ; Thu, 27 Jun 2013 04:17:48 -0700 (PDT) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D357421F9A92 for ; Thu, 27 Jun 2013 04:17:47 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 5so178967qeb.3 for ; Thu, 27 Jun 2013 04:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=hWBO8Ewzjx9gfrpVTW/CzMPQgQA/LPgWHt0nChDcIVg=; b=ap6/rDL9bYMVk10KyXzpNaPvpb9Rpq5fC2fnxEW20xpitj0IYFxU5bxf9trbYK4pU6 alpVHZss1IcwMRWiTVWRsR0Xh8iaQ1kuKTGRXGJX0y4xaa/ROgLkIl9GIeC+U7SrdQ4X Ln5AFk4VFyfZrYCPg9grxjaxxPhu00UZZmjz0yyUXiQC5mfSDr4TlOgOFz+ke97TFYDN 6hFaQzFKPY84RRx96HuQVi/G2yLqCgfU5HRY4XYrOJkVkoRS2VlKgaZ3/qKp3w62Cj7k 4tScqBELd2/Jb+4X5eCsW5/Xzcitsg85VCB8WChgQAAhUbofrLwBtD+o2drnp6zBtEGx vhhw== X-Received: by 10.229.170.20 with SMTP id b20mr2401012qcz.19.1372331866280; Thu, 27 Jun 2013 04:17:46 -0700 (PDT) Received: from ?IPv6:2001:4830:16b1:1:cc54:9e96:2745:ce28? ([2001:4830:16b1:1:cc54:9e96:2745:ce28]) by mx.google.com with ESMTPSA id r10sm3231099qeu.4.2013.06.27.04.17.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Jun 2013 04:17:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: question re REBIND in RFC 3315 (DHCPv6) From: Ralph Droms In-Reply-To: <1372290019.3215.32.camel@karl> Date: Thu, 27 Jun 2013 07:17:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3ED742F1-C82A-43E3-A2CD-CAD8F1E283B1@gmail.com> References: <1372290019.3215.32.camel@karl> To: Karl Auer X-Mailer: Apple Mail (2.1508) Cc: IETF IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 11:17:49 -0000 On Jun 26, 2013, at 7:40 PM 6/26/13, Karl Auer = wrote: > This sorta also relates to the ongoing efforts to redo DHCP failover = for > v6. See: >=20 >=20 > = http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requirements-05 >=20 > I get the feeling I've missed something obvious. >=20 > The description of how a server should respond to REBIND (RFC 3315 > 18.2.4) covers these three situations: > - the IA is found and the addresses are OK > - the IA is found and the addresses are not OK > - the IA is NOT found and the addresses are not OK >=20 > It does NOT appear to cover the situation where the IA is not found = and > the addresses *are* OK. Yet this situation is the only one where there > is any difference between RENEW and REBIND, and the only situation = where > a client is likely to get to the point of sending a REBIND - i.e., > because the server that is holding the IA for the client's addresses = is > not responding to a RENEW. There is another difference between REBIND and RENEW: the client = includes the Server Identifier of the server from which the client = received the IA in the RENEW message (but not the REBIND). In = multi-server deployments, a RENEW is processed only by the relevant = server, while a REBIND can be processed by any server. The = differentiation is specified up in sections 15.5 and 15.6: 15.6. Renew Message Clients MUST discard any received Renew messages. Servers MUST discard any received Renew message that meets any of the following conditions: - the message does not include a Server Identifier option. - the contents of the Server Identifier option does not match the server's identifier. - the message does not include a Client Identifier option. 15.7. Rebind Message Clients MUST discard any received Rebind messages. Servers MUST discard any received Rebind messages that do not include a Client Identifier option or that do include a Server Identifier option. >=20 > I'm not sure I see the point of REBIND if no server apart from the > original one is ever going to be able to permit continued use of the > address. The idea is that some external data channel is used to replicate the IA = binding from the responsible server to all the other servers. >=20 > Looking to DHCPv4 for a hint, the description of rebinding in RFC 2131 > was: >=20 > "The DHCPREQUEST from a REBINDING client is intended to accommodate > sites that have multiple DHCP servers and a mechanism for > maintaining consistency among leases managed by multiple servers. > A DHCP server MAY extend a client's lease only if it has local > administrative authority to do so. >=20 > In DHCPv6 (minus failover) there seems to be no "mechanism for > maintaining consistency", and there is no mention in RFC 3315 of any > additional behaviour involving "local administrative authority". There's no such mechanism defined in DHCPv4 (RFC 2131 and RFC 2132), = either. It may be an oversight that it is not mentioned as "out of = scope" in RFC 3315. - Ralph >=20 > So is REBIND basically pointless in DHCPv6? >=20 > Regards, K. >=20 > --=20 > = ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer@biplane.com.au) > http://www.biplane.com.au/kauer > http://twitter.com/kauer389 >=20 > GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A > Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From volz@cisco.com Thu Jun 27 04:26:32 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BB521F997D for ; Thu, 27 Jun 2013 04:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkCeShVcE-na for ; Thu, 27 Jun 2013 04:26:28 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C87C021F99AB for ; Thu, 27 Jun 2013 04:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14539; q=dns/txt; s=iport; t=1372332387; x=1373541987; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+M+N0SIjAle63Zpq877MBNpRE1r5d04cwPyue3mlIKc=; b=YujkhV//QcpboY2TpOdjM3xz16iQCcbV6cTiJ1ZQNJxHxzy9Lm0KqqYW qLnIpxTTzUKzaCpW37uKsN/fVDa4hKCVOk+JHLEHzqwcGeB3Sj4vnJQLL /jo20XJcccWOpamBc8k7XigJPVsw1MHvrCaKo6FXTboVZnfmuFQtMmVAC c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoEFAG4gzFGtJXG+/2dsb2JhbABbgkVEMUO2Tog7fhZ0giQBAQQBAQFrCxACAQgOMQchBgsUEQIEDgUJh3MDDwcFsV8NiFKMbYE2gS4EB4MCYQOVXoFngSmKdwOFIoMRgXE X-IronPort-AV: E=Sophos;i="4.87,951,1363132800"; d="scan'208,217";a="228101546" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 27 Jun 2013 11:26:27 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5RBQRq5018462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Jun 2013 11:26:27 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 27 Jun 2013 06:26:26 -0500 From: "Bernie Volz (volz)" To: Ralph Droms Subject: Re: question re REBIND in RFC 3315 (DHCPv6) Thread-Topic: question re REBIND in RFC 3315 (DHCPv6) Thread-Index: AQHOcygK10Y+ta1O/UyOynXqD99giJlJbAKl Date: Thu, 27 Jun 2013 11:26:26 +0000 Message-ID: <6ABC1135-2AB2-43EC-A863-ACFFF546997B@cisco.com> References: <1372290019.3215.32.camel@karl>, <3ED742F1-C82A-43E3-A2CD-CAD8F1E283B1@gmail.com> In-Reply-To: <3ED742F1-C82A-43E3-A2CD-CAD8F1E283B1@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6ABC11352AB243ECA863ACFFF546997Bciscocom_" MIME-Version: 1.0 Cc: IETF IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 11:26:32 -0000 --_000_6ABC11352AB243ECA863ACFFF546997Bciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've been trying to get the DHC WG to address this issue but there appears = to be zero interest in doing anything about it - see http://www.ietf.org/ma= il-archive/web/dhcwg/current/msg14315.html. - Bernie (from iPad) On Jun 27, 2013, at 7:18 AM, "Ralph Droms" > wrote: On Jun 26, 2013, at 7:40 PM 6/26/13, Karl Auer > wrote: This sorta also relates to the ongoing efforts to redo DHCP failover for v6. See: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requirements-05 I get the feeling I've missed something obvious. The description of how a server should respond to REBIND (RFC 3315 18.2.4) covers these three situations: - the IA is found and the addresses are OK - the IA is found and the addresses are not OK - the IA is NOT found and the addresses are not OK It does NOT appear to cover the situation where the IA is not found and the addresses *are* OK. Yet this situation is the only one where there is any difference between RENEW and REBIND, and the only situation where a client is likely to get to the point of sending a REBIND - i.e., because the server that is holding the IA for the client's addresses is not responding to a RENEW. There is another difference between REBIND and RENEW: the client includes t= he Server Identifier of the server from which the client received the IA in= the RENEW message (but not the REBIND). In multi-server deployments, a RE= NEW is processed only by the relevant server, while a REBIND can be process= ed by any server. The differentiation is specified up in sections 15.5 and= 15.6: 15.6. Renew Message Clients MUST discard any received Renew messages. Servers MUST discard any received Renew message that meets any of the following conditions: - the message does not include a Server Identifier option. - the contents of the Server Identifier option does not match the server's identifier. - the message does not include a Client Identifier option. 15.7. Rebind Message Clients MUST discard any received Rebind messages. Servers MUST discard any received Rebind messages that do not include a Client Identifier option or that do include a Server Identifier option. I'm not sure I see the point of REBIND if no server apart from the original one is ever going to be able to permit continued use of the address. The idea is that some external data channel is used to replicate the IA bin= ding from the responsible server to all the other servers. Looking to DHCPv4 for a hint, the description of rebinding in RFC 2131 was: "The DHCPREQUEST from a REBINDING client is intended to accommodate sites that have multiple DHCP servers and a mechanism for maintaining consistency among leases managed by multiple servers. A DHCP server MAY extend a client's lease only if it has local administrative authority to do so. In DHCPv6 (minus failover) there seems to be no "mechanism for maintaining consistency", and there is no mention in RFC 3315 of any additional behaviour involving "local administrative authority". There's no such mechanism defined in DHCPv4 (RFC 2131 and RFC 2132), either= . It may be an oversight that it is not mentioned as "out of scope" in RFC= 3315. - Ralph So is REBIND basically pointless in DHCPv6? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --_000_6ABC11352AB243ECA863ACFFF546997Bciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    I've been trying to get the DHC WG to address this issue but there app= ears to be zero interest in doing anything about it - see http://www.ietf.org/mail-archive/web/dhcwg/current/msg14315.ht= ml.

    - Bernie (from iPad)

    On Jun 27, 2013, at 7:18 AM, "Ralph Droms" <rdroms.ietf@gmail.com> wrote:


    On Jun 26, 2013, at 7:40 PM 6/26/13, Karl Auer <kauer@biplane.com.au> wrote:

    This sorta also relates to the ongoing effo= rts to redo DHCP failover for
    v6. See:


    http://tools.ietf.org/html/draft= -ietf-dhc-dhcpv6-failover-requirements-05

    I get the feeling I've missed something obv= ious.

    The description of how a server should resp= ond to REBIND (RFC 3315
    18.2.4) covers these three situations:
    - the IA is found and the addresses are OK<= /span>
    - the IA is found and the addresses are not= OK
    - the IA is NOT found and the addresses are= not OK

    It does NOT appear to cover the situation w= here the IA is not found and
    the addresses *are* OK. Yet this situation = is the only one where there
    is any difference between RENEW and REBIND,= and the only situation where
    a client is likely to get to the point of s= ending a REBIND - i.e.,
    because the server that is holding the IA f= or the client's addresses is
    not responding to a RENEW.

    There is another difference between REBIND and RENEW: the client incl= udes the Server Identifier of the server from which the client received the= IA in the RENEW message (but not the REBIND).  In multi-server deploy= ments, a RENEW is processed only by the relevant server, while a REBIND can be processed by any server.  The = differentiation is specified up in sections 15.5 and 15.6:

    15.6. Renew Message

      Clients MUST discard any received Renew messages.<= br>
      Servers MUST discard any received Renew message that meet= s any of the
      following conditions:

      -  the message does not include a Server Identifier = option.

      -  the contents of the Server Identifier option does= not match the
         server's identifier.

      -  the message does not include a Client Identifier = option.

    15.7. Rebind Message

      Clients MUST discard any received Rebind messages.=

      Servers MUST discard any received Rebind messages that do= not include
      a Client Identifier option or that do include a Server Id= entifier
      option.


    I'm not sure I see the point of REBIND if n= o server apart from the
    original one is ever going to be able to pe= rmit continued use of the
    address.

    The idea is that some external data channel is used to replicate the = IA binding from the responsible server to all the other servers.


    Looking to DHCPv4 for a hint, the descripti= on of rebinding in RFC 2131
    was:

     "The DHCPREQUEST from a REBINDIN= G client is intended to accommodate
      sites that have multiple DHCP s= ervers and a mechanism for
      maintaining consistency among l= eases managed by multiple servers.
      A DHCP server MAY extend a clie= nt's lease only if it has local
      administrative authority to do = so.

    In DHCPv6 (minus failover) there seems to b= e no "mechanism for
    maintaining consistency", and there is= no mention in RFC 3315 of any
    additional behaviour involving "local = administrative authority".

    There's no such mechanism defined in DHCPv4 (RFC 2131 and RFC 2132), = either.  It may be an oversight that it is not mentioned as "out = of scope" in RFC 3315.

    - Ralph


    So is REBIND basically pointless in DHCPv6?=

    Regards, K.

    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Karl Auer (kauer@biplane.com.au)
    http://www.biplane.com.au/kauer
    htt= p://twitter.com/kauer389

    GPG fingerprint: B862 FB15 FE96 4961 BC62 1= A40 6239 1208 9865 5F9A
    Old fingerprint: AE1D 4868 6420 AD9A A698 5= 251 1699 7B78 4EEE 6017

    -------------------------------------------= -------------------------
    IETF IPv6 working group mailing list=
    ipv6@ietf.= org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    -------------------------------------------= -------------------------

    --------------------------------------------------------------------<= /span>
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------<= /span>
    --_000_6ABC11352AB243ECA863ACFFF546997Bciscocom_-- From kauer@biplane.com.au Thu Jun 27 07:09:12 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF63021F9E08 for ; Thu, 27 Jun 2013 07:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wq8uxWD1ZMPH for ; Thu, 27 Jun 2013 07:09:12 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id C40A121F9E07 for ; Thu, 27 Jun 2013 07:09:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUBABZHzFGWZX+7/2dsb2JhbAANToM6Q78PgRSDFwEBAQECAX4LCxguVwYTiAgNqCqSJ49cg2UDiGqQBIp6iEU Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.203]) ([150.101.127.187]) by ipmail06.adl6.internode.on.net with ESMTP; 27 Jun 2013 23:39:07 +0930 Message-ID: <1372342144.3215.106.camel@karl> Subject: Re: question re REBIND in RFC 3315 (DHCPv6) From: Karl Auer To: IETF IPv6 Date: Fri, 28 Jun 2013 00:09:04 +1000 In-Reply-To: <3ED742F1-C82A-43E3-A2CD-CAD8F1E283B1@gmail.com> References: <1372290019.3215.32.camel@karl> <3ED742F1-C82A-43E3-A2CD-CAD8F1E283B1@gmail.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:09:12 -0000 On Thu, 2013-06-27 at 07:17 -0400, Ralph Droms wrote: > There is another difference between REBIND and RENEW: the client > includes the Server Identifier of the server from which the client > received the IA in the RENEW message (but not the REBIND). Yes. My question could be summarised I suppose as "what's the point of REBIND?" You answer that: > The idea is that some external data channel is used to replicate the > IA binding from the responsible server to all the other servers. And there is no such channel. As you say: > There's no such mechanism defined in DHCPv4 (RFC 2131 and RFC 2132), > either. It may be an oversight that it is not mentioned as "out of > scope" in RFC 3315. The separately defined (albeit still draft) failover system is that mechanism for DHCPv4. So, at the moment and absent any failover for DHCPv6, there is no point to REBIND except for the dubious benefit that addresses that are no good any more can possibly be confirmed as duds by other servers. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 From kauer@biplane.com.au Thu Jun 27 07:19:13 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CFF21F8925 for ; Thu, 27 Jun 2013 07:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heH8MI9LC48c for ; Thu, 27 Jun 2013 07:19:13 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id AC56621F9DC9 for ; Thu, 27 Jun 2013 07:19:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUBAHVJzFGWZX+7/2dsb2JhbAANToM6Q78PgRSDFwEBAQEDgQkLGC5XBhMJiAwFqC2SKI4jgTmDZQOIapAEinqIRYFf Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.203]) ([150.101.127.187]) by ipmail06.adl6.internode.on.net with ESMTP; 27 Jun 2013 23:48:59 +0930 Message-ID: <1372342737.3215.114.camel@karl> Subject: Re: question re REBIND in RFC 3315 (DHCPv6) From: Karl Auer To: IETF IPv6 Date: Fri, 28 Jun 2013 00:18:57 +1000 In-Reply-To: <6ABC1135-2AB2-43EC-A863-ACFFF546997B@cisco.com> References: <1372290019.3215.32.camel@karl> ,<3ED742F1-C82A-43E3-A2CD-CAD8F1E283B1@gmail.com> <6ABC1135-2AB2-43EC-A863-ACFFF546997B@cisco.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:19:13 -0000 On Thu, 2013-06-27 at 11:26 +0000, Bernie Volz (volz) wrote: > I've been trying to get the DHC WG to address this issue but there > appears to be zero interest in doing anything about it - > see http://www.ietf.org/mail-archive/web/dhcwg/current/msg14315.html. I'm interested. Dunno what practical difference that makes :-) I think it would be useful to have the additions you suggest. However, I would suggest making explicit the reasoning for them, and making explicit the potential for IAs to be updated between servers by an out-of-scope mechanism. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 From Fred.L.Templin@boeing.com Thu Jun 27 08:34:49 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12FC21F997F for ; Thu, 27 Jun 2013 08:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WE09ydSnAc6 for ; Thu, 27 Jun 2013 08:34:45 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 32B4121F91C4 for ; Thu, 27 Jun 2013 08:33:23 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r5RFXHQw004677 for ; Thu, 27 Jun 2013 08:33:17 -0700 Received: from XCH-PHX-511.sw.nos.boeing.com (xch-phx-511.sw.nos.boeing.com [10.57.37.28]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r5RFXG6B004664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 27 Jun 2013 08:33:16 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-PHX-511.sw.nos.boeing.com ([169.254.11.108]) with mapi id 14.02.0328.011; Thu, 27 Jun 2013 08:33:16 -0700 From: "Templin, Fred L" To: Brian E Carpenter , 6man Subject: RE: draft-bonica-6man-frag-deprecate Thread-Topic: draft-bonica-6man-frag-deprecate Thread-Index: AQHOctO2UZaGJnzSMU6ZOUB9nA7EbJlJr1mA Date: Thu, 27 Jun 2013 15:33:15 +0000 Message-ID: <2134F8430051B64F815C691A62D983180AEA5F@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <51CB91E4.5090603@gmail.com> In-Reply-To: <51CB91E4.5090603@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 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 15:34:49 -0000 Hi Brian, > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Brian E Carpenter > Sent: Wednesday, June 26, 2013 6:14 PM > To: 6man > Subject: draft-bonica-6man-frag-deprecate >=20 > Cutting to the chase, and assuming that the next version > will have more analysis and observational evidence, I'm thinking > something like the following: >=20 > 3. Recommendation >=20 > This memo deprecates IPv6 fragmentation and the IPv6 fragment > header. > Application and transport layer protocols SHOULD support effective > PMTU discovery [RFC4821], since ICMP-based PMTU discovery [RFC1981] > is unreliable. Any application or transport layer protocol that > cannot support effective PMTU discovery MUST NOT in any > circumstances > send IPv6 packets that exceed the IPv6 minimum MTU of 1280 bytes. But, if those 1280 packets go into a tunnel they become (1280 + HLEN) and are vulnerable to loss. This is even before we start talking about tunnels-within-tunnels. It should therefore be well established by now that tunnels over IPv6 MUST be capable of some form of frag/reass. > IPv6 stacks and forwarding nodes SHOULD continue to support inbound > fragmented IPv6 packets as specified in [RFC2460]. However, this > requirement exceeds the capability of some types of forwarding node > such as firewalls and load balancers. Therefore implementers and > operators need to be aware that on many paths through the Internet, > IPv6 fragmentation will fail. Legacy applications and transport > layer > protocols that do not conform to the previous paragraph can expect > connectivity failures as a result. Without some form of frag/reass, tunnels over IPv6 will black-hole. If IPv6 frag/reass is off the table, then we simply need something else. That something else is SEAL. Thanks - Fred fred.l.templin@boeing.com > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From rdroms.ietf@gmail.com Thu Jun 27 08:35:14 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8E321F9D56 for ; Thu, 27 Jun 2013 08:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.401 X-Spam-Level: X-Spam-Status: No, score=-99.401 tagged_above=-999 required=5 tests=[J_CHICKENPOX_21=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtXmRsz5TXjM for ; Thu, 27 Jun 2013 08:35:13 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5D08E21F969F for ; Thu, 27 Jun 2013 08:35:10 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id n1so601054qcw.30 for ; Thu, 27 Jun 2013 08:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=T4ALe9Qn1OcS8DbkiX2EKOflPVoPoSGoXetklJYTnqc=; b=A/pc77iC/1BrksUpgCL6ZgGM105Rb23yATaGYY5ydiLsgIW9ZAHjqeTMODTlEPBJaT 4qvIbgqRv5tRWSHF0ztQMH3UTTAHx1u4Mr3cqWItOiQI5uqr7pMYn4YmGK8UX0seojfo jVOKShtYrXWFd9nWut9z4AiflQbyfMW8kjIgAKys2NytamDGOK09Q5ykW3qBtbvi4bLe CL0BkclbLeXaUseQpZYfCDkBZmmrgHWU6DCECV/itMiJtLxW1b6hn+TnhR1XVBeI8vlh 8P9DUyOQAlQFHc4GeAcdZI+WtfG/lITwAVhCl1YIeOLMKKFwQ96qe6urbFy8EoQVcqh1 Motg== X-Received: by 10.49.16.197 with SMTP id i5mr11290290qed.58.1372347309861; Thu, 27 Jun 2013 08:35:09 -0700 (PDT) Received: from dhcp-i7prhfzrgrwle.d.cisco.com ([2001:420:2c52:1316:f9c6:c3df:d81:5cf6]) by mx.google.com with ESMTPSA id ds7sm5247822qab.13.2013.06.27.08.35.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Jun 2013 08:35:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: question re REBIND in RFC 3315 (DHCPv6) From: Ralph Droms In-Reply-To: <1372342144.3215.106.camel@karl> Date: Thu, 27 Jun 2013 11:34:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <146A0EDF-3A96-401B-8A18-573A630967C9@gmail.com> References: <1372290019.3215.32.camel@karl> <3ED742F1-C82A-43E3-A2CD-CAD8F1E283B1@gmail.com> <1372342144.3215.106.camel@karl> To: Karl Auer X-Mailer: Apple Mail (2.1508) Cc: IETF IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 15:35:14 -0000 On Jun 27, 2013, at 10:09 AM 6/27/13, Karl Auer = wrote: > On Thu, 2013-06-27 at 07:17 -0400, Ralph Droms wrote: >> There is another difference between REBIND and RENEW: the client >> includes the Server Identifier of the server from which the client >> received the IA in the RENEW message (but not the REBIND). >=20 > Yes. My question could be summarised I suppose as "what's the point of > REBIND?" You answer that: >=20 >> The idea is that some external data channel is used to replicate the >> IA binding from the responsible server to all the other servers. >=20 > And there is no such channel. Not yet, as part of the DHCP suite of specifications. Other channels, = such as a distributed database or grad students at keyboards calling = each other, can be (have been?) used. > As you say: >=20 >> There's no such mechanism defined in DHCPv4 (RFC 2131 and RFC 2132), >> either. It may be an oversight that it is not mentioned as "out of >> scope" in RFC 3315. >=20 > The separately defined (albeit still draft) failover system is that > mechanism for DHCPv4. >=20 > So, at the moment and absent any failover for DHCPv6, there is no = point > to REBIND except for the dubious benefit that addresses that are no = good > any more can possibly be confirmed as duds by other servers. I would be a little more optimistic and say that REBIND is specified, = (presumably) implemented and ready to use for non-DHCP mechanisms or = failover (when specified). - Ralph >=20 > Regards, K. >=20 > --=20 > = ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer@biplane.com.au) > http://www.biplane.com.au/kauer > http://twitter.com/kauer389 >=20 > GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A > Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From antonios.atlasis@gmail.com Thu Jun 27 11:33:00 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF17121F9D6A for ; Thu, 27 Jun 2013 11:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3du5Kp1PZnD for ; Thu, 27 Jun 2013 11:33:00 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C78C921F9D5F for ; Thu, 27 Jun 2013 11:32:59 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id ci6so2699667qab.18 for ; Thu, 27 Jun 2013 11:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=gyO7S9l9hKN6MDVArUkmjjYcB/cY+FE+oAbj6OAtb6U=; b=HFsY42kHeE11XG0Sjk5n/cCD0AbUxzUq0b21ln4LpkQldaJF7ySqDHDYz1TLRDf/58 J9HzNU8ffeX5huqcLmCgY529UIoYk4jUdQMT0/jTq/xyIyRqJLLPetzinV2J2UyW2/BC 1qlU9uQJMxSs8KfuJZPeBK8R1KUHJ6N9pbEtsHWZHyhSHdfR0KjK4FHXOa4j08YqJyVr Akgct/u/oed6ZwyHYiX+XEJAqv8iZdzPiut1mISUBAT0zi6rX0V1r6tGFIkjmLfgkW5c sZGFhWmWNpMVYURR7RBVa7Y8lEN5dHunx5ZdDwbi0VbQasVkzkePMC4U/jhDwFUPaJ00 B+ww== MIME-Version: 1.0 X-Received: by 10.49.98.196 with SMTP id ek4mr12665198qeb.8.1372357979250; Thu, 27 Jun 2013 11:32:59 -0700 (PDT) Received: by 10.224.184.79 with HTTP; Thu, 27 Jun 2013 11:32:59 -0700 (PDT) In-Reply-To: <51CB91E4.5090603@gmail.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <51CB91E4.5090603@gmail.com> Date: Thu, 27 Jun 2013 21:32:59 +0300 Message-ID: Subject: Re: draft-bonica-6man-frag-deprecate From: Antonios Atlasis To: ipv6@ietf.org Content-Type: multipart/alternative; boundary=047d7bdcace4dba65504e026fd41 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 18:33:00 -0000 --047d7bdcace4dba65504e026fd41 Content-Type: text/plain; charset=ISO-8859-1 Hi, there are certainly many security issues in IPv6 related with fragmentation, but still not convinced if its use should be deprecated completely. We should not remove any feature that may cause security issues. We may need it some day. On the contrary, I believe that we should try to fix it. I believe that some of the draft RFCs proposed by Fernando Gont are in the good direction (regarding the RA-Guard case, the generation of the fragment id values, etc), as well as the newly accepted RFC regarding the handling of atomic fragments. Apart from the above, what remains to be fixed, in my humble opinion, are the following: a. Tiny fragments (smaller than 1280 bytes) should not be accepted (unless they are atomic fragments or the last fragment of a datagram). b. RFC 5722 should be updated so as only the overlapping fragments to be dropped, not all the ones already received, or the ones that follow (as it is the recommendation now). This is already implemented by FreeBSD and seems to me the most proper way for handling overlapping fragments. We should also never forget that the rest of IPvt6Extension headers can result in datagrams much bigger than 1280 bytes, 1500 bytes, or even more. So, if you want to deprecate fragmentation in IPv6, you should also deprecate or at least change the extension headers usage in IPv6. Which actually means, redesign IPv6. Just my 0.02$ Antonios 2013/6/27 Brian E Carpenter > Cutting to the chase, and assuming that the next version > will have more analysis and observational evidence, I'm thinking > something like the following: > > 3. Recommendation > > This memo deprecates IPv6 fragmentation and the IPv6 fragment header. > Application and transport layer protocols SHOULD support effective > PMTU discovery [RFC4821], since ICMP-based PMTU discovery [RFC1981] > is unreliable. Any application or transport layer protocol that > cannot support effective PMTU discovery MUST NOT in any circumstances > send IPv6 packets that exceed the IPv6 minimum MTU of 1280 bytes. > > IPv6 stacks and forwarding nodes SHOULD continue to support inbound > fragmented IPv6 packets as specified in [RFC2460]. However, this > requirement exceeds the capability of some types of forwarding node > such as firewalls and load balancers. Therefore implementers and > operators need to be aware that on many paths through the Internet, > IPv6 fragmentation will fail. Legacy applications and transport layer > protocols that do not conform to the previous paragraph can expect > connectivity failures as a result. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --047d7bdcace4dba65504e026fd41 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi,

    there are = certainly many security issues in IPv6 related with fragmentation, but stil= l not convinced if its use should be deprecated completely. We should not r= emove any feature that may cause security issues. We may need it some day. = On the contrary, I believe that we should try to fix it.

    I believe that some of the draft RFCs proposed by Fernando Gont a= re in the good direction (regarding the RA-Guard case, the generation of th= e fragment id values, etc), as well as the newly accepted RFC regarding the= handling of atomic fragments. =A0 Apart from the above, what remains to be= fixed, in my humble opinion, are the following:

    a. Tiny fragments (smaller than 1280 bytes) should not be accepte= d (unless they are atomic fragments or the last fragment of a datagram).
    b. RFC 5722 should be updated so as only the overlapping fragments t= o be dropped, not all the ones already received, or the ones that follow (a= s it is the recommendation now). This is already implemented by FreeBSD and= seems to me the most proper way for handling overlapping fragments.

    We should also never forget that the rest of IPvt6Extension heade= rs can result in datagrams much bigger than 1280 bytes, 1500 bytes, or even= more. So, if you want to deprecate fragmentation in IPv6, you should also = deprecate or at least change the extension headers usage in IPv6. Which act= ually means, redesign IPv6.

    Just my 0.02$


    Antonios


    2013/6/27 Brian E Carpenter <brian.e.carpenter= @gmail.com>
    Cutting to the chase, and assuming that the = next version
    will have more analysis and observational evidence, I'm thinking
    something like the following:

    3. =A0Recommendation

    =A0 =A0This memo deprecates IPv6 fragmentation and the IPv6 fragment header= .
    =A0 =A0Application and transport layer protocols SHOULD support effective =A0 =A0PMTU discovery [RFC4821], since ICMP-based PMTU discovery [RFC1981]<= br> =A0 =A0is unreliable. Any application or transport layer protocol that
    =A0 =A0cannot support effective PMTU discovery MUST NOT in any circumstance= s
    =A0 =A0send IPv6 packets that exceed the IPv6 minimum MTU of 1280 bytes.
    =A0 =A0IPv6 stacks and forwarding nodes SHOULD continue to support inbound<= br> =A0 =A0fragmented IPv6 packets as specified in [RFC2460]. However, this
    =A0 =A0requirement exceeds the capability of some types of forwarding node<= br> =A0 =A0such as firewalls and load balancers. Therefore implementers and
    =A0 =A0operators need to be aware that on many paths through the Internet,<= br> =A0 =A0IPv6 fragmentation will fail. Legacy applications and transport laye= r
    =A0 =A0protocols that do not conform to the previous paragraph can expect =A0 =A0connectivity failures as a result.
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------


    =
    --047d7bdcace4dba65504e026fd41-- From Fred.L.Templin@boeing.com Thu Jun 27 11:56:17 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58DC21F9ED2 for ; Thu, 27 Jun 2013 11:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.3 X-Spam-Level: X-Spam-Status: No, score=-5.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7zMBJuzT8K1 for ; Thu, 27 Jun 2013 11:56:12 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 59EE821F9EDB for ; Thu, 27 Jun 2013 11:56:12 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r5RIuA0w010725 for ; Thu, 27 Jun 2013 13:56:10 -0500 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r5RIu9DE010707 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 27 Jun 2013 13:56:09 -0500 Received: from XCH-BLV-208.nw.nos.boeing.com (10.57.37.5) by XCH-NWHT-11.nw.nos.boeing.com (130.247.25.114) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 27 Jun 2013 11:56:08 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-BLV-208.nw.nos.boeing.com ([169.254.8.102]) with mapi id 14.02.0328.011; Thu, 27 Jun 2013 11:56:08 -0700 From: "Templin, Fred L" To: Antonios Atlasis , "ipv6@ietf.org" Subject: RE: draft-bonica-6man-frag-deprecate Thread-Topic: draft-bonica-6man-frag-deprecate Thread-Index: AQHOc2S/UZaGJnzSMU6ZOUB9nA7EbJlJ45pw Date: Thu, 27 Jun 2013 18:56:08 +0000 Message-ID: <2134F8430051B64F815C691A62D983180AECDE@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <51CB91E4.5090603@gmail.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 18:56:18 -0000 Hi, > a. Tiny fragments (smaller than 1280 bytes) should not be accepted (unles= s they are atomic fragments or > the last fragment of a datagram). I disagree that all fragments less than 1280 bytes should be classified as "tiny fragments". For nested tunnels, for example, the first tunnel ingress may wish to fragment to a smaller size (e.g. 1024 bytes) so that subsequent tunnel ingresses do not have to fragment further. I think a "tiny fragment" is simply an initial fragment that does not include all extension headers plus upper layer headers. On the other hand, SEAL fragments cannot be smaller than 256bytes so there is no possible way to create a truly tiny SEAL first fragment. SEAL also requires the sender to include all upper layer headers in the first fragment unless they absolutely cannot fit due to a size restriction. > b. RFC 5722 should be updated so as only the overlapping fragments to be = dropped, not all the ones > already received, or the ones that follow (as it is the recommendation no= w). This is already > implemented by FreeBSD and seems to me the most proper way for handling o= verlapping fragments. SEAL has a strategy for dealing with overlapping fragments. It would be interesting to hear whether it meets your understanding of how best to handle overlaps because we can still make changes now if something doesn't look right. > We should also never forget that the rest of IPvt6Extension headers can r= esult in datagrams much > bigger than 1280 bytes, 1500 bytes, or even more. So, if you want to depr= ecate fragmentation in IPv6, > you should also deprecate or at least change the extension headers usage = in IPv6. Which actually means, > redesign IPv6. I agree that excessively-long extension headers are problematic in any case - especially if the length of the extension headers exceeds the effective path MTU. That needs to be fixed no matter what frag/reass scheme is applied. Thanks - Fred fred.l.templin@boeing.com =20 > Just my 0.02$ Antonios 2013/6/27 Brian E Carpenter Cutting to the chase, and assuming that the next version will have more analysis and observational evidence, I'm thinking something like the following: 3. =A0Recommendation =A0 =A0This memo deprecates IPv6 fragmentation and the IPv6 fragment header= . =A0 =A0Application and transport layer protocols SHOULD support effective =A0 =A0PMTU discovery [RFC4821], since ICMP-based PMTU discovery [RFC1981] =A0 =A0is unreliable. Any application or transport layer protocol that =A0 =A0cannot support effective PMTU discovery MUST NOT in any circumstance= s =A0 =A0send IPv6 packets that exceed the IPv6 minimum MTU of 1280 bytes. =A0 =A0IPv6 stacks and forwarding nodes SHOULD continue to support inbound =A0 =A0fragmented IPv6 packets as specified in [RFC2460]. However, this =A0 =A0requirement exceeds the capability of some types of forwarding node =A0 =A0such as firewalls and load balancers. Therefore implementers and =A0 =A0operators need to be aware that on many paths through the Internet, =A0 =A0IPv6 fragmentation will fail. Legacy applications and transport laye= r =A0 =A0protocols that do not conform to the previous paragraph can expect =A0 =A0connectivity failures as a result. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From antonios.atlasis@gmail.com Thu Jun 27 13:15:46 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEC121F9E89 for ; Thu, 27 Jun 2013 13:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Y43UdOsxoBz for ; Thu, 27 Jun 2013 13:15:45 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 14EDB21F9E60 for ; Thu, 27 Jun 2013 13:15:44 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id f11so77489qae.3 for ; Thu, 27 Jun 2013 13:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BQOqVRVfAqiqsP2wM04+1SlsQn3QeAtdWPAU6SkllaI=; b=Q6xO+wgTjBwohXllIMMc1tS0fVKs1YmAU+131w/nJzWk4uES4XjpidYJYAOihK4p8/ Sy4ms/vPogzsd7EN17H8rj8pyZ2Bs5U4y1JPMXm3aq1rYGLsxfrOEDqTYvx3W91Biuyq lVW+nJWLrL9KyhXC5TTHCE4tTfHEb7K5cxU6mD2R+k4Apa8ozLyNMMumvbp4NegEvgV3 vTc0Dk9HhwZTZ7WRNE82v6/o+8xxl8GwFYJInSGT+z5BLd6ZPWdFX9p+Es33baae1ZLl VWez3/pRxclAyCXuINb2y9RP9zgigMusRGo81MfcPvVqlDqpk9OHHMUy40q2o1/6hmyt WTPw== MIME-Version: 1.0 X-Received: by 10.224.188.74 with SMTP id cz10mr294269qab.31.1372364144415; Thu, 27 Jun 2013 13:15:44 -0700 (PDT) Received: by 10.224.184.79 with HTTP; Thu, 27 Jun 2013 13:15:44 -0700 (PDT) In-Reply-To: <2134F8430051B64F815C691A62D983180AECDE@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <51CB91E4.5090603@gmail.com> <2134F8430051B64F815C691A62D983180AECDE@XCH-BLV-504.nw.nos.boeing.com> Date: Thu, 27 Jun 2013 23:15:44 +0300 Message-ID: Subject: Re: draft-bonica-6man-frag-deprecate From: Antonios Atlasis To: "Templin, Fred L" Content-Type: multipart/alternative; boundary=485b397dd237550e8604e0286d2c Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 20:15:46 -0000 --485b397dd237550e8604e0286d2c Content-Type: text/plain; charset=ISO-8859-1 Hi Fred, 2013/6/27 Templin, Fred L > Hi, > > > a. Tiny fragments (smaller than 1280 bytes) should not be accepted > (unless they are atomic fragments or > the last fragment of a datagram). > > I disagree that all fragments less than 1280 bytes should be classified > as "tiny fragments". For nested tunnels, for example, the first tunnel > ingress may wish to fragment to a smaller size (e.g. 1024 bytes) so that > subsequent tunnel ingresses do not have to fragment further. I think a > "tiny fragment" is simply an initial fragment that does not include all > extension headers plus upper layer headers. > > On the other hand, SEAL fragments cannot be smaller than 256bytes > so there is no possible way to create a truly tiny SEAL first fragment. > SEAL also requires the sender to include all upper layer headers in > the first fragment unless they absolutely cannot fit due to a size > restriction. > Actually, I was not talking only about SEAL, but generally. If this is the case, the minimum acceptable size of fragments could be discussed/adjusted accordingly, but as it is, OS accept as small as 56 bytes fragments! > > > b. RFC 5722 should be updated so as only the overlapping fragments to be > dropped, not all the ones > > already received, or the ones that follow (as it is the recommendation > now). This is already > > implemented by FreeBSD and seems to me the most proper way for handling > overlapping fragments. > > SEAL has a strategy for dealing with overlapping fragments. It would > be interesting to hear whether it meets your understanding of how best > to handle overlaps because we can still make changes now if something > doesn't look right. > Again, generally speaking (and not just for SEAL) RFC 5722 "allows" the abuse of its recommended policy for launching DoS attacks (a single overlapping fragment will result in discarding a whole datagram). On the contrary, if only the overlapping fragment is discarded, at least DoS will be slightly more difficult. > > > We should also never forget that the rest of IPvt6Extension headers can > result in datagrams much > > bigger than 1280 bytes, 1500 bytes, or even more. So, if you want to > deprecate fragmentation in IPv6, > > you should also deprecate or at least change the extension headers usage > in IPv6. Which actually means, > > redesign IPv6. > > I agree that excessively-long extension headers are problematic > in any case - especially if the length of the extension headers > exceeds the effective path MTU. That needs to be fixed no matter > what frag/reass scheme is applied. > > I agree Thank you too Antonios > Thanks - Fred > fred.l.templin@boeing.com > > > Just my 0.02$ > > Antonios > > 2013/6/27 Brian E Carpenter > Cutting to the chase, and assuming that the next version > will have more analysis and observational evidence, I'm thinking > something like the following: > > 3. Recommendation > > This memo deprecates IPv6 fragmentation and the IPv6 fragment header. > Application and transport layer protocols SHOULD support effective > PMTU discovery [RFC4821], since ICMP-based PMTU discovery [RFC1981] > is unreliable. Any application or transport layer protocol that > cannot support effective PMTU discovery MUST NOT in any circumstances > send IPv6 packets that exceed the IPv6 minimum MTU of 1280 bytes. > > IPv6 stacks and forwarding nodes SHOULD continue to support inbound > fragmented IPv6 packets as specified in [RFC2460]. However, this > requirement exceeds the capability of some types of forwarding node > such as firewalls and load balancers. Therefore implementers and > operators need to be aware that on many paths through the Internet, > IPv6 fragmentation will fail. Legacy applications and transport layer > protocols that do not conform to the previous paragraph can expect > connectivity failures as a result. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --485b397dd237550e8604e0286d2c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi Fred,

    2013/6/27 Templin, Fred L <Fred.L.= Templin@boeing.com>
    Hi,

    > a. Tiny fragments (smaller than 1280 bytes) should not be accepted (un= less they are atomic fragments or > the last fragment of a datagram).
    I disagree that all fragments less than 1280 bytes should be classifi= ed
    as "tiny fragments". For nested tunnels, for example, the first t= unnel
    ingress may wish to fragment to a smaller size (e.g. 1024 bytes) so that subsequent tunnel ingresses do not have to fragment further. I think a
    "tiny fragment" is simply an initial fragment that does not inclu= de all
    extension headers plus upper layer headers.

    On the other hand, SEAL fragments cannot be smaller than 256bytes
    so there is no possible way to create a truly tiny SEAL first fragment.
    SEAL also requires the sender to include all upper layer headers in
    the first fragment unless they absolutely cannot fit due to a size
    restriction.


    Actually, I was not ta= lking only about SEAL, but generally. If this is the case, the minimum acce= ptable size of fragments could be discussed/adjusted accordingly, but as it= is, OS accept as small as 56 bytes fragments!

    =A0

    > b. RFC 5722 should be updated so as only the overlapping fragments to = be dropped, not all the ones
    > already received, or the ones that follow (as it is the recommendation= now). This is already
    > implemented by FreeBSD and seems to me the most proper way for handlin= g overlapping fragments.

    SEAL has a strategy for dealing with overlapping fragments. It would<= br> be interesting to hear whether it meets your understanding of how best
    to handle overlaps because we can still make changes now if something
    doesn't look right.

    Again, generall= y speaking (and not just for SEAL) RFC 5722 "allows" the abuse of= its recommended policy for launching DoS attacks (a single overlapping fra= gment will result in discarding a whole datagram). On the contrary, if=A0 o= nly the overlapping fragment is discarded, at least DoS will be slightly mo= re difficult.=A0
    =A0

    > We should also never forget that the rest of IPvt6Extension headers ca= n result in datagrams much
    > bigger than 1280 bytes, 1500 bytes, or even more. So, if you want to d= eprecate fragmentation in IPv6,
    > you should also deprecate or at least change the extension headers usa= ge in IPv6. Which actually means,
    > redesign IPv6.

    I agree that excessively-long extension headers are problematic
    in any case - especially if the length of the extension headers
    exceeds the effective path MTU. That needs to be fixed no matter
    what frag/reass scheme is applied.


    I agree

    Thank you to= o

    Antonios

    =A0
    fred.l.templin@boeing.com<= br>

    > Just my 0.02$

    Antonios

    2013/6/27 Brian E Carpenter <brian.e.carpenter@gmail.com>
    Cutting to the chase, and assuming that the next version
    will have more analysis and observational evidence, I'm thinking
    something like the following:

    3. =A0Recommendation

    =A0 =A0This memo deprecates IPv6 fragmentation and the IPv6 fragment header= .
    =A0 =A0Application and transport layer protocols SHOULD support effective =A0 =A0PMTU discovery [RFC4821], since ICMP-based PMTU discovery [RFC1981]<= br> =A0 =A0is unreliable. Any application or transport layer protocol that
    =A0 =A0cannot support effective PMTU discovery MUST NOT in any circumstance= s
    =A0 =A0send IPv6 packets that exceed the IPv6 minimum MTU of 1280 bytes.
    =A0 =A0IPv6 stacks and forwarding nodes SHOULD continue to support inbound<= br> =A0 =A0fragmented IPv6 packets as specified in [RFC2460]. However, this
    =A0 =A0requirement exceeds the capability of some types of forwarding node<= br> =A0 =A0such as firewalls and load balancers. Therefore implementers and
    =A0 =A0operators need to be aware that on many paths through the Internet,<= br> =A0 =A0IPv6 fragmentation will fail. Legacy applications and transport laye= r
    =A0 =A0protocols that do not conform to the previous paragraph can expect =A0 =A0connectivity failures as a result.
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------




    =
    --485b397dd237550e8604e0286d2c-- From alh-ietf@tndh.net Thu Jun 27 15:24:51 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A4511E8108 for ; Thu, 27 Jun 2013 15:24:51 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ...that system for details.\n \n Content previ[...] X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2pKQPZzYNHf for ; Thu, 27 Jun 2013 15:24:51 -0700 (PDT) Received: from express.tndh.net (express.tndh.net [IPv6:2001:470:e930:1240:20d:56ff:fe04:4c0a]) by ietfa.amsl.com (Postfix) with ESMTP id 6304711E80F2 for ; Thu, 27 Jun 2013 15:24:51 -0700 (PDT) Received: from express.tndh.local ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1UsKc6-000Lox-9B; Thu, 27 Jun 2013 15:24:31 -0700 From: "Tony Hain" To: "'Antonios Atlasis'" , "'Templin, Fred L'" References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <51CB91E4.5090603@gmail.com> <2134F8430051B64F815C691A62D983180AECDE@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Subject: RE: draft-bonica-6man-frag-deprecate Date: Thu, 27 Jun 2013 15:24:26 -0700 Message-ID: <00de01ce7385$15428a50$3fc79ef0$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFPmzyGg3SBeEPNIeSj1WaAnqHbKQFoz6nmATozAx4DC6ihzwHXD68zAWtvC4UCE6gwgQKpxY60AovOJPsBB58Y7QI6wCxTAnTsjU8BsSq9NQFa335BAos4mO4BrPSbjpleIpWA Content-Language: en-us X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a X-SA-Exim-Mail-From: alh-ietf@tndh.net X-SA-Exim-Scanned: No (on express.tndh.net); SAEximRunCond expanded to false Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 22:24:52 -0000 Antonios Atlasis wrote: ... > Again, generally speaking (and not just for SEAL) RFC 5722 "allows" > the abuse of its recommended policy for launching DoS attacks (a=20 > single overlapping fragment will result in discarding a whole=20 > datagram). On the contrary, if=A0 only the overlapping fragment is=20 > discarded, at least DoS will be slightly more difficult.=A0=20 =A0 DoS is more difficult, but packet hijack is easier. All an attacker = needs to do is inject a set of fragments before the next one from the source to = cause it to appear to be an overlap and rejected. Once the attacker can get = the real fragments rejected as overlaps, the rest of the packet is filled = with bogus attack fragments. Wouldn't it have been better to drop the whole datagram? DoS is a problem, but undetected malicious data is worse. Tony From fred@cisco.com Thu Jun 27 15:48:32 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3829B11E80DC for ; Thu, 27 Jun 2013 15:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.448 X-Spam-Level: X-Spam-Status: No, score=-110.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhIp1ukshXHT for ; Thu, 27 Jun 2013 15:48:26 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A3BE411E80E2 for ; Thu, 27 Jun 2013 15:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2612; q=dns/txt; s=iport; t=1372373306; x=1373582906; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ejf+ce4i91nuJZnPVnZVJoVmrufkzWgWmmfhhpUyMk0=; b=GOXRcW3puyoKtOupmfEK2pM+CU9nxjqkqnf7D/WUpYXL6wLDDHXMyCs5 rlxS2d2xdBWakfrVGwQ8HZ3Y2YRCdgFdJNUJljYkXLgsXkJFNpcb9Sndr Vbq4hU/Id9Rm6rZFnD0rjhJm60ehp7cmIpBvFjmnJRauDhLSkS/fXhQXO k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFANS/zFGtJV2d/2dsb2JhbABbgwl6vwyBAxZ0giQBAQEDeRACAQgEHh0HIREUEQIEDgUIh3QDD7JqDYhSjG2CNzEHgwJjA4hqjHSOB4UlgxGCKA X-IronPort-AV: E=Sophos;i="4.87,955,1363132800"; d="scan'208,217";a="228398369" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 27 Jun 2013 22:48:26 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5RMmQrW004931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Jun 2013 22:48:26 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Thu, 27 Jun 2013 17:48:25 -0500 From: "Fred Baker (fred)" To: Marc Lampo Subject: Re: draft-bonica-6man-frag-deprecate Thread-Topic: draft-bonica-6man-frag-deprecate Thread-Index: AQHOctOqKSNCWRrYkESNmwbscYIw9plJYzyAgAANDgCAAQ64gA== Date: Thu, 27 Jun 2013 22:48:25 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B92B349@xmb-rcd-x09.cisco.com> References: <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <51CB91E4.5090603@gmail.com> <20130627055241.GA3358@virgo.local> 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.125] Content-Type: multipart/alternative; boundary="_000_8C48B86A895913448548E6D15DA7553B92B349xmbrcdx09ciscocom_" MIME-Version: 1.0 Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 22:48:32 -0000 --_000_8C48B86A895913448548E6D15DA7553B92B349xmbrcdx09ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jun 26, 2013, at 11:39 PM, Marc Lampo > wrote: Would we think about deprecating the use of fragmentation fields in the IPv= 4 header and recommending they MUST always be set to 0 ? I would say "no", for the same reasons that I think it's a poor idea in IPv= 6. It pushes the requirement to match MTU to the client of IP. Some clients= , notably IPv4, have ways to do that. Some have been noted that don't. --_000_8C48B86A895913448548E6D15DA7553B92B349xmbrcdx09ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
    On Jun 26, 2013, at 11:39 PM, Marc Lampo <marc.lampo.ietf@gmail.com> wrote:

    Would we think about deprecating the use of fragmentation fields in the IPv4 hea= der and recommending they MUST always be set to 0 ?

    I would say "no", for the same reasons that I think it's a poor i= dea in IPv6. It pushes the requirement to match MTU to the client of IP. So= me clients, notably IPv4, have ways to do that. Some have been noted that d= on't.  --_000_8C48B86A895913448548E6D15DA7553B92B349xmbrcdx09ciscocom_-- From marka@isc.org Thu Jun 27 16:31:52 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32D011E8144 for ; Thu, 27 Jun 2013 16:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMaOthPcjVZp for ; Thu, 27 Jun 2013 16:31:48 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id EE0B111E8132 for ; Thu, 27 Jun 2013 16:31:44 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id C3D9EC94EF; Thu, 27 Jun 2013 23:31:36 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372375904; bh=E+6zaCNJTaBRuB2qhQIcJ28/r+2JK40ZWsiv16GLBhw=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=r/0Y69bEAkGQ1wOC7f+YFIMX5p8/kfahyqjyrq8ckqMdKcgeiNR0uX2SPg37DMIaY /Q5xP64q5ZrH3Ul0DsurRgGDIaBe5AH7qmkPbcpdbAroKOAtgMWYg2z3WpH1z4HLLX qz43KmvJtqcoUGh9XR21JGtkfHHwiDzPZQPwTyFQ= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 27 Jun 2013 23:31:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 569EB1600A4; Thu, 27 Jun 2013 23:32:55 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id BlPwBHbjer23; Thu, 27 Jun 2013 23:32:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 719631600A3; Thu, 27 Jun 2013 23:32:54 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id K4INT1VkCOIG; Thu, 27 Jun 2013 23:32:54 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id 1056A16004A; Thu, 27 Jun 2013 23:32:54 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 345EB36613EA; Fri, 28 Jun 2013 09:31:30 +1000 (EST) To: "Tony Hain" From: Mark Andrews References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <51CB91E4.5090603@gmail.com> <2134F8430051B64F815C691A62D983180AECDE@XCH-BLV-504.nw.nos.boeing.com> <00de01ce7385$15428a50$3fc79ef0$@tndh.net> Subject: Re: draft-bonica-6man-frag-deprecate In-reply-to: Your message of "Thu, 27 Jun 2013 15:24:26 -0700." <00de01ce7385$15428a50$3fc79ef0$@tndh.net> Date: Fri, 28 Jun 2013 09:31:30 +1000 Message-Id: <20130627233130.345EB36613EA@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 23:31:53 -0000 In message <00de01ce7385$15428a50$3fc79ef0$@tndh.net>, "Tony Hain" writes: > Antonios Atlasis wrote: > ... > > Again, generally speaking (and not just for SEAL) RFC 5722 "allows" > > the abuse of its recommended policy for launching DoS attacks (a > > single overlapping fragment will result in discarding a whole > > datagram). On the contrary, if only the overlapping fragment is > > discarded, at least DoS will be slightly more difficult. > > DoS is more difficult, but packet hijack is easier. All an attacker needs > to do is inject a set of fragments before the next one from the source to > cause it to appear to be an overlap and rejected. Once the attacker can get > the real fragments rejected as overlaps, the rest of the packet is filled > with bogus attack fragments. Wouldn't it have been better to drop the whole > datagram? DoS is a problem, but undetected malicious data is worse. Then add a cryptographic checksum of the original packet when fragmenting. 48 bits in a HBH should be enough. > Tony > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From kauer@biplane.com.au Thu Jun 27 17:00:36 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0563B11E8149 for ; Thu, 27 Jun 2013 17:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jxn2b2ik4KFj for ; Thu, 27 Jun 2013 17:00:28 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFE911E8142 for ; Thu, 27 Jun 2013 17:00:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoEDAKfQzFGWZX+7/2dsb2JhbAANToM6Q78JAQMBAwGBGIMXAQEBAQOBCQsYLlcZiBWpF5Ipj1wWg08DiGqQBIp6iEU Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.203]) ([150.101.127.187]) by ipmail06.adl6.internode.on.net with ESMTP; 28 Jun 2013 09:30:14 +0930 Message-ID: <1372377611.3215.141.camel@karl> Subject: Re: draft-bonica-6man-frag-deprecate From: Karl Auer To: ipv6@ietf.org Date: Fri, 28 Jun 2013 10:00:11 +1000 In-Reply-To: <20130627233130.345EB36613EA@drugs.dv.isc.org> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <51CB91E4.5090603@gmail.com> <2134F8430051B64F815C691A62D983180AECDE@XCH-BLV-504.nw.nos.boeing.com> <00de01ce7385$15428a50$3fc79ef0$@tndh.net> <20130627233130.345EB36613EA@drugs.dv.isc.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 00:00:36 -0000 On Fri, 2013-06-28 at 09:31 +1000, Mark Andrews wrote: > Then add a cryptographic checksum of the original packet when fragmenting. > 48 bits in a HBH should be enough. Why HBH? Is that to prevent it being send in a fragment itself? And, um, I hate to suggest this, but isn't that sort of exactly what the AH header is for? I know, I know.... (covers head, ducks) Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 From Fred.L.Templin@boeing.com Thu Jun 27 17:09:16 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285D721F9D67 for ; Thu, 27 Jun 2013 17:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZC0Y1cxb7z6 for ; Thu, 27 Jun 2013 17:09:11 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 6953B21F9D3B for ; Thu, 27 Jun 2013 17:09:11 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r5S09AUt022577 for ; Thu, 27 Jun 2013 17:09:10 -0700 Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r5S098Zu022572 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 27 Jun 2013 17:09:08 -0700 Received: from XCH-BLV-305.nw.nos.boeing.com (130.247.25.217) by XCH-NWHT-09.nw.nos.boeing.com (130.247.25.115) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 27 Jun 2013 17:09:09 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-BLV-305.nw.nos.boeing.com ([169.254.5.115]) with mapi id 14.02.0328.011; Thu, 27 Jun 2013 17:09:08 -0700 From: "Templin, Fred L" To: Karl Auer , "ipv6@ietf.org" Subject: RE: draft-bonica-6man-frag-deprecate Thread-Topic: draft-bonica-6man-frag-deprecate Thread-Index: AQHOc5J1UZaGJnzSMU6ZOUB9nA7EbJlKPuaw Date: Fri, 28 Jun 2013 00:09:07 +0000 Message-ID: <2134F8430051B64F815C691A62D983180AF228@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <51CB91E4.5090603@gmail.com> <2134F8430051B64F815C691A62D983180AECDE@XCH-BLV-504.nw.nos.boeing.com> <00de01ce7385$15428a50$3fc79ef0$@tndh.net> <20130627233130.345EB36613EA@drugs.dv.isc.org> <1372377611.3215.141.camel@karl> In-Reply-To: <1372377611.3215.141.camel@karl> 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 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 00:09:16 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Karl Auer > Sent: Thursday, June 27, 2013 5:00 PM > To: ipv6@ietf.org > Subject: Re: draft-bonica-6man-frag-deprecate >=20 > On Fri, 2013-06-28 at 09:31 +1000, Mark Andrews wrote: > > Then add a cryptographic checksum of the original packet when > fragmenting. > > 48 bits in a HBH should be enough. >=20 > Why HBH? Is that to prevent it being send in a fragment itself? And, > um, > I hate to suggest this, but isn't that sort of exactly what the AH > header is for? I know, I know.... (covers head, ducks) SEAL has the *option* to insert a per-segment HMAC that the destination can use for data origin verification. Sort of like AH, but this is only one *optional* mode of operation. But that said, going back to Tony's scenario why would an adversary that is already able to get the destination to accept its packets bother with finessing the reassembly cache? Upper-layer checksums would weed out bad reassemblies, while the attacker could much more easily just inject whole packets that are evil. Thanks - Fred fred.l.templin@boeing.com > Regards, K. >=20 > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer@biplane.com.au) > http://www.biplane.com.au/kauer > http://twitter.com/kauer389 >=20 > GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A > Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From markzzzsmith@yahoo.com.au Thu Jun 27 17:13:15 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048D611E8156 for ; Thu, 27 Jun 2013 17:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MV98fw5j0pYI for ; Thu, 27 Jun 2013 17:13:09 -0700 (PDT) Received: from nm29-vm1.bullet.mail.bf1.yahoo.com (nm29-vm1.bullet.mail.bf1.yahoo.com [98.139.213.144]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9E011E814E for ; Thu, 27 Jun 2013 17:13:09 -0700 (PDT) Received: from [98.139.212.147] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 28 Jun 2013 00:13:08 -0000 Received: from [98.139.212.206] by tm4.bullet.mail.bf1.yahoo.com with NNFMP; 28 Jun 2013 00:13:08 -0000 Received: from [127.0.0.1] by omp1015.mail.bf1.yahoo.com with NNFMP; 28 Jun 2013 00:13:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 760724.42035.bm@omp1015.mail.bf1.yahoo.com Received: (qmail 65734 invoked by uid 60001); 28 Jun 2013 00:13:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1372378388; bh=MYfeB5ikt3kBe8yo5IwSYYQa8sknxO1/pMTYGMsBBE4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=X8FK5SnFpRi6HrK9QVRafZEtqnsIJSv+XiWO+WFc4jv4y0tMywtkDa+J5y0C00mZ9zv4IHcX8UpRRP/tz1MsfLaamA4ZNr6KDDS7ujyMaOV39tIcY2jee+/jkKZy5YBvEpphdjM9gdDsgsggaUx6ZM8qXY4AvcwhnhiivyVOA2I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jYpRlNAjmK+gJX6MD5+4ZorDOZw+LSgT0ILXuWvSTxSPaynoXVc3OhVzH0cGOsQ9uLpkwfVTFJxv0Yyri75lwsyPsJ8CsmC3jYjDq+aP385wdtsa4RsiBcnVocGDQFUYrnHrXzRuXW/djU56VVbsd8fOcjoxKOO1ndc/dbyPVIk=; X-YMail-OSG: cHmfbU0VM1lK0.px7K5lvrxEGo8_j8SdL28fxVbm7FALRoE 0S8Rdf8OEWw0KbUIf.suQEhJlMKpLCrtfYdD5vgn641swuZPIIE3kdnwZhOf eAMWyLsqSTEf08zlBUvkONTwQ7.FYVHgSWhKOPnNYfNnCBH4_JjkOYV5GvMt WnxKT2AXgjlB28z5fr4xO5LD..TERY8zPwhfA9Jc6FPFXiizbE0GWMPcKUhn PCrQnoayc8ieuHBQxyNwjzkLsYNoOmJe3Glf872JEK5noOgfY98JD4JIFKIp KPnEUH5u0e5MJIVt8IVsucpXLlj00huTo8hm67.Tx06bOt5nyCV7BDWtV2nu fwJ2Qvss4i9e_s.vGJkIqHISSYpdR0zGGBMuyI2jipcjz300e_xbkgXe8bby k6VsU9chI8ygv16GE8CRKfMFu6DIbjQDSN8Ztgt5a3C1l6iSI5XlnXnyUI6x 4_l.C.Vk2fzLZ6NwNwCdC9OyqMIQ0e86NSQPJm8XHEDPIxR.3Jv4nDUhUKrq VKGe9tv.0E0AFrxKTWlj5HykyP.cISuFevCZSoHXyuBbGVWsIQrS6AzjI_dZ ruMf_3R8igAysGeZVm3.Un6yBjvT8DsMIXQ-- Received: from [150.101.221.237] by web142504.mail.bf1.yahoo.com via HTTP; Thu, 27 Jun 2013 17:13:07 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBLYXJsIEF1ZXIgPGthdWVyQGJpcGxhbmUuY29tLmF1Pgo.IFRvOiBJRVRGIElQdjYgPGlwdjZAaWV0Zi5vcmc.Cj4gQ2M6IAo.IFNlbnQ6IEZyaWRheSwgMjggSnVuZSAyMDEzIDEyOjA5IEFNCj4gU3ViamVjdDogUmU6IHF1ZXN0aW9uIHJlIFJFQklORCBpbiBSRkMgMzMxNSAoREhDUHY2KQo.IAo.IE9uIFRodSwgMjAxMy0wNi0yNyBhdCAwNzoxNyAtMDQwMCwgUmFscGggRHJvbXMgd3JvdGU6Cj4.ICBUaGVyZSBpcyBhbm90aGVyIGRpZmYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.148.557 References: <1372290019.3215.32.camel@karl> <3ED742F1-C82A-43E3-A2CD-CAD8F1E283B1@gmail.com> <1372342144.3215.106.camel@karl> Message-ID: <1372378387.65495.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Thu, 27 Jun 2013 17:13:07 -0700 (PDT) From: Mark ZZZ Smith Subject: Re: question re REBIND in RFC 3315 (DHCPv6) To: Karl Auer , IETF IPv6 In-Reply-To: <1372342144.3215.106.camel@karl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 00:13:15 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Karl Auer =0A> To: IETF IPv6 =0A> Cc: =0A> Sent: Friday, 28 Ju= ne 2013 12:09 AM=0A> Subject: Re: question re REBIND in RFC 3315 (DHCPv6)= =0A> =0A> On Thu, 2013-06-27 at 07:17 -0400, Ralph Droms wrote:=0A>> There= is another difference between REBIND and RENEW: the client=0A>> includes = the Server Identifier of the server from which the client=0A>> received th= e IA in the RENEW message (but not the REBIND).=0A> =0A> Yes. My question c= ould be summarised I suppose as "what's the point of=0A> REBIND?" You answe= r that:=0A> =0A>> The idea is that some external data channel is used to r= eplicate the=0A>> IA binding from the responsible server to all the other = servers.=0A> =0A> And there is no such channel. As you say:=0A> =0A>> Ther= e's no such mechanism defined in DHCPv4 (RFC 2131 and RFC 2132),=0A>> eith= er.=A0 It may be an oversight that it is not mentioned as "out of=0A>> sco= pe" in RFC 3315.=0A> =0A> The separately defined (albeit still draft) failo= ver system is that=0A> mechanism for DHCPv4.=0A> =0A> So, at the moment and= absent any failover for DHCPv6, there is no point=0A> to REBIND except for= the dubious benefit that addresses that are no good=0A> any more can possi= bly be confirmed as duds by other servers.=0A>=A0=0A=0APerhaps a DHCPv6 ser= ver could have a "promiscuous mode" where it accepts and permits the addres= ses it doesn't know about in REBIND messages, with an upper total limit to = prevent DoS.=0A=0AOne thing that is easy to forget is that the address pref= erred and valid lifetimes should dictate whether a host can continue to use= addresses issued by stateful DHCPv6. If a host resorts to a DHCPv6 REBIND,= and the server doesn't know about the addresses, the host should continue = to use the addresses while they continue to have a valid lifetime. A host s= hould only stop using addresses assigned via stateful DHCPv6 if the preferr= ed and valid lifetimes are specifically set via a RENEW or REBIND to deprec= ated values (zero for preferred, 7200 for valid IIRC).=0A=0ARegards,=0AMark= . From marka@isc.org Thu Jun 27 17:15:43 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B82C11E8181 for ; Thu, 27 Jun 2013 17:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6mXue8XXxFf for ; Thu, 27 Jun 2013 17:15:39 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 4B43311E817A for ; Thu, 27 Jun 2013 17:15:39 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id EA03DC94E7; Fri, 28 Jun 2013 00:15:31 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372378539; bh=puPHPj2gNG/Epj6gvlYi6WSNXpFMikuYR+2/Jnxlhwc=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=mQBHR/rBEU2uY/3GR9kBg+Jv/P4REW7R4j3XENQdl+stko1M80Oz+u/P9tMqp2jN5 6cSnu29eVd+1HDQzWb8Hy8ahb5aZeTgIggAAQUMkiRK6vcqAI7RW+TBTiy2EyW3a76 FCzI5DiuXSZB0ZwqBkL7INnOE2xXHdosj5TW36/w= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Fri, 28 Jun 2013 00:15:31 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9D1FD1600A4; Fri, 28 Jun 2013 00:16:50 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id rqZF8LaThz3k; Fri, 28 Jun 2013 00:16:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 463251600A3; Fri, 28 Jun 2013 00:16:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id O09MFIeiQXky; Fri, 28 Jun 2013 00:16:50 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id D810416004A; Fri, 28 Jun 2013 00:16:49 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 62F723661D01; Fri, 28 Jun 2013 10:15:27 +1000 (EST) To: Karl Auer From: Mark Andrews References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <51CB91E4.5090603@gmail.com> <2134F8430051B64F815C691A62D983180AECDE@XCH-BLV-504.nw.nos.boeing.com> <00de01ce7385$15428a50$3fc79ef0$@tndh.net> <20130627233130.345EB36613EA@drugs.dv.isc.org> <1372377611.3215.141.camel@karl> Subject: Re: draft-bonica-6man-frag-deprecate In-reply-to: Your message of "Fri, 28 Jun 2013 10:00:11 +1000." <1372377611.3215.141.camel@karl> Date: Fri, 28 Jun 2013 10:15:27 +1000 Message-Id: <20130628001527.62F723661D01@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 00:15:43 -0000 In message <1372377611.3215.141.camel@karl>, Karl Auer writes: > On Fri, 2013-06-28 at 09:31 +1000, Mark Andrews wrote: > > Then add a cryptographic checksum of the original packet when fragmenting. > > 48 bits in a HBH should be enough. > > Why HBH? Is that to prevent it being send in a fragment itself? And, um, > I hate to suggest this, but isn't that sort of exactly what the AH > header is for? I know, I know.... (covers head, ducks) I really don't care which header it is included in. If we could drop it to 32 bits we could just set the fragment id to the checksum and use one of the reserved bits to indicate that one should treat it as a checksum. My gut feel is that 32 bits is a little to small however. > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer@biplane.com.au) > http://www.biplane.com.au/kauer > http://twitter.com/kauer389 > > GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A > Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From kauer@biplane.com.au Thu Jun 27 17:32:45 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0762E21F85EB for ; Thu, 27 Jun 2013 17:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kr-NgwJX4SB2 for ; Thu, 27 Jun 2013 17:32:44 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id D7F9C21F860B for ; Thu, 27 Jun 2013 17:32:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUBAGnYzFGWZX+7/2dsb2JhbAANToM6Q78SgRiDFwEBAQECAX4LCxguVwYTiAgNqRqSKY4egT6DZQOIapAEinqIRYFX Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.203]) ([150.101.127.187]) by ipmail06.adl2.internode.on.net with ESMTP; 28 Jun 2013 10:02:39 +0930 Message-ID: <1372379554.3215.154.camel@karl> Subject: Re: question re REBIND in RFC 3315 (DHCPv6) From: Karl Auer To: IETF IPv6 Date: Fri, 28 Jun 2013 10:32:34 +1000 In-Reply-To: <1372378387.65495.YahooMailNeo@web142504.mail.bf1.yahoo.com> References: <1372290019.3215.32.camel@karl> <3ED742F1-C82A-43E3-A2CD-CAD8F1E283B1@gmail.com> <1372342144.3215.106.camel@karl> <1372378387.65495.YahooMailNeo@web142504.mail.bf1.yahoo.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 00:32:45 -0000 On Thu, 2013-06-27 at 17:13 -0700, Mark ZZZ Smith wrote: > Perhaps a DHCPv6 server could have a "promiscuous mode" where it > accepts and permits the addresses it doesn't know about in REBIND > messages, with an upper total limit to prevent DoS. It needs to know about them at least in so far as the server is responsible for the range, and knows that the addresses concerned are appropriate for the client's link. > If a host resorts to a DHCPv6 REBIND, and the server doesn't know > about the addresses, the host should continue to use the addresses > while they continue to have a valid lifetime. *Stopping* using inappropriate addresses is thoroughly dealt with, both in RENEW and REBIND, and in the eventual expiry of addresses if neither of those mechanisms is working. The issue that REBIND is supposed to solve, though as it turns out, only with the addition of a moving part that no-one has actually built yet, is the problem of allowing a client to *continue* using an address, even if the server that originally allocated that address is not answering the phone. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 From markzzzsmith@yahoo.com.au Thu Jun 27 22:45:37 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A342F21F9F20 for ; Thu, 27 Jun 2013 22:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbsc3EJ3yi1v for ; Thu, 27 Jun 2013 22:45:33 -0700 (PDT) Received: from nm40-vm1.bullet.mail.bf1.yahoo.com (nm40-vm1.bullet.mail.bf1.yahoo.com [72.30.239.209]) by ietfa.amsl.com (Postfix) with ESMTP id B6D0321F9F93 for ; Thu, 27 Jun 2013 22:45:32 -0700 (PDT) Received: from [66.196.81.170] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 28 Jun 2013 05:45:19 -0000 Received: from [98.139.212.236] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 28 Jun 2013 05:45:19 -0000 Received: from [127.0.0.1] by omp1045.mail.bf1.yahoo.com with NNFMP; 28 Jun 2013 05:45:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 761122.57368.bm@omp1045.mail.bf1.yahoo.com Received: (qmail 51970 invoked by uid 60001); 28 Jun 2013 05:45:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1372398319; bh=f6v+sjjAAA90MkXS9sYWvCSvwM9BcUmfjpr9Lqu7rh8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ueL0zHNK2NpWAVlS0M6xpWOU0/Tt3XpHD9zs7yHch57E+XCfnWyGma/y+xRCDw80kPV3Rby+5+OZ8qCWiFJLW9yTxB8AiDx6sPTxW/X7IEgalDLKqJnUWOAoyHIhKlNJizTL989fic94XPnAB9caxCvSJcOe8neFr1g8IGocrXc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Z/rns0fH/jeeOKKTjbRfhopXcmrTiAbOP2lGZnU8Xy22t6JqAJGwkv9Av1cGwriBQubUJ+gJwmhdbQj9DA//CmeO9imGcXTD2Gn3JF9LpjqLXrJKwYP7zOtq8mUmfg1NZH4lP8o1uulsBLo/e0pwLwvPOWY7bebKVbWEBZLngug=; X-YMail-OSG: I.5H6nsVM1kQEpd_YKAdsTD0y8Da9qGgqfDJvBfAzLnjZ0f jPcyl9LtODf3Pv8CC.n8kzntwV9txdpVErJfbeOIiRbJwHJvF3uRFq4qm.4L qh8cIrqxw5Mb4g61GjvSFbpvXuYnc.XTaAfeo.QXGtGi8WI2cDXr4UUg8swD cttpsCCBmn1WJLbuApnDyUFDGtCKYdAYAnm3utjzX809g3ZSTci5nCOCF6.L 57T.QuaqvDzYbpF3OOemSDtF_skVKLhJr98.vvFN0VtsTHeddp69kuFrLiv1 DQUsrO8jgnb20jnBttrI401IJIslBZKE2n8hdMXhngryjR2TyAPOx56Aj96U MtKo3F87F829wziEd6aoycrs0CQnN6r6JWkhKXdGAMCiou6yxBdIs7dIrBik bxBBrtyEjO7hjS3i_eMEA.zm090vUVB.M3r8pszFtsMFbk3QiaRkqiEps7Aq xnBJhSMfpxQI_JDe3dS31Bti0Sz6FmM71k4gOr3gejvyEHgdooiaTThF1UKT dI9Sp17wG.VgmyKtqXUux3y60FK6brSs9A_hL3HZEZYcXIDVSCStm1zZ5rlY xlFv0CMpDIA611UM_9dHD8BFd0xKfuRQoz4MigRHVxkAhRFgQhy6jH.uBMbR Vu_KIv_u061fajtKPZod_QLeM9FqA9g-- Received: from [150.101.221.237] by web142505.mail.bf1.yahoo.com via HTTP; Thu, 27 Jun 2013 22:45:19 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBLYXJsIEF1ZXIgPGthdWVyQGJpcGxhbmUuY29tLmF1Pgo.IFRvOiBJRVRGIElQdjYgPGlwdjZAaWV0Zi5vcmc.Cj4gQ2M6IAo.IFNlbnQ6IEZyaWRheSwgMjggSnVuZSAyMDEzIDEwOjMyIEFNCj4gU3ViamVjdDogUmU6IHF1ZXN0aW9uIHJlIFJFQklORCBpbiBSRkMgMzMxNSAoREhDUHY2KQo.IAo.IE9uIFRodSwgMjAxMy0wNi0yNyBhdCAxNzoxMyAtMDcwMCwgTWFyayBaWlogU21pdGggd3JvdGU6Cj4.ICBQZXJoYXBzIGEgREhDUHY2IHMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.148.557 References: <1372290019.3215.32.camel@karl> <3ED742F1-C82A-43E3-A2CD-CAD8F1E283B1@gmail.com> <1372342144.3215.106.camel@karl> <1372378387.65495.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1372379554.3215.154.camel@karl> Message-ID: <1372398319.51189.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Thu, 27 Jun 2013 22:45:19 -0700 (PDT) From: Mark ZZZ Smith Subject: Re: question re REBIND in RFC 3315 (DHCPv6) To: Karl Auer , IETF IPv6 In-Reply-To: <1372379554.3215.154.camel@karl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 05:45:38 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Karl Auer =0A> To: IETF IPv6 =0A> Cc: =0A> Sent: Friday, 28 Ju= ne 2013 10:32 AM=0A> Subject: Re: question re REBIND in RFC 3315 (DHCPv6)= =0A> =0A> On Thu, 2013-06-27 at 17:13 -0700, Mark ZZZ Smith wrote:=0A>> Pe= rhaps a DHCPv6 server could have a "promiscuous mode" where it=0A>> accept= s and permits the addresses it doesn't know about in REBIND=0A>> messages,= with an upper total limit to prevent DoS.=0A> =0A> It needs to know about = them at least in so far as the server is=0A> responsible for the range, and= knows that the addresses concerned are=0A> appropriate for the client's li= nk.=0A> =0A>> If a host resorts to a DHCPv6 REBIND, and the server doesn't= know=0A>> about the addresses, the host should continue to use the addres= ses=0A>> while they continue to have a valid lifetime.=0A> =0A> *Stopping*= using inappropriate addresses is thoroughly dealt with, both=0A> in RENEW = and REBIND, and in the eventual expiry of addresses if neither=0A> of those= mechanisms is working.=0A> =0A> The issue that REBIND is supposed to solve= , though as it turns out, only=0A> with the addition of a moving part that = no-one has actually built yet,=0A> is the problem of allowing a client to *= continue* using an address,=0A=0AI think a client is allowed to continue to= use an address if the address's valid lifetime is non-zero, regardless of = how that address was acquired, be it stateful DHCPv6, SLAAC or static.=0A= =0AStateful DHCPv6 doesn't seem to tightly bind the state of addresses it i= ssues to the state of the DHCPv6 session, such that if the DHCPv6 session g= oes away the addresses go away. If it did, I think there would be would be = statements in RFC3315 to set T1 and T2 timers to the values intended for pr= efix preferred and valid lifetimes, there would be no need for preferred an= d valid lifetime fields in the IAs for addresses, and there would be=A0stat= ements saying that if the DHCPv6 session fails for any reason then the clie= nt MUST remove the addresses acquired during that session.=A0=0A=0AI think = this means that at RENEW or REBIND time, the client is only checking to see= if there are updated values for the addresses (and other options), and to = register a continuing interest in using the addresses. The client is not se= eking permission to continue to use the addresses, such that absence of the= DHCPv6 server would mean that it doesn't have permission any more. If the = client has non-zero valid lifetimes for the DHCPv6 supplied addresses, that= is all the permission it needs to continue to use them.=0A=0A=0AI think th= is is what allows SLAAC and stateful DHCPv6 to co-exist, which then allows = a transition between one method and the other. The only arbiter of whether = an address on a host is valid or deprecated is the host's own values of the= preferred and valid lifetimes. Stateful DHCPv6 or RA PIOs can be used to c= hange those values, indirectly controlling the address validity, but disapp= earance of the DHCPv6 server or the router issuing PIO containing RAs shoul= dn't cause the addresses that were configured using that method to then imm= ediately become invalid.=0A=0ARegards,=0AMark.=0A=0A=0A> even=0A> if the se= rver that originally allocated that address is not answering=0A> the phone.= =0A> =0A> Regards, K.=0A> =0A> -- =0A> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=0A> Karl Auer (kauer@biplane.com.au)=0A= > http://www.biplane.com.au/kauer=0A> http://twitter.com/kauer389=0A> =0A> = GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A=0A> Old = fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017=0A> =0A> ---= -----------------------------------------------------------------=0A> IETF = IPv6 working group mailing list=0A> ipv6@ietf.org=0A> Administrative Reques= ts: https://www.ietf.org/mailman/listinfo/ipv6=0A> ------------------------= --------------------------------------------=0A> From kauer@biplane.com.au Thu Jun 27 23:56:07 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AAB21F9374 for ; Thu, 27 Jun 2013 23:56:07 -0700 (PDT) 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=[J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzBDaWgJyS1N for ; Thu, 27 Jun 2013 23:56:01 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id C9D7621F8468 for ; Thu, 27 Jun 2013 23:55:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoCAN8yzVGWZX+7/2dsb2JhbAANToM6Q78MBAQBgRqDFwEBAQMBfgsLGC5XBhOICA2pI5Isj1yDZQOIapAEinqIRQ Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.203]) ([150.101.127.187]) by ipmail06.adl2.internode.on.net with ESMTP; 28 Jun 2013 16:25:17 +0930 Message-ID: <1372402515.3215.240.camel@karl> Subject: Re: question re REBIND in RFC 3315 (DHCPv6) From: Karl Auer To: IETF IPv6 Date: Fri, 28 Jun 2013 16:55:15 +1000 In-Reply-To: <1372398319.51189.YahooMailNeo@web142505.mail.bf1.yahoo.com> References: <1372290019.3215.32.camel@karl> <3ED742F1-C82A-43E3-A2CD-CAD8F1E283B1@gmail.com> <1372342144.3215.106.camel@karl> <1372378387.65495.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1372379554.3215.154.camel@karl> <1372398319.51189.YahooMailNeo@web142505.mail.bf1.yahoo.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 06:56:07 -0000 On Thu, 2013-06-27 at 22:45 -0700, Mark ZZZ Smith wrote: > I think a client is allowed to continue to use an address if the > address's valid lifetime is non-zero, regardless of how that address > was acquired, be it stateful DHCPv6, SLAAC or static. That's debatable according to Microsoft. Send an RA past with the M flag unset and watch the addresses get dropped! Valid schmalid. I consider that behaviour a bug, but opinions do apparently differ. The way you describe it is how it should be, but sometimes isn't. > Stateful DHCPv6 doesn't seem to tightly bind the state of addresses it > issues to the state of the DHCPv6 session, such that if the DHCPv6 > session goes away the addresses go away. There is no session...? Not sure what you are saying here. > If it did, I think there would be would be statements in RFC3315 to > set T1 and T2 timers to the values intended for prefix preferred and > valid lifetimes Not to those values, but the RFC does say that they should be set with reference to the preferred and valid lifetimes: The server selects the T1 and T2 times to allow the client to extend the lifetimes of any addresses in the IA_NA before the lifetimes expire, even if the server is unavailable for some short period of time. Recommended values for T1 and T2 are .5 and .8 times the shortest preferred lifetime of the addresses in the IA that the server is willing to extend, respectively. If the "shortest" preferred lifetime is 0xffffffff ("infinity"), the recommended T1 and T2 values are also 0xffffffff. But it can be left to the client, which would then presumably choose not-dissimilar values: If the time at which the addresses in an IA_NA are to be renewed is to be left to the discretion of the client, the server sets T1 and T2 to 0. > there would be statements saying that if the DHCPv6 session fails for > any reason then the client MUST remove the addresses acquired during > that session. There is no session...? The RFC *does* say that if the client cannot renew its addresses before they expire it must stop using them. It must also remove them if, during RENEW or REBIND, the responding server authoritatively rejects them (see sections 18.2.4 and 19.4.5) by setting their lifetimes to zero. > I think this means that at RENEW or REBIND time, the client is only > checking to see if there are updated values for the addresses (and > other options), and to register a continuing interest in using the > addresses. The client is not seeking permission to continue to use the > addresses, such that absence of the DHCPv6 server would mean that it > doesn't have permission any more. If the client has non-zero valid > lifetimes for the DHCPv6 supplied addresses, that is all the > permission it needs to continue to use them. well - yes - but the responding server might set them to zero. Or it might return the same values as last time, refreshing the lease. It could even shorten the lease without terminating it. But from the client's perspective, the RENEW and REBIND messages are absolutely about the client seeking to extend its use of its addresses. I'm not sure I see the distinction in your statement above. > The only arbiter of whether an address on a host is valid or > deprecated is the host's own values of the preferred and valid > lifetimes. Stateful DHCPv6 or RA PIOs can be used to change those > values, indirectly controlling the address validity, but disappearance > of the DHCPv6 server or the router issuing PIO containing RAs > shouldn't cause the addresses that were configured using that method > to then immediately become invalid. Well, no. How does the host know they've "disappeared" anyway? There is no "session". If the host doesn't see RAs for long enough the valid lifetime of a SLAAC expires and the address must be dropped. If the host doesn't get answers to RENEW and REBIND messages, the valid lifetime of a an address acquired via DHCPv6 expires and the address must be dropped. It's a pretty simple setup, really. The question that started all this was whether a REBIND can ever be used by a server to extend the lease on an address it didn't allocate. Short answer is "no". The longer answer is "no, unless there is some kind of sharing of IAs happening, which is not specified in RFC3315". Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 From volz@cisco.com Fri Jun 28 05:33:45 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8936521F9B14 for ; Fri, 28 Jun 2013 05:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Okq5dX-S87lq for ; Fri, 28 Jun 2013 05:33:34 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id EB6C021F9EFB for ; Fri, 28 Jun 2013 05:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1377; q=dns/txt; s=iport; t=1372422771; x=1373632371; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xcOyVy237RlVrTfKwgrFcf9Q9l2SVEQuWufQjQBXkrk=; b=Z1liWdE/C6uR7mQ+HN7rSidPFhVZ2nyFMaa/XY8+R/YereexBRpoBrq/ W4U01qxEonlBLzEYQQwBIJUfnL8ULKgIRTDtV2LpF0BNUo26QrIx6UVwc N45C//Q2abK80QE8LjyNVObTdhPIaRB07K1X9MQJGc5uT6Z1qmuSCcpHT 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANqBzVGtJV2b/2dsb2JhbABbgmDABIEGgQmCIwEBAQMBOjQDCAULAgEIDigQMiUCBA4FiAgGs0iPIjMHgwJjA5dFkUWDEQ X-IronPort-AV: E=Sophos;i="4.87,958,1363132800"; d="scan'208";a="228576943" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 28 Jun 2013 12:32:50 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5SCWoFv003329 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Jun 2013 12:32:50 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 07:32:50 -0500 From: "Bernie Volz (volz)" To: Karl Auer Subject: Re: question re REBIND in RFC 3315 (DHCPv6) Thread-Topic: question re REBIND in RFC 3315 (DHCPv6) Thread-Index: AQHOc8Ks10Y+ta1O/UyOynXqD99giJlLBS6AgAAKf78= Date: Fri, 28 Jun 2013 12:32:49 +0000 Message-ID: References: <1372290019.3215.32.camel@karl> <3ED742F1-C82A-43E3-A2CD-CAD8F1E283B1@gmail.com> <1372342144.3215.106.camel@karl> <1372378387.65495.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1372379554.3215.154.camel@karl> <1372398319.51189.YahooMailNeo@web142505.mail.bf1.yahoo.com>, <1372402515.3215.240.camel@karl> In-Reply-To: <1372402515.3215.240.camel@karl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 12:33:45 -0000 The question that started all this was whether a REBIND can ever be used by a server to extend the lease on an address it didn't allocate. Short answer is "no". The longer answer is "no, unless there is some kind of sharing of IAs happening, which is not specified in RFC3315". The sharing part was out of scope for 3315. Failover might be one such mech= anism (which is being worked on in the DHC wg). There are others such as a = shared database. And there is also the ability to trust clients as long as there is no confl= ict (known by the server). So while perhaps not directly spelled out in 331= 5, a server could use the client supplied information to generate the bindi= ngs and leases. With failover, there are reasons why doing this might be ap= propriate -- the lazy update might not have been sent before the partner th= at gave out the lease went down. This is done in v4 failover. I'm not surr why this isn't on the dhc wg mailing list? - Bernie (from iPad) On Jun 28, 2013, at 2:56 AM, "Karl Auer" wrote: > The question that started all this was whether a REBIND can ever be used > by a server to extend the lease on an address it didn't allocate. Short > answer is "no". The longer answer is "no, unless there is some kind of > sharing of IAs happening, which is not specified in RFC3315". From he@uninett.no Fri Jun 28 06:26:10 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D1E21F9B52 for ; Fri, 28 Jun 2013 06:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5Ma3uTKklQi for ; Fri, 28 Jun 2013 06:26:05 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0B621F888F for ; Fri, 28 Jun 2013 06:25:29 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 097A43D0B5 for ; Fri, 28 Jun 2013 15:25:27 +0200 (CEST) Date: Fri, 28 Jun 2013 15:25:26 +0200 (CEST) Message-Id: <20130628.152526.152295907.he@uninett.no> To: ipv6@ietf.org Subject: draft-bonica-6man-frag-deprecate From: Havard Eidnes X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 13:26:10 -0000 Hi, some comments from this corner, some small, some not so...: In section 1: MTU is a unidirectional metric. A bidirectional link may be characterized by one MTU in the forward direction and another MTU in the reverse direction. I'm sure this is formally true. However, in practice, I have never seen a router where you can separately configure the receive and transmit MTU. So ... I would remove this altogether; it may otherwise pave the way for unsuspecting individuals reading this to create a path MTU discovery black hole by configuring inconsistent MTUs for devices on the same link. In section 2.1: [Kent87] points out that the reassembly process is resource intensive. It consumes significant compute and memory resources. Is that argument still valid today? Is it impossible to engineer an implementaiton which restricts the memory consumption in order to improve robustness of the implementation? Section 2.2 states "Fragmentation Is Rare". I think this will be hihgly dependent on your choice of observation points. E.g. in the vicinity of an NFS server serving using UDP, I would not be surprised to see a lot of fragments. And, as has been mentioned elsewhere in this discussion, in the vicinity of a DNSSEC-validating recursive DNS resolver, you would expect to see an increasing proportion of fragmented UDP traffic as DNSSEC deployment progresses. In section 2.2.1, the document appears to dismiss the DNSSEC use of UDP and fragmentation with "use TCP instead". I beleive Mark Andrews in <20130624030939.CA0DD363070C@drugs.dv.isc.org> stated why this is far from good enough as an answer. In addition to TCP PMTUD being too slow, you have the issue that TCP in general is about 3 times slower than UDP in delivering a DNS response even if PMTUD is not involved -- I beleive RIPE NCC Labs did a test using their "RIPE Atlas" probes to check for this, and they came up with 2.5x - 3x as the slowdown factor. Additionally there is the vastly increased need to keep state in DNS name servers by the TCP load which would result from the abolishment of UDP as a transport for DNS. On top of this, there is the argument that "firewalls and network operators may filter DNS over TCP", but I would not use that as an argument because I consider it invalid -- more on that below. Section 2.3, "Attack vectors". Isn't this whole section giving bad excuses to IP stack implementors for not providing a robust and well-tested implementation?!? BTW, I'm wondering whether there is a spec issue lurking within this area, wrt. invalidating the most obscure corner cases? Section 2.4, "Operator behavior". It is claimed that IPv6 fragments are being dropped in several places, e.g. by enterprise firewalls or other environments who want to tightly control what traffic is passed. I claim that is's a matter of principle whether we let the tail wag the dog. Firewall administrators or other users of the network may do unwise things when configuring their device, but should such behaviour be allowed to restrict what becomes standardized?!? If that were the case, we might as well all restrict ourselves to speaking TCP over port 80. Section 3, "Recommendation". I question whether you can in fact make the backward-incompatible change of getting rid of the need for implementations to support fragment reassembly -- the genie is already out of the bottle -- has been for quite a while, and I claim it's already too late to try to put it back in. So some of the claimed attack vectors in section 2.3 will also be difficult to get rid of, as hosts will in all probability have to continue to support fragment reassembly for quite a while. At the very least, there's a need to separate the recommendations for "sending fragments" and "support reception of fragments". Best regards, - H=E5vard From nygren@gmail.com Fri Jun 28 08:36:20 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002E821F9BF6 for ; Fri, 28 Jun 2013 08:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5Y93-iVy6Jx for ; Fri, 28 Jun 2013 08:36:19 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5D71C21F9BF5 for ; Fri, 28 Jun 2013 08:36:19 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id db10so1958566veb.12 for ; Fri, 28 Jun 2013 08:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tGvX+Pjdk/HsDZQOfIWdiagKwjfxRpPXcus4yi53wjQ=; b=cpl+B8xjfa97i8Q1U7O7szGC2HxHzudLlbs5W6twp8Y5+R1A0TMcpgpCjtqJGt67lj aLWfBq3o0aBG0sEyy9qqJGAqnaGt1S0j6J+W7csOgkp3D2yc4qlohVYor1EAu1LlGsFz 7afOYLcywHzGfTiDdOgUCpq2N8r/dApTHCipCWwIp4Ix+qz+fvvm2FA2ct4zS0v6znBS OQsMjhCg3aCEWFy5Gdn99Nirn8ZH6V4hXvqRKFkmVu0KdkXaNJ6MW9jeUVBQKV8pVhw8 fOeVBv3FAcrOWOOh1Uq9Ds9u26oSTahe5Lic3Vk6wrJ0VbGGDyw5ELrHHcjr50/jYIVh Ysjg== MIME-Version: 1.0 X-Received: by 10.220.83.69 with SMTP id e5mr3115345vcl.53.1372433778751; Fri, 28 Jun 2013 08:36:18 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.220.79.138 with HTTP; Fri, 28 Jun 2013 08:36:18 -0700 (PDT) In-Reply-To: <51CA2C56.1080809@gmail.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> <51CA2C56.1080809@gmail.com> Date: Fri, 28 Jun 2013 11:36:18 -0400 X-Google-Sender-Auth: ANEVIpRWeYNaDajBrrrVl-GuIMs Message-ID: Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt From: Erik Nygren To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 15:36:20 -0000 If we accept that 1280 is the only non-broken MTU for IPv6, I share James' fear that this would spell doom for IPv6 on the broad Internet and land us in a world where broad IPv6 adoption stalls out and IPv4 ith CGN dominates. The current reality is that many hosts do have 1500 byte MTUs (as Tore observed with many of the top Alexa sites, and presumably also with the default configuration for many hosts out there). We need to make sure that this current reality keeps working. If content providers need to drop their IPv6 MTU/MSS down below that of IPv4 (eg, to 1280), this has the potential to be enough of a performance difference (even a few percent matters!) to cause many content providers to hold off indefinitely on dual-stacking. If large ISPs or enterprises need to find some way to get their end users down to lower MTUs or need to wait for some OS updates to do some other form of PMTU discovery, then IPv6 is DOA for them as well and they'll have a good excuse to not roll out out. As such, I agree with other comments that it's important to re-emphasize that any environment that both blocks ICMPv6 PTB and at the same time doesn't allow 1500 byte packets through is broken and needs to get fixed. This also means that anyone deploying or implementing a tunnel (or VPN) needs to carefully consider how they'll deal with this. For fragments themselves, would it make more sense to constrain their usage rather than deprecate them entirely? For example, express that certain headers may not appear in fragments, and also perhaps express that overlapping fragments or overly spase fragments are likely to be dropped? In looking at a global end-user facing HTTP (TCP) environment, I'm seeing around 0.0005% of the packets arrive as fragments which sounds similar to some of the other numbers on this thread. Erik On Tue, Jun 25, 2013 at 7:48 PM, Brian E Carpenter wrote: > On 26/06/2013 11:08, james woodyatt wrote: >> On Jun 25, 2013, at 13:13 , Randy Bush wrote: >>> ron has made one suggestion. though brutal, its simplicity and its >>> recognition of reality appeal to me. >> >> Why not go large and deprecate all of RFC 2460? >> >> I'm not entirely joking. If the practical global MTU for IPv6 is 1280, ... > > We went through a protracted phase where the practical global MTU > for IPv4 was around 512, unless you wanted to reconfigure your laptop > stack experimentally each time you checked into a hotel and figured > out how to connect to the phone line. I even recall having to set the > MTU to 256 in one hotel. We may well have to accept a protracted phase > of 1280 for IPv6. Eventually it will resolve itself, as it did for IPv4. > I think that's orthogonal to the question of deprecating L3 fragmentation. > > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From Fred.L.Templin@boeing.com Fri Jun 28 09:00:59 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C83E21F9BE5 for ; Fri, 28 Jun 2013 09:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaHUInxhBzx2 for ; Fri, 28 Jun 2013 09:00:54 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7410B21F9BF5 for ; Fri, 28 Jun 2013 09:00:37 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r5SG0ZXV015255 for ; Fri, 28 Jun 2013 11:00:36 -0500 Received: from XCH-PHX-510.sw.nos.boeing.com (xch-phx-510.sw.nos.boeing.com [10.57.37.27]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r5SG0YnH015246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 28 Jun 2013 11:00:35 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-PHX-510.sw.nos.boeing.com ([169.254.10.143]) with mapi id 14.02.0328.011; Fri, 28 Jun 2013 09:00:34 -0700 From: "Templin, Fred L" To: Erik Nygren , Brian E Carpenter Subject: RE: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHOdBU7I1L7sow7kkSTr5SDOLoWMJlLRKJA Date: Fri, 28 Jun 2013 16:00:33 +0000 Message-ID: <2134F8430051B64F815C691A62D983180AFC95@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> <51CA2C56.1080809@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 16:00:59 -0000 Hi, > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Erik Nygren > Sent: Friday, June 28, 2013 8:36 AM > To: Brian E Carpenter > Cc: 6man > Subject: Re: New Version Notification for draft-bonica-6man-frag- > deprecate-00.txt >=20 > If we accept that 1280 is the only non-broken MTU for IPv6, I share > James' fear that this would spell doom for IPv6 on the broad Internet > and land us in a world where broad IPv6 adoption stalls out and IPv4 > ith CGN dominates. It doesn't have to be that way. With SEAL, packets up to 1500 get through no matter what, and larger packets also get through if the path MTU is sufficiently large. > The current reality is that many hosts do have > 1500 byte MTUs (as Tore observed with many of the top Alexa sites, and > presumably also with the default configuration for many hosts out > there). We need to make sure that this current reality keeps working. >=20 > If content providers need to drop their IPv6 MTU/MSS down below that > of IPv4 (eg, to 1280), this has the potential to be enough of a > performance difference (even a few percent matters!) to cause many > content providers to hold off indefinitely on dual-stacking. If large > ISPs or enterprises need to find some way to get their end users down > to lower MTUs or need to wait for some OS updates to do some other > form of PMTU discovery, then IPv6 is DOA for them as well and they'll > have a good excuse to not roll out out. >=20 > As such, I agree with other comments that it's important > to re-emphasize that any environment that both blocks ICMPv6 PTB > and at the same time doesn't allow 1500 byte packets through is broken > and needs to get fixed. This also means that anyone deploying > or implementing a tunnel (or VPN) needs to carefully consider > how they'll deal with this. Right. Tunnels over IPv6 absolutely require some form of frag/reass to meet the IPv6 minMTU of 1280. SEAL goes it one better and ensures that everything up to 1500 makes it through.=20 > For fragments themselves, would it make more sense to constrain > their usage rather than deprecate them entirely? For example, > express that certain headers may not appear in fragments, > and also perhaps express that overlapping fragments or overly > spase fragments are likely to be dropped? I think the question has been raised as to whether standard IPv6 frag/reass can be re-worked now that it is already in widespread deployment. SEAL fixes these and other issues and also has the advantage that it doesn't yet have a widespread deployed base. Thanks - Fred fred.l.templin@boeing.com > In looking at a global end-user facing HTTP (TCP) environment, > I'm seeing around 0.0005% of the packets arrive as fragments > which sounds similar to some of the other numbers on this thread. >=20 > Erik >=20 >=20 >=20 > On Tue, Jun 25, 2013 at 7:48 PM, Brian E Carpenter > wrote: > > On 26/06/2013 11:08, james woodyatt wrote: > >> On Jun 25, 2013, at 13:13 , Randy Bush wrote: > >>> ron has made one suggestion. though brutal, its simplicity and its > >>> recognition of reality appeal to me. > >> > >> Why not go large and deprecate all of RFC 2460? > >> > >> I'm not entirely joking. If the practical global MTU for IPv6 is > 1280, ... > > > > We went through a protracted phase where the practical global MTU > > for IPv4 was around 512, unless you wanted to reconfigure your laptop > > stack experimentally each time you checked into a hotel and figured > > out how to connect to the phone line. I even recall having to set the > > MTU to 256 in one hotel. We may well have to accept a protracted > phase > > of 1280 for IPv6. Eventually it will resolve itself, as it did for > IPv4. > > I think that's orthogonal to the question of deprecating L3 > fragmentation. > > > > Brian > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From jhw@apple.com Fri Jun 28 12:22:57 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2FA21F9C49 for ; Fri, 28 Jun 2013 12:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQgNAfPTppQF for ; Fri, 28 Jun 2013 12:22:47 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id EE56621F9C4C for ; Fri, 28 Jun 2013 12:22:33 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay7.apple.com ([17.128.113.101]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MP400J7PB4EBEX0@mail-out.apple.com> for ipv6@ietf.org; Fri, 28 Jun 2013 12:21:56 -0700 (PDT) X-AuditID: 11807165-b7f496d000000613-74-51cde25417f8 Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id C5.F7.01555.452EDC15; Fri, 28 Jun 2013 12:21:56 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MP400MBAB4JXJ60@aniseed.apple.com> for ipv6@ietf.org; Fri, 28 Jun 2013 12:21:56 -0700 (PDT) Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt From: james woodyatt In-reply-to: Date: Fri, 28 Jun 2013 12:21:56 -0700 Message-id: References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> <51CA2C56.1080809@gmail.com> To: 6man X-Mailer: Apple Mail (2.1782) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUi2FAsrhvy6GygwePbUhYvz75ncmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxve3S5gK/slWfF/5n7GB8ZRYFyMnh4SAicTR23vYIWwxiQv3 1rN1MXJxCAn0M0m8PLmXCcKZziTRuWEZWBWzgI5E7/dvzCA2r4CexLznvWBxYYFgiR0HpzCB 2GwCKhLfLt8FszmB4u9ftYHVswioSiyac5QFYo62xJN3F1gh5thIHLp3GWrzb1aJ21deMIIk RAQkJK4tesQGcZ6sxLufsxgnMPLPQnLHLCR3zEIydwEj8ypGgaLUnMRKc73EgoKcVL3k/NxN jOAgK0zdwdi43OoQowAHoxIP74u5ZwOFWBPLiitzDzFKcDArifByzwMK8aYkVlalFuXHF5Xm pBYfYpTmYFES55XyOh4oJJCeWJKanZpakFoEk2Xi4JRqYBRx/LuOIfiMatLfHpHrVYz5PFc6 v+Z0yBtqnIpQFnu1pKqDKbnR9EzSTYbrWeYJKS6O1up8/2/sUo8W41zXNJ/5gX7GZE57XuHc yV8VTk5S0zKQeNFeF/gm7qi6Ss7kKVzmvdOFum66WR7bscnlyP+p+RKCk+8vCrYJTbg4n1O4 iOVyR6C4EktxRqKhFnNRcSIASwBxPS4CAAA= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 19:22:57 -0000 On Jun 28, 2013, at 08:36 , Erik Nygren wrote: > [...] > As such, I agree with other comments that it's important > to re-emphasize that any environment that both blocks ICMPv6 PTB > and at the same time doesn't allow 1500 byte packets through is broken > and needs to get fixed. This also means that anyone deploying > or implementing a tunnel (or VPN) needs to carefully consider > how they'll deal with this. > [...] And this is where I point at RFC 2473 "Generic Packet Tunneling in IPv6" section 7.2 "IPv4 Tunnel Packet Fragmentation" which I will quote for handy reference below: >> 7.2 IPv4 Tunnel Packet Fragmentation >> >> When an IPv4 original packet enters a tunnel, if the original packet >> size exceeds the tunnel MTU (i.e., the Path MTU between the tunnel >> entry-point and the tunnel exit-point, minus the size of the tunnel >> header(s)), it is handled as follows: >> >> (a) if in the original IPv4 packet header the Don't Fragment - >> DF - bit flag is SET, the entry-point node discards the >> packet and returns an ICMP message. The ICMP message has >> the type = "unreachable", the code = "packet too big", and >> the recommended MTU size field set to the size of the >> tunnel MTU - see sections 6.7 and 8.3. >> >> (b) if in the original packet header the Don't Fragment - DF - >> bit flag is CLEAR, the tunnel entry-point node encapsulates >> the original packet, and subsequently fragments the >> resulting IPv6 tunnel packet into IPv6 fragments that do >> not exceed the Path MTU to the tunnel exit-point. This is cited in RFC 6333 "Dual-stack Lite" section 5.3 "Fragmentation and Reassembly" which I will also quote for handy reference: >> 5.3. Fragmentation and Reassembly >> >> Using an encapsulation (IPv4-in-IPv6 or anything else) to carry IPv4 >> traffic over IPv6 will reduce the effective MTU of the datagram. >> Unfortunately, path MTU discovery [RFC1191] is not a reliable method >> to deal with this problem. >> >> A solution to deal with this problem is for the service provider to >> increase the MTU size of all the links between the B4 element and the >> AFTR elements by at least 40 bytes to accommodate both the IPv6 >> encapsulation header and the IPv4 datagram without fragmenting the >> IPv6 packet. >> >> However, as not all service providers will be able to increase their >> link MTU, the B4 element MUST perform fragmentation and reassembly if >> the outgoing link MTU cannot accommodate the extra IPv6 header. The >> original IPv4 packet is not oversized. The packet is oversized after >> the IPv6 encapsulation. The inner IPv4 packet MUST NOT be >> fragmented. Fragmentation MUST happen after the encapsulation of the >> IPv6 packet. Reassembly MUST happen before the decapsulation of the >> IPv4 packet. A detailed procedure has been specified in [RFC2473] >> Section 7.2. Clearly, this proposal to deprecate IPv6 fragmentation headers entails an update to RFC 2473 and RFC 6333 as well as RFC 2460. The procedure for encapsulating IPv4 packets with DF=0 in IPv6 tunnels where the path MTU is less than typical IPv4 path MTU currently requires tunnel endpoints to use IPv6 fragment headers. I guess they have to stop doing that if this RFC is published. I'm also excited to learn about how we're going to add PLPMTUD to GRE and tunnel-mode IPsec ESP so they have some hope of using path MTU larger than 1280 octets. -- james woodyatt core os networking From Fred.L.Templin@boeing.com Fri Jun 28 12:32:37 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F6C21F9C5E for ; Fri, 28 Jun 2013 12:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhpgTrsrW-oS for ; Fri, 28 Jun 2013 12:32:31 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD7821F9C5A for ; Fri, 28 Jun 2013 12:32:31 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r5SJWUfb025817 for ; Fri, 28 Jun 2013 12:32:30 -0700 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r5SJWTTY025814 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 28 Jun 2013 12:32:29 -0700 Received: from XCH-BLV-403.nw.nos.boeing.com (130.247.25.62) by XCH-NWHT-11.nw.nos.boeing.com (130.247.25.114) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 28 Jun 2013 12:32:30 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-BLV-403.nw.nos.boeing.com ([169.254.3.80]) with mapi id 14.02.0328.011; Fri, 28 Jun 2013 12:32:30 -0700 From: "Templin, Fred L" To: james woodyatt , 6man Subject: RE: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHOdDTAI1L7sow7kkSTr5SDOLoWMJlLgu5A Date: Fri, 28 Jun 2013 19:32:28 +0000 Message-ID: <2134F8430051B64F815C691A62D983180AFF83@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> <51CA2C56.1080809@gmail.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 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 19:32:37 -0000 Hi James, > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > james woodyatt > Sent: Friday, June 28, 2013 12:22 PM > To: 6man > Subject: Re: New Version Notification for draft-bonica-6man-frag- > deprecate-00.txt >=20 > On Jun 28, 2013, at 08:36 , Erik Nygren wrote: > > [...] > > As such, I agree with other comments that it's important > > to re-emphasize that any environment that both blocks ICMPv6 PTB > > and at the same time doesn't allow 1500 byte packets through is > broken > > and needs to get fixed. This also means that anyone deploying > > or implementing a tunnel (or VPN) needs to carefully consider > > how they'll deal with this. > > [...] >=20 > And this is where I point at RFC 2473 "Generic Packet Tunneling in > IPv6" section 7.2 "IPv4 Tunnel Packet Fragmentation" which I will quote > for handy reference below: Yes, that has already been pointed out on the intarea list where some parallel discussions have transpired. > >> 7.2 IPv4 Tunnel Packet Fragmentation > >> > >> When an IPv4 original packet enters a tunnel, if the original > packet > >> size exceeds the tunnel MTU (i.e., the Path MTU between the > tunnel > >> entry-point and the tunnel exit-point, minus the size of the > tunnel > >> header(s)), it is handled as follows: > >> > >> (a) if in the original IPv4 packet header the Don't > Fragment - > >> DF - bit flag is SET, the entry-point node discards the > >> packet and returns an ICMP message. The ICMP message > has > >> the type =3D "unreachable", the code =3D "packet too big"= , > and > >> the recommended MTU size field set to the size of the > >> tunnel MTU - see sections 6.7 and 8.3. > >> > >> (b) if in the original packet header the Don't Fragment - > DF - > >> bit flag is CLEAR, the tunnel entry-point node > encapsulates > >> the original packet, and subsequently fragments the > >> resulting IPv6 tunnel packet into IPv6 fragments that > do > >> not exceed the Path MTU to the tunnel exit-point. >=20 > This is cited in RFC 6333 "Dual-stack Lite" section 5.3 "Fragmentation > and Reassembly" which I will also quote for handy reference: >=20 > >> 5.3. Fragmentation and Reassembly > >> > >> Using an encapsulation (IPv4-in-IPv6 or anything else) to carry > IPv4 > >> traffic over IPv6 will reduce the effective MTU of the datagram. > >> Unfortunately, path MTU discovery [RFC1191] is not a reliable > method > >> to deal with this problem. > >> > >> A solution to deal with this problem is for the service provider > to > >> increase the MTU size of all the links between the B4 element and > the > >> AFTR elements by at least 40 bytes to accommodate both the IPv6 > >> encapsulation header and the IPv4 datagram without fragmenting > the > >> IPv6 packet. > >> > >> However, as not all service providers will be able to increase > their > >> link MTU, the B4 element MUST perform fragmentation and > reassembly if > >> the outgoing link MTU cannot accommodate the extra IPv6 header. > The > >> original IPv4 packet is not oversized. The packet is oversized > after > >> the IPv6 encapsulation. The inner IPv4 packet MUST NOT be > >> fragmented. Fragmentation MUST happen after the encapsulation of > the > >> IPv6 packet. Reassembly MUST happen before the decapsulation of > the > >> IPv4 packet. A detailed procedure has been specified in > [RFC2473] > >> Section 7.2. >=20 > Clearly, this proposal to deprecate IPv6 fragmentation headers entails > an update to RFC 2473 and RFC 6333 as well as RFC 2460. The procedure > for encapsulating IPv4 packets with DF=3D0 in IPv6 tunnels where the path > MTU is less than typical IPv4 path MTU currently requires tunnel > endpoints to use IPv6 fragment headers. I guess they have to stop doing > that if this RFC is published. Right; it is already well established that tunnels over IPv6 MUST perform some form of frag/reass in order to meet the IPv6 minMTU. =20 > I'm also excited to learn about how we're going to add PLPMTUD to GRE > and tunnel-mode IPsec ESP so they have some hope of using path MTU > larger than 1280 octets. https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ Thanks - Fred fred.l.templin@boeing.com =20 > -- > james woodyatt > core os networking >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From jhw@apple.com Fri Jun 28 13:41:14 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A1521F9CC1 for ; Fri, 28 Jun 2013 13:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPB-e9FmZ2hS for ; Fri, 28 Jun 2013 13:41:08 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 378ED21F92A5 for ; Fri, 28 Jun 2013 13:41:06 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MP400AC1ESBOP11@mail-out.apple.com> for ipv6@ietf.org; Fri, 28 Jun 2013 13:41:04 -0700 (PDT) X-AuditID: 11807166-b7faa6d000003acb-bd-51cdf4e0e391 Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 88.33.15051.0E4FDC15; Fri, 28 Jun 2013 13:41:04 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MP400MORESGXJ80@aniseed.apple.com> for ipv6@ietf.org; Fri, 28 Jun 2013 13:41:04 -0700 (PDT) Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt From: james woodyatt In-reply-to: <2134F8430051B64F815C691A62D983180AFF83@XCH-BLV-504.nw.nos.boeing.com> Date: Fri, 28 Jun 2013 13:41:03 -0700 Message-id: <09B6DBA3-0DF1-4BD9-98EF-E6CA672B977F@apple.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> <51CA2C56.1080809@gmail.com> <2134F8430051B64F815C691A62D983180AFF83@XCH-BLV-504.nw.nos.boeing.com> To: 6man X-Mailer: Apple Mail (2.1782) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUi2FAsrvvgy9lAg1u7jSxenn3P5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujG1XN7EX7GeteN7Rx9LAuJGli5GTQ0LARGLNrr2MELaYxIV7 69m6GLk4hAT6mSR+bJ/FBOFMZ5I48WQGG0gVs4CWxPqdx5lAbF4BPYl5z3vZQWxhgWCJHQen gMXZBFQkvl2+C2ZzCoRK3J57BKyXRUBVYu+s9YwQc7Qlnry7wAoxx0bi2uaFUJu/s0m0HzsJ lhARkJC4tugRG8R5shLvfs5inMDIPwvJHbOQ3DELydwFjMyrGAWKUnMSKy30EgsKclL1kvNz NzGCg6wwbQdj03KrQ4wCHIxKPLwOC84GCrEmlhVX5h5ilOBgVhLh5Z4HFOJNSaysSi3Kjy8q zUktPsQozcGiJM4r7XU8UEggPbEkNTs1tSC1CCbLxMEp1cB48p71gvNCD54eCNnseDyFcbm/ 6suaSOHe3ZqZMzRmBxwMaP49QziIKyC3OecQ228B0UwffVar4icLwtob/rzOfPHz85EnU0x+ yep9f/oqizdIX/DY/qP95hc/c64Ru+DU+sFh03q+LXd6DY3Yd8xbGyLxmztO+IGAR9gx9Tcp q851N7SlG8xRYinOSDTUYi4qTgQA/hscxC4CAAA= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 20:41:14 -0000 On Jun 28, 2013, at 12:32 , Templin, Fred L wrote: > [I wrote:] >> >> I'm also excited to learn about how we're going to add PLPMTUD to GRE >> and tunnel-mode IPsec ESP so they have some hope of using path MTU >> larger than 1280 octets. > > https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ I'm not sure I read this comment correctly. Are you suggesting that we should replace tunnel-mode ESP and GRE tunnels with SEAL in order to get PLPMTUD to work? Are we all *really* okay with just trashing ESP and GRE like that? Maybe we should be moving to deprecate those too? -- james woodyatt core os networking From brian.e.carpenter@gmail.com Fri Jun 28 13:48:49 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF1121F9C63 for ; Fri, 28 Jun 2013 13:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIYV8y-zkpvx for ; Fri, 28 Jun 2013 13:48:48 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id BA73A21F9A4B for ; Fri, 28 Jun 2013 13:48:48 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id xa12so2673668pbc.11 for ; Fri, 28 Jun 2013 13:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bCq4N+nNnNfFoEpTIhuE6/7KDKRnvBO3p1zFIqEahVI=; b=nkIed3NpoG7LzApCezKFG6U6jhCZKf0Ot6tBZwPIjzrB9EntcoFpxcDglSHblNl+1t eZWyrHVV4fZMxbK1OJc8aBdpYqCeN2E2qBkvdM5tnQHP7Le7ga8x8O11YzvSUmDn+3z6 E66dEfRXCryXPpgF8dnxs9srA6G++vyzHKObEEVoy51jxlTa+KxAeIqZ/T7EQQOKDsLq mXOy3oyBtf7ZlOGoKc7NGQWx6cMXuCF8ODGiuPfD/Hv0q41Dr1HnQCkAJq/MOAMXl7+F 8PabMU+Q4PtvwlG01NMCHRbBOun1mrC52F0JyyWwE0XUDE0ZzCxdNVtp1Ri7W+AMa5ib gYsA== X-Received: by 10.68.237.106 with SMTP id vb10mr13244881pbc.131.1372452528363; Fri, 28 Jun 2013 13:48:48 -0700 (PDT) Received: from [192.168.178.22] (10.198.69.111.dynamic.snap.net.nz. [111.69.198.10]) by mx.google.com with ESMTPSA id z5sm9678817pbk.0.2013.06.28.13.48.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Jun 2013 13:48:47 -0700 (PDT) Message-ID: <51CDF6BA.3010904@gmail.com> Date: Sat, 29 Jun 2013 08:48:58 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Havard Eidnes Subject: Re: draft-bonica-6man-frag-deprecate References: <20130628.152526.152295907.he@uninett.no> In-Reply-To: <20130628.152526.152295907.he@uninett.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 20:48:49 -0000 On 29/06/2013 01:25, Havard Eidnes wrote: > Hi, >=20 > some comments from this corner, some small, some not so...: >=20 >=20 > In section 1: >=20 > MTU is a unidirectional metric. A bidirectional link may be > characterized by one MTU in the forward direction and another > MTU in the reverse direction. >=20 > I'm sure this is formally true. However, in practice, I have > never seen a router where you can separately configure the > receive and transmit MTU. So ... I would remove this altogether; > it may otherwise pave the way for unsuspecting individuals > reading this to create a path MTU discovery black hole by > configuring inconsistent MTUs for devices on the same link. True, but of course *path* MTU may well be unidirectional, if the forward and reverse paths are different. PMTUD definitely has to allow for asymmetry, which is what counts for fragmentation. Brian >=20 >=20 > In section 2.1: >=20 > [Kent87] points out that the reassembly process is resource > intensive. It consumes significant compute and memory resources. >=20 > Is that argument still valid today? Is it impossible to engineer an > implementaiton which restricts the memory consumption in order to > improve robustness of the implementation? >=20 >=20 > Section 2.2 states "Fragmentation Is Rare". I think this will be > hihgly dependent on your choice of observation points. E.g. in the > vicinity of an NFS server serving using UDP, I would not be > surprised to see a lot of fragments. And, as has been mentioned > elsewhere in this discussion, in the vicinity of a DNSSEC-validating > recursive DNS resolver, you would expect to see an increasing > proportion of fragmented UDP traffic as DNSSEC deployment > progresses. >=20 >=20 > In section 2.2.1, the document appears to dismiss the DNSSEC use of > UDP and fragmentation with "use TCP instead". I beleive Mark > Andrews in <20130624030939.CA0DD363070C@drugs.dv.isc.org> stated why > this is far from good enough as an answer. In addition to TCP PMTUD > being too slow, you have the issue that TCP in general is about 3 > times slower than UDP in delivering a DNS response even if PMTUD is > not involved -- I beleive RIPE NCC Labs did a test using their "RIPE > Atlas" probes to check for this, and they came up with 2.5x - 3x as > the slowdown factor. Additionally there is the vastly increased > need to keep state in DNS name servers by the TCP load which would > result from the abolishment of UDP as a transport for DNS. >=20 > On top of this, there is the argument that "firewalls and network > operators may filter DNS over TCP", but I would not use that as an > argument because I consider it invalid -- more on that below. >=20 >=20 > Section 2.3, "Attack vectors". Isn't this whole section giving bad > excuses to IP stack implementors for not providing a robust and > well-tested implementation?!? BTW, I'm wondering whether there is a > spec issue lurking within this area, wrt. invalidating the most > obscure corner cases? >=20 >=20 > Section 2.4, "Operator behavior". It is claimed that IPv6 fragments > are being dropped in several places, e.g. by enterprise firewalls or > other environments who want to tightly control what traffic is > passed. I claim that is's a matter of principle whether we let the > tail wag the dog. Firewall administrators or other users of the > network may do unwise things when configuring their device, but > should such behaviour be allowed to restrict what becomes > standardized?!? If that were the case, we might as well all > restrict ourselves to speaking TCP over port 80. >=20 >=20 > Section 3, "Recommendation". I question whether you can in fact > make the backward-incompatible change of getting rid of the need for > implementations to support fragment reassembly -- the genie is > already out of the bottle -- has been for quite a while, and I claim > it's already too late to try to put it back in. So some of the > claimed attack vectors in section 2.3 will also be difficult to get > rid of, as hosts will in all probability have to continue to support > fragment reassembly for quite a while. >=20 > At the very least, there's a need to separate the recommendations > for "sending fragments" and "support reception of fragments". >=20 >=20 > Best regards, >=20 > - H=C3=A5vard > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From Fred.L.Templin@boeing.com Fri Jun 28 13:54:18 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE9121F9C06 for ; Fri, 28 Jun 2013 13:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsLcJ1k5MU-I for ; Fri, 28 Jun 2013 13:54:07 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id A210821F9BC4 for ; Fri, 28 Jun 2013 13:54:06 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r5SKs5Nj001296 for ; Fri, 28 Jun 2013 15:54:06 -0500 Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r5SKs4kb001286 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 28 Jun 2013 15:54:05 -0500 Received: from XCH-BLV-406.nw.nos.boeing.com (130.247.25.162) by XCH-NWHT-02.nw.nos.boeing.com (130.247.70.248) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 28 Jun 2013 13:54:04 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-BLV-406.nw.nos.boeing.com ([169.254.6.216]) with mapi id 14.02.0328.011; Fri, 28 Jun 2013 13:54:03 -0700 From: "Templin, Fred L" To: james woodyatt , 6man Subject: RE: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHOdD/OI1L7sow7kkSTr5SDOLoWMJlLmU1Q Date: Fri, 28 Jun 2013 20:54:03 +0000 Message-ID: <2134F8430051B64F815C691A62D983180B006F@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> <51CA2C56.1080809@gmail.com> <2134F8430051B64F815C691A62D983180AFF83@XCH-BLV-504.nw.nos.boeing.com> <09B6DBA3-0DF1-4BD9-98EF-E6CA672B977F@apple.com> In-Reply-To: <09B6DBA3-0DF1-4BD9-98EF-E6CA672B977F@apple.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 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 20:54:18 -0000 Hi James, > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > james woodyatt > Sent: Friday, June 28, 2013 1:41 PM > To: 6man > Subject: Re: New Version Notification for draft-bonica-6man-frag- > deprecate-00.txt >=20 > On Jun 28, 2013, at 12:32 , Templin, Fred L > wrote: > > [I wrote:] > >> > >> I'm also excited to learn about how we're going to add PLPMTUD to > GRE > >> and tunnel-mode IPsec ESP so they have some hope of using path MTU > >> larger than 1280 octets. > > > > https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ >=20 > I'm not sure I read this comment correctly. Are you suggesting that we > should replace tunnel-mode ESP and GRE tunnels with SEAL in order to > get PLPMTUD to work? No, I am saying that these and others are compatible with SEAL. The SEAL header has a "next header" field exactly like an IPv6 extension header, and that next header could be IPsec, GRE, etc. Used in this way, the SEAL header has the same footprint as an IPv6 fragmentation header. That said, SEAL could be used in place of other tunnel types like GRE and IPv6/IPv6. How they all fit together is something we should discuss either here or in intarea. > Are we all *really* okay with just trashing ESP > and GRE like that? Maybe we should be moving to deprecate those too? Not what I am suggesting. SEAL+GRE, SEAL+IPsec-ESP, etc. all work just fine. Thanks - Fred fred.l.templin@boeing.com =20 > -- > james woodyatt > core os networking >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Fri Jun 28 13:57:26 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185FB21F9C98 for ; Fri, 28 Jun 2013 13:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSGZM4T2KFyy for ; Fri, 28 Jun 2013 13:57:25 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 51F4021F9C06 for ; Fri, 28 Jun 2013 13:57:25 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa11so2862315pad.5 for ; Fri, 28 Jun 2013 13:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9jpATkEa86fG8/fiGiKZDkLfjC94J7zbYAolCvewUl4=; b=wcwwaGErmXUbamT5wsgyUG9ikr2S68r3Am4SWegV6wNYphic9Ykjd7h1mDUGtbm9j1 rCV+vFZPwd8KsH0vlNLd4c/mb3ldfv7DI/b1us+ZVSUXl05Rou6BmcACY6K9Vlsq/TDL rhjItEsOY2zwnY2PBLpwewo7Iji+E48p5I7lUv+IOuUSI5FyS6XVTtvlMt+Zy9fNJyqG 46Q3rgu2PB1K2sq6Eeaq78PmG3+SOb426nTywf1JGEKOQ7FGeFOYzzZ2zZBN38ACu4Re GuZ3slnWBzsF43tovQytyenQBsDK4g8JqQj88msamHenAAJ49EHfGnCH1eLJbIbcgpKu kMsA== X-Received: by 10.68.245.200 with SMTP id xq8mr13016608pbc.32.1372453044950; Fri, 28 Jun 2013 13:57:24 -0700 (PDT) Received: from [192.168.178.22] (10.198.69.111.dynamic.snap.net.nz. [111.69.198.10]) by mx.google.com with ESMTPSA id gb2sm9637593pbd.38.2013.06.28.13.57.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Jun 2013 13:57:24 -0700 (PDT) Message-ID: <51CDF8BF.6060002@gmail.com> Date: Sat, 29 Jun 2013 08:57:35 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: james woodyatt Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> <51CA2C56.1080809@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 20:57:26 -0000 One comment below... On 29/06/2013 07:21, james woodyatt wrote: > On Jun 28, 2013, at 08:36 , Erik Nygren wrote: >> [...] >> As such, I agree with other comments that it's important >> to re-emphasize that any environment that both blocks ICMPv6 PTB >> and at the same time doesn't allow 1500 byte packets through is broken >> and needs to get fixed. This also means that anyone deploying >> or implementing a tunnel (or VPN) needs to carefully consider >> how they'll deal with this. >> [...] > > And this is where I point at RFC 2473 "Generic Packet Tunneling in IPv6" section 7.2 "IPv4 Tunnel Packet Fragmentation" which I will quote for handy reference below: > >>> 7.2 IPv4 Tunnel Packet Fragmentation >>> >>> When an IPv4 original packet enters a tunnel, if the original packet >>> size exceeds the tunnel MTU (i.e., the Path MTU between the tunnel >>> entry-point and the tunnel exit-point, minus the size of the tunnel >>> header(s)), it is handled as follows: >>> >>> (a) if in the original IPv4 packet header the Don't Fragment - >>> DF - bit flag is SET, the entry-point node discards the >>> packet and returns an ICMP message. The ICMP message has >>> the type = "unreachable", the code = "packet too big", and >>> the recommended MTU size field set to the size of the >>> tunnel MTU - see sections 6.7 and 8.3. >>> >>> (b) if in the original packet header the Don't Fragment - DF - >>> bit flag is CLEAR, the tunnel entry-point node encapsulates >>> the original packet, and subsequently fragments the >>> resulting IPv6 tunnel packet into IPv6 fragments that do >>> not exceed the Path MTU to the tunnel exit-point. > > This is cited in RFC 6333 "Dual-stack Lite" section 5.3 "Fragmentation and Reassembly" which I will also quote for handy reference: > >>> 5.3. Fragmentation and Reassembly >>> >>> Using an encapsulation (IPv4-in-IPv6 or anything else) to carry IPv4 >>> traffic over IPv6 will reduce the effective MTU of the datagram. >>> Unfortunately, path MTU discovery [RFC1191] is not a reliable method >>> to deal with this problem. >>> >>> A solution to deal with this problem is for the service provider to >>> increase the MTU size of all the links between the B4 element and the >>> AFTR elements by at least 40 bytes to accommodate both the IPv6 >>> encapsulation header and the IPv4 datagram without fragmenting the >>> IPv6 packet. >>> >>> However, as not all service providers will be able to increase their >>> link MTU, the B4 element MUST perform fragmentation and reassembly if >>> the outgoing link MTU cannot accommodate the extra IPv6 header. The >>> original IPv4 packet is not oversized. The packet is oversized after >>> the IPv6 encapsulation. The inner IPv4 packet MUST NOT be >>> fragmented. Fragmentation MUST happen after the encapsulation of the >>> IPv6 packet. Reassembly MUST happen before the decapsulation of the >>> IPv4 packet. A detailed procedure has been specified in [RFC2473] >>> Section 7.2. > > Clearly, this proposal to deprecate IPv6 fragmentation headers entails an update to RFC 2473 and RFC 6333 as well as RFC 2460. The procedure for encapsulating IPv4 packets with DF=0 in IPv6 tunnels where the path MTU is less than typical IPv4 path MTU currently requires tunnel endpoints to use IPv6 fragment headers. I guess they have to stop doing that if this RFC is published. All this is why it seems reasonable to deprecate ("SHOULD NOT") fragmentation by hosts without disabling reassembly, and leave a window for cases such as foo-in-IPv6 tunnels where fragmentation is still useful. You just have to know that those tunnels won't work across certain middleboxes. > I'm also excited to learn about how we're going to add PLPMTUD to GRE and tunnel-mode IPsec ESP so they have some hope of using path MTU larger than 1280 octets. You mean a better chance than they have today, except on carefully tailored paths? Let's face it, this train left the station a while back. (This doesn't mean I'm happy, but it is what it is.) Brian From Fred.L.Templin@boeing.com Fri Jun 28 14:03:29 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9451D21F9A52 for ; Fri, 28 Jun 2013 14:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avt0f1yjUvuD for ; Fri, 28 Jun 2013 14:03:24 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 35B8621F9A50 for ; Fri, 28 Jun 2013 14:03:24 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r5SL3MEU002076 for ; Fri, 28 Jun 2013 14:03:22 -0700 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r5SL3MQD002070 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 28 Jun 2013 14:03:22 -0700 Received: from XCH-BLV-403.nw.nos.boeing.com (130.247.25.62) by XCH-NWHT-04.nw.nos.boeing.com (130.247.64.250) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 28 Jun 2013 14:03:23 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-BLV-403.nw.nos.boeing.com ([169.254.3.80]) with mapi id 14.02.0328.011; Fri, 28 Jun 2013 14:03:22 -0700 From: "Templin, Fred L" To: Brian E Carpenter , james woodyatt Subject: RE: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHOdEImFDUdty5cqE+ZfOAkvkuJfZlLnEVw Date: Fri, 28 Jun 2013 21:03:21 +0000 Message-ID: <2134F8430051B64F815C691A62D983180B00B6@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> <51CA2C56.1080809@gmail.com> <51CDF8BF.6060002@gmail.com> In-Reply-To: <51CDF8BF.6060002@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 Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 21:03:29 -0000 Hi Brian, > Let's face it, this train left the station a while back. (This doesn't > mean I'm happy, but it is what it is.) Do you mean that you want to give up and declare that the fixed MTU for IPv6 is 1280 now and for always (and remember, that still would not excuse tunnels from using frag/reass)? I still think the situation can be salvaged with something like SEAL, but if we want to just give up then I think I agree with others that we may need to increment the IP protocol version (I for one would not like to see that). Thanks - Fred fred.l.templin@boeing.com=20 =20 > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From otroan@employees.org Fri Jun 28 14:51:57 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3380421F9CF1 for ; Fri, 28 Jun 2013 14:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWfJkqtbtpcv for ; Fri, 28 Jun 2013 14:51:49 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 25E9321F9CF0 for ; Fri, 28 Jun 2013 14:51:49 -0700 (PDT) Received: from dhcp-10-61-104-121.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 4E6625F8C; Fri, 28 Jun 2013 14:51:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: draft-bonica-6man-frag-deprecate From: Ole Troan In-Reply-To: <2134F8430051B64F815C691A62D983180AEA5F@XCH-BLV-504.nw.nos.boeing.com> Date: Fri, 28 Jun 2013 17:51:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <51CB91E4.5090603@gmail.com> <2134F8430051B64F815C691A62D983180AEA5F@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1508) Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 21:51:57 -0000 >> This memo deprecates IPv6 fragmentation and the IPv6 fragment >> header. >> Application and transport layer protocols SHOULD support effective >> PMTU discovery [RFC4821], since ICMP-based PMTU discovery [RFC1981] >> is unreliable. Any application or transport layer protocol that >> cannot support effective PMTU discovery MUST NOT in any >> circumstances >> send IPv6 packets that exceed the IPv6 minimum MTU of 1280 bytes. >=20 > But, if those 1280 packets go into a tunnel they become (1280 + HLEN) > and are vulnerable to loss. This is even before we start talking about > tunnels-within-tunnels. It should therefore be well established by now > that tunnels over IPv6 MUST be capable of some form of frag/reass. in my understanding the 1280 minimum MTU for IPv6 was already chosen to = accommodate nested tunnels. the expectation made, I believe, was that native links support at least = an MTU of 1500 bytes, allowing 220 bytes for tunnel encap (5 IPv6 headers). you want to avoid reassembly at tunnel endpoints, if you care about = performance that is. cheers, Ole From fgont@si6networks.com Fri Jun 28 14:54:21 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3001621F9D4E for ; Fri, 28 Jun 2013 14:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PypeNOJfgNG for ; Fri, 28 Jun 2013 14:54:20 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 8353F21F9D32 for ; Fri, 28 Jun 2013 14:54:20 -0700 (PDT) Received: from [2001:5c0:1400:a::53b] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UsgcP-0002At-Ut; Fri, 28 Jun 2013 23:54:18 +0200 Message-ID: <51CE05E5.4040202@si6networks.com> Date: Fri, 28 Jun 2013 23:53:41 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "ipv6@ietf.org" Subject: Meta-issues: On the deprecation of the fragmentation function X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 21:54:21 -0000 Folks, I wanted to comment on some met-issues regarding the deprecation of the IPv6 fragmentation function. ** On the motivation of deprecating the fragmentation function ** So far (and without having read Ron's recent I-D -- shame on me), it looks like the main two reasons for deprecating the fragmentation function are: 1) The inability of middle-boxes to parse past the first XXX bytes of a packet 2) Unavailability of the connection-id (five-tuple) in the non-first fragments. Regarding "1)", I believe that deprecating fragmentation is not really the right solution. If anything, one could require the entire header chain to be within the first XXX bytes of a packet (as a former version of draft-ietf-6man-oversized-header-chain did). Besides, if we're going to deprecate the fragmentation function because of this, then we should also deprecate all extension headers, because they might lead to the same issue. Regarding "2)", IPv4 doesn't have the connection-id in the non-first fragments, either. So whatever middle-boxes are doing, they should/could do it in the same way as they currently do for IPv4. ** On the impact on applications ** It has been stated that fragmentation is uncommon. However, multiple uses for IPv6 fragmentation have been mentioned -- from NFS, to tunnels or the recent data posted by Mark Andrews. I think such use cases should really be considered. That aside, if the IPv6 fragmentation function is removed, it also means that UDP can only be used for applications that send datagrams smaller than 1280 bytes (assuming no Path-MTUD for UDP). I haven't done a survey myself, but I wonder to what extent one can really conclude there's no need for that (e.g., I'm told that in the stock market sector they employ multicast... which might mean that they need to send such "large" UDP datagrams). ** Therefore.... ** Considering the above, I guess I'm in the camp of "avoid fragmentation where possible". However, I don't think I'd go as far as deprecating it. Just my two cents. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian.e.carpenter@gmail.com Fri Jun 28 15:26:15 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6B421F9D23 for ; Fri, 28 Jun 2013 15:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.979 X-Spam-Level: X-Spam-Status: No, score=-101.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09vVyL18HFNd for ; Fri, 28 Jun 2013 15:26:15 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id DA8AB21F9D17 for ; Fri, 28 Jun 2013 15:26:14 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id um15so2774147pbc.10 for ; Fri, 28 Jun 2013 15:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EJtqJ4k6QCumek0wauYulnB124MPL1GW9ICZ9j37LjM=; b=SYgbgIVAjsDD/4kyzld2dYIm/R14rw1PZfmnbYPPsWtu8IZBQKnlEFfULDY2HZTgby QqUvPvmRGu84OpohvhzpOWwaEQXu28GHONFE84DLCcPCT3AVw83vFdq2xVQy+48EHYEs Zol0b5uNVDF/9ZeLLJ8iMM3ysfWhiJXDPTuY3oO4OoY9+YCm6Skf/2NlTqYtDMd+72px cHLQ4GnL/Q44HViXTaeBxgxv5YQvUQhA3jW8A8yXnX1ZWvY6u0fCzQ53nWCFfCJgkDdV RWlDMMx4HjH/VW4cIJB349PXGQ0BKKUx1qP63JMT8Ji2CW9lZhbGJ5h/xSSBSzVRwlyt 3ZOA== X-Received: by 10.67.21.229 with SMTP id hn5mr13622060pad.135.1372458374195; Fri, 28 Jun 2013 15:26:14 -0700 (PDT) Received: from [192.168.178.22] (10.198.69.111.dynamic.snap.net.nz. [111.69.198.10]) by mx.google.com with ESMTPSA id ag4sm9909898pbc.20.2013.06.28.15.26.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Jun 2013 15:26:13 -0700 (PDT) Message-ID: <51CE0D90.7090007@gmail.com> Date: Sat, 29 Jun 2013 10:26:24 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> <51CA2C56.1080809@gmail.com> <51CDF8BF.6060002@gmail.com> <2134F8430051B64F815C691A62D983180B00B6@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180B00B6@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 22:26:15 -0000 On 29/06/2013 09:03, Templin, Fred L wrote: > Hi Brian, > >> Let's face it, this train left the station a while back. (This doesn't >> mean I'm happy, but it is what it is.) > > Do you mean that you want to give up and declare that the fixed > MTU for IPv6 is 1280 now and for always (and remember, that still > would not excuse tunnels from using frag/reass)? No. I believe that (a) strongly recommending packetizatiion layer PMTUD and deprecating fragmentation at source is a sound long term policy and (b) accepting that strapping the MTU at 1280 is a reasonable short term policy. If (a) progressively pervades the installed base then (b) can be dropped as the years go by. (Though frankly I have never seen MTU problems in v6 since I stopped trying to use 6to4; I've used three different configured tunnel solutions, and various native services, without problems. So while there are clearly paths with this problem, I suspect they're a minority even today.) > I still think the situation can be salvaged with something like SEAL, > but if we want to just give up then I think I agree with others that > we may need to increment the IP protocol version (I for one would not > like to see that). In effect using SEAL is part of (a), for the cases where tunels are used, isn't it? Talk of changing the version number doesn't have much to do with the world that I live in. We have plenty of experience now of how easy it isn't to change the version number. Brian From Fred.L.Templin@boeing.com Fri Jun 28 15:27:31 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83EEA21F9D09 for ; Fri, 28 Jun 2013 15:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVlEO-yaj787 for ; Fri, 28 Jun 2013 15:27:25 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id EEFD821F9D17 for ; Fri, 28 Jun 2013 15:27:24 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r5SMRMnH023074 for ; Fri, 28 Jun 2013 15:27:22 -0700 Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r5SMRMMp023071 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 28 Jun 2013 15:27:22 -0700 Received: from XCH-EXCO-103.nw.nos.boeing.com (130.247.25.37) by XCH-NWHT-01.nw.nos.boeing.com (130.247.70.222) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 28 Jun 2013 15:27:22 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-EXCO-103.nw.nos.boeing.com ([fe80::7434:66d:a0ba:2234%15]) with mapi id 14.02.0328.011; Fri, 28 Jun 2013 15:27:22 -0700 From: "Templin, Fred L" To: Ole Troan Subject: RE: draft-bonica-6man-frag-deprecate Thread-Topic: draft-bonica-6man-frag-deprecate Thread-Index: AQHOdEmpUZaGJnzSMU6ZOUB9nA7EbJlLsY5g Date: Fri, 28 Jun 2013 22:27:21 +0000 Message-ID: <2134F8430051B64F815C691A62D983180B0221@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <51CB91E4.5090603@gmail.com> <2134F8430051B64F815C691A62D983180AEA5F@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 Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 22:27:31 -0000 Hi Ole, > in my understanding the 1280 minimum MTU for IPv6 was already chosen to > accommodate nested tunnels. Right, but.. > the expectation made, I believe, was that native links support at least > an MTU of 1500 bytes, But, that expectation went out the window at the same time the IPv6 minMTU was set to 1280 - so now 1280 is all that can be expected. So, without fragmentation, when the tunnel ingress receives a 1280 packet, it emits a (1280+HLEN) packet. If that packet is dropped at a link that configures a 1280 MTU, then it simply black holes. > allowing 220 bytes for tunnel encap (5 IPv6 headers). Tunnels within tunnels presents an additional pain point, but the plain truth is that IPv6 links only need to configure a 1280 MTU; not a 1500. > you want to avoid reassembly at tunnel endpoints, if you care about > performance that is. Unfortunately, reassembly is absolutely necessary if the tunnel is configured over a path that contains at least one 1280 link (see above). Thanks - Fred fred.l.templin@boeing.com =20 > cheers, > Ole From Fred.L.Templin@boeing.com Fri Jun 28 15:33:25 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12FE121F941F for ; Fri, 28 Jun 2013 15:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kbun4H9j-Di for ; Fri, 28 Jun 2013 15:33:18 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 54D2321F9346 for ; Fri, 28 Jun 2013 15:33:16 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r5SMXFAg014903 for ; Fri, 28 Jun 2013 17:33:15 -0500 Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r5SMXDUo014493 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 28 Jun 2013 17:33:14 -0500 Received: from XCH-EXCO-101.nw.nos.boeing.com (130.247.25.127) by XCH-NWHT-10.nw.nos.boeing.com (130.247.25.113) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 28 Jun 2013 15:33:13 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-EXCO-101.nw.nos.boeing.com ([fe80::fc2d:7b3b:2de5:b12c%15]) with mapi id 14.02.0328.011; Fri, 28 Jun 2013 15:33:13 -0700 From: "Templin, Fred L" To: Fernando Gont , "ipv6@ietf.org" Subject: RE: Meta-issues: On the deprecation of the fragmentation function Thread-Topic: Meta-issues: On the deprecation of the fragmentation function Thread-Index: AQHOdEoZI7x0xWSePUeIaE2lvBCrY5lLtSkA Date: Fri, 28 Jun 2013 22:33:12 +0000 Message-ID: <2134F8430051B64F815C691A62D983180B024E@XCH-BLV-504.nw.nos.boeing.com> References: <51CE05E5.4040202@si6networks.com> In-Reply-To: <51CE05E5.4040202@si6networks.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 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 22:33:25 -0000 Hi Fernando, > Considering the above, I guess I'm in the camp of "avoid fragmentation > where possible". However, I don't think I'd go as far as deprecating > it. I was originally thinking this way too, but now I am thinking that deprecation of an old method is often the first step in the path to adoption of a new method that avoids the old issues. There have been examples in the past (e.g., deprecation of site locals leading to ULAs), and I don't see why it would be any different in this case. Thanks - Fred fred.l.templin@boeing,cim From Fred.L.Templin@boeing.com Fri Jun 28 15:44:45 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2576221F9A14 for ; Fri, 28 Jun 2013 15:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.929 X-Spam-Level: X-Spam-Status: No, score=-5.929 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzfujGGLtSpM for ; Fri, 28 Jun 2013 15:44:33 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id D270221F99C3 for ; Fri, 28 Jun 2013 15:44:33 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r5SMiWFY012923 for ; Fri, 28 Jun 2013 15:44:32 -0700 Received: from XCH-PHX-213.sw.nos.boeing.com (xch-phx-213.sw.nos.boeing.com [130.247.25.142]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r5SMiW1h012920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 28 Jun 2013 15:44:32 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.48]) by XCH-PHX-213.sw.nos.boeing.com ([169.254.13.207]) with mapi id 14.02.0328.011; Fri, 28 Jun 2013 15:44:32 -0700 From: "Templin, Fred L" To: Brian E Carpenter Subject: RE: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Thread-Index: AQHOdE6FFDUdty5cqE+ZfOAkvkuJfZlLtvlA Date: Fri, 28 Jun 2013 22:44:32 +0000 Message-ID: <2134F8430051B64F815C691A62D983180B02A3@XCH-BLV-504.nw.nos.boeing.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> <51CA2C56.1080809@gmail.com> <51CDF8BF.6060002@gmail.com> <2134F8430051B64F815C691A62D983180B00B6@XCH-BLV-504.nw.nos.boeing.com> <51CE0D90.7090007@gmail.com> In-Reply-To: <51CE0D90.7090007@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 22:44:45 -0000 SGkgQnJpYW4sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4g RSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6 IEZyaWRheSwgSnVuZSAyOCwgMjAxMyAzOjI2IFBNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwNCj4g Q2M6IGphbWVzIHdvb2R5YXR0OyA2bWFuDQo+IFN1YmplY3Q6IFJlOiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LWJvbmljYS02bWFuLWZyYWctDQo+IGRlcHJlY2F0ZS0wMC50eHQN Cj4gDQo+IE9uIDI5LzA2LzIwMTMgMDk6MDMsIFRlbXBsaW4sIEZyZWQgTCB3cm90ZToNCj4gPiBI aSBCcmlhbiwNCj4gPg0KPiA+PiBMZXQncyBmYWNlIGl0LCB0aGlzIHRyYWluIGxlZnQgdGhlIHN0 YXRpb24gYSB3aGlsZSBiYWNrLiAoVGhpcw0KPiBkb2Vzbid0DQo+ID4+IG1lYW4gSSdtIGhhcHB5 LCBidXQgaXQgaXMgd2hhdCBpdCBpcy4pDQo+ID4NCj4gPiBEbyB5b3UgbWVhbiB0aGF0IHlvdSB3 YW50IHRvIGdpdmUgdXAgYW5kIGRlY2xhcmUgdGhhdCB0aGUgZml4ZWQNCj4gPiBNVFUgZm9yIElQ djYgaXMgMTI4MCBub3cgYW5kIGZvciBhbHdheXMgKGFuZCByZW1lbWJlciwgdGhhdCBzdGlsbA0K PiA+IHdvdWxkIG5vdCBleGN1c2UgdHVubmVscyBmcm9tIHVzaW5nIGZyYWcvcmVhc3MpPw0KPiAN Cj4gTm8uIEkgYmVsaWV2ZSB0aGF0IChhKSBzdHJvbmdseSByZWNvbW1lbmRpbmcgcGFja2V0aXph dGlpb24gbGF5ZXINCj4gUE1UVUQgYW5kIGRlcHJlY2F0aW5nIGZyYWdtZW50YXRpb24gYXQgc291 cmNlIGlzIGEgc291bmQgbG9uZw0KPiB0ZXJtIHBvbGljeQ0KDQpObyBkaXNhZ3JlZW1lbnQgaGVy ZS4NCg0KPiBhbmQgKGIpIGFjY2VwdGluZyB0aGF0IHN0cmFwcGluZyB0aGUgTVRVIGF0IDEyODAg aXMNCj4gYSByZWFzb25hYmxlIHNob3J0IHRlcm0gcG9saWN5LiBJZiAoYSkgcHJvZ3Jlc3NpdmVs eSBwZXJ2YWRlcw0KPiB0aGUgaW5zdGFsbGVkIGJhc2UgdGhlbiAoYikgY2FuIGJlIGRyb3BwZWQg YXMgdGhlIHllYXJzIGdvIGJ5Lg0KDQpPbmNlIGEgbGluayBzZXRzIGEgMTI4MCBNVFUsIGhvdyB3 aWxsIGl0IGtub3cgdGhhdCBpdCBpcyBub3cNCnNhZmUgdG8gaW5jcmVhc2UgdGhlIE1UVT8gQW5k LCBvbmNlIHNldCwgaG93IGNhbiB3ZSBleHBlY3QNCm9wZXJhdG9ycyB0byBnbyBiYWNrIGFuZCBy ZS1zZXQgaW4gdGhlIGZ1dHVyZS4gSU1ITywgc3RyYXBwaW5nDQp0aGUgTVRVIHRvIDEyODAgZXZl cnl3aGVyZSBub3cgd291bGQgYmVjb21lIG9zc2lmaWVkIGxvbmcgaW50bw0KdGhlIGZ1dHVyZS4N Cg0KPiAoVGhvdWdoIGZyYW5rbHkgSSBoYXZlIG5ldmVyIHNlZW4gTVRVIHByb2JsZW1zIGluIHY2 IHNpbmNlIEkgc3RvcHBlZA0KPiB0cnlpbmcgdG8gdXNlIDZ0bzQ7IEkndmUgdXNlZCB0aHJlZSBk aWZmZXJlbnQgY29uZmlndXJlZCB0dW5uZWwNCj4gc29sdXRpb25zLCBhbmQgdmFyaW91cyBuYXRp dmUgc2VydmljZXMsIHdpdGhvdXQgcHJvYmxlbXMuIFNvIHdoaWxlDQo+IHRoZXJlIGFyZSBjbGVh cmx5IHBhdGhzIHdpdGggdGhpcyBwcm9ibGVtLCBJIHN1c3BlY3QgdGhleSdyZSBhIG1pbm9yaXR5 DQo+IGV2ZW4gdG9kYXkuKQ0KPiANCj4gPiBJIHN0aWxsIHRoaW5rIHRoZSBzaXR1YXRpb24gY2Fu IGJlIHNhbHZhZ2VkIHdpdGggc29tZXRoaW5nIGxpa2UgU0VBTCwNCj4gPiBidXQgaWYgd2Ugd2Fu dCB0byBqdXN0IGdpdmUgdXAgdGhlbiBJIHRoaW5rIEkgYWdyZWUgd2l0aCBvdGhlcnMgdGhhdA0K PiA+IHdlIG1heSBuZWVkIHRvIGluY3JlbWVudCB0aGUgSVAgcHJvdG9jb2wgdmVyc2lvbiAoSSBm b3Igb25lIHdvdWxkIG5vdA0KPiA+IGxpa2UgdG8gc2VlIHRoYXQpLg0KPiANCj4gSW4gZWZmZWN0 IHVzaW5nIFNFQUwgaXMgcGFydCBvZiAoYSksIGZvciB0aGUgY2FzZXMgd2hlcmUgdHVuZWxzDQo+ IGFyZSB1c2VkLCBpc24ndCBpdD8NCg0KSSB3YXMgb3JpZ2luYWxseSB0aGlua2luZyBhYm91dCBT RUFMIGZvciBqdXN0IHR1bm5lbHMsIGJ1dCB0aGUNCnJlYWxpemF0aW9uIEkgYW0gY29taW5nIHRv IGlzIHRoYXQgaXQgY2FuIGFsc28gYmUgdXNlZCBhbnl3aGVyZQ0KdGhlIElQdjYgZnJhZ21lbnRh dGlvbiBoZWFkZXIgY2FuIGJlIHVzZWQgLSBpLmUuLCBib3RoIHR1bm5lbA0KYW5kIHRyYW5zcG9y dCBtb2RlcyBhcmUgcG9zc2libGUuIFRoYXQgaW5jbHVkZXMgdXNlIHdpdGggImF0b21pYw0KZnJh Z21lbnRzIiBhbmQgYXNzdXJhbmNlIHRoYXQgdGhlIFVMUCBoZWFkZXJzIGFyZSBjb250YWluZWQg aW4NCnRoZSBmaXJzdCBmcmFnbWVudC4gVGhpbmsgb2YgZGVwcmVjYXRpb24gb2YgdGhlIElQdjYg ZnJhZ21lbnQNCmhlYWRlciBhcyBnaXZpbmcgd2F5IHRvIGEgbmV3IG1ldGhvZCB0aGF0IGZpeGVz IGZyYWdtZW50YXRpb24sDQppLmUuLCB0aGUgc2FtZSBhcyBkZXByZWNhdGlvbiBvZiBzaXRlIGxv Y2FsIGdhdmUgd2F5IHRvIFVMQS4NCg0KPiBUYWxrIG9mIGNoYW5naW5nIHRoZSB2ZXJzaW9uIG51 bWJlciBkb2Vzbid0IGhhdmUgbXVjaCB0byBkbyB3aXRoDQo+IHRoZSB3b3JsZCB0aGF0IEkgbGl2 ZSBpbi4gV2UgaGF2ZSBwbGVudHkgb2YgZXhwZXJpZW5jZSBub3cgb2YNCj4gaG93IGVhc3kgaXQg aXNuJ3QgdG8gY2hhbmdlIHRoZSB2ZXJzaW9uIG51bWJlci4NCg0KSXQgd2FzIGEgcG9vciBwdW4g b24gbXkgcGFydCwgYW5kIG5vdCBzb21ldGhpbmcgSSB3b3VsZCBhZHZvY2F0ZS4NCkkgZG8gbm90 IG1lYW4gdG8gb2ZmZW5kIGFsbCBvZiB0aGUgY29udHJpYnV0b3JzIHdobyBoYXZlIHdvcmtlZA0K bG9uZyBhbmQgaGFyZCB0byBtb3ZlIElQdjYgZm9yd2FyZC4NCg0KVGhhbmtzIC0gRnJlZA0KZnJl ZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KDQo+ICAgIEJyaWFuDQo= From hannes@stressinduktion.org Fri Jun 28 16:54:31 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8125221F99B2 for ; Fri, 28 Jun 2013 16:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvkoY0FS3Igw for ; Fri, 28 Jun 2013 16:54:26 -0700 (PDT) Received: from order.stressinduktion.org (s15338416.onlinehome-server.info [87.106.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id 67C3221F888F for ; Fri, 28 Jun 2013 16:53:40 -0700 (PDT) Received: by order.stressinduktion.org (Postfix, from userid 500) id A54B11A0CC44; Sat, 29 Jun 2013 01:53:29 +0200 (CEST) Date: Sat, 29 Jun 2013 01:53:29 +0200 From: Hannes Frederic Sowa To: "Templin, Fred L" Subject: Re: Meta-issues: On the deprecation of the fragmentation function Message-ID: <20130628235329.GA6519@order.stressinduktion.org> References: <51CE05E5.4040202@si6networks.com> <2134F8430051B64F815C691A62D983180B024E@XCH-BLV-504.nw.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2134F8430051B64F815C691A62D983180B024E@XCH-BLV-504.nw.nos.boeing.com> Cc: Fernando Gont , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 23:54:31 -0000 On Fri, Jun 28, 2013 at 10:33:12PM +0000, Templin, Fred L wrote: > Hi Fernando, > > > Considering the above, I guess I'm in the camp of "avoid fragmentation > > where possible". However, I don't think I'd go as far as deprecating > > it. > > I was originally thinking this way too, but now I am thinking > that deprecation of an old method is often the first step in > the path to adoption of a new method that avoids the old issues. > There have been examples in the past (e.g., deprecation of site > locals leading to ULAs), and I don't see why it would be any > different in this case. While browsing the draft I wondered if applications do handle the EPROTO errno case for writes on a socket with a recevied icmp error parameter-problem correctly today. I doubt that recommending not implementing reassembly would be beneficial. Greetings, Hannes From brian.e.carpenter@gmail.com Fri Jun 28 21:19:59 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266B021F9E38 for ; Fri, 28 Jun 2013 21:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.772 X-Spam-Level: X-Spam-Status: No, score=-101.772 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wb4d3AWfzm2A for ; Fri, 28 Jun 2013 21:19:58 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id C2B1921F9E36 for ; Fri, 28 Jun 2013 21:19:58 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id um15so2935457pbc.38 for ; Fri, 28 Jun 2013 21:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TxtFefZ0EwlKnjJ9Yw4yrK0uy2BiO9zu7a6T68hbG3g=; b=xth2mNrkDboDVUkBAIlKIH1xmL8BNiigu0ssQR7pLaeI9isefXtWwXCY1O2lDXhzi8 dyhq1URxaaujzkEv60cJCY+G5dQXRpt8KwgJGFK2JR2keZepBo9XeUlnSGHgP1Zvf/cV CmsOBfE/V8ynTpYHU/lDof4dURyJiRTdzcYBMswykZLhb8eiiE7610pUNyNymA187giB SjNtC3n2pRVQo+EEr0cwXXLGCpBLWwTzZ/pIwge2fmiUBzC/yTNjGr44FmgAlhB4bt9c B03YGTty2QNDRE7R0TkdTQP/EboA2yK1TykclX4eSu47SOURCiWjYL/K+2UVOS4jLrJJ rnuQ== X-Received: by 10.66.163.130 with SMTP id yi2mr14287662pab.7.1372479598457; Fri, 28 Jun 2013 21:19:58 -0700 (PDT) Received: from [192.168.178.22] (10.198.69.111.dynamic.snap.net.nz. [111.69.198.10]) by mx.google.com with ESMTPSA id oy10sm12005562pac.9.2013.06.28.21.19.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Jun 2013 21:19:57 -0700 (PDT) Message-ID: <51CE6079.7060205@gmail.com> Date: Sat, 29 Jun 2013 16:20:09 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> <51CA2C56.1080809@gmail.com> <51CDF8BF.6060002@gmail.com> <2134F8430051B64F815C691A62D983180B00B6@XCH-BLV-504.nw.nos.boeing.com> <51CE0D90.7090007@gmail.com> <2134F8430051B64F815C691A62D983180B02A3@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983180B02A3@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 04:19:59 -0000 On one point... On 29/06/2013 10:44, Templin, Fred L wrote: ... >> and (b) accepting that strapping the MTU at 1280 is >> a reasonable short term policy. If (a) progressively pervades >> the installed base then (b) can be dropped as the years go by. > > Once a link sets a 1280 MTU, how will it know that it is now > safe to increase the MTU? And, once set, how can we expect > operators to go back and re-set in the future. IMHO, strapping > the MTU to 1280 everywhere now would become ossified long into > the future. It would certainly take years, but I think the end result would be implementors raising the default to the real link MTU, one stack at a time. I don't think you find many IPv4 stacks today with the MTU set low by default. Brian From dougb@dougbarton.us Fri Jun 28 22:35:03 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3413F21F9E65 for ; Fri, 28 Jun 2013 22:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.36 X-Spam-Level: X-Spam-Status: No, score=-1.36 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gN2S8IdHHGpo for ; Fri, 28 Jun 2013 22:35:02 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9C84721F9E63 for ; Fri, 28 Jun 2013 22:35:02 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:224:e8ff:fe30:109b] (unknown [IPv6:2001:470:d:5e7:224:e8ff:fe30:109b]) by dougbarton.us (Postfix) with ESMTPSA id 24E9922B0C for ; Sat, 29 Jun 2013 05:35:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1372484102; bh=3ogzYUiwnw7DiEVQvwYhs0vPOm3C320CeWiHeht+WV0=; h=Date:From:To:Subject:References:In-Reply-To; b=XDUC7j4j7p/LssF/EMMAgkS+8EqYUFISc8fh36eFIRQ8U9mMAadqUSTR49DL5hHJC 4/idotmV5rjmiMd4DpRr3NKl9mFXvahcEm29rJdZicsj+ZFmWLovIpeJ+VPMhNmZ5F RUJu1AXuN5RnX7gONiXaveykx4wf8W0mWo/9hJTE= Message-ID: <51CE7205.4090509@dougbarton.us> Date: Fri, 28 Jun 2013 22:35:01 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <3B0D9447-D39F-4165-9B43-019C3513101A@employees.org> <51CA2C56.1080809@gmail.com> <51CDF8BF.6060002@gmail.com> <2134F8430051B64F815C691A62D983180B00B6@XCH-BLV-504.nw.nos.boeing.com> <51CE0D90.7090007@gmail.com> <2134F8430051B64F815C691A62D983180B02A3@XCH-BLV-504.nw.nos.boeing.com> <51CE6079.7060205@gmail.com> In-Reply-To: <51CE6079.7060205@gmail.com> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 05:35:03 -0000 On 06/28/2013 09:20 PM, Brian E Carpenter wrote: > On one point... > > > On 29/06/2013 10:44, Templin, Fred L wrote: > ... >>> and (b) accepting that strapping the MTU at 1280 is >>> a reasonable short term policy. If (a) progressively pervades >>> the installed base then (b) can be dropped as the years go by. >> >> Once a link sets a 1280 MTU, how will it know that it is now >> safe to increase the MTU? And, once set, how can we expect >> operators to go back and re-set in the future. IMHO, strapping >> the MTU to 1280 everywhere now would become ossified long into >> the future. > > It would certainly take years, but I think the end result would be > implementors raising the default to the real link MTU, one stack > at a time. I don't think you find many IPv4 stacks today with > the MTU set low by default. I think an argument can be made that in today's world 1500 MTU (which is the fairly ubiquitous default) IS actually low. Doug From v6ops@globis.net Fri Jun 28 23:13:01 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552B221F9E43 for ; Fri, 28 Jun 2013 23:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sl3Ikt2quBfX for ; Fri, 28 Jun 2013 23:13:00 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id AFD3821F9E16 for ; Fri, 28 Jun 2013 23:13:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id DAE8787006B for ; Sat, 29 Jun 2013 08:12:44 +0200 (CEST) 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 Yl6EClMhkdd6 for ; Sat, 29 Jun 2013 08:12:44 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id B6905870047 for ; Sat, 29 Jun 2013 08:12:44 +0200 (CEST) Message-ID: <51CE7AD6.1040908@globis.net> Date: Sat, 29 Jun 2013 08:12:38 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: 6man Mailing List Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 06:13:01 -0000 With all this talk of 1280 as the minimum *link* MTU, I think it's easy to forget that 2460 states: > A node must be able to accept a fragmented packet that, after > reassembly, is as large as 1500 octets. A node is permitted to > accept fragmented packets that reassemble to more than 1500 octets. > An upper-layer protocol or application that depends on IPv6 > fragmentation to send packets larger than the MTU of a path should > not send packets larger than 1500 octets unless it has assurance that > the destination is capable of reassembling packets of that larger > size. So there was a very clear expectation that the *application level API* could always rely on being able to transmit as much data as it wanted as long as it didn't exceed a *1500* octet packet, and that this would always be reliably transmitted end to end. Anyone not transmitting this data across their network is currently ignoring a must in 2460. We should not forget the effect that changing such an important API parameter will have. I think Brian Carpenter has certainly got that in his suggestion. But perhaps some additional limits on the sanity of fragments might allow us to maintain a minimum 1500 octet limit at the API level, whilst allowing middleware boxes to process them correctly? [ I do realise that (nested) tunnels will always be problematic, no matter where you set any MTU limit, but that's nothing new and we have ways of dealing with that] regards, RayH From antonios.atlasis@gmail.com Fri Jun 28 23:55:01 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9241221F979E for ; Fri, 28 Jun 2013 23:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rL569DmRzloG for ; Fri, 28 Jun 2013 23:55:00 -0700 (PDT) Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id D0B4321F883B for ; Fri, 28 Jun 2013 23:54:55 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id 1so972967qee.40 for ; Fri, 28 Jun 2013 23:54:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=krad3vvXvvUf3Dws1h9+FtYJJxnQDowwrNTPi9i2NgU=; b=WX/RAxZv3HjTjFHb2TMeyjmVby00UbeSQEfx9h1TgVmJ/7vfjS6F3OXkF5+R9bOcnS qE8BwbqWuKPFVni+rcm1iAci4Aa9QBBvanTIXaPyGbScpPjnoxa5u4r7dWIRevY271KW zK6w5HPAWNeVEbCqT6YBDuvZw1SJ0QYnW5aQAK3TiqSNq8X/J+94Oi9t7XOPUCb5+Hj1 VaQA0iEOBfvzLuq9rxaF4nKjjJQ/7YnMg9ArhS0hhZaT3Bup83yTym3Wo4XQiadkd0UT 7naEjXEU3xX0g4zUGpbjGtYNtxgnRDPiz0oD4Qvqxq5+eNVy5sLsUYZcrLmB5OqMVWA/ qeEQ== MIME-Version: 1.0 X-Received: by 10.229.204.131 with SMTP id fm3mr4978056qcb.15.1372488895315; Fri, 28 Jun 2013 23:54:55 -0700 (PDT) Received: by 10.224.184.79 with HTTP; Fri, 28 Jun 2013 23:54:55 -0700 (PDT) In-Reply-To: <51CE05E5.4040202@si6networks.com> References: <51CE05E5.4040202@si6networks.com> Date: Sat, 29 Jun 2013 09:54:55 +0300 Message-ID: Subject: Re: Meta-issues: On the deprecation of the fragmentation function From: Antonios Atlasis To: Fernando Gont Content-Type: multipart/alternative; boundary=001a11c2bc0210463304e0457927 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 06:55:01 -0000 --001a11c2bc0210463304e0457927 Content-Type: text/plain; charset=ISO-8859-1 +1 for Fernando's comments 2013/6/29 Fernando Gont > Folks, > > I wanted to comment on some met-issues regarding the deprecation of the > IPv6 fragmentation function. > > ** On the motivation of deprecating the fragmentation function ** > > So far (and without having read Ron's recent I-D -- shame on me), it > looks like the main two reasons for deprecating the fragmentation > function are: > > 1) The inability of middle-boxes to parse past the first XXX bytes of a > packet > > 2) Unavailability of the connection-id (five-tuple) in the non-first > fragments. > > Regarding "1)", I believe that deprecating fragmentation is not really > the right solution. If anything, one could require the entire header > chain to be within the first XXX bytes of a packet (as a former version > of draft-ietf-6man-oversized-header-chain did). Besides, if we're going > to deprecate the fragmentation function because of this, then we should > also deprecate all extension headers, because they might lead to the > same issue. > > Regarding "2)", IPv4 doesn't have the connection-id in the non-first > fragments, either. So whatever middle-boxes are doing, they should/could > do it in the same way as they currently do for IPv4. > > > ** On the impact on applications ** > > It has been stated that fragmentation is uncommon. However, multiple > uses for IPv6 fragmentation have been mentioned -- from NFS, to tunnels > or the recent data posted by Mark Andrews. I think such use cases should > really be considered. > > That aside, if the IPv6 fragmentation function is removed, it also means > that UDP can only be used for applications that send datagrams > smaller than 1280 bytes (assuming no Path-MTUD for UDP). I haven't done > a survey myself, but I wonder to what extent one can really conclude > there's no need for that (e.g., I'm told that in the stock market sector > they employ multicast... which might mean that they need to send such > "large" UDP datagrams). > > > ** Therefore.... ** > > Considering the above, I guess I'm in the camp of "avoid fragmentation > where possible". However, I don't think I'd go as far as deprecating it. > > Just my two cents. > > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a11c2bc0210463304e0457927 Content-Type: text/html; charset=ISO-8859-1
    +1 for Fernando's comments


    2013/6/29 Fernando Gont <fgont@si6networks.com>
    Folks,

    I wanted to comment on some met-issues regarding the deprecation of the
    IPv6 fragmentation function.

    ** On the motivation of deprecating the fragmentation function **

    So far (and without having read Ron's recent I-D -- shame on me), it
    looks like the main two reasons for deprecating the fragmentation
    function are:

    1) The inability of middle-boxes to parse past the first XXX bytes of a
    packet

    2) Unavailability of the connection-id (five-tuple) in the non-first
    fragments.

    Regarding "1)", I believe that deprecating fragmentation is not really
    the right solution. If anything, one could require the entire header
    chain to be within the first XXX bytes of a packet (as a former version
    of draft-ietf-6man-oversized-header-chain did). Besides, if we're going
    to deprecate the fragmentation function because of this, then we should
    also deprecate all extension headers, because they might lead to the
    same issue.

    Regarding "2)", IPv4 doesn't have the connection-id in the non-first
    fragments, either. So whatever middle-boxes are doing, they should/could
    do it in the same way as they currently do for IPv4.


    ** On the impact on applications **

    It has been stated that fragmentation is uncommon. However, multiple
    uses for IPv6 fragmentation have been mentioned -- from NFS, to tunnels
    or the recent data posted by Mark Andrews. I think such use cases should
    really be considered.

    That aside, if the IPv6 fragmentation function is removed, it also means
    that UDP can only be used for applications that send datagrams
    smaller than 1280 bytes (assuming no Path-MTUD for UDP). I haven't done
    a survey myself, but I wonder to what extent one can really conclude
    there's no need for that (e.g., I'm told that in the stock market sector
    they employ multicast... which might mean that they need to send such
    "large" UDP datagrams).


    ** Therefore.... **

    Considering the above, I guess I'm in the camp of "avoid fragmentation
    where possible". However, I don't think I'd go as far as deprecating it.

    Just my two cents.

    Cheers,
    --
    Fernando Gont
    SI6 Networks
    e-mail: fgont@si6networks.com
    PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------


    --001a11c2bc0210463304e0457927-- From otroan@employees.org Sun Jun 30 07:45:57 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACD321F9A34 for ; Sun, 30 Jun 2013 07:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.38 X-Spam-Level: X-Spam-Status: No, score=-9.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-7eV9XgoI+d for ; Sun, 30 Jun 2013 07:45:48 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id B7D0A21F9A0B for ; Sun, 30 Jun 2013 07:45:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAFS6zFGQ/khL/2dsb2JhbABbKIJhwAaBAhZ0giMBAQQBOj8FCwtGVwaIGwa7So8iMweDAmMDk3OVF4MtIA X-IronPort-AV: E=Sophos;i="4.87,969,1363132800"; d="scan'208";a="14668153" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 30 Jun 2013 14:45:45 +0000 Received: from dhcp-10-61-102-53.cisco.com (dhcp-10-61-102-53.cisco.com [10.61.102.53]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5UEjg3E002187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 30 Jun 2013 14:45:43 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: draft-bonica-6man-frag-deprecate From: Ole Troan In-Reply-To: <2134F8430051B64F815C691A62D983180B0221@XCH-BLV-504.nw.nos.boeing.com> Date: Sat, 29 Jun 2013 02:55:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <520FB317-19E8-4DCA-81FB-124B17732FE0@employees.org> References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <51CB91E4.5090603@gmail.com> <2134F8430051B64F815C691A62D983180AEA5F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D983180B0221@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1508) Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 14:45:57 -0000 Fred, >> in my understanding the 1280 minimum MTU for IPv6 was already chosen = to >> accommodate nested tunnels. >=20 > Right, but.. >=20 >> the expectation made, I believe, was that native links support at = least >> an MTU of 1500 bytes, >=20 > But, that expectation went out the window at the same time the IPv6 > minMTU was set to 1280 - so now 1280 is all that can be expected. quite the opposite. physical link MTUs aren't getting smaller. do you have any evidence that operators set the IPv6 MTU to a value = smaller than the MTU supported by the link-layer? as far as I can see the setting IPv6 minimum MTU to 1280, which gives = ample room for nested tunnels works as designed. > So, without fragmentation, when the tunnel ingress receives a 1280 > packet, it emits a (1280+HLEN) packet. If that packet is dropped > at a link that configures a 1280 MTU, then it simply black holes. >=20 >> allowing 220 bytes for tunnel encap (5 IPv6 headers). >=20 > Tunnels within tunnels presents an additional pain point, but the > plain truth is that IPv6 links only need to configure a 1280 MTU; > not a 1500. again, why would anyone do that? the pain here is fragmentation, not supporting an MTU larger than 1280. >> you want to avoid reassembly at tunnel endpoints, if you care about >> performance that is. >=20 > Unfortunately, reassembly is absolutely necessary if the tunnel is > configured over a path that contains at least one 1280 link (see = above). reassembly in the network is a non-starter. the vendor I'm most familiar with does not do this in hardware. sure, = you can get reassembly, but at an order of one or two magnitudes less. = if anyone know of platforms doing IPv6 fragment reassembly at line rate = for 10G or 100G interfaces I'll stand corrected. ;-) for now reassembly in the network is not realistic. cheers, Ole= From heard@pobox.com Sun Jun 30 13:42:10 2013 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4BB21F9C51 for ; Sun, 30 Jun 2013 13:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOg5K-riZQ1k for ; Sun, 30 Jun 2013 13:42:06 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id D177921F9C4F for ; Sun, 30 Jun 2013 13:42:05 -0700 (PDT) Received: (qmail 12479 invoked from network); 30 Jun 2013 13:42:02 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Jun 2013 13:42:02 -0700 Date: Sun, 30 Jun 2013 13:42:02 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: IPv6 Subject: Re: Meta-issues: On the deprecation of the fragmentation function In-Reply-To: <51CE05E5.4040202@si6networks.com> Message-ID: References: <51CE05E5.4040202@si6networks.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625015317.6B256363BD8F@drugs.dv.isc.org> <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625040207.1CCA7363C42A@drugs.dv.isc.org> <51C98103.4050008@fud.no> <010f01ce71e3$7f43aea0$7dcb0be0$@tndh.net> <20130625233717.618C53642429@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 20:42:10 -0000 On Fri, 28 Jun 2013, Fernando Gont wrote: Fernando> I wanted to comment on some met-issues regarding the deprecation of the Fernando> IPv6 fragmentation function. Fernando> Fernando> ** On the motivation of deprecating the fragmentation function ** Fernando> Fernando> So far (and without having read Ron's recent I-D -- shame on me), it Fernando> looks like the main two reasons for deprecating the fragmentation Fernando> function are: Fernando> Fernando> 1) The inability of middle-boxes to parse past the first XXX bytes of a Fernando> packet Fernando> Fernando> 2) Unavailability of the connection-id (five-tuple) in the non-first Fernando> fragments. I disagree -- I think Mark Andrews got it (mostly) right in his message of Wed, 26 Jun 2013: Mark> One needs to get the L4 information the firewall/loadbalancer uses in *each* fragment. The flow label, if properly set at or near the source, could plausibly address "2)" -- see https://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label-balancing/?include_text=1 However, it won't help middle boxes that implement stateless packet filters. Indeed, such boxes have fundamental problems with non-first fragments irrespective of how many bytes of extension headers they can parse or whether there are sufficient length limits on the extension header chain that guarantee that the L4 header always appears in the first fragment. As I see it, the biggest meta-issue in this discussionis for the IPv6 WG is to decide out whether middle boxes that implement stateless packet filters with a "default-deny" policy will be a significant part of the landscape indefinitely, regardless of what the IETF says about their merits or lack thereof. If so, fragmented IP datagrams will continue be problematic in the general case; and since the job of this (or any other) IETF WG is to make the internet work better, it will be incumbent on the WG to deal with the issue. Ron Bonica and co-authors have made one proposal to do just that. Thinking aloud ... If we decide that the only path forward is to deprecate IPv6 fragmentation and reassambly (presumably not IPv4, since it's at end of life), the next question I see is what can or should be done to allow UDP and kin to send large datagrams. A UDP replacement with fragmentation and reassembly built in to the transport layer is one possibility. The questions that come to mind are (a) is this capability actually needed, and if so, (b) can it be incrementally deployed, in the face of middle boxes with "default deny" policies causing them to discard protocols that they don't know? //cmh